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

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

John:

> -----Original Message-----
> From: John G. Scudder [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 2:44 PM
> To: Abarbanel, Benjamin
> Cc: [email-masked]
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> At 1:27 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >  > 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.
> 
> 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!)
> 
I think its a fair request, if there are cases like this they should be
documented as well, as Yakov, said describe what is done.

> >  > 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?
> 
> 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.
> 
I very believe the Chair wants to document what is, not what is historical.

> In essence the origin code is just another way of biasing a route's 
> preference, and is used as such in operation.
> 
> >  > 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?
> 
> Because the proposed text does not correctly describe current 
> implementations.  You are proposing a change to the protocol, not a 
> clarification of existing practice.
Then tell me how I am wrong. 

I read "per-destination basis" and "per BGP peer basis" as two different
things. The first term, is the neighbor, the second term is our router. 
If I was wrong then they both have to say either "per destination basis" or
"per peer basis" but not both. It confuses the reader, who does not know
the protocol that way. Remember, assumptions, are sometimes bad.

Ben

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 11 Sep 2002 15:10:13 -0400

>Then tell me how I am wrong.

I'm sorry but I'm not sure how much plainer I can put it.  The text 
as written reflects reality for various implementations -- there's a 
value you can set on a per-peer basis to limit the rate at which you 
advertise changed routes to that peer.  The text you have proposed 
says "same value for all peers" in so many words.  In point of fact, 
implementations need not and typically do not force the same value to 
be used for all peers.

>the protocol that way. Remember, assumptions, are sometimes bad.

I don't quite follow what your understanding of the original text is. 
The "destination" being referred to is an NLRI.  This is consistent 
with how the word "destination" is used throughout the document.  The 
"BGP peer" referred to is, well, a BGP peer of our router.  If there 
is further clarification required on this point perhaps we should 
take it off-list.

--John

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Sep 2002 19:46:49 -0400

In message <[email-masked]>, 
> the protocol that way. Remember, assumptions, are sometimes bad.

  9.2.1.1 Frequency of Route Advertisement

   The parameter MinRouteAdvertisementInterval determines the minimum
   amount of time that must elapse between advertisement of routes to a
   particular destination from a single BGP speaker. This rate limiting
   procedure applies on a per-destination basis, although the value of
   MinRouteAdvertisementInterval is set on a per BGP peer basis.

MinRouteAdvertisementInterval is applied on a per destination basis.

MinRouteAdvertisementInterval is configured on a per peer basis.

The text is clear.  It matches practice.  

Route flap damping ala rfc2439 is a whole different mechanism but the
base BGP protocol spec does not have to include or even reference
extensions defined in separate documents.

Curtis