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

Christoph Loibl <c@tix.at> Tue, 29 September 2020 18:04 UTC

Return-Path: <c@tix.at>
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 2C1C23A104E; Tue, 29 Sep 2020 11:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at
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 hxnax0o4RF3s; Tue, 29 Sep 2020 11:04:17 -0700 (PDT)
Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332CF3A104A; Tue, 29 Sep 2020 11:04:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=JdX/zpUkWh4GUZgvWuTAEbDnVnJgl2f7tg9Q2qIIA1g=; b=lwNlhbd3zfALV2gTynh/aFln49 shD8JmgQn0cdT/vPXf+I0kZgy9y2U/Agn04K52aF8RLYMZOVU5ylDJQJvNk830XgKquvV0aPapdms E1u/QCyU20v+FjPQwrtdi3989EAevuFZ9OZLp9pcdv+uEUh6py5hIzEtdSmn2a8fy+lITeh0apTqu GH1q9DnjOrIXjX+/WGbGWKqtrdgaxZ+RWtM54hmwLRg1NxFhTbBuxXx8Xn1N4IVq/vNxycYCmrsnh YtbJTsxx+dxuBZf5LKAjiyUt1b8v7HVkPmRILJlOxJ7kYTik+OTUlOui8pZswDOZBibQ0CD/BWTLH t/TmV3Xg==;
Received: from 80-110-113-91.cgn.dynamic.surfer.at ([80.110.113.91] helo=[192.168.66.207]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <c@tix.at>) id 1kNJyx-0003RB-Pj; Tue, 29 Sep 2020 20:04:08 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Christoph Loibl <c@tix.at>
In-Reply-To: <E3FC039D-83DD-4997-AFDE-EC7DB3B0744B@juniper.net>
Date: Tue, 29 Sep 2020 20:04:06 +0200
Cc: Robert Raszuk <robert@raszuk.net>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-rfc5575bis@ietf.org" <draft-ietf-idr-rfc5575bis@ietf.org>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, Hares Susan <shares@ndzh.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A29EA15-3585-4F26-8AAC-BD926FA2CD17@tix.at>
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>
To: John Scudder <jgs@juniper.net>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Tue, 29 Sep 2020 20:04:07 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/e71ZjdYhxVlNrpX5JmbIEItu3Lg>
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: Tue, 29 Sep 2020 18:04:20 -0000

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