Problem Statement, Use Cases, and Requirements of Hierarchical SFC with Segment Routing
draft-nh-sr-hsfc-usecases-requirements-01

SPRING                                                        K. Ni, Ed.
Internet-Draft                                              China Mobile
Intended status: Standards Track                           H. Huang, Ed.
Expires: 3 September 2024                                         Huawei
                                                                Y. Zhang
                                                              J. Ye, Ed.
                                                            China Mobile
                                                            2 March 2024

Problem Statement, Use Cases, and Requirements of Hierarchical SFC with
                            Segment Routing
               draft-nh-sr-hsfc-usecases-requirements-01

Abstract

   Hierarchical Service Function Chaining (hSFC) is a network service
   chaining method that utilizes a hierarchical structure to efficiently
   organize and manage service function chains, enhancing network
   performance and scalability.  This document primarily describes the
   use case of hSFC, which is the security resource pool.  It outlines
   the associated problem statement and requirements for the security
   resource pool.  The document aims to assist in identifying candidate
   solution architectures and solutions.

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

Copyright Notice

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

Ni, et al.              Expires 3 September 2024                [Page 1]
Internet-Draft              SR hSFC Usecases                  March 2024

   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
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   5
       2.1.1.  Dispersion Of Service Resources . . . . . . . . . . .   5
       2.1.2.  Multi-tenant  . . . . . . . . . . . . . . . . . . . .   5
       2.1.3.  Multi-vendor  . . . . . . . . . . . . . . . . . . . .   6
       2.1.4.  Dynamic Orchestration . . . . . . . . . . . . . . . .   6
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Service Function Chaining (SFC) [RFC7665] is a network service
   delivery and traffic processing technique that allows for the
   definition and execution of specific service chain routing policies,
   ensuring that data flows through a sequence of service functions in a
   predetermined order as it traverses the network.  As network scales
   have grown, such as the decentralization of service resources and the
   diversification of tenants and vendors, it is difficult to
   administrate such a large network.  A new network architecture known
   as Hierarchical Service Function Chaining (hSFC) [RFC8459] has
   emerged. hSFC enables an organization to decompose large-scale
   networks into multiple administrative domains.  This means that it
   can provide better network design, simplified control, and support
   for different functional groups within the network, thereby enhancing
   overall efficiency and management.

Ni, et al.              Expires 3 September 2024                [Page 2]
Internet-Draft              SR hSFC Usecases                  March 2024

   To enhance network service security and offer a wide range of
   protective services to users, network operators have centrally
   constructed numerous security resource pools.  Within these pools,
   various security network devices, such as firewalls, Web Application
   Firewalls (WAFs), Intrusion Prevention Systems (IPS), and more, are
   deployed to deliver diverse value-added services (i.e Service
   Function).  According to tenants' business requirements or their
   geographical location the user traffic is steered into the
   corresponding security resource pool, after arriving which a series
   of services in a certain order are provided based on security
   protection needs, network topology, and resource usage.  The packets
   need to continue the remaining original forwardness when finishing
   the processes inside the resource pool.  As per [RFC8459], the
   original path information before entering security resource pool is
   expected to be stored somewhere, within the packets or in the gateway
   of resource pools, so that it can be restored later.  Therefore, it
   is suitable to orchestrate with hSFC architecture. hSFC introduces a
   solution based on NSH (Network Service Header).  This approach
   involves network configurations of each type of traffic and
   additional NSH header in packet headers, which is complicated and not
   conducive to expansive.  However, in cases where SR (Segment Routing)
   networks are deployed, it only needs to issue the SR policy to define
   transmission path and update a new one to alter the path when
   physical topology or business requirements change.  By contrast, the
   NSH solution may not be the preferred choice.

   This document describes a use case involving the deployment of
   multiple resource pools by network service provider.  Every resource
   pool is designed to offer tenants a wide range of security protection
   services.  The document also analyzes the challenges and issues
   associated with this use case, discussing the requirements, seeking
   an SR-based hSFC solution.

1.1.  Terminology

   hSFC: Hierarchical Service Function Chaining

   NSH: Network Service Header

   PBR: Policy Based Routing

   SR: Segment Routing

   SFC: Service Function Chaining

Ni, et al.              Expires 3 September 2024                [Page 3]
Internet-Draft              SR hSFC Usecases                  March 2024

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

2.  Use Cases

   To defend against network attacks, ensure the security of enterprise
   tenants' business applications against viruses, malware, and other
   security threats, and meet their customized security protection
   needs, network operators have established security resource pools in
   multiple regions.  Typically, these security resource pools host
   various security network devices, including firewalls, Web
   Application Firewalls (WAF), Intrusion Prevention Systems (IPS), and
   more, to provide a variety of security-focused value-added services.
   In practical applications, the first step involves routing user
   traffic to the appropriate security resource pool based on user
   location, which typically utilizing SR in the existing Internet
   environment.  Then, customized security protection services are
   provided to customers according to their specific requirements.  For
   example, some tenants may require the use of a firewall followed by
   IPS services, while others may need to use IPS first and then utilize
   firewall services.  After traversing through all SFs in a SFC,
   packets are returned to the gateway (i.e., security resource pool)
   and continue to be forwarded to devices outside of IDC.  This
   necessitates hierarchical service chains to orchestrate SFs within
   security resource pool (lower-level sub-domain)and service nodes
   outside the IDC (upper-level domain) respectively and independently.

   SR is a novel network orchestration technology that guides packet
   paths by adding Segment Identifiers (Segment Routing) in the packet
   header.  Each Segment Identifier corresponds to a node or service
   function within the network, creating an ordered path from source to
   destination, defining the packet's transmission route.  SR service
   chain orchestration offers several advantages, including the
   flexibility to define and customize service chain paths based on
   specific application and business requirements, support for dynamic
   adjustment of service chain paths based on real-time application
   needs, and the ability to guide packets directly to the desired
   service functions, reducing unnecessary delays within the service
   chain.  Furthermore, SR enables network administrators to manage
   service chains without altering the underlying network topology,
   simplifying network configuration.

Ni, et al.              Expires 3 September 2024                [Page 4]
Internet-Draft              SR hSFC Usecases                  March 2024

   As a result, SR represents a user-friendly service chain
   orchestration method suitable for complex network environments that
   need to meet diverse application requirements.  Given the complexity
   of internet architecture, the widespread deployment of SR, and the
   dynamic updates of security devices within a security resource pool,
   it is recommended to use SR-based service chaining for traffic
   steering within the security resource pool.  This enables dynamic
   adjustment of service chains and reduces traffic bypass.

2.1.  Problem Statement

   Due to the growth of network scales and the constraints of the
   existing orchestration method, security resource pools is facing some
   challenges of delivering value-added security protection services for
   different users.  This section provides an overview of these
   challenges.

2.1.1.  Dispersion Of Service Resources

   Due to varying geographical locations of different tenants and for
   the purpose of minimizing latency, facilitating network management,
   and maintenance, the security resource pool is physically deployed in
   a distributed manner.

2.1.2.  Multi-tenant

   In the existing Internet environment, tenants' network service
   requirements have become diverse, with different tenants facing
   various threats and demands.  In the security resource pool, On one
   hand, some tenants may only require basic access control
   functionality, in which case, tenants would only need firewall
   services.  On the other hand, other tenants may necessitate more
   complex and comprehensive security services.  For instance, certain
   tenants may require initial use of Web Application Firewall services
   to isolate potential malicious websites and code, followed by
   additional security checks using firewall services.  Different
   tenants have different needs, and the security resource pool needs to
   provide tenant-level customized security protection capabilities.
   Additionally, the network security device needs to be differentiated
   between different tenants to provide them with distinct
   configuration.

Ni, et al.              Expires 3 September 2024                [Page 5]
Internet-Draft              SR hSFC Usecases                  March 2024

2.1.3.  Multi-vendor

   In a security resource pool, security network devices are usually
   provided by different vendors, they need to be orchestrated by
   unified external network communication.  For example, in the security
   resource pool, firewalls are provided by Vendor A, and WAF is
   provided by Vendor B.  If a customer subscribes to both firewall and
   WAF security value-added services, the traffic needs to pass through
   Vendor A's firewall first and then through Vendor B's WAF device.
   This implies that Vendor A's firewall needs to be aware of the next
   hop being Vendor B's WAF device, and there is an expectation for the
   traffic to flow directly from Vendor A's firewall device to Vendor
   B's WAF.

2.1.4.  Dynamic Orchestration

   In a security resource pool, security network devices may encounter
   dynamic adjustments.  For example, adding new security network
   devices to the pool may require existing service chains, such as NSH,
   to undergo state updates across multiple devices.  The main issue in
   this situation is the presence of state (SPI, SI index tables) within
   the network devices.  Therefore, when there are changes in business
   deployments, all network devices need to undergo state updates.  This
   is unfavorable for flexible and agile deployments.  In contrast, SR
   is friendly as it does not require the presence of specific states in
   the network.

3.  Requirements

   [REQ-1] Tenant-level Service Orchestration

   Different tenants have varying security protection needs.
   specifically, the types and order of security protection they require
   are differently.  Therefore, it is imperative to cater to multiple
   tenants and support tenant-level service chain orchestration.

   [REQ-2] Tenant Information Carriage

   As the security resource pool needs to meet service chaining at the
   tenant level, it is essential for the packets to support carrying
   tenant information.

   [REQ-3] Dynamic Allocation Of Service Resources (Scalability)

Ni, et al.              Expires 3 September 2024                [Page 6]
Internet-Draft              SR hSFC Usecases                  March 2024

   The security resource pool is in a constant state of dynamic
   adjustment, and with the evolution of business needs, there may be
   additions or removals of certain security network devices.  When
   there are updates to the security network devices within the resource
   pool, it is essential to support their dynamic orchestration into the
   service chain.

   [REQ-4] Independent Resource Pool Orchestration

   Service functions in different security resource pools support
   different protocols (i.e., some security network devices within
   certain resource pools do not support SR), and their suitable methods
   for service chaining may also vary.  Achieving unified orchestration
   is challenging.  Therefore, it is necessary for security resource
   pools to support independent orchestration, without interfering with
   each other.

   [REQ-5] Reliability Of Service Function

   During service chain orchestration, it is necessary to support the
   retrieval of device information, including device operational status,
   identification details, etc.  In the event of network equipment
   issues, bypassing the problematic equipment to avoid traffic
   disruption should be enabled.

4.  Security Considerations

   TBD.

5.  IANA Considerations

   This document has no IANA actions.

6.  References

6.1.  Normative References

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

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

6.2.  Informative References

Ni, et al.              Expires 3 September 2024                [Page 7]
Internet-Draft              SR hSFC Usecases                  March 2024

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

   [RFC8459]  Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
              "Hierarchical Service Function Chaining (hSFC)", RFC 8459,
              DOI 10.17487/RFC8459, September 2018,
              <https://www.rfc-editor.org/rfc/rfc8459>.

Acknowledgments

Contributors

Authors' Addresses

   Kangkang Ni (editor)
   China Mobile
   Email: nikangkang@chinamobile.com

   Hongyi Huang (editor)
   Huawei
   Email: hongyi.huang@huawei.com

   Yige Zhang
   China Mobile
   Email: zhangyige@chinamobile.com

   Jiaming Ye (editor)
   China Mobile
   Email: yejiaming@chinamobile.com

Ni, et al.              Expires 3 September 2024                [Page 8]