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

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

Part II:

Editorial Comments:
===================

1. P. 41. Typing error, "Each time time the local system...".

2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in the
glossary, so when they are used in section 9.1, it is well understood what
they are.

3. P. 45, Phase I, There is no definition of what are unfeasible routes? Are
they the same as withdrawn routes? If so, the two should be combined to one
name.

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

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

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

7. P. 61, item 6.4. Although all the BGP protocol interfacing timers are  
   mentioned, there are a few FSM internal timers mentioned in the spec that

   need to be covered  here as well.

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.

Overall Comment:
================
Spec is well written for its technical content, buts needs a little more
structure for the various types of sections it has. Implying moving 
and recombining sections into key sections, (e.g. Update message processing
and its fields should be combined).

Thats all Folks!

---

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

Alex:
  YOu are correct, I must have missed the appendix when I read the core
sections. Perhaps a pointer to the appendix that talks about this will
be helpfull.

BTW there are two section 6.2 in the spec, one called 
"6.2 OPEN message error handling", and the other called
"6.2 Processing Messages on a Stream Protocol".

Using same type of sections number in Appendix A is not 
good. Especially if you search for strings.

I will renumber the Appendix 1 and use letters like
Appendix A, sections to A1, A6.2, etc.

Ben

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 11:40 AM
> To: Yakov Rekhter
> Cc: Abarbanel, Benjamin; [email-masked]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> Yakov, Ben-
> 
>  I thought section 6.2 "Processing Messages on a Stream Protocol"
>  actually talked about these things...
> 
> -- 
> Alex
> 
> Wednesday, September 11, 2002, 5:36:47 PM, Yakov Rekhter wrote:
> > Ben,
> 
> >> Yakov:
> >>   That may be true, but I have seen in a couple of BGP 
> implementations
> >> handling the socket level that the BGP code had to 
> reassemble the logical
> >> packet. TCP did not do it. 
> >> 
> >> What I mean the application code had to read from the 
> socket several times
> >> to get the entire packet and reassemble it, before passing 
> it to the BGP
> >> state machine.
> 
> > This is purely an *implementation* issue, and as such is not
> > subject to standardization.
> 
> > Yakov.
> 
> >> 
> >> Ben
> >> 
> >> > -----Original Message-----
> >> > From: Yakov Rekhter [mailto:[email-masked]]
> >> > Sent: Wednesday, September 11, 2002 11:26 AM
> >> > To: Abarbanel, Benjamin
> >> > Cc: [email-masked]'
> >> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> >> > 
> >> > 
> >> > Ben,
> >> > 
> >> > > Part I.
> >> > > 
> >> > > Technical Comments:
> >> > > ===================
> >> > > 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.  
> >> > 
> >> > *BGP* implementations are *not* required to perform any 
> >> > message reassembly.
> >> > (remember this is BGP spec, not TCP and/or IP spec).
> >> > 
> >> > Yakov.
> >> > 
> 
>

---

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

Just wanted to say what would improve it. I realize its difficult 
to change very basic and implemented features.

Ben

> Sent: Wednesday, September 11, 2002 11:48 AM
> To: Abarbanel, Benjamin
> Cc: [email-masked]'
> > I realize if we do what I suggest, there will have to be a 
> transition
> > period where the two types are in the same message as well 
> as separate
> > messages. If they are in the same message, we need to keep 
> the existing
> > rules, until everyone (?) upgrades, then we can obsolete 
> these rules.
> 
> Please bear in mind that the spec is about what is 
> *currently* deployed.
> As such any change to the base spec that required upgrades/transition
> is outside the scope of the current discussion.
> 
> Yakov.
> 
> > 
> > Ben
> > 
> > > Sent: Wednesday, September 11, 2002 11:34 AM
> > > To: Abarbanel, Benjamin
> > > Cc: 'Kaarthik Sivakumar'; [email-masked]'
> > > > No it means if they are placed in different messages and 
> > > sent in the order 
> > > > that the source router wants the destination router to 
> > > execute them. 
> > > > 
> > > > It just makes the messages simpler, requiring less rules of 
> > > processing.
> > > 
> > > it also makes the case where they are in the same message 
> unspecified.
> > >   
> > > > Ben
> > > > 
> > > > > From: Kaarthik Sivakumar [mailto:[email-masked]]
> > > > > Sent: Wednesday, September 11, 2002 11:12 AM
> > > > > To: Abarbanel, Benjamin
> > > > > Cc: [email-masked]'
> > > > > >>> "BA" == Benjamin Abarbanel <Abarbanel> writes:
> > > > > 
> > > > > [...]
> > > > > 
> > > > > BA> 4. P.16, last paragraph in section 4.3 as stated,
> > > > > BA>  "An UPDATE message should not include the same address 
> > > > > prefix in the
> > > > > BA>   WITHDRAWN ROUTES and Network Layer Reachability 
> > > > > Information fields,
> > > > > BA>   however a BGP speaker MUST be able to process UPDATE 
> > > > messages in this
> > > > > BA>   form. A BGP speaker should treat an UPDATE message of 
> > > > > this form as if
> > > > > BA>   the WITHDRAWN ROUTES doesn't contain the 
> address prefix."
> > > > >               
> > > > > BA> This complexity could have been avoided if withdrawn 
> > > > > routes and NRLI
> > > > > BA> prefixes with their attributes were mutually exclusive of 
> > > > > each other and
> > > > > BA> appeared in different update messages. If that was the 
> > > > > case, the priority of
> > > > > BA> which field to process first would have been as simple as 
> > > > > using "first come,
> > > > > BA> first served" message processing approach.
> > > > > 
> > > > > What you suggest isnt the same as what is there now. The 
> > > draft says
> > > > > that NLRI has higher preference to a WITHDRAWN prefix and 
> > > this makes
> > > > > the behavior predictable. In what you suggest the 
> behavior isnt
> > > > > predictable. Or is it? Hmm .. Maybe I am mistaken here, 
> > > but it doesnt
> > > > > seem like the same thing.
> > > > > 
> > > > > Kaarthik
> > > > > 
> > > 
>

