[Teas] Re: [CCAMP]Missing switching-types for WSON and flexi-grid: WG LC comment for RFC 8776-bis or RFC 9093-bis
julien.meuric@orange.com Tue, 19 November 2024 15:03 UTC
Return-Path: <julien.meuric@orange.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07251C17C89D; Tue, 19 Nov 2024 07:03:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYfhw6LmM7MM; Tue, 19 Nov 2024 07:03:01 -0800 (PST)
Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.126.238]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98017C15106B; Tue, 19 Nov 2024 07:02:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1732028581; x=1763564581; h=message-id:date:mime-version:subject:to:cc:references: in-reply-to:from; bh=ysXP8TwgO3j4DTtpXulNyF2HUsUWzqe3Lfc+Te8BvII=; b=XTQVN+jASDT9mz2vyObefMnFMD9Y2vjk4xOO/0on3DeJU7ePL69aw17o b5hk6M4lkVe6UNUdvG4LnJRjeJSRzJ4vtfvxSXejNLPLppRgUjQ9o75/+ dPof/fiHYxy5rStjPld8Ft8e5B5MzPJMPahFs6zUnrgFyNZJQ27INo8sI wddYHEK/KayKUEKJ9TQIedvWVmY9uh4byZr4djhk1FLaRU882uG2Qk4D/ 3z+PJYqi5ooULKRcqa/NTeZhixoF4lphg/J6Z+0HkACCgXTWbCCDtvDy3 1Q+FpkKKfUepAnkUKD9pEPxFQoj8HTM4ZgPEAnBm/FmEXa2zjlPwGI+8T w==;
X-CSE-ConnectionGUID: /NLdNn8CTV6MCU6QH7R+bw==
X-CSE-MsgGUID: icdcO6DFQTO0WvAe1KFkuw==
Received: from unknown (HELO opfedv3rlp0h.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2024 16:02:57 +0100
Received: from unknown (HELO OPE16NORMBX407.corporate.adroot.infra.ftgroup) ([x.x.x.x]) by opfedv3rlp0h.nor.fr.ftgroup with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 19 Nov 2024 16:02:57 +0100
Received: from [x.x.x.x] [x.x.x.x] by OPE16NORMBX407.corporate.adroot.infra.ftgroup [x.x.x.x] with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Tue, 19 Nov 2024 16:02:56 +0100
From: julien.meuric@orange.com
X-IronPort-AV: E=Sophos;i="6.12,166,1728943200"; d="p7s'346?scan'346,208,217,346";a="224037515"
Message-ID: <7f1cd9ae-0763-4601-8a08-5c22ef5f0397@orange.com>
Date: Tue, 19 Nov 2024 16:02:47 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Italo Busi <Italo.Busi@huawei.com>
References: <49a1953ca67e4e799531c4835d6241e8@huawei.com> <d567d691-96b0-456c-a0a7-6fcca1b5d67d@orange.com> <4e70247efe5446f5b414e73a31e45c83@huawei.com>
Content-Language: en-US, fr
Organization: Orange
In-Reply-To: <4e70247efe5446f5b414e73a31e45c83@huawei.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000502080901060606070105"
X-Originating-IP: [10.115.26.50]
X-ClientProxiedBy: OPE16NORMBX408.corporate.adroot.infra.ftgroup (10.115.27.17) To OPE16NORMBX407.corporate.adroot.infra.ftgroup (10.115.27.16)
Message-ID-Hash: MAATOZD2OKIP2VTJ7U2NTB7KJG627UPQ
X-Message-ID-Hash: MAATOZD2OKIP2VTJ7U2NTB7KJG627UPQ
X-MailFrom: julien.meuric@orange.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "teas@ietf.org" <teas@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Teas] Re: [CCAMP]Missing switching-types for WSON and flexi-grid: WG LC comment for RFC 8776-bis or RFC 9093-bis
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/YgnlTMZbib-3OP4hESv47ePw1KQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>
Your option 2 described below looks like a reasonable trade off that minimizes the impact on the documents. Your proposal for encodings and SCs also clarifies the situation for future extensions, so I support adding some clarifying text into 8776-bis.
Thanks,
Julien
Hi Julien,
I agree with you that LSC would have been better be defined in RFC9093 rather than in RFC8776 but it is not too late to change this
I do not see too much technical differences between the two options since YANG identities can be defined anywhere but I am a bit worried by the process-related issue if TE Types needs to be updated any time a new technology-specific switching type or LSP encoding type is defined
However, without guidelines, there is a risk to have duplicated definitions e.g., when TE types is updated by someone who is not aware of derived identities already being defined in other technology-specific model
I have checked whether RFC8776-bis provides some guidelines but actually it does not:
lsp-encoding-types: A base YANG identity for supported LSP encoding
types as defined in [RFC3471].
<…>
switching-capabilities: A base YANG identity for supported interface
switching capabilities as defined in [RFC3471].
The current text is also not fully accurate since RFC8876 defines also LSP encoding types and switching capabilities defined in other RFCs so we better take the opportunity to fix also this text
Option 1: if the decision is to define all the standardized LSP encodings and SCs identities in TE Types, the text can be updated as follow:
lsp-encoding-types: A base YANG identity for supported LSP encoding
types as defined in [RFC3471], [RFC4328] and [RFC6004].
Other standardized LSP encoding types can be defined in future
updates of the “ieft-te-types” YANG data model.
<…>
switching-capabilities: A base YANG identity for supported interface
switching capabilities as defined in [RFC3471], [RFC6002],
[RFC6004], [RFC7138], [RFC7688] and [RFC8363].
Other standardized interface switching capabilities can be
defined in future updates of the “ieft-te-types” YANG data
model.
Option 2: if the decision is to define WSON-LSC and Flexi-Grid-LSC identities in L0 Types, the text can be updated as follow, to give guidance on where future technology-specific identities should be defined:
lsp-encoding-types: A base YANG identity for supported LSP encoding
types as defined in [RFC3471], [RFC4328] and [RFC6004].
Additional technology-specific LSP encoding types can be defined
in other technology-specific models.
<…>
switching-capabilities: A base YANG identity for supported interface
switching capabilities as defined in [RFC3471], [RFC6002],
[RFC6004] and [RFC7138].
Additional technology-specific interface switching capabilities
can be defined in other technology-specific models.
Opinions?
I have also noted that RFC7074 provide some further clarification about the definition of LSP encoding types and switching capability and deprecates PSC-2, PSC-3 and PSC-4, thus providing the rationale for not defining corresponding identities in TE-Types
I am wondering whether it is worthwhile adding also RFC7074 to the list of RFCs referenced for the definitions of the lsp-encoding-types and switching-capabilities identities?
Opinions?
Italo
From: julien.meuric@orange.com <julien.meuric@orange.com>
Sent: giovedì 14 novembre 2024 21:11
Hi Italo,
I we were adding them from scratch, I'd fully agree to prefer L0 Types... However, I'm not sure it's a good idea to have LSC in one document and WSON-LSC/Flexi-Grid-LSC in a different one.
Thanks,
Julien
On 09/11/2024 12:18:25 Italo Busi <Italo.Busi=40huawei.com@dmarc.ietf.org> wrote:
I have recently noted that there are no standardized YANG identities that could be used to represent the WSON-LSC, defined in RFC 7688, and flexi-grid LSC, defined in RFC 8363
I am not sure whether these identities are better defined in TE Types (RFC 8776-bis) or Layer0 Types (RFC 9093-bis) YANG models but since both drafts are in WG LC we can fix in either was this gap
My personal preference is to add them to RFC 9093-bis in order to avoid the need to update TE Types any time a new technology-specific switching type or LSP encoding type is defined
What do you think?
Italo
- [Teas] Missing switching-types for WSON and flexi… Italo Busi
- [Teas] Re: Missing switching-types for WSON and f… tom petch
- [Teas] Re: [CCAMP]Missing switching-types for WSO… julien.meuric
- [Teas] Re: Missing switching-types for WSON and f… Daniele Ceccarelli (dceccare)
- [Teas] Re: Missing switching-types for WSON and f… Sergio Belotti (Nokia)
- [Teas] Re: [CCAMP]Re: Missing switching-types for… Aihua Guo
- [Teas] Re: [CCAMP]Missing switching-types for WSO… Italo Busi
- [Teas] Re: [CCAMP]Missing switching-types for WSO… julien.meuric
- [Teas] Re: [CCAMP]Re: Missing switching-types for… Italo Busi
- [Teas] Re: [CCAMP]Re: Missing switching-types for… julien.meuric
- [Teas] Re: [CCAMP]Re: Missing switching-types for… Sergio Belotti (Nokia)