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

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Chris Hall
Sent: Thursday, December 06, 2012 5:22 AM
To: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt

I've been trying to adjust the error handling in Quagga bgpd to follow this draft, without success.

If an update message arrives and there is a problem with one or more significant attributes, then if (and only if) *all* the NLRI in the update can be identified, then treat-as-withdraw is an excellent alternative to crashing the entire session.

This much is clear, and clearly a step forward.  If only it were possible to "parse" attributes individually....

[SR] In which way is the attribute "broken"? If the receiver ever thinks/knows that it has lost the sync 
         (i.e., the knowledge of TLV to byte mapping) on the tcp stream, it must reset the session.
         So if an attribute is broken because of any length issue, the session needs to be reset.

....but since it is not: when faced with a broken set of attributes, I do not see how the receiver can be certain that it has correctly and completely identified all NLRI.

RFC4271 allows for an update to contain any and all combinations of vanilla IPv4 Unicast NLRI (reachable and/or unreachable) and MP NLRI (also reachable and/or unreachable).  Given that one broken attribute may obscure following ones, the receiver can be certain that it has correctly and completely identified all NLRI if, and only if, it has extracted *both* a complete MP_REACH_NLRI *and* a complete MP_UNREACH_NLRI attribute.  Otherwise, the receiver must, in effect, prove a negative: that one or both attributes were not sent.

The draft acknowledges the issue, and requires that "the MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if present) SHALL be encoded as the very first path attribute" (should that be "and/or" rather than "or" ?).
How is the receiver to know that the sender is following this new rule ?  Can it simply assume that to be the case ?  Apparently the answers
are: it cannot and may not, in that order -- since the draft also says "... MUST still be prepared to receive these fields in any position".

If the receiver cannot know (or simply assume) that the new rule is being followed, then given a broken set of attributes:

  * if there are vanilla IPv4 NLRI:

     - can it be assumed that there are no MP NLRI
       if none can be extracted ?

  * if there are no vanilla IPv4 NLRI:

     - can it be assumed that if MP_REACH_NLRI can be
       extracted then there will be no MP_UNREACH_NLRI ?

     - if the only attribute is MP_UNREACH_NLRI then
       everything is fine.

       But if any other attribute is present, if no 
       MP_REACH_NLRI can be extracted, should the
       receiver assume that one is missing (hidden by
       a broken attribute) ?

       The answer to that appears, currently, to be yes.
       But that excludes, forever, the ability to attach
       extra information to a withdraw update.

     - if neither MP_REACH_NLRI nor MP_UNREACH_NLRI
       can be extracted, can it be assumed that this
       is an empty UPDATE ?  Or is this a session-
       crashing-error ?

Of course, if the session is only carrying vanilla IPv4 Unicast, life is easy.

But otherwise, it seems to me that in order to make use of the "treat-as-withdraw" mechanism, the receiver of a broken set of attributes has to make some significant assumptions about the behaviour of the sender.  I do not know which, if any, of those assumptions it is safe to make.

I am, of course, assuming that having received a broken UPDATE, it is
*essential* to avoid continuing with the session unless *all* NLRI referred to in that UPDATE have been "treated-as-withdraw".

Chris

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr