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

[Dhruv Dhody]

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

I sure we can add more points to the list!

Thanks!
Dhruv

From: Igor Bryskin [mailto:i_brys...@yahoo.com]
Sent: 08 August 2017 23:16
To: jdr...@juniper.net; Dhruv Dhody <dhruv.dh...@huawei.com>; Thomas Nadeau 
<tnad...@lucidvision.com>; Robert Varga <n...@hq.sk>
Cc: pce@ietf.org; pce-cha...@ietf.org
Subject: Re: [Pce] PCEP as an SDN controller protocol?

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<https://overview.mail.yahoo.com/mobile/?.src=Android>

On Tue, Aug 8, 2017 at 1:32 PM, John E Drake
<jdr...@juniper.net<mailto:jdr...@juniper.net>> wrote:
Hi,

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

Yours Irrespectively,

John


> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>] On 
> Behalf Of Dhruv Dhody
> Sent: Tuesday, August 8, 2017 11:21 AM
> To: Thomas Nadeau <tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>>; 
> Robert Varga <n...@hq.sk<mailto:n...@hq.sk>>
> Cc: pce@ietf.org<mailto:pce@ietf.org>; 
> pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
> Subject: Re: [Pce] PCEP as an SDN controller protocol?
>
> Hi Robert, Thomas,
>
> See inline...
>
> > -Original Message-
> > From: Thomas Nadeau 
> > [mailto:tnad...@lucidvision.com<mailto:tnad...@lucidvision.com>]
> > Sent: 08 August 2017 05:09
> > To: Robert Varga <n...@hq.sk<mailto:n...@hq.sk>>
> > Cc: Dhruv Dhody <dhruv.dh...@huawei.com<mailto:dhruv.dh...@huawei.com>>; 
> > olivier.dug...@orange.com<mailto:olivier.dug...@orange.com>;
> > Jonathan Hardwick 
> > <jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>>;
> >  pce@ietf.org<mailto:pce@ietf.org>;
> > pce- cha...@ietf.org<mailto:cha...@ietf.org>
> > Subject: Re: [Pce] PCEP as an SDN controller protocol?
> >
> >
> > > On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga 
> > > <n...@hq.sk<mailto:n...@hq.sk>> wrote:
> > >
> > > On 07/08/17 13:10, Dhruv Dhody wrote:
> > >> 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:pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>] 
> > >> *On Behalf Of
> > >> *olivier.dug...@orange.com<mailto:olivier.dug...@orange.com>
> > >> *Sent:* 27 July 2017 23:42
> > >> *To:* Jonathan Hardwick 
> > >> <jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>>;
> > >> pce@ietf.org<mailto:pce@ietf.org>
> > >> *Cc:* pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
> > >> *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

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

[Igor Bryskin]

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<jdr...@juniper.net> wrote:   Hi,

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

Yours Irrespectively,

John


> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
> Sent: Tuesday, August 8, 2017 11:21 AM
> To: Thomas Nadeau <tnad...@lucidvision.com>; Robert Varga <n...@hq.sk>
> Cc: pce@ietf.org; pce-cha...@ietf.org
> Subject: Re: [Pce] PCEP as an SDN controller protocol?
> 
> Hi Robert, Thomas,
> 
> See inline...
> 
> > -Original Message-
> > From: Thomas Nadeau [mailto:tnad...@lucidvision.com]
> > Sent: 08 August 2017 05:09
> > To: Robert Varga <n...@hq.sk>
> > Cc: Dhruv Dhody <dhruv.dh...@huawei.com>; olivier.dug...@orange.com;
> > Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org;
> > pce- cha...@ietf.org
> > Subject: Re: [Pce] PCEP as an SDN controller protocol?
> >
> >
> > > On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga <n...@hq.sk> wrote:
> > >
> > > On 07/08/17 13:10, Dhruv Dhody wrote:
> > >> 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:pce-boun...@ietf.org] *On Behalf Of
> > >> *olivier.dug...@orange.com
> > >> *Sent:* 27 July 2017 23:42
> > >> *To:* Jonathan Hardwick <jonathan.hardw...@metaswitch.com>;
> > >> pce@ietf.org
> > >> *Cc:* pce-cha...@ietf.org
> > >> *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 

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

[John E Drake]

Hi,

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

Yours Irrespectively,

John


> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
> Sent: Tuesday, August 8, 2017 11:21 AM
> To: Thomas Nadeau <tnad...@lucidvision.com>; Robert Varga <n...@hq.sk>
> Cc: pce@ietf.org; pce-cha...@ietf.org
> Subject: Re: [Pce] PCEP as an SDN controller protocol?
> 
> Hi Robert, Thomas,
> 
> See inline...
> 
> > -Original Message-
> > From: Thomas Nadeau [mailto:tnad...@lucidvision.com]
> > Sent: 08 August 2017 05:09
> > To: Robert Varga <n...@hq.sk>
> > Cc: Dhruv Dhody <dhruv.dh...@huawei.com>; olivier.dug...@orange.com;
> > Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org;
> > pce- cha...@ietf.org
> > Subject: Re: [Pce] PCEP as an SDN controller protocol?
> >
> >
> > > On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga <n...@hq.sk> wrote:
> > >
> > > On 07/08/17 13:10, Dhruv Dhody wrote:
> > >> 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:pce-boun...@ietf.org] *On Behalf Of
> > >> *olivier.dug...@orange.com
> > >> *Sent:* 27 July 2017 23:42
> > >> *To:* Jonathan Hardwick <jonathan.hardw...@metaswitch.com>;
> > >> pce@ietf.org
> > >> *Cc:* pce-cha...@ietf.org
> > >> *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]] Wh

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

[Ken Gray (kegray)]

Something vaguely familiar about this thread …

-Original Message-
From: Pce <pce-boun...@ietf.org> on behalf of Thomas Nadeau 
<tnad...@lucidvision.com>
Date: Monday, August 7, 2017 at 7:39 PM
To: Robert Varga <n...@hq.sk>
Cc: "pce-cha...@ietf.org" <pce-cha...@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Subject: Re: [Pce] PCEP as an SDN controller protocol?


> On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga <n...@hq.sk> wrote:
> 
> On 07/08/17 13:10, Dhruv Dhody wrote:
>> 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:pce-boun...@ietf.org] *On Behalf Of
>> *olivier.dug...@orange.com
>> *Sent:* 27 July 2017 23:42
    >> *To:* Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org
>> *Cc:* pce-cha...@ietf.org
>> *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
>> impleme

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

[Thomas Nadeau]

> On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga <n...@hq.sk> wrote:
> 
> On 07/08/17 13:10, Dhruv Dhody wrote:
>> 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:pce-boun...@ietf.org] *On Behalf Of
>> *olivier.dug...@orange.com
>> *Sent:* 27 July 2017 23:42
>> *To:* Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org
>> *Cc:* pce-cha...@ietf.org
>> *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 

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

[Robert Varga]

On 07/08/17 13:10, Dhruv Dhody wrote:
> 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:pce-boun...@ietf.org] *On Behalf Of
> *olivier.dug...@orange.com
> *Sent:* 27 July 2017 23:42
> *To:* Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org
> *Cc:* pce-cha...@ietf.org
> *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 i

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

[Dhruv Dhody]

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:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 20 July 2017 20:52
To: pce@ietf.org
Cc: pce-cha...@ietf.org
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 

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

[Dhruv Dhody]

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:pce-boun...@ietf.org] On Behalf Of olivier.dug...@orange.com
Sent: 27 July 2017 23:42
To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org
Cc: pce-cha...@ietf.org
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 ini

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

[John E Drake]

Olivier,

Very cogently argued

Yours Irrespectively,

John

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of olivier.dug...@orange.com
Sent: Thursday, July 27, 2017 2:12 PM
To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org
Cc: pce-cha...@ietf.org
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.

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.

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.

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.

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

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

[olivier.dugeon]

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 
topologye.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-Band node B report Link B-A instead of Link B-C and LinkB-C 
instead of Link B-A due to a wrong manual configuration. You obtain a wrong 
topology and thus a wrong graphas 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, PCEWG must not work on alternative solution to
learn topology.

2/ On PCE-CC: Why extending PCE for such functionality ? For IP/MPLS, it is a 
non sense to study such solutionespecially 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 
anSDN Controller, the best is to useGMPLS. This keep vendor adjust the lambda 
without disclosing their IPR. Of course their is an initiative named OpenROADM 
which try to break thiswith 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.

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 isnot 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.

4/ What is missing? Yes. There is missing pieces in the puzzle. And spent 
energy to extra functions while essentialones are not ready is not the good way 
to progress. I'm referring to thetraffic 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.

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, 

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

[Leeyoung]

I think there are much misunderstanding on what PCEP-LS is. Adrian pointed out 
an accurate assessment of what PCEP-LS is doing with TE information:

>> In this network, the question to address is "How does the PCE learn the 
>> topology of the TE network?" I believe that at least some of the proponents 
>> of PCEP-LS are suggesting that *each* NE can have a PCEP session that is 
>> used not only for programming the NE for forwarding, but also for reporting 
>> a fragment of the topology. In other words, PCEP-LS would be used by *each* 
>> NE to report its local links. (Whether this assumes that the NEs are running 
>> some form of discovery/verification protocol such as LMP is maybe something 
>> we should also be talking about.)

>> So maybe what is needed to make this clear is a tiny little architecture 
>> statement? That way people hearing "PCEP-LS" will not think "dump the whole 
>> topology from a single node in the network" the way that we have become 
>> accustomed to thinking with BGP-LS, but will see the picture being solved 
>> and will understand the flow of information.

Regards,
Young



From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Tuesday, July 25, 2017 5:59 AM
To: 'Daniele Ceccarelli' <daniele.ceccare...@ericsson.com>; 'Julien Meuric' 
<julien.meu...@orange.com>; pce@ietf.org
Cc: pce-cha...@ietf.org
Subject: Re: [Pce] PCEP as an SDN controller protocol?

I think it is all slightly a distraction :-)

It is possible to run an MCN without a routing protocol depending on the 
topology of the MCN. Many MCNs can be achieved with relatively simple static 
routes.

Statements (Haomian) that optical devices cannot run BGP-LS seem to me to be an 
exaggeration. I understand why they choose to not do it.

The use of BGP-LS or PCEP-LS in a network where an IGP-TE is running may be 
excessive since making a PCE a passive partner in an IGP is very cheap and easy.



All of these things are an aside to the deployment models being discussed. 
Those models are more closely SDN-based, and that fact may be missing from the 
conversation.

Consider a network that runs without a horizontal control plane (i.e., no 
IGP-TE and no signaling protocol). In this mode, devices are individually 
provisioned from a controller using a protocol such as PCEP in a PCE-CC mode. 
The controller-device communications run through an MCN, but that network could 
be fairly simply constructed of P2P forwarding paths or (in the case of an 
in-fiber MCN) by taking advantage of default static routes.

In this network, the question to address is "How does the PCE learn the 
topology of the TE network?" I believe that at least some of the proponents of 
PCEP-LS are suggesting that *each* NE can have a PCEP session that is used not 
only for programming the NE for forwarding, but also for reporting a fragment 
of the topology. In other words, PCEP-LS would be used by *each* NE to report 
its local links. (Whether this assumes that the NEs are running some form of 
discovery/verification protocol such as LMP is maybe something we should also 
be talking about.)

I find myself asking, "How does an individual NE know its configuration? What 
identities does it give to links? Where do those links connect to?" If that 
information is pushed by configuration, couldn't that configuration station 
push that information to the PCE as well.

So maybe what is needed to make this clear is a tiny little architecture 
statement? That way people hearing "PCEP-LS" will not think "dump the whole 
topology from a single node in the network" the way that we have become 
accustomed to thinking with BGP-LS, but will see the picture being solved and 
will understand the flow of information.

Thanks,
Adrian


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: 25 July 2017 11:27
To: Julien Meuric; pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
Subject: Re: [Pce] PCEP as an SDN controller protocol?

HI Julien,

your correction is…correct 

You’re referring to the protocols running on the DCN, or more appropriately on 
the MCN, right? The IGP is usually non TE and just providing reachability 
info…but as PCEP can be modified for other purposes, they can be modified as 
well. On this I agree with you.

Cheers
Daniele

From: Julien Meuric [mailto:julien.meu...@orange.com]
Sent: martedì 25 luglio 2017 11:36
To: Daniele Ceccarelli 
<daniele.ceccare...@ericsson.com<mailto:daniele.ceccare...@ericsson.com>>; 
pce@ietf.org<mailto:pce@ietf.org>
Cc: Jonathan Hardwick 
<jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>>; 
pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
Subject: Re: PCEP as an SDN controller protocol?

Hi Daniele,

