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

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 20 Jul 2017 15:22:28 +0000

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

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 20 Jul 2017 18:46:52 +0200

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Jul 2017 20:58:04 +0100

Hi,
 
Ramon's last line for me is the core of the argument.
 
> IMHO, with the stateful PCE work we already went beyond the basic
> path computation service.
 
You might recall (if you are old and carry a grudge) that I was not an
enthusiast for stateful active PCE (i.e., PCInitiate), but like the good soldier
I am, I bowed to IETF consensus and PCE is what it is. More importantly, PCEP is
what it is.
 
IM(not-very)HO we have already crossed the line and PCEP *is* an SDN controller
(southbound) protocol.
 
Now the question is: what do we want to be able to do with it?
 
Obviously, as editor of draft-ietf-teas-pce-central-control, I support PCE-CC.
As discussed in the meeting, I'm not so happy with the mechanisms in the current
solutions drafts. This is because I believe we can actually do (or almost do)
most of the function with existing messages and objects. But that is a question
of detail, not principle.
 
I would argue that this PCE-CC function doesn't "replace" RSVP-TE, but rather it
replaces other configuration or SDN southbound protocols. 
 
Cheers,
Adrian
 
From: Pce [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: 20 July 2017 17:47
To: [email-masked]
Subject: Re: [Pce] PCEP as an SDN controller protocol?
 
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.

Best regards
Ramon

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 20 Jul 2017 22:07:42 +0000

Hi,

Having arrived to the PCEverse later than most of you, I must say my impression is exactly the same. I remember asking my colleagues who were already involved why we were not using the term SDN when it became common and, in fact, referencing our PCE implementation in the list of our SDN projects.

As Adrian says, the question is what do we want to be able to do with this "recently discovered” SDN protocol...

Be goode,

On 20 Jul 2017, at 21:58 , Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

> path computation service.

You might recall (if you are old and carry a grudge) that I was not an enthusiast for stateful active PCE (i.e., PCInitiate), but like the good soldier I am, I bowed to IETF consensus and PCE is what it is. More importantly, PCEP is what it is.

IM(not-very)HO we have already crossed the line and PCEP *is* an SDN controller (southbound) protocol.

Obviously, as editor of draft-ietf-teas-pce-central-control, I support PCE-CC. As discussed in the meeting, I'm not so happy with the mechanisms in the current solutions drafts. This is because I believe we can actually do (or almost do) most of the function with existing messages and objects. But that is a question of detail, not principle.

I would argue that this PCE-CC function doesn't "replace" RSVP-TE, but rather it replaces other configuration or SDN southbound protocols.

Cheers,
Adrian

From: Pce [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: 20 July 2017 17:47
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] PCEP as an SDN controller protocol?

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.

Hi all,

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

--

_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Robert Varga <[email-masked]>
Date: Fri, 21 Jul 2017 00:31:02 +0200

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

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 21 Jul 2017 10:31:09 +0800

Hi,

I support the idea of selecting PCEP as an SDN controller protocol, but did
not support the idea that let PCEP do all the work that IGP/BGP has
accomplished.

>From the viewpoint of network operator, we think SDN can introduce some
flexibility/controllability to our network and we think the future network
should be the integration of centrally control and traditional distributed
protocol.

And we have present CCDR(Centrally Control Dynamic Routing) (CCDR
Presentation Material
<https://www.ietf.org/proceedings/99/slides/slides-99-teas-sessa-13-ccdr-cen
trally-control-dynamic-routing-scenario-simulation-and-suggestion-01.pdf> )
at IETF99 and PCE in Native IP network
<https://www.ietf.org/proceedings/98/slides/slides-98-teas-10_pce_in_native_
ip-01.pdf>  at IETF98 in TEAS WG to introduce the idea that use PCE/SDN
controller within Native IP network and also the related PCEP extension
proposal to accomplish such aim.

Any idea is welcome to support our scenario and solution.

Best Regards.

Aijun Wang

Network R&D and Operation Support Department

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

发件人: Pce [mailto:[email-masked]] 代表 Jonathan Hardwick
发送时间: 2017年7月20日 23:22
收件人: [email-masked]
抄送: [email-masked]
主题: [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

---

From: Leeyoung <[email-masked]>
Date: Fri, 21 Jul 2017 08:01:47 +0000

Hi,

I support PCE as an SDN controller architecture and PCEP as an SDN controller protocol.

Over the course of time, PCE has evolved little by little toward SDN evolution starting from path computation function to be centrally controlled. I believe this is the first SN concept even before SDN was termed officially. Then we have seen the next step into more functionality given to PCEP; Stateful PCE has become a tool for path provisioning. Recently, with ACTN and PCE CC, PCE plays more role of assigning labels and managing LSPs. The only missing puzzle has been centralized link-state and TE resource discovery mechanism which is known as PCEP-LS. Clearly, PCE is an SDN architecture and PCEP can become a full-fledged solution for SDN.

The advantage of PCEP-LS is as follows: As we are proposing using direct PCEP session to all nodes, PCEP-LS would be fastest to learn TE information. It is also a binary protocol which is faster than text-based. One thing to note for PCEP-LS, we are using LS-ID (stateful) concept where a B/W change, for example, can be updated only with BW TLV without other link properties. This saves packet size and encoding/decoding time is faster than distributed mechanisms.

In a nutshell, I would be really excited to see PCE WG to embrace PCEP a full-fledged SDN controller protocol and I would like to contribute with passion.

Thanks,
Young

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

Dear PCE WG

Many thanks
Jon

---

From: <[email-masked]>
Date: Mon, 24 Jul 2017 12:02:54 +0000

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:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: Thursday, July 20, 2017 17:22
To: [email-masked]
Cc: [email-masked]
Subject: [Pce] PCEP as an SDN controller protocol?

Dear PCE WG

Many thanks
Jon

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 24 Jul 2017 12:52:30 +0000

Hi Stephanie,

You said:
< Why not limiting PCEP to path programming and path policies (traffic steering on path...) ?

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

Cheers,,
Igor

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

Hi,

IMO:

Brgds,

Dear PCE WG

Many thanks
Jon

Thank you.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 24 Jul 2017 12:54:07 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: lunedì 24 luglio 2017 14:03
To: Jonathan Hardwick <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] PCEP as an SDN controller protocol?

Hi,

IMO:

Brgds,

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

Dear PCE WG

Many thanks
Jon

Thank you.

---

From: Khasanov Boris <[email-masked]>
Date: Mon, 24 Jul 2017 14:34:43 +0000

Hi all,
Firstly as others said - thank you Jon for bringing it up.

My 0,05$:

1)      I also do agree with Daniele, Stephane, Adrian and others that PCEP as SBI is a fact.

