Detecting P2MP Data Plane Failures draftyasukawamplsp2mplspping00.txt

1
Detecting P2MP Data Plane Failuresdraft-yasukawa-
mpls-p2mp-lsp-ping-00.txt

• Seisho Yasukawa - yasukawa.seisho_at_lab.ntt.co.jp
  Adrian Farrel - adrian_at_olddog.co.uk

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.

3
Solution Development

• Ideally any potential solutions should look to
  reuse existing techniques.
• Obvious candidate is LSP Ping
• P2P LSP Ping ltdraft-ietf-mpls-lsp-ping-07.txtgt
• 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.

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

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

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
• Cant 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?