Subject: Re: [Teas] WG adoption poll draft-zhao-teas-pce-control-function

From: Lou Berger <[email-masked]>
Date: Thu, 1 Sep 2016 09:35:58 -0400

The poll is closed and the draft is adopted. 

Authors,

    Unless you object to the name change, please resubmit as
draft-ietf-teas-pce-central-control-00.  The only change should be the
file name and publication date.  Comments and other planned changes  can
go into -01.

Thank you,

Lou (and Pavan)

On 8/17/2016 5:05 PM, Lou Berger wrote:
> All,
>
> This is start of a two week poll on making
> draft-zhao-teas-pce-control-function-01 a working group document. Please
> send email to the list indicating "yes/support" or "no/do not
> support".  If indicating no, please state your reservations with the
> document.  If yes, please also feel free to provide comments you'd
> like to see addressed once the document is a WG document.
>
> The poll ends August 31.
>
> Thanks,
>
> Lou and Pavan
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 2 Sep 2016 17:12:25 +0000

Lou, Pavan, authors and all,

Sorry for being late to this work, but I do have a few questions.

1.	I think the term “PCE based network controller” is a misnomer. As correctly stated pretty much any SDN controller has some ability to perform path computations on a network topology, hence it includes a path computation element and hence PCE-based. I think the architecture attempts to propose “PCEP-based network controller”. But let’s stick to the original term for now.

2.	Applying the architecture to transport circuit-switched networks, it is not clear for me whether the “PCE-based network controller” is expected to control only a single network domain (with all NEs likely coming from the same vendor), or it should also be able to control inter-connected multi-domain network (with NEs comprising each domain possibly coming from separate vendors). So, is the configuration depicted in figure 2 is possible with multiple vendor-specific NCs? In other words, is there a case when the PCE-based network controller has to perform multi-domain coordination?

3.	The document states that PCEP is a natural and reasonable SBI choice for the PCE-based network controller:
“PCEP is essentially already capable of acting as an SBI and only
   small, use case- specific modifications to the protocol are needed to
   support this architecture.  The implications for the protocol are
   discussed further in Section 4.”
And then in section 4. It is stated that no extensions are required beyond [I-D.ietf-pce-pce-initiated-lsp])

I agree with these statements for the case when the controller manages a single-vendor environment. However, if/when the controller manages a multi-domain multi-vendor transport network, there is a need to reconcile vendor-specific differences/peculiarities. I think for this purpose an explicit model (e.g. YANG) based SBI is a better choice than PCEP, because it has richer semantics and more room for the information abstracting, abstractnative translations, tuning to particular client-server pair capability sets, and for all other reasons why we love YANG so much these days. In fact I cannot think of a more typical and demonstrative use case than this multi-domain coordination, for example, to illustrate the use of the TE Tunnel model or static LSP model that we develop in TEAS WG.

4.	What about getting events and telemetry from the network? It is not clear whether the architecture suggests using PCEP for this purpose as well. If yes, are we, really, going to define PCEP TLVs for every event or data state the controller or its clients might be interested in? Again, RPC style interface supported by explicit model(s) (e.g. gRPC) is a better choice IMO.

5.	It is not clear what is the suggested interface between the orchestrator and the controller, or between controllers in adjacent hierarchy levels (Figure 6). Why not PCEP everywhere? If there is a reason to use something else, why this something else should not also be used when the controller talks south to inferior controllers (NCs)? 

6.	In the Partitioned Networks section (2.1.1) when describing the configuration in Figure 4, the authors say that peering PCE-based controllers can coordinate themselves because they speak PCEP. I’d like them to walk me through the process of setting up on a 10 partition network end-to-end protected tunnel.

Cheers,
Igor

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Thursday, September 01, 2016 9:36 AM
To: TEAS WG
Cc: TEAS WG Chairs
Subject: Re: [Teas] WG adoption poll draft-zhao-teas-pce-control-function

Authors,

Thank you,

Lou (and Pavan)

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 30 Sep 2016 13:42:09 +0100

Hello Igor,

Almost a month late, here is an answer to your email.

> 1.	I think the term “PCE based network controller” is a misnomer. As
> correctly stated pretty much any SDN controller has some ability to perform path
> computations on a network topology, hence it includes a path computation
> element and hence PCE-based. I think the architecture attempts to propose
> “PCEP-based network controller”. But let’s stick to the original term for now.

I think you are somewhat right. There is perhaps an obvious, but often over-looked, truism: An SDN controller (well, should we say "An SDN Domain Controller", "An SDN Network Controller", or "An SDN Orchestrator") is responsible for determining paths through a network and as such it has PCE functionality within it. The purpose of this document is partly to recognise this fact.

Additionally, since PCEP was designed as a protocol for communicating with a PCE about computed paths, there is some logic to saying that PCEP has a role in SDN deployments. This document develops this idea to investigate use cases where PCEP could have a useful role.

> 2.	Applying the architecture to transport circuit-switched networks, it is not
> clear for me whether the “PCE-based network controller” is expected to control
> only a single network domain (with all NEs likely coming from the same vendor),
> or it should also be able to control inter-connected multi-domain network (with
> NEs comprising each domain possibly coming from separate vendors). So, is the
> configuration depicted in figure 2 is possible with multiple vendor-specific NCs? In
> other words, is there a case when the PCE-based network controller has to
> perform multi-domain coordination?

Mutter, mutter.
Over the last couple of months I have repeatedly run into the problem of a clear SDN architecture. I have encountered the following terms:
- SDN Controller
- Device Controller
- Domain Controller
- Network Controller
- Super Controller
- SDN Orchestrator
- Network Orchestrator
- Service Orchestrator

While many people have personal pictures of what these terms mean, I haven't seen a consensus view. We tried to pull some of these terms together in draft-wu-opsawg-service-model-explained but that isn't the purpose of that document, so we didn't complete the job.

I think the way to build a view of this is from the bottom upwards. The "network controller" in Figure 2 is issuing SBI instructions to devices. That should tell you where it fits in the architecture. That box might be functionally more complex than a single box, but it receives PCEP "commands" from something further north: that is a "PCE-based controller" which is capable of computing paths.

There is most certainly the possibility of a hierarchy of PCE-based controllers.

> D.ietf-pce-pce-initiated-lsp])

No, section 4 does not say that!
In fact it says that small changes are expected.
   As such, there is an expectation that only relatively minor changes
   to PCEP are required to support the concept of a PCE-based
   controller.  The only work expected to be needed is small extensions
   to carry additional or specific information elements for the
   individual use cases.

> I agree with these statements for the case when the controller manages a single-
> vendor environment. However, if/when the controller manages a multi-domain
> multi-vendor transport network, there is a need to reconcile vendor-specific
> differences/peculiarities. I think for this purpose an explicit model (e.g. YANG)
> based SBI is a better choice than PCEP, because it has richer semantics and more
> room for the information abstracting, abstractnative translations, tuning to
> particular client-server pair capability sets, and for all other reasons why we love
> YANG so much these days. In fact I cannot think of a more typical and
> demonstrative use case than this multi-domain coordination, for example, to
> illustrate the use of the TE Tunnel model or static LSP model that we develop in
> TEAS WG.

I think you make an important point where equipment varies per vendor. This is especially true in the case of optical equipment. 
I can see the attraction of YANG in this case although it is the nature of vendor-specific details that they cannot be standardised beyond a general container. That's easily done, but PCEP has exactly the concept available in PCEP Vendor Constraints [RFC7470, etc.]

> 4.	What about getting events and telemetry from the network? It is not
> clear whether the architecture suggests using PCEP for this purpose as well. If
> yes, are we, really, going to define PCEP TLVs for every event or data state the
> controller or its clients might be interested in? Again, RPC style interface
> supported by explicit model(s) (e.g. gRPC) is a better choice IMO.

I'd like to discuss this further. I know people have different opinions on this.
My opinion pops up in ABNO [RFC7491] and shows a different reporting mechanism (and a separate correlation component).

> 5.	It is not clear what is the suggested interface between the orchestrator
> and the controller, or between controllers in adjacent hierarchy levels (Figure 6).
> Why not PCEP everywhere? If there is a reason to use something else, why this
> something else should not also be used when the controller talks south to
> inferior controllers (NCs)?

In another context someone recently noted that there is a sad IETF tendency to extend all protocols to do all things resulting in every protocol being equivalent.

I suppose we have to choose. At the time of writing, no-one had seriously proposed using PCEP on that interface. I suppose we would only consider that if there is enthusiasm to implement. Do you want to?

But look at Figure 6.

> 6.	In the Partitioned Networks section (2.1.1) when describing the
> configuration in Figure 4, the authors say that peering PCE-based controllers can
> coordinate themselves because they speak PCEP. I’d like them to walk me
> through the process of setting up on a 10 partition network end-to-end
> protected tunnel.

It could be done. BRPC is an example [RFC5441]. But *I* would not advocate is for large clusters of domains (1 < large < 10).
On the other hand H-PCE [RFC6805] has been implemented and shown to work for such situations.
And this is developed through abstraction in [RFC7926].

Sections 2.1.2 and 2.1.3 develop the use case in 2.1.1 (the sequence of development seems natural in terms of the ability to cope with more complex scenarios) and result in H-PCE as shown in Figure 6.

