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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/