Subject: [Teas] Adam Roach's No Objection on draft-ietf-teas-pce-central-control-04: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 30 Aug 2017 20:50:31 -0700

Adam Roach has entered the following ballot position for
draft-ietf-teas-pce-central-control-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central-control/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I like how clearly this document spells out the nature of the work that is to
be performed to adapt PCEP to enable the described network architecture. It's
not entirely clear to me what value it has as an archival document (rather than
simply being used internally by the working group to guide future development).
Has the working group explicitly discussed why they might want this published
as an RFC?

This document uses the term "control plane" rather extensively without
concretely defining it. While I can infer some things about what is meant, it
appears to be intended as a very concrete and specific term. In particular, it
seems to diverge from how that term is used in (e.g.) voice networks, to the
point of meaning nearly the opposite (that is: I've gathered that it refers to
the exchange of routing information on the same paths as are used to exchange
traffic). If there is a formal definition of the term in some referenced
document, I would think a citation to it would be useful. If not, please take a
stab at a formal definition of this term early in this document.

Section 2.1.2 suggests that inter-controller state sync can be achieved by
sharing a common back-end database ("...or by using a shared database.").
Without further qualifying the database as being also distributed, this simply
pushes the single point of failure from the controller to the database. Please
add terms to qualify the database itself as being highly-available/distributed.

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 31 Aug 2017 08:32:07 +0000

Hello Adam,

> I like how clearly this document spells out the nature of the work 
> that is to be performed to adapt PCEP to enable the described 
> network architecture. It's not entirely clear to me what value it
> has as an archival document (rather than simply being used 
> internally by the working group to guide future development).
> Has the working group explicitly discussed why they might want
> this published as an RFC?

I'll let the WG chairs comment on what the opinion of the WG is, but I would note that the publication request came from the WG so (I assume) the WG requested publication.

For me (as editor, and therefore someone who bothered to produce this as a candidate for being an archival document) the value here was making a statement that was persistent and stable, and recording the result of discussions and decisions in the WG. TEAS appeared (to me) to have some pretty wide ranging discussions that kept reinventing themselves. Pointing back to mailing list threads was not a good solution, and (as you can see from the size of the document) was never going to make it possible to find all of the corners. So, working as the Technical Advisor for the WG, I used this document to pull together and capture those opinions and the WG consensus so that we could nail it down and continue work without reopening the debate every three months.

> This document uses the term "control plane" rather extensively
> without concretely defining it. While I can infer some things about
> what is meant, it appears to be intended as a very concrete and
> specific term. In particular, it seems to diverge from how that term
> is used in (e.g.) voice networks, to the point of meaning nearly the
> opposite (that is: I've gathered that it refers to the exchange of 
> routing information on the same paths as are used to exchange
> document, I would think a citation to it would be useful. If not, 
> please take a stab at a formal definition of this term early in this
> document.

I chuckled quite a lot at this. Thanks.

I'm not going to grep out the definition of "control plane" in any of the voice documents. That's probably a distraction, but I'm sure it is there, clearly defined, and always referenced. I would note that protocols such as SS7 are control plane protocols in exactly the way the term is used across the whole Routing Area even if the protocol is used in a different layer of the network.

It seems to me that you have got sucked in to what is effectively a discussion of a control channel and not the control plane itself. This may lead you to consider that an IGP running in an IP network is a special case where the control channel is coincident with the data channel and allows the control protocol to monitor the data channel. But, in general, a control plane can be distributed or centralized, and the control channels can be in-band, in-fiber (but out-of-band), or out-of-band. (Actually, the IPPM WG is currently also looking at in-data control channels - but that may be a different matter.) 

This document would probably not be the place to attempt a consensus definition of what the control  plane is. Such a definition might attract lots of citations, and this doesn't seem the right document for that.  So maybe we should look for a separate definition somewhere.

Around a hundred years ago I wrote: "The Control Plane is where the signaling and control protocols operate to dynamically interact between computers." It's worth noting that some people consider the Management Plane as being part of the Control Plane, and some people think that the Routing Plane is distinct form the Control Plane.

I went and checked in RFC 4397, but even that assumes "control plane" as a well-known context while defining "control plane network", "controller", and "control plane protocol".

Does this get us anywhere, or is the term sufficiently well understood in its context that we should move on? I doubt that you'll find the energy in the Routing Area to work on formal definitions for these things (after all, this is not the ITU-T), but maybe the IESG would like to lead on this fundamental architectural work: they could steer by trying to capture a definition of these terms that would span the whole IETF.

> add terms to qualify the database itself as being highly-available/distributed.

Yes. It is worth adding something like...
It should be noted that addressing the synchronization problem through a shared database may be hiding the issues of congestion and of a single point of failure: whole the controllers may have been made resilient by allowing redundancy, the shared database is still a problem and so the whole system is still vulnerable.

Cheers,
Adrian

---

From: Adam Roach <[email-masked]>
Date: Thu, 31 Aug 2017 10:31:34 -0500

> I'll let the WG chairs comment on what the opinion of the WG is, but I would note that the publication request came from the WG so (I assume) the WG requested publication.

Yes, but that is frequently done in a somewhat pro-forma fashion, so 
much so that the IESG has issued specific guidance on the topic 
(<https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html>). 
That said, you, Spencer, and Deborah have all made good points in favor 
of publication. I'm not trying to stand in the way; I'm just making sure 
the question has been considered.

>> please take a stab at a formal definition of this term early in this
[snip]
> Around a hundred years ago I wrote: "The Control Plane is where the signaling and control protocols operate to dynamically interact between computers." It's worth noting that some people consider t…

Thanks for the explanation (and related exposition and musings). This, 
in particular, clarified for me that the problem I encountered isn't the 
terminology (which does seem roughly congruent with how I'd seen the 
term used before); but, rather the diagrams in the document. Consider, 
for example, Figure 1:

                  --------------------------------------------
                 | Orchestrator / Service Manager / OSS / NMS |
                  --------------------------------------------
                          ^
                          |
                          v
                      ------------
                     |            |     -----
                     | PCE-based  |<---| TED |
                     | Controller |     -----
                     |            |
                      ------------
                        ^
                    PCEP|
                        v
                       ----           ----       ----       ----
                      | NE |<------->| NE |<--->| NE |<--->| NE |
                       ----  Control  ----       ----       ----
                             Plane

      Figure 1: Architecture for Central Controller with Control Plane

In my understanding (based on your definition and previous experience), 
everything here participates in the control plane (although I take your 
point that there may be a diversity of opinions about whether things 
like the OSS function is included). However, in this diagram (and Figure 
3), there is a specific line labeled "Control Plane," from which I 
(apparently incorrectly) inferred that the remaining labeled lines were 
something else. Perhaps selecting a different label for the inter-NE 
communications would be clearer (or possibly adding some textual 
clarification that would help readers who would otherwise fall into the 
same confusion as I did).

/a

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 31 Aug 2017 15:56:54 +0000

Adam,

Your final point is a good catch and is my bad.

In pinching the figure from RFC 4655 I should have labeled the horizontal lines something like “signaling and routing”.

Deborah, looks like this is another update we’ll need after IESG review.

A

From: Adam Roach [mailto:[email-masked]]
Sent: 31 August 2017 16:32
To: Adrian Farrel <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Vishnu Pavan Beeram <[email-masked]>
Subject: Re: Adam Roach's No Objection on draft-ietf-teas-pce-central-control-04: (with COMMENT)

Hello Adam,

Yes, but that is frequently done in a somewhat pro-forma fashion, so much so that the IESG has issued specific guidance on the topic (<https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html><https://www.ietf.org/iesg/statement/support-documents-in-ietf-wgs.html>). That said, you, Spencer, and Deborah have all made good points in favor of publication. I'm not trying to stand in the way; I'm just making sure the question has been considered.

document.
[snip]

Thanks for the explanation (and related exposition and musings). This, in particular, clarified for me that the problem I encountered isn't the terminology (which does seem roughly congruent with how I'd seen the term used before); but, rather the diagrams in the document. Consider, for example, Figure 1:

                         ^

                         |

                         v

                     ------------

                    |            |     -----

                    | PCE-based  |<---| TED |

                    | Controller |     -----

                    |            |

                     ------------

                       ^

                   PCEP|

                       v

                      ----           ----       ----       ----

                            Plane

In my understanding (based on your definition and previous experience), everything here participates in the control plane (although I take your point that there may be a diversity of opinions about whether things like the OSS function is included). However, in this diagram (and Figure 3), there is a specific line labeled "Control Plane," from which I (apparently incorrectly) inferred that the remaining labeled lines were something else. Perhaps selecting a different label for the inter-NE communications would be clearer (or possibly adding some textual clarification that would help readers who would otherwise fall into the same confusion as I did).

/a