diff options
Diffstat (limited to 'doc/rfc/rfc7775.txt')
| -rw-r--r-- | doc/rfc/rfc7775.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc7775.txt b/doc/rfc/rfc7775.txt new file mode 100644 index 0000000..d4fa861 --- /dev/null +++ b/doc/rfc/rfc7775.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Ginsberg +Request for Comments: 7775 Cisco Systems +Updates: 5308 S. Litkowski +Category: Standards Track Orange Business Service +ISSN: 2070-1721 S. Previdi + Cisco Systems + February 2016 + + + IS-IS Route Preference for Extended IP and IPv6 Reachability + +Abstract + + In existing specifications, the route preferences for IPv4/IPv6 + Extended Reachability TLVs are not explicitly stated. There are also + inconsistencies in the definition of how the up/down bit applies to + route preference when the prefix advertisement appears in Level 2 + Link State Protocol Data Units (LSPs). This document addresses these + issues. + + This document updates RFC 5308. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7775. + + + + + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 1] + +RFC 7775 IS-IS Route Preference February 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + 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. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 2. Use of the Up/Down Bit in Level 2 LSPs . . . . . . . . . . . 3 + 3. Types of Routes in IS-IS Supported by Extended Reachability + TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Types of Routes Supported by TLVs 135 and 235 . . . . . . 4 + 3.2. Types of Routes Supported by TLVs 236 and 237 . . . . . . 6 + 3.3. Order of Preference for All Types of Routes Supported by + TLVs 135 and 235 . . . . . . . . . . . . . . . . . . . . 7 + 3.4. Order of Preference for All Types of Routes Supported by + TLVs 236 and 237 . . . . . . . . . . . . . . . . . . . . 8 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 5.2. Informative References . . . . . . . . . . . . . . . . . 9 + Appendix A. Example Interoperability Issue . . . . . . . . . . . 10 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + + + + +Ginsberg, et al. Standards Track [Page 2] + +RFC 7775 IS-IS Route Preference February 2016 + + +1. Introduction + + [RFC5302] defines the route preference rules as they apply to TLVs + 128 and 130. [RFC5305] introduced the IP Extended Reachability TLV + 135 but did not explicitly adapt the route preference rules defined + in [RFC5302] for the new TLV. [RFC5308] defines the IPv6 + Reachability TLV 236 and does include an explicit statement regarding + route preference -- but the statement introduces use of the up/down + bit in advertisements that appear in Level 2 LSPs, which is + inconsistent with statements made in [RFC5302] and [RFC5305]. This + document defines explicit route preference rules for TLV 135, revises + the route preference rules for TLV 236, and clarifies the usage of + the up/down bit when it appears in TLVs in Level 2 LSPs. This + document is a clarification (NOT a correction) of [RFC5302] and + [RFC5305]; it is a correction of the route preference rules defined + in [RFC5308] to be consistent with the rules for IPv4. It also makes + explicit that the same rules apply to the Multi-Topology (MT) + equivalent TLVs 235 and 237. + +1.1. 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 RFC 2119 [RFC2119]. + +2. Use of the Up/Down Bit in Level 2 LSPs + + The up/down bit was introduced in support of leaking prefixes + downwards in the IS-IS level hierarchy. Routes that are leaked + downwards have the bit set to 1. Such prefixes MUST NOT be leaked + upwards in the hierarchy. So long as we confine ourselves to a + single IS-IS instance and the current number of supported levels + (two), it is impossible to have a prefix advertised in a Level 2 LSP + and have the up/down bit set to 1. However, because [RFC5302] + anticipated a future extension to IS-IS that might support additional + levels, it allowed for the possibility that the up/down bit might be + set in a Level 2 LSP and supported easy migration in the event such + an extension was introduced. Section 3.3 of [RFC5302] states: + + ...it is RECOMMENDED that implementations ignore the up/down bit + in L2 LSPs, and accept the prefixes in L2 LSPs regardless of + whether the up/down bit is set. + + [RFC5305] addressed an additional case wherein an implementation + included support for multiple virtual routers running IS-IS in + different areas. In such a case, it is possible to redistribute + prefixes between two IS-IS instances in the same manner that prefixes + are redistributed from other protocols into IS-IS. This introduced + + + +Ginsberg, et al. Standards Track [Page 3] + +RFC 7775 IS-IS Route Preference February 2016 + + + the possibility that a prefix could be redistributed from Level 1 to + Level 1 (as well as between Level 2 and Level 2), and in the event + the redistributed route was leaked from Level 1 to Level 2, two + different routers in different areas would be advertising the same + prefix into the Level 2 sub-domain. To prevent this, Section 4.1 of + [RFC5305] specifies: + + If a prefix is advertised from one area to another at the same + level, then the up/down bit SHALL be set to 1. + + However, the statement in [RFC5302] that the up/down bit is ignored + in Level 2 LSPs is not altered by [RFC5305]. + + The conclusion then is that there is no "L2 inter-area route"; + indeed, no such route type is defined by [RFC5302]. However, + [RFC5308] ignored this fact and introduced such a route type in + Section 5 when it specified a preference for "Level 2 down prefix". + This is an error that this document corrects. As changing the use of + the up/down bit in TLVs 236 and 237 may introduce interoperability + issues, implementors may wish to support transition mechanisms from + the behavior described in [RFC5308] to the behavior described in this + document. + +3. Types of Routes in IS-IS Supported by Extended Reachability TLVs + + [RFC5302] is the authoritative reference for the types of routes + supported by TLVs 128 and 130. However, a number of attributes + supported by those TLVs are NOT supported by TLVs 135, 235, 236, and + 237. Distinction between internal/external metrics is not supported. + In the case of IPv4 TLVs (135 and 235), the distinction between + internal and external route types is not supported. However, the + Prefix Attribute Flags sub-TLV defined in [PFXATTR] reintroduces the + distinction between internal and external route types. The + definitions below include references to the relevant attribute bits + from [PFXATTR]. + +3.1. Types of Routes Supported by TLVs 135 and 235 + + This section defines the types of route supported for IPv4 when using + TLV 135 [RFC5305] and/or TLV 235 [RFC5120]. The text follows as + closely as possible the original text from [RFC5302]. + + L1 intra-area routes: These are advertised in L1 LSPs, in TLV 135 or + TLV 235. The up/down bit is set to 0. These IP prefixes are + directly connected to the advertising router. If the Prefix + Attribute Flags sub-TLV is included, both the X-Flag and the + R-Flag are set to 0. + + + + +Ginsberg, et al. Standards Track [Page 4] + +RFC 7775 IS-IS Route Preference February 2016 + + + L1 external routes: These are advertised in L1 LSPs, in TLV 135 or + TLV 235. The up/down bit is set to 0. These IP prefixes are + learned from other protocols and are usually not directly + connected to the advertising router. If the Prefix Attribute + Flags sub-TLV is included, the X-Flag is set to 1, and the R-Flag + is set to 0. + + L2 intra-area routes: These are advertised in L2 LSPs, in TLV 135 or + TLV 235. The up/down bit is set to 0. These IP prefixes are + directly connected to the advertising router. If the Prefix + Attribute Flags sub-TLV is included, both the X-Flag and the + R-Flag are set to 0. + + L1->L2 inter-area routes: These are advertised in L2 LSPs, in TLV + 135 or TLV 235. The up/down bit is set to 0. These IP prefixes + are learned via L1 routing and were derived during the L1 Shortest + Path First (SPF) computation from prefixes advertised in L1 LSPs + in TLV 135 or TLV 235. If the Prefix Attribute Flags sub-TLV is + included, the R-Flag is set to 1. + + L2->L2 inter-area routes: These are advertised in L2 LSPs, in TLV + 135 or TLV 235. The up/down bit is set to 1 but is ignored and + treated as if it were set to 0. These IP prefixes are learned + from another IS-IS instance usually operating in another area. If + the Prefix Attribute Flags sub-TLV is included, the X-Flag is set + to 1, and the R-Flag is set to 0. + + L2 external routes: These are advertised in L2 LSPs, in TLV 135 or + TLV 235. The up/down bit is set to 0. These IP prefixes are + learned from other protocols and are usually not directly + connected to the advertising router. If the Prefix Attribute + Flags sub-TLV is included, the X-Flag is set to 1, and the R-Flag + is set to 0. + + L2->L1 inter-area routes: These are advertised in L1 LSPs, in TLV + 135 or TLV 235. The up/down bit is set to 1. These IP prefixes + are learned via L2 routing and were derived during the L2 SPF + computation from prefixes advertised in TLV 135 or TLV 235. If + the Prefix Attribute Flags sub-TLV is included, the R-Flag is set + to 1. + + L1->L1 inter-area routes: These are advertised in L1 LSPs, in TLV + 135 or TLV 235. The up/down bit is set to 1. These IP prefixes + are learned from another IS-IS instance usually operating in + another area. If the Prefix Attribute Flags sub-TLV is included, + the X-Flag is set to 1, and the R-Flag is set to 0. + + + + + +Ginsberg, et al. Standards Track [Page 5] + +RFC 7775 IS-IS Route Preference February 2016 + + +3.2. Types of Routes Supported by TLVs 236 and 237 + + This section defines the types of route supported for IPv6 when using + TLV 236 [RFC5308] and/or TLV 237 [RFC5120]. + + L1 intra-area routes: These are advertised in L1 LSPs, in TLV 236 or + TLV 237. The up/down bit is set to 0. The external bit is set to + 0. These IPv6 prefixes are directly connected to the advertising + router. If the Prefix Attribute Flags sub-TLV is included, the + R-Flag is set to 0. + + L1 external routes: These are advertised in L1 LSPs, in TLV 236 or + TLV 237. The up/down bit is set to 0. The external bit is set to + 1. These IPv6 prefixes are learned from other protocols and are + usually not directly connected to the advertising router. If the + Prefix Attribute Flags sub-TLV is included, the R-Flag is set to + 0. + + L2 intra-area routes: These are advertised in L2 LSPs, in TLV 236 or + TLV 237. The up/down bit is set to 0. The external bit is set to + 0. These IPv6 prefixes are directly connected to the advertising + router. If the Prefix Attribute Flags sub-TLV is included, the + R-Flag is set to 0. + + L1->L2 inter-area routes: These are advertised in L2 LSPs, in TLV + 236 or TLV 237. The up/down bit is set to 0. The external bit is + set to 0. These IPv6 prefixes are learned via L1 routing and were + derived during the L1 Shortest Path First (SPF) computation from + prefixes advertised in L1 LSPs in TLV 236 or TLV 237. If the + Prefix Attribute Flags sub-TLV is included, the R-Flag is set to + 1. + + L2 external routes: These are advertised in L2 LSPs, in TLV 236 or + TLV 237. The up/down bit is set to 0. The external bit is set to + 1. These IPv6 prefixes are learned from other protocols and are + usually not directly connected to the advertising router. If the + Prefix Attribute Flags sub-TLV is included, the R-Flag is set to + 0. + + L1->L2 external routes: These are advertised in L2 LSPs, in TLV 236 + or TLV 237. The up/down bit is set to 0. The external bit is set + to 1. These IPv6 prefixes are learned via L1 routing and were + derived during the L1 Shortest Path First (SPF) computation from + L1 external routes advertised in L1 LSPs in TLV 236 or TLV 237. + If the Prefix Attribute Flags sub-TLV is included, the R-Flag is + set to 1. + + + + + +Ginsberg, et al. Standards Track [Page 6] + +RFC 7775 IS-IS Route Preference February 2016 + + + L2->L2 inter-area routes: These are advertised in L2 LSPs, in TLV + 236 or TLV 237. The up/down bit is set to 1 but is ignored and + treated as if it were set to 0. The external bit is set to 1. + These IP prefixes are learned from another IS-IS instance usually + operating in another area. If the Prefix Attribute Flags sub-TLV + is included, the R-Flag is set to 0. + + L2->L1 inter-area routes: These are advertised in L1 LSPs, in TLV + 236 or TLV 237. The up/down bit is set to 1. The external bit is + set to 0. These IPv6 prefixes are learned via L2 routing and were + derived during the L2 SPF computation from prefixes advertised in + TLV 236 or TLV 237. If the Prefix Attribute Flags sub-TLV is + included, the R-Flag is set to 1. + + L2->L1 external routes: These are advertised in L1 LSPs, in TLV 236 + or TLV 237. The up/down bit is set to 1. The external bit is set + to 1. These IPv6 prefixes are learned via L2 routing and were + derived during the L2 SPF computation from prefixes advertised in + TLV 236 or TLV 237. If the Prefix Attribute Flags sub-TLV is + included, the R-Flag is set to 1. + + L1->L1 inter-area routes: These are advertised in L1 LSPs, in TLV + 236 or TLV 237. The up/down bit is set to 1. The external bit is + set to 1. These IP prefixes are learned from another IS-IS + instance usually operating in another area. If the Prefix + Attribute Flags sub-TLV is included, the R-Flag is set to 0. + +3.3. Order of Preference for All Types of Routes Supported by TLVs 135 + and 235 + + This document defines the following route preferences for IPv4 routes + advertised in TLVs 135 or 235. Note that all types of routes listed + for a given preference are treated equally. + + 1. L1 intra-area routes; L1 external routes + + 2. L2 intra-area routes; L2 external routes; L1->L2 inter-area + routes; L2-L2 inter-area routes + + 3. L2->L1 inter-area routes; L1->L1 inter-area routes + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 7] + +RFC 7775 IS-IS Route Preference February 2016 + + +3.4. Order of Preference for All Types of Routes Supported by TLVs 236 + and 237 + + This document defines the following route preferences for IPv6 routes + advertised in TLVs 236 or 237. Note that all types of routes listed + for a given preference are treated equally. + + 1. L1 intra-area routes; L1 external routes + + 2. L2 intra-area routes; L2 external routes; L1->L2 inter-area + routes; L1-L2 external routes; L2-L2 inter-area routes + + 3. L2->L1 inter-area routes; L2->L1 external routes; L1->L1 inter- + area routes + +4. Security Considerations + + This document raises no new security considerations. Security + considerations for the IS-IS protocol are covered in [ISO10589], + [RFC5304], and [RFC5310]. + +5. References + +5.1. Normative References + + [ISO10589] International Organization for Standardization, + "Intermediate System to Intermediate System intra-domain + routeing information exchange protocol for use in + conjunction with the protocol for providing the + connectionless-mode network service (ISO 8473)", + ISO Standard 10589, 2002. + + [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>. + + [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, + <http://www.rfc-editor.org/info/rfc5120>. + + [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix + Distribution with Two-Level IS-IS", RFC 5302, + DOI 10.17487/RFC5302, October 2008, + <http://www.rfc-editor.org/info/rfc5302>. + + + + +Ginsberg, et al. Standards Track [Page 8] + +RFC 7775 IS-IS Route Preference February 2016 + + + [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic + Authentication", RFC 5304, DOI 10.17487/RFC5304, October + 2008, <http://www.rfc-editor.org/info/rfc5304>. + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, DOI 10.17487/RFC5305, October + 2008, <http://www.rfc-editor.org/info/rfc5305>. + + [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, + DOI 10.17487/RFC5308, October 2008, + <http://www.rfc-editor.org/info/rfc5308>. + + [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., + and M. Fanto, "IS-IS Generic Cryptographic + Authentication", RFC 5310, DOI 10.17487/RFC5310, February + 2009, <http://www.rfc-editor.org/info/rfc5310>. + +5.2. Informative References + + [PFXATTR] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and + U. Chunduri, "IS-IS Prefix Attributes for Extended IP and + IPv6 Reachability", Work in Progress, draft-ietf-isis- + prefix-attributes-04, January 2016. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 9] + +RFC 7775 IS-IS Route Preference February 2016 + + +Appendix A. Example Interoperability Issue + + This example documents a real-world interoperability issue that + occurs because implementations from different vendors have + interpreted the use of the up/down bit in Level 2 LSPs + inconsistently. + + L2 L2 L2 L2|L2 L2 + 10/8 - R0 ----- R1 ----- R2 ----- R3 ----- R4 ---- 10/8 + | + Figure 1 + + In Figure 1, both R0 and R4 are advertising the prefix 10/8. Two IS- + IS Level 2 instances are running on R3 to separate the network into + two areas. R3 is performing route leaking and advertises prefixes + from R4 to the other Level 2 process. The network is using extended + metrics (TLV 135 defined in [RFC5305]). R0 advertises 10/8 with + metric 2000, and R3 advertises 10/8 with metric 100. All links have + a metric of 1. When advertising 10/8 in its Level 2 LSP, R3 sets the + down bit as specified in [RFC5305]. + + R1, R2, and R3 are from three different vendors (R1->Vendor1, + R2->Vendor2, R3->Vendor3). During interoperability testing, routing + loops are observed in this scenario. + + o R2 has two possible paths to reach 10/8: Level 2 route with metric + 2002 and up/down bit set to 0 (from R0) and Level 2 route with + metric 101 and up/down bit set to 1 (from R3). R2 selects R1 as + the next hop to 10/8 because it prefers the route that does NOT + have the up/down bit set. + + o R3 has two possible paths to reach 10/8: Level 2 route with metric + 2003 and up/down bit set to 0 (from R0) and Level 2 route with + metric 101 and up/down bit set to 0 (from R4). R3 selects R4 as + the next hop due to lowest metric. + + o R1 has two possible paths to reach 10/8: Level 2 route with metric + 2001 and up/down bit set to 0 (from R0) and Level 2 route with + metric 102 and up/down bit set to 1 (from R3). R1 selects R2 as + the next hop due to lowest metric. + + When R1 or R2 try to send traffic to 10/8, packets loop due to + inconsistent routing decisions between R1 and R2. + + + + + + + + +Ginsberg, et al. Standards Track [Page 10] + +RFC 7775 IS-IS Route Preference February 2016 + + +Acknowledgements + + The authors wish to thank Ahmed Bashandy for his insightful review. + +Authors' Addresses + + Les Ginsberg + Cisco Systems + 510 McCarthy Blvd. + Milpitas, CA 95035 + United States + + Email: ginsberg@cisco.com + + + Stephane Litkowski + Orange Business Service + + Email: stephane.litkowski@orange.com + + + Stefano Previdi + Cisco Systems + Via Del Serafico 200 + Rome 0144 + Italy + + Email: sprevidi@cisco.com + + + + + + + + + + + + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 11] + |