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

[Robert Varga]

Hello,

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

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

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

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

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

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

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

1) Total event ordering
2) Single failure domain

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

Regards,
Robert



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

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

[Ramon Casellas]

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


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



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




Hi all,

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


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


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


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


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


Best regards
Ramon

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

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

[Pce] PCEP as an SDN controller protocol?

[Jonathan Hardwick]

Dear PCE WG

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

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

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

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

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

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

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

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

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

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

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

Many thanks
Jon

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

Re: [Pce] 答复: My Comment on draft-lee-pce-flexible-grid

[Dieter Beller]

  
  
Hi Young,

On 20.07.2017 11:41, Leeyoung wrote:


  
  
  
  
Hi
Dieter,
 
I
agree. In this draft, we refer to

https://tools.ietf.org/html/draft-ietf-ccamp-flexible-grid-ospf-ext-09#section-4.1.1
for the available spectrum encoding. Is this what you are
referring to, or more than that?
  
  


[DB>] no, I am exactly referring to
draft-ietf-ccamp-flexible-grid-ospf-ext that is referenced in your
pce draft.
[DB>] I just wanted to point out that you have to clearly define
what a frequency slot is as it could be interpreted in
[DB>] different ways (see below).


Thanks,
Dieter



  

 
Thanks.
Young
 

  
From:
Dieter Beller [mailto:dieter.bel...@nokia.com]

Sent: Thursday, July 20, 2017 11:35 AM
To: Zhenghaomian ;
Leeyoung ; Julien Meuric
; pce@ietf.org;
draft-lee-pce-flexible-g...@ietf.org
Subject: Re: [Pce] 答复:
My Comment on draft-lee-pce-flexible-grid
  

 
Hi all,

the description of the available spectrum in
draft-lee-pce-flexible-grid should in my opinion be
consistent with the available spectrum
description in draft-ietf-ccamp-flexible-grid-ospf-ext.
Please note that the available spectrum is advertised in
terms of available central
frequencies!

A central frequency f_c is available only if the spectrum is
available in the interval [f_c - f_minSlotWidth/2, fc +
f_minSlotWidth/2]

If the flexgrid granularity is 6.25GHz and the minSlotWidth
is 12.5GHz this means leads to: [f_c - 6.25GHz, f_c + 6.25
GHz]

This is different from advertising spectrum slots like for
example [f_c_n-1, fc_n].

Please note that a modulated optical carrier occupies
spectrum symmetrical around the central frequency.


Thanks,
Dieter

  

  On 20.07.2017 11:04, Zhenghaomian wrote:


  Hi, Julien and Young, 
   
  I fully agree on that we should try our best on reusing the existing object/TLVs. FYI, when we are working on GMPLS extensions from fixed-grid (WSON) to flexi-grid, we have some TLVs in parallel (switching types) for fixed/flexi-grid. 
   
  I assume this is exactly what we are doing in this draft, the split occurs when it is difficult to use existing TLV to represent the new features. In some cases, the meaning of flags/TLVs need to be changed to support different scenarios, so the similarity on object does not necessarily mean the equivalent on functionality. 
   
  My 2 cents, 
  Haomian
   
  -邮件原件-
  发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Leeyoung
  发送时间: 2017年7月20日 16:41
  收件人: Julien Meuric; pce@ietf.org; draft-lee-pce-flexible-g...@ietf.org
  主题: Re: [Pce] My Comment on draft-lee-pce-flexible-grid
   
  Hi Julien,
   
  I agree. A New flag on the object header (WA Object, I assume that is what you are pointing to) where we have a flag to indicate if this is fixed (WSON) or flexi-grid is reasonable instead of creating a new object for a new Spectrum Assignment Object.
   
  TLVs require a bit different encoding due to the nature of additional parameters for flexi-grid. So strict re-use of WSON TLV may not be sufficient for some cases in flexi-grid. 
   
  Best regards,
  Young
   
  -Original Message-
  From: Julien Meuric [mailto:julien.meu...@orange.com] 
  Sent: Thursday, July 20, 2017 10:28 AM
  To: pce@ietf.org; draft-lee-pce-flexible-g...@ietf.org
  Subject: My Comment on draft-lee-pce-flexible-grid
   
  Hi,
   
  The discussion during the meeting suggests that I need to clarify my comment about draft-lee-pce-flexible-grid.
   
  This I-D is very similar to draft-ietf-pce-wson-rwa-ext, which addresses the exact same problem over a slightly different WDM label space (running a side-by-side diff between them appears to be very practical).
  This new I-D requests the creation of one object and 3 TLVs, which are identical to the ones created in the WSON.
  As a result, I believe the latter should be reused as a starting popint.

