Re: [CCAMP] Requirement document for coherent Plugs (based on discussion at IETF 118)

Adrian Farrel <adrian@olddog.co.uk> Thu, 16 November 2023 21:54 UTC

Return-Path: <adrian@olddog.co.uk>
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 330FFC14CEFA; Thu, 16 Nov 2023 13:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.403
X-Spam-Level:
X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=olddog.co.uk
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 pKam-6kchHxj; Thu, 16 Nov 2023 13:54:45 -0800 (PST)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 4C079C14F74A; Thu, 16 Nov 2023 13:54:43 -0800 (PST)
Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta8.iomartmail.com (8.14.7/8.14.7) with ESMTP id 3AGLsXLX010185; Thu, 16 Nov 2023 21:54:33 GMT
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 89A534604A; Thu, 16 Nov 2023 21:54:33 +0000 (GMT)
Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 68EBE46043; Thu, 16 Nov 2023 21:54:33 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs4.iomartmail.com (Postfix) with ESMTPS; Thu, 16 Nov 2023 21:54:33 +0000 (GMT)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 3AGLsUBG014567 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Nov 2023 21:54:31 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Daniele Ceccarelli (dceccare)'" <dceccare@cisco.com>, "'Rokui, Reza'" <rrokui@ciena.com>, ccamp@ietf.org, 'Oscar González de Dios' <oscar.gonzalezdedios@telefonica.com>, 'CCAMP Working Group' <ccamp-chairs@ietf.org>, "'Davis, Nigel'" <ndavis@ciena.com>, "'julien.meuric'" <julien.meuric@orange.com>
References: <4b54a17e9b7140f0a40fc7b3d21d9d36@huawei.com> <SJ0PR04MB8391338830C5CFFF6B2313EBCDB2A@SJ0PR04MB8391.namprd04.prod.outlook.com> <CY8PR11MB7340304C400C15A745B0CBCDD4B2A@CY8PR11MB7340.namprd11.prod.outlook.com> <SJ0PR04MB8391FCE961B38BE4903AD8BACDB2A@SJ0PR04MB8391.namprd04.prod.outlook.com> <CY8PR11MB7340A04227B801CC013DC42DD4B1A@CY8PR11MB7340.namprd11.prod.outlook.com> <0a1801da17c6$adbe8a40$093b9ec0$@olddog.co.uk> <CY8PR11MB73405F46F108458CE7F2EFC3D4B1A@CY8PR11MB7340.namprd11.prod.outlook.com>
In-Reply-To: <CY8PR11MB73405F46F108458CE7F2EFC3D4B1A@CY8PR11MB7340.namprd11.prod.outlook.com>
Date: Thu, 16 Nov 2023 21:54:31 -0000
Organization: Old Dog Consulting
Message-ID: <0c6801da18d7$7b5bcce0$721366a0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C69_01DA18D7.7B5E3DE0"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQGWxbHMAMR741JmIp9UbnHxL3XwgQDnadYMAKwwwT4Bq0RkmALAuMn0AQbP7A8Ci28T4LC3jj9A
X-Originating-IP: 82.69.109.75
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=H13dj6ozmpBIWMWgViyKN qB73gxlAnfXZp9TUou3sJ0=; b=P2xWgLzB2CfXrJm791wgRt5T/CROboQFhKn5Q h/Xht7SmB+OSPKBaZhW/v3strbb5zFD+h3Q2MFgdPI7tzVJxeaYnDYRwPat/fXlw cC8vIvCjsP9E/riqiHPEldr95xbFBVQ/IdBN0w22gRCZffCcV0/CwJQc+mradF18 4A0+ahlHiI+MIQ3YoGs7FXXkRGN/AfYv2rhAQX0eSo6EWQldD4hYuLUkqR+WeN34 AiIYrwYbZZkRxE1RXPgf0SOFnn8waIMeHTmAyIXuMIgLpAgfenVEHp8xk3IhYq25 BkxIqwHRSQimM31TS7I51f8f3AeGw4d66D0VLxjOhwINL9OUQ==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28002.003
X-TM-AS-Result: No--31.189-10.0-31-10
X-imss-scan-details: No--31.189-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28002.003
X-TMASE-Result: 10--31.188500-10.000000
X-TMASE-MatchedRID: CxmI61mtwh/xIbpQ8BhdbPHkpkyUphL9JdXjF5ArCFdh1JA5DtT1Z0bV C+F4n057dx3xKWX+pAL8VNp1Fx68ZXPqwPPs7pzB4yhsfWHTXOJNLPQl0QAltLBxKHmTK1j54xu 5XN3Jhhr8Sl9vOxiYx2uRQddMxZuoKG4Hoz3QEqEMPOZL2X19iqn/3nyhTdZwL31P64kiV5Ed/v FhrUPHQz7Iuem1C2Ra5zyDwiE+qjRRzwsUwjX0WB4ltknlvB5rVYuumPukKudyc1Mco+YfL2JiW B230g8wwmv6EZjydZBfas326o3tQEkM8+FM829aVUIE0/jxA/2nqX8cP+Mnncpj/9aYiP+hilJm lF8p4QfpHsRqnUTSbkFfmRgtdg1D5VtV90uxxtfece0aRiX9WrcDdFQ3mmWjGiPTaHrEWquku8y eP3l9Pd/Nc0lwBLJoAYib098UJWwNzYFS+u/SmwXtykVcrvpN5DK54t41kdASgmfkOsgfKhKTGN KPwayns8Gd+x8nSh4VHaceCtRAI7Lz7aZOfW7hCTeoveN0UE0JcQP6aAwUG6PFDYCUOq7HPieVR gmhMn8ugPi2f29Ykg5W7frTc06t7wpL3oGfDi2JJ72DuZB0nMot0tGMsqGnVtDtdluQbaHBqRbu wQkb0PNIAuVzaWaFzNgvVpvSOG0ZOq+6NU4O5ao2fOuRT7aalzaoGiRdh+JitSrZ0Oj0Pv/GMtO zOpELepwUk+McqyzJVWLjSiZxbvZdJdGHWlzNL7p//vLv4bMUns+AEn7rqTKv4QSPP2GxNFDLqt 8GS91w3a1RYGUMygvdahAhjjkAVSxGzzbvSpdANB89sV0bJ30tCKdnhB58r10pknZXGJrS1nwvJ X3LrWF5X5yuwToh8DFFIBzQ4Q0i4mJ41W/O+n7cGd19dSFd
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/WW9IMDtQjLru29COpSFwPDdkleA>
Subject: Re: [CCAMP] Requirement document for coherent Plugs (based on discussion at IETF 118)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2023 21:54:50 -0000

Hi Daniele,

 

> This discussion is due to field experience. 

 

Field experience is very valuable.

 

> Different implementations using the same YANG model hardly ever interwork
and many hours of integration are needed.

 

To be clear, here, do you mean:

*	Management system doesn’t interwork with equipment
*	Two pieces of equipment configured using the same YANG model won’t
interwork

 

> In many cases having just the YANG model is not enough, we should also
provide.

> some guidelines on how to use them

 

I can see how that can be valuable. Especially to make sure that everyone
has the same understanding of what the YANG objects are supposed to achieve.

 

> this is why the drafts also describe the workflows between P-PNC, MDSC,

> O-PNC etc…and they are functional blocks.

 

This may be the cause of some our problems. This forces a decision about
whether the O-PNC or the P-PNC controls the pluggable. And hence the debate.
In, on the other hand, we talk about the flow of control only saying “PNC”
then the conflict is hidden as part of the implementation choice, and we
restrict our conversation to functional blocks.

 

> This will not provide the “plug and play” standard, but should
significantly reduce

> the number of integration hours needed to make it work.

> 

> I understood this is what some operators tried to push in TIP before and
in IETF

> later…but please, anyone correct me if I’m wrong.

 

Best,

Adrian

 

 

From: Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> > 
Sent: Wednesday, November 15, 2023 2:22 PM
To: Daniele Ceccarelli (dceccare) <dceccare@cisco.com
<mailto:dceccare@cisco.com> >; 'Rokui, Reza' <rrokui@ciena.com
<mailto:rrokui@ciena.com> >; 'Rokui, Reza' <rrokui@ciena.com
<mailto:rrokui@ciena.com> >; ccamp@ietf.org <mailto:ccamp@ietf.org> ; 'Oscar
González de Dios' <oscar.gonzalezdedios@telefonica.com
<mailto:oscar.gonzalezdedios@telefonica.com> >; 'CCAMP Working Group'
<ccamp-chairs@ietf.org <mailto:ccamp-chairs@ietf.org> >; 'Davis, Nigel'
<ndavis@ciena.com <mailto:ndavis@ciena.com> >; julien.meuric
<julien.meuric@orange.com <mailto:julien.meuric@orange.com> >
Subject: RE: [CCAMP] Requirement document for coherent Plugs (based on
discussion at IETF 118)

 

Hello all,

 

I’ve been watching this debate about management architectures for pluggables
with some confusion.

 

It is clear (to me) that implementers of management systems, and vendors of
routers / pluggables have to decide how their systems will be built. And it
is probable that different approaches will be implemented and compete in the
market. So what?

 

The IETF does not (should not?) care so much about implementation/deployment
realisations at this early stage. It may suggest frameworks and
architectures, but these come later because they just show how you might
build a network. It is not our business to tell operators how to build
networks, and it is not our job to stop people making mistakes.

 

What we should be doing is looking at *functional* architectures. There are
components with responsibilities and functional interfaces. We can draw
them, but it is an implementation choice how these are realised in code:
they may be built into one product or into multiple products; they may be
present on one management station or in many places; there may be one
instance or multiple instances.

 

(FWIW, this is a repeated problem in the IETF. As engineers we are not able
to separate a functional architecture from software design. We repeatedly
believe that we must implement the functional architecture as separate
software components. But that should not be the case.)

 

So, we should convert this discussion to a debate about interfaces and
functional components, but principally about interfaces, because that is
what we standardise.

*	It looks like there is a packet router control interface (not our
business in CCAMP)
*	It looks like there is an optical line system control interface
(already done?)
*	It looks like there is an optical pluggable control interface that
must support read/write and read-only access (to be worked on in CCAMP?)
*	There needs to be (index-based?) cross-reference between the data
models on these interfaces

If we keep these interfaces (YANG models) clean, then *everyone* can
implement the management system that makes them happiest. We might end up
with applicability statements or such like that describe how to put the
models together.

 

Am I missing something important?

 

Cheers,

Adrian

 

From: CCAMP < <mailto:ccamp-bounces@ietf.org> ccamp-bounces@ietf.org> On
Behalf Of Daniele Ceccarelli (dceccare)
Sent: 15 November 2023 12:32
To: Rokui, Reza < <mailto:rrokui@ciena.com> rrokui@ciena.com>; Rokui, Reza <
<mailto:rrokui=40ciena.com@dmarc.ietf.org>
rrokui=40ciena.com@dmarc.ietf.org>;  <mailto:ccamp@ietf.org> ccamp@ietf.org;
Oscar González de Dios < <mailto:oscar.gonzalezdedios@telefonica.com>
oscar.gonzalezdedios@telefonica.com>; CCAMP Working Group <
<mailto:ccamp-chairs@ietf.org> ccamp-chairs@ietf.org>; Davis, Nigel <
<mailto:ndavis@ciena.com> ndavis@ciena.com>; julien.meuric <
<mailto:julien.meuric@orange.com> julien.meuric@orange.com>
Subject: Re: [CCAMP] Requirement document for coherent Plugs (based on
discussion at IETF 118)

 

Hi Reza,

 

Thanks for your inputs and sharing your high expectations on our work, but
whether this activity fits in CCAMP or not, is a decision that needs to be
done by the chairs and the ADs, and this is exactly what we’re working on. 

 

Having said that, we appreciate your effort in driving this effort, but
please limit it to the contribution part and leave the decision and
consensus to the proper roles.

 

Regarding the packet expertise I don’t doubt you are one of the most
experienced in your company, but the expertise we need to bring in is on the
operators side, the ones that will use what we produce.

 

Regarding your plan to publish your documents in CCAMP, again, you’re free
to submit any draft to any working group, but then it will follow the IETF
process and the consensus will be called by the chairs (and AD) …and in
order to guarantee the total transparency and fairness we already asked an
external chair (representing an operator and not a vendor) to support us in
this.

 

Thank you,

Daniele

 

 

From: Rokui, Reza < <mailto:rrokui@ciena.com> rrokui@ciena.com> 
Sent: Tuesday, November 14, 2023 9:48 PM
To: Daniele Ceccarelli (dceccare) < <mailto:dceccare@cisco.com>
dceccare@cisco.com>; Rokui, Reza <
<mailto:rrokui=40ciena.com@dmarc.ietf.org>
rrokui=40ciena.com@dmarc.ietf.org>;  <mailto:ccamp@ietf.org> ccamp@ietf.org;
Oscar González de Dios < <mailto:oscar.gonzalezdedios@telefonica.com>
oscar.gonzalezdedios@telefonica.com>; CCAMP Working Group <
<mailto:ccamp-chairs@ietf.org> ccamp-chairs@ietf.org>; Davis, Nigel <
<mailto:ndavis@ciena.com> ndavis@ciena.com>; julien.meuric <
<mailto:julien.meuric@orange.com> julien.meuric@orange.com>; Rokui, Reza <
<mailto:rrokui@ciena.com> rrokui@ciena.com>
Subject: Re: Requirement document for coherent Plugs (based on discussion at
IETF 118)

 

Hi Daniele,

 

Thanks for recognising the importance of the pluggable
requirements/use-cases. The requirements that we need to define are all
intended to address the management and control of pluggables and hence the
work is correctly placed in CCAMP where we can involve any necessary
expertise.

 

Having said that, these requirements must be broad and should also address
the multi-layer operational use-cases such as multi-layer visualization, PM
and telemetry collection, optimization and so on across the entire network
but should focus on control of coherent pluggables.

 

To this end, as per your comments we need expertise in control of Optical
and IP networks, and this is why Nigel and I from Ciena are engaged.

 

On the above basis, we will continue working on requirement/framework
document for publication in CCAMP with support of Operators and other
vendors and expect the support of CCAMP chairs and RTG AD.

 

Cheers,

Reza 

 

 

 

From: Daniele Ceccarelli (dceccare) < <mailto:dceccare@cisco.com>
dceccare@cisco.com>
Date: Tuesday, November 14, 2023 at 9:22 AM
To: Rokui, Reza < <mailto:rrokui=40ciena.com@dmarc.ietf.org>
rrokui=40ciena.com@dmarc.ietf.org>,  <mailto:ccamp@ietf.org> ccamp@ietf.org
< <mailto:ccamp@ietf.org> ccamp@ietf.org>, Oscar González de Dios <
<mailto:oscar.gonzalezdedios@telefonica.com>
oscar.gonzalezdedios@telefonica.com>, CCAMP Working Group <
<mailto:ccamp-chairs@ietf.org> ccamp-chairs@ietf.org>, Davis, Nigel <
<mailto:ndavis@ciena.com> ndavis@ciena.com>, Rokui, Reza <
<mailto:rrokui@ciena.com> rrokui@ciena.com>, julien.meuric <
<mailto:julien.meuric@orange.com> julien.meuric@orange.com>
Subject: [**EXTERNAL**] RE: Requirement document for coherent Plugs (based
on discussion at IETF 118)

Hi Reza, working group,

 

Requirements are a very important starting point for this work, but I’m not
sure CCAMP is the right place for this work.

Among the chairs we reached the agreement that this work needs to be done
involving the competences and the point of view of both the optical and
routing experts. While the former is widely present in CCAMP, the latter is
definitely missing. 

 

Together with the AD of the operations area and the RTG area we’re working
on the best way to proceed, whether moving to a different working group or
maybe having joint sessions with other working groups.

 

This doesn’t obviously prevent anyone from putting together a proposed set
of requirements that could be used as the basis for the extended work, but I
wanted to let you know that this work will require a broader set of inputs.

 

Thanks

Daniele  

 

 

From: Rokui, Reza < <mailto:rrokui=40ciena.com@dmarc.ietf.org>
rrokui=40ciena.com@dmarc.ietf.org> 
Sent: Tuesday, November 14, 2023 3:07 PM
To:  <mailto:ccamp@ietf.org> ccamp@ietf.org; Oscar González de Dios <
<mailto:oscar.gonzalezdedios@telefonica.com>
oscar.gonzalezdedios@telefonica.com>; Daniele Ceccarelli (dceccare) <
<mailto:dceccare@cisco.com> dceccare@cisco.com>; CCAMP Working Group <
<mailto:ccamp-chairs@ietf.org> ccamp-chairs@ietf.org>; Davis, Nigel <
<mailto:ndavis@ciena.com> ndavis@ciena.com>; Rokui, Reza <
<mailto:rrokui@ciena.com> rrokui@ciena.com>; julien.meuric <
<mailto:julien.meuric@orange.com> julien.meuric@orange.com>
Subject: Requirement document for coherent Plugs (based on discussion at
IETF 118)

 

Hi CCAMP,

 

There were many meetings at IETF 118 regarding the management and control of
coherent pluggables. >From these meetings, there was a tentative agreement
to develop an IETF framework/requirement document which will include packet
over optical requirements, use cases and examples. The goal of this document
is to capture a set of requirements which are agnostics to any options and
are needed to allow the full automation of packet over optical networks.

 

Several people have already agreed to work on the document. We will prepare
an initial version that captures the requirements from the existing drafts
and the slides presented by Oscar at IETF 118 on behalf of the operators. 

  

We invite you to join us if you'd like to contribute to this important work.

 

Cheers,

Reza and Nigel