Re: [rrg] draft-narten-radir-problem-statement-05.txt

[Robin Whittle <[e-mail]>]

Hi Thomas,

Thanks for your reply, in which you wrote:

> Hi Robin.
> 
> I've looked at some of the references and older messages, but it's not
> clear to me what action item you want me to make. Do you have specific
> concerns with the accuracy of our document? etc? It would be much more
> helpful if you can point out specific wording or sections that you
> feel are not right - and explain why.

OK.  I support the improvements you have been discussing with Joel.
I have my own attempt (msg06099) to describe the problem, and won't try
to alter your document to match that.  I do have some suggestions
regarding "portability" and other difficulties inherent in renumbering.


>> Section 3.3 states "there are millions of potential end sites which
>> would benefit from being able to multihome".  Brian Carpenter and I
>> recently, independently, nominated 10 million as a rough upper limit
>> on the number of non-mobile network which want or need portability,
>> multihoming and/or TE (though perhaps Brian didn't mention
>> "portability".  My reasoning was roughly that with human population
>> of 10 billion, there will probably be only one organisation per 1000
>> people (mainly small companies, but also schools and other
>> organisations) which have sufficient need of portability or
>> multihoming to get "edge" space in a CES system and to get the two or
>> more physical links from two or more ISP's services as needed for
>> multihoming.
> 
> I don't know that I agree with this actually. In today's world of
> DSL/Cable/soon-to-be ubiquitous wireless, I could imagine every home
> using multiple ISPs. Won't those users want multihoming to work for
> them?

I doubt this would occur very much.  My impression is that most existing
services, such as via DSL, fibre or HFC cable are highly reliable except
for when a storm or other disastrous event damages infrastructure.
However I guess those who live in earthquake-prone areas, or where cyclones
and hurricanes are a constant threat, would have different perspectives.

If the DSL or whatever service is as reliable as the one I use - and I
only vaguely remember a short outage in almost four years - then I think
few people would want to add a router to link two services, and pay for
the extra service year-after-year.  The act of adding another box or
configuration item to the multihoming arrangement is would probably be
less reliable than the raw DSL service.

I suppose massively over-engineered, super-fast, multihomed home Internet
services could be the new form of hot-rodding, just as illuminated
sci-fi-like fluid-cooled gaming PCs with massive radiators seem to have
taken over from the hot-rodding of automobiles.


> But in any case, I don't know that  our document needs to take a stand
> on any one particular number.

OK.


>> I think the Problem Statement's references to "4.3. End Site
>> Renumbering" and to certain extent to "4.4. Acquisitions and
>> Mergers" could be improved by reference to address space
>> "portability".  The word "portability" does not appear in the
>> Statement, and while I think it makes some people's teeth itch, I
>> think it should be mentioned.
> 
> IMO, there is an important and subtle difference between "portability"
> and "renumbering hurts bad". They are not the same thing.

Portability is a solution to the problem - the only solution - while
"renumbering hurts bad" is the problem.

So perhaps I am going a little beyond the formal scope of the document
by referring to the problem in terms of the lack of its solution.

Still, since I (and I think many others, especially those with networks)
perceive the problem to be a lack of having portable address space which
is affordable, accessible and does not overly burden the interdomain
routing system, I think it would be reasonable to use the "portability"
term.

> Portability is only wanted because that is the primary solution for
> avoiding the pain of renumbering (other than NAT).

Yes, but since NAT gives no globally accessible hosts (unless by port
forwarding) "portability" of address space is the only solution - and
it comes at a price which is too high for many networks, and never
in scalable fashion.


> And portability also says (to me) something about individual prefixes
> going into the DFZ, which is not really what people necessarily
> actually care about (or want) when they want "portability". 

Core-Edge Separation (CES) architectures such as those being considered by
the RRG: LISP, Ivip, TIDR and IRON-RANGER are all intended to provide
portable address space - which is also suitable for end-user networks
to multihome, and have inbound TE - which does not unreasonably burden
the interdomain routing system's control plane.

Perhaps to those outside the RRG, "portability" implies a prefix of
space being advertised in the DFZ, people who working on CES architectures
are in the business of providing large numbers of genuinely portable
global unicast prefixes which are not advertised as individual prefixes
in the DFZ.  This includes prefixes longer than /24 all the way to
individual IPv4 addresses.  Ivip is not restricted to prefixes and can
separately map "micronets" of any number of contiguous IPv4 addresses
or IPv6 /64s.

With Ivip, a "Mapped Address Block" (MAB) is advertised in the DFZ.  For
instance a /16 MAB is advertised, but covers the "edge" "Scalable PI"
(SPI) address space used by thousands of end-user networks.  In LISP,
the term "EID" refers to this scalable "edge" space and the term
"coarse prefix" may be used for the same thing as Ivip's MAB.


> They want
> to be able to switch providers without renumbering. So I think it is
> more accurate to focus on that as being the true underlying issue.

Yes, but the only way of having global unicast address space and
avoiding changing this when using a different ISP is for the address
space to be "portable" to any ISP.


>> The problems mentioned in these sections arguably only exist because
>> only PI space is "portable" and that when splitting even this
>> portable space into two separately advertised PI prefixes is
>> possible, this contributes to the routing scaling problem.
> 
> Section 4.2 on multihoming pretty clearly points out that PI vs. PA is
> not the issue w.r.t. causing problems in the case of multihoming. You
> can multihome with PA space, but you get the same bad properties.

OK - I agree that the much the same routing scaling difficulties occur
due to advertising a PI prefix via one ISP or another as occur by
sometimes (when there is a fault) advertising a PA prefix which comes
from one ISP-A's shorter prefix as a more specific prefix via another
ISP-B.  With PA space, this does not normally add to the number of
prefixes in the DFZ, but making the switch to ISP-B adds a new prefix,
which is at least as disruptive as changing he advertisement of an
existing prefix.


>> Core-Edge Separation architectures provide a new subset of the global
>> unicast address space which is portable in a scalable manner, and
>> which can be split up much more finely than the /24 limit which
>> applies to conventional PI prefixes.
> 
>> So I think it would be reasonable to describe a key part of the
>> routing scaling problem as being due to the lack of portability for
>> any scalable form of address space in the current system.
> 
> I am not convinced that this is an accurate statement.

I think this is a reasonable way of characterizing the problem.

Below are some suggested alterations to the RADIR ID.

  - Robin



4.3. End Site Renumbering

   It is generally considered painful and costly to renumber a site,
   with the cost proportional to the size and complexity of the network
   and most importantly, to the degree that addresses are stored in
   places that are difficult in practice to update.

   The addresses of hosts and of the network's prefix may be stored in
   configuration  files and other places outside the network.  These
   address configurations are beyond the network's control and may be
   unknown to the network.

   Altering the DNS zone files for a large network may be an error-prone
   and costly process.  Furthermore, if the network hosts services for
   other organizations, the addresses of its hosts may appear in the
   zone files of other organisations, including those of the network's
   customers.  So renumbering may require the network to inconvenience
   its own customers, and burden them with the error-prone task of
   changing their DNS zone files to include new addresses at the
   particular time when the new space is adopted.  This cannot be done
   without disruption to the services provided to these customers.

   When using PA space, a site must renumber when changing providers.
   Larger sites object to this cost and view the requirement to renumber
   akin to being held "hostage" to the provider from which PA space was
   obtained.  This raises questions of competition policy and reduces
   the ability of networks to take advantage of better and/or less
   expensive alternative services.

   Consequently, many sites desire PI space, since this is currently the
   only type of global unicast space which is portable to any ISP.
   Having PI space provides independence from any one provider and makes
   it easier to switch providers (for whatever reason).  However, each
   individual PI prefix must be propagated throughout the DFZ and so
   adds to the control plane load.

   It should be noted that while larger sites may also want to
   multihome, the cost of renumbering drives some sites to seek PI
   space, even though they do not multihome.