RFC 5302

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

📅 published October 2008, from ietf

RFC 5302: Domain-Wide Prefix Distribution with Two-Level IS-IS 🦋

Okay bestie, this is RFC 5302, and it's giving Standards Track 💅. It came out in October 2008 as part of the Network Working Group series. The authors are T. Li from Redback Networks, Inc., H. Smit, and T. Przygienda from Z2 Sagl 🌸. It obsoletes RFC 2966 and updates RFC 1195, so it's the new, improved version of 2966 and it adds to 1195 🔥.

Status of This Memo

This doc is an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 🫶. If you want to know where this protocol stands, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨.

Abstract

Okay so this document extends Intermediate System to Intermediate System (IS-IS) so it can do optimal routing inside a two-level domain 🧚. IS-IS is specified in ISO 10589, and the IPv4 extensions are specified in RFC 1195. This doc replaces RFC 2966 💖.

It also extends the semantics from RFC 1195. In a routing domain running both level 1 and level 2 Intermediate Systems (IS), which are routers, prefixes can get distributed between level 1 and level 2, and vice versa 👑. This only works with certain restrictions, so that persistent forwarding loops don't form. The whole point is to increase the granularity of routing information in the domain 🌈.

Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Motivations for Domain-Wide Prefix Distribution  . . . . .  3
  1.2.  Scalability  . . . . . . . . . . . . . . . . . . . . . . .  5
  1.3.  Requirements Language  . . . . . . . . . . . . . . . . . .  6
2.  Proposed Syntax and Semantics for L2->L1 Inter-Area Routes . .  6
  2.1.  Clarification of External Route-Type and External
        Metric-Type  . . . . . . . . . . . . . . . . . . . . . . .  7
  2.2.  Definition of External IP Prefixes in Level 1 LSPs . . . .  8
3.  Types of IP Routes in IS-IS and Their Order of Preference  . .  8
  3.1.  Overview of All Types of IP Prefixes in IS-IS Link
        State PDUs . . . . . . . . . . . . . . . . . . . . . . . .  9
  3.2.  Order of Preference for all Types of IP Routes in IS-IS  . 11
  3.3.  Additional Notes on What Prefixes to Accept or
        Advertise  . . . . . . . . . . . . . . . . . . . . . . . . 12
4.  Inter-Operability with Older Implementations . . . . . . . . . 12
5.  Comparisons with Other Proposals . . . . . . . . . . . . . . . 13
6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
  7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
  7.2.  Informative References . . . . . . . . . . . . . . . . . . 14

1. Introduction ✨

Same vibe as the abstract, bestie: this document extends IS-IS so it can do optimal routing within a two-level domain 💅. IS-IS is specified in [ISO-10589], and the IPv4 extensions are specified in [RFC1195] 🦋.

This doc replaces [RFC2966], which was an Informational document. This one is on the standards track 🌸. No other intentional substantive changes have been made 💜.

This document extends the semantics from RFC 1195 so that a routing domain running both level 1 and level 2 Intermediate Systems (IS), which are routers, can distribute IP prefixes between level 1 and level 2, and vice versa 🔥. There are certain restrictions on this so persistent forwarding loops don't form. The goal is to increase the granularity of the routing information within the domain ✨.

Okay, so an IS-IS routing domain (a.k.a. an autonomous system running IS-IS) can be split into multiple level 1 (L1) areas 🧚. There's also a level 2 (L2) connected subset of the topology that links all of the L1 areas together 👑. Inside each L1 area, all routers swap link state information 💖. L2 routers also swap L2 link state information so they can compute routes between areas 🌈.

RFC 1195 defines the Type, Length, and Value (TLV) tuples used to carry IPv4 routing information in IS-IS 💅. It also spells out the semantics and procedures for how the levels interact 🫶. Routers in an L1 area exchange information within that area. For IP destinations that aren't in the prefixes in the L1 database, the L1 router should forward packets to the nearest router that is in both L1 and L2 (i.e., an L1L2 router) 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 🙈.

1.1. Motivations for Domain-Wide Prefix Distribution

Real talk, the mechanisms in RFC 1195 are a great fit for lots of situations and they give you excellent scalability 💜. But sometimes the domain administrator might want to sacrifice a bit of scalability and distribute more specific info than RFC 1195 describes 🎀. This section goes through why they might make that tradeoff 🌸.

One big reason to distribute more prefix info is to improve the quality of the routes 👑. Prefix summarization (or any abstraction mechanism) necessarily loses information 😭. That lost info means routes get computed from less data, and those routes frequently aren't optimal 🙈.

Here's an example that makes it super clear ✨. Say an L1 area has two L1L2 routers that each advertise a single summary of all prefixes in the L1 area 🦋. To reach a destination inside that L1 area, any other L2 router computes the shortest path to one of the two L1L2 routers for that area 🧚. 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 selected L1L2 router to the destination could go right through the L1L2 router that wasn't selected 😱. If the L2 source router had more detailed topology or metric info, it could make a more optimal route computation 💖.

This situation is symmetric 🔁. An L1 router has no info about prefixes in L2 or in a different L1 area 🌈. By using the nearest L1L2 router, that L1L2 is effectively injecting a default route with no metric info into the L1 area 🫶. The route computation the L1 router does is similarly suboptimal 🥲.

Besides route optimality, there are two other big drivers for domain-wide distribution of prefix info ⭐.

The first one: when a router learns multiple possible paths to external destinations via BGP, it selects only one of those routes to install 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 gets advertised to other domains, and it's used to tell them the optimal entry point into the current domain 🧚. Right now, the practice is to take the IS-IS metric and put it in 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 🙈. Still, the current practice is to distribute the IGP metric this way, to optimize routing wherever possible ✨. This works in current networks that are only a single area, but it gets problematic if hierarchy is installed in the network 😭. That's again because losing end-to-end metric info means the MED value won't reflect the true distance across the advertising domain 💀. Full distribution of prefix info within the domain would fix this, since it lets you accurately compute the IS-IS metric across the domain, so the MED shows an accurate value 💖.

1.2. Scalability

Okay, the downside of domain-wide prefix distribution is that it impacts the scalability of IS-IS 🥲. Areas help IS-IS scale because LSPs are contained within a single area 🫶. That limits the size of the link state database, which in turn limits how complex the shortest path computation gets 🌸.

Summarizing prefix info also helps scalability 💜. Abstracting the prefix info removes a huge number of data items that would otherwise need transporting, plus the number of routes that need computing 🧚.

It's worth saying loudly that distributing prefixes domain-wide hits scalability in that second way 🔥. 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 must also be noted that domain-wide distribution of prefixes has no effect at all 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 that 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 you the maximum scalability that IS-IS can offer 👑. Domains that use this feature should be aware of the tradeoff 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 kind of configuration 🙈.

1.3. Requirements Language

This is the part where the key words get their official definitions, bestie 🎀. The document says:

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

To be continued in part 2 🌈💖

2. Proposed Syntax and Semantics for L2->L1 Inter-Area Routes ✨

okay so this section is where the syntax lives 🫶 the encoding is basically an extension of the one from RFC 1195, so nothing gets thrown out. we just level it up 💅

okay so picture the level 2 backbone as its own little area, lowkey 🦋 RFC 1195 lets L1L2 routers advertise IP routes they learned through L1 routing up into L2. those are inter-area routes, periodt. RFC 1195 says these L1->L2 inter-area routes have to show up in L2 LSPs inside the "IP Internal Reachability Information" TLV (TLV 128). L2 intra-area routes also go in L2 LSPs in an "IP Internal Reachability Information" TLV, so L1->L2 inter-area routes look exactly the same as L2 intra-area routes 🙈

RFC 1195 doesn't define L2->L1 inter-area routes at all. the obvious move would be letting an L1L2 router advertise routes it learned via L2 routing in its L1 LSP. BUT to stop routing loops, L1L2 routers MUST NOT advertise L2->L1 inter-area routes that they learned via L1 routing back into L2 💀 so we need a way to tell L2->L1 inter-area routes apart from L1 intra-area routes. [RFC5305] defines the "up/down bit" for this in the extended IP reachability TLV (TLV 135). RFC 1195 defines TLVs 128 and 130 to carry IP routes, and both have a Metric field made of 4 Type of Service (TOS) metrics. the first one, the "default metric", has its high-order bit (bit 8) reserved. 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 of TLVs 128 and 130 as the up/down bit 🎀 L1L2 routers MUST set this bit to one for prefixes derived from L2 routing that get 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 NOT be advertised by L1L2 routers back into L2. it's giving "no loops allowed" ✨

2.1. Clarification of External Route-Type and External Metric-Type

RFC 1195 has two TLVs for carrying IP prefixes. TLV 128 is "IP Internal Reachability Information" and should be used for IP prefixes directly connected to IS-IS routers. TLV 130 is "IP External Reachability Information" and should be used for routes learned from outside the IS-IS domain. RFC 1195 only documents TLV type 130 for level 2 LSPs.

RFC 1195 also defines two metric types 📏 Internal metric-type metrics should be used when the metric is comparable to the metrics used to weigh links inside the IS-IS domain. External metric-type metrics should be used if an IP prefix's metric can't be directly compared to internal metrics. The external metric-type can only be used for external IP prefixes, which means metrics of the external metric-type should never be seen in TLV 128 💅

