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

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

Jakob Heitz wrote (on Sun 09-Dec-2012 at 23:37 +0000)
> IMO, another goal is not to require any change to the peer.
> Not even a little bit.

Sure.  It would be good to be able to improve error handling
unilaterally.  As discussed elsewhere, I think it is possible to do
that, subject to some limitations.

Without those limitations, the receiver is at risk of applying
"treat-as-withdraw", but failing to identify all NLRI in the message,
and hence continuing with some invalid and/or out of date routes.  IMO
that is best avoided.  There may be a good argument for rejecting the
limitations and accepting the risk of some invalid and/or out of date
routes -- I look forward to considering it.  

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

Hmmm.  Section 3 of the draft states:

  "To facilitate the determination of the NLRI field
   in an UPDATE with a malformed attribute, the
   MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if
   present) SHALL be encoded as the very first..."

which looks like a change in peer behaviour to me... but my eyesight
is not what it was ?

Chris

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