Subject: RE: Review of draft-ietf-idr-bgp4-17.txt

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 11 Sep 2002 14:14:17 -0400

Yakov:

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 2:05 PM
> To: Abarbanel, Benjamin
> Cc: [email-masked]
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Ben,
> 
> > > As a general comment, if you are going to split up your 
> remarks into 
> > > many tiny messages it would be very helpful if you would use 
> > > descriptive subjects.  Also, FYI you seem to have an 
> off-by-one error 
> > > in your reading of the page numbers.
> > >
> > Then I would need to place each item in a separate message, 
> as you saw
> > I grouped them as 5 issues per message. Per request from the ADS.
> > The subjects they cover could vary thus making the 
> description not bound to
> > one thing. Sorry.
> > 
> > I used the page number printed on the page not the word 
> processor generated
> > one. If I missed it, sorry.
> >  
> > > This message aggregates my replies to all your messages with the 
> > > subject "Review of draft-ietf-idr-bgp4-17.txt".
> > > 
> > > At 10:35 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > >4. In many places in the document the term Transport 
> > > Connection is used, and
> > > >in the FSM area the term TCP Connection is used. One generic 
> > > term should be
> > > >used   throughout the document in case a different transport 
> > > (like SCTP) is
> > > >used to service the BGP sessions.
> > > 
> > > As Yakov mentioned earlier, BGP is not actually 
> > > transport-independent.  This might equally well argue in favor of 
> > > dropping the "transport connection" pretense and just 
> saying "TCP" 
> > > throughout (applies to the FSM too, BTW).
> > > 
> > In the FSM draft, there is an effort to abstract things to 
> only mention
> > "transport connection" not "TCP", in this spec its the 
> other way around. We
> > clearly need a common way of describing the transport layer in all
> > BGP protocol related specs.
> 
> Please ask the author(s) of the FSM draft to use TCP.
>   
If the author who happens to be the Co Chair is reading this message.
The job is done already.

> > > A future protocol based on BGP 4 might be transport independent 
> > > and/or run over SCTP, but I think that is far beyond our current 
> > > scope.
> >  
> > Agreed, but IMHO, the BGP spec should describe the protocol 
> independent
> > of its use of the TCP layer and its details. But I think,
> > its so dependent on it now, that you almost have to redo 
> the BGP protocol
> > description to use a different transport layer (SCTP).  
> 
> With this in mind can we keep the comments focuses on 
> reality, and not 
> on what one would wish for.
>   
> [clipped...]
> 
> > > At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > >This complexity could have been avoided if withdrawn 
> routes and NRLI
> > > >prefixes with their attributes were mutually exclusive of 
> > > each other and
> > > >appeared in different update messages. If that was the case, 
> > > the priority of
> > > >which field to process first would have been as simple as 
> > > using "first come,
> > > >first served" message processing approach.
> > > 
> > > If wishes were horses, beggars would ride.  There are 
> plenty of ugly 
> > > bits of the protocol which I'd change if we had a clean 
> slate.  But 
> > > surely something this fundamental to the operation of the 
> > > protocol-as-deployed is not open for revision right now?
> >  
> > I threw this one out, just to see if anything can be done. 
> Knowing full 
> > well you guys will do nothing. But we can wish can't we?
> 
> One can certainly wish, but this is outside the scope of the current
> discussion. So, while commenting on the base spec please avoid
> including wishes in your comments.
>   
> [clipped...]
> 
> > > At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > >4. P. 31, section 6.8, Please rewrite this sentence from:
> > > >    "Comparing BGP Identifiers is done by treating them as 
> > > >     (4-octet long) unsigned integers."
> > > >  To This:
> > > >    "Comparing BGP Identifiers is done by treating them as 
> > > >     large numbers based
> > > >     on their IP Address type (e.g. IPv4, IPv6, etc.)."
> > > 
> > > The BGP identifier is a 4-byte quantity, not a variable 
> quantity.  I 
> > > think the sentence is fine as written.
> > >
> > I was thinking of IPv6 in which case a message format 
> change would be
> > required. My thinking is based on using full IPv6 routable 
> addresses 
> > for the BGP Identifier. 
> 
> Since it requires message format change, it is outside the scope
> of the current discussion. 
>
> > BTW I do not agree with the IPv6 Router-ID draft proposed 
> by someone.
> 
> What that has to do with the comments on the base BGP spec ?
>
Nothing, just an opinion on what was proposed.
 
