home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1745 < prev    next >
Text File  |  1994-12-29  |  44KB  |  1,068 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       K.  Varadhan
  8. Request for Comments: 1745                                  OARnet & ISI
  9. Category: Standards Track                                       S. Hares
  10.                                                             NSFnet/Merit
  11.                                                               Y. Rekhter
  12.                                   T.J. Watson Research Center, IBM Corp.
  13.                                                            December 1994
  14.  
  15.  
  16.                   BGP4/IDRP for IP---OSPF Interaction
  17.  
  18. Status of this Memo
  19.  
  20.    This document specifies an Internet standards track protocol for the
  21.    Internet community, and requests discussion and suggestions for
  22.    improvements.  Please refer to the current edition of the "Internet
  23.    Official Protocol Standards" (STD 1) for the standardization state
  24.    and status of this protocol.  Distribution of this memo is unlimited.
  25.  
  26. Abstract
  27.  
  28.    This memo defines the various criteria to be used when designing an
  29.    Autonomous System Border Router (ASBR) that will run either BGP4 or
  30.    IDRP for IP with other ASBRs external to the AS and OSPF as its IGP.
  31.  
  32. Table of Contents
  33.  
  34.    1.  Introduction .................................................  2
  35.    2.  Reachability Information Exchange ............................  4
  36.    2.1.  Exporting OSPF information into BGP/IDRP  ..................  4
  37.    2.2.  Importing BGP/IDRP information into OSPF ...................  6
  38.    3.  BGP/IDRP Identifier and OSPF router ID .......................  7
  39.    4.  Setting OSPF tags, ORIGIN and PATH attributes ................  8
  40.    4.1.  Configuration parameters for setting the OSPF tag .......... 10
  41.    4.2.  Manually configured tags ................................... 10
  42.    4.3.  Automatically generated tags ............................... 11
  43.    4.3.1. Tag = <Automatic = 1, Complete = 0, PathLength = 00> ...... 11
  44.    4.3.2. Tag = <Automatic = 1, Complete = 0, PathLength = 01> ...... 11
  45.    4.3.3. Tag = <Automatic = 1, Complete = 0, PathLength = 10> ...... 12
  46.    4.3.4. Tag = <Automatic = 1, Complete = 1, PathLength = 00> ...... 12
  47.    4.3.5. Tag = <Automatic = 1, Complete = 1, PathLength = 01> ...... 12
  48.    4.3.6. Tag = <Automatic = 1, Complete = 1, PathLength = 10> ...... 13
  49.    4.4.  Miscellaneous tag settings ................................. 14
  50.    5.  Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ... 14
  51.    6.  Changes from the BGP 3 - OSPF interactions document .......... 15
  52.    7.  Security Considerations ...................................... 16
  53.    8.  Acknowledgements ............................................. 16
  54.    9.  Bibliography ................................................. 16
  55.  
  56.  
  57.  
  58. Varadhan, Hares & Rekhter                                       [Page 1]
  59.  
  60. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  61.  
  62.  
  63.    10.  Appendix .................................................... 18
  64.    11.  Authors' Present Addresses .................................. 19
  65.  
  66. 1.  Introduction
  67.  
  68.    This document defines the various criteria to be used when designing
  69.    an Autonomous System Border Router (ASBR) that will run BGP4
  70.    [RFC1654] or IDRP for IP [IDRP] with other ASBRs external to the AS,
  71.    and OSPF [RFC1583] as its IGP.
  72.  
  73.    All future references of BGP in this document will refer to BGP
  74.    version 4, as defined in [RFC1654].  All reference to IDRP are
  75.    references to the Inter-Domain Routing Protocol (ISO 10747) which has
  76.    been defined by the IDRP for IP document [IDRP] for use in Autonomous
  77.    Systems.
  78.  
  79.    This document defines how the following fields in OSPF and attributes
  80.    in BGP/IDRP are to be set when interfacing between BGP/IDRP and OSPF
  81.    at an ASBR:
  82.  
  83.    IDRP came out of the same work as BGP, and may be consider a follow
  84.    on to BGP-3 and BGP-4.  Most fields defined in the interaction
  85.    between BGP and IDRP are named the same.  Where different, the IDRP
  86.    fields are shown separately.
  87.  
  88.            BGP/IDRP MULTI_EXIT_DISC
  89.  
  90.            BGP ORIGIN and AS_PATH/AS_SET     vs. OSPF tag
  91.            IDRP EXT_INFO and RD_PATH/RD_SET
  92.  
  93.            BGP/IDRP NEXT_HOP                 vs. OSPF Forwarding Address
  94.  
  95.            BGP/IDRP LOCAL_PREF               vs. OSPF cost and type
  96.  
  97.    IDRP contains RD_PATH and RD_SET fields which serves the same purpose
  98.    as AS_PATH and AS_SET fields for IDRP for IP.  In this document, we
  99.    will use the terms PATH and SET to refer to the BGP AS_PATH and
  100.    AS_SET, or the IDRP RD_PATH and RD_SET fields respectively, depending
  101.    on the context of the protocol being used.
  102.  
  103.    Both IDRP and BGP provide a mechanism to indicate whether the routing
  104.    information was originated via an IGP, or some other means.  In IDRP,
  105.    if route information is originated by means other than an IGP, then
  106.    the EXT_INFO attribute is present.  Likewise, in BGP, if a route
  107.    information is originated by means other than an IGP, then the ORIGIN
  108.    attribute is set to <EGP> or <INCOMPLETE>.  For the purpose of this
  109.    document, we need to distinguish between the two cases:
  110.  
  111.  
  112.  
  113.  
  114. Varadhan, Hares & Rekhter                                       [Page 2]
  115.  
  116. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  117.  
  118.  
  119.         (a)  Route information was originated via an IGP,
  120.  
  121.         (b)  Route information was originated by some other means.
  122.  
  123.    The former case is realized in IDRP by not including the EXT_INFO
  124.    attribute, and in BGP by setting the BGP ORIGIN=<IGP>;  The latter
  125.    case is realized by including the EXT_INFO attribute in IDRP, and by
  126.    setting the BGP ORIGIN=<EGP>.  For the rest of the document, we will
  127.    use the BGP ORIGIN=<IGP> to refer to the former scenario, and BGP
  128.    ORIGIN=<EGP> to refer to the latter.
  129.  
  130.    One other difference between IDRP and BGP remains.  IDRP for IP
  131.    identifies an autonomous system by an identifier of variable length
  132.    that is syntactically identical to an NSAP address prefix, and
  133.    explicitly embeds the autonomous system number [IDRP].  BGP
  134.    identifies an autonomous system just by an autonomous system number.
  135.    Since there is a one-to-one mapping between how an autonomous system
  136.    is identified in IDRP and in BGP, in this document, we shall identify
  137.    an autonomous system by its autonomous system number.
  138.  
  139.    For a more general treatise on routing and route exchange problems,
  140.    please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist.
  141.  
  142.    This document uses the two terms "Autonomous System" and "Routing
  143.    Domain".  The definitions for the two are below:
  144.  
  145.    The term Autonomous System is the same as is used in the BGP RFC
  146.    [RFC1267], given below:
  147.  
  148.       "The use of the term Autonomous System here stresses the fact
  149.       that, even when multiple IGPs and metrics are used, the
  150.       administration of an AS appears to other ASs to have a single
  151.       coherent interior routing plan and presents a consistent picture
  152.       of what destinations are reachable through it.  From the
  153.       standpoint of exterior routing, an AS can be viewed as monolithic:
  154.       reachability to destinations directly connected to the AS must be
  155.       equivalent from all border gateways of the AS."
  156.  
  157.    The term Routing Domain was first used in [ROUTE-LEAKING] and is
  158.    given below:
  159.  
  160.       "A Routing Domain is a collection of routers which coordinate
  161.       their routing knowledge using a single [instance of a] routing
  162.       protocol."
  163.  
  164.    By definition, a Routing Domain forms a single Autonomous System, but
  165.    an Autonomous System may be composed of a collection of Routing
  166.    Domains.
  167.  
  168.  
  169.  
  170. Varadhan, Hares & Rekhter                                       [Page 3]
  171.  
  172. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  173.  
  174.  
  175.    BGP, IDRP and OSPF have the concept of a set of reachable
  176.    destinations.  This set is called NLRI or Network Layer Reachability
  177.    Information.  The set can be represented either as an IP address
  178.    prefix, or an address, mask pair.  Note that if the mask is
  179.    contiguous in the latter, then the two representations are
  180.    equivalent.  In this document, we use the term "address/mask pair" in
  181.    the context of OSPF, and "destination" or "set of reachable
  182.    destinations" in the context of BGP or IDRP.
  183.  
  184.    This document follows the conventions embodied in the Host
  185.    Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST",
  186.    "SHOULD," and "MAY" for the various requirements.
  187.  
  188.    A minimal implementation of BGP/IDRP OSPF exchange MUST not advertise
  189.    a route containing a set of reachable destinations when none of the
  190.    destinations in the address/mask pair is reachable via OSPF (section
  191.    2.1, bullet 3), MUST merge the PATH into a SET when multiple exit
  192.    points exist within the same autonomous system for the same external
  193.    destination (section 3), MUST set the OSPF tag accurately (section
  194.    4).  This subset is chosen so as to cause minimal havoc to the
  195.    Internet at large.  It is strongly recommended that implementors
  196.    implement more than a minimalistic specification.
  197.  
  198. 2.  Reachability Information Exchange
  199.  
  200.    This section discusses the constraints that must be met to exchange
  201.    the set of reachable destinations between an external BGP/IDRP peer
  202.    from another AS and internal OSPF address/mask pairs.
  203.  
  204.    2.1.  Exporting OSPF information into BGP
  205.  
  206.       1.   The administrator MUST be able to selectively export
  207.            address/mask pairs into BGP/IDRP via an appropriate filter
  208.            mechanism.
  209.  
  210.            This filter mechanism MUST support such control with the
  211.            granularity of an address/mask pair.
  212.  
  213.            This filter mechanism will be the primary method of
  214.            aggregation of OSPF internal and type 1 and type 2 external
  215.            routes within the AS into BGP/IDRP.
  216.  
  217.            Additionally, the administrator MUST be able to filter based
  218.            on the OSPF tag and the various sub-fields of the OSPF tag.
  219.            The settings of the tag and the sub-fields are defined in
  220.            section 4 in more detail.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Varadhan, Hares & Rekhter                                       [Page 4]
  227.  
  228. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  229.  
  230.  
  231.            o    The default MUST be to export no routes from OSPF into
  232.                 BGP/IDRP.  A single configuration parameter MUST permit
  233.                 all OSPF inter-area and intra-area address/mask pairs to
  234.                 be exported into BGP/IDRP.
  235.  
  236.                 OSPF external address/mask pairs of type 1 and type 2
  237.                 MUST never be exported into BGP/IDRP unless they are
  238.                 explicitly configured.
  239.  
  240.       2.   An address/mask pair having a non-contiguous mask MUST not be
  241.            exported to BGP/IDRP.
  242.  
  243.       3.   When configured to export an address/mask pair from OSPF into
  244.            BGP/IDRP, the ASBR MAY advertise the route containing the set
  245.            of reachable destinations via BGP/IDRP as soon as at least
  246.            one of the destinations in the address/mask pair is
  247.            determined to be reachable via OSPF; it MUST stop advertising
  248.            the route containing the set of reachable destinations when
  249.            none of the destinations in the address/mask pair is
  250.            reachable via OSPF.
  251.  
  252.       4.   The network administrator MUST be able to statically
  253.            configure the BGP/IDRP attribute MULTI_EXIT_DISC attribute to
  254.            be used for any route.
  255.  
  256.            o    The default MUST be to omit the MULTI_EXIT_DISC in the
  257.                 route advertised via BGP/IDRP.
  258.  
  259.       5.   An implementation of BGP/IDRP and OSPF on an ASBR MUST have a
  260.            mechanism to set up a minimum amount of time that must elapse
  261.            between the learning of a new address/mask pair via OSPF and
  262.            subsequent advertisement of the address/mask pair via
  263.            BGP/IDRP to the external neighbours.
  264.  
  265.            o    The default value for this setting MUST be 0, indicating
  266.                 that the address/mask pair is to be advertised to the
  267.                 neighbour BGP/IDRP peers instantly.
  268.  
  269.                 Note that BGP and IDRP mandate a mechanism to dampen the
  270.                 inbound advertisements from adjacent neighbours.  See
  271.                 the variable MinRouteAdvertisementInterval in section
  272.                 9.2.3.1, [RFC1654] or in section 7.17.3.1, [IS10747].
  273.  
  274.       6.   LOCAL_PREF is not used when exporting OSPF information into
  275.            BGP/IDRP, as it is not applicable.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Varadhan, Hares & Rekhter                                       [Page 5]
  283.  
  284. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  285.  
  286.  
  287.    2.2.  Importing BGP/IDRP information into OSPF
  288.  
  289.       1.   BGP/IDRP implementations SHOULD allow an AS to control
  290.            announcements of BGP/IDRP learned set of reachable
  291.            destinations into OSPF.  Implementations SHOULD support such
  292.            control with the granularity of a single destination.
  293.  
  294.            Implementations SHOULD also support such control with the
  295.            granularity of an autonomous system, where the autonomous
  296.            system may be either the autonomous system that originated
  297.            the information or the autonomous system that advertised the
  298.            information to the local system (adjacent autonomous system).
  299.  
  300.            o    The default MUST be to import nothing from BGP/IDRP into
  301.                 OSPF.  Administrators must configure every destination
  302.                 they wish to import.
  303.  
  304.                 A configuration parameter MAY allow an administrator to
  305.                 configure an ASBR to import all the set of reachable
  306.                 destinations from BGP/IDRP into the OSPF routing domain.
  307.  
  308.       2.   The administrator MUST be able to configure the OSPF cost and
  309.            the OSPF metric type of every destination imported into OSPF.
  310.            The OSPF metric type MUST default to type 2. If the
  311.            LOCAL_PREF value is used to construct the OSPF cost, one must
  312.            be extremely careful with such a conversion. In OSPF the
  313.            lower cost is preferred, while in BGP/IDRP the higher value
  314.            of the LOCAL_PREF is preferred.  In addition, the OSPF cost
  315.            ranges between 1 and 2^24, while the LOCAL_PREF value ranges
  316.            between 0 and 2^32.  Note that if ASBRs within a domain are
  317.            configured to correlate BGP/IDRP and OSPF information (as
  318.            described in Section 3), then the route selection by the
  319.            ASBRs is determined solely by the OSPF cost, and the value
  320.            carried by the LOCAL_PREF attribute has no impact on the
  321.            route selection.
  322.  
  323.       3.   Information learned via BGP/IDRP from peers within the same
  324.            AS MUST not be imported into OSPF.
  325.  
  326.       4.   The ASBR MUST never generate a default destination into the
  327.            OSPF routing domain unless explicitly configured to do so.
  328.  
  329.            A default destination is a set of all possible destinations.
  330.            By convention, it is represented as a prefix of 0 length or a
  331.            mask of all zeroes.
  332.  
  333.            A possible criterion for generating default into an IGP is to
  334.            allow the administrator to specify a set of (set of reachable
  335.  
  336.  
  337.  
  338. Varadhan, Hares & Rekhter                                       [Page 6]
  339.  
  340. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  341.  
  342.  
  343.            destinations, PATH, default cost, default type) tuples.  If
  344.            the ASBR learns of at least one of the destinations in the
  345.            set of reachable destinations, with the corresponding PATH,
  346.            then it generates a default destination into the OSPF routing
  347.            domain, with the appropriate cost and type.  The lowest cost
  348.            route will then be injected into the OSPF routing domain.
  349.  
  350.            This is the recommended method for originating default
  351.            destinations in the OSPF routing domain.
  352.  
  353.       5.   Note that [RFC1247] requires the network number to be used as
  354.            the Link State ID.  This will produce a conflict if the ASBR
  355.            tries to import two destinations, differing only in their
  356.            prefix length.  This problem is fixed in [RFC1583], which
  357.            obsoletes [RFC1247].
  358.  
  359.            An implementation conforming to the older [RFC1247] MUST, in
  360.            this case, drop the more specific route, i.e. the route
  361.            corresponding to the longer prefix in the reachability
  362.            information.
  363.  
  364.       6.   MULTI_EXIT_DISC is not used to import BGP/IDRP information
  365.            into OSPF, as it is not applicable.
  366.  
  367. 3.  BGP/IDRP Identifier and OSPF router ID
  368.  
  369.    The BGP/IDRP identifier MUST be the same as the OSPF router id at all
  370.    times that the router is up.
  371.  
  372.    Note that [RFC1654] requires that the BGP identifier be an address
  373.    assigned to the BGP speaker.
  374.  
  375.    In the case of IDRP, the IDRP protocol does not explicitly carry the
  376.    identity of the IDRP speaker.  An implicit notion of the identity of
  377.    the IDRP speaker can be obtained by examining the source address in
  378.    the IP packets carrying the IDRP information.  Therefore, all IDRP
  379.    speakers participating in the OSPF protocol MUST bind the IDRP
  380.    identifier to be the address of the OSPF router id.
  381.  
  382.    This characteristic makes it convenient for the network administrator
  383.    looking at an ASBR to correlate different BGP/IDRP and OSPF
  384.    information based on the identifier.  There is another more important
  385.    reason for this characteristic.
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Varadhan, Hares & Rekhter                                       [Page 7]
  395.  
  396. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  397.  
  398.  
  399.    Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3, belong to
  400.    the same autonomous system.
  401.  
  402.                                      +-----+
  403.                                      | RT3 |
  404.                                      +-----+
  405.                                         |
  406.  
  407.                           Autonomous System running OSPF
  408.  
  409.                                  /               \
  410.  
  411.                              +-----+          +-----+
  412.                              | RT1 |          | RT2 |
  413.                              +-----+          +-----+
  414.  
  415.    Both RT1 and RT2 can reach an external destination X and import this
  416.    information into the OSPF routing domain.  RT3 is advertising this
  417.    information about destination X to other external BGP/IDRP speakers.
  418.    The following rule specifies how RT3 can generate the correct
  419.    advertisement.
  420.  
  421.    RT3 MUST determine which ASBR(s) it is using to reach destination X
  422.    by matching the OSPF router ID for its route to destination with the
  423.    BGP identifier of the ASBR(s), or the IP source address of the IDRP
  424.    protocol packet from the ASBR(s).
  425.  
  426.      o    If RT3 has equal cost routes to X through RT1 and RT2, then,
  427.           RT3 MUST merge the PATH through RT1 and RT2 into a SET.
  428.  
  429.      o    Otherwise, RT3 MAY merge the PATH through RT1 and RT2.
  430.  
  431.      It MAY then generate the corresponding network layer reachability
  432.      information for further advertisement to external BGP/IDRP peers.
  433.  
  434. 4.  Setting OSPF tags, ORIGIN and PATH attributes
  435.  
  436.    The OSPF external route tag is a "32-bit field attached to each
  437.    external route . . . It may be used to communicate information
  438.    between AS boundary routers; the precise nature of such information
  439.    is outside the scope of [the] specification" [RFC1583].
  440.  
  441.    We use the external route tag field in OSPF to intelligently set the
  442.    ORIGIN and PATH attributes in BGP/IDRP.  These attributes are well-
  443.    known, mandatory attributes in BGP/IDRP.  The exact mechanism for
  444.    setting the tags is defined in sections 4.2 and 4.3.  Every
  445.    combination of tag bits is described in two parts:
  446.  
  447.  
  448.  
  449.  
  450. Varadhan, Hares & Rekhter                                       [Page 8]
  451.  
  452. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  453.  
  454.  
  455.      import  This describes when an ASBR imports an AS external LSA into
  456.              the OSPF domain with the given tag setting.
  457.  
  458.      export  This indicates how the BGP/IDRP path attribues should be
  459.              formatted when an ASBR, having a given type 1 or type 2
  460.              OSPF external route in its routing table, decides to export
  461.              according to the considerations in section 2.1.
  462.  
  463.      The tag is broken up into sub-fields shown below.  The various
  464.      sub-fields specify the characteristics of the set of reachable
  465.      destinations imported into the OSPF routing domain.
  466.  
  467.      The high bit of the OSPF tag is known as the "Automatic" bit.
  468.      Setting this bit indicates that the tag has been generated
  469.      automatically by an ASBR.
  470.  
  471.      When the network administrator configures the tag, this bit MUST be
  472.      0.  This setting is the default tag setting, and is described in
  473.      section 4.2.
  474.  
  475.      When the tag is automatically generated, this bit is set to 1.  The
  476.      other bits are defined below:
  477.  
  478.       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
  479.       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
  480.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  481.      |1|c|p l|     ArbitraryTag      |       AutonomousSystem        |
  482.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  483.  
  484.      c    1 bit of Completeness information, set when the ORIGIN of the
  485.           route is either <EGP> or <IGP>.
  486.  
  487.      pl   2 bits of PathLength information;  this field is set depending
  488.           on the length of the PATH that the protocol could have carried
  489.           when importing the reachability information into the OSPF
  490.           routing domain.
  491.  
  492.      ArbitraryTag
  493.           12 bits of tag information, defaults to 0 but can be
  494.           configured to anything else.
  495.  
  496.      AutonomousSystem (or "AS")
  497.           16 bits, indicating the AS number corresponding to the set of
  498.           reachable destinations, 0 if the set of reachable destinations
  499.           is to be considered as part of the local AS.
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Varadhan, Hares & Rekhter                                       [Page 9]
  507.  
  508. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  509.  
  510.  
  511.           local_AS:     The AS number of the local OSPF routing domain.
  512.  
  513.           next_hop_AS:  The AS number of an external BGP peer.
  514.  
  515.    4.1.  Configuration parameters for setting the OSPF tag
  516.  
  517.       o    There MUST be a mechanism to enable automatic generation of
  518.            the tag characteristic bits.
  519.  
  520.       o    Configuration of an ASBR running OSPF MUST include the
  521.            capability to associate a tag value, for the ArbitraryTag, or
  522.            LocalInfo sub-field of the OSPF tag, with each instance of a
  523.            routing domain.
  524.  
  525.       o    Configuration of an ASBR running OSPF MUST include the
  526.            capability to associate an AS number with each instance of a
  527.            routing domain.
  528.  
  529.            Associating an AS number with an instance of an IGP is
  530.            equivalent to flagging those set of reachable destinations
  531.            imported from the IGP to be external destinations outside the
  532.            local autonomous system.
  533.  
  534.    4.2.  Manually configured tags
  535.  
  536.        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
  537.        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
  538.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  539.       |0|                          LocalInfo                          |
  540.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  541.  
  542.  
  543.       import  This tag setting corresponds to the administrator manually
  544.               setting the OSPF tag bits.
  545.  
  546.       export  The route SHOULD be exported into BGP with the attributes
  547.               ORIGIN=<EGP>, PATH=<local_AS>.
  548.  
  549.       Nothing MUST inferred about the characteristics of the set of
  550.       reachable destinations corresponding to this tag setting.
  551.  
  552.       For backward compatibility with existing implementations of OSPF
  553.       currently deployed in the field, this MUST be the default setting
  554.       for importing destinations into the OSPF routing domain.  There
  555.       MUST be a mechanism to enable automatic tag generation for
  556.       imported destinations.
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Varadhan, Hares & Rekhter                                      [Page 10]
  563.  
  564. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  565.  
  566.  
  567.    4.3.  Automatically generated tags
  568.  
  569.       4.3.1. Tag = <Automatic = 1, Complete = 0, PathLength = 00>
  570.  
  571.        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
  572.        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
  573.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  574.       |1|0|0|0|     ArbitraryTag      |       AutonomousSystem        |
  575.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  576.  
  577.  
  578.          import  These are reachable destinations imported from routing
  579.                  protocols with incomplete path information and cannot
  580.                  or may not carry the neighbour AS or AS path (and hence
  581.                  the IDRP RD_PATH) as part of the routing information.
  582.  
  583.                  This setting SHOULD be used to import reachable
  584.                  destinations from an IGP that the network administrator
  585.                  has configured as external routes, without specifying
  586.                  the next_hop_AS.
  587.  
  588.          export  The route SHOULD be exported into BGP/IDRP with the
  589.                  attributes ORIGIN=<EGP>, PATH=<Local_AS>.
  590.  
  591.       4.3.2. Tag = <Automatic = 1, Complete = 0, PathLength = 01>
  592.  
  593.        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
  594.        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
  595.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  596.       |1|0|0|1|     ArbitraryTag      |       AutonomousSystem        |
  597.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  598.  
  599.          import  These are reachable destinations imported from routing
  600.                  protocols with incomplete path information.  The
  601.                  neighbour AS (and therefore IDRP RD) is carried in the
  602.                  routing information.
  603.  
  604.                  This setting SHOULD be used for importing reachable
  605.                  destinations from EGP into the OSPF routing domain.
  606.                  This setting MAY also be used when importing reachable
  607.                  destinations from BGP/IDRP whose ORIGIN=<EGP> and
  608.                  PATH=<next_hop_AS>; if the BGP/IDRP learned route has
  609.                  no other transitive attributes, then its propagation
  610.                  via BGP/IDRP to ASBRs internal to the autonomous system
  611.                  MAY be suppressed.
  612.  
  613.          export  The route SHOULD be exported into BGP/IDRP with
  614.                  ORIGIN=<EGP> and PATH=<local_AS, next_hop_AS>.
  615.  
  616.  
  617.  
  618. Varadhan, Hares & Rekhter                                      [Page 11]
  619.  
  620. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  621.  
  622.  
  623.       4.3.3. Tag = <Automatic = 1, Complete = 0, PathLength = 10>
  624.  
  625.        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
  626.        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
  627.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  628.       |1|0|1|0|     ArbitraryTag      |       AutonomousSystem        |
  629.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  630.  
  631.          import  These are reachable destinations imported from routing
  632.                  protocols with truncated path information.
  633.  
  634.                  These are imported by a border router, which is running
  635.                  BGP/IDRP to a stub domain, and not running BGP/IDRP to
  636.                  other ASBRs in the same autonomous system.  This causes
  637.                  a truncation of the PATH.  These destinations MUST not
  638.                  be re-exported into BGP/IDRP at another ASBR.
  639.  
  640.          export  The route MUST never be exported into BGP/IDRP.
  641.  
  642.  
  643.  
  644.       4.3.4. Tag = <Automatic = 1, Complete = 1, PathLength = 00>
  645.  
  646.        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
  647.        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
  648.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  649.       |1|1|0|0|     ArbitraryTag      |       AutonomousSystem        |
  650.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  651.  
  652.          import  These are reachable destinations imported from routing
  653.                  protocols with either complete path information or are
  654.                  known to be complete through means other than that
  655.                  carried by the routing protocol.
  656.  
  657.                  This setting SHOULD be used for importing reachable
  658.                  destinations into OSPF from an IGP.
  659.  
  660.          export  The route SHOULD be exported to BGP/IDRP with
  661.                  ORIGIN=<IGP>, PATH=<Local_AS>.
  662.  
  663.       4.3.5. Tag = <Automatic = 1, Complete = 1, PathLength = 01>
  664.  
  665.        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
  666.        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
  667.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  668.       |1|1|0|1|     ArbitraryTag      |       AutonomousSystem        |
  669.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  670.  
  671.  
  672.  
  673.  
  674. Varadhan, Hares & Rekhter                                      [Page 12]
  675.  
  676. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  677.  
  678.  
  679.          import  These are reachable destinations imported from routing
  680.                  protocols with either complete path information, or are
  681.                  known to be complete through means other than that
  682.                  carried by the routing protocol.  The routing protocol
  683.                  also has additional information about the next hop AS
  684.                  or RD, the destination was learned from.
  685.  
  686.                  This setting SHOULD be used when the administrator
  687.                  explicitly associates an AS number with an instance of
  688.                  an IGP.  This setting MAY also be used when importing
  689.                  reachable destinations from BGP/IDRP whose ORIGIN=<IGP>
  690.                  and PATH=<next_hop_AS>; if the BGP/IDRP learned route
  691.                  has no other transitive attributes, then its
  692.                  propagation via BGP/IDRP to other ASBRs internal to the
  693.                  autonomous system MAY be suppressed.
  694.  
  695.          export  OSPF routes with this tag setting SHOULD be exported
  696.                  with the BGP/IDRP attributes, ORIGIN=<IGP>,
  697.                  PATH=<local_AS, next_hop_AS>.
  698.  
  699.       4.3.6. Tag = <Automatic = 1, Complete = 1, PathLength = 10>
  700.  
  701.        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
  702.        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
  703.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  704.       |1|1|1|0|     ArbitraryTag      |       AutonomousSystem        |
  705.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  706.  
  707.          import  These are reachable destinations imported from routing
  708.                  protocols with complete path information and carry the
  709.                  AS path information as part of the routing information.
  710.  
  711.                  These destinations MUST not be exported into BGP/IDRP
  712.                  because these are destinations that are already
  713.                  imported from BGP/IDRP into the OSPF RD.  Hence, it is
  714.                  assumed that the BGP/IDRP speaker will convey these
  715.                  routes to other BGP/IDRP speakers within the same
  716.                  autonomous system via BGP/IDRP.  An ASBR learning of
  717.                  such a destination MUST wait for the BGP update from
  718.                  its internal neighbours before advertising it to
  719.                  external BGP/IDRP peers.
  720.  
  721.          export  These routes MUST not be exported into BGP/IDRP.
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Varadhan, Hares & Rekhter                                      [Page 13]
  731.  
  732. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  733.  
  734.  
  735.    4.4.  Miscellaneous tag settings
  736.  
  737.        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
  738.        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
  739.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  740.       |1|x|1|1|              Reserved  for  future  use               |
  741.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  742.  
  743.       The value of PathLength=11 is reserved during automatic tag
  744.       generation.  Routers MUST NOT generate such a tag when importing
  745.       reachable destinations into the OSPF routing domain.  ASBRs must
  746.       ignore tags which indicate a PathLength=11.
  747.  
  748. 5.  Setting OSPF Forwarding Address and BGP/IDRP NEXT_HOP attribute
  749.  
  750.    Forwarding addresses are used to avoid extra hops between multiple
  751.    routers that share a common network and that speak different routing
  752.    protocols with each other on the common network.
  753.  
  754.    Both BGP/IDRP and OSPF have equivalents of forwarding addresses.  In
  755.    BGP and IDRP, the NEXT_HOP attribute is a well-known, mandatory
  756.    attribute.  OSPF has a Forwarding address field.  We will discuss how
  757.    these are to be filled in various situations.
  758.  
  759.    Consider the 4 router situation below:
  760.  
  761.    RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another.
  762.    RT1 and RT3 are talking BGP/IDRP with each other.  RT3 and RT4 are
  763.    talking OSPF with each other.
  764.  
  765.             +-----+                 +-----+
  766.             | RT1 |                 | RT2 |
  767.             +-----+                 +-----+
  768.                |                       |            common network
  769.             ---+-----------------------+--------------------------
  770.             <BGP/IDRP> |                       |
  771.                     +-----+     <OSPF>      +-----+
  772.                     | RT3 |                 | RT4 |
  773.                     +-----+                 +-----+
  774.  
  775.  
  776.      - Importing a reachable destination into OSPF:
  777.           When importing a destination from BGP/IDRP into OSPF, RT3 MUST
  778.           always fill the OSPF Forwarding Address with the BGP/IDRP
  779.           NEXT_HOP attribute for the destination.
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Varadhan, Hares & Rekhter                                      [Page 14]
  787.  
  788. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  789.  
  790.  
  791.      - Exporting a reachable destination into BGP:
  792.           When exporting set of reachable destinations internal to the
  793.           OSPF routing domain from OSPF to BGP/IDRP, if all the
  794.           destinations in the set of reachable destinations are through
  795.           RT4, then RT3 MAY fill the NEXT_HOP attribute for the set of
  796.           reachable destinations with the address of RT4.  This is to
  797.           avoid requiring packets to take an extra hop through RT3 when
  798.           traversing the AS boundary.  This is similar to the concept of
  799.           indirect neighbour support in EGP [RFC888, RFC827].
  800.  
  801. 6.  Changes from the BGP 3 - OSPF interactions document
  802.  
  803.      o    The use of the term "route" has attained a more complicated
  804.           structure in BGP 4.  This document follows the constraint in
  805.           the manner shown below:
  806.  
  807.           -    The term "set of reachable destinations" is called a NLRI
  808.                in [RFC1654].
  809.  
  810.           -    The term "route" in the BGP context refers to a set of
  811.                reachable destinations, and the associated attributes for
  812.                the set.
  813.  
  814.           -    The term "route" in the OSPF context refers to the set of
  815.                reachable destinations, and the cost and the type to
  816.                reach destinations.  This is to keep the definitions
  817.                consistent in the document.
  818.  
  819.      o    The notion of exchanging reachability information between BGP
  820.           4 and OSPF has been updated to handle variable length net mask
  821.           information.
  822.  
  823.      o    The previous term INTER_AS_METRIC in BGP 3 has now been
  824.           changed to MULTI_EXIT_DISC.
  825.  
  826.      o    The default metric to be used for importing BGP information
  827.           into the OSPF RD is now the LOCAL_PREF attribute, instead of a
  828.           constant value.
  829.  
  830.      o    Section 3 which requires an ASBR to match the OSPF tag
  831.           corresponding to a route to the BGP Identifier, can cause
  832.           potential loops if the AS has equal cost multipath routing
  833.           amongst the ASBRs.  This scenario is outlined in the Appendix
  834.           below.  This is fixed in BGP4 by requiring the ASBR seeing
  835.           equal cost multi-path routes to merge the PATHs through the
  836.           various ASBRs into appropriate SETs.
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Varadhan, Hares & Rekhter                                      [Page 15]
  843.  
  844. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  845.  
  846.  
  847.      o    BGP 4 requires that the BGP identifier be an address assigned
  848.           to the BGP speaker.  This is dealt with in section 3.
  849.  
  850.      o    Section 5 on setting NEXT_HOP attributes and Forwarding
  851.           Address field has been updated to account for variable length
  852.           net information.
  853.  
  854.      o    This section, 6, has been added.
  855.  
  856. 7.  Security Considerations
  857.  
  858.    Security issues are not discussed in this memo.
  859.  
  860. 8.  Acknowledgements
  861.  
  862.    We would like to thank Jeff Honig (Cornell University), John Moy
  863.    (Cascade Communications Corp.), Tony Li (cisco Systems), Rob Coltun
  864.    (Consultant), Dennis Ferguson (ANS, Inc.), Phil Almquist
  865.    (Consultant), Scott Bradner (Harvard University), and Joel Halpern
  866.    (Newbridge Networks Inc.) for their help and suggestions in writing
  867.    this document.  Cengiz Aleattinoglu (USC/ISI) and Steve Hotz
  868.    (USC/ISI) provided fresh insights into the packet looping problem
  869.    described in the appendix.
  870.  
  871.    We would also like to thank the countless number of people from the
  872.    OSPF and BGP working groups who have offered numerous suggestions and
  873.    comments on the different stages of this document.
  874.  
  875.    Thanks also to Bob Braden (ISI), whose suggestions on the earlier
  876.    BGP-OSPF document, [RFC1403] were useful even for this one, and have
  877.    been carried through.
  878.  
  879.    We would also like to thank OARnet, where one of the authors did most
  880.    of his work on this document, before moving to USC to resurrect his
  881.    PhD.
  882.  
  883. 9.  Bibliography
  884.  
  885.    [RFC827]  Rosen, E., "Exterior Gateway Protocol (EGP)", RFC 827,
  886.              BBN, October 1982.
  887.  
  888.    [RFC888]  Seamonson, L., and E. Rosen, "`STUB' Exterior Gateway
  889.              Protocol", RFC 888, BBN, January 1984.
  890.  
  891.    [RFC1058] Hedrick, C, "Routing Information Protocol", RFC 1058,
  892.              Rutgers University, June 1988.
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Varadhan, Hares & Rekhter                                      [Page 16]
  899.  
  900. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  901.  
  902.  
  903.    [RFC1122] Braden, R., Editor, "Requirements for Internet Hosts -
  904.              Communication Layers", STD 3, RFC 1122, USC/Information
  905.              Sciences Institute, October 1989.
  906.  
  907.    [RFC1123] Braden, R., Editor, "Requirements for Internet Hosts -
  908.              Application and Support", STD 3, RFC 1123,
  909.              USC/Information Sciences Institute, October 1989.
  910.  
  911.    [RFC1247] Moy, J., "The OSPF Specification Version 2", RFC 1247,
  912.              Proteon, January 1991.
  913.  
  914.    [RFC1403] Varadhan, K., "BGP OSPF Interaction", RFC 1403,
  915.              OARnet, January 1993.
  916.  
  917.    [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting:
  918.              an Address Assignment and Aggregation Strategy", RFC 1519,
  919.              BARRNet, cisco, Merit, OARnet, September 1993.
  920.  
  921.    [RFC1583] Moy, J., "The OSPF Specification Version 2", RFC 1583,
  922.              (Obsoletes [RFC1247]), Proteon, March 1994.
  923.  
  924.    [RFC1654] Rekhter, Y., and T. Li, Editors, "A Border Gateway
  925.              Protocol 4 (BGP-4)", RFC 1654, T.J. Watson Research Center,
  926.              IBM Corp., cisco Systems, July 1994.
  927.  
  928.    [ROUTE-LEAKING] Almquist, P., "Ruminations on Route Leaking",
  929.                    Work in Progress.
  930.  
  931.    [NEXT-HOP] Almquist, P., "Ruminations on the Next Hop,
  932.               Work in Progress.
  933.  
  934.    [IDRP] Hares, S., "IDRP for IP", Work in Progress.
  935.  
  936.    [IS10747] ISO/IEC IS 10747 - Information Processing Systems -
  937.              Telecommunications and Information Exchange between
  938.              Systems - Protocol for Exchange of Inter-domain Routeing
  939.              Information among Intermediate Systems to Support
  940.              Forwarding of ISO 8473 PDUs, 1993.
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Varadhan, Hares & Rekhter                                      [Page 17]
  955.  
  956. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  957.  
  958.  
  959. 10.  Appendix
  960.  
  961.    This is an example of how the two routing protocols, BGP/IDRP and
  962.    OSPF, might both be consistent in their behaviour, and yet packets
  963.    from a source domain, S, to a destination in domain X might be stuck
  964.    in a forwarding loop.
  965.  
  966.                                        +--------+
  967.                            X ----------| C1     |
  968.                            |           |Domain C|
  969.                            |           | C3  C2 |
  970.                            |           +--------+
  971.                            B             /   \
  972.                             \           /     \
  973.                              \         /      S
  974.                               \       /      /
  975.                                \     /      /
  976.                              +--------+    /
  977.                              | A1  A2 |   /
  978.                              |Domain A|  /
  979.                              |     A3 |-/
  980.                              +--------+
  981.  
  982.    Given the domains, X, A, B, C and S, let domains A and C be running
  983.    OSPF, and ASBRs A3 and C3 have equal cost multipath routes to A1, A2
  984.    and C1, C2 respectively.  The picture above shows the internal
  985.    structure of domains A and C only.
  986.  
  987.    During steady state, the following are the route advertisements:
  988.  
  989.      o    Domain B advertises to A path <B,X>
  990.  
  991.      o    ASBR A3 in domain A advertises path <A,B,X> to domain C, at
  992.           ASBR C2.
  993.  
  994.      o    Domain C has two equal cost paths to X: one direct <C,X>, and
  995.           another through A <C,A,B,X>
  996.  
  997.      o    BR C3 in domain C advertises to A2 path <C,X>
  998.  
  999.      o    Domain A has two equal cost paths to X: <A,C,X> and <A,B,X>
  1000.  
  1001.    Both C1 and C2 inject a route to X within the domain C, and likewise
  1002.    A1 and A2 inject a route to X within the domain A.  Since A3 and C3
  1003.    see equal cost routes to X through A1, A2 and C1, C2 respectively, a
  1004.    stable loop through ASBRs <A3, A2, C3, C2, A3> exists.
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Varadhan, Hares & Rekhter                                      [Page 18]
  1011.  
  1012. RFC 1745          BGP4/IDRP for IP - OSPF Interaction      December 1994
  1013.  
  1014.  
  1015.    Section 4 specifies that A3 and C3 that advertise a PATH to
  1016.    destination X, MUST aggregate all the PATHs through A1 and A2, and C1
  1017.    and C2 respectively.  This has the consequence of constraining the
  1018.    BGP/IDRP speaker in either domain A or domain C from choosing
  1019.    multiple routes to destination X, and importing only one route into
  1020.    OSPF.  This breaks the multiple paths seen in one domain.  The exact
  1021.    domain in which the multiple paths are broken is nondeterministic.
  1022.  
  1023. 11.  Authors' Present Addresses
  1024.  
  1025.    Kannan Varadhan
  1026.    USC/Information Sciences Institute
  1027.    4676 Admiralty Way
  1028.    Marina Del Rey, CA 90292-6695
  1029.  
  1030.    Phone: +1 310 822 1511 x 402
  1031.    EMail: kannan@isi.edu
  1032.  
  1033.  
  1034.    Susan Hares
  1035.    Merit, Inc.
  1036.    1071 Beal Avenue,
  1037.    Ann Arbor, MI 48109
  1038.  
  1039.    Phone: +1 313 936 2095
  1040.    EMail: skh@merit.edu
  1041.  
  1042.  
  1043.    Yakov Rekhter
  1044.    T.J. Watson Research Center, IBM Corporation
  1045.    P.O. Box 704,
  1046.    Yorktown Heights, NY 10598.
  1047.  
  1048.    Phone: +1 914 784 7361
  1049.    EMail: yakov@watson.ibm.com
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Varadhan, Hares & Rekhter                                      [Page 19]
  1067.  
  1068.