Re: [routing-wg]BGP Update Report

From: Vince Fuller (no email)
Date: Mon Sep 11 2006 - 14:22:18 EDT

  • Next message: Joe Abley: "Re: [Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]"

    >> The comment still applies. Imagine that this system were implemented
    >> globally on all international/intercontinental air routes. It would still
    >> be nice to avoid having each of those airplanes cause a globally-visible
    >> routing update whenever it crosses some geographical boundary.
    >
    > The problem is physics: The speed of light is about 300.000km/s in air
    > and about 200.000km/s in fibre, which means a VPN solution causes an
    > _additional_ >70ms delay for some additional 7000km VPN distance.

    If one assumes a well-engineered VPN solution that interconnects the ground
    stations to "peering" points to the rest of the Internet, then there should
    be no increase in delay for traffic outbound from the plane toward the
    Internet - traffic path will still be plane -> ground station -> nearest exit
    point to Internet.

    The amount of delay increase for return traffic is hard to quantify; it will
    depend on how well the Conxion service network/VPN is connected to its
    upstream providers, how well-connected those providers are to interconnect
    points to the rest of the Internet, whether shortest-exit routing (or some
    other "optimized exit routing") is implemented between the various providers,
    etc. Many of these issues will apply to the current, dynamically-route-every-
    prefix model, too. In some cases, the VPN will make little or no different
    in delay; in some cases, it may increase one-way delay a bit. On the upside,
    worries about more-specific filtering and route-dampening will go away.

    > No, VPN and NAT and PA and shim are not the solution for todays
    > mobile communications demands. From the view point of the developer
    > of such an intercontinental communications system todays internet
    > technology looks outdated, the BGP re-anouncement is just a hack.
    > Indeed, RFC1661 is dated July 1994.
    >
    > This is just another example for the obvious demand of a true dynamic
    > routing system beeing capable to handle large numbers of prefixes and
    > dynamic changes in the routing table. Other demand results from mobile
    > networks, IPv6 PI etc.
    >
    > The demand _is_ there, simply saying "don't use PI, do keep 200 customers
    > rules (IPv6), don't accept small prefixes, don't permit dynamic changes,
    > do wait for our perfect shim solution which takes short additional 10 years
    > to develop, do purely theoretical discussions on geoadressing" as the
    > "restrictive approach" is not the solution.
    >
    > Either the Internet community will find good answers to these demands,
    > or the markets will find solutions without the Internet community ...
    >
    > Ceterum Censeo: BGP_Standard_Update subito, IPv6 PI subito ...

    If one assumes no changes to ipv6 semantics, it is hard to envision such a
    solution being possible. "PI routing" degenerates into flat routing and
    building "a true dynamic routing system beeing capable to handle large numbers
    of prefixes and dynamic changes in the routing table" is difficult to
    impossible if one assumes a) a single number space that accomodates both
    routing information and endpoint-identification (which is a fundamental design
    assumption in ipv6 as currently specified) and b) continued super-linear
    growth in the number of unique subnets that are identified using that
    numbering space.

    There are smart people who have been looking at how to fix this for more than
    a decade (some would say that research along these lines dates back to the
    1960s...see http://www.nanog.org/mtg-0606/fuller.html for a recent NANOG
    presentation on this topic, with pointers to earlier work); virtually all of
    the designs that have been offered require routing locator/endpoint-id
    separation. Unfortunately, those who put together the current ipv6 did not
    choose to follow the locator/endpoint-id separation path. For a variety of
    reasons, trying to retro-fit the split into ipv6 with something like shim6
    is difficult and it running into a lot of resistance.

            --Vince


  • Next message: Joe Abley: "Re: [Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD