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

[Robert Raszuk <[e-mail]>]

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"

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

Cheers,
R.


On Tue, Oct 21, 2025 at 5:35 PM <[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]>
> *Sent:* Monday, October 20, 2025 6:20 PM
> *To:* DECRAENE Bruno INNOV/NET <[e-mail]>
> *Cc:* Donatas Abraitis <[e-mail]>; idr <[e-mail]>;
> [e-mail]; John Scudder <jgs=
> [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]> wrote:
>
> Hi Robert,
>
>
>
> *From:* Robert Raszuk <[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]> wrote:
>
> Hi Robert,
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Friday, October 17, 2025 12:32 AM
> *To:* John Scudder <jgs=[e-mail]>
> *Cc:* Donatas Abraitis <[e-mail]>; DECRAENE Bruno
> INNOV/NET <[e-mail]>; idr <[e-mail]>;
> [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]> 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]>
> 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]> wrote:
>
> > On Oct 16, 2025, at 9:26 AM, Donatas Abraitis <
> [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]
> To unsubscribe send an email to [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.
>
>