2)      Can PCEP be extended to some new directions? IMO - yes, why not. Surely we have different protocols that my look overlapping (or competing sometimes), they have own pros and cons.  I think we should provide different options, there should be no monopoly with just one or two protocols. Stephane mentioned IGP vs. BGP example. Just for illustration, I would like to remind that currently in some big DCs BGP (eBGP) is used as routing protocol instead of IGP, although some time ago it would be a very strange decision.

3)      So we do not have a crystal ball and we cannot say which protocol will or can prevail even in mid-term perspective. Only time will show that. Thus I do support our efforts for PCEP development.

Thank you.

SY,
Boris

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

BR
Daniele

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: lunedì 24 luglio 2017 14:03
To: Jonathan Hardwick <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] PCEP as an SDN controller protocol?

Hi,

IMO:

Brgds,

Dear PCE WG

Many thanks
Jon

Thank you.

---

From: Zhenghaomian <[email-masked]>
Date: Tue, 25 Jul 2017 01:58:03 +0000

Thanks Jon for bringing this topic, it is already a fact that people are implementing PCEP with their controllers, as many other experts mentioned in previous email.

The point I would like to raise is how to deal with PCEP with other protocols. Currently it seems that there is some competition with BGP in link state (both binary but Optical/MW CANNOT run BGP), and also with Netconf/RESTconf on device configuration (well they are text). If we consider PCEP-LS work only, we should consider it at least for optical/MW binary solution. I believe that the direction we are promoting is correct for PCEP, i.e., make PCEP applicable in necessary network environments, rather than pure ‘path computation methodology’.

