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

The goal of "treat as withdraw" is not to reinterpret a broken update message and continue the session, like nothing happened.

IMO, the goal is to limit the disruption caused by a session reset, while alerting a human to fix the problem that no machine can.

--
Jakob Heitz.

On Dec 8, 2012, at 3:21 AM, "Chris Hall" <chris.hall@highwayman.com> wrote:

> 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
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr