Re: IDR WG Last Call

[Russ White <[e-mail]>]

Correct--SAFI 3.... There aren't any implementations that I've
seen, and it does complicate matters a bit more than needed.

Russ

On Tue, 15 Jan 2002, Enke Chen wrote:

> Sue,
> 
> > Date: Tue, 15 Jan 2002 14:49:14 -0500
> > To: Russ White <[e-mail]>
> > From: Susan Hares <[e-mail]>
> > Subject: Re: IDR WG Last Call 
> > Cc: Enke Chen <[e-mail]>, Jeffrey Haas <[e-mail]>,
> > 	[e-mail]
> > In-Reply-To: <[e-mail]
> >  .com>
> > References: <[e-mail]>
> > Mime-Version: 1.0
> > Content-Type: text/plain; charset="us-ascii"; format=flowed
> > X-NextHop-MailScanner: Found to be clean
> > 
> > Russ:
> > 
> > We had that vote 1 month ago.  The overwhelming
> > majority was to keep it in. We are not re-opening
> > that issue having closed it on the mail list already.
> 
> The issue then was the "BGP State Machine". Russ was talking abut "SAFI 3"
> in his message if I am not mistaken.
> 
> -- Enke
> 
> > 
> > 
> > Sue
> > 
> > At 01:03 PM 1/15/2002 -0500, Russ White wrote:
> > 
> > >I think it's probably a good idea to get rid of this out of the
> > >spec--it would make things cleaner.
> > >
> > >Russ
> > >
> > >On Tue, 15 Jan 2002, Enke Chen wrote:
> > >
> > > > Jeff,
> > > >
> > > > > Date: Mon, 14 Jan 2002 23:21:28 -0500
> > > > > From: Jeffrey Haas <[e-mail]>
> > > > > To: Enke Chen <[e-mail]>
> > > > > Cc: [e-mail]
> > > > > Subject: Re: IDR WG Last Call
> > > > > Message-ID: <[e-mail]>
> > > > >
> > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote:
> > > > > > It seems that the "SAFI 3" certainly makes the issue at hand much more
> > > > > > complicated.
> > > > >
> > > > > IMO, SAFI 3 was probably not a very good idea.  Dealing with it can
> > > > > be a real pain in the implementation. :-)
> > > >
> > > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add
> > > > much value, but has caused a lot of confusion and complexity. I am not
> > > > aware of any depolyment either.
> > > >
> > > > >
> > > > > > As Yakov and Sue pointed out, it is a good idea to discourage
> > > > > > having one prefix in multiple fields of an update message. How 
> > > about the
> > > > > > following text:
> > > > > >
> > > > > >    An UPDATE message should not include the same address prefix in 
> > > more than
> > > > > >    one of the following fields: WITHDRAWN ROUTES field, Network 
> > > Reachability
> > > > > >    Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI 
> > > field. The
> > > > > >    processing of an UPDATE message in this form is un-defined.
> > > > >
> > > > > I think that "undefined" is overkill.  I would suggest the following 
> > > instead:
> > > > >
> > > > > An UPDATE message should not include the same address prefix in
> > > > > more than one of the following fields: WITHDRAWN ROUTES, Network
> > > > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI.
> > > > > An implementation that receives a packet in this form should process
> > > > > the Update as if it had processed it in the following order:
> > > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer
> > > > > Reachability Information.
> > > > >
> > > > > The wording could probably use some tightening.
> > > > >
> > > > > The intended result is that reachability rules over unreachability.
> > > >
> > > > If we want to define the behavior, I would like to suggest sticking to
> > > > the order in the message. That probably would reflect the sender's
> > > > intention more closely, and make the processing simpler.
> > > >
> > > > -- Enke
> > > >
> > > >
> > >
> > >_____________________________
> > >[e-mail] <>< Grace Alone
> > 
> > 
> 

_____________________________
[e-mail] <>< Grace Alone