SPRING Working Group J. Dong Internet-Draft Huawei Technologies Intended status: Standards Track S. Bryant Expires: July 22, 2021 Futurewei Technologies T. Miyasaka KDDI Corporation Y. Zhu China Telecom F. Qin Z. Li China Mobile F. Clad Cisco Systems January 18, 2021 Introducing Resource Awareness to SR Segments draft-ietf-spring-resource-aware-segments-01 Abstract This document describes the mechanism to associate network resource attributes to Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs in this document. The resource- aware SIDs retain their original forwarding semantics, but with the additional semantics to identify the set of network resources available for the packet processing action. The resource-aware SIDs can therefore be used to build SR paths or virtual networks with a set of reserved network resources. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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/. Dong, et al. Expires July 22, 2021 [Page 1]
Internet-Draft Resource-Aware SR Segments January 2021 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 July 22, 2021. Copyright Notice Copyright (c) 2021 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Segments with Resource Awareness . . . . . . . . . . . . . . 3 2.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Control Plane Considerations . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets through an ordered list of segments. A segment is referred to by its Segment Identifier (SID). With SR, explicit source routing can be achieved without introducing per-path state into the network. Compared with RSVP-TE [RFC3209], currently SR does not have the capability of reserving network resources or identifying a set of network resources reserved for individual services or customers. Although a centralized controller can have a global view of network Dong, et al. Expires July 22, 2021 [Page 2]
Internet-Draft Resource-Aware SR Segments January 2021 state and can provision different services using different SR paths, in data packet forwarding it still relies on traditional DiffServ QoS mechanism [RFC2474] [RFC2475] to provide coarse-grained traffic differentiation in the network. While such kind of mechanism may be sufficient for some types of services, some customers or services may require a set of dedicated network resources to be allocated in the network to achieve resource isolation from other customers/services in the same network. Also note the number of such customers or services can be larger than the number of traffic classes available with DiffServ QoS. This document extends the SR paradigm without the need of defining new SID types by associating SIDs with network resource attributes. These resource-aware SIDs retain their original functionality, with the additional semantics of identifying the set of network resources available for the packet processing action. One typical type of the network resource is bandwidth, but it is also possible to associate SR SIDs with other types of resources (e.g., processing or storage resources). On a particular network segment, multiple resource-aware SIDs can be allocated, each of which represents a subset of network resources allocated in the network to meet the requirement of individual customers or services. The allocation of network resources on network segments can be done either via local configuration or via a centralized controller. Other approaches are possible such as use of a control protocol signaling, but they are for further study. Each set of network resources can be associated with one or multiple resource-aware SIDs. These resource-aware SIDs can be used to build SR paths with a set of reserved network resources, which can be used to carry service traffic which requires dedicated network resources. The resource-aware SIDs can also be used to build SR based virtual networks with the required network topology and resource attributes. The proposed mechanism is applicable to SR with both MPLS data plane (SR-MPLS) and IPv6 data plane (SRv6). 2. Segments with Resource Awareness In segment routing architecture [RFC8402], several types of segments are defined to represent either topological or service instructions. A topological segment can be a node segment or an adjacency segment. A service segment may be associated with specific service functions for service chaining purpose. This document introduces additional resource semantics to these existing types of SIDs, so that the SIDs can be used to identify the topology or service functions, and also the set of network resources allocated on the network segments for packet processing. Dong, et al. Expires July 22, 2021 [Page 3]
Internet-Draft Resource-Aware SR Segments January 2021 This section describes the mechanisms of using SR SIDs to identify the additional resource information associated with SR paths or virtual networks based on the two SR data plane instantiations: SR- MPLS and SRv6. The mechanisms to identify the forwarding path or network topology with SIDs as defined in [RFC8402] can be reused, and the control plane can be based on [RFC4915], [RFC5120] and [I-D.ietf-lsr-flex-algo]. 2.1. SR-MPLS As specified in [RFC8402], an IGP Adjacency Segment (Adj-SID) is an SR segment attached to a unidirectional adjacency or a set of unidirectional adjacencies. An IGP Prefix Segment (Prefix-SID) is an SR segment attached to an IGP prefix, which identifies an instruction to forward the packet along the path computed using the routing algorithm in the associated topology. An IGP node segment is an IGP- Prefix segment that identifies a specific router (e.g., a loopback). As described in [I-D.ietf-spring-segment-routing-central-epe] and [I-D.ietf-idr-bgpls-segment-routing-epe], BGP PeerAdj SID is used as an instruction to steer over a local interface towards a specific peer node in a peering Autonomous System (AS). These types of SIDs can be extended to represent both topological instructions and the set of network resources allocated for packet processing following the instruction. The MPLS instantiation of Segment Routing is specified in [RFC8660]. For one IGP link, multiple resource-aware Adj-SIDs SHOULD be allocated, each of which is associated with a subset of the link resources allocated on the link, e.g. the link bandwidth. For one inter-domain link, multiple BGP PeerAdj SIDs SHOULD be allocated, each of which is associated with a subset of the link resources allocated on the inter-domain link. The resource-aware Adj-SIDs MAY be associated with a specific network topology and/or algorithm, so that it is used only for resource-aware SR paths computed within the topology and/or algorithm. Note that this per-segment resource allocation complies to the SR paradigm, which avoids introducing per- path state into the network. Several approaches can be used to partition the link resource, such as [FLEXE], Layer-2 logical sub- interfaces, dedicated queues, etc. The detailed mechanism of link resource partitioning is out of scope of this document. For one IGP prefix, multiple resource-aware prefix-SIDs SHOULD be allocated. A resource-aware prefix SID is associated with a network topology and/or algorithm in which the attached node participates, and in addition, each resource-aware prefix-SID is associated with a set of local resources (e.g. bandwidth, processing and storage resources) on each node participating in the same topology and/or algorithm. Such set of network resources are used for forwarding the Dong, et al. Expires July 22, 2021 [Page 4]
Internet-Draft Resource-Aware SR Segments January 2021 packets with this resource-aware prefix-SID, along the path computed with the associated topology and/or algorithm. Although each resource-aware prefix-SID can be associated with a set of dedicated resources, this implies additional overhead with per- prefix resource reservation in both control plane signaling and data plane states, and it is likely some resources will be wasted with per-prefix resource allocation along all the possible paths. Thus it is RECOMMENDED that a group of resource-aware prefix-SIDs be associated with an aggregated set of network resources in the network. This helps to reduce the dynamics in resource allocation, so that the resource can be allocated based on network planning and does not have to rely on dynamic signaling. For one IGP prefix, each resource-aware prefix-SID can be associated with a unique <topology, algorithm> tuple, in this case different <topology, algorithm> tuples can be used to distinguish the resource- aware prefix-SIDs for the same prefix. In another case, for one IGP prefix, multiple resource-aware prefix-SIDs can be associated with the same <topology, algorithm> tuple, then an additional distinguisher needs to be introduced to distinguish different resource-aware prefix-SIDs associated with the same topology and algorithm but different groups of network resources. More details about the new distinguisher will be described in a future version. A group of resource-aware SR-MPLS SIDs can be used to construct SID lists to steer the traffic along the explicit paths (either strict or loose) and be processed using the set of network resources identified by the SIDs. In data packet forwarding, each resource-aware Adj-SID identifies both the next-hop and the set of resources used for packet processing on the outgoing interface. Each resource-aware Prefix-SID identifies a path to the node which the prefix is attached to, and the set of network resources used for packet forwarding on network nodes along the path. The transit nodes determine the next-hop of the packet and the set of associated local resources based on the resource-aware prefix-SID, then forward the packet to the next-hop using the set of local resources. When the set of network resources allocated on the egress node also needs to be determined, It is RECOMMENDED that Penultimate Hop Popping (PHP) [RFC3031] be disabled, or the inner service label is used to infer the set of resources to be used for packet processing on the egress node of the SR path. This mechanism requires to allocate additional prefix-SIDs or adj- SIDs for network segments to identify different set of network Dong, et al. Expires July 22, 2021 [Page 5]
Internet-Draft Resource-Aware SR Segments January 2021 resources. As the number of resource groups increases, the number of SIDs would increase accordingly, while it should be noted that there is no per-path state introduced into the network. 2.2. SRv6 As specified in [I-D.ietf-spring-srv6-network-programming], an SRv6 Segment Identifier (SID) is a 128-bit value which consists of a locator (LOC) and a function (FUNCT), optionally it may also contain additional arguments (ARG) immediately after the FUNCT. The Locator part of the SID is routable and leads to the node which instantiates that SID, which means the Locator can be parsed by all nodes in the network. The FUNCT part of the SID is an opaque identification of a local function bound to the SID, and the ARG bits of the SID can be used to encode additional information for the processing of the behavoir bound to the SID. The FUNCT and ARG parts can only be parsed by the node which instantiates the SRv6 SID. For one SRv6 node, multiple resource-aware SRv6 LOCs SHOULD be allocated. A resource-aware LOC is associated with a network topology and/or algorithm in which the node participates, and in addition, a resource-aware LOC is associated with a set of local resources (e.g. bandwidth, processing and storage resources) on each node participating in the same topology and/or algorithm. Such set of network resources are used to forward the packets with SIDs which has the resource-aware LOC as its prefix, along the path computed with the associated topology and/or algorithm. Similar to the resource-aware prefix-SIDs in SR-MPLS, the network resources used for the forwarding instruction of a group of LOCs can be aggregated, this helps to reduce the dynamics of resource allocation, so that the resource can be allocated based on network planning and does not have to rely on dynamic signaling. For one IGP link, the resource-aware SRv6 End.X SIDs are used to identify different set of link resources allocated. Each resource- aware End.X SID SHOULD use a resource-aware LOC as its prefix. SRv6 SIDs for other types of functions MAY also be assigned as resource- aware SIDs, which can identify the set of network resources allocated by the node for executing the function. A group of resource-aware SRv6 SIDs can be used to construct SID lists to steer the traffic along the explicit paths (either strict or loose) and be processed using the set of network resources identified by the SRv6 SIDs and Locators. In data packet forwarding, each resource-aware End.X SID identifies both the next-hop and the set of resources used for packet processing on the outgoing interface. Each resource-aware Locator identifies Dong, et al. Expires July 22, 2021 [Page 6]
Internet-Draft Resource-Aware SR Segments January 2021 the path to the node which the LOC is assigned to, and the set of network resources used for packet forwarding on network nodes along the path. The transit nodes determine the next-hop of the packet and the set of associated local resources based on the resource-aware Locator, then forward the packet to the next-hop using the set of local resources. This mechanism requires to allocate additional SRv6 Locators and SIDs for network segments to identify different set of network resources. As the number of resource groups increases, the number of SRv6 Locators and SIDs would increase accordingly, while it should be noted that there is no per-path state introduced into the network. 3. Control Plane Considerations The mechanism described in this document makes use of a centralized controller to collect the information about the network (configuration, state, routing databases, etc.) as well as the service information (traffic matrix, performance statistics, etc.) for the planning of network resources based on service requirement. Then the centralized controller instructs network nodes to allocate the network resources and associate the resources with resource-aware SIDs. The resource-aware SIDs can be either explicitly provisioned by the controller, or dynamically allocated by network nodes then reported to the controller. The controller is also responsible for the centralized computation and optimization of the SR paths with the topology, algorithm and network resource constraints. The interaction between the controller and the network nodes can be based on PCEP [RFC5440], Netconf/YANG [RFC6241] [RFC7950] and BGP-LS [RFC7752]. In some scenarios, extensions to some of these protocols is needed, which are out of the scope of this document and will be specified in separate documents. In some cases, a centralized controller may not be used, but this would complicate the operations and planning therefore not suggested. The distributed control plane is complementary to the centralized controller. A distributed control plane can be used for the collection and distribution of the network topology and resource information associated with SIDs among network nodes, then some of the nodes can distribute the collected information to the centralized controller. Distributed route computation for services with topology and resource constraints may also be needed. The distributed control plane may be based on [RFC4915], [RFC5120], [I-D.ietf-lsr-flex-algo] or the combination of some of them with necessary extensions. The details are out of the scope of this document. Dong, et al. Expires July 22, 2021 [Page 7]
Internet-Draft Resource-Aware SR Segments January 2021 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations The security considerations of segment routing are applicable to this document. The Resource-aware SIDs may be used for provisioning of SR paths or virtual networks to carry traffic with latency as one of the SLA parameters. By disrupting the latency of such traffic an attack can be directly targeted at the customer application, or can be targeted at the network operator by causing them to violate their SLA, triggering commercial consequences. Dynamic attacks of this sort are not something that networks have traditionally guarded against, and networking techniques need to be developed to defend against this type of attack. By rigorously policing ingress traffic and carefully provisioning the resources provided to such services, this type of attack can be prevented. However care needs to be taken when providing shared resources, and when the network needs to be reconfigured as part of ongoing maintenance or in response to a failure. The details of the underlay network MUST NOT be exposed to third parties, to prevent attacks aimed at exploiting a shared resource. 6. Contributors Zhenbin Li Email: lizhenbin@huawei.com Zhibo Hu Email: huzhibo@huawei.com 7. Acknowledgements The authors would like to thank Mach Chen, Stefano Previdi, Charlie Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein and Joel Halpern for the valuable discussion and suggestions to this document. Dong, et al. Expires July 22, 2021 [Page 8]
Internet-Draft Resource-Aware SR Segments January 2021 8. References 8.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/info/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/info/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/info/rfc8402>. [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>. 8.2. Informative References [FLEXE] "Flex Ethernet Implementation Agreement", March 2016, <http://www.oiforum.com/wp-content/uploads/OIF-FLEXE- 01.0.pdf>. [I-D.ietf-idr-bgpls-segment-routing-epe] Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, S., and J. Dong, "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", draft-ietf-idr-bgpls- segment-routing-epe-19 (work in progress), May 2019. [I-D.ietf-lsr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- algo-13 (work in progress), October 2020. [I-D.ietf-spring-segment-routing-central-epe] Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", draft-ietf-spring-segment-routing-central- epe-10 (work in progress), December 2017. Dong, et al. Expires July 22, 2021 [Page 9]
Internet-Draft Resource-Aware SR Segments January 2021 [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", draft- ietf-spring-segment-routing-policy-09 (work in progress), November 2020. [I-D.ietf-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "SRv6 Network Programming", draft-ietf-spring-srv6-network-programming-28 (work in progress), December 2020. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <https://www.rfc-editor.org/info/rfc4915>. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>. Dong, et al. Expires July 22, 2021 [Page 10]
Internet-Draft Resource-Aware SR Segments January 2021 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>. [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of Scaling Issues in MPLS-TE Core Networks", RFC 5439, DOI 10.17487/RFC5439, February 2009, <https://www.rfc-editor.org/info/rfc5439>. [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/info/rfc5440>. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>. [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>. [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>. [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>. [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, <https://www.rfc-editor.org/info/rfc7810>. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. Dong, et al. Expires July 22, 2021 [Page 11]
Internet-Draft Resource-Aware SR Segments January 2021 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, <https://www.rfc-editor.org/info/rfc8571>. Authors' Addresses Jie Dong Huawei Technologies Email: jie.dong@huawei.com Stewart Bryant Futurewei Technologies Email: stewart.bryant@gmail.com Takuya Miyasaka KDDI Corporation Email: ta-miyasaka@kddi.com Yongqing Zhu China Telecom Email: zhuyq8@chinatelecom.cn Fengwei Qin China Mobile Email: qinfengwei@chinamobile.com Zhenqiang Li China Mobile Email: li_zhenqiang@hotmail.com Francois Clad Cisco Systems Email: fclad@cisco.com Dong, et al. Expires July 22, 2021 [Page 12]