Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

Peter Psenak <ppsenak@cisco.com> Wed, 31 March 2021 08:23 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1B33A1FBA; Wed, 31 Mar 2021 01:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 VGlcW_n7ryr6; Wed, 31 Mar 2021 01:23:02 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E113A1FBC; Wed, 31 Mar 2021 01:23:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3481; q=dns/txt; s=iport; t=1617178982; x=1618388582; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=abKStOlzpyntv+pqSH+g4nPbd96NsO6IyH9KzgZkuNI=; b=GV5wlHCIopmpp6EiAT8GRb4R8TdRHl2f9UB4656FgK38DGmibakO6sTx eONAJZjK5MKsQBHVbpTfK1OUVR+P8qhDAqLRXXNcDPCOvU9fU0drMCgUL lO4rKTlkk+b4+p03AvUBUUHwo2yu9d35D8wpOem/caDWSFV1zCVBBKYqn 4=;
X-IronPort-AV: E=Sophos;i="5.81,293,1610409600"; d="scan'208";a="34580734"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Mar 2021 08:22:59 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 12V8MxOp003362; Wed, 31 Mar 2021 08:22:59 GMT
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-lsr-isis-srv6-extensions@ietf.org" <draft-ietf-lsr-isis-srv6-extensions@ietf.org>
Cc: "lsr@ietf.org" <lsr@ietf.org>, John Scudder <jgs@juniper.net>, Christian Hopps <chopps@chopps.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>
References: <CAMMESswF4GiLTRAYeLfhkC4w9tsr2J5YaMNFSG=979Bh2tmULw@mail.gmail.com> <836ca254-1273-7339-4c7d-f92d5e17315f@cisco.com> <CAMMESszNithwE6cGy9pkyb7Zxso=BTqwyO9oza-Ascz-5dU=jg@mail.gmail.com> <cf0a8c57-96f7-2684-8752-887887dc1831@cisco.com> <CAMMESszvHXXZpqQhrqF6MFVvpukf7vt4qLVXHocWa1JAneKXRw@mail.gmail.com> <BY5PR11MB4337A9227CEC26D5058882BCC17C9@BY5PR11MB4337.namprd11.prod.outlook.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <85237a3e-43aa-1fcd-3547-735e79dfddb8@cisco.com>
Date: Wed, 31 Mar 2021 10:22:57 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <BY5PR11MB4337A9227CEC26D5058882BCC17C9@BY5PR11MB4337.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Pqx-T6j0WcMykzsgJQJrIZmljKQ>
Subject: Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Mar 2021 08:23:07 -0000

Hi Les,

On 31/03/2021 07:01, Les Ginsberg (ginsberg) wrote:
> Alvaro/Peter -
> 
> In regards to:
> 
>> ...
>>> 906 12.5. Sub-Sub-TLVs for SID Sub-TLVs
>>>
>>> 908 This document requests a new IANA registry be created under the IS-IS
>>> 909 TLV Codepoints Registry to control the assignment of sub-TLV types
>>> 910 for the SID Sub-TLVs specified in this document - Section 7.2,
>>> 911 Section 8.1, Section 8.2. The suggested name of the new registry is
>>> 912 "Sub-Sub-TLVs for SID Sub-TLVs". The registration procedure is
>>> 913 "Expert Review" as defined in [RFC8126]. The following assignments
>>> 914 are made by this document:
>>>
>>> [minor] In line with the name of other registries; suggestion:
>>> "Sub-sub-TLVs for sub-TLVs 5, 43 and 44 (SRv6 End SID , SRv6 End.X SID
>>> and SRv6 LAN End.X SID)".
>>>
>>>
>>> ##PP2
>>> I find that confusing as the sub-TLVs 5 is a locator Sub-TLV, while
>>> Sub-TLVs 43 and 44 are IS reachability sub-TLVs.
>>> What about:
>>>
>>> "Sub-Sub-TLVs for SID Sub-TLVs (SRv6 End SID, SRv6 End.X SID
>>> and SRv6 LAN End.X SID)"
>>
>> Most of the other registries include the number of the TLV.  So I
>> think it would be good to remain consistent.  Maybe we should ask the
>> current DEs: Chris, Hannes and Les.
>>
> 
> I think this is an odd situation.
> You have three new sub-TLVs:
> 
> SRv6 End SID sub-TLV(5) which is a sub-TLV of TLVs 27, 135, 235, 236 and 237 (only allowed in TLV 27)
> 
> SRv6 End.X SID(43) and SRv6 LAN End.X SID(44) sub-TLVs which are sub-TLVs of TLVs 22, 23, 25, 141, 222 and 223 (allowed in all TLVs)
> 
> You propose to create a single registry common to all three of these sub-TLVs to share codepoints for sub-sub-TLVs. This is motivated by the one defined sub-sub-TLV SRv6 SID Structure Sub-Sub-TLV(1) which is applicable to all three new sub-TLVs.
> 
> Such a registry  (code points for sub-sub-TLVs associated with sub-TLVs in different parent TLVs) has not been defined before. Closest we have come is the "Sub-sub-TLV Codepoints for Application-Specific Link Attributes" which exists separately from " sub-TLVs of TLVs 22, 23, 25, 141, 222 and 223" but comes with the advisory:
> 
> "If a link attribute can be advertised both as a sub-TLV of TLVs
> 22, 23, 25, 141, 222, and 223 and as a sub-sub-TLV of the
> Application-Specific Link Attributes sub-TLV defined in
> [RFC8919], then the same numerical code
> should be assigned to the link attribute whenever possible."
> 
> You could elect to do the same thing here i.e., create two new registries but include a Note saying codepoints in the two should be the same whenever it makes sense to do so.
> Or, you could do something new and create a single registry even though the grandparent TLVs are different.
> 
> I don’t have a strong opinion here, but if it is anticipated that most of the sub-sub-TLVs would be shared then a single registry is easier to manage.

single one is preferred.

> 
> The name however becomes quite a mouthful - something like:
> 
> "sub-sub-TLVs for SRv6EndSID(5) (sub-TLV of TLVs 27, 135, 235, 236 and 237) and SRv6 End.X SID(43)/SRv6 LAN End.X SID(44) (sub-TLVs of TLVs 27, 135, 235, 236 and 237)"

I'm fine with that.

> 
> And you would need to create columns (analogous to the columns in existing registries which have multiple parent TLVs) to show in which parents a given sub-sub-TLV is allowed.

sure.

Peter


> 
>     Les
> 
>