Re: [Detnet] Management Plane in draft-malis-detnet-controller-plane-framework-04

["Gengxuesong (Geng Xuesong)" <[e-mail]>]

Hi Lou,

Thank you for providing your thoughts.
My intension here is to close the previous comments for the document and prepare for a new version which will be ready for WG adoption, as we have discussed in IETF 108. I think most of the legacy questions have been clarified. If there is no more questions in the ML, I will work on updating the draft with other authors.

Best Regards
Xuesong

From: Lou Berger [mailto:[e-mail]]
Sent: Sunday, August 30, 2020 3:08 AM
To: Gengxuesong (Geng Xuesong) <[e-mail]>; DetNet WG <[e-mail]>
Cc: 'DetNet Chairs' <[e-mail]>; [e-mail]; Loa Andersson <[e-mail]>
Subject: Re: Management Plane in draft-malis-detnet-controller-plane-framework-04


Xuesong,

I'm not too sure what input you are looking.  So I hope you find my responses below as helpful.
On 8/25/2020 3:53 AM, Gengxuesong (Geng Xuesong) wrote:
Hi WG,

After some great discussions in IETF 108 and offline, I would like to start a thread in the ML to discuss about the management plane of draft-malis-detnet-controller-plane-framework-04, to get consensus in WG . Guidance from WG chairs will also be very helpful.
Background information could be found in the end of the email[*].
Here are some topics that to be discussed:

1.       In IETF 108, a question about "M" is raised: in OAM, "M" represents "Maintenance", but in this document, all the contents about OAM are discussed in a section 5 named "management plane"; This may bring confusion about the terminologies;

I think the M in OAM maps to Maintenance.

2.


3.       In section 5, DetNet OAM is briefly discussed by dividing it into two aspects: OAM for PM and OAM for CFM; while there are two documents in WG covering the same topic: DetNet MPLS OAM and DetNet IP OAM. The relationship between these documents should be considered;

My personal perspective is that the controller plane needs to be aware of, and perhaps control and even take input from OAM.  Byt the controller plane doesn't include or implement OAM functions.

To me OAM is separate from, but lives in the data plane.

4.       The motivation of DetNet controller plane framework is to analysis the gap between the existing technologies in IETF and DetNet controller plane requirement, and give guidance for further protocol extension or new protocol design. If there have been management plane solutions, whether this part in the document is still necessary.

I think things like YANG blur the management and controller plane as it is used as an interface in many SDN solutions.  For me, such API- based control mechanisms are distinctly separate from the traditional device configuration uses of YANG, even when the same YANG transport is used, and they are generally supported with different modules.  I think there is room in the control plane document for such usage, as well as for fully (or partially) distributed control plane solutions.

Lou

(no hats)

Best Regards
Xuesong

---
[*]:Here are some background information:

-          WG charter:
Controller Plane: The DetNet Controller Plane is defined in RFC 8655 as "the aggregation of the Control and Management Planes";

-          RFC 8655  Deterministic Networking Architecture
4.4.2.  The Controller Plane
   The Controller Plane corresponds to the aggregation of the Control
   and Management Planes in [RFC7426], though Common Control and
   Measurement Plane (CCAMP) (as defined by the CCAMP Working Group
   [CCAMP]) makes an additional distinction between management and
   measurement.  When the logical separation of the Control,
   Measurement, and other Management entities is not relevant, the term
   "Controller Plane" is used for simplicity to represent them all, and
   the term "Controller Plane Function (CPF)" refers to any device
   operating in that plane, whether it is a Path Computation Element
   (PCE) [RFC4655], a Network Management Entity (NME), or a distributed
   control protocol.  The CPF is a core element of a controller, in
   charge of computing deterministic paths to be applied in the Network
   Plane.

-          RFC 7426  Software-Defined Networking (SDN): Layers and Architecture Terminology
3.4<https://tools.ietf.org/html/rfc7426#section-3.4>.  Management Plane
   The management plane is usually centralized and aims to ensure that
   the network as a whole is running optimally by communicating with the
   network devices' operational plane using a Management-Plane
   Southbound Interface (MPSI) with DAL as a point of reference.
   Management-plane functionalities are typically initiated, based on an
   overall network view, and traditionally have been human-centric.
   However, lately, algorithms are replacing most human intervention.
   Management-plane functionalities [FCAPS<https://tools.ietf.org/html/rfc7426#ref-FCAPS>] typically include:
   o  Fault and monitoring management
   o  Configuration management
-  RFC 7276  An Overview of Operations, Administration, and Maintenance (OAM) Tools
Abstract
   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset for fault detection and isolation, and for
   performance measurement.