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

["Andrew G. Malis" <[e-mail]>]

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) <
[e-mail]> 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:[e-mail]]
> *Sent:* Sunday, May 22, 2016 6:24 AM
> *To:* Scharf, Michael (Nokia - DE)
> *Cc:* [e-mail]
>
> *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.
>
>
>
> 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]
> <[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] <[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
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
>