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

["Chris Hall" <[e-mail]>]

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

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