Subject: Re: [Teas] WG Last Call on draft-ietf-teas-pce-central-control

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 4 Jun 2017 19:01:24 +0100

Weeeeeeeeeell, as the current document editor, I have read this.
 
More relevant is that I think this document is "done". 
The intent of the document is to provide a reference for a number of use cases that utilise a PCE as a central controller rather than just as a computation server.
 
Thanks,
Adrian
 
From: Teas [mailto:[email-masked]] On Behalf Of Vishnu Pavan Beeram
Sent: 31 May 2017 17:20
To: [email-masked]
Cc: TEAS WG Chairs
Subject: [Teas] WG Last Call on draft-ietf-teas-pce-central-control
 
All,
This starts a two week working group last call on
draft-ietf-teas-pce-central-control-02.

The working group last call ends on Wednesday, June 14th. Please
send your comments to the TEAS mailing list.

As is always the case, positive comments, e.g., "I've reviewed this
document and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thanks,
Pavan and Lou

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 5 Jun 2017 11:20:08 +0800

Hi, Adrian and other authors of this draft:

As the user of SDN-related technology, I support the concepts of PCECC architecture that mentioned in this draft.

And after reviewing this draft again, I have the following comments for the current document for your reference:

1.       About Section  “ 2.  Architecture”:

Figure 2 is not very  convincing for emphasizing the necessary of PCECC architecture. The necessary of PCECC is that it can simplify the processing of distributed control plane, not to replace it entirely. For example, from our experiences, the network will be more simple and efficient if we can deploy the PCE in Native IP network as described in draft  https://tools.ietf.org/html/draft-wang-teas-pce-native-ip-03. In this scenario, the PCE should interact with the on-path routers on-demand( that is conform to the intention of PCECC) , not  just the entrance node of the path( which is traditional use of PCE/PCEP)

2.       About Section  “2.1.2 Multiple Parallel Controller”

Will it be better to solve the resilience and scaling problem via the “Controller Cluster” technology? Although the synchronize solution is similar, the Cluster deployment may be more acceptable than “Multiple Parallel Controller”.

3.       About Section “3. Applicability”

3.1.1 and 3.1.5 are similar because they all requires the existing of control protocol in the underlying network.  Is it better to combine them into one section?

And if we consider 3.1.6 as one applicability, will the PCEP protocol to be developed as the Openflow protocol?

In general, we think the PCECC architecture is one viable solution, not only for MPLS-based network, transport network, but also for Native IP network, and the PCE/PCEP should be considered as the enhance/complementary to traditional distributed control protocol, not to replace it totally as envisioned by ONF/Openflow.

Best Regards.

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Teas [mailto:[email-masked]] 代表 Adrian Farrel
发送时间: 2017年6月5日 2:01
收件人: 'Vishnu Pavan Beeram'; [email-masked]
抄送: 'TEAS WG Chairs'
主题: Re: [Teas] WG Last Call on draft-ietf-teas-pce-central-control

Thanks,

Adrian

All,

Thanks,
Pavan and Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 7 Jun 2017 20:59:39 +0100

Hi Aijun,

Thanks for taking the time to make your comments.

> As the user of SDN-related technology, I support the concepts of PCECC
> architecture that mentioned in this draft.

Great. So if we can address you comments we should be good to go.

> Figure 2 is not very  convincing for emphasizing the necessary of PCECC architecture. The
> necessary of PCECC is that it can simplify the processing of distributed control plane, not
> to replace it entirely.

I agree with you completely. Section 2 provides a progression:
- Figure 1 shows the control plane approach (which is what we have with PCE today)
- Figure 2 shows (as you observe) the complete replacement (which is one option and is a simplistic view)
- Figure 3 shows the "simplification not replacement" that you are asking for.

> For example, from our experiences, the network will be more simple
> and efficient if we can deploy the PCE in Native IP network as described in draft  
> https://tools.ietf.org/html/draft-wang-teas-pce-native-ip-03. In this scenario, the PCE
> should interact with the on-path routers on-demand (that is conform to the intention of
> PCECC) , not  just the entrance node of the path (which is traditional use of PCE/PCEP)

