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

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

Shyam Sethuram wrote (on Fri 07-Dec-2012 at 21:56 +0000):
...
> One attribute follows another. There's really no way to tell
> what pairs of octets are really acceptable as Flags and Type.
 
Currently, for both known and unknown Types there are some (small)
restrictions on the Flags, and repeat Types are invalid.  However
strong these cross-checks are, the draft relaxes them.

For known Types there are known restrictions on the length.  The draft
relaxes all those cross-checks too.

...
> You can reset the session at this point if you haven't come
> across MP_REACH so far and know that IPv4 NLRI length is 0.
 
Indeed.  If you have a messed up set of attributes and no NLRI in your
hands, then it's fair to assume that some NLRI have been lost, so
session-reset is the only way forward.

This is one of the few unambiguous cases.

...
> IMO, MP_UNREACH_NLRI does not enter the picture here. The
> test for NLRI presence for the scenario you described is
> limited to plain IPv4 NLRI and/or MP_REACH_NLRI.
 
I suggest that failing to withdraw some routes is worse than failing
to install or update the attributes of some routes.

Suppose an MP_UNREACH_NLRI was sent, but is obscured by some broken
attribute.  If the code takes the view that MP_UNREACH_NLRI do not
matter, then routes which the sender knows should not be used, may
continue to be installed and advertised by the receiver -- and may
stay that way "forever".

Conversely, with an MP_REACH_NLRI the receiver may (a) not install a
new route (which is effectively "treat-as-withdraw"), or (b) not
update an existing route (which is bad, but may not actually matter).

Chris