Re: [Pce] 答复: My Comment on draft-lee-pce-flexible-grid

[Leeyoung]

Hi Dieter,

I agree. In this draft, we refer to 
https://tools.ietf.org/html/draft-ietf-ccamp-flexible-grid-ospf-ext-09#section-4.1.1
 for the available spectrum encoding. Is this what you are referring to, or 
more than that?

Thanks.
Young

From: Dieter Beller [mailto:dieter.bel...@nokia.com]
Sent: Thursday, July 20, 2017 11:35 AM
To: Zhenghaomian ; Leeyoung ; 
Julien Meuric ; pce@ietf.org; 
draft-lee-pce-flexible-g...@ietf.org
Subject: Re: [Pce] 答复: My Comment on draft-lee-pce-flexible-grid

Hi all,

the description of the available spectrum in draft-lee-pce-flexible-grid should 
in my opinion be consistent with the available spectrum
description in draft-ietf-ccamp-flexible-grid-ospf-ext. Please note that the 
available spectrum is advertised in terms of available central
frequencies!

A central frequency f_c is available only if the spectrum is available in the 
interval [f_c - f_minSlotWidth/2, fc + f_minSlotWidth/2]

If the flexgrid granularity is 6.25GHz and the minSlotWidth is 12.5GHz this 
means leads to: [f_c - 6.25GHz, f_c + 6.25 GHz]

This is different from advertising spectrum slots like for example [f_c_n-1, 
fc_n].

Please note that a modulated optical carrier occupies spectrum symmetrical 
around the central frequency.


Thanks,
Dieter

On 20.07.2017 11:04, Zhenghaomian wrote:

Hi, Julien and Young,



I fully agree on that we should try our best on reusing the existing 
object/TLVs. FYI, when we are working on GMPLS extensions from fixed-grid 
(WSON) to flexi-grid, we have some TLVs in parallel (switching types) for 
fixed/flexi-grid.



I assume this is exactly what we are doing in this draft, the split occurs when 
it is difficult to use existing TLV to represent the new features. In some 
cases, the meaning of flags/TLVs need to be changed to support different 
scenarios, so the similarity on object does not necessarily mean the equivalent 
on functionality.



My 2 cents,

Haomian



-邮件原件-

发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Leeyoung

发送时间: 2017年7月20日 16:41

收件人: Julien Meuric; pce@ietf.org; 
draft-lee-pce-flexible-g...@ietf.org

主题: Re: [Pce] My Comment on draft-lee-pce-flexible-grid



Hi Julien,



I agree. A New flag on the object header (WA Object, I assume that is what you 
are pointing to) where we have a flag to indicate if this is fixed (WSON) or 
flexi-grid is reasonable instead of creating a new object for a new Spectrum 
Assignment Object.



TLVs require a bit different encoding due to the nature of additional 
parameters for flexi-grid. So strict re-use of WSON TLV may not be sufficient 
for some cases in flexi-grid.



Best regards,

Young



-Original Message-

From: Julien Meuric [mailto:julien.meu...@orange.com]

Sent: Thursday, July 20, 2017 10:28 AM

To: pce@ietf.org; 
draft-lee-pce-flexible-g...@ietf.org

Subject: My Comment on draft-lee-pce-flexible-grid



Hi,



The discussion during the meeting suggests that I need to clarify my comment 
about draft-lee-pce-flexible-grid.



