Re: [Idr] locator length : draft-li-idr-flowspec-srv6

Joel Halpern Direct <jmh.direct@joelhalpern.com> Fri, 12 March 2021 14:58 UTC

Return-Path: <jmh.direct@joelhalpern.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 0E94D3A1157 for <idr@ietfa.amsl.com>; Fri, 12 Mar 2021 06:58:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 i--ca7F7mdKi for <idr@ietfa.amsl.com>; Fri, 12 Mar 2021 06:58:04 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 4EBA13A114B for <idr@ietf.org>; Fri, 12 Mar 2021 06:58:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DxppM6gWKz6G9Q7; Fri, 12 Mar 2021 06:58:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1615561083; bh=q2ygOhG9SeCa3IQKIcmpc2qQ37nVwtLl3UL1YaETaHA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZUo0BDmn9gBpU4FdJMisYXyDNCOl4MiBC1ue78YSbMno4w/mHXdqqTd46cAB2mDbF VyIHTfIrYyke01waQhYNnoqC2jK8ccaj4r3cfnDK7JeDpmOG5OIZW6Yx8h2qJ37SBm F3gW8qydkN73LeNZc6agr2iJiI4NCVpZ6vGGr2uo=
X-Quarantine-ID: <2zRDjMTbU8eD>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4DxppM0hkQz6G7wR; Fri, 12 Mar 2021 06:58:02 -0800 (PST)
To: Huaimo Chen <huaimo.chen@futurewei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: "idr@ietf.org" <idr@ietf.org>, Lizhenbin <lizhenbin@huawei.com>
References: <MN2PR13MB40876899246382264C393D06F26F9@MN2PR13MB4087.namprd13.prod.outlook.com>
From: Joel Halpern Direct <jmh.direct@joelhalpern.com>
Message-ID: <89430d8e-58c1-7854-27a5-b01a4cf9c43f@joelhalpern.com>
Date: Fri, 12 Mar 2021 09:58:00 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <MN2PR13MB40876899246382264C393D06F26F9@MN2PR13MB4087.namprd13.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/s4PlAu6735l7m7zcFqMAlr34sxE>
Subject: Re: [Idr] locator length : draft-li-idr-flowspec-srv6
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, 12 Mar 2021 14:58:10 -0000

An operator can assign B::/48 and C::?46  for Locators.  Sure, it would 
usually be a single prefix with a single length.  But that is not required.

When one is examining the LOC, sure, you can use the value length to 
handle it.
But the way the mechanism is described, one could try to check just the 
FUNC bits, without matching the LOC.
First, that has the problem of needing exogenous information about the 
LOC length.

And it is actually worse than that.  Testing the FUNC bits of the 
destination field of an IP packet without checking the LOC bits is 
actually meaningless.  You don't even know if the DA is an SRv6 SID.

An yet further, there is no requirement that the encoding of the FUNC in 
different SIDs uses the same value representation.  The standardized 
values are for advertising in routing protocols, not for the packets.

Net: I don't think having the field identification works.

Yours,
Joel

On 3/12/2021 9:51 AM, Huaimo Chen wrote:
> Hi Joel,
> 
>      Thank you very much for your comment during the IETF 110.
> 
>      Regarding to the lengths of locator(LOC)s and function(FUNCT)s in 
> SIDs,
> RFC8986 says that the locator length, is flexible, and an operator is free
> to use the locator length of their choice. This seems indicating that the
> operator can select the length for the locator. After their selection, the
> the locator length is determined/fixed. This is illustrated by examples
> in RFC8986.
> 
>      One example in the beginning of section 3.2 is as follows:
>         For example, a network operator may:
>            Assign block B::/48 to the SR domain
>            Assign a unique B:N::/64 block to each SRv6-enabled node in 
> the domain.
> After this assignment, the length of the locators of the SIDs in the domain
> is 64 bits.
> 
>      In the end of section 3.2, the text shows the Function fields of SIDs.
> The length of function(FUNCT)s is 16 bits.
> 
>      When a SID is used in the domain, its locator length and function 
> length
> should have been determined.
> 
>      When an operator configures a SRv6 flow specification, involving
> a SID or a group of SIDs, s/he should have known the locator length and
> function length in the SID(s).
> 
> Best Regards,
> Huaimo