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

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

Jakob Heitz wrote (on Mon 10-Dec-2012 at 16:31 +0000);
> If, at the time a bgp speaker detects a malformation in a received
> UPDATE, it has completely parsed at least one of:
> . Withdrawn routes section
> . NLRI

Sure.  The draft states that the 'Message Length', 'Withdrawn Routes
Length' and 'Total Attributes Length' must be consistent -- ie
correctly "framed".  And anything in the (vanilla IPv4 Unicast)
Withdrawn Routes and the NLRI sections must be internally consistent
prefixes.  So, if there is anything there, it can be parsed entirely
separately from the attributes.

> . MP_REACH
> . MP_UNREACH

For the receiver to have parsed one or both of these, the sender must
have sent them before the first malformed attribute.

If the sender is unchanged (which I recall you were keen on) how is it
certain that either or both these attributes will precede the first
broken one ?

> then it assumes that there are no more of these following.

So, the presence, say, of an MP_REACH_NLRI attribute is deemed to
guarantee that no MP_UNREACH_NLRI will follow ?

I can quite believe that, in practice, few BGP implementations (if
any) send more than one of the above forms of NLRI in a single UPDATE
message.

But that is not a requirement of the RFC or the draft -- so the
receiver is not (strictly speaking) entitled to assume it.

What is the receiver supposed to do if it has not found any NLRI at
the point that it hits a malformed attribute ?

> A capability to say so adds nothing.
> The router will behave exactly the same way.

So, the receiver scans the attributes, and on the first malformed one
it stops.  Yes ?  Or, perhaps it ploughs on to the end stepping past
malformed attributes, and truncating the final attribute if it
overruns the 'Total Attributes Length'.  Yes ?

If there are any NLRI visible (and valid), then they can all be
"treated-as-withdraw".  Yes ?

Any NLRI that might be in the UPDATE, but are not visible because of
the malformed attributes, are simply ignored.  Yes ?

OK... if that is the procedure, the capability is redundant.  [I take
issue with the procedure, but won't rehearse that, again, here.]

However, the draft comes out strongly against simply ignoring the NLRI
in a broken update.  The draft also requires session-reset if the NLRI
found in the UPDATE are not 100% valid.  The procedure I understand
you to be describing (and correct me if I have misunderstood) does not
appear to be consistent with that.

> Either way, human intervention is required to restore correct
> routing.

Sure.  I think the issue is how to avoid/minimise incorrect routeing
in the meantime.  Also, I kinda suspect that the human bean will be
greatly assisted if it is clear which NLRI have been affected (and
which definitely have not).

Chris