--- 1/draft-ietf-isis-mrt-02.txt 2017-06-30 11:13:21.432124766 -0700 +++ 2/draft-ietf-isis-mrt-03.txt 2017-06-30 11:13:21.468125622 -0700 @@ -1,25 +1,25 @@ Network Working Group Z. Li Internet-Draft N. Wu Intended status: Standards Track Q. Zhao -Expires: November 19, 2016 Huawei Technologies +Expires: January 1, 2018 Huawei Technologies A. Atlas C. Bowers Juniper Networks J. Tantsura Individual - May 18, 2016 + June 30, 2017 Intermediate System to Intermediate System (IS-IS) Extensions for Maximally Redundant Trees (MRT) - draft-ietf-isis-mrt-02 + draft-ietf-isis-mrt-03 Abstract This document describes extensions to IS-IS to support the distributed computation of Maximally Redundant Trees (MRT). Example uses of MRT include IP/LDP Fast-Reroute and global protection or live-live for multicast traffic. The extensions indicate what MRT profile(s) each router supports. Different MRT profiles can be defined to support different uses and to allow transition of capabilities. An extension is introduced to flood MRT-Ineligible @@ -35,25 +35,25 @@ 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 November 19, 2016. + This Internet-Draft will expire on January 1, 2018. 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. 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 @@ -95,24 +95,24 @@ The IS-IS protocol is specified in [ISO10589], with extensions for supporting IPv4 and IPv6 specified in [RFC1195] and [RFC5308]. Each Intermediate System (IS) (router) advertises one or more IS-IS Link State Protocol Data Units (LSPs) with routing information. Each LSP 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 TLVs, and are a good way of encoding information in a flexible and extensible format. - [I-D.ietf-rtgwg-mrt-frr-architecture] gives a complete solution for - IP/LDP fast-reroute using Maximally Redundant Trees (MRT) to provide - alternates. This document describes signalling extensions for - supporting MRT-FRR in an IS-IS routing domain. + [RFC7812] gives a complete solution for IP/LDP fast-reroute using + Maximally Redundant Trees (MRT) to provide alternates. This document + describes signalling extensions for supporting MRT-FRR in an IS-IS + routing domain. 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 @@ -142,57 +142,55 @@ to a lower one. 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. 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. 4. Overview of IS-IS Signalling Extensions for MRT - 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 - fashion. This is achieved by using the same MRT profile and - selecting a common and unique GADAG root in the MRT Island which is - connected by MRT-Eligible links. Each of these issues will be - discussed in the following sections separately. + As stated in [RFC7811], it is necessary for each MRT-Capable router + to compute MRT next hops in a consistent fashion. This is achieved + by using the same MRT profile and selecting a common and unique GADAG + root in the MRT Island which is connected by MRT-Eligible links. + Each of these issues will be discussed in the following sections + separately. 4.1. Supporting MRT Profiles The contents and requirements of an MRT profile has been defined in - [I-D.ietf-rtgwg-mrt-frr-architecture]. The parameters and behavioral - rules contained in an MRT profile define one router's MRT - capabilities. Based on common capabilities, one unified MRT Island - is built. + [RFC7812]. The parameters and behavioral rules contained in an MRT + profile define one router's MRT capabilities. Based on common + capabilities, one unified MRT Island is built. The MRT-Capable router MUST advertise its corresponding MRT profiles by IS-IS protocol extension within IS-IS routing domain. The capabilities of the advertiser MUST completely conform to the profile it claimed, including the MT-IDs, the algorithm and the corresponding forwarding mechanism. This advertisement MUST have level scope. A given router MAY support multiple MRT profiles. If so, it MUST advertise each of these profiles in the corresponding IS-IS level. - The default MRT Profile is defined in - [I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to - support IP/LDP unicast and multicast Fast-Reroute. MRT-Capable - routers SHOULD support the default MRT profile. + The default MRT Profile is defined in [RFC7812]. Its behavior is + intended to support IP/LDP unicast and multicast Fast-Reroute. MRT- + Capable routers SHOULD support the default MRT profile. 4.2. Selecting the GADAG Root - 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 among - MRT Island routers is a necessity to do MRT computation. Since the - selection of the GADAG root can affect the quality of paths for - traffic sent over MRT Red and Blue trees, the GADAG Root Selection - Priority and the GADAG Root Selection Policy gives a network operator - the ability to influence the selection of the GADAG root. + As per [RFC7811], a GADAG root MUST be selected for one MRT Island. + An unique GADAG root in common among MRT Island routers is a + necessity to do MRT computation. Since the selection of the GADAG + root can affect the quality of paths for traffic sent over MRT Red + and Blue trees, the GADAG Root Selection Priority and the GADAG Root + Selection Policy gives a network operator the ability to influence + the selection of the 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 Island. It can have multiple priorities for different MRT Islands it supports. Routers that are marked as overloaded([RFC3787]) are not qualified as candidate for root selection. The GADAG Root Selection Policy (defined as part of an MRT profile) 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 @@ -354,28 +352,28 @@ The format of the Controlled Convergence sub-TLV (discussed below) also contains an MT-ID field, allowing a Controlled Convergence sub- TLV to be scoped to a particular topology. This document does not 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. 6. Controlled Convergence sub-TLV in IS-IS Router CAPABILITY TLV - 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 - failure to insure that all routers are using their new shortest path - trees. Similarly, avoiding micro-forwarding loops during convergence - [RFC5715] requires determining the maximum among all routers in the - area of the worst-case route computation and FIB installation time. - More details on the specific reasoning and need for flooding this - value are given in [I-D.atlas-bryant-shand-lf-timers]. + Section 12.2 of [RFC7812] describes the need to wait for a configured + or advertised period after a network failure to insure that all + routers are using their new shortest path trees. Similarly, avoiding + micro-forwarding loops during convergence [RFC5715] requires + determining the maximum among all routers in the area of the worst- + case route computation and FIB installation time. More details on + the specific reasoning and need for flooding this value are given in + [I-D.atlas-bryant-shand-lf-timers]. A new Controlled Convergence sub-TLV is introduced into the IS-IS Router CAPABILITY TLV (TLV #242 defined in [RFC4971]) to advertise 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 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 scoped by MT-ID, allowing a router supporting multi-topology routing to advertise a different worst-case FIB compute/install time for each topology. This makes sense as the SPF computations and FIB @@ -474,22 +472,21 @@ not support these extensions are expected to silently ignore them. Router that do support these extensions have mechanisms to recognize routers that don't support these extensions (or are not configured to participate in MRT) and behave accordingly. 9. Implementation Status [RFC Editor: please remove this section prior to publication.] - Please see [I-D.ietf-rtgwg-mrt-frr-architecture] for details on - implementation status. + Please see [RFC7812] for details on implementation status. 10. Security Considerations The IS-IS extensions in this document do not introduce new security concerns. 11. Acknowledgements The authors would like to thank Shraddha Hegde for her useful suggestions. @@ -523,42 +520,40 @@ 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.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 Networks using Intermediate System to Intermediate System (IS-IS)", RFC 3787, DOI 10.17487/RFC3787, May 2004, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . + [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, + . + + [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, + . + 13.2. Infomative References [I-D.atlas-bryant-shand-lf-timers] K, A. and S. Bryant, "Synchronisation of Loop Free Timer Values", draft-atlas-bryant-shand-lf-timers-04 (work in 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", @@ -566,25 +561,20 @@ [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . - [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, - . - [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, DOI 10.17487/RFC4971, July 2007, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008,