IGP extensions for PCE Discovery

draft-leroux-pce-disco-proto-igp-00.txt J.L. Le Roux (France Telecom) J.P. Vasseur (Cisco System Inc.) Yuichi Ikejiri (NTT Communications)

IETF 64, Vancouver 11/09/2005

Context

Rationales & Requirements for automatic PCE discovery are listed in draft-ietf-pce-discovery-reqs-02.txt

Work is completed, WG last call ended two weeks ago

These requirements include:Automatic discovery of the location of a set of PCEs within and across

domain boundaries, along with some information relevant for PCE selectionDynamic discovery of a change in PCE information or a new PCE

Motivations

When PCEs are LSRs participating to the IGP (ISIS, OSPF), or even servers participating passively to the IGP, a simple an efficient way for PCE discovery consists of relying on IGP flooding

Generic mechanisms have been defined for the advertisement of node information in ISIS and OSPF:

ISIS CAPABILITY TLV : draft-ietf-isis-capsOSPF Router Information LSA: draft-ietf-ospf-caps

This perfectly fits with the dynamic PCE discovery requirements

ID Overview

This ID defines simple ISIS and OSPF extensions for the advertisement of PCE information within and across IGP areas

A new PCE Discovery TLV (PCED TLV) is defined, to be carried: within the ISIS CAPABILITY TLV within the OSPF Router Information LSA

This allows an IGP node to advertise its PCE information (location, scope…)

This ID only addresses discovery within an IGP domain

The PCED TLV

The PCED TLV includes information relevant for PCE selectionTwo mandatory elements: PCE address(es) & PCE path scopeThree optional elements:

–The set of domain(s) where the PCE has topology visibility–The set of destination domain(s) towards which the PCE can compute paths–A set of general and path computation specific PCE capabilities

Flooding scope: local or entire IGP domainIn ISIS this is controlled by the S bit of the ISIS CAPABILITY TLVIn OSPF this is controlled by the Router Information LSA type (10 or 11)

Where does this ID fit?

This document does not define any new OSPF or ISIS elements of procedure

But rather how OSPF and ISIS generic capability procedures should be used

Hence, it will be discussed within the PCE WG with a review of the ISIS and OSPF WGs, as agreed with these WGs

Once stabilized it may be splitted in two separate ISIS and OSPF documents for the sake of clarity

Next steps

This ID meets requirements for PCE discovery inside an IGP domain (intra-AS discovery)

Quite straightforward and perfect fit with ISIS and OSPF caps

Minor extension, negligible impact on IGP scalabilityStatic information

WG feedback is required

Thanks

Questions?

Impact on the IGP?Amount of information?

Only a few pieces of informationThis can be reduced in most cases to one PCE address

and the PCE scope (8 bytes…)

Frequency of change?Any change in the information maintained in the PCED

TLV will trigger LSA floodingBut PCE information is quite static, it may actually be

updated in the following cases:–A PCE is installed/removed or activated/deactivated–A change in PCE configuration–PCE failure

This is a stable information that will not change frequently

=> Hence minimal impact on the IGP