Re: [Idr] draft-ietf-idr-error-handling-08

Robert Raszuk wrote (on Mon 26-May-2014 at 19:55 +0100):
....
> Isn't your example subject to reset of the session regardless what
> AFI/SAFI it is ? The way I see attribute overrun + no parsable NLRI
> present is that it does not fall under current error handling draft
> exceptions.

I don't know :-(  My reading suggests that the default response is to be "treat-as-withdraw".  If no NLRI at all can be found, what the draft specifies seems to hinge on the interpretation of "successfully parsed": is parsing nothing at all trivially successful or trivially a failure ?  Some folk appear to want the session to stay up no matter what (more or less), so it might be helpful if this was less a matter of interpretation.

Assuming that "not finding any NLRI at all" is defined/deemed to require session-reset: what about the cases where the receiver can find *some* NLRI, but knows it has not found *all* NLRI ?  Suppose:

   Withdrawn Routes field -- empty
   Attributes: MP_UNREACH_NLRI -- some valid NLRI
               ORIGIN    -- some valid origin
               ....      )  other valid stuff...
               ....      )  ...but NOT MP_REACH_NLRI
               <invalid> -- attributes overrun
   NLRI field -- empty

In this case it is pretty clear that there is an MP_REACH_NLRI buried in the rubble.

For this case, and other more ambiguous ones, we need to interpret: "the entire NLRI field and/or the MP_REACH_NLRI and MP_UNREACH_NLRI attributes need to be successfully parsed".

Chris

> On Mon, May 26, 2014 at 8:43 PM, Chris Hall
> <chris.hall@highwayman.com> wrote:
> > Robert Raszuk wrote (on Mon 26-May-2014 at 17:30 +0100):
> >> Bruno Decraene wrote:
> >>
> >> > AFI/SAFI is indeed a valid criteria but on my side, if we had
> >> > multiple level of error handling (which I'm not asking for) I'd
> >> > rather leave it to local configuration for flexibility (and
> >> > because I would not expect rough consensus).
> >
> >> But that is precisely what I am after too.  Not #define that this
> >> SAFI is subject or not, but a text in the draft that the error
> >> handling should be possible to be disabled/enabled on a per
> >> AFI/SAFI per peer basis.
> >
> > Which would be possible when it's clear what the AFI/SAFI was.  In
> the
> > (previously noted) case of:
> >
> >   Withdrawn Routes field -- empty
> >   Attributes: ORIGIN    -- some valid origin
> >               ....      )  other valid stuff...
> >               ....      )  ...but NOT MP_xx_NLRI
> >               <invalid> -- attributes overrun
> >   NLRI field -- empty
> >
> > it's (ever so) slightly tricky to tell what the AFI/SAFI was :-(
> > Unless the session carries only one AFI/SAFI, of course.
> >
> > Chris
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr