Skip to main content

Segment Routing Header encapsulation for Alternate Marking Method
draft-fz-spring-srv6-alt-mark-03

Document Type Active Internet-Draft (individual)
Authors Giuseppe Fioccola , Tianran Zhou , Mauro Cociglio
Last updated 2022-08-05
Stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-fz-spring-srv6-alt-mark-03
SPRING Working Group                                         G. Fioccola
Internet-Draft                                                   T. Zhou
Intended status: Standards Track                                  Huawei
Expires: 6 February 2023                                     M. Cociglio
                                                          Telecom Italia
                                                           5 August 2022

   Segment Routing Header encapsulation for Alternate Marking Method
                    draft-fz-spring-srv6-alt-mark-03

Abstract

   This document describes how the Alternate Marking Method can be used
   as the passive performance measurement tool in an SRv6 network.  It
   defines how Alternate Marking data fields are transported as part of
   the Segment Routing with IPv6 data plane (SRv6) header.

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 6 February 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Fioccola, et al.         Expires 6 February 2023                [Page 1]
Internet-Draft                  SRv6 AMM                     August 2022

   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 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Application of the Alternate Marking to SRv6  . . . . . . . .   3
     2.1.  Controlled Domain . . . . . . . . . . . . . . . . . . . .   4
   3.  Definition of the SRH AltMark TLV . . . . . . . . . . . . . .   4
     3.1.  Data Fields Format  . . . . . . . . . . . . . . . . . . .   4
   4.  Use of the SRH AltMark TLV  . . . . . . . . . . . . . . . . .   6
   5.  Alternate Marking Method Operation  . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   [I-D.ietf-ippm-rfc8321bis] and [I-D.ietf-ippm-rfc8889bis] describe a
   passive performance measurement method, which can be used to measure
   packet loss, latency and jitter on live traffic.  Since this method
   is based on marking consecutive batches of packets, the method is
   often referred as Alternate Marking Method.

   This document defines how the Alternate Marking Method
   ([I-D.ietf-ippm-rfc8321bis]) can be used to measure packet loss and
   delay metrics for Segment Routing with IPv6 data plane (SRv6).

   [RFC8754] defines the Segment Routing Header (SRH) and how it is used
   by nodes that are Segment Routing (SR) capable.

   [I-D.ietf-6man-ipv6-alt-mark] analyzes the possible implementation
   options for the application of the Alternate Marking Method in an
   IPv6 domain.  [I-D.ietf-6man-ipv6-alt-mark] defines a new TLV that
   can be encoded in the Option Headers (both Hop-by-hop or Destination)
   for the purpose of the Alternate Marking Method application in an
   IPv6 domain.

Fioccola, et al.         Expires 6 February 2023                [Page 2]
Internet-Draft                  SRv6 AMM                     August 2022

   This document defines how Alternate Marking data is carried as SRH
   TLV, that can be can be piggybacked in the packet and transported as
   part of the SRH.  The usage of SRH TLV is introduced in [RFC8754].

2.  Application of the Alternate Marking to SRv6

   The Alternate Marking Method requires a marking field.  A possibility
   is already offered by [I-D.ietf-6man-ipv6-alt-mark] while the use of
   a new TLV to be encoded in the SRH is defined in this document.

   Since [I-D.ietf-6man-ipv6-alt-mark] defines the IPv6 Application of
   the Alternate Marking Method through both Hop-by-Hop and Destination
   Options Header, it is applicable also to SRv6 network.  Indeed the
   use of Destination Option Header carrying Alternate Marking bits
   coupled with SRH allows to monitor every node along the SR path.

   This document introduces the SRH TLV carrying Alternate Marking bits
   and this can be a preferred approach in case of SRv6 network since it
   does not rely on the use of Destination Option Header.

   The optimization of both implementation and scaling of the Alternate
   Marking Method is also considered and a way to identify flows is
   required.  The Flow Monitoring Identification field (FlowMonID), as
   introduced in the next sections, goes in this direction and it is
   used to identify a monitored flow.

   Note that the FlowMonID is different from the Flow Label field of the
   IPv6 Header ([RFC8200]).  Flow Label is used for application service,
   like load-balancing/equal cost multi-path (LB/ECMP) and QoS.
   Instead, FlowMonID is only used to identify the monitored flow.  The
   reuse of flow label field for identifying monitored flows is not
   considered since it may change the application intent and forwarding
   behaviour.  Furthermore the flow label may be changed en route and
   this may also violate the measurement task.  Those reasons make the
   definition of the FlowMonID necessary for IPv6.  Flow Label and
   FlowMonID within the same packet have different scope, identify
   different flows, and associate different uses.

   An important point that will also be discussed in this document is
   the the uniqueness of the FlowMonID and how to allow disambiguation
   of the FlowMonID in case of collision.

   The following section highlights an important requirement for the
   application of the Alternate Marking to IPv6 and SRv6.  The concept
   of the controlled domain is explained and it is considered an
   essential precondition.

