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

[Robert Raszuk <[e-mail]>]

Hi Enke,

I think the draft is pretty clear reg the MP_REACH_NLRI. However as
indicated in this thread what is not clear are the following cases:

- MP_UNREACH_NLRI is not mandatory so you never know if it was not
sent after some malformed attribute -> possible solution would be to
send empty UNREACH each time after MP_REACH. Otherwise if you are not
sure sender did not include MP_UNREACH you really can not
treat-as-withdraw so session will get reset.

- Sending vanilla IPv4 reach/unreach unicast NLRI is still allowed and
receiver has no way of knowing if sender did include those or not in
addition to new SAFIs in MP_REACH - here again lack of such assurance
will cause session reset even if first MP_REACH was parsed  ->
possible solution would be to depreciate vanilla IPv4 reach/unreach
unicast NLRI if MP capabilities were negotiated.

Thx,
R.


On Sun, Dec 9, 2012 at 7: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.
>
> -- 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
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr