Bad routes update

[Joe Abley]

Hi,

On Tue, Jul 20, 1999 at 02:55:44AM -0400, Craig Metz wrote:
> In message <4D0A23B3F74DD111ACCD00805F31D810145155E7@RED-MSG-50>, you write:
> >> >3FFE:F00:2::0/48		11261
> >> 
> >>   This is not a bogus route per se. I told them to set it up 
> >> this way. I have
> >> been recommending that non-pTLA multi-homed sites use a /48, 
> >> which happens to
> >> mesh nicely with the way I've been managing tunnel address 
> >> space at NRL.
> >
> >This is bogus - the backbone should only see /24s.
> 
>   First off, you're going to have a very hard time arguing that the new /28s
> shouldn't be seen. Second, there *must* be some provision for sites to
> multi-home without being a full pTLA, or pTLA allocations will explode as will
> the allocations of pTLAs to people who shouldn't have them.

I was going to keep quiet about this until I had done a lot more reading,
but it seems that perhaps things aren't as cut and dried as I had imagined,
and perhaps there is some benefit in raising this on the 6bone list.

I asked questions about multi-homing a long time ago, and the prevelant
answer at the time (which I am hearing from Richard again, so I guess it
hasn't changed) was:

 o  if you connect to multiple pTLAs, you will get multple allocations
    of address space, since aggregation in the backbone is important and
    must not be compromised.

 o  if you connect to an NLA which is multi-homed, you will be provided
    with multiple addresses for every host.

I raised some issues regarding resilience of individual TCP sessions
in the event of a pTLA-NLA event upstream, and the answers were (and are):

 o  stability of individual sessions is not important in the event of
    a routing change upstream;

 o  having _new_ sessions connect correctly (i.e. handling the change
    of TCP session endpoint address) is more important; this will be done by

 o  an algorithm for choosing suitable source and destination addresses
    for TCP virtual circuit endpoints that will become clear with
    operational experience.

I am not convinced by the first point, and the second and third ideas
look very clumsy to me. Much more clumsy than having long-prefix routes
injected into the backbone, leading to routers with 80,000 routes in them,
to be honest. Personal opinion, and a little diversionary.

My real concern is the operational impact of managing IP addresses of
end users, or of the administrators just before the end-users. Suppose
we, as a large (by NZ terms; tiny in global terms) operator decide to
multi-home to four backbone providers. We will not be alone; other
providers in NZ will do similar things. This happens now with IPv4
in one way or another.

Today we have smaller ISPs who dual-attach to two or more of the major
carriers.

And below them we have customers who dual-home between ISPs.

All this dual-homing is done for a reason, and that's diversity -- the
way we build fault tolerance into our IP networks is to provision multiple,
diverse and independent paths, and to advertise our networks in every
direction. This takes care and skill to manage correctly, but if done
well can be very effective.

With IPv6, this means that the poor customer will need to number each
address on their equipment with as many as 16 different addresses
(their upstreams will each have to deal with 8).

>From an operational perspective, we deal with dual-homed customers today
who do not have technical staff in-house -- they hire it in, by the
hour, and pay through the nose for it. A change in a customer
relationship for one of the NLAs (who have no direct relationship with
the end customer in question) now has the knock-on effect of requiring
all downstream users to change addresses on their interfaces.

I believe the IPv6 autoconfiguration story, but only as far as it
goes -- I don't believe in effective automatic DNS and route filter
updates, for example. There is going to be manual intervention required
all along the track.

The number of end-users just in our customer base that have a business
requirement to multi-home increases every month.

This sounds a little bit like a nightmare. Is this for real? This
sounds a little less like IP, and a little more like E.164 number
portability in the switched voice network, complete with business
cards that need re-printing every two months (cue Psycho violins,
trembling shower curtain, shadow of hand c/w bloody knife).

For pTLA above, also read TLA in the real network -- I am presuming
that the original aims of the 6bone hold true, and that operational
procedures developed here will migrate their way to the Real Network.

I still presume that I am under some basic misconception that, once
cleared, will leave me happy and relaxed. The sooner someone can
point it out to me, the sooner I can get some sleep :)


Joe

-- 
Joe Abley <jabley@clear.co.nz>      Tel +64 9 912-4065, Fax +64 9 912-5008
Te Kaihoahoa Kawei, CLEAR Communications Ltd      http://www.clear.net.nz/