IETF- 58

1
IETF- 58 Minneapolis
Inter-AS MPLS Traffic Engineering
draft-vasseur-inter-AS-TE-01.txt 
Jean-Philippe Vasseur Cisco Systems
Raymond Zhang - Infonet
draft-vasseur-inter-AS-TE-01.txt

IETF-58 - Minneapolis
2

• draft-vasseur-inter-as-te-01.txt
• First published two IETF ago,
• Addresses a CCAMP WG item of the new charter
• Define signaling and routing mechanisms to make
  possible the creation of paths that span multiple
  IGP areas, multiple ASes, and multiple providers,
  including techniques for crankback.
• ...
• The draft defines two scenarios for signalling
  and routing of TE LSPs spanning multiples ASes
• Per-AS path computation
• Distributed path computation between PCSes
  (ASBR)
• Can be used in combination with Hierarchical
  LSPs, crankback,
• draft-vasseur-mpls-loose-path-reopt-01.txt
  proposes a set of mechanisms allowing a Head-end
  to exert a strict control on the TE LSP
  reoptimization process and draft-ietf-mpls-nodeid-
  subobject-00.txt to support MPLS TE Fast Reroute

draft-vasseur-inter-AS-TE-01.txt

IETF-58 Minneapolis
3
Two scenarios

• Scenario 1 per-AS TE LSP Path computation
• - No impact on RSVP/IGP scalability,
• Semi-dynamic,
• Small set of protocol extensions required,
• No optimal end to end path
• Diverse path computation not always possible
  (Path protection, load balancing)
• Call set up failure,
• Support of end to end reoptimization
  (timer/event driven)
• Support of FRR Bypass for ASBR protection

• Scenario 2 distributed path computation server
• No impact on RSVP/IGP scalability,
• Dynamic,
• - Implementation more complex,
• Optimal end to end path
• Diverse path computation always possible (Path
  protection, load balancing)
• No call set up failure (not more than with a
  single area/AS)
• Support of end to end reoptimization
• Support of FRR Bypass for ASBR protection
• TE LSP local protection recommended

Scenario 1 and 2 are both compliant with the set
of requirements defined in draft-ietf-tewg-interas
-mpls-te-req-00.txt
draft-vasseur-inter-AS-TE-01.txt

IETF-58 Minneapolis
4

• Changes compared to rev -00 (Cont)
• A few naming inconsistencies have been fixed,
  clarifications and examples added, minor
  extensions
• Definition of the LSP-ATTRIBUTE object
• 0x01 Crankback allowed bit When set, the
  boundary LSP can either decide to forward the
  Path Error message upstream to the Head-end LSR
  or try to select another egress boundary LSR
  (which is also referred to as crankback). When
  cleared, this bit indicates that a boundary
  region LSR (an ABR or an ASBR LSR), when
  receiving a Path Error message from a downstream
  boundary LSR MUST propagate the Path Error
  message up to the inter-region head-end LSR.
• ? Will probably be removed (see 0x40 Hierarchical
  re-routing desired in draft-iwata-mpls-crankback-0
  7.txt)
• 0x02 Contiguous LSP required bit when set, this
  indicates that a boundary LSR MUST not perform
  any stitching or nesting on the TE LSP and the TE
  LSP MUST be routed as any other TE LSP (it must
  be contiguous end to end). When this bit is
  cleared, a boundary LSR can decide to perform
  stitching or nesting. This bit MUST not be
  modified by any downstream node. See draft
  ayyangar-inter-region-te-00.txt for a definition
  of TE LSP stitching.
• 0x04 LSP stitching required bit this flag is
  set for the segment LSP. This flag SHOULD not be
  modified by any LSRs in between. If the egress
  LSR for the segment LSP does not understand this
  flag then it will simply forward the object
  unmodified and will send a Path Error message
  upstream
• ? Will be defined in draft-farrel-mpls-rsvpte-attr
  ibutes-00.txt

draft-vasseur-inter-AS-TE-01.txt

IETF-58 Minneapolis
5
Proposed next steps and questions

• More discussion on the list about the proposed
  solution (probably a good time since there are
  already several vendor implementations and
  planned deployments )
• Attempt to come up with a merged draft for
  inter-AS TE
• Questions to the WG
• Should that draft cover both inter-area and
  inter-AS TE ?
• Should some companion draft like
  draft-vasseur-mpls-loose-path-reopt-01.txt be
  moved in CCAMP ?
• Should the solution address both packet and
  non-packet based LSPs ?
• What about LSR-PCS signalling extensions ?

draft-vasseur-inter-AS-TE-01.txt

IETF-58 Minneapolis