[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Routing area                                                    S. Hegde
Internet-Draft                                                    W. Lin
Intended status: Standards Track                   Juniper Networks Inc.
Expires: September 9, 2020                                 March 8, 2020


          Egress Protection for Segment Routing (SR) networks
           draft-hegde-rtgwg-egress-protection-sr-networks-00

Abstract

   This document specifies a Fast Reroute(FRR) mechanism for protecting
   IP/MPLS services that use Segment Routing (SR) paths for transport
   against egress node and egress link failures.  The mechanism is based
   on egress protection framework described in
   [I-D.ietf-mpls-egress-protection-framework].  The egress protection
   mechanism can be further simplified in Segment Routing networks with
   anycast SIDs and anycast Locators.  This document addresses all kinds
   of networks that use Segment Routing transport such as SR-MPLS over
   IPv4, SR-MPLS over IPv6, SRv6 and SRm6.

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 September 9, 2020.








Hegde & Lin             Expires September 9, 2020               [Page 1]


Internet-Draft              EGRESS-PROTECTION                 March 2020


Copyright Notice

   Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Egress Node Protection  . . . . . . . . . . . . . . . . . . .   3
     2.1.  SR-MPLS Networks  . . . . . . . . . . . . . . . . . . . .   4
     2.2.  SRm6 Networks . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  SRv6 Networks . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Egress Link Protection  . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Segment Routing Architecture as defined in [RFC8401] provides a
   simple and scalable MPLS control plane that removes state from
   transit nodes in the network.  SRm6 as defined in
   [I-D.bonica-spring-sr-mapped-six] and SRv6 as defined in
   [I-D.ietf-spring-srv6-network-programming] provide Segment Routing
   transport in pure IPv6 networks where MPLS data plane is not used.
   End-to-End resiliency is very important to satisfy Service Level
   Agreements (SLA) such as 50ms convergence.  The transport resiliency
   and fast rerouting are described
   in[I-D.ietf-rtgwg-segment-routing-ti-lfa] and
   [I-D.hegde-spring-node-protection-for-sr-te-paths].  Egress node and
   egress link failures are not covered by these protection mechanisms.
   Egress node and link failures need to address moving the services to
   other nodes where the customer services are multi-homed.  In
   traditional MPLS networks service labels (ex: L3VPN) are assigned



Hegde & Lin             Expires September 9, 2020               [Page 2]


Internet-Draft              EGRESS-PROTECTION                 March 2020


   dynamically.  The protector nodes need to learn the service labels
   advertised by primary nodes and build a local context table
   corresponding to each primary node that a node protects.This requires
   building local context tables and also specialized context table
   lookups as described in [I-D.ietf-mpls-egress-protection-framework].

   Egress protection can be simplified by statically assigning service
   labels on egress nodes.  When a service is multi-homed to two or more
   egress nodes, the same service label can be assigned to the service
   on each egress node.  This mechanism, coupled with using anycast SIDs
   for loopbacks, greatly simplifies the egress protection.  Following
   the principles described in
   [I-D.ietf-mpls-egress-protection-framework], this document specifies
   procedures which can be used to greatly simplify the operation of
   egress protection in a segment routing network.  Egress protection
   for Multicast services is for FFS.

2.  Egress Node Protection

                        services 1, ..., N
        =====================================> tunnel

      I ------ R1 ------- PLR --------------- E ----
   ingress          penultimate-hop        egress    \
                           |  .           (primary    \
                           |  .            service     \
                           |  .            instances)   \
                           |  .                          \
                           |  .                           \   service
                           |  .                             destinations
                           |  .                           / (CEs, sites)
                           |  .                          /
                           |  . TI-LFA backup           /
                           |  . path                   /
                           |  .                       /
                           |  ...............        /
                           R2 --------------- P ----
                                          protector
                                         (protection
                                          service
                                          instances)


                       Figure 1: Reference topology

   The reference topology from
   [I-D.ietf-mpls-egress-protection-framework] has been reproduced in
   Figure 1 for ease of reading.  The current document also uses the



Hegde & Lin             Expires September 9, 2020               [Page 3]


Internet-Draft              EGRESS-PROTECTION                 March 2020


   terminology defined in [I-D.ietf-mpls-egress-protection-framework].In
   the topology in Figure 1, service destinations are attached to two
   egress nodes.  The two egress nodes could be used in primary/
   protection mode or they could also be used in ECMP mode.  When one of
   egress nodes fails, traffic should be switched to the other egress
   node and the convergence should be on the order of 50ms.  The
   transport network is based on Segment Routing technology and could be
   using any of the SR-MPLS over IPv4, SR-MPLS over IPV6 , SRm6 or SRv6.
   The sections below describe the solution for each of the transport
   mechanisms.

2.1.  SR-MPLS Networks

   [RFC8401] describes the concept of anycast SIDs.  Applying anycast
   SIDs to egress protection, the same IP address is configured as a
   loopback address on multiple egress nodes, and the same SID is
   advertised for this IP address.  In the reference topology in
   Figure 1, E and P are associated with anycast loopback and
   corresponding anycast SID.  The egress protected tunnel is considered
   logically destined to this anycast address and the egress protected
   tunnel always carries this anycast SID corresponding to the
   destination anycast address as the last SID.  The egress protected
   service is hosted on both E and P.  The egress protected tunnel can
   be used in primary/protector mode in which case, the anycast loopback
   MUST be advertised with better metric and the protector MUST
   advertise with an inferior metric.  An egress protected service MUST
   advertise same service label from both E and P.  The service label is
   assigned from the SRLB as defined in [RFC8401].  The egress node
   pairs that serve egress protected service MUST be able to allocate
   the same service label and hence MUST have overlapping local label
   space (SRLB) reserved for static assignment.

   The TI-LFA procedures described in
   [I-D.ietf-rtgwg-segment-routing-ti-lfa] apply to the anycast
   prefixes.  Based on the transport IGP topology, TI-LFA backup path is
   computed and programmed into the forwarding plane on the PLR nodes.
   The PLR SHOULD be configured to provide node protection for the
   failure.  On the egress node E's failure, traffic on the PLR SHOULD
   be switched to the other egress node which is P.  As the service
   label carried in the packet is understood by P as well, P will
   correctly send the traffic to the service destination.

   The above procedure is applicable to SR-MPLS over IPv4 as well as SR-
   MPLS over IPv6 networks.  In case of IPv4 networks, the anycast SIDs
   are assigned to IPv4 loopbacks and in case of IPv6 networks, the
   anycast SIDs are assigned to IPv6 loopback addresses.  The egress
   protected IP/MPLS services advertise the service prefix with the
   anycast address information in the message.  In case of BGP based



Hegde & Lin             Expires September 9, 2020               [Page 4]


Internet-Draft              EGRESS-PROTECTION                 March 2020


   services such as L3vpn [RFC2547], the nexthop attribute carries the
   anycast address which is the logical tunnel destination address.  On
   the ingress, when the service prefix is received, the service is
   mapped to the corresponding egress protected tunnel.

   If some services are multi-homed to a different node for example, in
   the reference topology, if a service is multi-homed to E and another
   node P', then there SHOULD be another anycast address representing
   {E,P'}. The number of anycast loopbacks on a given node will be equal
   to the number of such {primary, protector} pairs a node belongs
   to.The egress protected service prefixes MUST carry the anycast
   address corresponding to the {primary, protector} pair in their next
   hop attribute.

   When there is a single homed CE connected to the egress node, it
   SHOULD use a node loopback in the next hop attribute and should not
   use anycast loopback address.

2.2.  SRm6 Networks

   [I-D.bonica-spring-sr-mapped-six] defines segment routing applied to
   IPv6 networks which is optimized for high data rate forwarding.  SRm6
   control plane is very similar to SR-MPLS but it uses the IPv6 data
   plane.  The egress node protection procedures described for SR-MPLS
   are applicable to SRm6 as well.  Anycast loopback addresses are
   advertised and corresponding anycast SIDs are associated with the
   anycast addresses.  The anycast SIDs in case of SRm6 are globally
   unique indices of size 16 or 32 bits.

   The VPN services that require a label to identify the service are
   advertised as described in [I-D.ssangli-idr-bgp-vpn-srv6-plus].  The
   same PPSI value MUST be allocated to the service prefix on both the
   egress nodes on which the service is multi-homed.The TI-LFA
   procedures explained in Section 2.1 are applicable to SRm6 as well.
   After the CRH header is removed at the egress node, lookup is done
   based on PPSI which points to the correct service instance.  Since
   the same PPSI is assigned on both nodes, the context table as
   described in [I-D.ietf-mpls-egress-protection-framework] is not
   required to be built.

2.3.  SRv6 Networks

   [I-D.ietf-spring-srv6-network-programming] describes various types of
   SIDs used in SRv6 networks.The routing in the transport is based on
   the locators.  Locators are most significant bits of the SID.  In
   order to achieve the egress protection functionality, anycast
   locators MUST be assigned on the egress nodes {E,P} where the service
   are multi-homed.  The service SIDs MUST be derived from the anycast



Hegde & Lin             Expires September 9, 2020               [Page 5]


Internet-Draft              EGRESS-PROTECTION                 March 2020


   SID.  The multi-homed service MUST be assigned with same service SID
   on both the egress nodes.  It is recommended to provide mechanisms to
   statically configure the service SIDs which can easily serve the
   purpose of synchronized SID allocation on both nodes.  As explained
   in the Section 2.1, if an egress node has services which are multi-
   homed to different nodes, then each such pair of node will need a
   separate locator assigned.

   When there is a single homed CE connected to an egress, it MUST use a
   node specific locator to advertise service SID.  It should not use
   service SIDs based on anycast locator

   The TI-LFA procedure is applicable to anycast locators and each
   transport node in the transport IGP, installs a primary and backup
   path to the anycast locator.  It is assumed that PLR has a backup
   path to alternate egress node which does not go via the primary
   egress node.

3.  Egress Link Protection

                                                    Anycast loopback:10.10.10.10
                                                    Anycast SID: 10 SRGB (1000-2000)
                                                    Node loopback: 2.2.2.2

                           ---------- R1 ----------- PE2 -
                          /          (PLR)          (PLR)  \
    (          )         /            |               |     (          )
    (          )        /             |               |     (          )
    (  site 1  )-- PE1 |              |               R3    (  site 2  )
    (          )        \             |               |     (          )
    (          )         \            |               |     (          )
                          \           |               |    /
                           ---------- R2 ----------- PE3 -
                                                 (protector)
                                                 Anycast loopback:10.10.10.10
                                                 Anycast SID: 10 SRGB (1000-2000)
                                                 Node loopback: 3.3.3.3


                     Figure 2: Egress Link Protection

   The link from egress node towards the CE (service destination) fails,
   that failure needs to be protected.  Egress link protection can be
   achieved using similar means as egress node protection.  In egress
   link failure case, egress node is the PLR and it has learned the
   service prefix from the other egress node.  PLR egress node pre-
   establishes backup path to the other egress node and programs the
   forwarding plane with backup path.  As the BGP based service prefixes



Hegde & Lin             Expires September 9, 2020               [Page 6]


Internet-Draft              EGRESS-PROTECTION                 March 2020


   advertise the anycast loopback address in the next hop attribute, the
   egress nodes will ignore the advertisement from other egress node.
   For Example, in the above Figure 2, when PE3 advertises a service
   prefix for site 2 with a next hop attribute of anycast loopback
   address, PE2 does not consider this advertisement and program a
   backup path towards PE3.  To solve this problem, The egress nodes
   could advertise service prefixes with NEXT_HOP [RFC4271]attribute
   carrying anycast loopback as well as node specific loopback with a
   different RD [RFC2547].

4.  Security Considerations

   This document does not introduce any new security risks.  For
   deploying this solution, security considerations described in
   [RFC8401], [I-D.bonica-spring-sr-mapped-six],
   [I-D.ietf-spring-srv6-network-programming] and
   [I-D.ietf-mpls-egress-protection-framework] are applicable.

5.  IANA Considerations

   This document does not introduce any new IANA requests.

6.  Acknowledgments

   Thanks to Krzysztof Szarkowicz,Louis Chan and Chris Bowers for
   careful review and inputs.

7.  References

7.1.  Normative References

   [I-D.bonica-spring-sr-mapped-six]
              Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques,
              D., Jalil, L., Halpern, J., Linkova, J., and G. Chen,
              "Segment Routing Mapped To IPv6 (SRm6)", draft-bonica-
              spring-sr-mapped-six-00 (work in progress), November 2019.

   [I-D.ietf-mpls-egress-protection-framework]
              Shen, Y., Jeganathan, J., Decraene, B., Gredler, H.,
              Michel, C., and H. Chen, "MPLS Egress Protection
              Framework", draft-ietf-mpls-egress-protection-framework-07
              (work in progress), July 2019.

   [I-D.ietf-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
              Matsushima, S., and Z. Li, "SRv6 Network Programming",
              draft-ietf-spring-srv6-network-programming-10 (work in
              progress), February 2020.



Hegde & Lin             Expires September 9, 2020               [Page 7]


Internet-Draft              EGRESS-PROTECTION                 March 2020


   [RFC8401]  Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z.
              Zhang, "Bit Index Explicit Replication (BIER) Support via
              IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018,
              <https://www.rfc-editor.org/info/rfc8401>.

7.2.  Informative References

   [I-D.hegde-spring-node-protection-for-sr-te-paths]
              Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu,
              "Node Protection for SR-TE Paths", draft-hegde-spring-
              node-protection-for-sr-te-paths-05 (work in progress),
              July 2019.

   [I-D.ietf-rtgwg-segment-routing-ti-lfa]
              Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B.,
              Francois, P., Voyer, D., Clad, F., and P. Camarillo,
              "Topology Independent Fast Reroute using Segment Routing",
              draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in
              progress), March 2020.

   [I-D.ssangli-idr-bgp-vpn-srv6-plus]
              Ramachandra, S. and R. Bonica, "BGP based Virtual Private
              Network (VPN) Services over SRv6+ enabled IPv6 networks",
              draft-ssangli-idr-bgp-vpn-srv6-plus-02 (work in progress),
              July 2019.

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

   [RFC2547]  Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
              DOI 10.17487/RFC2547, March 1999,
              <https://www.rfc-editor.org/info/rfc2547>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC7911]  Walton, D., Retana, A., Chen, E., and J. Scudder,
              "Advertisement of Multiple Paths in BGP", RFC 7911,
              DOI 10.17487/RFC7911, July 2016,
              <https://www.rfc-editor.org/info/rfc7911>.







Hegde & Lin             Expires September 9, 2020               [Page 8]


Internet-Draft              EGRESS-PROTECTION                 March 2020


Authors' Addresses

   Shraddha Hegde
   Juniper Networks Inc.
   Exora Business Park
   Bangalore, KA  560103
   India

   Email: shraddha@juniper.net


   Wen Lin
   Juniper Networks Inc.

   Email: wlin@juniper.net




































Hegde & Lin             Expires September 9, 2020               [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/