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

[Enke Chen <[e-mail]>]

Hi, Chris:

On 12/6/12 5:21 AM, Chris Hall wrote:
> 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".

When parsing the path attributes, the receiver knows definitely whether 
the MP_REACH_NLRI or MP_UNREACH_NLRI attribute is the very first path 
attribute.

If it is the first path attribute, life would be better w.r.t the error 
handling. If it is not (as is the case with the old code), it can be 
tricky and disruptive.  The situation will progressively improve with 
the continuous rollout of new code.

Another practical detail that helps error handling in some cases is that 
vendors are not encoding multiple NLRI fields in one UPDATE message (as 
least I am not aware of any that does).

-- Enke

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