1 / 5

Detecting P2MP Data Plane Failures draft-yasukawa-mpls-p2mp-lsp-ping-02.txt

Detecting P2MP Data Plane Failures draft-yasukawa-mpls-p2mp-lsp-ping-02.txt. Seisho Yasukawa - yasukawa.seisho@lab.ntt.co.jp Adrian Farrel - adrian@olddog.co.uk Zafar Ali – zali@cisco.com Bill Fenner - fenner@research.att.com. Recap of Objectives. Point-to-multipoint MPLS development is real

suchi
Download Presentation

Detecting P2MP Data Plane Failures draft-yasukawa-mpls-p2mp-lsp-ping-02.txt

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. Detecting P2MP Data Plane Failuresdraft-yasukawa-mpls-p2mp-lsp-ping-02.txt Seisho Yasukawa - yasukawa.seisho@lab.ntt.co.jp Adrian Farrel - adrian@olddog.co.uk Zafar Ali – zali@cisco.com Bill Fenner - fenner@research.att.com 63rd IETF Parris August 2005

  2. Recap of Objectives • Point-to-multipoint MPLS development is real • P2MP MPLS-TE is under development in the MPLS working group • Work starting on multicast LDP • Need simple and efficient mechanisms to detect data plane failures in P2MP MPLS LSPs Requirements include: • Verification of reception at recipients. • Discovering point-to-multipoint tree topology. • Ping/Trace from ingress/egress. • Whole tree (source-to-recipient) • Individual recipients • Objective is to build a solution on top of existing LSP Ping technology 63rd IETF Parris August 2005

  3. Proposed Solution • Heavy re-use of LSP Ping • Need to identify the LSP • Introduce RSVP P2MP Session sub-TLV • Ingress can control ping/trace of whole tree or individual recipients • Necessary to protect the ingress from being swamped • Introduce P2MP Egress Identifier sub-TLV (of FEC Stack TLV) • Place-holder for multicast LDP FEC when stable • P2MP LSP Ping • Echo request cannot be filtered based on identified recipient • Echo response only from targeted recipient • P2MP LSP traceroute • Echo request cannot be filtered based on identified recipient • Only LSRs on the path to identified recipients respond 63rd IETF Parris August 2005

  4. Changes in 02 Revision • New co-author (Bill Fenner) • Introduce jitter parameter • Allows initiator to specify jitter at responder • Increases size of tree that can be pinged • Parameter might be added to response to indicate how much jitter was applied (not in current version) • Editorial nits and boilerplate 63rd IETF Parris August 2005

  5. Further Issues & Questions • Support multicast LDP in the same I-D? • Yes! • Will need work to support multicast FEC • Consult with mLDP authors • Ping a subset of leaves? • Removed from early versions • Too much processing at transit nodes • Question raised in Minneapolis, but no follow-up on list • Minneapolis • Agreed not to merge with P2P LSP Ping I-D • Agreed this MPLS WG work • Agreed need for P2MP OAM requirements I-D • Now available • Now ready to be WG doc? 63rd IETF Parris August 2005

More Related