Network Working Group Anil Kumar S N
INTERNET-DRAFT Gaurav Agrawal
Intended Status: Standard Track Vinod Kumar S
Expires: April 11, 2016 Huawei Technologies India
October 9, 2015
Maximally Redundant Trees in Segment Routing
draft-agv-rtgwg-spring-segment-routing-mrt-00
Abstract
This document presents a Fast Reroute (FRR) approach aimed at
providing link and node protection of node and adjacency segments
within the Segment Routing (SR) framework. This FRR behavior builds
on Maximally Redundant Trees (MRT) FRR algorithm [I-D.atlas-rtgwg-
mrt-mc-arch].
Fast-Reroute with Maximally Redundant Trees (MRT-FRR) using
Segment routing is a technology that gives link-protection and node-
protection with 100% coverage in any network topology that is still
connected after the failure. MRT is computational efficient. For any
router in the network, the MRT computation is less than the LFA
computation for a node with three or more neighbors in SR domain (Ex:
Topology Independent Fast Reroute).
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
AGV Expires April 11, 2016 [Page 1]
INTERNET DRAFT MRT in Segment Routing October 9, 2015
Copyright and License Notice
Copyright (c) 2015 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Standard Terminology . . . . . . . . . . . . . . . . . . . . 3
2. Draft Specific Terminology . . . . . . . . . . . . . . . . . . 3
3. Overview of SR Signaling for MRT . . . . . . . . . . . . . . . 5
4. Protecting segments . . . . . . . . . . . . . . . . . . . . . . 5
4.1. The top segment is a node segment . . . . . . . . . . . . . 5
4.1. The top segment is an adjacency segment . . . . . . . . . . 5
5. Requirements for SR MRT implementation . . . . . . . . . . . . 6
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Normative References . . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
AGV Expires April 11, 2016 [Page 2]
INTERNET DRAFT MRT in Segment Routing October 9, 2015
1 Introduction
SR MRT FRR is one among the local repair mechanisms for Segment
routing network. Another well known local repair mechanism for SR is
Topology Independent Fast Reroute which is also capable of restoring
end-to-end connectivity in case of a failure of a link or a node,
with guaranteed coverage properties. MRT also provides 100% network
failure coverage. The advantage of MRT over TI-LFA would be the
computation complexities involved in MRT is much lesser then TI-LFA.
MRT is best suited for access/aggregate ring network or low end
devices which has low computing capacity.
1.1 Standard Terminology
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].
2. Draft Specific Terminology
For ease of reading, some of the terminology defined in [I-D.ietf-
rtgwg-mrt-frr-architecture] is repeated here.
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.
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.
AGV Expires April 11, 2016 [Page 3]
INTERNET DRAFT MRT in Segment Routing October 9, 2015
Rainbow MRT MT-ID: It is useful to have an MT-ID that refers to the
multiple MRT topologies and to the default topology. This is
referred to as the Rainbow MRT MT-ID and is used by LDP to reduce
signaling and permit the same label to always be advertised to all
peers for the same (MT-ID, Prefix).
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..
AGV Expires April 11, 2016 [Page 4]
INTERNET DRAFT MRT in Segment Routing October 9, 2015
3. Overview of SR Signaling for MRT
To extend MRT support to Segment routing following requirement
need to be achieved :
1. SR MRT Capabilities must be advertised using IGP extension for SR
MRT. Also SR MRT capabilities must be in sync with IGP specific MRT
capabilities advertisement. If the peer has not advertised the SR MRT
capability, then it indicates that LSR does not support MRT
procedures.
2. As specified in MRT Architecture draft-ietf-rtgwg-mrt-frr-
architecture, both Option 1A and Option 1B can be used for the
implementation of SR MRT.
For Option 1A, two additional Prefix SID's/Label for RED and BLUE MT
must be advertised in addition to default prefix SID/Label. The IGP
extension carrying prefix SID for RED and BLUE MT must have
corresponding MT-ID allocated by IANA for default MRT profile.
For Option 1B, Global Unique Context SID/Label for Red & Blue as
topology identifier must be used.
4. Protecting segments
In this section, we explain how a protecting router processes the
label stack of a packet upon the failure of its interface.
The behavior depends on the type of top segment in SR label stack to
be protected. Its assumed the MRT algorithm is run prior to interface
failure and alternate is selected as per the algorithm. The alternate
segment could be MRT-RED label or MRT Blue label of Next/Next-to-Next
Hop depending on the scenario.
4.1. The top segment is a node segment The current SR Label Stack is
kept intact. The alternate segment is pushed at the top of SR label
stack and continue forwarding the packet as per updated label stack.
4.1. The top segment is an adjacency segment The top adjacency label in
the SR label stack representing the failed interface is popped & the
alternate segment is pushed at the top of SR Label stack and contineu
forwarding the packet as per updated label stack.
AGV Expires April 11, 2016 [Page 5]
INTERNET DRAFT MRT in Segment Routing October 9, 2015
5. Requirements for SR MRT implementation
REQ1 : IGP Extension to carry the Segment Routing Node MRT Capability
in addition to exiting IGP extension carrying IGP MRT Capability
REQ2 : IGP Extension to carry Red & Blue MRT SR Segments in addition
to existing Default SR Segment
3 Security Considerations
None of the security consideration are identified
4 IANA Considerations
None of the IANA consideration are identified
AGV Expires April 11, 2016 [Page 6]
INTERNET DRAFT MRT in Segment Routing October 9, 2015
5 References
5.1 Normative References
[I-D.ietf-rtgwg-mrt-frr-algorithm]
Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "Algorithms for computing Maximally Redundant
Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr-
algorithm-05 (work in progress), July 2015.
[I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
A., Tantsura, J., and R. White, "An Architecture for IP/
LDP Fast-Reroute Using Maximally Redundant Trees", draft-
ietf-rtgwg-mrt-frr-architecture-05 (work in progress),
January 2015.
[RFC5036]
Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5561]
Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, DOI
10.17487/RFC5561, July 2009, <http://www.rfc-
editor.org/info/rfc5561>.
[RFC6420]
Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join
Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011,
<http://www.rfc-editor.org/info/rfc6420>.
[RFC7307]
Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
King, "LDP Extensions for Multi-Topology", RFC 7307, DOI
10.17487/RFC7307, July 2014, <http://www.rfc-
editor.org/info/rfc7307>.
AGV Expires April 11, 2016 [Page 7]
INTERNET DRAFT MRT in Segment Routing October 9, 2015
5.2. Informative References
[I-D.atlas-rtgwg-mrt-mc-arch]
Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G.
Envedi, "An Architecture for Multicast Protection Using
Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc-
arch-02 (work in progress), July 2013.
[I-D.ietf-isis-mrt]
Li, Z., Wu, N., Zhao, 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-00 (work in progress), February 2015.
[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-00 (work in progress), January 2015.
[I-D.wijnands-mpls-mldp-node-protection]
Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas,
A., and Q. Zhao, "mLDP Node Protection", draft-wijnands-
mpls-mldp-node-protection-04 (work in progress), June
2013.
[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>.
Authors' Addresses
Anil Kumar S N
Huawei Technologies India Pvt. Ltd,
Near EPIP Industrial Area,
Kundalahalli Village,
Whitefield,
Bangalore - 560037
EMail: anil.sn@huawei.com
Gaurav Agrawal
AGV Expires April 11, 2016 [Page 8]
INTERNET DRAFT MRT in Segment Routing October 9, 2015
Huawei Technologies India Pvt. Ltd,
Near EPIP Industrial Area,
Kundalahalli Village,
Whitefield,
Bangalore - 560037
EMail: gaurav.agrawal@huawei.com
Vinod Kumar S
Huawei Technologies India Pvt. Ltd,
Near EPIP Industrial Area,
Kundalahalli Village,
Whitefield,
Bangalore - 560037
EMail: vinods.kumar@huawei.com
AGV Expires April 11, 2016 [Page 9]