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

From: Dhruv Dhody <[email-masked]>
Date: Mon, 7 Aug 2017 11:10:47 +0000

Hi Oliver,

Sorry for a late response and thanks for engaging on this topic. With this response I would try to clear up some misconceptions, some context and counter-viewpoint.  Please see inline…

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 27 July 2017 23:42
To: Jonathan Hardwick <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] PCEP as an SDN controller protocol?

Hi Jon,

Thanks to open this thread. As many of you have already said, PCEP is already an SDN controller protocol since the work on stateful mode. But, IMHO, recent drafts doesn't go into the right direction. Let me explain:

1/ On PCE-LS. Of course there is already plenty of solution to learn the topology e.g. listen to IGP protocol, BGP-LS ... But, dont forget that the primary goal of PCE is to compute a path on a topology. This mean that the PCE need a graph which represent the network topology. This graph is extract from the TED, later fulfil by the topology learning mechanism. Why PCE-LS and other equivalent mechanism that collect topology information on a node by node basis ? Simply because you are unable to guarantee that the graph you extract from what you learn is accurate. Indeed, a node known its interfaces through what the administrator configure in this node. But, it doesn't know exactly to which neighbour it is connected while there is a protocol between node. In IP network, it is the role of the IGP. if there is an error in the node configuration, the IGP adjacency doesn't fire up and thus, IGP or BGP-LS will not report this link betwenn the two nodes. The graph is not complete, but not wrong. So when you learn the topology from the IGP you could guarantee that the link between two nodes corresponds effectively to what is really configured and physically connected. If there is no protocol between the nodes, you can't guarantee that what the node announce through PCEP-LS is accurate. E.g. Node A report Link A-B and node B report Link B-A instead of Link B-C and Link B-C instead of Link B-A due to a wrong manual configuration. You obtain a wrong topology and thus a wrong graph as you invert two links between two nodes. An you have no way to check it. So, in any case, and it is true for Optical / Transport network, you MUST run an IGP in your network to be sure that the topology is accurate and so to guarantee that the PCE work on a correct graph. A PCE working on a bad topology is painful. So, because you must run an IGP in your network, fulfil the PCE TED by listen the IGP or BGP-LS is the best solution. IMHO, PCE WG must not work on alternative solution to learn topology.
[[Dhruv Dhody]] When PCEP-LS is deployed in SDN mode (node by node basis), the node could run any protocol on the link to make verification. Adrian also mentioned in his reply, that device could be running, some form of discovery/verification protocol such as LMP, LLDP or even IGP on the per link basis. Each node is free to run any local mechanism to make sure that the link information is correct. The PCEP-LS extension is written in such a way that it could be used in any mode and independent of what the device choose to do. The PCEP-LS also support “remote data” (data a node would have learned via other protocols as IGP - remote nodes and links).

There are *already* multiple ways to learn TED at PCE – IGP-TE, BGP-LS, NetConf/ RestConf – Yang. The architecture allows that. The various implementation of SDN also already allow multiple SBI to achieve the same result, to allow the SDN solution to be deployed in various scenarios and to meet different requirements of the network. The PCEP-LS claims that there are specific deployments that would like to use PCEP-LS as the mechanism of choice, as the other SBI doesn’t work for them.  It does not claim that other mechanism should not be used ever, it is just another tool in the tool-set and IMHO we should allow it, if does no break/harm the network.

2/ On PCE-CC: Why extending PCE for such functionality ? For IP/MPLS, it is a non sense to study such solution especially with Segment Routing where you need to configure the edge node. For Optical / Transport network, well, again, it is not the good solution. First, vendor are opposed to open their ROADM to fine tune the configuration of the node disregarding if the protocol is PCEP or Netconf. So, if you intend to control an Optical / Transport network through an SDN Controller, the best is to use GMPLS. This keep vendor adjust the lambda without disclosing their IPR. Of course their is an initiative named OpenROADM which try to break this with its TransortPCE project within OpenDayLight. But look at the spec: it is yang model + NetConf. Not PCEP + extension. Again, IMHO, it is not the good solution to study.
[[Dhruv Dhody]] At the broad level this functionality already exist in PCE. This is just a special case for PCE initiated LSP, where the LSP is one hop. A PCE-enabled controller can speak PCEP as the SBI (i.e., it can communicate with each node along the path using PCEP).  That means that the controller can communicate with a conventional control plane-enabled NE using PCEP and can also use the same protocol to program individual NEs. It is just “OF-like” functionality for PCEP.

Yes, segment routing should also be supported, that is why PCECC-SR also exist. The two proposals are complementary. Please check the TEAS WG documents that explain this further.

Even TransportPCE philosophy is to allow both NetConf/PCEP as SBI, at least that what the material online says :)

3/ On PCECC-SR. This time, it could make sense. But, again, it is not the good way to proceed. In fact, when you use PCEP as control protocol, the node doesn't store the configuration like it does with NetConf in the standard-config, but it is store in the ephemeral config. This means that when the PCEP session break or the node reload, all the configuration is loose. If you need to wait PCE configuration to finish to boot e.g. advertise Segment Routing capabilities need SRGB, prefix SID ... it is not a safe solution. For that kind of information NetConf is superior to PCEP. In addition SPRING WG is working on yang model for NetConf for this purpose. Not on PCEP extension. One more time, IMHO, PCE WG must not spent energy in this direction.
[[Dhruv Dhody]] PCEP is not (and does not claim to be a) configuration protocol. Just like PCE-initiated LSP, you could set local policy on node to retain information when the session goes down. Since this is not configuration, that information would not survive the node restarts. This is true for any PCE interactions, and holds true for PCECC-SR as well. But the key is that, PCECC-SR is not trying to be a replacement of SR-Yang, it is a way for a PCE-based controller to instruct the SR forwarding action each node needs to make via PCEP, alongside the label stack instructions to the head node that needs to be attached to packets as they enter the network.

4/ What is missing? Yes. There is missing pieces in the puzzle. And spent energy to extra functions while essential ones are not ready is not the good way to progress. I'm referring to the traffic steering. I know that there is a very recent draft that propose a FlowSpec like in PCEP. Indeed, once a tunnel is setup through PCEP, you have no good tool to enforce the traffic in this newly created tunnel. Again, using NetConf is not a good idea as you mix ephemeral config and standard config. BGP-FlowSpec is too close too related to BGP and not ensure fine granularity you wish to steer the traffic into a tunnel. So, IMHO, this is the direction where the WG must go.
[[Dhruv Dhody]] Flowspec proposal is part of the overall PCECC framework and good, that you agree on usefulness of that part :)
But some of the key philosophy for other proposal is on the same line of enabling “PCEP as SBI protocol” between a PCE-based controller and the device to meet all requirements of central control of TE LSPs.

Now, just to finish, can you raise hand in the room to count the number of operational network where RSVP-TE is really used (I mean other than those used for FRR) ? number of operational network using Segment Routing ? And on this few subset the number that really use PCEP ? I'm pretty sure that I have sufficient finger in one hand to count them. And, if I restrict them to which are really need Path Computation with constraints (I mean path diversity, bandwidth reservation, delay constraint ...) I will be very happy if one hand raise in the room. So, from this poor operational usage, we absolutely don't know if PCEP is stable, scale at large ... Can we guarantee that a PCE could maintain a PCEP session with all nodes in a large network (say 1000 nodes and more) ? No. Because nobody report on the WG such experience like other WG do. Do we have interoperability issues ? Yes plenty. From all industrial and Open Source PCE solutions I tested no one implement correctly all the RFCs and recent drafts. So, before extending PCEP I suggest to concentrate on implementing what is already available. Make large experiment, see what's happen. Debug, report, adjust. Then we could think about the future of PCEP when we will collect sufficient background and experience. Up to know, from what I experiment, the technology is good, promising, but too young.
[[Dhruv Dhody]] I agree that some of the above issues exist. We should welcome any initiatives like Hackathon, Inter-Op etc that help with those.
Our aim here was to increase deployment of PCE by enabling PCEP to be a “full SBI protocol for TE LSPs”, this would help in moving some networks towards a centrally controlled environment with PCE at the center. Hopefully these extensions would help in that.

Regards,
Dhruv

my 2cts

Olivier

Le 20/07/2017 à 17:22, Jonathan Hardwick a écrit :
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

_______________________________________________

Pce mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/pce

_________________________________________________________________________________________________________________________

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.

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 7 Aug 2017 11:17:05 +0000

Hi,

One overall clarification -

The notion that PCEP extensions replaces other protocol is not the right way to look at the issue here. It should be looked at in complementary terms *only*.

There are some other points that some have made on the overarching principle. Let me try to summarize them from my point of view -

(1) Use of Yang based mechanism (NetConf/RestConf/gRPC/gNMI) instead, develop solution based on yang only.
Well to me that sounds like moving functionality that exist in PCEP to Yang (and isn't that the issue that has been pointed out for these PCEP extensions!).
Note that, I would never argue against developing solution based on Yang, as IMHO both should co-exist and have different considerations involved.
W.r.t binary in yang based solutions, though it is possible, it is not something that is implemented or available right now in NetConf/RestConf where as PCEP extensions have been implemented/tested, and moreover having multiple SBI options is good :)

(2) The functionality already exist in other protocols, and creating choice would lead to operation-issues.
I think it was pointed out by Adrian, we already have multiple protocols doing similar things today -
- OSPF-TE, ISIS-TE, BGP-LS, Yang based solutions (NetConf/RestConf/gRPC) for TED
- PCEP, Yang based solutions (NetConf/RestConf/gRPC) for path setup
- BGP-FlowSpec, Yang based solutions (NetConf/RestConf/gRPC) for flow
This PCEP proposals in question, did not create these choices, they exist already and adding PCEP in the mix does not change that.

---

Some of the arguments for not taking on this work could be applied to various other works that IETF has taken on in recent past :), looks like we apply the principles selectively.

IMHO if there exist deployments where the work makes sense, then it should be explored. If there are implementations that exist or are planned, and if there are a volunteers from multiple organizations who would like to continue to work on it, and if it does no harm - the work should continue.
There have been experiments, Hackathon and Bits-n-Bytes effort that showcased interest. There have been presentations from operators on how they plan to deploy and use these functionalities. There are implementation reports as well.

---

Jon's mail asked the question where do we stop? My answer would be -
- at "configuration"
- at use of PCEP for work beyond TE
- kitchen sink (as Jeff put it)
- harm to the network (non-backward compatible etc)
- incompatible with framework in TEAS

The work proposed in PCEP falls well under the umbrella of acceptable PCEP extensions IMHO.

Regards,
Dhruv

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

Dear PCE WG

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.

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.

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

---

From: Robert Varga <[email-masked]>
Date: Tue, 8 Aug 2017 01:13:37 +0200

> Hi Oliver,

Hello Dhruv,

> Sorry for a late response and thanks for engaging on this topic. With
> this response I would try to clear up some misconceptions, some context
> and counter-viewpoint.  Please see inline…
> 
>  
> 
> *From:*Pce [mailto:[email-masked]] *On Behalf Of
> [email-masked]
> *Sent:* 27 July 2017 23:42
> *To:* Jonathan Hardwick <[email-masked]>; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [Pce] PCEP as an SDN controller protocol?
> 
>  
> 
> Hi Jon,
> 
> Thanks to open this thread. As many of you have already said, PCEP is
> already an SDN controller protocol since the work on stateful mode. But,
> IMHO, recent drafts doesn't go into the right direction. Let me explain:
> 
> 1/ On PCE-LS. Of course there is already plenty of solution to learn the
> topology e.g. listen to IGP protocol, BGP-LS ... But, dont forget that
> the primary goal of PCE is to compute a path on a topology. This mean
> that the PCE need a graph which represent the network topology. This
> graph is extract from the TED, later fulfil by the topology learning
> mechanism. Why PCE-LS and other equivalent mechanism that collect
> topology information on a node by node basis ? Simply because you are
> unable to guarantee that the graph you extract from what you learn is
> accurate. Indeed, a node known its interfaces through what the
> administrator configure in this node. But, it doesn't know exactly to
> which neighbour it is connected while there is a protocol between node.
> In IP network, it is the role of the IGP. if there is an error in the
> node configuration, the IGP adjacency doesn't fire up and thus, IGP or
> BGP-LS will not report this link betwenn the two nodes. The graph is not
> complete, but not wrong. So when you learn the topology from the IGP you
> could guarantee that the link between two nodes corresponds effectively
> to what is really configured and physically connected. If there is no
> protocol between the nodes, you can't guarantee that what the node
> announce through PCEP-LS is accurate. E.g. Node A report Link A-B and
> node B report Link B-A instead of Link B-C and Link B-C instead of Link
> B-A due to a wrong manual configuration. You obtain a wrong topology and
> thus a wrong graph as you invert two links between two nodes. An you
> have no way to check it. So, in any case, and it is true for Optical /
> Transport network, you MUST run an IGP in your network to be sure that
> the topology is accurate and so to guarantee that the PCE work on a
> correct graph. A PCE working on a bad topology is painful. So, because
> you must run an IGP in your network, fulfil the PCE TED by listen the
> IGP or BGP-LS is the best solution. IMHO, PCE WG must not work on
> alternative solution to learn topology.
> 
> [[Dhruv Dhody]] When PCEP-LS is deployed in SDN mode (node by node
> basis), the node could run any protocol on the link to make
> verification. Adrian also mentioned in his reply, that device could be
> running, some form of discovery/verification protocol such as LMP, LLDP
> or even IGP on the per link basis. Each node is free to run any local
> mechanism to make sure that the link information is correct. The PCEP-LS
> extension is written in such a way that it could be used in any mode and
> independent of what the device choose to do. The PCEP-LS also support
> “remote data” (data a node would have learned via other protocols as IGP
> - remote nodes and links).
> 
>  
> 
> There are *already* multiple ways to learn TED at PCE – IGP-TE, BGP-LS,
> NetConf/ RestConf – Yang. The architecture allows that. The various
> implementation of SDN also already allow multiple SBI to achieve the
> same result, to allow the SDN solution to be deployed in various
> scenarios and to meet different requirements of the network. The PCEP-LS
> claims that there are specific deployments that would like to use
> PCEP-LS as the mechanism of choice, as the other SBI doesn’t work for
> them.  It does not claim that other mechanism should not be used ever,
> it is just another tool in the tool-set and IMHO we should allow it, if
> does no break/harm the network.

Yes. My question is here is whether the same can be achieved by
tunnelling the same data over BGP-LS.

What advantages does PCEP-LS bring to counter-balance the duplication of
protocol-level work?

Understanding that balance, does the WG feel it should focus on that work?

> 3/ On PCECC-SR. This time, it could make sense. But, again, it is not
> the good way to proceed. In fact, when you use PCEP as control protocol,
> the node doesn't store the configuration like it does with NetConf in
> the standard-config, but it is store in the ephemeral config. This means
> that when the PCEP session break or the node reload, all the
> configuration is loose. If you need to wait PCE configuration to finish
> to boot e.g. advertise Segment Routing capabilities need SRGB, prefix
> SID ... it is not a safe solution. For that kind of information NetConf
> is superior to PCEP. In addition SPRING WG is working on yang model for
> NetConf for this purpose. Not on PCEP extension. One more time, IMHO,
> PCE WG must not spent energy in this direction.
> 
> [[Dhruv Dhody]] PCEP is not (and does not claim to be a) configuration
> protocol. Just like PCE-initiated LSP, you could set local policy on
> node to retain information when the session goes down. Since this is not
> configuration, that information would not survive the node restarts.
> This is true for any PCE interactions, and holds true for PCECC-SR as
> well. But the key is that, PCECC-SR is not trying to be a replacement of
> SR-Yang, it is a way for a PCE-based controller to instruct the SR
> forwarding action each node needs to make via PCEP, alongside the label
> stack instructions to the head node that needs to be attached to packets
> as they enter the network.

