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

SPRING                                                        K. Ni, Ed.
Internet-Draft                                              China Mobile
Intended status: Standards Track                           H. Huang, Ed.
Expires: 25 April 2024                                            Huawei
                                                                Y. Zhang
                                                            China Mobile
                                                         23 October 2023

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

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 25 April 2024.

Copyright Notice

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

Ni, et al.                Expires 25 April 2024                 [Page 1]
Internet-Draft              SR hSFC Usecases                October 2023

   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 . . . . . . . . . . . . . . . . . .   3
   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  . . . . . . . . . . . . . . . . . . . .   5
       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
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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

   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,

Ni, et al.                Expires 25 April 2024                 [Page 2]
Internet-Draft              SR hSFC Usecases                October 2023

   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).  The resource pool, managed as an independent domain,
   requires directing user traffic into the security resource pool and
   performing orchestration within the pool, which is suitable for the
   hSFC architecture.  A security resource pool can select one or more
   resource pools based on the tenant's location, network topology, and
   resource usage to provide services to tenants. hSFC introduces a
   solution based on NSH (Network Service Header).  However, this
   approach involves network configurations and additional NSH header in
   packet headers.  In cases where SR (Segment Routing) networks are
   deployed, 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

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.

Ni, et al.                Expires 25 April 2024                 [Page 3]
Internet-Draft              SR hSFC Usecases                October 2023

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.  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.  This necessitates orchestrating service chains
   for the overall security resource pool and the internal security
   network devices.

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

   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.

Ni, et al.                Expires 25 April 2024                 [Page 4]
Internet-Draft              SR hSFC Usecases                October 2023

2.1.  Problem Statement

   This section provides an overview of the challenges that security
   resource pools face when attempting to deliver value-added security
   protection services for different uesrs.

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 differentiate
   between different tenants to provide them with distinct
   configuration.

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.

Ni, et al.                Expires 25 April 2024                 [Page 5]
Internet-Draft              SR hSFC Usecases                October 2023

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)

   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] Reliablity Of Service Function

Ni, et al.                Expires 25 April 2024                 [Page 6]
Internet-Draft              SR hSFC Usecases                October 2023

   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

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

Acknowledgements

Contributors

Authors' Addresses

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

Ni, et al.                Expires 25 April 2024                 [Page 7]
Internet-Draft              SR hSFC Usecases                October 2023

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

   Yige Zhang
   China Mobile
   Email: zhangyige@chinamobile.com

Ni, et al.                Expires 25 April 2024                 [Page 8]