IGP%20extensions%20for%20PCE%20Discovery%20%20%20%20%20%20%20%20%20%20draft-leroux-pce-disco-proto-igp-00.txt

1
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

2
Context

• Rationales Requirements for automatic PCE
  discovery are listed in draft-ietf-pce-discovery-r
  eqs-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/deactivat
  ed
• A change in PCE configuration
• PCE failure
• This is a stable information that will not change
  frequently
• gt Hence minimal impact on the IGP