OK, I'm not the architecture monitor, but I disagree with some of
this, and agree with the rest...
:-)
In the case of HIP BONE, the peer (or routing) protocol is both a
user of HIP and an enable of HIP. But so are the routing
protocols for IP, and in certain sense DNS for IP, too.
OSPF does use IP *encapsulation*, *fragmentation/reassembly*, etc.
but OSPF conversations happen with direct adjacencies. Using IP
*encapsulation* is very different from using *IP*.
Exactly. And that is very much how HIP would be used in HIP BONE for
creating connectivity between peer nodes that are adjacent according
to their finger (or whatever routing) tables. In that case the peer
protocol is a user of HIP for encapsulation, security, mobility,
multi-homing, and NAT traversal, but not for directly forwarding
signalling messages from one overlay node to another.
In the case of routing initial HIP signalling messages for creating
direct peer-to-peer connections, HIP is then a user of the peer
protocol, the peer protocol being an enabler for HIP.
IS-IS runs directly over link-layer protocols ("same level as CLNS").
I know. Did you intentionally leave out e.g. BGP which does use both
IP and also TCP? :-)
DNS looks like a IP enabler to applications that are trying to use
DNS names, but it's not - IP ran for years before there was a
naming system at all (see HOSTS.TXT).
Such a circular dependency in itself is not bad, as long as it is
designed (i.e. not accidental) and we have a clear understanding
how to manage the bootstrap problem.
I would agree with both points here - design and understanding are
what's needed, and being able to bootstrap would be the first test
that we have a design and understanding.
I couldn't agree more. Personally, I don't see any big problems in
bootstrapping. The only bigger problems I see are related to
supporting multiple name spaces aka multiple overlays and allowing
nodes to participate to a number of them same time. There I see at
least three or four approaches, and I have big difficulties in
understanding the tradeoffs, as I don't understand the requirements
or scenarios well enough.
--Pekka
_______________________________________________
P2PSIP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/p2psip
