Subject: [rrg] RANGER-06

From: Robin Whittle <[email-masked]>
Date: Sun, 01 Feb 2009 22:51:18 +1100

Short version:    I read the RANGER I-D and came away without
                  any substantial understanding of what RANGER
                  is supposed to achieve, in terms of scalable
                  routing and addressing, or what new capabilities
                  or requirements it has for hosts - different from
                  how the IPv4 and IPv6 Internets work today.

Hi Fred,

Here are my thoughts when reading and trying to understand:

  http://tools.ietf.org/html/draft-templin-ranger-06

In the absence of any Summary and Analysis on the RRG wiki, and
without actually reading the various related I-Ds, I am hoping to
understand enough of RANGER by reading the above I-D - to decide
whether I want to read the other documents.

I thought I had a half-way decent understanding of SEAL from early
2008, but I wouldn't want to be examined on it, and I haven't kept up
with your revisions since then.

I don't really understand VET or ISATAP - but I figure I shouldn't
have to read a bunch of other documents in order to develop a
reasonable overview of RANGER.

You gave a summary:

  RANGER BOF - call for participation
  http://www.irtf.org/pipermail/rrg/2009-January/000909.html

While I understand that RANGER is intended to be a solution to the
routing and addressing problems we are all trying to solve, I
couldn't figure out from the summary whether RANGER is:

  1 - A core-edge separation scheme (LISP, APT, Ivip, TRRP)

  2 - A core-edge elimination scheme - usually done with
      changes in hosts, such as with HIP.

  3 - Something else.

The first two classes are discussed in:

      Towards a Future Internet Architecture: Arguments for
      Separating Edges from Transit Core
      Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang
      http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf

I got the clear impression that RANGER is intended to work with both
IPv4 and IPv6 and enable a recursive application of the same "network
within a network" structure, with one of the goals being the re-use
of at least some parts of the address space as separate namespaces in
separate networks.  There are lots of encapsulating tunnels, with
SEAL somehow taking care of the PMTU problems these cause.  IPv4 can
travel in IPv6 tunnels and vice-versa.

At this point, I wanted to know:

  1 - Is this intended to be a complete scalable routing solution?

  2 - Assuming this is the case, to what extent are host stack, API
      and application changes required?

  3 - I knew "mapping" was somehow involved in RANGER, but the
      introduction does not mention it, and I want to know how this
      concept in RANGER compares with its use in LISP, APT, Ivip etc.

  4 - What sort of introduction plan you had in mind, including
      immediate benefits to those end-user networks and ISPs which
      adopt it - together with costs, risks, changes to networks,
      hosts etc.

I am up to page 12 and will summarise my questions so far.

Then I will read on and write further comments.

In the terminology section, or in some early section, I think you
really need to give the reader a good functional understanding of
some of the building blocks of RANGER.  These include:

   The mapping system.  There are frequent references to this, but
   by page 12, no description of its purpose, structure or
   functionality.

   VET.  From the "Terminology" section:

      Virtual Enterprise Traversal (VET) [I-D.templin-autoconf-dhcp];
      functional specifications and operational practices that
      provide a functional superset of 6over4 and ISATAP.  In
      addition to both unicast and multicast tunneling, VET also
      supports address/prefix autoconfiguration as well as additional
      encapsulations such as IPSec, SEAL, LISP, etc.

   This is very broad-brush, so I read the abstracts:

      http://tools.ietf.org/html/draft-templin-autoconf-dhcp-32

         Enterprise networks connect routers over various link types,
         and may also connect to provider networks and/or the global
         Internet.  Nodes in enterprise networks must have a way to
         automatically provision IP addresses/prefixes and other
         information, and must also support internetworking operation
         even in highly-dynamic networks.  This document specifies a
         Virtual Enterprise Traversal (VET) abstraction for
         autoconfiguration and operation of nodes in enterprise
         networks.

      http://tools.ietf.org/html/rfc2529  (6over4)

         This memo specifies the frame format for transmission of
         IPv6 packets and the method of forming IPv6 link-local
         addresses over IPv4 domains.  It also specifies the content
         of the Source/Target Link-layer Address option used in the
         Router Solicitation, Router Advertisement, Neighbor
         Solicitation, and Neighbor Advertisement and Redirect
         messages, when those messages are transmitted on an IPv4
         multicast network.

         The motivation for this method is to allow isolated IPv6
         hosts, located on a physical link which has no directly
         connected IPv6 router, to become fully functional IPv6 hosts
         by using an IPv4 domain that supports IPv4 multicast as
         their virtual local link. It uses IPv4 multicast as a
         "virtual Ethernet".

            (IPv4 multicast??  Who actually uses this in big
             networks?  It doesn't work in the DFZ.  I see later
             that there is some explanation of this in section 4.1
             of the RANGER I-D.)

      http://tools.ietf.org/html/rfc5214  (ISATAP)

        The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
        connects dual-stack (IPv6/IPv4) nodes over IPv4 networks.
        ISATAP views the IPv4 network as a link layer for IPv6 and
        supports an automatic tunneling abstraction similar to the
        Non-Broadcast Multiple Access (NBMA) model.

   Lacking detailed understanding of all the above, I have a vague,
   open, notion of VET being a means of connecting things via
   tunnels, though I have no idea what this means with multicast, or
   with "LISP encapsulation" .

