Transcript PPT Version

Requirements
for P2MP Extensions to LDP
draft-leroux-mpls-mp-ldp-reqs-02.txt
Jean-Louis Le Roux (France Telecom)
Thomas Morin (France Telecom)
Vincent Parfait (Equant)
Luyuan Fang (AT&T)
Lei Wang (Telenor)
Yuji Kamite (NTT Communications)
Shane Amante (Level 3 Communications)
IETF 64, Vancouver, MPLS WG, 11/08/2005
Motivations and Objectives (Reminder)
 LDP largely deployed for setting up unicast LSPs in MPLS VPN
networks
 Emerging requirements for supporting multicast traffic delivery
within these MPLS VPN networks
 A relevant approach for multicast traffic delivery over a LDP enabled
MPLS backbone = LDP extensions for setting up Point-ToMultipoint LSPs (P2MP LSPs)
 This draft focuses on the LDP approach for setting up P2MP LSPs
 It lists a detailed set of requirements for P2MP extensions to LDP
To be used as guidelines when specifying LDP extensions
Requirements summary
 MUST allow setting up P2MP LSPs
 MUST define a FEC suitable for P2MP forwarding
 SHOULD rely on unicast routing table for setting up MPLS shortest path trees
 SHOULD support leaf initiated approach for LSP setup and modification
 SHOULD avoid data duplication
 SHOULD avoid routing loops
 SHOULD minimize recovery upon network failure
 SHOULD avoid both packet loss and packet duplication during rerouting upon










planned maintenance or metric change: Tension?
MUST avoid traffic replication on LAN interfaces
MUST Support encapsulation in P2P and P2MP TE tunnels
MUST support IPv4/IPv6 (control and forwarding)
MUST support multi-area LSPs
OAM Requirements:
MIB module, connectivity checking and path tracing tool, fast failure detection tool
MUST support Graceful Restart and Fault Recovery
SHOULD scale independently of the number of leaves
SHOULD allow setting up P2MP LSPs over a transit non branch legacy LSR
MUST not impede the operations of unicast LSPs
MAY support Multipoint-to-Multipoint LSPs (MP2MP LSPs)
Changes since last version
 Added an application scenario
Multicast VPN traffic delivery on a LDP-enabled MPLS backbone
 Clarified routing requirements
 Clarified OAM requirements
Need for extensions of P2MP LSP-Ping to LDP P2MP LSPs
Need for a fast data plane failure detection mechanism for P2MP LDP LSPs
Detailed requirements addressed in the P2MP MPLS OAM draft
 Added orders of magnitude of the expected #Trees &
#Leaves / Tree
Extracted from the Multicast L3 VPN survey (L3VPN WG)
 Added some text on shared trees and MP2MP LSPs
 Some rewordings for the sake of clarity
Remaining issues (1)
 Need to complement the requirements related to LAN interfaces,
when there are several candidate upstream LSRs
The solution MUST allow selecting a single upstream for a given P2MP
LSP on a LAN
The solution SHOULD support for efficient balancing of a set of P2MP
LSPs among a set of candidates upstream LSRs on a LAN interface
 Need to detail routing requirements
Consensus among SPs on this draft that P2MP LDP routing SHOULD
rely on the unicast RIB for setting up MPLS SPT, and not require an IP
multicast routing protocol…
We need to detail the rationales for this requirement
This requires more discussions and WG feedback
Remaining issues (2)
 About shared trees
Two main approaches for setting up shared trees in an MPLS network:
– MPLS level: Multipoint-to-Multipoint LSPs (MP2MP LSPs) => need for specific
LDP procedures
– Application level: Combination of a MP2P LSPs with a P2MP LSP (see
Multicast 2547 ID)
Not clear analysis of the pros and cons of the two approaches at the time
being
– Do we need both approaches?
– What would be the gain of the MP2MP approaches versus the added complexity on
LDP?
This is why the requirement for MP2MP LSPs remains OPTIONAL
Of course this may evolve based on WG feedback
Next steps
Need for WG feedback, particularly on open issues
A WG polling in Paris showed a significant interest for this
work
WG doc?
To chairs: What is the status of the WG charter update process?