[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] How to Incrementally Deploy APT
Robin Whittle wrote:
This makes me think that APT would be a lot less effective at
enabling better utilization of IPv4 than the other proposals.
When, for instance, 80% of ISPs use APT and form a single island,
does this mean you could have edge networks with smaller address
assignments than the 256 lower limit imposed by your need to be
compatible with BGP's /24 limit?
Not necessarily, see below...
I think that any such smaller edge networks would not be reachable
without the problems I raised from the other 20% of networks.
Ivip "anycast ITRs in the core/DFZ" advertise Mapped Address Blocks.
These are /24 or shorter. A typical MAB might be a /16 or a /14.
It would contain the User Address Blocks (UABs) of hundreds or more
likely thousands of separate end-users.
Yes, but this is an economic issue, not a technical one. The reason you
can do this is that you require that an entire /24 or shorter prefix is
reserved for edge address space. There is no reason that APT cannot do
this as well, assuming it is economically feasible.
OK, so load sharing wouldn't work for traffic coming from an
upgraded network?
That's right. The portion of your traffic that follows your TE
preferences is based on the portion of traffic that comes from within
your island. This may actually be a good thing, as it will provide a
further incentive for islands to merge and customers to pick ISPs that
are part of larger islands.
However, this seems to us to be fundamentally the same problem
faced by LISP PTRs or Ivip anycast ITRs in the core -- the
ITR/PTR/BR/whatever becomes a necessary extra hop in the path
which may be less than optimal. So we don't agree that other
proposals avoid this problem.
With Ivip <snip>
Sending hosts all over the world, in non-upgraded networks, have
their packets attracted to one or more "anycast ITRs in the core/DFZ".
>
So there needs to be anycast ITRs in the
core/DFZ pretty widely scattered around the Net for the system to
work with little or no extra path lengths.
So it sounds like we agree.
I will reply to the rest of your message later. I haven't yet read
your discussions with Bill Herrin.
Thanks, Robin, we'll keep an eye out.
-Michael and Dan
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg