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

[John Scudder <[e-mail]>]

Fun!

I’m not so sure any additional specification is needed, since by definition if you know how to build an MP_UNREACH_NLRI you know how to build a TAW. Still, it’s worth a think, thanks.

—John

On Oct 17, 2025, at 1:47 PM, Robert Raszuk <[e-mail]> wrote:



[External Email. Be cautious of content]


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]<mailto:[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]<mailto:[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]<mailto:[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