North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: shim6 @ NANOG (forwarded note from John Payne)
On 1-Mar-2006, at 13:32, Kevin Day wrote:
If a client has a set of locators, some of which are reachable via peering connections and some of which are reachable via transit connections, you want to be able to bias the locator selection such that (perhaps, e.g.) peering locators are always preferred to those which involve transit providers.Ok, I was a bit too vague there...We have peering arrangements with about 120 ASNs. How do we mix BGP IPv6 peering and Shim6 for transit?
Although simple performance benefits might cause hosts to make that decision on their own, you don't want to leave the decision up to the hosts, since if they get it wrong it will cost you money.
This seems inordinately reasonable. Did I summarise correctly?
[...]Actually, I think policies are conservative because there's a lack of solid, technical argument for loosening them. If (for example) there was consensus between operators and shim6 architects that the requirements of hosting providers are definitively not met by shim6, for technical/architectural reasons, then it'd be far easier to convince RIR memberships and boards that policy modifications should be made to accommodate operators like you.
[...]The trouble with this is that for every argument that says "PI for all will be fine" there's a corresponding argument that says "PI for all will not scale".
Without totally upending my network, I need:For sure, the simplest and cheapest thing for you would be to obtain PI space and continue as you have been doing with v4. The implications of that are not necessarily simple nor cheap for others, however, if you're one of $BIGNUM people doing it.
-- Kevin (wondering how many people are muttering 'kook' right now)