This I-D is very similar to draft-ietf-pce-wson-rwa-ext, which addresses the 
exact same problem over a slightly different WDM label space (running a 
side-by-side diff between them appears to be very practical).

This new I-D requests the creation of one object and 3 TLVs, which are 
identical to the ones created in the WSON.

As a result, I believe the latter should be reused as a starting popint.

Covering the flexi-grid case may just need to allocate new flag in the object 
header to identify the WDM type we're dealing with, and document the 
flexi-grid-specific assumptions (if any).



Thanks,



Julien



___

Pce mailing list

Pce@ietf.org

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

___

Pce mailing list

Pce@ietf.org

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

--

Dieter Beller
Open Agent & Routing Project Manager
IP/Optical Networks, Optics, Nokia

t: +49 711 821 43125 | m : +49 175 7266874 | OnNet: 259 43125
dieter.bel...@nokia.com
Alcatel-Lucent Deutschland AG | Lorenzstr. 10 | 70435 Stuttgart
Sitz der Gesellschaft | Domicile of the Company: Stuttgart ・ Amtsgericht 
Stuttgart HRB 4026
Vorsitzender des Aufsichtsrates | Chairman of the Supervisory Board: Prof. J. 
Menno Harms
Vorstand | Board of Management: Wilhelm Dresselhaus (Vorsitzender | Chairman) ・ 
Ralf Niederberger

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or 
destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of 
the e-mail and its attachments, if 

Re: [Pce] 答复: My Comment on draft-lee-pce-flexible-grid

[Dieter Beller]

  
  
Hi all,
  
  the description of the available spectrum in
  draft-lee-pce-flexible-grid should in my opinion be consistent
  with the available spectrum
  description in draft-ietf-ccamp-flexible-grid-ospf-ext. Please
  note that the available spectrum is advertised in terms of
  available central
  frequencies!
  
  A central frequency f_c is available only if the spectrum is
  available in the interval [f_c - f_minSlotWidth/2, fc + f_minSlotWidth/2]
  
  If the flexgrid granularity is 6.25GHz and the minSlotWidth is
  12.5GHz this means leads to: [f_c - 6.25GHz, f_c + 6.25 GHz]
  
  This is different from advertising spectrum slots like for example
  [f_c_n-1, fc_n].
  
  Please note that a modulated optical carrier occupies spectrum
  symmetrical around the central frequency.
  
  
  Thanks,
  Dieter
  

On 20.07.2017 11:04, Zhenghaomian
  wrote:


  Hi, Julien and Young, 

I fully agree on that we should try our best on reusing the existing object/TLVs. FYI, when we are working on GMPLS extensions from fixed-grid (WSON) to flexi-grid, we have some TLVs in parallel (switching types) for fixed/flexi-grid. 

I assume this is exactly what we are doing in this draft, the split occurs when it is difficult to use existing TLV to represent the new features. In some cases, the meaning of flags/TLVs need to be changed to support different scenarios, so the similarity on object does not necessarily mean the equivalent on functionality. 

My 2 cents, 
Haomian

-邮件原件-
发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Leeyoung
发送时间: 2017年7月20日 16:41
收件人: Julien Meuric; pce@ietf.org; draft-lee-pce-flexible-g...@ietf.org
主题: Re: [Pce] My Comment on draft-lee-pce-flexible-grid

Hi Julien,

I agree. A New flag on the object header (WA Object, I assume that is what you are pointing to) where we have a flag to indicate if this is fixed (WSON) or flexi-grid is reasonable instead of creating a new object for a new Spectrum Assignment Object.

TLVs require a bit different encoding due to the nature of additional parameters for flexi-grid. So strict re-use of WSON TLV may not be sufficient for some cases in flexi-grid. 

Best regards,
Young

-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: Thursday, July 20, 2017 10:28 AM
To: pce@ietf.org; draft-lee-pce-flexible-g...@ietf.org
Subject: My Comment on draft-lee-pce-flexible-grid

Hi,

The discussion during the meeting suggests that I need to clarify my comment about draft-lee-pce-flexible-grid.

