1. Ethernet 802.1ag Fault Management Across Domains Freek Dijkstra, Sander Boele, Ronald van der Pol – SARA TERENA Networking Conference – Reykjavík, 23 May 2012 Sponsored in part by: v 03

2. Ethernet 802.1ag Fault Management Across Domains Freek Dijkstra, Sander Boele, Ronald van der Pol – SARA TERENA Networking Conference – Reykjavík, 23 May 2012 Sponsored in part by: v 03

3. Ethernet 802.1ag Fault Management Across Domains Freek Dijkstra, Sander Boele, Ronald van der Pol – SARA TERENA Networking Conference – Reykjavík, 23 May 2012 Sponsored in part by: v 02

4. SC11 Demonstration

5. Freek Dijkstra (SARA) @ TNC 2012 802.1ag vs. Y.1731 IEEE 802.1agITU-T Y.1731 Connectivity Fault Management (CFM) Operations, Administration, and Maintenance (OAM) Connectivity messagesConnectivity messages + Performance messages http://standards.ieee.org/getieee802/downl oad/802.1ag-2007.pdf (Sep 2007) http://www.itu.int/rec/T-REC-Y.1731 (May 2006)

6. Freek Dijkstra (SARA) @ TNC 2012 Terminology MEPMaintenance End Point MIPMaintenance Intermediate Point MAIDMaintenance Association Identifier "Domain" Identifier MD LevelLevel of a Maintenance Domain (0…7) "Scope": link segment or path monitoring MEP IDMEP Identifier (1...8191)

7. Freek Dijkstra (SARA) @ TNC 2012 802.1ag Messages Loopback (LB)  Layer 2 ping Link trace (LT)  Layer 2 traceroute Continuity check (CC)  One-way hello

8. Freek Dijkstra (SARA) @ TNC 2012 List of Open Issues Continuity Check or Link Trace Who deploys it Transparent transmission Domain Identifier MD level Monitoring Point Identifiers Time interval between Continuity Checks

9. Freek Dijkstra (SARA) @ TNC 2012 1. Continuity Check or Link Trace Continuity Check (CC)  Detect loss of connectivity (suited to link status tests)  Periodic (automatic) hello messages from MEPs  Processed by MEPs  CC frames sent to multicast group, no replies are sent Link Trace Message/Reply (LTM/LTR)  Path information (superior for fault localisation)  Sent manually from MEPs via CLI  Processed by MIPs and MEPs in path  Multicast request including TTL and destination MAC, unicast replies We recommend to deploy both technologies.

10. Freek Dijkstra (SARA) @ TNC 2012 2. Who deploys it Continuity checks: NRENs Similar to present-day link status monitoring Link trace: end-sites (if possible ▼ ) and NRENs Similar to present-day ping and traceroute (▼) There may be a router between NREN and end-user* ➡ Ethernet CFM packets don't traverse routers ➡ End-users may not have access to these routers ➡ End-users can't see Ethernet CFM info ➡ Out-of-band distribution of Ethernet CFM results is still required. *user or other NREN

11. Freek Dijkstra (SARA) @ TNC 2012 3. Transparent transmission Transparent circuits through NRENs + NREN does never interfere with user-protocols - Topology is obscured, making link traces less useful Non-transparent circuits through NRENs + Topology is exposed to user*, making monitoring easier - Need coordination between NRENs about configuration We recommend that at least the Exchanges (GLIF Open Lightpath Exchanges, GOLEs) deploy MIPs. *user or other NREN

12. Freek Dijkstra (SARA) @ TNC 2012 4. Domain Identifier (MAID) Maintenance Association Identifier (MAID) Must be the same for communication Format part 1: Domain Name (optional)  Domain name system (DNS) string  MAC address + integer  String Format part 2: Short Name  VLAN ID  String  Integer (0..65335)  VPN ID (OUI + 32-bit integer) VLAN ID impractical with the uptake of VLAN translation. We recommend the same MAID for all links for all NRENs.

13. Freek Dijkstra (SARA) @ TNC 2012 5. MD levels MD level 76543210 UseCustomer Service provider Operator Higher: end-to-end pathLower: link segment

14. Freek Dijkstra (SARA) @ TNC 2012 6. MEP Identifier (MEP ID) 13-bits Integer (1…8191) Must be unique for each MEP on a VLAN Short: needs coordination to prevent collisions Alternatives  Out-of-band coordination for MEP ID assignment  MAC address used for identification  Extra TLV with DNS name or URN (protocol extension)

15. Freek Dijkstra (SARA) @ TNC 2012 7. Time interval between Continuity Checks Allowed:  3.3 ms (timeout in 11.7 ms)  10 ms (timeout in 35 ms)  100 ms (timeout in 350 ms)  1 s (timeout in 3.5 s)  10 s (timeout in 35 s)  1 min (timeout in 3.5 min)  10 min (timeout in 35 min) We recommend one message every second.

16. Freek Dijkstra (SARA) @ TNC 2012 Thank You! Questions? For further discussion, visit poster #5 in the next coffee break