Brian E Carpenter wrote:
...
I don't think that is quite the argument. It is more like this:
1. We know of no alternative to a longest-match based approach to
routing lookup for the inter-AS routing system (commonly known
as the DFZ).
2. To control the long-term scaling of that approach, we need to
control the long-term size of the lookup table and the long-term
rate of dynamic updates to that table.
3. We assume there will be continued unbounded growth in the
number of sites requiring multihoming, but today each site that
requires multihoming thereby requires its own entry in the DFZ
lookup table. In the long term, this is unsustainable.
[Digression about numbers and dates omitted.]
This does not necessarily follow ... Even so, we could easily scale a couple of
orders of magnitude from the existing number of multihomed edge networks, so
they aren't the problem. The fundamental problem with route scaling is that
people choose to pollute the system to do rudimentary traffic engineering with
BGP.
4. The known solutions to this all require some mechanism for
aggregating site prefixes into ISP prefixes.
BS... Containing the size requires aggregation, but ISP based prefixes is a
choice rather than a requirement.
[There's space for
a digression about the related advantages of separating
the transport ID from the network address, and about the
application layer's view of all this, but that doesn't
affect what I just said.]
5. One solution to that is a multi-prefix model (a site runs
multiple prefixes), which is of course the IPv6 design assumption.
Another solution is a map-and-encap model. A third solution is
a map-and-translate model. There are many variants of all these
models, but I don't know of a fourth one.
Choosing to ignore Geo approaches does not make them go away. Yes that means
that topology would have to follow routing rather than the other way around,
but that could be done at a global scale with regional deaggregates where
routing follows topology and the result would be carving up the scaling problem
to whatever size ISPs could get routers to support.
All solutions have advantages and disadvantages.
True enough, and geo requires the ISPs to consider something besides local
optimization at a cost to the entire rest of the world. These are all
trade-offs...
IMHO the reason we're hearing about NAT66 is because people
still find the IPv6 multi-prefix model unfamiliar and there is
no consensus-based map-and-encap solution yet. So it's natural
to look at map-and-translate, and NAT66 is one of the solutions
in that category.
While that is somewhat true, the majority of the reason has been clearly stated
by the proponents: Vendors are building 46/64, and will be throwing in 66 just
because they can. There has been no outcry from the masses trying to deploy
IPv6, it is strictly vendor driven because they want something they can point
to as justification for building something that is totally unnecessary.
Tony
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf