Network Working Group C. Li Internet-Draft M. Chen Intended status: Standards Track Huawei Expires: September 6, 2018 March 5, 2018 Passive Performance Measurement for SRv6 Network Programming draft-li-spring-passive-pm-for-srv6-np-00 Abstract This document defines a passive performance measurement method for SRv6 network programming. In this method, performance measurement information can be carried in data packets by two ways. One way is carrying measurement information by used SIDs. Another way is carrying measurement information via related SRH TLVs. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of Li & Chen Expires September 6, 2018 [Page 1] Internet-Draft Passive PM for SRv6 NP March 2018 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Passive SRv6 Performace Measurement . . . . . . . . . . . . . 4 4. SRH Flags for PM . . . . . . . . . . . . . . . . . . . . . . 5 4.1. DM-bit for Delay Measurement . . . . . . . . . . . . . . 5 4.2. LM-bit for Loss Measurement . . . . . . . . . . . . . . . 6 5. Optional TLVs . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Path ID TLV . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Block ID TLV . . . . . . . . . . . . . . . . . . . . . . 9 5.3. DM TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. LM TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Delay Measurement procedures . . . . . . . . . . . . . . 12 6.1.1. Using SIDs . . . . . . . . . . . . . . . . . . . . . 12 6.1.2. Using DM TLV . . . . . . . . . . . . . . . . . . . . 13 6.2. Loss Measurement procedures . . . . . . . . . . . . . . . 14 6.2.1. Using SIDs . . . . . . . . . . . . . . . . . . . . . 14 6.2.2. Using LM TLV . . . . . . . . . . . . . . . . . . . . 15 6.3. End.IOAM . . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Segment routing (SR) [I-D.ietf-spring-segment-routing] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node by inserting an ordered list of instructions, called segments. A segment can represent a topological or service-based instruction. Segment routing allows a node to steer packets based on segments. When segment routing is deployed on IPv6 dataplane, called SRv6[I-D.ietf-6man-segment-routing-header], a segment is a 128 bit value, and it can be an IPv6 address of a local interface but it does Li & Chen Expires September 6, 2018 [Page 2] Internet-Draft Passive PM for SRv6 NP March 2018 not have to. As defined at [I-D.filsfils-spring-srv6-network-programming], a segment has the format of LOC: FUNCT. The most significant L bits is LOC that is routable and leads packets to the SID originating node. The least significant 128-L bits is the value of FUNCT that defines the local actions of SID. L is the length of LOC and it is flexible. For supporting SR, an extended header called Segment Routing Header (SRH), which contains a list of SIDs and several needed information such as Segment Left, has been defined in [I-D.ietf-6man-segment-routing-header]. In most cases, a SRv6 segment will not be reused for routing again after it has been updated to IPv6 destination address. But these used SIDs will be carried in the packet to the egress node unless PSP is enable. Therefore, these SIDs can be reused for other purposes such as carring performance measurement information or IOAM [I-D.ietf-ippm-ioam-data] information. This document introduces a passive SRv6 network programming based performance measurement. In this method, the performance measurement information can be carried in data packets without extra OAM packets. There are two options to carry the performance measurement information in the data packets: using SIDs and using TLVs. Using SIDs to carry performance measurement information will reuse the SID space and does no require any extra space. Therefore, it is a light weight SRv6 network programming based performance measurement method or even a light weight SRv6 network programming based IOAM. 2. Terminology This memo makes use of the terms defined in [I-D.ietf-spring-segment-routing], [I-D.ietf-ippm-ioam-data] and [I-D.filsfils-spring-srv6-network-programming]. It also introduces the following terminologies. PM: Performance measurement. DM: Delay measurement. LM: Packet Loss measurement. DA: Destination Address MI: Measurement Information PMI: Performance Measurement Information NMS: Network Management System Li & Chen Expires September 6, 2018 [Page 3] Internet-Draft Passive PM for SRv6 NP March 2018 3. Passive SRv6 Performace Measurement This document defines a passive SRv6 performance measurement method including delay measurement and packet loss measurement. For delay measurement (DM), timestamp will be carried in the data packet. For end-to-end DM, only the ingress node sending timestamp needs to be carried in the data packet while all the timestamps of each endpoint node along the path need to be carried for per-hop DM. The timestamp will be used for calculating the delay by the egress node or a controller, and the algorithm is the same as defined at [RFC6374]. This documents proposes two options to carry timestamps: using SIDs and using DM TLV. For achieving DM, this document defines a new SRH flag DM bit. For LM, counters associated with block[RFC8321] should be set. The packets coloring and counting mechanism are the same as defined at [RFC8321]. For identifying a block which the packet belongs to, a Block ID TLV is proposed by this document. There are two options to collect counters.The first one is sending counter values to NMS or controller by nodes periodically. This option will be discussed at later version of this document or another document. This document will describe the second option, carrying counter values by packets to the egress node and sending to controller or calculating by the egress node. For achieving LM, this document defines a new SRH flag LM bit. A Block ID TLV should be carried by each data packets for packet accounting when packet loss measurement is enable. The LM bit can be set periodically at packets of a flow, so that corresponding counter values can be obtained. Some packets without payload MUST be sent so that the counter of last block can be obtained if there is no data packet to carry PMI. This meachanism will be discussed at the later version of this document. For solving the problem of packet misorder, a data packet can carry the counter value of the previous block, which means a sufficient margin should be considered between the end of the block and reading of counter. For solving the problem of lossing the data packets with LM data, multiple data packets with LM data can be sent in a block. These meachanisms will be discussed at the future version. For end-to-end LM, only the ingress node counter value needs to be carried in data packets. But counter values of each endpoint node along the path need to be carried for per-hop LM. The counter value will be used for calculating the packet loss by the egress node or a controller, and the algorithm is the same as defined at [RFC6374]. Li & Chen Expires September 6, 2018 [Page 4] Internet-Draft Passive PM for SRv6 NP March 2018 As well as DM, LM has two options to carry performance measurement information(PMI): using SIDs and using LM TLV. For option of using SIDs, PMI can be carried by the last 64 bits of SIDs. In SRv6, a SID will not be used for routing after it has been updated to IPv6 destination address (DA), so it can be rewrote with metadata such as PMI. But for identifying nodes of SR path, the LOC part of SID needs to remain still if there is no path ID to identify a path, so only the non-LOC part can be rewrote with PMI. In this draft, we assume the value of length of LOC is 64 or less when there is no path ID in SRH since PMI need to meet the accuracy requirement as defined at [I-D.ietf-ippm-ioam-data]. For getting rid of the limitation of keeping LOC part of SIDs, a Path ID TLV is defined at this documents. Using SID to carry PMI is a light weight passive PM method for SRv6, and it also can be a light weight IOAM for SRv6. For options of using TLVs, this documents defines DM TLV and LM TLV in SRH to carry the PMI. Futhermore, for punting a copied packet at a specific node, a new SID is proposed at Section 6.3, called End.IOAM. 4. SRH Flags for PM For measuring delay and packet loss, this draft defines 2 new flags in SRH: o DM-bit (Delay Measurement): Flag for Delay Measurement. o LM-bit (Loss Measurement): Flag for Loss Measurement.. The recommended locations of DM-bit and LM-bit in SRH.Flag shows below. 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | U| P| O| A| H|DM|LM| U| +--+--+--+--+--+--+--+--+ The rest of this section will describe more detailed information of these two flags. 4.1. DM-bit for Delay Measurement The "Delay Measurement bit (DM-bit for short)" is a new flag in SRH. The SRH.Flags.DM implements the "record timestamp and punt the copied packet at the egress node" behavior. When a node N receives an SRv6 packet, N does following actions for processing DM-bit: Li & Chen Expires September 6, 2018 [Page 5] Internet-Draft Passive PM for SRv6 NP March 2018 1.If DM-bit = 1: 2. Get the receving timestamp T1 ASAP. 3. If SL=1 and DA is End.S or if SL=0: ;;Ref1 4. Punt a copied packet with T1 to CPU for further processing;;Ref2 5. Else: 6. If DM TLV: 7 If I-flag = 1: 8. Write T1 into DM TLV 9. Else: 10. Insert following code after the instruction of updating DA: 11. Update SRH[SL][64:] with the T1 ;;Ref3 o Ref1: If SL is 0 or SL is 1 and the DA is an End.S [I-D.filsfils-spring-srv6-network-programming], meaning the current node is the egress node, the node will punt a copied packet with the timestamp to CPU for further processing. Else, the node, which a middle node only inserts "updates the SID with current timestamp" after the instruction of "update DA with SRH[SL]" or write the timestamp into DM TLV if the I-flag is set. The ralated timestamp at the ingress node should be wrote into SID or DM TLV accordingly before sending the data packet. o Ref2: At the egress node, in order to not affect the packet forwarding, a copied data packet should be punted instead of the datda packet itself. But this document does not limit implementation to punt the entire packet or only headers of packet. o Ref3: If no DM TLV appears in SRH, the last 64 bits of SID SRH[SL] is rewrote with current timestamp after updating SID SRH[SL] to IPv6 DA. If there is no Path ID TLV in SRH, the locator part needs to remain for identifying a SID. The 64-bits timestamp meets the accuracy requirement of IOAM [I-D.ietf-ippm-ioam-data]. If a node does not support the DM-bit, then it simply ignores it upon reception. If a node supports the DM-bit, it SHOULD advertise its capability via node capability advertisement in IGP [ID.TBA]. When DM-bit is set, PSP flavor can not be enable since the SRH needs to be punted at the egress node. Likewise, implementation of USP should be executed after DM-flag's implementation because of the same reason. 4.2. LM-bit for Loss Measurement The "Loss Measurement bit (LM-bit for short)" is a new flag in SRH. The SRH.Flags.LM implements the"record value of counter and punt the Li & Chen Expires September 6, 2018 [Page 6] Internet-Draft Passive PM for SRv6 NP March 2018 copied packet at the egress node" behavior. When a node N receives an SRv6 packet, N does following actions for processing LM-bit: 1.If LM-bit = 1: 2. Record the value of corresponding counter as C1 3. If SL=1 and DA is End.S or if SL=0: ;;Ref1 4. Punt a copied packet with C1 to CPU for further processing;;Ref2 5. Else: 6. If LM TLV: 7 If I-flag = 1: 8. Write C1 into LM TLV 9. Else: 10. Insert following code after the instruction of updating DA: 11. Update SRH[SL][64:] with the C1 ;;Ref3 o Ref1: If SL is 0 or SL is 1 and the DA is an End.S [I-D.filsfils-spring-srv6-network-programming], meaning the current node is the egress node, the node will punt a copied packet with the related counter's value to CPU for further processing. Else, the node, which is a middle node only inserts "updates the SID with current value of counter" after the instruction of "update DA with SRH[SL]" or or write the counter value into LM TLV if the I-flag is set. The related counter value at the ingress node should be wrote into SID or DM TLV accordingly before sending the data packet. o Ref2: At the egress node, in order to not affect the packet forwarding, a copied data packet should be punted instead of the data packet itself. But this document does not limit implementation to punt the entire packet or only headers of packet. For measuring correctly, a Block ID TLV SHALL be carried in SRH. o Ref3: If no LM TLV appears in SRH, the last 64 bits of SID SRH[SL] is rewrote with current value of counter associated to a path or a flow after updating the SID SRH[SL] to IPv6 DA. If there is no Path ID TLV in SRH, the locator part needs to remain for identifying a SID. The key of counter can be SID list or path ID or other ID such as flow label [I-D.fioccola-spring-flow-label-alt-mark] that can identify a SID path or a flow. However, a SID can be the key for a single hop packet loss measurement. If a node does not support the LM-bit, then it simply ignores it upon reception. If a node supports the LM-bit, it SHOULD advertise its capability via node capability advertisement in IGP [ID.TBA]. Li & Chen Expires September 6, 2018 [Page 7] Internet-Draft Passive PM for SRv6 NP March 2018 When LM-bit is set, PSP flavor can not be enable since the SRH needs to be punted at the egress node. Likewise, implementation of USP should be executed after LM-flag's implementation because of the same reason. 5. Optional TLVs 5.1. Path ID TLV For easier identifying an SR path, this document defines a new Path ID TLV, which identifies an SR path beginning from the ingress node. If the path ID is a global ID, it can identfiy a path within an SR domain then. If the path ID is a local ID assigned by an ingress node, a tuple can identify a single path within an SR domain. The Ingress ID can be the ingress node SID or other ID that can identify ingress uniquely within an SR domain. With a Path ID TLV, the whole SID space can be reused for carrying metadata since the path information will be indicated by the path ID. The global path ID or tuple of can be the key of counter for packet loss measurement. The Path ID TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flag | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: o Type: to be assigned by IANA (suggested value 7). o Length: 6. o Flag: 8 bits of flags. Following flags are defined: 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | Reserved | G| +--+--+--+--+--+--+--+--+ G-Flag: Global flag. Set when the path ID is a global path ID. o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be ignored on receipt. Li & Chen Expires September 6, 2018 [Page 8] Internet-Draft Passive PM for SRv6 NP March 2018 o Path ID: 32 bits. Defines a unique path beginning from the ingress node. With a Path ID TLV, the entire SID space can be reused without limitation of keeping LOC part. 5.2. Block ID TLV Marking packets with difference colors as a block is a packet loss measurement method proposed at [RFC8321]. A block ID describes a block which the packet belongs to. This document defines a new Block ID TLV, and it has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | RESERVED | Block ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: o Type: to be assigned by IANA (suggested value 8). o Length: 2. o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be ignored on receipt. o Block ID: 8 bits. Defines a block which the packet belongs to. 5.3. DM TLV Delay measurement information can be carried by DM TLV. The timestamp type is the same as defined at [I-D.ietf-ippm-ioam-data]. DM TLV will appear only once in SRH, the first one will be processed while the rests will be ignored. The DM TLV has the following format: Li & Chen Expires September 6, 2018 [Page 9] Internet-Draft Passive PM for SRv6 NP March 2018 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type | length | Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp n | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: o Type: to be assigned by IANA (suggested value 9). o Length: 8-bit unsigned integer. This field specifies the length of data added by each node in multiples of 4-octets. o Flag: 8 bits of flags. Following flags are defined: 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | Reserved | I| +--+--+--+--+--+--+--+--+ I-Flag: IOAM flag. Set when the the measurment mode is IOAM mode. If it is not set, only one timestamp will be carried at this DM TLV, which is a 64 bits sending timestamp at the ingress node. Thus, the middle nodes will not write the timestamp into DM TLV. o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be ignored on receipt. o Timestamp 1: 64 bits sending timestamp at the ingress node. o Timestamp n: 64 bits receving timestamp at a specific node n. 5.4. LM TLV Loss measurement information can be carried by LM TLV. LM TLV will appear only once in SRH, the first one will be processed while the rests will be ignored. The LM TLV has the following format: Li & Chen Expires September 6, 2018 [Page 10] Internet-Draft Passive PM for SRv6 NP March 2018 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type | length | Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Coutner 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Counter n | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: o Type: to be assigned by IANA (suggested value 10). o Length: 8-bit unsigned integer. This field specifies the length of data added by each node in multiples of 4-octets. o Flag: 8 bits of flags. Following flags are defined: 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | Reserved | I| +--+--+--+--+--+--+--+--+ I-Flag: IOAM flag. Set when the the measurment mode is IOAM mode. If it is not set, only one counter will be carried at this LM TLV, which is a 64 bit counter value of pakcets in corresponding block at the ingress node. Thus, the middle nodes will not write the counter value into DM TLV. o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be ignored on receipt. o Counter 1: 64 bits counter value of packets in corresponding block at the ingress node. o Counter n: 64 bits counter value of packets in corresponding block at the ingress node at a specific node n. Li & Chen Expires September 6, 2018 [Page 11] Internet-Draft Passive PM for SRv6 NP March 2018 6. Operations This section will describe detailed operations of passive SRv6 network programming based performance measurement. For easy understanding, the following simple topology is used for illustration. CE-A ---- N1-----N2-----N3---- CE-B Reference Topology In the reference topology: o Nodes N1, N2, and N3 are all SRv6 capable nodes. o Node N1 and N3 are configured with a tenant 10, each connected to CE-A and CE-B respectively. o Node Nk has Ak::/68 for its local SID space from which Local SIDs are explicitly allocated. o A2::1 is an End function allocated by N2 o A3::D10 is an End.DT4 function bound to tenant IPv4 table 10 allocated by N3. o Bk::/64 is the loopback address of node K for IGP. Assuming that the measured flow from CE-A to CE-B will travel path . The ingress node N1 will insert a SRH with SID list into the IPv6 header when it receives a IPv4 packet with SA is CE-A, and DA is CE-B, so the packet header is (B1, DA) (A3::D10, A2::1, SL=2)(CE-A, CE-B). The DA of IPv6 header is waiting to be reworte by the active segment. 6.1. Delay Measurement procedures For measuring delay, there are two options. In both options, DM-bit needs to be set. If there is a DM TLV in SRH, PMI will be carried by DM TLV. Otherwise, the PMI will be carried by SIDs. 6.1.1. Using SIDs If choosing the option of using SIDs to carry delay MI, the SRH.Flag.DM-bit needs to be set, and DM TLV MUST NOT appear in SRH. After updating IPv6 DA with A2::1, the ingress node N1 updates SID A2::1 in SRH with current timestamp and then forwards packet to N2 Li & Chen Expires September 6, 2018 [Page 12] Internet-Draft Passive PM for SRv6 NP March 2018 according to matched FIB entries. Assuming that the timestamp value is T1, then the updated packet header becomes (B1, A2::1) (A3::D10, A2::T1, SL=1) (CE-A, CE-B). When N2 receives the packet with DA A2::1 which is an End SID originated by N2, N2 will insert "Update SRH[SL][64:] with the current timestamp" after instruction of "update DA with SRH[SL]", and then process this End SID. After updating IPv6 DA with SRH[0] A::D10, the current timestamp will be recorded at the last 64 bits of End SID A3::D10. Assuming that the timestamp value is T2, the updated packet header becomes (B1, A3::D10) (A3::T2, A2::T1, SL=0) (CE-A, CE-B). According to the updated DA A3::D10, the packet will be forwarded to N3. When the egress node N3 receives the packet with header (B1, A3::D10) (A3::T2, A2::T1, SL=0) (CE-A, CE-B), N3 should timestamp the copied packet and punt it to CPU for further processing since SRH.SL is 0 meaning the packet has reached the egress node. Then, N3 decapsulates the outer header and forwards the inner packet to CE-B based on the routes in tenant-10 IPv4 table since the DA is a local End.DT4 SID. Measurement can be implemented by node or a remote controller. The algorithm of delay measurement is the same as defined at [RFC6374]. However, in this solution, only one receiving timestamp or sending timestamp can be recorded in SID at each endpoint node. Therefore, it is RECOMMENDED that the ingress node records the sending timestamp while the other nodes record the receiving timestamp. Therefore, end-to-end delay measurement can be measured accurately. But for middle nodes, the delay for a single hop is the sum of previous node's processing delay and link delay between two nodes instead of link delay only. 6.1.2. Using DM TLV If choosing the option of using DM TLV to carry delay MI, and the SRH.Flag.DM-bit needs to be set, and a DM TLV needs to be inserted in SRH with the flag set accordingly. Using the DM TLV will not affect the processing of SIDs. But before sending a data packet, the ingress node N1 will write the sending timestamp into DM TLV. When a middle node N2 receives a data packet, it will inspect the existence of DM TLV. If there is a DM TLV in SRH and the SRH.DM.I-flag is set, then a timestamp Tn will be wrote into DM TLV. Otherwise, the DM TLV will contain an ingress sending timestamp only. When the packet arrives at the egress node N3, a Li & Chen Expires September 6, 2018 [Page 13] Internet-Draft Passive PM for SRv6 NP March 2018 copied packet with its timestamp will be punted to CPU for further processing. 6.2. Loss Measurement procedures For measuring packet loss, there are two options. In both options, LM-bit needs to be set. If there is a LM TLV in SRH, PMI will be carried by LM TLV. Otherwise, the PMI will be carried by SIDs. 6.2.1. Using SIDs If choosing the option of using SIDs to carry packet loss MI, the SRH.Flag.LM-bit needs to be set, and LM TLV MUST NOT appear in SRH. After updating IPv6 DA with A2::1, the ingress node N1 updates A2::1 with the current counter value and then forwards packet to N2 according to matched FIB entries. Assuming that the corresponding counter value is C1, then the updated packet header becomes (B1, A2::1) (A3::D10, A2::C1, SL=1) (CE-A, CE-B). When node N2 receives the packet with DA A2::1 which is an End SID originated by N2, node N2 will insert "Update SRH[SL][64:] with the current counter value" after instruction of "update DA with SRH[SL]", and then process End SID. After updating IPv6 DA with SRH[0] A::D10, the current counter value will be recorded at the last 64 bits of End SID A3::D10. Assuming that the value of corresponding counter is C2, then the updated packet header becomes (B1, A3::D10) (A3::C2, A2::C1, SL=0) (CE-A, CE- B). According to the updated DA A3::D10, the packet will be forwarded to N3. When the egress node N3 receives the packet with header (B1, A3::D10) (A3::C2, A2::C1, SL=0) (CE-A, CE-B), node N3 punts a copied packet with its corresponding counter value to CPU for further processing since the packet has reached the egress node. Then, N3 decapsulates the outer header and forwards the inner packet to CE-B based on the routes in tenant-10 IPv4 table since the DA is a local End.DT4 SID. Measurement can be implemented by node or a remote controller. The algorithm of packet loss measurement is the same as defined at [RFC6374]. Per-hop packet loss or end-to-end packet loss can be measured by data packets without additional OAM packets. Li & Chen Expires September 6, 2018 [Page 14] Internet-Draft Passive PM for SRv6 NP March 2018 6.2.2. Using LM TLV If choosing the option of using LM TLV to carry packet loss MI, and the SRH.Flag.LM-bit needs to be set, and a LM TLV needs to be inserted in SRH with the flag set accordingly. Using the LM TLV will not affect the processing of SIDs. But before sending a data packet, the ingress node N1 should write the counter value into LM TLV. When the middle node N2 receives a data packet, it should inspect the existence of LM TLV. If there is a LM TLV in SRH and the SRH.LM.I-flag is set, then a counter value Cn will be wrote into LM TLV. Otherwise, the LM TLV will contain the counter value at the ingress node only. When the packet arrives at the egress node N3, a copied packet with its counter value will be punted to CPU for further processing. 6.3. End.IOAM In many scenarios, such as In-situ OAM, a copied packet with corresponding metadata needs to be punted to CPU at a node in the network. This document proposes a new SID function called End.IOAM to implement it. This Function uses the reseved opcode which is TBA. It can be inserted in any location of SIDs list to punt a copied data packet at any node along the SRv6 path. When N receives a packet destined to S and S is a local End.IOAM SID, N does: 1.Punt a copied packet with metadata to CPU for further processing ;;Ref1 o Ref1: The corresponding metadata should be obtained according to the IOAM data type. In this draft, IOAM data such as timestamp can be indicated by SRH flags. If the last SID is a End.IOAM SID, two copied packets will be punted since the another packet will be punted as well by SL=0. The solution of solving this problem will be futher discussed in a future verison of this document. 7. IANA Considerations TBA 8. Security Considerations TBA Li & Chen Expires September 6, 2018 [Page 15] Internet-Draft Passive PM for SRv6 NP March 2018 9. Acknowledgements TBA 10. References 10.1. Normative References [I-D.filsfils-spring-srv6-network-programming] Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. Camarillo, "SRv6 Network Programming", draft-filsfils- spring-srv6-network-programming-03 (work in progress), December 2017. [I-D.ietf-6man-segment-routing-header] Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., Field, B., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-08 (work in progress), January 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2. Informative References [I-D.fioccola-spring-flow-label-alt-mark] Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "Using the IPv6 Flow Label for Performance Measurement with Alternate Marking Method in Segment Routing", draft- fioccola-spring-flow-label-alt-mark-01 (work in progress), October 2017. [I-D.ietf-ippm-alt-mark] Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate Marking method for passive and hybrid performance monitoring", draft-ietf-ippm-alt-mark-14 (work in progress), December 2017. Li & Chen Expires September 6, 2018 [Page 16] Internet-Draft Passive PM for SRv6 NP March 2018 [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- data-02 (work in progress), March 2018. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-12 (work in progress), February 2018. [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018, . Authors' Addresses Cheng Li Huawei Email: chengli13@huawei.com Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com Li & Chen Expires September 6, 2018 [Page 17]