[Operator hat

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

[Jeff Tantsura]

++1

 

Cheers,

Jeff

 

From: Pce <pce-boun...@ietf.org> on behalf of Cyril Margaria 
<cyril.marga...@gmail.com>
Date: Tuesday, July 25, 2017 at 12:25
To: LITKOWSKI Stephane DTF/DERX <stephane.litkow...@orange.com>
Cc: "pce@ietf.org" <pce@ietf.org>, "pce-cha...@ietf.org" <pce-cha...@ietf.org>
Subject: Re: [Pce] PCEP as an SDN controller protocol?

 

+1, 

 

PCEP is rather efficient at dealing with paths and constraints. 

PCE-CC , as someone mentioned earlier, can be seen as 1-hop LSPs, there could 
be minimum protocol extensions.  

 

PCEP-LS is redoing links-state flooding over PCEP, using the same elements as 
existing protocols. This sounds OK as an experiment but the operational or 
scale advantages to it seems very limited. 

 

I don't think we should overload PCEP to carry IGP information (nor device 
configuration) 

 

My 2 cents

Cyril

 

 

On 24 July 2017 at 08:02, <stephane.litkow...@orange.com> wrote:

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:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Thursday, July 20, 2017 17:22
To: pce@ietf.org
Cc: pce-cha...@ietf.org
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 
specifi

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

[Cyril Margaria]

+1,

PCEP is rather efficient at dealing with paths and constraints.
PCE-CC , as someone mentioned earlier, can be seen as 1-hop LSPs, there
could be minimum protocol extensions.

PCEP-LS is redoing links-state flooding over PCEP, using the same elements
as existing protocols. This sounds OK as an experiment but the operational
or scale advantages to it seems very limited.

I don't think we should overload PCEP to carry IGP information (nor device
configuration)

My 2 cents
Cyril


On 24 July 2017 at 08:02,  wrote:

> 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:pce-boun...@ietf.org] *On Behalf Of *Jonathan Hardwick
> *Sent:* Thursday, July 20, 2017 17:22
> *To:* pce@ietf.org
> *Cc:* pce-cha...@ietf.org
> *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 

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

[Scharf, Michael (Nokia - DE/Stuttgart)]

PCEP-LS looks to me like an experiment.

For IP, the value proposition of PCEP-LS compared to e.g. BGP-LS is unclear to 
me.

For optical nodes, I think an NMS or controller can deal with this without 
requiring PCEP-LS, e.g., using NETCONF.

For communication between controllers, typical use cases I am aware of require 
functions beyond the PCEP extensions listed below, so it is not obvious whether 
PCEP extensions would be sufficient.

Do we really want to throw spaghettis to the wall?

Michael


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Thursday, July 20, 2017 5:22 PM
To: pce@ietf.org
Cc: pce-cha...@ietf.org
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

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Belotti, Sergio (Nokia - IT/Vimercate)]

Hi Dhruv ,

Never said to stop work on PCEP, but in the mail below the intention is to 
extend protocol in order to be capable to replace other protocol that already 
deal with specific functionality. The example for ACTN, can be applied as well 
for functionality like flooding and signaling already covered by specific 
protocols.

Cheers
Sergio


From: dhruvdh...@gmail.com [mailto:dhruvdh...@gmail.com] On Behalf Of Dhruv 
Dhody
Sent: Tuesday, July 25, 2017 5:16 PM
To: Belotti, Sergio (Nokia - IT/Vimercate) 
Cc: Jonathan Hardwick ; pce@ietf.org; 
pce-cha...@ietf.org
Subject: Re: PCEP as an SDN controller protocol?

Hi Sergio,

We also have a PCE WG document which describes the use of PCEP in ACTN - 
https://datatracker.ietf.org/doc/draft-ietf-pce-applicability-actn/. Yes, ACTN 
solution via Yang models is perfectly valid. But that should not be a reason, 
to stop work on PCEP IMHO.

Regards,
Dhruv


On Tue, Jul 25, 2017 at 8:22 PM, Belotti, Sergio (Nokia - IT/Vimercate) 
> wrote:
Hi Jon, all

Looking at the mail below, it seems as though you derive needs to extend PCEP , 
from the fact PCEP can be consider as having a root role in ACTN context.
Well, while ACTN does not mandate any protocol specific in his architecture, 
the basic toolset  to operate ACTN architecture is based on NETCON/YANG model, 
as well described in the draft 
https://datatracker.ietf.org/doc/draft-zhang-teas-actn-yang/ . Topology model 
is used at MPI level to get topology information augmented with needed 
technology specific information  and Tunnel model  (and related technology 
specific augmentation) is used to create tunnel inside the network ,  for 
CMI,VN Yang model is used to specifically operate on VN. No mandatory need for 
PCEP extension to cover ACTN functionality, so I have a clear concern to go 
ahead with this request of PCEP extension as described in this mail.

