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

"Adrian Farrel" <> Fri, 30 September 2016 12:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8412C12B38B for <>; Fri, 30 Sep 2016 05:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kclKVIs2wD_4 for <>; Fri, 30 Sep 2016 05:47:53 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D106912B383 for <>; Fri, 30 Sep 2016 05:42:41 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id u8UCgFE0028844; Fri, 30 Sep 2016 13:42:15 +0100
Received: from 950129200 ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u8UCgDJO028780 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 30 Sep 2016 13:42:14 +0100
From: Adrian Farrel <>
To: 'Igor Bryskin' <>
References: <> <> <0C72C38E7EBC34499E8A9E7DD007863908EFCBC3@dfweml501-mbx>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908EFCBC3@dfweml501-mbx>
Date: Fri, 30 Sep 2016 13:42:09 +0100
Message-ID: <09ea01d21b18$1149f3f0$33dddbd0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGJaZ8yC2TH33Bk9Yfea3ElEfsLYwK1IXSeAVdjs3KhAtyYUA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--8.206-10.0-31-10
X-imss-scan-details: No--8.206-10.0-31-10
X-TMASE-MatchedRID: yebcs53SkkDhD3VLjruNvbWIY9nJrxeGyeUl7aCTy8iLaDxfPEIN+zME cqwMcuifgewoUL5rrDQhUhCIHia0GDvtvnDYesL7BEfU2vugRF3XO6omeezMlUFF7QZ35lZ3WXO j3NIpqIoxp+EH81xurqfgtzYSuAV4FXUpVtGqgg2zI1v7J4hECjQAp53S718HncFP6l2MR7zwkI 7BR2usvLE2LgS10530qxu5rVNsbfwGVvXcakEYax3EEAbn+GRbKx5ICGp/WtFuZoqw6ulhro4iw i2FbcRAK3HANEAMiEjwr1PgEoEaDm5/NyTKlG69xXUIe0x/OqBmKMusEj+yBUvVerLPvnLyIYY7 wd9NUbzN6+L7qeUBxddLImwRoYjw7Dsybo3S8NtLP/ppPVWQqJqCl1R34jDPULzpjrEhojrw3uR B+9Ky4tjmEBRIwfLJT4M92CP8aKt5xCAgKqhZQev8QGaI25e3gsuHb8lxzt7deAKnvBMxfCC6qL zeaOaJjf7Pf2RZqS/mRvuH3Ahb2Ye/o1zWuGFv5ghRQ2Zr49Q4gG1vqBBN+AqiCYa6w8tvArfwh XClRwnHgxUsEI0nTGY90WKI+MXp/AcphgPTFgKKC6Im4I1RF7kkkTL3YjiMHRspwjeLvSUTngoa 8A5k4AnMSII8OwL/GQTrdWli6u/1YAnKwZYkDFmW6+4cR52EzJmqByfAaS2dI/DikZ1UPOe658R H980KhQIZ1Gqo9DQkT9A++CZS0ljTyMZNUK202MZGQuKc8UiFBoWoxESWCQ2G3vz8l/IElnHzCf nTdMhVwtEGsP6x4n8vHqIwBzQYVB55dkRMs8yeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNer4vmH2u5wMcuAjPlVkyf0mIbzl1+a/YG6sovpQ5Z4cCL1sEq32V+TAvpLE+mvX8g==
Archived-At: <>
Cc: 'TEAS WG' <>
Subject: Re: [Teas] WG adoption poll draft-zhao-teas-pce-control-function
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Sep 2016 12:47:55 -0000

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

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.

Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen MORE new fairy tales.
Or buy from me direct.