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

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 11 Sep 2002 13:27:47 -0400

John,

> 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.

> 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).  

> At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >1. P.6  section 4. Message Formats, its possible for the 
> source BGP peer IP
> >layer to fragment a message such that the receiving BGP peer 
> socket layer
> >would have to reassemble it. Need to mention this, since BGP 
> implementations
> >are required to do this.
> 
> Seems to me that this is out of the scope of BGP.  It's a transport 
> and network layer thing.
> 
Incorrect if you followed the previous messages here, Look at Appendix 6,
section 6.2.

> 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?

> At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >5. P. 20 Its not stated how we delete or modify Path 
> Attributes associated
> >with NLRI prefixes.
> 
> This is implicit in the definition of "route", which discussion I 
> will not repeat here, plus withdraw/replace behavior.  IMO we don't 
> need to further belabor the point in the spec (which is already wordy 
> enough and then some).
> 
I disagree, there is an assumption how one would delete or replace say
optional attributes, but no direct way of doing it. I think a good 
implementation spec does not require its reader to guess how to do 
something.

> At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >1. P.28, 2nd to last paragraph. The line that reads, "To be 
> semantically
> >correct, the IP address in the NEXT_HOP must not be the IP 
> address of the
> >receiving speaker, and the NEXT_HOP IP address must either 
> be the sender's
> >IP address (used to establish the BGP session), or the 
> interface associated
> >with the NEXT_HOP IP address must share a common subnet with 
> the receiving
> >BGP speaker..."
> >
> >This is not always true, what if the current ASBR BGP router 
> is advertising
> >an external AS route (to a IBGP Peer) whose NEXT_HOP IP 
> address is the IP
> >address of the EBGP peer in the other AS?
> 
> Doesn't apply.  Right before the text you quoted is this: "Semantic 
> correctness applies only to the external BGP links, and only when the 
> sender and the receiving speaker are one IP hop away from each other."
> 
OK, I withdraw the issue.

> At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >2. P. 29, Section 6.3. Add this rule near the attribute rules.
> >"Multiple prefixes that require the same attribute type with 
> different
> >values must never appear in the same update message".
> 
> This is implicit in the message format and therefore redundant -- you 
> don't have to forbid something which is just plain impossible.  IMO 
> redundancy is to be avoided, eschewed and shunned except where the 
> point being emphasized is subtle and easily missed (which does not 
> apply in this case IMO).
>
This rule just adds another flavor to the use of attributes. I agree it 
would be silly, since you would need duplicate attributes with different
values to coexist in the same message. I'll accept your point. 
 
> At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >3. P. 29, Section 6.5, Please rewrite this sentence from:
> >     "If a system does not receive successive KEEPALIVE and/or UPDATE
> >      and/or NOTIFICATION messages within the period 
> specified in the Hold
> >      Time field of the OPEN message ..."
> >
> >  To This:
> >     "If a system does not receive successive KEEPALIVE and/or UPDATE
> >      and/or any other BGP message within the period 
> specified in the Hold
> >      Time field of the OPEN message ..."
> 
> I disagree as previously discussed (see archives, I won't 
> repeat myself here).

Again, it opens the door to new features and functionality that the current
door is closed. I agree we can argue on this till the cows come home.
This one is up to the BGP ADS to decide.

> 
> If this change were to be made anyway, it would be important to 
> update the language of 4.4 ("KEEPALIVE Message Format") to make clear 
> that only updates and keepalives can be relied upon to reset the hold 
> time.
> 
> 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. BTW I do not agree with the IPv6 Router-ID
draft proposed by someone.
 
> At 10:58 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >3. P. 13, EGP, are there other EGP protocols other than BGP 
> that are in use?
> >If not, change EGP to BGP.
> 
> From the references section:
> 
>     [1] Mills, D., "Exterior Gateway Protocol Formal Specification",
>     RFC904, April 1984.
> 
> I suppose it might not hurt to stick a "[1]" in the origin code 
> section to add clarity.  The conflation of EGP-the-protocol and 
> EGP-the-class-of-protocols is unfortunate, but we're stuck with it 
> now.
> 
Yes, but does anyone use this form of EGP?

