home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-idr-as-dedicated-00.txt < prev    next >
Text File  |  1997-07-30  |  10KB  |  336 lines
  1.  
  2.  
  3. INTERNET-DRAFT                      John W. Stewart, III / ISI
  4. <draft-ietf-idr-as-dedicated-00.txt>              Tony Bates / Cisco
  5.                             Ravi Chandra / Cisco
  6.                                Enke Chen / Cisco
  7.                                    July 1997
  8.  
  9.  
  10.      Using a Dedicated AS for Sites    Homed to a Single Provider
  11.            <draft-ietf-idr-as-dedicated-00.txt>
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.    This    document is an Internet-Draft. Internet-Drafts are working docu-
  17.    ments of the    Internet Engineering Task Force    (IETF),    its areas, and
  18.    its working groups. Note that other groups may also distribute work-
  19.    ing documents as Internet-Drafts.
  20.  
  21.    Internet-Drafts are draft documents valid for a maximum of six
  22.    months.  Internet-Drafts may    be updated, replaced or    obsoleted by
  23.    other documents at any time.    It is not appropriate to use Internet-
  24.    Drafts as reference material    or to cite them    other than as a    "working
  25.    draft" or "work in progress."
  26.  
  27.    Please check    the abstract listing contained in each Internet-Draft
  28.    directory to    learn the current status of this or any    other Internet-
  29.    Draft.
  30.  
  31.  
  32. Abstract
  33.  
  34.    With    the increased growth of    the Internet, the number of customers
  35.    using BGP4 has grown    significantly. RFC1930 outlines    a set of guide-
  36.    lines for when one needs and    should use an AS. However, the customer
  37.    and service provider    (ISP) are left with a problem as a result of
  38.    this    in that    while there is no need for an allocated    AS under the
  39.    guidelines, certain conditions make the use of BGP4 a very pragmatic
  40.    and perhaps only way    to connect a customer homed to a single    ISP.
  41.    This    paper proposes a solution to this problem in line with recommen-
  42.    dations set forth in    RFC1930.
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Stewart, Bates,    Chandra    and Chen                    [Page 1]
  55.  
  56. INTERNET-DRAFT          Using    a Dedicated AS           February 1997
  57.  
  58.  
  59. 1.  Problems
  60.  
  61.    With    the increased growth of    the Internet, the number of customers
  62.    using BGP4 [1],[2] has grown    significantly. RFC1930 [4] outlines a
  63.    set of guidelines for when one needs    and should use an AS. However,
  64.    the customer    and service provider (ISP) are left with a problem as a
  65.    result of this in that while    there is no need for an    allocated AS
  66.    under the guidelines, certain conditions make the use of BGP4 a very
  67.    pragmatic and perhaps only way to connect a customer    homed to a sin-
  68.    gle ISP. These conditions are as follows:
  69.  
  70.    1) Customers    multi-homed to single provider
  71.  
  72.       Consider the scenario outlined in    Figure 1 below.
  73.  
  74.                 +-------+      +-------+
  75.                +----+    |      |       |
  76.         +------+   |    | ISP A    +------+ ISP B |
  77.         | Cust.+---+    |    |      |       |
  78.         |   X  +--------+    |      |       |
  79.         +------+    ++-----++\     +-------+
  80.                  |     |  \
  81.                  |     |   \  +--------+
  82.                 ++-----++   +-|           |
  83.                 | Cust.    |     |     ISP C |
  84.                 |   Y    |     |           |
  85.                 +-------+     +--------+
  86.  
  87.       Figure 1: Customers multi-home to a single provider
  88.  
  89.       Here both    customer X and customer    Y are multi-homed to a single
  90.       provider,    ISP A. Because these multiple connections are "local-
  91.       ized" between the    ISP A and its customers, the rest of the routing
  92.       system (ISP B and    ISP C in this case) doesn't need to see    routing
  93.       information for a    single multi-homed customer any    differently than
  94.       a    singly-homed customer as it has    the same routing policy    as ISP A
  95.       relative to ISP B    and ISP    C.  In other words, with respect to the
  96.       rest of the Internet routing system the organization is singly-
  97.       homed, so    the complexity of the multiple connections is not rele-
  98.       vant in a    global sense.  Autonomous System Numbers (AS) are iden-
  99.       tifiers used in routing protocols    and are    needed by routing
  100.       domains as part of the global routing system.  However, as [4]
  101.       correctly    outlines, organizations    with the same routing policy as
  102.       their upstream provider do not need an AS.
  103.  
  104.       Despite this fact, a problem exists in that many ISPs can    only
  105.       support the load-sharing and reliability requirements of a multi-
  106.       homed customer if    that customer exchanges    routing    information
  107.  
  108.  
  109.  
  110. Stewart, Bates,    Chandra    and Chen                    [Page 2]
  111.  
  112. INTERNET-DRAFT          Using    a Dedicated AS           February 1997
  113.  
  114.  
  115.       using BGP-4 which    does require an    AS as part of the protocol.
  116.  
  117.    2) Singly-homed customers requiring dynamic advertisement of    NLRI's
  118.  
  119.       While this is not    a common case as static    routing    is generally
  120.       used for this purpose, if    a large    amount of NLRI's need to be
  121.       advertised from the customer to the ISP it is often administra-
  122.       tively easier for    these prefixes to be advertised    using a    dynamic
  123.       routing protocol.    Today, the only    exterior gateway protocol (EGP)
  124.       that is able to do this is BGP. This leads to the    same problem
  125.       outlined in condition 1 above.
  126.  
  127.    As can be seen there    is clearly a problem with the recommendations
  128.    set forth in    [4] and    the practice of    using BGP4 in the scenarios
  129.    above. Section 2 proposes a solution    to this    problem    with following
  130.    sections describing the implications    and application    of the proposed
  131.    solution.
  132.  
  133.    It should also be noted that    if a customer is multi-homed to    more
  134.    than    one ISP    then they are advised to obtain    an official allocated AS
  135.    from    their allocation registry.
  136.  
  137.  
  138. 2.  Solution
  139.  
  140.    The solution    we are proposing is that all BGP customers homed to the
  141.    same    single ISP use a single, dedicated AS specified    by the ISP.
  142.  
  143.    Logically, this solution results in an ISP having many peers    with the
  144.    same    AS, although that AS exists in "islands" completely disconnected
  145.    from    one another.
  146.  
  147.    Several practical implications of this solution are discussed in the
  148.    next    section.
  149.  
  150. 3. Implications
  151.  
  152. 3.1 Full Routing Table Announcement
  153.  
  154.    The solution    precludes the ability for a BGP    customer using the dedi-
  155.    cated AS to receive 100% full routes.  Because of routing loop detec-
  156.    tion    of AS path, a BGP speaker rejects routes with its own AS number
  157.    in the AS path.  Imagine Customer X and Customer Y maintain BGP peers
  158.    with    Provider A using AS number N. Then, Customer X will not    be able
  159.    to received routes of Customer Y.  We do not    believe    that this would
  160.    cause a problem for Customer    X, though, because Customer X and Cus-
  161.    tomer Y are both stub networks so default routing is    adequate, and
  162.    the absence of a very small portion of the full routing table is
  163.  
  164.  
  165.  
  166. Stewart, Bates,    Chandra    and Chen                    [Page 3]
  167.  
  168. INTERNET-DRAFT          Using    a Dedicated AS           February 1997
  169.  
  170.  
  171.    unlikely to have a noticeable impact    on traffic patterns guided by
  172.    MEDs    received.
  173.  
  174.    A BGP customer using    the dedicated AS must carry a default route
  175.    (preferably receiving from its provider via BGP).
  176.  
  177.  
  178. 3.2  Change of External    Connectivity
  179.  
  180.    The dedicated AS specified by a provider is purely for use in peering
  181.    between its customers and the provider. When    a customer using the
  182.    dedicated AS    changes    its external connectivity, it may be necessary
  183.    for the customer to reconfigure their network to use    a different AS
  184.    number (either a globally unique one    if homed to multiple providers,
  185.    or a    dedicated AS of    a different provider).
  186.  
  187.  
  188. 3.3  Aggregation
  189.  
  190.    As BGP customers using this dedicated AS are    only homed to one ISP,
  191.    their routes    allocated from its providers CIDR block    do not need to
  192.    be announced    upstream by its    provider as the    providers will already
  193.    be originating the larger block. [6].
  194.  
  195.  
  196. 3.4  Routing Registries
  197.  
  198.    The Internet    Routing    Registry (IRR) [5] is used by providers    to gen-
  199.    erate route filtering lists.     Such lists are    derived    primarily from
  200.    the "origin"    attribute of the route objects.     The "origin" is the AS
  201.    that    originates the route.  With multiple customers using the same
  202.    AS, finer granularity will be necessary to generate the correct route
  203.    filtering.  For example, the    "mntner" attribute or the "community"
  204.    attribute of    a route    object can be used along with the "origin"
  205.    attribute in    generating the filtering lists.
  206.  
  207.  
  208. 4. Practice
  209.  
  210.    The AS number specified by a    provider can either be an AS from the
  211.    private AS space (64512 - 65535) [4], or be an AS previously    allo-
  212.    cated to the    provider.  With    the former, the    dedicated AS like all
  213.    other private AS's should be    stripped from its AS path while    the
  214.    route is being propagated to    the rest of the    Internet routing system.
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222. Stewart, Bates,    Chandra    and Chen                    [Page 4]
  223.  
  224. INTERNET-DRAFT          Using    a Dedicated AS           February 1997
  225.  
  226.  
  227. 5.  Security Considerations
  228.  
  229.    Security considerations are not discussed in    this memo.
  230.  
  231.  
  232. 6.  Acknowledgments
  233.  
  234.    The authors would like to thank Roy Alcala of MCI and Arpakorn
  235.    Boonkongchuen for  their input to this document.  The members of the
  236.    IDR Working Group also provided helpful comments.
  237.  
  238. 7.  References
  239.  
  240.    [1] Rekhter,    Y., and    Li, T.,    "A Border Gateway Protocol 4 (BGP-4)",
  241.    RFC1771, March 1995.
  242.  
  243.    [2] Rekhter,    Y., and    Gross, P., "Application    of the Border Gateway
  244.    Protocol in the Internet", RFC1772, March 1995.
  245.  
  246.    [3] Rekhter,    Y., "Routing in    a Multi-provider Internet", RFC1787,
  247.    April 1995.
  248.  
  249.    [4] Hawkinson, J., and Bates, T., "Guidelines for creation, selec-
  250.    tion, and registration of an    Autonomous System (AS)", RFC1930, March
  251.    1996.
  252.  
  253.    [5] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg,
  254.    M. Terpstra,    & J. Yu., "Representation of IP    Routing    Policies in a
  255.    Routing Registry (ripe-81++)", RFC1786, March 1995.
  256.  
  257.    [6] E. Chen,    J. Stewart., "A    Framework for Inter-Domain Route Aggre-
  258.    gation", draft-ietf-idr-aggregation-framework-01.txt, July 1997.
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. Stewart, Bates,    Chandra    and Chen                    [Page 5]
  279.  
  280. INTERNET-DRAFT          Using    a Dedicated AS           February 1997
  281.  
  282.  
  283. 8.  Author's Addresses
  284.  
  285.  
  286. John Stewart
  287. USC/ISI
  288. 4350 North Fairfax Drive
  289. Suite 620
  290. Arlington, VA  22203
  291. email: jstewart@isi.edu
  292.  
  293. Tony Bates
  294. Cisco Systems, Inc.
  295. 170 West Tasman    Drive
  296. San Jose, CA 95134
  297. email: tbates@cisco.com
  298.  
  299. Ravi Chandra
  300. Cisco Systems, Inc.
  301. 170 West Tasman    Drive
  302. San Jose, CA 95134
  303. email: rchandra@cisco.com
  304.  
  305. Enke Chen
  306. Cisco Systems, Inc.
  307. 170 West Tasman    Drive
  308. San Jose, CA 95134
  309. email: enkechen@cisco.com
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334. Stewart, Bates,    Chandra    and Chen                    [Page 6]
  335.  
  336.