As per Relevance of the word internal, we have this rfc below:
Network Working Group T.
Request for Comments: 2966 Procket
Category: Informational T.
H.
Procket
October 2000
Domain-wide Prefix Distribution with Two-Level IS-
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document describes extensions to the Intermediate System
Intermediate System (IS-IS) protocol to support optimal
within a two-level domain. The IS-IS protocol is specified in
10589, with extensions for supporting IPv4 (Internet Protocol
specified in RFC 1195 [2].
This document extends the semantics presented in RFC 1195 so that
routing domain running with both level 1 and level 2
Systems (IS) [routers] can distribute IP prefixes between level 1
level 2 and vice versa. This distribution requires
restrictions to insure that persistent forwarding loops do not form
The goal of this domain-wide prefix distribution is to increase
granularity of the routing information within the domain
1.
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
L1 areas. Within each L1 area, all routers exchange link
information. L2 routers also exchange L2 link state information
compute routes between areas
Informational [Page 1]
RFC 2966 Domain-wide Prefix Distribution October 2000
RFC 1195 [2] defines the Type, Length and Value (TLV) tuples that
used to transport IPv4 routing information in IS-IS. RFC 1195
specifies the semantics and procedures for interactions
levels. Specifically, routers in a L1 area will exchange
within the L1 area. For IP destinations not found in the prefixes
the L1 database, the L1 router should forward packets to the
router that is in both L1 and L2 (i.e., an L1L2 router) with
"attached bit" set in its L1 Link State Protocol Data Unit (LSP).
Also per RFC 1195, an L1L2 router should be manually configured
a set of prefixes that summarizes the IP prefixes reachable in
L1 area. These summaries are injected into L2. RFC 1195
no further interactions between L1 and L2 for IPv4 prefixes
1.1 Motivations for domain-wide prefix
The mechanisms specified in RFC 1195 are appropriate in
situations, and lead to excellent scalability properties. However
in certain circumstances, the domain administrator may wish
sacrifice some amount of scalability and distribute more
information than is described by RFC 1195. This section
the various reasons why the domain administrator may wish to
such a tradeoff
One major reason for distributing more prefix information is
improve the quality of the resulting routes. A well know property
prefix summarization or any abstraction mechanism is that
necessarily results in a loss of information. This loss
information in turn results in the computation of a route based
less information, which will frequently result in routes that are
optimal
A simple example can serve to demonstrate this adequately.
that a L1 area has two L1L2 routers that both advertise a
summary of all prefixes within the L1 area. To reach a
inside the L1 area, any other L2 router is going to compute
shortest path to one of the two L1L2 routers for that area. Suppose
for example, that both of the L1L2 routers are equidistant from
L2 source, and that the L2 source arbitrarily selects one L1L
router. This router may not be the optimal router when viewed
the L1 topology. In fact, it may be the case that the path from
selected L1L2 router to the destination router may traverse the L1L
router that was not selected. If more detailed
information or more detailed metric information was available to
L2 source router, it could make a more optimal route computation
Informational [Page 2]
RFC 2966 Domain-wide Prefix Distribution October 2000
This situation is symmetric in that an L1 router has no
about prefixes in L2 or within a different L1 area. In using
nearest L1L2 router, that L1L2 is effectively injecting a
route without metric information into the L1 area. The
computation that the L1 router performs is similarly suboptimal
Besides the optimality of the routes computed, there are two
significant drivers for the domain wide distribution of
information
When a router learns multiple possible paths to external
via BGP, it will select only one of those routes to be installed
the forwarding table. One of the factors in the BGP route
is the IGP cost to the BGP next hop address. Many ISP
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
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
in the MED is advertised to other domains and is used to inform
domains of the optimal entry point into the current domain.
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
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
in order to optimize routing wherever possible. This is possible
current networks that only are a single area, but becomes
if hierarchy is to be installed into the network. This is
because the loss of end-to-end metric information means that the
value will not reflect the true distance across the
domain. Full distribution of prefix information within the
would alleviate this problem as it would allow accurate
of the IS-IS metric across the domain, resulting in an accurate
presented in the MED
1.2
The disadvantage to performing the domain-wide prefix
described above is that it has an impact to the scalability of IS-IS
Areas within IS-IS help scalability in that LSPs are contained
a single area. This limits the size of the link state database,
in turn limits the complexity of the shortest path computation
Informational [Page 3]
RFC 2966 Domain-wide Prefix Distribution October 2000
Further, the summarization of the prefix information aids
in that the abstraction of the prefix information removes the
number of data items to be transported and the number of routes to
computed
It should be noted quite strongly that the distribution of
on a domain wide basis impacts the scalability of IS-IS in the
respect. It will increase the number of prefixes throughout
domain. This will result in increased memory consumption
transmission requirements and computation requirements throughout
domain
It must also be noted that the domain-wide distribution of
has no effect whatsoever on the first aspect of scalability,
the existence of areas and the limitation of the distribution of
link state database
Thus, the net result is that the introduction of domain-wide
distribution into a formerly flat, single area network is a
benefit to the scalability of that network. However, it is
compromise and does not provide the maximum scalability
with IS-IS. Domains that choose to make use of this facility
be aware of the tradeoff that they are making between scalability
optimality and provision and monitor their networks accordingly
Normal provisioning guidelines that would apply to a
hierarchical deployment of IS-IS will not apply to this type
configuration
2. Proposed syntax and semantics for L2->L1 inter-area
This document defines the syntax of how to advertise level 2
in level 1 LSPs. The encoding is an extension of the encoding in
1195.
To some extent, in IS-IS the level 2 backbone can be seen as
separate area itself. RFC 1195 defines that L1L2 routers
advertise IP routes that were learned via L1 routing into L2.
routes can be regarded as inter-area routes. RFC 1195 defines
these L1->L2 inter-area routes must be advertised in L2 LSPs in
"IP Internal Reachability Information" TLV (TLV 128). Intra-area L
routes are also advertised in L2 LSPs in an "IP Internal
Information" TLV. Therefore, L1->L2 inter-area routes
indistinguishable from L2 intra-area routes
RFC 1195 does not define L2->L1 inter-area routes. A
extension would be to allow a L1L2 router to advertise routes
via L2 routing in its L1 LSP. However, to prevent routing-loops
L1L2 routers must never advertise L2->L1 inter-area routes that
Informational [Page 4]
RFC 2966 Domain-wide Prefix Distribution October 2000
learn via L1 routing, back into L2. Therefore, there must be a
to distinguish L2->L1 inter-area routes from L1 intra-area routes
Draft-ietf-isis-traffic-01.txt defines the "up/down bit" for
purpose. RFC 1195 defines TLVs 128 and 130 to contain IP routes
TVLs 128 and 130 have a metric field that consists of 4 TOS metrics
The first metric, the so-called "default metric", has the high-
bit reserved (bit 8). Routers must set this bit to zero
transmission, and ignore it on receipt
This document redefines this high-order bit in the default
field in TLVs 128 and 130 to be the up/down bit. L1L2 routers
set this bit to one for prefixes that are derived from L2 routing
are advertised into L1 LSPs. The bit must be set to zero for
other IP prefixes in L1 or L2 LSPs. Prefixes with the up/down
set that are learned via L1 routing, must never be advertised by L1L
routers back into L2.
2.1 Clarification of external route-type and external metric-
RFC 1195 defines two TLVs for carrying IP prefixes. TLV 128
defined as "IP Internal Reachability Information", and should be
to carry IP prefixes that are directly connected to IS-IS routers
TLV 130 is defined as "IP External Reachability Information",
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
metric-type should be used when the metric is comparable to
used to weigh links inside the ISIS domain. Metrics of the
metric-type should be used if the metric of an IP prefix cannot
directly compared to internal metrics. External metric-type can
be used for external IP prefixes. A direct result is that metrics
external metric-type should never be seen in TLV 128.
To prevent confusion, this document states again that when a
computes IP routes, it must give the same preference to IP
advertised in an "IP Internal Reachability Information" TLV and
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
"IP Internal Reachability Information" field), and
routes using internal metrics (routes to destinations
in the "IP External Reachability Information" field, with
metric of type "internal") are treated identically for
purpose of the order of preference of routes, and the
calculation
Informational [Page 5]
RFC 2966 Domain-wide Prefix Distribution October 2000
However, IP routes advertised in "IP External
Information" with external metric-type must be given less
than the same IP routes advertised with internal-metric type
regardless of the value of the metrics
While IS-IS routers must not give different preference to IP
learned via "IP Internal Reachability Information" and "IP
Reachability Information" when executing the Dijkstra calculation
routers that implement multiple IGPs are free to use this
between internal and external routes when comparing routes
from different IGPs for inclusion in their global RIB
2.2 Definition of external IP prefixes in level 1
RFC 1195 does not define the "IP External Reachability Information
TLV for L1 LSPs. However, there is no reason why an IS-
implementation could not allow for redistribution of external
into L1. Some IS-IS implementations already allow
administrators to do this. This document loosens the restrictions
RFC 1195, and allows for the inclusion of the "IP
Reachability Information" TLV in L1 LSPs
RFC 1195 defines that IP routes learned via L1 routing must always
advertised in L2 LSPs in a "IP Internal Reachability Information
TLV. Now that this document allows "IP External
Information" TLVs in L1 LSPs, and allows for the advertisement
routes learned via L2 routing into L1, the above rule needs
extensions
When a L1L2 router advertises a L1 route into L2, where that L1
was learned via a prefix advertised in a "IP External
Information" TLV, that L1L2 router should advertise that prefix
its L2 LSP within an "IP External Reachability Information" TLV. L
routes learned via an "IP Internal Reachability Information"
should still be advertised within a "IP Internal
Information" TLV. These rules should also be applied
advertising IP routes derived from L2 routing into L1. Of course
this case also the up/down bit must be set
RFC 1195 defines that if a router sees the same external
advertised by two or more routers with the same external metric,
must select the route that is advertised by the router that
closest to itself. It should be noted that now that external
can be advertised from L1 into L2, and vice versa, that the
that advertises an external prefix in its LSP might not be the
that originally injected this prefix into the IS-IS domain
Therefore, it is less useful to advertise external routes
external metrics into other levels
Informational [Page 6]
RFC 2966 Domain-wide Prefix Distribution October 2000
3. Types of IP routes in IS-IS and their order of
RFC 1195 and this document defines several ways of advertising
routes in IS-IS. There are four variables involved
1) The level of the LSP in which the route is advertised. There
currently two possible values: level 1 and level 2
2) The route-type, which can be derived from the type of TLV in
the prefix is advertised. Internal routes are advertised in
Internal Reachability Information TLVs (TLV 128), and
routes are advertised in IP External Reachability Information
(TLV 130).
3) The metric-type: Internal or External. The metric-type is
from the Internal/External metric-type bit in the metric
(bit 7).
4) The fact whether this route is leaked down in the hierarchy,
thus can not be advertised back up. This information can
derived from the newly defined up/down bit in the default
field
3.1 Overview of all types of IP prefixes in IS-IS Link State
The combination IP Internal Reachability Information and
metric-type is not allowed. Also the up/down bit is never set in L
LSPs. This leaves us with 8 different types of IP advertisements
IS-IS. However, there are more than 8 reasons for IP prefixes to
advertised in IS-IS. The following tables describe the types of
prefixes and how they are encoded
1) L1 intra-area
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
2) L1 external
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
directly connected to the advertising router
Informational [Page 7]
RFC 2966 Domain-wide Prefix Distribution October 2000
3) L2 intra-area
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 can not be distinguished from L1->L2 inter-
routes
4) L2 external
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
directly connected to the advertising router. These prefixes
not be distinguished from L1->L2 inter-area external routes
5) L1->L2 inter-area
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
during the L1 SPF computation from prefixes advertised in L1 LSPs
TLV 128. These prefixes can not be distinguished from L2 intra-
routes
6) L1->L2 inter-area external
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
during the L1 SPF computation from prefixes advertised in L1 LSPs
TLV 130. These prefixes can not be distinguished from L2
routes
7) L2->L1 inter-area
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
during the L2 SPF computation from prefixes advertised in TLV 128.
8) L2->L1 inter-area external
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
during the L2 SPF computation from prefixes advertised in L2 LSPs
TLV 130.
Informational [Page 8]
RFC 2966 Domain-wide Prefix Distribution October 2000
9) L1 external routes with external
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
directly connected to the advertising router
10) L2 external routes with external
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
directly connected to the advertising router. These prefixes
not be distinguished from L1->L2 inter-area external routes
external metric
11) L1->L2 inter-area external routes with external
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
during the L1 SPF computation from prefixes advertised in L1 LSPs
TLV 130 with external metrics. These prefixes can not
distinguished from L2 external routes with external metric
12) L2->L1 inter-area external routes with external
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
during the L1 SPF computation from prefixes advertised in L2 LSPs
TLV 130 with external metrics
3.2 Order of preference for all types of IP routes in IS-
Unfortunately IS-IS cannot depend on metrics alone for
selection. Some types of routes must always preferred over others
regardless of the costs that were computed in the
calculation. One of the reasons for this is that inter-area
can only be advertised with a maximum metric of 63. Another
is that this maximum value of 63 does not mean infinity (e.g. like
hop count of 16 in RIP denotes unreachable). Introducing a value
infinity cost in IS-IS inter-area routes would introduce counting
to-infinity behavior via two or more L1L2 routers, which would have
bad impact on network stability
The order of preference of IP routes in IS-IS is based on a
assumptions
Informational [Page 9]
RFC 2966 Domain-wide Prefix Distribution October 2000
- RFC 1195 defines that routes derived from L1 routing are
over routes derived from L2 routing
- The note in RFC 1195 paragraph 3.10.2, item 2c) defines
internal routes with internal metric-type and external
with internal metric-type have the same preference
- RFC 1195 defines that external routes with internal metric-type
preferred over external routes with external metric type
- Routes derived from L2 routing are preferred over L2->L1
derived from L1 routing
Based on these assumptions, this document defines the following
preferences
1) L1 intra-area routes with internal
L1 external routes with internal
2) L2 intra-area routes with internal
L2 external routes with internal
L1->L2 inter-area routes with internal
L1->L2 inter-area external routes with internal
3) L2->L1 inter-area routes with internal
L2->L1 inter-area external routes with internal
4) L1 external routes with external
5) L2 external routes with external
L1->L2 inter-area external routes with external
6) L2->L1 inter-area external routes with external
3.3 Additional notes on what prefixes to accept or
Paragraphs 4.1 and 4.2 enumerate all used IP route types in IS-IS
Besides these defined route types, the encoding used would allow
a few more potential combinations. One of them is the combination
"IP Internal Reachability Information" and external metric type
This combination should never be used when building an LSP.
receipt of an IP prefix with this combination, routers must
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
hierarchy, L2-only (or L1L2) routers will need to be able to
L2 IP routes with the up/down bit set. Therefore, it is
that implementations ignore the up/down bit in L2 LSPs, and
the prefixes in L2 LSPs regardless whether the up/down bit is set
This will allow for simpler migration once more than two levels
hierarchy are defined
Informational [Page 10]
RFC 2966 Domain-wide Prefix Distribution October 2000
Another detail that implementors should be aware of is the fact
L1L2 routers should only advertise in their L2 LSP those L1
that they use for forwarding themselves. They should
unconditionally advertise into L2 all prefixes from LSPs in the L
database
Not all prefixes need to be advertised up or down the hierarchy
Implementations might allow for additional manual filtering
summarization to further bring down the number of inter-area
they advertise in their LSPs. It is also recommended that
default configuration of L1L2 routers is to not advertise any L
routes into L1 (see also paragraph 5.0).
4. Inter-operability with older
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
functionality of external L1 routes, nor L2->L1 inter-area routes
older implementations that strictly follow RFC 1195 will
compatible with newer implementations that follow this document
Implementations that do not accept the "IP External
Information" TLV in L1 LSPs will not be able to compute external L
routes. This could cause routing loops between L1-only routers
do understand external L1 routes for a particular destination,
L1-only routers that use the default route pointing the
attached L1L2 router for that destination
Implementations that follow RFC 1195 should ignore bit 8 in
default metric field when computing routes. Therefore, even
implementations that do not know of the up/down bit should be able
accept the new L2->L1 inter-area routes. These older
will install the new L2->L1 inter-area routes as L1 intra-
routes, but that in itself does not cause routing loops among L1-
routers
However, it is vital that the up/down bit is recognized by L1L
routers. As has been stated before, L1L2 routers must
advertise L2->L1 inter-area routes back into L2. Therefore, if L
routes are advertised down into L1 area, it is required that all L1L
routers in that area run software that understands the new up/
bit. Older implementations that follow RFC 1195 and do
understand the new up/down bit will threat the L2->L1 inter-
routes as L1 intra-area routes, and they will advertise these
back into L2. This can cause routing loops, sub-optimal routing
extra routing instability. For this reason it is recommended
Informational [Page 11]
RFC 2966 Domain-wide Prefix Distribution October 2000
implementations by default do not advertise any L2 routes into L1.
Implementations should force the network administrator to
configure L1L2 routers to advertise any L2 routes into L1.
5. Comparisons with other
In [3], a new TLV is defined to transport IP prefix information
This TLV format also defines an up/down bit to allow for L2->L
inter-area routes. [3] also defines a new TLV to describe links
Both TLVs have wider metric space, and have the possibility to
sub-TLVs to advertise extra information belonging to the link
prefix. The wider metric space in IP prefix TLVs allows for
granular metric information about inter-area path costs. To
full use of the wider metric space, network administrators
deploy both new TLVs at the same time
Deployment of [3] requires an upgrade of all routers in the
and a transition to the new TLVs. Such a network-wide upgrade
transition might not be an easy task. In this case, the
defined in this document, which requires only an upgrade of L1L
routers in selected areas, might be a good alternative to
solution defined in [3].
6. Security
This document raises no new security issues for IS-IS
7.
[1] ISO 10589, "Intermediate System to Intermediate System Intra
Domain Routing Exchange Protocol for use in Conjunction with
Protocol for Providing the Connectionless-mode Network
(ISO 8473)". [Also republished as RFC 1142.]
[2] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
environments", RFC 1195, December 1990.
[3] Smit, H. and T. Li, "IS-IS Extensions for Traffic Engineering",
Work in Progress
Informational [Page 12]
RFC 2966 Domain-wide Prefix Distribution October 2000
8. Authors'
Tony
Procket
1100 Cadillac
Milpitas, CA 95035-3025
EMail: tli@procket.
Tony
350 Holger
San Jose, CA 95134
EMail: prz@redback.
Henk
Procket
1100 Cadillac
Milpitas, CA 95035-3025
EMail: henk@procket.
Informational [Page 13]
RFC 2966 Domain-wide Prefix Distribution October 2000
9. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Informational [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
