E N D
IGP extensions for PCE Discoverydraft-leroux-pce-disco-proto-igp-00.txtJ.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 selection • Dynamic 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-caps • OSPF 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 selection • Two mandatory elements: PCE address(es) & PCE path scope • Three 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 domain • In ISIS this is controlled by the S bit of the ISIS CAPABILITY TLV • In 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 scalability • Static information • WG feedback is required
Impact on the IGP? • Amount of information? • Only a few pieces of information • This 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 flooding • But 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