As per Relevance of the word complete, we have this rfc below:
Network Working Group K.
Request for Comments: 1364
September 1992
BGP OSPF
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This memo defines the various criteria to be used when
Autonomous System Border Routers (ASBR) that will run BGP with
ASBRs external to the AS and OSPF as its IGP
Table of
1. Introduction ................................................. 2
2. Route Exchange ............................................... 2
2.1. Exporting OSPF routes into BGP ............................. 3
2.2. Importing BGP routes into OSPF ............................. 4
3. BGP Identifier and OSPF router ID ............................ 5
4. Setting OSPF tags, BGP ORIGIN and AS_PATH attributes ......... 5
4.1. Semantics of the characteristics bits ...................... 7
4.2. Configuration parameters for setting the OSPF tag .......... 8
4.3. Manually configured tags ................................... 9
4.4. Automatically generated tags ................................ 9
4.4.1. Routes with incomplete path information, pl = 0 ........... 9
4.4.2. Routes with incomplete path information, pl = 1 ........... 9
4.4.3. Routes with incomplete path information, pl >= 1 ..........10
4.4.4. Routes with complete path information, pl = 0 .............10
4.4.5. Routes with complete path information, pl = 1 .............11
4.4.6. Routes with complete path information, pl >= 1 ............11
4.5. Miscellaneous tag settings ..................................12
4.6. Summary of the TagType field setting ........................12
5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ....12
6. Security Considerations .......................................13
7. Acknowledgements ..............................................13
8. Bibliography ..................................................14
9. Author's Address ..............................................14
Varadhan [Page 1]
RFC 1364 BGP OSPF Interaction September 1992
1.
This document defines the various criteria to be used when
Autonomous System Border Routers (ASBR) that will run BGP [RFC1267]
with other ASBRs external to the AS, and OSPF [RFC1247] as its IGP
This document defines how the following fields in OSPF and
in BGP are to be set when interfacing between BGP and OSPF at
ASBR
OSPF cost and type vs. BGP INTER-AS
OSPF tag vs. BGP ORIGIN and AS_
OSPF Forwarding Address vs. BGP NEXT_
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-3
[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 networks are reachable through it. From the standpoint
exterior routing, an AS can be viewed as monolithic:
to networks directly connected to the AS must be equivalent
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."
2. Route
This section discusses the constraints that must be met to
routes between an external BGP session with a peer from another
and internal OSPF routes
BGP does not carry subnet information in routing updates. Therefore
when referring to a subnetted network in the OSPF routing domain,
consider the equivalent network route in the context of BGP
Varadhan [Page 2]
RFC 1364 BGP OSPF Interaction September 1992
Multiple subnet routes for a subnetted network in OSPF are
into one network route when exported into BGP
2.1. Exporting OSPF routes into
1. The administrator must be able to selectively export
into BGP via an appropriate filter mechanism
This filter mechanism must support such control with
granularity of a single network
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
o By default, no routes must be exported from OSPF
BGP. A single mechanism must permit all OSPF inter-
and intra-area routes to be exported into BGP
OSPF external routes of type 1 and type 2 must never
exported into BGP unless they are explicitly configured
2. When configured to export a network, the ASBR must
a network route for a subnetted network, as long as at
one subnet in the subnetted network is reachable via OSPF
3. The network administrator must be able to
configure the BGP attribute INTER-AS METRIC to be used
any network route
o By default, the INTER_AS METRIC must default to 1.
Explanatory text: The OSPF cost and the BGP INTER-AS
are of different widths. The OSPF cost is a two
metric. The BGP INTER-AS METRIC is only an optional non
transitive attribute. Hence, a more complex BGP INTER-
METRIC-OSPF cost mapping scheme is not necessary
4. When an ASBR is advertising an OSPF route to network Y
external BGP neighbours and learns that the route has
unreachable, the ASBR must immediately propogate
information to the external BGP neighbours
5. An implementation of BGP and OSPF on an ASBR must have
mechanism to set up a minimum amount of time that must
between the learning of a new route via OSPF and
advertisement of the route via BGP to the
Varadhan [Page 3]
RFC 1364 BGP OSPF Interaction September 1992
neighbours
o The default value for this setting must be 0,
that the route is to be advertised to the neighbour
peers instantly
Note that [RFC1267] mandates a mechanism to dampen
inbound advertisements from adjacent neighbours
2.2. Importing BGP routes into
1. BGP implementations should allow an AS to
announcements of BGP-learned routes into OSPF
Implementations should support such control with
granularity of a single network. Implementations should
support such control with the granularity of an
system, where the autonomous system may be either
autonomous system that originated the route or the
system that advertised the route to the local
(adjacent autonomous system).
o By default, no routes must be imported from BGP
OSPF. Administrators must configure every route
wish to import
A mechanism may allow an administrator to configure
ASBR to import all the BGP routes into the OSPF
domain
2. The administrator must be able to configure the OSPF cost
the OSPF metric type of every route imported into OSPF
o The OSPF cost must default to 1; the OSPF metric
must default to type 2.
3. Routes learned via IBGP must not be imported into OSPF
4. The ASBR must never generate a default route into the
routing domain unless explicitly configured to do so
A possible criterion for generating default into an IGP is
allow the administrator to specify a set of (network route
AS_PATH, default route cost, default route type) tuples.
the ASBR learns of the network route for an element of
set, with the corresponding AS_PATH, then it generates
default route into the OSPF routing domain, with
"default route cost" and type, "default route type".
lowest cost default route will then be injected into the
Varadhan [Page 4]
RFC 1364 BGP OSPF Interaction September 1992
routing domain
This is the recommended method for originating default
in the OSPF routing domain
3. BGP Identifier and OSPF router
The BGP identifier must be the same as the OSPF router id at
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
/ \
+-----+ +-----+
| RT1 | | RT2 |
+-----+ +-----+
Both RT1 and RT2 have routes to an external network X and import
into the OSPF routing domain. RT3 is advertising the route
network X to other external BGP speakers. RT3 must use the
router ID to determine whether it is using RT1 or RT2 to
packets to network X and hence build the correct AS_PATH to
to other external speakers
More precisely, RT3 must use the AS_PATH of the route announced
the ASBR, whose BGP Identifier is the same as the OSPF
corresponding to its route for network X
ii. It will be convenient for the network administrator looking
an ASBR to correlate different BGP and OSPF routes based
the identifier
4. Setting OSPF tags, BGP ORIGIN and AS_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." [RFC1247]
Varadhan [Page 5]
RFC 1364 BGP OSPF Interaction September 1992
OSPF imports information from various routing protocols at all
ASBRs. In some instances, it is possible to use protocols other
EGP or BGP across autonomous systems. It is important, in BGP,
differentiate between routes that are external to the OSPF
domain but must be considered internal to the AS, as opposed
routes that are external to the AS
Routes that are internal to the AS and that may or may not
external to the OSPF routing domain will not come to the various
speakers via IBGP. Therefore, ASBRs running BGP must have
of this class of routes so that they can advertise these routes
the various external AS without waiting for IBGP updates about
routes
Additionally, in the specific instance of an AS intermixing
running EGP and BGP as external gateway routing protocols, using
as an IGP, the network administrator does not have to configure
on every ASBR running EGP and not running BGP, if this
can be carried in the OSPF tag field
We use the external route tag field in OSPF to intelligently set
ORIGIN and AS_PATH attributes in BGP. Both the ORIGIN and AS_
attributes are well-known, mandatory attributes in BGP. The
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 route imported into
OSPF routing domain
The high bit of the OSPF tag is known as the "Automatic" bit.
this bit is set to 1, 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|c|p l| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a is 1 bit called the Automatic bit, indicating that
Completeness and PathLength bits have been
automatically by a router. The meaning of this
and its setting are defined below
c is 1 bit of Completeness information. The meaning of
characteristic and its settings are defined below
pl are 2 bits of PathLength information. The meaning of
characteristic and its setting are defined below
Varadhan [Page 6]
RFC 1364 BGP OSPF Interaction September 1992
ArbitraryTag (or "at")
is 12 bits of tag information, which defaults to 0 but can
configured to anything else
AutonomousSystem (or "as")
is 16 bits, indicating the AS number corresponding to
route, 0 if the route is to be considered as part of the
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a is 1 bit called the Automatic bit, set to 0.
LocalInfo (or "li")
is 31 bits of an arbitrary value, manually configured by
network administrator
The format of the tag for various values of the characteristics
is defined below
4.1. Semantics of the characteristics
The Completeness and PathLength characteristics bits define
characteristic of the route imported into OSPF from other ASBRs
the autonomous system. This setting is then used to set the
and NEXT_HOP attributes when re-exporting these routes to an
BGP speaker
o The "a" bit or the Automatic characteristic bit is set
the Completeness and PathLength characteristics bits
automatically set by a border router
For backward compatibility, the Automatic bit must default
0 and the network administrator must have a mechanism
enable automatic tag generation. Nothing must be
about the characteristics of the OSPF route from the
bits, unless the tag has been automatically generated
o The "c" bit of the Completeness characteristic bit is
when the source of the incoming route is known precisely,
instance, from an IGP within the local autonomous system
EGP at one of the autonomous system's boundaries. It
Varadhan [Page 7]
RFC 1364 BGP OSPF Interaction September 1992
to the status of the path information carried by the
protocol
o The "pl" or the PathLength characteristic sub-field is
depending on the length of the AS_PATH that the
could have carried when importing the route into the
routing domain. The length bits will indicate whether
AS_PATH attribute for the length is zero, one, or
than one
Routes imported from an IGP will usually have an AS_PATH
length of 0, routes imported from an EGP will have an AS_
of length 1, BGP and routing protocols that support
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
about routes that have an associated PathLength greater
one. Path information about these routes will have to
carried via IBGP. Such routes must not be exported from
into BGP
For brevity in the following sections, the keywords O and P refer
the BGP ORIGIN and AS_PATH attributes respectively. Likewise, we
the abbreviations , "l" and "nh" for the local_AS and next_hop_
respectively in the following sections
4.2. 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 protocol
o Configuration of an ASBR running OSPF must include
capability to associate an AS number with each instance of
routing protocol
Associating an AS number with an instance of an IGP
equivalent to flagging those set of routes imported from
IGP to be external routes outside the local
system
Specifically, when the IGP is RIP [RFC1058], it should
possible to associate a tag and/or an AS number with
Varadhan [Page 8]
RFC 1364 BGP OSPF Interaction September 1992
interface running RIP on the ASBR
4.3. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This tag setting corresponds to the administrator manually
the tag bits. Nothing shall be inferred about the characteristics
the route corresponding to this tag setting
For backward compatibility with existing implementations of
currently deployed in the field, this must be the default setting
importing routes into the OSPF routing domain. There must be
mechanism to enable automatic tag generation for imported routes
The OSPF tag to BGP attribute mappings for these routes must
a=0, li=Arbitrary_Value => O=, P=
4.4. Automatically generated
4.4.1. Routes 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 routes imported from routing protocols with
path information and cannot or may not carry the neighbour AS
AS path as part of the routing information
The OSPF tag to BGP attribute mappings for these routes must
a=1,c=0,pl=00,as=0 => O=, P=
4.4.2 Routes 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 routes imported from routing protocols with
Varadhan [Page 9]
RFC 1364 BGP OSPF Interaction September 1992
path information and carry the neighbour AS as part of the
information
The OSPF tag to BGP attribute mappings for these routes must
a=1,c=0,pl=01,as=nh => O=, P=
This setting should be used for importing EGP routes into the
routing domain. This setting can also be used when importing
routes whose origin= and AS_PATH=; if the BGP
route has no other transitive attributes, then its propogation
IBGP can be suppressed
4.4.3. Routes 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 routes imported from routing protocols with
path information
The OSPF tag to BGP attribute mappings for these routes must
a=1,c=0,pl=10,as=don't
These are imported by a border router, which is running BGP to
stub domain, and not running IBGP to other ASBRs. This causes
truncation of the AS_PATH. These routes must not be re-
into BGP at another ASBR
4.4.4. Routes 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 routes imported from routing protocols with
complete path information or are known to be complete
means other than that carried by the routing protocol
The OSPF tag to BGP attribute mappings for these routes must
a=1,c=1,pl=00,as=0 => O=, P=
This should be used for importing routes into OSPF from an IGP
Varadhan [Page 10]
RFC 1364 BGP OSPF Interaction September 1992
4.4.5. Routes 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 routes imported from routing protocols with
complete path information, or are known to be complete
means other than that carried by the routing protocol.
routing protocol also has additional information about
neighbour AS of the route
The OSPF tag to BGP attribute mappings for these routes must
a=1,c=1,pl=01,as=nh => O=, P=
This setting should be used when the administrator
associates an AS number with an instance of an IGP. This
can also be used when importing BGP routes whose origin=
AS_PATH=; if the BGP learned route has no other
attributes, then its propogation via IBGP can be suppressed
4.4.6. Routes 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 routes imported from routing protocols with
path information and carry the AS path information as part of
routing information
The OSPF tag must be set
a=1,c=1,pl=10,as=don't
These routes must not be exported into BGP because these
are already imported from BGP into the OSPF RD. Hence, it
assumed that the BGP speaker will convey this information to
BGP speakers via IBGP
Note that an implementation may import BGP routes with a
length of 1 and no other transitive attributes directly into
and not send these routes via IBGP. In this situation, it
use tag settings corresponding to 4.1.2.2, or 4.1.2.5.
Varadhan [Page 11]
RFC 1364 BGP OSPF Interaction September 1992
4.5. 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 pl = 3 is reserved during automatic tag generation
Routers must not generate such a tag when importing routes into
OSPF routing domain. ASBRs must ignore tags which indicate a pl = 3.
4.6. Summary of the tag sub-field
The following table summarises the various combinations of
tag settings for the Completeness and PathLength sub-field of
OSPF tag and the default behaviour permitted for each setting
Completeness := 0 | 1 ;
PathLength := 00 | 01 | 10 | 11;
ORIGIN := | | ;
AS_PATH := valid AS path settings as defined in BGP
pl = 00 pl = 01 pl = 10 pl = 11
+----------------------------------------------------------------
|
c = 0 | never export
c = 1 | out of band
|
The "out of band" in the table above implies that OSPF will not
able to carry everything that BGP needs in its
information. Therefore, some other means must be found to
this information. In BGP, this is done via IBGP
5. Setting OSPF Forwarding Address and BGP 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
Both BGP and OSPF have equivalents of forwarding addresses. In BGP
the NEXT_HOP attribute is a well-known, mandatory attribute.
has a Forwarding address field. We will discuss how these are to
filled in various situations
Consider the 4 router situation below
Varadhan [Page 12]
RFC 1364 BGP OSPF Interaction September 1992
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
---+-----------------------+--------------------------
| |
+-----+ +-----+
| RT3 | | RT4 |
+-----+ +-----+
- Importing network X to OSPF
Consider an external network X, learnt via BGP from RT1.
RT3 must always fill the OSPF Forwarding Address with the
NEXT_HOP attribute for the route to network X
- Exporting network Y to BGP
Consider a network Y, internal to the OSPF routing domain
RT3's route to network Y is via RT4, and network Y is to
exported via BGP to RT1.
If network Y is not a subnetted network, RT3 must fill
NEXT_HOP attribute for network Y with the address of RT4.
This is to avoid requiring packets to take an extra
through RT3 when traversing the AS boundary. This is
to the concept of indirect neighbour support in EGP [RFC888,
RFC827].
6. Security
Security considerations are not discussed in this memo
7.
I would like to thank Yakov Rekhter, Jeff Honig, John Moy, Tony Li
and Dennis Ferguson for their help and suggestions in writing
document, without which I could not have written this document.
would also like to thank them for giving me the opportunity to
this document, and putting up with my muddlements through
phases of this document
Varadhan [Page 13]
RFC 1364 BGP OSPF Interaction September 1992
I 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
8.
[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.
[RFC1267] Lougheed, K., and Y. Rekhter, "A Border
Protocol 3 (BGP-3)", RFC 1267, cisco Systems
T.J. Watson Research Center, IBM Corp., October 1991.
[RFC1268] Rekhter, Y., and P. Gross, Editors, "Application of
Border Gateway Protocol in the Internet", RFC 1268,
T.J. Watson Research Center, IBM Corp., ANS, October 1991.
[RFC1247] Moy, J., "The OSPF Specification - Version 2:", RFC 1247,
Proteon, January 1991.
[ROUTE-LEAKING] Almquist, P., "Ruminations on Route Leaking",
Work in Progress
[NEXT-HOP] Almquist, P., "Ruminations on the Next Hop",
Work in Progress
9. Author's
Kannan
Internet Engineer,
1224 Kinnear
Columbus, OH 43212-1136
EMail: kannan@oar.
Varadhan [Page 14]
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