I agree. From the protocol perspective, though, stateful PCEP with state
synchronization optimizations makes it possible to retain state across
reboots and skip state resynchronization.

On the other hand, I think NETCONF can make equivalent functionality
available via a rather simple extension, especially with (finally)
revised notifications.

I agree with Olivier that for state transfer design NETCONF/YANG is much
friendlier to extensions than PCEP. It makes much easier to reason about
data structure and interactions, which I think is extremely important
for other WGs.

Regards,
Robert

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 7 Aug 2017 19:39:17 -0400

> On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga <[email-masked]> wrote:
> 

TOM: Lets not forget that BGP-LS is deployed on a pretty wide scale now both 
on the device (pick any major router vendor) and client sides (ODL, etc…), so
the big advantage is that there is something that is not only working, but deployed
into production.  The latter is important from the IETF’s perspective, as 
running and deployed code with a good deal of deployment experience. 

	—Tom

> [email-masked]

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Mon, 7 Aug 2017 23:42:45 +0000

Something vaguely familiar about this thread …

-----Original Message-----
From: Pce <[email-masked]> on behalf of Thomas Nadeau <[email-masked]>
Date: Monday, August 7, 2017 at 7:39 PM
To: Robert Varga <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Pce] PCEP as an SDN controller protocol?

    
    	—Tom

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 8 Aug 2017 15:20:55 +0000

Hi Robert, Thomas, 

See inline...

