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

[Lou Berger <[e-mail]>]

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

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