> Yakov.

Wishfull thinking is how things get started. Otherwise
no one ever knows that there is a better way to do something. I am not
suggesting it be done now, but maybe in the future. Perhaps they should
be kept as future things. 

Ben

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 11 Sep 2002 11:19:51 -0700

Ben,

> be kept as future things. 

Or perhaps they should be kept as future comments (to be posted to the list
once we'll finish with the base spec).

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 Sep 2002 14:34:30 -0400

> be kept as future things. 

"Nobody, but nobody, who attempts to bend the entire world to his
will could possibly be accused of having a small ego.

"The reasonable man adapts himself to the world; the unreasonable
one persists in trying to adapt the world to himself.  Therefore
all progress depends on the unreasonable man."
                -- George Bernard Shaw

I keep waiting for Allegro to make a shirt that replaces "world"
with "BGP specification".

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Sep 2002 20:43:05 -0400

In message <[email-masked]>, 

Ben,

This is an IETF WG mailing list.  We are trying to accomplish a
specific task.  That is updating the BGP protocol spec.  Things that
are out of bounds for change have been clearly and repeatedly stated.

You are consistently wasting the time of hundreds if not thousands of
people reading this list and the dozen or more that are currently
active on this list.  Please use the list to comment on the BGP spec
within the bounds of what we reasonably can be expected to change and
the bounds that the WG chairs have already stated.

Curtis

ps - The WG chairs, ADs, or others can chime in but IMHO the bounds,
stated in part in prior messages, should be the following.

  1) If the document is incorrect, incomplete, or ambiguous, it has a
     flaw and needs to be changed.  Changing the protocol itself,
     except to reflect current implementation of multiple vendors, is
     out of bounds.  [under that assumption that by now we've made the
     implmentations work].  Changes to reflect a single vendor's
     idiosyncracies are out of bounds, particularly if no
     interoperability issues exist.

  2) If the document is unclear to the well qualified reader (one
     possessing a thorough understanding of foundations of this work,
     including IP routing, TCP, TCP programming, and the referenced
     documents) then the document may need to be changed to improve
     clarity.

  3) Editorial or document organization changes that would clearly
     improve clarity of the document in areas where clarity is
     deficient to the well qualified and carefull reader are welcome.
     Addition of background tutorial information is out of bounds.

This may help us make real progress.  In the past we haven't had to
explicitly state this but I think this time we do.  We seem to be
bogged down in minutia.

---

From: Alex Zinin <[email-masked]>
Date: Mon, 16 Sep 2002 15:20:04 -0700

Curtis,

Wednesday, September 11, 2002, 5:43:05 PM, Curtis Villamizar wrote:
[...]

>      implmentations work].

Correct

> Changes to reflect a single vendor's

"no interoperability issue" is key here. If in reality people have
to guess or reverse-engineer specific behavior of a particular
vendor's implementation (for instance because that particular vendor
has a large installed base, and one just can't go into a network
without it) even though that behavior does not follow what
the current spec says, I'd rather see this documented somehow (note
the difference between "documenting" and "mandating").

>      documents)

+ ", and not including knowledge of BGP implementations, BGP-related
books, articles or e-mail discussions"

> then the document may need to be changed to improve
>      clarity.

> explicitly state this but I think this time we do.  We seem to be

I guess Curtis'es point here is to make sure we do not go over the
line of putting in stuff that does not belong in the spec, and my
point is to make sure we do not abuse any formal or informal rules and
drop stuff important for interoperability because of this. Let's keep
the final goal in mind--making possible the development of independent
and interoperable implementations.

Alex