> At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >4. P. 50,  line, "If a route in Loc-RIB is excluded from a particular
> >Adj-RIB-Out the previously advertised route in that 
> Adj-RIB-Out must be
> >withdrawn from service by means of an UPDATE message (see 9.2)."
> >
> >Would like to rephrase the sentence for clarity,
> >"If a route in Loc-RIB is excluded from a particular 
> Adj-RIB-Out and was
> >previously advertised via Adj-RIB-Out, it must be withdrawn 
> from service by
> >means of an UPDATE message (see 9.2)."
> 
> If we're going for total claribility here, I would like to ask what 
> other way there is to advertise a route, since the proposed wording 
> implies that there are options other than placing it in Adj-RIB-Out. 
> I'd say either s/via Adj-RIB-Out// or simply keep the original 
> wording.
>
 OK, I withdraw the comment.
 
> At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >5. P. 50, section 9.1.4, The two fragments of this sentence 
> are redundant
> >and don't say anything new or simplify the content. Just 
> keep one fragment.
> >"A route describing a smaller set of destinations (a longer 
> prefix) is said
> >to be more specific than a route describing a larger set of 
> destinations (a
> >shorted prefix); similarly, a route describing a larger set 
> of destinations
> >(a shorter prefix) is said to be less specific than a route 
> describing a
> >smaller set of destinations (a longer prefix)."
> 
> I'm glad we seem to agree about the undesirability of redundancy. 
> However I would say that in this case, while the sentence is 
> uncomfortably wordy every part of it contributes.  The first clause 
> defines "more specific" the second, "less specific".
> 
> I'll grant you that the third and fourth parentheses could be dropped.
> 
Great!

> At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >6. P. 52, section 9.2.1.1 Change this sentence for clarity,
> >    "This rate limiting procedure applies on a per-destination basis,
> >although 
> >     the value of MinRouteAdvertisementInterval is set on a 
> per BGP peer
> >basis."
> >
> >  To This:
> >    "This rate limiting procedure applies on a per-destination basis,
> >although   
> >     the value of MinRouteAdvertisementInterval is set on a 
> BGP router (same
> >     value for all peers) basis."
> 
> I disagree.
why?
> 
> At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >8. Since there is going to be an FSM spec, do we need to have FSM
> >    descriptions in this spec. Maybe the FSM section should 
> be delete.
> 
> Yep.
> 
OK.

> Regards,
> --John

---

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

Ben,

> BGP protocol related specs.

Please ask the author(s) of the FSM draft to use TCP.
  
> 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...]

> 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...]

> > >     (4-octet long) unsigned integers."
> > >  To This:
> > >     large numbers based
> 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 ?

Yakov.

---

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

Ben and John,

[clipped...]

> > >    descriptions in this spec. Maybe the FSM section should 

Just to make clear, are you suggesting to take section 8 ("8. BGP Finite 
State machine.") out of the base spec draft ?

Yakov.

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 11 Sep 2002 14:43:51 -0400

At 1:27 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
>optional attributes, but no direct way of doing it.

True that there is no direct way of doing it.  There are a lot of 
other things that can't be done in BGP.  I don't think we need to 
start listing them or we'll never be done.  (Oh, too late for that!)

>Yes, but does anyone use this form of EGP?

I very much doubt it but that in no way detracts from the fact that 
that _is_ what the code means, for historic reasons related to the 
transition from an EGP-based Internet to a BGP-based one.

In essence the origin code is just another way of biasing a route's 
preference, and is used as such in operation.

>>  >     value for all peers) basis."

Because the proposed text does not correctly describe current 
implementations.  You are proposing a change to the protocol, not a 
clarification of existing practice.

--John