[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] "No renumbering" for any networks precludes scalable support for packets from non-upgraded networks
- To: Routing Research Group <rrg@psg.com>, tony.li@tony.li
- Subject: [RRG] "No renumbering" for any networks precludes scalable support for packets from non-upgraded networks
- From: Robin Whittle <rw@firstpr.com.au>
- Date: Fri, 05 Sep 2008 12:08:57 +1000
- Organization: First Principles
- User-agent: Thunderbird 2.0.0.16 (Windows/20080708)
Hi Tony,
This consensus for no renumbering covers every kind of end-user
network which we want to adopt the scalable routing solution.
Do we have consensus that our proposed solution needs to be
attractive to all sizes of end-user network, including those
currently with PA addresses? Including a single PA IPv4 address,
such as my home network which runs on a fixed IP address DSL?
I think we should agree to this, since the largest number of
networks which want and need portability and multihoming are those
which currently use, or only really need, a very small amount of
address space, such as one or a few IPv4 addresses. Still, the same
argument applies to networks which have, and need, /24s and other
small slabs of address space.
I am sure the scalable routing solution needs to be highly
attractive to all these "small" networks, as well as the medium
sized and "big" networks such as those of universities, government
departments and large corporations.
Without this broad attractiveness to all sizes and types of end-user
network, our solution will not be adopted widely enough to make the
large impact we need to make on the routing scaling problem.
If we do have consensus that the RRG solution needs to be attractive
to all kinds and sizes of end-user network, then I can't imagine any
solution which will *scalably* enable a "small" network such as this
- let's say 1 to 1024 IPv4 addresses - to adopt the new system: to
gain what I call "Scalable PI" (SPI) space, in a way which supports
backwards compatibility with hosts in non-upgraded networks.
The only practical technique so far developed to ensure that traffic
from non-upgraded networks will be fully supported (portability of
the SPI-using network between ISPs, with multihoming and TE support
for all incoming traffic) is the technique used by Ivip's OITRDs
(Open ITRs in the DFZ) and LISP's PTRs (Proxy Tunnel Routers).
In both approaches, the SPI space needs to be within a larger
address block (shorter prefix) which is advertised in BGP. This is
absolutely required in order for the OITRDs or the PTRs in the DFZ
to be able to collect packets sent to these SPI networks by hosts in
networks without ITRs.
This will only be practical and scalable for small SPI networks if
multiple such networks' address space is combined into a single such
advertised prefix.
In Ivip, each (ideally large) advertised address block which
contains SPI space is called a Mapped Address Block (MAB). Up to
some limit, such as /10 or similar, the bigger these are, the
better, since this one advertised prefix provides OITRD support for
many (potentially millions of) separate SPI-using end-user networks.
With LISP PTRs, a similar requirement exists for the approach to be
scalable, but it is expressed in terms of these prefixes PTRs
advertise as being "highly aggregated".
Unless someone pulls a rabbit out of a hat, it will be impossible
for any new routing and addressing architecture to *scalably* cope
with a situation such as me introducing my little PI network's space
- 150.101.162.123/32 - into the Ivip system, LISP or any other
system which supports backwards compatibility for hosts from
non-upgraded networks.
Do we have consensus that our scalable routing system needs to be
highly attractive, including when adoption rates are low, in order
for it to have a chance of being widely enough adopted to make the
required impact on scaling?
I assume we would if this was tested.
If so, then do we have consensus that this level of attractiveness
can only be achieved by providing full support for packets sent from
non-upgraded networks?
I assume this would be the case too if it was tested.
In that case, then I argue that (unless someone invents something
far beyond what anyone has so far been able to devise) that the just
decided consensus for "no renumbering" paints us into a corner which
condemns any scalable routing solution which could have RRG support
to do something which is impossible: to scalably provide backwards
compatibility for all packets sent to SPI-using user networks of all
sizes.
Broadly speaking, we can't have:
(1) No renumbering" for all networks.
and
(2) Scalable support for packets sent from non-upgraded
networks to small networks which use the new system.
I believe (1) is desirable, but not essential for any PA network -
or for many PI networks, especially the smaller ones.
I believe (2) is absolutely essential for all networks which adopt
the new system.
I think those who voted for the "no renumbering" did not fully
consider the impracticality of providing (2) when they elevated (1)
to a "need" for all networks rather than something which I think is
"desirable" but not essential for PA and some PI networks.
My argument above has been about IPv4/32s. The same principle
applies for substantially larger, and less numerous, end-user
networks with a /24, a /23 or whatever.
The only way we currently know of by which we can provide backwards
compatible support for these numerous "small" networks is to ensure
they are in a BGP advertised prefix. Even if the network which
wants to convert to the new system wasn't buried in some ISP's
prefix - as my /32 is - if we have to advertise each such /24 or
whatever in BGP in order to provide support for packets from
non-upgraded networks, then the so-called solution is not going to
help much, or at all, with scalability, since the number of DFZ
routes will not be appreciably reduced.
My suggestions on how the scalable routing solution should or should
not require renumbering is described in:
Renumbering once might be OK when converting to Scalable PI (SPI
space) http://psg.com/lists/rrg/2008/msg02355.html
2008-08-26
I cannot imagine how the RRG can do useful work with the
just-decided consensus.
We could retain it and decide we don't have to support "small"
networks. In that case, our solution will be inapplicable to the
great majority of end-user networks we need to attract into using
it, in order to solve the scalability problem.
I believe the only way forward is as I suggest, expect all PA
networks to renumber once, when adopting the new system - and allow
for some PI networks to renumber, relinquish their space, and gain
new SPI space in an existing MAB.
- Robin
--
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