rfc2966.txt

<VC++网络游戏建摸与实现>源代码

       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

   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 for
   a few more potential combinations.  One of them is the combination of
   "IP Internal Reachability Information" and external metric type.
   This combination should never 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 whether the up/down bit is set.
   This will allow for simpler migration once more than two levels of
   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 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 is to not advertise any L2
   routes into L1 (see also paragraph 5.0).

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, nor 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 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.  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 never
   advertise L2->L1 inter-area routes back into L2.  Therefore, if L2
   routes are advertised down into 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 threat 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





                             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 manually
   configure L1L2 routers to advertise any L2 routes into L1.

5. Comparisons with other proposals

   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->L1
   inter-area routes.  [3] 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 [3] 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 [3].

6. Security Considerations

   This document raises no new security issues for IS-IS.

7. References

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

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

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












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


8. Authors' Addresses

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

   EMail: [e-mail]


   Tony Przygienda
   Redback
   350 Holger Way
   San Jose, CA 95134

   EMail: [e-mail]


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

   EMail: [e-mail]



























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


9.  Full Copyright Statement

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

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

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

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

Acknowledgement

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



















                             Informational                     [Page 14]