Re: [Idr] Question about draft-haas-flowspec-capability-bits-02

Jeffrey Haas <jhaas@pfrc.org> Tue, 22 June 2021 12:12 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 4325D3A22C0; Tue, 22 Jun 2021 05:12:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XhbZrsNCffuC; Tue, 22 Jun 2021 05:12:43 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 66FFF3A22C6; Tue, 22 Jun 2021 05:12:43 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id B64261E45C; Tue, 22 Jun 2021 08:38:28 -0400 (EDT)
Date: Tue, 22 Jun 2021 08:38:28 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Linda Dunbar <ldunbar@futurewei.com>
Cc: "draft-haas-flowspec-capability-bits@ietf.org" <draft-haas-flowspec-capability-bits@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Message-ID: <20210622123828.GB23751@pfrc.org>
References: <CO1PR13MB4920AD5CA604B232E294B978A90A9@CO1PR13MB4920.namprd13.prod.outlook.com> <CO1PR13MB4920A5147F8441F1FD0FBD46A90A9@CO1PR13MB4920.namprd13.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CO1PR13MB4920A5147F8441F1FD0FBD46A90A9@CO1PR13MB4920.namprd13.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-u1dWdiFC781wMYkR9hNw6cfHvQ>
Subject: Re: [Idr] Question about draft-haas-flowspec-capability-bits-02
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, 22 Jun 2021 12:12:45 -0000

Linda,

On Mon, Jun 21, 2021 at 08:51:41PM +0000, Linda Dunbar wrote:
> Jeff,
> 
> One more question:
> Page 3 first paragraph says that "this is due to the lack of a mandatory length element for the components in the NLRI".
> 
> But Section 4.2.1.2 of the RFC8555 Figure 3 shows that the Len can be encoded in the bits. Are you talking about a different "length"?

If you observe the various forms of "length" in RFC 8955 section 4, you'll
see that in some cases it's an explicit one octet length (prefixes) mixed
with numeric op or bitmask op.  The latter two forms provide for a variable
length component type with variable width values.

If I introduce a component 14, how do I know what scheme it uses for length
calculations?  

The implementation must KNOW by the spec.  It is not carried in the
protocol consistently.  That is the problem.

-- Jeff