> From: Thomas Nadeau [mailto:[email-masked]]
> Sent: 08 August 2017 05:09
> Cc: Dhruv Dhody <[email-masked]>; [email-masked];
> Jonathan Hardwick <[email-masked]>; [email-masked]; pce-
> [email-masked]
> >> this response I would try to clear up some misconceptions, some
> >> context and counter-viewpoint.  Please see inline…
> >>
> >>
> >>
> >> already an SDN controller protocol since the work on stateful mode.
> >> But, IMHO, recent drafts doesn't go into the right direction. Let me
> explain:
> >>
> >> 1/ On PCE-LS. Of course there is already plenty of solution to learn
> >> the topology e.g. listen to IGP protocol, BGP-LS ... But, dont forget
> >> that the primary goal of PCE is to compute a path on a topology. This
> >> mean that the PCE need a graph which represent the network topology.
> >> This graph is extract from the TED, later fulfil by the topology
> >> learning mechanism. Why PCE-LS and other equivalent mechanism that
> >> collect topology information on a node by node basis ? Simply because
> >> you are unable to guarantee that the graph you extract from what you
> >> learn is accurate. Indeed, a node known its interfaces through what
> >> the administrator configure in this node. But, it doesn't know
> >> exactly to which neighbour it is connected while there is a protocol
> between node.
> >> node configuration, the IGP adjacency doesn't fire up and thus, IGP
> >> or BGP-LS will not report this link betwenn the two nodes. The graph
> >> is not complete, but not wrong. So when you learn the topology from
> >> the IGP you could guarantee that the link between two nodes
> >> corresponds effectively to what is really configured and physically
> >> connected. If there is no protocol between the nodes, you can't
> >> guarantee that what the node announce through PCEP-LS is accurate.
> >> E.g. Node A report Link A-B and node B report Link B-A instead of
> >> Link B-C and Link B-C instead of Link B-A due to a wrong manual
> >> configuration. You obtain a wrong topology and thus a wrong graph as
> >> you invert two links between two nodes. An you have no way to check
> >> it. So, in any case, and it is true for Optical / Transport network,
> >> you MUST run an IGP in your network to be sure that the topology is
> >> accurate and so to guarantee that the PCE work on a correct graph. A
> >> PCE working on a bad topology is painful. So, because you must run an
> >> IGP in your network, fulfil the PCE TED by listen the IGP or BGP-LS
> >> is the best solution. IMHO, PCE WG must not work on alternative
> solution to learn topology.
> >>
> >> verification. Adrian also mentioned in his reply, that device could
> >> be running, some form of discovery/verification protocol such as LMP,
> >> LLDP or even IGP on the per link basis. Each node is free to run any
> >> local mechanism to make sure that the link information is correct.
> >> The PCEP-LS extension is written in such a way that it could be used
> >> in any mode and independent of what the device choose to do. The
> >> PCEP-LS also support “remote data” (data a node would have learned
> >> via other protocols as IGP
> >> There are *already* multiple ways to learn TED at PCE – IGP-TE,
> >> BGP-LS, NetConf/ RestConf – Yang. The architecture allows that. The
> >> various implementation of SDN also already allow multiple SBI to
> >> achieve the same result, to allow the SDN solution to be deployed in
> >> various scenarios and to meet different requirements of the network.
> >> The PCEP-LS claims that there are specific deployments that would
> >> like to use PCEP-LS as the mechanism of choice, as the other SBI
> >> doesn’t work for them.  It does not claim that other mechanism should
> >> not be used ever, it is just another tool in the tool-set and IMHO we
> >> should allow it, if does no break/harm the network.
> >
> > What advantages does PCEP-LS bring to counter-balance the duplication
> > of protocol-level work?
> >
> TOM: Lets not forget that BGP-LS is deployed on a pretty wide scale now
> both on the device (pick any major router vendor) and client sides (ODL,
> etc…), so the big advantage is that there is something that is not only
> working, but deployed into production.  The latter is important from the
> IETF’s perspective, as running and deployed code with a good deal of
> deployment experience.
> 
> 	—Tom
> 
> 
[[[Dhruv Dhody]]] Let me try another way - 

If I am making a decision on which protocol to choose, I would consider - 

If the network is already running IGP, and the PCE can join the IGP domain, let's go IGP-TE way.  
If the network can export data via BGP-LS, then PCE can go BGP-LS way.
But there are deployments where -
- PCE can't join IGP domain 
- or Network doesn’t run BGP-LS (optical)
- or PCE is being run in a central control mode (PCECC)
	- and using PCEP for both learning from / programming the device is advantageous
- H-PCE mode, where PCEP is used for communication between parent PCE and child PCE
	- PCEP-LS could be used to communicate the abstract domain topology (border nodes, links)

Our intention has not been to say don’t use BGP-LS or any other existing mechanism, rather it is to say that there are some deployment scenarios where PCEP-LS makes sense and let us offer that choice for those deployments.  

> >> the good way to proceed. In fact, when you use PCEP as control
> >> protocol, the node doesn't store the configuration like it does with
> >> NetConf in the standard-config, but it is store in the ephemeral
> >> config. This means that when the PCEP session break or the node
> >> reload, all the configuration is loose. If you need to wait PCE
> >> configuration to finish to boot e.g. advertise Segment Routing
> >> capabilities need SRGB, prefix SID ... it is not a safe solution. For
> >> that kind of information NetConf is superior to PCEP. In addition
> >> SPRING WG is working on yang model for NetConf for this purpose. Not
> >> on PCEP extension. One more time, IMHO, PCE WG must not spent energy in
> this direction.
> >>
> >> [[Dhruv Dhody]] PCEP is not (and does not claim to be a)
> >> configuration protocol. Just like PCE-initiated LSP, you could set
> >> local policy on node to retain information when the session goes
> >> down. Since this is not configuration, that information would not
> survive the node restarts.
> >> well. But the key is that, PCECC-SR is not trying to be a replacement
> >> of SR-Yang, it is a way for a PCE-based controller to instruct the SR
> >> forwarding action each node needs to make via PCEP, alongside the
> >> label stack instructions to the head node that needs to be attached
> >> to packets as they enter the network.
> >
> > I agree. From the protocol perspective, though, stateful PCEP with
> > state synchronization optimizations makes it possible to retain state
> > across reboots and skip state resynchronization.
> >
> > I agree with Olivier that for state transfer design NETCONF/YANG is
> > much friendlier to extensions than PCEP. It makes much easier to
> > reason about data structure and interactions, which I think is
> > extremely important for other WGs.
> >
[[[Dhruv Dhody]]] My point above was that in PCECC-SR, the interaction between PCE and device should not be considered as configurations. It is a case where PCE is managing the label space, allocating labels and programming the device with instructions. Further if you are using PCE to program the label stack at the head node, this approach suggest using the same protocol to program the label instructions on all nodes. 

I feel there is space for both Netconf/Yang and PCEP based solutions in parallel. 

Thanks! 
Dhruv

---

From: John E Drake <[email-masked]>
Date: Tue, 8 Aug 2017 17:32:21 +0000

Hi,

So, what exactly is it that PCEP should not do?

Yours Irrespectively,

John

> From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
> Sent: Tuesday, August 8, 2017 11:21 AM
> To: Thomas Nadeau <[email-masked]>; Robert Varga <[email-masked]>
> Cc: [email-masked]; [email-masked]
> > Jonathan Hardwick <[email-masked]>; [email-masked];
> > pce- [email-masked]
> > >> Sorry for a late response and thanks for engaging on this topic.
> > >> With this response I would try to clear up some misconceptions,
> > >> some context and counter-viewpoint.  Please see inline…
> > >>
> > >>
> > >>
> > >> Thanks to open this thread. As many of you have already said, PCEP
> > >> is already an SDN controller protocol since the work on stateful mode.
> > >> 1/ On PCE-LS. Of course there is already plenty of solution to
> > >> learn the topology e.g. listen to IGP protocol, BGP-LS ... But,
> > >> dont forget that the primary goal of PCE is to compute a path on a
> > >> topology. This mean that the PCE need a graph which represent the
> network topology.
> > >> collect topology information on a node by node basis ? Simply
> > >> because you are unable to guarantee that the graph you extract from
> > >> what you learn is accurate. Indeed, a node known its interfaces
> > >> through what the administrator configure in this node. But, it
> > >> doesn't know exactly to which neighbour it is connected while there
> > >> is a protocol
> > between node.
> > >> In IP network, it is the role of the IGP. if there is an error in
> > >> the node configuration, the IGP adjacency doesn't fire up and thus,
> > >> IGP or BGP-LS will not report this link betwenn the two nodes. The
> > >> graph is not complete, but not wrong. So when you learn the
> > >> topology from the IGP you could guarantee that the link between two
> > >> nodes corresponds effectively to what is really configured and
> > >> physically connected. If there is no protocol between the nodes,
> > >> you can't guarantee that what the node announce through PCEP-LS is
> accurate.
> > >> configuration. You obtain a wrong topology and thus a wrong graph
> > >> as you invert two links between two nodes. An you have no way to
> > >> check it. So, in any case, and it is true for Optical / Transport
> > >> network, you MUST run an IGP in your network to be sure that the
> > >> topology is accurate and so to guarantee that the PCE work on a
> > >> correct graph. A PCE working on a bad topology is painful. So,
> > >> because you must run an IGP in your network, fulfil the PCE TED by
> > >> listen the IGP or BGP-LS is the best solution. IMHO, PCE WG must
> > >> not work on alternative
> > >> be running, some form of discovery/verification protocol such as
> > >> LMP, LLDP or even IGP on the per link basis. Each node is free to
> > >> run any local mechanism to make sure that the link information is correct.
> > >> The PCEP-LS extension is written in such a way that it could be
> > >> used in any mode and independent of what the device choose to do.
> > >> The PCEP-LS also support “remote data” (data a node would have
> > >> learned via other protocols as IGP
> > >> achieve the same result, to allow the SDN solution to be deployed
> > >> in various scenarios and to meet different requirements of the network.
> > >> doesn’t work for them.  It does not claim that other mechanism
> > >> should not be used ever, it is just another tool in the tool-set
> > >> and IMHO we should allow it, if does no break/harm the network.
> > >
> > > What advantages does PCEP-LS bring to counter-balance the
> > > duplication of protocol-level work?
> > >
> > TOM: Lets not forget that BGP-LS is deployed on a pretty wide scale
> > now both on the device (pick any major router vendor) and client sides
> > (ODL, etc…), so the big advantage is that there is something that is
> > not only working, but deployed into production.  The latter is
> > important from the IETF’s perspective, as running and deployed code
> > with a good deal of deployment experience.
> >
> > 	—Tom
> >
> >
> Our intention has not been to say don’t use BGP-LS or any other existing
> mechanism, rather it is to say that there are some deployment scenarios where
> PCEP-LS makes sense and let us offer that choice for those deployments.
> 
> > >
> > >> 3/ On PCECC-SR. This time, it could make sense. But, again, it is
> > >> not the good way to proceed. In fact, when you use PCEP as control
> > >> protocol, the node doesn't store the configuration like it does
> > >> with NetConf in the standard-config, but it is store in the
> > >> ephemeral config. This means that when the PCEP session break or
> > >> the node reload, all the configuration is loose. If you need to
> > >> wait PCE configuration to finish to boot e.g. advertise Segment
> > >> Routing capabilities need SRGB, prefix SID ... it is not a safe
> > >> solution. For that kind of information NetConf is superior to PCEP.
> > >> In addition SPRING WG is working on yang model for NetConf for this
> > >> purpose. Not on PCEP extension. One more time, IMHO, PCE WG must
> > >> not spent energy in
> > this direction.
> > >>
> > >> This is true for any PCE interactions, and holds true for PCECC-SR
> > >> as well. But the key is that, PCECC-SR is not trying to be a
> > >> replacement of SR-Yang, it is a way for a PCE-based controller to
> > >> instruct the SR forwarding action each node needs to make via PCEP,
> > >> alongside the label stack instructions to the head node that needs
> > >> to be attached to packets as they enter the network.
> > >
> > > state synchronization optimizations makes it possible to retain
> > > state across reboots and skip state resynchronization.
> > >
> [[[Dhruv Dhody]]] My point above was that in PCECC-SR, the interaction
> between PCE and device should not be considered as configurations. It is a
> case where PCE is managing the label space, allocating labels and
> programming the device with instructions. Further if you are using PCE to
> program the label stack at the head node, this approach suggest using the
> same protocol to program the label instructions on all nodes.
>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 8 Aug 2017 17:46:29 +0000 (UTC)

Excellent question, John. Wonder myself. Let's ask Gert. He is very good at defining thibgs they are not :-)
Yours also irresoectively,igor

Sent from Yahoo Mail on Android 
 
  On Tue, Aug 8, 2017 at 1:32 PM, John E Drake<[email-masked]> wrote:   Hi,

Yours Irrespectively,

John

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 8 Aug 2017 18:08:12 +0000

Hi John, Igor,

I tried to answer that question in another thread. Here is my response -

Jon’s original mail asked the question where do we stop? My answer would be -
- at "configuration"

I sure we can add more points to the list!

Thanks!
Dhruv

From: Igor Bryskin [mailto:[email-masked]]
Sent: 08 August 2017 23:16
To: [email-masked]; Dhruv Dhody <[email-masked]>; Thomas Nadeau <[email-masked]>; Robert Varga <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] PCEP as an SDN controller protocol?

Yours also irresoectively,
igor
Sent from Yahoo Mail on Android<https://overview.mail.yahoo.com/mobile/?.src=Android>

On Tue, Aug 8, 2017 at 1:32 PM, John E Drake
<[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Yours Irrespectively,

John

> From: Pce [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dhruv Dhody
> To: Thomas Nadeau <[email-masked]<mailto:[email-masked]>>; Robert Varga <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > From: Thomas Nadeau [mailto:[email-masked]<mailto:[email-masked]>]
> > To: Robert Varga <[email-masked]<mailto:[email-masked]>>
> > Cc: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> > Jonathan Hardwick <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> > pce- [email-masked]<mailto:[email-masked]>
> > > On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga <[email-masked]<mailto:[email-masked]>> wrote:
> > >
> > >> *From:*Pce [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of
> > >> [email-masked]<mailto:[email-masked]>
> > >> *To:* Jonathan Hardwick <[email-masked]<mailto:[email-masked]>>;
> > >> [email-masked]<mailto:[email-masked]>
> > >> *Cc:* [email-masked]<mailto:[email-masked]>