Now to the I-D:

Page 6:

  What is meant by "next generation enterprise networks"?

  I think I get the notion of "enterprises within enterprises" -
  including with inner enterprise networks running their own BGP
  which is separate from that of the outer enterprise.

  I don't understand how this differs in a functional sense from what
  can be done today with conventional techniques.  Also, how many
  enterprises want to be connected to the rest of the world solely
  from within another?

Page 8:

  I understand VET can connect multiple sub-enterprises within one
  enterprise, with the sub-enterprises using the outer enterprise's
  addressing system, or having their own.

  I want to know how DNS works in the latter scenario.  I think of
  DNS as a global system returning (in addition to MX records,
  sub-domains and potentially other things) one or more IP addresses
  for a given FQDN.  While I have heard of plans to make DNS supply
  different answers for requests from different places (and while I
  know there are good purposes for this in the global Internet to
  cause sessions to go to servers which are generally physically
  close to the requesting host) I want to know how DNS can work if
  some enterprises are using some numeric range of what is to other
  enterprises "public" address space in a different, private,
  manner than the other enterprises.

  With IPv6, there's plenty of space - so why would any network
  want to reuse part of it which someone else is already using?

  With IPv4, there is not enough - but how could reusing part of
  the global public space be a good idea, since it would seem to
  require that local hosts not be able to access some parts of
  the public address space outside?

Page 9:

     "The prefixes could be either Provider-Independent (PI) prefixes
      owned by the BR or Provider-Aggregated (PA) prefixes delegated
      by the BG, but the prefixes are linked with mapping and routing
      over the virtual topology in both cases."

   I don't understand how prefixes could be "linked".   I still have
   no idea what "mapping" means in the context of RANGER.

     "Additionally, fault tolerance and multihoming is naturally
      afforded through configuration of multiple BGs per enterprise."

   I haven't seen a diagram depicting multihomed networks, only one
   network within another.  Searching ahead I find a section on
   Multihoming, on page 16 and am alarmed to discover that HIP may
   be required to do it!

      "At the enterprise edge, a true location/identity split
       approach such as HIP may be necessary for supporting true
       multihoming across multiple physical links with diverse
       properties."

Page 10, para 2:

   I understand that PA prefixes are handed downwards, from routers
   closer to the DFZ to routers in sub-networks, and then from
   those routers potentially to further sub-networks etc.

   I also understand that PI prefixes are announced (by some
   secure means, I assume) from the lower levels and the upper
   layer routers carry the announcement, advertisement whatever
   to make the prefix appear to the rest of the world.

   But I still have no idea what RANGER's "mapping system" is, so
   I can't understand the following at all:  Regarding PI prefix
   information propagating upwards, via "registration":

      "This registration results in updates to the mapping system,
       which can later be used to populate a BR's Forwarding
       Information Base (FIB)."

Page 11 para 3:

   Again, there is mention of mapping: "mapping database lookups"
   but I still have no idea what this means.

   I gather that VET can have more than two networks connected to
   it, as per Figure 3, and that the connections need not always
   be maintained.   So I wonder how it scales if the traffic does
   need to maintain them.  If there are 100 networks connecting
   via VET, are there 100 * 99 separate sets of two-way tunnel?

OK - now I am at page 13, with more questions than understanding.

What exactly are "legacy services" in this context.  I figure they
are the global behaviours of the entire IPv4 and IPv6 Internets as
perceived by any participating host today.

But this is page 13, and there has been no description of what is
different, from a host point of view, or in terms of DNS, about the
new RANGER architecture.

What is it you are trying to do which is different from today's
Internets?

A quick scan of page 13 turns up, in the last para, mention of NAT in
some intermediate network as part of providing "legacy services".
NAT is to be avoided if at all possible.

I still don't understand why enterprises want to be recursively
nested.  For multihoming, don't they want two or more physically
diverse connections to the DFZ, as short and fat as possible?

