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

[Susan Hares <[e-mail]>]

John: 

 

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

 

Cheerily, Susan Hares 

 

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

 

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 <[e-mail]> wrote:

 

[External Email. Be cautious of content]


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:[e-mail]> mailto:[e-mail]]
Sent: Tuesday, September 29, 2020 2:04 PM
To: John Scudder
Cc: Robert Raszuk; Jakob Heitz (jheitz); idr@ietf. org;  <mailto:[e-mail]> [e-mail];  <mailto:[e-mail]> [e-mail]; 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 <[e-mail]> 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
 <mailto:[e-mail]> [e-mail] | 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$