Subject: Meta: goals for IETF Routing area

From: Alex Zinin <[email-masked]>
Date: Fri, 23 May 2003 23:05:10 -0700

Folks-

 I started writing the message to start the discussion on
 under-specification vs over-specification and quickly realized that
 my thoughts are based on some fundamental assumptions about the IETF
 and the Routing area in particular. It seems that a discussion on
 this would be useful to at least realize where we all stand so we can
 understand where people come from.

 Here are some of the most basic statements I have in mind, by no
 means complete, but roughly what I think:

 S1: The goal of the IETF process is to produce technical specifications
     that can be used to develop multiple independent implementations
     that can interoperate with each other.

 S2: One of the direct responsibilities of the WGs within the Routing
     area is to ensure continuos operational status of the Internet
     routing system by maintaining scalability and stability
     characteristics of the existing routing protocols, as well as
     developing new protocols, extensions, and bug fixes in a timely
     manner.

 Corollaries from the above:

 C1: Specifications produced within the Routing area need to specify
     enough details to ensure that an informed reader unfamiliar with
     the specific subject of the document can write an implementation
     that a) can interoperate with others and b) does not affect
     the aspects described in S2 above.

 C2: We (the routing community, including vendors, and users) need to
     be able to conduct adequate review of proposals affecting the
     Internet routing protocols so that we can filter out bad ideas,
     fix bugs and improve the mechanisms by leveraging the collective
     wisdom.

 Let's keep this warm and friendly, but open ;)

 Regards.
     
-- 
Alex
http://www.psg.com/~zinin/

---

From: Russ White <[email-masked]>
Date: Tue, 27 May 2003 17:48:03 -0400 (Eastern Daylight Time)

>      that can interoperate with each other.

Agreed.

>      developing new protocols, extensions, and bug fixes in a timely

Agreed.

>      the aspects described in S2 above.

This is much harder--what do you mean by "an informed reader," and "enough
details?" For instance, SPF operation. How should you sort the TENT? What
sort of SPF should you use (there are other than djikstra, after all)?
There are a lot of questions here that, if the reader is not informed
about, you could clearly argue that they should be described to handle S2
above.

But.... You are not just treading on implementation stuff here, you're also
treading on the ability to improve the protocol through real world
experiments. For instance, what if the OSPF specs said you would use
Djikstra SPF, and someone wanted to try something different? Let's say this
other implementation produces performance that is dramatically faster than
other implementations.

Should this implementation be called "nonstandard," because it doesn't use
djkistra?

There is an art in deciding where to draw the line, and it all depends on
what you consider "a well informed implementor." Is this someone who's had
x amount of years of school? Experience at a major implementor? Or, what
other requirements would you name?

I don't think it's all that easy to say. We should probably sway more
towards examples of how things work, without making those examples
normative. There's nothing to gain to the community, imho, in making things
obtuse simply to make them obtuse. There's also nothing to gain to the
community by specifying a lot of things.

So, we need to balance, somehow.

>      fix bugs and improve the mechanisms by leveraging the collective

Yes, and this is more difficult, on multiple fronts. For one, we all have a
different view of who this "well informed implementor" dude (or gal) is.
This means we all have different ideas of what needs to be documented, and
what doesn't.

Second, we all play the "balance game" of how to keep our competative edges
for out company's, and how we work to grow the internet as a whole.
Because, we have to face it, the more stable and faster routing is, the
more attractive the internet, and networks in general, look for carrying
various things, and thus, the more the internet will grow, and thus the
larger market each of our companies will have to work in.

You can either work to make the pie bigger, or work to make your piece of
the pie bigger. There has to be a balance between these two. Some people
are on one extreme (hey, the pie is going to get bigger on its own, so we
should just snatch up as much of a piece as we can while the gettin's
good), and others are on the other extreme (unless I publish my company's
internal information, the pie wont' grow). I think we all know it's
someplace in the middle, but the motiviations are different in big and
little vendors, and even in big and little operators.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Alex Zinin <[email-masked]>
Date: Wed, 28 May 2003 01:15:05 -0700

Russ,

> This is much harder--what do you mean by "an informed reader,"

I like Curtis'es definition:

                                                              ...one
     possessing a thorough understanding of foundations of this work,
     including IP routing, TCP, TCP programming, and the referenced
     documents...

> and "enough details?"

Just enough, overspecification is not a goal.

> For instance, SPF operation. How should you sort the TENT? What

I think we had a good agreement on this during the discussion on the
isis-admin-tags document--i.e., specify that next-hop calculation
should be based on the SPT, and provide the description of a way
to calculate it (e.g. Dijkstra) for informational purposes. The point
here is that all implementations should end up with the same routes
and next-hops.

> other implementation produces performance that is dramatically faster than

Do you think the above approach would leave enough space for
innovation?

> Should this implementation be called "nonstandard," because it doesn't use

Nope.

> normative.

Agree that examples are useful even if informative, especially in
situations where there are potentially multiple ways of doing
something and one doesn't want to/there's no reason to limit
implementations to do it one way.

On the other hand, just examples, without any normative text
specifying the framework does not seem enough.

> There's nothing to gain to the community, imho, in making things

> So, we need to balance, somehow.

Agreed. Would "just enough details" be a better wording choice?

> little vendors, and even in big and little operators.

It seems that there should still be a way to agree on the criteria
for what should be specified and what may be left out. Quick thoughts:

  If potential deviations of an implementation wrt
     a certain part of the spec can:

      a) affect interoperability with other new or existing
         implementations, OR

      b) affect characteristics of the distributed system
         (read: scalability and stability), OR

      c) affect the ability of the SPs to effectively deploy,
         configure, or troubleshoot the protocol

  then the spec should provide recommended behavior.

