Subject: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

From: John Scudder <[email-masked]>
Date: Wed, 23 Sep 2020 21:14:47 +0000

Hi All,

I’m a little concerned about a change I failed to notice earlier in 5575bis. Version 17 had this paragraph in Section 4.2:

   All combinations of component types within a single NLRI are allowed,
   even if the combination makes no sense from a semantical perspective.
   If a given component type within a prefix in unknown, the prefix in
   question cannot be used for traffic filtering purposes by the
   receiver.  Since a Flow Specification has the semantics of a logical
   AND of all components, if a component is FALSE, by definition it
   cannot be applied.  However, for the purposes of BGP route
   propagation, this prefix should still be transmitted since BGP route
   distribution is independent on NLRI semantics.

Version 18 removed the paragraph. I believe it was removed because of good and reasonable concerns about the “prefix should still be transmitted” part. But, it appears we threw out the baby with the bathwater: the final version of the draft has nothing that corresponds to the underlined part. It is underspecified with respect to what should be done with unknown component types. The closest it comes is this paragraph in Section 4.2 of version 26:

   A NLRI value not encoded as specified specified here is considered
   malformed and error handling according to Section 10<https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-10> is performed.

But I think this falls well short of being either clear or unambiguous, because what does “as specified here” mean exactly?

I’d like to open a discussion of whether the WG agrees that this is a bug and if so, whether it’s concerning enough to request a last-minute patch to the document, which is currently with the RFC Editor, so it’s almost an RFC. I think the least intrusive fix would be to insert the clause “including an NLRI that contains an unknown component type”, as in:

   A NLRI value not encoded as specified here,

   including an NLRI that contains an unknown component type,

   is considered
   malformed and error handling according to Section 10<https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-10> is performed.

Just as a side note, “error handling according to Section 10” points us to RFCs 7606 and 4760, which end up telling us to reset the session if the NLRI is malformed.

Until we get a chance to discuss this, I’ve sent a note to the RFC Editor asking them to hold publication.

Thanks,

—John

P.S.: The version 26 text also has a proofreading error, “specified specified”. But I assume the RFC Editor would fix that anyway.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 23 Sep 2020 17:37:06 -0400

John:

Hi!

Personal opinion:  I believe that the “specified here” part (meaning this
document) is already covering the unknown case.  However, I have no
objections to adding the phrase in.

Thanks!

Alvaro.

On September 23, 2020 at 5:14:50 PM, John Scudder ([email-masked]) wrote:

Hi All,

I’m a little concerned about a change I failed to notice earlier in
5575bis. Version 17 had this paragraph in Section 4.2:

   All combinations of component types within a single NLRI are allowed,
   even if the combination makes no sense from a semantical perspective.
   *If a given component type within a prefix in unknown, the prefix in*
   *question cannot be used for traffic filtering* purposes by the
   receiver.  Since a Flow Specification has the semantics of a logical
   AND of all components, if a component is FALSE, by definition it
   cannot be applied.  However, for the purposes of BGP route
   propagation, this prefix should still be transmitted since BGP route
   distribution is independent on NLRI semantics.

Version 18 removed the paragraph. I believe it was removed because of good
and reasonable concerns about the “prefix should still be transmitted”
part. But, it appears we threw out the baby with the bathwater: the final
version of the draft has nothing that corresponds to the underlined part.
It is underspecified with respect to what should be done with unknown
component types. The closest it comes is this paragraph in Section 4.2 of
version 26:

   A NLRI value not encoded as specified specified here is considered
   malformed and error handling according to Section 10
<https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-10>
is performed.

But I think this falls well short of being either clear or unambiguous,
because what does “as specified here” mean exactly?

I’d like to open a discussion of whether the WG agrees that this is a bug
and if so, whether it’s concerning enough to request a last-minute patch to
the document, which is currently with the RFC Editor, so it’s almost an
RFC. I think the least intrusive fix would be to insert the clause
“including an NLRI that contains an unknown component type”, as in:

   is considered
   malformed and error handling according to Section 10
<https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-10>
is performed.

Just as a side note, “error handling according to Section 10” points us to
RFCs 7606 and 4760, which end up telling us to reset the session if the
NLRI is malformed.

Until we get a chance to discuss this, I’ve sent a note to the RFC Editor
asking them to hold publication.

Thanks,

—John

P.S.: The version 26 text also has a proofreading error, “specified
specified”. But I assume the RFC Editor would fix that anyway.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 24 Sep 2020 00:22:52 +0200

Hi Alvaro & John

That change originated based on your below review comments:

[major] "...for the purposes of BGP route propagation, this prefix should
still be transmitted since BGP route distribution is independent on NLRI
semantics." I think this is a vulnerability: a (large) set of meaningless
Flow Specifications may be injected in the routing system...

[major] Also, propagating these unknown components may result in a router
down the line, which understands them, reacting. While the reaction
shouldn't result in reset adjacencies, it may result in inconsistent
forwarding or other unexpected outcomes...

[major] This treatment of unknown extensions is in conflict with the text
in §11. See my comments there.

- - -

It seems clear we have few point of view here to consider:

a) Yes John is right that just because my RRs do not recognize the NLRI
encoding should I block myself for propagating it ... well today it is
dropped in all other AFI/SAFIs so why should flowspec be any different ?

b) Alvaro's review was (I believe) targeting more inter-as propagation
cases and we discussed this and decided it is better to be safe than sorry
and removed that text.

c) We are talking here about BGP NLRI ... not some opaque attribute. If you
allow "garbage" to be sent within NLRI - which as we all know is a BGP db
key to store information - I think we are opening a much bigger security
hole as our imagination can reach.

To summarize at the end of the day I support current text.

Thx,

Robert (as co-author of this change).

On Wed, Sep 23, 2020 at 11:37 PM Alvaro Retana <[email-masked]>
wrote:

>    malformed and error handling according to Section 10 <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-10> is performed.
>
>
>    malformed and error handling according to Section 10 <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-10> is performed.
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 24 Sep 2020 00:32:47 +0200

Btw some pointers to the archives of the discussions on this very point
below:

https://github.com/stoffi92/rfc5575bis/issues/20

https://github.com/stoffi92/rfc5575bis/issues/93

Thx and all credit to Christoph for making is so open and transparent like
no one has ever done it before when editing and reviewing an ietf
document.

Kind regards,
R.

On Thu, Sep 24, 2020 at 12:22 AM Robert Raszuk <[email-masked]> wrote:

> c) We are talking here about BGP NLRI ... not some opaque attribute. If
> you allow "garbage" to be sent within NLRI - which as we all know is a BGP
> db key to store information - I think we are opening a much bigger security
>> Version 18 removed the paragraph. I believe it was removed because of
>> good and reasonable concerns about the “prefix should still be transmitted”
>> Just as a side note, “error handling according to Section 10” points us
>> to RFCs 7606 and 4760, which end up telling us to reset the session if the
>> NLRI is malformed.
>>

---

From: John Scudder <[email-masked]>
Date: Thu, 24 Sep 2020 01:20:38 +0000

Robert,

I think you must have misunderstood my point. You write,

"a) Yes John is right that just because my RRs do not recognize the NLRI encoding should I block myself for propagating it ... well today it is dropped in all other AFI/SAFIs so why should flowspec be any different ?”

I’m not talking about that at all. What I’m saying is, the document currently doesn’t talk about what to do with unrecognized component types, except maybe in the most subtle way, with the text about “specified here” that Alvaro commented on. To understand what my real point is, you can look at my proposed change, namely the following addition:

   is considered
   malformed and error handling according to Section 10<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26*section-10__;Iw!!NEt6yMaO-gk!R8yX8Nb809gEyrF-PBbvD7X_2gWsfBcmRVxSRQDYZpDth-wkOeLb7U2XmjjeTQ$> is performed.

It makes it explicit that unknown component types lead the NLRI to be “considered malformed”. Nothing more.

—John

On Sep 23, 2020, at 6:22 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alvaro & John

[major] "...for the purposes of BGP route propagation, this prefix should still be transmitted since BGP route distribution is independent on NLRI semantics." I think this is a vulnerability: a (large) set of meaningless Flow Specifications may be injected in the routing system...

[major] Also, propagating these unknown components may result in a router down the line, which understands them, reacting. While the reaction shouldn't result in reset adjacencies, it may result in inconsistent forwarding or other unexpected outcomes...