Thanks
Sergio

From: Pce [mailto:pce-boun...@ietf.org] On Behalf 
Of Jonathan Hardwick
Sent: Thursday, July 20, 2017 5:22 PM
To: pce@ietf.org
Cc: pce-cha...@ietf.org
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 

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

[Dhruv Dhody]

Hi Sergio,

We also have a PCE WG document which describes the use of PCEP in ACTN -
https://datatracker.ietf.org/doc/draft-ietf-pce-applicability-actn/. Yes,
ACTN solution via Yang models is perfectly valid. But that should not be a
reason, to stop work on PCEP IMHO.

Regards,
Dhruv


On Tue, Jul 25, 2017 at 8:22 PM, Belotti, Sergio (Nokia - IT/Vimercate) <
sergio.belo...@nokia.com> wrote:

> Hi Jon, all
>
>
>
> Looking at the mail below, it seems as though you derive needs to extend
> PCEP , from the fact PCEP can be consider as having a root role in ACTN
> context.
>
> Well, while ACTN does not mandate any protocol specific in his
> architecture, the basic toolset  to operate ACTN architecture is based on
> NETCON/YANG model, as well described in the draft
> https://datatracker.ietf.org/doc/draft-zhang-teas-actn-yang/ . Topology
> model is used at MPI level to get topology information augmented with
> needed technology specific information  and Tunnel model  (and related
> technology specific augmentation) is used to create tunnel inside the
> network ,  for CMI,VN Yang model is used to specifically operate on VN. No
> mandatory need for PCEP extension to cover ACTN functionality, so I have a
> clear concern to go ahead with this request of PCEP extension as described
> in this mail.
>
>
>
> Thanks
>
> Sergio
>
>
>
> *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Jonathan Hardwick
> *Sent:* Thursday, July 20, 2017 5:22 PM
> *To:* pce@ietf.org
> *Cc:* pce-cha...@ietf.org
> *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 

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

[Igor Bryskin]

Stephanie,

You said that there are better ways to extract topologies and configure things 
than using PCEP.

You forgot to mention the issue of collecting telemetry and I hope you are not 
suggesting using PCEP for that. In fact, it is widely accepted that the best 
way to go about the telemetry collection is via using gRPC/protobufs. 
Considering that:

a)  gRPC can do all other things , including path provisioning on the 
devices, policy pushing, topology discovery/configuration at least as well as 
any other tool you mentioned (in fact, I believe far better);

b) Daniele's point of operators requiring a single tool for all network 
control purposes;

c)  gRPC being very well documented and tested open source project, 
adaptable for big and small systems/devices
could you give a reason, why not to go with gRPC in the long term (and RESTCONF 
in the short term) ?

Cheers,
Igor

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: Tuesday, July 25, 2017 8:50 AM
To: Igor Bryskin; Jonathan Hardwick; pce@ietf.org
Cc: pce-cha...@ietf.org
Subject: RE: PCEP as an SDN controller protocol?

Hi,

You can use RESTCONF, NETCONF or anything similar (CLI ?) to provision paths as 
you can do with PCEP. Nothing prevents to do that.

Brgds,

From: Igor Bryskin [mailto:igor.brys...@huawei.com]
Sent: Monday, July 24, 2017 14:53
To: LITKOWSKI Stephane OBS/OINIS; Jonathan Hardwick; pce@ietf.org
Cc: pce-cha...@ietf.org
Subject: RE: 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:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>
Sent: Monday, July 24, 2017 8:03 AM
To: Jonathan Hardwick; pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
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 :) ?
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:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Thursday, July 20, 2017 17:22
To: pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
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 

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

[Belotti, Sergio (Nokia - IT/Vimercate)]

Hi Jon, all

Looking at the mail below, it seems as though you derive needs to extend PCEP , 
from the fact PCEP can be consider as having a root role in ACTN context.
Well, while ACTN does not mandate any protocol specific in his architecture, 
the basic toolset  to operate ACTN architecture is based on NETCON/YANG model, 
as well described in the draft 
https://datatracker.ietf.org/doc/draft-zhang-teas-actn-yang/ . Topology model 
is used at MPI level to get topology information augmented with needed 
technology specific information  and Tunnel model  (and related technology 
specific augmentation) is used to create tunnel inside the network ,  for 
CMI,VN Yang model is used to specifically operate on VN. No mandatory need for 
PCEP extension to cover ACTN functionality, so I have a clear concern to go 
ahead with this request of PCEP extension as described in this mail.

