draft-ietf-6man-spring-srv6-oam-04.txt | draft-ietf-6man-spring-srv6-oam-05.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: October 1, 2020 S. Matsushima | Expires: December 14, 2020 S. Matsushima | |||
Softbank | Softbank | |||
D. Voyer | D. Voyer | |||
Bell Canada | Bell Canada | |||
M. Chen | M. Chen | |||
Huawei | Huawei | |||
March 30, 2020 | June 12, 2020 | |||
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-04 | draft-ietf-6man-spring-srv6-oam-05 | |||
Abstract | Abstract | |||
This document defines building blocks for Operations, Administration, | This document describes how the existing IPv6 OAM mechanisms can be | |||
and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane | used in an SRv6 network. The document also introduces enhancements | |||
(SRv6). The document also describes some SRv6 OAM mechanisms. | for controller-based OAM mechanisms for SRv6 networks. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 October 1, 2020. | This Internet-Draft will expire on December 14, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 | |||
4. Terminology and Reference Topology . . . . . . . . . . . . . 3 | 1.3. Terminology and Reference Topology . . . . . . . . . . . 3 | |||
5. OAM Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. OAM Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5.1. O-flag in Segment Routing Header . . . . . . . . . . . . 5 | 2.1. O-flag in Segment Routing Header . . . . . . . . . . . . 5 | |||
5.1.1. O-flag Processing . . . . . . . . . . . . . . . . . . 5 | 2.1.1. O-flag Processing . . . . . . . . . . . . . . . . . . 6 | |||
5.2. OAM Segments . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.3. End.OP: OAM Endpoint with Punt . . . . . . . . . . . . . 6 | 3.1. Ping in SRv6 Networks . . . . . . . . . . . . . . . . . . 7 | |||
6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.1.1. Classic Ping . . . . . . . . . . . . . . . . . . . . 7 | |||
6.1. Ping in SRv6 Networks . . . . . . . . . . . . . . . . . . 7 | 3.1.2. Pinging a SID . . . . . . . . . . . . . . . . . . . . 9 | |||
6.1.1. Classic Ping . . . . . . . . . . . . . . . . . . . . 7 | 3.2. Traceroute . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
6.1.2. Pinging a SID . . . . . . . . . . . . . . . . . . . . 9 | 3.2.1. Classic Traceroute . . . . . . . . . . . . . . . . . 10 | |||
6.2. Traceroute . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.2.2. Traceroute to a SID . . . . . . . . . . . . . . . . . 11 | |||
6.2.1. Classic Traceroute . . . . . . . . . . . . . . . . . 10 | 3.3. A Controller-Based Hybrid OAM Using O-flag . . . . . . . 13 | |||
6.2.2. Traceroute to a SID . . . . . . . . . . . . . . . . . 11 | 3.4. Monitoring of SRv6 Paths . . . . . . . . . . . . . . . . 15 | |||
6.3. A Controller-Based Passive OAM Using O-flag . . . . . . . 13 | 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 | |||
6.4. Monitoring of SRv6 Paths . . . . . . . . . . . . . . . . 15 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 6.1. Segment Routing Header Flags . . . . . . . . . . . . . . 17 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 | |||
9.1. ICMPv6 type Numbers Registry . . . . . . . . . . . . . . 16 | 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
9.2. SRv6 OAM Endpoint Types . . . . . . . . . . . . . . . . . 17 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9.3. Segment Routing Header Flags . . . . . . . . . . . . . . 17 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 | 9.2. Informative References . . . . . . . . . . . . . . . . . 18 | |||
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 | ||||
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 | ||||
12.2. Informative References . . . . . . . . . . . . . . . . . 19 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
1. Introduction | 1. Introduction | |||
This document defines building blocks for Operations, Administration, | As Segment Routing with IPv6 data plane (SRv6) simply adds a new type | |||
and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane | of Routing Extension Header, existing IPv6 OAM mechanisms can be used | |||
(SRv6). | in an SRv6 network. This document describes how the existing IPv6 | |||
mechanisms for ping and trace route can be used in an SRv6 network. | ||||
2. Requirements Language | The document also introduces enhancements for controller-based OAM | |||
mechanism for SRv6 networks. Specifically, the document describes an | ||||
OAM mechanism for performing controllable and predictable flow | ||||
sampling from segment endpoints using, e.g., IP Flow Information | ||||
Export (IPFIX) protocol [RFC7011]. The document also outlines how | ||||
centralized OAM technique in [RFC8403] can be extended for SRv6 to | ||||
perform a path continuity check between any nodes within an SRv6 | ||||
domain from a centralized monitoring system, with minimal or no | ||||
control plane intervene on the nodes. | ||||
1.1. Requirements Language | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119], [RFC8174]. | document are to be interpreted as described in [RFC2119], [RFC8174]. | |||
3. Abbreviations | 1.2. Abbreviations | |||
The following abbreviations are used in this document: | The following abbreviations are used in this document: | |||
SID: Segment ID. | SID: Segment ID. | |||
SL: Segments Left. | SL: Segments Left. | |||
SR: Segment Routing. | SR: Segment Routing. | |||
SRH: Segment Routing Header. | SRH: Segment Routing Header. | |||
SRv6: Segment Routing with IPv6 Data plane. | SRv6: Segment Routing with IPv6 Data plane. | |||
TC: Traffic Class. | TC: Traffic Class. | |||
ICMPv6: ICMPv6 Specification [RFC4443]. | ICMPv6: ICMPv6 Specification [RFC4443]. | |||
4. Terminology and Reference Topology | 1.3. Terminology and Reference Topology | |||
This document uses the terminology defined in [I-D.ietf- spring-srv6- | This document uses the terminology defined in [I-D.ietf- spring-srv6- | |||
network-programming]. The readers are expected to be familiar with | network-programming]. The readers are expected to be familiar with | |||
the same. | the same. | |||
Throughout the document, the following simple topology is used for | Throughout the document, the following simple topology is used for | |||
illustration. | illustration. | |||
+--------------------------| N100 |---------------------------------+ | +--------------------------| N100 |---------------------------------+ | |||
| | | | | | |||
skipping to change at page 4, line 7 ¶ | skipping to change at page 4, line 21 ¶ | |||
| | | | | | | | | | |||
---+-- | ------ | --+--- | ---+-- | ------ | --+--- | |||
|CE 1| +-------| N6 |---------+ |CE 2| | |CE 1| +-------| N6 |---------+ |CE 2| | |||
------ link7 | | link8 ------ | ------ link7 | | link8 ------ | |||
------ | ------ | |||
Figure 1 Reference Topology | Figure 1 Reference Topology | |||
In the reference topology: | In the reference topology: | |||
Node k has a classic IPv6 loopback address A:k::/128. | Node k has a classic IPv6 loopback address 2001:DB8:A:k::/128. | |||
Nodes N1, N2, and N4 are SRv6 capable nodes. | Nodes N1, N2, and N4 are SRv6 capable nodes. | |||
Nodes N3, N5 and N6 are IPv6 nodes that are not SRv6 capable. | Nodes N3, N5 and N6 are IPv6 nodes that are not SRv6 capable. | |||
Such nodes are referred as classic IPv6 nodes. | Such nodes are referred as classic IPv6 nodes. | |||
A SID at node k with locator block B and function F is represented | A SID at node k with locator block 2001:DB8:B::/48 and function F | |||
by B:k:F::. | is represented by 2001:DB8:B:k:F::. | |||
Node N100 is a controller. | Node N100 is a controller. | |||
The IPv6 address of the nth Link between node X and Y at the X | The IPv6 address of the nth Link between node X and Y at the X | |||
side is represented as 2001:DB8:X:Y:Xn::, e.g., the IPv6 address | side is represented as 2001:DB8:X:Y:Xn::, e.g., the IPv6 address | |||
of link6 (the 2nd link) between N3 and N4 at N3 in Figure 1 is | of link6 (the 2nd link) between N3 and N4 at N3 in Figure 1 is | |||
2001:DB8:3:4:32::. Similarly, the IPv6 address of link5 (the 1st | 2001:DB8:3:4:32::. Similarly, the IPv6 address of link5 (the 1st | |||
link between N3 and N4) at node 3 is 2001:DB8:3:4:31::. | link between N3 and N4) at node 3 is 2001:DB8:3:4:31::. | |||
B:k:Cij:: is explicitly allocated as the END.X function at node k | 2001:DB8:B:k:Cij:: is explicitly allocated as the END.X function | |||
towards neighbor node i via jth Link between node i and node k. | at node k towards neighbor node i via jth Link between node i and | |||
e.g., B:2:C31:: represents END.X at N2 towards N3 via link3 (the | node k. e.g., 2001:DB8:B:2:C31:: represents END.X at N2 towards | |||
1st link between N2 and N3). Similarly, B:4:C52:: represents the | N3 via link3 (the 1st link between N2 and N3). Similarly, | |||
END.X at N4 towards N5 via link10. | 2001:DB8:B:4:C52:: represents the END.X at N4 towards N5 via | |||
link10. | ||||
A SID list is represented as <S1, S2, S3> where S1 is the first | A SID list is represented as <S1, S2, S3> where S1 is the first | |||
SID to visit, S2 is the second SID to visit and S3 is the last SID | SID to visit, S2 is the second SID to visit and S3 is the last SID | |||
to visit along the SR path. | to visit along the SR path. | |||
(SA,DA) (S3, S2, S1; SL)(payload) represents an IPv6 packet with: | (SA,DA) (S3, S2, S1; SL)(payload) represents an IPv6 packet with: | |||
* IPv6 header with source address SA, destination addresses DA | * IPv6 header with source address SA, destination addresses DA | |||
and SRH as next-header | and SRH as next-header | |||
skipping to change at page 5, line 9 ¶ | skipping to change at page 5, line 26 ¶ | |||
use-case, it is simpler to use the <S1, S2, S3> notation. When | use-case, it is simpler to use the <S1, S2, S3> notation. When | |||
referring to an illustration of the detailed packet behavior, | referring to an illustration of the detailed packet behavior, | |||
the (S3, S2, S1; SL) notation is more convenient. | the (S3, S2, S1; SL) notation is more convenient. | |||
* (payload) represents the the payload of the packet. | * (payload) represents the the payload of the packet. | |||
SRH[SL] represents the SID pointed by the SL field in the first | SRH[SL] represents the SID pointed by the SL field in the first | |||
SRH. In our example SID list (S3, S2, S1; SL), SRH[2] represents | SRH. In our example SID list (S3, S2, S1; SL), SRH[2] represents | |||
S1, SRH[1] represents S2 and SRH[0] represents S3. | S1, SRH[1] represents S2 and SRH[0] represents S3. | |||
5. OAM Mechanisms | 2. OAM Mechanisms | |||
As Segment Routing with IPv6 data plane (SRv6) simply adds a new type | ||||
of Routing Extension Header, existing IPv6 OAM mechanisms can be used | ||||
in an SRv6 network. | ||||
This section defines OAM enhancement for the SRv6 networks. | This section defines OAM enhancement for the SRv6 networks. | |||
Specifically, it defines the O-flag for implementing a controller | ||||
based passive OAM mechanism and an OAM SID to more closely examine | ||||
the contents of packet at a segment endpoint for active OAM. | ||||
5.1. O-flag in Segment Routing Header | 2.1. O-flag in Segment Routing Header | |||
[I-D.ietf-6man-segment-routing-header] describes the Segment Routing | [RFC8754] describes the Segment Routing Header (SRH) and how SR | |||
Header (SRH) and how SR capable nodes use it. The SRH contains an | capable nodes use it. The SRH contains an 8-bit "Flags" field. This | |||
8-bit "Flags" field. This document defines the following bit in the | document defines the following bit in the SRH.Flags to carry the | |||
SRH.Flags to carry the O-flag: | O-flag: | |||
0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| |O| | | | |O| | | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
Where: | Where: | |||
O-flag: OAM flag. When set, it indicates that this packet is an | O-flag: OAM flag. | |||
Operation Administration and Maintenance (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 | 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. | |||
5.1.1. O-flag Processing | 2.1.1. O-flag Processing | |||
The SRH.Flags.O-flag implements the "punt a timestamped copy of the | The O-flag in SRH is used as a marking-bit in the user packets to | |||
packet" behavior. This enables an SRv6 Endpoint node to send a | trigger the telemetry data collection and export at the segment | |||
timestamped copy of the packets marked with o-flag to a local OAM | endpoints. | |||
process. To prevent multiple evaluations of the datagram, the OAM | ||||
process MUST NOT process the packet or respond to any upper-layer | ||||
header (like ICMP, UDP, etc.) payload. However, the OAM process MAY | ||||
export the time-stamped copy of the packet to a controller using | ||||
e.g., IPFIX [RFC7011]. If data from the last node in the segment- | ||||
list (Egress node) is desired, the ingress uses an Ultimate Segment | ||||
Pop (USP) SID advertised by the Egress node. To avoid hitting any | ||||
performance impact, the processing node SHOULD rate-limit the number | ||||
of packets punted to the OAM process. Specification of the OAM | ||||
process or the external controller operations are beyond the scope of | ||||
this document. Section 6 illustrates use of the SRH.Flags.O-flag for | ||||
implementing a controller-based passive OAM mechanism. | ||||
Implementation of the O-flag is OPTIONAL. If a node does not support | Without the loss of generality, this document assumes IP Flow | |||
the O-flag, then upon reception it simply ignores it. | Information Export (IPFIX) protocol [RFC7011] is used for exporting | |||
the traffic flow information from the network devices to a controller | ||||
for monitoring and analytics. The requested information elements are | ||||
configured by the management plane through data set templates (e.g., | ||||
as in IPFIX [RFC7012]). | ||||
If a node supports the O-flag, it can optionally advertise its | Implementation of the O-flag is OPTIONAL. If a node does not support | |||
potential via node capability advertisement in IGP [I-D.ietf-isis- | the O-flag, then upon reception it simply ignores it. If a node | |||
srv6- extensions] and BGP-LS [I-D.ietf-idr-bgpls-srv6-ext]. | supports the O-flag, it can optionally advertise its potential via | |||
control plan protocol(s). | ||||
When N receives a packet whose IPv6 DA is S and S is a local SID, the | When N receives a packet whose IPv6 DA is S and S is a local SID, the | |||
line S01 of the pseudo-code associated with the SID S, as defined in | line S01 of the pseudo-code associated with the SID S, as defined in | |||
section 4.3.1.1 of [I-D.ietf-6man-segment-routing-header], is | section 4.3.1.1 of [RFC8754], is modified as follows for the O-flag | |||
modified as follows for the O-flag processing. | processing. | |||
S01.1. IF SRH.Flags.O-flag is set and local configuration permits | S01.1. IF SRH.Flags.O-flag is set and local configuration permits | |||
O-flag processing THEN | O-flag processing THEN | |||
a. Make a copy of the packet. | a. Make a copy of the packet. | |||
b. Send the copied packet, along with a timestamp | b. Send the copied packet, along with a timestamp | |||
to the OAM process. ;; Ref1 | to the OAM process for telemetry data collection | |||
and export. ;; Ref1 | ||||
Ref1: An implementation SHOULD copy and record the timestamp as | Ref1: An implementation SHOULD copy and record the timestamp as | |||
soon as possible during packet processing. Timestamp is not | soon as possible during packet processing. Timestamp or any other | |||
metadata is not | ||||
carried in the packet forwarded to the next hop. | carried in the packet forwarded to the next hop. | |||
Please note that the O-flag processing happens before execution of | Please note that the O-flag processing happens before execution of | |||
regular processing of the local SID S. | regular processing of the local SID S. | |||
5.2. OAM Segments | Based on the requested information elements configured by the | |||
management plane through data set templates [RFC7012], the OAM | ||||
The presence of an OAM SID in the Destination address of the IPv6 | process exports the requested information elements. The information | |||
header instructs the segment endpoint implementing the OAM SID that | elements include parts of the packet header and/or parts of the | |||
the content of the packet is of interest. | packet payload for flow identification. The OAM process uses | |||
information elements defined in IPFIX [RFC7011] and PSAMP [RFC5476] | ||||
The document defines OAM Endpoint with Punt action. Additional OAM | for exporting the requested sections of the mirrored packets. | |||
SIDs may be defined in future documents. | ||||
5.3. End.OP: OAM Endpoint with Punt | ||||
When N receives a packet destined to S and S is a local End.OP SID, N | ||||
does: | ||||
S01. Send the packet to the OAM process | If the telemetry data from the last node in the segment-list (egress | |||
node) is desired, the ingress uses an Ultimate Segment Pop (USP) SID | ||||
advertised by the egress node. | ||||
The local OAM process further processes the packet, this MAY involve | The processing node SHOULD rate-limit the number of packets punted to | |||
processing protocol layers above IPv6. For example, ping and | the OAM process to avoid hitting any performance impact. | |||
traceroute will require ICMP or UDP protocol processing. Once the | ||||
packet leaves the IPv6 layer the processing is considered host | ||||
processing and the upper layer protocols MUST be processed as such. | ||||
As END.OP SID terminates the forwarding of the probe packets for the | The OAM process MUST NOT process the copy of the packet or respond to | |||
upper layer processing, it is used for the active OAM mechanisms. | any upper-layer header (like ICMP, UDP, etc.) payload to prevent | |||
For example, the END.OP SID SID is not designed for implementing In- | multiple evaluations of the datagram. | |||
situ OAM mechanisms defined in [I.D-draft-ietf-ippm-ioam-data]. | ||||
6. Illustrations | Specification of the OAM process or the external controller | |||
operations are beyond the scope of this document. section 3 | ||||
illustrates use of the SRH.Flags.O-flag for implementing a | ||||
controller-based hybrid OAM mechanism, where the "hybrid" | ||||
classification is based on RFC7799 [RFC7799]. The illustration is | ||||
different than the In-situ OAM defined in [I.D-draft-ietf-ippm-ioam- | ||||
data]. This is because In-situ OAM records operational and telemetry | ||||
information in the packet as the packet traverses a path between two | ||||
points in the network [I.D-draft-ietf- ippm-ioam-data]. The | ||||
controller-based OAM mechanism using O-flag illustration in section 3 | ||||
does not require the recording of OAM data in the packet. | ||||
This section illustrates the use of existing IPv6 OAM mechanisms in | 3. Illustrations | |||
the SRv6 network. It also illustrates the use of the END.OP SID and | ||||
O-flag at segment endpoints. | ||||
The document does not propose any changes to the standard ICMPv6 | This section shows how some of the existing IPv6 OAM mechanisms can | |||
[RFC4443], [RFC4884] or standard ICMPv4 [RFC792] or [RFC2151]. | be used in an SRv6 network. It also illustrates an OAM mechanism for | |||
performing controllable and predictable flow sampling from segment | ||||
endpoints. How centralized OAM technique in [RFC8403] can be | ||||
extended for SRv6 is also described in this Section. | ||||
6.1. Ping in SRv6 Networks | 3.1. Ping in SRv6 Networks | |||
The following subsections outline some use cases of the ICMP ping in | The following subsections outline some use cases of the ICMP ping in | |||
the SRv6 networks. | the SRv6 networks. | |||
6.1.1. Classic Ping | 3.1.1. Classic Ping | |||
The existing mechanism to query liveliness of a remote IP address, | The existing mechanism to query liveliness of a remote IP address, | |||
along the shortest path, continues to work without any modification. | along the shortest path, continues to work without any modification. | |||
The initiator may be an SRv6 node or a classic IPv6 node. Similarly, | The initiator may be an SRv6 node or a classic IPv6 node. Similarly, | |||
the egress or transit may be an SRv6 capable node or a classic IPv6 | the egress or transit may be an SRv6 capable node or a classic IPv6 | |||
node. | node. | |||
If an SRv6 capable ingress node wants to ping an IPv6 prefix via an | If an SRv6 capable ingress node wants to ping an IPv6 address via an | |||
arbitrary segment list <S1, S2, S3>, it needs to initiate ICMPv6 ping | arbitrary segment list <S1, S2, S3>, it needs to initiate ICMPv6 ping | |||
with an SR header containing the SID list <S1, S2, S3>. This is | with an SR header containing the SID list <S1, S2, S3>. This is | |||
illustrated using the topology in Figure 1. Assume all the links | illustrated using the topology in Figure 1. Assume all the links | |||
have IGP metric 10 except both links between node2 and node3, which | have IGP metric 10 except both links between node2 and node3, which | |||
have IGP metric set to 100. User issues a ping from node N1 to a | have IGP metric set to 100. User issues a ping from node N1 to a | |||
loopback of node 5, via segment list <B:2:C31, B:4:C52>. | loopback of node 5, via segment list <2001:DB8:B:2:C31::, | |||
2001:DB8:B:4:C52::>. | ||||
Figure 2 contains sample output for a ping request initiated at node | Figure 2 contains sample output for a ping request initiated at node | |||
N1 to the loopback address of node N5 via a segment list <B:2:C31, | N1 to the loopback address of node N5 via a segment list | |||
B:4:C52>. | <2001:DB8:B:2:C31::, 2001:DB8:B:4:C52::>. | |||
> ping 2001:DB8:A:5:: via segment-list 2001:DB8:B:2:C31::, | ||||
2001:DB8:B:4:C52:: | ||||
> ping A:5:: via segment-list B:2:C31, B:4:C52 | ||||
Sending 5, 100-byte ICMP Echos to B5::, timeout is 2 seconds: | Sending 5, 100-byte ICMP Echos to B5::, timeout is 2 seconds: | |||
!!!!! | !!!!! | |||
Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 | Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 | |||
/0.749/0.931 ms | /0.749/0.931 ms | |||
Figure 2 A sample ping output at an SRv6 capable node | Figure 2 A sample ping output at an SRv6 capable node | |||
All transit nodes process the echo request message like any other | All transit nodes process the echo request message like any other | |||
data packet carrying SR header and hence do not require any change. | data packet carrying SR header and hence do not require any change. | |||
Similarly, the egress node (IPv6 classic or SRv6 capable) does not | Similarly, the egress node (IPv6 classic or SRv6 capable) does not | |||
require any change to process the ICMPv6 echo request. Furthermore, | require any change to process the ICMPv6 echo request. For example, | |||
there is no difference in processing of the ICMPv6 echo request at an | in the ping example of Figure 2: | |||
IPv6 classic node or an SRv6 capable node. For example, in the ping | ||||
example of Figure 2: | ||||
o Node N1 initiates an ICMPv6 ping packet with SRH as follows | o Node N1 initiates an ICMPv6 ping packet with SRH as follows | |||
(A:1::, B:2:C31)(A:5::, B:4:C52, B:2:C31, SL=2, NH = | (2001:DB8:A:1::, 2001:DB8:B:2:C31::) (2001:DB8:A:5::, | |||
ICMPv6)(ICMPv6 Echo Request). If B:4:C52 is a PSP SID, the OAM | 2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::, SL=2, NH = ICMPv6)(ICMPv6 | |||
probes encodes the PSP SID in the packet (just mimicking data | Echo Request). If 2001:DB8:B:4:C52:: is a PSP SID, the OAM probes | |||
packets). No special consideration is needed to handle PSP SIDs. | encodes the PSP SID in the packet (just mimicking data packets). | |||
No special consideration is needed to handle PSP SIDs. | ||||
o Node N2, which is an SRv6 capable node, performs the standard SRH | o Node N2, which is an SRv6 capable node, performs the standard SRH | |||
processing. Specifically, it executes the END.X function | processing. Specifically, it executes the END.X function | |||
(B:2:C31) and forwards the packet on link3 to N3. | (2001:DB8:B:2:C31::) and forwards the packet on link3 to N3. | |||
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 | |||
the DA B:4:C52 in the IPv6 header. | the DA 2001:DB8:B:4:C52:: in the IPv6 header. | |||
o Node N4, which is an SRv6 capable node, performs the standard SRH | o Node N4, which is an SRv6 capable node, performs the standard SRH | |||
processing. Specifically, it observes the END.X function | processing. Specifically, it observes the END.X function | |||
(B:4:C52) and forwards the packet on link10 towards N5. If | (2001:DB8:B:4:C52::) and forwards the packet on link10 towards N5. | |||
B:4:C52 is a PSP SID, The penultimate node (Node N4) does not, | If 2001:DB8:B:4:C52:: is a PSP SID, The penultimate node (Node N4) | |||
should no and cannot differentiate between the data packets and | does not, should not and cannot differentiate between the data | |||
OAM probes. Specifically, if B:4:C52 is a PSP SID, node N4 | packets and OAM probes. Specifically, if 2001:DB8:B:4:C52:: is a | |||
executes the SID like any other data packet with DA = B:4:C52 and | PSP SID, node N4 executes the SID like any other data packet with | |||
removes the SRH. | DA = 2001:DB8:B:4:C52:: and removes the SRH. | |||
o The echo request packet at N5 arrives as an IPv6 packet with or | o The echo request packet at N5 arrives as an IPv6 packet with or | |||
without an SRH. If N5 receives the packet with SRH, it skips SRH | without an SRH. If N5 receives the packet with SRH, it skips SRH | |||
processing. In either case, Node N5 performs the standard IPv6/ | processing (SL=0). In either case, Node N5 performs the standard | |||
ICMPv6 processing on the echo request. | IPv6/ ICMPv6 processing on the echo request. | |||
6.1.2. Pinging a SID | 3.1.2. Pinging a SID | |||
The following illustration uses END.OP SID for pinging a SID. | The classic ping described in the previous section applies equally to | |||
ping a remote SID function, as explained using an example in the | ||||
following. | ||||
Consider the example where the user wants to ping a remote SID | Consider the example where the user wants to ping a remote SID | |||
function B:4:C52, via B:2:C31, from node N1. The ICMPv6 echo request | function 2001:DB8:B:4::, via 2001:DB8:B:2:C31::, from node N1. The | |||
is processed at the individual nodes along the path as follows: | ICMPv6 echo request is processed at the individual nodes along the | |||
path as follows: | ||||
o To force a punt of the ICMPv6 echo request at the node N4, node N1 | o Node N1 initiates an ICMPv6 ping packet with SRH as follows | |||
inserts the END.OP SID just before the target SID B:4:C52 in the | (2001:DB8:A:1::, 2001:DB8:B:2:C31::) (2001:DB8:B:4::, | |||
SRH. Specifically, Node N1 initiates an ICMPv6 ping packet with | 2001:DB8:B:2:C31::; SL=1; NH=ICMPv6)(ICMPv6 Echo Request). If | |||
SRH as follows (A:1::, B:2:C31)(B:4:C52, B:4:OP, B:2:C31; SL=2; | 2001:DB8:B:2:C31:: is a PSP SID, the OAM probes encodes the PSP | |||
NH=ICMPv6)(ICMPv6 Echo Request). | SID in the packet (just mimicking data packets). No special | |||
consideration is needed to handle PSP SIDs. | ||||
o Node N2, which is an SRv6 capable node, performs the standard SRH | o Node N2, which is an SRv6 capable node, performs the standard SRH | |||
processing. Specifically, it executes the END.X function | processing. Specifically, it executes the END.X function | |||
(B:2:C31) on the echo request packet. | (2001:DB8:B:2:C31::) on the echo request packet. If | |||
2001:DB8:B:2:C31:: is a PSP SID, node N4 executes the SID like any | ||||
other data packet with DA = 2001:DB8:B:2:C31:: and removes the | ||||
SRH. | ||||
o Node N3 receives the packet as follows (A:1::, B:4:OP)(B:4:C52, | o Node N3, which is a classic IPv6 node, performs the standard IPv6 | |||
B:4:OP, 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 | processing. Specifically, it forwards the echo request based on | |||
DA B:4:OP in the IPv6 header. | DA = 2001:DB8:B:4:: in the IPv6 header. | |||
o When node N4 receives the packet (A:1::, B:4:OP)(B:4:C52, B:4:OP, | o When node N4 receives the packet, it processes the 2001:DB8:B:4:: | |||
B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request), it processes the | SID, as described in the pseudocode in [I-D.ietf-spring-srv6- | |||
END.OP SID, as described in the pseudocode in Section 3. The | network-programming]. | |||
packet gets punted to the OAM process for processing. The OAM | ||||
process checks if the next SID in SRH (the target SID B:4:C52) is | ||||
locally programmed. | ||||
o If the next SID is not locally programmed, the OAM process returns | o If the 2001:DB8:B:4:: SID is not locally programmed, the packet is | |||
an ICMPv6 error message type 4 (parameter problem) code 0 | discarded | |||
(erroneous header field encountered) with pointer set to the | ||||
target SID B:4:C52 and the packet is discarded. | ||||
o If the next SID is locally programmed, the node processes the | o If the target SID (2001:DB8:B:4::) is locally programmed, the node | |||
upper layer header, as a host. As part of the upper layer header | processes the upper layer header. As part of the upper layer | |||
(ICMPv6) processing node N4 sends the ICMPv6 Echo Reply message | header processing node N4 respond to the ICMPv6 echo request | |||
[RFC4443]. | message. | |||
6.2. Traceroute | 3.2. Traceroute | |||
There is no hardware or software change required for traceroute | There is no hardware or software change required for traceroute | |||
operation at the classic IPv6 nodes in an SRv6 network. That | operation at the classic IPv6 nodes in an SRv6 network. That | |||
includes the classic IPv6 node with ingress, egress or transit roles. | includes the classic IPv6 node with ingress, egress or transit roles. | |||
Furthermore, no protocol changes are required to the standard | Furthermore, no protocol changes are required to the standard | |||
traceroute operations. In other words, existing traceroute | traceroute operations. In other words, existing traceroute | |||
mechanisms work seamlessly in the SRv6 networks. | mechanisms work seamlessly in the SRv6 networks. | |||
The following subsections outline some use cases of the traceroute in | The following subsections outline some use cases of the traceroute in | |||
the SRv6 networks. | the SRv6 networks. | |||
6.2.1. Classic Traceroute | 3.2.1. Classic Traceroute | |||
The existing mechanism to traceroute a remote IP prefix, along the | The existing mechanism to traceroute a remote IP address, along the | |||
shortest path, continues to work without any modification. The | shortest path, continues to work without any modification. The | |||
initiator may be an SRv6 node or a classic IPv6 node. Similarly, the | initiator may be an SRv6 node or a classic IPv6 node. Similarly, the | |||
egress or transit may be an SRv6 node or a classic IPv6 node. | egress or transit may be an SRv6 node or a classic IPv6 node. | |||
If an SRv6 capable ingress node wants to traceroute to IPv6 prefix | If an SRv6 capable ingress node wants to traceroute to IPv6 address | |||
via an arbitrary segment list <S1, S2, S3>, it needs to initiate | via an arbitrary segment list <S1, S2, S3>, it needs to initiate | |||
traceroute probe with an SR header containing the SID list <S1, S2, | traceroute probe with an SR header containing the SID list <S1, S2, | |||
S3>. That is illustrated using the topology in Figure 1. Assume all | S3>. That is illustrated using the topology in Figure 1. Assume all | |||
the links have IGP metric 10 except both links between node2 and | the links have IGP metric 10 except both links between node2 and | |||
node3, which have IGP metric set to 100. User issues a traceroute | node3, which have IGP metric set to 100. User issues a traceroute | |||
from node N1 to a loopback of node 5, via segment list <B:2:C31, | from node N1 to a loopback of node 5, via segment list | |||
B:4:C52>. Figure 3 contains sample output for the traceroute | <2001:DB8:B:2:C31::, 2001:DB8:B:4:C52::>. Figure 3 contains sample | |||
request. | output for the traceroute request. | |||
> traceroute A:5:: via segment-list B:2:C31, B:4:C52 | > traceroute 2001:DB8:A:5:: via segment-list 2001:DB8:B:2:C31::, | |||
Tracing the route to A:5:: | 2001:DB8:B:4:C52:: | |||
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) | ||||
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) | ||||
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) | ||||
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 | ||||
Please note that if B:4:C52 is a PSP SID, the traceroute probe | Tracing the route to 2001:DB8:A:5:: | |||
encodes the PSP SID in the packet (just mimicking data packets). | 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec | |||
Likewise, if B:4:C52 is a PSP SID, node N4 executes the SID like any | DA: 2001:DB8:B:2:C31::, | |||
other data packet with DA = B:4:C52. I.e., no special consideration | SRH:(2001:DB8:A:5::, 2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::, SL=2) | |||
is needed to handle PSP SIDs. | 2 2001:DB8:2:3:31:: 0.721 msec 0.810 msec 0.795 msec | |||
DA: 2001:DB8:B:4:C52::, | ||||
SRH:(2001:DB8:A:5::, 2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::, SL=1) | ||||
3 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec | ||||
DA: 2001:DB8:B:4:C52::, | ||||
SRH:(2001:DB8:A:5::, 2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::, SL=1) | ||||
4 2001:DB8:4:5::52:: 0.879 msec 0.916 msec 1.024 msec | ||||
DA: 2001:DB8:A:5:: | ||||
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 11, line 28 ¶ | skipping to change at page 11, line 35 ¶ | |||
response. ICMP extensions defined in [RFC5837] can be used to also | response. ICMP extensions defined in [RFC5837] can be used to also | |||
display information about the IP interface through which the datagram | display information about the IP interface through which the datagram | |||
would have been forwarded had it been forwardable, and the IP next | would have been forwarded had it been forwardable, and the IP next | |||
hop to which the datagram would have been forwarded, the IP interface | hop to which the datagram would have been forwarded, the IP interface | |||
upon which a datagram arrived, the sub-IP component of an IP | upon which a datagram arrived, the sub-IP component of an IP | |||
interface upon which a datagram arrived. | interface upon which a datagram arrived. | |||
The information about the IP address of the incoming interface on | The information about the IP address of the incoming interface on | |||
which the traceroute probe was received by the reporting node is very | which the traceroute probe was received by the reporting node is very | |||
useful. This information can also be used to verify if SID functions | useful. This information can also be used to verify if SID functions | |||
B:2:C31 and B:4:C52 are executed correctly by N2 and N4, | 2001:DB8:B:2:C31:: and 2001:DB8:B:4:C52:: are executed correctly by | |||
respectively. Specifically, the information displayed for hop2 | N2 and N4, respectively. Specifically, the information displayed for | |||
contains the incoming interface address 2001:DB8:2:3:31:: at N3. | hop2 contains the incoming interface address 2001:DB8:2:3:31:: at N3. | |||
This matches with the expected interface bound to END.X function | This matches with the expected interface bound to END.X function | |||
B:2:C31 (link3). Similarly, the information displayed for hop5 | 2001:DB8:B:2:C31:: (link3). Similarly, the information displayed for | |||
contains the incoming interface address 2001:DB8:4:5:52:: at N5. | hop5 contains the incoming interface address 2001:DB8:4:5::52:: at | |||
This matches with the expected interface bound to the END.X function | N5. This matches with the expected interface bound to the END.X | |||
B:4:C52 (link10). | function 2001:DB8:B:4:C52:: (link10). | |||
6.2.2. Traceroute to a SID | 3.2.2. Traceroute to a SID | |||
The following illustration uses END.OP SID for trace-routing a SID. | The classic traceroute described in the previous section applies | |||
The illustration assumes traceroute probe is UDP encoded but the | equally to traceroute a remote SID function, as explained using an | |||
procedure is equally applicable to other encoding types. | example in the following. | |||
Consider the example where the user wants to traceroute to a remote | Please note that traceroute to a SID function is exemplified using | |||
SID function B:4:C52, via B:2:C31, from node N1. The traceroute | UDP probes. However, the procedure is equally applicable to other | |||
probe is processed at the individual nodes along the path as follows: | implementations of traceroute mechanism. | |||
o To force a punt of the traceroute probe at the node N4, node N1 | Consider the example where the user wants to traceroute a remote SID | |||
inserts the END.OP SID just before the target SID B:4:C52 in the | function 2001:DB8:B:4::, via 2001:DB8:B:2:C31::, from node N1. The | |||
SRH. Specifically, Node N1 initiates a traceroute probe packet | traceroute probe is processed at the individual nodes along the path | |||
with a monotonically increasing value of hop-count and SRH as | as follows: | |||
follows (A:1::, B:2:C31)(B:4:C52, B:4:OP, B:2:C31; SL=2; | ||||
NH=UDP)(Traceroute probe). | o Node N1 initiates a traceroute probe packet with a monotonically | |||
increasing value of hop count and SRH as follows (2001:DB8:A:1::, | ||||
2001:DB8:B:2:C31::) (2001:DB8:B:4::, 2001:DB8:B:2:C31::; SL=1; | ||||
NH=UDP)(Traceroute probe). If 2001:DB8:B:2:C31:: is a PSP SID, | ||||
the OAM probes encodes the PSP SID in the packet (just mimicking | ||||
data packets). No special consideration is needed to handle PSP | ||||
SIDs. | ||||
o When node N2 receives the packet with hop-count = 1, it processes | o When node N2 receives the packet with hop-count = 1, it processes | |||
the hop-limit expiry. Specifically, the node N2 responses with | the hop count expiry. Specifically, the node N2 responses with | |||
the ICMPv6 message (Type: "Time Exceeded", Code: "Time to Live | the ICMPv6 message (Type: "Time Exceeded", Code: "Time to Live | |||
exceeded in Transit"). | exceeded in Transit"). | |||
o When Node N2 receives the packet with hop-count > 1, it performs | o When Node N2 receives the packet with hop-count > 1, it performs | |||
the standard SRv6 SID and SRH processing. Specifically, it | the standard SRH processing. Specifically, it executes the END.X | |||
executes the END.X function (B:2:C31) on the traceroute probe. | function (2001:DB8:B:2:C31::) on the traceroute probe. If | |||
2001:DB8:B:2:C31:: is a PSP SID, node N4 executes the SID like any | ||||
other data packet with DA = 2001:DB8:B:2:C31:: and removes the | ||||
SRH. | ||||
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 | |||
(A:1::, B:4:OP)(B:4:C52, B:4:OP, B:2:C31 ; HC=1, SL=1; | with hop-count = 1, it processes the hop count expiry. | |||
NH=UDP)(Traceroute probe) with hop-count = 1, it processes the | Specifically, the node N3 responses with the ICMPv6 message (Type: | |||
hop-limit expiry. Specifically, the node N3 responses with the | "Time Exceeded", Code: "Time to Live exceeded in Transit"). | |||
ICMPv6 message (Type: "Time Exceeded", Code: "Time to Live | ||||
exceeded in 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:OP | Specifically, it forwards the traceroute probe based on DA | |||
in the IPv6 header. | 2001:DB8:B:4:: in the IPv6 header. | |||
o When node N4 receives the packet (A:1::, B:4:OP)(B:4:C52, B:4:OP, | o When node N4 receives the packet with DA set to the local SID | |||
B:2:C31 ; SL=1; HC=1, NH=UDP)(Traceroute probe), it processes the | 2001:DB8:B:4::, it processes the END SID, as described in the | |||
END.OP SID, as described in the pseudocode in Section 3, before | pseudocode in [I-D.ietf-spring-srv6-network-programming]. | |||
hop-limit processing. The packet gets punted to the OAM process | ||||
for processing. The OAM process checks if the next SID in SRH | ||||
(the target SID B:4:C52) is locally programmed. | ||||
o If the next SID is not locally programmed, the OAM process returns | o If the 2001:DB8:B:4:: SID is not locally programmed, the packet is | |||
an ICMPv6 error message type 4 (parameter problem) code 0 | discarded. | |||
(erroneous header field encountered) with pointer set to the | ||||
target SID B:4:C52 and the packet is discarded. | ||||
o If the next SID is locally programmed, the node processes the | o If the target SID (2001:DB8:B:4::) is locally programmed, the node | |||
upper layer header. As part of the upper layer header processing | processes the upper layer header. As part of the upper layer | |||
node N4 responses with the ICMPv6 message (Type: Destination | header processing node N4 responses with the ICMPv6 message (Type: | |||
unreachable, Code: Port Unreachable). | Destination unreachable, Code: Port Unreachable). | |||
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 2001:DB8:B:4:C52:: via segment-list 2001:DB8: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:OP, 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:OP, B:2:C31; SL=1) | ||||
3 2001:DB8:3:4:41:: 0.921 msec 0.816 msec 0.759 msec | ||||
SRH: (B:4:C52, B:4:OP, B:2:C31; SL=1) | ||||
Figure 4 A sample output for traceroute to a SID | ||||
6.3. A Controller-Based Passive OAM Using O-flag | Tracing the route to SID function 2001:DB8:B:4:C52:: | |||
1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec | ||||
DA: 2001:DB8:B:2:C31::, | ||||
SRH:(2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::; SL=1) | ||||
2 2001:DB8:2:3:31:: 0.721 msec 0.810 msec 0.795 msec | ||||
DA: 2001:DB8:B:4:C52::, | ||||
SRH:(2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::; SL=0) | ||||
3 2001:DB8:3:4:41:: 0.921 msec 0.816 msec 0.759 msec | ||||
DA: 2001:DB8:B:4:C52::, | ||||
SRH:(2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::; SL=0) | ||||
This section illustrates a controller-based passive OAM mechanism | Figure 4 A sample output for hop-by-hop traceroute to a SID | |||
using the SRH.Flags.O-flag. | ||||
The mechanism is different than the passive In-situ OAM defined in | 3.3. A Controller-Based Hybrid OAM Using O-flag | |||
[I.D-draft-ietf-ippm-ioam-data]. This is because In-situ OAM records | ||||
operational and telemetry information in the packet as the packet | ||||
traverses a path between two points in the network [I.D-draft-ietf- | ||||
ippm-ioam-data]. The controller-based OAM mechanism using O-flag | ||||
described in this section does not require the recording of OAM data | ||||
in the packet. Instead, a copy of the packet with the SRH.O-flag set | ||||
is sent to a local OAM process. The OAM process adds the required | ||||
metadata to the packet and sends the packet to a controller for | ||||
further processing. Specification of how the OAM process computes | ||||
the metadata and how the controller correlates and processes the copy | ||||
of the packets from different segment endpoints is beyond the scope | ||||
of this document. | ||||
Consider the example where the user wants to monitor sampled IPv4 VPN | Consider the example where the user wants to monitor sampled IPv4 VPN | |||
100 traffic going from CE1 to CE2 via a low latency SR policy P | 100 traffic going from CE1 to CE2 via a low latency SR policy P | |||
installed at Node N1. To exercise a low latency path, the SR Policy | installed at Node N1. To exercise a low latency path, the SR Policy | |||
P forces the packet via segments B:2:C31 and B:4:C52. The VPN SID at | P forces the packet via segments 2001:DB8:B:2:C31:: and | |||
N7 associated with VPN100 is B:7:DT100. B:7:DT100 is a USP SID. N1, | 2001:DB8:B:4:C52::. The VPN SID at N7 associated with VPN100 is | |||
N4, and N7 are capable of processing SRH.Flags.O-flag but N2 is not | 2001:DB8:B:7:DT100::. 2001:DB8:B:7:DT100:: is a USP SID. N1, N4, | |||
and N7 are capable of processing SRH.Flags.O-flag but N2 is not | ||||
capable of processing SRH.Flags.O-flag. N100 is the centralized | capable of processing SRH.Flags.O-flag. N100 is the centralized | |||
controller capable of processing and correlating the copy of the | controller capable of processing and correlating the copy of the | |||
packets sent from nodes N1, N4, and N7. N100 is aware of | packets sent from nodes N1, N4, and N7. N100 is aware of | |||
SRH.Flags.O-flag processing capabilities. Controller N100 with the | SRH.Flags.O-flag processing capabilities. Controller N100 with the | |||
help from nodes N1, N4, N7 and implements a passive OAM mechanism | help from nodes N1, N4, N7 and implements a hybrid OAM mechanism | |||
using the SRH.Flags.O-flag as follows: | using the SRH.Flags.O-flag as follows: | |||
o A packet P1:(IPv4 header)(payload) is sent from CE1 to Node N1. | o A packet P1:(IPv4 header)(payload) is sent from CE1 to Node N1. | |||
o Node N1 steers the packet P1 through the Policy P. Based on a | o Node N1 steers the packet P1 through the Policy P. Based on a | |||
local configuration, Node N1 also implements logic to sample | local configuration, Node N1 also implements logic to sample | |||
traffic steered through policy P for passive OAM purposes. | traffic steered through policy P for hybrid OAM purposes. | |||
Specification for the sampling logic is beyond the scope of this | Specification for the sampling logic is beyond the scope of this | |||
document. Consider the case where packet P1 is classified as a | document. Consider the case where packet P1 is classified as a | |||
packet to be monitored via the passive OAM. Node N1 sets | packet to be monitored via the hybrid OAM. Node N1 sets | |||
SRH.Flags.O-flag during encapsulation required by policy P. As | SRH.Flags.O-flag during encapsulation required by policy P. As | |||
part of setting the SRH.Flags.O-flag, node N1 also send a | part of setting the SRH.Flags.O-flag, node N1 also send a | |||
timestamped copy of the packet P1: (A:1::, B:2:C31)(B:7:DT100, | timestamped copy of the packet P1: (2001:DB8:A:1::, | |||
B:4:C52, B:2:C31; SL=2; O-flag=1; NH=IPv4)(IPv4 header)(payload) | 2001:DB8:B:2:C31::) (2001:DB8:B:7:DT100::, 2001:DB8:B:4:C52::, | |||
2001:DB8:B:2:C31::; SL=2; O-flag=1; NH=IPv4)(IPv4 header)(payload) | ||||
to a local OAM process. The local OAM process sends a full or | to a local OAM process. The local OAM process sends a full or | |||
partial copy of the packet P1 to the controller N100. The OAM | partial copy of the packet P1 to the controller N100. The OAM | |||
process includes the recorded timestamp, additional OAM | process includes the recorded timestamp, additional OAM | |||
information like incoming and outgoing interface, etc. along with | information like incoming and outgoing interface, etc. along with | |||
any applicable metadata. Node N1 forwards the original packet | any applicable metadata. Node N1 forwards the original packet | |||
towards the next segment B:2:C31. | towards the next segment 2001:DB8:B:2:C31::. | |||
o When node N2 receives the packet with SRH.Flags.O-flag set, it | o When node N2 receives the packet with SRH.Flags.O-flag set, it | |||
ignores the SRH.Flags.O-flag. This is because node N2 is not | ignores the SRH.Flags.O-flag. This is because node N2 is not | |||
capable of processing the O-flag. Node N2 performs the standard | capable of processing the O-flag. Node N2 performs the standard | |||
SRv6 SID and SRH processing. Specifically, it executes the END.X | SRv6 SID and SRH processing. Specifically, it executes the END.X | |||
function (B:2:C31) and forwards the packet P1 (A:1::, | function (2001:DB8:B:2:C31::) and forwards the packet P1 | |||
B:4:C52)(B:7:DT100, B:4:C52, B:2:C31; SL=1; O-flag=1; | (2001:DB8:A:1::, 2001:DB8:B:4:C52::) (2001:DB8:B:7:DT100::, | |||
2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::; SL=1; O-flag=1; | ||||
NH=IPv4)(IPv4 header)(payload) over link 3 towards Node N3. | NH=IPv4)(IPv4 header)(payload) over link 3 towards Node N3. | |||
o When node N3, which is a classic IPv6 node, receives the packet P1 | o When node N3, which is a classic IPv6 node, receives the packet P1 | |||
, it performs the standard IPv6 processing. Specifically, it | , it performs the standard IPv6 processing. Specifically, it | |||
forwards the packet P1 based on DA B:4:C52 in the IPv6 header. | forwards the packet P1 based on DA 2001:DB8:B:4:C52:: in the IPv6 | |||
header. | ||||
o When node N4 receives the packet P1 (A:1::, B:4:C52)(B:7:DT100, | o When node N4 receives the packet P1 (2001:DB8:A:1::, | |||
B:4:C52, B:2:C31; SL=1; O-flag=1; NH=IPv4)(IPv4 header)(payload), | 2001:DB8:B:4:C52::) (2001:DB8:B:7:DT100::, 2001:DB8:B:4:C52::, | |||
it processes the SRH.Flags.O-flag. As part of processing the | 2001:DB8:B:2:C31::; SL=1; O-flag=1; NH=IPv4)(IPv4 | |||
O-flag, it sends a timestamped copy of the packet to a local OAM | header)(payload), it processes the SRH.Flags.O-flag. As part of | |||
process. The local OAM process sends a full or partial copy of | processing the O-flag, it sends a timestamped copy of the packet | |||
the packet P1 to the controller N100. The OAM process includes | to a local OAM process. The local OAM process sends a full or | |||
the recorded timestamp, additional OAM information like incoming | partial copy of the packet P1 to the controller N100. The OAM | |||
and outgoing interface, etc. along with any applicable metadata. | process includes the recorded timestamp, additional OAM | |||
Node N4 performs the standard SRv6 SID and SRH processing on the | information like incoming and outgoing interface, etc. along with | |||
original packet P1. Specifically, it executes the END.X function | any applicable metadata. Node N4 performs the standard SRv6 SID | |||
(B:4:C52) and forwards the packet P1 (A:1::, B:7:DT100)(B:7:DT100, | and SRH processing on the original packet P1. Specifically, it | |||
B:4:C52, B:2:C31; SL=0; O-flag=1; NH=IPv4)(IPv4 header)(payload) | executes the END.X function (2001:DB8:B:4:C52::) and forwards the | |||
over link 10 towards Node N5. | packet P1 (2001:DB8:A:1::, 2001:DB8:B:7:DT100::) | |||
(2001:DB8:B:7:DT100::, 2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::; | ||||
SL=0; O-flag=1; NH=IPv4)(IPv4 header)(payload) over link 10 | ||||
towards Node N5. | ||||
o When node N5, which is a classic IPv6 node, receives the packet | o When node N5, which is a classic IPv6 node, receives the packet | |||
P1, it performs the standard IPv6 processing. Specifically, it | P1, it performs the standard IPv6 processing. Specifically, it | |||
forwards the packet based on DA B:7:DT100 in the IPv6 header. | forwards the packet based on DA 2001:DB8:B:7:DT100:: in the IPv6 | |||
header. | ||||
o When node N7 receives the packet P1 (A:1::, B:7:DT100)(B:7:DT100, | o When node N7 receives the packet P1 (2001:DB8:A:1::, | |||
B:4:C52, B:2:C31; SL=0; O-flag=1; NH=IPv4)(IPv4 header)(payload), | 2001:DB8:B:7:DT100::) (2001:DB8:B:7:DT100::, 2001:DB8:B:4:C52::, | |||
it processes the SRH.Flags.O-flag. As part of processing the | 2001:DB8:B:2:C31::; SL=0; O-flag=1; NH=IPv4)(IPv4 | |||
O-flag, it sends a timestamped copy of the packet to a local OAM | header)(payload), it processes the SRH.Flags.O-flag. As part of | |||
process. The local OAM process sends a full or partial copy of | processing the O-flag, it sends a timestamped copy of the packet | |||
the packet P1 to the controller N100. The OAM process includes | to a local OAM process. The local OAM process sends a full or | |||
the recorded timestamp, additional OAM information like incoming | partial copy of the packet P1 to the controller N100. The OAM | |||
and outgoing interface, etc. along with any applicable metadata. | process includes the recorded timestamp, additional OAM | |||
Node N4 performs the standard SRv6 SID and SRH processing on the | information like incoming and outgoing interface, etc. along with | |||
original packet P1. Specifically, it executes the VPN SID | any applicable metadata. Node N4 performs the standard SRv6 SID | |||
(B:7:DT100) and based on lookup in table 100 forwards the packet | and SRH processing on the original packet P1. Specifically, it | |||
P1 (IPv4 header)(payload) towards CE 2. | executes the VPN SID (2001:DB8:B:7:DT100::) and based on lookup in | |||
table 100 forwards the packet P1 (IPv4 header)(payload) towards CE | ||||
2. | ||||
o The controller N100 processes and correlates the copy of the | o The controller N100 processes and correlates the copy of the | |||
packets sent from nodes N1, N4 and N7 to find segment-by-segment | packets sent from nodes N1, N4 and N7 to find segment-by-segment | |||
delays and provide other passive OAM information related to packet | delays and provide other hybrid OAM information related to packet | |||
P1. | P1. | |||
o The process continues for any other sampled packets. | o The process continues for any other sampled packets. | |||
6.4. Monitoring of SRv6 Paths | 3.4. 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. [RFC8403] describes | |||
like YANG are available to collect data from the network and manage | such a centralized OAM mechanism. Specifically, the document | |||
it from a centralized entity. | describes a procedure that can be used to perform path continuity | |||
check between any nodes within an SR domain from a centralized | ||||
SR technology enables a centralized OAM entity to perform path | monitoring system, with minimal or no control plane intervene on the | |||
monitoring from centralized OAM entity without control plane | nodes. However, the document focuses on SR networks with MPLS data | |||
intervention on monitored nodes. [RFC 8403] describes such a | plane. This document describes how the concept can be used to | |||
centralized OAM mechanism. Specifically, the draft describes a | perform path monitoring in an SRv6 network from the centralized | |||
procedure that can be used to perform path continuity check between | controller. | |||
any nodes within an SR domain from a centralized monitoring system, | ||||
with minimal or no control plane intervene on the nodes. However, | ||||
the draft focuses on SR networks with MPLS data plane. The same | ||||
concept applies to the SRv6 networks. This document describes how | ||||
the concept can be used to perform path monitoring in an SRv6 | ||||
network. This document describes how the concept can be used to | ||||
perform path monitoring in an SRv6 network as follows. | ||||
In the above reference topology, N100 is the centralized monitoring | ||||
system implementing an END function B:100:1::. In order to verify a | ||||
segment list <B:2:C31, B:4:C52>, N100 generates a probe packet with | ||||
SRH set to (B:100:1::, B:4:C52, B:2:C31, SL=2). The controller | ||||
routes the probe packet towards the first segment, which is B:2:C31. | ||||
N2 performs the standard SRv6 SID and SRH processing and forward it | ||||
over link3 with the DA of IPv6 packet set to B:4:C52. N4 also | ||||
performs the normal SRH processing and forward it over link10 with | ||||
the DA of IPv6 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 | 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. The controller leverages the visibility of the topology to | |||
the topology to monitor the paths between the various endpoints | monitor the paths between the various endpoints without control plane | |||
without control plane intervention required at the monitored nodes. | intervention required at the monitored nodes. | |||
7. Implementation Status | ||||
This section is to be removed prior to publishing as an RFC. | The controller N100 advertises an END SID 2001:DB8:B:100:1::. To | |||
monitor any arbitrary SRv6 paths, the controller can create a | ||||
loopback probe that originates and terminates on Node N100. For | ||||
example, in order to verify a segment list <2001:DB8:B:2:C31::, | ||||
2001:DB8:B:4:C52::>: | ||||
See [I-D.matsushima-spring-srv6-deployment-status] for updated | o N100 generates an OAM packet (2001:DB8:A:100::, | |||
deployment and interoperability reports. | 2001:DB8:B:2:C31::)(2001:DB8:B:100:1::, 2001:DB8:B:4:C52::, | |||
2001:DB8:B:2:C31::, SL=2)(OAM Payload). The controller routes the | ||||
probe packet towards the first segment, which is | ||||
2001:DB8:B:2:C31::. | ||||
8. Security Considerations | o Node N2 executes the END.X function (2001:DB8:B:2:C31::) and | |||
forwards the packet (2001:DB8:A:100::, | ||||
2001:DB8:B:4:C52::)(2001:DB8:B:100:1::, 2001:DB8:B:4:C52::, | ||||
2001:DB8:B:2:C31::, SL=1)(OAM Payload) on link3 to N3. | ||||
This document does not define any new protocol extensions and relies | o Node N3, which is a classic IPv6 node, performs the standard IPv6 | |||
on existing procedures defined for ICMP. This document does not | processing. Specifically, it forwards the packet based on the DA | |||
impose any additional security challenges to be considered beyond | 2001:DB8:B:4:C52:: in the IPv6 header. | |||
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]. | ||||
9. IANA Considerations | o Node N4 executes the END.X function (2001:DB8:B:4:C52::) and | |||
forwards the packet (2001:DB8:A:100::, | ||||
2001:DB8:B:100:1::)(2001:DB8:B:100:1::, 2001:DB8:B:4:C52::, | ||||
2001:DB8:B:2:C31::, SL=0)(OAM Payload) on link10 to N5. | ||||
9.1. ICMPv6 type Numbers Registry | o Node N5, which is a classic IPv6 node, performs the standard IPv6 | |||
processing. Specifically, it forwards the packet based on the DA | ||||
2001:DB8:B:100:1:: in the IPv6 header. | ||||
This document defines one ICMPv6 type Number in the "ICMPv6 'type' | o Node N100 executes the standard SRv6 END function. It | |||
Numbers" registry of [RFC4443]. Specifically, the document requests | decapsulates the header and consume the probe for OAM processing. | |||
to add the following ICMPv6 type Number to the "ICMPv6 Type Numbers" | The information in the OAM payload is used to detect any missing | |||
registry: | probes, round trip delay, etc. | |||
TBA (suggested value: 162) SRv6 OAM Message. | The OAM payload type or the information carried in the OAM probe is a | |||
local implementation decision at the controller and is outside the | ||||
scope of this document. | ||||
The document also requests the creation of a new IANA registry to the | 4. Implementation Status | |||
"ICMPv6 'Code' Fields" against the "ICMPv6 Type Numbers TBA - SRv6 | ||||
OAM Message" with the following codes: | ||||
Code Name Reference | This section is to be removed prior to publishing as an RFC. | |||
-------------------------------------------------------- | ||||
0 No Error This document | ||||
1 SID is not locally implemented This document | ||||
9.2. SRv6 OAM Endpoint Types | See [I-D.matsushima-spring-srv6-deployment-status] for updated | |||
deployment and interoperability reports. | ||||
This I-D requests to IANA to allocate, within the "SRv6 Endpoint | 5. Security Considerations | |||
Behaviors Registry" sub-registry belonging to the top-level "Segment- | ||||
routing with IPv6 data plane (SRv6) Parameters" registry [I-D.ietf- | ||||
spring- srv6-network-programming], the following allocations: | ||||
+------------------+-------------------+-----------+ | This document does not define any new protocol extensions and relies | |||
| Value (Suggested | Endpoint Behavior | Reference | | on existing procedures defined for ICMP. This document does not | |||
| Value) | | | | impose any additional security challenges to be considered beyond | |||
+------------------+-------------------+-----------+ | security considerations described in [RFC4884], [RFC4443], [RFC0792], | |||
| TBA (40) | End.OP | [This.ID] | | and [RFC8754]. | |||
+------------------+-------------------+-----------+ | ||||
9.3. Segment Routing Header Flags | 6. IANA Considerations | |||
6.1. Segment Routing Header Flags | ||||
This I-D requests to IANA to allocate bit position 2, within the | This I-D requests to IANA to allocate bit position 2, within the | |||
"Segment Routing Header Flags" registry defined in [I-D.draft-ietf- | "Segment Routing Header Flags" registry defined in [RFC8754]. | |||
6man-segment-routing-header]. | ||||
10. Acknowledgements | 7. Acknowledgements | |||
The authors would like to thank Gaurav Naik for his review comments. | The authors would like to thank Joel M. Halpern, Greg Mirsky, Bob | |||
Hinden, Loa Andersson and Gaurav Naik for their review comments. | ||||
11. Contributors | 8. 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 18, line 34 ¶ | skipping to change at page 18, line 26 ¶ | |||
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 | |||
12. References | 9. References | |||
12.1. Normative References | 9.1. Normative References | |||
[I-D.ietf-6man-segment-routing-header] | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Filsfils, C., Dukes, D., Previdi, S., Leddy, J., | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | ||||
<https://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., | ||||
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header | Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header | |||
(SRH)", draft-ietf-6man-segment-routing-header-26 (work in | (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, | |||
progress), October 2019. | <https://www.rfc-editor.org/info/rfc8754>. | |||
9.2. Informative References | ||||
[I-D.ietf-spring-srv6-network-programming] | [I-D.ietf-spring-srv6-network-programming] | |||
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., | Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., | |||
Matsushima, S., and Z. Li, "SRv6 Network Programming", | Matsushima, S., and Z. Li, "SRv6 Network Programming", | |||
draft-ietf-spring-srv6-network-programming-15 (work in | draft-ietf-spring-srv6-network-programming-15 (work in | |||
progress), March 2020. | progress), March 2020. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, | ||||
DOI 10.17487/RFC2119, March 1997, | ||||
<https://www.rfc-editor.org/info/rfc2119>. | ||||
12.2. Informative References | ||||
[I-D.matsushima-spring-srv6-deployment-status] | [I-D.matsushima-spring-srv6-deployment-status] | |||
Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6 | Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K. | |||
Implementation and Deployment Status", draft-matsushima- | Rajaraman, "SRv6 Implementation and Deployment Status", | |||
spring-srv6-deployment-status-06 (work in progress), March | draft-matsushima-spring-srv6-deployment-status-07 (work in | |||
2020. | progress), April 2020. | |||
[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>. | |||
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, | [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, | |||
"Extended ICMP to Support Multi-Part Messages", RFC 4884, | "Extended ICMP to Support Multi-Part Messages", RFC 4884, | |||
DOI 10.17487/RFC4884, April 2007, | DOI 10.17487/RFC4884, April 2007, | |||
<https://www.rfc-editor.org/info/rfc4884>. | <https://www.rfc-editor.org/info/rfc4884>. | |||
[RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet | ||||
Sampling (PSAMP) Protocol Specifications", RFC 5476, | ||||
DOI 10.17487/RFC5476, March 2009, | ||||
<https://www.rfc-editor.org/info/rfc5476>. | ||||
[RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, | [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, | |||
N., and JR. Rivers, "Extending ICMP for Interface and | N., and JR. Rivers, "Extending ICMP for Interface and | |||
Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, | Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, | |||
April 2010, <https://www.rfc-editor.org/info/rfc5837>. | April 2010, <https://www.rfc-editor.org/info/rfc5837>. | |||
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, | ||||
"Specification of the IP Flow Information Export (IPFIX) | ||||
Protocol for the Exchange of Flow Information", STD 77, | ||||
RFC 7011, DOI 10.17487/RFC7011, September 2013, | ||||
<https://www.rfc-editor.org/info/rfc7011>. | ||||
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model | ||||
for IP Flow Information Export (IPFIX)", RFC 7012, | ||||
DOI 10.17487/RFC7012, September 2013, | ||||
<https://www.rfc-editor.org/info/rfc7012>. | ||||
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with | ||||
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, | ||||
May 2016, <https://www.rfc-editor.org/info/rfc7799>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. | [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. | |||
Kumar, "A Scalable and Topology-Aware MPLS Data-Plane | Kumar, "A Scalable and Topology-Aware MPLS Data-Plane | |||
Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July | Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July | |||
2018, <https://www.rfc-editor.org/info/rfc8403>. | 2018, <https://www.rfc-editor.org/info/rfc8403>. | |||
Authors' Addresses | Authors' Addresses | |||
Zafar Ali | Zafar Ali | |||
Cisco Systems | Cisco Systems | |||
End of changes. 119 change blocks. | ||||
394 lines changed or deleted | 403 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/ |