Moreover, instead of PCEP-LS outcome,  I am more interested in the principle behind, i.e., are we trying to construct PCEP as a fully overlapping with any other protocol, or even a super set of them? My answer would probably be no. I think PCEP is complementary with other protocols and is only extended when there is a valid scenario, and the same for other protocols (BGP, netconf…). When we are promoting PCEP features (like cc, ls), we are not and should not be criticizing other solutions.

PS: IETF was not restricting multi-protocols (ospf vs. isis…) before, and it was proved to be success in my understanding.

Best wishes,
Haomian

发件人: Pce [mailto:[email-masked]] 代表 Daniele Ceccarelli
发送时间: 2017年7月24日 20:54
收件人: [email-masked]; Jonathan Hardwick; [email-masked]
抄送: [email-masked]
主题: Re: [Pce] PCEP as an SDN controller protocol?

-        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

Hi,

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,

Dear PCE WG

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

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

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

Thank you.

---

From: Julien Meuric <[email-masked]>
Date: Tue, 25 Jul 2017 11:36:22 +0200

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 - [email-masked]:

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 25 Jul 2017 10:26:49 +0000

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:[email-masked]]
Sent: martedì 25 luglio 2017 11:36
To: Daniele Ceccarelli <[email-masked]>; [email-masked]
Cc: Jonathan Hardwick <[email-masked]>; [email-masked]
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 - [email-masked]<mailto:[email-masked]>:
·         It could be the SBI solution for those networks where there is no control plane (e.g. many NMS driven optical networks)

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Jul 2017 11:58:39 +0100

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:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: 25 July 2017 11:27
To: Julien Meuric; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] PCEP as an SDN controller protocol?
 
HI Julien,

 
Cheers
Daniele   

Hi Daniele,

[Operator hat on.]

Thanks,

Julien

---

From: <[email-masked]>
Date: Tue, 25 Jul 2017 12:49:53 +0000

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:[email-masked]]
Sent: Monday, July 24, 2017 14:53
To: LITKOWSKI Stephane OBS/OINIS; Jonathan Hardwick; [email-masked]
Cc: [email-masked]
Subject: RE: PCEP as an SDN controller protocol?

Hi Stephanie,

You said:

Cheers,,
Igor

To: Jonathan Hardwick; [email-masked]<mailto:[email-masked]>

Hi,

IMO:

Brgds,

Dear PCE WG

Many thanks
Jon

Thank you.

---

From: Dieter Beller <[email-masked]>
Date: Tue, 25 Jul 2017 16:27:03 +0200

Hi Jon, all,

I do have strong concerns to extend PCEP as described in the e-mail
below:

Currently, IETF is working on YANG models covering TE-topology as
well as TE-tunnels. This means that the NETCONF protocol can be used
to

retrieve local topology information including link state information
for the links connecting the node with its immediate neighbors. This
information

can be used by the NETCONF client (could be an SDN controller) to
put the entire TE-topology of a domain together.

As far as connection control is concerned, NETCONF can also be used
to either establish an e2e connections by configuring all nodes
along the

the path or NETCONF can trigger connection establishment in the
source node in case a GMPLS control plane is in place and RSVP-TE
signaling

will be used for setting up the LSP. There is no obvious reason why
PCEP would have any advantages over NETCONF/YANG. Introducing an

additional protocol supporting almost the same functionality will
certainly not be helpful for the industry because vendors will have
to implement

and test an additional protocol.

Thanks,

Dieter

On 20.07.2017 17:22, Jonathan Hardwick
wrote:

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

[email-masked]

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tue, 25 Jul 2017 14:52:44 +0000

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

Dear PCE WG

