Network Working Group Y. Liu Internet-Draft China Mobile Intended status: Informational Y. Zhu Expires: 10 August 2024 China Telecom 7 February 2024 IPv6 Address Assignment for SRv6 draft-liu-srv6ops-sid-address-assignment-00 Abstract This document provides detailed SRv6 SID assignment considerations, which could be a comprehensive guide for optimizing SRv6 SID allocation in diverse deployment scenarios. 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/. 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 10 August 2024. Copyright Notice Copyright (c) 2024 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 Liu & Zhu Expires 10 August 2024 [Page 1]
Internet-Draft Abbreviated-Title February 2024 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 2. SRv6 SID Block Assignment . . . . . . . . . . . . . . . . . . 3 3. SRv6 SID Assignment for P2P and P2MP . . . . . . . . . . . . 4 4. SRv6 Node ID Assignment . . . . . . . . . . . . . . . . . . . 4 4.1. Node ID for SRv6 Compression . . . . . . . . . . . . . . 4 4.1.1. Assignment for REPLACE-C-SID . . . . . . . . . . . . 5 4.1.2. Assignment for NEXT-C-SID . . . . . . . . . . . . . . 5 5. SRv6 Function ID Assignment . . . . . . . . . . . . . . . . . 5 5.1. Function ID for SRv6 Compression . . . . . . . . . . . . 5 5.1.1. Function ID for REPLACE-C-SID . . . . . . . . . . . . 5 5.1.2. Function ID for NEXT-C-SID . . . . . . . . . . . . . 6 5.2. Dynamic and Static Assignment . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction [RFC8986](Section 3.2 "SID Allocation within an SR Domain") provides basic principle and practice for allocating SRv6 SIDs within SRv6 networks. These practices typically involve assigning large IPv6 prefixes to the SR domain and further subdividing them into smaller prefixes for individual nodes. This approach ensures efficient address utilization and simplifies network management. However, existing work primarily focuses on basic SRv6 deployments without considering the complexities introduced by advanced features like SRv6 compression and diverse service provider requirements. This document aims to bridge the gap by comprehensively detailing SRv6 SID assignment, which could provide service providers and network engineers with a comprehensive and practical guide for optimizing SRv6 SID allocation in diverse deployment scenarios. Liu & Zhu Expires 10 August 2024 [Page 2]
Internet-Draft Abbreviated-Title February 2024 2. SRv6 SID Block Assignment Prior to SRv6, service providers typically allocate IPv6 addresses based on "administrative divisions" (e.g., province, city) and "network types" (e.g.,IP network, wireless network, transport network). This approach assigns distinct unicast addresses (e.g., interface and loopback addresses) for network device. However, introducing SRv6 with independent allocations within each administrative division or network type creates challenges: 1) Fragmented SRv6 Space: Independent allocations result in scattered SRv6 address blocks across the provider's network, hindering SRv6 SID aggregation. Aggregation simplifies network management and allows efficient use of address space. 2) Edge Filtering Complexity: With fragmented SRv6 space, filtering SRv6 traffic at network edges becomes significantly more complex due to the dispersed nature of the addresses. This complicates network security and policy enforcement. To address these challenges, it's recommended to allocate a "dedicated IPv6 address block" for SRv6 across the entire service provider network. Example: Scenario 1: Integrated SRv6 SIDs Planning in 1 Service Operator Assume Block A:A:X:X::/24 is allocated for SRv6. It only requests to apply a single policy to this prefix in edge configuration, such as: deny A:A:X:X::/24 Scenario 2: Separate SIDs Planning in different administrative division Each administrative division has its own SRv6 block. It requires multiple policies for each discrete prefix in edge configuration, such as: deny A:B:X:X:C1:D:/48 deny A:B:Z:Z:C2:D:/48 ... Liu & Zhu Expires 10 August 2024 [Page 3]
Internet-Draft Abbreviated-Title February 2024 deny A:B:X:X:Cn:D:/48 Here, C1...Cn represent n administrative divisions, and D represents the SRv6 SIDs allocated to each division. The difference between A:A and A:B indicates whether ordinary IPv6 network addresses and SRv6 addresses are distinguished from the high- order address bits: A:A represents a separate SRv6 prefix, while A:B represents an ordinary IPv6 network address prefix. It is showed that integrated SRv6 SIDs planning simplifies edge configuration by requiring only a single policy for the dedicated SRv6 prefix. This approach improves network management efficiency and reduces configuration complexity. 3. SRv6 SID Assignment for P2P and P2MP Based on existing SR P2MP solutions, both SRv6 P2P and P2MP utilize unicast IPv6 addresses. While considering the distinction between the service of unicast and multicast, it may request separate address pools for SRv6 P2P and P2MP, for the following 2 aspects of considerations: 1) It's crucial to avoid allocating SRv6 SIDs for both P2P and P2MP connections under the same Node ID. This prevents address space contention and simplifies traffic management. 2) Independent Locator Advertisement for P2MP SIDs So, it is suggested to dedicate distinct SID ranges or Node IDs for P2P and P2MP traffic flows within a service provider's network to ensure clear differentiation. 4. SRv6 Node ID Assignment Node ID allocation could be flat or structured. Flat allocation requests less resources but needs complex management, which is caused by the structural nature of administrative division in geography. Node ID allocation could also be structured, enabling further administrative division refinement in SRv6 SIDs. 4.1. Node ID for SRv6 Compression Liu & Zhu Expires 10 August 2024 [Page 4]
Internet-Draft Abbreviated-Title February 2024 4.1.1. Assignment for REPLACE-C-SID If compressed and uncompressed Node IDs remain different: - Benefit: Independent function planning becomes possible. - Limitation: Separate Locator publication necessitates Node ID space wastage, which is not acceptable. SoIf compressed and uncompressed Node IDs should remain consistent: - Benefit: Only one Locator needs publication. - Limitation: Available space for uncompressed Node IDs reduces proportionately. It is necessary to mention that sharing the same Node ID for compressed and uncompressed functions inevitably leads to the joint occupation of the function space. This means that compressed and uncompressed functions must "share" this space, which can result in resource contention and limit the flexibility of function allocation. Additionally, using the same Node ID indirectly restricts the Node ID length for non-compressed SIDs, considering the Node ID length limitation for compressed SIDs. This can be a significant constraint for networks that require a large number of non-compressed SIDs. 4.1.2. Assignment for NEXT-C-SID TBD 5. SRv6 Function ID Assignment Function ID should have ennough space for different functionalities and services. 5.1. Function ID for SRv6 Compression 5.1.1. Function ID for REPLACE-C-SID It should also be considered about balancing the length of Node ID and Function ID for Compressed SIDs. It means that due to the inherent length limitations of compressed SIDs, a trade-off must be made between the scope of manageable nodes and the range of network functions that each node can provide. Liu & Zhu Expires 10 August 2024 [Page 5]
Internet-Draft Abbreviated-Title February 2024 Even considering only path-related network functions like End and End.X, a certain amount of Function IDs(for example: End.X and links are related, with multiple Flavors: the number of Function IDs should at least exceed the link number * Flavor number) are required. Additional functions such as VPN services will further occupy the address space. Therefore, when planning SRv6 SID allocation, it is crucial to carefully consider the application scenarios and functional requirements of compressed SIDs to find the optimal trade- off solution. 5.1.2. Function ID for NEXT-C-SID TBD 5.2. Dynamic and Static Assignment There could be 2 types of Allocation: 1) Dynamic: Automatic device allocation; For example: End. X and VPN SIDs. 2) Static assignment: Manual configuration for easy management; It is suitable for functions with small number of SIDs. For example: End . 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations TBD 8. Acknowledgements TBD 9. 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>. Liu & Zhu Expires 10 August 2024 [Page 6]
Internet-Draft Abbreviated-Title February 2024 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>. Authors' Addresses Yisong Liu China Mobile China Email: liuyisong@chinamobile.com Yongqing Zhu China Telecom China Email: zhuyq8@chinatelecom.cn Liu & Zhu Expires 10 August 2024 [Page 7]