1 / 7

IETF 64, Vancouver, MPLS WG, 11/08/2005

base
Download Presentation

IETF 64, Vancouver, MPLS WG, 11/08/2005

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements for P2MP Extensions to LDP draft-leroux-mpls-mp-ldp-reqs-02.txtJean-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

  2. 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-To-Multipoint 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

  3. 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)

  4. 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

  5. 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

  6. 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

  7. 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?

More Related