rfc1364.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |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
                        a=1,c=0,pl=10,as=don't care

      These are imported by a border router, which is running BGP to a
      stub domain, and not running IBGP to other ASBRs.  This causes a
      truncation of the AS_PATH.  These routes must not be re-exported
      into BGP at another ASBR.

   4.4.4.  Routes with complete path information, pl = 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
                   a=1,c=1,pl=00,as=0 => O=<IGP>, P=<l>

      This should be used for importing routes into OSPF from an IGP.




Varadhan                                                       [Page 10]

RFC 1364                  BGP OSPF Interaction            September 1992


   4.4.5.  Routes with complete path information, pl = 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
                 a=1,c=1,pl=01,as=nh => O=<IGP>, P=<l, nh>

      This setting should be used when the administrator explicitly
      associates an AS number with an instance of an IGP.  This setting
      can also be used when importing BGP routes whose origin=<IGP> and
      AS_PATH=<nh>; if the BGP learned route has no other transitive
      attributes, then its propogation via IBGP can be suppressed.

   4.4.6.  Routes with complete path information, pl >= 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
                        a=1,c=1,pl=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 via IBGP.

      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 IBGP.  In this situation, it must
      use tag settings corresponding to 4.1.2.2, or 4.1.2.5.




Varadhan                                                       [Page 11]

RFC 1364                  BGP OSPF Interaction            September 1992


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 pl = 3 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 pl = 3.

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.

           pl = 00       pl = 01            pl = 10        pl = 11
       +----------------------------------------------------------------
       |
c = 0  |    <EGP><l>    <EGP><l,nh>       never export       reserved
c = 1  |    <IGP><l>    <IGP><l,nh>       out of band        reserved
       |

      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 via IBGP.

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.

   Consider the 4 router situation below:



Varadhan                                                       [Page 12]

RFC 1364                  BGP OSPF Interaction            September 1992


   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 considerations are not discussed in this memo.

7.  Acknowledgements

   I would like to thank Yakov Rekhter, Jeff Honig, John Moy, Tony Li,
   and Dennis Ferguson 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 13]

RFC 1364                  BGP OSPF Interaction            September 1992


   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.

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", RFC 1058,
              Rutgers University, June 1988.

   [RFC1267]  Lougheed, K., and Y. Rekhter, "A Border Gateway
              Protocol 3 (BGP-3)", RFC 1267, cisco Systems,
              T.J. Watson Research Center, IBM Corp., October 1991.

   [RFC1268]  Rekhter, Y., and P. Gross, Editors, "Application of the
              Border Gateway Protocol in the Internet", RFC 1268,
              T.J. Watson Research Center, IBM Corp., ANS, October 1991.

   [RFC1247]  Moy, J., "The OSPF Specification - Version 2:", RFC 1247,
              Proteon, January 1991.

   [ROUTE-LEAKING]  Almquist, P., "Ruminations on Route Leaking",
                    Work in Progress.

   [NEXT-HOP]  Almquist, P., "Ruminations on the Next Hop",
               Work in Progress.

9.  Author's  Address

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

   EMail: [e-mail]











Varadhan                                                       [Page 14]