If multihoming with RANGER requires host changes, such as with HIP,
then isn't this a complete non-starter in terms of any routing
scaling solution, which has to be adopted enthusiastically and
voluntarily by the great majority of end-user networks?

Page 14:

     "IPv4 NAT capability however this approach requires multiple
      instances of stateful NAT devices on the path which can lead to
      an overall degree of brittleness and intolerance to routing
      changes."

   This makes me think RANGER is some kind of radical revision of
   both IPv4 and IPv6 in a way which makes current hosts, DNS etc.
   non-functional, or only partially functional - and therefore to
   be known as "legacy" and afforded special treatment.

   What are the unique advantages of changing much of the Net over
   to this RANGER model?   LISP, APT, Ivip and TRRP etc. provide
   multihoming without any host changes, but it seems RANGER can't
   provide it, except with the complete host changes of HIP.

I can't make head or tail of section 3.2.3.

In 3.3 I understand that SEAL will somehow enable the creation of
good tunnels, with proper management of PMTUD, in an environment
where ICMP messages, particularly RFC 1191 Packet Too Big (PTB)
messages may be either lost or spoofed.

Page 15:

  "mapping/routing"??

Page 16:

  I haven't tried to follow all the mobile stuff, but I have a
  question about the airliner with a PI prefix which it announces
  at one ground station, and then the next (say 1/3 the way around
  the planet).

  As long as this is a real, public, PI prefix, then in order to
  ensure optimal paths, potentially all routers in the DFZ will
  need to adapt to the change.  It doesn't matter how many
  layers of networks there are between the DFZ and those
  ground points, or whether the ground points are owned by the
  same network or not.  Moving PI space requires BGP changes -
  and this is an unscalable approach considering the number of
  aircraft travelling in this way.   A solution is the TTR
  approach, in which this specific problem is discussed:

    http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

  I still don't have any clear idea of what RANGER is supposed to
  achieve or how it helps with mobility.

  The TTR approach avoids the need for the mobile node to ever
  renumber its public, numerically stable, physically globally
  mobile, address, no matter how many CoAs it has.  So there is
  no breaks in sessions, as long as connectivity is maintained
  via one CoA or another in any access network, including behind
  NAT.

Section 3.5 on multihoming:

  If an enterprise advertises a prefix to multiple upstream
  BGs, how do these advertise it upwards to the DFZ?  What if
  the link to one BG becomes unusable, but that BG is still
  advertising the prefix to the DFZ?

  Is HIP really needed for multihoming with RANGER?

  If so, this requires the hosts to get a separate address
  from each PA prefix from each upstream ISP/whatever.  But
  the first two sentences of this section involve the network
  advertising a PI prefix (or multiple PI prefixes) with
  every upstream BG.  This is like traditional BGP-based
  multihoming today - and not related at all to the PA based
  HIP approach.

Page 17:

       "4.4. The Locator Identifier Split Protocol (LISP)

        The Locator-Identifier Split Protocol (LISP)
        [I-D.farinacci-lisp] proposes a map-and-encaps architecture
        for scalable routing and addressing within the global
        Internet Default Free Zone (DFZ).  Several companion
        documents (e.g., LISP-ALT, LISP-CONS, LISP-EMACS,
        LISP-NERD) propose mapping function solutions.  A related
        mapping function solution proposal is found in
        [I-D.jen-apt]."

APT is not related to LISP, in my view.  It has some common
characteristics, such as non-real-time mapping and each ITR having to
do reachability testing to each ETR etc.

However, APT is more than a mapping distribution system.  It is
completely different from LISP-NERD on one hand and the other LISP
approaches on the other, in that it uses local query servers.

        "LISP, and a number of related proposals being discussed in
         the Routing Research Group, share common properties with the
         solution proposed here."

I have no idea what common properties these are.

       "They may therefore be architecturally consistent with
        the RANGER architecture."

I have spent a few hours trying to understand RANGER - its purpose,
its changes to host and DNS behavior, its support for multihoming,
its support for today's IPv4 and IPv6 Internet host and DNS behaviour
("legacy").  I still have no clear idea what RANGER is supposed to
achieve or how it works.

Does RANGER complement a global LISP, APT or Ivip system?

If so, then is it a solution to the scalable routing problem on its
own?  If so, then why would anyone want LISP, APT or Ivip?

If not, then why do we want to know about it here?  What does it add
to the scalable routing solution which is not already provided by
LISP, APT or Ivip?

The final section on Security again fails to connect with my mind in
a concrete enough fashion to form real understanding.

I need overall goals, purpose etc.  I need to know where this scheme
fits with other schemes - does it complement a core-edge separation
scheme, is it one in itself or is it something else?  I need to have
a rough understanding of the behaviour of the building blocks - SEAL
and VET - so I can envisage what RANGER builds them into.  I have
some understanding of SEAL, but none of VET.  I think the RANGER I-D
needs to be self-contained, so people who don't already know of your
specific building blocks can learn enough about them to understand
your description of how RANGER would work.

  - Robin

_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 1 Feb 2009 22:52:46 -0800

Robin,

Thank you for your consideration of RANGER. Please see
below for my responses: 

> -----Original Message-----
> From: Robin Whittle [mailto:[email-masked]] 
> Sent: Sunday, February 01, 2009 3:51 AM
> To: RRG
> Cc: Templin, Fred L
> Subject: RANGER-06
> 
>                   routing and addressing,

Scalable routing and addressing in RANGER has exactly the
same considerations as LISP, APT, and the other map/encaps
variants. It uses IP-in-IP encapsulation, with the outer
IP addresses taken from prefixes already published in BGP
routing tables in the global DFZ, and with inner IP
addresses taken from prefixes taken from a mapping table
kept separate from the global routing table. You have
heard me say it before, but IMHO to get to true scalable
routing and addressing we will need to eventually transition
to using IPv6 as the inner IP protocol for the long term.
But, nothing in the RANGER architecture depends on this.

>From a top-level perspective, RANGER is in many respects
th  offspring of a map/encaps lineage that includes (from
latest to eldest) RFC5214, RFC4380, RFC4213, RFC2529,
RFC2003, RFC1955, and certainly others that I am missing.

>                   or what new capabilities

No new capabilities or requirements for hosts. RANGER is
about xTR interactions in the network with unmodified hosts
at the edges. The hosts may be able to benefit from deploying
complementary mechanisms themselves in the future, but this
would be a separate transition and completely independent
of the RANGER domain of application.
 
> with your revisions since then.

Both the SEAL spec and prototype code have been stable
for a long time now.
 
> reasonable overview of RANGER.

RANGER is an architectural overview, and VET and SEAL
are functional building blocks. RANGER's job is to lead
the way for the other documents.

>   1 - A core-edge separation scheme (LISP, APT, Ivip, TRRP)

This is in fact exactly what RANGER is about.

>       changes in hosts, such as with HIP.

As stated earlier, the RANGER domain of application
focuses on the same xTR problem space as for LISP and
the others, and as such any host changes would be out
of scope. There is a sole exception that RANGER allows
end hosts to configure tunnel endpoints in certain
enterprise use cases, but that would be pushing the
RANGER core/edge separation all the way to the end
host as opposed to introducing a core-edge elimination
scheme. Such end hosts would generally be better served
to attach themselves to a native link of the inner IP
protocol and allow xTRs in the network to do any
necessary map/encaps, but in some cases there is
no other option.

>   1 - Is this intended to be a complete scalable routing solution?

Yes.

>       and application changes required?

No host stack/API/app changes.

>       concept in RANGER compares with its use in LISP, APT, Ivip etc.

RANGER supports mapping in two ways. First, ITRs that
have a packet to send but no matching FIB entry can
either discard or queue the packet while they lookup
the mapping in the mapping system. (VET uses DNS syntax
as the "front-end" for mapping lookups, but the back-end
could be any sort of distributed database that stores
the mapping tables.)

In the second method, the ITR forwards a packet to a
default mapper (i.e., just like APT) and gets an ICMP
redirect back. The packet gets stretched, but the ICMP
redirect provides route optimization for future packets. 

>       adopt it - together with costs, risks, changes to networks,

I think this is exactly the same analysis that the
LISP and APT approaches need to look at. But, RANGER
is advocating a transition to IPv6 also.
 
>   What is meant by "next generation enterprise networks"?

A next-generation enterprise network is one which
deploys xTRs at border routers. This can either be
through building a brand new enterprise network from
scratch or by simply placing xTR-equipped border
routers at the edges of existing enterprise networks.

>   enterprises want to be connected to the rest of the world solely

Using VET, each enterprise network appears as a virtual
Non-Broadcast, Multiple Access (NBMA) link, and multiple
enterprises are joined by xTRs that connect the links
together.

>   the public address space outside?

No, there is no re-use of inner IP address space; there
is only re-use of outer IP address space. And, the DNS
arrangement in VET calls for each enterprise to have
an enterprise-specific domain name (e.g., "example.com")
and arrange the inner IP address mappings as strings of
nibbles within that domain name. For example, for the
IPv6 prefix 2001:db8::/56 the mapping would appear as:

0.0.0.0.d.b.8.0.1.0.0.2.ip6.isatap.example.com

