I-D Action:draft-azinger-scalable-addressing-00.txt
Brian E Carpenter
brian.e.carpenter at gmail.com
Tue Sep 28 22:48:17 CEST 2010
On 2010-09-29 03:58, Michael K. Smith - Adhost wrote:
...
>
> I'm trying to wrap my brain around how PA space is going to be "better" than PI space. Follow my potentially flawed logic.
>
> - I have a /32 that I announce through my various upstreams - no more specifics, just one /32.
> - I get a /48 from my upstream out of their /32. I announce my /48 through my various providers
> - I pressure my provider into announcing my /48 as well for traffic engineering
> - Now we have a /32 and a /48 in the table.
> - Rinse, repeat
>
> How is this better? Is it really anyone's assumption that I should be forced into a one-upstream solution and that I would find that acceptable?
Tony replied correctly, and indeed I teach graduate students that it isn't
better, so it must be true :-).
To be clear, the classical model for scalable PA-based multihoming in IPv6
is and always was that a multihomed site would simultaneously operate a
different PA prefix from each of its ISPs and each host would simultaneously
have N addresses, one for each of those ISPs. Whether you like it or not,
this works perfectly and allows complete aggregation. Shim6 was designed to
provide for session survival in that situation. This works too.
The problem is, site IT managers don't seem to like this model and its
implication of renumbering when you add or drop an ISP. (Whether ISPs
like it or not is somewhat irrelevant, because they have no say in whether
a site chooses to operate this way. Even the fact that it messes with
current methods of BGP-based traffic engineering is not an objection
that ISPs can force onto site IT managers.)
Hence, the RRG work, LISP, ILNP, etc. Been there, discussed that, and
here we are with PI as the only deployed alternative. Grumble.
Brian
More information about the ipv6-ops
mailing list