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

[Igor Bryskin <[e-mail]>]

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:[e-mail]] 
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,

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.

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

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.