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

Susan Hares <shares@ndzh.com> Fri, 02 October 2020 20:57 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3903A16DA; Fri, 2 Oct 2020 13:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Level:
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIE-AkusDagc; Fri, 2 Oct 2020 13:57:43 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC48F3A16D8; Fri, 2 Oct 2020 13:57:42 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.25.164.118;
From: "Susan Hares" <shares@ndzh.com>
To: "'Christoph Loibl'" <c@tix.at>, "'John Scudder'" <jgs@juniper.net>
Cc: "'Robert Raszuk'" <robert@raszuk.net>, "'Jakob Heitz \(jheitz\)'" <jheitz@cisco.com>, "'idr@ietf. org'" <idr@ietf.org>, <draft-ietf-idr-rfc5575bis@ietf.org>, <bruno.decraene@orange.com>
References: <303E54F6-833A-4458-B3E6-DE90E7CA121B@juniper.net> <22341_1601052988_5F6E213C_22341_268_1_53C29892C857584299CBF5D05346208A48F82C17@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <DEE76A95-339B-433C-BD46-AD0243F72FBE@juniper.net> <3366_1601300732_5F71E8FC_3366_6_3_53C29892C857584299CBF5D05346208A48F86028@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <21B4E52C-38F4-4C94-985C-8C1DF88F4A92@juniper.net> <CAMMESsxG+ASdax1USizop-1bzYELcSdvND-f3RNEJ78zDUPrng@mail.gmail.com> <A9128F3D-948E-4F22-B000-7B470AFAC219@tix.at> <CAOj+MMESP=1EtTcuptE9xdyb+g36kDiD4sH6wSLezeZX74v2vw@mail.gmail.com> <BYAPR11MB32079E5730B9B170C1ADF7E1C0350@BYAPR11MB3207.namprd11.prod.outlook.com> <CAOj+MMFrFhwF1D=j1KS5wJXzc-ULEA6Ne-n296LYvit5fKUB+w@mail.gmail.com> <57A5696C-4AD1-46E3-85C8-21867D821A3D@juniper.net> <CAOj+MMENOtZ2tEJYRUq8EXizJNZ75+r3YWFDp7yOBka_hgj-UA@mail.gmail.com> <493732DD-ADAE-44F2-A5BE-2AE7FEAA3222@tix.at> <E3FC039D-83DD-4997-AFDE-EC7DB3B0744B@juniper.net> <1A29EA15-3585-4F26-8AAC-BD926FA2CD17@ tix.at>
In-Reply-To: <1A29EA15-3585-4F26-8AAC-BD926FA2CD17@tix.at>
Date: Fri, 2 Oct 2020 16:57:32 -0400
Message-ID: <02d801d698fe$a6683290$f33897b0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJFO/98nG4CXpcqgpkjUdeb0RRdigIhl7wCAmAFbBACjYZjawGNusElAavd4aUA2w2+NQKIG+yUAJ6HCjABzify9wFzYpbRAXGVW7cA18zMzQEj13S7AoyDjIGn602JIA==
Content-Language: en-us
X-Antivirus: AVG (VPS 201001-2, 10/01/2020), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/JeBg3MWQiIp3pZctQoiLzn7jkCA>
Subject: Re: [Idr] [BULK] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2020 20:57:45 -0000

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:c@tix.at] 
Sent: Tuesday, September 29, 2020 2:04 PM
To: John Scudder
Cc: Robert Raszuk; Jakob Heitz (jheitz); idr@ietf. org; draft-ietf-idr-rfc5575bis@ietf.org; bruno.decraene@orange.com; 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 <jgs@juniper.net> 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
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at