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

[[e-mail]]

Hi Robert,

From: Robert Raszuk <[e-mail]>
Sent: Tuesday, October 21, 2025 6:14 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]>
Cc: idr <[e-mail]>; [e-mail]; John Scudder <jgs=[e-mail]>
Subject: [Idr] Re: draft-decraene-idr-nlri-error-handling-00.txt

Hi Bruno,

> I’m a bit reluctant to use your proposal to define “key” as the data placed in MP_UNREACH_NLRI, because Label NLRI do not use that.

But you are already doing that in your draft .. just between lines :)

Also I am not sure I understand this in this context: " because Label NLRI do not use that"

I meant : because Label NLRI includes non-key data/field in the NLRI field of the MP_UNREACH_NLRI attribute. E.g., the “Compatibility” field of RFC 8277.


> “The NLRI key is the part of the NLRI which is used to identify and distinguish between each individual route in the BGP RIB”

That to me seems way too broad and very much implementation dependent.

I’m open to other suggestions.
But I don’t see how this could be implementation dependent because this defines whether the NLRI-key advertised in MP_REACH_NLRI (resp.  MP_UNREACH_NLRI) updates (resp. withdraw) a previously announced route in the RIB.

Cheers,
--Bruno

Cheers,
R.


On Tue, Oct 21, 2025 at 5:35 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

Thanks for the feedback.

I agree with you : I would have loved to be able to reference the definition of NLRI-key and NLRI-non-key-data. But I haven’t found one, although clearly some existing AFI/SAFIs use that.
BGP CAR has some text specific to the BGP CAR address family
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-16#section-2.1

NLRI Key: Falls into two categories, to accommodate the use-cases described in the introduction:
-  Type-1: Key is IP Prefix and Color (E, C). Color in NLRI key distinguishes a color-aware route for a common IP prefix, one per intent. Color also indicates the intent associated with the route.
- Type-2: Key is IP Prefix (E). The unique IP prefix assigned for an intent (i.e, IP Prefix == Intent or Color) distinguishes the color-aware route. Color is not needed in NLRI key as a distinguisher.

NLRI non-key encapsulation data: Data such as MPLS label stack, Label Index and SRv6 SID list associated with NLRI. Contained in TLVs as described in Section 2.9.2<https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-16#NLRITLVs>

Somehow that was good enough at the time for the WG and the IESG, but now this fall on us to define it 😉

I’m a bit reluctant to use your proposal to define “key” as the data placed in MP_UNREACH_NLRI, because Label NLRI do not use that.
I though “key” for database was well-know, but it’s relatively fair to ask for clarity.

Using Wikipedia as an input, I’d propose something along: “The NLRI key is the part of the NLRI which is used to identify and distinguish between each individual route in the BGP RIB”. Followed by examples, typically referencing BGP CAR.
I’m pretty sure someone will be able to propose something better.

Thanks,
--Bruno

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Monday, October 20, 2025 6:20 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc: Donatas Abraitis <[e-mail]<mailto:[e-mail]>>; idr <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; John Scudder <jgs=[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] Re: draft-decraene-idr-nlri-error-handling-00.txt

Hi Bruno,

Proposed text is a good one - does help to add a few stones on the positive side of the weight of the draft.

My only concern with it is that you keep using a notion of key in correspondence to documents which do not define them explicitly. Neither RFC8277 nor CT draft define key - even if they are defining MP_UNREACH_NLRI attributes in some form or shape.

Therefore I would strongly advise that if you want to keep using the key vs non-key  nomenclature you should up fronty define what are key vs non-key parts of NLRIs. It could be as simple as saying:

NLRIs in some address families consist of key and non-key data. What this document considers as key data and what is expected to be placed into TAW attribute is what corresponding address families select from NLRI and place into MP_UNREACH_NLRI attributes today. What is not expected to be found in MP_UNREACH_NLRIs in this document we define as non-key data of the NLRI(s).

Thx,
R.

On Mon, Oct 20, 2025 at 5:31 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Friday, October 17, 2025 7:56 PM
Hi Bruno,

Ok I get your point that the issue may be on the receiver and not on the sender in parsing MP_REACH_NLRI. Indeed I was mainly talking about the issue on the sender side, badly composing the MP_REACH_NLRIs.

Ack. Thanks for the clarification.

Btw are you advocating to be sending TAW for all AFI/SAFIs ? Even those which do not contain next hop as part of MP_REACH ? If so what would be the rationale for doing such MP_REACH duplication ?

One is free to use it when one wants, on a per AFI or even a per BGP UPDATE if needed.
Current version of the draft (local version, not yet published) has the following “applicability” text

The NLRI_KEY_LIST attribute is generally useful as its encoding is simpler than the encoding of the MP_REACH_NLRI, hence it maximizes the chances of handling an error in the MP_REACH_NLRI attribute using the treat-as-withdraw approach.
In particular the NLRI_KEY_LIST attribute does not carry the variable length "Network Address of Next Hop" field nor the "Length of Next Hop Network Address" which, if erroneous, trigger a BGP session reset as per {{RFC7606}}.
It is specifically useful for AFI/SAFI carrying non-key data in the NLRI such as {{RFC8277}}, {{I-D.ietf-idr-bgp-car}}, and {{I-D.ietf-idr-bgp-ct}} as these NLRI are longer and more complex, hence have a higher probability of error. In addition, in case of error, they have a lower probability of being able to parse the full list of NLRIs.
It is less useful when the NLRI encoding is the same for MP_REACH_NLRI and MP_UNREACH_NLRI.

Comments welcomed.

As for myself, I think I would use it a priori for AFI/SAFI carrying a (significant) non-key data, especially for infrastructure routes which are critical, and with lower route scale (number of routes and number of updates/instability). E.g., BGP CAR, BGP CT, BGP LU. In particular if they are recent or known to have issues.
And a posteriori for an AFI/SAFI which triggered an impactful session reset which could have been better handled by this proposal.
My 2 cents.

Thanks,
--Bruno

Example RFC8955.

Thx,
R.



On Fri, Oct 17, 2025 at 3:38 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Robert,

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Friday, October 17, 2025 12:32 AM
To: John Scudder <jgs=[e-mail]<mailto:[e-mail]>>
Cc: Donatas Abraitis <[e-mail]<mailto:[e-mail]>>; DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>; idr <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] Re: draft-decraene-idr-nlri-error-handling-00.txt

Hi John,

So in your example you are pointing out that the sender can not correctly encode the next hop in the MP_REACH.

Well sorry to say but this to me is good enough of a reason to drop a session with such a sender ASAP.

Note that you and Bruno are taking a very myopic view on the network.

[Bruno] Thanks ( 😉 )

You think that dropping the session is a disaster and that it always impacts customers given the network is serving.

[Bruno] No. I’m saying that dropping the session does sometimes impact customers. Sometimes a very large base.
I’m assuming that you see the difference between both assertions.

Well this is IMO quite wrong conclusion.

Properly constructed network is usually not a single vendor shop and control plane information - especially BGP - is distributed over different vendor control plane nodes with multiple sessions in place. Hence you should have more than one way of getting your BGP overlay information between egress and ingress nodes to your domain.

[Bruno] How does that help?
You are considering one assumption: the BGP error I due to your BGP peer. (so a diverse one will help).
There are other assumptions. E.g. the BGP update is valid and the receiver believes there is an error. E.g. A BGP LU route is advertised with a label stack of more than one label. The one seeing the error is the ingress node. Having diverse signaling does not help.


With that bigger picture in mind please notice that dropping a single BGP session in the vast majority of modern implementations usually has zero (well cost of local pointer switch so single ms) negative effect on the data plane and on the customer transit/services offered.

[Bruno] Again, I think you are considering a subset of the cases. See above.

I think we need to take a look from this angle as well when considering adoption or not of this proposal.

[Bruno] Let’s take a look from all angles. Not just “this angle”.

We could discuss error handling considerations, but this is a large and complex topic, with different points of views. Usually tradeoffs are involved, so there is no easy answer (and whatever the choice taken, this can backfire)

Example of two points of view:
1.      Box/BGP session centric: I’m receiving a wrong message. What a pathetic implementation is running  on my neighbor! Hopefully, I’m a smart implementation and  _I_ detected the error. Since the neighbor implementation is bad, and I can’t trust that session, let’s kill it. (the session)
2.      Global network centric. I’m receiving a wrong message. As a first reaction, I could indeed shut down that session (since a not so myopic operator probably configured redundant sessions with redundant codes, and the not so myopic customer is dual homed to another PE). But thinking a bit more: what makes me think that my redundant session will not receive the same message? That the redundant PE will not receive the same message? That all PE will not receive the same message (it’s an IBGP session, so even if it’s not a link state IGP, it’s likely a goal to simulate a full mesh where everyone receives all routes (with same attribute)). With this is mind, if I take the decision to shut down that session, all other PEs may equally take the same decision. Is that really such a smart move?

On top of that, the incorrect message may come from an attacker. In such case, taking an action which increases the scope or consequences is debatable as it gives the attacker a bigger attack vector. Better try to ignore or minimize (even just creating local states, consuming/leaking memory… may be exploited).



Hopefully, I’ve shared a different angle. Even if not, I hope it’s clear that I’ve not been convinced by your arguments to support your claim that [John and I]  “are taking a very myopic view on the network”


Kind regards,
--Bruno



Kind regards,
Robert

On Thu, Oct 16, 2025 at 5:59 PM John Scudder <jgs=[e-mail]<mailto:[e-mail]>> wrote:
Hi Donatas,

If the MP_REACH_NLRI is fine, we do nothing with the TAW and process the MP_REACH_NLRI as normal.

If, during processing of the MP_REACH_NLRI, we discover an error [1], then we extract the keys from the TAW and use them to drive treat-as-withdraw behavior [2], instead of resetting the session as RFC 7606 tells us to.

In reviewing RFC 7606 just now, I see we can construct a rather straightforward example of a malformation that would be overcome by TAW. Let’s use Bruno’s diagrams, and fill in some of the fields:

Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14)
        +---------------------------------------------------------+
        | Address Family Identifier (2 octets)             0x0002 |
        +---------------------------------------------------------+
        | Subsequent Address Family Identifier (1 octet)     0x01 |
        +---------------------------------------------------------+
        | Length of Next Hop Network Address (1 octet)       0xff |
        +---------------------------------------------------------+
        | Network Address of Next Hop (variable)                  |
        +---------------------------------------------------------+
        | Reserved (1 octet)                                      |
        +---------------------------------------------------------+
        | NLRI1 (key1)                                            |
        | NLRI2 (key2)                                            |
        +---------------------------------------------------------+

Above, I have not filled in beyond the “Length of Next Hop Network Address” field, since that’s where the error occurs, and the rest is not reliably determinable (7606 Section 7.11). I removed the “non-key” notations since this example uses plain IPv6 unicast, mostly to keep the example simple.

Treat-As-Withdraw  (Type Code TBD1)

        +---------------------------------------------------------+
        | Address Family Identifier (2 octets)             0x0002 |
        +---------------------------------------------------------+
        | Subsequent Address Family Identifier (1 octet)     0x01 |
        +---------------------------------------------------------+
        | NLRI1 (2001:DB8::/32)                                   |
        | NLRI2 (3fff::/20)                                       |
        +---------------------------------------------------------+

While we are trying to parse the MP_REACH_NLRI, we hit the absurd Length of Next Hop Network Address field, and therefore, RFC 7606 tells us we MUST reset the session. However, since we also have access to the TAW, we can confidently extract the two prefixes (“keys”) it carries, and proceed to apply treat-as-withdraw logic instead of resetting the session.

I hope we don’t need to debate whether this particular example is likely to occur in the field — I concede it isn’t; as noted, I chose it because it’s simple, illustrates the point, and follows directly from unambiguous language in RFC 7606.

HTH,

—John

[1] See RFC 7606 Sections 3.j, 5, and 7.11.

[2] See RFC 7606 Section 2, third bullet.

On Oct 16, 2025, at 9:45 AM, Donatas Abraitis <[e-mail]<mailto:[e-mail]>> wrote:


[External Email. Be cautious of content]


>It’s a sort of a duplicate MP_UNREACH attribute

Okay, let's say we received this one (followed by MP_REACH_NLRI):

Treat-As-Withdraw  (Type Code TBD1)

        +---------------------------------------------------------+
        | Address Family Identifier (2 octets)                    |
        +---------------------------------------------------------+
        | Subsequent Address Family Identifier (1 octet)          |
        +---------------------------------------------------------+
        | NLRI1 (key1)                                            |
        | NLRI2 (key2)                                            |
        +---------------------------------------------------------+

What should we do with MP_REACH_NLRI then? My question is, what problem solves the "duplication"? :)


On Thu, Oct 16, 2025 at 4:35 PM John Scudder <[e-mail]<mailto:[e-mail]>> wrote:
> On Oct 16, 2025, at 9:26 AM, Donatas Abraitis <[e-mail]<mailto:[e-mail]>> wrote:
>
> Correct me if I'm wrong... So, this TAW attribute is sort of a duplicate MP_REACH attribute,

Almost, you left out the “UN". It’s a sort of a duplicate MP_UNREACH attribute:

                The format of the Treat-As-
   Withdraw attribute is the same as the format of the MP_UNREACH_NLRI
   as defined in Section 4 of [RFC4760].

> or what actually? I still don't understand how it solves the parsing problem

The problem it’s meant to solve is if the MP_REACH_NLRI can’t be parsed for some reason:

   However, as indicated in Section 3 of [RFC7606], treat-as-withdraw
   can only be used if the entire NLRI field of the MP_REACH_NLRI
   attribute is successfully parsed.  This typically means parsing
   errors in MP_REACH_NLRI cannot be handled by any means short of
   session reset.

In code bases I’m aware of, the MP_UNREACH_NLRI generation code path is simpler than the MP_REACH_NLRI code path, and of course we’ve already discussed that the MP_UNREACH_NLRI content is sometimes simpler than the MP_REACH_NRLI content. The hypothesis that underpins the draft is that simpler => less likely to contain an error. This generally seems like an uncontroversial assumption. There is of course no guarantee (the entire draft is essentially about how to handle bugs, so this is true by definition).

> (I might be completely dumb) :)

On the contrary, your comments, Robert’s, and others, illustrate that we need to work harder to be clear. (And also need to fix the bug that Robert called out!) So, thank you!

—John


--
Donatas

_______________________________________________
Idr mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.