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

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

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
 
> -----Original Message-----
> From: Scharf, Michael (Nokia - DE) [mailto:[e-mail]]
> Sent: 20 May 2016 19:07
> To: [e-mail]; [e-mail]
> 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?
> 
> Michael
> 
> 
> 
> -----Original Message-----
> From: Teas [mailto:[e-mail]] On Behalf Of EXT Adrian Farrel
> Sent: Friday, May 13, 2016 6:54 PM
> To: Scharf, Michael (Nokia - DE); [e-mail]
> Subject: Re: [Teas] A New I-D on PCE as a central controller
> 
> 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
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas