Subject: [Teas] A New I-D on PCE as a central controller

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 May 2016 15:24:02 +0100

Hi,

The idea of a "PCE-based central controller" has been bouncing around between
PCE and TEAS for a bit. There have been plenty of use cases proposed and some
protocol extension work.

In Buenos Aires a group of us got together to try to work out where all this was
going and how to structure the work to get more progress especially on the bits
that some people are very keen to advance quickly.

The result is this architecture document which we are targeting at TEAS.
Originally intended to be very short and simple it has already grown a bit, but
it is still a manageable read. Our idea is that the different use cases will
result in a variety of distinct protocol extensions to PCEP that can be handled
in separate documents in the PCE working group . This will allow different
people to support different use cases and work on them at their own speed.

Discussion is encouraged.

Adrian (per pro "the team")

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 06 May 2016 15:16
> To: [email-masked]
> Subject: I-D Action: draft-zhao-teas-pce-control-function-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
>         Title           : An Architecture for Use of PCE and PCEP in a Network
with Central
> Control
>         Authors         : Adrian Farrel
>                           Quintin Zhao
>                           Robin Li
>                           Chao Zhou
> 	Filename        : draft-zhao-teas-pce-control-function-00.txt
> 	Pages           : 21
> 	Date            : 2016-05-06
> 
> Abstract:
>    The Path Computation Element (PCE) has become established as a core
>    component of Software Defined Networking (SDN) systems.  It can
>    compute optimal paths for traffic across a network for any definition
>    of "optimal" and can also monitor changes in resource availability
>    and traffic demands to update the paths.
> 
>    Conventionally, the PCE has been used to derive paths for MPLS Label
>    Switched Paths (LSPs).  These paths are supplied using the Path
>    Computation Element Communication Protocol (PCEP) to the head end of
>    the LSP for signaling in the MPLS network.
> 
>    SDN has a far broader applicability than just signaled MPLS traffic
>    engineered networks, and the PCE may be used to determine paths in a
>    wide range of use cases including static LSPs, segment routing,
>    service function chaining (SFC), and indeed any form of routed or
>    switched network.  It is, therefore reasonable to consider PCEP as a
>    general southbound control protocol for use in these environments to
>    allow the PCE to be fully enabled as a central controller.
> 
>    This document briefly introduces the architecture for PCE as a
>    central controller, examines the motivations and applicability for
>    PCEP as a southbound interface, and introduces the implications for
>    the protocol.  This document does not describe the use cases in
>    detail and does not define protocol extensions: that work is left for
>    other documents.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-zhao-teas-pce-control-function/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-zhao-teas-pce-control-function-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Thu, 12 May 2016 11:41:13 +0000

When reading about uses cases such as L3VPN service delivery in "Section 3.2.3", what is the author's view on the line of demarcation between NETCONF and PCEP?

Thanks

Michael

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of EXT Adrian Farrel
Sent: Friday, May 06, 2016 4:24 PM
To: [email-masked]
Subject: [Teas] A New I-D on PCE as a central controller

Hi,

The idea of a "PCE-based central controller" has been bouncing around between PCE and TEAS for a bit. There have been plenty of use cases proposed and some protocol extension work.

In Buenos Aires a group of us got together to try to work out where all this was going and how to structure the work to get more progress especially on the bits that some people are very keen to advance quickly.

The result is this architecture document which we are targeting at TEAS.
Originally intended to be very short and simple it has already grown a bit, but it is still a manageable read. Our idea is that the different use cases will result in a variety of distinct protocol extensions to PCEP that can be handled in separate documents in the PCE working group . This will allow different people to support different use cases and work on them at their own speed.

directories.
with Central
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 May 2016 17:54:10 +0100

Hello again, Michael, it seems to be my day for replying to your emails.

> When reading about uses cases such as L3VPN service delivery in "Section
3.2.3",
> what is the author's view on the line of demarcation between NETCONF and
> PCEP?

Well, I wonder which interface you're talking about.
The ones that out in here are:
- the interface between customer and operator
- the interface between "service orchestrator" and "network orchestrator"

The former of these is like the interface used in L3SM. As co-chair of L3SM, you
might not be surprised to hear that my view is that NETCONF is a fine solution -
well, the use of a YANG data model, in any case.

