RFC 1745
BGP4/IDRP for IP---OSPF Interaction
RFC 1745: BGP4/IDRP for IP---OSPF Interaction ✨
This one is from the Network Working Group 🌸 and it's dated December 1994. The authors are K. Varadhan (OARnet & ISI), S. Hares (NSFnet/Merit), and Y. Rekhter (T.J. Watson Research Center, IBM Corp.). It's on the Standards Track, and its title block doesn't list anything it obsoletes or updates. Iconic lineup, honestly 👑
Status of this Memo
Okay so this doc is an Internet standards track protocol for the whole Internet community 🌐 It's also asking for discussion and suggestions for improvements, so feedback is literally welcome 💖 If you want the current standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share away 🦋
Abstract
The vibe here is that this memo sets out the criteria you need when you're designing an Autonomous System Border Router (ASBR) 🎀 That ASBR runs either BGP4 or IDRP for IP, talks to other ASBRs outside its AS, and uses OSPF as its IGP. Main character router energy 💅
Table of Contents
1. Introduction ................................................. 2
2. Reachability Information Exchange ............................ 4
2.1. Exporting OSPF information into BGP/IDRP .................. 4
2.2. Importing BGP/IDRP information into OSPF ................... 6
3. BGP/IDRP Identifier and OSPF router ID ....................... 7
4. Setting OSPF tags, ORIGIN and PATH attributes ................ 8
4.1. Configuration parameters for setting the OSPF tag .......... 10
4.2. Manually configured tags ................................... 10
4.3. Automatically generated tags ............................... 11
4.3.1. Tag = <Automatic = 1, Complete = 0, PathLength = 00> ...... 11
4.3.2. Tag = <Automatic = 1, Complete = 0, PathLength = 01> ...... 11
4.3.3. Tag = <Automatic = 1, Complete = 0, PathLength = 10> ...... 12
4.3.4. Tag = <Automatic = 1, Complete = 1, PathLength = 00> ...... 12
4.3.5. Tag = <Automatic = 1, Complete = 1, PathLength = 01> ...... 12
4.3.6. Tag = <Automatic = 1, Complete = 1, PathLength = 10> ...... 13
4.4. Miscellaneous tag settings ................................. 14
5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ... 14
6. Changes from the BGP 3 - OSPF interactions document .......... 15
7. Security Considerations ...................................... 16
8. Acknowledgements ............................................. 16
9. Bibliography ................................................. 16
10. Appendix .................................................... 18
11. Authors' Present Addresses .................................. 191. Introduction 🧚
This doc is all about the rules for designing an Autonomous System Border Router (ASBR) 🦋 The ASBR runs BGP4 [RFC1654] or IDRP for IP [IDRP], talks to other ASBRs outside the AS, and uses OSPF [RFC1583] as its IGP. Think of it as the router that's basically the group chat's go-between 💬
Every time this document says BGP, it means BGP version 4, the one defined in [RFC1654]. When it says IDRP, it means the Inter-Domain Routing Protocol (ISO 10747), which the IDRP for IP document [IDRP] defines for use in Autonomous Systems 🌸
The doc spells out how the following OSPF fields and BGP/IDRP attributes need to be set when an ASBR is connecting BGP/IDRP to OSPF ✨
IDRP came out of the same work as BGP, so you can think of it as a follow-on to BGP-3 and BGP-4 🫶 Most of the fields in the BGP and IDRP interaction are named the same. Where they're different, the IDRP fields get their own mention. Here's the quick comparison:
BGP/IDRP MULTI_EXIT_DISC
BGP ORIGIN and AS_PATH/AS_SET vs. OSPF tag
IDRP EXT_INFO and RD_PATH/RD_SET
BGP/IDRP NEXT_HOP vs. OSPF Forwarding Address
BGP/IDRP LOCAL_PREF vs. OSPF cost and typeIDRP has RD_PATH and RD_SET fields, which do the same job that AS_PATH and AS_SET do for IDRP for IP 💅 In this document, PATH and SET mean either the BGP AS_PATH and AS_SET, or the IDRP RD_PATH and RD_SET fields, depending on which protocol you're working with. Easy peasy 🍓
BGP and IDRP both have a way to show whether routing information came from an IGP or from something else 👑 In IDRP, if the info didn't come from an IGP, the EXT_INFO attribute shows up. In BGP, if the info came from somewhere other than an IGP, the ORIGIN attribute gets set to <EGP> or <INCOMPLETE>. For this document, we need to tell apart two cases:
- (a) Route information was originated via an IGP,
- (b) Route information was originated by some other means.
Case (a) is what happens in IDRP when the EXT_INFO attribute isn't included, and in BGP when the ORIGIN is set to <IGP>. Case (b) is what happens in IDRP when the EXT_INFO attribute is included, and in BGP when the ORIGIN is set to <EGP>. From here on, BGP ORIGIN=<IGP> means the first scenario and BGP ORIGIN=<EGP> means the second 🎀
There's one more difference between IDRP and BGP 🙈 IDRP for IP identifies an autonomous system with a variable-length identifier that looks exactly like an NSAP address prefix, and it explicitly embeds the autonomous system number [IDRP]. BGP just identifies an autonomous system by its autonomous system number. Since there's a one-to-one mapping between the two, this document identifies an autonomous system by its autonomous system number. Simple and clean 🧁
If you want the bigger picture on routing and route exchange problems, go read [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist 📚
This document uses two terms, "Autonomous System" and "Routing Domain", and here's what each one means 💜
"Autonomous System" is the same term the BGP RFC [RFC1267] uses. Here's what that RFC 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 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."
"Routing Domain" was first used in [ROUTE-LEAKING], and the definition goes like this:
"A Routing Domain is a collection of routers which coordinate their routing knowledge using a single [instance of a] routing protocol."
So a Routing Domain always forms a single Autonomous System, but an Autonomous System can be made up of several Routing Domains 🌈
BGP, IDRP, and OSPF all have the idea of a set of reachable destinations, and it's called NLRI, or Network Layer Reachability Information 🦋 That set can be shown either as an IP address prefix or as an address/mask pair. If the mask is contiguous in the second form, the two representations are equivalent. In this document, "address/mask pair" is the term for OSPF, and "destination" or "set of reachable destinations" is the term for BGP or IDRP ✨
This document follows the conventions in the Host Requirements RFCs [RFC1122, RFC1123] for the terms "MUST", "SHOULD," and "MAY" when it describes the various requirements 💖
Here's the super-minimal version 🫶 An implementation of the BGP/IDRP OSPF exchange MUST not advertise a route containing a set of reachable destinations when none of the destinations in the address/mask pair is reachable via OSPF (section 2.1, bullet 3). It MUST merge the PATH into a SET when multiple exit points exist within the same autonomous system for the same external destination (section 3). It MUST set the OSPF tag accurately (section 4). This subset was picked so it causes minimal havoc to the Internet at large 🙈 That said, it is strongly recommended that implementors go beyond this minimal specification 🔥
2. Reachability Information Exchange ✨
okay so this section is all about the rules for swapping the list of reachable destinations between an external BGP/IDRP peer in another AS and our internal OSPF address/mask pairs. it's giving border router drama 🫶
2.1. Exporting OSPF information into BGP 📤
- The administrator MUST be able to selectively export address/mask pairs into BGP/IDRP through an appropriate filter mechanism. 💅
This filter mechanism MUST support that control at the granularity of an address/mask pair.
This filter mechanism will be the main way to aggregate OSPF internal routes and type 1 and type 2 external routes inside the AS when they go into BGP/IDRP. 🧚
The administrator MUST also be able to filter based on the OSPF tag and its various sub-fields. The tag and sub-field settings are explained in section 4 in more detail. 🎀
- The default MUST be to export no routes from OSPF into BGP/IDRP. A single configuration parameter MUST permit all OSPF inter-area and intra-area address/mask pairs to be exported into BGP/IDRP. 🌸
OSPF external address/mask pairs of type 1 and type 2 MUST never be exported into BGP/IDRP unless they are explicitly configured. 🙈
- An address/mask pair with a non-contiguous mask MUST not be exported to BGP/IDRP. 💀
- When an address/mask pair is configured to be exported from OSPF into BGP/IDRP, the ASBR MAY advertise the route containing the set of reachable destinations via BGP/IDRP as soon as at least one destination in that address/mask pair is determined to be reachable via OSPF. It MUST stop advertising that route once none of the destinations in the address/mask pair is reachable via OSPF. 🦋
- The network administrator MUST be able to statically configure the MULTI_EXIT_DISC attribute of BGP/IDRP for any route. 🍓
- The default MUST be to omit MULTI_EXIT_DISC from the route advertised via BGP/IDRP. 🌈
- An implementation of BGP/IDRP and OSPF on an ASBR MUST have a mechanism for setting a minimum amount of time that must pass between learning a new address/mask pair via OSPF and then advertising that pair via BGP/IDRP to external neighbours. ⏳
- The default value for this setting MUST be 0, which means the address/mask pair gets advertised to the neighbouring BGP/IDRP peers instantly. ⚡
Note that BGP and IDRP both mandate a mechanism to dampen inbound advertisements from adjacent neighbours. See the variable MinRouteAdvertisementInterval in section 9.2.3.1, [RFC1654] or in section 7.17.3.1, [IS10747]. 🧐
- LOCAL_PREF is not used when exporting OSPF information into BGP/IDRP, because it doesn't apply there. 🙅♀️
2.2. Importing BGP/IDRP information into OSPF 📥
- BGP/IDRP implementations SHOULD let an AS control the announcements of BGP/IDRP-learned sets of reachable destinations into OSPF. Implementations SHOULD support that control at the granularity of a single destination. 🔐
Implementations SHOULD also support that control at the granularity of an autonomous system. That autonomous system can be either the one that originated the information or the one that advertised it to the local system (the adjacent autonomous system). 👑
- The default MUST be to import nothing from BGP/IDRP into OSPF. Administrators must configure every destination they want to import. 🛑
A configuration parameter MAY let an administrator configure an ASBR to import all of the sets of reachable destinations from BGP/IDRP into the OSPF routing domain. 🌊
- The administrator MUST be able to configure the OSPF cost and the OSPF metric type of every destination imported into OSPF. The OSPF metric type MUST default to type 2. If the LOCAL_PREF value is used to build the OSPF cost, one must be extremely careful with that conversion. In OSPF the lower cost is preferred, while in BGP/IDRP the higher LOCAL_PREF value is preferred. On top of that, the OSPF cost ranges from 1 to 2^24, while the LOCAL_PREF value ranges from 0 to 2^32. 🤯
Note that if the ASBRs within a domain are configured to correlate BGP/IDRP and OSPF information (as described in Section 3), then the route selection by those ASBRs is decided solely by the OSPF cost. The value carried by the LOCAL_PREF attribute has no impact on route selection in that case. 🫠
- Information learned via BGP/IDRP from peers within the same AS MUST not be imported into OSPF. 🚫
- The ASBR MUST never generate a default destination into the OSPF routing domain unless it is explicitly configured to do so. 🙅♀️
A default destination is the set of all possible destinations. By convention it is represented as a prefix of length 0, or as a mask of all zeroes. 🌍
One possible way to generate a default into an IGP is to let the administrator specify a set of (set of reachable destinations, PATH, default cost, default type) tuples. If the ASBR learns of at least one of the destinations in the set of reachable destinations, with the corresponding PATH, then it generates a default destination into the OSPF routing domain with the appropriate cost and type. The lowest-cost route is then injected into the OSPF routing domain. 🧃
This is the recommended method for originating default destinations in the OSPF routing domain. ✅
- Note that [RFC1247] requires the network number to be used as the Link State ID. That causes a conflict if the ASBR tries to import two destinations that differ only in their prefix length. This problem is fixed in [RFC1583], which obsoletes [RFC1247]. 🔧
In this case, an implementation conforming to the older [RFC1247] MUST drop the more specific route, meaning the route corresponding to the longer prefix in the reachability information. 🗑️
- MULTI_EXIT_DISC is not used to import BGP/IDRP information into OSPF, because it doesn't apply there. 🙃
3. BGP/IDRP Identifier and OSPF router ID 🪪
The BGP/IDRP identifier MUST be the same as the OSPF router ID at all times while the router is up. 🫶
Note that [RFC1654] requires the BGP identifier to be an address assigned to the BGP speaker. 📍
For IDRP it's a little different, because the IDRP protocol doesn't explicitly carry the identity of the IDRP speaker. You can get an implicit idea of who the IDRP speaker is by looking at the source address in the IP packets that carry the IDRP information. So all IDRP speakers participating in the OSPF protocol MUST bind the IDRP identifier to the address of the OSPF router ID. 🔗
This setup makes life way easier for the network administrator looking at an ASBR, since they can correlate different BGP/IDRP and OSPF information using the identifier. But there's another, even more important reason for it too. 👀
Picture this: 3 ASBRs, RT1, RT2, and RT3, all 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 that information into the OSPF routing domain. RT3 is advertising this information about destination X to other external BGP/IDRP speakers. The following rule explains how RT3 can generate the correct advertisement. 🎯
RT3 MUST determine which ASBR(s) it's using to reach destination X by matching the OSPF router ID of its route to the destination with either the BGP identifier of the ASBR(s), or the IP source address of the IDRP protocol packet from the ASBR(s). 🕵️♀️
- 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. 💖
- Otherwise, RT3 MAY merge the PATH through RT1 and RT2. 🌙
It MAY then generate the corresponding network layer reachability information for further advertisement to external BGP/IDRP peers. 📣
4. Setting OSPF tags, ORIGIN and 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" [RFC1583]. 📜
We use the external route tag field in OSPF to smartly set the ORIGIN and PATH attributes in BGP/IDRP. These are well-known, mandatory attributes in BGP/IDRP. The exact mechanism for setting the tags is defined in sections 4.2 and 4.3. Every combination of tag bits is described in two parts: 🧩
- import: this describes when an ASBR imports an AS external LSA into the OSPF domain with the given tag setting. 📥
- export: this shows how the BGP/IDRP path attributes should be formatted when an ASBR, holding a given type 1 or type 2 OSPF external route in its routing table, decides to export it according to the considerations in section 2.1. 📤
The tag is split into sub-fields, shown below. The sub-fields describe the characteristics of the set of reachable destinations imported into the OSPF routing domain. 🍰
The high bit of the OSPF tag is known as the "Automatic" bit. Setting this bit means the tag was generated automatically by an ASBR. 🤖
When the network administrator configures the tag, this bit MUST be 0. That's the default tag setting, and it's described in section 4.2. 🙌
When the tag is generated automatically, this bit is set to 1. The 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 the route is either<EGP>or<IGP>. 🌟pl: 2 bits of PathLength information. This field is set based on the length of the PATH that the protocol could have carried when importing the reachability information into the OSPF routing domain. 🛣️ArbitraryTag: 12 bits of tag information. It defaults to 0 but can be configured to anything else. 🎁
The AutonomousSystem (or AS) field is 16 bits, and it holds the AS number for the set of reachable destinations. If the set is meant to count as part of the local AS, the value is 0 ✨
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 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 domain. 💅
- Configuration of an ASBR running OSPF MUST include the capability to associate an AS number with each instance of a routing domain. 👑
Okay so associating an AS number with an instance of an IGP is basically the same thing as flagging that set of reachable destinations (imported from the IGP) as external destinations outside the local autonomous system. It's giving "not from around here" 🦋
4.2. 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 for when the administrator manually sets the OSPF tag bits, so it's very much a hands-on vibe 🫶
- import: this tag setting corresponds to the administrator manually setting the OSPF tag bits. ✨
- export: the route SHOULD be exported into BGP with the attributes
ORIGIN=<EGP>,PATH=<local_AS>. 🌈
Nothing MUST inferred about the characteristics of the set of reachable destinations 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 destinations into the OSPF routing domain. There MUST be a mechanism to enable automatic tag generation for imported destinations. It's giving legacy-friendly but still flexible 💜
4.3. Automatically generated tags 🦋
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 routing protocols with incomplete path information, and they cannot or may not carry the neighbour AS or AS path (and hence the IDRP RD_PATH) as part of the routing information. 🥺
This setting SHOULD be used to import reachable destinations from an IGP that the network administrator has configured as external routes, without specifying the next_hop_AS. 💅
- export: the route SHOULD be exported into BGP/IDRP with the attributes
ORIGIN=<EGP>,PATH=<Local_AS>. 🍓
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 routing protocols with incomplete path information. The neighbour AS (and therefore IDRP RD) is carried in the routing information. 📮
This setting SHOULD be used for importing reachable destinations from EGP into the OSPF routing domain. It MAY also be used when importing reachable destinations from BGP/IDRP whose ORIGIN=<EGP> and PATH=<next_hop_AS>. If the BGP/IDRP learned route has no other transitive attributes, then its propagation via BGP/IDRP to ASBRs internal to the autonomous system MAY be suppressed. 🌷
- export: the route SHOULD be exported into BGP/IDRP with
ORIGIN=<EGP>andPATH=<local_AS, next_hop_AS>. 💫
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 routing protocols with truncated path information. 🫣
They're imported by a border router that runs BGP/IDRP to a stub domain, and doesn't run BGP/IDRP to other ASBRs in the same autonomous system. That causes a truncation of the PATH. These destinations MUST not 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 routing protocols with either complete path information, or ones known to be complete through means other than what the routing protocol carries. ✅
This setting SHOULD be used for importing reachable destinations into OSPF from an IGP. 🔥
- export: the route SHOULD be exported to BGP/IDRP with
ORIGIN=<IGP>,PATH=<Local_AS>. 🌸
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- import: these are reachable destinations imported from routing protocols with either complete path information, or ones known to be complete through means other than what the routing protocol carries. The routing protocol also has extra info about the next hop AS or RD the destination was learned from. 🧠
This setting SHOULD be used when the administrator explicitly associates an AS number with an instance of an IGP. It MAY also be used when importing reachable destinations from BGP/IDRP whose ORIGIN=<IGP> and PATH=<next_hop_AS>. If the BGP/IDRP learned route has no other transitive attributes, then its propagation via BGP/IDRP to other ASBRs internal to the autonomous system MAY be suppressed. 🌟
- export: OSPF routes with this tag setting SHOULD be exported with the BGP/IDRP attributes,
ORIGIN=<IGP>,PATH=<local_AS, next_hop_AS>. 🦋
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 routing protocols with complete path information, and they carry the AS path information as part of the routing information. 🛤️
These destinations MUST not be exported into BGP/IDRP, because they're already imported from BGP/IDRP into the OSPF RD. So it's assumed that the BGP/IDRP speaker will convey these routes to other BGP/IDRP speakers within the same autonomous system via BGP/IDRP. An ASBR that learns about such a destination MUST wait for the BGP update from its internal neighbours before advertising it to external BGP/IDRP peers. ⏳
- export: these routes MUST not be exported into BGP/IDRP. 🚫💖
4.4. 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 PathLength=11 is reserved during automatic tag generation. Routers MUST NOT generate such a tag when importing reachable destinations into the OSPF routing domain. ASBRs must ignore tags which indicate a PathLength=11. 🙅♀️🫶
5. Setting OSPF Forwarding Address and BGP/IDRP NEXT_HOP attribute 🎀
okay so forwarding addresses exist to stop packets from taking extra hops between routers that sit on the same shared network and speak different routing protocols to each other 🧚 it's giving efficiency, bestie 💅
both BGP/IDRP and OSPF have their own version of this. in BGP and IDRP, the NEXT_HOP attribute is a well-known, mandatory attribute 👑 and OSPF has a Forwarding address field 🦋 we're gonna walk through how each one should get filled in for different situations ✨
picture this 4-router setup 💖
RT1 and RT2 live in one autonomous system, and RT3 and RT4 live in another. RT1 and RT3 are chatting over BGP/IDRP, and RT3 and RT4 are chatting over OSPF 🌸
+-----+ +-----+
| RT1 | | RT2 |
+-----+ +-----+
| | common network
---+-----------------------+--------------------------
<BGP/IDRP> | |
+-----+ <OSPF> +-----+
| RT3 | | RT4 |
+-----+ +-----+- Importing a reachable destination into OSPF 🔥 okay so when RT3 brings a destination in from BGP/IDRP into OSPF, RT3 MUST always fill the OSPF Forwarding Address with the BGP/IDRP NEXT_HOP attribute for that destination. no exceptions, periodt 💀
- Exporting a reachable destination into BGP 🌈 now for the other direction. when RT3 exports a set of reachable destinations that live inside the OSPF routing domain over to BGP/IDRP, and every single one of them is reached through RT4, then RT3 MAY fill the NEXT_HOP attribute for that set with RT4's address 🫶 the whole point is to stop packets from having to take an extra hop through RT3 when they cross the AS boundary ✨ this is kinda like the indirect neighbour support idea in EGP [RFC888, RFC827] 🍓
6. Changes from the BGP 3 - OSPF interactions document 🦋
okay this section is the glow-up list 💅 here's everything that changed 💖
- ⭐ the word "route" got way more complicated in BGP 4, so this document sticks to a specific rule:
- "set of reachable destinations" is called an NLRI in [RFC1654] 🌸
- in the BGP context, "route" means a set of reachable destinations plus the attributes attached to that set 🎀
- in the OSPF context, "route" means the set of reachable destinations plus the cost and the type used to reach them 🧚 this keeps the definitions consistent across the whole doc, which is so iconic 🙈
- ✨ exchanging reachability info between BGP 4 and OSPF got updated to handle variable length net mask information 🌈
- 🍓 the old term INTER_AS_METRIC from BGP 3 is now MULTI_EXIT_DISC 💅
- 💜 the default metric for importing BGP info into the OSPF RD used to be a constant value, but now it's the LOCAL_PREF attribute 👑
- 😭 Section 3 says an ASBR has to match the OSPF tag for a route to the BGP Identifier, and that can cause loops if the AS has equal cost multipath routing among the ASBRs 💀 the scenario is laid out in the Appendix below 🔥 BGP4 fixes this by requiring an ASBR that sees equal cost multi-path routes to merge the PATHs through the various ASBRs into appropriate SETs 🫶
- BGP 4 requires that the BGP identifier be an address assigned to the BGP speaker 🦋 section 3 covers this one too 🌸
- Section 5 on setting NEXT_HOP attributes and the Forwarding Address field got updated to account for variable length net information 🎀
- and this section, 6, was added ✨ bestie we did it 🥳
7. Security Considerations 🔒
Security issues are not discussed in this memo 🙈 so yeah, nothing to see here from this doc itself 💅
8. Acknowledgements 🫶
big thank you to Jeff Honig (Cornell University), John Moy (Cascade Communications Corp.), Tony Li (cisco Systems), Rob Coltun (Consultant), Dennis Ferguson (ANS, Inc.), Phil Almquist (Consultant), Scott Bradner (Harvard University), and Joel Halpern (Newbridge Networks Inc.) for their help and suggestions while writing this doc 💖 Cengiz Aleattinoglu (USC/ISI) and Steve Hotz (USC/ISI) gave fresh insights into the packet looping problem described in the appendix 🧚
we also owe a huge thanks to the countless people from the OSPF and BGP working groups who dropped suggestions and comments on every stage of this doc 🌈
and thanks to Bob Braden (ISI) too 🎀 his suggestions on the earlier BGP-OSPF document, [RFC1403], were useful even for this one and got carried through ✨
finally, we'd like to thank OARnet, where one of the authors did most of his work on this document before moving to USC to resurrect his PhD 👑😭
9. 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", RFC 1058,
Rutgers University, June 1988.
[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.
[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 Gateway
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 between
Systems - Protocol for Exchange of Inter-domain Routeing
Information among Intermediate Systems to Support
Forwarding of ISO 8473 PDUs, 1993.10. Appendix 🧩
okay this appendix is a whole mystery story 🕵️♀️ it shows how BGP/IDRP and OSPF can both be behaving consistently, and yet packets from a source domain S headed to a destination in domain X can still get stuck in a forwarding loop 😭
+--------+
X ----------| C1 |
| |Domain C|
| | C3 C2 |
| +--------+
B / \
\ / \
\ / S
\ / /
\ / /
+--------+ /
| A1 A2 | /
|Domain A| /
| A3 |-/
+--------+so picture domains X, A, B, C and S 🗺️ domains A and C are both running OSPF, and ASBRs A3 and C3 have equal cost multipath routes to A1, A2 and C1, C2 respectively 💅 the diagram above only shows the inside of domains A and C 🫶
here's the steady state, the route advertisements going on:
- domain B advertises path <B,X> to A 🌸
- ASBR A3 in domain A advertises path <A,B,X> to domain C, at ASBR C2 🎀
- domain C has two equal cost paths to X: one direct <C,X>, and another through A, <C,A,B,X> ✨
- BR C3 in domain C advertises path <C,X> to A2 🧚
- domain A has two equal cost paths to X: <A,C,X> and <A,B,X> 👑
so C1 and C2 both inject a route to X inside domain C, and A1 and A2 do the same inside domain A 💖 since A3 and C3 see equal cost routes to X through A1, A2 and C1, C2 respectively, you get a stable loop through the ASBRs <A3, A2, C3, C2, A3> 😭🔥
section 4 says that A3 and C3, when they advertise a PATH to destination X, MUST aggregate all the PATHs through A1 and A2, and C1 and C2 respectively 💀 this ends up stopping the BGP/IDRP speaker in either domain A or domain C from choosing multiple routes to destination X and importing only one route into OSPF 🙈 which breaks the multiple paths seen in one domain 💔 the exact domain where the paths get broken is nondeterministic 🌀
11. Authors' Present Addresses 🎀
Kannan Varadhan
USC/Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, CA 90292-6695
Phone: +1 310 822 1511 x 402
EMail: kannan@isi.edu
Susan Hares
Merit, Inc.
1071 Beal Avenue,
Ann Arbor, MI 48109
Phone: +1 313 936 2095
EMail: skh@merit.edu
Yakov Rekhter
T.J. Watson Research Center, IBM Corporation
P.O. Box 704,
Yorktown Heights, NY 10598.
Phone: +1 914 784 7361
EMail: yakov@watson.ibm.com📦 where this page comes from
- ietf: rfc1745 1994-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms