[Idr] Re: Treat-as-withdraw attribute consistency (was Re: [Idr] draft-decraene-idr-nlri-error-handling-00.txt)

[[e-mail]]

Jeff,

Thanks for the email and taking the time to explicit your points.
I'm not so sure whether I'd rather top post or reply in line...

With regards to consistency between MP_REACH & TAW.
This is a very good point. Authors are not decided yet, but it's good to have feedback.

Originally, we are coming from this position: minimal change versus today (RFC 7606):
- parse MP_REACH_NLRI 
	- if well-formed, skip TAW (so just like today)
	- if error preventing NLRI key identification, uses TAW to Treat-as-withdraw

In this position, there is not really consistency considerations. In the worst cases, we could have inconsistencies as you mentioned:
- MP_REACH_NLRI may be well-formed but with an incorrect list of NLRI. In which case we may have an inconsistency with TAW, but we don't act upon. Just like today, if we see MP_REAHC_NLRI as well-formed, we assume that it's valid. We may be wrong, but that's the behavior today and nobody seems to care/raise the point.
- MP_REACH_NLRI may be malformed. We are using TAW to treat-as-withdraw. Possibly TAW has as "bad" list of NLRI, but TAW is nothing more than an MP_REACH_NLRI. You could have received it in the next UPDATE and you would have trust its content given that it's well-formed. 

