[Idr] Re: draft-decraene-idr-nlri-error-handling-00.txt

[Robert Raszuk <[e-mail]>]

John,

Do you plan to add any text on how you plan to encode TAW attribute if
given AFI/SAFI is using Extended NLRI Encoding from RFC7911 (ADD-PATHs RFC)
?

Thx,
R.



On Fri, Oct 17, 2025 at 7:30 PM John Scudder <[e-mail]> wrote:

> Hi Donatas,
>
> I’m combining replies to two of your questions. I hope that’s OK.
>
> > On Oct 17, 2025, at 2:28 AM, Donatas Abraitis <
> [e-mail]> wrote:
> >
> > This must be written in the document, because now I understand what the
> point of this new attribute is, thanks. How do we ensure consistency
> between TAW and MP_REACH_NLRI keys? They can be different, right?
>
> They are never supposed to be different, that’s the point. Looking at the
> spec, I guess we need to be clearer about this up front. Section 4, second
> paragraph, does demonstrate the intent, though:
>
> ```
> the Treat-As-Withdraw attribute SHOULD be parsed and its list of NLRI
> compared to the list of NLRI present in the MP_REACH_NLRI attribute. In
> case of difference, the Treat-As-Withdraw attribute SHALL be ignored.
> However, because this reveals an error in either the Treat-As-Withdraw
> attribute or the MP_REACH_NLRI attribute
> ```
>
> As Bruno and Jeff were discussing, there are different choices available
> for how aggressively to police consistency. On one end we have “do not
> police it at all”, on the other end we have “treat it as a fatal error if
> they are inconsistent”. The present version falls somewhere in between.
>
> > On Oct 17, 2025, at 10:01 AM, Donatas Abraitis <
> [e-mail]> wrote:
> >
> > Didn't look if this was asked/answered, but correct me if I'm wrong (or
> speaking nonsense). The entire MP_REACH_NLRI attribute must be treated as
> withdrawn, but is it possible to signal that ONLY a subnet of the NLRI
> parsing failed?
>
> I’m confused by the question: there isn’t any signaling in the proposal,
> unless you count "logging an error listing the NLRI involved” as a form of
> “signaling” to the administrator of the router involved.
>
> In any case, IMO (and per the present spec and RFC 7606) once you’ve
> decided the MP_REACH_NLRI is malformed, you MUST treat everything within it
> as toxic. I guess you might be able to be even more selective, but I
> wouldn’t advocate that.
>
> Thanks,
>
> —John