Internet-Draft | Abbreviated-Title | March 2024 |
Liu, et al. | Expires 21 September 2024 | [Page] |
This document aims to provide a concise overview of the common problems encountered during SRv6 deployment and operation, which provides foundations for further work, including for example of potential solutions and best practices to navigate deployment.¶
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].¶
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 21 September 2024.¶
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 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.¶
Segment Routing over IPv6 (SRv6) is a new technology that builds upon the existing IPv6 infrastructure to offer programmable data plane capabilities. This allows for more granular control over traffic forwarding, enabling flexible and scalable network designs. While SRv6 presents numerous potential benefits, such as improved traffic engineering, optimized resource utilization, its deployment and operation come with certain challenges. This document aims to provide a concise overview of the common problems encountered during SRv6 deployment and operation, which provides foundations for further work, including for example potential solutions and best practices to navigate deployment . By understanding these challenges and exploring mitigation strategies, network administrators can make informed decisions when implementing and managing SRv6 networks.¶
This document identifies a number of Deployment and Operation Problems (DOPs) that require additional work within IETF.¶
While traditional inter-domain implementations in service provider networks often rely on MPLS and leverage Option A. Option A has scalability limitations and is complex to deploy and maintain. The ASBR needs to manage the routing of all VPNs and create VPN instances for each VPN. At the same time, it requests associating separate interfaces and corresponding VLANs for each inter-domain VPN. SRv6 presents an alternative approach with E2E inter-domain solution, potentially leading to simplification and improved scalability from the following 2 aspects: 1) SRv6naturally support end-to-end inter-domain by utilizing IPv6 route reachability; 2) IPv6 route aggregation reduces the number of SRv6 locators distribution for inter-domain deployment. However it requests further work to deal with the challenges of SRv6 inter-domain deployments including:¶
DOP-1 How to deploy SRv6 inter-domain in the existing MPLS network, which requires consideration of existing mechanism and potential migration strategies.¶
DOP-2 Utilizing SRv6 compression techniques in inter-domain scenario to further optimize bandwidth usage, which requires effective IPv6 address planning and block allocation strategies to achieve optimal aggregation benefits.¶
Also, protocol extension is out of scope and only implementation experience is considered to deal with these challenges.¶
Network visualization is a critical aspect for service providers, especially when implementing new technologies like SRv6. It provides essential insights into network traffic flow, resource utilization, and potential performance bottlenecks. Visualizing the SRv6 data plane requests further work in the aspects described next.¶
The existing IETF work on data collection formats can be leveraged for SRv6 data plane visualization. Further work is necessary to define SRv6-specific customization information; For example:¶
DOP-3 Reuse Telemetry Framework: The telemetry framework, used for collecting and transmitting network telemetry data, offers a solid foundation. While specific content and parameters need to be defined to capture SRv6-specific information relevant for visualization.¶
DOP-4 Reuse Netconf/Yang Framework: SRPING already defines the Yang Model for protocol extension; for better operation and maintenance of SRv6 network, the Yang Model for information collection, status notification, failure handling and recovery may also be required.¶
Once data is collected from network devices using the defined format, several techniques can be employed to utilize this information for network analysis and performance optimization for SRv6, especially traffic engineering. This brings the need for:¶
DOP-5 Identification of techniques for performance optimization in operational scenarios.¶
Existing IPv6 address planning approach ensures efficient address utilization and simplifies network management for IPv6 netowrk, which can't satisfy the SRv6 SID planning for service provider, especially considering the complexities introduced by advanced features like SRv6 compression. Further work is requested including: SRv6 SID Block Assignment, SRv6 SID Assignment for P2P and P2MP, SRv6 Node ID Assignment, SRv6 Function ID Assignment and so on. Some initial work could refer to [I-D.liu-srv6ops-sid-address-assignment]. In summary:¶
DOP-6 Efficient assignment of addresses and identifiers.¶
This document makes no request of IANA.¶
Note to RFC Editor: this section may be removed on publication as an RFC.¶