Internet DRAFT - draft-agv-rtgwg-spring-segment-routing-mrt

draft-agv-rtgwg-spring-segment-routing-mrt







Routing Area Working Group                                Anil Kumar S N
Internet-Draft                                            Gaurav Agrawal
Intended status: Standards Track                           Vinod Kumar S
Expires: March 2, 2017                               Huawei Technologies
                                                               C. Bowers
                                                        Juniper Networks
                                                         August 29, 2016


              Maximally Redundant Trees in Segment Routing
             draft-agv-rtgwg-spring-segment-routing-mrt-03

Abstract

   [RFC7812] defines an architecture for IP/LDP Fast Reroute using
   Maximally Redundant Trees (MRT-FRR).  This document extends the use
   of MRT to provide link and node protection for networks that use
   segment routing.  This document makes use of the inherent support in
   segment routing for associating segments with different algorithms
   for computing next hops to reach prefixes.  It assigns new Segment
   Routing Algorithms values corresponding to the MRT-Red and MRT-Blue
   next-hop computations defined in [RFC7811].

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 http://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 March 2, 2017.

Copyright Notice

   Copyright (c) 2016 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
   (http://trustee.ietf.org/license-info) in effect on the date of



Anil Kumar S N, et al.    Expires March 2, 2017                 [Page 1]

Internet-Draft                  MRT in SR                    August 2016


   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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  MRT for Segment Routing Network . . . . . . . . . . . . . . .   3
     4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  IGP extensions for MRT  . . . . . . . . . . . . . . . . .   4
     4.3.  SR Algorithm value for MRT-Blue and MRT-Red . . . . . . .   4
     4.4.  MRT capability advertisement for SR . . . . . . . . . . .   5
     4.5.  SR MRT SID/Label advertisement  . . . . . . . . . . . . .   5
     4.6.  MRT computation for SR  . . . . . . . . . . . . . . . . .   6
   5.  MRT-FRR for destination-based and traffic-engineered SR . . .   6
   6.  SR MRT Profile  . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   MRT is a fast re-route technology that provides 100% coverage for
   link and nodes failures.  This document describes how to use MRT as a
   FRR technology in a segment routing network.

2.  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 [RFC2119]

3.  Terminology

   Redundant Trees (RT):  A pair of trees where the path from any node X
      to the root R along the first tree is node-disjoint with the path
      from the same node X to the root along the second tree.  These can
      be computed in 2-connected graphs.




Anil Kumar S N, et al.    Expires March 2, 2017                 [Page 2]

Internet-Draft                  MRT in SR                    August 2016


   Maximally Redundant Trees (MRT):  A pair of trees where the path from
      any node X to the root R along the first tree and the path from
      the same node X to the root along the second tree share the
      minimum number of nodes and the minimum number of links.  Each
      such shared node is a cut-vertex.  Any shared links are cut-links.
      Any RT is an MRT but many MRTs are not RTs.  The two MRTs are
      referred to as MRT-Blue and MRT-Red.

   MRT-Red:  MRT-Red is used to describe one of the two MRTs; it is used
      to described the associated forwarding topology and MT-ID.
      Specifically, MRT-Red is the decreasing MRT where links in the
      GADAG are taken in the direction from a higher topologically
      ordered node to a lower one.

   MRT-Blue:  MRT-Blue is used to describe one of the two MRTs; it is
      used to described the associated forwarding topology and MT-ID.
      Specifically, MRT-Blue is the increasing MRT where links in the
      GADAG are taken in the direction from a lower topologically
      ordered node to a higher one.

   MRT Island:  From the computing router, the set of routers that
      support a particular MRT profile and are connected via MRT-
      eligible links.

   Island Border Router (IBR):  A router in the MRT Island that is
      connected to a router not in the MRT Island and both routers are
      in a common area or level.

   Island Neighbor (IN):  A router that is not in the MRT Island but is
      adjacent to an IBR and in the same area/level as the IBR.

4.  MRT for Segment Routing Network

4.1.  Overview

   Segment Routing (SR) allows a flexible definition of end-to-end paths
   within IGP topologies by encoding paths as sequences of topological
   sub-paths, called "segments".  These segments are advertised by the
   link-state routing protocols (IS-IS and OSPF).  Prefix segments
   represent an ECMP-aware shortest-path to a prefix (or a node), as per
   the state of the IGP topology.  Adjacency segments represent a hop
   over a specific adjacency between two nodes in the IGP.

   MRT Fast Reroute requires that packets to be forwarded not only on
   the shortest-path tree, but also on two Maximally Redundant Trees
   (MRTs), referred to as the MRT-Blue and the MRT-Red. A router that
   experiences a local failure must also have predetermined which
   alternate to use.  The MRT algorithm is defined in [RFC7811].  The



Anil Kumar S N, et al.    Expires March 2, 2017                 [Page 3]

Internet-Draft                  MRT in SR                    August 2016


   Default MRT Profile path calculation uses Lowpoint algorithm to
   calculate Maximally Redundant Trees.

   To use MRT in Segment Routing network below mentioned capabilities
   needs to be incorporated in SR node.

   1.  SR nodes MUST support IGP extensions for MRT.

   2.  SR nodes MUST support MRT-RED and MRT-BLUE Algorithms.

   3.  SR nodes MUST advertise it's MRT capability.

   4.  SR nodes SHOULD send and receive SID/Label for MRT topologies
       (MRT-RED and MRT-BLUE) for SR segment(s).

   5.  SR nodes MUST support computation of MRTs.

4.2.  IGP extensions for MRT

   These extensions are to support the distributed computation of
   Maximally Redundant Trees (MRT).  These extensions indicate the MRT
   profile(s) each router supports.  Different MRT profiles can be
   defined to support different uses and to allow transition of
   capabilities.

   To support MRT for SR, a new SR MRT Profile is defined (as defined in
   section 5 of this document).  IGP extensions for
   MRT[I-D.ietf-isis-mrt] / [I-D.ietf-ospf-mrt]MUST carry SR MRT
   profile.

4.3.  SR Algorithm value for MRT-Blue and MRT-Red

   Segment routing supports the use of different algorithms for
   computing paths to reach nodes and prefixes.  To accomplish this,
   every Prefix-SID has a mandatory algorithm field.  This Prefix-SID
   identifies an instruction to forward a packet along the path computed
   using the algorithm identified in the algorithm field.

   [I-D.ietf-spring-segment-routing] defines two algorithms, Shortest
   Path and Strict Shortest Path.
   [I-D.ietf-isis-segment-routing-extensions] and
   [I-D.ietf-ospf-segment-routing-extensions] each assign the algorithm
   values of 0 and 1 to identify these two algorithms.

   This document defines two additional algorithm values to support MRT-
   FRR using Segment Routing.  The two algorithms correspond to the MRT-
   Red and MRT-Blue for the Default MRT Profile.




Anil Kumar S N, et al.    Expires March 2, 2017                 [Page 4]

Internet-Draft                  MRT in SR                    August 2016


4.4.  MRT capability advertisement for SR

   As packets routed on a hop-by-hop basis require that each router
   compute a shortest-path tree that is consistent, it is necessary for
   each router to compute the MRT-Blue next hops and MRT-Red next hops
   in a consistent fashion.  For this each SR node needs to know which
   of the SR nodes in the SR domain supports MRT.  This MUST be
   communicated using SR MRT Capability Advertisement.

   Both OSPF [I-D.ietf-ospf-segment-routing-extensions] and ISIS
   [I-D.ietf-isis-segment-routing-extensions] supports segment routing
   capabilities advertisement.  MRT algorithm capabilities need to be
   advertised in SR-Algorithm TLV for OSPF extension for segment routing
   and SR-Algorithm Sub-TLV for ISIS extension for segment routing.

   SR-Algorithm TLV [I-D.ietf-ospf-segment-routing-extensions]

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Algorithm 1 | Algorithm...  |   Algorithm n |               |
   +---------------------------------------------------------------+
   |                                                               |
   +                                                               +

   SR-Algorithm Sub-TLV[I-D.ietf-isis-segment-routing-extensions]

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type        |     Length    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Algorithm 1   |  Algorithm 2  | Algorithm ... |  Algorithm n  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   SR node is considered as MRT capable node if it advertises MRT
   capability in IGP extension of MRT as well as IGP extension of SR.

4.5.  SR MRT SID/Label advertisement

   In a link-state IGP domain, an SR-capable IGP node advertises
   segments for its attached prefixes and adjacencies.  These segments
   are called IGP segments or IGP SIDs.  They play a key role in Segment
   Routing as they enable the expression of any topological path
   throughout the IGP domain.  Such a topological path is either
   expressed as a single IGP segment or a list of multiple IGP segments.



Anil Kumar S N, et al.    Expires March 2, 2017                 [Page 5]

Internet-Draft                  MRT in SR                    August 2016


   SR nodes supporting MRT MUST advertise two additional labels
   corresponding to MRT-BLUE and MRT-RED for each prefix segment.

   These labels are carried as a part of prefix SID sub-tlv (OSPF
   Section 5 of [I-D.ietf-ospf-segment-routing-extensions], ISIS
   Section 2.1 of [I-D.ietf-isis-segment-routing-extensions]) with
   algorithm field set to algorithm value corresponding to the MRT
   forwarding topology as described in section Section 4.3.

4.6.  MRT computation for SR

   An SR node that advertise support for the Segment Routing MRT Profile
   MUST support MRT-RED and MRT-BLUE forwarding topology creation and
   support the computation of FRR paths as per the MRT algorithm
   described in [RFC7811].

5.  MRT-FRR for destination-based and traffic-engineered SR

   In addition to the Prefix-SIDs for Shortest Path algorithm, the IGP
   distributes Prefix-SIDs for MRT-Red and MRT-Blue.  This allows each
   node to install transit forwarding entries for the MRT-Red and MRT-
   Blue paths for those prefixes.  In normal operation, the traffic for
   a given destination will be forwarded based on the Shortest Path
   algorithm Prefix-SID for that destination.  Upon detecting a link
   failure, a node can act as a point-of-local repair (PLR) by
   forwarding the traffic using either the MRT-Red or MRT-Blue Prefix-
   SID for the same destination.  Following the appropriate MRT path,
   the traffic will the destination without crossing the failed link or
   the remote node attached to the failed link, if such a path exists.

   The description above is independent of the segment routing
   forwarding plane.  With the MRT-Red and MRT-Blue Segment Routing
   Algorithm values defined in this document, MRT-FRR can provide
   protection for traffic using either the MPLS or the IPv6 forwarding
   plane for segment routing.  For clarity, we also describe the MRT-FRR
   mechanism when realized using the MPLS forwarding plane for segment
   routing.

   In the MPLS-specific description, each node uses the index
   information contained in Prefix-SIDs and the SRGBs advertised by its
   neighbors to install transit forwarding entries for the Shortest
   Path, MRT-Red path, and MRT-Blue path for each destination prefix.
   As an example, the transit forwarding entry for a destination prefix
   on the MRT-Red path is a label swap operation where the both the
   incoming and outgoing labels correspond to the MRT-Red labels on the
   MRT-Red path.





Anil Kumar S N, et al.    Expires March 2, 2017                 [Page 6]

Internet-Draft                  MRT in SR                    August 2016


   In the absence of failures, traffic flows on transit forwarding
   entries corresponding to the Shortest Path algorithm where an
   incoming Shortest Path label is swapped to an outgoing Shortest Path
   label for a given destination.  Upon the failure of a link, the PLR
   may change some forwarding entries to swap an incoming Shortest Path
   label to an outgoing MRT-Red or MRT-Blue label.

   MRT Prefix Segments are applicable to both destination-based SR as
   well as traffic-engineered SR.  In the case of destination-based SR,
   the Segment List consists of a single Prefix Segment with an MRT-Red
   or MRT-Blue algorithm value.  In this case Prefix Segment identifies
   the complete MRT-Red or MRT-Blue path to the destination node or
   prefix.  In the case of traffic-engineered SR, a Prefix Segment with
   an MRT algorithm value may form part of a larger Segment List.  In
   this case, the MRT Prefix Segment identifies a portion of the entire
   end-to-end path in the SR domain.  That portion of the path
   corresponds to the MRT-Red or MRT-Blue path for that prefix.

6.  SR MRT Profile

   The following set of options defines the SR MRT Profile.  The SR MRT
   Profile is indicated by the MRT Profile ID.

   MRT Algorithm: MRT Lowpoint algorithm defined in [RFC7811].

   MRT-Red SR Algorithm ID: The MRT-Red SR Algorithm ID is indicated by
   the MRT-Red SR Algorithm ID.

   MRT-Blue SR Algorithm ID: The MRT-Blue SR Algorithm ID is indicated
   by the MRT-BLue SR Algorithm ID.

   GADAG Root Selection Policy: Among the routers in the MRT Island with
   the lowest numerical value advertised for GADAG Root Selection
   Priority, an implementation MUST pick the router with the highest
   Router ID to be the GADAG root.  Note that a lower numerical value
   for GADAG Root Selection Priority indicates a higher preference for
   selection.

   Forwarding Mechanisms: MRT SR Label Option 1A

   Recalculation: Recalculation of MRTs SHOULD occur as described in
   Section 12.2 of [RFC7812] with SR label.

   Area/Level Border Behavior: As described in Section 10 of [RFC7812],
   ABRs/LBRs SHOULD ensure that traffic leaving the area also exits the
   MRT-Red or MRT-Blue forwarding topology.





Anil Kumar S N, et al.    Expires March 2, 2017                 [Page 7]

Internet-Draft                  MRT in SR                    August 2016


7.  IANA Considerations

   IANA is requested to allocate a value from the MRT Profile Identifier
   Registry for the Segment Routing MRT Profile with a value of TDB-1.

   Value    Description                               Reference
   -------  ----------------------------------------  ------------
   TBD-1    Segment Routing MRT Profile               This document

   Currently, there is no IANA registry defined for SR Algorithm values
   carried in the Prefix-SID sub-TLV and the SR Algorithm sub-TLV for
   IS-IS or the Prefix-SID sub-TLV and SR Algorithm TLV for OSPF
   [I-D.ietf-isis-segment-routing-extensions] and
   [I-D.ietf-ospf-segment-routing-extensions] define the Segment Routing
   algorithms for values 0 and 1.

   This document requests IANA to create a registry entitled "Segment
   Routing Algorithm Values".  This should appear in the IANA registry
   under a new top-level entry entitled "IGP-Independent Segment Routing
   Parameters".  The initial registry is shown below.

 Value   SR Algorithm           References
 ---------------------------------------
 0       Shortest Path          I-D.ietf-isis-segment-routing-extensions
                                I-D.ietf-ospf-segment-routing-extensions
 1       Strict Shortest Path   I-D.ietf-isis-segment-routing-extensions
                                I-D.ietf-ospf-segment-routing-extensions
 TBD-2   MRT-Red                This document
 TBD-3   MRT-Blue               This document

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

8.  Security Considerations

   Security consideration of MRT and SR are applicable here.  None of
   the additional security consideration are identified.

9.  Acknowledgements

   None

10.  References








Anil Kumar S N, et al.    Expires March 2, 2017                 [Page 8]

Internet-Draft                  MRT in SR                    August 2016


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

   [RFC7811]  Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
              Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute
              Using Maximally Redundant Trees (MRT-FRR)", RFC 7811,
              DOI 10.17487/RFC7811, June 2016,
              <http://www.rfc-editor.org/info/rfc7811>.

   [RFC7812]  Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
              IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-
              FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
              <http://www.rfc-editor.org/info/rfc7812>.

10.2.  Informative References

   [I-D.ietf-isis-mrt]
              Li, Z., Wu, N., <>, Q., Atlas, A., Bowers, C., and J.
              Tantsura, "Intermediate System to Intermediate System (IS-
              IS) Extensions for Maximally Redundant Trees (MRT)",
              draft-ietf-isis-mrt-02 (work in progress), May 2016.

   [I-D.ietf-isis-segment-routing-extensions]
              Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
              Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
              Extensions for Segment Routing", draft-ietf-isis-segment-
              routing-extensions-07 (work in progress), June 2016.

   [I-D.ietf-ospf-mrt]
              Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li,
              "OSPF Extensions to Support Maximally Redundant Trees",
              draft-ietf-ospf-mrt-02 (work in progress), May 2016.

   [I-D.ietf-ospf-segment-routing-extensions]
              Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
              Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
              Extensions for Segment Routing", draft-ietf-ospf-segment-
              routing-extensions-09 (work in progress), July 2016.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
              and R. Shakir, "Segment Routing Architecture", draft-ietf-
              spring-segment-routing-09 (work in progress), July 2016.




Anil Kumar S N, et al.    Expires March 2, 2017                 [Page 9]

Internet-Draft                  MRT in SR                    August 2016


Authors' Addresses

   Anil Kumar S N
   Huawei Technologies
   Near EPIP Industrial Area, Kundalahalli Village
   Whitefield, Bangalore, Karnataka  560066
   India

   Email: anil.ietf@gmail.com


   Gaurav Agrawal
   Huawei Technologies
   Near EPIP Industrial Area, Kundalahalli Village
   Whitefield, Bangalore, Karnataka  560066
   India

   Email: gaurav.agrawal@huawei.com


   Vinod Kumar S
   Huawei Technologies
   Near EPIP Industrial Area, Kundalahalli Village
   Whitefield, Bangalore, Karnataka  560066
   India

   Email: vinods.kumar@huawei.com


   Chris Bowers
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   USA

   Email: cbowers@juniper.net















Anil Kumar S N, et al.    Expires March 2, 2017                [Page 10]