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

[Susan Hares <[e-mail]>]

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]] 
Sent: Tuesday, September 29, 2020 2:04 PM
To: John Scudder
Cc: Robert Raszuk; Jakob Heitz (jheitz); idr@ietf. org; [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
[e-mail] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at