SPRING S. Hegde Internet-Draft R. Shetty Intended status: Standards Track R. Bharath Expires: 18 April 2024 Juniper Networks Inc. D. Voyer Bell Canada 23 October 2023 SRv6 Migration Scenarios draft-hegde-spring-srv6-migration-00 Abstract SRv6 forwarding plane requires devices to support processing newly defined Segment Routing extension header. All devices in the network may not be capable of processing this new header and may require gradual upgrade. This document specifies mechanisms that to deploy features such as TI-LFA, in the presence of SRH incapable devices in the network. 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 18 April 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Hegde, et al. Expires 18 April 2024 [Page 1] Internet-Draft SRv6 Migration Scenarios October 2023 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. TI-LFA with Encapsulation mode . . . . . . . . . . . . . . . 3 3. Decap_only Flavor . . . . . . . . . . . . . . . . . . . . . . 4 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4 5. Operational Considerations . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 10.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Segment Routing for IPv6 defines new Segment Routing extension header as defined in [RFC8754]. Legacy devices may not be capable of processing the SRH. This poses challenges in deploying features such as TI-LFA, that require anchor nodes to support processing SRH. Hegde, et al. Expires 18 April 2024 [Page 2] Internet-Draft SRv6 Migration Scenarios October 2023 +----+ 10 +----+ 10 +----+ 10 +----+ 10 +----+ | R1 |--------| R2 |--------| R3 |--------| R4 |--------| R5 | +----+ +----+ +----+ +----+ +----+ \ \ / \ 10 \ 100 / 60 \ \ / \ +----+ +----+ +--| R7 |------------------| R8 | +----+ 30 +----+ / / +----+ | R6 | +----+ * Numbers on the links represent the symmetric link cost Figure 1: Example topology with locators Consider the topology diagram above. On R1, The primary path to R5 is R1->R2->R3->R4->R5. The TI-LFA backup path is R1->R7->R8->R4->R5 where R8 is the anchor node.The TI-LFA backup path consists of one SID in SRH in case of classic SRH [RFC8754] or one additional SID in the micro-SID container [I-D.filsfils-spring-net-pgm-extension-srv6-usid]. If device R8 is not capable of processing SRH or the micro-SID instructions, the TI- LFA backup path cannot be installed as R8 does not advertise a END SID or uN SID. 2. TI-LFA with Encapsulation mode TI-LFA with encapsulation mode imposes an additional IPv6 header on the packet. This additional header is decapsulated on the anchor node and lookup done for the inner packet. Many legacy devices are capable of decapsulating IPv6 header and lookingup inner packet and forward. The legacy device shuold advertise a SID behaviour which implies decapsulation and lookup only. Currently defined SIDs END and END.X from [RFC8986] and un/uA defined in [I-D.filsfils-spring-net-pgm-extension-srv6-usid] also imply support for NEXT operation which legacy devices cannot support. The END.DT6 and END.DX6 SIDs specify decapsulation and lookup. Reusing these SIDs and advertising them in IGPs have below disadvantages - Pure transit nodes will also have to advertise these SIDs where there are no service routes. This may give false impression that the transit node is advertising service routes. Hegde, et al. Expires 18 April 2024 [Page 3] Internet-Draft SRv6 Migration Scenarios October 2023 - It is much easier to debug TI-LFA which uses END/END.X uN/uA with new flavor rather than using SIDs defined for advertising Services. - When the platform capability is upgraded, its operationally easier to advertise the ‘END with decap_only’ with END/uN and ‘END.X with decap_only’ with END.X/UA SIDs respectively. 3. Decap_only Flavor This document proposes a new flavor for the END/END.X and un/uA SIDs named decap_only. SIDs with decap_only flavor MUST be used as last SID in the SRH or as last SID in the last SID container. Nodes computing TI-LFA backup paths SHOULD use the decap_only flavored SIDs, if the backup path contains only one SID either END/uN or END.X/uA. The backup path MUST be installed by the computing node in the encapsulation mode where the incoming packet is imposed with additional IPv6 header on failure while exercising the backup path. 4. Backward Compatibility TBD 5. Operational Considerations TBBD 6. Security Considerations TBD 7. IANA Considerations This document defines new SRv6 END Point behaviours Code point Behaviour reference ----------------------------------------------------------------- TBD1 END with decap_only This document TBD2 END.X with decap_only This document Figure 2: IANA Cosepoints Hegde, et al. Expires 18 April 2024 [Page 4] Internet-Draft SRv6 Migration Scenarios October 2023 8. Acknowledgements 9. Contributors 10. References 10.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, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [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, . 10.2. Informative References [I-D.filsfils-spring-net-pgm-extension-srv6-usid] Filsfils, C., Camarillo, P., Cai, D., Voyer, D., Meilik, I., Patel, K., Henderickx, W., Jonnalagadda, P., Melman, D. T., Liu, Y., and J. Guichard, "Network Programming extension: SRv6 uSID instruction", Work in Progress, Internet-Draft, draft-filsfils-spring-net-pgm-extension- srv6-usid-15, 12 June 2023, . Authors' Addresses Shraddha Hegde Juniper Networks Inc. Exora Business Park Bangalore 560103 KA India Email: shraddha@juniper.net Hegde, et al. Expires 18 April 2024 [Page 5] Internet-Draft SRv6 Migration Scenarios October 2023 Rajesh Shetty Juniper Networks Inc. Email: mrajesh@juniper.net Bharath R Juniper Networks Inc. Email: rbharath@juniper.net Daniel Voyer Bell Canada Email: daniel.voyer@bell.ca Hegde, et al. Expires 18 April 2024 [Page 6]