to avoid confusion, this doc 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 IP routes advertised in an "IP External Reachability Information" TLV. RFC 1195 says this super clearly in the note in paragraph 3.10.2, item 2c). This document doesn't change that preference rule ✨

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.

BUT, 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, regardless of the value of the metrics. 🙅‍♀️

while IS-IS routers MUST NOT give different preference to IP prefixes learned via "IP Internal Reachability Information" and "IP External Reachability Information" when executing the Dijkstra calculation, routers that implement multiple IGPs are free to use this internal vs. external distinction when comparing routes derived from different IGPs for inclusion in their global Routing Information Base (RIB). that's a whole other vibe, but still valid 🌈

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 there's no reason an IS-IS implementation couldn't allow redistribution of external routes into L1, and some already let admins do it. This document loosens the RFC 1195 restrictions and allows the "IP External Reachability Information" TLV in L1 LSPs 🎀

RFC 1195 says IP routes learned via L1 routing must always be advertised in L2 LSPs in an "IP Internal Reachability Information" TLV. Now that this doc 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. Of course, in this case the up/down bit MUST be set also. 🔁

RFC 1195 says 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 closest to itself. It should be noted that now that external routes can be advertised from L1 into L2, and vice versa, the router advertising an external prefix in its LSP might not be the one that originally injected it 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 the route is leaked down 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. 🌸

okay so first things first 🎀 the combination of IP Internal Reachability Information and external metric-type is literally not allowed 🙅‍♀️. And the up/down bit MUST NOT be set in L2 LSPs 💅. That leaves us with 8 different types of IP advertisements in IS-IS. BUT there are more than 8 reasons for IP prefixes to get advertised in IS-IS 🤯, so here's the full breakdown 🍓

  • L1 intra-area routes 🌸: These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are directly connected to the advertising router.
  • L1 external routes 🧚: These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router.
  • L2 intra-area routes 💜: These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. These IP prefixes are directly connected to the advertising router. These prefixes cannot be distinguished from L1->L2 inter-area routes.
  • L2 external routes 🦋: These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, 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 cannot be distinguished from L1->L2 inter-area external routes.
  • L1->L2 inter-area routes 🌈: These are advertised in L2 LSPs, in TLV 128. The up/down bit is set to zero, metric-type is internal metric. 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 128. These prefixes cannot be distinguished from L2 intra-area routes.
  • L1->L2 inter-area external routes 🫶: These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, 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 cannot be distinguished from L2 external routes.
  • L2->L1 inter-area routes 👑: These are advertised in L1 LSPs, in TLV 128. The up/down bit is set to one, 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.
  • L2->L1 inter-area external routes ⭐: These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to one, 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.
  • L1 external routes with external metric 🍓: These are advertised in L1 LSPs, in TLV 130. The up/down bit is set to zero, metric-type is external metric. These IP prefixes are learned from other IGPs, and are usually not directly connected to the advertising router.
  • L2 external routes with external metric 💖: These are advertised in L2 LSPs, in TLV 130. The up/down bit is set to zero, 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 cannot be distinguished from L1->L2 inter-area external routes with external metric.
  • 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, 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.
  • 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, 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 this part is lowkey important 🫣 IS-IS cannot depend on metrics alone for route selection. Some route types just have to win no matter what the costs say from the Dijkstra calculation 👑. One reason is that inter-area routes can only be advertised with a maximum metric of 63. Another reason is that 63 does not mean infinity (unlike a hop count of 16 in RIP, which means unreachable). If we introduced an infinity cost for IS-IS inter-area routes, we'd get counting-to-infinity behavior across two or more L1L2 routers, and that would seriously hurt network stability 💀

The order of preference is built on a few assumptions 🧠:

  • RFC 1195 defines that routes derived from L1 routing are preferred over routes derived from L2 routing.
  • The note in RFC 1195, paragraph 3.10.2, item 2c) defines that internal routes with internal metric-type and external prefixes with internal metric-type have the same preference.
  • RFC 1195 defines that external routes with internal metric-type are preferred over 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 💅

  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

so remember Section 3.1 lists every route type IS-IS actually uses 🎀. The encoding would technically allow a few more combinations though 🙈. One is the combination of "IP Internal Reachability Information" and external metric-type. This combination SHOULD NOT be used when building an LSP. Upon receipt of an IP prefix with this combination, routers MUST ignore this prefix 🚫

Next up is the up/down bit in L2 LSPs. IS-IS is currently defined with two levels of hierarchy, so there should never be a need to set it there 🌸. But if IS-IS ever gets extended to more than two levels, L2-only (or L1L2) routers will need to accept L2 IP routes with the up/down bit set 😭. So 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. That keeps migration simple once more than two levels are defined ✨

