Requirements for P2MP Extensions to LDP draftlerouxmplsmpldpreqs01.txt

1
Requirements for P2MP
Extensions to LDP
draft-leroux-mpls-mp-ldp-reqs-01.txt


Jean-Louis Le Roux
(France Telecom)
Thomas Morin (France Telecom)
Vincent Parfait (Equant)
Luyuan Fang (ATT)
Lei Wang (Telenor)
Yuji Kamite (NTT Communications)
Shane Amante (Level 3 Communications)

• IETF 63, Paris, MPLS WG, 08/01/2005

2
Does this ID fit in with the MPLS Charter??

• This draft lists a set of functional requirements
  for P2MP extensions to LDP
• From MPLS WG Charter
• "procedures and protocols for multicast protocol
  extensions for point-to
• multipoint TE, including soft-preemption"
• What does it mean?
• Some charter rewording would be highly benefic ?
• Proposal "Procedures and protocols for
  point-to-multipoint MPLS, including Traffic
  Engineering"
• Soft preemption is actually a separate item
• Hence, can we say that P2MP LDP is part of the
  charter?
• Strictly speaking NO
• But after this cosmetic rewording YES ?

3
Problem Statement 1/2

• LDP largely deployed for setting up unicast MPLS
  LSPs
• Point-to-point MPLS traffic delivery
• Major applications PE-to-PE tunneling in MPLS
  L3/L2 VPN networks
• Emerging requirements for supporting multicast
  traffic delivery in these MPLS VPN networks (see
  ongoing work in L3/L2VPN WGs)
• Use of MPLS tunneling for delivery of multicast
  traffic in these MPLS VPN networks is a valuable
  approach
• Consistency with unicast traffic delivery
• Take full advantage of MPLS infrastructure
• Could rely on a group of unicast LSPs, with
  traffic replication on the Ingress LSR
• But this is sub-optimal and may lead to
  significant bandwidth wasting

4
Problem Statement 2/2

• Hence new mechanisms are required for setting up
  P2MP LSPs
• P2MP LSP One Ingress LSR and one or more Egress
  LSRs, with MPLS traffic replication at some
  Branch LSRs
• as already well pointed out in draft-ietf-mpls-p2m
  p-sig-requirements
• Several possible approaches for setting up P2MP
  LSPs, with some common and some distinct
  capabilities and properties
• RSVP-TE, LDP, or PIM extensions
• Important work already done for P2MP TE LSPs
  signaling
• See draft-ietf-mpls-rsvp-te-p2mp
• For LDP-based MPLS networks without TE needs, a
  relevant approach would consist of relying on
  simple LDP extensions for setting up P2MP LSPs
• Provided of course, that this does not introduce
  complexity to such a degree that it would
  diminish the benefits of reusing LDP ?

5
ID Objectives / Non Objectives

• This document focuses on the LDP approach for
  setting up P2MP LSPs
• List of detailed requirements for P2MP extensions
  to LDP
• Some are common with the P2MP TE Reqs ID
  (draft-ietf-mpls-p2mp-sig-requirements)
• To be used as guidelines when specifying LDP
  extensions
• Non objectives
• Generic requirements for P2MP MPLS
• Comparison of various P2MP MPLS approaches

6
Illustration
PE
7
Requirements summary 1/4

• P2MP LSP
• Same data plane aspects (Branch LSR) as defined
  in the P2MP TE req ID
• A P2MP LDP LSP MUST be identified by a constant
  and unique identifier
• Need to define a FEC that is suitable for P2MP
  forwarding
• P2MP LSP Setup/Teardown/Modification
• It is RECOMMENDED to follow a leaf initiated LSP
  setup/teardown approach, so as to scale well with
  a large number of leaves
• The way leaf LSRs discover LSP identifiers
  depends on the application and is out of the
  scope of P2MP LDP
• MUST support dynamic addition/removal of Leaf
  LSRs
• It is RECOMMENDED that this imply processing only
  on the path from the Branch LSR to the
  added/removed Leaf LSR

8
Requirements summary 2/4

• Data Duplication
• SHOULD be avoided and limited to rare transitory
  conditions
• Routing Loops
• Routing loops that may trigger non-localized
  exponential growth of traffic MUST be avoided
• Any loop avoidance mechanism MUST respect
  scalability requirements
• P2MP LDP Routing
• MUST support hop-by-hop routing
• SHOULD rely upon RIB information
• P2MP LDP MUST support LSP re-routing
• On a better path gt Packet loss SHOULD be
  avoided, potential data duplication MUST be
  minimized
• Upon network failure gt Recovery time SHOULD be
  minimized, need for a mechanism to avoid LSP
  flapping
• For planned maintenancegt SHOULD avoid packet
  loss, potential data duplication MUST be
  minimized

9
Requirements summary 3/4

• P2MP LDP on LAN interfaces
• MUST allow to send a single copy of the data to
  reach a set of downstream LSRs on a LAN segment
• This requires that the same label be negotiated
  with all downstream LSRs
• An upstream label allocation mode sounds relevant
  to ease such negotiation
• Label spaces
• MAY be shared or dedicated (gtDedicated implies
  separate LDP sessions)
• Note that upstream label allocation requires
  dedicated label spaces (context specific label
  space)
• P2MP LDP MUST be equally applicable to IPv4 and
  IPv6
• Control and data plane

10
Requirements summary 4/4

• P2MP LDP MUST allow setting up Multi-Area LSPs
• Without any impact on IGP hierarchy
• P2MP OAM
• Required enhancements to the LDP MIB module
• This may yield a new MIB module inherited from
  the LDP MIB
• Precise requirements are already or will be
  addressed in the P2MP OAM ID
• Graceful Restart/Fault Recovery
• LDP GR and FT has to be enhanced to support P2MP
  LSPs
• Scalability MUST be designed to scale well with
  an increase of Leaf LSRs, Branch LSRs, LSPs
  per LSR
• Backward compatibility
• MUST interoperate seamlessly with and inherit its
  capability set from unicast LDP
• MUST not impede operations of unicast LSPs
• SHOULD allow setting up P2MP LSPs among legacy
  non branch transit LSRs

11
Open Issues 1/2

• Shared trees
• Shared trees would be useful for traffic delivery
  between a group of N PE acting indifferently as
  Ingress or Egress.
• This would avoid having N P2MP LSPs rooted at
  each PE, and would reduce the amount of LDP state
  to be maintained on an LSR
• Various approaches to build such shared trees
• MPLS level gt Multipoint-to-Multipoint LSPs
  (MP2MP LSPs)gt Need for specific LDP procedures
• Application level gt Unicast LSPs to a root PE
  and one P2MP LSP from the root PE to each other
  PE gt See draft-ietf-l3vpn-2547bis-mcast-00.txt
• Is there a need for shared trees?
• Ongoing simulation effort to quantify the real
  gain of shared trees in operational MPLS networks
  
• If yes, should it rely on application level
  procedures or on LDP procedures (MP2MP LSPs) or
  both?
• MP2MP LSP Support is currently a MAY but this
  could evolve

12
Open Issues 2/2

• Need for a survey of the expected order of
  magnitude of leaf LSRs, Number of LSPs per
  LSR, Leaf activity
• Some parameters will be deduced form the
  Multicast VPN survey
• Service Providers' feedback would be highly
  useful

13
Next Steps

• Interest for this work ?
• Need for WG feedback, particularly on open issues
• WG doc ?