This I-D is very similar to draft-ietf-pce-wson-rwa-ext, which addresses the exact same problem over a slightly different WDM label space (running a side-by-side diff between them appears to be very practical).
This new I-D requests the creation of one object and 3 TLVs, which are identical to the ones created in the WSON.
As a result, I believe the latter should be reused as a starting popint.
Covering the flexi-grid case may just need to allocate new flag in the object header to identify the WDM type we're dealing with, and document the flexi-grid-specific assumptions (if any).

Thanks,

Julien

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



-- 
  
Dieter Beller 
Open Agent & Routing Project Manager 
IP/Optical Networks, Optics, Nokia 

t: +49 711 821 43125 | m : +49 175 7266874 | OnNet: 259 43125 
dieter.bel...@nokia.com 

  
  Alcatel-Lucent
Deutschland AG | Lorenzstr. 10 | 70435 Stuttgart 
  
  Sitz
der Gesellschaft | Domicile of the Company: Stuttgart ·
Amtsgericht Stuttgart HRB 4026 
Vorsitzender des Aufsichtsrates | Chairman of the Supervisory
Board: Prof. J. Menno Harms 
Vorstand | Board of Management: Wilhelm Dresselhaus
(Vorsitzender | Chairman) · Ralf Niederberger 

This e-mail and its attachments, if any, may contain
confidential information.
If you have received this e-mail in error, please notify us and
delete or destroy the e-mail and its attachments, if any,
immediately. 
If you have received this e-mail in error, you must not forward
or make use of the e-mail and its attachments, if any.
  

  


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

[Pce] PCE WG Minutes.

[Dhruv Dhody]

Hi WG,

The draft minutes for the PCE WG session are uploaded.

https://www.ietf.org/proceedings/99/minutes/minutes-99-pce-00.txt

Please reply, if there any corrections.

Thanks to all, who contributed on etherpad.

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

Re: [Pce] My Comment on draft-lee-pce-flexible-grid

[Leeyoung]

Hi Julien,

I agree. A New flag on the object header (WA Object, I assume that is what you 
are pointing to) where we have a flag to indicate if this is fixed (WSON) or 
flexi-grid is reasonable instead of creating a new object for a new Spectrum 
Assignment Object.

TLVs require a bit different encoding due to the nature of additional 
parameters for flexi-grid. So strict re-use of WSON TLV may not be sufficient 
for some cases in flexi-grid. 

Best regards,
Young

-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: Thursday, July 20, 2017 10:28 AM
To: pce@ietf.org; draft-lee-pce-flexible-g...@ietf.org
Subject: My Comment on draft-lee-pce-flexible-grid

Hi,

The discussion during the meeting suggests that I need to clarify my comment 
about draft-lee-pce-flexible-grid.

This I-D is very similar to draft-ietf-pce-wson-rwa-ext, which addresses the 
exact same problem over a slightly different WDM label space (running a 
side-by-side diff between them appears to be very practical).
This new I-D requests the creation of one object and 3 TLVs, which are 
identical to the ones created in the WSON.
As a result, I believe the latter should be reused as a starting popint.
Covering the flexi-grid case may just need to allocate new flag in the object 
header to identify the WDM type we're dealing with, and document the 
flexi-grid-specific assumptions (if any).

Thanks,

Julien

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

[Pce] My Comment on draft-lee-pce-flexible-grid

[Julien Meuric]

Hi,

The discussion during the meeting suggests that I need to clarify my
comment about draft-lee-pce-flexible-grid.

This I-D is very similar to draft-ietf-pce-wson-rwa-ext, which addresses
the exact same problem over a slightly different WDM label space
(running a side-by-side diff between them appears to be very practical).
This new I-D requests the creation of one object and 3 TLVs, which are
identical to the ones created in the WSON.
As a result, I believe the latter should be reused as a starting popint.
Covering the flexi-grid case may just need to allocate new flag in the
object header to identify the WDM type we're dealing with, and document
the flexi-grid-specific assumptions (if any).

Thanks,

Julien

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