Best,
Adrian
--
Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen MORE new fairy tales.
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 30 Sep 2016 13:02:56 +0000

> I suppose we have to choose. At the time of writing, no-one had seriously
> proposed using PCEP on that interface. I suppose we would only consider that
> if there is enthusiasm to implement. Do you want to?
> 
> But look at Figure 6.

I am not aware of any enthusiasm to implement PCEP on some interfaces shown in Figure 6.

Thanks

Michael

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 30 Sep 2016 14:13:52 +0100

> I am not aware of any enthusiasm to implement PCEP on some interfaces shown

I suspect you a referring to some specific interfaces rather than all interfaces in Fig 6.
But which i/fs are you concerned about?
Does this mean that you don't believe there is support for H-PCE as (discussed in RFC 6805), or that you don't think PCEs should talk to NEs (as discussed in RFC 5440)? 
Or are you talking about the "NBI" between orchestrator and PCE-based controller?

If you mean this last point then I will step back and let anyone who likes the idea speak up.

Cheers,
Adrian

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 30 Sep 2016 13:21:23 +0000

I see lots of enthusiasm to implement PCEP towards routers. Of course, this is only one interface in real carrier SDN architecture.

Thanks

Michael

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, September 30, 2016 3:14 PM
To: Scharf, Michael (Nokia - DE) <[email-masked]>; 'Igor Bryskin' <[email-masked]>
Cc: 'TEAS WG' <[email-masked]>
Subject: RE: [Teas] WG adoption poll draft-zhao-teas-pce-control-function

> > I suppose we have to choose. At the time of writing, no-one had 
> > seriously proposed using PCEP on that interface. I suppose we would 
> > only consider that if there is enthusiasm to implement. Do you want to?
> >
> > But look at Figure 6.
> 

Cheers,
Adrian

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 30 Sep 2016 15:19:47 +0000

Hi Adrian,

Thanks for your responses.

I am not sure if I made clear the basic point I was trying to make, which is the following:
It is my conviction that T-SDN (transport SDN) should start not on an NE, rather, on North Bound Interface(s) exposed and supported by a first level Domain Controller, DC (the entity that directly manages a transport domain). It does not really matter, as far as the external world (e.g. SDN applications such as multi-domain coordinators/orchestrators, integrators, slicers, big data collectors, etc.) is concerned what happens south to the DC. Please, don’t get me wrong, PCEP based DC is a solid/legit way to build an intra-domain network architecture on. But so is the architecture empowered by GMPLS Control Plane (as it is done each in their own way by Huawei, Nokia-Siemens, ADVA and others) or by ATM/PNNI style Control Plane (e.g. Ciena) or any proprietary Control/Management plane. Unless you consider a multi-vendor domain (which is virtually never the case AFAIK in LO/L! transport networks), working on a standardized DC and the automation it uses to control its domain, makes as much sense as to try standardizing domain’s NMS. In fact IMHO the most important (if not the only) difference between DC and NMS is that the former exposes/supports open NBIs to the external applications I mentioned above, and that’s where IMHO we need to focus our standardization efforts, so that any legacy NMS could be potentially converted into DC. 
There are many reasons to my thinking. Some of them I provided in my original email. Let me give one more, practical one.

Huawei folks believe (and quite rightfully so) that they have a very successful GMPLS/ASON based single-domain transport network management product today.  As everyone else they want to take part in the T-SDN game. Their ideal T-SDN story is one that, on the one hand, requires minimal (ideally 0) changes to their solution, and, on the other hand,  would be appealing/acceptable to operators, other vendors, application developers, industry as a whole,  so that they collectively could enhance existing network management paradigms.
The interesting thing is that this is, actually, possible to achieve if one believes (as I do) that T-SDN starts on the interface north of DC, and it is unimportant what is happening south of DC. This is a very practical and evolutionary mindset from the Huawei architects/developers point of view, because they can continue enhancing/innovating on their GMPLS/ASON story (which has succeeded already) totally independently from T-SDN (which may or may not succeed), getting involved in T-SDN incrementally if/when they feel comfortable and safe to do so.
However, if one believes that T-SDN starts on the network element, this would be totally revolutionary for the Huawei (and other vendors) architects/developers: they would have to give up on their GMPLS/ASON or develop a parallel intra-domain architecture, moving all the network intelligence from NEs to the centralized DC and having NEs support and DC use south bound interface (e.g. PCEP or OpenFlow style). 
Cheers,
Igor

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, September 30, 2016 8:42 AM
To: Igor Bryskin
Cc: 'TEAS WG'
Subject: RE: [Teas] WG adoption poll draft-zhao-teas-pce-control-function

Hello Igor,

Mutter, mutter.

But look at Figure 6.

Best,
Adrian