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

[Robert Raszuk <[e-mail]>]

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

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

Maybe it was not clear but I mainly asked in the light of the discussion
and text in the draft concerning the comparison of MP_REACH and TAW

   In the case of an UPDATE message with a correctly formed
   MP_REACH_NLRI attribute, 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.

With ADD-PATHs MP_UNREACH is quite different then MP_REACH.

Is one match of NLRI found in TAW enough irrespective of how many matches
for the NLRI MP_REACH with extended NLRI encoding would/should contain ?

Thx.
R.


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