So in summary, I guess the reasoning is minimal change vs today, and in particular if you see it well-formed, you trust its content.

 
There is a second position that we are equally considering: always check for consistency.
Pro: This is extra work/process for the receiver.
Con: we constantly check for implementation error leading to inconsistency between TAX and MP_REACH. (because if we never test the code, we'll never find the bugs)

With this second position implementation have more work and we more decision to take. Exactly the one you raised about consistency.
One option is to stick with the logic of the first position. Same consideration applies.

With that I believe I have covered your two first sections below.
Please see inline below for you other points. [Bruno]

> -----Original Message-----
> From: Jeffrey Haas <[e-mail]>
> Sent: Thursday, October 16, 2025 10:17 PM
> 
> 
> [Forking thread to discuss a particular set of points.]
> 
> 
> > On Oct 16, 2025, at 8:48 AM, [e-mail] wrote:
> >
> > [Bruno] Mostly agreed:
> > - You/IDR is very welcome to address the "do better encoding for reachability", or more generally "do better encoding". I would support the effort.
> > - Yes this proposal adds complexity, but I believe that this complexity is limited, and probably much more limited than the above.
> >
> >> I simultaneously don't claim there's a good way to accomplish that.  Our current RFC 7606 compromise came after a lot of discussion about how messy this stuff is.  Examples might include proposals similar to the GROW BMP TLV format where additional data is placed after the NLRI stream in an indexed fashion.
> >
> > [Bruno] I'm not familiar with GROW BMP TLV. This looks similar to what I had proposed once in private but was replied that the separation & index thing was complex from an implementation standpoint.
> > Anyway, this is a discussion for the "do better encoding for reachability" effort.
> [...]
> 
> >> When an encoding issue is encountered, we hope that there isn't an issue in the parallel encoding of the same NLRI in a different part of the packet.
> > [Bruno] Yes but I believe that this is more than just hope. As per you point 2, the encoding of MP_UNREACH / TAW is simpler than MP-REACH. In particular,
> > - if the encoding error was in the non key-data, we won't have error in TAW as there is no such data.
> > - if the encoding error was in the key-data, we are doomed whether the error was in MP_REACH or MP_UNREACH.
> >
> >> When an encoding issue is NOT encountered in the NLRI, but a consistency issue is detected, it's ... okay?
> > [Bruno] you mean a consistency issue between MP_REACH and TAW? This is a point that authors are still discussing as there are tradeoffs.
> 
> I've selected a subset of the points from your last reply to discuss consistency and some implementation considerations.  My primary concern here remains "is this additional complexity worth the effort".  I accept as a given that the problem to be avoided is session reset.
> 
> Presume that we have two lists of destinations in an update denoted TAW and NLRI, ignoring non-key field differences in the encodings.
> 
> At the moment, the draft doesn't provide any ordering guarantees between TAW and NLRI.  For this example, presume we use the notation { TAW } to represent an unordered set of the TAW destinations and ( TAW ) to represent an ordered list.  I'll begin with examples based on the set behavior and then move to discussing how implementation considerations may push us to list behavior.
> 
> Our desired outcome is { TAW } == { NLRI }.
> 
> Case 1: { TAW } != { NLRI }, NLRI is malformed, TAW is well-formed.
> 
> This is the base case for the draft.  In this TAW is accepted as being "more correct" and we execute treat-as-withdraw behavior on TAW.
> 
> Case 2a: { TAW } != { NLRI }, TAW and NLRI are well-formed, { TAW } is a superset of { NLRI }
> 
> In this case, we have a consistency issue, both sets of destinations are well formed, but we have more items in the { TAW } set.
> 
> Did we fail to encode some destinations in NLRI?  Should we execute treat-as-withdraw for { { TAW } - { NLRI } }?
> 
> Case 2b: { TAW } != { NLRI }, TAW and NLRI are well-formed, { TAW } is a subset of { NLRI }
> 
> In this case, we have "extra" NLRI vs. what TAW thinks should be encoded.  Is this cruft left in a buffer and misencoded?  Should we execute treat-as-withdraw for { { NLRI } - { TAW } }?
> 
> Case 2c: { TAW } != { NLRI }, TAW and NLRI are well-formed, there are elements in TAW not in NLRI and vice-versa.
> 
> In this case it's very unclear what should be done.  We have two sets that are problematic: { TAW } - { NLRI }, and { NLRI } - { TAW }.
> 
> Case 3: NLRI well-formed, TAW is malformed.
> 
> The draft says "attribute discard" for TAW.  But if we are proceeding on the premise that TAW is "harder to get wrong", why should we trust that we haven't introduced stuck prefix issues?
> 
> -----
> 
> In the cases above, the underlying premise is "TAW is safer to trust".  But if that's true, and there's inconsistency, shouldn't we trust that something is broken?
> 
> Once we've accepted that we're "okay with inconsistency", we're making the active trade from session reset to being unclear whether we've introduced stuck/incorrect prefix issues.  We made a form of this judgment call previously during our RFC 7606 debates, but decided at that time that if we couldn't trust the NLRI that we'd reset the session rather than live with stuck routes.
> 
> -----
> 
> With regard to encoding complexities, your high level reading of the BMP TLV format is correct.  The question is whether something similar is really much worse than the complexities introduced to the code for this feature?

[Bruno] Good point. I was expecting it 😉
Discussion is a bit unsafe as I haven't read the MP TLV format, and I had not written my former BGP proposal. Nonetheless we seem confident to be in sync, so let's try.

With draft-decraene-idr-nlri-error-handling, implementation are free to implement or not. If implemented, this applies to all address families with no impact/change on those address families.
My previous proposal was for the BGP CAR draft. It would have obliged all BGP CAR implementation to implement it. It would not have applied to other addresses families (past and future). Also the BGP CAR draft is already quite large.
 
> The example cases above presume a "set" behavior rather than a list.  The code work involved in such processing behavior is that the implementation:
> 
> 1. MUST parse the TAW destinations, and minimally make sure they're acceptable.
> 2. Then, parse the mp-reach destinations.
> 
> If the only behavior for looking at TAW is when the mp-reach is malformed as the current draft suggests, it's fairly straight forward.

[Bruno] Good to see that we agree. (I may record that quote 😉)
 
> However, if there's any desire to address consistency issues, ordered processing may be better.

[Bruno] Fully agreed.
 
> Given ( TAW ) and ( NLRI ), doing pair-wise comparison between both lists makes sense when they are identically ordered.  It avoids keeping intermediate parsing state in what tend to already be slightly messy code paths.  How much it makes sense to do ordered pair-wise comparison depends on what the behavior should be in the face of inconsistencies.

[Bruno] Make sense. Thanks for taking the time to explain.

--Bruno
 
> -- Jeff
> 
> 
> 
> 
> 
> 
> 
> 
>
____________________________________________________________________________________________________________
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.