The latter is the interface between "Orchestrator / Service Manager / OSS / NMS"
and "PCE-based Controller" as shown on the various figures in the picture. We
haven't discussed this interface in the document, and perhaps we should.

If you look at Figure 6 (with the hierarchy of controllers) you might observe
that the parent controller could be implemented to act as though it is talking
to an NE (in the abstract node model) and that means that the southbound
interface of the parent controller would be PCEP. That means (of course) that
the northbound interface of the child controller would also be PCEP. Then, it
might seem obvious that we would want all PCE implementations to behave the same
way and so that makes the northbound interface of the parent PCE
would/could/should/might also be PCEP.

What do you think?

Thanks,
Adrian

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 20 May 2016 18:06:55 +0000

As I said, I specifically wonder about Section 3.2.3 "Service Delivery", which states (omitting some parts that are not relevant here):

"Various network services may be offered over a network. These include protection services [...] Virtual Private Network (VPN) service (such as Layer 3 VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. [...]  A PCE-based central control can consider the whole network and all components of a service at once when planning how to deliver the service. It can then use PCEP to manage the network resources and to install the necessary associations between those resources."

This wording on use of PCEP confuses me, no matter what interface we talk about. I would have assumed that YANG-based protocols such as NETCONF/RESTCONF could be useful in this context, and I am a bit surprised that the document focuses on using PCEP e.g. for L3VPN service delivery. By the way, I also wonder how PCEP fits into the discussion on QoS classification in Section 3.2.2.

I wonder if the authors could add to Section 3.2.2 and Section 3.2.3 e.g. a message sequence chart that illustrates how what is discussed in those sections relates to PCEP?

Michael

-----Original Message-----
From: Teas [mailto:[email-masked]] On Behalf Of EXT Adrian Farrel
Sent: Friday, May 13, 2016 6:54 PM
To: Scharf, Michael (Nokia - DE); [email-masked]
Subject: Re: [Teas] A New I-D on PCE as a central controller

3.2.3",
> what is the author's view on the line of demarcation between NETCONF 
> and PCEP?

The former of these is like the interface used in L3SM. As co-chair of L3SM, you might not be surprised to hear that my view is that NETCONF is a fine solution - well, the use of a YANG data model, in any case.

The latter is the interface between "Orchestrator / Service Manager / OSS / NMS"
and "PCE-based Controller" as shown on the various figures in the picture. We haven't discussed this interface in the document, and perhaps we should.

If you look at Figure 6 (with the hierarchy of controllers) you might observe that the parent controller could be implemented to act as though it is talking to an NE (in the abstract node model) and that means that the southbound interface of the parent controller would be PCEP. That means (of course) that the northbound interface of the child controller would also be PCEP. Then, it might seem obvious that we would want all PCE implementations to behave the same way and so that makes the northbound interface of the parent PCE would/could/should/might also be PCEP.

What do you think?

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 22 May 2016 05:23:47 +0100

Michael, 
 
I don't think it is complicated, but it is obviously not clear from the
document, so thank you for raising the concern.
 
You say it doesn't matter which interface we're talking about, but it does. PCEP
is a protocol and protocols are used on interfaces.
 
Let's start with southbound of the PCE. We already use PCEP on this interface.
We have always done. It is what PCEP was invented for. And recent developments
in Stateful PCE and PCE-Initiated LSPs have made PCEP (and this interface) able
to send control "commands" as well as respond to requests. Thus, PCEP is an SBI
protocol for use with signaling systems.
 
Now, we might make several observations...
 
In many (most?) MPLS-TE networks, every router is capable of being the head end
of LSPs. That means that in a PCE-enabled MPLS-TE network, every router is a
PCEP speaker.
 
Additionally, we can observe that LSPs (or PWs) can be stitched together. The
stitching, if under the control of a PCE, requires a special instruction to be
sent to the stitching node.
 
Furthermore, we can understand that a single end-to-end LSP is actually the
stitching of lots of single hop LSPs. That is really what a statically
provisioned LSP is.
 
Finally, we can see a desire to send TE instructions from a computation engine
(e.g., PCE) to individual network nodes to program their forwarding. For
example, in a Segment Routed network or for static MPLS-TE LSPs.

Put all of this together with the recognition that all TE path management is
fundamentally the same and can be performed by the same engine, and that it does
not make sense for such an engine to have to implement multiple SBI protocols,
and you end up with this draft.
 
