re: [RRG] Re: Why not take address depletion issue into account

[Xu Xiaohu <xuxh@huawei.com>]

> Short version:
> 
>    When comparing map-encap proposals, we should consider their
>    ability to help with the IPv4 address depletion problem.  All
>    of them should be capable of making a major contribution to
>    improving address utilization.
> 
I agree. In fact, those approaches which use IPv4 address as EID will
alleviate the IP shortage problem, while other approaches which introduce a
new host identifier namespace will solve the address depletion problem.
So should this point be added as a desired option in RRG-Design-Goals?
>
>    This is the problem everyone knows about - so if we can
>    say this routing scalability solution is also inherently
>    a means of alleviating the IPv4 address "shortage", then
>    it will be a lot easier to get people excited about it.
> 
Agree.
> With Ivip it would be possible to have a caching ITR function built
> into the sending host.  However the system doesn't rely on this.  It
> would make sense most where there are cost benefits for the person
> who runs the hosts.  For instance, a server farm would have a choice
> between purchasing a bunch of high-powered ITRs to do all the work
> or installing some free software update to the OS of its servers.
> 
> Assuming the task per server is not to heavy on CPU or RAM (as it
> would be, except perhaps for the busiest servers which send packets
> to a very wide range of destinations), putting the ITR function in
> the host would be the best approach.
> 
It's a good option which will alleviate the pressure of the ITR. Although
the scalability issue seems nothing to do with the end-user, however, the
continual growth of routing table will degrade the routing stability which
will eventually degrade the service experience. Besides, the first adopter
of this host change will jump out of the initial packet loss/delay pain
provided some LISP-like solution was deployed.

On the other hand, the direct pressure on the carrier should be transferred
partially to the end users in a reasonable way. Although IETF/IRTF is not a
suitable place to talk about business model, it should consider offering
some corresponding solution once some business model succeeds.
>
> As long as we are using IPv4, I believe we are stuck with NAT - any
> widely used application needs to be able to fight its way out of
> whatever NAT or nested NATs, it finds itself in.  There is a lot of
> potential for standardising how NAT is applied and how it can be
> auto-discovered.  http://tools.ietf.org/wg/behave/ RFC 4787 but
> there will be plenty of NATs around for a long time which do not
> conform to any such standards.
> 
IPNL-A NAT-Extended Internet Architecture is a good idea, it not only
overcomes the side-effect of NAT which destroy the e2e argument, but also
utilizes the NAT box to extend the address space (global IPv4 address+
private address=a new and bigger address space). There is no need to upgrade
all the routers except the NAT boxes. Of course, the host should be changed
to use FQDN as host identifier.

Best regards,
Xiaohu XU



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