--- 1/draft-ietf-6man-spring-srv6-oam-00.txt 2019-11-03 07:13:37.669147388 -0800 +++ 2/draft-ietf-6man-spring-srv6-oam-01.txt 2019-11-03 07:13:37.717148602 -0800 @@ -1,25 +1,25 @@ 6man Z. Ali Internet-Draft C. Filsfils Intended status: Standards Track Cisco Systems -Expires: February 8, 2020 S. Matsushima +Expires: May 6, 2020 S. Matsushima Softbank D. Voyer Bell Canada M. Chen Huawei - August 9, 2019 + November 3, 2019 Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6) - draft-ietf-6man-spring-srv6-oam-00 + draft-ietf-6man-spring-srv6-oam-01 Abstract This document defines building blocks for Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane (SRv6). The document also describes some SRv6 OAM mechanisms. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 8, 2020. + This Internet-Draft will expire on May 6, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -63,40 +63,41 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology and Reference Topology . . . . . . . . . . . 3 3. OAM Building Blocks . . . . . . . . . . . . . . . . . . . . . 5 3.1. O-flag in Segment Routing Header . . . . . . . . . . . . 5 3.1.1. O-flag Processing . . . . . . . . . . . . . . . . . . 6 3.2. OAM Segments . . . . . . . . . . . . . . . . . . . . . . 6 3.3. End.OP: OAM Endpoint with Punt . . . . . . . . . . . . . 6 3.4. End.OTP: OAM Endpoint with Timestamp and Punt . . . . . . 7 - 3.5. SRH TLV . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4. OAM Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.5. SRH TLV . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4. OAM Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Ping . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Classic Ping . . . . . . . . . . . . . . . . . . . . 8 - 4.1.2. Pinging a SID Function . . . . . . . . . . . . . . . 9 + 4.1.2. Pinging a SID Function . . . . . . . . . . . . . . . 10 4.1.3. Error Reporting . . . . . . . . . . . . . . . . . . . 12 - 4.2. Traceroute . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.2. Traceroute . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Classic Traceroute . . . . . . . . . . . . . . . . . 13 - 4.2.2. Traceroute to a SID Function . . . . . . . . . . . . 14 + 4.2.2. Traceroute to a SID Function . . . . . . . . . . . . 15 4.3. Monitoring of SRv6 Paths . . . . . . . . . . . . . . . . 18 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 6.1. ICMPv6 type Numbers RegistrySEC . . . . . . . . . . . . . 19 - 6.2. SRv6 OAM Endpoint Types . . . . . . . . . . . . . . . . . 19 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 - 9.2. Informative References . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 7.1. ICMPv6 type Numbers RegistrySEC . . . . . . . . . . . . . 20 + 7.2. SRv6 OAM Endpoint Types . . . . . . . . . . . . . . . . . 20 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 + 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 + 10.2. Informative References . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction This document defines building blocks for Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane (SRv6). The document also describes some SRv6 OAM mechanisms. 2. Conventions Used in This Document 2.1. Abbreviations @@ -215,86 +216,97 @@ O-flag: OAM flag. When set, it indicates that this packet is an operations and management (OAM) packet. This document defines the usage of the O-flag in the SRH.Flags. The document does not define any other flag in the SRH.Flags and meaning and processing of any other bit in SRH.Flags is outside of the scope of this document. 3.1.1. O-flag Processing - Implementation of the O-flag is OPTIONAL. A node MAY ignore - SRH.Flags.O-flag. It is also possible that a node is capable of - supporting the O-bit but based on a local decision it MAY ignore it - during processing on some local SIDs. If a node does not support the - O-flag, then upon reception it simply ignores it. If a node supports - the O-flag, it can optionally advertise its potential via node - capability advertisement in IGP [I-D.ietf-isis-srv6- extensions] and - BGP-LS [I-D.ietf-idr-bgpls-srv6-ext]. - The SRH.Flags.O-flag implements the "punt a timestamped copy and forward" behavior. + Implementation of the O-flag is OPTIONAL. If a node does not support + the O-flag, then upon reception it simply ignores it. It is also + possible that a node is capable of supporting the O-bit but based on + a local decision it MAY ignore it during processing on some local + SIDs. + + If a node supports the O-flag, it can optionally advertise its + potential via node capability advertisement in IGP [I-D.ietf-isis- + srv6- extensions] and BGP-LS [I-D.ietf-idr-bgpls-srv6-ext]. + When N receives a packet whose IPv6 DA is S and S is a local SID, N executes the following pseudo-code, before the execution of the local - SID S. + SID S. Specifically, for the SID defined in section 4.3.1.1 of [I- + D.ietf-6man-segment-routing-header], the O-flag processing happens + immediately following S01. - 1. IF SRH.Flags.O-flag is one and local configuration permits THEN + S01.1. IF SRH.Flags.O-flag is one and local configuration permits THEN a. Make a copy of the packet. b. Send the copied packet, along with an accurate timestamp - to the OAM process. ;; Ref1 + to the OAM process. ;; Ref1, Ref2, Ref3 Ref1: An implementation SHOULD copy and record the timestamp as soon as possible during packet processing. Timestamp is not carried in the packet forwarded to the next hop. + Ref2: An implementation SHOULD NOT generate ICMP error during + local SID S processing. If local SID S processing requires generation + of an ICMP error, the error is generated by the local OAM process. + Ref3: If multiple SRH are present with O-flag set, an implementation + SHOULD only send one copy of the packet to the OAM process. 3.2. OAM Segments OAM Segment IDs (SIDs) is another component of the SRv6 OAM building Blocks. This document defines a couple of OAM SIDs. 3.3. End.OP: OAM Endpoint with Punt Many scenarios require punting of SRv6 OAM packets at the desired nodes in the network. The "OAM Endpoint with Punt" function (End.OP for short) represents a particular OAM function to implement the punt behavior for an OAM packet. It is described using the pseudocode as follows: When N receives a packet destined to S and S is a local End.OP SID, N does: - 1. Send the packet to the OAM process + 1. Send the packet to the OAM process ;; Ref1 + + Ref1: The local OAM process SHOULD NOT generate ICMP error during + local SID S processing. Please note that in an SRH containing END.OP SID, it is RECOMMENDED to set the SRH.Flags.O-flag = 0. 3.4. End.OTP: OAM Endpoint with Timestamp and Punt Scenarios demanding performance management of an SR policy/ path requires hardware timestamping before hardware punts the packet to the software for OAM processing. The "OAM Endpoint with Timestamp and Punt" function (End.OTP for short) represents an OAM SID function to implement the timestamp and punt behavior for an OAM packet. It is described using the pseudocode as follows: When N receives a packet destined to S and S is a local End.OTP SID, N does: - 1. Timestamp the packet ;; Ref1, Ref2 + 1. Timestamp the packet ;; Ref1 - 2. Send the packet, along with an accurate timestamp, to the OAM process. + 2. Send the packet, along with an accurate timestamp, to the + OAM process ;; Ref2 Ref1: Timestamping SHOULD be done in hardware, as soon as possible during the packet processing. - Ref2: An implementation should not generate further ICMP error during - local SID S processing. If local SID S processing requires generation - of an ICMP error, the error is generated by the local OAM process. + Ref2: The local OAM process SHOULD NOT generate ICMP error during + local SID S processing. Please note that in an SRH containing END.OTP SID, it is RECOMMENDED to set the SRH.Flags.O-flag = 0. 3.5. SRH TLV [I-D.ietf-6man-segment-routing-header] defines TLVs of the Segment Routing Header. SRH TLV plays an important role in carrying OAM and Performance @@ -433,23 +445,23 @@ o Node N3 receives the packet as follows (A:1::, B:4:OTP)(B:4:C52, B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request). Node N3, which is a classic IPv6 node, performs the standard IPv6 processing. Specifically, it forwards the echo request based on DA B:4:OTP in the IPv6 header. o When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request), it processes the END.OTP SID, as described in the pseudocode in - Section 3. The packet gets punted to the ICMPv6 process for - processing. The ICMPv6 process checks if the next SID in SRH (the - target SID B:4:C52) is locally programmed. + Section 3. The packet gets time-stamped and punted to the ICMPv6 + process for processing. The ICMPv6 process checks if the next SID + in SRH (the target SID B:4:C52) is locally programmed. o If the target SID is not locally programmed, N4 responses with the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not locally implemented (TBA)"); otherwise a success is returned. 4.1.2.2. Segment-by-segment ping using O-flag (Proof of Transit) Consider the same example where the user wants to ping a remote SID function B:4:C52, via B:2:C31, from node N1. However, in this ping, the node N1 wants to get a response from each segment node in the SRH @@ -486,25 +498,26 @@ o Node N3, which is a classic IPv6 node, performs the standard IPv6 processing. Specifically, it forwards the echo request based on DA B:4:C52 in the IPv6 header. o When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, B:2:C31; SL=0, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request), it processes the O-flag in SRH, as described in the pseudocode in Section 3. A time-stamped copy of the packet gets punted to the ICMPv6 process for processing. The ICMPv6 process at node N4 - checks if its local SID (B:2:C31) is locally programmed or not and - responds to the ICMPv6 Echo Request. If the target SID is not - locally programmed, N4 responses with the ICMPv6 message (Type: - "SRv6 OAM (TBA)", Code: "SID not locally implemented (TBA)"); - otherwise a success is returned. + checks if its local SID (B:4:C52) is locally programmed or not and + responds to the ICMPv6 Echo Request. + + o If the target SID is not locally programmed, N4 responses with the + ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not locally + implemented (TBA)"); otherwise a success is returned. Support for O-flag is part of node capability advertisement. That enables node N1 to know which segment nodes are capable of responding to the ICMPv6 echo request. Node N1 processes the echo responses and presents data to the user, accordingly. Please note that segment-by-segment ping can be used to address proof of transit use-case. 4.1.3. Error Reporting @@ -694,27 +708,29 @@ Transit"). o When node N3, which is a classic IPv6 node, receives the packet with hop-count > 1, it performs the standard IPv6 processing. Specifically, it forwards the traceroute probe based on DA B:4:OTP in the IPv6 header. o When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, B:4:OTP, B:2:C31 ; SL=1; HC=1, NH=UDP)(Traceroute probe), it processes the END.OTP SID, as described in the pseudocode in - Section 3. The packet gets punted to the traceroute process for - processing. The traceroute process checks if the next SID in SRH - (the target SID B:4:C52) is locally programmed. If the target SID - B:4:C52 is locally programmed, node N4 responses with the ICMPv6 - message (Type: Destination unreachable, Code: Port Unreachable). - If the target SID B:4:C52 is not a local SID, node N4 silently - drops the traceroute probe. + Section 3. The packet gets timestamped and punted to the + traceroute process for processing. The traceroute process checks + if the next SID in SRH (the target SID B:4:C52) is locally + programmed. + + o If the target SID B:4:C52 is locally programmed, node N4 responses + with the ICMPv6 message (Type: Destination unreachable, Code: Port + Unreachable). If the target SID B:4:C52 is not a local SID, node + N4 silently drops the traceroute probe. Figure 4 displays a sample traceroute output for this example. > traceroute srv6 B:4:C52 via segment-list B:2:C31 Tracing the route to SID function B:4:C52 1 2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 2 2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) @@ -765,37 +781,39 @@ performs the standard IPv6 processing. Specifically, it forwards the traceroute probe based on DA B:4:C52 in the IPv6 header. Please note that there is no hop-count expiration at the transit nodes. o When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, B:2:C31; SL=0, HC=62, Flags.O=1; NH=UDP)(Traceroute Probe), it processes the O-flag in SRH, as described in the pseudocode in Section 3. A time-stamped copy of the packet gets punted to the traceroute process for processing. The traceroute process at node - N4 checks if its local SID (B:2:C31) is locally programmed. If - the SID is not locally programmed, it silently drops the packet. - Otherwise, it performs the egress check by looking at the SL value - in SRH. As SL is equal to zero (i.e., N4 is the egress node), - node N4 tries to consume the UDP probe. As UDP probe is set to - access an invalid port, the node N4 responses with the ICMPv6 - message (Type: Destination unreachable, Code: Port Unreachable) + N4 checks if its local SID (B:2:C31) is locally programmed. + + o If the SID is not locally programmed, it silently drops the + packet. Otherwise, it performs the egress check by looking at the + SL value in SRH. As SL is equal to zero (i.e., N4 is the egress + node), node N4 tries to consume the UDP probe. As UDP probe is + set to access an invalid port, the node N4 responses with the + ICMPv6 message (Type: Destination unreachable, Code: Port + Unreachable) Figure 5 displays a sample overlay traceroute output for this example. Please note that the underlay node N3 does not appear in the output. Tracing the route to SID function B:4:C52 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec - SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) - 2 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) + 2 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec + SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=0) Figure 5 A sample output for overlay traceroute to a SID function 4.3. Monitoring of SRv6 Paths In the recent past, network operators are interested in performing network OAM functions in a centralized manner. Various data models like YANG are available to collect data from the network and manage it from a centralized entity. @@ -823,70 +841,77 @@ packet set to B:100:1::. This makes the probe loops back to the centralized monitoring system. In the reference topology in Figure 1, N100 uses an IGP protocol like OSPF or ISIS to get the topology view within the IGP domain. N100 can also use BGP-LS to get the complete view of an inter-domain topology. In other words, the controller leverages the visibility of the topology to monitor the paths between the various endpoints without control plane intervention required at the monitored nodes. -5. Security Considerations +5. Implementation Status + + This section is to be removed prior to publishing as an RFC. + + See [I-D.matsushima-spring-srv6-deployment-status] for updated + deployment and interoperability reports. + +6. Security Considerations This document does not define any new protocol extensions and relies on existing procedures defined for ICMP. This document does not impose any additional security challenges to be considered beyond security considerations described in [RFC4884], [RFC4443], [RFC792], RFCs that updates these RFCs, [I-D.ietf-6man-segment-routing-header] and [I-D.ietf-spring-srv6-network-programming]. -6. IANA Considerations +7. IANA Considerations -6.1. ICMPv6 type Numbers RegistrySEC +7.1. ICMPv6 type Numbers RegistrySEC This document defines one ICMPv6 Message, a type that has been allocated from the "ICMPv6 'type' Numbers" registry of [RFC4443]. Specifically, it requests to add the following to the "ICMPv6 Type Numbers" registry: TBA (suggested value: 162) SRv6 OAM Message. The document also requests the creation of a new IANA registry to the "ICMPv6 'Code' Fields" against the "ICMPv6 Type Numbers TBA - SRv6 OAM Message" with the following codes: Code Name Reference -------------------------------------------------------- 0 No Error This document 1 SID is not locally implemented This document 2 O-flag punt at Transit This document -6.2. SRv6 OAM Endpoint Types +7.2. SRv6 OAM Endpoint Types This I-D requests to IANA to allocate, within the "SRv6 Endpoint Behaviors Registry" sub-registry belonging to the top-level "Segment- routing with IPv6 dataplane (SRv6) Parameters" registry [I-D.ietf- spring- srv6-network-programming], the following allocations: +------------------+-------------------+-----------+ | Value (Suggested | Endpoint Behavior | Reference | | Value) | | | +------------------+-------------------+-----------+ | TBA (40) | End.OP | [This.ID] | | TBA (41) | End.OTP | [This.ID] | +------------------+-------------------+-----------+ -7. Acknowledgements +8. Acknowledgements The authors would like to thank Gaurav Naik for his review comments. -8. Contributors +9. Contributors The following people have contributed to this document: Robert Raszuk Bloomberg LP Email: robert@raszuk.net John Leddy Individual Email: john@leddy.net @@ -904,59 +929,65 @@ Email: naikumar@cisco.com Carlos Pignataro Cisco Systems, Inc. Email: cpignata@cisco.com Rakesh Gandhi Cisco Systems, Inc. Canada Email: rgandhi@cisco.com + Frank Brockners Cisco Systems, Inc. Germany Email: fbrockne@cisco.com Darren Dukes Cisco Systems, Inc. Email: ddukes@cisco.com - Cheng Li Huawei Email: chengli13@huawei.com Faisal Iqbal Individual Email: faisal.ietf@gmail.com -9. References +10. References -9.1. Normative References +10.1. Normative References [I-D.ietf-6man-segment-routing-header] Filsfils, C., Dukes, D., Previdi, S., Leddy, J., - Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment - Routing Header (SRH)", draft-ietf-6man-segment-routing- - header-21 (work in progress), June 2019. + Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header + (SRH)", draft-ietf-6man-segment-routing-header-26 (work in + progress), October 2019. [I-D.ietf-spring-srv6-network-programming] - Filsfils, C., Camarillo, P., Leddy, J., - daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 - Network Programming", draft-ietf-spring-srv6-network- - programming-01 (work in progress), July 2019. + Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., + Matsushima, S., and Z. Li, "SRv6 Network Programming", + draft-ietf-spring-srv6-network-programming-05 (work in + progress), October 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . -9.2. Informative References +10.2. Informative References + + [I-D.matsushima-spring-srv6-deployment-status] + Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 + Implementation and Deployment Status", draft-matsushima- + spring-srv6-deployment-status-02 (work in progress), + October 2019. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, .