On Wed, 20 Dec 2000, John Stracke wrote:
> > Why don't you read the I-D
>
> I did.
Then you'd see that the invisibility refers to that of the server
host, as follows: The client sees only the service name binding
in the form of the URL, but what it gets as the data path is
a virtual path (or LSP) handle. Since the label changes at each
hop, the path index visible to the client host relates only to
its own handle or file descriptor for the path, and is not
enough to identify the server host. (The server host gets revealed
only if there's only one hop.)
----
Obscurity would mean that a unique server host address exists but
is not advertised.
Invisibility means that a unique server host address does not exist
at all. This is a harder condition.
----
If my approach is implemented *in addition to* end-to-end IP, you
do get compromised because the IP layer supplies the host address.
But the defect would be due to the IP layer, NOT my framework,
which is happy as long as it can do MPLS end-to-end for transport.
In particular, one does not need IP per se under my framework, and
in that aspect, one can continue to use the higher IP protocols,
like TCP, UDP, SCTP, etc. e2e because they'd run on top of the
virtual path endings.
One question that was unclear till the IETF meeting was whether these
higher protocols could indeed be fooled to work independently of IP:
the proof of principle exists - in Cheritan's Triad project at Stanford,
the 32 b IP address is faked in similar fashion. Incidentally, Triad
was substantially what I had initially proposed within IBM in 1995-1996,
and we didn't see it as being of more than academic interest
at that time.
best regards,
-p.