Many thanks
Jon

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 25 Jul 2017 15:01:15 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 25, 2017 8:50 AM
To: Igor Bryskin; Jonathan Hardwick; [email-masked]
Cc: [email-masked]
Subject: RE: PCEP as an SDN controller protocol?

Hi,

Brgds,

Hi Stephanie,

You said:

Cheers,,
Igor

Hi,

IMO:

Brgds,

Dear PCE WG

Many thanks
Jon

Thank you.

Thank you.

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 25 Jul 2017 20:45:54 +0530

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) <
[email-masked]> 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:[email-masked]] *On Behalf Of *Jonathan Hardwick
> *Sent:* Thursday, July 20, 2017 5:22 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [Pce] PCEP as an SDN controller protocol?
>
>
>
> Dear PCE WG
>
>
>
> The purpose of this email is to initiate a discussion about whether we
> want to extend PCEP to allow it to replace the functions that are
> traditionally provided by the routing and signalling protocols.
>
>
>
> Originally, PCEP was designed with the goal of providing a distributed
> path computation service.  In recent years we have extended that mission,
> and added path modification and path instantiation capabilities to PCEP.
> This has added capabilities to PCEP that would traditionally have been
> performed by the network management plane.
>
>
>
> We are now starting to discuss proposals to add more capabilities to PCEP
> – capabilities that are traditionally part of routing and signalling.
> There were three examples of this in the PCE working group meeting this
> week.
>
>    - The PCECC proposal, which extends PCEP’s path instantiation
>    - 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
> we want to take PCEP in.  However, there are two procedural issues, as I
> see it.
>
>    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
> justifications for or against.  Such as, which production networks would
> run PCEP in place of a traditional control plane?  Why is it not desirable
> to solve the problems in those networks with the traditional control
> plane?  What harm could this do?  What would be the operational problems
> associated with adding these functions to PCEP?
>
>
>
> Many thanks
>
> Jon
>
>
>

---

From: Robert Varga <[email-masked]>
Date: Tue, 25 Jul 2017 17:23:38 +0200

On 25/07/17 03:58, Zhenghaomian wrote:
> The point I would like to raise is how to deal with PCEP with other
> protocols. Currently it seems that there is some competition with BGP in
> link state (both binary but Optical/MW CANNOT run BGP), and also with
> Netconf/RESTconf on device configuration (well they are text).

I would like to dispel the notion that NETCONF/RESTCONF are inherently
text-based. While they operate on XML Information Set and their
currently-standardized transports are based on JSON/XML, there is no
reason why you cannot use session-negotiated binary schema-informed
encoding, which can in fact be more compact than PCEP.

