Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17 -> Updated Version -18 and Flowspec v6

Christoph Loibl <c@tix.at> Sat, 21 December 2019 10: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 CE989120A3D; Sat, 21 Dec 2019 02:04:03 -0800 (PST)
X-Quarantine-ID: <wkb9KU9HQ7DN>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): X-Spam-Report: ....\n\tIt is supposed to >>> \342\200\234ignore\342\200\235 the[...]
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 wkb9KU9HQ7DN; Sat, 21 Dec 2019 02:04:01 -0800 (PST)
Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B034120A3B; Sat, 21 Dec 2019 02:04:00 -0800 (PST)
Received: from 80-110-104-164.cgn.dynamic.surfer.at ([80.110.104.164] helo=[192.168.66.207]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1iibRv-0007Dq-CL; Sat, 21 Dec 2019 10:53:27 +0100
From: Christoph Loibl <c@tix.at>
Message-Id: <51657538-DD97-497D-9D9E-D9ACDFBBB0C1@tix.at>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3AB36DA8-194A-4B56-BCD9-1922B150B21C"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Sat, 21 Dec 2019 11:03:55 +0100
In-Reply-To: <CAMMESsz+cLgPxZeQHNfDuZpiSY992Vm5YnEzc9LK1aOSjrA8rw@mail.gmail.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, idr-chairs@ietf.org, "idr@ietf. org" <idr@ietf.org>, draft-ietf-idr-rfc5575bis@ietf.org
To: Alvaro Retana <aretana.ietf@gmail.com>
References: <CAMMESsxHXUB_jQk7E9FkeNef2C7DDcbiEvnROFdbEjAVtMqcFA@mail.gmail.com> <F9C8F51F-FB7C-4530-93EA-BF188D007C98@tix.at> <CAMMESsxDYo2JPQ=tw3m9EQrDwyGCjWMem_oiH4WZy4FHRBOFtQ@mail.gmail.com> <20191217220936.GE4858@pfrc.org> <44C0D224-1C71-4B88-B3D9-A12F417AD3F0@tix.at> <20191218121235.GF4858@pfrc.org> <CAMMESsz+cLgPxZeQHNfDuZpiSY992Vm5YnEzc9LK1aOSjrA8rw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nGdI8-L9Bm4SoqzSjOMa1QMLfBM>
Subject: Re: [Idr] AD Review of draft-ietf-idr-rfc5575bis-17 -> Updated Version -18 and Flowspec v6
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: Sat, 21 Dec 2019 10:04:04 -0000

Alvaro,

> On 18.12.2019, at 17:17, Alvaro Retana <aretana.ietf@gmail.com> wrote:
> 
>>> In case of an unknown flowspec component the parser can run until decoding
>>> the component type (always the first byte of the component). When it reads
>>> a unknown type-value it can easily jump over the remaining bytes of the
>>> entire NLRI (the length of the the complete NLRI is encoded in the first
>>> bytes of the NLRI) without needing to understand what is in there, because
>>> it should treat it as withdraw. I do not see the problem. It is supposed to
>>> “ignore” the entire NLRI not only a single component of it.
> 
> Christoph: It seems to me that we're getting to the same behavior: I
> call it "discard", you call it "treat it as withdraw...“ignore”".
> While discarding, ignoring and treat-as-withdraw are different things,
> the effect seems to be the same: we won't use the NLRI.  We can find
> the right words...  Do you also think we're going in the same
> direction?

I agree. I will need to collect the comments and think that I can come up with something that is acceptable while still giving some certain degree of flexibility to protocol extensions. 

I already started working on all the the issues in the document you pointed out on github:

	https://github.com/stoffi92/rfc5575bis <https://github.com/stoffi92/rfc5575bis>

Expect a new -19 to be ready by the end of January, maybe a little earlier.

Cheers,
Christoph

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at