Thanks
Sergio

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Thursday, July 20, 2017 5:22 PM
To: pce@ietf.org
Cc: pce-cha...@ietf.org
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

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Adrian Farrel]

I think it is all slightly a distraction :-)
 
It is possible to run an MCN without a routing protocol depending on the 
topology of the MCN. Many MCNs can be achieved with relatively simple static 
routes.
 
Statements (Haomian) that optical devices cannot run BGP-LS seem to me to be an 
exaggeration. I understand why they choose to not do it.
 
The use of BGP-LS or PCEP-LS in a network where an IGP-TE is running may be 
excessive since making a PCE a passive partner in an IGP is very cheap and easy.
 
 
 
All of these things are an aside to the deployment models being discussed. 
Those models are more closely SDN-based, and that fact may be missing from the 
conversation.
 
Consider a network that runs without a horizontal control plane (i.e., no 
IGP-TE and no signaling protocol). In this mode, devices are individually 
provisioned from a controller using a protocol such as PCEP in a PCE-CC mode. 
The controller-device communications run through an MCN, but that network could 
be fairly simply constructed of P2P forwarding paths or (in the case of an 
in-fiber MCN) by taking advantage of default static routes.
 
In this network, the question to address is "How does the PCE learn the 
topology of the TE network?" I believe that at least some of the proponents of 
PCEP-LS are suggesting that *each* NE can have a PCEP session that is used not 
only for programming the NE for forwarding, but also for reporting a fragment 
of the topology. In other words, PCEP-LS would be used by *each* NE to report 
its local links. (Whether this assumes that the NEs are running some form of 
discovery/verification protocol such as LMP is maybe something we should also 
be talking about.)
 
I find myself asking, "How does an individual NE know its configuration? What 
identities does it give to links? Where do those links connect to?" If that 
information is pushed by configuration, couldn't that configuration station 
push that information to the PCE as well.
 
So maybe what is needed to make this clear is a tiny little architecture 
statement? That way people hearing "PCEP-LS" will not think "dump the whole 
topology from a single node in the network" the way that we have become 
accustomed to thinking with BGP-LS, but will see the picture being solved and 
will understand the flow of information.
 
Thanks,
Adrian
 
 
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: 25 July 2017 11:27
To: Julien Meuric; pce@ietf.org
Cc: pce-cha...@ietf.org
Subject: Re: [Pce] PCEP as an SDN controller protocol?
 
HI Julien,
 
your correction is…correct 
 
You’re referring to the protocols running on the DCN, or more appropriately on 
the MCN, right? The IGP is usually non TE and just providing reachability 
info…but as PCEP can be modified for other purposes, they can be modified as 
well. On this I agree with you.
 
Cheers
Daniele   
 
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: martedì 25 luglio 2017 11:36
To: Daniele Ceccarelli <daniele.ceccare...@ericsson.com>; pce@ietf.org
Cc: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce-cha...@ietf.org
Subject: Re: PCEP as an SDN controller protocol?
 
Hi Daniele,

[Operator hat on.]

I agree on several things you wrote, starting from the answer to Jon's 
rhetorical question, which cares more about how much (at least I've never 
noticed my co-chair has a short memory).

Nevertheless the sentence below needs to be corrected, because it happens to be 
wrong: "optical networks with no control plane" is as inaccurate as "a fuel car 
with no battery".
Not relying on the high-end version of this mean to realize the core task of an 
equipment must not hide that most (even those Sonet/SDH ADMs) of the deployed 
optical devices do (mostly for management traffic, whose fate PCEP may 
share)...:
- perform IP forwarding,
- have a routing table,
- run an IGP to populate that routing table,
- run an IGP to advertise their attached addresses,
- support a large set of (IP-based) protocols for various purposes (e.g., ICMP, 
DHCP, SSH, SMTP), i.e. squeezing many roles within a single protocol is a 
non-goal.

A possible rephrasing could be "networks where the control plane is limited to 
background tasks", which reminds that operators deploy "fully packaged cars", 
not just "raw wheels with a motor" according to the misleading scope assumed in 
the current discussion.

Thanks,

Julien
Jul. 24, 2017 - daniele.ceccare...@ericsson.com:
· It could be the SBI solution for those networks where there is no 
control plane (e.g. many NMS driven optical networks)
 
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Daniele Ceccarelli]

HI Julien,