For NETCONF all you need to do is change the encoding at the Messages
layer (https://tools.ietf.org/html/rfc6241#section-1.2). You can
negotiate that at session setup time, for example using the approach
proposed in https://tools.ietf.org/html/draft-varga-netconf-exi-capability.

Regards,
Robert

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tue, 25 Jul 2017 15:28:03 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Tuesday, July 25, 2017 5:16 PM
To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
Cc: Jonathan Hardwick <[email-masked]>; [email-masked]; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jon, all

Thanks
Sergio

From: Pce [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jonathan Hardwick

Dear PCE WG

Many thanks
Jon

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Tue, 25 Jul 2017 17:37:47 +0000

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

Dear PCE WG

Many thanks
Jon

---

From: Cyril Margaria <[email-masked]>
Date: Tue, 25 Jul 2017 15:25:25 -0400

+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, <[email-masked]> 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.
>
> 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 ?
>
> 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
>
> *Sent:* Thursday, July 20, 2017 17:22
> *To:* [email-masked]
> 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
> “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.
>
>
>

---

From: John E Drake <[email-masked]>
Date: Tue, 25 Jul 2017 19:50:30 +0000

I also agree.

This seems to be a poster child for mission creep.

Yours Irrespectively,

John

From: Pce [mailto:[email-masked]] On Behalf Of Cyril Margaria
Sent: Tuesday, July 25, 2017 3:25 PM
To: LITKOWSKI Stephane DTF/DERX <[email-masked]>
Cc: [email-masked]; [email-masked]
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, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

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 ☺ ?

IMO:

Brgds,

Dear PCE WG

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

Many thanks
Jon

Thank you.

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 25 Jul 2017 13:38:17 -0700

++1

Cheers,

Jeff

From: Pce <[email-masked]> on behalf of Cyril Margaria <[email-masked]>
Date: Tuesday, July 25, 2017 at 12:25
To: LITKOWSKI Stephane DTF/DERX <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Pce] PCEP as an SDN controller protocol?

+1, 

My 2 cents

Cyril

Hi,

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 ?

Example:

…

IMO: 

Brgds,

Dear PCE WG

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

Many thanks

Jon

 

_______________________________________________ Pce mailing list [email-masked] https://www.ietf.org/mailman/listinfo/pce

---

From: Leeyoung <[email-masked]>
Date: Wed, 26 Jul 2017 02:35:00 +0000

Regards,
Young

From: Pce [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, July 25, 2017 5:59 AM
To: 'Daniele Ceccarelli' <[email-masked]>; 'Julien Meuric' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] PCEP as an SDN controller protocol?

Thanks,
Adrian

From: Pce [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: 25 July 2017 11:27
To: Julien Meuric; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] PCEP as an SDN controller protocol?

HI Julien,

Cheers
Daniele

From: Julien Meuric [mailto:[email-masked]]
Sent: martedì 25 luglio 2017 11:36
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Jonathan Hardwick <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: PCEP as an SDN controller protocol?

Hi Daniele,

[Operator hat on.]

Thanks,

Julien
Jul. 24, 2017 - [email-masked]<mailto:[email-masked]>:
•         It could be the SBI solution for those networks where there is no control plane (e.g. many NMS driven optical networks)

---

From: <[email-masked]>
Date: Thu, 27 Jul 2017 20:11:45 +0200

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, delay constraint ...) I will be very happy if one hand raise in the room. So, fromthis poor operational usage, we absolutely don't know if PCEP is stable, scale at large... Can we guarantee that a PCE could maintain a PCEP session with all nodes in a large network (say 1000 nodes and more) ? No. Because nobody report on the WG such experience like other WG do. Do we have interoperability issues ? Yes plenty. From all industrial and OpenSource PCE solutions I tested no one implement correctly all the RFCs
and recent drafts. So, before extending PCEP I suggest to concentrate on implementing what is already available. Make large experiment, see what's happen. Debug, report, adjust. Then we could think about the future of PCEP when we will collect sufficient backgroundand experience. Upto know, from what I experiment, the technology is good, promising, but too young.

my 2cts

Olivier

---

From: John E Drake <[email-masked]>
Date: Thu, 27 Jul 2017 19:16:43 +0000

Olivier,

Very cogently argued

Yours Irrespectively,

John

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

Hi Jon,

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 of operational network using Segment Routing ? And on this few subset the number that really use PCEP ? I'm pretty sure that I have sufficient finger in one hand to count them. And, if I restrict them to which are really need Path Computation with constraints (I mean path diversity, bandwidth reservation, delay constraint ...) I will be very happy if one hand raise in the room. So, from this poor operational usage, we absolutely don't know if PCEP is stable, scale at large ... Can we guarantee that a PCE could maintain a PCEP session with all nodes in a large network (say 1000 nodes and more) ? No. Because nobody report on the WG such experience like other WG do. Do we have interoperability issues ? Yes plenty. From all industrial and Open Source PCE solutions I tested no one implement correctly all the RFCs and recent drafts. So, before extending PCEP I suggest to concentrate on implementing what is already available. Make large experiment, see what's happen. Debug, report, adjust. Then we could think about the future of PCEP when we will collect sufficient background and experience. Up to know, from what I experiment, the technology is good, promising, but too young.

my 2cts

Olivier

Many thanks
Jon

Pce mailing list

Thank you.