I don't think we are saying that this approach is compulsory, but we are saying
that it is possible. Other possibilities exist including using NETCONF/YANG in
place of PCEP, and enhancing BGP in place of PCEP. Others have suggested XMPP.
Frankly, if we were proposing a new protocol it would be correct to tell us not
to, and to persuade us that one of the other protocols will do the job. But here
we are with three (or four) protocols that fit the bill: each currently covers
some of the function space and each could easily be extended to cover the whole
space. I'm not capable of saying how to decide which protocol does which
function, but I do see pressures of implementation and deployment that lead to
this draft.
 
[Historic note: I was somewhat opposed to adding PCE-Initiated LSP support to
PCEP. I thought this bent the architecture further than was originally intended.
But we went there in the PEC WG and the I-D is now "complete". By adding support
of PCE initiation of LSPs, we naturally opened the path to this document. FWIW,
this is not the first time that PCEP has been discussed as a more general SBI
protocol - RFC 7491 shows it in this context although does not discuss it much
(we should probably add a reference to ABNO in this document).]

Now, you say you are surprised that "the document focuses on using PCEP e.g. for
L3VPN service delivery." I think there is a significant difference between
*requesting* a service and *delivering* that service. The service request (as,
for example, in L3SM) does not involve a PCE and is easily achieved using a YANG
model which, if the service request is on-line, can be delivered using NETCONF.
However, service delivery requires "orchestration". Orchestration is the process
of considering available network resources and selecting what will be
provisioned to support the service. A PCE is at least a key feature of
orchestration, just as it is a key component of a network controller. 
 
But the document does NOT focus on PCEP in quite the way you describe. In fact,
the only discussion is in 3.2.3 (just two paragraphs in the whole document)
where the focus is on the use of a PCE-based central controller that can
"consider the whole network and all components of a service at once when
planning how to deliver the service." It then goes on to observe that PCEP can
be used "to manage the network resources and to install the necessary
associations between those resources." 

If we included a message flow chart it would look something like...
 
Service Manager      PCE-based Controller     NEs
     Request service--------->
                          Compute
                               Provision ------>
                                <------------- Ack
                          Update DBs
     <-------------------Ack
 
If that simple figure helps with the understanding of this or any other part of
the document, we can surely add it.
 
Cheers,
Adrian
 
> From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
> Sent: 20 May 2016 19:07
> To: [email-masked]; [email-masked]
> Subject: RE: [Teas] A New I-D on PCE as a central controller
> 
> As I said, I specifically wonder about Section 3.2.3 "Service Delivery", which
states
> (omitting some parts that are not relevant here):
> 
> "Various network services may be offered over a network. These include
> protection services [...] Virtual Private Network (VPN) service (such as Layer
3
> VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. [...]  A
> PCE-based central control can consider the whole network and all components of
> a service at once when planning how to deliver the service. It can then use
PCEP
> to manage the network resources and to install the necessary associations
> between those resources."
> 
> This wording on use of PCEP confuses me, no matter what interface we talk
> about. I would have assumed that YANG-based protocols such as
> NETCONF/RESTCONF could be useful in this context, and I am a bit surprised
that
> the document focuses on using PCEP e.g. for L3VPN service delivery. By the
way,
> I also wonder how PCEP fits into the discussion on QoS classification in
Section
> 3.2.2.
> 
> I wonder if the authors could add to Section 3.2.2 and Section 3.2.3 e.g. a
> message sequence chart that illustrates how what is discussed in those
sections
> relates to PCEP?
that
> the parent controller could be implemented to act as though it is talking to
an NE
> (in the abstract node model) and that means that the southbound interface of
> the parent controller would be PCEP. That means (of course) that the
> northbound interface of the child controller would also be PCEP. Then, it
might
> seem obvious that we would want all PCE implementations to behave the same

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sun, 22 May 2016 21:34:07 +0000

Hi Adrian,

Many thanks for the tutorial. Since RFC 7491 already acknowledges the role of a PCE, I see little value of a high-level document that talks about PCEP as a general SBI for the topics mentioned in Section 3.2.2 and Section 3.2.3, if that document does not discuss more specifically the impact on PCEP, data models, etc.

It should be obvious that in my point of view the wording in Sections 3.2.2 and 3.2.3 is not clear. Just repeating the wording once again does not address my question, since I have obviously read the document and since I know the terminology (albeit I am not a native speaker). A generic flow chart not detailing for which of the messages PCEP would be used, and with what content, also does not address my concern.
In any case, if the content of Section 3.2.2 and Section 3.2.3 cannot be made more explicit, it is impossible for me to understand whether the conclusion in Section 4 ... "As such, no substantial changes to PCEP are required to support the concept of a PCE-based controller. The only work needed will be small extensions to carry additional or specific information elements for the individual use cases." is correct and how it is actually justified for the technical areas such as Section 3.2.2 and Section 3.2.3 .

>From my personal experience this sort of entirely generic conclusion could perhaps be a bit of simplification, but this may depend on the actual use case. But in an I-D, I believe such a generic conclusion needs backing by content and as far as I understand for Section 3.2.2 and Section 3.2.3 this backing is lacking in the document right now.

Thanks

Michael

From: Adrian Farrel [mailto:[email-masked]]
Sent: Sunday, May 22, 2016 6:24 AM
To: Scharf, Michael (Nokia - DE)
Cc: [email-masked]
Subject: RE: [Teas] A New I-D on PCE as a central controller

Michael,

I don't think it is complicated, but it is obviously not clear from the document, so thank you for raising the concern.

You say it doesn't matter which interface we're talking about, but it does. PCEP is a protocol and protocols are used on interfaces.

Let's start with southbound of the PCE. We already use PCEP on this interface. We have always done. It is what PCEP was invented for. And recent developments in Stateful PCE and PCE-Initiated LSPs have made PCEP (and this interface) able to send control "commands" as well as respond to requests. Thus, PCEP is an SBI protocol for use with signaling systems.

In many (most?) MPLS-TE networks, every router is capable of being the head end of LSPs. That means that in a PCE-enabled MPLS-TE network, every router is a PCEP speaker.

Additionally, we can observe that LSPs (or PWs) can be stitched together. The stitching, if under the control of a PCE, requires a special instruction to be sent to the stitching node.

Furthermore, we can understand that a single end-to-end LSP is actually the stitching of lots of single hop LSPs. That is really what a statically provisioned LSP is.

Finally, we can see a desire to send TE instructions from a computation engine (e.g., PCE) to individual network nodes to program their forwarding. For example, in a Segment Routed network or for static MPLS-TE LSPs.

Put all of this together with the recognition that all TE path management is fundamentally the same and can be performed by the same engine, and that it does not make sense for such an engine to have to implement multiple SBI protocols, and you end up with this draft.

I don't think we are saying that this approach is compulsory, but we are saying that it is possible. Other possibilities exist including using NETCONF/YANG in place of PCEP, and enhancing BGP in place of PCEP. Others have suggested XMPP. Frankly, if we were proposing a new protocol it would be correct to tell us not to, and to persuade us that one of the other protocols will do the job. But here we are with three (or four) protocols that fit the bill: each currently covers some of the function space and each could easily be extended to cover the whole space. I'm not capable of saying how to decide which protocol does which function, but I do see pressures of implementation and deployment that lead to this draft.

[Historic note: I was somewhat opposed to adding PCE-Initiated LSP support to PCEP. I thought this bent the architecture further than was originally intended. But we went there in the PEC WG and the I-D is now "complete". By adding support of PCE initiation of LSPs, we naturally opened the path to this document. FWIW, this is not the first time that PCEP has been discussed as a more general SBI protocol - RFC 7491 shows it in this context although does not discuss it much (we should probably add a reference to ABNO in this document).]

Now, you say you are surprised that "the document focuses on using PCEP e.g. for L3VPN service delivery." I think there is a significant difference between *requesting* a service and *delivering* that service. The service request (as, for example, in L3SM) does not involve a PCE and is easily achieved using a YANG model which, if the service request is on-line, can be delivered using NETCONF. However, service delivery requires "orchestration". Orchestration is the process of considering available network resources and selecting what will be provisioned to support the service. A PCE is at least a key feature of orchestration, just as it is a key component of a network controller.

But the document does NOT focus on PCEP in quite the way you describe. In fact, the only discussion is in 3.2.3 (just two paragraphs in the whole document) where the focus is on the use of a PCE-based central controller that can "consider the whole network and all components of a service at once when planning how to deliver the service." It then goes on to observe that PCEP can be used "to manage the network resources and to install the necessary associations between those resources."

                          Compute

                               Provision ------>

                                <------------- Ack

                          Update DBs

     <-------------------Ack

If that simple figure helps with the understanding of this or any other part of the document, we can surely add it.

Cheers,

Adrian

> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> As I said, I specifically wonder about Section 3.2.3 "Service Delivery", which states

> protection services [...] Virtual Private Network (VPN) service (such as Layer 3

> a service at once when planning how to deliver the service. It can then use PCEP

> NETCONF/RESTCONF could be useful in this context, and I am a bit surprised that

> the document focuses on using PCEP e.g. for L3VPN service delivery. By the way,

> I also wonder how PCEP fits into the discussion on QoS classification in Section

> message sequence chart that illustrates how what is discussed in those sections

> To: Scharf, Michael (Nokia - DE); [email-masked]<mailto:[email-masked]>

> > When reading about uses cases such as L3VPN service delivery in

> > "Section

> The latter is the interface between "Orchestrator / Service Manager / OSS /

> NMS"

> If you look at Figure 6 (with the hierarchy of controllers) you might observe that

> the parent controller could be implemented to act as though it is talking to an NE

> northbound interface of the child controller would also be PCEP. Then, it might

> [email-masked]<mailto:[email-masked]>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 23 May 2016 09:35:11 -0400

Michael,

I think you’re expecting too much from this draft. It’s meant to be a very
high-level informational document to introduce the concepts and a
non-exhaustive list of possible applications and use cases. As with any
such early document, there’s some amount of speculative writing, and
there’s no expectation that all of the discussed applications or use cases
will actually come to fruition, and there may be others in the future that
do end up being implemented. But the actual details of protocol changes and
applications will be the topics of other standards-track draft(s) to come.

Cheers,
Andy

On Sun, May 22, 2016 at 5:34 PM, Scharf, Michael (Nokia - DE) <
[email-masked]> wrote:

> Hi Adrian,
>
>
>
> Many thanks for the tutorial. Since RFC 7491 already acknowledges the role
> of a PCE, I see little value of a high-level document that talks about PCEP
> as a general SBI for the topics mentioned in Section 3.2.2 and Section
> 3.2.3, if that document does not discuss more specifically the impact on
> PCEP, data models, etc.
>
>
>
> It should be obvious that in my point of view the wording in Sections
> 3.2.2 and 3.2.3 is not clear. Just repeating the wording once again does
> not address my question, since I have obviously read the document and since
> I know the terminology (albeit I am not a native speaker). A generic flow
> chart not detailing for which of the messages PCEP would be used, and with
> what content, also does not address my concern.
>
> In any case, if the content of Section 3.2.2 and Section 3.2.3 cannot be
> made more explicit, it is impossible for me to understand whether the
> conclusion in Section 4 … “As such, no substantial changes to PCEP are
> required to support the concept of a PCE-based controller. The only work
> needed will be small extensions to carry additional or specific information
> elements for the individual use cases.” is correct and how it is actually
> justified for the technical areas such as Section 3.2.2 and Section 3.2.3 .
>
>
>
> From my personal experience this sort of entirely generic conclusion could
> perhaps be a bit of simplification, but this may depend on the actual use
> case. But in an I-D, I believe such a generic conclusion needs backing by
> content and as far as I understand for Section 3.2.2 and Section 3.2.3 this
> backing is lacking in the document right now.
>
>
>
> Thanks
>
>
>
> Michael
>
>
>
>
>
> *From:* Adrian Farrel [mailto:[email-masked]]
> *Sent:* Sunday, May 22, 2016 6:24 AM
> *To:* Scharf, Michael (Nokia - DE)
> *Cc:* [email-masked]
>
> *Subject:* RE: [Teas] A New I-D on PCE as a central controller
>
>
>
> Michael,
>
>
>
> You say it doesn't matter which interface we're talking about, but it
> does. PCEP is a protocol and protocols are used on interfaces.
>
>
>
> Let's start with southbound of the PCE. We already use PCEP on this
> interface. We have always done. It is what PCEP was invented for. And
> recent developments in Stateful PCE and PCE-Initiated LSPs have made PCEP
> (and this interface) able to send control "commands" as well as respond to
> requests. Thus, PCEP is an SBI protocol for use with signaling systems.
>
>
>
> In many (most?) MPLS-TE networks, every router is capable of being the
> head end of LSPs. That means that in a PCE-enabled MPLS-TE network, every
> router is a PCEP speaker.
>
>
>
> Additionally, we can observe that LSPs (or PWs) can be stitched together.
> The stitching, if under the control of a PCE, requires a special
> instruction to be sent to the stitching node.
>
>
>
> Furthermore, we can understand that a single end-to-end LSP is actually
> the stitching of lots of single hop LSPs. That is really what a statically
> provisioned LSP is.
>
>
>
> Finally, we can see a desire to send TE instructions from a computation
> engine (e.g., PCE) to individual network nodes to program their forwarding.
> For example, in a Segment Routed network or for static MPLS-TE LSPs.
>
>
>
>
>
> Put all of this together with the recognition that all TE path management
> is fundamentally the same and can be performed by the same engine, and that
> it does not make sense for such an engine to have to implement multiple SBI
> protocols, and you end up with this draft.
>
>
>
> I don't think we are saying that this approach is compulsory, but we are
> saying that it is possible. Other possibilities exist including using
> NETCONF/YANG in place of PCEP, and enhancing BGP in place of PCEP. Others
> have suggested XMPP. Frankly, if we were proposing a new protocol it would
> be correct to tell us not to, and to persuade us that one of the other
> protocols will do the job. But here we are with three (or four) protocols
> that fit the bill: each currently covers some of the function space and
> each could easily be extended to cover the whole space. I'm not capable of
> saying how to decide which protocol does which function, but I do see
> pressures of implementation and deployment that lead to this draft.
>
>
>
> [Historic note: I was somewhat opposed to adding PCE-Initiated LSP support
> to PCEP. I thought this bent the architecture further than was originally
> intended. But we went there in the PEC WG and the I-D is now "complete". By
> adding support of PCE initiation of LSPs, we naturally opened the path to
> this document. FWIW, this is not the first time that PCEP has been
> discussed as a more general SBI protocol - RFC 7491 shows it in this
> context although does not discuss it much (we should probably add a
> reference to ABNO in this document).]
>
>
>
>
>
> Now, you say you are surprised that "the document focuses on using PCEP
> e.g. for L3VPN service delivery." I think there is a significant difference
> between *requesting* a service and *delivering* that service. The service
> request (as, for example, in L3SM) does not involve a PCE and is easily
> achieved using a YANG model which, if the service request is on-line, can
> be delivered using NETCONF. However, service delivery requires
> "orchestration". Orchestration is the process of considering available
> network resources and selecting what will be provisioned to support the
> service. A PCE is at least a key feature of orchestration, just as it is a
> key component of a network controller.
>
>
>
> But the document does NOT focus on PCEP in quite the way you describe. In
> fact, the only discussion is in 3.2.3 (just two paragraphs in the whole
> document) where the focus is on the use of a PCE-based central controller
> that can "consider the whole network and all components of a service at
> once when planning how to deliver the service." It then goes on to observe
> that PCEP can be used "to manage the network resources and to install the
> necessary associations between those resources."
>
>
>
>
>
> If that simple figure helps with the understanding of this or any other
> part of the document, we can surely add it.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> > From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]
> <[email-masked]>]
>
> > Sent: 20 May 2016 19:07
>
> > From: Teas [mailto:[email-masked] <[email-masked]>] On
> Behalf Of EXT Adrian Farrel
>

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 23 May 2016 13:37:11 +0000

Why doesn’t the document then mention that the use cases and conclusions on PCEP are hypothetical?

Michael

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Monday, May 23, 2016 3:35 PM
To: Scharf, Michael (Nokia - DE)
Cc: [email-masked]; [email-masked]
Subject: Re: [Teas] A New I-D on PCE as a central controller

Michael,

I think you’re expecting too much from this draft. It’s meant to be a very high-level informational document to introduce the concepts and a non-exhaustive list of possible applications and use cases. As with any such early document, there’s some amount of speculative writing, and there’s no expectation that all of the discussed applications or use cases will actually come to fruition, and there may be others in the future that do end up being implemented. But the actual details of protocol changes and applications will be the topics of other standards-track draft(s) to come.

Cheers,
Andy

On Sun, May 22, 2016 at 5:34 PM, Scharf, Michael (Nokia - DE) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Adrian,

It should be obvious that in my point of view the wording in Sections 3.2.2 and 3.2.3 is not clear. Just repeating the wording once again does not address my question, since I have obviously read the document and since I know the terminology (albeit I am not a native speaker). A generic flow chart not detailing for which of the messages PCEP would be used, and with what content, also does not address my concern.
In any case, if the content of Section 3.2.2 and Section 3.2.3 cannot be made more explicit, it is impossible for me to understand whether the conclusion in Section 4 … “As such, no substantial changes to PCEP are required to support the concept of a PCE-based controller. The only work needed will be small extensions to carry additional or specific information elements for the individual use cases.” is correct and how it is actually justified for the technical areas such as Section 3.2.2 and Section 3.2.3 .

Thanks

Michael

From: Adrian Farrel [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, May 22, 2016 6:24 AM
To: Scharf, Michael (Nokia - DE)
Cc: [email-masked]<mailto:[email-masked]>

Michael,

                          Compute

                               Provision ------>

                                <------------- Ack

                          Update DBs

     <-------------------Ack

Cheers,

Adrian

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 23 May 2016 09:43:25 -0400

Michael,

The introduction to section 3 says: “As previously mentioned, this section
is intended to just make suggestions.”. That sound like hypothetical to me.

Cheers,
Andy

On Mon, May 23, 2016 at 9:37 AM, Scharf, Michael (Nokia - DE) <
[email-masked]> wrote:

> *From:* Andrew G. Malis [mailto:[email-masked]]
> *Sent:* Monday, May 23, 2016 3:35 PM
> *Cc:* [email-masked]; [email-masked]
>
> *Subject:* Re: [Teas] A New I-D on PCE as a central controller
>
>
>
> Michael,
>
>
>

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 23 May 2016 13:52:29 +0000

Fair point. But Section 4 should also be more explicit that the conclusion there as hypothetical as the use cases Section 3.

This would not fix the problem with Section 3.2.2 and Section 3.2.3 but at least make clear that Section 4 is pure speculation only.

Michael

Sent: Monday, May 23, 2016 3:43 PM

Michael,

The introduction to section 3 says: “As previously mentioned, this section is intended to just make suggestions.”. That sound like hypothetical to me.

Cheers,
Andy

On Mon, May 23, 2016 at 9:37 AM, Scharf, Michael (Nokia - DE) <[email-masked]<mailto:[email-masked]>> wrote:
Why doesn’t the document then mention that the use cases and conclusions on PCEP are hypothetical?

Michael

From: Andrew G. Malis [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, May 23, 2016 3:35 PM
To: Scharf, Michael (Nokia - DE)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Michael,

Cheers,
Andy

Thanks

Michael

Michael,

                          Compute

                               Provision ------>

                                <------------- Ack

                          Update DBs

     <-------------------Ack

Cheers,

Adrian

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 23 May 2016 10:01:07 -0400

Michael,

I agree that we don’t yet positively know that the conclusions in section 4
are correct, but there’s also no specific knowledge that they are
incorrect. So I think it would be fair to change the sentence "As such, no
substantial changes to PCEP are required to support the concept of a
PCE-based controller.” to "As such, no substantial changes to PCEP are
expected to support the concept of a PCE-based controller.”

Cheers,
Andy

On Mon, May 23, 2016 at 9:52 AM, Scharf, Michael (Nokia - DE) <
[email-masked]> wrote:

> Fair point. But Section 4 should also be more explicit that the conclusion
> there as hypothetical as the use cases Section 3.
>
>
>
> This would not fix the problem with Section 3.2.2 and Section 3.2.3 but at
> least make clear that Section 4 is pure speculation only.
>
>
>
> Michael
>
>
>
>
>
> *Sent:* Monday, May 23, 2016 3:43 PM
>

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 23 May 2016 14:08:38 +0000

That wording is somewhat better. From my experience with use cases discussed in this draft it would be a surprise if that expectation was true. But, of course, your mileage may vary.

Michael

Sent: Monday, May 23, 2016 4:01 PM

Michael,

I agree that we don’t yet positively know that the conclusions in section 4 are correct, but there’s also no specific knowledge that they are incorrect. So I think it would be fair to change the sentence "As such, no substantial changes to PCEP are required to support the concept of a PCE-based controller.” to "As such, no substantial changes to PCEP are expected to support the concept of a PCE-based controller.”

Cheers,
Andy

On Mon, May 23, 2016 at 9:52 AM, Scharf, Michael (Nokia - DE) <[email-masked]<mailto:[email-masked]>> wrote:
Fair point. But Section 4 should also be more explicit that the conclusion there as hypothetical as the use cases Section 3.

Michael

Michael,

Cheers,
Andy

Michael

Michael,

Cheers,
Andy

Thanks

Michael

Michael,

                          Compute

                               Provision ------>

                                <------------- Ack

                          Update DBs

     <-------------------Ack

Cheers,

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 May 2016 11:11:59 +0100

Thanks Andy and Michael for pushing this forward while I was otherwise engaged.
 
I can modify the paragraph in section 4 to something like...
 
     <t>As such, there is an expectation that no substantial 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.  Where possible, consistent
        with the general principles of how protocols are extended, any additions to the protocol should be made
        in a generic way such that they are open to use in a range of applications.</t>
 
But before posting this I'd like to pick a little at Michael's point because if he is right then some of this work may collapse. Of course, it may all depend on some relative terms: "substantial" and "small".
 
What I meant to imply in the document was that existing mechanisms (PCEP sessions over TCP) and messages (such as PCInitiate) are likely to be adequate to achieve all of the functions since the required protocol will need to be session-based and reliable, and since *some* message to push state is needed. It is also my opinion that the sort of state being pushed is:
- to a network element
- concerned with programming a forwarding instruction
- related to reserving forwarding resources
All of those things already exist to some extent in PCEP.
 
Do I think new objects/TLVs will be needed? Yes, probably, for some uses.
Do I think new values for some distinguishers will be needed? Yes, definitely.
 
Would it help to go further in the proposed text by clarifying "substantial"?
 
Thanks,
Adrian
 
Sent: 23 May 2016 15:09
To: Andrew G. Malis

Michael

Michael,

Cheers,
Andy
 
On Mon, May 23, 2016 at 9:52 AM, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:
Fair point. But Section 4 should also be more explicit that the conclusion there as hypothetical as the use cases Section 3.

Michael

 
Michael,

Cheers,
Andy

On Mon, May 23, 2016 at 9:37 AM, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:
Why doesn’t the document then mention that the use cases and conclusions on PCEP are hypothetical?
 
Michael

 
Michael,

Cheers,
Andy

On Sun, May 22, 2016 at 5:34 PM, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:
Hi Adrian,

 
 
Thanks
 
Michael

 
Michael, 

 

 

 

 

 
 
Cheers,
Adrian

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 24 May 2016 15:29:46 -0400

Adrian,

It might be easier to just say “relatively minor changes” rather than “no
substantial changes”. I think people in general have a good feel for what a
“reiatively minor” change to an existing protocol entails, and again, this
is not a standards track document, just informational, and it’s just an
expectation.

Just my two cents.

Cheers,
Andy

On Tue, May 24, 2016 at 6:11 AM, Adrian Farrel <[email-masked]> wrote:

> But before posting this I'd like to pick a little at Michael's point
> because if he is right then some of this work may collapse. Of course, it
> may all depend on some relative terms: "substantial" and "small".
>
>
>
> What I meant to imply in the document was that existing mechanisms (PCEP
> sessions over TCP) and messages (such as PCInitiate) are likely to be
> adequate to achieve all of the functions since the required protocol will
> need to be session-based and reliable, and since *some* message to push
> state is needed. It is also my opinion that the sort of state being pushed
> is:
>
> - to a network element
>
> *From:* Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
> *Sent:* 23 May 2016 15:09
> *To:* Andrew G. Malis
> That wording is somewhat better. From my experience with use cases
> discussed in this draft it would be a surprise if that expectation was
> true. But, of course, your mileage may vary.
>
>
>
> Michael
>
>
>
>
>
> *Sent:* Monday, May 23, 2016 4:01 PM
> I agree that we don’t yet positively know that the conclusions in section
> 4 are correct, but there’s also no specific knowledge that they are