[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Inviting people to join the RRG

On 7 nov 2007, at 1:08, Robin Whittle wrote:


I am the only person to have attempted a comparison or critique of
of the proposals.  I haven't yet compared TRRP with the others.  It
is nearly 4 months since my Ivip proposal became available as an
Internet Draft
Can you send me the latest version of your draft (or a link) in private email? 


- and 3 weeks since I proposed a solution to the
PMTUD problems faced by all these ITR-ETR proposals:



 http://www.firstpr.com.au/ip/ivip/pmtud-frag/
I only scanned this quickly (it's a bit long...), but it looks like a complex scheme in the same vain as Fred's MTU proposals. In my opinion, that's not the best way to handle this. First of all, operators need to make sure that they use decent MTUs after tunneling so that hosts that send 1500-byte packets won't get in trouble or lead to much, if any, MTU discovery. Second, tunnel endpoints should simply implement two sides of path MTU discovery: they should discover the maximum packets they can successfully send to the other endpoint, and they should set their own inbound MTU to that value minus the size of the header that's added. This is simple enough that it's possible to get it right and doesn't add much overhead. 


I know the "crisis in routing and addressing" stuff we are working
on relates largely to scalability of the BGP routing system, and is
not explicitly tied to IPv4 address depletion, but I am adamant that:



1 - IPv4 address depletion is the most urgent architectural problem
   facing the Internet - and far better recognised than BGP
   stability and router scaling problems with the growth of
   advertised prefixes.
Ah, but that's a solved problem. RRG = research, IETF = engineering. IPv4 depletion = operation. We all know what needs to be done here. A wise man once said: just do it. 


2 - All the ITR-ETR schemes are capable of slicing and dicing IPv4
   address space in many more pieces, and in finer pieces, than
   is ever likely to be practical with BGP.



3 - Therefore, any of the ITR-ETR schemes could make a major
   contribution to the more efficient utilisation of IPv4 space.
I'm not convinced. The issue isn't the number of places that need an address block, but the number of places that need an individual address. 


4 - We are stuck with IPv4 for the next decade or so.  IPv6
   provides few, if any, benefits for ordinary end-users, is
   complex and is not ubiquitously supported by applications,
   firewalls etc.  No ordinary Internet user is likely to be happy
   with an IPv6-only address in the foreseeable future.


The alternative is NAT, which is worse.


5 - IPv4 address space utilisation could easily be improved if there
   were suitable policies and slicing and dicing technologies.
   Ping responsive host rates in advertised space are around 4%:
Meaningless. First of all, they also pinged unrouted space. Second, current Windows doesn't respond to pings. Third, there's NATs and firewalls. Fourth, not all systems are turned on 24/7. Fifth, this is an average that includes both stuff given out under the current fairly tight policies and large amounts of stuff given away to people who aren't using it anymore. 


   So there is plenty of room for improvement.
No. Any effort spent on getting back IPv4 space for new uses is wasted effort, because we need to move to IPv6 in the slightly longer run anyway. 


We are attempting to devise something really challenging here - and
I think more expertise, more energy and wider perspectives would be
very helpful.
Again: no. We made our beds over the past 15 years. We have another few years to fluff the pillows, then it's time to go to sleep. Even if it's possible to go back and redo the IPv6 effort and arrive at substantially better results (debatable), it's too late for that now. The message should be: you have three more years to start running IPv6 if you don't want to be left behind on a network that isn't going anywhere in the medium- to long term. 

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