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

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:teas-bounces@ietf.org] 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

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
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas