Re: [rrg] RANGER-06

["Templin, Fred L" <[e-mail]>]

Robin,

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

> -----Original Message-----
> From: Robin Whittle [mailto:[e-mail]] 
> Sent: Sunday, February 01, 2009 3:51 AM
> To: RRG
> Cc: Templin, Fred L
> Subject: 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,

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
>                   or requirements it has for hosts - different from
>                   how the IPv4 and IPv6 Internets work today.

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

Both the SEAL spec and prototype code have been stable
for a long time now.
 
> 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.

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.

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

This is in fact exactly what RANGER is about.

>   2 - A core-edge elimination scheme - usually done with
>       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.

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

Yes.

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

No host stack/API/app changes.

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

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. 

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

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.

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

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.

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

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.

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

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.  

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

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.

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

No differences for any hosts.
 
> 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.

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
> diverse connections to the DFZ, as short and fat as possible?

Site multihoming is indeed possible and encouraged.

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

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

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.

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

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.

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

You should really look at VET and SEAL too.

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

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.

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

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
[e-mail]

> 
>   - Robin
> 
> 
_______________________________________________
rrg mailing list
[e-mail]
http://www.irtf.org/mailman/listinfo/rrg