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

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

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.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Wednesday, September 11, 2002 11:34 AM
> To: Abarbanel, Benjamin
> Cc: 'Kaarthik Sivakumar'; [email-masked]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Ben,
> 
> > 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
> > 
> > > -----Original Message-----
> > > From: Kaarthik Sivakumar [mailto:[email-masked]]
> > > Sent: Wednesday, September 11, 2002 11:12 AM
> > > To: Abarbanel, Benjamin
> > > Cc: [email-masked]'
> > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > > 
> > > 
> > > >>> "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: Yakov Rekhter <[email-masked]>
Date: Wed, 11 Sep 2002 08:48:20 -0700

Ben,

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

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Sep 2002 16:22:21 -0400

In message <[email-masked]>, 
> rules, until everyone (?) upgrades, then we can obsolete these rules.

The existing rules are very clear.

Summarized:

  If an UPDATE contains only a withdraw for a prefix, then withdraw
  whatever route the peer had previously sent.

  If an UPDATE contains the prefix only in the NRLI section, replace
  whatever route had previously been advertised by the peer or add a
  route if there was no previous route, in both cases adding a route
  with the current attributes.

  Don't put the same prefix in the same in both the withdraw and NRLI
  section of the same update.

  If you receive an UPDATE with the same prefix in both the withdraw
  and NRLI, ignore the withdraw.  [Some older implementations thought
  this was a good way to say "delete then add".]

  Process UPDATEs from the same peer in the order received.

These are the existing rules and we have found no reason to change
them in almost a decade of use.  If they are not written down clearly
there could be reason to clarify the text, but that doesn't seem to be
the case.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Sep 2002 16:32:32 -0400

In message <[email-masked]>, Yakov Rekhter writes
> is outside the scope of the current discussion.

If no one other than Ben sees reason to change this I suggest we
declare consensus on this with one disenting opinion and move on.

Curtis