Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30306C1D4CCA for ; Wed, 13 Nov 2024 10:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no 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 sGlLxGi29itK for ; Wed, 13 Nov 2024 10:09:04 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF758C1DC807 for ; Wed, 13 Nov 2024 10:09:03 -0800 (PST) Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XpWW3699zz6LD8K; Thu, 14 Nov 2024 02:08:47 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id 0E5B8140114; Thu, 14 Nov 2024 02:09:01 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 13 Nov 2024 19:09:00 +0100 Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.039; Wed, 13 Nov 2024 19:09:00 +0100 From: Italo Busi To: "Sergio Belotti (Nokia)" , "Daniele Ceccarelli (dceccare)" , "ccamp@ietf.org" Thread-Topic: WG last call on draft-ietf-ccamp-rfc9093-bis-11 Thread-Index: AdskZn955L6z5CpFSD6k2OItYblH6wQ6oCagAB5ThYAAAvJC4AADzByQ Date: Wed, 13 Nov 2024 18:09:00 +0000 Message-ID: <3ad870f77e7145979430fd6222e35acf@huawei.com> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.81.210.95] Content-Type: multipart/alternative; boundary="_000_3ad870f77e7145979430fd6222e35acfhuaweicom_" MIME-Version: 1.0 Message-ID-Hash: TUASX66S2OJ5KAUJWV4HOJN3KQKFJNHI X-Message-ID-Hash: TUASX66S2OJ5KAUJWV4HOJN3KQKFJNHI X-MailFrom: Italo.Busi@huawei.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ccamp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Aihua Guo X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BCCAMP=5DRe=3A_WG_last_call_on_draft-ietf-ccamp-rfc9093-bis-11?= List-Id: Discussion list for the CCAMP working group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_3ad870f77e7145979430fd6222e35acfhuaweicom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sergio, Good catch Then I think we should just update the common-all-modes and transceiver-mod= e groupings to use also these attributes as RO (like all the other attribut= es defined within these groupings) Italo From: Sergio Belotti (Nokia) Sent: mercoled=EC 13 novembre 2024 15:21 To: Daniele Ceccarelli (dceccare) ; = Italo Busi ; ccamp@ietf.org Cc: Aihua Guo Subject: RE: WG last call on draft-ietf-ccamp-rfc9093-bis-11 Hi Daniele, Italo, I would have a comment/doubt on point 2 : If I'm not wrong transmitter-tuning-range has been defined in the context o= f wdm-tunnel to use this grouping under tx-tune-constraints, to set all th= e constraint fro the tunnel. It is not used in Optical Impairment (where frequency range is in fact a ca= pability) . So I would say rw would be correct. Cheers Thanks Sergio From: Daniele Ceccarelli (dceccare) > Sent: Wednesday, November 13, 2024 1:50 PM To: Italo Busi >; ccamp= @ietf.org Subject: [CCAMP]Re: WG last call on draft-ietf-ccamp-rfc9093-bis-11 CAUTION: This is an external email. Please be very careful when clicking li= nks or opening attachments. See the URL nok.it/ext for additional informati= on. Hi Italo, The addition of the switching-types seemed to have collected good consensus= by TEAS/CCAMP so I'd proceed with it. Regarding 1) and 2) I think they can be managed as a WG LC comments, while = il would be great to update security and IANA considerations according to R= FC8407bis. Thanks Daniele From: Italo Busi > Sent: Tuesday, November 12, 2024 11:52 PM To: Daniele Ceccarelli (dceccare) >; ccamp@ietf.org Subject: RE: WG last call on draft-ietf-ccamp-rfc9093-bis-11 Hi Daniele, chairs and WG, I was forgetting today is the deadline for this WG LC: thanks Daniele for t= he reminder As co-author of this draft, I support moving it forward for publication wit= h the few limitations described in the mail from Daniele which, IMHO, can b= e addressed in future BC model updates if CCAMP WG agrees to address them Besides the need to add the switching-types for WSON and flexi-grid which a= ll the people who have replied to my previous e-mail have agreed being in t= he scope of this I-D, I have also spotted two other minor issues that can b= e addressed as part of the WG LC: 1. I think we can remove the base identity otu-type and its derived iden= tities from this version of the module. IMHO, they will be needed in future when addressing the limitations of the = current versions of the models but they are not used by any dependent model= so far. When addressing in the future the identified limitations, we can consider t= hese definitions as the starting point but have more freedom to change them= based on the detailed analysis of the solution. Thanks to datatracker and = github the current definitions will not be lost even if removed in the next= draft update. 1. The attributes defined in the grouping transmitter-tuning-range shall= be RO since they represent a capability Based on the comments I have recently received on other drafts in WG LC or = IESG processing, we can also consider the following points or wait for comm= ents later in the publication process (no strong opinion on my side, just a= n early warning): 1. YANG tree: shall we move it to an appendix to follow the guidelines i= n draft-ietf-netmod-rfc8407bis? 2. Security Considerations: shall we update it to follow the new templat= e in draft-ietf-netmod-rfc8407bis? 3. IANA Considerations: shall we update it to follow section 3.8.3.1 of = draft-ietf-netmod-rfc8407bis? Italo From: Daniele Ceccarelli (dceccare) > Sent: marted=EC 22 ottobre 2024 14:01 To: ccamp@ietf.org Subject: [CCAMP]WG last call on draft-ietf-ccamp-rfc9093-bis-11 Hi CCAMP, -- IMPORTANT PREAMBLE-- We have two drafts which have a very good level of maturity, namely RFC9093= bis and Optical Impairment aware topology. The more we work on them and the more disparate use cases pop up. We reques= ted the authors to have the drafts in a status that is "good enough" to add= ress the vast majority of use cases supported by the industry today so that= we can progresse the drafts to the next stage and not hold them potentiall= y for ever. With the actual version of the drafts we should be able to cover all of the= use cases with only the following limitations: * Homogenous muxponders: with the present version of the draft we are n= ot able to support use cases of interoperability between muxponder of diffe= rent versions, and we can use regenerator always at the lowest level (OTU) = since we do not have client information when setting up a tunnel. This info= rmation is missing today. * Client mapping compatibility: at the moment we can support optical co= mpatibility with operational model, but we don't support client compatibili= ty. These use cases and others that might come to your mind, if really needed, = can be handled by an update to the RFCs at later stages. - END PREAMBLE -- That said, this starts a 3 weeks working group last call on draft-ietf-ccam= p-rfc9093-bis-11. The last call will last 3 weeks to provide more time for reviewing, given w= e're approaching IETF 121 meeting. It will end on Tuesday November 12th . P= lease indicate your support or concern to the mailing list. Review comments= and nits are also welcome. All the IPR declarations from authors and contributors have been collected = and can be found in the CCAMP WIKI page: https://wiki.ietf.org/en/group/cca= mp If anyone is willing to be the shepherd for this draft, please feel free to= volunteer (authors excluded). Thanks Daniele, Fatai, Luis --_000_3ad870f77e7145979430fd6222e35acfhuaweicom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Sergio,

 

Good catch

 

Then I think we should just update the common-all-modes and transcei= ver-mode groupings to use also these attributes as RO (like all the other a= ttributes defined within these groupings)

 

Italo

 

From: Sergio Belotti (Nokia) <= ;sergio.belotti@nokia.com>
Sent: mercoled=EC 13 novembre 2024 15:21
To: Daniele Ceccarelli (dceccare) <dceccare=3D40cisco.com@dmarc.i= etf.org>; Italo Busi <Italo.Busi@huawei.com>; ccamp@ietf.org
Cc: Aihua Guo <aihuaguo@futurewei.com>
Subject: RE: WG last call on draft-ietf-ccamp-rfc9093-bis-11

 

Hi Daniele, Italo,

 

I would have a comment/doubt on point 2 :=

If I’m not wrong transmitter-tuning-range has = been defined in the context of wdm-tunnel to use this grouping  under = tx-tune-constraints, to set all the constraint fro the tunnel.

It is not used in Optical Impairment (where frequenc= y range is in fact a capability) . So I would say rw would be correct.=

 

Cheers

Thanks

 

Sergio

 

From: Daniele Ceccarelli (dcecca= re) <dceccare= =3D40cisco.com@dmarc.ietf.org>
Sent: Wednesday, November 13, 2024 1:50 PM
To: Italo Busi <Italo.Bu= si@huawei.com>; ccamp@ietf.org
Subject: [CCAMP]Re: WG last call on draft-ietf-ccamp-rfc9093-bis-11<= o:p>

 

 

CAUTIO= N: This is an external email. Please be very careful when clicking links = or opening attachments. See the URL nok.it/ext for additional information.

 

Hi Italo,

 

The addition of the switching-types seemed to have c= ollected good consensus by TEAS/CCAMP so I’d proceed with it.

Regarding 1) and 2) I think they can be managed as a= WG LC comments, while il would be great to update security and IANA consid= erations according to RFC8407bis.

 

Thanks

Daniele 

 

From: Italo Busi <Italo.Busi@huawei.com>
Sent: Tuesday, November 12, 2024 11:52 PM
To: Daniele Ceccarelli (dceccare) <dceccare@cisco.com>; ccamp@ietf.org
Subject: RE: WG last call on draft-ietf-ccamp-rfc9093-bis-11

 

Hi Daniele, chairs and WG,

 

I was forgetting today is the deadline for this WG LC: thanks Daniel= e for the reminder

 

As co-author of this draft, I support moving it forward for publicat= ion with the few limitations described in the mail from Daniele which, IMHO= , can be addressed in future BC model updates if CCAMP WG agrees to address them

 

Besides the need to add the switching-types for WSON and flexi-grid = which all the people who have replied to my previous e-mail have agreed bei= ng in the scope of this I-D, I have also spotted two other minor issues that can be addressed as part of the WG LC:

 

  1. I think we= can remove the base identity otu-type and its derived identities from this= version of the module.

IMHO, they will be needed in future when addressing the limit= ations of the current versions of the models but they are not used by any d= ependent model so far.

When addressing in the future the identified limitations, we = can consider these definitions as the starting point but have more freedom = to change them based on the detailed analysis of the solution. Thanks to datatracker and github the current definitions = will not be lost even if removed in the next draft update.

  1. The attrib= utes defined in the grouping transmitter-tuning-range shall be RO since the= y represent a capability

 

Based on the comments I have recently received on other drafts in WG= LC or IESG processing, we can also consider the following points or wait f= or comments later in the publication process (no strong opinion on my side, just an early warning):

 

  1. YANG tree:= shall we move it to an appendix to follow the guidelines in draft-ietf-net= mod-rfc8407bis?
  2. Security Considerations: shall we update it to= follow the new template in draft-ietf-netmod-rfc8407bis?=
  3. IANA = Considerations: shall we update it to follow section 3.8.3.1 of draft-ietf-= netmod-rfc8407bis?

 

Italo

 

From: Daniele Ceccarelli (dcecca= re) <dceccare@cisco.com>
Sent: marted=EC 22 ottobre 2024 14:01
To: ccamp@ietf.org
Subject: [CCAMP]WG last call on draft-ietf-ccamp-rfc9093-bis-11=

 

Hi CCAMP,

 

-- IMPORTANT PREAMBLE--

We have two drafts which have a very good level of m= aturity, namely RFC9093bis and Optical Impairment aware topology.

The more we work on them and the more disparate use = cases pop up. We requested the authors to have the drafts in a status that = is “good enough” to address the vast majority of use cases supp= orted by the industry today so that we can progresse the drafts to the next stage and not hold them potentially for ever.<= /o:p>

 

With the actual version of the drafts we should be a= ble to cover all of the use cases with only the following limitations:=

 

  • Homogenous muxponders: with the present version of the draft we are n= ot able to support use cases of interoperability between muxponder of diffe= rent versions, and we can use regenerator always at the lowest level (OTU) since we do not have client information w= hen setting up a tunnel. This information is missing today.
    • =
  • Client mapping compatibility: at the moment we can support optical co= mpatibility with operational model, but we don’t support client compa= tibility.

 

These use cases and others that might come to your m= ind, if really needed, can be handled by an update to the RFCs at later sta= ges.

- END PREAMBLE --

 

That said, this starts a 3 weeks working group last = call on draft-ietf-ccamp-rfc9093-bis-11.

 

The last call will last 3 weeks to provide more time= for reviewing, given we’re approaching IETF 121 meeting. It will end= on Tuesday November 12th . Please indicate your support or conc= ern to the mailing list. Review comments and nits are also welcome.

All the IPR declarations from authors and contributo= rs have been collected and can be found in the CCAMP WIKI page: https://wiki.ietf.org/en/g= roup/ccamp

 

If anyone is willing to be the shepherd for this dra= ft, please feel free to volunteer (authors excluded).

 

Thanks

Daniele, Fatai, Luis

 

--_000_3ad870f77e7145979430fd6222e35acfhuaweicom_--