your correction is…correct 

You’re referring to the protocols running on the DCN, or more appropriately on 
the MCN, right? The IGP is usually non TE and just providing reachability 
info…but as PCEP can be modified for other purposes, they can be modified as 
well. On this I agree with you.

Cheers
Daniele

From: Julien Meuric [mailto:julien.meu...@orange.com]
Sent: martedì 25 luglio 2017 11:36
To: Daniele Ceccarelli ; pce@ietf.org
Cc: Jonathan Hardwick ; pce-cha...@ietf.org
Subject: Re: PCEP as an SDN controller protocol?

Hi Daniele,

[Operator hat on.]

I agree on several things you wrote, starting from the answer to Jon's 
rhetorical question, which cares more about how much (at least I've never 
noticed my co-chair has a short memory).

Nevertheless the sentence below needs to be corrected, because it happens to be 
wrong: "optical networks with no control plane" is as inaccurate as "a fuel car 
with no battery".
Not relying on the high-end version of this mean to realize the core task of an 
equipment must not hide that most (even those Sonet/SDH ADMs) of the deployed 
optical devices do (mostly for management traffic, whose fate PCEP may 
share)...:
- perform IP forwarding,
- have a routing table,
- run an IGP to populate that routing table,
- run an IGP to advertise their attached addresses,
- support a large set of (IP-based) protocols for various purposes (e.g., ICMP, 
DHCP, SSH, SMTP), i.e. squeezing many roles within a single protocol is a 
non-goal.

A possible rephrasing could be "networks where the control plane is limited to 
background tasks", which reminds that operators deploy "fully packaged cars", 
not just "raw wheels with a motor" according to the misleading scope assumed in 
the current discussion.

Thanks,

Julien

Jul. 24, 2017 - 
daniele.ceccare...@ericsson.com:
· It could be the SBI solution for those networks where there is no 
control plane (e.g. many NMS driven optical networks)

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Julien Meuric]

  
  
Hi Daniele,

[Operator hat on.]

I agree on several things you wrote, starting from the answer to
Jon's rhetorical question, which cares more about how much (at least
I've never noticed my co-chair has a short memory).

Nevertheless the sentence below needs to be corrected, because it
happens to be wrong: "optical networks with no control plane" is as
inaccurate as "a fuel car with no battery".
Not relying on the high-end version of this mean to realize the core
task of an equipment must not hide that most (even those Sonet/SDH
ADMs) of the deployed optical devices do (mostly for management
traffic, whose fate PCEP may share)...:
- perform IP forwarding,
- have a routing table,
- run an IGP to populate that routing table,
- run an IGP to advertise their attached addresses,
- support a large set of (IP-based) protocols for various purposes
(e.g., ICMP, DHCP, SSH, SMTP), i.e. squeezing many roles within a
single protocol is a non-goal.

A possible rephrasing could be "networks where the control plane is
limited to background tasks", which reminds that operators deploy
"fully packaged cars", not just "raw wheels with a motor" according
to the misleading scope assumed in the current discussion.

Thanks,

Julien


Jul. 24, 2017 - daniele.ceccare...@ericsson.com:


  
  
It could be the SBI solution for those networks
where there is no control plane (e.g. many NMS driven
optical networks)
  


  


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Jeff Tantsura]

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 <pce-boun...@ietf.org> on behalf of Igor Bryskin 
<igor.brys...@huawei.com>
Date: Monday, July 24, 2017 at 14:52
To: "stephane.litkow...@orange.com" <stephane.litkow...@orange.com>, Jonathan 
Hardwick <jonathan.hardw...@metaswitch.com>, "pce@ietf.org" <pce@ietf.org>
Cc: "pce-cha...@ietf.org" <pce-cha...@ietf.org>
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:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, July 24, 2017 8:03 AM
To: Jonathan Hardwick; pce@ietf.org
Cc: pce-cha...@ietf.org
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:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Thursday, July 20, 2017 17:22
To: pce@ietf.org
Cc: pce-cha...@ietf.org
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 d

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

[Daniele Ceccarelli]

Thanks Jon for starting this discussion.

I agree with Stephane when saying that the decision to turn PCEP into an SDN 
protocol was already taken a while ago (with the active PCE IMHO).

What are the pros and cons of this approach, let me share some loud thinking:


  *   It could be the SBI solution for those networks where there is no control 
plane (e.g. many NMS driven optical networks)
  *   It could be a good alternative to Netconf/Restconf as a protocol between 
