rfc1745.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/3 页
TXT
1,068 行
Network Working Group K. Varadhan
Request for Comments: 1745 OARnet & ISI
Category: Standards Track S. Hares
NSFnet/Merit
Y. Rekhter
T.J. Watson Research Center, IBM Corp.
December 1994
BGP4/IDRP for IP---OSPF Interaction
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 memo defines the various criteria to be used when designing an
Autonomous System Border Router (ASBR) that will run either BGP4 or
IDRP for IP with other ASBRs external to the AS and OSPF as its IGP.
Table of Contents
1. Introduction ................................................. 2
2. Reachability Information Exchange ............................ 4
2.1. Exporting OSPF information into BGP/IDRP .................. 4
2.2. Importing BGP/IDRP information into OSPF ................... 6
3. BGP/IDRP Identifier and OSPF router ID ....................... 7
4. Setting OSPF tags, ORIGIN and PATH attributes ................ 8
4.1. Configuration parameters for setting the OSPF tag .......... 10
4.2. Manually configured tags ................................... 10
4.3. Automatically generated tags ............................... 11
4.3.1. Tag = <Automatic = 1, Complete = 0, PathLength = 00> ...... 11
4.3.2. Tag = <Automatic = 1, Complete = 0, PathLength = 01> ...... 11
4.3.3. Tag = <Automatic = 1, Complete = 0, PathLength = 10> ...... 12
4.3.4. Tag = <Automatic = 1, Complete = 1, PathLength = 00> ...... 12
4.3.5. Tag = <Automatic = 1, Complete = 1, PathLength = 01> ...... 12
4.3.6. Tag = <Automatic = 1, Complete = 1, PathLength = 10> ...... 13
4.4. Miscellaneous tag settings ................................. 14
5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ... 14
6. Changes from the BGP 3 - OSPF interactions document .......... 15
7. Security Considerations ...................................... 16
8. Acknowledgements ............................................. 16
9. Bibliography ................................................. 16
Varadhan, Hares & Rekhter [Page 1]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
10. Appendix .................................................... 18
11. Authors' Present Addresses .................................. 19
1. Introduction
This document defines the various criteria to be used when designing
an Autonomous System Border Router (ASBR) that will run BGP4
[RFC1654] or IDRP for IP [IDRP] with other ASBRs external to the AS,
and OSPF [RFC1583] as its IGP.
All future references of BGP in this document will refer to BGP
version 4, as defined in [RFC1654]. All reference to IDRP are
references to the Inter-Domain Routing Protocol (ISO 10747) which has
been defined by the IDRP for IP document [IDRP] for use in Autonomous
Systems.
This document defines how the following fields in OSPF and attributes
in BGP/IDRP are to be set when interfacing between BGP/IDRP and OSPF
at an ASBR:
IDRP came out of the same work as BGP, and may be consider a follow
on to BGP-3 and BGP-4. Most fields defined in the interaction
between BGP and IDRP are named the same. Where different, the IDRP
fields are shown separately.
BGP/IDRP MULTI_EXIT_DISC
BGP ORIGIN and AS_PATH/AS_SET vs. OSPF tag
IDRP EXT_INFO and RD_PATH/RD_SET
BGP/IDRP NEXT_HOP vs. OSPF Forwarding Address
BGP/IDRP LOCAL_PREF vs. OSPF cost and type
IDRP contains RD_PATH and RD_SET fields which serves the same purpose
as AS_PATH and AS_SET fields for IDRP for IP. In this document, we
will use the terms PATH and SET to refer to the BGP AS_PATH and
AS_SET, or the IDRP RD_PATH and RD_SET fields respectively, depending
on the context of the protocol being used.
Both IDRP and BGP provide a mechanism to indicate whether the routing
information was originated via an IGP, or some other means. In IDRP,
if route information is originated by means other than an IGP, then
the EXT_INFO attribute is present. Likewise, in BGP, if a route
information is originated by means other than an IGP, then the ORIGIN
attribute is set to <EGP> or <INCOMPLETE>. For the purpose of this
document, we need to distinguish between the two cases:
Varadhan, Hares & Rekhter [Page 2]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
(a) Route information was originated via an IGP,
(b) Route information was originated by some other means.
The former case is realized in IDRP by not including the EXT_INFO
attribute, and in BGP by setting the BGP ORIGIN=<IGP>; The latter
case is realized by including the EXT_INFO attribute in IDRP, and by
setting the BGP ORIGIN=<EGP>. For the rest of the document, we will
use the BGP ORIGIN=<IGP> to refer to the former scenario, and BGP
ORIGIN=<EGP> to refer to the latter.
One other difference between IDRP and BGP remains. IDRP for IP
identifies an autonomous system by an identifier of variable length
that is syntactically identical to an NSAP address prefix, and
explicitly embeds the autonomous system number [IDRP]. BGP
identifies an autonomous system just by an autonomous system number.
Since there is a one-to-one mapping between how an autonomous system
is identified in IDRP and in BGP, in this document, we shall identify
an autonomous system by its autonomous system number.
For a more general treatise on routing and route exchange problems,
please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist.
This document uses the two terms "Autonomous System" and "Routing
Domain". The definitions for the two are below:
The term Autonomous System is the same as is used in the BGP RFC
[RFC1267], given below:
"The use of the term Autonomous System here stresses the fact
that, even when multiple IGPs and metrics are used, the
administration of an AS appears to other ASs to have a single
coherent interior routing plan and presents a consistent picture
of what destinations are reachable through it. From the
standpoint of exterior routing, an AS can be viewed as monolithic:
reachability to destinations directly connected to the AS must be
equivalent from all border gateways of the AS."
The term Routing Domain was first used in [ROUTE-LEAKING] and is
given below:
"A Routing Domain is a collection of routers which coordinate
their routing knowledge using a single [instance of a] routing
protocol."
By definition, a Routing Domain forms a single Autonomous System, but
an Autonomous System may be composed of a collection of Routing
Domains.
Varadhan, Hares & Rekhter [Page 3]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
BGP, IDRP and OSPF have the concept of a set of reachable
destinations. This set is called NLRI or Network Layer Reachability
Information. The set can be represented either as an IP address
prefix, or an address, mask pair. Note that if the mask is
contiguous in the latter, then the two representations are
equivalent. In this document, we use the term "address/mask pair" in
the context of OSPF, and "destination" or "set of reachable
destinations" in the context of BGP or IDRP.
This document follows the conventions embodied in the Host
Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST",
"SHOULD," and "MAY" for the various requirements.
A minimal implementation of BGP/IDRP OSPF exchange MUST not advertise
a route containing a set of reachable destinations when none of the
destinations in the address/mask pair is reachable via OSPF (section
2.1, bullet 3), MUST merge the PATH into a SET when multiple exit
points exist within the same autonomous system for the same external
destination (section 3), MUST set the OSPF tag accurately (section
4). This subset is chosen so as to cause minimal havoc to the
Internet at large. It is strongly recommended that implementors
implement more than a minimalistic specification.
2. Reachability Information Exchange
This section discusses the constraints that must be met to exchange
the set of reachable destinations between an external BGP/IDRP peer
from another AS and internal OSPF address/mask pairs.
2.1. Exporting OSPF information into BGP
1. The administrator MUST be able to selectively export
address/mask pairs into BGP/IDRP via an appropriate filter
mechanism.
This filter mechanism MUST support such control with the
granularity of an address/mask pair.
This filter mechanism will be the primary method of
aggregation of OSPF internal and type 1 and type 2 external
routes within the AS into BGP/IDRP.
Additionally, the administrator MUST be able to filter based
on the OSPF tag and the various sub-fields of the OSPF tag.
The settings of the tag and the sub-fields are defined in
section 4 in more detail.
Varadhan, Hares & Rekhter [Page 4]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
o The default MUST be to export no routes from OSPF into
BGP/IDRP. A single configuration parameter MUST permit
all OSPF inter-area and intra-area address/mask pairs to
be exported into BGP/IDRP.
OSPF external address/mask pairs of type 1 and type 2
MUST never be exported into BGP/IDRP unless they are
explicitly configured.
2. An address/mask pair having a non-contiguous mask MUST not be
exported to BGP/IDRP.
3. When configured to export an address/mask pair from OSPF into
BGP/IDRP, the ASBR MAY advertise the route containing the set
of reachable destinations via BGP/IDRP as soon as at least
one of the destinations in the address/mask pair is
determined to be reachable via OSPF; it MUST stop advertising
the route containing the set of reachable destinations when
none of the destinations in the address/mask pair is
reachable via OSPF.
4. The network administrator MUST be able to statically
configure the BGP/IDRP attribute MULTI_EXIT_DISC attribute to
be used for any route.
o The default MUST be to omit the MULTI_EXIT_DISC in the
route advertised via BGP/IDRP.
5. An implementation of BGP/IDRP and OSPF on an ASBR MUST have a
mechanism to set up a minimum amount of time that must elapse
between the learning of a new address/mask pair via OSPF and
subsequent advertisement of the address/mask pair via
BGP/IDRP to the external neighbours.
o The default value for this setting MUST be 0, indicating
that the address/mask pair is to be advertised to the
neighbour BGP/IDRP peers instantly.
Note that BGP and IDRP mandate a mechanism to dampen the
inbound advertisements from adjacent neighbours. See
the variable MinRouteAdvertisementInterval in section
9.2.3.1, [RFC1654] or in section 7.17.3.1, [IS10747].
6. LOCAL_PREF is not used when exporting OSPF information into
BGP/IDRP, as it is not applicable.
Varadhan, Hares & Rekhter [Page 5]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
2.2. Importing BGP/IDRP information into OSPF
1. BGP/IDRP implementations SHOULD allow an AS to control
announcements of BGP/IDRP learned set of reachable
destinations into OSPF. Implementations SHOULD support such
control with the granularity of a single destination.
Implementations SHOULD also support such control with the
granularity of an autonomous system, where the autonomous
system may be either the autonomous system that originated
the information or the autonomous system that advertised the
information to the local system (adjacent autonomous system).
o The default MUST be to import nothing from BGP/IDRP into
OSPF. Administrators must configure every destination
they wish to import.
A configuration parameter MAY allow an administrator to
configure an ASBR to import all the set of reachable
destinations from BGP/IDRP into the OSPF routing domain.
2. The administrator MUST be able to configure the OSPF cost and
the OSPF metric type of every destination imported into OSPF.
The OSPF metric type MUST default to type 2. If the
LOCAL_PREF value is used to construct the OSPF cost, one must
be extremely careful with such a conversion. In OSPF the
lower cost is preferred, while in BGP/IDRP the higher value
of the LOCAL_PREF is preferred. In addition, the OSPF cost
ranges between 1 and 2^24, while the LOCAL_PREF value ranges
between 0 and 2^32. Note that if ASBRs within a domain are
configured to correlate BGP/IDRP and OSPF information (as
described in Section 3), then the route selection by the
ASBRs is determined solely by the OSPF cost, and the value
carried by the LOCAL_PREF attribute has no impact on the
route selection.
3. Information learned via BGP/IDRP from peers within the same
AS MUST not be imported into OSPF.
4. The ASBR MUST never generate a default destination into the
OSPF routing domain unless explicitly configured to do so.
A default destination is a set of all possible destinations.
By convention, it is represented as a prefix of 0 length or a
mask of all zeroes.
A possible criterion for generating default into an IGP is to
allow the administrator to specify a set of (set of reachable
Varadhan, Hares & Rekhter [Page 6]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
destinations, PATH, default cost, default type) tuples. If
the ASBR learns of at least one of the destinations in the
set of reachable destinations, with the corresponding PATH,
then it generates a default destination into the OSPF routing
domain, with the appropriate cost and type. The lowest cost
route will then be injected into the OSPF routing domain.
This is the recommended method for originating default
destinations in the OSPF routing domain.
5. Note that [RFC1247] requires the network number to be used as
the Link State ID. This will produce a conflict if the ASBR
tries to import two destinations, differing only in their
prefix length. This problem is fixed in [RFC1583], which
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?