Hello Joe,
On 1/23/2015 12:54 PM, Joe Touch wrote:
Charlie,
Regarding anthropomorphisms to avoid, they include:
detect
Non-human devices do "detect" signals. Many radios have
been built using "detectors",whatever. See:
http://en.wikipedia.org/wiki/Cat%27s-whisker_detector
reaches
hears
We use these as examples of terminology that has been used,
but we don't recommend them as an unambiguous terms.
The term you should be using is "can transfer an IP datagram to".
Isn't that pretty verbose? I'll see if I can work with it, thanks for the
suggestion...
Regarding other things to consider before assuming this is a new problem:
L2VPN
We are definitely not dealing with VPNs.
DTN (which is more than about delay)
if your delays/disruptions are brief enough,
that's covered by existing dynamic routing
Well, the dynamic routing protocols haven't been suitable
for ad hoc networks for various reasons. That discussion
could fill volumes. Much of the reason is because they do
not easily handle the problems outlined in the draft. That's
a terribly long discussion.
Well, in [manet] we are dealing with routers to establish multihop
connectivity between endpoints.
That's an L2VPN.
At the L2VPN layer, you're using L3 to transit L2 between disconnected
islands of reachability. L2 frames between those islands are carried
inside L3 packets that go over L2.
When you run IP over that, IP thinks it's a single L2 subnet.
We don't propose that an ad hoc network is a single L2 subnet,
and I'm pretty darned sure that L2VPN would not work for them.
Similarly for other networks as mentioned. Have you looked at
ad hoc networks? Please do, and see if you think L2VPN would work.
(to repeat) In order to claim there's something worthwhile here, you
need to explain how what you're doing hasn't already been addressed in
existing RFCs.
I don't know of any RFCs that do describe these problems,
that's just the point. Sorry if you feel this is repetitious...!
I am trying to be responsive to your discussion.
Regards,
Charlie P.
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
