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

[Jakob Heitz <[e-mail]>]

IMO, another goal is not to require any change to the peer.
Not even a little bit.

Changing the peer behaviour (even a little bit)
is an entirely different story.

On Sunday, December 09, 2012 3:07 PM, Chris Hall <mailto:[e-mail]> wrote:

> Jakob Heitz wrote (on Sat 08-Dec-2012 at 16:43 +0000):
>> 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.
> 
> I guess you are suggesting that it does not then matter if a broken
> UPDATE message results in some NLRI being missed, and so not
> "treated-as-withdraw", and hence the receiver continues with some
> invalid or out of date routes, for some time.
> 
> Clearly session-reset is a less than perfect remedy.  But in proposing
> an alternative treatment, perhaps "first do no harm" is as good a
> guide as any.  I think that to achieve that, one needs to be sure that
> *all* NLRI in a broken update can be identified if
> "treat-as-withdraw" is to be applied. 
> 
> If the intention is to "treat-as-withdraw" any NLRI which is visible,
> but continue the session in any case (so, accepting the risks of
> invalid or out of date routes) then I think the draft should estimate
> the risks and set out a justification for this being a less-bad
> remedy than session-reset. 
> 
> Of course, a major issue with session-reset is that the error may well
> simply be repeated, creating a ghastly cycle session-reset/restart.
> It could well be better to avoiding session-reset, and continue with
> some invalid or out of date routes -- or a while, defined somehow ?  I
> just don't know how to demonstrate that, or how to limit the downside
> of accepting that risk, etc. 
> 
> "Treat-as-withdraw" is an excellent and minimally disruptive response
> in those cases where all NLRI can be identified.  But it is not the
> only alternative to session-reset.  If there is doubt and uncertainty
> about some routes, the receiver could deem *all* routes learned from
> the peer in question to be "routes-of-last-resort", which it then uses
> if and only if it had nothing else, but would not advertise them to
> other peers.  This is just short of a "session-reset", and avoids
> falling into a cycle of session-reset/restart.
> 
> Chris



-- 
Jakob Heitz.