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

From: "Susan Hares" <[email-masked]>
Date: Fri, 2 Oct 2020 16:57:32 -0400

John
<WG-chair hat off> 
<co-author hat on>  

On Tuesday 9/29/2020, Christoph sent this request to confirm these are the changes for the document. 

The only other changes suggested was a clarification to: 

4.2.2.12 Type 12 - Fragment

Old text: 
/
   IsF -  Is a fragment - match if [RFC0791] IP Header Fragment Offset
      is not 0
/
New text: 
   IsF -  Is a fragment other than the first - match if [RFC0791] IP Header Fragment Offset
      is not 0
/

Please confirm that we have all the changes between these two. 

I think it time to close this discussion.  Christoph has agreed up provided an updated draft (-27) so the RFC editor can published the document. 

The rest of the issues point up the need to begin Flow-spec v2 with TLV and other improvements. 

Thank you, Sue 

-----Original Message-----
From: Christoph Loibl [mailto:[email-masked]] 
Sent: Tuesday, September 29, 2020 2:04 PM
To: John Scudder
Cc: Robert Raszuk; Jakob Heitz (jheitz); idr@ietf. org; [email-masked]; [email-masked]; Hares Susan
Subject: Re: [BULK] [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Hi all,

> On 29.09.2020, at 17:42, John Scudder <[email-masked]> wrote:
> (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

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

John suggested to extend that sentence from the doc:

OLD:

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

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

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

---

From: John Scudder <[email-masked]>
Date: Tue, 6 Oct 2020 22:47:24 +0000

Hi Sue, Christoph, and all,

I think you are right that between these two we have captured all the changes for which we have unambiguous WG consensus. I wish we could also fix the error handling ambiguity, but I just don’t see how we could do that without pulling the document all the way back to the WG and reopening the topic in earnest. I don’t think the benefit for doing that justifies the demands it would place on the authors, so let’s proceed forward with the document with the small and noncontroversial changes only.

Thanks,

—John

On Oct 2, 2020, at 4:57 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

[External Email. Be cautious of content]

John
<WG-chair hat off>
<co-author hat on>

Old text:
/

Thank you, Sue

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

Hi all,

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

Thanks,

—John

OLD:

NEW:

OLD:
10.  Error Handling

NEW:
10.  Error Handling

Cheers Christoph

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 7 Oct 2020 12:49:08 -0400

John: 

Hopefully, we can fix this text in a flow specification version 2. 

Cheerily, Susan Hares 

From: Idr [mailto:[email-masked]] On Behalf Of John Scudder
Sent: Tuesday, October 6, 2020 6:47 PM
To: Hares Susan
Cc: idr@ietf. org; Robert Raszuk; [email-masked]; [email-masked]
Subject: Re: [Idr] [BULK] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

Thanks,

—John

On Oct 2, 2020, at 4:57 PM, Susan Hares <[email-masked]> wrote:

John
<WG-chair hat off>
<co-author hat on>

Old text:
/

Thank you, Sue

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

Hi all,

Thanks,

—John

OLD:

NEW:

OLD:
10.  Error Handling

NEW:
10.  Error Handling

Cheers Christoph

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

---

From: Christoph Loibl <[email-masked]>
Date: Thu, 15 Oct 2020 10:45:30 +0200

Hi IDR;

I uploaded the -27 of the document. Covering the text changes as requested by John and Sue.

Cheers Christoph

> On 02.10.2020, at 22:57, Susan Hares <[email-masked]> wrote:
> 
> John
> <WG-chair hat off> 
> <co-author hat on>  
>

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 15 Oct 2020 15:50:33 +0200

John:

Are we ready to go?   I’ll wait for your positive confirmation.

Thanks!

Alvaro.

On October 15, 2020 at 4:46:05 AM, Christoph Loibl ([email-masked]) wrote:

Hi IDR;

I uploaded the -27 of the document. Covering the text changes as requested
by John and Sue.

Cheers Christoph

---

From: John Scudder <[email-masked]>
Date: Thu, 15 Oct 2020 13:57:43 +0000

On Oct 15, 2020, at 9:50 AM, Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:

Yes, ready.

Thanks,

—John

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 28 Oct 2020 16:58:09 -0400

I have been unable to follow IETF properly in recent times, so forgive this
stale comment for the archive:

On Tue, Sep 29, 2020 at 03:31:33PM +0000, Jakob Heitz (jheitz) wrote:
> 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.

When the authors of the interface-set draft were discussing encoding
considerations, we had two things that came out of that discussion relevant
to this thread:

1. We were aware that implementations that didn't understand a new component
type may have difficulties enforcing the intent of the interface-set
scoping.  Given this text from RFC 5575, that's potentially problematic:

:   If a given component type within a prefix in unknown, the prefix in
:   question cannot be used for traffic filtering purposes by the
:   receiver

At that time, the magnitude of the issues surrounding extending flowspec
weren't totally understood.

2. The inter-domain considerations for interface-set group ids was
problematic.  Such group ids were likely to be applicable to one domain and
may not be useful inter-domain; i.e. customer to ISP.  Since there was a
likelihood of needing to be able to change the mappings somewhat
dynamically, this was more applicable to a path attribute that could be
readily modified.  In this case we chose extended communities.

There is also the problem that if it were encoded in the NLRI, that would
mean that the NLRI itself would need a rewrite when crossing such
boundaries.  Our general experience with BGP over the years usually suggests
that this is a recipe for disaster.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 28 Oct 2020 17:02:24 -0400

Again, for the archive.

On Wed, Sep 30, 2020 at 08:51:17PM +0200, Robert Raszuk wrote:
> 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 ?

A poll some time back when we were discussing the change to remove the
"opaque" behavior of several implementations suggested that no one dealt
with unknown components without a session reset.  This reduced the concerns
at the time that we were making a change that left implementations of -bis
as non-comformant.

This poll was certainly not comprehensive of all implementation, nor done in
such a way that the results should be posted officially.  An implementation
report might be appropriate.

-- Jeff