Fioccola, et al.         Expires 6 February 2023                [Page 3]
Internet-Draft                  SRv6 AMM                     August 2022

2.1.  Controlled Domain

   [RFC8799] introduces the concept of specific limited domain solutions
   and, in this regard, it is reported the Application of the Alternate
   Marking Method as an example.

   IPv6 has much more flexibility than IPv4 and innovative applications
   have been proposed, but for a number of reasons, such as the
   policies, options supported, the style of network management and
   security requirements, it is suggested to limit some of these
   applications to a controlled domain.  This is also the case of the
   Alternate Marking application to SRv6 as assumed hereinafter.

   Therefore, the application of the Alternate Marking Method to SRv6
   MUST NOT be deployed outside a controlled domain.  It is RECOMMENDED
   that an implementation can be able to reject packets that carry
   Alternate Marking data and are entering or leaving the controlled
   domains.

3.  Definition of the SRH AltMark TLV

   A new TLV carrying the data fields dedicated to the alternate marking
   method can be defined for the SRH extension headers.

   This enables the Alternate Marking Method to take advantage of the
   network programmability capability of SRv6 ([RFC8986]).
   Specifically, the ability for an SRv6 endpoint to determine whether
   to process or ignore some specific SRH TLVs is based on the SID
   function.  The nodes that are not capable of supporting the Alternate
   Marking functionality do not have to look or process the SRH AltMark
   TLV and can simply ignore it.  This also enables collection of
   Alternate Marking data only from the supporting segment endpoints.

3.1.  Data Fields Format

   The following figure shows the data fields format for enhanced
   alternate marking TLV.  This AltMark data is expected to be
   encapsulated as SRH TLV.

    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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   | SRH TLV Type  |  SRH TLV Len  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              FlowMonID                |L|D|     Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

Fioccola, et al.         Expires 6 February 2023                [Page 4]
Internet-Draft                  SRv6 AMM                     August 2022

   *  SRH TLV Type: 8 bit identifier of the type of Option/TLV that
      needs to be allocated.  Unrecognised Types MUST be ignored on
      receipt.

   *  SRH TLV Len: The length of the Data Fields of this TLV in bytes.

   *  FlowMonID: 20 bits unsigned integer.  The FlowMon identifier is
      described hereinafter.

   *  L: Loss flag as defined in [I-D.ietf-ippm-rfc8321bis] and
      [I-D.ietf-6man-ipv6-alt-mark];

   *  D: Delay flag as defined in [I-D.ietf-ippm-rfc8321bis] and
      [I-D.ietf-6man-ipv6-alt-mark];

   *  Reserved: is reserved for future use.  These bits MUST be set to
      zero on transmission and ignored on receipt.

   The Flow Monitoring Identification (FlowMonID) is required for some
   general reasons:

      First, it helps to reduce the per node configuration.  Otherwise,
      each node needs to configure an access-control list (ACL) for each
      of the monitored flows.  Moreover, using a flow identifier allows
      a flexible granularity for the flow definition.

      Second, it simplifies the counters handling.  Hardware processing
      of flow tuples (and ACL matching) is challenging and often incurs
      into performance issues, especially in tunnel interfaces.

      Third, it eases the data export encapsulation and correlation for
      the collectors.

   The FlowMon identifier field is to uniquely identify a monitored flow
   within the measurement domain.  The field is set at the source node.
   The FlowMonID can be uniformly assigned by the central controller or
   algorithmically generated by the source node.  The latter approach
   cannot guarantee the uniqueness of FlowMonID but it may be preferred
   for local or private network, where the conflict probability is small
   due to the large FlowMonID space.

   It is important to note that if the 20 bit FlowMonID is set
   independently and pseudo randomly there is a chance of collision.
   So, in some cases, FlowMonID could not be sufficient for uniqueness.

   This issue is more visible when the FlowMonID is pseudo randomly
   generated by the source node and there needs to tag it with
   additional flow information to allow disambiguation.  While, in case

Fioccola, et al.         Expires 6 February 2023                [Page 5]
Internet-Draft                  SRv6 AMM                     August 2022

   of a centralized controller, the controller should set FlowMonID by
   considering these aspects and instruct the nodes properly in order to
   guarantee its uniqueness.

4.  Use of the SRH AltMark TLV

   SRv6 leverages the Segment Routing header which consists of a new
   type of routing header.  Like any other use case of IPv6, Hop-by-Hop
   and Destination Options are useable when SRv6 header is present.
   Because SRv6 is a routing header, destination options before the
   routing header are processed by each destination in the route list.

   SRH TLV can also be used to encode the AltMark Data Fields for SRv6
   and to monitor every node along the SR path.  For SRv6, it may be
   preferred to use the SRH TLV, while for all the other cases with IPv6
   data plane the use of the Hop-by-Hop and Destination Option to carry
   AltMark data fields (as described in [I-D.ietf-6man-ipv6-alt-mark])
   is the best choice.

   It is to be noted that the SR nodes implementing the Alternate
   Marking functionality follows the MTU and other considerations
   outlined in [I-D.voyer-6man-extension-header-insertion].
   Furthermore, in a SRv6 network, the intermediated nodes that are not
   in the SID list do not consider the SRH, therefore they cannot
   support and dig into the SRH TLV.

   It is possible to summarize the procedure for AltMark data
   encapsulation in SRv6 SRH:

      * Ingress Node: As part of the SRH encapsulation, the ingress node
      of an SR domain or an SR Policy
      [I-D.ietf-spring-segment-routing-policy] MAY add the AltMark TLV
      in the SRH of the data packet, if it supports AltMark
      functionality and based on local configuration.

      * Intermediate SR Node: The intermediate SR node is any node
      receiving an IPv6 packet where the destination address of that
      packet is a local SID.  If an intermediate SR node is not capable
      of processing AltMark TLV, it simply ignores it.  While, if an
      intermediate SR node is capable of processing AltMark TLV, it
      checks if SRH AltMark TLV is present in the packet using
      procedures defined in [RFC8754] and process it.

      * Egress Node: The Egress node is the last node in the segment-
      list of the SRH.  The processing of AltMark TLV at the Egress node
      is similar to the processing of AltMark TLV at the Intermediate SR
      Nodes.

Fioccola, et al.         Expires 6 February 2023                [Page 6]
Internet-Draft                  SRv6 AMM                     August 2022

5.  Alternate Marking Method Operation

   [I-D.ietf-ippm-rfc8321bis], [I-D.ietf-ippm-rfc8889bis] describe the
   Alternate Marking Method in general.  While
   [I-D.ietf-6man-ipv6-alt-mark] describe in detail the application and
   the Operation of the methodology for IPv6.

6.  Security Considerations

   The security considerations of SRv6 are discussed in [RFC8754] and
   [RFC8986], and the security considerations of Alternate Marking in
   general and its application to IPv6 are discussed in
   [I-D.ietf-ippm-rfc8321bis] and [I-D.ietf-6man-ipv6-alt-mark].

   The Alternate Marking application to IPv6, defined in
   [I-D.ietf-6man-ipv6-alt-mark], analyzes different security concerns
   and related solutions.  These aspects are valid and applicable also
   to this document.  In particular the fundamental security requirement
   is that Alternate Marking MUST be applied in a specific limited
   domain, as also mentioned in [RFC8799].

   Alternate Marking is a feature applied to a trusted domain, where one
   or several operators decide on leveraging and configuring Alternate
   Marking according to their needs.  Additionally, operators need to
   properly secure the Alternate Marking domain to avoid malicious
   configuration and attacks, which could include injecting malicious
   packets into a domain.  So the implementation of Alternate Marking is
   applied within a controlled domain where the network nodes are
   locally administered.  A limited administrative domain provides the
   network administrator with the means to select, monitor and control
   the access to the network.

7.  IANA Considerations

   The SRH TLV Type should be assigned in IANA's Segment Routing Header
   TLVs Registry.

   This draft requests to allocate a SRH TLV Type for Alternate Marking
   TLV data fields under registry name "Segment Routing Header TLVs"
   requested by [RFC8754].

         SRH TLV Type   Description                 Reference
       -----------------------------------------------------------
         TBD            AltMark Data Fields TLV     This document

Fioccola, et al.         Expires 6 February 2023                [Page 7]
Internet-Draft                  SRv6 AMM                     August 2022

8.  Acknowledgements

   The authors would like to thank Haoyu Song for the precious comments
   and suggestions.

9.  References

9.1.  Normative References

   [I-D.ietf-ippm-rfc8321bis]
              Fioccola, G., Cociglio, M., Mirsky, G., Mizrahi, T., and
              T. Zhou, "Alternate-Marking Method", Work in Progress,
              Internet-Draft, draft-ietf-ippm-rfc8321bis-03, 25 July
              2022, <https://www.ietf.org/archive/id/draft-ietf-ippm-
              rfc8321bis-03.txt>.

   [I-D.ietf-ippm-rfc8889bis]
              Fioccola, G., Cociglio, M., Sapio, A., Sisto, R., and T.
              Zhou, "Multipoint Alternate-Marking Clustered Method",
              Work in Progress, Internet-Draft, draft-ietf-ippm-
              rfc8889bis-03, 25 July 2022,
              <https://www.ietf.org/archive/id/draft-ietf-ippm-
              rfc8889bis-03.txt>.

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

9.2.  Informative References

   [I-D.ietf-6man-ipv6-alt-mark]
              Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
              Pang, "IPv6 Application of the Alternate Marking Method",
              Work in Progress, Internet-Draft, draft-ietf-6man-ipv6-
              alt-mark-16, July 2022, <https://www.ietf.org/archive/id/
              draft-ietf-6man-ipv6-alt-mark-16.txt>.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", Work in
              Progress, Internet-Draft, draft-ietf-spring-segment-
              routing-policy-22, 22 March 2022,
              <https://www.ietf.org/archive/id/draft-ietf-spring-
              segment-routing-policy-22.txt>.

Fioccola, et al.         Expires 6 February 2023                [Page 8]
Internet-Draft                  SRv6 AMM                     August 2022

   [I-D.voyer-6man-extension-header-insertion]
              Voyer, D., Filsfils, C., Dukes, D., Matsushima, S., Leddy,
              J., Li, Z., and J. Guichard, "Deployments With Insertion
              of IPv6 Segment Routing Headers", Work in Progress,
              Internet-Draft, draft-voyer-6man-extension-header-
              insertion-10, 20 November 2020,
              <https://www.ietf.org/archive/id/draft-voyer-6man-
              extension-header-insertion-10.txt>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

Authors' Addresses

   Giuseppe Fioccola
   Huawei
   Riesstrasse, 25
   80992 Munich
   Germany
   Email: giuseppe.fioccola@huawei.com

   Tianran Zhou
   Huawei
   156 Beiqing Rd.
   Beijing
   100095
   China
   Email: zhoutianran@huawei.com

Fioccola, et al.         Expires 6 February 2023                [Page 9]
Internet-Draft                  SRv6 AMM                     August 2022

   Mauro Cociglio
   Telecom Italia
   Via Reiss Romoli, 274
   10148 Torino
   Italy
   Email: mauro.cociglio@telecomitalia.it

Fioccola, et al.         Expires 6 February 2023               [Page 10]