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

1. Detecting P2MP Data Plane Failuresdraft-yasukawa-mpls-p2mp-lsp-ping-00.txt Seisho Yasukawa - yasukawa.seisho@lab.ntt.co.jp Adrian Farrel - adrian@olddog.co.uk 61st IETF Washington DC November 2004

2. Problem Statement Recent proposals have extended the scope of MPLS TE LSPs to encompass P2MP TE LSPs. There is a requirement for 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 Issues to overcome include: • Tracing in a tree context. • Ping/Trace from receiver to source may not be viable. • Scalability. 61st IETF Washington DC November 2004

3. Solution Development Ideally any potential solutions should look to reuse existing techniques. • Obvious candidate is LSP Ping P2P LSP Ping <draft-ietf-mpls-lsp-ping-07.txt> • Ping to verify the LSP connectivity. • Traceroute to identify LSP paths as well as fault isolation. • Return codes to indicate possible errors. Adapting P2P LSP Ping for P2MP networks • Scaling ping • Handling multiple recipient echo replies. • Ability to target specific recipients. • Scaling trace • Tracing across point-to-multipoint tree topologies. • Displaying transit and branching routers. • Security & bandwidth handling • DOS attacks. • Handling simultaneous query responses. 61st IETF Washington DC November 2004

4. Proposed Solution • Heavy re-use of LSP Ping • Need to identify the LSP • LSP Ping has RSVP Session sub-TLV • We need to identify a P2MP 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) • 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 61st IETF Washington DC November 2004

5. Other Features • Branch and bud (drop-and-continue) flags added to Downstream Mapping TLV • Coordination of responses • Problem is that traceroute for the whole tree will return many responses • Many possible solutions for coordination • We have chosen to list the recipients on each branch • Helps build up a picture of the tree early • Helps understand the tree when there are multiple faults • Achieved using new Downstream Mapping Multipath Information 61st IETF Washington DC November 2004

6. Issues & Questions • Is this the right approach, what are the alternatives? • Base on LSP Ping or develop new protocol? • Ping/Trace from the recipient to the source • Easier to navigate the tree • Not obvious for operational use • Can’t build the whole tree • How to handle scaling? • Control simultaneous echo responses using identified recipient • An option would be to use jittered responses • Additional Requirements? • Targeting specific groups of receivers? • Specifying Ping/Trace source nodes? • What should happen to this draft? • Merge with existing MPLS LSP Ping or create new draft? • Something the MPLS WG should be working on? 61st IETF Washington DC November 2004