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 ; Robert Varga 
> 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 
> > Cc: Dhruv Dhody ; olivier.dug...@orange.com;
> > Jonathan Hardwick ; 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  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 ;
> > >> 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 scena

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 ; 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 other than those used 
for FRR) ? number 

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

[John E Drake]

I also agree.

This seems to be a poster child for mission creep.

Yours Irrespectively,

John

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Cyril Margaria
Sent: Tuesday, July 25, 2017 3:25 PM
To: LITKOWSKI Stephane DTF/DERX 
Cc: pce@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, 
mailto: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 ☺ ?
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 

Re: [Pce] Experimental Codepoints allocation in PCEP registry

[John E Drake]

However it's not prime

Yours Irrespectively,

John

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jeff Tantsura
> Sent: Thursday, June 16, 2016 1:42 AM
> To: Dhruv Dhody; adr...@olddog.co.uk; 'Ramon Casellas'; pce@ietf.org
> Subject: Re: [Pce] Experimental Codepoints allocation in PCEP registry
> 
> Hi Adrian,
> 
> 8 sounds like a good number.
> 
> Cheers,
> Jeff
> 
> On 6/16/16, 9:25 AM, "Pce on behalf of Dhruv Dhody"  behalf of
> dhruv.dh...@huawei.com> wrote:
> 
> >Hi Adrian,
> >
> >> How would you all feel about 8? (My instinct is to push for 4, but I
> >> can pre-emptively compromise :-)
> >
> >I can work with 8 :)
> >
> >Regards,
> >Dhruv
> >
> >> -Original Message-
> >> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> >> Sent: 15 June 2016 23:52
> >> To: Dhruv Dhody ; 'Ramon Casellas'
> >> ; pce@ietf.org
> >> Subject: RE: [Pce] Experimental Codepoint allocation in PCEP registry
> >>
> >> To Ramon's point...
> >>
> >> > We do need to reach a consensus on what range to set aside.
> >>
> >> Yes, we do. Both to satisfy ourselves and to get past the current
> >> IESG (not the one that approved the MANET registry).
> >>
> >> I think you captured the essence. There should be enough code points
> >> to run the parallel experiments that need to be run together, but not
> >> so many that experiments that don't need to be run at the same time
> >> can grab values and expect to keep them. Essentially, before running
> >> an experiment all participants should get together to agree what
> >> values to use, and then when the experiment is over they should
> >> consider the values to have no meaning (until the next and completely 
> >> different
> experiment).
> >>
> >> As far as I can see, 30 messages looks like a complete orgy of 
> >> experimentation!
> >> Four times more active experimentation in one experimental network
> >> than in the whole of the standardised and soon-to-be standardised history 
> >> of PCEP.
> >>
> >> How would you all feel about 8? (My instinct is to push for 4, but I
> >> can pre-emptively compromise :-)
> >>
> >> Adrian
> >>
> >> > -Original Message-
> >> > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
> >> > Sent: 10 June 2016 11:03
> >> > To: Ramon Casellas; pce@ietf.org
> >> > Subject: Re: [Pce] Experimental Codepoint allocation in PCEP
> >> > registry
> >> >
> >> > Hi Ramon,
> >> >
> >> > > -Original Message-
> >> > > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Ramon
> >> > > Casellas
> >> > > Sent: 10 June 2016 14:42
> >> > > To: pce@ietf.org
> >> > > Subject: Re: [Pce] Experimental Codepoint allocation in PCEP
> >> > > registry
> >> > >
> >> > > Hi Dhruv, Jeff, all
> >> > >
> >> > > Indeed. Having been involved in PCE-related experimental and
> >> > > research activities I would welcome this and could be very helpful.
> >> > > It will not solve the issues but at least it defines the ranges.
> >> > >
> >> > > I can't provide much feedback, just curious about the rationale
> >> > > to allocate a given range e.g. 224-255 > 30 messages, etc.
> >> >
> >> > [Dhruv] You hit the jackpot we wanted to get the feedback of
> >> > the WG about this.
> >> >
> >> > IMHO we need to strike a right balance that there are enough
> >> > codepoints set aside for multiple parallel experimentations at a
> >> > given time, and not to give
> >> up a
> >> > big chunk out for experimentation that it hinders IANA allocation.
> >> >
> >> > We currently have 9 messages set by IANA, some 4 new messages in
> >> > queue to be sent to IANA, 13/255 ... so we do not have to worry
> >> > about running out any time soon :)
> >> >
> >> > BTW I could find one instance in MANET where a similar range is
> >> > allocated -
> >> > https://tools.ietf.org/html/rfc5444#section-6.2
> >> >
> >> > We do need to reach a consensus on what range to set aside.
> >> >
> >> > Regards,
> >> > Dhruv
> >> >
> >> > >
> >> > > Best regards
> >> > > Ramon
> >> > >
> >> > > On 10/06/2016 11:00, Jeff Tantsura wrote:
> >> > > > Hi Dhruv,
> >> > > >
> >> > > > Support, very much needed!
> >> > > >
> >> > > > Thanks,
> >> > > > Jeff
> >> > > >
> >> > > > On 6/9/16, 5:09 AM, "Pce on behalf of Dhruv Dhody"
> >> > > >  >> > > on behalf of dhruv.dh...@huawei.com> wrote:
> >> > > >
> >> > > >> Hi WG,
> >> > > >>
> >> > > >> In PCE IANA registry [http://www.iana.org/assignments/pcep] we
> >> > > >> do not
> >> > > have any codepoints for experimental usage. As we work on some
> >> > > new
> >> > experiments
> >> > > with PCEP (sometimes in open source platform), it would be wise
> >> > > to use experimental codepoints to avoid any conflict. For this
> >> > > purpose we have written a small draft to carve out some
> >> > > codepoints for experimental usage for PCEP messages, objects and TLVs.
> >> > > >>
> >> > > >> https://tools.ietf.org/html/draft-dhody-pce-pcep-exp-codepoint
> >> > > >> s-0
> >> > > >> 0
> >> > > >>
> >> > > >> Please provide your feedbac