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

[Jakob Heitz <[e-mail]>]

On Monday, December 10, 2012 9:52 AM, Chris Hall <mailto:[e-mail]> wrote:

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

It is not certain.
Once you have a malformed update, NOTHING is certain.
We limit the damage and call for human intervention.

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

No.

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

It assumes the best it can to limit the damage.

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

Reset the session.

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

It doesn't stop.
If the malformation is when reading NLRI in any of
the places, it resets the session.

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

No.
If an NLRI type attribute is completely parsed
and the malformation is not in a subsequent one
and the other conditions in the draft, then we treat as withdraw.

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

yes.
Again:
Once you have a malformed update, NOTHING is certain.
We limit the damage and call for human intervention.

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

The human bean will not rely on ANY routes or information
from the broken session.

> 
> Chris



-- 
Jakob Heitz.