RFC 2966

Domain-wide Prefix Distribution with Two-Level IS-IS

📅 published October 2000, from ietf

RFC 2966: Domain-wide Prefix Distribution with Two-Level IS-IS 🎀

Okay bestie, let's get into this one. RFC 2966 was published in October 2000 as an Informational document, which means it shares information with the Internet community and isn't an Internet standard ✨. The authors are T. Li and H. Smit from Procket Networks, and T. Przygienda from Redback. It doesn't list anything it obsoletes or updates. The whole thing is about making IS-IS routing way more precise inside a two-level domain 🦋

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

Okay so this doc extends IS-IS, the Intermediate System to Intermediate System protocol, so that routing inside a two-level domain can be optimal 🧚 IS-IS itself is specified in ISO 10589, and the IPv4 extensions come from RFC 1195 [2].

It builds on RFC 1195 so that a routing domain running both level 1 and level 2 Intermediate Systems (IS) [routers] can pass IP prefixes between level 1 and level 2, and back again 🔥 There's a catch though. This only works with certain restrictions, because otherwise persistent forwarding loops could form, and nobody wants that 💀 The whole goal is to make the routing information inside the domain more granular.

1. Introduction

Let's set the scene 🌸 An IS-IS routing domain (a.k.a., an autonomous system running IS-IS) can be split into multiple level 1 (L1) areas, plus a level 2 (L2) connected subset of the topology that links all of those L1 areas together. Inside each L1 area, all the routers swap link state information. L2 routers also swap L2 link state information so they can work out routes between areas.

RFC 1195 [2] defines the Type, Length and Value (TLV) tuples used to carry IPv4 routing information in IS-IS. It also lays out the semantics and procedures for how the levels talk to each other. Basically, routers in an L1 area exchange info within that L1 area. For IP destinations that aren't in the prefixes of the L1 database, the L1 router should forward packets to the nearest router that is in both L1 and L2 (so an L1L2 router), the one with the "attached bit" set in its L1 Link State Protocol Data Unit (LSP) 💅

Also per RFC 1195, an L1L2 router should be manually configured with a set of prefixes that summarizes the IP prefixes reachable in that L1 area. Those summaries get injected into L2. RFC 1195 doesn't specify any further interactions between L1 and L2 for IPv4 prefixes, and that's the gap this doc fills 🫶

1.1 Motivations for domain-wide prefix distribution

RFC 1195 works great in a lot of situations and gives excellent scalability properties 🌈 But sometimes the domain administrator might want to give up a bit of scalability and distribute more specific information than RFC 1195 describes. This section explains why someone might make that tradeoff.

The big reason is to improve the quality of the resulting routes ✨ Prefix summarization, or any abstraction mechanism, always loses information. That lost information means routes get computed from less data, and that will often produce routes that aren't optimal. Honestly, it's giving "less info, worse choices" 😭

Here's an example that makes it clear. Say an L1 area has two L1L2 routers that both advertise one summary of all the prefixes inside that area. When some other L2 router wants to reach a destination inside the L1 area, it's going to compute the shortest path to one of those two L1L2 routers. Now say both L1L2 routers are equidistant from the L2 source, and the L2 source arbitrarily picks one. That router might not be the optimal one when you look at the L1 topology. In fact, the path from the chosen L1L2 router to the destination might go right through the L1L2 router that wasn't picked 🙈 If the L2 source had more detailed topology or metric information, it could compute a better route.

This is symmetric, because an L1 router has no info about prefixes in L2 or in a different L1 area. When it uses the nearest L1L2 router, that L1L2 is effectively injecting a default route without metric information into the L1 area. The route computation the L1 router does is similarly suboptimal 💜

Besides route optimality, there are two other big drivers for distributing prefix info across the whole domain 🍓

The first one: when a router learns multiple possible paths to external destinations via BGP, it only installs one of those routes in the forwarding table. One of the factors in BGP route selection is the IGP cost to the BGP next hop address. Lots of ISP networks depend on this technique, which is known as "shortest exit routing". If an L1 router doesn't know the exact IGP metric to all BGP speakers in other L1 areas, it can't do effective shortest exit routing 🦋

The second one is the current practice of using the IGP (IS-IS) metric as part of the BGP Multi-Exit Discriminator (MED). The MED value is advertised to other domains and tells them the optimal entry point into the current domain. Current practice is to take the IS-IS metric and insert it as the MED value. This tends to make external traffic enter the domain at the point closest to the exit router. The receiving domain may, based on policy, choose to ignore the advertised MED. Even so, current practice is to distribute the IGP metric this way in order to optimize routing wherever possible. This works fine in networks that are only a single area, but it gets problematic once hierarchy is installed. Again, that's because losing end-to-end metric information means the MED value won't reflect the true distance across the advertising domain. Full distribution of prefix information within the domain would fix this, because it would allow accurate computation of the IS-IS metric across the domain, and so an accurate value gets presented in the MED 🎀

1.2 Scalability

Okay, real talk, there's a downside to domain-wide prefix distribution 😬 It does affect the scalability of IS-IS. Areas help scalability because LSPs are contained within a single area. That limits the size of the link state database, which in turn limits the complexity of the shortest path computation.

Prefix summarization also helps scalability, because abstracting the prefix information removes the sheer number of data items to transport and the number of routes to compute 💅

It should be noted really strongly that distributing prefixes on a domain-wide basis hits the second kind of scalability. It increases the number of prefixes throughout the domain. That means more memory consumption, more transmission requirements, and more computation requirements everywhere in the domain 🙈

It also must be noted that domain-wide prefix distribution has no effect whatsoever on the first aspect of scalability, which is the existence of areas and the limit on how far the link state database gets distributed 🧚

So the net result is: bringing domain-wide prefix distribution into a formerly flat, single area network is a clear benefit to that network's scalability. But it's a compromise, and it doesn't give the maximum scalability IS-IS can offer. Domains that choose to use this feature should understand the tradeoff they're making between scalability and optimality, and should provision and monitor their networks accordingly. The normal provisioning guidelines for a fully hierarchical IS-IS deployment won't apply to this type of configuration 👑

2. Proposed syntax and semantics for L2->L1 inter-area routes

This doc defines the syntax for advertising level 2 routes in level 1 LSPs. The encoding is an extension of the encoding in RFC 1195 ✨

In a way, the level 2 backbone in IS-IS can be seen as a separate area all on its own. RFC 1195 says L1L2 routers can advertise IP routes that were learned via L1 routing into L2, and those routes count as inter-area routes. RFC 1195 also says these L1->L2 inter-area routes must be advertised in L2 LSPs in the "IP Internal Reachability Information" TLV (TLV 128). Intra-area L2 routes are advertised in L2 LSPs in an "IP Internal Reachability Information" TLV too. So L1->L2 inter-area routes are indistinguishable from L2 intra-area routes 🦋

RFC 1195 doesn't define L2->L1 inter-area routes. A simple extension would be to let an L1L2 router advertise routes learned via L2 routing in its L1 LSP. But to prevent routing loops, L1L2 routers must never advertise L2->L1 inter-area routes that they learned via L1 routing back into L2. So there has to be a way to tell L2->L1 inter-area routes apart from L1 intra-area routes 🔥 Draft-ietf-isis-traffic-01.txt defines the "up/down bit" for exactly this purpose. RFC 1195 defines TLVs 128 and 130 to contain IP routes. TLVs 128 and 130 have a metric field made of 4 TOS metrics. The first metric, the so-called "default metric", has its high-order bit reserved (bit 8). Routers must set this bit to zero on transmission, and ignore it on receipt 💜

This document redefines that high-order bit in the default metric field in TLVs 128 and 130 to be the up/down bit. L1L2 routers must set this bit to one for prefixes that are derived from L2 routing and are advertised into L1 LSPs. The bit must be set to zero for all other IP prefixes in L1 or L2 LSPs. Prefixes with the up/down bit set that were learned via L1 routing must never be advertised by L1L2 routers back into L2 😭🫶

2.1 Clarification of external route-type and external metric-type ✨

Okay so, RFC 1195 defines two TLVs for carrying IP prefixes 💅. TLV 128 is called IP Internal Reachability Information, and it should be used for IP prefixes that are directly connected to IS-IS routers 🌸. TLV 130 is called IP External Reachability Information, and it should be used for routes learned from outside the IS-IS domain 🦋. RFC 1195 only documents TLV type 130 for level 2 LSPs, which is kind of a big deal 👀.

