Here's a first cut at a BGP4 OSPF document.
Kannan Varadhan <kannan@oar.net> Thu, 09 July 1992 05:42 UTC
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa12957; 9 Jul 92 1:42 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa12953; 9 Jul 92 1:42 EDT
Received: from interlock.ans.net by NRI.Reston.VA.US id aa17655; 9 Jul 92 1:44 EDT
Received: from moe.rice.edu by interlock.ans.net with SMTP id AA101787 (InterLock SMTP Gateway 1.1 for <iwg@ans.net>); Thu, 9 Jul 1992 00:53:13 -0400
Received: from rice.edu ([128.42.5.1]) by moe.rice.edu (AA26757); Wed, 8 Jul 92 23:53:23 CDT
Received: from malgudi.oar.net by rice.edu (AA04361); Wed, 8 Jul 92 23:52:35 CDT
Received: from valhalla.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA08611; Thu, 9 Jul 1992 00:53:09 -0400
Message-Id: <199207090453.AA08611@malgudi.oar.net>
From: Kannan Varadhan <kannan@oar.net>
Reply-To: kannan@oar.net
X-Mail-Agent: mh-6.7.2-MIME
To: ospf@comet.cit.cornell.edu, iwg@rice.edu
Subject: Here's a first cut at a BGP4 OSPF document.
Date: Thu, 09 Jul 1992 00:56:27 -0400
Sender: kannan@oar.net
Yo folks,
The significant modifications are in sections 2 which deal with
routeNLRI (oops :-) exchange. BGP4 has introduced the
concept of a NLRI being a set of reachable destinations, where a
destination is an IP address, prefix pair, and a BGP route is an NLRI
with other attributes. I have tried to be consistent with that
definition.
We should be discussing this document. I am hoping to fill out the
notions of type 8 LSAs in this document to avoid running n**2 IBGP
sessions, but Rob wanted to defer it to the IETF, so we should discuss
this too there.
Thanks,
Kannan
valhalla% mkrfc bgp4-ospf.ms
Network Working Group K. Varadhan
Request for Comments: DRAFT OARnet
July 9, 1992
BGP4 OSPF Interaction
Table of Contents
1. Introduction .................................................... 1
2. NLRI Exchange ................................................... 2
2.1. Exporting OSPF information into BGP ........................... 3
2.2. Importing BGP information into OSPF ........................... 4
3. BGP Identifier and OSPF router ID ............................... 5
4. Setting OSPF tags, BGP ORIGIN and AS_PATH attributes ............ 6
4.1. Semantics of the characteristics bits ......................... 8
4.2. Configuration parameters for setting the OSPF tag ............. 9
4.3. Manually configured tags ...................................... 9
4.4. Automatically generated tags .................................. 10
4.4.1. NLRIs with incomplete path information, pl = 0 .............. 10
4.4.2. NLRIs with incomplete path information, pl = 1 .............. 10
4.4.3. NLRIs with incomplete path information, pl >= 1 ............. 11
4.4.4. NLRIs with complete path information, pl = 0 ................ 11
4.4.5. NLRIs with complete path information, pl = 1 ................ 12
4.4.6. NLRIs with complete path information, pl >= 1 ............... 12
4.5. Miscellaneous tag settings .................................... 13
4.6. Summary of the TagType field setting .......................... 13
5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ...... 13
6. Security Considerations ......................................... 14
7. Acknowledgements ................................................ 14
8. Bibliography .................................................... 15
9. Author's Address ................................................ 15
Status of this Memo
This memo defines the various criteria to be used when designing
Autonomous System Border Routers (ASBR) that will run BGP4 with other
ASBRs external to the AS and OSPF as its IGP. Distribution of this
memo is unlimited.
1. Introduction
This document defines the various criteria to be used when designing
Autonomous System Border Routers (ASBR) that will run BGP4[BGP-4]
with other ASBRs external to the AS, and OSPF[RFC1247] as its IGP.
All future references of BGP in this document will refer to BGP
version 4, as defined in [BGP-4].
Varadhan [Page 1]
INTERNET DRAFT July 92
This document defines how the following fields in OSPF and attributes
in BGP are to be set when interfacing between BGP and OSPF at an
ASBR:
OSPF cost and type vs. BGP MULTI_EXIT_DISC
OSPF tag vs. BGP ORIGIN and AS_PATH
OSPF Forwarding Address vs. BGP NEXT_HOP
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.''
BGP 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.
2. NLRI Exchange
This section discusses the constraints that must be met to exchange
NLRIs between an external BGP session with a peer from another AS and
internal OSPF NLRIs.
Varadhan [Page 2]
INTERNET DRAFT July 92
2.1. Exporting OSPF information into BGP
1. The administrator must be able to selectively export NLRI
into BGP via an appropriate filter mechanism.
This filter mechanism must support such control with the
granularity of a single destination, represented either as an
IP address prefix or 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.
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.
o By default, no information must be exported from OSPF
into BGP. A single mechanism must permit all OSPF
inter-area and intra-area NLRIs to be exported into BGP.
OSPF external NLRI of type 1 and type 2 must never be
exported into BGP unless they are explicitly configured.
2. A NLRI represented as an address, mask pair, and having a
non-contiguous mask must not be exported to BGP.
3. When configured to export a NLRI from OSPF into BGP, the ASBR
must advertise the route containing the NLRI via BGP as soon
as at least one of the destinations in the NLRI is determined
to be reachable via OSPF and must stop advertising the route
containing the NLRI when none of the desinations in the NLRI
are reachable via OSPF.
4. The network administrator must be able to statically
configure the BGP attribute MULTI_EXIT_DISC attribute to be
used for any route.
o By default, the MULTI_EXIT_DISC must default to 1.
5. An implementation of BGP 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 NLRI via OSPF and subsequent
advertisement of the NLRI via BGP to the external neighbours.
Varadhan [Page 3]
INTERNET DRAFT July 92
o The default value for this setting must be 0, indicating
that the NLRI is to be advertised to the neighbour BGP
peers instantly.
Note that [BGP-4] mandates a mechanism to dampen the
inbound advertisements from adjacent neighbours. See
the variable MinRouteAdvertisementInterval in section
9.2.3.1.
2.2. Importing BGP information into OSPF
1. BGP implementations should allow an AS to control
announcements of BGP-learned NLRI into OSPF. Implementations
should support such control with the granularity of a single
destination, represented either as a IP address, prefix pair
or an address mask pair. 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 By default, no NLRI must be imported from BGP into OSPF.
Administrators must configure every NLRI they wish to
import.
A mechanism may allow an administrator to configure an
ASBR to import all the BGP NLRIs into the OSPF routing
domain.
2. The administrator must be able to configure the OSPF cost and
the OSPF metric type of every NLRI imported into OSPF.
o The OSPF cost must default to 1; the OSPF metric type
must default to type 2.
3. NLRI learned via IBGP must not be imported into OSPF.
4. The ASBR must never generate a default NLRI into the OSPF
routing domain unless explicitly configured to do so.
A default NLRI is a set of all possible destinations. By
convention, it is represented as an IP address 0, with a
prefix 0 or mask of 0 length.
A possible criterion for generating default into an IGP is to
allow the administrator to specify a set of (NLRI, AS_PATH,
default NLRI cost, default NLRI type) tuples. If the ASBR
Varadhan [Page 4]
INTERNET DRAFT July 92
learns of at least one of the destinations in the NLRI, with
the corresponding AS_PATH, then it generates a default NLRI
into the OSPF routing domain, with cost ``default NLRI cost''
and type, ``default NLRI type.'' The lowest cost default NLRI
will then be injected into the OSPF routing domain.
This is the recommended method for originating default NLRIs
in the OSPF routing domain.
3. BGP Identifier and OSPF router ID
The BGP identifier must be the same as the OSPF router id at all
times that the router is up.
This characteristic is required for two reasons.
i Consider the scenario in which 3 routers, RT1, RT2, and RT3,
belong to the same autonomous system.
+-----+
| RT3 |
+-----+
|
Autonomous System running OSPF
/ \
+-----+ +-----+
| RT1 | | RT2 |
+-----+ +-----+
Both RT1 and RT2 can reach an external destination X and
import this information into the OSPF routing domain. RT3 is
advertising this information about destination X to other
external BGP speakers. RT3 must use the OSPF router ID to
determine whether it is using RT1 or RT2 to forward packets to
destination X and hence build the correct AS_PATH to advertise
to other external speakers.
More precisely, RT3 must use the AS_PATH of the NLRI announced
by the ASBR, whose BGP Identifier is the same as the OSPF
routerID corresponding to its NLRI for the destination X.
ii It will be convenient for the network administrator looking at
an ASBR to correlate different BGP and OSPF NLRIs based on the
identifier.
Varadhan [Page 5]
INTERNET DRAFT July 92
Note that BGP requires that an interface IP address on the ASBR be
chosen as the BGP Identifier. Hence, the following mechanism
should be used to ensure the above characteristics:
BGP will assign its Identifier as one of its IP addresses, and
then OSPF will inherit its identifier from BGP.
4. Setting OSPF tags, BGP ORIGIN and AS_PATH attributes
The OSPF external route tag is a ``32-bit field attached to each
external route . . . It may be used to communicate information
between AS boundary routers; the precise nature of such information
is outside the scope of [the] specification.''[RFC1247]
OSPF imports information from various routing protocols at all its
ASBRs. In some instances, it is possible to use protocols other than
EGP or BGP across autonomous systems. It is important, in BGP, to
differentiate between NLRIs that are external to the OSPF routing
domain but must be considered internal to the AS, as opposed to NLRIs
that are external to the AS.
NLRIs that are internal to the AS and that may or may not be external
to the OSPF routing domain will not come to the various BGP speakers
via IBGP. Therefore, ASBRs running BGP must have knowledge of this
class of NLRIs so that they can advertise these NLRIs to the various
external AS without waiting for IBGP updates about these NLRIs.
Additionally, in the specific instance of an AS intermixing routers
running EGP and BGP as external gateway routing protocols, using OSPF
as an IGP, the network administrator does not have to configure IBGP
on every ASBR running EGP and not running BGP, if this information
can be carried in the OSPF tag field.
We use the external route tag field in OSPF to intelligently set the
ORIGIN and AS_PATH attributes in BGP. Both the ORIGIN and AS_PATH
attributes are well-known, mandatory attributes in BGP. The exact
mechanism for setting the tags is defined below.
The tag is broken up into sub-fields shown below. The various sub-
fields specify the characteristics of the NLRI imported into the OSPF
routing domain.
The high bit of the OSPF tag is known as the ``Automatic'' bit. When
this bit is set to 1, the following sub-fields apply:
Varadhan [Page 6]
INTERNET DRAFT July 92
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|a|c|p l| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a is 1 bit called the Automatic bit, indicating that the
Completeness and PathLength bits have been generated
automatically by a router. The meaning of this
characteristic and its setting are defined below.
c is 1 bit of Completeness information. The meaning of this
characteristic and its settings are defined below.
pl are 2 bits of PathLength information. The meaning of this
characteristic and its setting are defined below.
ArbitraryTag (or ``at'')
is 12 bits of tag information, which defaults to 0 but can
be configured to anything else.
AutonomousSystem (or ``as'')
is 16 bits, indicating the AS number corresponding to the
NLRI, 0 if the NLRI is to be considered as part of the
local AS.
When the Automatic bit is set to 0, the following sub-fields
apply:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|a| LocalInfo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
t is 1 bit called the Automatic bit, set to 0.
LocalInfo (or ``li'')
is 31 bits of an arbitrary value, manually configured by
the network administrator.
The format of the tag for various values of the characteristics
bits is defined below.
Varadhan [Page 7]
INTERNET DRAFT July 92
4.1. Semantics of the characteristics bits
The Completeness and PathLength characteristics bits define the
characteristic of the NLRI imported into OSPF from other ASBRs in
the autonomous system. This setting is then used to set the
ORIGIN and NEXT_HOP attributes when re-exporting these NLRIs to an
external BGP speaker.
o The ``a'' bit or the Automatic characteristic bit is set when
the Completeness and PathLength characteristics bits are
automatically set by a border router.
For backward compatibility, the Automatic bit must default to
0 and the network administrator must have a mechanism to
enable automatic tag generation. Nothing must be inferred
about the characteristics of the OSPF NLRI from the tag bits,
unless the tag has been automatically generated.
o The ``c'' bit of the Completeness characteristic bit is set
when the source of the incoming NLRI is known precisely, for
instance, from an IGP within the local autonomous system or
EGP at one of the autonomous system's boundaries. It refers
to the status of the path information carried by the routing
protocol.
o The ``pl'' or the PathLength characteristic sub-field is set
depending on the length of the AS_PATH that the protocol
could have carried when importing the NLRI into the OSPF
routing domain. The length bits will indicate whether the
AS_PATH attribute for the length is zero, one, or greater
than one.
NLRIs imported from an IGP will usually have an AS_PATH of
length of 0, NLRIs imported from an EGP will have an AS_PATH
of length 1, BGP and routing protocols that support complete
path information, either as AS_PATHs or routing domain paths,
will indicate a path greater than 1.
The OSPF tag is not wide enough to carry path information
about NLRIs that have an associated PathLength greater than
one. Path information about these NLRIs will have to be
carried via IBGP. Such NLRIs must not be exported from OSPF
into BGP.
For brevity in the following sections, the keywords O and P refer
to the BGP ORIGIN and AS_PATH attributes respectively. Likewise,
we use the abbreviations , ``l'' and ``nh'' for the local_AS and
next_hop_AS respectively in the following sections.
Varadhan [Page 8]
INTERNET DRAFT July 92
4.2. Configuration parameters for setting the OSPF tag
o There must be a mechanism to enable automatic generation of
the tag characteristic bits.
o Configuration of an ASBR running OSPF must include the
capability to associate a tag value, for the ArbitraryTag, or
LocalInfo sub-field of the OSPF tag, with each instance of a
routing protocol.
o Configuration of an ASBR running OSPF must include the
capability to associate an AS number with each instance of a
routing protocol.
Associating an AS number with an instance of an IGP is
equivalent to flagging those set of NLRIs imported from the
IGP to be external NLRIs outside the local autonomous system.
Specifically, when the IGP is RIP[RFC1058], it should be
possible to associate a tag and/or an AS number with every
interface running RIP on the ASBR.
4.3. Manually configured tags
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This tag setting corresponds to the administrator manually
setting the tag bits. Nothing shall be inferred about the
characteristics of the NLRI corresponding to this tag setting.
For backward compatibility with existing implementations of
OSPF currently deployed in the field, this must be the default
setting for importing NLRIs into the OSPF routing domain.
There must be a mechanism to enable automatic tag generation
for imported NLRIs.
The OSPF tag to BGP attribute mappings for these NLRIs must be
a=0, li=Arbitrary_Value => O=<INCOMPLETE>, P=<l>
Varadhan [Page 9]
INTERNET DRAFT July 92
4.4. Automatically generated tags
4.4.1. NLRIs with incomplete path information, pl = 0.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are NLRIs imported from routing protocols with incomplete
path information and cannot or may not carry the neighbour AS
or AS path as part of the routing information.
The OSPF tag to BGP attribute mappings for these NLRIs must be
a=1,c=0,pl=00,as=0 => O=<EGP>, P=<l>
4.4.2 NLRIs with incomplete path information, pl = 1.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are NLRIs imported from routing protocols with incomplete
path information and carry the neighbour AS as part of the
routing information.
The OSPF tag to BGP attribute mappings for these NLRIs must be
a=1,c=0,pl=01,as=nh => O=<EGP>, P=<l, nh>
This setting should be used for importing EGP NLRIs into the
OSPF routing domain. This setting can also be used when
importing BGP NLRIs whose origin=<EGP> and AS_PATH=<nh>; if
the BGP learned NLRI has no other transitive attributes, then
its propogation via IBGP can be suppressed.
Varadhan [Page 10]
INTERNET DRAFT July 92
4.4.3. NLRIs with incomplete path information, pl >= 1.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are NLRI imported from routing protocols with truncated
path information.
The OSPF tag to BGP attribute mappings for these NLRIs must be
a=1,c=0,pl=10,as=don't care
These are imported by a border router, which is running BGP to
a stub domain, and not running IBGP to other ASBRs. This
causes a truncation of the AS_PATH. These NLRIs must not be
re-exported into BGP at another ASBR.
4.4.4. NLRIs with complete path information, pl = 0.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are NLRIs imported from routing protocols with either
complete path information or are known to be complete through
means other than that carried by the routing protocol.
The OSPF tag to BGP attribute mappings for these NLRIs must be
a=1,c=1,pl=00,as=0 => O=<IGP>, P=<l>
This should be used for importing NLRIs into OSPF from an IGP.
Varadhan [Page 11]
INTERNET DRAFT July 92
4.4.5. NLRIs with complete path information, pl = 1.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are NLRIs imported from routing protocols with either
complete path information, or are known to be complete through
means other than that carried by the routing protocol. The
routing protocol also has additional information about the
neighbour AS of the NLRI.
The OSPF tag to BGP attribute mappings for these NLRIs must be
a=1,c=1,pl=01,as=nh => O=<IGP>, P=<l, nh>
This setting should be used when the administrator explicitly
associates an AS number with an instance of an IGP. This
setting can also be used when importing BGP NLRIs whose
origin=<IGP> and AS_PATH=<nh>; if the BGP learned NLRI has no
other transitive attributes, then its propogation via IBGP can
be suppressed.
4.4.6. NLRIs with complete path information, pl >= 1.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are NLRIs imported from routing protocols with complete
path information and carry the AS path information as part of
the routing information.
The OSPF tag must be set to
a=1,c=1,pl=10,as=don't care
These NLRIs must not be exported into BGP because these NLRIs
are already imported from BGP into the OSPF RD. Hence, it is
assumed that the BGP speaker will convey this information to
other BGP speakers via IBGP.
Note that an implementation may import BGP NLRIs with a path
length of 1 and no other transitive attributes directly into
OSPF and not send these NLRIs via IBGP. In this situation, it
must use tag settings corresponding to 4.1.2.2, or 4.1.2.5.
Varadhan [Page 12]
INTERNET DRAFT July 92
WAITING ON FOLKS FOR TYPE 8 DISCUSSIONS, and DECISIONS
4.5. Miscellaneous tag settings
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 pl = 3 is reserved during automatic tag generation.
Routers must not generate such a tag when importing NLRIs into the
OSPF routing domain. ASBRs must ignore tags which indicate a pl =
3.
4.6. Summary of the tag sub-field setting
The following table summarises the various combinations of
automatic tag settings for the Completeness and PathLength sub-
field of the OSPF tag and the default behaviour permitted for each
setting.
Completeness := 0 | 1 ;
PathLength := 00 | 01 | 10 | 11;
ORIGIN := <INCOMPLETE> | <IGP> | <EGP>;
AS_PATH := valid AS path settings as defined in BGP.
pl = 00 pl = 01 pl = 10 pl = 11
+-----------------------------------------------------------------
|
c = 0 | <EGP><l> <EGP><l,nh> never export reserved
c = 1 | <IGP><l> <IGP><l,nh> out of band reserved
|
The "out of band" in the table above implies that OSPF will not be
able to carry everything that BGP needs in its routing
information. Therefore, some other means must be found to carry
this information. In BGP, this is done via IBGP.
5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute
Forwarding addresses are used to avoid extra hops between multiple
routers that share a common network and that speak different routing
protocols with each other.
Both BGP and OSPF have equivalents of forwarding addresses. In BGP,
the NEXT_HOP attribute is a well-known, mandatory attribute. OSPF
Varadhan [Page 13]
INTERNET DRAFT July 92
has a Forwarding address field. We will discuss how 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 with each other.
RT3 and RT4 are talking OSPF with each other.
+-----+ +-----+
| RT1 | | RT2 |
+-----+ +-----+
| | common network
---+-----------------------+--------------------------
<BGP> | |
+-----+ <OSPF> +-----+
| RT3 | | RT4 |
+-----+ +-----+
- Importing NLRI to OSPF:
When importing an NLRI from BGP into OSPF, RT3 must always
fill the OSPF Forwarding Address with the BGP NEXT_HOP
attribute for the NLRI.
- Exporting NLRI to BGP:
When exporting a NLRI internal to the OSPF routing domain from
OSPF to BGP, if all the destinations in the NLRI are through
RT4, then RT3 may fill the NEXT_HOP attribute for the NLRI
with the address of RT4. This is to avoid requiring packets
to take an extra hop through RT3 when traversing the AS
boundary. This is similar to the concept of indirect
neighbour support in EGP[RFC888, RFC827].
6. Security Considerations
Security considerations ane not discussed in this memo.
7. Acknowledgements
I would like to thank Yakov Rekhter, Jeff Honig, John Moy, Tony Li,
Rob Coltun, and Dennis Ferguson for their help and suggestions in
writing this document, without which I could not have written this
document. I would also like to thank them for giving me the
opportunity to write this document, and putting up with my
muddlements through various phases of this document.
I would also like to thank the countless number of people from the
Varadhan [Page 14]
INTERNET DRAFT July 92
OSPF and BGP working groups who have offered numerous suggestions and
comments on the different stages of this document.
8. Bibliography
[RFC827] Rosen, Eric C., ``Exterior Gateway Protocol (EGP)'', October
1982.
[RFC888] Seamonson, Linda J.; and Rosen, Eric C., ``'STUB' Exterior
Gateway Protocol'', January 1984.
[RFC1058] Hedrick, Charles, L., ``Routing Information Protocol'', June
1988.
[RFC1247] Moy, John, ``The OSPF Specification Version 2'', January
1991.
[RFC1338] Fuller, Vince; Li, Tony; Yu, Jessica; Varadhan, Kannan,
``Supernetting: an Address Assignment and Aggregation Strategy'',
June 1992.
[ROUTE-LEAKING] Almquist, Philip, ``Ruminations on Route Leaking'', in
preparation.
[NEXT-HOP] Almquist, Philip, ``Ruminations on the Next Hop'', in
preparation.
[BGP-4] Rekhter, Yakov; and Li, Tony, Editors ``A Border Gateway
Protocol 4 (BGP-4)'', in preparation.
9. Author's Address:
Kannan Varadhan
Internet Engineer, OARnet,
1224, Kinnear Road,
Columbus, OH 43212-1136.
email: kannan@oar.net
Varadhan [Page 15]
valhalla%
-=-
Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137
Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX)
- Here's a first cut at a BGP4 OSPF document. Kannan Varadhan