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 <Ingress ID, Path ID> 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 <Ingress ID, Path ID> 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
   <N1, N2, N3>.  The ingress node N1 will insert a SRH with SID list
   <A2::1, A3::D10> 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,
              <https://www.rfc-editor.org/info/rfc2119>.

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,
              <https://www.rfc-editor.org/info/rfc6374>.

   [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, <https://www.rfc-editor.org/info/rfc8321>.

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]