1 / 9

IETF 64, Vancouver 11/09/2005

siusan
Télécharger la présentation

IETF 64, Vancouver 11/09/2005

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

  5. 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)

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

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

  8. ThanksQuestions?

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

More Related