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 02968C1CAF58 for ; Fri, 18 Oct 2024 13:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20230601.gappssmtp.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 04sRqTEMjwg8 for ; Fri, 18 Oct 2024 13:33:13 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260F1C1CAF4C for ; Fri, 18 Oct 2024 13:33:10 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-37d3ecad390so2617144f8f.1 for ; Fri, 18 Oct 2024 13:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20230601.gappssmtp.com; s=20230601; t=1729283589; x=1729888389; darn=ietf.org; h=content-language:thread-index:mime-version:message-id:date:subject :in-reply-to:references:to:from:sender:from:to:cc:subject:date :message-id:reply-to; bh=bHuB9Qi2SCZQHuXzkCOmCHuC42Vp6x9vsmFyPbfhPyw=; b=C9mACGj9JTTBvcXJ5MafmXtrrd+sJDpgm2nlhePpUvCSKl6qZ9LwZltFdoi/4u9eZP O8NcppvKFxawP0Eqq2xj3tLZVAxa2Xkb27PqNDQeKPBnnRcMQ2OuKGNlv7WwQyjCDo0B 0NPCPgF6Wymh3Wl4yoyhJNnnWHSiiC1XHeTXJtim6aSpOIcxQ1RynvG11sl2RlKp4EmD N5BpvA/RZTjVd470uXLDpT7o9zgp7TonJl2VEd8QgINuuizJWwwijwddr22vOCVBODKL D2PaU/zH4CLIj9z5ItDrDGFPDbGbO2Wj/v3dWdFTJH0Fheq1vBUrKfDch9wWv/fuLdp4 MYaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729283589; x=1729888389; h=content-language:thread-index:mime-version:message-id:date:subject :in-reply-to:references:to:from:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bHuB9Qi2SCZQHuXzkCOmCHuC42Vp6x9vsmFyPbfhPyw=; b=EgB2Lz7uDdSXrfTZ3QDT15HsdXlbIXtltDSseB6ISkPGiT+E6S98A81F+6lG7Ss/90 YAsto+dw3tUS4NNNEzgW2nZuftgNnaPbQYvHO9ztRmz/XAVdvngdc+MiJRkg/h3czQmu BQ8mOuDUHQcpirAPKHfL5vj/P2cUnbPB04OldSEDQEW7J+KBVkuQtDsIHRn+YDOWmBej mtX2YyVHD22/MOTKSrKylxliRoWmrV+DMrlGQYfGLt5XGgg8erd1Q2lhygGTj/gV19mS bLLu1bH10l6mC+k24KvGUG+GbxX7EQ92YbCAiJLvLvfTMjs/avlf7YvPfMkS3xyEn2+I FhOA== X-Gm-Message-State: AOJu0YwITQv6C/fug1ceolQuVrK771VhX2d3BfMQES5OMtd+NeqDFJPI 7igMODLtujjv4+GxSStx8Gaznk5wwwkRqDrucR9u0u5pguSOZiVltHSbq72fipEbmzSujYsuB9u Ens+h X-Google-Smtp-Source: AGHT+IEiVljbUy4li74UyU+m8CyrlQT7XsR+x2ZRDflQC2pI0RumT0gOmt1NyoqVdGux2wFW9pzu7A== X-Received: by 2002:a5d:6703:0:b0:37d:34e7:6d24 with SMTP id ffacd0b85a97d-37d93e25a4fmr5647537f8f.18.1729283588295; Fri, 18 Oct 2024 13:33:08 -0700 (PDT) Received: from CIPHER ([2a00:23c7:115:2301:f4fc:964a:8d7b:11bb]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-431606c64c7sm35694735e9.37.2024.10.18.13.33.05 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Oct 2024 13:33:07 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: From: To: "'ccamp'" References: <202409201814239174342@chinaunicom.cn>+52DE309A2EEEED2A <005701db130a$0e87c0a0$2b9741e0$@olddog.co.uk> In-Reply-To: <005701db130a$0e87c0a0$2b9741e0$@olddog.co.uk> Date: Fri, 18 Oct 2024 21:33:02 +0100 Message-ID: <07a001db219c$ee740fc0$cb5c2f40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07A1_01DB21A5.5039FE60" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdshnOisl9V5zD6fQNmd4V4sHG3pWg== Content-Language: en-gb Message-ID-Hash: 6C73WLKEB56E27O4DBOY67YNKQDKZ4XM X-Message-ID-Hash: 6C73WLKEB56E27O4DBOY67YNKQDKZ4XM X-MailFrom: dk@danielking.net 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 X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BCCAMP=5DNew_version_of_draft-gstk-ccamp-actn-optical-transport-?= =?utf-8?q?mgmt_=28Was_RE=3A_A_review_of_draft-gstk-ccamp-actn-optical-trans?= =?utf-8?q?port-mgmt-04=29?= List-Id: Discussion list for the CCAMP working group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_07A1_01DB21A5.5039FE60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi CCAMP,=20 We just posted a new version of = draft-gstk-ccamp-actn-optical-transport-mgmt.=20 =20 Thanks to Yanxia for the questions and contributions.=20 =20 The new version and diff is available: =20 HTMLized: = https://datatracker.ietf.org/doc/html/draft-gstk-ccamp-actn-optical-trans= port-mgmt Diff: = https://author-tools.ietf.org/iddiff?url2=3Ddraft-gstk-ccamp-actn-optical= -transport-mgmt-05 =20 Main changes are: =20 - Providing a clearer view of the ACTN and FGNM interfaces; - Clarifying the Domain Controller functional component; - Adding section and holding text for migrating from a legacy OSS = towards an ACTN-based FGNM system; - Cleaning up references; - Squashing various nits and grammar bugs. =20 BR, Dan.=20 =20 From: Daniel King On Behalf Of daniel@olddog.co.uk Sent: 30 September 2024 08:26 To: = '=E8=B0=AD=E8=89=B3=E9=9C=9E(=E8=81=94=E9=80=9A=E9=9B=86=E5=9B=A2=E6=9C=AC= =E9=83=A8)' Cc: 'draft-gstk-ccamp-actn-optical-transport-mgmt' = ; 'ccamp' = Subject: RE: [CCAMP]A review of = draft-gstk-ccamp-actn-optical-transport-mgmt-04 =20 Hi Yanxia,=20 =20 Thank you for the review and suggestions. It=E2=80=99s great to have = additional reviewers of the I-Ds in CCAMP. =20 My responses inline =E2=80=9C[DK]=E2=80=9D.=20 =20 BR, Dan. =20 From: = =E8=B0=AD=E8=89=B3=E9=9C=9E(=E8=81=94=E9=80=9A=E9=9B=86=E5=9B=A2=E6=9C=AC= =E9=83=A8) >=20 Sent: 30 September 2024 03:49 To: ccamp > Cc: draft-gstk-ccamp-actn-optical-transport-mgmt = > Subject: [CCAMP]A review of = draft-gstk-ccamp-actn-optical-transport-mgmt-04 =20 Hi authors of FGNM draft and CCAMP working group, =20 I have read the FGNM draft recently and have got some comments on it.=20 Please help to clarify and share your comments. =20 1.1 para 3 =20 There may be a typo in this paragraph. I think it should be = 'non-SDN/NFV' instead of 'non-SDN/VFN'. =20 [DK] Yes, I agree. =20 ---- 2 para 3 and Figure 1 For Figure 1, I think, the function of the PNC contains both management = and control functions, while Domain Controller only includes control = functions. The positions of PNC and Domain Controller should be swapped. = At the same time, the text in paragraph 3 is also not so accurate. =20 [DK] Do you see an implementation difference in the role of = =E2=80=9CDomain Controller=E2=80=9D and =E2=80=9CPhysical Network = Controller=E2=80=9D in the functional architecture of Figure 1, or is = this comment just terminology consistency? Previous documents described = a PNC as potentially a Controller, NMS, and or EMS. We update the = =E2=80=9CDomain Controller=E2=80=9D label to =E2=80=9CPhysical Network = Controller=E2=80=9D, leave the NMS/EMS label, and then describe in the = test that a PNC could be Controller, NMS or EMS. What do you think? =20 ---- 3.1 Figure 2 =20 I think inventory should be in the scope of FGNM. =20 [DK] Ok.=20 =20 ---- 3.2 para 4 =20 The last paragraph about inventory draft should be moved to the FCAPS = section. =20 [DK] Ok. Maybe we can reference the YANG models in 3.2, but also expand = the discussion in the FCAPs section.=20 =20 ---- 5.2 para 1 =20 There is not a direct relationship between CORBA and XML. I would = suggest to change 'CORBA/XML' to be 'MTOSI/XML'. =20 [DK] Good point. If there are other specific interfaces for legacy = management systems you would like to reference, please provide them.=20 =20 ---- 5.3 Figure 3 =20 If I am not wrong, Figure 3 was intent to illustrate the relationship = between FGNM and AC models. In my understanding, the requirement for AC = models is to configure end to end paths in transport network while FGNM = model is to supplement the FCAPS functionalities. But this figure is not = so clear to me at least, maybe we can have some updates both on this = figure and related text.=20 =20 [DK] Ok. I think we (authors) initially made too many assumptions and = needed to expand the text. I will do this shortly and send it to you for = review; if you can help polish or suggest additional content, it would = be appreciated. =20 =20 ---- =20 Since China Unicom have both adopted ACTN and traditional FCAPS = interfaces in our live network, I think this draft is of great help for = us to solve some issues we met. And I would like to suggest the authors = to clarify a bit more on: =20 1. What is the full meaning of ACTN FGNM? =20 [DK] When we worked on RFC8453, we clearly stated that ACTN abstracts TE = network resources to provide a limited network view for customers to = request and self-manage connectivity services. We expected ACTN = implementations to use the recent API innovations from the IETF and = YANG-based data models. We did not fully consider the legacy OSS = components, more traditional interfaces, and the FCAPS approach.=20 =20 [DK] The original intention of the document was to examine how the ACTN = architecture can be augmented and the MPI extended to provide FCAPS = functions for fine-grain management functions. It assumed the focus = would be to leverage CCAMP and IVY data models over IETF APIs.=20 =20 2. What are the requirements for the FGNM and what is the relationship = with the existing ACTN models? =20 [DK] This is another good point. We need a sub-section explaining the = abstract API=E2=80=99s of ACTN and then some examples of what could be = implemented to provide function and how that relates to FCAPS. I will = draft some text and send it to you for review.=20 =20 3. How to deal with the compatibility issue, especially for those = operators who have adopted ACTN models in their live network? =20 [DK] Aha. I think this needs careful consideration, and I don=E2=80=99t = operate a network, so I may defer to your knowledge and that of other = operators in CCAMP. This discussion may benefit from a conversation. I = would like to do this and document the findings. Let me see if other = operators would also like to be part of this discussion.=20 =20 4. Is it possible to make a series of ACTN FGNM module document? For = example, based on the existing ACTN definition, expand the object = definition of management capabilities. =20 [DK] Typically, this is the approach we use at the IETF. It usually = depends on the requirements number, scope and complexity. Whenever = sensible, we separate the data models into different documents, which = makes implementation(s) easier, reduces the number of options, and makes = it easy for future data models to augment. =20 =20 Thanks. Yanxia Tan _____ =20 =20 =20 =E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E8=AF=AF=E6=8E=A5=E6=94=B6=E4=BA=86=E8= =AF=A5=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E9=80=9A=E8=BF=87=E7=94=B5=E5=AD= =90=E9=82=AE=E4=BB=B6=E7=AB=8B=E5=8D=B3=E9=80=9A=E7=9F=A5=E6=88=91=E4=BB=AC= =E3=80=82=E8=AF=B7=E5=9B=9E=E5=A4=8D=E9=82=AE=E4=BB=B6=E5=88=B0 = hqs-spmc@chinaunicom.cn = = =EF=BC=8C=E5=8D=B3=E5=8F=AF=E4=BB=A5=E9=80=80=E8=AE=A2=E6=AD=A4=E9=82=AE=E4= =BB=B6=E3=80=82=E6=88=91=E4=BB=AC=E5=B0=86=E7=AB=8B=E5=8D=B3=E5=B0=86=E6=82= =A8=E7=9A=84=E4=BF=A1=E6=81=AF=E4=BB=8E=E6=88=91=E4=BB=AC=E7=9A=84=E5=8F=91= =E9=80=81=E7=9B=AE=E5=BD=95=E4=B8=AD=E5=88=A0=E9=99=A4=E3=80=82 If you = have received this email in error please notify us immediately by = e-mail. Please reply to hqs-spmc@chinaunicom.cn = ,you can unsubscribe from this mail. = We will immediately remove your information from send catalogue of our.=20 ------=_NextPart_000_07A1_01DB21A5.5039FE60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi CCAMP,


We just posted a new version of = =C2=A0draft-gstk-ccamp-actn-optical-transport-mgmt. =

 

Thanks to Yanxia for the questions and contributions. =

 

The new version and diff is = available:

 

HTMLized: https://datatracker.ietf.org/doc/html/draft-gstk-ccamp= -actn-optical-transport-mgmt

Diff: https://author-tools.ietf.org/iddiff?url2=3Dd= raft-gstk-ccamp-actn-optical-transport-mgmt-05

 

Main changes are:

 

- Providing a clearer view of the ACTN and FGNM = interfaces;

- Clarifying the Domain Controller functional = component;

- Adding section and holding text for migrating from a = legacy OSS towards an ACTN-based FGNM system;

- Cleaning up references;

- Squashing various nits and grammar = bugs.

 

BR, Dan.

 

From: Daniel King <dk@danielking.net> On Behalf Of = daniel@olddog.co.uk
Sent: 30 September 2024 = 08:26
To: '=E8=B0=AD=E8=89=B3=E9=9C= =9E(=E8=81=94=E9=80=9A=E9=9B= =86=E5=9B=A2=E6=9C=AC=E9=83=A8)' <tanyx11@chinaunicom.cn>
Cc: = 'draft-gstk-ccamp-actn-optical-transport-mgmt' = <draft-gstk-ccamp-actn-optical-transport-mgmt@ietf.org>; 'ccamp' = <ccamp@ietf.org>
Subject: RE: [CCAMP]A review of = draft-gstk-ccamp-actn-optical-transport-mgmt-04

 

Hi Yanxia,

 

Thank you for the review and suggestions. It=E2=80=99s great = to have additional reviewers of the I-Ds in = CCAMP.

 

My responses inline =E2=80=9C[DK]=E2=80=9D. =

 

BR, Dan.

 

From:<= /b> = =E8=B0=AD=E8=89=B3=E9=9C=9E(=E8=81=94=E9=80=9A=E9=9B=86=E5=9B=A2=E6=9C=AC=E9= =83=A8) <tanyx11@chinaunicom.cn> =
Sent: 30 September 2024 03:49
To: ccamp <ccamp@ietf.org>
Cc: = draft-gstk-ccamp-actn-optical-transport-mgmt <dra= ft-gstk-ccamp-actn-optical-transport-mgmt@ietf.org>
Subject:= [CCAMP]A review of = draft-gstk-ccamp-actn-optical-transport-mgmt-04

 

Hi authors of FGNM draft and CCAMP = working group,

 

I have read the FGNM draft recently = and have got some comments on = it. 

Please help to clarify and share your = comments.

 

1.1 para = 3

 

There may be a typo in this paragraph. = I think it should be 'non-SDN/NFV' instead of = 'non-SDN/VFN'.

 

[DK] Yes, I = agree.

 

----

2  para 3 and Figure = 1

For Figure 1, I think, the function of the = PNC contains both management and control functions, while Domain = Controller only includes control functions. The positions of PNC and = Domain Controller should be swapped. At the same time, the text in = paragraph 3 is also not so accurate.

 

[DK] Do you = see an implementation difference in the role of =E2=80=9CDomain = Controller=E2=80=9D and =E2=80=9CPhysical Network Controller=E2=80=9D in = the functional architecture of Figure 1, or is this comment just = terminology consistency? Previous documents described a PNC as = potentially a Controller, NMS, and or EMS. We update the =E2=80=9CDomain = Controller=E2=80=9D label to =E2=80=9CPhysical Network = Controller=E2=80=9D, leave the NMS/EMS label, and then describe in the = test that a PNC could be Controller, NMS or EMS. What do you = think?

 

----

3.1  Figure = 2

 

I think inventory should be in the = scope of FGNM.

 

[DK] Ok. =

 

----

3.2  para = 4

 

The last paragraph about inventory = draft should be moved to the FCAPS = section.

 

[DK] Ok. Maybe = we can reference the YANG models in 3.2, but also expand the discussion = in the FCAPs section.

 

----

5.2 para = 1

 

There is not a direct relationship = between CORBA and XML. I would suggest to change 'CORBA/XML' to be = 'MTOSI/XML'.

 

[DK] Good = point. If there are other specific interfaces for legacy management = systems you would like to reference, please provide them. =

 

----

5.3  Figure = 3

 

If I am not wrong, Figure 3 was intent = to illustrate the relationship between FGNM and AC models. In my = understanding, the requirement for AC models is to configure end to end = paths in transport network while FGNM model is to supplement the FCAPS = functionalities. But this figure is not so clear to me at least, maybe = we can have some updates both on this figure and related = text. 

 

[DK] Ok. I = think we (authors) initially made too many assumptions and needed to = expand the text. I will do this shortly and send it to you for review; = if you can help polish or suggest additional content, it would be = appreciated.  

 

----

 

Since China Unicom have both adopted = ACTN and traditional FCAPS interfaces in our live network, I think this = draft is of great help for us to solve some issues we met. And I would = like to suggest the authors to clarify a bit more = on:

 

1. What is the full meaning of ACTN = FGNM?

 

[DK] When we = worked on RFC8453, we clearly stated that ACTN abstracts TE network = resources to provide a limited network view for customers to request and = self-manage connectivity services. We expected ACTN implementations to = use the recent API innovations from the IETF and YANG-based data models. = We did not fully consider the legacy OSS components, more traditional = interfaces, and the FCAPS approach.

 

[DK] The = original intention of the document was to examine how the ACTN = architecture can be augmented and the MPI extended to provide FCAPS = functions for fine-grain management functions. It assumed the focus = would be to leverage CCAMP and IVY data models over IETF APIs. =

 

2. What are the requirements for the FGNM = and what is the relationship with the existing ACTN = models?

 

[DK] This is another good point. We need a sub-section = explaining the abstract API=E2=80=99s of ACTN = and then some examples of what could be implemented to provide function = and how that relates to FCAPS. I will draft some text and send it to you = for review.

 

3. How to deal with the compatibility issue, = especially for those operators who have adopted ACTN models in their = live network?

 

[DK] Aha. I = think this needs careful consideration, and I don=E2=80=99t operate a = network, so I may defer to your knowledge and that of other operators in = CCAMP. This discussion may benefit from a conversation. I would like to = do this and document the findings. Let me see if other operators would = also like to be part of this discussion.

 

4. Is it possible to make a series of ACTN = FGNM module document? For example, based on the existing ACTN = definition, expand the object definition of management = capabilities.

 

[DK] = Typically, this is the approach we use at the IETF. It usually depends = on the requirements number, scope and complexity. Whenever sensible, we = separate the data models into different documents, which makes = implementation(s) easier, reduces the number of options, and makes it = easy for future data models to augment. =   

 

Thanks.

Yanxia = Tan

<= o:p> 

 

=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E8=AF=AF= =E6=8E=A5=E6=94=B6=E4=BA=86=E8=AF=A5=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E9= =80=9A=E8=BF=87=E7=94=B5=E5=AD=90=E9=82=AE=E4=BB=B6=E7=AB=8B=E5=8D=B3=E9=80= =9A=E7=9F=A5=E6=88=91=E4=BB=AC=E3=80=82=E8=AF=B7=E5=9B=9E=E5=A4=8D=E9=82=AE= =E4=BB=B6=E5=88=B0 hqs-spmc@chinaunicom.cn=EF=BC=8C=E5=8D=B3=E5=8F=AF=E4=BB=A5=E9=80=80=E8=AE=A2=E6=AD= =A4=E9=82=AE=E4=BB=B6=E3=80=82=E6=88=91=E4=BB=AC=E5=B0=86=E7=AB=8B=E5=8D=B3= =E5=B0=86=E6=82=A8=E7=9A=84=E4=BF=A1=E6=81=AF=E4=BB=8E=E6=88=91=E4=BB=AC=E7= =9A=84=E5=8F=91=E9=80=81=E7=9B=AE=E5=BD=95=E4=B8=AD=E5=88=A0=E9=99=A4=E3=80=82 If you have received this = email in error please notify us immediately by e-mail. Please reply = to hqs-spmc@chinaunicom.cn = ,you can unsubscribe from this mail. We will immediately remove your = information from send catalogue of our. =

------=_NextPart_000_07A1_01DB21A5.5039FE60--