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

[Robert Raszuk <[e-mail]>]

Perfect !

On Tue, Oct 21, 2025 at 5:01 AM Nat Kao <[e-mail]> wrote:

> Hi, Robert & Bruno.
>
> I believe the proposed text clarifies the key/non-key data definitions.
> To avoid possible conflict, would it be better to add some exceptions in
> 2nd sentence? For example:
> "If not defined explicitly by the address families, 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."
>
> Many Thanks!
> Nat
>
> On Tue, Oct 21, 2025 at 12:26 AM Robert Raszuk <[e-mail]> wrote:
>
>> 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.
>>>
>>> _______________________________________________
>> Idr mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>