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

[Brian Dickson <[e-mail]>]

On Sun, Dec 9, 2012 at 1:26 PM, Enke Chen <[e-mail]> wrote:

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

Hi, Enke,

Yes, BUT...

The specific attributes will be first, ONLY if the sender puts them in that
order. (This is restating the obvious for effect, sorry.)

What Chris is proposing is a negotiated option where the sender COMMITS to
observing the specified order in which to send the attributes.

Without that negotiated option, there is no method of influencing the
sender's behavior.

This is not to say that SOME senders won't use that order.

However, any implementation that supports this new option negotiation, and
either defaults to or exposes a "knob" for enabling it, will then need to
use the SPECIFIC order to be compliant.

Having this in an RFC, gives customers a specific thing to point the
implementors/vendors at, for requesting support for this.

The amount of logic needed to use this specific order, versus any other
deterministic, semi-deterministic, or random order, is pretty small.

The order is a good order, IMHO. And I think the cost of doing so as a
negotiated capability is well worth it, in order to better facilitate the
desired error handling, especially
inter-vendor/inter-implementation/inter-code-train. (And standardized is
much better than potential vendor-specific ways of signaling behavior or
defaults, of course.)

 Brian


> 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<https://www.ietf.org/mailman/listinfo/idr>
>>
>
> ______________________________**_________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/idr<https://www.ietf.org/mailman/listinfo/idr>
>