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

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

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 <[e-mail]> wrote:

> 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
>
>
>
> *From:* Scharf, Michael (Nokia - DE) [mailto:[e-mail]]
> *Sent:* 23 May 2016 15:09
> *To:* Andrew G. Malis
> *Cc:* [e-mail]; [e-mail]
>
> *Subject:* RE: [Teas] A New I-D on PCE as a central controller
>
>
>
> 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
>
>
>
>
>
> *From:* Andrew G. Malis [mailto:[e-mail]]
> *Sent:* Monday, May 23, 2016 4:01 PM
> *To:* Scharf, Michael (Nokia - DE)
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [Teas] A New I-D on PCE as a central controller
>
>
>
> 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) <
> [e-mail]> 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
>
>
>
>
>
> *From:* Andrew G. Malis [mailto:[e-mail]]
> *Sent:* Monday, May 23, 2016 3:43 PM
>
>
> *To:* Scharf, Michael (Nokia - DE)
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [Teas] A New I-D on PCE as a central controller
>
>
>
> 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) <
> [e-mail]> wrote:
>
> Why doesn’t the document then mention that the use cases and conclusions
> on PCEP are hypothetical?
>
>
>
> Michael
>
>
>
>
>
> *From:* Andrew G. Malis [mailto:[e-mail]]
> *Sent:* Monday, May 23, 2016 3:35 PM
> *To:* Scharf, Michael (Nokia - DE)
> *Cc:* [e-mail]; [e-mail]
>
>
> *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) <
> [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
>
>
>
>
>
>
>