[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 Multi-homing BOF at NANOG 35

John Payne wrote:


On Oct 11, 2005, at 4:04 AM, Brian E Carpenter wrote:
Do you think that operators of commercial networks will want to switch to 
shim6?



They won't need to. Shim6 deploys in the hosts. An ISP doesn't have
to do a single thing to enable or switch to shim6. Customer sites with
two PA prefixes will just start multihoming. That's the beauty
of it.



Except for ISPs who are too small to get their own prefix....


Right.
A local ISP might decide to facilitate shim6 for the benefit of its customers (i.e. the ISP plus its subscribers becomes a "site" in shim6 terms). That ISP would indeed have to do something, but not much - advertise two prefixes 
to its customers, who would thereby get 2N addresses where they had N
addresses before. Shim6 would do the rest in the hosts.
How then does the ISP perform any traffic engineering if all of the control is in the end-host? That needs a _lot_ of focus because ISPs aren't going to put their 
COGS into the hands of their end users.


See the TLV discussion that Jason started. While I'm not sure he has
the right mechanism, there is definitely a requirement for hosts
to switch locators on request from a TE function as well as on outage.





[In both cases I've skimmed over exit router selection issues, which
still needs work.]
Understood, but do not forget inbound path selection or weighting or preference or whatever you want to call it. That needs to be controllable from the network 
level, not from the end hosts.


Yep. I think that is also a case where hosts will need to switch
on request.




Consider the current comfort level with the IPv4 style BGP
de-aggregate traffic engineering. Consider that the current approach to 
shim6 is less functional than the current IPv4 style multi-homing.



I don't think that's true, from the requirements viewpoint
of the end user.
I don't care about the end user's requirements so much as the ISP's requirements. The ISPs are the ones that need to manage cost, so they need tools equivalent to 
what they have today.


Understood, but the IETF is supposed to balance everybody's interests -
not just the ISPs', not just the end users'.





Consider the the shim6 solution may be very different to operate
(configuring end hosts instead of Internet facing routers)



No configuration involved. Just a shim6 capable stack.
That's oversimplifying it, surely? With no consideration to (again) traffic engineering, I can believe the lack of configuration... but with traffic engineering, 
*something* needs to be configured.


Hopefully only in the TE system itself, but I'm assuming a non-existent
mechanism for distributing address selection policy to hosts. I do agree that
is an open requirement today.




and may
break current operational boundaries.



It seems more likely to make them irrelevant, to me.



Some would see that as a problem.


Busines model issue, I guess.




There's a big difference between what major sites with the weight to
get their prefix advertised can do and what small and medium  businesses
without such weight can do. I don't doubt that a few thousand major
corporations will end up with PI-like solutions. I know that won't happen 
for tens of millions of small and medium businesses. I hope that ARIN
and all the RIRs move very carefully, for that reason.
Something like "you can get PI space if you have an ASN, when we run out of ASNs 
you run out of luck" ?


Well, we can easily fix the supply of ASNs. I think that when the
operators start yelling for that, the IETF and vendors know what to do.

But yes, PI doesn't scale. That's been known for ten years and I don't
see any new inventions that will change it.

   Brian