[ppml] Proposed Policy: PI assignments for V6

[Owen DeLong]

--On Thursday, December 9, 2004 4:42 PM +0100 marcelo bagnulo braun 
<marcelo at it.uc3m.es> wrote:

> Hi Stephen,
>
> just a  comment...
>
> El 09/12/2004, a las 1:15, Stephen Sprunk escribió:
>>> That said. There are a few things I think is being forgotten in this
>>> discussion, and I really, really didn't want to point this out, but I
>>> guess I have to. PI space have the property that you can take it with
>>> you when you change providers, and really only solves renumbering. It
>>> does not give you anything wrt provider independence you do not
>>> already have. Why? Because you can today already either get multiple
>>> PAs, which won't help the problem with surviving TCP flows, but
>>> honestly, PI won't help you with that either.
>>
>> Please explain how connections using PI addresses do not survive when
>> a site's link to the respective provider goes down, either
>> intentionally or otherwise.
>>
>
> i don't know what Kurtis had in mind when he made this comments, if you
> pretend to obtain tcp connection survivability with current size of the
> bgp global routing table, you will find the problems described in C.
> Labovitz, A. Ahuja, A. Bose, “Delayed Internet Routing Convergence”,
> 2000, SIGCOMM 2000.
>
Much of that has been somewhat mitigated with recent advances in router
software.  Withdrawls now happen quite a bit faster than they did in 2000,
and, the fact that table insertions take longer is generally not as harmful
as the slow withdrawls used to be.

In my experience recently having been running routers at multi-homed 
end-sites,
we saw relatively good TCP session survivability across provider outage
events with restoration times in the 15-30 second range and full convergence
taking on the order of 2-4 minutes.  YMMV, but, those are my recent
real world observations.

> in addition you probably have to deal with default BGP keepalive timer
> which in widely deployed commercial routers is 180 seconds. This means
> that some failures modes that are only detected through bgp keepalives,
> it will take 3 minutes to detect the failre which is probably longer that
> most apps using tcp connections are willing to wait. So the question is
> how much of this feature of established connection preservation through
> BGP reconvergence is actually a myth (in ipv4)... (clearly for now in
> ipv6 i guess we don't have delayed reconvergence, for now)
>
You only have to deal with default BGP keepalive timers if you don't
know how to configure them differently on your router.  In most EBGP
sessions, I have found that 10 second keepalives with 30 second fallovers
do not provide a significant additional load on the routers and provide
much faster failover.  Additionally, in my recent experience, this 
particular
type of failure is less common than other failure modes.  In fact, my
recent experience has been that circuit failures are most likely, followed
by link-affecting router failures (e.g. the connection drops due to
link state detection rather than waiting for BGP timer).  Undetected
failures that wait for the BGP timer are, in my experience, quite
rare except in the instance of multihop sessions.

Again, YMMV, but, this has been my experience in this situation within
the last 6 months.

As such, I'd say it's fact, not myth.

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20041209/d7fde711/attachment.sig>