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