On Nov 25, 2009, at 1:24 PM, Noel Chiappa wrote:
......
Also, as I've mentioned before, if we are to produce _practical_
proposals, we are heavily constrained by what is already deployed, and
that limits the clarity of what we can do. Yes, with a clean-sheet
design,
one could carefully and completely separate location and identity.
However, we do not have the luxury of a clean sheet; we can only
_start_ to move in that direction.
The fact that local locators are often called "identifiers" does not
help to understand what proposals actually do.
Differing definitions here are proving to be a problem. To me,
anything
that can serve to identify one end of a TCP connection _cannot_ be a
pure
'locator', as to me, locators name interfaces, not stacks.
Similarly, to me, anything which can identify one end of a TCP
connection
is, by definition, an 'endpoint identifier'; it may have _other_
functionality as well, but its base functionality is that of an
endpoint
identifier.
Again, due to TCP's past co-mingling of the concept of 'interface
name' and
'endpoint name', we cannot (alas) get cystal pure 'locators' and
'endpoint
identifiers' in any design, _especially_ if we wish to support
unmodified
hosts.
Hi Noel, you are exactly right that if we "no change to hosts" as
prerequisite, then we would not be able to have a clean solution to
this end identifier problem.
But I do not think "no change to hosts" should be a prerequisite.
So, IMO, trying to apply these pure, theoretical terms to actual
proposals is necessarily problematic...
It is problematic only because of the "no change to hosts" prerequisite.
(personal opinion) I think we need to separate out two things:
1/ Requiring changes to (most if not all) hosts to reduce global
routing table size,
versus
2/ Requiring host changes to solve the identifier separation problem.
To me, 2/ will necessarily happen to those hosts which need the
separation.
Lixia
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
