[CCAMP]New version of draft-gstk-ccamp-actn-optical-transport-mgmt (Was RE: A review of draft-gstk-ccamp-actn-optical-transport-mgmt-04)

[[e-mail]]

Hi CCAMP, 


We just posted a new version of  draft-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=draft-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 <[e-mail]> On Behalf Of [e-mail]
Sent: 30 September 2024 08:26
To: '谭艳霞(联通集团本部)' <[e-mail]>
Cc: 'draft-gstk-ccamp-actn-optical-transport-mgmt' <[e-mail]>; 'ccamp' <[e-mail]>
Subject: RE: [CCAMP]A review of draft-gstk-ccamp-actn-optical-transport-mgmt-04

 

Hi Yanxia, 

 

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

 

My responses inline “[DK]”. 

 

BR, Dan.

 

From: 谭艳霞(联通集团本部) <[e-mail] <mailto:[e-mail]> > 
Sent: 30 September 2024 03:49
To: ccamp <[e-mail] <mailto:[e-mail]> >
Cc: draft-gstk-ccamp-actn-optical-transport-mgmt <[e-mail] <mailto:[e-mail]> >
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 “Domain Controller” and “Physical Network Controller” 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 “Domain Controller” label to “Physical Network Controller”, 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’s 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’t 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

  _____  

 

 

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [e-mail] <mailto:[e-mail]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除> ，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [e-mail] <mailto:[e-mail]>  ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.