As per Relevance of the word autonomous, we have this rfc below:
Network Working Group K.
Request for Comments: 1745 OARnet &
Category: Standards Track S.
NSFnet/
Y.
T.J. Watson Research Center, IBM Corp
December 1994
BGP4/IDRP for IP---OSPF
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This memo defines the various criteria to be used when designing
Autonomous System Border Router (ASBR) that will run either BGP4
IDRP for IP with other ASBRs external to the AS and OSPF as its IGP
Table of
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.
This document defines the various criteria to be used when
an Autonomous System Border Router (ASBR) that will run BGP
[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
version 4, as defined in [RFC1654]. All reference to IDRP
references to the Inter-Domain Routing Protocol (ISO 10747) which
been defined by the IDRP for IP document [IDRP] for use in
Systems
This document defines how the following fields in OSPF and
in BGP/IDRP are to be set when interfacing between BGP/IDRP and
at an ASBR
IDRP came out of the same work as BGP, and may be consider a
on to BGP-3 and BGP-4. Most fields defined in the
between BGP and IDRP are named the same. Where different, the
fields are shown separately
BGP/IDRP MULTI_EXIT_
BGP ORIGIN and AS_PATH/AS_SET vs. OSPF
IDRP EXT_INFO and RD_PATH/RD_
BGP/IDRP NEXT_HOP vs. OSPF Forwarding
BGP/IDRP LOCAL_PREF vs. OSPF cost and
IDRP contains RD_PATH and RD_SET fields which serves the same
as AS_PATH and AS_SET fields for IDRP for IP. In this document,
will use the terms PATH and SET to refer to the BGP AS_PATH
AS_SET, or the IDRP RD_PATH and RD_SET fields respectively,
on the context of the protocol being used
Both IDRP and BGP provide a mechanism to indicate whether the
information was originated via an IGP, or some other means. In IDRP
if route information is originated by means other than an IGP,
the EXT_INFO attribute is present. Likewise, in BGP, if a
information is originated by means other than an IGP, then the
attribute is set to or . For the purpose of
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_
attribute, and in BGP by setting the BGP ORIGIN=; The
case is realized by including the EXT_INFO attribute in IDRP, and
setting the BGP ORIGIN=. For the rest of the document, we
use the BGP ORIGIN= to refer to the former scenario, and
ORIGIN= to refer to the latter
One other difference between IDRP and BGP remains. IDRP for
identifies an autonomous system by an identifier of variable
that is syntactically identical to an NSAP address prefix,
explicitly embeds the autonomous system number [IDRP].
identifies an autonomous system just by an autonomous system number
Since there is a one-to-one mapping between how an autonomous
is identified in IDRP and in BGP, in this document, we shall
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 "
Domain". The definitions for the two are below
The term Autonomous System is the same as is used in the BGP
[RFC1267], given below
"The use of the term Autonomous System here stresses the
that, even when multiple IGPs and metrics are used,
administration of an AS appears to other ASs to have a
coherent interior routing plan and presents a consistent
of what destinations are reachable through it. From
standpoint of exterior routing, an AS can be viewed as monolithic
reachability to destinations directly connected to the AS must
equivalent from all border gateways of the AS."
The term Routing Domain was first used in [ROUTE-LEAKING] and
given below
"A Routing Domain is a collection of routers which
their routing knowledge using a single [instance of a]
protocol."
By definition, a Routing Domain forms a single Autonomous System,
an Autonomous System may be composed of a collection of
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
destinations. This set is called NLRI or Network Layer
Information. The set can be represented either as an IP
prefix, or an address, mask pair. Note that if the mask
contiguous in the latter, then the two representations
equivalent. In this document, we use the term "address/mask pair"
the context of OSPF, and "destination" or "set of
destinations" in the context of BGP or IDRP
This document follows the conventions embodied in the
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
a route containing a set of reachable destinations when none of
destinations in the address/mask pair is reachable via OSPF (
2.1, bullet 3), MUST merge the PATH into a SET when multiple
points exist within the same autonomous system for the same
destination (section 3), MUST set the OSPF tag accurately (
4). This subset is chosen so as to cause minimal havoc to
Internet at large. It is strongly recommended that
implement more than a minimalistic specification
2. Reachability Information
This section discusses the constraints that must be met to
the set of reachable destinations between an external BGP/IDRP
from another AS and internal OSPF address/mask pairs
2.1. Exporting OSPF information into
1. The administrator MUST be able to selectively
address/mask pairs into BGP/IDRP via an appropriate
mechanism
This filter mechanism MUST support such control with
granularity of an address/mask pair
This filter mechanism will be the primary method
aggregation of OSPF internal and type 1 and type 2
routes within the AS into BGP/IDRP
Additionally, the administrator MUST be able to filter
on the OSPF tag and the various sub-fields of the OSPF tag
The settings of the tag and the sub-fields are defined
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
BGP/IDRP. A single configuration parameter MUST
all OSPF inter-area and intra-area address/mask pairs
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
explicitly configured
2. An address/mask pair having a non-contiguous mask MUST not
exported to BGP/IDRP
3. When configured to export an address/mask pair from OSPF
BGP/IDRP, the ASBR MAY advertise the route containing the
of reachable destinations via BGP/IDRP as soon as at
one of the destinations in the address/mask pair
determined to be reachable via OSPF; it MUST stop
the route containing the set of reachable destinations
none of the destinations in the address/mask pair
reachable via OSPF
4. The network administrator MUST be able to
configure the BGP/IDRP attribute MULTI_EXIT_DISC attribute
be used for any route
o The default MUST be to omit the MULTI_EXIT_DISC in
route advertised via BGP/IDRP
5. An implementation of BGP/IDRP and OSPF on an ASBR MUST have
mechanism to set up a minimum amount of time that must
between the learning of a new address/mask pair via OSPF
subsequent advertisement of the address/mask pair
BGP/IDRP to the external neighbours
o The default value for this setting MUST be 0,
that the address/mask pair is to be advertised to
neighbour BGP/IDRP peers instantly
Note that BGP and IDRP mandate a mechanism to dampen
inbound advertisements from adjacent neighbours.
the variable MinRouteAdvertisementInterval in
9.2.3.1, [RFC1654] or in section 7.17.3.1, [IS10747].
6. LOCAL_PREF is not used when exporting OSPF information
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
1. BGP/IDRP implementations SHOULD allow an AS to
announcements of BGP/IDRP learned set of
destinations into OSPF. Implementations SHOULD support
control with the granularity of a single destination
Implementations SHOULD also support such control with
granularity of an autonomous system, where the
system may be either the autonomous system that
the information or the autonomous system that advertised
information to the local system (adjacent autonomous system).
o The default MUST be to import nothing from BGP/IDRP
OSPF. Administrators must configure every
they wish to import
A configuration parameter MAY allow an administrator
configure an ASBR to import all the set of
destinations from BGP/IDRP into the OSPF routing domain
2. The administrator MUST be able to configure the OSPF cost
the OSPF metric type of every destination imported into OSPF
The OSPF metric type MUST default to type 2. If
LOCAL_PREF value is used to construct the OSPF cost, one
be extremely careful with such a conversion. In OSPF
lower cost is preferred, while in BGP/IDRP the higher
of the LOCAL_PREF is preferred. In addition, the OSPF
ranges between 1 and 2^24, while the LOCAL_PREF value
between 0 and 2^32. Note that if ASBRs within a domain
configured to correlate BGP/IDRP and OSPF information (
described in Section 3), then the route selection by
ASBRs is determined solely by the OSPF cost, and the
carried by the LOCAL_PREF attribute has no impact on
route selection
3. Information learned via BGP/IDRP from peers within the
AS MUST not be imported into OSPF
4. The ASBR MUST never generate a default destination into
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
mask of all zeroes
A possible criterion for generating default into an IGP is
allow the administrator to specify a set of (set of
Varadhan, Hares & Rekhter [Page 6]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
destinations, PATH, default cost, default type) tuples.
the ASBR learns of at least one of the destinations in
set of reachable destinations, with the corresponding PATH
then it generates a default destination into the OSPF
domain, with the appropriate cost and type. The lowest
route will then be injected into the OSPF routing domain
This is the recommended method for originating
destinations in the OSPF routing domain
5. Note that [RFC1247] requires the network number to be used
the Link State ID. This will produce a conflict if the
tries to import two destinations, differing only in
prefix length. This problem is fixed in [RFC1583],
obsoletes [RFC1247].
An implementation conforming to the older [RFC1247] MUST,
this case, drop the more specific route, i.e. the
corresponding to the longer prefix in the
information
6. MULTI_EXIT_DISC is not used to import BGP/IDRP
into OSPF, as it is not applicable
3. BGP/IDRP Identifier and OSPF router
The BGP/IDRP identifier MUST be the same as the OSPF router id at
times that the router is up
Note that [RFC1654] requires that the BGP identifier be an
assigned to the BGP speaker
In the case of IDRP, the IDRP protocol does not explicitly carry
identity of the IDRP speaker. An implicit notion of the identity
the IDRP speaker can be obtained by examining the source address
the IP packets carrying the IDRP information. Therefore, all
speakers participating in the OSPF protocol MUST bind the
identifier to be the address of the OSPF router id
This characteristic makes it convenient for the network
looking at an ASBR to correlate different BGP/IDRP and
information based on the identifier. There is another more
reason for this characteristic
Varadhan, Hares & Rekhter [Page 7]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3, belong
the same autonomous system
+-----+
| RT3 |
+-----+
|
Autonomous System running
/ \
+-----+ +-----+
| RT1 | | RT2 |
+-----+ +-----+
Both RT1 and RT2 can reach an external destination X and import
information into the OSPF routing domain. RT3 is advertising
information about destination X to other external BGP/IDRP speakers
The following rule specifies how RT3 can generate the
advertisement
RT3 MUST determine which ASBR(s) it is using to reach destination
by matching the OSPF router ID for its route to destination with
BGP identifier of the ASBR(s), or the IP source address of the
protocol packet from the ASBR(s).
o If RT3 has equal cost routes to X through RT1 and RT2, then
RT3 MUST merge the PATH through RT1 and RT2 into a SET
o Otherwise, RT3 MAY merge the PATH through RT1 and RT2.
It MAY then generate the corresponding network layer
information for further advertisement to external BGP/IDRP peers
4. Setting OSPF tags, ORIGIN and PATH
The OSPF external route tag is a "32-bit field attached to
external route . . . It may be used to communicate
between AS boundary routers; the precise nature of such
is outside the scope of [the] specification" [RFC1583].
We use the external route tag field in OSPF to intelligently set
ORIGIN and PATH attributes in BGP/IDRP. These attributes are well
known, mandatory attributes in BGP/IDRP. The exact mechanism
setting the tags is defined in sections 4.2 and 4.3.
combination of tag bits is described in two parts
Varadhan, Hares & Rekhter [Page 8]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
import This describes when an ASBR imports an AS external LSA
the OSPF domain with the given tag setting
export This indicates how the BGP/IDRP path attribues should
formatted when an ASBR, having a given type 1 or type 2
OSPF external route in its routing table, decides to
according to the considerations in section 2.1.
The tag is broken up into sub-fields shown below. The
sub-fields specify the characteristics of the set of
destinations imported into the OSPF routing domain
The high bit of the OSPF tag is known as the "Automatic" bit
Setting this bit indicates that the tag has been
automatically by an ASBR
When the network administrator configures the tag, this bit MUST
0. This setting is the default tag setting, and is described
section 4.2.
When the tag is automatically generated, this bit is set to 1.
other bits are defined below
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|c|p l| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c 1 bit of Completeness information, set when the ORIGIN of
route is either or .
pl 2 bits of PathLength information; this field is set
on the length of the PATH that the protocol could have
when importing the reachability information into the
routing domain
12 bits of tag information, defaults to 0 but can
configured to anything else
AutonomousSystem (or "AS")
16 bits, indicating the AS number corresponding to the set
reachable destinations, 0 if the set of reachable
is to be considered as part of the local AS
Varadhan, Hares & Rekhter [Page 9]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
local_AS: The AS number of the local OSPF routing domain
next_hop_AS: The AS number of an external BGP peer
4.1. Configuration parameters for setting the OSPF
o There MUST be a mechanism to enable automatic generation
the tag characteristic bits
o Configuration of an ASBR running OSPF MUST include
capability to associate a tag value, for the ArbitraryTag,
LocalInfo sub-field of the OSPF tag, with each instance of
routing domain
o Configuration of an ASBR running OSPF MUST include
capability to associate an AS number with each instance of
routing domain
Associating an AS number with an instance of an IGP
equivalent to flagging those set of reachable
imported from the IGP to be external destinations outside
local autonomous system
4.2. Manually configured
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| LocalInfo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
import This tag setting corresponds to the administrator
setting the OSPF tag bits
export The route SHOULD be exported into BGP with the
ORIGIN=, PATH=.
Nothing MUST inferred about the characteristics of the set
reachable destinations corresponding to this tag setting
For backward compatibility with existing implementations of
currently deployed in the field, this MUST be the default
for importing destinations into the OSPF routing domain.
MUST be a mechanism to enable automatic tag generation
imported destinations
Varadhan, Hares & Rekhter [Page 10]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
4.3. Automatically generated
4.3.1. Tag = <Automatic = 1, Complete = 0, PathLength = 00>
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
import These are reachable destinations imported from
protocols with incomplete path information and
or may not carry the neighbour AS or AS path (and
the IDRP RD_PATH) as part of the routing information
This setting SHOULD be used to import
destinations from an IGP that the network
has configured as external routes, without
the next_hop_AS
export The route SHOULD be exported into BGP/IDRP with
attributes ORIGIN=, PATH=.
4.3.2. Tag = <Automatic = 1, Complete = 0, PathLength = 01>
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|1| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
import These are reachable destinations imported from
protocols with incomplete path information.
neighbour AS (and therefore IDRP RD) is carried in
routing information
This setting SHOULD be used for importing
destinations from EGP into the OSPF routing domain
This setting MAY also be used when importing
destinations from BGP/IDRP whose ORIGIN=
PATH=; if the BGP/IDRP learned route
no other transitive attributes, then its
via BGP/IDRP to ASBRs internal to the autonomous
MAY be suppressed
export The route SHOULD be exported into BGP/IDRP
ORIGIN= and PATH=.
Varadhan, Hares & Rekhter [Page 11]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
4.3.3. Tag = <Automatic = 1, Complete = 0, PathLength = 10>
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|1|0| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
import These are reachable destinations imported from
protocols with truncated path information
These are imported by a border router, which is
BGP/IDRP to a stub domain, and not running BGP/IDRP
other ASBRs in the same autonomous system. This
a truncation of the PATH. These destinations MUST
be re-exported into BGP/IDRP at another ASBR
export The route MUST never be exported into BGP/IDRP
4.3.4. Tag = <Automatic = 1, Complete = 1, PathLength = 00>
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|0| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
import These are reachable destinations imported from
protocols with either complete path information or
known to be complete through means other than
carried by the routing protocol
This setting SHOULD be used for importing
destinations into OSPF from an IGP
export The route SHOULD be exported to BGP/IDRP
ORIGIN=, PATH=.
4.3.5. Tag = <Automatic = 1, Complete = 1, PathLength = 01>
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|1| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Varadhan, Hares & Rekhter [Page 12]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
import These are reachable destinations imported from
protocols with either complete path information, or
known to be complete through means other than
carried by the routing protocol. The routing
also has additional information about the next hop
or RD, the destination was learned from
This setting SHOULD be used when the
explicitly associates an AS number with an instance
an IGP. This setting MAY also be used when
reachable destinations from BGP/IDRP whose ORIGIN=
and PATH=; if the BGP/IDRP learned
has no other transitive attributes, then
propagation via BGP/IDRP to other ASBRs internal to
autonomous system MAY be suppressed
export OSPF routes with this tag setting SHOULD be
with the BGP/IDRP attributes, ORIGIN=,
PATH=.
4.3.6. Tag = <Automatic = 1, Complete = 1, PathLength = 10>
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|1|0| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
import These are reachable destinations imported from
protocols with complete path information and carry
AS path information as part of the routing information
These destinations MUST not be exported into BGP/
because these are destinations that are
imported from BGP/IDRP into the OSPF RD. Hence, it
assumed that the BGP/IDRP speaker will convey
routes to other BGP/IDRP speakers within the
autonomous system via BGP/IDRP. An ASBR learning
such a destination MUST wait for the BGP update
its internal neighbours before advertising it
external BGP/IDRP peers
export These routes MUST not be exported into BGP/IDRP
Varadhan, Hares & Rekhter [Page 13]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
4.4. Miscellaneous tag
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|x|1|1| Reserved for future use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of PathLength=11 is reserved during automatic
generation. Routers MUST NOT generate such a tag when
reachable destinations into the OSPF routing domain. ASBRs
ignore tags which indicate a PathLength=11.
5. Setting OSPF Forwarding Address and BGP/IDRP NEXT_HOP
Forwarding addresses are used to avoid extra hops between
routers that share a common network and that speak different
protocols with each other on the common network
Both BGP/IDRP and OSPF have equivalents of forwarding addresses.
BGP and IDRP, the NEXT_HOP attribute is a well-known,
attribute. OSPF has a Forwarding address field. We will discuss
these are to be filled in various situations
Consider the 4 router situation below
RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another
RT1 and RT3 are talking BGP/IDRP with each other. RT3 and RT4
talking OSPF with each other
+-----+ +-----+
| RT1 | | RT2 |
+-----+ +-----+
| | common
---+-----------------------+--------------------------
| |
+-----+ +-----+
| RT3 | | RT4 |
+-----+ +-----+
- Importing a reachable destination into OSPF
When importing a destination from BGP/IDRP into OSPF, RT3
always fill the OSPF Forwarding Address with the BGP/
NEXT_HOP attribute for the destination
Varadhan, Hares & Rekhter [Page 14]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
- Exporting a reachable destination into BGP
When exporting set of reachable destinations internal to
OSPF routing domain from OSPF to BGP/IDRP, if all
destinations in the set of reachable destinations are
RT4, then RT3 MAY fill the NEXT_HOP attribute for the set
reachable destinations with the address of RT4. This is
avoid requiring packets to take an extra hop through RT3
traversing the AS boundary. This is similar to the concept
indirect neighbour support in EGP [RFC888, RFC827].
6. Changes from the BGP 3 - OSPF interactions
o The use of the term "route" has attained a more
structure in BGP 4. This document follows the constraint
the manner shown below
- The term "set of reachable destinations" is called a
in [RFC1654].
- The term "route" in the BGP context refers to a set
reachable destinations, and the associated attributes
the set
- The term "route" in the OSPF context refers to the set
reachable destinations, and the cost and the type
reach destinations. This is to keep the
consistent in the document
o The notion of exchanging reachability information between
4 and OSPF has been updated to handle variable length net
information
o The previous term INTER_AS_METRIC in BGP 3 has now
changed to MULTI_EXIT_DISC
o The default metric to be used for importing BGP
into the OSPF RD is now the LOCAL_PREF attribute, instead of
constant value
o Section 3 which requires an ASBR to match the OSPF
corresponding to a route to the BGP Identifier, can
potential loops if the AS has equal cost multipath
amongst the ASBRs. This scenario is outlined in the
below. This is fixed in BGP4 by requiring the ASBR
equal cost multi-path routes to merge the PATHs through
various ASBRs into appropriate SETs
Varadhan, Hares & Rekhter [Page 15]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
o BGP 4 requires that the BGP identifier be an address
to the BGP speaker. This is dealt with in section 3.
o Section 5 on setting NEXT_HOP attributes and
Address field has been updated to account for variable
net information
o This section, 6, has been added
7. Security
Security issues are not discussed in this memo
8.
We would like to thank Jeff Honig (Cornell University), John
(Cascade Communications Corp.), Tony Li (cisco Systems), Rob
(Consultant), Dennis Ferguson (ANS, Inc.), Phil
(Consultant), Scott Bradner (Harvard University), and Joel
(Newbridge Networks Inc.) for their help and suggestions in
this document. Cengiz Aleattinoglu (USC/ISI) and Steve
(USC/ISI) provided fresh insights into the packet looping
described in the appendix
We would also like to thank the countless number of people from
OSPF and BGP working groups who have offered numerous suggestions
comments on the different stages of this document
Thanks also to Bob Braden (ISI), whose suggestions on the
BGP-OSPF document, [RFC1403] were useful even for this one, and
been carried through
We would also like to thank OARnet, where one of the authors did
of his work on this document, before moving to USC to resurrect
PhD
9.
[RFC827] Rosen, E., "Exterior Gateway Protocol (EGP)", RFC 827,
BBN, October 1982.
[RFC888] Seamonson, L., and E. Rosen, "`STUB' Exterior
Protocol", RFC 888, BBN, January 1984.
[RFC1058] Hedrick, C, "Routing Information Protocol", RFC 1058,
Rutgers University, June 1988.
Varadhan, Hares & Rekhter [Page 16]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
[RFC1122] Braden, R., Editor, "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, USC/
Sciences Institute, October 1989.
[RFC1123] Braden, R., Editor, "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
USC/Information Sciences Institute, October 1989.
[RFC1247] Moy, J., "The OSPF Specification Version 2", RFC 1247,
Proteon, January 1991.
[RFC1403] Varadhan, K., "BGP OSPF Interaction", RFC 1403,
OARnet, January 1993.
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting
an Address Assignment and Aggregation Strategy", RFC 1519,
BARRNet, cisco, Merit, OARnet, September 1993.
[RFC1583] Moy, J., "The OSPF Specification Version 2", RFC 1583,
(Obsoletes [RFC1247]), Proteon, March 1994.
[RFC1654] Rekhter, Y., and T. Li, Editors, "A Border
Protocol 4 (BGP-4)", RFC 1654, T.J. Watson Research Center
IBM Corp., cisco Systems, July 1994.
[ROUTE-LEAKING] Almquist, P., "Ruminations on Route Leaking",
Work in Progress
[NEXT-HOP] Almquist, P., "Ruminations on the Next Hop
Work in Progress
[IDRP] Hares, S., "IDRP for IP", Work in Progress
[IS10747] ISO/IEC IS 10747 - Information Processing Systems -
Telecommunications and Information Exchange
Systems - Protocol for Exchange of Inter-domain
Information among Intermediate Systems to
Forwarding of ISO 8473 PDUs, 1993.
Varadhan, Hares & Rekhter [Page 17]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
10.
This is an example of how the two routing protocols, BGP/IDRP
OSPF, might both be consistent in their behaviour, and yet
from a source domain, S, to a destination in domain X might be
in a forwarding loop
+--------+
X ----------| C1 |
| |Domain C
| | C3 C2 |
| +--------+
B / \
\ / \
\ /
\ / /
\ / /
+--------+ /
| A1 A2 | /
|Domain A| /
| A3 |-/
+--------+
Given the domains, X, A, B, C and S, let domains A and C be
OSPF, and ASBRs A3 and C3 have equal cost multipath routes to A1, A
and C1, C2 respectively. The picture above shows the
structure of domains A and C only
During steady state, the following are the route advertisements
o Domain B advertises to A path
o ASBR A3 in domain A advertises path to domain C,
ASBR C2.
o Domain C has two equal cost paths to X: one direct ,
another through A
o BR C3 in domain C advertises to A2 path
o Domain A has two equal cost paths to X: and
Both C1 and C2 inject a route to X within the domain C, and
A1 and A2 inject a route to X within the domain A. Since A3 and C
see equal cost routes to X through A1, A2 and C1, C2 respectively,
stable loop through ASBRs exists
Varadhan, Hares & Rekhter [Page 18]
RFC 1745 BGP4/IDRP for IP - OSPF Interaction December 1994
Section 4 specifies that A3 and C3 that advertise a PATH
destination X, MUST aggregate all the PATHs through A1 and A2, and C
and C2 respectively. This has the consequence of constraining
BGP/IDRP speaker in either domain A or domain C from
multiple routes to destination X, and importing only one route
OSPF. This breaks the multiple paths seen in one domain. The
domain in which the multiple paths are broken is nondeterministic
11. Authors' Present
Kannan
USC/Information Sciences
4676 Admiralty
Marina Del Rey, CA 90292-6695
Phone: +1 310 822 1511 x 402
EMail: kannan@isi.
Susan
Merit, Inc
1071 Beal Avenue
Ann Arbor, MI 48109
Phone: +1 313 936 2095
EMail: skh@merit.
Yakov
T.J. Watson Research Center, IBM
P.O. Box 704,
Yorktown Heights, NY 10598.
Phone: +1 914 784 7361
EMail: yakov@watson.ibm.
Varadhan, Hares & Rekhter [Page 19]
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