---

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

Actually that was Appendix 4 not 1, I think a TOC will bring out these
numbering problems right away.

Ben

> From: Abarbanel, Benjamin 
> Sent: Wednesday, September 11, 2002 11:50 AM
> To: 'Alex Zinin'; Yakov Rekhter
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> Alex:

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 11 Sep 2002 12:00:44 -0400

NO its Appendix 6, LOL......Sheesh.

> Sent: Wednesday, September 11, 2002 11:59 AM
> To: Abarbanel, Benjamin; 'Alex Zinin'; 'Yakov Rekhter'
> Cc: [email-masked]'

---

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

> From: Mathew Richardson [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 1:12 PM
> To: Abarbanel, Benjamin
> Cc: [email-masked]'
> > Abarbanel, Benjamin <[email-masked]> [Wed, 
> Sep 11, 2002 at 10:52:33AM -0400]:
> >Part II.
> >
> >Technical Comments:
> >===================
> >
> >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?
> 
> See the sentence immediately prior to the one you don't 
> like... it reads:
> 
>    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
> 
> <snip>
> 
> >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 4 octets...
> 
> >5. P.46, last sentence, "However, corresponding unresolvable 
> routes SHOULD
> >be kept in the Adj-RIBs-In."  It would helpful if the author 
> states why
> >unresolvable routes should be kept in Adj-RIBs-In?
> 
> In case they become resolvable...

Then the point that the peer will not refresh the route if we drop 
them (unless we use Route Refresh) because they are unreachable should be
made.

> mrr

All other points have already been answered.

Ben

---

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

Natale:

> 
> (your page nums are wrong)
> 
> 1. agree, but cap. Is not a msg type
 
This is taken from draft-ietf-idr-dynamic-cap-02.txt:

"5. Capability Message

   The CAPABILITY Message is a new BGP message type with type code 6.
   In addition to the fixed-size BGP header [BGP-4], the CAPABILITY
   message contains one or more of the following tuples:"

> 2. agree
> 3. disagree, but maybe:
> IGP = network was explicitly introduced into bgp (network cmd)
> INCOMPLETE = network was implicitly introduced into bgp (redistribute)
> EGP = other
> Also, maybe a discussion/reference on how this is used in 
> decision process.
> (I have seen folks infer that EGP == EBGP, so this has been a 
> source of
> confusion.  May add a note that this is historic???  What do 
> operators use
> Origin = EGP for??? (comments?))

To make a long story short, there is no other EGP in use other BGP
so why bother mentioning it. I dont hear anyone calling for another
EGP protocol as a standard Inter-AS protocol.

As far as I know the original EGP protocol was flawed and BGP corrected
a number of problems. So why bother with it?

> 4. disagree (covered elsewhere)
>
How can you disagree with this? This is what MED is. All other attributes
have the type described in the same place where I want MED to do.

Ben  
> From: Abarbanel, Benjamin [mailto:[email-masked]] 
> Sent: Wednesday, September 11, 2002 10:59 AM
> To: [email-masked]'
> Subject: Review of draft-ietf-idr-bgp4-17.txt
> 
> Part I:
> 
> Editorial Comments:
> ===================
> 1. P. 7 Type: Need to add the new message types such as, Capability
> Negotiations (RFC2842), Route Refresh, etc.
> 
> 2. P. 9, right after "This document defines the following optional
> parameters:"
> Need to mention possible options, such as: Capabilitites (RFC2842),
> Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).
> 
> 3. P. 13, EGP, are there other EGP protocols other than BGP 
> that are in use?
> If not, change EGP to BGP.
> 
> 4. P.23, change the following: 
> 
> "The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
>  links to discriminate among multiple exit or entry points to the same
>  neighboring AS ..."
> 
>  To the following:
> 
> "The MULTI_EXIT_DISC is an optional non-transitive attribute 
> which may be
> used on external (inter-AS) links to discriminate among 
> multiple exit or
> entry points to the same neighboring AS ..."
> 
> 5. In section 8, there are a number of Timers, Counters, etc. 
> that need to
> be explicitly defined before they are used by the FSM. Perhaps these
> definitions should go in the Glossary section.
>

---

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

Yakov,

> Sent: Wednesday, September 11, 2002 2:20 PM
> To: Abarbanel, Benjamin
> Cc: [email-masked]
> > > Sent: Wednesday, September 11, 2002 2:05 PM
> > > To: Abarbanel, Benjamin
> > > Cc: [email-masked]
> > > > > 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-octet long) unsigned integers."
> > > > > >  To This:
> > > > > >     large numbers based
> > > > > 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. 
> 
> Or perhaps they should be kept as future comments (to be 
> posted to the list
> once we'll finish with the base spec).
> 
Thats fine.

Ben

---

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 11 Sep 2002 14:38:00 -0400

Huh?  Seems like a violation of basic TCP concepts!  Do you mean the entire
MESSAGE?  That would make sense and I think the draft already mentions that
you should not do anything until the whole msg is read.  It should be
understood (from TCP concepts) that the msg can get chopped up and/or
concatenated.  Maybe I missed the point.

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Wednesday, September 11, 2002 11:30 AM
To: 'Yakov Rekhter'; Abarbanel, Benjamin
Cc: [email-masked]'
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 

Yakov:
  That may be true, but I have seen in a couple of BGP implementations
handling the socket level that the BGP code had to reassemble the logical
packet. TCP did not do it. 

What I mean the application code had to read from the socket several times
to get the entire packet and reassemble it, before passing it to the BGP
state 
machine.

Ben

---

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

Jeff:
 My comments for the future changes are not based on EGO but Common 
Sense. Sometimes, experience == Common_Sense.

I am not saying that all the great BGP Wizards of the decade could not
think of it, just that no one raised them as issues.

End of Editorial
Ben

> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 2:35 PM
> To: Abarbanel, Benjamin
> Cc: [email-masked]
> On Wed, Sep 11, 2002 at 02:14:17PM -0400, Abarbanel, Benjamin wrote:
> "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: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 11 Sep 2002 14:56:27 -0400

Thank You

Ben

> From: John G. Scudder [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 2:51 PM
> To: Abarbanel, Benjamin
> Cc: [email-masked]
> At 2:43 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >The point is the application has to reassemble the packet, not TCP.
> 
> I think the crux of the confusion is in the use of the word "packet". 
> BGP doesn't know from packets, which have a specific network-layer 
> meaning.  It uses messages, or what some folks like to call protocol 
> data units (PDUs).
> 
> So actually, there is something to be fixed here.  In section 4.3, 
> second line of first paragraph, s/UPDATE packet/UPDATE message/. 
> That's the only misuse of "packet" I found in a quick grep of the 
> document.
> 
> --John
>

---

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 11 Sep 2002 15:06:05 -0400

Agreed, it should be fixed.  I still don't think we need to discuss
re-assembly, but if it is there, fine. (maybe I missed the whole point)

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Wednesday, September 11, 2002 2:56 PM
To: 'John G. Scudder'; Abarbanel, Benjamin
Cc: [email-masked]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt

Thank You

Ben

---

From: Susan Hares <[email-masked]>
Date: Wed, 11 Sep 2002 20:26:54 -0400

Ben:

My earlier understanding is that we would add the Route Refresh
and Capabilities in a 2nd round.  This matches my understanding of the
charter.

Sue

At 10:58 AM 9/11/2002 -0400, Abarbanel, Benjamin wrote:
>3. P. 13, EGP, are there other EGP protocols other than BGP that are in use?
>"The MULTI_EXIT_DISC is an optional non-transitive attribute which may be
>used on external (inter-AS) links to discriminate among multiple exit or
>5. In section 8, there are a number of Timers, Counters, etc. that need to

---

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 11 Sep 2002 16:27:11 -0400

Abe,

In reference to:
 "This rate limiting procedure applies on a per-destination basis, although
the value of MinRouteAdvertisementInterval is set on a per BGP peer basis.

Is ok the way it is.  True, "per-destination basis" and "per BGP peer basis"
are two different things.  The above is saying that the VALUE is set per
peer.  But separate timers are applied to each route.  When a timer
(associated with a route) hits the value (associated with a peer) then that
route may be sent to that peer.

My understanding of IOS is that there is, in fact, one timer for the whole
box for all routes and all peers (I think the peers might be out of synch,
at least it seems to me they should be).  I don't see a CLI cmd for this
timer (and in fact requiring this timer to be configurable was removed in
the Draft).  But this is an implementation detail anyway.  

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]] 
Sent: Wednesday, September 11, 2002 3:10 PM
To: Abarbanel, Benjamin
Cc: [email-masked]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt

At 2:55 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
>  > >  > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>>  >>  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'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.

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

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: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 11 Sep 2002 16:35:19 -0400

OK,

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 11 Sep 2002 16:36:34 -0400

You guys are pretty funny, some extensions are OK to cover in this spec and
others are not. Comon, give me break.

Ben

> From: Natale, Jonathan [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 3:44 PM
> To: 'Abarbanel, Benjamin'; Natale, Jonathan; [email-masked]'
> 1. Aahhh...DYNAMIC capabability.  So this makes me say that 
> this is beyond
> the scope of the base doc.
> 
> 3. EGP is a messy historical thing, not sure what we can do (ask ISP
> folks???)
> 
> 4. No, the "optional non-transitive" type descriptions are in another
> section.
> 
> Sent: Wednesday, September 11, 2002 2:01 PM
> To: 'Natale, Jonathan'; Abarbanel, Benjamin; [email-masked]'

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 11 Sep 2002 16:38:39 -0400

Curtis:
 Its already in the spec look at Appendix 6.2 from day one.

Thank You,
Ben

> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 4:08 PM
> To: Abarbanel, Benjamin
> Cc: 'Yakov Rekhter'; [email-masked]'
> In message 
> <[email-masked]>, 
> "Abarbanel, Benjamin" writes:
> > Yakov:
> This is C network coding 101.  It doesn't need to be in the spec.  If
> you know how to write C code for sockets for any purpose, it can be
> applied to BGP.
> 
> We also shouldn't have to specify that writes should be non-blocking.
> 
> We also don't need to specify that you should watch for EWOULDBLOCK on
> writes and that some OS retrun EAGAIN instead.
> 
> We also don't need to specify that EWOULDBLOCK is broken on some
> versions of some OS (not an *ix) and doesn't write anything if the
> whole write doesn't fit in the available socket buffer.
> 
> We don't need to explain that after a partial read rather than hang on
> the socket waiting for more input you should use the select system
> call, or the poll system call for sys5ish OS, or whatever m$soft uses.
> 
> ... etc.
> 
> Curtis
>

---

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

Jonathan:
Jonathan:

Thank You, I thought my memory served me right. Its amazing how people
keep telling me I am wrong and at the end, I usually am right. 
Wow, you made my day.

I have to confess, I have been BGP bread on Cisco way of doing things.

Ben

> Sent: Wednesday, September 11, 2002 4:27 PM

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 11 Sep 2002 16:49:38 -0400

> the Draft).  But this is an implementation detail anyway.  

Then maybe, the configurable assumption of whether its per route, 
peer, or box should be removed from the spec.

Ben

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 11 Sep 2002 16:50:33 -0400

Thats fine.

Thank you
Ben

> From: Susan Hares [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 8:27 PM
> To: Abarbanel, Benjamin
> Cc: [email-masked]'

---

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 11 Sep 2002 17:28:58 -0400

I agree, the entire section should be removed.

-----Original Message-----
From: Justin Fletcher [mailto:[email-masked]] 
Sent: Wednesday, September 11, 2002 5:01 PM
To: [email-masked]
Cc: Alex Zinin; Yakov Rekhter; Abarbanel, Benjamin
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt

On Wed, 2002-09-11 at 13:30, Curtis Villamizar wrote:
> 
> In message <[email-masked]>, Alex Zinin writes:
> > Yakov, Ben-
> > 
> A you suggesting we turn the terse reminder in the appendix into a
> full TCP programming tutorial?
> 
> Maybe we should just change that section to.
> 
>   6.2  Processing Messages on a Stream Protocol
> 
>      BGP uses TCP as a transport mechanism.  If you are unsure as to
>      how to handle asynchronous reads and writes on TCP sockets please
>      refer to Unix Network Programming [RWStevens] or other
>      introductory text for programming techniques for the operating
>      system and TCP implementation that you are using.
> 
> That would save having to rewrite major parts of Stevens work into the
> BGP spec.
> 
> Curtis

Perhaps the entire section should be deleted as beyond scope.

Justin Fletcher

---

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

Maybe Appendix 6 Needs to turn into another draft. It does have usefull
information for newbies.

I will go along with this plan, if people wont mind.

Ben

> Sent: Wednesday, September 11, 2002 5:29 PM
> To: 'Justin Fletcher'; [email-masked]

---

From: "Natale, Jonathan" <[email-masked]>
Date: Thu, 12 Sep 2002 12:44:07 -0400

I agree, the text is clear and it matches practice (close enough).

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Wednesday, September 11, 2002 7:47 PM
To: Abarbanel, Benjamin
Cc: 'John G. Scudder'; [email-masked]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 

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

---

From: "Natale, Jonathan" <[email-masked]>
Date: Thu, 12 Sep 2002 14:17:12 -0400

Change:
            "ORIGIN is a well-known mandatory attribute that defines the
            origin of the path information.  The data octet can assume
            the following values:

                  Value      Meaning

                  0         IGP - Network Layer Reachability Information
                               is interior to the originating AS

                  1         EGP - Network Layer Reachability Information
                               learned via the EGP protocol

                  2         INCOMPLETE - Network Layer Reachability
                               Information learned by some other means"
to:
            "ORIGIN is a well-known mandatory attribute that defines the
            origin of the path information.  The data octet can assume
            the following values:

                  Value      Meaning

                  0         IGP - NLRI was explicitly introduced into bgp

                  1         EGP - this value was administratively
                               configured to affect policy decisions or
                               NLRI was learned via the EGP protocol [1]

                  2         INCOMPLETE - NLRI was implicitly introduced
                                      into bgp"

since:
1) The network command sets the origin to IGP and I remember seeing
somewhere that only static routes should be set to IGP.
2) The primary use of EGP value is policy
3) EGP seems to still exist, anyway even if it does not it is
not worth re-writing the world.

Also, change:
"5.1.1 ORIGIN

   ORIGIN is a well-known mandatory attribute.  The ORIGIN attribute
   shall be generated by the autonomous system that originates the
   associated routing information. It shall be included in the UPDATE
   messages of all BGP speakers that choose to propagate this
   information to other BGP speakers."

to:
"5.1.1 ORIGIN

   The value of the ORIGIN attribute shall be set by the speaker
   that originates the associated NLRI.  Its value shall not be
   changed by any other speaker unless the other speaker is
   administratively configured to do so to affect policy
   decisions."

since:
1) It is already defined as well-known mandatory attribute.
2) It may be set differently within the same AS (not saying this is good).
3) It is commonly used for policy, but by default does not get changed.
4) Speakers have no choice, it is mandatory.

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Thursday, September 12, 2002 1:16 PM
To: Natale, Jonathan
Cc: [email-masked]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 

Jonathan,

> I think a reference to the fact that it is mainly used for route selection
> would suffice.

please propose the text.

Yakov.

> Sent: Thursday, September 12, 2002 10:48 AM
> To: [email-masked]
> Cc: [email-masked]
> On Wed, Sep 11, 2002 at 06:17:27PM -0400, Curtis Villamizar wrote:
> > We might want to say the value EGP in the ORIGIN field (which does
> > mean the EGP protocol, not any EGP type protocol) is depricated since
> > the EGP protocol has been moved to historic but retain the value to
> > document what it used to mean.
> 
> I would ask us to consider carefully before deprecating it.
> While no longer used (from what I've seen or heard) as the origin
> of the route being from the EGP protocol, people *are* using it in
> their route-maps to bias route selection.
> 
> -- 
> Jeff Haas 
> NextHop Technologies

---

From: "Natale, Jonathan" <[email-masked]>
Date: Thu, 12 Sep 2002 15:14:31 -0400

References

   [1] Mills, D., "Exterior Gateway Protocol Formal Specification",
   RFC904, April 1984.

--this was a previous suggestion by another guy, so I threw it in.

-----Original Message-----
From: David Barak [mailto:[email-masked]] 
Sent: Thursday, September 12, 2002 2:26 PM
To: Natale, Jonathan
Cc: 'Yakov Rekhter'; [email-masked]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 

I support this change.  However, to what does footnote [1] refer?

David Barak
WorldCom
Voice: +1-703-886-5500
Fax: +1-703-886-0541

"Quis custodes ipsos custodiet?" - Juvenal