[rrg] RANGER-06

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
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg