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

[Robert Raszuk <[e-mail]>]

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.

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 ?

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