Internet DRAFT - draft-ddcb-cats-sfc-bgp-applicability
draft-ddcb-cats-sfc-bgp-applicability
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, <https://www.rfc-
editor.org/info/rfc8174>.
[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]