Right. This is certainly a use case that can be explicitly called out in draft-ietf-teas-pcecc-use-cases. In this document we wanted to make sure we facilitated very possible/reasonable use case, but we did not want to describe them all.

I think you'll find that Figure 3 encompasses your scenario and that the concepts in Figure 3.2.1 also cover what you want to do (although they don't reference your draft explicitly).

To restate this point: we absolutely want to make sure that you can make full use of PCE-CC to do what you want to do, but we must try not to include every possible deployment view because that will hold up this document and make it too large.

> Will it be better to solve the resilience and scaling problem via the “Controller Cluster”
> technology? Although the synchronize solution is similar, the Cluster deployment may
> be more acceptable than “Multiple Parallel Controller”.

I'd like to understand your proposal a bit more. As far as I can see, a "cluster" is a set of controllers that have to keep in synch with each other and where any one member of the cluster could act as the PCE for any network node. I don't see how that is different from a "set of parallel controllers" except that the buzz word is different.

Perhaps there is a sense with a cluster that new controller instances can be added to the cluster dynamically. I think that is the same with parallel controllers, but maybe it is not clear in the use of the terminology.

One last possibility is the use of a proxy/gateway as a front end to a cluster of (or set of parallel) controllers. That allows a single network node to think it is talking with a single controller, but to have its requests offloaded according to how busy the controllers are. This solves some of the problems, but the proxy/gateway remains a single point of failure and a potential bottleneck.

I'd be OK to change the terminology to refer to "clusters", but I am worried that I am missing some larger point that you are making.

> 3.1.1 and 3.1.5 are similar because they all requires the existing of control
> protocol in the underlying network.  Is it better to combine them into one
> section?

I'm not so sure. 
3.1.1 is about a system with an active control plane. If you like, this is the "traditional" PCE-based MPLS-TE system.
3.1.5 describes a segment routing environment. It is quite probable that such an environment uses a routing protocol, and that is a form of control plane. But it does not use a signaling plane to install TE paths.
So while 3.1.1 pushes instructions for an LSP to be signaled, 3.1.5. pushes label stacks to be imposed.
Similar, but not the same.

> developed as the Openflow protocol?

I think that question may be even more relevant if applied to 3.1.2.
The question you are asking is whether PCEP will be extended to address these use cases, and whether that means it will evolve along a similar path to OpenFlow.
This document suggests PCEP as a general southbound protocol and is quite clear about that.

> In general, we think the PCECC architecture is one viable solution, not only for 
> MPLS-based network, transport network, but also for Native IP network, and 
> the PCE/PCEP should be considered as the enhance/complementary to traditional
> distributed control protocol, not to replace it totally as envisioned by ONF/Openflow.

I hope I have addressed your questions.
Please let me know if you think we need to make any changes to the document.

Thanks,
Adrian

---

From: Aijun Wang <[email-masked]>
Date: Thu, 8 Jun 2017 16:07:59 +0800

Hi, Adrian:

The main aim of my comments is just to want the reader get the impression that PCECC is an interesting topic and necessary architecture after reading the draft.
I think if you can incorporate your following explanation into the current draft, it will be better to achieve the above goal. Or you can seek the comments from other experienced viewer and then revised the document together.
For the word about "Multiple Parallel Controller" and "Controller Cluster" , I think the latter is the acceptable deployment option, because it can tackle  more complex situations.

From Aijun Wang

From Aijun Wang

> 在 2017年6月8日，03:59，Adrian Farrel <[email-masked]> 写道：
> 
> Hi Aijun,
>

---

From: Phil Bedard <[email-masked]>
Date: Thu, 8 Jun 2017 17:32:12 -0400

