Operations and Maintenance Next Generation Requirements

1. Operations and Maintenance Next Generation Requirements draft-amante-oam-ng-requirements-01 Shane Amante Alia Atlas Andrew Lange Danny McPherson March 10, 2008

2. Overview • Why use LAG, ECMP? • Background • Use Cases • Intra- vs. Inter-AS OAM Requirements • Path Capabilities

3. Why use LAG, ECMP? • LAG, ECMP and ECMP over LAG are used to increase virtual bandwidth between two, or more, [adjacent] nodes. • Why not just use larger links (e.g.: 40G, 100G) and avoid these problems? • Because the problems discussed in this draft still exist with N x 40G, N x 100G, etc.

4. Background & Goals • Inspired by: draft-atlas-icmp-unnumbered • This memo defines ICMP extensions through which an router or host can explicitly identify the interface upon which an undeliverable datagram arrived. The incoming interface can be identified by ifIndex, name, and/or address. The extensions defined herein are particularly useful when troubleshooting networks with unnumbered interfaces, parallel interfaces and/or asymmetric routing. • Goal: Specify requirements to enhance IP & MPLS traceroute and ping to identify and exercise specific paths through links consisting of LAG, ECMP and ECMP over LAG. • i.e., update traceroute/ping for the 21st century. • Prefer one solution, which addresses: • Intra-AS: Lots of information returned to originator • Inter-AS: Limited/Select information returned to originator

5. Scenario 1: Traceroute thru Routed Hops LAG-1 LAG-2 Intf-2: 10.1.1.2/30 Intf-4: 10.5.1.2/30 R1 R2 R3 A1 A2 D1 D2 B1 B2 C1 C2 E1 E2 • During traceroute from R1 to R3, need to know: • Actual component-links used on output and input for a particular user’s microflow. If no response from R3, want to know output component-link used by R2 to get to R3. • If using “legacy” ping, from R1 to R3, it is not guaranteed to be hashed onto same LAG or ECMP component-links as end-user traffic. Intf-1: 10.1.1.1/30 Intf-3: 10.5.1.1/30

6. Scenario 2: Traceroute thru 1 Switched Hop LAG-1 LAG-2 Intf-2: 10.1.1.2/30 R1 SW1 R2 A1 A2 C1 C2 D1 D2 B1 B2 E1 E2 • Mostly the same as Scenario 1, except puts more emphasis on the need to: • Have R1 return outgoing component-link ID, in cases where SW1 dies. • In addition, because SW1 makes an independent hashing decision on IP/MPLS packets need R2 to return incoming component-link ID. Intf-1: 10.1.1.1/30

7. Scenario 3: Traceroute thru 2+ Switched Hops LAG-1 LAG-2 LAG-3 Intf-2: 10.1.1.2/30 R1 SW1 SW2 R2 A1 A2 C1 C2 E1 E2 F1 F2 B1 B2 D1 D2 G1 G2 • Scenario common in Enterprise or DataCenter environments. • SW1 & SW2 commonly understand how to load-hash based on outer IP and/or MPLS payloads to make effective use of bandwidth between them. • “Legacy” traceroute is ineffective because you will not know the identity of component-links between SW1 <-> SW2. • “Legacy” ping is ineffective because traffic is not guaranteed to use component-links as end-user traffic between SW1 <-> SW2 <-> R2. Intf-1: 10.1.1.1/30

8. Other scenarios • ECMP: TBD • Proxy Traceroute/Ping: • Need for functionality similar to draft-ietf-mpls-remote-lsp-ping • PTR/PTP are important, in order to scale automated performance monitoring of larger networks. • Performance Monitoring • Used for automatically & proactively detecting (soft) failures in the network. • Discuss differences between: • Proactive Periodic Perf. Monitoring • Proactive Perpetual Perf. Monitoring

9. Intra-AS OAM Reqmt’s • Must work with IP and MPLS • Traceroute Probe Requests: • Ability to specify input “keys” to hash/ECMP algorithm, (e.g.: 5-tuple for IP), in probe payload to exercise hash algorithm with ‘real’ customer traffic. • Traceroute Probe Replies: • Incoming Interface Name (+ Descr) • Outgoing Interface Name (+ Descr) • # of component-links in a bundle • % BW Utilization on interface(s) • Remote Link-Layer neighbor name + Interface Name • Required for automatically identifying Layer-2 switched hops • Ping • Ability to input “keys” to hash/ECMP algorithm, (e.g.: 5-tuple for IP), in probe payload to exercise hash algorithm with ‘real’ customer traffic. • MUST follow data plane for forwarding within the network elements. • Proxy Traceroute/Ping Support • Used by Network Monitoring systems to proactively exercise paths through network similar to MPLS LSR self-test. • Need some form of (lightweight) authentication for Intra-AS OAM to only reveal detailed network knowledge to “trusted” entities. • Also, recommend that dropping OAM packets may be necessary to prevent starvation of resources within network elements.

10. Inter-AS OAM Reqmt’s • Must work with IP and MPLS • For example: customer & peering links • Traceroute Probe Requests: • Ability to specify input “keys” to hash/ECMP algorithm, (e.g.: 5-tuple for IP), in probe payload to exercise hash algorithm with ‘real’ customer traffic. • Traceroute Probe Replies: • Incoming Interface Name • Outgoing Interface Name • Ping • Ability to specify input “keys” to hash/ECMP algorithm, (e.g.: 5-tuple for IP), in probe payload to exercise hash algorithm with ‘real’ customer traffic.

11. Path Capabilities • Probe before traceroute? Or, • Designate special label/codepoint for “new” OAM protocol? • Draft currently recommends latter approach to deterministically deal with cases of oscillating links and/or paths.

12. Comments? Questions?