RFC 1403

BGP OSPF Interaction

📅 published January 1993, from ietf

RFC 1403: BGP OSPF Interaction ✨

okay bestie, so this is RFC 1403, called BGP OSPF Interaction 🦋 it was written by K. Varadhan at OARnet and dated January 1993. it's an IAB standards track protocol doc, and it obsoletes RFC 1364 (this one is basically a re-release of 1364 with some editorial fixes 💅)

Status of This Memo

ok so this doc is a spec for an IAB standards track protocol for the Internet community 🌸 it's asking everyone for discussion and suggestions for improvements 💜 for where this protocol actually stands, check the current edition of the "IAB Official Protocol Standards" 📜 and fyi, distribution of this memo is unlimited 🎀

Abstract

this memo lays out the criteria you need to think about when designing an Autonomous System Border Router (ASBR) that runs BGP with other ASBRs outside its AS and uses OSPF as its IGP 🧚 it's a republication of RFC 1364 to fix some editorial problems ✨

 1.  Introduction ....................................................  2
 2.  Route Exchange ..................................................  3
 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 ............  6
 4.1.  Semantics of the characteristics bits .........................  8
 4.2.  Configuration parameters for setting the OSPF tag .............  9
 4.3.  Manually configured tags ...................................... 10
 4.4.  Automatically generated tags .................................. 10
 4.4.1.  Routes with incomplete path information, PathLength = 0 ..... 10
 4.4.2.  Routes with incomplete path information, PathLength = 1 ..... 11
 4.4.3.  Routes with incomplete path information, PathLength >= 1 .... 11
 4.4.4.  Routes with complete path information, PathLength = 0 ....... 12
 4.4.5.  Routes with complete path information, PathLength = 1 ....... 12
 4.4.6.  Routes with complete path information, PathLength >= 1 ...... 13
 4.5.  Miscellaneous tag settings .................................... 13
 4.6.  Summary of the TagType field setting .......................... 14
 5.  Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ...... 14
 6.  Security Considerations ......................................... 15
 7.  Acknowledgements ................................................ 15
 8.  Bibliography .................................................... 16
 9.  Author's Address ................................................ 17

1. Introduction 🎀

okay so this doc defines the rules for designing an Autonomous System Border Router (ASBR) that runs BGP [RFC1267] with other ASBRs outside the AS, and OSPF [RFC1247] as its IGP 💖

it also spells out how these fields in OSPF and these attributes in BGP should be set when the two protocols meet at an ASBR 🧠✨

        OSPF cost and type      vs. BGP INTER-AS METRIC
        OSPF tag                vs. BGP ORIGIN and AS_PATH
        OSPF Forwarding Address vs. BGP NEXT_HOP

