Robin, Please see below for some follow-up:
> -----Original Message----- > From: Robin Whittle [mailto:[email protected]] > Sent: Monday, February 02, 2009 8:36 AM > To: RRG > Cc: Templin, Fred L > Subject: Re: [rrg] RANGER-06 > > 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. Using the LISP terminology, the RANGER "Border Router (BR)" in fact performs the xTR function. But, have we settled on a common terminology for RRG (and perhaps other domains also) such that all map/encaps proposals have to use that terminology? > 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. RANGER treats each enterprise as a link and views all BRs (i.e., all xTRs) as neighbors on the link. That means that ordinary link-scoped neighbor discovery mechanisms (RS/RA/NS/NA/Redirect) can be used between BRs as if they were on-link neighbors. RANGER is also about discovery of BRs that can be used as exit gateways for forwarding packets to destinations outside of the enterprise. A special subset of these BRs are known as "Border Gateways (BGs)" and provide a "default" routing capability. In APT, these are known as "default mappers". In ISATAP and VET, they are known as "Potential Router List (PRL)" routers. > 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. How the mapping system works and the actual data in the mapping system is covered in detail in (VET, section 5.3.3). About EID, again this comes down to a terminology question. I still think the LISP EID terminology is misleading in that the thing EID refers to is an IP address that gets assigned to an interface just like any other IP address. I'm not going to beat on this further, but at the same time I don't want to propagate the use of the term in RANGER if I don't have to. > 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. There is a separate mapping service for each enterprise. Border Gateways (which are also known as PRL routers in ISATAP and VET, and are also known as "default mappers" in APT) have synchronized mapping tables that cover all inner IP prefixes reachable from within the enterprise. Border Gateways also provide default forwarding services for reaching inner IP prefixes that can only be reached outside of the enterprise. All BRs (i.e., all ITRs) cache the mappings they receive in their Forwarding Information Base. > Are the mapping queries and the query servers which send back > the reply all operating on the "outer" address space, the > "inner" or both? Using the default mapping option, Border Gateways are themselves xTRs that receive encapsulated packets, decapsulate them, and send encapsulated ICMP redirects back. So, both outer and inner space are used Using the DNS resolution option, the BR performing the query can locate a DNS server using the outer IP address space only and get back an outer IP (i.e., unencapsulated DNS response). Alternatively, it can use encapsulated DNS queries using both inner and outer address space. This may in fact be an important consideration for encapsulations that use IPsec. > 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. With RANGER, mapping resolution returns a list of ETR RLOCs that are potential next-hops toward an EID prefix. Locator liveness testing is done in the data plane, and if an RLOC appears to be failing, the ITR tries another. > 4 - One or two concrete examples of site multihoming. OK. > 5 - Likewise RANGER's "site mobility" and an explanation of how this > differs in principle and practice from "end system mobility". OK. > 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. For example, the IPv4 address space behind most home user's NAT boxes is taken from 192.168/16. That means that that (outer) IP prefix space is spatially reused among all such disjoint home networks. > 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? An IPv6 host on a native IPv6 link would not notice any change if the IPv6 router were to begin using RANGER. > 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. Correct. > If you could explain clearly how RANGER achieves a reduction in > DFZ size, while providing multihoming, TE and portability, that > would be great. Using the IPv6 example above, IPv6 prefixes go in the mapping table of a parent enterprise only; they do not go in the RIB of all parent enterprise border routers. > I guess this means the IPv4 DFZ, where > all the VET tunnels occur. In the Internet core, yes - the IPv4 DFZ. In "child" enterprises-within-enterprises, the VET tunnels occur within the borders of those child enterprises. > Is there anything like an IPv6 DFZ > in RANGER? Not that I can think of at the moment. > 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. Is there an agreed common terminology for RRG map/encaps? If not, isn't it sufficient for RANGER to define its own terms within its own scope? > 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. If you can grasp the RANGER Border Router/Gateway building blocks, you are most of the way there. > Then I can start to consider whether I think the whole thing > will work! Again, VET and SEAL give the details on how it works and a fair amount it is already working in prototype and production code. > 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. Hope this has helped. Fred [email protected] > > - Robin > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
