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

Jeffrey Haas <jhaas@pfrc.org> Tue, 22 June 2021 18:11 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 53EBA3A1101; Tue, 22 Jun 2021 11:11:11 -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 Fc1Iaa3gn19y; Tue, 22 Jun 2021 11:11:08 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 696F63A10FE; Tue, 22 Jun 2021 11:11:08 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 975221E464; Tue, 22 Jun 2021 14:36:54 -0400 (EDT)
Date: Tue, 22 Jun 2021 14:36:54 -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: <20210622183654.GA5863@pfrc.org>
References: <CO1PR13MB4920AD5CA604B232E294B978A90A9@CO1PR13MB4920.namprd13.prod.outlook.com> <CO1PR13MB4920A5147F8441F1FD0FBD46A90A9@CO1PR13MB4920.namprd13.prod.outlook.com> <20210622123828.GB23751@pfrc.org> <CO1PR13MB4920075B30135CB1E679D879A9099@CO1PR13MB4920.namprd13.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CO1PR13MB4920075B30135CB1E679D879A9099@CO1PR13MB4920.namprd13.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/pSIZd1vO9UenS-sEUl1N3n4okcY>
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 18:11:11 -0000

Linda,

On Tue, Jun 22, 2021 at 02:15:24PM +0000, Linda Dunbar wrote:
> Based on the TYPE, the receiver can get the "length" field properly. Why it is a problem? 

Because for a new component type, you don't know where length is for that
type, nor how long.

> Type 1 and Type 2 have Length Field. For the Types using "Numeric Operator" or "Bitmask Operator", there is "Length" field as well. 
> 
> If I introduce a new type, Type 14, can I just use the format as Type 1 or Type 2? 

We can do anything we like as long as we have rules for it.  Right now,
flowspec doesn't have consistent rules among the types.  We have two styles.

If this were a normal TLV protocol, length wouldn't be arbitrarily
specified.  That's one of the motivations for flowspec v2.  And, similarly,
it's what PCEP decided to do when it leveraged flowspec encodings.

The capability bits proposal attempts the middle road: An implementation
must KNOW the rule for a component type.  This lets two implementations
disclose to each other what types they understand.

-- Jeff