doc: Add RFC documents

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