Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt

[Enke Chen <[e-mail]>]

Hi, Chris:

As I replied before,  the receiver knows from parsing the path 
attributes whether the MP_REACH_NLRI and/or MP_UNREACH_NLRI is the first 
attribute in an UPDATE message.  It does not need a new capability to 
make that determination.

-- Enke

On 12/9/12 3:37 AM, Chris Hall wrote:
> Brian Dickson wrote (on Fri 07-Dec-2012 at 23:13 +0000):
>> I see the high-level problem Chris describes, and think maybe
>> it requires discussing possible ways of removing
>> doubt/ambiguity over successful parsing of such MP_REACH
>> and MP_UNREACH attributes.
> My suggestion, for minimal change to the protocol, would be a new
> capability which would carry the undertaking that:
>
>    * when sending MP_UNREACH_NLRI and/or MP_REACH_NLRI
>      they will be the first attribute(s), and will
>      appear in that order.
>
>    * the ORIGIN attribute will be the first attribute,
>      or will follow any NLRI attributes.
>
>      Which deals with the absence of one or both NLRI
>      attributes.
>
> A receiver in possession of this new capability knows that, once it
> has seen completely valid versions of these leading attributes, it can
> tolerate any malformation of the following attributes, or absence of
> essential attributes, etc. and "treat-as-withdraw".
>
> The ORIGIN attribute has the value 0x0X 0x01 0x01 0x0Y -- where X is
> supposed to be 0 and Y MUST be 0, 1 or 2.  This pattern is,
> effectively, and "end-of-NLRI-attributes" mark.
>
> If the new capability also meant that this attribute would always be
> output with extended length and guaranteed X = 0, then the receiver
> would expect to see 0x10 0x01 0x00 0x01 0x0Y -- which is a little more
> unique, and offer a little more assurance that the attributes so far
> are completely valid.  (But this is not essential)
>
> (The new capability could also mean that IPv4 Unicast will not appear
> both in the body of the message and in NLRI attributes -- but that is
> not essential, either.)
>
> If the sender misbehaves, and sends any NLRI attribute after the
> ORIGIN then:
>
>    a) if it is not a repeat attribute then...
>
>         ...accept, but turn off the capability ?
>
>         ...treat as a repeat ?
>
>    b) if it is a repeat attribute then...
>
>         ...session-reset, as per draft ?
>
>    c) if the extra attribute is hidden by a preceding
>       broken attribute then...
>
>         ...the change to the relevant NLRI is lost.
>
> The last case is BAD: the receiver will "treat-as-withdraw" the NLRI
> it can see, but not those it cannot.  The risk here may be deemed
> ignorable -- but needs to be assessed.
>
> For all code which deals with BGP updates -- BGP speakers or analysers
> of BGP streams etc -- the only change here is the new capability;
> UPDATE messages will have attributes in a particular order (and
> perhaps take a particular form) but are entirely RFC4271 compliant.
>
> That leaves the question of what the receiver does in the absence of
> the new capability... but that's another story, for another day.
>
> Chris
>     
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr