Internet DRAFT - draft-watal-spring-srv6-sfc-sr-aware-functions

draft-watal-spring-srv6-sfc-sr-aware-functions







SPRING                                                        W. Mishima
Internet-Draft                                               Y. Fukagawa
Intended status: Informational                        NTT Communications
Expires: 5 September 2024                                   4 March 2024


             SRv6 SFC Architecture with SR-aware Functions
           draft-watal-spring-srv6-sfc-sr-aware-functions-00

Abstract

   This document describes the architecture of Segment Routing over IPv6
   (SRv6) Service Function Chaining (SFC) with SR-aware functions.  This
   architecture provides the following benefits:

   *  Comprehensive management: a centralized controller for SFC,
      handling SR Policy, link-state, and network metrics.

   *  Simplicity: no SFC proxies, so that reduces nodes and address
      resource consumption.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Source Packet Routing
   in Networking Working Group mailing list (spring@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/spring/.

   Source for this draft and an issue tracker can be found at
   https://https/github.com/watal.

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 5 September 2024.



Mishima & Fukagawa      Expires 5 September 2024                [Page 1]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


Copyright Notice

   Copyright (c) 2024 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 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terminology Defined in Related RFCs and
           Internet-Drafts . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Newly Defined Terminology . . . . . . . . . . . . . . . .   4
     2.3.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   3.  Design Objectives and Assumptions . . . . . . . . . . . . . .   4
     3.1.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Overview of Architecture  . . . . . . . . . . . . . . . . . .   6
   5.  Forwarding Plane  . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  End.AN-based Service Segment Provisioning . . . . . . . .   8
       5.1.1.  When a Network Function Goes Down . . . . . . . . . .   9
       5.1.2.  Anycast Segment . . . . . . . . . . . . . . . . . . .   9
       5.1.3.  Fast Reroute  . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Service Function Chains . . . . . . . . . . . . . . . . .   9
     5.3.  Per-Flow Encapsulation  . . . . . . . . . . . . . . . . .   9
   6.  Control Plane . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Service Function Controller . . . . . . . . . . . . . . .  11
     6.2.  Path Computation Element (PCE)  . . . . . . . . . . . . .  11
     6.3.  Classification Rule Controller  . . . . . . . . . . . . .  11
   7.  Management Plane  . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  13
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Segment Routing over IPv6 (SRv6) [RFC8986] enables packet steering
   through a set of instructions called a segment list.  Each SR segment
   endpoint node provides SRv6 Endpoint Behaviors, including Prefix/
   Adjacency segments, VPNs, and Binding Segments.




Mishima & Fukagawa      Expires 5 September 2024                [Page 2]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


   Service Function Chaining (SFC) [RFC7665] can be used in various
   scenarios (e.g.  FW, IPS, IDS, NAT, and DPI).  The SFC based on
   Segment Routing (SR) is defined in
   [I-D.draft-ietf-spring-sr-service-programming], which describes SFC
   proxies like End.AS/AD/AM are necessary to use SR-unaware functions.

   This document describes an architecture for SRv6 SFC with SR-aware
   functions, which provides comprehensive management of SRv6 network
   resources and services.

2.  Terminology

2.1.  Terminology Defined in Related RFCs and Internet-Drafts

   The following terms are used in this document as defined in the
   related RFCs and Internet-Drafts:

   *  SR, SR Domain, Segment ID (SID), SRv6, SR Policy, Prefix segment,
      Adjacency segment, Anycast segment, Active segment, and
      distributed/centralized/hybrid control plane defined in [RFC8402].

   *  SR source node, transit node, and SR segment endpoint node defined
      in [RFC8754].

   *  SRv6 SID function and SRv6 Endpoint behavior defined in [RFC8986].

   *  SFC, SFC proxy, and service classification function defined in
      [RFC7665].

   *  service segment, SR-aware service, SR-unaware Service, End.AS,
      End.AD and End.AM defined in
      [I-D.draft-ietf-spring-sr-service-programming].

   *  Headend, Color, and Endpoint defined in [RFC9256].

   *  Quality of Service (QoS), Service Level Agreement (SLA), and
      Service Level Objective (SLO) defined in [RFC9522].

   *  forwarding plane (FP), control plane (CP), management plane (MP),
      application plane (AP), northbound interface, southbound interface
      defined in [RFC7426].

   *  Path Computation Client (PCC), Path Computation Element (PCE), and
      Traffic Engineering Database (TED) defined in [RFC5440].

   *  BGP Flow Specification defined in [RFC8955]





Mishima & Fukagawa      Expires 5 September 2024                [Page 3]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


2.2.  Newly Defined Terminology

   The following terms are used in this document as defined below:

   *  SRv6 Service Function Node: an SR segment endpoint node that
      provides SR-aware functions as service segments.

   *  Classification Rule Controller: applies sets of SR policy and
      flows to SR Source Nodes.

   *  Service Function Controller: applies service segments to SRv6
      Service Function Nodes.

   *  SRv6 Controller: controls SRv6 services comprehensively,
      consisting of a Service Function Controller, a PCE, and a
      Classification Rule Controller.

   *  SRv6 Managers: manage SRv6 SFC infrastructure, consisting of a
      Virtualized Network Function (VNF) Manager, a Virtualized
      Infrastructure Manager (VIM), and a data collector of network
      metrics.

2.3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Design Objectives and Assumptions

   ## Goals/Objectives SRv6 SFC Architecture is designed with two main
   objectives:

   *  Comprehensive management: a centralized controller for SFC,
      handling SR Policy, link-state, and network metrics.  When
      providing SRv6 services, meeting SLAs for each customer is
      required.  These SLAs consist of one or more SLOs such as
      availability, latency, and bandwidth.  In an SRv6 SFC network,
      service segment provisioning, link-state collection, and SR policy
      calculation are required to meet SLOs, respectively.









Mishima & Fukagawa      Expires 5 September 2024                [Page 4]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


      [RFC8402] outlines a hybrid control plane that merges a
      distributed control plane and a centralized control plane.  In
      this hybrid control plane, forwarding information like Node/
      Adjacency SIDs are advertised mutually by distributed SR nodes via
      IGPs such as ISIS and OSPF, while other information like SR
      Policies and service segments are provided by a centralized
      controller.

      Software-Defined Networking (SDN) [RFC7426] provides centralized
      management of a network by a controller and a manager.
      Centralized management reduces operational costs through
      abstraction and automation.  The SDN framework allows users to
      manage an SR domain without considering the details of a
      forwarding plane like a topology and node state.  Operators can
      use a SRv6 controller to build SR policies for SFC and QoS, manage
      the state of network functions, issue service segments
      automatically, and specify disaster recovery with protection.

   *  Simplicity: no SFC proxies, so that reduces nodes and address
      resource consumption.  Network complexity increases operating
      costs.  Generally, using a variety of protocols in a network
      raises operational costs, including designing, building,
      monitoring, and troubleshooting.

      Using an SFC proxy may increase forwarding overhead due to
      additional header manipulations.

3.1.  Assumptions

   To achieve these objectives, this architecture is based on two main
   assumptions:

   *  Straightforward extension of the SRv6 Network Programming model

      The protocol used in this architecture is compatible with SRv6.
      This streamlines the operation of services like traffic steering,
      including SFC, redundancy, and local protection.  Standardized
      protocols such as BGP, PCEP, IS-IS, OSPF, TI-LFA, and Anycast SID
      are used in this architecture.

      This architecture is SRv6 compliant, enabling support for SR-
      unaware functions, although SR-aware functions are expected to
      meet the objective.

   *  SDN Framework compliance and comprehensive management of SRv6 SFC
      by controllers





Mishima & Fukagawa      Expires 5 September 2024                [Page 5]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


      A controller is used to provide comprehensive management.  To
      simplify building and operating, the controller uses standardized
      protocols and abstracted service interfaces.  This also provides
      programmability by controlling policies that meet a user's intent
      including SFC and quality of service (QoS).

4.  Overview of Architecture

   Figure 1 illustrates an overview of this architecture.

    +------------------------------------------------+
    |               Application Plane                |
    +------------------------|-----------------------+
                             | Control Plane Northbound Interface
    +--- SRv6 Controller ----v-----------------------+
    | +--------------+ +-------------+ +-----------+ | +-----------+
    | |Classification| |    Path     | | Service   | | |  Service  |
    | |     Rule     | | Computation | | Function  | | |  Funtion  |
    | |  Controller  | |Element (PCE)| |Controller | | |  Managers |
    | +------|-------+ +-^---------|-+ +-----|-----+ | +-----|-----+
    +--------|-----------|---------|---------|-------+   Management
             |           |         |         |             Plane
            Control Plane Southbound Interfaces          Southbound
             |           |         |         |           Interface
    +--------|-----------|---------|---------|---------------|-------+
    | +------v-----------|---------v-+ +-----v---------------v-----+ |
    | |     SRv6 SR Source Node /    | |       SRv6 Service        | |
    | |    Service Classification    |-|         Function          | |
    | |           Function           | |           Node            | |
    | +------------------------------+ +---------------------------+ |
    +--------------------------- SR domain --------------------------+

    Figure 1: Overview of SRv6 SFC Architecture with SR-aware Functions

   This architecture is based on SDN [RFC7426] separating the forwarding
   plane (FP), control plane (CP), management plane (MP), and
   application plane (AP).  Each plane has the following roles:

   *  Forwarding plane: classifies packets and encapsulates SRH,
      forwards them, and applies endpoint behavior.

      -  Provides SR-aware function using End.AN.

      -  Classify flow and apply them to TE application with PBR.

      -  Ensures redundancy with Anycast.

      -  Ensure local protection with Fast Reroute (FRR).



Mishima & Fukagawa      Expires 5 September 2024                [Page 6]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


   *  Control plane: makes decisions about packet forwarding and
      provides rules for a forwarding plane.

      -  Collects link-state including SRv6 locator, prefix, behavior,
         and delay.

      -  Calculates and provisioning SR Policies.

      -  Applies SR Policies to each flow by provisioning flow
         classification rules.

      -  Manages the provisioning of Service Segments to SR-aware
         functions.

   *  Management plane: monitors and maintenances of SRv6 devices and
      services

      -  Monitors and deploys network functions.

      -  Manages hypervisor resources.

      -  Collects metrics of devices, network functions, and SFC
         services.

   *  Application plane: provides APIs for users to use a control and
      management plane.

      -  Provide an interface to operators or customers.

      -  Applying intents defined in [RFC9315], including Operational,
         Rule, Service, and Flow intents.

   Each component communicates using standardized protocols.  These are
   designed to be loosely coupled and cooperate by using an abstraction
   layer.

   This document suggests handling a control plane by application plane,
   but a detailed design of an application plane is out of the scope of
   this document.  This is because application plane components and
   abstraction layers should be designed based on individual network
   utilization and operator intent.  In the following sections, details
   of a forwarding plane, control plane, and management plane are
   explained.








Mishima & Fukagawa      Expires 5 September 2024                [Page 7]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


5.  Forwarding Plane

   A forwarding plane is responsible for providing SFC through packet
   classification, SRv6 encapsulation, and forwarding.  In this
   architecture, all forwarding plane components are located within the
   SR domain.

    +----------------------------------------------------------------+
    | +--------------+             +--------+             +--------+ |
    | |   SRv6 SR    | SRv6 Packet |  SRv6  | SRv6 Packet |  SRv6  | |
    | | Source Node  |(S2,S1; SL:1)|Service |(S2,S1; SL:1)|Service | |
   -->|  / Service   |------------>|Function|------------>|Function|-->
    | |Classification|             |  Node  |             |  Node  | |
    | |   Function   |             |  (S1)  |             |  (S2)  | |
    | +--------------+             +--------+             +--------+ |
    +-------------------------- SR domain ---------------------------+

                         Figure 2: Forwarding Plane

   Figure 2 shows an example of SFC with two network functions.
   Firstly, the SRv6 SR source node classifies the flow and encapsulates
   it with an SRH containing the segment list <S1, S2>.  Next, the SRv6
   Service Function Node (S1) receives the packet and applies a network
   function associated with an End.AN S1.  Finally, the SRv6 Service
   Function Node (S2) receives the packet and also applies a network
   function associated End.AN S2, thus achieving SFC.

5.1.  End.AN-based Service Segment Provisioning

   End.AN provides an SR-aware function.

   Functions with the same role MAY be assigned as the same service
   segment within the SR domain.  By using Anycast-SIDs, multiple nodes
   can be grouped as part of the same service segment.

   End.AN MAY have optional arguments.  This can provide additional
   programmability by embedding network function instructions in the
   segment list.

   By using virtualized spaces within routers or on generic servers,
   network functions can be provided at any node in an SR domain.  This
   allows for scaling and flexible redundancy of network functions.









Mishima & Fukagawa      Expires 5 September 2024                [Page 8]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


5.1.1.  When a Network Function Goes Down

   If a network function experiences a failure, the associated route
   MUST be promptly removed.  In the case of Anycast configuration, it
   MUST be gracefully rerouted to other nodes.  Additionally, if no
   alternative nodes are available, consider either dropping the packet
   and sending an ICMP Destination Unreachable message or forwarding it
   as a pass-through.

5.1.2.  Anycast Segment

   The concept of the Anycast segment is introduced in [RFC8402].  In
   the SRv6 SFC, it realizes to provide the same network function
   segment as the same Anycast segment.  In such cases, the state
   between network functions MUST be shared mutually.

5.1.3.  Fast Reroute

   The ordering of network functions in an SRv6 SFC is guaranteed by the
   segment list, even if an FRR occurs, When an FRR occurs, if the
   Active segment is an Anycast SID, it MAY be forwarded to another SRv6
   Service Function Node.  In such a case, since state synchronization
   may not have been completed, the network function MUST have a
   mechanism to handle rerouted packets, such as buffering to wait for
   synchronization.

5.2.  Service Function Chains

   In this architecture, each SFC is represented as an SRv6 Policy
   [RFC9256].  The purpose or intent of each SRv6 Policy can be
   identified using attributes such as color or name.

   In general, SFC is achieved by using loose source routing.  If both
   SFC and QoS are desired, they can be achieved by using strict source
   routing or loose source routing with Flex-Algo SIDs.

5.3.  Per-Flow Encapsulation

   In the SRv6 SR source node, which serves as the Service Classifier,
   packets are classified on a per-flow basis using PBR and encapsulated
   with SRv6 Policy.  Therefore, the SRv6 SR source node MUST be capable
   of identifying packets using at least a 5-tuple or even more detailed
   information.

   In this architecture, aiming for comprehensive management, the
   service classifier has an API to communicate with the controller.





Mishima & Fukagawa      Expires 5 September 2024                [Page 9]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


6.  Control Plane

   A control plane is responsible for enabling comprehensive management
   of SRv6 SFC.  It enables SR-aware functions as service segments and
   specifies SR Policies including SFC for each flow.  A control plane
   has a Northbound API to receive user requests and a Southbound API to
   manipulate a forwarding plane.

    +---------------- SRv6 Controller ----------------+
    | +--------------+ +-------------+ +------------+ |
    | |Classification| |    Path     | |  Service   | |
    | |     Rule     | | Computation | |  Function  | |
    | |  Controller  | |Element (PCE)| | Controller | |
    | +------|-------+ +-^---------|-+ +------|-----+ |
    +--------|-----------|---------|----------|-------+
      Classification link-state SR Policy Enable/Disable
           Rule       (BGP-LS) (PCEP/BGP) a Service Segment
      (BGP Flowspec)     |         |     (End.AN SID:S1)
    +--------|-----------|---------|----------|----------------------+
    | +------v-----------|---------v-+ +------v--------------------+ |
    | |     SRv6 SR Source Node /    | |       SRv6 Service        | |
    | |    Service Classification    |-|         Function          | |
    | |           Function           | |           Node            | |
    | +------------------------------+ +---------------------------+ |
    +--------------------------- SR domain --------------------------+

                          Figure 3: Control Plane

   The SRv6 Controller consists of the following three components:

   *  Service Function Controller: provides an SID for a network service
      and manages this state.

   *  PCE: provides SR Policies that fulfill SFC/QoS requirements from
      the headend to the tailend and sends them to the SRv6 SR source
      node.

   *  Classification Rule Controller: provides an Encapsulation Policy
      that corresponds to a specific flow and SR Policy, and sends them
      to the SRv6 SR source node.











Mishima & Fukagawa      Expires 5 September 2024               [Page 10]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


6.1.  Service Function Controller

   Service Function Controller is responsible for enabling and disabling
   service segments of SRv6 Service Function Nodes.  To manage service
   segments, it utilizes the extensions provided in a BGP-LS service
   segment, as outlined in
   [I-D.draft-ietf-idr-bgp-ls-sr-service-segments] and TODO: draft-
   watal-idr-bgp-ls-sr-service-segments-enabler, and defines the
   following parameters:

   *  Behavior: End.AN

   *  SID: the SID of End.AN (in IPv6 Address format).  Service segments
      that support slicing are specified here as Flex-Algo SIDs.

   *  Function Name: type of network function

   *  Action: enable

   *  TLV:

      -  Specification of the Anycast Segment Group: when deploying
         multiple Network Functions within the same context, it MUST use
         the Anycast Group TLV to specify the same anycast segment group
         SID.

      -  Allows for the specification of unique parameters and context
         associated with a particular network function.

6.2.  Path Computation Element (PCE)

   PCE is a controller that provides SR Policy.  As an Active Stateful
   PCE, it establishes sessions with all PEs in an SR domain and manages
   SFCs.  SR Policies MUST support both explicit and dynamic paths.  For
   dynamic path, Constrained Shortest Path First (CSPF) considers not
   only SFC but also QoS.

   It acquires the Traffic Engineering Database (TED) of the SR domain
   using BGP-LS and deploys SR Policies via PCEP [RFC5440] or BGP SR
   Policy [I-D.draft-ietf-idr-segment-routing-te-policy].  The BGP-LS
   service segment is required to calculate dynamic paths based on the
   state of service segments and network functions.

6.3.  Classification Rule Controller

   A Classification Rule Controller determines flows to apply specific
   SFC.




Mishima & Fukagawa      Expires 5 September 2024               [Page 11]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


   The classification results are advertised to each SRv6 SR Source node
   as a set of flow, endpoints, and color with an extended protocol
   based on BGP Flowspec defined in
   [I-D.draft-ietf-idr-ts-flowspec-srv6-policy].

7.  Management Plane

   A management plane is responsible for configuring network function
   instances, monitoring resources, and collecting network metrics.  The
   details of each manager are outside the scope of this document, as
   the southbound interface of the management plane may be different for
   each service and hardware architecture.

    +----------------- SRv6 Manager ------------------+
    | +--------------+ +--------------+ +-----------+ |
    | | Virtualized  | |     VNF      | |  Network  | |
    | |Infrastructure| |   Manager    | |  Metric   | |
    | |   Manager    | |              | |  Manager  | |
    | +------^-------+ +------^-------+ +-----^-----+ |
    +--------|----------------|---------------|-------+
             |                |               |
           Management Plane Southbound Interfaces
             |                |               |
    +--------|----------------|---------------|-------+
    | +------|----------------v---------------|-----+ |
    | |                 SRv6 Service                | |
    | |                   Function                  | |
    | |                     Node                    | |
    | +---------------------------------------------+ |
    +------------------- SR domain -------------------+

                         Figure 4: Management Plane

   Figure 4 shows examples of managers that MAY be added to a management
   plane: * VNF Manager: handles deployment and scaling of network
   functions. * This manager considers redundancy and link utilization
   optimization.

   *  VIM: monitors hypervisor resources on SRv6 Service Function Node.

      -  In SRv6 SFC, a hypervisor managed by a VIM MAY be located in
         virtualized spaces within routers or on generic servers.

   *  Network Metrics Manager: collects metrics for SRv6 policy
      calculation and evaluation.






Mishima & Fukagawa      Expires 5 September 2024               [Page 12]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


      -  Metrics are collected from multiple data sources, including
         IPFIX, TCP statistics, and SRv6 path tracing
         [I-D.draft-filsfils-spring-path-tracing].

      -  Metrics can be used for PCE calculation parameters.

8.  Normative References

   [I-D.draft-filsfils-spring-path-tracing]
              Filsfils, C., Abdelsalam, A., Camarillo, P., Yufit, M.,
              Graf, T., Su, Y., Matsushima, S., Valentine, M., and
              Dhamija, "Path Tracing in SRv6 networks", Work in
              Progress, Internet-Draft, draft-filsfils-spring-path-
              tracing-05, 23 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-filsfils-
              spring-path-tracing-05>.

   [I-D.draft-ietf-idr-bgp-ls-sr-service-segments]
              Dawra, G., Filsfils, C., Talaulikar, K., Clad, F.,
              Bernier, D., Uttaro, J., Decraene, B., Elmalky, H., Xu,
              X., Guichard, J., and C. Li, "BGP-LS Advertisement of
              Segment Routing Service Segments", Work in Progress,
              Internet-Draft, draft-ietf-idr-bgp-ls-sr-service-segments-
              02, 5 November 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
              ls-sr-service-segments-02>.

   [I-D.draft-ietf-idr-segment-routing-te-policy]
              Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and
              D. Jain, "Advertising Segment Routing Policies in BGP",
              Work in Progress, Internet-Draft, draft-ietf-idr-segment-
              routing-te-policy-26, 23 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
              segment-routing-te-policy-26>.

   [I-D.draft-ietf-idr-ts-flowspec-srv6-policy]
              Wenying, J., Liu, Y., Zhuang, S., Mishra, G. S., and S.
              Chen, "Traffic Steering using BGP FlowSpec with SR
              Policy", Work in Progress, Internet-Draft, draft-ietf-idr-
              ts-flowspec-srv6-policy-03, 16 June 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-ts-
              flowspec-srv6-policy-03>.

   [I-D.draft-ietf-spring-sr-service-programming]
              Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
              Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
              S. Salsano, "Service Programming with Segment Routing",
              Work in Progress, Internet-Draft, draft-ietf-spring-sr-



Mishima & Fukagawa      Expires 5 September 2024               [Page 13]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


              service-programming-09, 20 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              sr-service-programming-09>.

   [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/rfc/rfc2119>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/rfc/rfc5440>.

   [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
              Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
              Defined Networking (SDN): Layers and Architecture
              Terminology", RFC 7426, DOI 10.17487/RFC7426, January
              2015, <https://www.rfc-editor.org/rfc/rfc7426>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/rfc/rfc7665>.

   [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/rfc/rfc8174>.

   [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/rfc/rfc8402>.

   [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/rfc/rfc8754>.

   [RFC8955]  Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
              Bacher, "Dissemination of Flow Specification Rules",
              RFC 8955, DOI 10.17487/RFC8955, December 2020,
              <https://www.rfc-editor.org/rfc/rfc8955>.








Mishima & Fukagawa      Expires 5 September 2024               [Page 14]

Internet-Draft      SRv6 SFC with SR-aware Functions          March 2024


   [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/rfc/rfc8986>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/rfc/rfc9256>.

   [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
              Tantsura, "Intent-Based Networking - Concepts and
              Definitions", RFC 9315, DOI 10.17487/RFC9315, October
              2022, <https://www.rfc-editor.org/rfc/rfc9315>.

   [RFC9522]  Farrel, A., Ed., "Overview and Principles of Internet
              Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
              January 2024, <https://www.rfc-editor.org/rfc/rfc9522>.

Acknowledgments

   The authors would like to acknowledge the review and inputs from
   Mitsuru Maruyama, Katsuhiro Sebayashi, Yuma Ito, and Taisei Tanabe.
   We partially obtained the research results from NICT's commissioned
   research No.  JPJ012368C03101.

Authors' Addresses

   Wataru Mishima
   NTT Communications
   Japan
   Email: w.mishima@ntt.com


   Yuta Fukagawa
   NTT Communications
   Japan
   Email: y.fukagawa@ntt.com












Mishima & Fukagawa      Expires 5 September 2024               [Page 15]