sdn controllers (sort of NBI). It's less configuration driven and more event 
oriented. It also has different reaction time.
  *   On the other side the market seems to be asking more for Netconf/Restconf 
as the single protocol between SDN controller. We should try to understand if 
this is driven by the need for a single protocol doing everything, by the lack 
of knowledge (of PCEP as a potential SDN protocol), or other reasons.
  *   It could succeed where open flow failed, being the protocol that operates 
an heterogeneous network (where there is no control plane interoperability and 
provided that readiness is done a priori via NMS).
  *   Should we adopt it just for some of the functionalities Jon listed or 
all? Well, for some of them maybe it's not worth it?...

All in all I would say I'm leaning towards a yes (to the question in the 
subject).

BR
Daniele

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: lunedì 24 luglio 2017 14:03
To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org
Cc: pce-cha...@ietf.org
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 :) ?
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:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Thursday, July 20, 2017 17:22
To: pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
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

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

[stephane.litkowski]

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 :) ?
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:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Thursday, July 20, 2017 17:22
To: pce@ietf.org
Cc: pce-cha...@ietf.org
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 

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

[Robert Varga]

Hello,

On 20/07/17 18:46, Ramon Casellas wrote:
> We have implemented BGP-LS but I see no reason why PCEP cannot be
> extended for the same (PCEP-LS) being almost functionally equivalent.

With my stateful-pcep co-author hat on, I have to say this boils down to
what is really needed at the protocol layer.

At its core PCEP is BGP with RPCs on top of it. NETCONF can do the same
thing (if you add binary encoding and fix the notification model, which
is actively being done). PCEP has native binary encoding, but on the
other hand I always have to deal with the capability matrix in my parser.

From the protocol perspective, I think all we need to do is to specify
how externally-modeled data can be exchanged between PCEs/PCCs and their
discovery (which can be done in negotiation phase) -- something in the
vein of gNMI.

From the architecture perspective, defining modes of operation in terms
RPC/flooding interactions are worthwhile.

Beyond that, yes, PCEP can tunnel any sort of reasonably-sized data and
perform all sorts of client/server/proxy interactions, but is creating
an uber-protocol a good idea?

I think LSPDB and IGP information boils down to flooding, there are only
two benefits of running IGP-over-PCEP vs. PCEP+BGP/LS I can see:

1) Total event ordering
2) Single failure domain

both of which are implied by running over a single session.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Ramon Casellas]

On 7/20/2017 5:22 PM, Jonathan Hardwick wrote:


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.



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.




Hi all,

Just my two cents, trying not to elaborate too much. In short, my answer 
is yes.


The main disclaimer is that it is a view from a research/experimental 
perspective. I am aware of the functional implications, separation of 
concerns, functions, etc. and in previous meetings we have had several 
(heated  :) discussions on this.


We have a (proprietary) implementation which, in the last years, has 
morphed/grown into the likes of an SDN controller e.g., an optical SDN 
controller for fixed and flexi-grid networks.  It can be deployed 
directly over a GMPLS control plane or in PCECC mode. We have running 
implementations of PCEP-LS, PCE-CC and an ACTN proof-of-concept for 
multi-domain flexi-grid networks (base on active, stateful, hierarchical 
PCE).


The main driver/motivation has been convenience, in a clearly 
evolutionary approach (adding two wheels and an engine to the bicycle to 
make it a car). We have been influenced by SDN/Centralized control 
concepts. In most cases we needed to implement a message exchange and 
PCEP (beyond its original intent) provided such length-delimited 
reliable message exchange between entities. We have implemented BGP-LS 
but I see no reason why PCEP cannot be extended for the same (PCEP-LS) 
being almost functionally equivalent. We also had a modified OpenFlow 
for optical networks as SBI, (pre-ONF work adapting CFLOW_MOD) but 
PCE-CC also allows us to program roughly the same equivalent 
cross-connects. Having a single unified framework (PCEP) is very useful 
for robustness, avoid code duplication, etc., along with unified session 
management, parsers, tests, etc.


IMHO, with the stateful PCE work we already went beyond the basic path 
computation service.


Best regards
Ramon

--
Ramon Casellas, Ph.D. -- Senior Researcher -- Networks Division
Optical Networks and Systems Department -- http://www.cttc.es/people/rcasellas/
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya
Parc Mediterrani de la Tecnologia (PMT) - Edifici B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 ext 2168 -- Fax. +34 93 645 29 01

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce