Re: IDR WG Last Call

[Susan Hares <[e-mail]>]

Enke:

We are back to my original point.

I would suggest a SAFI 2 + SAFI 1 being bit patterns
in the specification.

We could then deal with the (AFI, SAFI) pair.

I would suggest (per the example) that the order of
process is UNREACH and then REACH.  Please see
my example for the example of this problem.



Sue


At 09:47 AM 1/15/2002 -0800, 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