> From: "Tony Li" <[EMAIL PROTECTED]>
> 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
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
