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

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

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.

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

Scenario 1: Traceroute thru Routed Hops 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. R1R2R3 A1 B1 C1 A2 B2 C2 D1 E1 D2 E2 LAG-1LAG-2 Intf-1: /30 Intf-2: /30Intf-4: /30 Intf-3: /30

Scenario 2: Traceroute thru 1 Switched Hop 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. R1SW1R2 A1 B1 A2 B2 C1 E1 C2 E2 LAG-1LAG-2 Intf-1: /30 Intf-2: /30 D1D2

Scenario 3: Traceroute thru 2+ Switched Hops 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. R1SW2R2 A1 B1 A2 B2 E1 G1 E2 G2 LAG-1LAG-3 Intf-1: /30 Intf-2: /30 F1F2 SW1 C1 D1 C2 D2 LAG-2

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

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.

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.

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.

Comments? Questions?