PCECP Specific Requirements for Inter-Area Path Computation draft-ietf-pce-pcecp-interarea-reqs-01.txt

1
PCECP Specific Requirements for
Inter-Area Path Computation
draft-ietf-pce-pcecp-interarea-reqs-01.txt


Jerry Ash
(ATT) Nabil Bitar
(Verizon) Dean Cheng
(Cisco) Kenji Kumaki
(KDDI) J.L. Le Roux
(France Telecom)

Eiji
Oki (NTT) Raymond
Zhang (BT Infonet)
Renhai Zhang (Huawei)

• IETF 65, PCE WG, Dallas, 03/20/2006

2
Changes since last version (1)

• The draft has been adopted as WG document after
  Vancouver meeting
• A new co-author joined the draft
• Section related to the various PCE-based
  inter-area path computation approaches (mono-area
  PCE, multi-area PCE, all-area PCE) has been
  removed
• To be added in a future PCE-based inter-domain
  applicability statement
• As agreed in Vancouver, generic requirements have
  been moved to the generic ID
• Objective functions
• Path reoptimization
• Path rerouting
• Load balancing path group
• Metric selection in a request message
• Metric recording in a response message

3
Changes since last version (2)

• Added a requirement on area crossing indication
• The response message MUST allow indicating
  whether the returned path crosses area
  boundaries. This may be a useful indication when
  the source and destinations are located within
  the same area
• Added a requirement on Area Recording
• A response message MUST support the inclusion of
  the identifiers of the crossed areas and MUST
  allow identifying the corresponding path segments
• Clarified requirements for inter-area diverse
  path computation
• Some rewordings for the sake of clarity
• We now have a 10-page draft, as requested by the
  chairs ?

4
Next Steps

• Sounds quite stable
• WG feedback required
• A new revision incorporating WG feedback to be
  posted by the end of April
• Then the draft should be ready for WG last call
• Time to start working on protocol solutions

5
ThanksQuestions?
6
Background and objectives (Reminder)

• RFC4105 defines requirements for inter-area
  MPLS-TE
• This includes the computation of end-to-end
  inter-area constrained
• shortest path
• With as key guideline to respect the IGP
  hierarchy properties and
• particularly the containment of routing
  information
• Inter-Area optimal path computation may be
  achieved using
• the services of one or more PCEs
• This could rely on a single multi-area PCE
• This could rely on a cooperation between PCEs in
  each area
• This implies specific requirements on the PCE
  Communication
• Protocol (PCECP)
• This ID complements generic PCECP requirements by
  listing a
• detailed set of requirements specific to
  inter-area path computation

7
Requirements summary (1)

• Control of area crossing
• The request message MUST allow indicating whether
  area crossing is allowed or not
• The response message MUST allow indicating
  whether the path crosses area boundaries
• Areas recording
• A response message MUST support the inclusion of
  the identifiers of the crossed areas and MUST
  allow identifying the corresponding path segments
• Inclusion of source/destination area IDs in the
  request
• The request message MUST support the inclusion of
  the source and destination area IDs
• Strict explicit path and Loose path
• The request message MUST allow indicating whether
  a Strict Explicit Path is required/desired

8
Requirements summary (2)

• PCE-list Enforcement and Recording in Multiple
  PCE Computation
• The PCECP request message MUST support the
  inclusion of a list of preferred PCEs
• The response message MUST support the recording
  of the set of one or more PCEs that took part in
  the computation
• Inter-Area Diverse Path computation
• The request message MUST allow requesting the
  computation of a set of inter-area diverse paths
  between the same node pair or between distinct
  node pairs
• It MUST allow indicating the required level of
  intra-area diversity (link, node, SRLG) on a per
  area basis, as well as the level of inter-area
  diversity (shared ABRs or ABR disjointness)
• Inter-Area Policies
• The request message MUST allow indicating the
  orignating PCC
• The request message MUST allow indicating that AS
  crossing is not authorized