RFC 1195 also defines two metric types. The internal metric-type should be used when the metric is comparable to the metrics used to weigh links inside the IS-IS domain 🧚. The external metric-type should be used if the metric of an IP prefix can't be directly compared to internal metrics 💜. External metric-type can only be used for external IP prefixes, so a direct result is that external metric-type metrics should never be seen in TLV 128 💀.

To prevent confusion, this document says it again: when a router computes IP routes, it must give the same preference to IP routes advertised in an IP Internal Reachability Information TLV and to IP routes advertised in an IP External Reachability Information TLV 🎀. RFC 1195 spells this out clearly in the note in paragraph 3.10.2, item 2c) 📖. This document does not change this rule of preference 🔒.

NOTE: Internal routes (routes to destinations announced in the "IP Internal Reachability Information" field), and external routes using internal metrics (routes to destinations announced in the "IP External Reachability Information" field, with a metric of type "internal") are treated identically for the purpose of the order of preference of routes, and the Dijkstra calculation.

However, IP routes advertised in IP External Reachability Information with the external metric-type must be given less preference than the same IP routes advertised with the internal metric-type, no matter what the metric values are 😤.

IS-IS routers must not give different preference to IP prefixes learned via IP Internal Reachability Information and IP External Reachability Information when they run the Dijkstra calculation. Routers that implement multiple IGPs are free to use this internal versus external distinction when comparing routes derived from different IGPs for inclusion in their global RIB 🌈.

2.2 Definition of external IP prefixes in level 1 LSPs 🌷

RFC 1195 doesn't define the IP External Reachability Information TLV for L1 LSPs. But honestly, there's no reason an IS-IS implementation couldn't allow redistribution of external routes into L1, and some implementations already let network admins do this ✨. This document loosens the restrictions in RFC 1195 and allows the IP External Reachability Information TLV in L1 LSPs 🫶.

RFC 1195 defines that IP routes learned via L1 routing must always be advertised in L2 LSPs in an IP Internal Reachability Information TLV. Now that this document allows IP External Reachability Information TLVs in L1 LSPs, and allows routes learned via L2 routing to be advertised into L1, that rule needs an extension 🔥.

When an L1L2 router advertises an L1 route into L2, and that L1 route was learned via a prefix advertised in an IP External Reachability Information TLV, the L1L2 router should advertise that prefix in its L2 LSP within an IP External Reachability Information TLV 💅. L1 routes learned via an IP Internal Reachability Information TLV should still be advertised within an IP Internal Reachability Information TLV 🦋. These rules should also be applied when advertising IP routes derived from L2 routing into L1. And of course, in this case the up/down bit must be set 🎀.

RFC 1195 defines that if a router sees the same external prefix advertised by two or more routers with the same external metric, it must select the route advertised by the router that is closest to itself 📖. Here's the tea: now that external routes can be advertised from L1 into L2 and vice versa, the router that advertises an external prefix in its LSP might not be the router that originally injected that prefix into the IS-IS domain 👀. So it's less useful to advertise external routes with external metrics into other levels 🙈.

3. Types of IP routes in IS-IS and their order of preference 🗺️

RFC 1195 and this document define several ways of advertising IP routes in IS-IS. There are four variables involved 💖.

  1. The level of the LSP in which the route is advertised. There are currently two possible values: level 1 and level 2.
  2. The route-type, which can be derived from the type of TLV in which the prefix is advertised. Internal routes are advertised in IP Internal Reachability Information TLVs (TLV 128), and external routes are advertised in IP External Reachability Information TLVs (TLV 130).
  3. The metric-type: Internal or External. The metric-type is derived from the Internal/External metric-type bit in the metric field (bit 7).
  4. Whether this route is leaked down in the hierarchy, and thus can not be advertised back up. This information can be derived from the newly defined up/down bit in the default metric field ⭐.

The combination of IP Internal Reachability Information and external metric-type is not allowed. Also, the up/down bit is never set in L2 LSPs 🙅. That leaves us with 8 different types of IP advertisements in IS-IS. However, there are more than 8 reasons for IP prefixes to be advertised in IS-IS, so the following breakdown covers the types of IP prefixes and how each one is encoded 🍓.

  1. L1 intra-area routes 🌸

These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to zero, and the metric-type is internal metric. These IP prefixes are directly connected to the advertising router.

  1. L1 external routes 🦋

These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, and the metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router.

  1. L2 intra-area routes 🌷

These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, and the metric-type is internal metric. These IP prefixes are directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area routes.

  1. L2 external routes 🧚

These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, and the metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area external routes.

  1. L1->L2 inter-area routes 🔁

These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, and the metric-type is internal metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 128. These prefixes can not be distinguished from L2 intra-area routes.

  1. L1->L2 inter-area external routes 🔁

These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, and the metric-type is internal metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 130. These prefixes can not be distinguished from L2 external routes.

  1. L2->L1 inter-area routes ⬇️

These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to one, and the metric-type is internal metric. These IP prefixes are learned via L2 routing, and were derived during the L2 SPF computation from prefixes advertised in TLV 128.

  1. L2->L1 inter-area external routes ⬇️

These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, and the metric-type is internal metric. These IP prefixes are learned via L2 routing, and were derived during the L2 SPF computation from prefixes advertised in L2 LSPs in TLV 130.

  1. L1 external routes with external metric 💌

These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, and the metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router.

  1. L2 external routes with external metric 💌

These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, and the metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router. These prefixes can not be distinguished from L1->L2 inter-area external routes with external metric.

  1. L1->L2 inter-area external routes with external metric 🔁

These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, and the metric-type is external metric. These IP prefixes are learned via L1 routing, and were derived during the L1 SPF computation from prefixes advertised in L1 LSPs in TLV 130 with external metrics. These prefixes can not be distinguished from L2 external routes with external metric.

  1. L2->L1 inter-area external routes with external metric ⬇️

These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, and the metric-type is external metric. These IP prefixes are learned via L2 routing, and were derived during the L1 SPF computation from prefixes advertised in L2 LSPs in TLV 130 with external metrics. 🌟

3.2 Order of preference for all types of IP routes in IS-IS

okay so IS-IS can't just vibe off metrics alone 💅 some route types have to ALWAYS win over others, no matter what the Dijkstra math says ✨ reason one: inter-area routes can only be advertised with a max metric of 63. reason two: 63 does NOT mean infinity 💀 (unlike RIP, where a hop count of 16 means unreachable). making infinity a cost for IS-IS inter-area routes would cause counting-to-infinity across two or more L1L2 routers, and that is a total vibe-killer for network stability 😭

the order of IP route preference in IS-IS is built on a few assumptions 🎀

  • routes derived from L1 routing are preferred over routes derived from L2 routing, per RFC 1195 🦋
  • the note in RFC 1195 paragraph 3.10.2, item 2c) says internal routes with internal metric-type and external prefixes with internal metric-type are equally preferred 🌸
  • RFC 1195 says external routes with internal metric-type beat external routes with external metric-type 👑
  • routes derived from L2 routing are preferred over L2->L1 routes derived from L1 routing 🧚

based on all that, this document defines the following route preferences, and yes it's giving very specific 💖

1) L1 intra-area routes with internal metric
   L1 external routes with internal metric
2) L2 intra-area routes with internal metric
   L2 external routes with internal metric
   L1->L2 inter-area routes with internal metric
   L1->L2 inter-area external routes with internal metric
3) L2->L1 inter-area routes with internal metric
   L2->L1 inter-area external routes with internal metric
4) L1 external routes with external metric
5) L2 external routes with external metric
   L1->L2 inter-area external routes with external metric
6) L2->L1 inter-area external routes with external metric

3.3 Additional notes on what prefixes to accept or advertise

okay bestie, sections 4.1 and 4.2 list every IP route type that's actually used in IS-IS 🍓 but the encoding leaves room for a few extra combos that nobody should be making 🙈 one of them is "IP Internal Reachability Information" paired with the external metric type. that combo should never be used when building an LSP. if a router receives an IP prefix with this combination, it must ignore that prefix. not me ignoring it on purpose lol 💀

next up is the up/down bit in L2 LSPs. IS-IS is currently defined with just two levels of hierarchy, so there should never be a reason to set the up/down bit in L2 LSPs ✨ but if IS-IS ever gets extended to more than two levels, L2-only (or L1L2) routers will need to accept L2 IP routes that have the up/down bit set 🌈 so implementations are recommended to ignore the up/down bit in L2 LSPs and accept the prefixes in L2 LSPs whether or not the bit is set. this makes migration way smoother once more than two levels are defined 🫶

