[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

SPRING Working Group                                      R. Gandhi, Ed.
Internet-Draft                                               C. Filsfils
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: September 6, 2020                                  N. Vaghamshi
                                                                Reliance
                                                            M. Nagarajah
                                                                 Telstra
                                                           March 5, 2020


Enhanced Performance and Liveness Monitoring in Segment Routing Networks
                 draft-gandhi-spring-sr-enhanced-plm-00

Abstract

   Segment Routing (SR) leverages the source routing paradigm.  SR is
   applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
   (SRv6) data planes.  This document defines procedure for Enhanced
   Performance and Liveness Monitoring (PLM) in Segment Routing
   networks.  The procedure uses the probe messages defined in RFC 5357
   (Two-Way Active Measurement Protocol (TWAMP) Light) as well as STAMP
   and is applicable to both SR-MPLS and SRv6 data planes.

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, 2020.

Copyright Notice

   Copyright (c) 2020 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



Gandhi, et al.          Expires September 6, 2020               [Page 1]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


   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.  Conventions Used in This Document . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Liveness Monitoring . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Loopback Mode for SR-MPLS . . . . . . . . . . . . . . . .   5
     3.2.  Loopback Mode for SRv6  . . . . . . . . . . . . . . . . .   6
   4.  Enhanced Performance and Liveness Monitoring  . . . . . . . .   7
     4.1.  Loopback Mode Enabled with Network Programming for SR-
           MPLS  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.1.  Node Capability for Timestamp Label . . . . . . . . .   9
     4.2.  Loopback Mode Enabled with Network Programming for SRv6 .   9
   5.  ECMP Handling . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Segment Routing (SR) leverages the source routing paradigm and
   greatly simplifies network operations for Software Defined Networks
   (SDNs).  SR is applicable to both Multiprotocol Label Switching (SR-
   MPLS) and IPv6 (SRv6) data planes [RFC8402].  SR takes advantage of
   the Equal-Cost Multipaths (ECMPs) between source and transit nodes,
   between transit nodes and between transit and destination nodes.  SR
   Policies as defined in [I-D.ietf-spring-segment-routing-policy] are
   used to steer traffic through a specific, user-defined paths using a
   stack of Segments.  Built-in Liveness Monitoring for detecting faults
   as well as Performance Delay and Loss Monitoring are essential
   requirements to provide Service Level Agreements (SLAs) in SR
   networks.

   The One-Way Active Measurement Protocol (OWAMP) defined in [RFC4656]
   and Two-Way Active Measurement Protocol (TWAMP) defined in [RFC5357]
   provide capabilities for the measurement of various performance



Gandhi, et al.          Expires September 6, 2020               [Page 2]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


   metrics in IP networks using probe messages.  The TWAMP Light
   [Appendix I in RFC 5357] provides simplified mechanisms for active
   performance measurement in Customer IP networks by provisioning UDP
   paths that eliminates the control-channel signaling.  The Simple Two-
   way Active Measurement Protocol (STAMP) [I-D.ietf-ippm-stamp]
   alleviates the control-channel signaling by using configuration data
   model to provision a test-channel.  [I-D.gandhi-spring-twamp-srpm]
   defines procedure for using TWAMP Light and STAMP messages with user-
   defined IP/UDP paths in SR networks and is applicable to both SR-MPLS
   and SRv6 data planes.

   For Liveness Monitoring, Seamless Bidirectional Forwarding Detection
   (S-BFD) [RFC7880] can be used in Segment Routing networks.  However,
   S-BFD requires protocol support on the reflector node to process the
   S-BFD packets as packets are punted from forwarding path in order to
   send reply thereby limiting the scale for number of sessions and
   fault detection interval.  In addition, S-BFD protocol does not have
   the capability today to enable performance delay and loss monitoring
   in SR networks.  Enabling multiple protocols in SR networks, S-BFD
   for liveness monitoring and TWAMP Light or STAMP for performance
   delay and loss monitoring increases the operational complexity in SR
   networks.

   This document defines procedure for Enhanced Performance and Liveness
   Monitoring (PLM) in Segment Routing networks.  The procedure uses the
   probe messages defined in [RFC5357] (Two-Way Active Measurement
   Protocol (TWAMP) Light) as well as STAMP defined in
   [I-D.ietf-ippm-stamp] in loopback mode.  The procedure specified is
   applicable to both SR-MPLS and SRv6 data planes.

   The procedure defined in this document will be updated in a future
   revision to include performance loss monitoring as well.

2.  Conventions Used in This Document

2.1.  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 [RFC2119] [RFC8174]
   when, and only when, they appear in all capitals, as shown here.

2.2.  Abbreviations

   BFD: Bidirectional Forwarding Detection.

   BSID: Binding Segment ID.




Gandhi, et al.          Expires September 6, 2020               [Page 3]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


   DM: Delay Measurement.

   ECMP: Equal Cost Multi-Path.

   LM: Loss Measurement.

   MPLS: Multiprotocol Label Switching.

   OWAMP: One-Way Active Measurement Protocol.

   PLM: Performance and Liveness Monitoring.

   PM: Performance Measurement.

   PTP: Precision Time Protocol.

   SID: Segment ID.

   SL: Segment List.

   SR: Segment Routing.

   SRH: Segment Routing Header.

   SR-MPLS: Segment Routing with MPLS data plane.

   SRv6: Segment Routing with IPv6 data plane.

   STAMP: Simple Two-way Active Measurement Protocol.

   TWAMP: Two-Way Active Measurement Protocol.

3.  Liveness Monitoring

   For liveness monitoring for an SR Policy, the loopback mode as
   defined in Section 4.2.3 of [I-D.gandhi-spring-twamp-srpm] is used.
   The TWAMP Light probe messages for delay measurement defined in
   Section 4.2.1 of [RFC5357] or STAMP probe messages as defined in
   [I-D.ietf-ippm-stamp] are sent by the sender (head-end) node R1 to
   the reflector endpoint node R5 of the SR Policy using the user-
   configured IP/UDP path as shown in Figure 1.










Gandhi, et al.          Expires September 6, 2020               [Page 4]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


                  +-------+ t1     Probe        +-------+
                  |       | - - - - - - - - - - |       |
                  |   R1  |--------------------||  R5   |
                  |       |<- - - - - - - - - - |       |
                  +-------+ t4   Return Probe   +-------+
                   Sender                       Reflector Endpoint
                                                (Simply Forward)

                          Figure 1: Loopback Mode

   The probe messages are sent using the Segment List (SL) of the SR
   Policy.  When an SR Policy has more than one Segment List, multiple
   probe messages are sent, one using each Segment List.  The Source and
   Destination IP addresses in the probe messages are set to the
   reflector endpoint and the sender head-end node addresses,
   respectively.  The IPv4 Time To Live (TTL), IPv6 Hop Limit (HL),
   Router Alert (RA) Option and UDP checksum fields in the probe
   messages are set using the procedures defined in
   [I-D.gandhi-spring-twamp-srpm].

   The probe packets are not punted on the reflector node but are simply
   forwarded just like data traffic.  The probe messages are received
   back by the sender node via IP/UDP [RFC0768] return path by default.
   The Segment List of the return SR path can be added in the probe
   message header to receive the probe message on a specific reverse
   path using the mechanisms defined in [I-D.ietf-pce-binding-label-sid]
   and [I-D.ietf-pce-sr-bidir-path].  In either case, the reflector node
   must not drop the loopback probe messages, for example, due to a
   local policy provisioned on the node.

   Liveness failure is notified when consecutive N number of probe
   messages are not received back at the sender, where N is locally
   provisioned value.

3.1.  Loopback Mode for SR-MPLS

   The TWAMP Light or STAMP probe messages are sent using the label
   stack of the SR Policy as shown in Figure 2 using the procedure
   specified in [I-D.gandhi-spring-twamp-srpm].  The label stack can
   contain a reverse SR-MPLS path to receive the reply on a specific
   path.










Gandhi, et al.          Expires September 6, 2020               [Page 5]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Label(1)                   | TC  |S|      TTL      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Label(n)                   | TC  |S|      TTL      |
     +---------------------------------------------------------------+
     | IP Header                                                     |
     .  Source IP Address = Endpoint IPv4 or IPv6 Address            .
     .  Destination IP Address = Sender IPv4 or IPv6 Address         .
     .  Protocol = UDP                                               .
     .                                                               .
     +---------------------------------------------------------------+
     | UDP Header                                                    |
     .  Source Port = As chosen by Sender                            .
     .  Destination Port = User-configured Port                      .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Payload as defined in Section 4.2.1 of RFC 5357              |
     |  Payload as defined in Section 4.2 of STAMP                   |
     .                                                               .
     +---------------------------------------------------------------+

                Figure 2: Probe Message Header for SR-MPLS

3.2.  Loopback Mode for SRv6

   The TWAMP Light or STAMP probe messages are sent using the SRH
   containing the Segment Identifier (SID) List of the SR Policy as
   shown in Figure 3 using the procedure specified in
   [I-D.gandhi-spring-twamp-srpm].  The SID List can contain a reverse
   SRv6 path to receive the reply on a specific path.















Gandhi, et al.          Expires September 6, 2020               [Page 6]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


     +---------------------------------------------------------------+
     |                           SRH                                 |
     .                           <Segment List>                      .
     .                                                               .
     +---------------------------------------------------------------+
     | IP Header                                                     |
     .  Source IP Address = Endpoint IPv6 Address                    .
     .  Destination IP Address = Sender IPv6 Address                 .
     .  Protocol = UDP                                               .
     .                                                               .
     +---------------------------------------------------------------+
     | UDP Header                                                    |
     .  Source Port = As chosen by Sender                            .
     .  Destination Port = User-configured Port                      .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Payload as defined in Section 4.2.1 of RFC 5357              |
     |  Payload as defined in Section 4.2 of STAMP                   |
     .                                                               .
     +---------------------------------------------------------------+

                  Figure 3: Probe Message Header for SRv6

4.  Enhanced Performance and Liveness Monitoring

   The enhanced performance and liveness monitoring for an SR Policy is
   defined using the loopback mode enabled with network programming.
   The network programming function optimizes the "operations of punt,
   add receive timestamp and inject the probe packet" on the reflector
   node and is implemented in hardware.  In this mode, both transmit
   (t1) and receive (t2) timestamps in data plane are collected by the
   probe messages sent in loopback mode as shown in Figure 4.  The
   payload of the probe message is not modified by any intermediate
   nodes.

                  +-------+ t1    Probe      t2 +-------+
                  |       | - - - - - - - - - - |       |
                  |   R1  |--------------------||  R5   |
                  |       |<- - - - - - - - - - |       |
                  +-------+     Return Probe    +-------+
                   Sender                       Reflector Endpoint
                                                (Timestamp,
                                                 Pop and Forward)

         Figure 4: Loopback Mode Enabled with Network Programming

   The sender node adds transmit (t1) timestamp in the payload of the
   TWAMP Light or STAMP probe message and clears the receive (t2)



Gandhi, et al.          Expires September 6, 2020               [Page 7]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


   timestamp.  The endpoint node adds the receive timestamp (at the
   fixed location locally provisioned consistently in the network) in
   the payload of the received TWAMP Light or STAMP probe message
   without punting the probe message in control-plane.  The reflector
   endpoint node only adds the receive timestamp if the source address
   in the probe message matches the local node address to ensure that
   the receive timestamp is returned by the intended endpoint node.  In
   addition, the UDP port in the probe message must be locally
   programmed for adding the timestamp in the probe message.  The end-
   to-end one-way delay is measured using the receive (t2) and transmit
   (t1) timestamps in the probe message.

   Timestamp format recommended is 64-bit PTPv2 [IEEE1588] as specified
   in [RFC8186] implemented in hardware.  Note that the timestamp format
   can be locally provisioned as part of enabling the network
   programming function.  In addition to adding the timestamp in the
   message, the "Error Estimate" field in the payload of the message is
   updated using the procedure defined in [RFC4656].

   The network programming function is enabled to add receive timestamp
   in the payload of the probe message at a specific location which is
   also locally provisioned.  In TWAMP Light message defined in
   Section 4.2.1 of [RFC5357] or STAMP message defined in
   [I-D.ietf-ippm-stamp] for delay measurement, the 64-bit receive
   timestamp is added at byte-offset 16 which is from the start of the
   payload.

   Liveness failure is notified when consecutive N number of probe
   messages are not received back at the sender, where N is locally
   provisioned value.  Similarly, delay metrics are notified when
   consecutive M number of probe messages have measured delay values
   violate user-configured threshold, where M is also locally
   provisioned value.

4.1.  Loopback Mode Enabled with Network Programming for SR-MPLS

   In this document, new Timestamp Label (special purpose label with
   value TBD1) is defined for SR-MPLS to enable network programming
   function for timestamp, pop and forward the received packet.

   In the loopback mode enabled with network programming for SR-MPLS,
   Timestamp Label is added in the MPLS header as shown in Figure 5, to
   collect "Receive Timestamp" field in the payload of the TWAMP Light
   [RFC5357] or STAMP probe message.  When a node receives a message
   with Timestamp Label, other than timestamping the message at a fixed
   location, the node pops the Timestamp Label and forwards the packet
   using the next label or IP header in the packet (just like the
   packets for the normal traffic).



Gandhi, et al.          Expires September 6, 2020               [Page 8]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Label(1)                   | TC  |S|      TTL      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Label(n)                   | TC  |S|      TTL      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Timestamp Label (TBA1)     | TC  |S|      TTL      |
     +---------------------------------------------------------------+
     | IP Header                                                     |
     .  Source IP Address = Endpoint IPv4 or IPv6 Address            .
     .  Destination IP Address = Sender IPv4 or IPv6 Address         .
     .  Protocol = UDP                                               .
     .                                                               .
     +---------------------------------------------------------------+
     | UDP Header                                                    |
     .  Source Port = As chosen by Sender                            .
     .  Destination Port = User-configured Port                      .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Payload as defined in Section 4.2.1 of RFC 5357              |
     |  Payload as defined in Section 4.2 of STAMP                   |
     .                                                               .
     +---------------------------------------------------------------+

      Figure 5: Probe Message Header for SR-MPLS with Timestamp Label

4.1.1.  Node Capability for Timestamp Label

   The ingress node needs to know if the egress node can process the
   Timestamp Label.  The signaling extension for this capability
   exchange is outside the scope of this document.

   Another way is to leverage a centralized controller (e.g., SDN
   controller) to program the ingress and egress nodes.  In this case,
   the controller MUST make sure (e.g., by some capability discovery
   mechanisms outside the scope of this document) that the egress node
   can process the Timestamp Label.

4.2.  Loopback Mode Enabled with Network Programming for SRv6

   In this document, new Endpoint function "Timestamp and Forward (TSF)"
   (value TBD2) is defined for Segment Routing Header (SRH)




Gandhi, et al.          Expires September 6, 2020               [Page 9]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


   [I-D.ietf-6man-segment-routing-header] for SRv6 to enable network
   programming function for timestamp and forward the received message.

   In the loopback mode enabled with network programming for SRv6,
   END.TSF function is added for the Endpoint SID in SRH
   [I-D.ietf-6man-segment-routing-header] as shown in Figure 6, to
   collect "Receive Timestamp" field in the payload of the TWAMP Light
   [RFC5357] or STAMP probe message.  When a node receives a packet with
   END.TSF function for the target SID which is local, other than
   timestamping the packet at a fixed location, the node forwards the
   packet using the next SID or IP header in the packet (just like the
   packets for the normal traffic).

     +---------------------------------------------------------------+
     |                           SRH                                 |
     .                           <Segment List>                      .
     +---------------------------------------------------------------+
     | IP Header                                                     |
     .  Source IP Address = Endpoint IPv6 Address                    .
     .  Destination IP Address = Sender IPv6 Address                 .
     .  Protocol = UDP                                               .
     .                                                               .
     +---------------------------------------------------------------+
     | UDP Header                                                    |
     .  Source Port = As chosen by Sender                            .
     .  Destination Port = User-configured Port                      .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Payload as defined in Section 4.2.1 of RFC 5357              |
     |  Payload as defined in Section 4.2 of STAMP                   |
     .                                                               .
     +---------------------------------------------------------------+

      Figure 6: Probe Message Header for SRv6 with Endpoint Function

5.  ECMP Handling

   An SR Policy can have ECMPs between the source and transit nodes,
   between transit nodes and between transit and destination nodes.  The
   PM probe messages need to be sent to traverse different ECMP paths to
   monitor the liveness for an SR Policy.

   Forwarding plane has various hashing functions available to forward
   packets on specific ECMP paths.  In the IP header of the PM probe
   messages, sweeping of Destination Addresses in 127/8 range for IPv4
   or 0:0:0:0:0:FFFF:7F00/104 range for IPv6 can be used to exercise
   different ECMP paths in loopback mode as long as the reverse path is




Gandhi, et al.          Expires September 6, 2020              [Page 10]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


   also an SR-MPLS or SRv6 path.  The Flow Label field in the outer IPv6
   header can also be used for sweeping ECMP paths.

6.  Security Considerations

   The Performance and Liveness Monitoring is intended for deployment in
   the well-managed private and service provider networks.  As such, it
   assumes that a node involved in a monitoring operation has previously
   verified the integrity of the path and the identity of the far-end
   reflector node.  If desired, attacks can be mitigated by performing
   basic validation and sanity checks, at the sender, of the counter or
   timestamp fields in received measurement response messages.  The
   minimal state associated with these protocols also limits the extent
   of disruption that can be caused by a corrupt or invalid message to a
   single query/response cycle.  Use of HMAC-SHA-256 in the
   authenticated mode protects the data integrity of the probe messages.
   Cryptographic measures may be enhanced by the correct configuration
   of access-control lists and firewalls.

7.  IANA Considerations

   IANA maintains the "Special-Purpose Multiprotocol Label Switching
   (MPLS) Label Values" registry (see <https://www.iana.org/assignments/
   mpls-label-values/mpls-label-values.xml>).  IANA is requested to
   allocate Timestamp Label value from the "Extended Special-Purpose
   MPLS Label Values" registry:

       +-------------+-------------------------+---------------+
       | Value       | Description             | Reference     |
       +-------------+-------------------------+---------------+
       | TBA1        | Timestamp Label         | This document |
       +-------------+-------------------------+---------------+

   IANA is requested to allocate, within the "SRv6 Endpoint 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:

       +-------------+---------------------------------+---------------+
       | Value       | Endpoint Behavior               | Reference     |
       +-------------+---------------------------------+---------------+
       | TBA2        | END.TSF (Timestamp and Forward) | This document |
       +-------------+---------------------------------+---------------+







Gandhi, et al.          Expires September 6, 2020              [Page 11]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


8.  References

8.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/info/rfc768>.

   [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>.

   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
              Zekauskas, "A One-way Active Measurement Protocol
              (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
              <https://www.rfc-editor.org/info/rfc4656>.

   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
              RFC 5357, DOI 10.17487/RFC5357, October 2008,
              <https://www.rfc-editor.org/info/rfc5357>.

   [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>.

   [I-D.gandhi-spring-twamp-srpm]
              Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B.
              Janssens, "Performance Measurement Using TWAMP Light for
              Segment Routing Networks", draft-gandhi-spring-twamp-
              srpm-05 (work in progress), December 2019.

   [I-D.ietf-ippm-stamp]
              Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
              Two-way Active Measurement Protocol", draft-ietf-ippm-
              stamp-10 (work in progress), October 2019.

8.2.  Informative References

   [IEEE1588]
              IEEE, "1588-2008 IEEE Standard for a Precision Clock
              Synchronization Protocol for Networked Measurement and
              Control Systems", March 2008.







Gandhi, et al.          Expires September 6, 2020              [Page 12]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


   [RFC7880]  Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
              Pallagatti, "Seamless Bidirectional Forwarding Detection
              (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
              <https://www.rfc-editor.org/info/rfc7880>.

   [RFC8186]  Mirsky, G. and I. Meilik, "Support of the IEEE 1588
              Timestamp Format in a Two-Way Active Measurement Protocol
              (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017,
              <https://www.rfc-editor.org/info/rfc8186>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", draft-
              ietf-spring-segment-routing-policy-06 (work in progress),
              December 2019.

   [I-D.ietf-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
              Matsushima, S., and Z. Li, "SRv6 Network Programming",
              draft-ietf-spring-srv6-network-programming-10 (work in
              progress), February 2020.

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-26 (work in
              progress), October 2019.

   [I-D.ietf-pce-binding-label-sid]
              Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J.,
              Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID
              in PCE-based Networks.", draft-ietf-pce-binding-label-
              sid-01 (work in progress), November 2019.

   [I-D.ietf-pce-sr-bidir-path]
              Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
              "PCEP Extensions for Associated Bidirectional Segment
              Routing (SR) Paths", draft-ietf-pce-sr-bidir-path-01 (work
              in progress), February 2020.







Gandhi, et al.          Expires September 6, 2020              [Page 13]


Internet-Draft  Performance and Liveness Monitoring in SR     March 2020


Acknowledgments

   TBD

Authors' Addresses

   Rakesh Gandhi (editor)
   Cisco Systems, Inc.
   Canada

   Email: rgandhi@cisco.com


   Clarence Filsfils
   Cisco Systems, Inc.

   Email: cfilsfil@cisco.com


   Navin Vaghamshi
   Reliance

   Email: Navin.Vaghamshi@ril.com


   Moses Nagarajah
   Telstra

   Email: Moses.Nagarajah@team.telstra.com






















Gandhi, et al.          Expires September 6, 2020              [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/