The draft is well written overall, I just had a minor nit on the "Static
LSP" section.  While the configuration on some vendors' devices call the
hop-by-hop explicit label mapping a "static LSP", I think most identify
with a static LSP as the entire end to end LSP with explicit label
instructions at each hop on the LSP.  I've also never heard the explicit
label action be referenced as a "micro-LSP" .   The term "one-hop" LSP may
also be confusing since vendors have implemented one-hop LSPs that still
use dynamic signaling.  It may be clearer to just eliminate the term
micro-LSP and define a static LSP as an end-to-end LSP with explicit label
operations at each hop in the path, or say the LSP is provisioned without
the use of a dynamic label mapping protocol.

Thanks,
Phil

On Wed, May 31, 2017 at 12:20 PM, Vishnu Pavan Beeram <[email-masked]
> wrote:

> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 9 Jun 2017 14:26:17 +0100

Thanks Phil, that makes sense.
 
Adrian
 
From: Teas [mailto:[email-masked]] On Behalf Of Phil Bedard
Sent: 08 June 2017 22:32
To: Vishnu Pavan Beeram
Cc: TEAS WG Chairs; [email-masked]
Subject: Re: [Teas] WG Last Call on draft-ietf-teas-pce-central-control
 
The draft is well written overall, I just had a minor nit on the "Static LSP" section.  While the configuration on some vendors' devices call the hop-by-hop explicit label mapping a "static LSP", I think most identify with a static LSP as the entire end to end LSP with explicit label instructions at each hop on the LSP.  I've also never heard the explicit label action be referenced as a "micro-LSP" .   The term "one-hop" LSP may also be confusing since vendors have implemented one-hop LSPs that still use dynamic signaling.  It may be clearer to just eliminate the term micro-LSP and define a static LSP as an end-to-end LSP with explicit label operations at each hop in the path, or say the LSP is provisioned without the use of a dynamic label mapping protocol.  
 
Thanks, 
Phil 
 
On Wed, May 31, 2017 at 12:20 PM, Vishnu Pavan Beeram <[email-masked]> wrote:
All,
This starts a two week working group last call on
draft-ietf-teas-pce-central-control-02.

Thanks,
Pavan and Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 14 Jun 2017 15:03:37 +0100

Hi again Aijun,

> The main aim of my comments is just to want the reader get the impression that
> PCECC is an interesting topic and necessary architecture after reading the
draft.
> I think if you can incorporate your following explanation into the current
draft, it
> will be better to achieve the above goal. 

I added  sentence to the Abstract and the Introduction to clarify your point 1.

> For the word about "Multiple Parallel Controller" and "Controller Cluster" , I
think
> the latter is the acceptable deployment option, because it can tackle  more
> complex situations.

I'm still struggling to see the difference between three parallel controllers
and a cluster of three controllers. It seems to me that in both cases, all of
the three controllers have to have access to a common set of data (TED, LSDB,
LSP-DB, ...) and that it should be possible to use any member of the set of
controllers interchangeably.

It is possible, as I said before that there is a subtle difference such that
with a set of parallel controllers a client must make a choice and direct a
request to a specific controller, while with a cluster the client just directs
the request to the cluster and load balancing etc. is a hidden function.

What I have done for your point 2 is to change the section title to "Multiple
Controllers on the Same Network". In the text I have added an explanation of the
two approaches and drawn a further figure to illustrate the cluster approach.

> >> 1. About Section  " 2.  Architecture":
> >>
> >> Figure 2 is not very  convincing for emphasizing the necessary of PCECC
> >> architecture. The necessary of PCECC is that it can simplify the processing
> >> of distributed control plane, not to replace it entirely.

[snip]

> >> 2. About Section  "2.1.2 Multiple Parallel Controller"
> >>
> >> Will it be better to solve the resilience and scaling problem via the
"Controller
> >> Cluster" technology? Although the synchronize solution is similar, the
Cluster
> >> deployment may be more acceptable than "Multiple Parallel Controller".

[snip]

A new revision sits on my lap top pending the end of WG last call.

Thanks,
Adrian

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Thu, 15 Jun 2017 18:52:19 -0400

This WG LC is closed. The authors have published a new revision addressing
the comments that were raised during the LC.

We'll trigger the next step in the process.

Regards,
-Pavan and Lou.