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.

> 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

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

> 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 only wanted because that is the primary solution for
avoiding the pain of renumbering (other than NAT).

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". 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.

> 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.

> 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.

rrg mailing list

Reply via email to