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

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

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]]
> 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

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