IPv6 Address Assignment for SRv6
draft-liu-srv6ops-sid-address-assignment-00

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]