Comments?
  
Alex

---

From: David Meyer <[email-masked]>
Date: Wed, 28 May 2003 09:29:43 -0700

Alex/Russ/All,

>>      including IP routing, TCP, TCP programming, and the referenced

	Unfortunately, "thorough understanding of foundations of
	this work" really  doesn't add any information, as we
	would then need to define/understand what constitutes 
	"thorough understanding of foundations...". As Russ said,
	this is *harder*. All of this being said, I don't have
	any better language here.

>> here is that all implementations should end up with the same routes

	But why do we care how they computed it (for whatever
	value if "it") if they come out with the same (external)
	behavior? Isn't this is the on-the-wire issue: That is,
	what do we care what is "inside the box" if the
	implementation behaves according to spec? Does it really
	matter? In fact, specification at this level may cross
	the so-called vendor-differentiation/innovation-space line. 

>> > But.... You are not just treading on implementation stuff
>> > here, you're also treading on the ability to improve the
>> > protocol through real world experiments. For instance, what
>> > if the OSPF specs said you would use Djikstra SPF, and
>> > someone wanted to try something different? Let's say this 
>> > other implementation produces performance that is
>> > dramatically faster than other implementations.
>> 

	See my comment above.

>> > Should this implementation be called "nonstandard," because it doesn't use

	Good.

>> specifying the framework does not seem enough.

	I agree with this. But perhaps we want to focus on
	(external-to-the-box) behavior rather than
	(internal-to-the-box) mechanism?

>> Agreed. Would "just enough details" be a better wording choice?

	Again, this seems to be at least ambiguous (i.e., please
	define "just enough detail").

>>       a) affect interoperability with other new or existing

	Good.

>>          (read: scalability and stability), OR

	Good.

>>          configure, or troubleshoot the protocol

	This one is likely an artifact of something else (likely
	a) and b) above, at least).
>>   then the spec should provide recommended behavior.

	The provide the recommended external behavior, I would
	imagine.

	Dave

---

From: Alex Zinin <[email-masked]>
Date: Wed, 28 May 2003 10:27:48 -0700

Dave,

>         any better language here.

The way I look at it myself is:

 a) for a completely new protocol specification, the reader should know
    how IP in general and IP routing in particular work (i.e., the
    notions of a route, routing table, the packet forwarding process)

 b) for a protocol extension, add the base protocol specification to
    the list of prerequisites.

The gray area is in how well/thorough understanding is, but I guess
the main thing here is that you don't have to re-explain those ideas
again, and can instead assume the reader has the knowledge and just
include a ref in the spec.

>         value if "it")

We don't. Note "for informational purposes above"

> if they come out with the same (external)

I am pessimistic about the concept of specifying only what's on the
wire. Clearly there are a number of node-local decisions (such as
route calculation, LSP origination/refreshment rates) that affect the
behavior of the distributed system.

However, it is not the intent to get into the "how to implement"
space, but rather make sure the specs contain sufficient details
to setup the framework that guarantees interoperability and
domain/Internet-wide behavior, yet leaving enough space for
implementation creativity.

>         (internal-to-the-box) mechanism?

See above

>         define "just enough detail").

Let's see below.

>         a) and b) above, at least).

Could be, but not necessarily.

Example: when I read the isis-admin-tags spec, it required conformant
systems to be able to originate tag TLVs, but it did not require them
to be able to act on those. In this situation, while the spec talks
about controlling prefix distribution throughout the domain,
conformance to such spec would not mean being able to actually control
prefix distribution. In other words, if you asked a vendor a question
"do you support RFC XXXX" and got a positive answer, it wouldn't mean
you can use that implementation to actually control prefix
distribution.

>         The provide the recommended external behavior, I would

I think we should agree on the terminology here. I guess what you mean
here is "externally visible behavior" vs "implementation specific".
Note though that there's a class of node-local decisions that are
externally visible, e.g., route calculation or LSA/LSP origination as
I mentioned earlier.

Alex

---

From: David Meyer <[email-masked]>
Date: Wed, 28 May 2003 10:36:20 -0700

>> externally visible, e.g., route calculation or LSA/LSP origination as

	Yes, externally visable. But your point is well taken on
	the overall behavior of a distributed system.

	Dave