Subject: [Pce] PCE - New Charter Proposal

From: JP Vasseur <[email-masked]>
Date: Tue, 15 Mar 2011 01:38:34 -0700

Dear WG,

Julien and I have discussed a proposal for PCE rechartering. Would you mind commenting before our WG meeting in Prague ? Thanks.

Description of Working Group:

The PCE Working Group is chartered to specify the required protocols so as
to enable a Path Computation Element  (PCE)-based architecture for the
computation of paths for MPLS and GMPLS  Point to Point and Point to Multi-
point Traffic Engineered LSPs.

In this architecture path computation does not necessarily occur on the
head-end (ingress) LSR, but on some other path computation entity that may
physically not be located on each head-end LSR.

The PCE WG works on application of this model within a single domain
or within a group of domains (where a domain is a layer, IGP area or
Autonomous System with limited visibility from the head-end LSR). At
this time, applying this model to large groups of domains such as the
Internet is not thought to be possible, and the PCE WG will not spend
energy on that topic.

The WG specifies the PCE communication Protocol (PCEP) and
needed extensions for communication between LSRs (termed Path
Computation Clients - PCCs) and PCEs, and between cooperating PCEs.
Security mechanisms such as authentication and confidentiality are
included.

The WG determines requirements for extensions to existing routing
and signaling protocols in support of PCE architecture and signaling of
inter-domain paths (e.g. RSVP-TE and its GMPLS variations). Any necessary
extensions will be produced in collaboration with the Working Groups
responsible for the protocols.

The WG also works on the mechanisms to for multi-layer path computation
and PCEP extensions for communication between several network layers.

The WG defines the required PCEP extensions for Wavelength Switched
Optical Networks (WSON) while keeping consistency with the GMPLS
architecture specified in the CCAMP WG.

Work Items:

- PCEP extensions for MPLS and GMPLS Traffic Engineered LSP path
computation models involving PCE(s). This includes the case of computing
the paths of intra and inter-domain TE LSPs. Such path computation includes
the generation of primary, protection and recovery paths, as well as
computations for (local/global) reoptimization and load balancing. Both
intra- and inter-domain applications are covered.
- In cooperation with protocol specific Working Group (e.g. MPLS, CCAMP),
development of LSP signaling (RSVP-TE) extensions required to support PCE-
based path computation models.
- Specification of PCEP extensions for communication in the various GMPLS-
controlled networks, including WSON.
- Definition of PCEP extensions for path computation in multi-layer
networks.

* To be discussed with the WG:
*1* Specification of PCEP extensions for VPN-specific uses.

Goals and Milestones:

June 2011    Submit WSON requirements to the IESG to be considered as an Informational RFC
June 2011    Submit vendor constraints in PCEP to the IESG to be considered as a Proposed Standard
Sept 2011    Submit extensions for hierarchical PCE path computation model as WG document
Oct 2011    Submit PCEP extensions for WSON as WG I-D
Oct 2011    Submit the PCEP MIB to the IESG to be considered as a Proposed Standard
Nov 2011    Submit the discovery MIB to the IESG to be considered as a Proposed Standard
Nov 2011    Submit inter-layer extensions to the IESG to be considered as a Proposed Standard
Dec 2011    Submit inter-area/AS applicability statement to the IESG as an informational RFC
*1*Nov 2011    Submit VPN extensions as WG document
Jan 2012    Submit the GMPLS requirements to the IESG to be considered as an Informational RFC
Mar 2012    Submit PCEP extensions for GMPLS to the IESG to be considered as a Proposed Standard
May 2012    Submit PCEP extensions for WSON to the IESG to be considered as a Proposed Standard
Jul 2012    Submit P2MP MIB to the IESG to be considered as a Proposed Standard
Oct 2012    Submit VPN extensions to the IESG to be considered as a Proposed Standard
Jan 2013    Submit extensions for hierarchical model to the IESG to be considered as a Proposed Standard
Feb 2013    Evaluate WG progress, recharter or close

---

From: Olivier Dugeon <[email-masked]>
Date: Fri, 25 Mar 2011 18:31:13 +0100

Dear all,

After implementing BRPC and studying inter-as PCE applicability, I 
wonder if there would be an opportunity
in the new charter to introduce a study point on how to fulfil the 
database of the PCE. Indeed, when using
BRPC across several domain (we play with around 10 AS in our labs) we 
miss some important information. For
example, we must fulfil PCE database by hand to provision ASBR 
information, inter link connectivity, IP
address of neighbour PCE, originating network prefix attached to the AS 
and so on. I now that PCE database
is implementation specific, but these information are needed if we want 
to optimize the BRPC process (e.g.
by avoiding to flood all PCE). So,I wonder if other peoples are 
concerned by this problem and if a few study
point couldbe added to the new PCE charter. The idea would be to define 
a new protocol or extensions to the
PCEP protocol to provide all relevant information to the PCE to run the 
BRPC.

Regards,

Olivier

-- 
Olivier Dugeon
Senior Research Engineer, QoS and network control
Orange Labs

Le 03/15/11 09:38, JP Vasseur a écrit :
> Dear WG,
>
> Julien and I have discussed a proposal for PCE rechartering. Would you 
> mind commenting before our WG meeting in Prague ? Thanks.
>
> */* To be discussed with the WG:
> /**1* Specification of PCEP extensions for VPN-specific uses.
>
> Goals and Milestones:
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Ramon Casellas <[email-masked]>
Date: Fri, 25 Mar 2011 18:50:05 +0100

> and so on. I now that PCE database
(...)

> concerned 

(...)
> PCEP protocol

Dear Olivier, all

My 0.02 €, for what is worth

Until now, our main approach (also shared by other implementors, afaict) is either to behave as a passive OSPF-TE listener, to collocate the PCE in a node running OSPF, or to implement a (non-standard) interface (XML/SOAP) to request the TED from a topology server. 

ABR / ASBRs are "indentified" by parsing External / Summary LSAs (which means that not only AS/Area TE opaques must be parsed), along with the relevant CIDR prefixes (we assume that control plane nodeids and router addresses -- as in OSPF-TLVs -- are equal). Inter-AS OSPF-TE links are "learnt" by parsing InterAS new TLV (rfc5392), although only in the outbound direction. This has been "enough" to test BRPC and H-PCE in a multi-AS scenario, with reduced manual provisioning, but, as you say, in BRPC, PCE peers (along the prefixes / domains they are responsible for) are pre-configured at each PCE. In H-PCE, the mapping PCEs/domains/endpoints are announced in the OPEN with the parent.

However, when working on H-PCE, child PCEs cooperate to "build" the parent aggregated TED. In this sense, we have also implemented the possibility to wrap OSPF-TE (either full LSU packets or selected LSAs, including the advertising router) within PCEP using a non standard Notification type / value and TLVs (alternatively the TED "pieces" are encoded as XML and also wrapped in another TLV). CIDR Address prefixes for endpoint localization at the parent level are forwarded in ERO-like objects. This approach has worked on relatively well, -- and I would like to discuss it within draft-h-pce-pcep -- but I am still unsure whether it should be included in the charter or not (I would not object to it). I am not knowledgeable enough regarding IS-IS to elaborate.

I would also appreciate other PCE'rs feedback.

Best regards,
Ramon

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01

--