Another thing implementors should know: L1L2 routers SHOULD only advertise the L1 routes they actually use for forwarding themselves into their L2 LSP 🦋. They SHOULD NOT unconditionally advertise all prefixes from LSPs in the L1 database into L2. 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 (see Section 4 for more). It is also RECOMMENDED that the default configuration of L1L2 routers not advertise any L2 routes into L1 🫶

4. Inter-Operability with Older Implementations ✨

the solution in this document is not fully compatible with RFC 1195 🥺. It is an extension to RFC 1195. If routers don't use the new functionality of external L1 routes or L2->L1 inter-area routes, older implementations that strictly follow RFC 1195 will still be compatible with newer ones that follow this document 🧚

Implementations that do not 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 particular destination, and L1-only routers that use the default route pointing to the closest attached L1L2 router for that destination 💀

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 the up/down bit is recognized by L1L2 routers 🚨. As said before, L1L2 routers MUST NOT 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 implementations that follow RFC 1195 and don't understand the new up/down bit will treat L2->L1 inter-area routes as L1 intra-area routes, and they will advertise those routes back into L2. This can cause routing loops, sub-optimal routing, or extra routing instability 😱. For this reason, it is RECOMMENDED that implementations by default not advertise any L2 routes into L1. Implementations SHOULD force the network administrator to manually configure L1L2 routers to advertise any L2 routes into L1 🎀

5. Comparisons with Other Proposals 👀

In [RFC5305], a new TLV is defined to transport IP prefix information. This TLV format also defines an up/down bit to allow for L2->L1 inter-area routes. RFC 5305 also defines a new TLV to describe links. Both TLVs have a wider metric space and can define sub-TLVs to advertise extra information belonging to the link or prefix. The wider metric space in IP prefix TLVs allows for more granular metric information about inter-area path costs. To make full use of that wider metric space, network administrators must deploy both new TLVs at the same time 🧐

Deployment of RFC 5305 requires an upgrade of all routers in the network and a transition to the new TLVs. That network-wide upgrade and transition might not be an easy task 😮‍💨. In this case, the solution defined in this document, which requires only an upgrade of L1L2 routers in selected areas, might be a good alternative to the solution defined in 5305 💖

6. Security Considerations 🔐

this one's short but it matters 🙈. This document raises no new security issues for IS-IS. For general security considerations for IS-IS, see [RFC5304].

7. References 🧚

7.1. Normative References 📚✨

These are the ones the spec leans on hardcore, so bookmark them 🔖

[ISO-10589]  ISO, "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)",
             International Standard 10589:2002, Second Edition, 2002.

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

[RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2. Informative References 🌸

These ones are the extra reading 🦋 Good for background, not required to get the core vibe.

[RFC2966]    Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix
             Distribution with Two-Level IS-IS", RFC 2966,
             October 2000.

[RFC5304]    Li, T. and R. Atkinson, "IS-IS Cryptographic
             Authentication", RFC 5304, October 2008.

[RFC5305]    Li, T. and H. Smit, "IS-IS Extensions for Traffic
             Engineering", RFC 5305, October 2008.

Authors' Addresses 🧚

Meet the squad who wrote this thing 💜

Tony Li
Redback Networks, Inc.
300 Holger Way
San Jose, CA  95134
USA

Phone: +1 408 750 5160
EMail: tony.li@tony.li


Henk Smit

EMail: hhw.smit@xs4all.nl


Tony Przygienda
Z2 Sagl
Via Tersaggio 20
CH-6949 Comano
Switzerland

EMail: prz@net4u.ch

Copyright (C) The IETF Trust (2008) 🎀

So the doc is under the rights, licenses and restrictions in BCP 78, and except for what that says, the authors keep all their rights 💅

The doc and the info in it come as-is, and the legal side is clear that the contributor, whoever they represent or sponsor, the Internet Society, the IETF Trust, and the Internet Engineering Task Force all disclaim every warranty. That covers express and implied ones, including no infringement, merchantability, and fitness for a particular purpose. Here's the exact wording:

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 💖

Okay, this part is about IP rights, aka who owns what 🙈

The IETF doesn't take a side on whether any IP rights or other claims about this tech are valid or how far they reach. It also doesn't say whether you can get a license for them, and it hasn't checked for any rights on its own. For the rules on rights in RFC docs, check BCP 78 and BCP 79 📖

Any IPR disclosures sent to the IETF Secretariat, plus any promised licenses, or the results of trying to get a general license or permission for implementers or users, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔍

And if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard, the IETF wants to hear about it! Send it to ietf-ipr@ietf.org 🫶

📦 where this page comes from