[major] This treatment of unknown extensions is in conflict with the text in §11. See my comments there.

- - -

a) Yes John is right that just because my RRs do not recognize the NLRI encoding should I block myself for propagating it ... well today it is dropped in all other AFI/SAFIs so why should flowspec be any different ?

b) Alvaro's review was (I believe) targeting more inter-as propagation cases and we discussed this and decided it is better to be safe than sorry and removed that text.

c) We are talking here about BGP NLRI ... not some opaque attribute. If you allow "garbage" to be sent within NLRI - which as we all know is a BGP db key to store information - I think we are opening a much bigger security hole as our imagination can reach.

Thx,

On Wed, Sep 23, 2020 at 11:37 PM Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:
John:

Hi!

Personal opinion:  I believe that the “specified here” part (meaning this document) is already covering the unknown case.  However, I have no objections to adding the phrase in.

Thanks!

Alvaro.

On September 23, 2020 at 5:14:50 PM, John Scudder ([email-masked]<mailto:[email-masked]>) wrote:

Hi All,

   A NLRI value not encoded as specified specified here is considered
   malformed and error handling according to Section 10<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26*section-10__;Iw!!NEt6yMaO-gk!X33aXIqmJKpuBLu5XhESzecquhHYnXvZ8bZcgnSfv5R5I_hLLjlkWSj18e_gKw$> is performed.

   is considered
   malformed and error handling according to Section 10<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26*section-10__;Iw!!NEt6yMaO-gk!X33aXIqmJKpuBLu5XhESzecquhHYnXvZ8bZcgnSfv5R5I_hLLjlkWSj18e_gKw$> is performed.

Thanks,

—John

---

From: John Scudder <[email-masked]>
Date: Thu, 24 Sep 2020 01:31:05 +0000

Robert,

Thanks for the pointers! Some comments in line.

On Sep 23, 2020, at 6:32 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Btw some pointers to the archives of the discussions on this very point below:

https://github.com/stoffi92/rfc5575bi/issues/20

In this one it seems the relevant comment is "This is a remain from the "old days" when FS should be opaque to BGP. In such an environment BGP has no understanding of components. Since the implementations do not treat the NLRI opaque the WG voted against this idea. Now BGP knows about components and is able to throw away useless combinations.” This makes sense to me and I agree, however I think that in addition, the change accidentally made it underspecified what to do with unknown component types.

By the way, I also noticed this later comment, "unknown flow components / NLRI that are not understood completely lead to treat-as-withdraw (and thus are not propagated) -> error handling. NLRI opaque has completely been removed from the draft.” Just as a by-the-way, I don’t think that’s what the final version of 5575bis says. As I remarked in my earlier email, it will lead to a session reset, not treat-as-withdraw. From my earlier: "Just as a side note, “error handling according to Section 10” points us to RFCs 7606 and 4760, which end up telling us to reset the session if the NLRI is malformed.” As I recall this was discussed in the WG and found to be acceptable.

I don’t think this one is related.

Thx and all credit to Christoph for making is so open and transparent like no one has ever done it before when editing and reviewing an ietf document.

Agreed!

—John

Kind regards,
R.

On Thu, Sep 24, 2020 at 12:22 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alvaro & John

- - -

Thx,

Hi!

Thanks!

Alvaro.

Hi All,

   A NLRI value not encoded as specified specified here is considered
   malformed and error handling according to Section 10<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26*section-10__;Iw!!NEt6yMaO-gk!Xo1YqMazt-59s4p8GkRbq0Hp2fu3Q6xEX1ZMT53DOe2DQcBkgGz1xrxrqrAW_g$> is performed.

   is considered
   malformed and error handling according to Section 10<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26*section-10__;Iw!!NEt6yMaO-gk!Xo1YqMazt-59s4p8GkRbq0Hp2fu3Q6xEX1ZMT53DOe2DQcBkgGz1xrxrqrAW_g$> is performed.

Thanks,

—John

---

From: Christoph Loibl <[email-masked]>
Date: Thu, 24 Sep 2020 11:48:44 +0200

Hi,

I fully agree with Alvaro (to both statements). 

John: If you want me to edit this phrase into the document I think there won't be any objections (while I believe it is not needed). How shall we continue (should I do the change or is this something RFC-editors are doing now?).

Cheers Christoph 

-- 
Christoph Loibl
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

> On 23.09.2020, at 23:37, Alvaro Retana <[email-masked]> wrote:
> 
> John:
> 
> Hi!
> 
> On September 23, 2020 at 5:14:50 PM, John Scudder ([email-masked] <mailto:[email-masked]>) wrote:
> 
>> Hi All,
>>

---

From: "McPherson, Danny" <[email-masked]>
Date: Thu, 24 Sep 2020 11:14:00 +0000

I agree as well.

-danny

On Sep 24, 2020, at 5:49 AM, Christoph Loibl <[email-masked]> wrote:

 Hi,

Cheers Christoph

--
Christoph Loibl
[email-masked]<mailto:[email-masked]> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at<http://secure-web.cisco.com/1cEXU7BTURyxeBLQHzaDtEia25k9TBqLCI0A2F7OPWhuNKjct1OsCPcm5PqMdliJoTDy8AAR6G8xznPT3I8ck0Nr2bpXNyJQPmk07LFh7VTpfAg9S0lvg5ADmnYDQ8xfrufPIoWWiC9MRl8uw5d1T9vxW1v_6BDWM97rj6DRCUPnkaK7GONrGhS-4ymzuYRB5ACDMs6O1a8JPUI_lNbGu2S8072yh6v0LrXK6SOyydpue1S9TlMWRDttWPiWM4UA5ouS2KunioqtviV8JQ4qgMw/http%3A%2F%2Fwww.nextlayer.at>

On 23.09.2020, at 23:37, Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:

John:

Hi!

Thanks!

Alvaro.

Hi All,

   A NLRI value not encoded as specified specified here is considered
   malformed and error handling according to Section 10<https://secure-web.cisco.com/1TLZgZGpDFqtnI2mJNLYf9XTaI2ut4-JFs012vxvkt1Jdiojqh8GRIf3cA3Pl1yKunmMj25sws1kaiwVyD3R42ozGNOdk568BE9H6IqHqoOO1g_CvOBp59Vd2pLRaO7a72R7HlyY6DqJL-GPPntoaTdpail5rDyuNoXHgt1yLonyLO3RpcLPHZ6zjOUK9n4cRIWDLCUZUd5sTU-kndI7z1wbRBy5LLjIu6j2xJdhY-5-A5noGLynYSZoq8BGWLXiMVp8T6xI3Dfx9eUqY-6lBlg/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-rfc5575bis-26%23section-10> is performed.

   is considered
   malformed and error handling according to Section 10<https://secure-web.cisco.com/1TLZgZGpDFqtnI2mJNLYf9XTaI2ut4-JFs012vxvkt1Jdiojqh8GRIf3cA3Pl1yKunmMj25sws1kaiwVyD3R42ozGNOdk568BE9H6IqHqoOO1g_CvOBp59Vd2pLRaO7a72R7HlyY6DqJL-GPPntoaTdpail5rDyuNoXHgt1yLonyLO3RpcLPHZ6zjOUK9n4cRIWDLCUZUd5sTU-kndI7z1wbRBy5LLjIu6j2xJdhY-5-A5noGLynYSZoq8BGWLXiMVp8T6xI3Dfx9eUqY-6lBlg/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-idr-rfc5575bis-26%23section-10> is performed.

Thanks,

—John

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 24 Sep 2020 15:10:56 -0400

John, Alvaro, Christoph,  and Danny: 

I agree with Alvaro that the document covers the unknown case.   

However,  it is fine to add the text to tie the information down. 

I do not think we need to take this back to the WG – as I believe the text covers this point already. 

Sue Hares

From: Idr [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: Wednesday, September 23, 2020 5:37 PM
To: John Scudder; idr@ietf. org
Cc: [email-masked]; Hares Susan
Subject: Re: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

John:

Hi!

 

Thanks!

Alvaro.

Hi All, 

Thanks,

—John

---

From: <[email-masked]>
Date: Fri, 25 Sep 2020 16:56:27 +0000

Hi John, all,

Thanks for the careful review.
Please see inline [Bruno]

From: Idr [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Wednesday, September 23, 2020 11:15 PM
To: idr@ietf. org <[email-masked]>

Hi All,

But I think this falls well short of being either clear or unambiguous, because what does “as specified here” mean exactly?
[Bruno] In general, I favour interop and clear spec and IMHO, the fact that you ask the question is an indication that the text is not clear enough.
However, I would not want to mess with this document as this stage; so please see the below comments as discussions/info. Especially since I’m not familiar with FS so I may be missing something obvious.

   is considered

[Bruno] Thanks for providing the full picture and hence the importance of the point.
_IMHO_, RFC 7606 calls for session reset as a ‘last’  resort error handling behaviour.
8.  Guidance for Authors of BGP Specifications
[…]
The "treat-as-withdraw" approach is generally preferred and the "session reset" approach is discouraged.
https://tools.ietf.org/html/rfc7606#section-8

Treat-as-withdraw cannot be performed when the NLRI can’t be found in the update, or the NLRI can’t be effectively withdrawn typically because the peer won’t accept it in the withdraw (e.g. and IPv4 address of 5 octets). Or (my reading) we feel that the received NLRI seem so wrong that what we read may not be what was intended to be send. IOW, there is an error in the syntax.

IHMO, RFC 7606 specifies “session reset” when the MP_REACH_NLRI attribute is malformed or the NLRI is syntactically incorrect.

I’m not familiar with FS, but so far, I don’t feel that an unknown component type in FS:
- prevents the “treat-as-withdraw” approach.
- matches the RFC 7606 description of a syntactically incorrect NLRI field https://tools.ietf.org/html/rfc7606#section-5.3

Also, I don’t see capability negotiation so how is the sender supposed to know the list of component types which is supported by the receiver?

Finally, I’d like to also point to another text from RFC 7606, which I think is relevant for this rfc5575bis discussion.
8.  Guidance for Authors of BGP Specifications
[…]
   Authors
   of BGP documents are also reminded to review the discussion of
   optional transitive attributes in the first paragraph of the
   Introduction of this document.
https://tools.ietf.org/html/rfc7606#section-8

Thanks,
--Bruno

Thanks,

—John

_________________________________________________________________________________________________________________________

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.

---

From: John Scudder <[email-masked]>
Date: Fri, 25 Sep 2020 19:04:22 +0000

Hi Bruno,

Thanks for your comments. Some replies in line.

On Sep 25, 2020, at 12:56 PM, [email-masked]<mailto:[email-masked]> wrote:

...

https://tools.ietf.org/html/rfc7606#section-8<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7606*section-8__;Iw!!NEt6yMaO-gk!VbvkPXEkoG_mG12V_w5W4g3uJjg0nhKD6gBw8TalRXnfznNSdAmgpOnjLHVOBw$>

Exactly right.

I’m not familiar with FS, but so far, I don’t feel that an unknown component type in FS:
- prevents the “treat-as-withdraw” approach.
- matches the RFC 7606 description of a syntactically incorrect NLRI field https://tools.ietf.org/html/rfc7606#section-5.3<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7606*section-5.3__;Iw!!NEt6yMaO-gk!VbvkPXEkoG_mG12V_w5W4g3uJjg0nhKD6gBw8TalRXnfznNSdAmgpOmjo43yJQ$>

My reading was that since the FS document carefully says “is considered malformed” and then references Section 10, which in turn references 7606 and 4760, and since 7606 and 4760 both say “reset the session if it’s malformed” that a session reset was called for. I think that is the right thing, too: FS uses T,V and not T,L,V for its component types, the lengths are implicit. So, if my parser encounters an unknown type code it is impossible for me to know how to skip over that type code. At that point, parsing breaks down.

It’s not, this is a deficiency in FS that I think the WG needs to address in the proposed FSv2 work.

Regards,

—John

---

From: John Scudder <[email-masked]>
Date: Fri, 25 Sep 2020 19:06:23 +0000

Hi Robert,

Just to close the loop, I think you are not objecting to the text I proposed, which just clarifies one (important) case which the other authors have agreed was already covered.

If I’m mistaken, please say so.

Thanks,

—John

On Sep 23, 2020, at 9:20 PM, John Scudder <jgs=[email-masked]<mailto:jgs=[email-masked]>> wrote:

Robert,

   is considered

—John

Hi Alvaro & John

- - -

Thx,

Hi!

Thanks!

Alvaro.

Hi All,

   is considered

Thanks,

—John

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!V1-2XdRBItnBmsiIntEXdv0HiPp5NLCGPetRiDIIT0XkiDjvrFK5lCLXxjg8Lg$

---

From: John Scudder <[email-masked]>
Date: Fri, 25 Sep 2020 19:14:34 +0000

Hi All,

Jie brought up another point in a unicast email. He points out that

The description about component type 12 (Fragment) has been updated, the meaning of the Bitmask values is added. For Bit-6 (IsF), the new description is:

   IsF -  Is a fragment - match if [RFC0791] IP Header Fragment Offset is not 0.

This description is IMO a little bit confusing, as it simply says “is a fragment”, but the matching rule does not include the case of the first fragment (MF=1, offset=0),. Perhaps it could either update the matching rules to also include the first fragment case, or it may update the description as “fragmented and not the first segment”.

Let’s also discuss this before we take the document off of hold and continue its processing. Speaking for myself, I don’t find the quoted text confusing since the rule specifically says “fragment offset is not 0”, but on the other hand it would do no harm to change the description to the even-more-correct “Is a fragment other than the first” (I didn’t use “segment” as Jie does, since that’s potentially a new source of confusion; “segment” is a TCP term, not an IPv4 term, and it’s a *different* IPv6 term).

Thanks,

—John

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 26 Sep 2020 00:05:24 +0200

John,

> FS uses T,V and not T,L,V for its component types, the lengths are
implicit.

That's not completely right ... number of types in NLRI include length
(called numeric_op) :) as spec defines them as 1 or 2 bytes values.

- - -

Original 5575 treated entrie NLRI as one value, allowing it to be
propagated and when locally some match was not supported it was not applied
to the data plane - but BGP still was propagating it. Here this change is
now asking for each BGP speaker involved in FS propagation that it MUST
parse all types of the NLRI and if it does not recognize any type reset the
session.

Putting aside if this is good or bad how are we going to actually roll in
such change while keeping same capabilities ?

Say someone just upgrades the OS with FS code compliant to 5575bis and
suddenly his sessions will be going down ...

I think some of my previous comments were just based on the view ... oh yes
let's make sure we propagate valid information only .. but do we all
realize the consequences of this change ? Do we check by default if prefix
is a valid IP prefix and not part of bogons or do we need policy line to do
it for us ?

I am not saying what you proposed is bad ... but I am scared about the
consequences to now validate all types encoded as part of each FS NLRI. And
if you sent 1000 and you get 1 more with new unknown type or worse some new
draft will define new numeric_op on the existing type - and receiver will
not recognize it .. all 1000 previously advertised NLRIs are going to be
withdrawn (if sessions gets reset) ...

- - -

Also, I don’t see capability negotiation so how is the sender supposed to
know the list of component types which is supported by the receiver?

> It’s not, this is a deficiency in FS that I think the WG needs to address
in the proposed FSv2 work.

Well I think this is a deficiency of BGP that only my directly connected
(in BGP sense) peer has a chance to know my capabilities.

But putting this aside - in any multi vendor network you will often have
discrepancy among vendors on the supported features. For FS primary use
there is no loops .. you drop and mitigate DDoS when and where you can.

If not and even if you would have a map of entire BGP network in terms of
supported match and actions - what would you propose to do ? Least common
denominator ?

Thx,
R.

On Fri, Sep 25, 2020 at 9:04 PM John Scudder <[email-masked]> wrote:

> On Sep 25, 2020, at 12:56 PM, [email-masked] wrote:
>
> ...
>
> RFCs 7606 and 4760, which end up telling us to reset the session if the NLRI
>  is malformed.
>
> _*IMHO*_, RFC 7606 calls for session reset as a ‘last’  resort error
> handling behaviour.
> <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7606*section-8__;Iw!!NEt6yMaO-gk!VbvkPXEkoG_mG12V_w5W4g3uJjg0nhKD6gBw8TalRXnfznNSdAmgpOnjLHVOBw$>
>
> Treat-as-withdraw cannot be performed when the NLRI can’t be found in the
> update, or the NLRI can’t be effectively withdrawn typically because the
> peer won’t accept it in the withdraw (e.g. and IPv4 address of 5 octets).
> Or (my reading) we feel that the received NLRI seem so wrong that what we
> read may not be what was intended to be send. IOW, there is an error in the
> syntax.
>
>
> Exactly right.
>
>
> IHMO, RFC 7606 specifies “session reset” when the MP_REACH_NLRI attribute is
> malformed or the NLRI is syntactically incorrect.
>
> - matches the RFC 7606 description of a syntactically incorrect NLRI field
>  https://tools.ietf.org/html/rfc7606#section-5.3
> <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7606*section-5.3__;Iw!!NEt6yMaO-gk!VbvkPXEkoG_mG12V_w5W4g3uJjg0nhKD6gBw8TalRXnfznNSdAmgpOmjo43yJQ$>
>
>
> My reading was that since the FS document carefully says “is considered
> malformed” and then references Section 10, which in turn references 7606
> and 4760, and since 7606 and 4760 both say “reset the session if it’s
> malformed” that a session reset was called for. I think that is the right
> thing, too: FS uses T,V and not T,L,V for its component types, the lengths
> are implicit. So, if my parser encounters an unknown type code it is
> impossible for me to know how to skip over that type code. At that point,
> parsing breaks down.
>
> Also, I don’t see capability negotiation so how is the sender supposed to
> know the list of component types which is supported by the receiver?
>
>

---

From: Christoph Loibl <[email-masked]>
Date: Sat, 26 Sep 2020 10:48:46 +0200

Hi John,

I agree that changing the name would do no harm.

Cheers

Christoph 

> On 25.09.2020, at 21:14, John Scudder <[email-masked]> wrote:
> 
> Hi All,
>

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 26 Sep 2020 21:04:25 -0400

Chrisoph and John: 

I’m fine with the word change as well.   I thought it was clear – but anything that helps make this very clear is fine with me. 

Sue 

From: Christoph Loibl [mailto:[email-masked]] 
Sent: Saturday, September 26, 2020 4:49 AM
To: John Scudder
Cc: idr@ietf. org; [email-masked]; Hares Susan
Subject: Re: [BULK] [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi John,

Cheers

Christoph 

 

Hi All, 

Thanks,

—John

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sun, 27 Sep 2020 06:43:25 +0000

Hi John,

Thanks for bringing this to list discussion.

I agree it would be no harm to clarify it as “Is a fragment other than the first”. (Sorry for the typo with “segment”, I mean fragment actually).

And since the description of the rule  “fragment offset is not 0” is added in 5575bis, perhaps it would be helpful to note whether the semantics aligns with RFC 5575, or is a small update?

Best regards,
Jie

From: Idr [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Saturday, September 26, 2020 3:15 AM
To: idr@ietf. org <[email-masked]>
Cc: [email-masked]; Hares Susan <[email-masked]>
Subject: Re: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi All,

Thanks,

—John

---

From: <[email-masked]>
Date: Mon, 28 Sep 2020 13:45:31 +0000

Hi John,

Thanks for your answer.
Please see two replies inline [Bruno]

From: John Scudder [mailto:[email-masked]]
Sent: Friday, September 25, 2020 9:04 PM
To: DECRAENE Bruno TGI/OLN <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; [email-masked]; Hares Susan <[email-masked]>
Subject: Re: Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi Bruno,

...

https://tools.ietf.org/html/rfc7606#section-8<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7606*section-8__;Iw!!NEt6yMaO-gk!VbvkPXEkoG_mG12V_w5W4g3uJjg0nhKD6gBw8TalRXnfznNSdAmgpOnjLHVOBw$>

Exactly right.

I’m not familiar with FS, but so far, I don’t feel that an unknown component type in FS:
- prevents the “treat-as-withdraw” approach.
- matches the RFC 7606 description of a syntactically incorrect NLRI field https://tools.ietf.org/html/rfc7606#section-5.3<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7606*section-5.3__;Iw!!NEt6yMaO-gk!VbvkPXEkoG_mG12V_w5W4g3uJjg0nhKD6gBw8TalRXnfznNSdAmgpOmjo43yJQ$>

My reading was that since the FS document carefully says “is considered malformed” and then references Section 10, which in turn references 7606 and 4760, and since 7606 and 4760 both say “reset the session if it’s malformed” that a session reset was called for.
[Bruno]
I agree that this is a valid reading.
However my reading was that draft-ietf-idr-rfc5575bis was saying that the NLRI was semantically malformed. Then that 7606 was calling for session reset only for the malformed MP_REACH attribute or syntactically incorrect NRLI, while calling for treat as withdraw when the NLRI could be recovered and hence withdrawn.

I’m fine to be declared in the rough, but so far (assuming I’m not wrong on the below second point), I do not support the proposed change.
I also note that this action may be seen as a local decision not impacting interop. Hence if we chose to modify the text, we could allow for both, allowing both types of implementation to be compliant with the RFC.

Also reviewing https://github.com/stoffi92/rfc5575bis/issues/20 I think that the outcome of the discussion was that the NRLI should not be propagated but “throw[n] away”.
I also see a specific concluding comment from stoffi92 (Christoph Loibl, the editor of the document) specifically referring to treat-as-withdraw  “unknown flow components / NLRI that are not understood completely lead to treat-as-withdraw (and thus are not propagated) -> error handling.”

I think that is the right thing, too: FS uses T,V and not T,L,V for its component types, the lengths are implicit. So, if my parser encounters an unknown type code it is impossible for me to know how to skip over that type code. At that point, parsing breaks down.
[Bruno] I had in mind the higher level of hierarchy:

   The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
   one or more 2-tuples of the form <length, NLRI value>.  It consists
   of a 1- or 2-octet length field followed by a variable-length NLRI
   value.  The length is expressed in octets.

                     +-------------------------------+
                     |    length (0xnn or 0xfnnn)    |
                     +-------------------------------+
                     |    NLRI value   (variable)    |
                     +-------------------------------+

                Figure 1: Flow Specification NLRI for IPv4

At this level, assuming that the NLRI value is found semantically incorrect, it seems to me that one could:

-          Skip this NLRI (thanks to the ‘length’ field) and continue with the next NLRI

-          Read the ‘NLRI value’ as an opaque data, and treat this NLRI as withdraw. (In the context of the discussion, this NLRI would never had been accepted, so ‘treat-as-withdraw’  could even be replaced with ‘ignore’. But I’m _not_ calling for this).
Hence it seems to me that treat-as-withdraw is technically possible.

With either ‘session reset’ or ‘treat as withdraw”, this NLRI is equally dead/withdrawn. The question is about punishing the other NLRIs from this AFI/SAFI and even all other AFI/SAFI sharing this BGP session.

I also note that RFC 7606 is opening another error handling strategy in between (called AFI/SAFI disable) but this seem out of scope of the discussion as “session reset” does not appear in draft-ietf-idr-rfc5575bis. Hence this would be about RFC 7606 interpretation. (my interpretation is that 7606 allows for both, with no preference given)

Thank you.

--Bruno

Regards,

—John

---

From: John Scudder <[email-masked]>
Date: Mon, 28 Sep 2020 18:16:06 +0000

Hi Bruno,

Thanks for your further comments. My responses in line.

On Sep 28, 2020, at 9:45 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi John,

Thanks for your answer.

From: John Scudder [mailto:[email-masked]]
Sent: Friday, September 25, 2020 9:04 PM
To: DECRAENE Bruno TGI/OLN <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Hares Susan <[email-masked]<mailto:[email-masked]>>
Subject: Re: Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi Bruno,

...

Exactly right.

I’m unclear on this point: the only change proposed so far (other than the one you’ll come to later in this message) is to add the clause "including an NLRI that contains an unknown component type” to Section 4.2. I don’t think that has any effect on the discussion we are now having about choice of error handling strategy, treat-as-withdraw vs. session reset, so your comment that you do not support it seems like a bit of a non sequitur.

Fair enough. It’s a little unfortunate that the draft contains this ambiguity; in retrospect it would have been better to be explicit about the error-handling strategy chosen rather than simply referencing RFC 7606. Whether or not we want to respin the draft in order to clarify it, is a question for the WG. If we were to make a change, it could potentially be the addition of this sentence, in Section 10:

   Error handling according to [RFC7606<https://tools.ietf.org/html/rfc7606>] and [RFC4760<https://tools.ietf.org/html/rfc4760>] applies to this

   specification. Notably, an NLRI that is found to be semantically

   incorrect (for example due to an unknown component type) MUST be

   handled using the “treat-as-withdraw” strategy (which in this case,

   it must be noted, works out to be the same as skipping over the NLRI).

I also note that RFC 7606 is opening another error handling strategy in between (called AFI/SAFI disable)

Just as a footnote, that strategy actually comes from RFC 4760, RFC 7606 merely cites it (and gives it a name).

—John

but this seem out of scope of the discussion as “session reset” does not appear in draft-ietf-idr-rfc5575bis. Hence this would be about RFC 7606 interpretation. (my interpretation is that 7606 allows for both, with no preference given)

Thank you.

--Bruno

Regards,

—John

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 28 Sep 2020 12:16:06 -0700

[Explicitly adding Jeff to the To list.]

Hi!

During my AD review there was a discussion on the list about this point,
and whether we could avoid resetting the session.  Jeff presented some
examples and, I think, made a very convincing case of why we really can’t:
even if we can look at the length, we would still be guessing.

I think this is one of the messages:
https://mailarchive.ietf.org/arch/msg/idr/FHC-Vz26LZfam-o5Y-9-WSrEm2g/

Jeff: if you get a chance, please chime in.

Thanks!

Alvaro.

On September 28, 2020 at 2:16:38 PM, John Scudder (
jgs=[email-masked]) wrote:

I think that is the right thing, too: FS uses T,V and not T,L,V for its
component types, the lengths are implicit. So, if my parser encounters an
unknown type code it is impossible for me to know how to skip over that
type code. At that point, parsing breaks down.
[Bruno] I had in mind the higher level of hierarchy:

At this level, assuming that the NLRI value is found semantically
incorrect, it seems to me that one could:
-          Skip this NLRI (thanks to the ‘length’ field) and continue with
the next NLRI
-          Read the ‘NLRI value’ as an opaque data, and treat this NLRI as
withdraw. (In the context of the discussion, this NLRI would never had been
accepted, so ‘treat-as-withdraw’  could even be replaced with ‘ignore’. But
I’m _*not*_ calling for this).
Hence it seems to me that treat-as-withdraw is technically possible.

Fair enough. It’s a little unfortunate that the draft contains this
ambiguity; in retrospect it would have been better to be explicit about the
error-handling strategy chosen rather than simply referencing RFC 7606.
Whether or not we want to respin the draft in order to clarify it, is a
question for the WG. If we were to make a change, it could potentially be
the addition of this sentence, in Section 10:

   Error handling according to [RFC7606
<https://tools.ietf.org/html/rfc7606>] and [RFC4760
<https://tools.ietf.org/html/rfc4760>] applies to this

   specification. *Notably, an NLRI that is found to be semantically*

   *incorrect (for example due to an unknown component type) MUST be*

   *handled using the “treat-as-withdraw” strategy (which in this case,*

   *it** must be noted, works out to be the same as skipping over the NLRI)**.	*

---

From: Christoph Loibl <[email-masked]>
Date: Mon, 28 Sep 2020 21:41:01 +0200

Hi,

I do not really want to repeat the whole discussion here (seems that we are going in circles) if not needed. I think that we agreed that if the NLRI is malformed the only option is to reset (+send notification) the session (even if we consider rfc7606). And from draft-rfc5575bis it is clear that we are talking about a malformed NLRI:

   A NLRI value not encoded as specified specified here is considered
   malformed and error handling according to Section 10 is performed.

-> I think that adding the small term that John suggested is sufficient.

Cheers Christoph

> On 28.09.2020, at 21:16, Alvaro Retana <[email-masked]> wrote:
> 
> During my AD review there was a discussion on the list about this point, and whether we could avoid resetting the session.  Jeff presented some examples and, I think, made a very convincing case of why we really can’t: even if we can look at the length, we would still be guessing.
> 
> I think this is one of the messages:  https://mailarchive.ietf.org/arch/msg/idr/FHC-Vz26LZfam-o5Y-9-WSrEm2g/ <https://mailarchive.ietf.org/arch/msg/idr/FHC-Vz26LZfam-o5Y-9-WSrEm2g/> 
> 
> On September 28, 2020 at 2:16:38 PM, John Scudder (jgs=[email-masked] <mailto:jgs=[email-masked]>) wrote:
> 
>> 
>>    Error handling according to [RFC7606 <https://tools.ietf.org/html/rfc7606>] and [RFC4760 <https://tools.ietf.org/html/rfc4760>] applies to this

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Sep 2020 22:43:37 +0200

All,

To me the real question is if we really should validate the content of NLRI
or just make sure that NLRI boundaries meet BGP MP_REACH definition and
treat NLRI values completely opaque to BGP (as per original RFC5575).

If NLRI is really malformed resulting in MP_REACH attribute being malformed
I do not see that much harm in session reset.

But if we dive into each atomic type parsing of the NLRI value itself at
each BGP speaker talking SAFI 133/134 I think this is going to be a mess.

Best,
R.

On Mon, Sep 28, 2020 at 9:41 PM Christoph Loibl <[email-masked]> wrote:

> Hi,
>
> I do not really want to repeat the whole discussion here (seems that we
> are going in circles) if not needed. I think that we agreed that if the
> NLRI is malformed the only option is to reset (+send notification) the
> session (even if we consider rfc7606). And from draft-rfc5575bis it is
> clear that we are talking about a malformed NLRI:
>
> -          Read the ‘NLRI value’ as an opaque data, and treat this NLRI
> as withdraw. (In the context of the discussion, this NLRI would never had
> been accepted, so ‘treat-as-withdraw’  could even be replaced with
> ‘ignore’. But I’m _*not*_ calling for this).
>    *it** must be noted, works out to be the same as skipping over the NLRI)**.*
>
>
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 28 Sep 2020 23:23:16 +0000

Also to consider that in BGP, there are several examples of NLRI
where the NLRI key is not the whole NLRI, starting with RFC 3107,
where the label is not part of the key.

A speaker that receives an update with an unknown NLRI does not
know if that unknown NLRI servers to withdraw a (seemingly)
different unknown NLRI, if the parts that are different are not
key material.

Therefore, a BGP speaker must always be able to completely
parse and understand received NLRI.

Flowspec does not AFAIK have any such NLRI... yet.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Monday, September 28, 2020 1:44 PM
To: Christoph Loibl <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; [email-masked]; John Scudder <jgs=[email-masked]>; [email-masked]; Hares Susan <[email-masked]>
Subject: Re: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

All,

To me the real question is if we really should validate the content of NLRI or just make sure that NLRI boundaries meet BGP MP_REACH definition and treat NLRI values completely opaque to BGP (as per original RFC5575).

If NLRI is really malformed resulting in MP_REACH attribute being malformed I do not see that much harm in session reset.

But if we dive into each atomic type parsing of the NLRI value itself at each BGP speaker talking SAFI 133/134 I think this is going to be a mess.

Best,
R.

On Mon, Sep 28, 2020 at 9:41 PM Christoph Loibl <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Cheers Christoph

--
Christoph Loibl
[email-masked]<mailto:[email-masked]> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

On 28.09.2020, at 21:16, Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:

Hi!

I think this is one of the messages:  https://mailarchive.ietf.org/arch/msg/idr/FHC-Vz26LZfam-o5Y-9-WSrEm2g/

Thanks!

Alvaro.

On September 28, 2020 at 2:16:38 PM, John Scudder (jgs=[email-masked]<mailto:jgs=[email-masked]>) wrote:

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 29 Sep 2020 08:57:33 +0200

Hi Jakob,

> Flowspec does not AFAIK have any such NLRI... yet.

I am not quite sure what are you trying to say above.

Today in RFC5575 NLRI is clearly defined as a numeric value with a given
length. It was by design not parsable by BGP. The entire NLRI is a key.

So updates and withdraws processing happens on the key as defined.

Now if we start to parse that value (except maybe for validation which I am
also now pretty sceptical about) and dissecting part of that calling some
types to be a key and some not - at min IMHO we should use different SAFI
not to create complete deployment issues.

Many thx,
R.

On Tue, Sep 29, 2020 at 1:23 AM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Idr <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Monday, September 28, 2020 1:44 PM
> *To:* Christoph Loibl <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>; [email-masked];
> John Scudder <jgs=[email-masked]>; [email-masked];
> Hares Susan <[email-masked]>
> *Subject:* Re: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth
> fixing?
>
>
>
> All,
>
>
>
> To me the real question is if we really should validate the content of
> NLRI or just make sure that NLRI boundaries meet BGP MP_REACH
> definition and treat NLRI values completely opaque to BGP (as per original
> RFC5575).
>
>
>
> If NLRI is really malformed resulting in MP_REACH attribute being
> malformed I do not see that much harm in session reset.
>
>
>
>    *it** must be noted, works out to be the same as skipping over the NLRI).*
>
>
>
>

---

From: <[email-masked]>
Date: Tue, 29 Sep 2020 10:14:30 +0000

Hi John,

Please see inline [Bruno2]

Sent: Monday, September 28, 2020 8:16 PM

Hi Bruno,

Hi John,

Thanks for your answer.

Hi Bruno,

...

Exactly right.

I’m unclear on this point: the only change proposed so far (other than the one you’ll come to later in this message) is to add the clause "including an NLRI that contains an unknown component type” to Section 4.2. I don’t think that has any effect on the discussion we are now having about choice of error handling strategy, treat-as-withdraw vs. session reset, so your comment that you do not support it seems like a bit of a non sequitur.
[Bruno2] You have a point.
On my side, I’m seeing another change of perspective, which is indeed not a change in the text. I had assumed that the error handling were treat-as-withdraw. You are stating that the error handling is session reset. This is a change in perspective which, from my view, is not in favor of adding the statement that un unknown type is to be translated as a syntax error in the NLRI.
We seem to have two points which are not crystal clear from the text:

-          Whether an unknown component type is to be considered as a syntax error or semantic error.

-          Whether the above error handling is to be as per treat as withdraw or session reset.

If we open the discussion on one point, I think that we should open the discussion on the second (related) one.
Another path, is that what is done, is done. The document followed the whole process and in theory could already be published as a final RFC.
As a third path, I can also live with your proposed change.

Coming back to your point, i.e. the proposed text change, I could propose
OLD (draft):
A NLRI value not encoded as specified specified here is considered
   malformed and error handling according to Section 10<https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-10> is performed.

NEW:
A NLRI value not encoded as specified here is considered syntactically
   malformed and error handling according to Section 10<https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-10> is performed.

An NLRI that contains an unknown component type, is considered semantically

Fair enough. It’s a little unfortunate that the draft contains this ambiguity; in retrospect it would have been better to be explicit about the error-handling strategy chosen rather than simply referencing RFC 7606.
[Bruno2] I agree.
 Whether or not we want to respin the draft in order to clarify it, is a question for the WG. If we were to make a change, it could potentially be the addition of this sentence, in Section 10:

[Bruno2] Would work for me, obviously. Thanks for the suggestion. I can also live with a SHOULD to avoid making some implementation non-compliant, which seem a bit unfair as one could have understood “session reset” in good faith. At this point in the process, I could also live with leaving both options equally open to implementations. But indeed to be frank, making “session reset” as a MUST is a bridge too far for me, although I could also live with this (as with all lived before RFC 7606)
But from other emails, it seems clear that some people read the draft with “session reset” in mind. So I’m merely stating my own point of view. I’m not stating that this is the truth to be followed. So up to the WG/chairs. Good luck.

--Bruno

—John

Thank you.

--Bruno

Regards,

—John

Thank you.

---

From: <[email-masked]>
Date: Tue, 29 Sep 2020 10:14:33 +0000

Hi Jeff, Alvaro, all

Ø  From: Alvaro Retana [mailto:[email-masked]]

[….]
>Jeff presented some examples and, I think, made a very convincing case of why we really can’t: even if we can look at the length, we would still be guessing.

I don’t share the above opinion.
Copy/pasting  below the referenced email on commenting inline

On Wed, Dec 18, 2019 at 08:11:37AM +0100, Christoph Loibl wrote:
> Hi Jeffrey, Alvaro!
>
> I only pick out this single issue from the complete list, because I do not 100% agree with this statement:
>
>
> > On 17.12.2019, at 23:09, Jeffrey Haas <[email-masked]><mailto:&lt;[email-masked]&gt;> wrote:
> >
> >> If an unknown Flow Specification component exists, then the entire
> >> NLRI cannot be "successfully parsed"...which results in not being able
> >> to use treat-as-withdraw.  The text above leaves us with AFI/SAFI
> >> disable, which is not extension-friendly.
> >
> > This is exactly my largest concern about flowspec right now.  There is no
> > safe way to extend the spec at this point.
> >
> > There are two options available to us, IMO:
> > 1. Flowspec v2, which we stalled out until 5575bis was done.
> > 2. We decide that for 5575-bis that all future extensions MUST be encoded
> > with a TLV format (length being mandatory).  And perhaps even protect a
> > compliant extension with a capability.  This is a major change, but perhaps
> > provides an upgrade path without waiting on v2.
> >>
> >> NEW (suggestion)>
> >>    An advertisement containing an unknown Flow Specification component
> >> should be discarded as specified in Section 5.4 of [RFC7606].
> >
> > You can't parse it, therefore it's malformed.
>
> In case of an unknown flowspec component the parser can run until decoding the component type (always the first byte of the component). When it reads a unknown type-value it can easily jump over the remaining bytes of the entire NLRI (the length of the the complete NLRI is encoded in the first bytes of the NLRI) without needing to understand what is in there, because it should treat it as withdraw. I do not see the problem. It is supposed to “ignore” the entire NLRI not only a single component of it.

Sigh.  Into example-land we go:

You receive the following byte-stream as NLRI in a single BGP PDU:
NLRI-1, length X components 1,2,3
NLRI-2, length Y components 1,2,3,?,?,?
NLRI-3, length Z components 1,2,3

In the case of NLRI-1,3 if you had received these individually, you'd know
they were correct because the implementation understands them.

In NLRI-2, you don't know what some of the components are starting at first ?.

The _best_ you can do in these circumstances is walk the list of NLRI by
length and see if you can arrive at NLRI boundaries and have a valid BGP
Update PDU.

However, you also don't know if you actually have an NLRI-3 or not.  It
might actually be a random byte stream that just happens to parse as an NLRI
and accidentally lands on a packet boundary.  NLRI-2 may be corrupt and the
length mis-calculated.

[Bruno]
OK for the example.
But I don’t think that this specific example support the general claim (that, to be fair, Jeff has not written)

1)      The general claim, that I’m seeing/extrapolating, is that TLV is not a reliable mechanism: it’s not enough to use the length field to skip the unknown type and the unparsable value.
If so, then we should urgently close the LSR WG as we can’t define new reliable (sub)TLVs. We may also consider closing other WGs.
If not, I don’t think that we can make that argument for rfc5575bis.

2)      You are saying that if one don’t see any error but can’t additionally check the validity of the NLRI then we should not trust the NLRI.

If so, we should probably never accept any IPv6 unicast NRLI as we don’t have additional check available to verify that the NLRI is not erroneous: we only rely on the length.

We have seen these bugs before, even in simple RFC 4271 PDUs.

Exactly my point: same thing with  4271 PDU so same conclusion: we couldn’t accept PDU even when the receiver see no error?

3)  Taking one example, and drawing a general conclusion is not a valid analysis of the situation.

If one want to make the analysis, we need to compare at least two scenarios (e.g. go/no go) and analyze all cases taking into account their probability of occurrence and their cost.

Another example: I can probably find a scenario leading to someone committing a fraud in an election. Should we conclude that it’s preferable to avoid election? Or should we accept the result when no fraud is detected?

However, you also don't know if you actually have an NLRI-3 or not.  It
might actually be a random byte stream that just happens to parse as an NLRI
and accidentally lands on a packet boundary.  NLRI-2 may be corrupt and the
length mis-calculated.
[Bruno] Yes, the NLRI may be corrupted. But one could state any hypothesis. E.g. the NLRI may be corrupted by Jeff. And I don’t think that we could use any remotely possible hypothesis to conclude that it’s better if Jeff does not approach an NLRI / BGP implementation. (sorry to pick a name. I’m assuming that my example and conclusion is seem as obviously stupid.)

We know that the syntax is correct. The content may be correct or incorrect: we don’t know. Why should we conclude that the content is wrong? (especially against the probabilities)

Thanks for the discussion.
Regards,
Bruno

-- Jeff

From: Alvaro Retana [mailto:[email-masked]]
Sent: Monday, September 28, 2020 9:16 PM
To: DECRAENE Bruno TGI/OLN <[email-masked]>; John Scudder <jgs=[email-masked]>; Jeffrey Haas <[email-masked]>
Cc: Hares Susan <[email-masked]>; idr@ietf. org <[email-masked]>; [email-masked]
Subject: Re: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi!

Thanks!

Alvaro.

---

From: John Scudder <[email-masked]>
Date: Tue, 29 Sep 2020 15:20:08 +0000

Hi Robert,

You are right that RFC 5575 is very clear about that decision:

   We define a "Flow Specification" NLRI type that may include several
   components such as destination prefix, source prefix, protocol,
   ports, etc.  This NLRI is treated as an opaque bit string prefix by
   BGP.  Each bit string identifies a key to a database entry with which
   a set of attributes can be associated.

It’s also true that rfc5575bis retracts it. Appendix B makes it clear this wasn’t an accident:

      Section 1<https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-1> introduces the Flow Specification NLRI.  In [RFC5575<https://tools.ietf.org/html/rfc5575>]
      this NLRI was defined as an opaque-key in BGPs database.  This
      specification has removed all references to an opaque-key
      property.  BGP implementations are able to understand the NLRI
      encoding.

I haven’t gone back to check, but given that this was made so explicit in the draft, I’m going to suppose that it was discussed in the WG before the WGLC concluded, so I’m not very excited to re-litigate it.

I do think that it would be good to commence work on FSv2 soon, while we still have this experience fresh in our minds.

—John

On Sep 29, 2020, at 2:57 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jakob,

Today in RFC5575 NLRI is clearly defined as a numeric value with a given length. It was by design not parsable by BGP. The entire NLRI is a key.

Now if we start to parse that value (except maybe for validation which I am also now pretty sceptical about) and dissecting part of that calling some types to be a key and some not - at min IMHO we should use different SAFI not to create complete deployment issues.

Many thx,
R.

On Tue, Sep 29, 2020 at 1:23 AM Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
Also to consider that in BGP, there are several examples of NLRI
where the NLRI key is not the whole NLRI, starting with RFC 3107,
where the label is not part of the key.

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Monday, September 28, 2020 1:44 PM
To: Christoph Loibl <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; John Scudder <jgs=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Hares Susan <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

All,

Best,
R.

Cheers Christoph

--
Christoph Loibl
[email-masked]<mailto:[email-masked]> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at<https://urldefense.com/v3/__http://www.nextlayer.at__;!!NEt6yMaO-gk!X4eMxV72EsYddrA45y5RcVvdurOK06WI3jav90JT_G28wjdKzOfMHr3s65ZeQA$>

Hi!

I think this is one of the messages:  https://mailarchive.ietf.org/arch/msg/idr/FHC-Vz26LZfam-o5Y-9-WSrEm2g/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/FHC-Vz26LZfam-o5Y-9-WSrEm2g/__;!!NEt6yMaO-gk!X4eMxV72EsYddrA45y5RcVvdurOK06WI3jav90JT_G28wjdKzOfMHr29g9EyWw$>

Thanks!

Alvaro.

   Error handling according to [RFC7606<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7606__;!!NEt6yMaO-gk!X4eMxV72EsYddrA45y5RcVvdurOK06WI3jav90JT_G28wjdKzOfMHr00REP3-Q$>] and [RFC4760<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc4760__;!!NEt6yMaO-gk!X4eMxV72EsYddrA45y5RcVvdurOK06WI3jav90JT_G28wjdKzOfMHr324tDOCw$>] applies to this

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 29 Sep 2020 17:24:00 +0200

Hi John,

I admit I have missed that change or even if I noticed it apparently I did
not realize the magnitude and consequences this change brings.

IMHO it would be a fine change for FSv2 however I am quite sceptical for
rolling it into 5575bis.

Many thx,
R.

On Tue, Sep 29, 2020 at 5:20 PM John Scudder <[email-masked]> wrote:

>       Section 1 <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-1> introduces the Flow Specification NLRI.  In [RFC5575 <https://tools.ietf.org/html/rfc5575>]
> I haven’t gone back to check, but given that this was made so explicit in
> the draft, I’m going to suppose that it was discussed in the WG before the
> WGLC concluded, so I’m not very excited to re-litigate it.
>
> I do think that it would be good to commence work on FSv2 soon, while we
> still have this experience fresh in our minds.
>
> —John
>
> On Sep 29, 2020, at 2:57 AM, Robert Raszuk <[email-masked]> wrote:
>
>
>
> Hi Jakob,
>
> Now if we start to parse that value (except maybe for validation which I
> am also now pretty sceptical about) and dissecting part of that calling
> some types to be a key and some not - at min IMHO we should use different
> SAFI not to create complete deployment issues.
>
> Many thx,
> R.
>
>
>> *From:* Idr <[email-masked]> *On Behalf Of *Robert Raszuk
>> John Scudder <jgs=[email-masked]>;
>> [email-masked]; Hares Susan <[email-masked]>
>> <https://urldefense.com/v3/__http://www.nextlayer.at__;!!NEt6yMaO-gk!X4eMxV72EsYddrA45y5RcVvdurOK06WI3jav90JT_G28wjdKzOfMHr3s65ZeQA$>
>>
>>
>>
>>
>>
>>
>>
>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/FHC-Vz26LZfam-o5Y-9-WSrEm2g/__;!!NEt6yMaO-gk!X4eMxV72EsYddrA45y5RcVvdurOK06WI3jav90JT_G28wjdKzOfMHr29g9EyWw$>
>>
>>
>>
>>
>>    Error handling according to [RFC7606 <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7606__;!!NEt6yMaO-gk!X4eMxV72EsYddrA45y5RcVvdurOK06WI3jav90JT_G28wjdKzOfMHr00REP3-Q$>] and [RFC4760 <https://urldefense.com/v3/__https://tools.ietf.org/html/rfc4760__;!!NEt6yMaO-gk!X4eMxV72EsYddrA45y5RcVvdurOK06WI3jav90JT_G28wjdKzOfMHr324tDOCw$>] applies to this
>>

---

From: John Scudder <[email-masked]>
Date: Tue, 29 Sep 2020 15:26:54 +0000

Speaking as an individual contributor, I find Bruno’s argument convincing.

Speaking as co-chair, the main thing I want is for the final document to be as unambiguous as it can be about important points like this. I think the conversation so far provides good evidence that knowledgeable and reasonable people can and will disagree about what the document says to do, which is not ideal in a spec.

I suppose one can argue that if one implementation chooses the treat-as-withdraw behavior, and another chooses the session reset behavior, the two are still interoperable and the market can apply corrective pressure as needed. But that’s not a preferred way to do it.

—John

On Sep 29, 2020, at 6:14 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Jeff, Alvaro, all

[….]

[Bruno]
OK for the example.

-- Jeff

From: Alvaro Retana [mailto:[email-masked]]
Sent: Monday, September 28, 2020 9:16 PM
To: DECRAENE Bruno TGI/OLN <[email-masked]<mailto:[email-masked]>>; John Scudder <jgs=[email-masked]<mailto:jgs=[email-masked]>>; Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Cc: Hares Susan <[email-masked]<mailto:[email-masked]>>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi!

I think this is one of the messages:  https://mailarchive.ietf.org/arch/msg/idr/FHC-Vz26LZfam-o5Y-9-WSrEm2g/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/FHC-Vz26LZfam-o5Y-9-WSrEm2g/__;!!NEt6yMaO-gk!X6MVqxYzZKOBij2CXmOCozwSH0sadCC07WqDYxq2kR1EsveHDshZD6-8u-ugOQ$>

Thanks!

Alvaro.

   Error handling according to [RFC7606<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7606__;!!NEt6yMaO-gk!X6MVqxYzZKOBij2CXmOCozwSH0sadCC07WqDYxq2kR1EsveHDshZD69d6BidTQ$>] and [RFC4760<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc4760__;!!NEt6yMaO-gk!X6MVqxYzZKOBij2CXmOCozwSH0sadCC07WqDYxq2kR1EsveHDshZD68YbtIlbw$>] applies to this

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 29 Sep 2020 15:31:33 +0000

This may have had something to do with getting an interface specific flowspec. There was debate about putting the interface specification as part of the NLRI or part of the attributes. My memory is leaking.

Regards,
Jakob.

On Sep 29, 2020, at 8:20 AM, John Scudder <[email-masked]> wrote:

 Hi Robert,

—John

Hi Jakob,

Many thx,
R.

Regards,
Jakob.

All,

Best,
R.

Cheers Christoph

Hi!

Thanks!

Alvaro.

---

From: Christoph Loibl <[email-masked]>
Date: Tue, 29 Sep 2020 17:34:05 +0200

Hi,

This has been a very very long discussion on the mailing-list, at meetings, … . And there was a very strong consensus for removing the opaque property (I was trying to keep it as it was but the WG decided to go that path). The good point: All implementations that I know of are implemented in a way that they do *not* treat FS NLRI as opaque key (at least they reset the session when they encounter a unknown FS component - something that is a good indication that they are not treating the NLRI as opaque key). Maybe for a good reason?

I do not think it makes any sense to change this back and forth every six month. -> go for FS2.0 

Cheers Christoph

> On 29.09.2020, at 17:24, Robert Raszuk <[email-masked]> wrote:
> 
> Hi John,
> 
> On Tue, Sep 29, 2020 at 5:20 PM John Scudder <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Robert,
>> 
>>      Section 1 <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-1 <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-1>> introduces the Flow Specification NLRI.  In [RFC5575 <https://tools.ietf.org/html/rfc5575 <https://tools.ietf.org/html/rfc5575>>]

---

From: John Scudder <[email-masked]>
Date: Tue, 29 Sep 2020 15:42:50 +0000

(Co-chair hat is on)

Yes, agreed. This is not subject to re-litigation now, we are trying to clarify things if needed, but not change decisions that were made.

Thanks,

—John

On Sep 29, 2020, at 11:34 AM, Christoph Loibl <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Cheers Christoph

--
Christoph Loibl
[email-masked]<mailto:[email-masked]> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at<https://urldefense.com/v3/__http://www.nextlayer.at__;!!NEt6yMaO-gk!WyyQ8EV6anHYW6a37jYyK1ivWQkr7vAVMIS41XLScR0HkQrPY7PwaV9mHCVxIA$>

On 29.09.2020, at 17:24, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

Many thx,
R.

On Tue, Sep 29, 2020 at 5:20 PM John Scudder <[email-masked]<mailto:[email-masked]>> wrote:

Hi Robert,

It’s also true that rfc5575bis retracts it. Appendix B makes it clear this
wasn’t an accident:

     Section 1 <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26#section-1<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-26*section-1__;Iw!!NEt6yMaO-gk!WyyQ8EV6anHYW6a37jYyK1ivWQkr7vAVMIS41XLScR0HkQrPY7PwaV-WOlQhkQ$>> introduces the Flow Specification NLRI.  In [RFC5575 <https://tools.ietf.org/html/rfc5575<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc5575__;!!NEt6yMaO-gk!WyyQ8EV6anHYW6a37jYyK1ivWQkr7vAVMIS41XLScR0HkQrPY7PwaV_U8CO1xA$>>]
     this NLRI was defined as an opaque-key in BGPs database.  This
     specification has removed all references to an opaque-key
     property.  BGP implementations are able to understand the NLRI
     encoding.

—John

---

From: Christoph Loibl <[email-masked]>
Date: Tue, 29 Sep 2020 20:04:06 +0200

Hi all,

> On 29.09.2020, at 17:42, John Scudder <[email-masked]> wrote:
> (Co-chair hat is on)
> 

Which brings me back to the point where this discussion started:

John suggested to extend that sentence from the doc:

OLD:

NEW:

   A NLRI value not encoded as specified here,
   including an NLRI that contains an unknown component type,
   is considered malformed and error handling according to 
   Section 10 is performed.

He also pointed out that a malformed NLRI (even when considering RFC7606) should lead to a session reset. If we want to make that even more clear (and based on all the discussion about opaque, non-opaque on the list (over months - if not years) this had very strong support) we can put it into the draft explicitly:

OLD: 
10.  Error Handling

   Error handling according to [RFC7606] and [RFC4760] applies to this
   specification.

   This document introduces Traffic Filtering Action Extended
   Communities.  Malformed Traffic Filtering Action Extended Communities
   in the sense of [RFC7606] Section 7.14. are Extended Community values
   that cannot be decoded according to Section 7 of this document.

NEW:
10.  Error Handling

   Error handling according to [RFC7606] and [RFC4760] applies to this
   specification. It needs to be pointed out that a malformed NLRI even
   when considering RFC7606 leads to a session reset.

   This document introduces Traffic Filtering Action Extended
   Communities.  Malformed Traffic Filtering Action Extended Communities
   in the sense of [RFC7606] Section 7.14. are Extended Community values
   that cannot be decoded according to Section 7 of this document.

I agree with the change since I want to make it as clear as possible, maybe someone can come up with a better solution/change to clarify what the WG already agreed on.

Cheers Christoph

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 30 Sep 2020 07:53:25 +0000

Hi Robert and Jakob,

Please note that section 3 of 5575bis says:

“BGP itself treats the NLRI as a key to an entry in its databases. Entries that are placed in the Loc-RIB are then associated with a given set of semantics, which is application dependent.”

Although comparing with RFC5575 the word “opaque” is removed, the NLRI is still treated as the key.

Best regards,
Jie

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, September 29, 2020 2:58 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; John Scudder <jgs=[email-masked]>; [email-masked]; [email-masked]; Hares Susan <[email-masked]>
Subject: Re: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi Jakob,

Many thx,
R.

Regards,
Jakob.

All,

Best,
R.

Cheers Christoph

Hi!

Thanks!

Alvaro.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 30 Sep 2020 18:34:14 +0000

In that case, I'm fine with it.
I personally prefer that BGP be nothing more than a transport for flowspec.
That makes it possible to change the flowspec updates without modifying BGP
or upgrading speakers that don't install the flowspecs themselves.

Regards,
Jakob.

From: Dongjie (Jimmy) <[email-masked]>
Sent: Wednesday, September 30, 2020 12:53 AM
To: Robert Raszuk <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; John Scudder <jgs=[email-masked]>; [email-masked]; [email-masked]; Hares Susan <[email-masked]>
Subject: RE: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi Robert and Jakob,

Best regards,
Jie

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, September 29, 2020 2:58 PM
To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>; John Scudder <jgs=[email-masked]<mailto:jgs=[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Hares Susan <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi Jakob,

Many thx,
R.

Regards,
Jakob.

All,

Best,
R.

Cheers Christoph

Hi!

Thanks!

Alvaro.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 30 Sep 2020 20:51:17 +0200

Hi Jakob,

> I personally prefer that BGP be nothing more than a transport for
flowspec.

100%

- - -

Can you take a look if XR, XE & NX all parse today's shipping FS NLRIs and
validate each type and when applicable length to be "valid" ?

What all three of those implementations do when they:

a) run into the case of unknown type ?

b) run into the case of invalid value of any type carried inside the NLRI ?

Many thx,
R.

On Wed, Sep 30, 2020 at 8:34 PM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Dongjie (Jimmy) <[email-masked]>
> *Sent:* Wednesday, September 30, 2020 12:53 AM
> *To:* Robert Raszuk <[email-masked]>; Jakob Heitz (jheitz) <
> [email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>; John Scudder <jgs=
> [email-masked]>; [email-masked];
> [email-masked]; Hares Susan <[email-masked]>
> *Subject:* RE: [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth
> fixing?
>
>
>
> Hi Robert and Jakob,
>
>
>
> “BGP itself treats the NLRI as a key to an entry in its databases. Entries
> that are placed in the Loc-RIB are then associated with a given set of
> semantics, which is application dependent.”
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Robert Raszuk
> *Sent:* Tuesday, September 29, 2020 2:58 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>; John Scudder <
> jgs=[email-masked]>; [email-masked];
> [email-masked]; Hares Susan <[email-masked]>
> been accepted, so ‘treat-as-withdraw’  could even be replaced with ‘ignore
> ’. But I’m _*not*_ calling for this).
>
>    *it must be noted, works out to be the same as skipping over the NLRI).*
>
>
>
>