RFC 7775

IS-IS Route Preference for Extended IP and IPv6 Reachability

📅 published February 2016, from ietf

IS-IS Route Preference for Extended IP and IPv6 Reachability 🦋✨

RFC 7775 is a Standards Track doc from February 2016 (ISSN 2070-1721) by L. Ginsberg (Cisco Systems), S. Litkowski (Orange Business Service), and S. Previdi (Cisco Systems) 👑. It updates RFC 5308. The header doesn't list any Obsoletes, so it doesn't replace anything.

Table of Contents 📑

Internet Engineering Task Force (IETF)                       L. Ginsberg
Request for Comments: 7775                                 Cisco Systems
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

Abstract 🌸

Okay so, the route preferences for IPv4/IPv6 Extended Reachability TLVs were never explicitly stated 😭. Also, the rules for how the up/down bit affects route preference got inconsistent when a prefix advertisement showed up in Level 2 Link State Protocol Data Units (LSPs). This doc sorts all of that out.

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. 🔗

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.

1. Introduction ✨

Okay bestie, here's the story 📖. [RFC5302] defines the route preference rules for TLVs 128 and 130. Then [RFC5305] brought in the IP Extended Reachability TLV 135, but it never explicitly adapted the [RFC5302] route preference rules for that new TLV. [RFC5308] defines the IPv6 Reachability TLV 236 and does include an explicit statement about route preference, but that statement brings in use of the up/down bit in advertisements that appear in Level 2 LSPs. That clashes with what [RFC5302] and [RFC5305] say 🙈.

This document defines explicit route preference rules for TLV 135, revises the route preference rules for TLV 236, and clarifies how the up/down bit gets used when it shows up in TLVs in Level 2 LSPs. It's a clarification (not a correction) of [RFC5302] and [RFC5305]. It is a correction of the route preference rules defined in [RFC5308], so they match the IPv4 rules. It also makes it 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]. These are the big-deal words, so pay attention to them 👀.

2. Use of the Up/Down Bit in Level 2 LSPs 🎀

The up/down bit was introduced to support leaking prefixes downwards in the IS-IS level hierarchy. Routes that get leaked downwards have the bit set to 1. Those prefixes MUST NOT be leaked upwards in the hierarchy. As long as we stick to a single IS-IS instance and the current number of supported levels (two), it's impossible to have a prefix advertised in a Level 2 LSP with the up/down bit set to 1. 🤯

BUT, because [RFC5302] anticipated a future IS-IS extension that might support more levels, it allowed for the possibility that the up/down bit could be set in a Level 2 LSP. That made migration easy if such an extension ever showed up. Section 3.3 of [RFC5302] says:

...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] looked at one more case, where an implementation runs multiple virtual routers, each running IS-IS in a different area. In that setup, prefixes can be redistributed between two IS-IS instances, the same way prefixes get redistributed from other protocols into IS-IS. That opened the door to a prefix being redistributed from Level 1 to Level 1 (and between Level 2 and Level 2). If a redistributed route got 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 that, 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.

But [RFC5305] didn't change the [RFC5302] statement that the up/down bit is ignored in Level 2 LSPs. 🙃

So the conclusion is that there is no "L2 inter-area route", and [RFC5302] doesn't define any such route type. However, [RFC5308] ignored this and introduced one anyway in Section 5, when it specified a preference for "Level 2 down prefix". This document corrects that error 🛠️. Changing how the up/down bit is used in TLVs 236 and 237 might cause interoperability issues, so implementors may want to support transition mechanisms that move 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. The distinction between internal and external metrics is not supported. For IPv4 TLVs (135 and 235), the distinction between internal and external route types is not supported either. BUT the Prefix Attribute Flags sub-TLV defined in [PFXATTR] brings back 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 routes supported for IPv4 when using TLV 135 [RFC5305] and/or TLV 235 [RFC5120]. The text follows the original text from [RFC5302] as closely as possible 📚.

  • 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.
  • 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. 💜

3.2. Types of Routes Supported by TLVs 236 and 237 🦋

okay so this bit is about IPv6 💅 It covers the route types you can use when you're advertising with TLV 236 [RFC5308] and/or TLV 237 [RFC5120]. Let's go through the whole squad 🌈

L1 intra-area routes 🌸: These get advertised in L1 LSPs, in TLV 236 or TLV 237. The up/down bit is set to 0 and the external bit is set to 0. These IPv6 prefixes are directly connected to the router doing the advertising. If the Prefix Attribute Flags sub-TLV is included, the R-Flag is set to 0.

L1 external routes 🧚: Also L1 LSPs, TLV 236 or TLV 237. The up/down bit is 0 but the external bit is 1. These are prefixes learned from other protocols, so they're 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 🍓: Now we're in L2 LSPs, in TLV 236 or TLV 237. The up/down bit is 0 and the external bit is 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 🦋: Still in L2 LSPs, TLV 236 or TLV 237. The up/down bit is 0 and the external bit is 0. These IPv6 prefixes are learned via L1 routing. They 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 💜: L2 LSPs, TLV 236 or TLV 237. The up/down bit is 0 and the external bit is 1. These 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 🌷: L2 LSPs, TLV 236 or TLV 237. The up/down bit is 0 and the external bit is 1. These IPv6 prefixes are learned via L1 routing. They were derived during the L1 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.

L2->L2 inter-area routes ✨: L2 LSPs, TLV 236 or TLV 237. This one's a little plot twist 🙈 The up/down bit is set to 1, but it gets 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 one 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 and the external bit is set to 0. These IPv6 prefixes are learned via L2 routing. They 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 👑: L1 LSPs, TLV 236 or TLV 237. The up/down bit is 1 and the external bit is 1. These IPv6 prefixes are learned via L2 routing. They 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 🎀: L1 LSPs, TLV 236 or TLV 237. The up/down bit is 1 and the external bit is 1. These IP prefixes are learned from another IS-IS instance, usually one 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 🌟

Here's the preference ranking for IPv4 routes advertised in TLVs 135 or 235 💖 The RFC defines these preferences, and all the route types listed under the same preference get treated equally, no drama 🫶

  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

3.4. Order of Preference for All Types of Routes Supported by TLVs 236 and 237 🌈

And this is the IPv6 version for routes advertised in TLVs 236 or 237 🧚 Same deal: each preference level is a group where everything in it is 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 🔐

Okay, the good news 💖 This document raises no new security considerations 🙌 The security stuff for IS-IS lives in [ISO10589], [RFC5304], and [RFC5310], so go check those out if you're worried. Stay safe, bestie 🫶

5. References 📚

5.1. Normative References 💜

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.

Appendix A. Example Interoperability Issue 🕵️‍♀️

This example is a real-world interop drama 😭 It happens because implementations from different vendors read the up/down bit in Level 2 LSPs in inconsistent ways. Let's look at the tea ☕

        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. 🌀

  • 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.
  • 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.
  • 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 because R1 and R2 make inconsistent routing decisions. 😵‍💫 Yikes!!

Acknowledgements 💞

The authors wish to thank Ahmed Bashandy for his insightful review. Thank you, Ahmed, you're iconic 👑

Authors' Addresses 🦋

These are the people who wrote it, so you know who to thank (or ask) 💅

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
📦 where this page comes from