Part of my difficulty with the question is taht it presuppose that a
system problem can be reasonably addressed by a compartmented
recommendation.
If we could pretend that, then our recommendation would be "stop using
PI addresses." Of course we would ahve to include the codicil "Don't
bother me with reality."
In purely technical terms, that suffices. Obviously however, that is
not a useful answer. It may well be that a combination of stack
identifiers (treated opaquely by routing and addressing), multipath TCP
support, better Internet layer support for renumbering, and maybe a few
other changes in other places, would actually be the right architectural
end point.
And it may well be that we can create tunneling and other border
techniques that will help get us there.
But for those to be the right answer it ought to be because in addition
to solving short term problems, they help us get to the right long term
answer.
Yours,
Joel
Scott Brim wrote:
William Herrin allegedly wrote on 12/03/2009 3:29 PM:
On Thu, Dec 3, 2009 at 10:20 AM, Scott Brim <[email protected]> wrote:
William Herrin allegedly wrote on 11/21/2009 8:41 AM:
If we'd like them to carry a
decoupled session ID in every packet and deal with it successfully
when the IP address for a particular flow changes unexpectedly, we
might want to mention that before they finish.
Do you think routing and addressing requires a session ID in every
packet? If not, let the upper layers find their own solutions -- e2e
argument and all that.
Hi Scott,
Yes, I do think every packet needs a session ID, for much the same
reason that every packet has to have an IP address even if it's only
to a host on the local LAN that you could reach with only it's MAC
address. Any time the transport protocol relies on the IP address for
non-routing functions, it places a constraint on the structure of
routing system that isn't otherwise there.
I guess I should have phrased my question differently. What I wanted to
stress was "Do you think ROUTING AND ADDRESSING requires a session ID"
etc. That is, is this something that must be in a routing and
addressing architecture recommendation?
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