if you want the big-picture treatise on routing and route exchange problems, go read [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist 📚 he's the one to ask 🫶

this doc uses two terms, "Autonomous System" and "Routing Domain", and here's how they're defined 🦋

the term Autonomous System means the same thing it does in the BGP-3 RFC [RFC1267], which says:

"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 networks are reachable through it. From the standpoint of exterior routing, an AS can be viewed as monolithic: reachability to networks 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 it's defined as:

"A Routing Domain is a collection of routers which coordinate their routing knowledge using a single (instance of) a routing protocol."

this doc follows the conventions from the Host Requirements RFCs [RFC1122, RFC1123] when it uses the terms "MUST", "SHOULD", and "MAY" for the various requirements 💅

2. Route Exchange 🌈

this section covers the constraints you have to meet to swap routes between an external BGP session (with a peer from another AS) and the internal OSPF routes 🔥

so BGP doesn't carry subnet info in its routing updates 😭 which means that when we talk about a subnetted network in the OSPF routing domain, we look at the equivalent network route from BGP's point of view 🙈 multiple subnet routes for one subnetted network in OSPF get collapsed into one network route when they're exported into BGP 🍓

2.1. Exporting OSPF routes into BGP

the administrator MUST be able to selectively export OSPF routes into BGP through an appropriate filter mechanism 💅

this filter mechanism MUST support that control with the granularity of a single network ✨

the administrator MUST also be able to filter based on the OSPF tag and its various sub-fields 🎀 the settings for the tag and sub-fields are covered in more detail in section 4 🧚

the default MUST be to export no routes from OSPF into BGP 🙅‍♀️ a single configuration parameter MUST permit all OSPF inter-area and intra-area routes to be exported into BGP 💖

OSPF external routes of type 1 and type 2 MUST never be exported into BGP unless they're explicitly configured 💀

when the ASBR is set up to export a network, it MUST advertise a network route for a subnetted network, as long as at least one subnet in that network is reachable via OSPF 🦋
the network administrator MUST be able to statically configure the BGP attribute INTER-AS METRIC for any network route 🌸
- by default, the INTER_AS METRIC MUST not be set 🙈 this is because the INTER_AS METRIC is an optional attribute in BGP 🫶

Explanatory text: the OSPF cost and the BGP INTER-AS METRIC are different widths 🍓 the OSPF cost is a two level metric, and the BGP INTER-AS METRIC is only an optional non-transitive attribute 🧠 so a more complex BGP INTER-AS METRIC-OSPF cost mapping scheme isn't necessary 👑

when an ASBR is advertising an OSPF route to network Y to external BGP neighbours and it learns the route has become unreachable, the ASBR MUST immediately propagate that info to the external BGP neighbours 😭
an implementation of BGP and OSPF on an ASBR MUST have a mechanism to set up a minimum amount of time that must pass between learning a new route via OSPF and later advertising that route via BGP to the external neighbours ⏳
- the default value for this setting MUST be 0, which means the route gets advertised to the neighbour BGP peers instantly ⚡

note that [RFC1267] mandates a mechanism to dampen the inbound advertisements from adjacent neighbours 🧊

2.2. Importing BGP routes into OSPF

BGP implementations SHOULD allow an AS to control announcements of BGP-learned routes into OSPF 🎀 implementations SHOULD support that control with the granularity of a single network 💖 implementations SHOULD also support that control with the granularity of an autonomous system, where the autonomous system could be either the one that originated the route or the one that advertised it to the local system (the adjacent autonomous system) 🌈
- the default MUST be to export no routes from BGP into OSPF 🙅‍♀️ administrators must configure every route they want to import ✨

a configuration parameter MAY allow an administrator to configure an ASBR to import all the BGP routes into the OSPF routing domain 🧚

the administrator MUST be able to configure the OSPF cost and the OSPF metric type of every route imported into OSPF 🔥
- the OSPF cost MUST default to 1, and the OSPF metric type MUST default to type 2 💅
routes learned via BGP from peers within the same AS MUST not be imported into OSPF 🙈
the ASBR MUST never generate a default route into the OSPF routing domain unless it's explicitly configured to do so 💀

a possible criterion for generating a default into an IGP is letting the administrator specify a set of (network route, AS_PATH, default route cost, default route type) tuples 🍓 if the ASBR learns of the network route for an element of the set, with the matching AS_PATH, then it generates a default route into the OSPF routing domain, with cost "default route cost" and type "default route type" ✨ the lowest cost default route then gets injected into the OSPF routing domain 🦋

this is the recommended method for originating default routes 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 🎀

there are two reasons this matters 🧠

i. synchronisation between OSPF and BGP 🌸

consider a scenario where 3 ASBRs, RT1, RT2, and RT3, all belong to the same autonomous system 🧚

                                     +-----+
                                     | RT3 |
                                     +-----+
                                        |

                          Autonomous System running OSPF

                                 /               \
                             +-----+          +-----+
                             | RT1 |          | RT2 |
                             +-----+          +-----+

both RT1 and RT2 have routes to an external network X and import it into the OSPF routing domain 🔥 RT3 is advertising the route to network X to other external BGP speakers 📣 RT3 has to use the OSPF router ID to figure out whether it's using RT1 or RT2 to forward packets to network X, so it can build the correct AS_PATH to advertise to other external speakers 💅

more precisely, RT3 has to work out which ASBR it's using to reach network X by matching the OSPF router ID for its route to network X with the BGP Identifier of one of the ASBRs 🦋 then it uses that corresponding route for further advertisement to external BGP peers 🫶

ii. it's convenient for the network administrator looking at an ASBR to correlate different BGP and OSPF routes based on the identifier 👑

4. Setting OSPF tags, BGP ORIGIN and AS_PATH attributes 🌈

ok so 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 pulls in routes from other routing protocols at all of its ASBRs 🦋 and sometimes you can use protocols that aren't EGP or BGP to cross autonomous systems ✨. The big thing to get straight in BGP is telling apart routes that are external to the OSPF routing domain but still have to count as internal to the AS, and routes that are external to the AS entirely 💅.

Routes that are internal to the AS, whether or not they're external to the OSPF routing domain, will never reach the various BGP speakers from other BGP speakers in the same AS via BGP 😭. So ASBRs running BGP need to already know about this class of routes, which lets them advertise these routes to the different external ASes without waiting for BGP updates about them from other BGP speakers in the same AS 🫶.

Also, if an AS mixes routers running EGP and BGP as exterior gateway routing protocols and uses OSPF as an IGP, then inside that AS it may not be necessary to run BGP with every ASBR that runs EGP and doesn't run BGP 🌈, as long as this information can be carried in the OSPF tag field.

We use the external route tag field in OSPF to smartly set the ORIGIN and AS_PATH attributes in BGP 👑. Both ORIGIN and AS_PATH are well-known, mandatory attributes in BGP, so this matters a lot. The exact mechanism for setting the tags is defined below 💖.

The tag gets split up into sub-fields, shown below. The sub-fields describe the characteristics of the route that got imported into the OSPF routing domain 🎀.

The high bit of the OSPF tag is called the "Automatic" bit. When this bit is set to 1, these 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, which says the Completeness and PathLength bits were generated automatically by a router 🤖. What that means and how it gets set is defined below.
c is 1 bit of Completeness information. Its meaning and settings are defined below.
pl is 2 bits of PathLength information. Its meaning and setting are defined below.
ArbitraryTag is 12 bits of tag information. It defaults to 0 but can be configured to anything else 🧚.
AutonomousSystem (or "AS") is 16 bits, holding the AS number that corresponds to the route. It's 0 if the route is supposed to count as part of the local AS 🍓.
- local_AS: the term refers to the AS number of the local OSPF routing domain.
- next_hop_AS: this refers to the AS number of an external BGP peer.

When the Automatic bit is set to 0, these 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 is 31 bits of an arbitrary value, manually configured by the network administrator 🌸.

The format of the tag for the various values of the characteristics bits is defined below 💅.

4.1. Semantics of the characteristics bits ✨

The Completeness and PathLength characteristics bits describe the characteristics of the route imported into OSPF from other ASBRs in the autonomous system. This setting is then used to set the ORIGIN and NEXT_HOP attributes when these routes get re-exported to an external BGP speaker 🦋.

The Automatic characteristic bit is set when the Completeness and PathLength characteristics bits are set automatically 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 route from the tag bits, unless the tag has been automatically generated 🙈.

The Completeness characteristic bit is set when the source of the incoming route is known precisely. For instance, that's an IGP inside the local autonomous system, or an EGP at one of the autonomous system's boundaries. It refers to the status of the path information carried by the routing protocol 🫶.
The PathLength characteristic sub-field is set depending on the length of the AS_PATH that the protocol could have carried when importing the route into the OSPF routing domain. The length bits indicate whether the AS_PATH attribute length is zero, one, or greater than one 🔢.

Routes imported from an IGP will usually have an AS_PATH of length of 0. Routes 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 isn't wide enough to carry path information about routes with a PathLength greater than one. Path information about these routes has to be carried via BGP to the other ASBRs in the same AS. Such routes must not be exported from OSPF into BGP 🚫.

4.2. Configuration parameters for setting the OSPF tag 🎀

There MUST be a mechanism to enable automatic generation of the tag characteristic bits 🔐.
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 🏷️.
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 basically the same as flagging that set of routes imported from the IGP as external routes outside the local autonomous system 👀.

Specifically, when the IGP is RIP [RFC1058, RFC1388], 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 is what happens when the administrator sets the tag bits by hand 🧑‍💻. Nothing MUST be inferred about the characteristics of the route corresponding to this tag setting.

For backward compatibility with existing implementations of OSPF that are currently deployed in the field, this MUST be the default setting for importing routes into the OSPF routing domain. There MUST be a mechanism to enable automatic tag generation for imported routes 🔧.

The OSPF tag to BGP attribute mappings for these routes MUST be

Automatic=0, LocalInfo=Arbitrary_Value =>
                           ORIGIN=<INCOMPLETE>, AS_PATH=<local_AS>

4.4. Automatically generated tags 🤖

4.4.1. Routes with incomplete path information, PathLength = 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 incomplete path information, which 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 routes MUST be

Automatic=1, Completeness=0, PathLength=00, AS=0 =>
                               ORIGIN=<EGP>, AS_PATH=<local_AS>

4.4.2 Routes with incomplete path information, PathLength = 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 incomplete path information. The neighbour AS is carried in the routing information 📡.

The OSPF tag to BGP attribute mappings for these routes MUST be

Automatic=1, Completeness=0, PathLength=01, AS=<next_hop_AS>
               => ORIGIN=<EGP>, AS_PATH=<local_AS, next_hop_AS>

This setting SHOULD be used for importing EGP routes into the OSPF routing domain. This setting MAY also be used when importing BGP routes whose ORIGIN=<EGP> and AS_PATH=<next_hop_AS>. If the BGP learned route has no other transitive attributes, then its propagation via BGP to ASBRs internal to the AS MAY be suppressed 🌷.

4.4.3. Routes with incomplete path information, PathLength >= 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 truncated path information 🪄.

The OSPF tag to BGP attribute mappings for these routes MUST be

Automatic=1, Completeness=0, PathLength=10, AS=don't care

These are imported by a border router that runs BGP to a stub domain and doesn't run BGP to other ASBRs in the same AS. That causes a truncation of the AS_PATH. These routes MUST not be re-exported into BGP at another ASBR 🛑.

4.4.4. Routes with complete path information, PathLength = 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 either complete path information, or routes known to be complete through means other than what the routing protocol carries 💫. The OSPF tag to BGP attribute mappings for these routes MUST be

Automatic=1, Completeness=1, PathLength=00, AS=0
                               => ORIGIN=<EGP>, AS_PATH=<local_AS>

bestie, this one SHOULD be used for importing routes into OSPF from an IGP 🌸✨

4.4.5. Routes with complete path information, PathLength = 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        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

okay so these are the routes that get imported from routing protocols with complete path info, or routes we already know are complete through some other means than what the routing protocol carries 🦋 The routing protocol also has extra info about the neighbour AS of the route, which is so iconic of it 👑

The OSPF tag to BGP attribute mappings for these routes MUST be (no skipping, it's giving rules 💅):

Automatic=1, Completeness=1, PathLength=01, AS=next_hop_AS
                  => ORIGIN=<IGP>, AS_PATH=<local_AS, next_hop_AS>

ok this setting SHOULD be used when the admin explicitly links an AS number to an instance of an IGP 🎀 It MAY also be used when importing BGP routes whose ORIGIN=<IGP> and AS_PATH=<next_hop_AS>. If the BGP learned route has no other transitive attributes, then its propagation via BGP to other ASBRs internal to the AS MAY be suppressed 🙈

4.4.6. Routes with complete path information, PathLength >= 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 complete path info, and they carry the AS path info as part of the routing info 🧚

The OSPF tag MUST be set to:

Automatic=1, Completeness=1, PathLength=10, AS=don't care

These routes MUST not be exported into BGP, because they were already imported from BGP into the OSPF RD. So it's assumed the BGP speaker will pass this info along to other BGP speakers in the same AS over BGP. An ASBR that learns about one of these routes MUST wait for the BGP update from its internal neighbours before advertising it to external BGP peers. Wait your turn, bestie 💀

Note that an implementation MAY import BGP routes with a path length of 1 and no other transitive attributes directly into OSPF, and not send those routes over BGP to ASBRs in the same AS 🌈 In that situation, it MUST use tag settings corresponding to 4.4.2, or 4.4.5.

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 PathLength=11 is reserved during automatic tag generation 🍓 Routers MUST not generate such a tag when importing routes into the OSPF routing domain. And ASBRs MUST ignore any tags that indicate a PathLength=11. Hard boundaries, no debate 🔥

4.6. Summary of the tag sub-field setting

here's the tea ☕ This table sums up the different automatic tag combos for the Completeness and PathLength sub-fields of the OSPF tag, plus the default behaviour allowed 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

PathLength ==> 00               01                   10            11
Completeness
  ||     +--------------------------------------------------------------
  vv     |
  =  NO  |    <EGP>            <EGP>             never export   reserved
         |  <local_AS>  <local_AS,next_hop_AS>
         |
  = YES  |    <IGP>            <IGP>             out of band    reserved
         |  <local_AS>  <local_AS,next_hop_AS>
         |

the "out of band" bit above basically means OSPF can't carry everything BGP needs in its routing info 😭 So some other way has to be found to carry that info. In BGP, that's handled by running BGP with the other ASBRs in the same AS 🫶

5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute

okay so forwarding addresses exist to help routers that share a common network skip extra hops, even when they're speaking 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 has a Forwarding address field. We're gonna go through how these get filled in for different situations ✨

Let's look at this 4 router setup 👀

        +-----+                 +-----+
        | RT1 |                 | RT2 |
        +-----+                 +-----+
           |                       |            common network
        ---+-----------------------+--------------------------
             <BGP> |                       |
                +-----+     <OSPF>      +-----+
                | RT3 |                 | RT4 |
                +-----+                 +-----+

RT1 and RT2 are in one autonomous system, and RT3 and RT4 are in another. RT1 and RT3 are talking BGP with each other. RT3 and RT4 are talking OSPF with each other 🌸

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 BGP 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 goes via RT4, and network Y is to be exported via BGP to RT1 💜 If network Y is not a subnetted network, RT3 MUST fill the NEXT_HOP attribute for network Y with the address of RT4. This avoids making packets take an extra hop through RT3 when crossing the AS boundary. It's similar to the concept of indirect neighbour support in EGP [RFC888, RFC827] 🧚

6. Security Considerations

Security issues are not discussed in this memo. 💀😭 The RFC is literally telling you it's not covering security here, so keep that in mind while you build 🙈

7. Acknowledgements

Kannan wants to give a huge shoutout to Yakov Rekhter, Jeff Honig, John Moy, Tony Li, Dennis Ferguson, and Phil Almquist 🫶 for their help and suggestions in writing this document. Without them the doc could not have been written. Kannan also thanks them for giving him the opportunity to write this document, and for putting up with his muddlements through the various phases of it 💖

Kannan also thanks the countless people from the OSPF and BGP working groups who offered loads of suggestions and comments on the different stages of the document 🌈

And a special thanks to Bob Braden, who went through the document thoroughly and came back with questions and comments that were super useful ✨ Those suggestions were carried over into the next version of this document, which dealt with BGP 4 and OSPF 👑

8. Bibliography

[RFC827] Rosen, E., "Exterior Gateway Protocol (EGP)", RFC 827, BBN, October 1982.

[RFC888] Seamonson, L., and E. Rosen, "STUB Exterior Gateway Protocol", RFC 888, BBN, January 1984.

[RFC1058] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058, Rutgers University, June 1988.

[RFC1388] Malkin, G., "RIP Version 2 - Carrying Additional Information", RFC 1388, Xylogics, Inc., January 1993.

[RFC1122] Braden, R., Editor, "Requirements for Internet Hosts - Communication Layers, STD 3, RFC 1122, USC/Information 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.

[RFC1267] Lougheed, K., and Y. Rekhter, "A Border Gateway 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 the 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 Address

Kannan Varadhan
Internet Engineer, OARnet,
1224, Kinnear Road,
Columbus, OH 43212-1136.

Phone: (614) 292-4137

Email: kannan@oar.net

📦 where this page comes from

ietf: rfc1403 1993-01
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms

RFC 1403

RFC 1403: BGP OSPF Interaction ✨

Status of This Memo

Abstract

Table of Contents

1. Introduction 🎀

2. Route Exchange 🌈

2.1. Exporting OSPF routes into BGP

2.2. Importing BGP routes into OSPF

3. BGP Identifier and OSPF router ID 💜

4. Setting OSPF tags, BGP ORIGIN and AS_PATH attributes 🌈

4.1. Semantics of the characteristics bits ✨

4.2. Configuration parameters for setting the OSPF tag 🎀

4.3. Manually configured tags 💖

4.4. Automatically generated tags 🤖

4.4.1. Routes with incomplete path information, PathLength = 0.

4.4.2 Routes with incomplete path information, PathLength = 1.

4.4.3. Routes with incomplete path information, PathLength >= 1.

4.4.4. Routes with complete path information, PathLength = 0.

4.4.5. Routes with complete path information, PathLength = 1.

4.4.6. Routes with complete path information, PathLength >= 1.

4.5. Miscellaneous tag settings

4.6. Summary of the tag sub-field setting

5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute

6. Security Considerations

7. Acknowledgements

8. Bibliography

9. Author's Address