[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Taxonomy: 25 questions
Short version: Two questions which weed out the impractical
proposals and leave us with five potentially
practical map-encap proposals.
Then, 23 questions which lead to a
taxonomy within which these five sit.
I think the answers to these help us
to understand the problems and
potential solutions.
Here are some questions which I think provide useful insights about
the five potentially practical map-encap schemes, and some schemes
which are impractical, at least according to my criteria (10) in:
Re: [RRG] What does incremental deployment mean - 2 questions
2008-03-22 http://psg.com/lists/rrg/2008/msg00957.html
I think criteria such as this must be met by any scheme which would
have a hope of being deployed widely enough to significantly reduce
the routing scaling problem.
These questions should all be answerable by the developers of each
scheme without much debate. I have answered for other proposals
where I felt confident I could give the right answer - but I may
have made mistakes.
Although many of the questions are strongly linked to outcomes such
as "deployability", "security" etc. none of them, as far as I know,
involve making value judgements about the performance of each
proposal, other than rough evaluations of mapping update time and
delay times for initial packets.
Links to these proposals are at the RRG Wiki:
http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup
[Q01]
Does the scheme require host changes in order for hosts to
participate in it? This includes adopting dual stack IPv4/v6 and
applications which in fact use IPv6. (A No for this answer means the
scheme could work, in different versions, with both IPv4 and IPv6.)
APT No.
AIRA ?
CRIO No?
LISP-ALT/NERD No.
IPvLX Yes. "long-term IPv6/IPv4
coexistence, with IPv6 addresses
serving as identifiers."
Anything proposed by
Heiner Hummel. Yes, as much as I understand
his proposals, which seem to
involve radical changes to
routing and addressing.
ISATAP Yes - IPv6.
Ivip No.
Six/One Router Yes - IPv6.
Six/One Yes - IPv6 with host changes to
implement Six/One.
TAMARA Yes - IPv6.
TRRP No.
I think those schemes above for which the answer is Yes should be
mentioned in the Taxonomy in this respect, but not considered any
further - unless perhaps in a completely separate section reserved
for long-term plans not restricted by practical considerations of
being deployable in currently foreseeable circumstances.
Trying to solve the IPv4 routing scaling problem by migrating users
to IPv6 addresses only (no IPv4 address at all) is nowhere near a
practical solution. There is no significant adoption of IPv6 at
present amongst general Internet users and no such user could
survive for a moment without their IPv4 address. Furthermore, there
is no routing scalability problem in IPv6 now, so IPv6 routing
scalability, lack of multihoming (now /48 PI space is available)
etc. is not a problem restricting the adoption of IPv6. So a
proposal which proposes to solve only the IPv6 scaling problem is of
no importance in the foreseeable future - only in the long term if
and when IPv6 is ever really widely used.
[Q02]
For the proposals for which the Q01 answer was No, do they aim to
provide a mechanism by which there is no loss of connectivity for
any hosts, as the system is deployed, including for communications
to and from networks with no upgrades?
APT Yes. However, there are limitations on the
support for EIDs, which might be resolved if APT
used allowed a somewhat different type of link
between APT networks, so there would naturally be
only one global APT system, rather than multiple
APT islands. See my message "APT: no need for
islands?" 2008-03-12:
http://psg.com/lists/rrg/2008/msg00734.html
AIRA No - there are two separate namespaces for
Identifiers and Locators. That means that hosts
using the new Identifiers for their own addresses
won't be able to communicate with hosts which are
not upgraded.
CRIO This is a complex proposal I have very little
understanding of, which has not been discussed
much recently in the RRG, and for which no RRG 8
page summary and analysis has been prepared.
AFAIK, it involves radical address changes
and so I think the answer is No.
LISP-ALT/NERD Yes - "Proxy Tunnel Routers".
Ivip Yes - OITRDs (Open ITRs in the DFZ, formerly
"anycast ITRs in the core".
TRRP Yes, but I can't recall exactly how at present.
This leaves five proposals which have a chance of meeting my message
957 (10) criteria (ignoring LISP-CONS, which I think is on the
back-burner):
APT
Ivip
LISP-NERD
LISP-ALT
TRRP
Since all other proposals have no hope of being practical, I think
rest of the Taxonomy should only consider these five proposals - and
any new proposals or variants which pass muster in the above two
questions.
Here are some Taxonomy questions which I think are illuminating:
[Q03]
How is mapping delivered to ITRs?
APT Hybrid push-pull.
Push to Default Mappers.
Pull to caching ITRs from Default Mappers.
Ivip Hybrid push-pull.
Push to full database ITRs (ITRDs) and to full
database Query Servers (QSDs).
Pull to caching ITRs (ITRCs), ITR functions in
sending hosts (ITFHs - not behind NAT) and
caching Query Servers (QSCs) from QSDs and QSCs.
LISP-NERD Pure push. (Not expected to be scalable to
hundreds of millions or billions of
EIDs.)
LISP-ALT Pure pull.
TRRP Pure pull.
[Q04]
How fast can an end-user's mapping change be sent to all ITRs?
(See my message: "Mapping model discussion - push, pull, hybrids
and notify", 2008-03-11: http://psg.com/lists/rrg/2008/msg00707.html
and "Notify = "proactive" updates; flexible placement of full db
ITRs & query servers" 2008-03-13 message 757.)
APT Slowly. Depends on slow flooding protocol and the
ability of Default Mappers to Notify ITRs of
changed mapping. No times are mentioned, but I
recall the earlier version, with BGP flooding,
anticipated the mapping not changing for days or
months.
Ivip Fast - ideally 5 seconds. Fast push to ITRDs and
QSDs. Immediate Notify from QSDs (via any intermediate
QSCs) to all ITRs which might be sending packets
for the micronet with changed mapping (according
to the caching time of map replies given out by
the QSD): ITRCs and ITFHs.
LISP-NERD Slowly. Depends on frequency by which central
servers files are updated with user mapping
changes and then on how frequently each ITR
downloads all the most recent files, or update
files.
LISP-ALT In practical terms, slowly, such as minutes or
tens of minutes. Depends primarily the caching
time of map replies - and shorter times means
more queries, responses etc. There is no Notify
(ITR cache invalidation) mechanism.
TRRP As for LISP-ALT, since both use a global query
server network. TRRP doesn't have a workable
Notify system. It has a limited cache invalidation
system where an unreachable ETR leads to an ICMP
message to an ITR, which can then issue a new
mapping request.
[Q05]
Would end-users pay for mapping changes:
APT I don't think so, but ISPs would be annoyed at
constant flurries of mapping changes tying up
their flooding system.
Ivip Yes - a few cents, I guess.
LISP-NERD I guess not, but again, if whoever runs the
central server gets sick of some end-users
constantly changing their mapping, some fees
would be charged.
LISP-ALT No. The end user runs their own authoritative
query servers in a pure pull global network.
They can change mapping as often as they like
without burdening anyone. But what about the
burden of mapping replies with short caching
times?
TRRP As for LISP-ALT.
[Q06]
Does the end-user have to pay for traffic directed to their micronet
/ EID prefix?
APT ?
Ivip Yes - the RUAS runs the OITRD ITRs in the DFZ, and can
be expected to charge end-users according to what
traffic these ITRs handle. However, this is probably
just a server sitting at an Internet exchange, so the
cost would be a lot less per gigabyte than for
connectivity via an ISP.
LISP-NERD } Not with current proposals - but these proposals
LISP-ALT } have no business plan for Proxy Tunnel Routers
TRRP ?
[Q07]
What information is contained in each micronet's mapping (each EID
prefix's mapping)?
Ivip The ETR address.
APT } One or more ETR addresses, with weights and
LISP-NERD } priorities to enable each ITR to implement
LISP-ALT } multihoming service restoration and/or
TRRP } inbound load sharing (explicit TE).
[Q08]
Therefore, what functionality is required in the ITR and ETR?
Ivip No reachability functionality, except as a by-product
of Ivip's inbuilt PMTUD and fragmentation management
system (yet to be finalised, but see my PMTUD-frag
page).
APT } ITRs must individually determine reachability
LISP-NERD } of each ETR and whether the ETR can reach the
LISP-ALT } destination. Also, I think in LISP, the ETR
TRRP } may, or must, somehow tell ITRs about reachability
of other ETRs which are in the mapping. (But
how does the ETR know exactly what mapping the
ITR has??)
[Q09]
Therefore, is the system a monolithic approach, permanently
integrating reachability and multihoming service restoration
decision-making functions in the map-encap scheme, or enabling and
requiring end-users to supply their own reachability and
decision-making systems?
Ivip Modular = non-monolithic.
End-users must do their own reachability testing
and make their own decisions on how to restore
service. (They would typically do this by hiring
some company to do it however they want it done.)
APT } Monolithic system. Since all these do not
LISP-NERD } get end-user mapping changes to all ITRs
LISP-ALT } quickly, the map-encap system must do all
TRRP } reachability testing and make all decisions.
ITRs and ETRs must do this, using relatively simple
mechanisms and mapping data which are hardwired into
the entire map-encap system. This will not
satisfy all needs of end-users, since it is
impossible to anticipate all the ways end-users might
want to test reachability and since it is impossible
to define exceedingly complex or extensible
arrangements into the map-encap scheme itself.
Also, ITRs acting alone are a poorly scalable and
inefficient mechanism for testing reachability and
for making decisions.
[Q10]
Does the proposal tackle the PMTU and Fragmentation problem?
APT No.
Ivip Yes - but I haven't finalised it.
http://www.firstpr.com.au/ip/ivip/pmtud-frag/
LISP-NERD } Yes, but this is subject to critiques which have
LISP-ALT not yet been answered:
http://psg.com/lists/rrg/2008/msg00678.html
http://psg.com/lists/rrg/2008/msg00687.html
http://psg.com/lists/rrg/2008/msg00692.html
http://psg.com/lists/rrg/2008/msg00694.html etc.
TRRP No.
[Q11]
Does the system involve explicit TE?
Ivip No. Load sharing must be done by splitting the traffic
over multiple micronets (each of which can be a single
IP address) and then mapping the micronets to different
ETRs, so the traffic is split over multiple links to
the provider networks with these ETRs.
This can be changed (for a small fee per update) in
real-time, which may make it more useful - at least
in some settings - than the slowly controlled, explicit
TE functions of the other schemes.
APT } Yes - they all use a similar method of specifying
LISP-NERD } the share of traffic to be sent to two or more
LISP-ALT } ETRs, by each ITR operating independently - except
TRRP } that in the case of APT, the Default Mapper makes the
splitting decision and tells each querying ITR a
single ETR address to use.
[Q12]
Does the system provide complete portability of the end-users mapped
address space?
Ivip } Yes - as long as the end-user network uses an ISP
APT } which has an ETR and which will accept outgoing
LISP-NERD } packet with the source address being within the
LISP-ALT } end-user's micronet (EID prefix).
TRRP } For ISPs which don't do this, Ivip's mobility
system, which requires the end user to be a
customer of a TTR network, will provide forwarding
of the end-user's outgoing packets.
[Q13]
Does the system aspire to support mobility, and if so, how?
Ivip Yes, without any extra complexity for the basic
map-encap requirements for solving the routing
scalability problem. See:
http://www.firstpr.com.au/ip/ivip/#mobile
which has new diagrams. This is a new approach to
mobility. See message 994 for using these "mobility"
techniques as a lightweight approach to multihoming
a fast, generally reliable, but expensive fibre link
for a moderate sized commercial end-user network.
APT } No specific mechanisms for supporting new
LISP-NERD } approaches to mobility. Should work fine
LISP-ALT } with existing mobile-IP, although any interactions
TRRP } have not yet been explored in detail.
[Q14]
What is the granularity of address management?
Ivip IPv4 addresses or IPv6 /64s. Within these
increments, each micronet has an arbitrary starting
point and length (except that the maximum length
of an IPv4 micronet is 2^24). This is not yet in
the Ivip IDs, but is described in message:
http://psg.com/lists/rrg/2008/msg00958.html
APT } Not yet clear, but I think they can all support
LISP-NERD } EID prefixes starting at any IPv4 address or
LISP-ALT } IPv6 /64, in CIDR prefix format and therefore
TRRP } powers of two lengths on binary boundaries.
[Q15]
What role might the scheme play in the IPv4 address depletion
problem, other than the long-term possibility of helping make IPv6
more attractive in various ways, including by providing a solution
to the multihoming, routing scaling problem etc. in IPv6?
Ivip Intended to help via lower-cost, more flexible,
management of finer slices of address space, including
individual IPv4 addresses. This will enable more
end-user networks to have MH, portability etc.
and will enable IPv4 space to be utilised significantly
more efficiently. This capability does not involve any
additional complexity over what is required for solving
the routing scalability problem.
APT } I think they would all be nearly as good as Ivip
LISP-NERD } for helping improve IPv4 address utilization.
LISP-ALT } Ivip's finer control over micronet length makes it
TRRP } somewhat better in this regard.
I think none of them have better IPv4 address
utilisation as an explicitly goal.
Nonetheless, any proposal which solves the routing
scalability problem for IPv4 must surely be
improve the utilization of IPv4 address space to
some degree. Since they could all do this, with
potentially smaller chunks than BGP can do (256
addresses at present) I think they are all capable
of making a big difference to IPv4 utilization and
therefore to make a significant contribution to the
IPv4 address depletion problem.
(This won't solve the problem - just extend it to give more time for
IPv6 or some other alternative to become attractive and widely used.
Alternatively, it will enable more of us to bury ourselves more
deeply entangled in IPv4 and so make the prospect of something else
even more unthinkable!)
[Q16]
What is the business case for the proposal's mechanisms for
supporting communication between hosts in upgraded and non-upgraded
networks?
APT No explicit business case, I think, other than general
benefits due to APT. I am not quite sure how it
works, but I think networks in APT islands have all
their border routers advertising prefixes to the BGP
system which cover APT-mapped EID prefixes of end-user
networks which use ISP networks inside the island.
So what traffic flows where, and why should one ISP
carry and advertise to non-APT networks for traffic
which will be sent to another ISP for that second ISP's
customer?
Ivip For the business case for RUASes deploying OITRDs:
"Open ITRs in the DFZ" (OITRDs), formerly "Anycast
ITRs in the core" 2008-03-21
http://psg.com/lists/rrg/2008/msg00937.html
LISP-NERD "Proxy Tunnel Routers" - there has been no discussion
of the business case for these in NERD specifically.
LISP-ALT Recent long discussions in the RRG seem to indicate
the LISP designers have no business case in mind for
"Proxy Tunnel Routers":
http://psg.com/lists/rrg/2008/msg00963.html
http://psg.com/lists/rrg/2008/msg00965.html
As far as I know, the alternative - LISP-NAT -
won't work. See my critique of LISP-NAT on
2007-12-01:
http://psg.com/lists/rrg/2007/msg00674.html
TRRP I don't recall the details right now, but
http://bill.herrin.us/network/trrp-implementation.html
mentions various carrots and sticks.
[Q17]
Where are ITRs placed?
APT Default Mappers are in ISP networks, perhaps at
border routers if I remember correctly. All other
ITRs are caching ITRs and I think they can be located
at Provider Edge routers, or is it Customer Edge, or
both, or in other places too?
Ivip OITRDs in the DFZ. ITRs can be pretty much anywhere
in provider and end-user networks, as long as they
have an ordinary ("RLOC" = public, stable, conventional
BGP managed) address. Also, ITFHs in sending hosts
with such addresses.
LISP-NERD } PTRs in the DFZ, and ITRs where?
LISP-ALT }
TRRP I am not sure - I guess in provider and perhaps
end-user networks.
[Q18]
Where are ETRs placed?
APT The same devices as ITRs? (Not counting Default
Mappers, which are ITRs too.)
Ivip ETRs can be pretty much anywhere in provider and
end-user networks, as long as they have an ordinary
("RLOC" = public, stable, conventional BGP managed)
address.
LISP-NERD } ETRs are generally in the same devices as ITRs
LISP-ALT } except PTRs?
TRRP I am not sure - I guess in provider and perhaps
end-user networks.
[Q19]
Does the internal routing system of ISP networks need to know about
each end-user network's micronet (EID prefix)? In other words, can
an ETR in an ISP network put out raw, decapsulated, traffic packets
it receives from an ITR and expect the internal routing system to
take these packets to the proper destination?
APT ?
Ivip No. ETRs need some kind of explicit link to get their
decapsulated packets to the destination. This could
be a physical link, or a tunnel of some kind.
(TTRs are special ETRs for mobility which do this via a
2-way tunnel established by the Mobile Node.)
LISP-NERD } ? I guess so.
LISP-ALT }
TRRP ? I guess so.
[Q20]
Does every packet addressed to a micronet (EID prefix) have to go
through an ITR and an ETR? If the answer is No to this question,
then it means that the proposal expects packets to be delivered to
the correct ETR not just by the map-encap scheme, but also by the
local routing system of any ISP network which is configured to have
the end-user's prefix in its local routing system. Where two ISP
networks have ETRs for the one end-user network, and they rely on
the internal routing system to deliver raw decapsulated packets from
the ETR to the proper point which links to the end-user network,
then each such ISP must have the micronet / EID of the end-user's
network in its internal routing system. For consistent operation,
this means the internal routing system needs to perform the same
functions as an ITR, including deciding whether this ETR is
reachable and has a connection to the end-user network (and if not
so, then tunneling the packet to another ISP's network and its ETR,
which requires an ITR function).
APT ?
Ivip Yes.
LISP-NERD } ?
LISP-ALT }
TRRP ?
[Q21]
What is the source address of the outer header of the packets in the
ITR-ETR tunnel?
Ivip Sending host's address.
APT } ITR's address.
LISP-NERD }
LISP-ALT }
TRRP }
[Q22]
Following the above answers, can the sending host traceroute through
the tunnel?
Ivip Yes, with a somewhat modified traceroute program. This
would also be able to identify the ITR and ETR.
APT } No, unless the ITR did heroics to convert the ICMP
LISP-NERD } messages it receives into ICMP messages with the
LISP-ALT } correct data for a standard or modified traceroute
TRRP } program on the sending host to recognise.
[Q23]
Following the answer about outer source address, how can an ETR
perform the same filtering on packets it decapsulates as an ISP
border router might perform on packets coming into the ISP network -
specifically, rejecting any packets from outside the ISP network
which have source addresses matching any internal prefix of that
network? See note below my signature for more on this.
Ivip The ETR simply rejects any inner packet which has a
different source address than the source address
of the outer header. See "ETRs checking src & dest
addresses", RAM list, 2007-07-12:
http://www.ietf.org/mail-archive/web/ram/current/msg01691.html
APT } The ETR would need to do a complete, expensive,
LISP-NERD } filter operation on the inner source address
LISP-ALT } against whatever list of prefixes the ISP's
TRRP } border routers use - which could be huge in a
large ISP network.
[Q24]
To what extent would packets be delayed when the ITR has no mapping
for the micronet (EID prefix) it is part of? (Not counting
occasional failures due to lost packets in local networks.)
APT Very short - a few 10s of milliseconds I guess, since
all caching ITRs send their packets to a local Default
Mapper, with both tunnels the packet to the correct
ETR without delay, and sends back an ETR address for
the ITR to use. (Does the map reply include a
specification for the EID prefix, so the ITR doesn't
have to ask again when it gets a packet for a nearby
address which is part of the same EID? If so, then
this is good in many ways. But if so, then how well
will load sharing work, since the ITR would send
all its packets to the ITR nominated by the Default
Mapper?)
Ivip No delay if the ITR is an ITRD. Very little delay
if it is an ITRC. This depends on how close the
nearest QSD is, though a QSC may have the mapping
and respond without having to ask an upstream QSD.
A few 10s of milliseconds I guess. However, caching
ITRCs in the same rack as QSDs, connected by an
Ethernet cable or two, will get their mapping in a few
milliseconds.
Apart from potential trouble with NTP packets (which could be fixed
by the NTP client sending an initial packet to get the ITR up to
speed, and then a timing-related packet a few seconds later), I
think both APT and Ivip would involve initial packet delays which
are firstly "no problem" for end-users and secondly so low that it
would be unlikely for them to be credibly trumped up into something
which appears significant to end-users, by some anti-APT or
anti-Ivip marketing campaign.
LISP-NERD No delay.
LISP-ALT Significant delays due to the global nature of the
query system - fractional second at worst. PLUS
a significant risk of a long delay due to the
possibility of the request or reply packets being
dropped. PLUS an often much longer delay in the ALT
network than would be indicated by geographical
distance due to ALT's insistence on strong
aggregation. See: "ALT's strong aggregation often
leads to *very* long paths" 2008-01-28:
http://psg.com/lists/rrg/2008/msg00229.html and the
long discussion which followed. The closest thing
to a defence against this critique was Scott's
message "Re: Why delaying initial packets matters"
2008-03-04: http://psg.com/lists/rrg/2008/msg00584.html
and my response to this towards the end of:
http://psg.com/lists/rrg/2008/msg00791.html
TRRP Significant delays due to the global nature of the
query system - fractional second at worst. PLUS
a significant risk of a long delay due to the
possibility of the request or reply packets being
dropped. PLUS often longer delays due to the need
to perform recursive DNS queries. See: "Delays
inherent in TRRP's DNS-like lookup?" 2008-02-28:
http://psg.com/lists/rrg/2008/msg00450.html and
the discussion which followed.
[Q25]
Does the proposal have an alternative system for delivering packets
to ETRs for which the ITR currently has no mapping?
APT No - the caching ITR or the Default Mapper always
has the mapping.
Ivip No - the packet is always handled by a full database
ITR or a caching ITR which has a reliable, close
full database Query Server.
LISP-NERD No - all ITRs are full database.
LISP-ALT Yes. The ALT network delivers the packet to the.
correct ETR, where it also functions as a mapping
request.
TRRP Yes - Waypoint Routers. But see my critique:
http://psg.com/lists/rrg/2008/msg00475.html
I may think of other questions and answers and post them in later
messages.
I think all these questions are instructive in helping us understand
the commonalities and differences - and the strengths and weaknesses
- of the various proposals.
I think these questions help us build a taxonomy which will help us
better understand the problem and solution spaces.
- Robin http://www.firstpr.com.au/ip/ivip/
Note on filtering of source addresses:
Even if the end-user runs their own ETR, the ISP - or ISPs - who
provide connectivity are likely to want to ensure there is some
source address filtering on the decapsulated packets.
Without the map-encap scheme, the ISP can filter at its border
routers and so prevent any attacker (implicitly, attackers are
outside the ISP and end-user network) from sending packets into
either network with the source address spoofed to be an address
inside the ISP network.
Since it is improbable that any ETR will have the grunt to do source
address filtering on decapsulated packets according to a long list
of prefixes in the ISP's network (except in the case of Ivip, which
does it automatically, with minimal effort and without having to
know the list of prefixes to filter), the other map-encap proposals
would lead to the end-user network being wide open to packets with
spoofed source addresses.
An attacker could send a packet from anywhere to the ETR and the
decapsulated packet could have the source address of any host in the
ISP's network. This is likely to be a security concern, if only
because an attacker could prompt the destination host to send
packets to the host at that spoofed address.
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg