[CCAMP]答复: Re: A review of draft-gstk-ccamp-actn-optical-transport-mgmt-04

[yuchaode <[e-mail]>]

Thanks Yanxia for your comments.

I think it is better to have a meeting to synch-up with each other.

Thanks
Chaode

发件人: Adrian Farrel [mailto:[e-mail]]
发送时间: 2024年9月30日 20:13
收件人: '谭艳霞(联通集团本部)' <[e-mail]>
抄送: 'draft-gstk-ccamp-actn-optical-transport-mgmt' <[e-mail]>; 'ccamp' <[e-mail]>
主题: RE: [CCAMP]Re: A review of draft-gstk-ccamp-actn-optical-transport-mgmt-04

Hi Yanxia,

Thank you for reading and commenting on the draft.
I’m supplementing Dan’s response in line.

Best,
Adrian

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 [could] 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?

[AF] I’d be really interested to know if anyone has a reference definition for “Domain Controller”. I’d agree that the PNC contains both management and control functions (I think that is clear in RFC 8453). Perhaps the difference between management and control functions is that “control” only pushes instructions south to the domain, while management does that and receives information from the domain.

[AF] But when I look at definitions of an SDN Controller, I see that, while its primary function is to programme the devices through messages sent southbound, it depends on information received northbound from the devices.

[AF] Otherwise, “Domain Controller” is just a term we tried to invent (with some context from RFC 7426 and RFC 8309) to cover everything that is in an NMS, EMS, or PNC. It is possible that, in an ACTN+FNGM system, the PNC will be equivalent to the Domain Controller. But it is also possible that there will remain NMS and EMS function (such as the GUI) that remains out of scope of the PNC.

[AF] So perhaps, if we’re not comfortable of “Domain Controller” we should find another term rather than restructure the figure. Yanxia, do you have any suggestions?

----
3.1  Figure 2

I think inventory should be in the scope of FGNM.

[DK] Ok.

[AF] I’m a little puzzled, but possibly Yanxia’s comment was a little terse for me.

[AF] Yanxia are you saying that inventory should not be included in section 3.1 and figure 2 because the section is supposed to describe pre-existing ACTN MPI data models? I think I could understand that. Perhaps we move these two models to section 5.3?

----
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.

[AF] Same as above. Perhaps the resolution is to move this to 5.3.

----
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.

[AF] I think I typed that line, and it was a bit lazy. I intended to convey “All CORBA and all XML-related protocols”. I guess that includes whatever application uses XML (SOAP, raw HTTP, MTOSI) and also CORBA. How about:
OLD
*  CORBA/XML
NEW
*  Management system approaches such as CORBA, MTOSI, and XML

----
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.

[AF] Yes, this figure and the text around it needs a lot of work.

----

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.

[AF] I think we should do something to make this clearer even if the whole document is supposed to be about this topic.

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.

[AF] I think we have all of this, but perhaps it is too spread around.
1.4 motivation and scope
3. What is the MPI and how is it used
4. What is FCAPS
5. What is FGNM in the ACTN context
5.1, 5.2, 5.3 What additions to the MPI for FGNM

[AF] I don’t think we should re-explain ACTN (we have RFC 8453 for that), but if there is some additional text we could include, I think we’d welcome suggestions.

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.

[AF] I agree that we should add some discussion of this.

[AF] But we need to focus a little. Compatibility between what and what? Is it a migration question? Is it about how you manage networks that have MTOSI-accessed devices and YANG-accessed devices?

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.

[AF] There are four set of YANG module documents (today and future).

  1.  The focus so far has been on defining YANG modules for specific purposes (e.g., topology) and then showing how their use fits into the ACTN model at the CMI and the MPI
  2.  Then there have been YANG modules for expressing service requests at the CMI
  3.  Now we enhance the set of YANG modules for specific purposes (e.g., inventory) to extend the MPI (and possibly the CMI, but possibly not)
  4.  And it *might* be that we enhance the models at the CMI, but I am not sure about that.
Classes 1 and 3 are not ACTN modules. They are generic modules that are picked up for use in an ACTN architecture.
Class 2 (and 4 if it actually exists) is ACTN-specific, but I don’t know that there is any work to do there.