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

["Adrian Farrel" <[e-mail]>]

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.