< draft-ietf-isis-mrt-00.txt   draft-ietf-isis-mrt-01.txt >
Network Working Group Z. Li Network Working Group Z. Li
Internet-Draft N. Wu Internet-Draft N. Wu
Intended status: Standards Track Q. Zhao Intended status: Standards Track Q. Zhao
Expires: August 13, 2015 Huawei Technologies Expires: April 21, 2016 Huawei Technologies
A. Atlas A. Atlas
C. Bowers C. Bowers
Juniper Networks Juniper Networks
J. Tantsura J. Tantsura
Ericsson Ericsson
February 9, 2015 October 19, 2015
Intermediate System to Intermediate System (IS-IS) Extensions for Intermediate System to Intermediate System (IS-IS) Extensions for
Maximally Redundant Trees (MRT) Maximally Redundant Trees (MRT)
draft-ietf-isis-mrt-00 draft-ietf-isis-mrt-01
Abstract Abstract
This document describes necessary extensions to IS-IS to support the This document describes extensions to IS-IS to support the
distributed computation of Maximally Redundant Trees (MRT). Some distributed computation of Maximally Redundant Trees (MRT). Example
example uses of the MRTs include IP/LDP Fast-Reroute and global uses of MRT include IP/LDP Fast-Reroute and global protection or
protection or live-live for multicast traffic. The extensions live-live for multicast traffic. The extensions indicate what MRT
indicate what MRT profile(s) each router supports. Different MRT profile(s) each router supports. Different MRT profiles can be
profiles can be defined to support different uses and to allow defined to support different uses and to allow transition of
transition of capabilities. An extension is introduced to flood MRT- capabilities. An extension is introduced to flood MRT-Ineligible
Ineligible links, due to administrative policy. links, due to administrative policy. This document also defines the
Controlled Convergence sub-TLV, which is useful for MRT FRR as well
as other applications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 13, 2015. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Using MRT with Multi-Topology IGP Routing . . . . . . . . . . 4 4. Overview of IS-IS Signalling Extensions for MRT . . . . . . . 4
5. Overview of IS-IS Signaling Extensions for MRT . . . . . . . 5 4.1. Supporting MRT Profiles . . . . . . . . . . . . . . . . . 4
5.1. Supporting MRT Profiles . . . . . . . . . . . . . . . . . 6 4.2. Selecting the GADAG Root . . . . . . . . . . . . . . . . 4
5.2. Electing GADAG Root . . . . . . . . . . . . . . . . . . . 6 4.3. Advertising MRT-Ineligible Links for MRT . . . . . . . . 5
5.3. Advertising MRT-Ineligible Links for MRT . . . . . . . . 7 4.4. Triggering an MRT Computation . . . . . . . . . . . . . . 5
5.4. Triggering an MRT Computation . . . . . . . . . . . . . . 7 5. MRT Capability Advertisement . . . . . . . . . . . . . . . . 5
6. MRT Capability Advertisement . . . . . . . . . . . . . . . . 7 5.1. MRT Profile sub-TLV in the IS-IS Router CAPABILITY TLV . 6
6.1. Advertising MRT Capability in IS-IS LSP . . . . . . . . . 7 5.1.1. A note on the M-bit in OSPF . . . . . . . . . . . . . 7
6.2. MRT Profile sub-TLV in IS-IS Router CAPABILITY TLV . . . 8 5.2. MRT-Ineligible Link sub-TLV in the Extended IS
6.3. MRT-Ineligible Links sub-TLV in IS-IS Router CAPABILITY Reachability TLV . . . . . . . . . . . . . . . . . . . . 7
TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. A Note on Multi-Topology Routing . . . . . . . . . . . . 8
7. Controlled Convergence sub-TLV in IS-IS Router CAPABILITY TLV 10 6. Controlled Convergence sub-TLV in IS-IS Router CAPABILITY TLV 8
8. Handling MRT Capability Sending and Receiving . . . . . . . . 11 7. Handling MRT Extensions . . . . . . . . . . . . . . . . . . . 10
8.1. Advertising MRT extension . . . . . . . . . . . . . . . . 12 7.1. Advertising MRT extensions . . . . . . . . . . . . . . . 10
8.2. Parsing MRT extension . . . . . . . . . . . . . . . . . . 12 7.2. Processing MRT extensions . . . . . . . . . . . . . . . . 10
9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12 8. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.1. MRT Profile and Controlled Convergence sub-TLVs . . . . 11
13.2. Infomative References . . . . . . . . . . . . . . . . . 14 12.2. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
13.1. Normative References . . . . . . . . . . . . . . . . . . 12
13.2. Infomative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The IS-IS protocol is specified in [ISO10589], with extensions for The IS-IS protocol is specified in [ISO10589], with extensions for
supporting IPv4 and IPv6 specified in [RFC1195] and [RFC5308]. Each supporting IPv4 and IPv6 specified in [RFC1195] and [RFC5308]. Each
Intermediate System (IS) (router) advertises one or more IS-IS Link Intermediate System (IS) (router) advertises one or more IS-IS Link
State Protocol Data Units (LSPs) with routing information. Each LSP State Protocol Data Units (LSPs) with routing information. Each LSP
is composed of a fixed header and a number of tuples, each consisting is composed of a fixed header and a number of tuples, each consisting
of a Type, a Length, and a Value. Such tuples are commonly known as of a Type, a Length, and a Value. Such tuples are commonly known as
TLVs, and are a good way of encoding information in a flexible and TLVs, and are a good way of encoding information in a flexible and
extensible format. extensible format.
[I-D.ietf-rtgwg-mrt-frr-architecture] gives a complete solution for [I-D.ietf-rtgwg-mrt-frr-architecture] gives a complete solution for
IP/LDP fast-reroute using Maximally Redundant Trees (MRT) to provide IP/LDP fast-reroute using Maximally Redundant Trees (MRT) to provide
alternates. This document describes the necessary signaling alternates. This document describes signalling extensions for
extensions for supporting MRT-FRR used in IS-IS routing domain. supporting MRT-FRR in an IS-IS routing domain.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
Redundant Trees (RT): A pair of trees where the path from any node X Redundant Trees (RT): A pair of trees where the path from any node X
skipping to change at page 4, line 13 skipping to change at page 4, line 13
Specifically, MRT-Red is the decreasing MRT where links in the GADAG Specifically, MRT-Red is the decreasing MRT where links in the GADAG
are taken in the direction from a higher topologically ordered node are taken in the direction from a higher topologically ordered node
to a lower one. to a lower one.
MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is
used to describe the associated forwarding topology and MT-ID. used to describe the associated forwarding topology and MT-ID.
Specifically, MRT-Blue is the increasing MRT where links in the GADAG Specifically, MRT-Blue is the increasing MRT where links in the GADAG
are taken in the direction from a lower topologically ordered node to are taken in the direction from a lower topologically ordered node to
a higher one. a higher one.
4. Using MRT with Multi-Topology IGP Routing 4. Overview of IS-IS Signalling Extensions for MRT
Both IS-IS and OSPF have support for multi-topology routing (see
[RFC5120] for ISIS and [RFC4915] for OSPF.) In addition to the
standard topology (identified by MT-ID=0), these extensions allow the
IGP to identify particular links and nodes as participating in
additional topologies (identified by MT-ID!=0). A given link can
belong to several topologies and be assigned different metrics in
each topology. The IGP runs an independent SPF computation for each
topology, finding independent shortest paths to prefixes in each
topology.
It is straightforward to extend the MRT computations to multi-
topology IGP routing. For each IGP topology identified by an IGP MT-
ID, we need to identify the node and links belonging to an MRT Island
for that IGP MT-ID. This process creates a graph for the MRT Island
for that specific IGP MT-ID, which can then be used to compute the
transit next-hops and alternate next-hops for MRT-Red and MRT-Blue
for that specific IGP MT-ID.
We expect that initial implementation and deployments of MRT will be
primarily concerned with computing MRT-Red and Blue trees for the
standard topology (IGP MT-ID=0). However, we have chosen to specify
the IS-IS MRT extensions to accommodate the computation of MRT-Red
and MRT-Blue in a multi-topology IS-IS environment. This comes at
the expense of 2-6 octets per TLV for MT-ID values, but it will allow
for standards-based multi-topology aware MRT implementations for ISIS
without any future standards work.
Using MRT in a multi-topology IGP environment does have one
complication which should be discussed. Forwarding LDP traffic over
MRT paths in the standard IGP topology requires the use of labels
bound to topology-scoped FECs to identify traffic on MRT-Red and Blue
trees. This is described in Section 6 of
[I-D.ietf-rtgwg-mrt-frr-architecture]. To facilitate this, an MRT
profile specifies IANA-assigned MRT-Red and MRT-Blue LDP MT-ID
values, which are then used by LDP to advertise labels for the MRT-
Red and Blue forwarding topologies. Note that the MRT-Red and MRT-
Blue LDP MT-ID values assigned by IANA for a given MRT profile
correspond to the MRT-Red and Blue forwarding trees associated with
the standard IGP topology with IGP MT-ID=0. For example, suppose
that a future MRT profile X is assigned (hypothetical) MRT-Red and
MRT-Blue LDP MT-ID values of 2001 and 2002. Then labels for shortest
path forwarding trees associated with the standard IGP topology will
be advertised using FECs with MT-ID=0, while the labels for the MRT-
Red and Blue forwarding trees for profile X will be advertised using
FECS with MT-ID=2001 and 2002, respectively. In the absence of
multi-topology IGP routing, all MT-IDs used by LDP for MRT are
assigned by IANA, so there are no potential conflicts in LDP MT-ID
usage.
When MRT is used together with multi-topology IGP routing, additional
LDP MT-IDs need to be specified for carrying traffic on the MRT-Red
and Blue forwarding trees associated with the additional IGP routing
topologies. Building on the previous example, suppose that a network
is configured with an additional IGP routing topology using MT-ID=20,
in addition to the standard topology with MT-ID=0. The router
advertises support for MRT with respect to MT-ID=20 with profile X,
as well as support for MRT with respect to MT-ID=0 with profile X.
The MRT-Red and Blue LDP MT-IDs for MT-ID=0 with profile X are still
inherited from profile X, as in the previous example. In order to
use LDP to create the MRT-Red and Blue forwarding trees for the IGP
topology with MT-ID=20, the router could, for example, advertise MRT-
Red and MRT-Blue LDP MT-ID values of 21 and 22 for IGP MT-ID=20 and
profile X. This overrides the (hypothetical) IANA-assigned values
MRT-Red and MRT-Blue LDP MT-ID values for profile X, but maintains
all other properties of profile X. Care must be taken to avoid
advertising LDP MT-ID values that conflict with implicitly advertised
IANA-assigned values LDP MT-ID.
The semantics of the IS-IS MRT extensions in this document are
designed to handle the most common case (MRT in the absence of multi-
topology IGP routing) in a simple manner. Setting the IGP MT-ID
field as well as the MRT-Blue and MRT-Red LDP MT-ID fields to 0 in
the TLV and sub-TLVs in this document results in the desired behavior
for the standard IGP topology.
5. Overview of IS-IS Signaling Extensions for MRT
As stated in [I-D.ietf-rtgwg-mrt-frr-algorithm], it is necessary for As stated in [I-D.ietf-rtgwg-mrt-frr-algorithm], it is necessary for
each MRT-Capable router to compute MRT next hops in a consistent each MRT-Capable router to compute MRT next hops in a consistent
fashion. This is achieved by using same MRT profile and selecting fashion. This is achieved by using the same MRT profile and
the unique root in a MRT Island which is connected by MRT-Eligible selecting a common and unique GADAG root in the MRT Island which is
links. Each of these issues will be discussed in following sections connected by MRT-Eligible links. Each of these issues will be
separately. discussed in the following sections separately.
5.1. Supporting MRT Profiles 4.1. Supporting MRT Profiles
The contents and requirements of an MRT profile has been defined in The contents and requirements of an MRT profile has been defined in
[I-D.ietf-rtgwg-mrt-frr-architecture]. The parameters and behavioral [I-D.ietf-rtgwg-mrt-frr-architecture]. The parameters and behavioral
rules contained in an MRT profile define one router's MRT rules contained in an MRT profile define one router's MRT
capabilities. Based on common capabilities, one unified MRT Island capabilities. Based on common capabilities, one unified MRT Island
is built. is built.
The MRT-Capable router MUST advertise its corresponding MRT profiles The MRT-Capable router MUST advertise its corresponding MRT profiles
by IS-IS protocol extension within IS-IS routing domain. The by IS-IS protocol extension within IS-IS routing domain. The
capabilities of advertiser MUST conform to the profile it claimed capabilities of the advertiser MUST completely conform to the profile
completely, especially the MT-IDs, the algorithm and the it claimed, including the MT-IDs, the algorithm and the corresponding
corresponding forwarding mechanism. This advertisement MUST have forwarding mechanism. This advertisement MUST have level scope. A
level scope. One router MAY support multiple MRT profiles and it given router MAY support multiple MRT profiles. If so, it MUST
MUST advertise these profiles in corresponding IS-IS level. The MT- advertise each of these profiles in the corresponding IS-IS level.
IDs used in one supported MRT Profile MUST NOT overlap with those MT-
IDs used in a different supported MRT Profile.
The default MRT Profile is defined in The default MRT Profile is defined in
[I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to [I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to
support IP/LDP unicast and multicast Fast-Reroute. MRT-Capable support IP/LDP unicast and multicast Fast-Reroute. MRT-Capable
routers SHOULD support the default MRT profile. routers SHOULD support the default MRT profile.
5.2. Electing GADAG Root 4.2. Selecting the GADAG Root
As per [I-D.ietf-rtgwg-mrt-frr-algorithm], a GADAG root MUST be As per [I-D.ietf-rtgwg-mrt-frr-algorithm], a GADAG root MUST be
selected for one MRT Island. An unique GADAG root in common-sense selected for one MRT Island. An unique GADAG root in common among
among MRT Island routers is a necessity to do MRT computation. Since MRT Island routers is a necessity to do MRT computation. Since the
the selection of the GADAG root can affect the alternates and the selection of the GADAG root can affect the quality of paths for
traffic through it, the selection rules give network operator a knob traffic sent over MRT Red and Blue trees, the GADAG Root Selection
to control the alternates and the traffic inside the MRT Island. Priority and the GADAG Root Selection Policy gives a network operator
Relevant discussion for the relationship between GADAG root role and the ability to influence the selection of the GADAG root.
MRT Island alternates is out of the scope of this document.
Each MRT-Capable router MUST advertise its priority for GADAG root Each MRT-Capable router MUST advertise its priority for GADAG root
selection. One router can only have one priority in the same MRT selection. A router can only have one priority in a given MRT
Island. It can have multiple priorities for different MRT Islands it Island. It can have multiple priorities for different MRT Islands it
supports. Routers that are marked as overloaded([RFC3787]) are not supports. Routers that are marked as overloaded([RFC3787]) are not
qualified as candidate for root selection. qualified as candidate for root selection.
The GADAG Root Selection Policy (defined as part of an MRT profile) The GADAG Root Selection Policy (defined as part of an MRT profile)
may make use of the GADAG Root Selection Priority value advertised in may make use of the GADAG Root Selection Priority value advertised in
the MRT Profile in the IS-IS Router CAPABILITY TLV. For example, the the MRT Profile in the IS-IS Router CAPABILITY TLV. For example, the
GADAG Root Selection Policy for the default MRT profile is the GADAG Root Selection Policy for the default MRT profile is the
following: Among the routers in the MRT Island and with the highest following: Among the routers in the MRT Island and with the highest
priority advertised, an implementation MUST pick the router with the priority advertised, an implementation MUST pick the router with the
highest Router ID to be the GADAG root. highest Router ID to be the GADAG root.
When the current root is out of service or new router with higher When the current root is out of service or new router with higher
priority joined into the MRT Island, the GADAG root MUST be re- priority joined into the MRT Island, the GADAG root MUST be re-
selected. A new MRT computation will be triggered because of such a selected. A new MRT computation will be triggered because of such a
topology change. topology change.
5.3. Advertising MRT-Ineligible Links for MRT 4.3. Advertising MRT-Ineligible Links for MRT
For certain administrative or management reason, some links may not For administrative or management reasons, it may be desirable to
be involved into MRT computation. In this scenario, MRT-Capable exclude some links from the MRT computation. In this scenario, MRT-
router MUST claim those MRT-Ineligible links are out of MRT Island Capable router MUST claim those MRT-Ineligible links are out of MRT
scope. If such claim splits current MRT Island then MRT computation Island scope. If such claim splits current MRT Island then MRT
has to be done inside the modified MRT Island which the computing computation has to be done inside the modified MRT Island which the
router belongs to. computing router belongs to.
5.4. Triggering an MRT Computation 4.4. Triggering an MRT Computation
A MRT Computation can be triggered through topology changes or MRT A MRT Computation can be triggered through topology changes or MRT
capability changes of any router in the MRT Island. It is always capability changes of any router in the MRT Island. It is always
triggered for a given MRT Profile in the corresponding level. First, triggered for a given MRT Profile in the corresponding level. First,
the associated MRT Island is determined. Then, the GADAG Root is the associated MRT Island is determined. Then, the GADAG Root is
selected. Finally, the actual MRT algorithm is run to compute the selected. Finally, the actual MRT algorithm is run to compute the
transit MRT-Red and MRT-Blue topologies. Additionally, the router transit MRT-Red and MRT-Blue topologies. Additionally, the router
MAY choose to compute MRT-FRR alternates or make other use of the MRT MAY choose to compute MRT-FRR alternates or make other use of the MRT
computation results. computation results.
Prefixes can be attached and detached and have their associated MRT- Prefixes can be attached and detached and have their associated MRT-
Red and MRT-Blue next-hops computed without requiring a new MRT Red and MRT-Blue next-hops computed without requiring a new MRT
computation. computation.
6. MRT Capability Advertisement 5. MRT Capability Advertisement
MRT-Capable router MUST identify its MRT capabilities through IS-IS
Link State Packet(LSP) in level scope.
6.1. Advertising MRT Capability in IS-IS LSP
One new M-bit is introduced into TLV 229 to identify router is MRT- An MRT-Capable router MUST identify its MRT capabilities through IS-
Capable. Structure of TLV 229 is stated in [RFC5120] as pictured IS Link State Packets(LSPs) in level scope.
below:
TYPE: 229 5.1. MRT Profile sub-TLV in the IS-IS Router CAPABILITY TLV
LENGTH: total length of the value field, it SHOULD be 2 times the A new MRT Profile sub-TLV is introduced into the IS-IS Router
number of MT components. CAPABILITY TLV (TLV #242 defined in [RFC4971]) to advertise MRT
capabilities. Since MRT has per level scope, the S-bit and D-bit of
IS-IS Router CAPABILITY TLV MUST be set to zero. The structure of
the MRT Profile sub-TLV is shown below:
VALUE: one or more 2-byte MT components, structured as follows: TYPE: TBA-MRT-ISIS-1 (To Be Allocated by IANA)
No. of Octets LENGTH: 4
+--------------------------------+
|O |A |M |R | MT ID | 2
+--------------------------------+
Bit M identifies the originator is of MRT-Capable. The MRT-Blue and VALUE:
the MRT-Red alternates will be calculated for the MT identified by
MT-ID.
This M-bit MUST be set and checked in LSP fragment 0. A MRT-Capable MT-ID (2 octets with 4 bits reserved)
router MUST advertise this TLV with M-bit set for corresponding MT.
For instance, if M-bit is set for MT-ID #0, MRT alternates will be
calculated for standard topology.
If only M-bit is advertised for MRT-Capabilities without any other MRT Profile ID (1 octet)
MRT information then the router is regarded as supporting default MRT
profile with default GADAG root selection priority.
6.2. MRT Profile sub-TLV in IS-IS Router CAPABILITY TLV GADAG Root Selection Priority (1 octet)
A new MRT Profile sub-TLV is introduced into IS-IS Router CAPABILITY Number of octets
TLV[RFC4971] to advertise MRT capabilities. Since MRT is per level +-------------------------------+
scope, the S-bit and D-bit of IS-IS Router CAPABILITY TLV MUST be set |R |R |R |R | MT-ID | 2
to zero. The structure of the MRT Profile sub-TLV is pictured as +-------------------------------+
below: | MRT Profile ID | 1
+-------------------------------+
| GADAG Root Selection Priority | 1
+-------------------------------+
TYPE: TBA-MRT-ISIS-1 (To Be Allocated by IANA) MT-ID is a 12-bit field containing the multi-topology ID. As
discussed in Section 5.3, this document specifies that the MT-ID
field MUST be set to zero.
LENGTH: 8 The MRT Profile ID represents the MRT profile this router supports.
VALUE: The GADAG Root Selection Priority is the priority for selection as
GADAG root. A router advertising the MRT Profile sub-TLV MUST
specify a GADAG Root Selection Priority. The range of this priority
is [0, 255]. The RECOMMENDED default value of the GADAG Root
Selection Priority is 128. The GADAG Root Selection Policy defined
as part of a given MRT profile determines how the GADAG Root
Selection Priority value is used.
MT ID (2 octet with 4 bits reserved) This sub-TLV can occur multiple times if a router supports multiple
MRT profiles. This can happen during a network transition. Or it
can be used to support different uses of MRT within the same network
which may perform better with different profiles.
Profile ID (1 octet) A given router SHOULD NOT advertise multiple MRT Profile sub-TLVs
with the same MRT profile ID. If a router receives multiple MRT
Profile sub-TLVs with the same MRT profile ID from the same
originator, it MUST use one with the lowest value of GADAG Root
Selection Priority.
MRT-Red LDP MT-ID (2 octet) 5.1.1. A note on the M-bit in OSPF
MRT-Blue LDP MT-ID (2 octet) [I-D.ietf-ospf-mrt] defines MRT signalling extensions for OSPF. In
+--------------------------------+ addition to the OSPF version of MRT Profile sub-TLV (which is carried
|R |R |R |R | MT ID | 2 in the OSPF Router Information LSA), it also defines the M-bit (which
+----------------+---------------+ is carried in the OSPF Router-LSA.) As discussed in
| Profile ID | 1 [I-D.ietf-ospf-mrt], the M-bit in the Router-LSA ensures that all
+----------------+ routers in the area have up-to-date information if a router is
| GADAG Priority | 1 downgraded to a software version that does not support MRT and the
+----------------+---------------+ Router Information LSA.
| MRT-Red LDP MT-ID | 2
+--------------------------------+
| MRT-Blue LDP MT-ID | 2
+--------------------------------+
12-bit MT ID represents the base MT topology which MRT computation is The problematic scenario that requires the M-bit in the OSPF Router-
based on. Profile ID represents the MRT profile this router supports LSA does not occur in IS-IS. The presence or absence of an IS-IS
and GADAG Root Selection Priority is the priority for root selection. Router CAPABILITY TLV containing a given MRT Profile sub-TLV in the
The range of this priority is [0, 255] with 128 as the default value. IS-IS Link State PDU provides enough information for all routers to
The GADAG Root Selection Policy defined as part of a given MRT determine which remote routers support MRT, even after a software
profile determine how the GADAG Root Selection Priority value is version downgrade of remote routers. Therefore, this document does
used. not define a corresponding M-bit for IS-IS.
If the MRT-Blue LDP MT-ID is 0, then the value specified in the 5.2. MRT-Ineligible Link sub-TLV in the Extended IS Reachability TLV
associated MRT Profile is assumed. If the MRT-Red LDP MT-ID is 0,
then the value specified in the associated MRT profile is assumed.
The MRT-Blue LDP MT-ID and MRT-Red LDP MT-ID MUST NOT be the reserved
values for LDP MT-IDs ([I-D.ietf-mpls-ldp-multi-topology] ). The
value for MRT-Blue LDP MT-ID and MRT-Red LDP MT-ID MUST be different
except for 0. As stated above, the MRT-Blue LDP MT-ID and MRT-Red
LDP MT-ID MUST NOT overlap among profiles if multiple MRT-Profile
sub-TLVs are advertised.
This sub-TLV can occur multiple times if this router support multiple As a matter of policy, an operator may choose to mark some links as
MRT profiles. This can happen during transition or to support ineligible for carrying MRT traffic. For instance, policy can be
multiple uses of MRT which prefer different profiles. made to prevent fast-rerouted traffic from taking those links.
6.3. MRT-Ineligible Links sub-TLV in IS-IS Router CAPABILITY TLV For a link to be marked as ineligible for use in the MRT calculation,
it MUST be advertised including the MRT-Ineligible Link sub-TLV in
the Extended IS Reachability TLV (TLV #22 defined in [RFC5305] )
corresponding to the ineligible link. The MRT-Ineligible Link sub-
TLV is a zero-length sub-TLV as shown below:
As a matter of policy, some links may not be available for the MRT TYPE: TBA-MRT-ISIS-2 (To Be Allocated by IANA)
computation, which can prevent alternates or traffic using these
links. For instance, policy can be made to prevent fast-rerouted
traffic from taking those links.
For a link to be excluded from the MRT computation, it MUST be LENGTH: 0
advertised as sub-TLV in IS-IS Router CAPABILITY TLV which is in
level scope with S-bit and D-bit unset. The MRT-Ineligible Link sub-
TLV is structured as below:
TYPE: TBA-MRT-ISIS-2 (To Be Allocated by IANA) VALUE: None
LENGTH: from 9 to 255 octets
VALUE: The presence of the zero-length MRT-Ineligible Link sub-TLV in the
Extended IS Reachability TLV indicates that the associated link MUST
NOT be used in the MRT calculation for the default topology for all
profiles.
MT ID (2 octet with 4 bits reserved) 5.3. A Note on Multi-Topology Routing
System ID and pseudo-node number (7 octet for each MRT-Ineligible [RFC5120] specifies how to support multi-topology routing in IS-IS.
Link) The current document specifies how to signal support for MRT in the
default routing topology only. The format of the extensions in this
document allows the MRT Profile sub-TLV and the MRT-Ineligible Link
sub-TLV to be scoped to topologies with non-zero MT-ID at some point
in future. However, this document restricts these extensions to
apply only to the default topology. The MRT Profile sub-TLV is
restricting by explicitly requiring the MT-ID field to be set to
zero. The MRT-Ineligible Link sub-TLV is restricted by only allowing
it to be included in the Extended IS Reachability TLV (TLV#22) which
is scoped to the default topology, and not allowing it to appear
TLV#222 (the topology-scoped version of the Extended IS Reachability
TLV).
No. of Octets Lifting these restrictions is for further study. Note that the MRT
+--------------------------------+ signalling extensions in this document can co-exist with IS-IS multi-
|R |R |R |R | MT ID | 2 topology routing, with the limitation that MRT Red and Blue
+--------------------------------+ forwarding trees can only be built for the default topology.
|System ID and pseudonode number | 7
+--------------------------------+
| Default metric | 3
+--------------------------------+
. .
. .
+--------------------------------+
|System ID and pseudonode number | 7
+--------------------------------+
| Default metric | 3
+--------------------------------+
Each MRT-Ineligible Link is identified by neighbor's System ID and The format of the Controlled Convergence sub-TLV (discussed below)
pseudo-node number and Default metric, same as IS Reachability TLV. also contains an MT-ID field, allowing a Controlled Convergence sub-
This sub-TLV MAY occur multiple times if multiple links are TLV to be scoped to a particular topology. This document does not
ineligible. place restrictions on the MT-ID field in the Controlled Convergence
sub-TLV. The Controlled Convergence sub-TLV has potential
applications that are not limited to MRT, and a topology-scoped FIB
compute/install time makes sense on its own.
7. Controlled Convergence sub-TLV in IS-IS Router CAPABILITY TLV 6. Controlled Convergence sub-TLV in IS-IS Router CAPABILITY TLV
Section 12.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the Section 12.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the
need to wait for a configured or advertised period after a network need to wait for a configured or advertised period after a network
failure to insure that all routers are using their new SPTs. failure to insure that all routers are using their new shortest path
Similarly, avoiding micro-forwarding loops during convergence trees. Similarly, avoiding micro-forwarding loops during convergence
[RFC5715] requires determining the maximum among all routers in the [RFC5715] requires determining the maximum among all routers in the
area of the worst-case route computation and FIB installation time. area of the worst-case route computation and FIB installation time.
More details on the specific reasoning and need for flooding this More details on the specific reasoning and need for flooding this
value are given in [I-D.atlas-bryant-shand-lf-timers]. value are given in [I-D.atlas-bryant-shand-lf-timers].
A new Controlled Convergence sub-TLV is introduced into the IS-IS A new Controlled Convergence sub-TLV is introduced into the IS-IS
Router CAPABILITY TLV [RFC4971] to advertise the worst-case time for Router CAPABILITY TLV (TLV #242 defined in [RFC4971]) to advertise
a router to compute and install all IS-IS routes in the level after a the worst-case time for a router to compute and install all IS-IS
change to a stable network. This advertisement has per level scope, routes in the level after a change to a stable network. This
so the S-bit and D-bit of IS-IS Router CAPABILITY TLV MUST be set to advertisement has per level scope, so the S-bit and D-bit of IS-IS
zero. The advertisement is scoped by IGP MT-ID, allowing a router Router CAPABILITY TLV MUST be set to zero. The advertisement is
supporting multi-topology IGP routing to advertise a different worst- scoped by MT-ID, allowing a router supporting multi-topology routing
case compute and install time for each IGP topology. This make sense to advertise a different worst-case FIB compute/install time for each
as the SPF computations for each IGP topology are independent of one topology. This makes sense as the SPF computations and FIB
another, and may have different worst-case compute and install times. installations for each IGP topology can potentially be done
independently of one another, and may have different worst-case
compute and install times.
The structure of the Controlled Convergence sub-TLV is shown below: The structure of the Controlled Convergence sub-TLV is shown below:
TYPE: TBA-MRT-ISIS-3 (To Be Allocated by IANA) TYPE: TBA-MRT-ISIS-3 (To Be Allocated by IANA)
LENGTH: 3 LENGTH: 3
VALUE: VALUE:
MT ID (2 octet with 4 bits reserved) MT-ID (2 octets with 4 bits reserved)
FIB compute/install time (1 octet) FIB compute/install time (1 octet)
+--------------------------------+ Number of octets
|R |R |R |R | MT ID | 2 +-------------------------------+
+----------------+---------------+ |R |R |R |R | MT-ID | 2
|FIB comp/in time| 1 +-------------------------------+
+----------------+ | FIB compute/install time | 1
+-------------------------------+
MT-ID is a 12-bit field containing the multi-topology ID.
The FIB compute/install time is the worst-case time the router may The FIB compute/install time is the worst-case time the router may
take to compute and install all IS-IS routes in the level after a take to compute and install all IS-IS routes in the level after a
change to a stable network. The value is in milliseconds. change to a stable network. The value is an unsigned integer in
units of milliseconds.
The FIB compute/install time value sent by a router SHOULD be an The FIB compute/install time value sent by a router SHOULD be an
estimate taking into account network scale or real-time measurements, estimate taking into account network scale or real-time measurements,
or both. Advertisements SHOULD be dampened to avoid frequent or both. Advertisements SHOULD be dampened to avoid frequent
communication of small changes in the FIB compute/install time. communication of small changes in the FIB compute/install time.
A router receiving the Controlled Convergence sub-TLV SHOULD estimate A router receiving the Controlled Convergence sub-TLV SHOULD estimate
the network convergence time as the maximum of the FIB compute/ the network convergence time as the maximum of the FIB compute/
install times advertised by the routers in a level, including itself. install times advertised by the routers in a level for a given MT-ID,
In order to account for routers that do not advertise the Controlled including itself. In order to account for routers that do not
Convergence sub-TLV, a router MAY use a locally configured minimum advertise the Controlled Convergence sub-TLV, a router MAY use a
network convergence time as a lower bound on the computed network locally configured minimum network convergence time as a lower bound
convergence time. A router MAY use a locally configured maximum on the computed network convergence time. A router MAY use a locally
network convergence time as an upper bound on the computed network configured maximum network convergence time as an upper bound on the
convergence time. computed network convergence time.
8. Handling MRT Capability Sending and Receiving
The M-bit which identifies router's MRT capability MUST be advertised 7. Handling MRT Extensions
in LSP fragment 0. Those MRT related sub-TLVs SHOULD be ignored when
MRT Capability bit is unset. When changes in MRT capabilities are
received, a MRT computation SHOULD be triggered but MAY be delayed
for a while to allow reception of all MRT-related information.
8.1. Advertising MRT extension 7.1. Advertising MRT extensions
MRT sub-TLVs are encapsulated in the Router Capability TLV and MRT sub-TLVs are encapsulated in the Router Capability TLV and
advertised through LSP PDU for the level-wide. MRT sub-TLVs are advertised using the LS-PDU with level-wide scope. MRT sub-TLVs are
optional. If one router does not support MRT, it MUST NOT advertise optional. If one router does not support MRT, it MUST NOT advertise
those sub-TLVs. those sub-TLVs.
Since the advertisement scope of the MRT sub-TLV is level-wide, the Since the advertisement scope of the MRT sub-TLV is level-wide, the
D-Bit and S-Bit of the Router Capability TLV MUST be set as 0 when it D-Bit and S-Bit of the Router Capability TLV MUST be set as 0 when it
is advertised. If other sub-TLVs in the Router Capability TLV need is advertised. If other sub-TLVs in the Router Capability TLV need
different values for those two bits, there MUST be an independent different values for those two bits, then the router MUST originate
Router Capability TLV for MRT sub-TLVs. multiple Router Capability TLVs with different bit values.
When MRT related information is changed for the router or existing When MRT-related information is changed for the router or existing
IS-IS LSP mechanisms are triggered for refreshing or updating, MRT IS-IS LSP mechanisms are triggered for refreshing or updating, MRT
sub-TLVs MUST be advertised if the router is MRT-Capable. sub-TLVs MUST be advertised if the router is MRT-Capable.
For administrative policies or reasons, it may be desirable to Based on administrative policy, it may be desirable to exclude
exclude certain links from the MRT computation. MRT-Ineligible sub- certain links from the MRT computation. The MRT-Ineligible sub-TLV
TLV is used to advertise which links should be excluded. Note that is used to advertise which links should be excluded. Note that an
an interface advertised as MRT-Ineligigle by a router is ineligible interface advertised as MRT-Ineligible by a router is ineligible with
with respect to all profiles advertised by that router. respect to all profiles advertised by that router.
8.2. Parsing MRT extension 7.2. Processing MRT extensions
MRT extension MUST NOT affect the peer setup and the routing The processing associated with MRT extensions SHOULD NOT
calculation of the standard topology. significantly degrade IS-IS adjacency formation and maintenance or
the routing calculation for normal shortest path routes.
MRT sub-TLVs SHOULD be validated like other sub-TLVs when received. MRT sub-TLVs SHOULD be validated like other sub-TLVs when received.
MRT sub-TLVs SHOULD also be taken for the checksum calculation and MRT sub-TLVs SHOULD also be taken into account for checksum
authentication. calculations and authentication.
If MT-ID conflict is found for MRT-Red or MRT-blue from multiple sub- Links advertised as MRT-ineligible using the MRT-Ineligible sub-TLV
TLVs then those associated sub-TLVs MUST be ignored. MUST be excluded from the MRT computation. The removal of individual
links from the MRT Island can partition an MRT Island or it can
significantly modify the construction of the GADAG and the result MRT
Red and Blue trees. Therefore, all routers must perform the same
computation using the same set of links.
Links advertised in MRT-Ineligible sub-TLV MUST be precluded from MRT 8. Backward Compatibility
Computation. The removal of those links may change the computing
router's MRT Island significantly.
9. Backwards Compatibility The MRT Profile sub-TLV, the MRT-Ineligible Link sub-TLV, and the
Controlled Convergence sub-TLV defined in this document are
compatible with existing implementations of IS-IS. Routers that do
not support these extensions are expected to silently ignore them.
The M-bit for MRT capability, the MRT Profile sub-TLV and the MRT- Router that do support these extensions have mechanisms to recognize
Ineligible Link sub-TLV defined in this document SHOULD NOT introduce routers that don't support these extensions (or are not configured to
any interoperability issues. Routers that do not support these MRT participate in MRT) and behave accordingly.
extensions SHOULD silently ignore them. Alternates or traffic MUST
NOT be affected in current IS-IS routing domain.
10. Implementation Status 9. Implementation Status
[RFC Editor: please remove this section prior to publication.] [RFC Editor: please remove this section prior to publication.]
Please see [I-D.ietf-rtgwg-mrt-frr-architecture] for details on Please see [I-D.ietf-rtgwg-mrt-frr-architecture] for details on
implementation status. implementation status.
11. Security Considerations 10. Security Considerations
This IS-IS extension is not believed to introduce new security The IS-IS extensions in this document do not introduce new security
concerns. concerns.
11. Acknowledgements
The authors would like to thank Shraddha Hegde for her useful
suggestions.
12. IANA Considerations 12. IANA Considerations
Please allocate values for the following IS-IS Router CAPABILITY TLV 12.1. MRT Profile and Controlled Convergence sub-TLVs
Types [RFC4971]: MRT Profile sub-TLV (TBA-MRT-ISIS-1), MRT-Ineligible
Link sub-TLV (TBA-MRT-ISIS-2), and Controlled Convergence sub-TLV IANA is requested to allocate values for the following sub-TLVs types
(TBA-MRT-ISIS-3). in the IS-IS Router CAPABILITY TLV defined in [RFC4971]: the MRT
Profile sub-TLV (TBA-MRT-ISIS-1) and Controlled Convergence sub-TLV
(TBA-MRT-ISIS-3). The IANA registry for these sub-TLV types is
displayed as "sub-TLVs for TLV 242" (http://www.iana.org/assignments/
isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-
242). The new entries in this registry are shown below.
Value Description Reference
-------------- ------------------------------ ------------
TBA-MRT-ISIS-1 MRT Profile sub-TLV [This draft]
TBA-MRT-ISIS-3 Controlled Convergence sub-TLV [This draft]
12.2. MRT-Ineligible Link sub-TLV
IANA is requested to allocate a value for the following sub-TLVs type
in the Extended IS Reachability TLV defined in [RFC5305]: MRT-
Ineligible Link sub-TLV (TBA-MRT-ISIS-2). The IANA registry for
these sub-TLV types is displayed as "Sub-TLVs for TLVs 22, 23, 141,
222, and 223" (http://www.iana.org/assignments/isis-tlv-codepoints/
isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-141-222-223).
The new entry in this registry is shown below.
Type Description 22 23 141 222 223 Ref.
-------------- --------------------------- -- -- --- --- --- --------
TBA-MRT-ISIS-2 MRT-Ineligible Link sub-TLV y y n n n [This
draft]
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-mpls-ldp-multi-topology]
Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
King, "LDP Extensions for Multi Topology", draft-ietf-
mpls-ldp-multi-topology-12 (work in progress), April 2014.
[I-D.ietf-rtgwg-mrt-frr-algorithm] [I-D.ietf-rtgwg-mrt-frr-algorithm]
Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "Algorithms for computing Maximally Redundant Gopalan, "Algorithms for computing Maximally Redundant
Trees for IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr- Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr-
algorithm-01 (work in progress), July 2014. algorithm-06 (work in progress), October 2015.
[I-D.ietf-rtgwg-mrt-frr-architecture] [I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Bowers, C., Enyedi, G., Csaszar, Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
A., Tantsura, J., Konstantynowicz, M., and R. White, "An A., Tantsura, J., and R. White, "An Architecture for IP/
Architecture for IP/LDP Fast-Reroute Using Maximally LDP Fast-Reroute Using Maximally Redundant Trees", draft-
Redundant Trees", draft-rtgwg-mrt-frr-architecture-04 ietf-rtgwg-mrt-frr-architecture-07 (work in progress),
(work in progress), July 2014. October 2015.
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. [RFC3787] Parker, J., Ed., "Recommendations for Interoperable IP
McPherson, "OSPF Stub Router Advertisement", RFC 3137, Networks using Intermediate System to Intermediate System
June 2001. (IS-IS)", RFC 3787, DOI 10.17487/RFC3787, May 2004,
<http://www.rfc-editor.org/info/rfc3787>.
[RFC3787] Parker, J., "Recommendations for Interoperable IP Networks [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
using Intermediate System to Intermediate System (IS-IS)", Engineering", RFC 5305, DOI 10.17487/RFC5305, October
RFC 3787, May 2004. 2008, <http://www.rfc-editor.org/info/rfc5305>.
13.2. Infomative References 13.2. Infomative References
[I-D.atlas-bryant-shand-lf-timers] [I-D.atlas-bryant-shand-lf-timers]
K, A. and S. Bryant, "Synchronisation of Loop Free Timer K, A. and S. Bryant, "Synchronisation of Loop Free Timer
Values", draft-atlas-bryant-shand-lf-timers-04 (work in Values", draft-atlas-bryant-shand-lf-timers-04 (work in
progress), February 2008. progress), February 2008.
[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-01 (work in progress), October 2015.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
4915, June 2007. RFC 4915, DOI 10.17487/RFC4915, June 2007,
<http://www.rfc-editor.org/info/rfc4915>.
[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
System to Intermediate System (IS-IS) Extensions for "Intermediate System to Intermediate System (IS-IS)
Advertising Router Information", RFC 4971, July 2007. Extensions for Advertising Router Information", RFC 4971,
DOI 10.17487/RFC4971, July 2007,
<http://www.rfc-editor.org/info/rfc4971>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008. Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<http://www.rfc-editor.org/info/rfc5120>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
2008. DOI 10.17487/RFC5308, October 2008,
<http://www.rfc-editor.org/info/rfc5308>.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, January 2010. Convergence", RFC 5715, DOI 10.17487/RFC5715, January
2010, <http://www.rfc-editor.org/info/rfc5715>.
Authors' Addresses Authors' Addresses
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
 End of changes. 86 change blocks. 
344 lines changed or deleted 310 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/