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

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 25 Aug 2020 07:53:07 +0000

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;

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;

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.

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.

---

From: Balázs Varga A <[email-masked]>
Date: Wed, 26 Aug 2020 16:16:14 +0000

Hi,

Some views/comments.

Regarding item 1 and 2:
I think OAM is only a portion of the Management plane. As for now, we may simple refer to the
"detnet-x-oam" drafts to avoid confusions.
Just some Management plane related tasks/functions/modules we should cover in the document
in my view:
- administration/collection of DetNet (DN) service requests
- administration/collection of node/network states (variables, counters, etc.) needed for providing a DN service
- tools to design/optimize a DN service (selecting functions to create the service e2e, across the network)
- configuration of nodes for a DN service (e2e, across the network)
- monitoring tools for the e2e DN service
- etc.
All this tasks/functions/modules already exists today but may need some extensions due to the special
requirements/characteristics of DetNet flows.

Regarding item 3:
I think the "Management plane" part of the document is needed and it should show how the above
listed functionalities are challenged by DetNet, where extension of current solutions is needed. For
example, we may compare the Management plane differences of legacy VPN services and DetNet
service.
Just as an example, we need node internal min/max delay between ingress and egress port pairs
in order to design proper queuing control. This is not relevant for non-DetNet flows, so a new
information element is needed. However, it may be collected using already existing management
plane methods ...

Cheers
Bala'zs

From: Gengxuesong (Geng Xuesong) <[email-masked]>
Sent: Tuesday, August 25, 2020 9:53 AM
To: DetNet WG <[email-masked]>
Cc: 'DetNet Chairs' <[email-masked]>; [email-masked]; Loa Andersson <[email-masked]>
Subject: Management Plane in draft-malis-detnet-controller-plane-framework-04

Hi WG,

Best Regards
Xuesong

---

-         WG charter:

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Thu, 27 Aug 2020 03:07:00 +0000

Hi Bala'zs

Thanks for providing your thoughts! Please find my comments inline.

Best Regards
Xuesong

From: Balázs Varga A [mailto:[email-masked]]
Sent: Thursday, August 27, 2020 12:16 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; DetNet WG <[email-masked]>
Cc: 'DetNet Chairs' <[email-masked]>; [email-masked]; Loa Andersson <[email-masked]>
Subject: RE: Management Plane in draft-malis-detnet-controller-plane-framework-04

Hi,

Some views/comments.

Regarding item 1 and 2:

[Xuesong] All these functions seem very interesting and useful to me, especially when we consider how to deploy DetNet in a real network. Only one concern is about whether these topics are supposed to be discussed in IETF, which I think is highly related to implementation.

Regarding item 3:

[Xuesong] Good point! I think we could consider to add some descriptions in the following versions.

Cheers
Bala'zs

From: Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, August 25, 2020 9:53 AM
To: DetNet WG <[email-masked]<mailto:[email-masked]>>
Cc: 'DetNet Chairs' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Loa Andersson <[email-masked]<mailto:[email-masked]>>
Subject: Management Plane in draft-malis-detnet-controller-plane-framework-04

Hi WG,

Best Regards
Xuesong

---

-          WG charter:

---

From: Lou Berger <[email-masked]>
Date: Sat, 29 Aug 2020 15:07:55 -0400

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

> -*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*
>
> -*RFC 7426  Software-Defined Networking (SDN): Layers and Architecture 
> Terminology*
>
> 3.4 <https://tools.ietf.org/html/rfc7426#section-3.4>.  Management Plane
>
> Management-plane functionalities [FCAPS 
> <https://tools.ietf.org/html/rfc7426#ref-FCAPS>] typically include:
>
> - *RFC 7276  An Overview of Operations, Administration, and 
> Maintenance (OAM) Tools*
>
> Abstract
>

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Mon, 31 Aug 2020 10:06:53 +0000

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:[email-masked]]
Sent: Sunday, August 30, 2020 3:08 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>; DetNet WG <[email-masked]>
Cc: 'DetNet Chairs' <[email-masked]>; [email-masked]; Loa Andersson <[email-masked]>
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,

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.

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

---

-          WG charter: