rfc2966.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 788 行 · 第 1/3 页

Network Working Group                                              T. Li
Request for Comments: 2966                              Procket Networks
Category: Informational                                    T. Przygienda
                                                                 Redback
                                                                 H. Smit
                                                        Procket Networks
                                                            October 2000


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

Status of this Memo

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

Copyright Notice

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

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

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

1. Introduction

   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.






                             Informational                      [Page 1]

RFC 2966            Domain-wide Prefix Distribution         October 2000


   RFC 1195 [2] 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 a 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 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 know 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 a 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.






                             Informational                      [Page 2]

RFC 2966            Domain-wide Prefix Distribution         October 2000


   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
   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 to 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, that
   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 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
   hierarchical deployment of IS-IS will not apply to this type of
   configuration.

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 a L1L2 router to advertise routes learned
   via L2 routing in its L1 LSP.  However, to prevent routing-loops,
   L1L2 routers must never advertise L2->L1 inter-area routes that they



                             Informational                      [Page 4]

RFC 2966            Domain-wide Prefix Distribution         October 2000


   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.
   Draft-ietf-isis-traffic-01.txt defines the "up/down bit" for this
   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-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 never be advertised by L1L2
   routers back into L2.

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 ISIS domain.  Metrics of the external
   metric-type should be used if the metric of an IP prefix cannot be
   directly compared to internal metrics. External metric-type can only
   be used for external IP prefixes.  A direct result is that metrics of
   external metric-type should never be seen in TLV 128.