Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg

[Robin Whittle <[e-mail]>]

Hi Chris,

Thanks for your reply, in which you wrote:

>>  1 - The unreasonable, arguably unscalable, burden placed on the
>>      DFZ routers individually, and on the DFZ control plane in
>>      general, by the set of end-user networks which currently
>>      get portability, multihoming and inbound TE by the only
>>      means available: getting their own space and advertising it
>>      as PI prefixes in the DFZ.
> 
> it's not just their own space, it's PA space as well, leaked around
> the provider, or through the provider.

OK - for brevity I usually write just PI prefixes, but I understand
some end-user networks get a prefix as PA space from one ISP and then
have another ISP advertise it for multihoming service restoration.


>>  2 - The much larger number of end-user networks which could use 2
>>      or more ISPs and which want or need portability, multihoming or
>>      inbound TE but don't have it because they are unable to get the
>>      space and advertise it.  (Perhaps a subset of these could do
>>      it, but don't because they known how unscalable it is.)
> 
> I reckon most folks don't do it because they haven't hit a reason that
> they see to actually do it. 

A reason strong enough to get a bunch of address space from an RIR,
with whatever initial and ongoing expenses that involves, plus having
their ISPs advertise it.

> If there were a scalable, simple method
> for most anything to be 'multihomed' I suspect you'd see a whole lot
> more multihoming going on (or mobility, or simple device/network
> agility)

Yes - including multihoming a small business network which uses
relatively inexpensive connections, such as DSL, fibre, HFC cable or
WiMAX.  Such networks would generally never have the resources or
expertise to get address space, or the type of Internet connectivity
which ISPs are ready to use with prefixes they advertise in the DFZ.

I think most networks on these DSL etc. services don't need
portability or multihoming, but I think we should aim for a scalable
routing solution which is light-weight enough that those who do what
these benefits should be able to get it, without too much expense,
administrative stuff or expertise.  I think my Ivip system could do this:

  http://tools.ietf.org/html/draft-whittle-ivip-arch
  http://tools.ietf.org/html/draft-whittle-ivip-drtm

and that LISP could too, if it adopted a mapping system like DRTM and
 if it involved address arrangements along the lines I plan for Ivip.

Dino recently mentioned (msg06229):

  > No, no renumbering required. Plus we want people to use their
  > existing PI or PA prefixes as EID-prefixes when they convert to
  > LISP.

I can't imagine how it could be scalable or desirable for end-user
networks to use their PA prefixes as EIDs.  Each EID prefix needs to
be covered by a "coarse" prefix which is advertised by multiple PTRs
in the DFZ. (For Ivip, each micronet is within a MAB which is
advertised in the DFZ by multiple DITRs).

These "coarse" prefixes (MABs) need to cover the EID prefixes
(micronets) of many end-user networks, otherwise there is
insufficient scaling benefit.

There's no way I can imagine sufficient routing scalability
improvements being achieved by converting an isolated PA prefix into
an EID, since each such EID prefix, or set of them for one end-user
network, would need its own "coarse" prefix in the DFZ.


>> Then there is mobility - which has a prominent place in the RRG
>> Charter's description of the routing scaling problem.  Broadly
>> speaking, mobility is a whole other iceberg, so far completely submerged.
> 
> providers see this in their own networks, but today the technology
> doesn't work/exist (no need to debate which) to have this work
> reliably and simply across provider boundaries, so it seems
> 'submerged'.

I am keen to get some critiques / discussion of the TTR Mobility
architecture, which will provide globally mobile global unicast
addresses for mobile nodes, for IPv4 and IPv6, no matter what sort of
address the MN has, including behind NAT:

  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf


>> So even if Moore's Law keeps up in some acceptable manner with the
>> pace of growth in the number of PI prefixes in the DFZ, this doesn't
>> help with point 2 or with mobility.
> 
> Tony's and VInce's work seems to say that moores law: 1) isn't going
> to cut it, 2) doesn't apply anyway... we should just drop this from
> the idea bench.

I agree.  We can't keep relying on semiconductors becoming more powerful.

  - Robin