Hi Robin On Wed, Feb 3, 2010 at 10:15 AM, Robin Whittle <r...@firstpr.com.au> wrote: >> If you take the core-edge philosophy and apply that on the address >> space - creating a hierarchical address space the endpoints can still >> be identified though they use the same edge space. > > I wouldn't describe CES architectures such as LISP as involving > "hierarchical address space", so I am not sure what you are referring > to. How could the "edge" addresses of LISP (EIDs) or Ivip (SPI > addresses) be used so that two hosts could be separately identified, > separately used for communications or whatever, when they are on the > same "edge" address? > > The "edge" addresses are a subset of the global unicast address > space. Unless used as anycast addresses, any such address - in > either the "core" or "edge" subset - can be used to identify only one > host.
I used the LISP terms to link it to hIPv4, to make it easier to capture, but perhaps I'm just mixing up peoples mind by doing that You are right about what you are saying about CES, there is no "hierarchical address space" in a CES architecture - you are preserving the flat, global unique address space there I was inspired by LISP and had a little misunderstanding how it really works :-) Nevertheless I took the core-edge split philosophy from there and applied it also on the address space (to see where it goes), dividing the currently flat address space into one global unique address space, called Area Locators (ALOC) and several regionally unique edge-address spaces, called Endpoint Locators (ELOC). This gives you the possibility to build a new routing architecture - you will have two types of DFZ: - a global DFZ that is containing only ALOC prefixes, only service providers should have the possibility to apply for an ALOC prefix so the size of this global DFZ should be less than 100k for a very very long period - several edge-DFZ, each service provider will have their own edge-DFZ and the edge-DFZ will contain the following prefixes: * the global ALOC prefixes * the directly attached PA-addresses (mostly residential users and small businesses) * the directly attached PI-addresses from multi-homed enterprises. As you can see, the directly attached PA/PI-addresses never goes into the global DFZ and thus prefixes from one edge-DFZ doesn't go into another edge-DFZ. Also if you have BGP churn in a edge-DFZ it is not reflected to rest of the Internet. So I claim that hIPv4 is providing a new routing architecture - it is either not a CES or a CEE - it is something else. And it seems that you have to do something to the address space in order to get a new routing architecture. There are also challenges and issues, can they be worked through or not reminds to be seen. An outcome of this approach is also that IPv4 addresses can be reused, if hIPv4 is adopted we should see less NAT in the future. To speed up transition hIPv4 should cooperate with a CES approach, it will take time before hosts' stacks are upgraded. But first, is the hIPv4 technically correct, is there something that is broken??? Then you have all the transition issues, hIPv4 will have an impact on the service providers and RIRs so they should analyze and either accept or deny the approach - but this step should be taken if hIPv4 is technical doable. The final frontier is the end users, but I think MP-TCP will do the job for us there And for sure, hIPv4 is not perfect but is it good enough..?. -- patte _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
