diff options
Diffstat (limited to 'doc/rfc/rfc1403.txt')
| -rw-r--r-- | doc/rfc/rfc1403.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc1403.txt b/doc/rfc/rfc1403.txt new file mode 100644 index 0000000..ca59215 --- /dev/null +++ b/doc/rfc/rfc1403.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group K. Varadhan +Request for Comments: 1403 OARnet +Obsoletes: 1364 January 1993 + + + BGP OSPF Interaction + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Abstract + + This memo defines the various criteria to be used when designing an + Autonomous System Border Routers (ASBR) that will run BGP with other + ASBRs external to the AS and OSPF as its IGP. This is a + republication of RFC 1364 to correct some editorial problems. + +Table of Contents + + 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 + + + + +Varadhan [Page 1] + +RFC 1403 BGP OSPF Interaction January 1993 + + +1. Introduction + + This document defines the various criteria to be used when designing + an 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 attributes + in BGP are to be set when interfacing between BGP and OSPF 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 + + 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-3 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 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 is + given below: + + "A Routing Domain is a collection of routers which coordinate + their routing knowledge using a single (instance of) a routing + protocol." + + This document follows the conventions embodied in the Host + Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST", + "SHOULD", and "MAY" for the various requirements. + + + + + + + + +Varadhan [Page 2] + +RFC 1403 BGP OSPF Interaction January 1993 + + +2. Route Exchange + + This section discusses the constraints that must be met to exchange + routes between an external BGP session with a peer from another AS + 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, we + consider the equivalent network route in the context of BGP. + Multiple subnet routes for a subnetted network in OSPF are collapsed + into one network route when exported into BGP. + + 2.1. Exporting OSPF routes into BGP + + 1. The administrator MUST be able to selectively export OSPF + routes into BGP via an appropriate filter mechanism. + + This filter mechanism MUST support such control with the + granularity of a single network. + + 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 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 are explicitly configured. + + 2. When configured to export a network, the ASBR MUST advertise + a network route for a subnetted network, as long as at least + one subnet in the subnetted network is reachable via OSPF. + + 3. The network administrator MUST be able to statically + configure the BGP attribute INTER-AS METRIC to be used for + any network route. + + o 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 of different widths. The OSPF cost is a two level + metric. The BGP INTER-AS METRIC is only an optional non- + + + +Varadhan [Page 3] + +RFC 1403 BGP OSPF Interaction January 1993 + + + transitive attribute. Hence, a more complex BGP INTER-AS + METRIC-OSPF cost mapping scheme is not necessary. + + 4. When an ASBR is advertising an OSPF route to network Y to + external BGP neighbours and learns that the route has become + unreachable, the ASBR MUST immediately propagate this + information to the external BGP neighbours. + + 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 route via OSPF and subsequent + advertisement of the route via BGP to the external + neighbours. + + o The default value for this setting MUST be 0, indicating + that the route is to be 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 + + 1. BGP implementations SHOULD allow an AS to control + announcements of BGP-learned routes into OSPF. + Implementations SHOULD support such control with the + granularity of a single network. 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 route or the autonomous + system that advertised the route to the local system + (adjacent autonomous system). + + o The default MUST be to export no routes from BGP into + OSPF. Administrators must configure every route they + wish to import. + + A configuration parameter MAY allow an administrator to + configure an ASBR to import all the BGP routes into the + OSPF routing domain. + + 2. The administrator MUST be able to configure the OSPF cost and + the OSPF metric type of every route imported into OSPF. + + o The OSPF cost MUST default to 1; the OSPF metric type + MUST default to type 2. + + + + + +Varadhan [Page 4] + +RFC 1403 BGP OSPF Interaction January 1993 + + + 3. Routes learned via BGP from peers within the same AS MUST not + be imported into OSPF. + + 4. The ASBR MUST never generate a default route into the OSPF + routing domain unless explicitly configured to do so. + + A possible criterion for generating default into an IGP is to + allow the administrator to 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 corresponding 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 will then be 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. + + This characteristic is required for two reasons. + + i Synchronisation between OSPF and BGP + + Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3, + 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 + + + +Varadhan [Page 5] + +RFC 1403 BGP OSPF Interaction January 1993 + + + must use the OSPF router ID to determine whether it is using + RT1 or RT2 to forward packets to network X and hence build the + correct AS_PATH to advertise to other external speakers. + + More precisely, RT3 must determine which ASBR it is 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, and + use the corresponding route for further advertisement to + external BGP peers. + + ii It will be 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 + + 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 routes that are external to the OSPF routing + domain but must be considered internal to the AS, as opposed to + routes that are external to the AS. + + Routes 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 from other BGP speakers within the same autonomous system + via BGP. Therefore, ASBRs running BGP must have knowledge of this + class of routes so that they can advertise these routes to the + various external AS without waiting for BGP updates from other BGP + speakers within the same autonomous system about these routes. + + Additionally, in the specific instance of an AS intermixing routers + running EGP and BGP as exterior gateway routing protocols and using + OSPF as an IGP, then within the autonomous system, it may not be + necessary to run BGP with 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- + + + +Varadhan [Page 6] + +RFC 1403 BGP OSPF Interaction January 1993 + + + fields specify the characteristics of the route 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: + + 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 + 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 + route, 0 if the route is to be considered as part of the local + AS. + + local_AS + The term `local_AS' refers to the AS number of the local + OSPF routing domain. + + next_hop_AS + `next_hop_AS' refers to the AS number of an external BGP + peer. + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Varadhan [Page 7] + +RFC 1403 BGP OSPF Interaction January 1993 + + + 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 various values of the characteristics + bits is defined below. + + 4.1. Semantics of the characteristics bits + + The Completeness and PathLength characteristics bits define the + characteristic 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 re-exporting these routes to + an external BGP speaker. + + o 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 route from the tag + bits, unless the tag has been automatically generated. + + o The Completeness characteristic bit is set when the source of + the incoming route 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 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 will indicate whether the AS_PATH + attribute for the 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 is not wide enough to carry path information + about routes that have an associated PathLength greater than + one. Path information about these routes will have to be + + + +Varadhan [Page 8] + +RFC 1403 BGP OSPF Interaction January 1993 + + + carried via BGP to other ASBRs within the same AS. Such + routes must not be exported from OSPF into BGP. + + + 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 routes imported from the + IGP to be 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Varadhan [Page 9] + +RFC 1403 BGP OSPF Interaction January 1993 + + + 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 MUST be inferred about the characteristics + of the route 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 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 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 routes MUST be + + Automatic=1, Completeness=0, PathLength=00, AS=0 => + ORIGIN=<EGP>, AS_PATH=<local_AS> + + + + + + + + + + +Varadhan [Page 10] + +RFC 1403 BGP OSPF Interaction January 1993 + + + 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, which is running BGP to + a stub domain, and not running BGP to other ASBRs in the same + AS. This causes a truncation of the AS_PATH. These routes + MUST not be re-exported into BGP at another ASBR. + + + + + + + + +Varadhan [Page 11] + +RFC 1403 BGP OSPF Interaction January 1993 + + + 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 are known to be complete through + means other than that carried by the routing protocol. + + 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> + + This 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + These are routes 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 route. + + The OSPF tag to BGP attribute mappings for these routes MUST be + + Automatic=1, Completeness=1, PathLength=01, AS=next_hop_AS + => ORIGIN=<IGP>, AS_PATH=<local_AS, next_hop_AS> + + This setting SHOULD be used when the administrator explicitly + associates an AS number with an instance of an IGP. This + setting 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. + + + + + + + +Varadhan [Page 12] + +RFC 1403 BGP OSPF Interaction January 1993 + + + 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 information and carry the AS path information as part of + the routing information. + + 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 these routes + 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 within the same AS via BGP. An ASBR + learning of such a route MUST wait for the BGP update from its + internal neighbours before advertising this route to external + BGP peers. + + 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 these routes via BGP to ASBRs within the same + AS. In this 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 of PathLength=11 is reserved during automatic tag + generation. Routers MUST not generate such a tag when importing + routes into the OSPF routing domain. ASBRs MUST ignore tags which + indicate a PathLength=11. + + + + + + + + + +Varadhan [Page 13] + +RFC 1403 BGP OSPF Interaction January 1993 + + + 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 + +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" 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 by running BGP to other + ASBRs within the same AS. + +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 + has a Forwarding address field. We will discuss how these are to be + filled in various situations. + + + + + + + + + + + + +Varadhan [Page 14] + +RFC 1403 BGP OSPF Interaction January 1993 + + + + 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 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 is 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 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 issues are not discussed in this memo. + +7. Acknowledgements + + I would like to thank Yakov Rekhter, Jeff Honig, John Moy, Tony Li, + Dennis Ferguson, and Phil Almquist 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. + + + +Varadhan [Page 15] + +RFC 1403 BGP OSPF Interaction January 1993 + + + I would also like to thank the countless number of people from the + OSPF and BGP working groups who have offered numerous suggestions and + comments on the different stages of this document. + + Thanks also to Bob Braden, who went through the document thoroughly, + and came back with questions and comments, which were very useful. + These suggestions have also been carried over into the next version + of this document for dealing 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. + + + + +Varadhan [Page 16] + +RFC 1403 BGP OSPF Interaction January 1993 + + +9. Author's Address: + + Kannan Varadhan + Internet Engineer, OARnet, + 1224, Kinnear Road, + Columbus, OH 43212-1136. + + Phone: (614) 292-4137 + + Email: kannan@oar.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Varadhan [Page 17] +
\ No newline at end of file |