CATS Working Group J. Drake Internet Draft Juniper Networks Intended status: Standard L. Dunbar Expires: November 5, 2023 Futurewei L. Contrerasmurillo Telefonica M. Boucadair Orange May 5, 2023 Using SFC BGP Control Plane for CATS draft-ddcb-cats-sfc-bgp-applicability-00 Abstract This document describes an approach for using the SFC BGP Control Plane (RFC 9015) for CATS ingress routers to steer traffic based on a set of metrics that reflect the underlying network conditions and other service-specific metrics collected from available service locations. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt xxx, et al. Expires November 5, 2023 [Page 1] Internet-Draft SFC BGP Applicability to CATS The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 7, 2021. Copyright Notice Copyright (c) 2023 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 (http://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 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.............................................. 3 2. Conventions and Terminology............................... 3 3. Information about CATS Service to be Distributed by BGP... 4 4. SFC BGP for CATS.......................................... 4 4.1. Potential use of SFIR Pool for CATS.................. 6 4.2. Service Function Path Router (SFPR) in CATS.......... 6 5. C-SMA Metrics Distribution for Service Instance........... 6 5.1. Service Metrics Encoding in BGP...................... 6 5.2. Scope of Metrics Distribution........................ 6 6. C-PS Decision Process..................................... 6 7. Minimum Interval for Metrics Change Advertisement......... 8 8. Manageability Considerations.............................. 8 9. Security Considerations................................... 8 10. IANA Considerations...................................... 8 11. References............................................... 9 11.1. Normative References................................ 9 11.2. Informative References.............................. 9 12. Appendix A.............................................. 10 12.1. Example of Flow Affinity........................... 10 13. Acknowledgments......................................... 10 Dunbar, et al. Expires November 5, 2023 [Page 2] Internet-Draft SFC BGP Applicability to CATS 1. Introduction Service Function Chaining (SFC) is an architecture that is meant to master the path over which a set of service functions are invoked. The steered path can comply with a set of objectives for an optimal service path placement that will involve a set of Service Function Forwarders (SFFs), with each SFF having one or more service functions instances attached to. CATS is about finding an optimal service path for placing a service request, and thus about selecting one of the available service instances that better optimize a set of metrics. Considering the router to which the service instance is attached is an SFF, the SFC's BGP control plane [RFC9015] can be considered for CATS purposes. The document focuses on a single domain with Router Reflectors (RRs) controlling the propagation of the BGP UPDATE messages. The Service Metadata is only collected for the selective services with special QoS requirements. For example, a drone needs ultra-low latency service for its control traffic. Its periodic backup traffic can be forwarded by a best-effort path. Services with special QoS requirements are a small subset of all services initiated by endpoints. 2. Conventions and Terminology 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. This document uses the terms defined in [CATS-Framework] and [RFC7665]. C-SMA: CATS Service Metric Agent In addition, the document makes use of the following terms: Dunbar, et al. Expires November 5, 2023 [Page 3] Internet-Draft SFC BGP Applicability to CATS 3. Information about CATS Service to be Distributed by BGP The goal of the proposed BGP extension is to distribute the metrics collected by C-SMAs (CATS Service Metric Agents) to the CATS ingress routers to be used by the corresponding CATS Path Selectors. The ingress nodes will continue using the existing methods to collect network metrics. Therefore, this document doesn't discuss any potential extension that might be needed. The detailed metrics collected by a C-SMA will be decided by the CATS WG. And the encoding of the CATS metrics that will be selected by the WG will be discussed in IDR WG. When a CATS ingress router receives metrics updates for a Service ID from multiple CATS egress routers, all those egress routers are considered as the next hops for that Service ID. The Service ID is represented as an IPv4/IPv6 unicast address, which is assigned to a group of interfaces to which the service instances are attached. The CATS ingress router's BGP engine would call an Edge Service Management function that can select an optimal path to an egress CATS router based on the metrics received. The SFC Traffic Classifier (C-TC) function can be applied to assign incoming packets from clients to C-PS selected paths to the designated egress CATS router. In an environment where an end host roams among multiple CATS ingress routers, such as UE in 5G, or clients attached to multiple Wireless LAN (WLAN) access points, if different source IP addresses are used, path selection and traffic classifier don't need to consider flow affinity. If the end host maintains the same IP address when anchored to a new CATS ingress router, flow affinity should be considered by the Traffic Classifier. 4. SFC BGP for CATS The Service Function Instance Route (SFIR) specified in the SFC NLRI [RFC9015] can be used for CATS egress router to announce the Service Instance attached to the egress router. +---------------------------------------+ Dunbar, et al. Expires November 5, 2023 [Page 4] Internet-Draft SFC BGP Applicability to CATS | Route Type (2 octets) | +---------------------------------------+ | Length (2 octets) | +---------------------------------------+ | Route Type specific (variable) | +---------------------------------------+ Route Type = Service Function Instance Route (SFIR). [Editor's Note: Alternatively, a new Route Type (e.g., CATS Route Type) can be added to advertise CATS specific information. ] Since there is only one service Instance per service type for the path in CATS, there is no need for CATS routers to send BGP UPDATE message for Route Type = Service Function Path Route (SFPR). RFC9015 specifies the Service Function Instance Route (SFIR) as follows: +--------------------------------------------+ | Route Distinguisher (RD) (8 octets) | +--------------------------------------------+ | Service Function Type (2 octets) | +--------------------------------------------+ The Route Distinguisher (RD) is to distinguish different administrative domains (within the same provider's operational domain) where the service instances for the same Service ID are instantiated. For example, when an operator instantiates one service in multiple 5G Local Data Networks (LDN), instances from different LDN should have different Route Distinguisher. So that an ingress node' path selector can use the Route Distinguisher to apply differentiated weight (or cost) over different LDNs. The Service Function Type can represent if the Service Function is owned by the network operator (such as Firewall, Load Balancer, etc.,) or owned by its clients. Dunbar, et al. Expires November 5, 2023 [Page 5] Internet-Draft SFC BGP Applicability to CATS 4.1. Potential use of SFIR Pool for CATS When one service ID is instantiated in multiple administrative domains, the SFIPs within one instance within one administrative domain can be group together to one SFIR pool. Some services might need stickiness within one administrative domain when the client roam from one CATS ingress router to another within the administrative domain. The SFIR Pool can be used by the new CATS ingress router to select the SFI for traffic from the mobile client. 4.2. Service Function Path Router (SFPR) in CATS Since there is only one service function on the Service Function Path, there is no need for CATS router to advertise SFPR. 5. C-SMA Metrics Distribution for Service Instance 5.1. Service Metrics Encoding in BGP The Service Metrics for each service instance can be encoded as sub-TLVs to be carried by the Service Metadata Path Attribute [Edge-Service-Metadata] or CARTS specific NLRI (if specified) 5.2. Scope of Metrics Distribution BGP has a built-in mechanism [RFC4684] to dynamically achieve the constrained distribution of edge information. In a nutshell, a CATS PE sends RT Constraint (RTC) NLRI to the RR for the RR to install an outbound route filter. When the RR receives BGP UPDATE from other PEs, it propagates the received UPDATE message to the nodes that are in the Outbound Route filter for the specific VPN. For each CARTS Service ID, a corresponding filter group can be formed on RR to represent the interested ingress routers that are interested in receiving the corresponding Service CARTS metrics information. 6. C-PS Decision Process When an ingress router receives BGP updates for the same IP address from multiple egress routers, all those egress routers are considered as the next hops for the IP address. For the Dunbar, et al. Expires November 5, 2023 [Page 6] Internet-Draft SFC BGP Applicability to CATS selected services configured to be influenced by the CATS Service Metadata, the ingress router's BGP Decision process would trigger the Edge Service Management function to compute the weight to be applied to the route's next hop in the forwarding plane. The decision process is influenced by the Service Metadata associated with the client routes, in addition to the traditional BGP multipath computation algorithm, such as the Weight, Local preference, Origin, MED, etc., shown below: BGP ANYCAST Update +--------+ with Metadata +---------------+ | BGP |----------------->| EdgeServiceMgn| |Decision|< - - - - - - - - | | +---^-|--+ +-------|-------+ | | BGP ANYCAST | Update Anycast | | Route | Route Nexthops | | Multi-path NH install | with weight +---|-V--+ | | RIB | | +----+---+ | | | +---V------------------------------V-------+ | Forwarding Plane | | | +------------------------------------------+ Figure 6: Metadata Influenced Decision When any of those metadata value goes to 0, the effect is the same as the routes becoming ineligible via the egress router to which the service instance is attached. But when any of those metadata just degrade, there is possibility, even though smaller, for the egress router to continue as the optimal next hop. Suppose a destination address for aa08::4450 can be reached by three next hops (R1, R2, R3). Further, suppose the local BGP's Decision Process based on the traditional network layer policies & metrics identifies the R1 as the optimal next hop for this destination (aa08::4450). The Edge Service Metadata might result in R2 as the optimal next hop for the prefix and influence the Forwarding Plane. The Edge Service Metadata influencing next hop selection is different from the metric (or weight) to the next hop. The Dunbar, et al. Expires November 5, 2023 [Page 7] Internet-Draft SFC BGP Applicability to CATS metric to a next hop can impact many (sometimes, tens of thousands) routes that have the node as their next hop. while as the Edge Service Metadata only impact the optimal next hop selection for a subset of client routes that are identified as the edge services. When the BGP custom decision [idr-custom-decision] is used, the Edge Service Management function would have algorithm to combine the Edge Service Metadata attributes with the custom decision to derive the optimal next hop for the Edge service routes. Note: For a BGP UPDATE message that only includes the Edge Service Metadata Path Attribute without any NLRI, service metrics are applied to all the NLRIs with the Site-ID indicated in the Edge Service Metadata Path Attribute. 7. Minimum Interval for Metrics Change Advertisement As the metrics change can impact the path selection, the Minimum Interval for Metrics Change Advertisement is configured to control the update frequency to avoid route oscillations. Default is 30s. For 5G wireless or advanced WLAN applications, short term gathering of mobile clients, like conventions, can trigger significant load changes at some edge data centers. In those use cases, the load metrics change rate can be in the magnitude of hours or days. 8. Manageability Considerations The Edge Service Metadata described in this document are only intended for propagating between Ingress and egress routers of one single BGP domain. Only the selective services by clients are considered as CATS Services, which are managed by one operator, even though the routers can be by different vendors. 9. Security Considerations TBD. 10. IANA Considerations TBD. Dunbar, et al. Expires November 5, 2023 [Page 8] Internet-Draft SFC BGP Applicability to CATS 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4364] E. rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private networks (VPNs)", Feb 2006. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC7911] D. Walton, et al, "Advertisement of Multiple Paths in BGP", RFC7911, July 2016. 11.2. Informative References [3GPP TS 23.501] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS) [3GPP-EdgeComputing] 3GPP TR 23.748, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on enhancement of support for Edge Computing in 5G Core network (5GC)", Release 17 work in progress, Aug 2020. [5G-EC-Metrics] L. Dunbar, H. Song, J. Kaippallimalil, "IP Layer Metrics for 5G Edge Computing Service", draft- dunbar-ippm-5g-edge-compute-ip-layer-metrics-00, work-in-progress, Oct 2020. Dunbar, et al. Expires November 5, 2023 [Page 9] Internet-Draft SFC BGP Applicability to CATS [5G-Edge-Sticky] L. Dunbar, J. Kaippallimalil, "IPv6 Solution for 5G Edge Computing Sticky Service", draft-dunbar- 6man-5g-ec-sticky-service-00, work-in-progress, Oct 2020. [Edge-Service-Metadata] L. Dunbar, K. Majumdar, H. Wang, and G. Mishra, "BGP Usage for 5G Edge Service Metadata", draft-ietf-idr-5g-edge-service-metadata-01, work-in- progress, Feb. 2023. [IDR-CUSTOM-DECISION] A. Retana, R. White, "BGP Custom Decision Process", draft-ietf-idr-custom-decision- 08, Feb 2017. [SDWAN-EDGE-Discovery] L. Dunbar, S. Hares, R. Raszuk, K. Majumdar, "BGP UPDATE for SDWAN Edge Discovery", draft-ietf-idr-sdwan-edge-discovery-06, March 2023. 12. Appendix A 12.1. Example of Flow Affinity 13. Acknowledgments Acknowledgements to xxx for their review and contributions. This document was prepared using 2-Word-v2.0.template.dot. Dunbar, et al. Expires November 5, 2023 [Page 10] Internet-Draft SFC BGP Applicability to CATS Authors' Addresses John Drake Juniper Networks, Email: jdrake@juniper.net Linda Dunbar Futurewei Email: ldunbar@futurewei.com Luis Contrerasmurillo Telefonica luismiguel.contrerasmurillo@telefonica.com Mohamed Boucadair Orange mohamed.boucadair@orange.com Dunbar, et al. Expires November 5, 2023 [Page 11]