Hi patte, In "Re: SIP will work fine with CES, CEE won't work with NAT" (msg05919) you 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 :-) Misunderstandings can be useful. There are occasions when the experts know something can't or shouldn't be done. Then a non-expert blunders in, not realising this, does it anyway - and makes it work better than the experienced folks could have imagined. For some reason I assumed LISP ITRs used the sending host's address in the outer source address of the encapsulated packets. Then I found it was useful in Ivip for extending ISP BR filtering to the ETR's decision of whether to forward or drop the inner packet - after which I discovered that LISP uses the ITR address for the outer source address. > 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). OK . . . > 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. I look forward to reading about hIPv4 properly. Based on a cursory reading I thought it was a CEE architecture. > 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??? I hope to read about it and write to you on the list with my understanding, queries, etc. towards the end of the week. > 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..?. After discussing it with you on the list, I plan to write a critique - since I think no-one has done so yet. - Robin _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
