diff options
Diffstat (limited to 'doc/rfc/rfc5302.txt')
| -rw-r--r-- | doc/rfc/rfc5302.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc5302.txt b/doc/rfc/rfc5302.txt new file mode 100644 index 0000000..fa47ca4 --- /dev/null +++ b/doc/rfc/rfc5302.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group T. Li +Request for Comments: 5302 Redback Networks, Inc. +Obsoletes: 2966 H. Smit +Updates: 1195 +Category: Standards Track T. Przygienda + Z2 Sagl + October 2008 + + + Domain-Wide Prefix Distribution with Two-Level IS-IS + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes extensions to the Intermediate System to + Intermediate System (IS-IS) protocol to support optimal routing + within a two-level domain. The IS-IS protocol is specified in ISO + 10589, with extensions for supporting IPv4 (Internet Protocol) + specified in RFC 1195. This document replaces RFC 2966. + + This document extends the semantics presented in RFC 1195 so that a + routing domain running with both level 1 and level 2 Intermediate + Systems (IS) (routers) can distribute IP prefixes between level 1 and + level 2, and vice versa. This distribution requires certain + restrictions to ensure that persistent forwarding loops do not form. + The goal of this domain-wide prefix distribution is to increase the + granularity of the routing information within the domain. + + + + + + + + + + + + + + + + + +Li, et al. Standards Track [Page 1] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Li, et al. Standards Track [Page 2] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + +1. Introduction + + This document describes extensions to the Intermediate System to + Intermediate System (IS-IS) protocol to support optimal routing + within a two-level domain. The IS-IS protocol is specified in + [ISO-10589], with extensions for supporting IPv4 (Internet Protocol) + specified in [RFC1195]. + + This document replaces [RFC2966], which was an Informational + document. This document is on the standards track. No other + intentional substantive changes have been made. + + This document extends the semantics presented in RFC 1195 so that a + routing domain running with both level 1 and level 2 Intermediate + Systems (IS) (routers) can distribute IP prefixes between level 1 and + level 2, and vice versa. This distribution requires certain + restrictions to ensure that persistent forwarding loops do not form. + The goal of this domain-wide prefix distribution is to increase the + granularity of the routing information within the domain. + + An IS-IS routing domain (a.k.a. an autonomous system running IS-IS) + can be partitioned into multiple level 1 (L1) areas, and a level 2 + (L2) connected subset of the topology that interconnects all of the + L1 areas. Within each L1 area, all routers exchange link state + information. L2 routers also exchange L2 link state information to + compute routes between areas. + + RFC 1195 defines the Type, Length, and Value (TLV) tuples that are + used to transport IPv4 routing information in IS-IS. RFC 1195 also + specifies the semantics and procedures for interactions between + levels. Specifically, routers in an L1 area will exchange + information within the L1 area. For IP destinations not found 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. These summaries are injected into L2. RFC 1195 specifies + no further interactions between L1 and L2 for IPv4 prefixes. + +1.1. Motivations for Domain-Wide Prefix Distribution + + The mechanisms specified in RFC 1195 are appropriate in many + situations and lead to excellent scalability properties. However, in + certain circumstances, the domain administrator may wish to sacrifice + some amount of scalability and distribute more specific information + + + +Li, et al. Standards Track [Page 3] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + + than is described by RFC 1195. This section discusses the various + reasons why the domain administrator may wish to make such a + tradeoff. + + One major reason for distributing more prefix information is to + improve the quality of the resulting routes. A well-known property + of prefix summarization or any abstraction mechanism is that it + necessarily results in a loss of information. This loss of + information in turn results in the computation of a route based upon + less information, which will frequently result in routes that are not + optimal. + + A simple example can serve to demonstrate this adequately. Suppose + that an L1 area has two L1L2 routers that both advertise a single + summary of all prefixes within the L1 area. To reach a destination + inside the L1 area, any other L2 router is going to compute the + shortest path to one of the two L1L2 routers for that area. Suppose, + for example, that both of the L1L2 routers are equidistant from the + L2 source and that the L2 source arbitrarily selects one L1L2 router. + This router may not be the optimal router when viewed from the L1 + topology. In fact, it may be the case that the path from the + selected L1L2 router to the destination router may traverse the L1L2 + router that was not selected. If more detailed topological + information or more detailed metric information was available to the + L2 source router, it could make a more optimal route computation. + + This situation is symmetric in that an L1 router has no information + about prefixes in L2 or within a different L1 area. In using the + nearest L1L2 router, that L1L2 is effectively injecting a default + route without metric information into the L1 area. The route + computation that the L1 router performs is similarly suboptimal. + + Besides the optimality of the routes computed, there are two other + significant drivers for the domain-wide distribution of prefix + information. + + When a router learns multiple possible paths to external destinations + via BGP, it will select only one of those routes to be installed in + the forwarding table. One of the factors in the BGP route selection + is the IGP cost to the BGP next hop address. Many ISP networks + depend on this technique, which is known as "shortest exit routing". + If a L1 router does not know the exact IGP metric to all BGP speakers + in other L1 areas, it cannot do effective shortest exit routing. + + The third driver is the current practice of using the IGP (IS-IS) + metric as part of the BGP Multi-Exit Discriminator (MED). The value + in the MED is advertised to other domains and is used to inform other + domains of the optimal entry point into the current domain. Current + + + +Li, et al. Standards Track [Page 4] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + + practice is to take the IS-IS metric and insert it as the MED value. + This tends to cause external traffic to enter the domain at the point + closest to the exit router. Note that the receiving domain MAY, + based upon policy, choose to ignore the MED that is advertised. + However, current practice is to distribute the IGP metric in this way + in order to optimize routing wherever possible. This is possible in + current networks that only are a single area, but becomes problematic + if hierarchy is to be installed into the network. This is again + because the loss of end-to-end metric information means that the MED + value will not reflect the true distance across the advertising + domain. Full distribution of prefix information within the domain + would alleviate this problem, as it would allow accurate computation + of the IS-IS metric across the domain, resulting in an accurate value + presented in the MED. + +1.2. Scalability + + The disadvantage to performing the domain-wide prefix distribution + described above is that it has an impact on the scalability of IS-IS. + Areas within IS-IS help scalability in that LSPs are contained within + a single area. This limits the size of the link state database, + which in turn limits the complexity of the shortest path computation. + + Further, the summarization of the prefix information aids scalability + in that the abstraction of the prefix information removes the sheer + number of data items to be transported and the number of routes to be + computed. + + It should be noted quite strongly that the distribution of prefixes + on a domain-wide basis impacts the scalability of IS-IS in the second + respect. It will increase the number of prefixes throughout the + domain. This will result in increased memory consumption, + transmission requirements, and computation requirements throughout + the domain. + + It must also be noted that the domain-wide distribution of prefixes + has no effect whatsoever on the first aspect of scalability, namely + the existence of areas and the limitation of the distribution of the + link state database. + + Thus, the net result is that the introduction of domain-wide prefix + distribution into a formerly flat, single area network is a clear + benefit to the scalability of that network. However, it is a + compromise and does not provide the maximum scalability available + with IS-IS. Domains that choose to make use of this facility should + be aware of the tradeoff that they are making between scalability and + optimality, and provision and monitor their networks accordingly. + Normal provisioning guidelines that would apply to a fully + + + +Li, et al. Standards Track [Page 5] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + + hierarchical deployment of IS-IS will not apply to this type of + configuration. + +1.3. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Proposed Syntax and Semantics for L2->L1 Inter-Area Routes + + This document defines the syntax of how to advertise level 2 routes + in level 1 LSPs. The encoding is an extension of the encoding in RFC + 1195. + + To some extent, in IS-IS the level 2 backbone can be seen as a + separate area itself. RFC 1195 defines that L1L2 routers can + advertise IP routes that were learned via L1 routing into L2. These + routes can be regarded as inter-area routes. RFC 1195 defines that + 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 also advertised in L2 LSPs in an "IP Internal Reachability + Information" TLV. Therefore, L1->L2 inter-area routes are + indistinguishable from L2 intra-area routes. + + RFC 1195 does not define L2->L1 inter-area routes. A simple + extension would be to allow an L1L2 router to advertise routes + learned via L2 routing in its L1 LSP. However, to prevent routing- + loops, L1L2 routers MUST NOT advertise L2->L1 inter-area routes that + they learn via L1 routing back into L2. Therefore, there must be a + way to distinguish L2->L1 inter-area routes from L1 intra-area + routes. [RFC5305] defines the "up/down bit" for this purpose in the + extended IP reachability TLV (TLV 135). RFC 1195 defines TLVs 128 + and 130 to contain IP routes. TLVs 128 and 130 have a Metric field + that consists of 4 Type of Service (TOS) metrics. The first metric, + the so-called "default metric", has the high-order bit reserved (bit + 8). Routers must set this bit to zero on transmission, and ignore it + on receipt. + + This document redefines this 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 are learned via L1 routing MUST NOT be advertised by L1L2 + routers back into L2. + + + + + +Li, et al. Standards Track [Page 6] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + +2.1. Clarification of External Route-Type and External Metric-Type + + RFC 1195 defines two TLVs for carrying IP prefixes. TLV 128 is + defined as "IP Internal Reachability Information", and should be used + to carry IP prefixes that are directly connected to IS-IS routers. + TLV 130 is defined as "IP External Reachability Information", and + should be used to carry routes learned from outside the IS-IS domain. + RFC 1195 documents TLV type 130 only for level 2 LSPs. + + RFC 1195 also defines two types of metrics. Metrics of the internal + metric-type should be used when the metric is comparable to metrics + used to weigh links inside the IS-IS domain. Metrics of the external + metric-type should be used if the metric of an IP prefix cannot be + directly compared to internal metrics. The external metric-type can + only be used for external IP prefixes. A direct result is that + metrics of the external metric-type should never be seen in TLV 128. + + To prevent confusion, this document states again that 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 states this quite clearly in the note in paragraph 3.10.2, + item 2c). This document does not alter 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, 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 distinction + between internal and external routes when comparing routes derived + from different IGPs for inclusion in their global Routing Information + Base (RIB). + + + + + + + + +Li, et al. Standards Track [Page 7] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + +2.2. Definition of External IP Prefixes in Level 1 LSPs + + RFC 1195 does not define the "IP External Reachability Information" + TLV for L1 LSPs. However, there is no reason why an IS-IS + implementation could not allow for redistribution of external routes + into L1. Some IS-IS implementations already allow network + administrators to do this. This document loosens the restrictions in + RFC 1195 and allows for the inclusion of 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 for the advertisement of + routes learned via L2 routing into L1, the above rule needs an + extension. + + When an L1L2 router advertises an L1 route into L2, where that L1 + route was learned via a prefix advertised in an "IP External + Reachability Information" TLV, that 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 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 that is advertised by the router that is + closest to itself. It should be noted that 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 this prefix into the IS-IS domain. Therefore, it + is 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 + + + +Li, et al. Standards Track [Page 8] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + + 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. The fact 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. + +3.1. Overview of All Types of IP Prefixes in IS-IS Link State PDUs + + The combination IP Internal Reachability Information and external + metric-type is not allowed. Also, the up/down bit MUST NOT be set in + L2 LSPs. This 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. The following list describes the types of IP + prefixes and how they are encoded. + + 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 + + + + +Li, et al. Standards Track [Page 9] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + + 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. + + + + +Li, et al. Standards Track [Page 10] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + +3.2. Order of Preference for all Types of IP Routes in IS-IS + + Unfortunately, IS-IS cannot depend on metrics alone for route + selection. Some types of routes must always be preferred over + others, regardless of the costs that were computed in the Dijkstra + calculation. One of the reasons for this is that inter-area routes + can only be advertised with a maximum metric of 63. Another reason + is that this maximum value of 63 does not mean infinity (e.g., like a + hop count of 16 in RIP denotes unreachable). Introducing a value for + infinity cost in IS-IS inter-area routes would introduce counting- + to-infinity behavior via two or more L1L2 routers, which would have a + bad impact on network stability. + + The order of preference of IP routes in IS-IS is based on a few + assumptions. + + o RFC 1195 defines that routes derived from L1 routing are preferred + over routes derived from L2 routing. + + o 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. + + o RFC 1195 defines that external routes with internal metric-type + are preferred over external routes with external metric-type. + + o Routes derived from L2 routing are preferred over L2->L1 routes + derived from L1 routing. + + Based on these assumptions, 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 + + + + + +Li, et al. Standards Track [Page 11] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + + 6. L2->L1 inter-area external routes with external metric + +3.3. Additional Notes on What Prefixes to Accept or Advertise + + Section 3.1 enumerates all used IP route-types in IS-IS. Besides + these defined route-types, the encoding used would allow for a few + more potential combinations. One of them 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. + Another issue would be the usage of the up/down bit in L2 LSPs. + Because IS-IS is currently defined with two levels of hierarchy, + there should never be a need to set the up/down bit in L2 LSPs. + However, if IS-IS would ever be extended with more than two levels of + hierarchy, L2-only (or L1L2) routers will need to be able to accept + L2 IP routes with the up/down bit set. Therefore, 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. + This will allow for simpler migration once more than two levels of + hierarchy are defined. + + Another detail that implementors should be aware of is the fact that + L1L2 routers SHOULD only advertise in their L2 LSP those L1 routes + that they use for forwarding themselves. They SHOULD NOT + unconditionally advertise into L2 all prefixes from LSPs in the L1 + database. + + Not all prefixes need to be advertised up or down the hierarchy. + Implementations might allow for additional manual filtering or + summarization to further bring down the number of inter-area prefixes + they advertise in their LSPs. It is also RECOMMENDED that the + default configuration of L1L2 routers not advertise any L2 routes + into L1 (see also Section 4). + +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 do not use the new + functionality of external L1 routes or L2->L1 inter-area routes, + older implementations that strictly follow RFC 1195 will be + compatible with newer implementations that follow this document. + + Implementations that do not accept the "IP External Reachability + Information" TLV in L1 LSPs will not be able to compute external L1 + routes. This 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. + + + +Li, et al. Standards Track [Page 12] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + + Implementations that follow RFC 1195 SHOULD ignore bit 8 in the + default Metric field when computing routes. Therefore, even older + implementations that do not know of the up/down bit should be able to + accept the new L2->L1 inter-area routes. These older implementations + will install the new L2->L1 inter-area routes as L1 intra-area + routes, but that in itself does not cause routing loops among L1-only + routers. + + However, it is vital that the up/down bit is recognized by L1L2 + routers. As has been stated before, L1L2 routers MUST NOT advertise + L2->L1 inter-area routes back into L2. Therefore, 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 do not understand the + new up/down bit will treat the L2->L1 inter-area routes as L1 intra- + area routes, and they will advertise these 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 wider metric space and have the + possibility to 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 the 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. Such a 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 document raises no new security issues for IS-IS; for general + security considerations for IS-IS see [RFC5304]. + + + + + + +Li, et al. Standards Track [Page 13] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + +7. References + +7.1. Normative References + + [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 + + [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. + + + + + + + + + + + + + + + + + + + + + + + + +Li, et al. Standards Track [Page 14] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + +Authors' Addresses + + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Li, et al. Standards Track [Page 15] + +RFC 5302 Domain-wide Prefix Distribution October 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + 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 + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Li, et al. Standards Track [Page 16] + |