RE: [RRG] Renumbering...

["Tony Li" <tony.li@tony.li>]

Hello yet again Eric,
 

|I concur with you that ISPs will usually be strongly motivated to
|support their largest customers so that the PI space will be supported
|indefinitely for both IPv4 and IPv6. If this would not be the 
|case, then
|the largest end users may become motivated to take action themselves --
|such as to decree ourselves to be our own ISPs (i.e., this is just one
|of many scenarios that large end users have toyed with since 2000).
|Regardless, however you cut it, I believe that the PI space will exist
|and I recommend that you emotionally accept that probability. More
|pertinently, I recommend that RRG accepts PI support as a requirement
|for advancing any RRG variant.


Thanks, but I'm not going to be accepting that anytime soon.  When true PI
is a requirement, then the 'net cannot possible scale.  Period.  Full stop.

Thus, this means that NAT is necessarily a requirement.


|I believe that some of our current worldwide Internet scaling 
|issues are
|a direct function of correctable BGP protocol behavior, notably
|associated with how BGP handles policy issues. I am curious how many of
|these scaling issues would diminish if BGP policy was implemented
|slightly differently.


Frankly, it would be wholly irrelevant.  The arguments that I've put forth
about scalability are wholly about the number of prefixes that are
distributed, not about HOW they are distributed.  Even if you are one of the
folks that believes that we should run the Internet on PNNI, this
scalability issue does not evaporate.


|I am also of the opinion that many RRG alternatives, including those
|which do map and encaps, well support an Internet future that includes
|large PI spaces. I do not believe that a large PI harms RRG in 
|any way. 
|...
|If you make the PI space be defined within the
|identifier space, then why wouldn't both the re-addressing and 
|PI issues disappear?

As has been noted by many LISP proponents, if APT is used to provide the
mapping, then renumbering is a necessity to ensure that the EID space
aggregates.  Again, abstraction is a necessity for scalability, be it within
routing or within the mapping function.  The only way to maintain that
abstraction within the ID space is by renumbering.

Map and encap does not 'solve' the problem, it only pushes it from BGP into
the mapping function.  Of course, if BGP is also used as the mapping
function, it's largely the same problem.


|I do not resonate with the "gloom and doom" embedded in your comments
|below. Rather, I would like to remind you of an excellent paper that
|Mark Handley wrote in the BT Technology Journal (Vol 24, No. 3, July
|2006, pages 119-129) which he entitled "Why the Internet only just
|works."


Since the both of us have lived it, I'll just remind you that the reason
that it works is that the community responds to issues, frequently just in
time, with just enough distributed pain to ensure the continued operation
for the common good.  When all problems become "The Other Guys Issue", that
cooperation is headed for a downfall.

Hope you like NAT,
Tony


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