But, you really need to look to VET to get to this level
of detail.

>    network within another.
>    Searching ahead I find a section on

Whoops - time out! I think it is important to stop at
this point and making a clear differentiation between
*site* multihoming and *end system* multihoming. RANGER
is meaning to talk *only* about the former, while HIP
and others deal with the latter.  

> perceived by any participating host today.

Legacy services are services that were in place before
any inner IP addresses and prefixes were introduced into
the routing and addressing architecture. For example, if
inner IP addresses were IPv6 and outer IP were IPv4, the
legacy services would be any IPv4 services.

> different, from a host point of view, or in terms of DNS, about the

No differences for any hosts.
 
> nested.

Let's call the existing Internet a gigantic Enterprise
network - after all, it is an "enterprise" in which all
DFZ routers throughout the world have a mutual spirit
of cooperation but with the potential for competing
interests or even conflict. Let's say that each major
corporation or ISP attached to the DFZ (e.g., Boeing,
Comcast, etc.) was an enterprise unto itself which would
be organized at a lower level of recursion removed from
the global Internet DFZ. Then, within each such major
enterprise there may be distinct "sites" (e.g., europe,
asia, the americas, etc.) and within each of those
distinct sites there may be other sites, etc. etc.

Now, let's look at it the other way around and suppose
that some parallel Internets were to come into being
that were totally separate from the Internet of today.
Each of those distinct Internets would be a separate
enterprise, and each could be interconnected across
a commons at a higher layer of recursion. And it is
also possible to postulate still higher layers of
recursion above that etc. etc.  

> For multihoming, don't they want two or more physically

Site multihoming is indeed possible and encouraged.

> voluntarily by the great majority of end-user networks?

As I have been saying, RANGER and HIP are completely
separate mechanisms, where RANGER supports site
multihoming and HIP supports end system multihoming.
RANGER without HIP is the first-order deployment
scenario. HIP at a later time is possible, but has
nothing whatsoever to do with the RANGER deployment.
 
>   achieve or how it helps with mobility.

There is no intention whatsover that a fast-moving site
announce and withdraw PI prefixes frequently in a slow-
converging mapping system like the BGP. Boeing has learned
some lessons about this, and RANGER is not in any way
linked to or modeled after those earlier efforts.

Just as for multi-homing, RANGER intends to address *site*
mobility and allow other mechanisms to address *end system*
mobility if necessary.

>   advertising the prefix to the DFZ?

The prefix times out and goes away. If the link comes
back, the prefix will eventually come back.

>   Is HIP really needed for multihoming with RANGER?

HIP end-system mobility and multihoming are distinct and
separate from RANGER site mobility and multihoming as
addressed several times above.

> ("legacy").  I still have no clear idea what RANGER is supposed to

You should really look at VET and SEAL too.

> own?  If so, then why would anyone want LISP, APT or Ivip?

Beginning with the ISATAP model, the RANGER approach began
examining "small" enterprise networks (like a SOHO network,
a mobile ad-hoc network, etc.) but it soon became clear
that the enterprise-within-enterprise model could recurse
upwards into larger and still larger enterprises until
ultimately the core of the global Internet itself could
be viewed as an enterprise network in exactly the same
way. So yes, RANGER has popped up the stack into the
same solution space the other proposals are targeting.

> your description of how RANGER would work.

RANGER, VET and SEAL should really be read as multiple
chapters of the same book. I'm sorry if you don't feel
it should be this way, but I think you would find many
similar examples in the published literature (the IPsec
RFC series comes to mind).

Thanks - Fred
[email-masked]

---

From: Robin Whittle <[email-masked]>
Date: Tue, 03 Feb 2009 03:36:19 +1100

Hi Fred,

Thanks for these clarifications.  I am surprised, based on what I
read in the I that RANGER I-D:

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Feb 2009 11:00:02 -0800

Robin,

Please see below for some follow-up: 

> Sent: Monday, February 02, 2009 8:36 AM
> To: RRG
> Cc: Templin, Fred L
> Subject: Re: [rrg] RANGER-06
> 
> Hi Fred,
> 

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?  

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

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

>      server system as with LISP-ALT or TRRP and that ITRs are all

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.

>      the reply all operating on the "outer" address space, the

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. 

>      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.
 
>      differs in principle and practice from "end system mobility".

OK.

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

>      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.
 
>      via ITRs and the mapping system.

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

> specific to the author, but mean little - or something different - to

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?

> 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 

Again, VET and SEAL give the details on how it works
and a fair amount it is already working in prototype
and production code.

> can say about it on the list, and I am sure other people would be

Hope this has helped.

Fred