> 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 [EMAIL PROTECTED] 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
