Subject: [RRG] arguments for map and encap

From: Michael Meisel <[email-masked]>
Date: Mon, 05 May 2008 18:06:31 -0700

In their earlier post 
(http://www.ops.ietf.org/lists/rrg/2008/msg01159.html), the RRG 
co-chairs requested that we first come to a consensus on the 
"highest-level branches of the decision tree". Towards that goal, Dan 
Jen and I want to open a discussion on this issue with some arguments 
for choosing the map & encap branch.

First, some background. We know the fundamental reason that the current 
routing system doesn't scale: there is a conflict between network 
customers and their transit-network providers. It is in the interest of 
network users to have provider-independent (PI) addresses, while it is 
in the interest of network service providers to maintain IP address 
aggregatability.

So what the RRG is tasked to decide is: what changes should be made to 
resolve this conflict?

We believe that the answer is to take a path that (1) best resolves the 
conflict for the long term and also (2) provides a feasible economic 
incentive to make the changes.

1. Selecting the best long term solution.
The Internet as it stands is a great success. We want to first make 
changes that are in the best long term interest. Faced with equally good 
long term changes, we should also select the one with the highest degree 
of backwards compatibility.

2. Ensuring that parties required to make changes have incentive to do so.
For any solution that does not align cost with benefit, it may be 
possible to deploy it in a few places, but the solution will not be 
widely adopted unless the economics are on the right side.

This means we cannot expect everyone to change operations. It is 
reasonable to ask each ISP to make a big change, but only if they can 
see some appreciable benefit. Conversely, it is not reasonable to ask 
all home users to change in order to better accommodate ISPs. The 
scaling problem is perhaps felt most profoundly at the ISPs, so fixing 
the problem by making changes at all ISPs seem more reasonable. Forcing 
changes upon all network customers would need to be matched by a 
compelling gain for those customers.

Arguments for Map & Encap

For a long term solution, we believe some decoupling of the network 
customers and transit networks is necessary. The conflict over PI 
addresses is a clear example of the need to decouple. In the long term, 
it also opens up a number of new possibilities at both sides for scaling 
and routing changes in the core and techniques to exploit mapping 
service for new features at the edges.

As compared to other types of schemes, map & encap requires changes only 
to the nodes at the borders (where encap/decap occurs), along perhaps 
with a small support infrastructure. No changes are required at end 
hosts who benefit only indirectly from the change -- in fact, map & 
encap schemes can be made invisible to end users (and edge networks in 
general, if desirable).

Service providers, both large and small, are the parties that stand to 
benefit from a resolution to the conflict. Thus, they should be the ones 
who bear the burden of deployment. Thus, map & encap seems to be the 
solution that best aligns cost with benefit, as well as the best 
long-term direction going forward.

-Michael and Dan

--
to unsubscribe send a message to [email-masked] 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

---

From: <[email-masked]>
Date: Tue, 6 May 2008 17:40:32 +0300

Hello Michael and Dan

We good and thoughtful mail from you. I agree with the logic you present
here. However, there  maybe some details that you are overlooking. 

- multihoming is not only for service providers, but required by end
users/network customers. Multihoming is not only about PI addressing,
but also of the possibility to route through alternative provider and to
have a backup route. If this is the case, the beneficiary is the end
user who should bear the cost for what she/he wishes for.

- it is not all service providers who experience the routing scalability
problem. The problem seems to be more of tier 1 and tier 2 providers,
rather than the access providers. At least those access providers I have
talked about this, do not confess having such a problem. Of course we
could assume that the ISPs are going to be consolidated to bigger ones
and at this point we need to have the technology in place. But I do not
find this believable. 

Regards Hannu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of ext Michael Meisel
>Sent: Tuesday, May 06, 2008 04:07
>To: Routing Research Group
>Subject: [RRG] arguments for map and encap
>
>In their earlier post
>(http://www.ops.ietf.org/lists/rrg/2008/msg01159.html), the 
>RRG co-chairs requested that we first come to a consensus on 
>the "highest-level branches of the decision tree". Towards 
>that goal, Dan Jen and I want to open a discussion on this 
>issue with some arguments for choosing the map & encap branch.
>
>First, some background. We know the fundamental reason that 
>the current routing system doesn't scale: there is a conflict 
>between network customers and their transit-network providers. 
>It is in the interest of network users to have 
>provider-independent (PI) addresses, while it is in the 
>interest of network service providers to maintain IP address 
>aggregatability.
>
>So what the RRG is tasked to decide is: what changes should be 
>made to resolve this conflict?
>
>We believe that the answer is to take a path that (1) best 
>resolves the conflict for the long term and also (2) provides 
>a feasible economic incentive to make the changes.
>
>The Internet as it stands is a great success. We want to first 
>make changes that are in the best long term interest. Faced 
>with equally good long term changes, we should also select the 
>one with the highest degree of backwards compatibility.
>
>For any solution that does not align cost with benefit, it may 
>be possible to deploy it in a few places, but the solution 
>will not be widely adopted unless the economics are on the right side.
>
>This means we cannot expect everyone to change operations. It 
>is reasonable to ask each ISP to make a big change, but only 
>if they can see some appreciable benefit. Conversely, it is 
>not reasonable to ask all home users to change in order to 
>better accommodate ISPs. The scaling problem is perhaps felt 
>most profoundly at the ISPs, so fixing the problem by making 
>changes at all ISPs seem more reasonable. Forcing changes upon 
>all network customers would need to be matched by a compelling 
>gain for those customers.
>
>
>For a long term solution, we believe some decoupling of the 
>network customers and transit networks is necessary. The 
>conflict over PI addresses is a clear example of the need to 
>decouple. In the long term, it also opens up a number of new 
>possibilities at both sides for scaling and routing changes in 
>the core and techniques to exploit mapping service for new 
>features at the edges.
>
>As compared to other types of schemes, map & encap requires 
>changes only to the nodes at the borders (where encap/decap 
>occurs), along perhaps with a small support infrastructure. No 
>changes are required at end hosts who benefit only indirectly 
>from the change -- in fact, map & encap schemes can be made 
>invisible to end users (and edge networks in general, if desirable).
>
>Service providers, both large and small, are the parties that 
>stand to benefit from a resolution to the conflict. Thus, they 
>should be the ones who bear the burden of deployment. Thus, 
>map & encap seems to be the solution that best aligns cost 
>with benefit, as well as the best long-term direction going forward.
>
>-Michael and Dan
>
>--

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 6 May 2008 09:59:20 -0700

From: Michael Meisel [mailto:[email-masked]] 
>For a long term solution, we believe some decoupling of the network
customers 
>and transit networks is necessary. The conflict over PI addresses is a
clear 
>example of the need to decouple. In the long term, it also opens up a
number 
>of new possibilities at both sides for scaling and routing changes in
the core 
>and techniques to exploit mapping service for new features at the
edges.

I value your posting and believe that it accurately reflects the
viewpoint of many of the stake holders, including the large corporate
end user.

I am confident that you already know that the actual situation is more
complicated than you stated but I believe that your summary is generally
accurate at a semi-high level of abstraction.

I interpret your posting as building upon Lixia's and Scott's
draft-rrg-taxonomy-00.txt by suggesting that the map and encaps
alternative is the most compelling. However, I would prefer that such a
decision be based upon modeling and simulation or some other analytical
technique. While I certainly concur with your logic, I do not believe
that we yet have documented technical evidence to prefer one generic
approach over another at this time.

---

From: "Tony Li" <[email-masked]>
Date: Wed, 7 May 2008 14:58:08 -0700

Hi Hannu,

|- it is not all service providers who experience the routing 
|scalability
|problem. The problem seems to be more of tier 1 and tier 2 providers,
|rather than the access providers. At least those access 
|providers I have
|talked about this, do not confess having such a problem. Of course we
|could assume that the ISPs are going to be consolidated to bigger ones
|and at this point we need to have the technology in place. But I do not
|find this believable. 

The problem is not delineated by tiers, but by those who need to carry the
full table.  Certainly some folks choose to do so for a variety of reasons,
but anyone who finds that they must carry the full table will be impacted,
whether they know it today or not.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Wed, 7 May 2008 18:09:24 -0700

Hi Michael, Dan,

Thanks for contributing. 

|First, some background. We know the fundamental reason that 
|the current 
|routing system doesn't scale: there is a conflict between network 
|customers and their transit-network providers. It is in the 
|interest of 
|network users to have provider-independent (PI) addresses, while it is 
|in the interest of network service providers to maintain IP address 
|aggregatability.

I think that this is not a precise statement of the problem.  There are many
reasons, both technical and non-technical why end-sites want to have PI
addresses.  Further, it's clearly the service providers who are damaging
aggregatability through actions such as traffic engineering by prefix
deaggragation.  Thus, I think it's much more productive to focus on the
technical issues that need to be addressed.

Today, the technical driver that injects routes into the global table is the
use of explicit, globally-advertised prefixes for multi-homing.  Most of the
other drivers (e.g., not wanting to renumber, traffic engineering without
re-aggregation) are economically based, and not technical requirements of
the architecture.  Thus, we should be focused on dealing with the
multi-homing issue.

The crux of the multi-homing issue is that explicit prefixes are necessary
because transport protocols are tied to the initially selected address and
if that address is topologically significant, the transport is vulnerable to
topological changes.  

|We believe that the answer is to take a path that (1) best 
|resolves the 
|conflict for the long term and also (2) provides a feasible economic 
|incentive to make the changes.

You are of course welcome to your opinion, but that's not the only
perspective.  In particular, the RG is not constrained in this way.  While
it makes sense to remain relevant, economic incentives are not the only way
to ensure that particular architectures are deployed.  Did the Web get
deployed initially because of the economics?  Subnetting?  NAT?  CIDR?  BGP?
In short, there are a variety of forcing functions that can cause
deployment, and our real requirement IMHO, is to ensure that there is some
effective forcing function but it need not be economic.  Sometimes just
solving a common problem is sufficient.

|Arguments for Map & Encap
|
|For a long term solution, we believe some decoupling of the network 
|customers and transit networks is necessary. The conflict over PI 
|addresses is a clear example of the need to decouple. In the 
|long term, 
|it also opens up a number of new possibilities at both sides 
|for scaling 
|and routing changes in the core and techniques to exploit mapping 
|service for new features at the edges.
|
|As compared to other types of schemes, map & encap requires 
|changes only 
|to the nodes at the borders (where encap/decap occurs), along perhaps 
|with a small support infrastructure. No changes are required at end 
|hosts who benefit only indirectly from the change -- in fact, map & 
|encap schemes can be made invisible to end users (and edge networks in 
|general, if desirable).
|
|Service providers, both large and small, are the parties that stand to 
|benefit from a resolution to the conflict. Thus, they should 
|be the ones 
|who bear the burden of deployment. Thus, map & encap seems to be the 
|solution that best aligns cost with benefit, as well as the best 
|long-term direction going forward.

I'll just point out that to make a more convincing and balanced argument,
it's necessary to address both the positives and negatives of an approach.
Would you care to expound a bit?

Regards,
Tony

---

From: Christian Vogt <[email-masked]>
Date: Sun, 18 May 2008 21:15:55 +0300

Dan and Michael,

I would like to make the observation that, by advocating map and
encap, one actually promotes two separate concepts:

- indirection between address realms (map)
- tunneling as a means to represent indirected packets (encap)

The arguments you put forth in favor of map and encap are in fact
arguments for only the 1st concept, address indirection.  Your
arguments would still hold if tunneling (the 2nd concept) was replaced
by address translation as a means to represent indirected packets.

I hence suggest to seek consensus more generally on "address
indirection", instead of more specifically on map and encap -- and to
leave it open, for now, how to represent indirected packets.  Below I
provide more rationale for this by (i) looking at how tunneling and
address translation differ conceptually, (ii) discussing what these
differences mean in the context of address indirection, and (iii)
concluding that tunneling and address translation are both valid
alternatives.

The difference between tunneling and translation is in the amount of
information about the original appearance of an indirected packet,
that is explicitly included in the indirected packet.  With tunneling,
all information needed to reestablish the original appearance is
included in packets.  With translation, information must be looked up
from elsewhere.

Including explicit information in indirected packets avoids state at
the receiving side (where the original appearance of the packets is to
be reestablished) *if* this information is trustworthy.  Avoiding
state, in turn, increases robustness to route changes, because the
route of packets depends less on information stored on entities on any
particular route.  Robustness to route changes is clearly an
attractive property.  It is one of the fundamental principles of IP,
and should be upheld by any new routing architecture.

But is tunneling the only way to facilitate robustness to path
changes?  I argue it is not:  State at the receiver could also be
avoided by storing it in an infrastructure, thus making it retrievable
by any entity on a new route after a route change.  More generally
hence, robustness to route changes requires that...

(a)  the information needed to reestablish the original appearance of
      an indirected packet is retrievable by any network entity that is
      to perform the reestablishment, independent of the route of the
      packet, and
(b)  the source of that information is trustworthy.

Tunneling is one way to achieve (a).  Yet tunneling alone does not
satisfy (b) because it does not protect against spoofing an inner IP
header.  An extra mechanism is needed for validating the mapping
between original and indirected addresses, such as per-packet
signatures as previously proposed by Noel, or by inquiry in a trusted
infrastructure.  Per-packet signatures would come at the cost of
per-packet overhead.  Inquiry in an infrastructure would come at the
cost of delay, although the validation result could be cached so that
the delay affects at most the 1st packet in a session and the 1st
packet after every route change.  The trusted infrastructure that is
consulted for mapping validation at the receiving side could be the
same infrastructure that the sending side uses for mapping resolution.

Address translation requires mapping resolution via some
infrastructure at the receiving side to satisfy (a).  If the
infrastructure is furthermore trusted, (b) is satisfied at the same
time.  Again, this would come at the cost of delaying at most the 1st
packet in a session and the 1st packet after every route change,
assuming the resolution/validation results are cached.

Overall, this shows that tunneling (encap) and address translation are
alternatives with similar properties in terms of robustness to route
changes.  I therefore believe that limiting RRG's design space to map
and encap is too restrictive.  While I would be favorable to limiting
the design space to address indirection in general (map), RRG should
IMO continue to be allowed to consider alternatives to tunneling, such
as address translation, as a way to represent indirected packets.

Lastly, it is noteworthy that there is a continuum of methods for
representing indirected packets; pure tunneling and pure address
translation are just the two extremes.  E.g., indirected packets could
carry only their original source address in an extension header, but
not the original destination address.  This method would rely on
knowledge at the receiving side to perform the trivial mapping of the
packets' destination address.

- Christian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 May 2008 10:09:24 -0700

Christian, 

>From: Christian Vogt [mailto:[email-masked]] 
>Sent: Sunday, May 18, 2008 11:16 AM
>To: Michael Meisel; Dan Jen
>Cc: Routing Research Group Mailing List
>Subject: Re: [RRG] arguments for map and encap
>
>Dan and Michael,
>

Your analysis of (b) I think was rather well stated. Just as
examples of existing map-and-encaps schemes, ISATAP (RFC5214)
validates mappings via inquiry in a trusted infrastructure
exactly as you say. Per-packet signatures on the inner packet
are also possible, but not on the outer packet header (which
may not be necessary if the inner packet has a signature).

Additionally, VET (draft-templin-autoconf-dhcp) updates ISATAP
by introducing an expanded domain of applicability that allows
tunnel-mode IPsec encapsulation between the inner and outer IP
layers. This provides a per-packet signature that applies to
both the inner and outer layers.

Thanks for this informed post,

Fred
[email-masked]

---

From: David R Oran <[email-masked]>
Date: Tue, 20 May 2008 12:52:47 -0400

> by address translation as a means to represent indirected packets.
I assume you mean only translations whose functions are one-to-one and  
onto in a mathematical sense, and for which the inverse is trivially  
computed. Additional design considerations on translation vs.  
encapsulation are:
- wire overhead
- state overhead at the translation or encap/decap points
- are the functions recursive
- traceability, fault isolation and debug
- attack surface (assuming the same threat model)

> leave it open, for now, how to represent indirected packets.
While these things are separable in principle, I think that the  
indirection mechanisms are first-order considerations and we should  
not in fact leave this open or consider the issue separately. That's  
my opinion, anyway.

>  Below I
True, but "looked up from elsewhere" could be state that is local to  
the translation points, or held by third parties and this makes a big  
difference. Also, when you look at the control plane, there may or may  
not be an explicit state setup protocol. What this winds up looking  
like is in fact not a detail but a really important part of the design  
and hence can't be pushed off as a secondary consideration.

> and should be upheld by any new routing architecture.
This is really good - add it to my list of considerations above.

> (b)  the source of that information is trustworthy.
As long as there are no circular dependencies, and that you build  
delay and possible quarantining complexities into the equation.

> per-packet overhead.
there could also be a protocol which establishes trust in an  
encapsulator. That way, although an encapsulator taken over by the  
enemy could inject packets spoofed from anywhere, you have a handle to  
use to damp an attack.

>  Inquiry in an infrastructure would come at the
Generally router folks cringe if you need to quarantine packets. This  
of course brings up the whole "how bad is dropping" discussion, which  
at the RRG meeting produced a lot more heat than light.

> assuming the resolution/validation results are cached.
There is a difference between quarantining and sending the packet on a  
sub-optimal path. Do you think this deserves highlighting?

> as address translation, as a way to represent indirected packets.
I see no problem with considering both seriously, but have misgivings  
about analyzing translation versus encapsulation independently of  
mapping.

> packets' destination address.
Good points. Just as there are continuums in the mapping part between  
pure push and pure pull, and between directory-based and overlay  
topology based mapping.

DaveO.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 21 May 2008 22:34:45 +0300

Hi David -

> computed.

At this point, I was deliberately talking about translation in
general, be it 1-to-1 or 1-to-many.  But yes, we are in complete
agreement that 1-to-1 translation is advantageous.  I was coming to
that later in the email, when talking about robustness to path
changes.

In this spirit, I am currently modifying Six/One Router to use
1-to-1 translation.  Address translation as used in Six/One Router
then differs from classic NAT boxes in two main aspects:

- Global host reachability -- Hosts behind a classic NAT box cannot
  be contacted from hosts on the other side of the NAT box because
  they use non-unique addresses.  Differently, hosts in Six/One-
  Router-capable edge networks use globally unique edge addresses.
  So they can be contacted from hosts elsewhere in the Internet.

- Robustness to route changes, as previously discussed -- Classic NAT
  boxes limit a network’s ability to reroute traffic in case of path
  failures because they build up dynamic state that communication
  sessions depend on.  The reason for having that state is that NAT
  boxes multiplex multiple host addresses onto a single translated
  address.  They need the state to perform the reverse operation,
  the demultiplexing from a translated address onto the correct host
  address.  With 1-to-1 translation, Six/One avoids address
  multiplexing, so rerouting between different paths is not a
  problem.

One may even claim that 1-to-1 translation between globally unique
edge and transit addresses does not break end-to-end semantics (though
this is clearly a personal opinion).  What is commonly associated with
"end-to-end semantics" is that the addresses that a packet receiver
sees are the same as the addresses the packet sender has used.  But
specifically and architecturally, what advantage does this have?
(...Other than not confusing protocols that have been build on the
assumption that addresses do not change in flight.)  Isn't the true
meaning of end-to-end semantics covered by global host reachability
and robustness to route changes, as long as there is a working route?

> Additional design considerations on translation vs. encapsulation are:
> - wire overhead

Yes, excellent.

> not in fact leave this open or consider the issue separately. That's

No problem.  What I meant was that we shouldn't limit ourselves to
tunneling without discussing the alternatives.  Didn't mean to suggest
postponing the discussion -- although, re-reading my own text, I
certainly was unclear in this regard.

> and hence can't be pushed off as a secondary consideration.

Oh yes, fully agree.

One observation that may be input to this discussion is that the
requirements in things address mapping are very similar for the sender
and the receiver, yet the solution spaces are different.

Regarding requirements, sender and receiver both need access to
address mapping information that provably originates from the owner of
the edge address ("identifier") in the mapping.  The sending host
needs it to accomplish the edge-to-transit mapping of the destination
address in a packet; the receiving host needs it to validate the
transit-to-edge mapping of the source address in the packet.

The solution space for the sender coincides with the solution space
for mapping resolution systems (including systems that can route
packets based on identifiers via a sub-optimal path).  The solution
space for the receiver is a true super-set of this.  In addition to
re-using the mapping resolution system for the purpose of mapping
validation, it also includes in-packet information, such as the edge
addresses in inner tunnel headers.  Either way, the mapping must
provably originate from the owner of the edge address.

> delay
> and possible quarantining complexities into the equation.

By "quarantining", do you mean buffering?

> encapsulator.
> That way, although an encapsulator taken over by the enemy could  
> inject
> packets spoofed from anywhere, you have a handle to use to damp an  
> attack.

Yes.  You could use ALT for this -- by adding an unguessable nonce to
the request packet, and requiring the mapping response to echo this
nonce back.  Such "routing based on identifiers" is exactly what
Mobile IPv6 does during a home address test (exchange of Home Test
Init and Home Test messages), or what DNS does by traversing a tree of
administrative relationships.  Although neither Mobile IPv6 nor DNS
piggyback their requests onto datagram packets.

> sub-optimal path. Do you think this deserves highlighting?

This is correct, but note that routing based on edge addresses (via a
sub-optimal path) is an option only for the sender.  The receiver
doesn't have this option when it comes to validating the mapping for a
received packet.  (Of course, the receiver could use the "sub-optimal
path infrastructure" in order to validate a mapping.  But this would
alleviate it from having to buffer the packet in the meantime.)

> about analyzing translation versus encapsulation independently of  

Yep, as noted above, this would in fact be completely alright with me.

Thanks for this nice discussion!

- Christian

---

From: David R Oran <[email-masked]>
Date: Wed, 21 May 2008 16:11:30 -0400

> By "quarantining", do you mean buffering?
Quarantining is a special form of buffering where you need to  
rendezvous the buffered packet(s) with a particular set of state which  
arrives asynchronously and possibly delayed by a significant amount.  
This is not nearly as simple as buffering for ARQ-like protocols, or  
for QoS purposes. It's in the same class IP fragment reassembly in  
that there is a whole class of state-based attacks that need to be  
considered as well as the inability of any hardware-based forwarding  
scheme I know of to handle this without punting to a control plane.  
Some protocols, like ARP, ussually do quarantining in hosts, but  
dropping in routers.

I suspect you and the rest of the folks on the list know this :-)
I'm just emphasizing that when a scheme needs this, it is a whole lot  
more complicated and expensive than simple buffering.

DaveO.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 May 2008 16:34:10 -0700

Dave, 

>From: David R Oran [mailto:[email-masked]] 
>Sent: Wednesday, May 21, 2008 1:12 PM
>To: Christian Vogt
>Cc: Michael Meisel; Dan Jen; Routing Research Group Mailing List
>>>> (a)  the information needed to reestablish the original 
>appearance  
>>>> of

I'm not quite seeing this as in the same class as IP fragment
reassembly; IP reassembly is like putting together a patchwork
quilt based on whatever oddly-shaped scraps the network throws
at you. But, if every component is identically sized and shaped
its as easy as stacking coins. Routers have been doing that
in fast path since the ATM days, haven't they?

Thanks - Fred

---

From: "Tony Li" <[email-masked]>
Date: Wed, 21 May 2008 19:21:55 -0700

Fred, 

|>Quarantining is a special form of buffering where you need to  
|>rendezvous the buffered packet(s) with a particular set of 
|>state which  
|>arrives asynchronously and possibly delayed by a significant amount.  
|>This is not nearly as simple as buffering for ARQ-like protocols, or  
|>for QoS purposes. It's in the same class IP fragment reassembly in  
|>that there is a whole class of state-based attacks that need to be  
|>considered as well as the inability of any hardware-based forwarding  
|>scheme I know of to handle this without punting to a control plane.  
|>Some protocols, like ARP, ussually do quarantining in hosts, but  
|>dropping in routers.
|
|I'm not quite seeing this as in the same class as IP fragment
|reassembly; IP reassembly is like putting together a patchwork
|quilt based on whatever oddly-shaped scraps the network throws
|at you. But, if every component is identically sized and shaped
|its as easy as stacking coins. Routers have been doing that
|in fast path since the ATM days, haven't they?

In part, you are correct.  The quarantining that Dave mentions need not
reorder the incoming flow.  However, it must effectively buffer the entire
flow for a considerable amount of time.  Typically routers have fast-path
buffering today that is on the order of 50-400ms.  Depending on the actual
mechanisms involved to resolve a mapping entry, I'd posit that one might
need to quarantine traffic for up to 10x that amount of time.  This should
be on the same order of magnitude as resolving a DNS query.  Storing full
flows in active components would be VERY expensive and even the aggregate
bandwidth into disk arrays would be non-trivial.

This is, in part, why I very much liked the idea of putting mapping lookups
in parallel with DNS lookups: if you can resolve the mapping prior to the
data flowing, then this issue is reduced.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 May 2008 15:27:25 +1200

Christian,

On 2008-05-22 07:34, Christian Vogt wrote:
...
> and robustness to route changes, as long as there is a working route?

It's true that there has been a historical assumption that "an address
is an address is an address" and that this has become the essential
implement in applying the end-to-end principle (which was written
down in 1984 [Saltzer] and resurrected in RFC 1958). Afaics, the
essential requirement to apply the e2e principle is an identifier
that asserts that a given packet belongs to a given packet stream.
Given that, the end system doesn't care about any aspect of the
network at all. But we can't avoid the fact that the identifier used
by the vast majority of software is the bitstring known as an address
in the socket API. You can do what you like below the transport layer
as long as you deliver that bitstring. In the real world, we can't change
that (which is why NATs are such a mess, of course).

I don't see any realistic way out of the rule of delivering the address
bitwise as sent. You're completely correct that this does not
mathematically require encapsulation (shim6 is a counter-example).

    Brian

[Saltzer] End-To-End Arguments in System Design, J.H. Saltzer,
   D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp
   277-288.

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 21 May 2008 23:43:44 -0700

catching up this thread ...

> user who should bear the cost for what she/he wishes for.

there might be a slight misunderstanding here: Michael's original msg  
meant to say that *user site* multihoming is among main drives of BGP  
routing table growth (alternative paths and backup paths are all  
benefits from having PI prefixes).
a scalable routing system is to solve a problems facing service  
providers today, thus they would be willing to deploy the solutions.

> and at this point we need to have the technology in place. But I do  

I agree with TOny's reply here, the concerned parties are whoever  
carrying the full table.

Lixia

---

From: Christian Vogt <[email-masked]>
Date: Thu, 22 May 2008 20:06:17 +0300

> that (which is why NATs are such a mess, of course).

Brian -

I fully agree that both sender and receiver need a stable identifier for
packet exchanges.  But stability does not necessitate that the  
identifier
be the same for the sender and for the receiver.  NATs demonstrate this.

Of course, I do understand yours and many other people's concerns about
NATs.  My stance, however, is that the hard problems with NATs are due  
to
their limitations in global host reachability and robustness to path
changes.  The mere fact that an address looks different on different  
sides
of a NAT is much easier to deal with.

- Christian

---

From: David R Oran <[email-masked]>
Date: Thu, 22 May 2008 14:34:00 -0400

On May 22, 2008, at 1:06 PM, Christian Vogt wrote:

> NATs.  My stance, however, is that the hard problems with NATs are  
> due to
Except for traceability, fault isolation, etc., not to mention latency  
of state-reestablishment after a crash in the absence of an explicit  
control plane state establishment protocol, etc.

---

From: "Tony Li" <[email-masked]>
Date: Thu, 22 May 2008 11:48:31 -0700

|Except for traceability, fault isolation, etc., not to mention 
|latency  
|of state-reestablishment after a crash in the absence of an explicit  
|control plane state establishment protocol, etc.

Dave,

Wouldn't those issues be reasonably address if the mapping was stable enough
to be cached in stable storage?

Tony

---

From: David R Oran <[email-masked]>
Date: Thu, 22 May 2008 14:55:41 -0400

> to be cached in stable storage?
yes, assuming people don't do really stupid things like create zombie  
state, or worse flood it back into the routing system after a box has  
been down for a long time.

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 22 May 2008 22:16:39 -0700

On May 7, 2008, at 6:09 PM, Tony Li wrote:

> use of explicit, globally-advertised prefixes for multi-homing.

Yes.

>  Most of the

To be a bit more precise: a specific TCP connection can be vulnerable  
to topological changes during its lifetime.

> solving a common problem is sufficient.

the above cited examples, Subnetting,  NAT, CIDR, and BGP, seem to all  
have shared a common effective forcing function: the pressing need.
and changes happened at the place which felt the most pressure.

If we try the same token here: the pressure for needing scalable  
routing is felt by the parties carrying the full routing table, and  
probably not by TCP connections which enjoy the use of PI prefixes.

> Would you care to expound a bit?

Well said.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 22 May 2008 22:25:11 -0700

On May 6, 2008, at 9:59 AM, Fleischman, Eric wrote:

>> addresses is a clear
>> the core and techniques to exploit mapping service for new features
>> at the edges.
>

I believe that Michael's initial message on this thread was meant to  
start the discussion on that "highest level of branch" decision, and  
not to declare a decision.

Lixia

---

From: Christian Vogt <[email-masked]>
Date: Fri, 23 May 2008 09:48:37 +0300

On May 22, 2008, at 21:48, Tony Li wrote:

>> Except for traceability, fault isolation, etc., not to mention
>> latency of state-reestablishment after a crash in the absence
>> of an explicit control plane state establishment protocol, etc.
>>
>
> Wouldn't those issues be reasonably address if the mapping was
> stable enough to be cached in stable storage?

Or if the mapping was stateless, i.e., 1-to-1?

Traceability, fault isolation, etc., would also be mitigated by
1-to-1 mapping.  Especially in IPv6, where the mapping could be as
simple as a prefix exchange.

- Christian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 May 2008 11:44:08 +1200

> simple as a prefix exchange.

Don't forget that the address is today also an essential part of
the data for a cryptographic protection of an end to end session.
In that role it could of course be replaced by some ID inserted
at a level above IP (as it is in IPSEC over UDP, in effect), but we
have to provide that at the same time as architecturally removing
e2e addressing. And if you do that *except* by inserting an alternative
32 or 128 bit e2e quantity that looks just like an IP address, you create
unthinkable amounts of disturbance to upper layer running code.

   Brian

---

From: Michael Meisel <[email-masked]>
Date: Mon, 09 Jun 2008 23:43:17 -0700

Hi everyone, sorry for our delayed response...

 > Would you care to expound a bit?

Well, the most obvious issue with any map & encap proposal is that
there must be a way to perform a mapping resolution, which means that
there must be a way to maintain many, many mapping entries.  This is a
very hard problem, usually solved by making some significant changes to
the Internet, such as creating a new infrastructure, modifying an 
existing one (such as DNS), or modifying a significant amount of nodes 
on the Internet.

There are probably other problems with map & encap schemes, and we were 
hoping that others would chime in on both the negative and positive 
aspects of such schemes (some people have done this).  Our post was only 
meant to open up a discussion about the highest level of the decision 
tree and voice an initial opinion.

-Michael and Dan