Internet DRAFT - draft-hegde-spring-srv6-migration

draft-hegde-spring-srv6-migration







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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc8754>.

   [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>.

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,
              <https://datatracker.ietf.org/doc/html/draft-filsfils-
              spring-net-pgm-extension-srv6-usid-15>.

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]