Subject: Re: [Pce] PCEP as an SDN controller protocol?

From: Jeff Tantsura <[email-masked]>
Date: Tue, 25 Jul 2017 00:12:28 +0200

We all know – every protocol has its strong and less strong sides, however the properties required for a distributed device2device communication are quite different from device2controller environment and should be evaluated as such.

There’s a long list of pros and cons for either environments (objective functions) as well operational preferences, domain knowledge, and such

Most of us here are biased ☺ 

To put it short – I believe there’s enough people who are interested in working on PCEP to extend it, personally I see value in having PCEP next to any other SBI’s mentioned below, however what I don’t want, is to overload semantics of PCEP (aka BGP kitchen sink ☺).

Cheers,

Jeff

From: Pce <[email-masked]> on behalf of Igor Bryskin <[email-masked]>
Date: Monday, July 24, 2017 at 14:52
To: "[email-masked]" <[email-masked]>, Jonathan Hardwick <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Pce] PCEP as an SDN controller protocol?

Hi Stephanie,

You said:

< Why not limiting PCEP to path programming and path policies (traffic steering on path…) ?

But why not to use for these purposes RESTCONF or gRPC/protobuffs? Do you see value in using explicit model based SBIs vs implicit (TLV-) based protocols such as  PCE?

Cheers,,

Igor

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 24, 2017 8:03 AM
To: Jonathan Hardwick; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] PCEP as an SDN controller protocol?

Hi,

As soon as we started with the active stateful PCE, the PCE became an SDN controller who takes decision and programs the network.

So as many already mentioned, PCEP as an SBI is already done.

IMO, PCECC does not change significantly PCEP, it’s just bring a new kind of LSP style for this hop by hop path programming. A controller implementing hop by hop path programming will require more intelligence as it needs to program nodes in the right order to prevent transient loops…

The question is more what is the exact scope of PCEP in term of SBI and do we want to create a protocol that does everything , including coffee J ?

We already have plenty of protocols: BGP, IGP, Netconf. Each protocol has strength and weaknesses and I’m not sure that we need to mimic all features in all protocols. What is the gain here ?

The best approach may be to use strength of protocols and use them for what they are good for:

Example:

IGP has good flooding capability with “limited scale”: interesting when all receivers need the same information

BGP has good flooding capability with large scale and ability to target specific groups (using route targets/communities) : interesting when groups of receivers need the same information

Netconf more generic and point to point

…

IMO: 

do we need PCEP-LS ? => This can be discussed, we already have two protocols to exchange the topology… 

do we need to add configuration capabilities in PCEP => not sure, we have Netconf for that.

Why not limiting PCEP to path programming and path policies (traffic steering on path…) ?

Brgds,

From: Pce [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: Thursday, July 20, 2017 17:22
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] PCEP as an SDN controller protocol?

Dear PCE WG

The purpose of this email is to initiate a discussion about whether we want to extend PCEP to allow it to replace the functions that are traditionally provided by the routing and signalling protocols.

Originally, PCEP was designed with the goal of providing a distributed path computation service.  In recent years we have extended that mission, and added path modification and path instantiation capabilities to PCEP.  This has added capabilities to PCEP that would traditionally have been performed by the network management plane.

We are now starting to discuss proposals to add more capabilities to PCEP – capabilities that are traditionally part of routing and signalling.  There were three examples of this in the PCE working group meeting this week.

·        The PCECC proposal, which extends PCEP’s path instantiation capability so that the PCE can provision a path end-to-end by touching each hop along the path.  This replaces the function already provided by RSVP-TE.

·        The PCEP-LS proposal, which extends PCEP to allow link state and TE information to be communicated from the network to the PCE.  This replaces the link state flooding function provided by the IGPs, or BGP-LS.

·        The PCECC-SR proposal extends PCEP to allow device-level configuration to be communicated between the network and the PCE, such as SRGBs, prefix SIDs etc.  Again, this replaces functions that are already designed into the IGPs.

These proposals are taking PCEP in the direction of being a fully-fledged SDN protocol.  With these proposals, one can envision a network in which there is no traditional control plane.  PCEP is used to communicate the current network state and to program flows.  These proposals have their roots in the ACTN and PCECC architectures that are adopted within the TEAS working group.  TEAS is very much assuming that this is the direction that we want to take PCEP in.  However, there are two procedural issues, as I see it.

1.      We have not had an explicit discussion in the PCE WG about whether we want to take PCEP in this direction.  We have had a few lively debates on specific cases, like PCEP-LS, but those cases represent the “thin end of the wedge”.  If we start down this path then we are accepting that PCEP will replace the functions available in the traditional control plane.  We need to test whether there is a consensus in the working group to move in that direction.

2.      We do not currently have a charter that allows us to add this type of capability to PCEP.  Depending on the outcome of discussion (1), we can of course extend the charter.

This email is to initiate the discussion (1).  So, please reply to the mailing list and share your thoughts on whether PCEP should be extended in this direction, and how far we should go.

I am hoping to get more than just “yes” or “no” answers to this question (although that would be better than no answer).  I would like to hear justifications for or against.  Such as, which production networks would run PCEP in place of a traditional control plane?  Why is it not desirable to solve the problems in those networks with the traditional control plane?  What harm could this do?  What would be the operational problems associated with adding these functions to PCEP?

Many thanks

Jon

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________ Pce mailing list [email-masked] https://www.ietf.org/mailman/listinfo/pce

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 27 Jul 2017 09:36:20 +0800

I agree with Jeff. 

The communication between distributed device2device is different from device2controller.  The latter should be complementary of the former, not replace them.

We operator just want to use such SBI protocol to enhance the coordination among the underlying devices, especially for the end-to-end optimal path programming. 

If the PCEP protocol can be extended to transfer some key parameters, we can easily deploy one unified solution to cover several different scenario, regardless they are in MPLS, Native IPv4, or IPv6 network. This can certainly relieve our burden to cope with the different solutions for different scenarios.  

We have also make the scenario/requirements presentation at Prague,  If you are interesting, please refer the material at CCDR Presentation Material <https://www.ietf.org/proceedings/99/slides/slides-99-teas-sessa-13-ccdr-centrally-control-dynamic-routing-scenario-simulation-and-suggestion-01.pdf> .

We have also compared the different approach protocols to fulfill them, and think PCEP may be the most candidate protocol to accomplish them.

Best Regards.

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Pce [mailto:[email-masked]] 代表 Jeff Tantsura
发送时间: 2017年7月25日 6:12
收件人: Igor Bryskin; [email-masked]; Jonathan Hardwick; [email-masked]
抄送: [email-masked]
主题: Re: [Pce] PCEP as an SDN controller protocol?

Cheers,

Jeff

Hi Stephanie,

You said:

Cheers,,

Igor

Hi,

Example:

…

IMO: 

Brgds,

Dear PCE WG

Many thanks

Jon