another detail implementors should totally know 👀 L1L2 routers should only advertise into their L2 LSP those L1 routes they actually use for forwarding themselves. they should NOT just dump every single prefix from the L1 database into L2 unconditionally. no thank you 🙅‍♀️

not every prefix needs to go up or down the hierarchy. implementations might allow extra manual filtering or summarization to bring down the number of inter-area prefixes they advertise in their LSPs 🦋 it's also recommended that L1L2 routers default to NOT advertising any L2 routes into L1 (see also paragraph 5.0). main character restraint 💅

4. Inter-operability with older implementations

this solution is not fully compatible with RFC 1195. it's an extension to RFC 1195, so think of it as a glow-up, not a replacement 🌸 if routers don't use the new functionality of external L1 routes or L2->L1 inter-area routes, then older implementations that strictly follow RFC 1195 will be compatible with newer implementations that follow this document 🫶

implementations that don't accept the "IP External Reachability Information" TLV in L1 LSPs won't be able to compute external L1 routes 😬 that could cause routing loops between L1-only routers that DO understand external L1 routes for a given destination, and L1-only routers that use the default route pointing at the closest attached L1L2 router for that destination. chaos, honestly 💀

implementations that follow RFC 1195 should ignore bit 8 in the default metric field when computing routes. so even older implementations that don't know about the up/down bit should be able to accept the new L2->L1 inter-area routes 🎀 those older implementations will install the new L2->L1 inter-area routes as L1 intra-area routes, but that alone does not cause routing loops among L1-only routers ✨

BUT it is vital that L1L2 routers recognize the up/down bit 🚨 as said before, L1L2 routers must never advertise L2->L1 inter-area routes back into L2. so if L2 routes are advertised down into an L1 area, it is required that ALL L1L2 routers in that area run software that understands the new up/down bit. older RFC 1195 implementations that don't understand the up/down bit will treat L2->L1 inter-area routes as L1 intra-area routes, and they'll advertise those routes back into L2. that can cause routing loops, sub-optimal routing, or extra routing instability 😭 for this reason, implementations are recommended to NOT advertise any L2 routes into L1 by default, and they should force the network administrator to manually configure L1L2 routers to advertise any L2 routes into L1 🔥

5. Comparisons with other proposals

in [3], a new TLV is defined to carry IP prefix information. that TLV format also defines an up/down bit to allow for L2->L1 inter-area routes 💜 [3] also defines a new TLV to describe links. both TLVs have a wider metric space and can define sub-TLVs to advertise extra information about the link or prefix 👑 the wider metric space in IP prefix TLVs allows more granular metric info about inter-area path costs. to actually use that wider metric space, network admins have to deploy both new TLVs at the same time 😮‍💨

deploying [3] requires upgrading ALL routers in the network and transitioning to the new TLVs. that network-wide upgrade might not be an easy task 😭 in that case, the solution in this document, which only requires upgrading L1L2 routers in selected areas, might be a good alternative to the solution in [3] 🦋

6. Security Considerations

this document raises no new security issues for IS-IS 🛡️✨ no new drama here, bestie 🫶

7. References

[1] ISO 10589, "Intermediate System to Intermediate System Intra-
    Domain Routing Exchange Protocol for use in Conjunction with the
    Protocol for Providing the Connectionless-mode Network Service
    (ISO 8473)".  [Also republished as RFC 1142.]

[2] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
    environments", RFC 1195, December 1990.

[3] Smit, H. and T. Li, "IS-IS Extensions for Traffic Engineering",
    Work in Progress.

8. Authors' Addresses

Tony Li
Procket Networks
1100 Cadillac Court
Milpitas, CA 95035-3025

EMail: tli@procket.com


Tony Przygienda
Redback
350 Holger Way
San Jose, CA 95134

EMail: prz@redback.com


Henk Smit
Procket Networks
1100 Cadillac Court
Milpitas, CA 95035-3025

EMail: henk@procket.com

Copyright (C) The Internet Society (2000). All Rights Reserved. 💖

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈✨

📦 where this page comes from