Hi Fred, Thanks for these clarifications. I am surprised, based on what I read in the I that RANGER I-D:
http://tools.ietf.org/html/draft-templin-ranger-06 that RANGER resembles LISP, APT or Ivip in that it has xTRs (ITRs and ETRs) and a mapping system. There is no mention of xTRs in the I-D. I hope you will explain this more clearly, on the RRG list and/or in a revised I-D - including by giving detailed examples and explanations of many things, such as: 0 - The major architectural differences between RANGER and other comparable schemes, such as LISP-ALT - and what benefits and problems arise from RANGER compared to some alternatives. 1 - How the mapping system works from the point of view of the ITR. This includes what actual data is in the mapping for each EID or whatever it is which is a unit of address space ("inner" address space, I think, in your terminology) which has a common treatment at ITRs. 2 - Who controls the mapping - from an administrative point of view - and in a technical sense: what are the query servers which respond to mapping queries. I gather it is a global query server system as with LISP-ALT or TRRP and that ITRs are all caching ITRs. Are the mapping queries and the query servers which send back the reply all operating on the "outer" address space, the "inner" or both? 3 - How ITRs do reachability testing to ETRs, and make decisions about which ETR to use. Ivip doesn't do it this way, but LISP and APT do - so as far as I know, so does RANGER. 4 - One or two concrete examples of site multihoming. 5 - Likewise RANGER's "site mobility" and an explanation of how this differs in principle and practice from "end system mobility". 6 - What "reuse of outer address space" means, with some examples. I gather that, for instance, IPv4 space would be "outer" in the way you are depicting RANGER - analogous to LISP's RLOC space. "Inner space" I think is analogous to LISP's EID space - and in your preferred example is IPv6 space. 7 - I understand a "legacy" host, such as an IPv4 host would keep working normally, and wouldn't be able to access anything in the inner address space (IPv6). But what about existing IPv6 hosts in networks which don't implement RANGER? Will they still be able to communicate with any IPv6 host in any of the RANGER equipped networks? 8 - I understand, in your preferred example, that IPv4 acts like RLOC space and IPv6 like EID space. I guess that means that each network somehow only needs to have a routing system which handles a subset of the IPv6 space, with the rest accessible via ITRs and the mapping system. If you could explain clearly how RANGER achieves a reduction in DFZ size, while providing multihoming, TE and portability, that would be great. I guess this means the IPv4 DFZ, where all the VET tunnels occur. Is there anything like an IPv6 DFZ in RANGER? It is always difficult explaining something new to people you you don't know, via a unidirectional link such as a written document. It is hard to avoid using terms which mean something detailed and specific to the author, but mean little - or something different - to the reader. Your response has definitely helped me understand what you are trying to achieve, but I probably won't be diving into VET or SEAL soon. My overall experience is that you describe things in such high-level terms, quite a few of which I don't understand in the specific way you do, and that I have a very hard time constructing a nuts and bolts model in my head of what RANGER would be like. It helps to know the goals of RANGER - as I think you have described more clearly in this reply than I in the I-D. However, in order for me to I feel I understand something I need to imagine a number of building blocks which I understand very clearly, and then imagine them strung together and interacting. Then I can start to consider whether I think the whole thing will work! I probably won't have time to build such an understanding of RANGER in the foreseeable future, but I am keen to read anything more you can say about it on the list, and I am sure other people would be interested too. - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
