Subject: Re: [rrg] Map and Encaps

From: [email-masked]
Date: Thu, 27 Nov 2008 05:46:47 EST

In einer eMail vom 27.11.2008 10:13:14 Westeuropäische Normalzeit schreibt  
[email-masked]:

Put  another way: I see the strong appeal of a recursive architecture and  I
embrace that portion of the goal.  However, all recursion starts  with a base
case, and it troubles me that the host cannot be an element of  that base
case.  It implies that the base is flawed and has  limitations in its
functionality.  Noel likes to say that the measure  of an architecture is its
ability to adapt to new requirements that are not  yet forseen.  What new
requirements will arise in the base  architecture where the fundamental lack
of host participation will cripple  us?

I like all of this email - not just the above copy.
Because my own concept starts out from a hierarchical topological  network 
view I wouldn't have a fundamental size problem in case the hosts  should also 
be part of the viewed topology (being stubs or non-stubs in case of  
multihoming). Nevertheless it takes some new thinking and some work to include  the 
hosts/residential stub routers.
 
Therefore my question: 
What are the reasons or why would it be favorable to include them in the  
topology ?
 
I would be grateful to learn about these reasons.
 
Heiner

_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 27 Nov 2008 10:04:57 -0500 (EST)

> From: "Tony Li" <[email-masked]>

    > My concern is that if we turn towards map-&-encap solutions, where we
    > can no longer actually run hosts in the native Internet architecture
    > (i.e., without encapsulation), we have, in some sense, fundamentally
    > given up on the ability of the host to act as a first class element in
    > that architecture. Instead, it must now be shielded, protected from
    > reality and encased in its private bubble of non-reality.

Good point.

I'd always envisioned a slightly different approach from 'map & encap',
perhaps 'transliteration' would be the name for it, where the entry edge
device (the one that normally did the 'encap' operation) instead 'translated'
the old-style packets into a 'second-generation' format that had richer
semantics (e.g. it could hold both an EID and a locator). At the far end,
unmodified hosts would be 'supported' by a 'de-transliterator' (the same edge
device that normally did de-capsulation) which would transform the second-gen
packet back into a first-gen packet for unmodified hosts.

Modified hosts, ones that understood the new format, wouldn't need the
services of a 'transliterator' (if the source) or a 'de-transliterator' (if
the destination), and eventually (oh happy day!) new-style packets would flow
directly from upgraded host to upgraded host.

We can get there through a 'map & encap' development stage _if the protocol
the edge boxes use to carry encapsulated packet around_ has a type field
which can say (roughly) either 'encapsulated old-style packet' or
'transliterated packet'; that allows a slow upgrade of edge boxes which can
only do encapsulation to edge boxes which can also do transliteration.

Yes, it's slow and painful, but with a supertanker network, all changes are
necessarily slow and painful, neh?

	Noel