draft-ietf-isis-mrt-02.txt   draft-ietf-isis-mrt-03.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: November 19, 2016 Huawei Technologies Expires: January 1, 2018 Huawei Technologies
A. Atlas A. Atlas
C. Bowers C. Bowers
Juniper Networks Juniper Networks
J. Tantsura J. Tantsura
Individual Individual
May 18, 2016 June 30, 2017
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-02 draft-ietf-isis-mrt-03
Abstract Abstract
This document describes extensions to IS-IS to support the This document describes extensions to IS-IS to support the
distributed computation of Maximally Redundant Trees (MRT). Example distributed computation of Maximally Redundant Trees (MRT). Example
uses of MRT include IP/LDP Fast-Reroute and global protection or uses of MRT include IP/LDP Fast-Reroute and global protection or
live-live for multicast traffic. The extensions indicate what MRT live-live for multicast traffic. The extensions indicate what MRT
profile(s) each router supports. Different MRT profiles can be profile(s) each router supports. Different MRT profiles can be
defined to support different uses and to allow transition of defined to support different uses and to allow transition of
capabilities. An extension is introduced to flood MRT-Ineligible capabilities. An extension is introduced to flood MRT-Ineligible
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 November 19, 2016. This Internet-Draft will expire on January 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 3, line 16 skipping to change at page 3, line 16
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 [RFC7812] gives a complete solution for IP/LDP fast-reroute using
IP/LDP fast-reroute using Maximally Redundant Trees (MRT) to provide Maximally Redundant Trees (MRT) to provide alternates. This document
alternates. This document describes signalling extensions for describes signalling extensions for supporting MRT-FRR in an IS-IS
supporting MRT-FRR in an IS-IS routing domain. 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 15 skipping to change at page 4, line 15
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. Overview of IS-IS Signalling Extensions for MRT 4. Overview of IS-IS Signalling Extensions for MRT
As stated in [I-D.ietf-rtgwg-mrt-frr-algorithm], it is necessary for As stated in [RFC7811], it is necessary for each MRT-Capable router
each MRT-Capable router to compute MRT next hops in a consistent to compute MRT next hops in a consistent fashion. This is achieved
fashion. This is achieved by using the same MRT profile and by using the same MRT profile and selecting a common and unique GADAG
selecting a common and unique GADAG root in the MRT Island which is root in the MRT Island which is connected by MRT-Eligible links.
connected by MRT-Eligible links. Each of these issues will be Each of these issues will be discussed in the following sections
discussed in the following sections separately. separately.
4.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 [RFC7812]. The parameters and behavioral rules contained in an MRT
rules contained in an MRT profile define one router's MRT profile define one router's MRT capabilities. Based on common
capabilities. Based on common capabilities, one unified MRT Island 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 the advertiser MUST completely conform to the profile capabilities of the advertiser MUST completely conform to the profile
it claimed, including the MT-IDs, the algorithm and the corresponding it claimed, including the MT-IDs, the algorithm and the corresponding
forwarding mechanism. This advertisement MUST have level scope. A forwarding mechanism. This advertisement MUST have level scope. A
given router MAY support multiple MRT profiles. If so, it MUST given router MAY support multiple MRT profiles. If so, it MUST
advertise each of these profiles in the corresponding IS-IS level. advertise each of these profiles in the corresponding IS-IS level.
The default MRT Profile is defined in The default MRT Profile is defined in [RFC7812]. Its behavior is
[I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to intended to support IP/LDP unicast and multicast Fast-Reroute. MRT-
support IP/LDP unicast and multicast Fast-Reroute. MRT-Capable Capable routers SHOULD support the default MRT profile.
routers SHOULD support the default MRT profile.
4.2. Selecting the GADAG Root 4.2. Selecting the GADAG Root
As per [I-D.ietf-rtgwg-mrt-frr-algorithm], a GADAG root MUST be As per [RFC7811], a GADAG root MUST be selected for one MRT Island.
selected for one MRT Island. An unique GADAG root in common among An unique GADAG root in common among MRT Island routers is a
MRT Island routers is a necessity to do MRT computation. Since the necessity to do MRT computation. Since the selection of the GADAG
selection of the GADAG root can affect the quality of paths for root can affect the quality of paths for traffic sent over MRT Red
traffic sent over MRT Red and Blue trees, the GADAG Root Selection and Blue trees, the GADAG Root Selection Priority and the GADAG Root
Priority and the GADAG Root Selection Policy gives a network operator Selection Policy gives a network operator the ability to influence
the ability to influence the selection of the GADAG root. the selection of the GADAG root.
Each MRT-Capable router MUST advertise its priority for GADAG root Each MRT-Capable router MUST advertise its priority for GADAG root
selection. A router can only have one priority in a given 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
skipping to change at page 8, line 35 skipping to change at page 8, line 35
The format of the Controlled Convergence sub-TLV (discussed below) The format of the Controlled Convergence sub-TLV (discussed below)
also contains an MT-ID field, allowing a Controlled Convergence sub- also contains an MT-ID field, allowing a Controlled Convergence sub-
TLV to be scoped to a particular topology. This document does not TLV to be scoped to a particular topology. This document does not
place restrictions on the MT-ID field in the Controlled Convergence place restrictions on the MT-ID field in the Controlled Convergence
sub-TLV. The Controlled Convergence sub-TLV has potential sub-TLV. The Controlled Convergence sub-TLV has potential
applications that are not limited to MRT, and a topology-scoped FIB applications that are not limited to MRT, and a topology-scoped FIB
compute/install time makes sense on its own. compute/install time makes sense on its own.
6. 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 [RFC7812] describes the need to wait for a configured
need to wait for a configured or advertised period after a network or advertised period after a network failure to insure that all
failure to insure that all routers are using their new shortest path routers are using their new shortest path trees. Similarly, avoiding
trees. Similarly, avoiding micro-forwarding loops during convergence micro-forwarding loops during convergence [RFC5715] requires
[RFC5715] requires determining the maximum among all routers in the determining the maximum among all routers in the area of the worst-
area of the worst-case route computation and FIB installation time. case route computation and FIB installation time. More details on
More details on the specific reasoning and need for flooding this the specific reasoning and need for flooding this value are given in
value are given in [I-D.atlas-bryant-shand-lf-timers]. [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 (TLV #242 defined in [RFC4971]) to advertise Router CAPABILITY TLV (TLV #242 defined in [RFC4971]) to advertise
the worst-case time for a router to compute and install all IS-IS the worst-case time for a router to compute and install all IS-IS
routes in the level after a change to a stable network. This routes in the level after a change to a stable network. This
advertisement has per level scope, so the S-bit and D-bit of IS-IS advertisement has per level scope, so the S-bit and D-bit of IS-IS
Router CAPABILITY TLV MUST be set to zero. The advertisement is Router CAPABILITY TLV MUST be set to zero. The advertisement is
scoped by MT-ID, allowing a router supporting multi-topology routing scoped by MT-ID, allowing a router supporting multi-topology routing
to advertise a different worst-case FIB compute/install time for each to advertise a different worst-case FIB compute/install time for each
topology. This makes sense as the SPF computations and FIB topology. This makes sense as the SPF computations and FIB
skipping to change at page 11, line 13 skipping to change at page 11, line 13
not support these extensions are expected to silently ignore them. not support these extensions are expected to silently ignore them.
Router that do support these extensions have mechanisms to recognize Router that do support these extensions have mechanisms to recognize
routers that don't support these extensions (or are not configured to routers that don't support these extensions (or are not configured to
participate in MRT) and behave accordingly. participate in MRT) and behave accordingly.
9. 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 [RFC7812] for details on implementation status.
implementation status.
10. Security Considerations 10. Security Considerations
The IS-IS extensions in this document do not introduce new security The IS-IS extensions in this document do not introduce new security
concerns. concerns.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Shraddha Hegde for her useful The authors would like to thank Shraddha Hegde for her useful
suggestions. suggestions.
skipping to change at page 12, line 14 skipping to change at page 12, line 14
Type Description 22 23 141 222 223 Ref. Type Description 22 23 141 222 223 Ref.
-------------- --------------------------- -- -- --- --- --- -------- -------------- --------------------------- -- -- --- --- --- --------
TBA-MRT-ISIS-2 MRT-Ineligible Link sub-TLV y y n n n [This TBA-MRT-ISIS-2 MRT-Ineligible Link sub-TLV y y n n n [This
draft] draft]
13. References 13. References
13.1. Normative References 13.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-06 (work in progress), October 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-07 (work in progress),
October 2015.
[RFC3787] Parker, J., Ed., "Recommendations for Interoperable IP [RFC3787] Parker, J., Ed., "Recommendations for Interoperable IP
Networks using Intermediate System to Intermediate System Networks using Intermediate System to Intermediate System
(IS-IS)", RFC 3787, DOI 10.17487/RFC3787, May 2004, (IS-IS)", RFC 3787, DOI 10.17487/RFC3787, May 2004,
<http://www.rfc-editor.org/info/rfc3787>. <http://www.rfc-editor.org/info/rfc3787>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>. 2008, <http://www.rfc-editor.org/info/rfc5305>.
[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>.
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] [I-D.ietf-ospf-mrt]
Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li,
"OSPF Extensions to Support Maximally Redundant Trees", "OSPF Extensions to Support Maximally Redundant Trees",
skipping to change at page 13, line 10 skipping to change at page 13, line 10
[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, DOI 10.17487/RFC1195, dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007,
<http://www.rfc-editor.org/info/rfc4915>.
[RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
"Intermediate System to Intermediate System (IS-IS) "Intermediate System to Intermediate System (IS-IS)
Extensions for Advertising Router Information", RFC 4971, Extensions for Advertising Router Information", RFC 4971,
DOI 10.17487/RFC4971, July 2007, DOI 10.17487/RFC4971, July 2007,
<http://www.rfc-editor.org/info/rfc4971>. <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, Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008, DOI 10.17487/RFC5120, February 2008,
 End of changes. 15 change blocks. 
58 lines changed or deleted 48 lines changed or added

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