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]
