Charlie,
On 1/23/2015 11:25 AM, Charlie Perkins wrote:
Hello Joe,
On 1/22/2015 4:25 PM, Joe Touch wrote:
...
The doc starts off on the wrong foot by introducing a new term for
reachability - "detects"? IP doesn't "detect" anything; it
communicates between IP addresses. Either they're reachable or not.
Reachability for L2 subnets is determined by ARP or an emulated
equivalent.
Well, that term "reachable" is itself debatable, as discussed in the
document.
It really isn't unless you're being anthropomorphic, and that's not useful.
Connectivity is all that matters, and it's either simplex or duplex,
single-point or multipoint, etc.
In fact the ambiguity surrounding "reachability" was a
motivating factor for writing the document. We thought that "detect"
was a term easily understandable by the intended audience, and up
until now it seems that the document is pretty unambiguous using
that term. The document does not suggest that IP "detects" packets.
Is there an effect you cannot state in terms of existing descriptions of
L2 links?
i.e., simplex/duplex, single-point/multipoint?
Note that links* always exist, whether they're up or down; having links
whose up/down state varies over time is already part of exstingn
descriptions too.
*"link", to L3, means something that provides communication between two
L2 endpoints. It has nothing to do with how many hops that takes at L2.
...
After reviewing PILC, I find that there is not much overlap with our
draft.
If you're expecting the same kind of obscure terminology, there
wouldn't be.
Many terms in common use have been found to be ambiguous, so
unambiguous terminology is then naturally less common. But "obscure"?
Anthropomorphic at best.
Can you suggest some unambiguous terminology that would be preferable?
See above.
What you're describing is an unstable set of unidirectional L2 paths,
and you want to call that an L2 network. It isn't.
We very definitely do *not* want to claim it is an L2 network.
Then what is it? A set of L2 networks? Those are interconnected by what
L3 calls routers.
I agree that PILC doesn't address unidirectional links, but most of IP
doesn't either. Unidirectional links inhibit most Internet protocols.
This is precisely our point. For people that want to design Internet
protocols that work well, the effects in the draft have to be kept in mind.
What exactly would you do with an endpoint that was reachable only as an
L3 destination?
Is that the only issue? Then what you're talking about is "how to model
source-only or sink-only hosts in the Internet" - note I was able to say
this without needing any reference to a L2.
However, I think those are a bit useless, from the standpoint of
fundamental communications. Once there is loss, they become irrelevant
because you don't know whether anything in either direction ever gets
anywhere.
If you're talking about nodes that are sometimes connected in one
direction then later connected in the other, that's just long-timescale
changes to links that affect communication - there's a whole area of
work addressing that (DTN).
So if that's where you're going, it'd help to explain what you hope to
accomplish other than saying "don't try to use most Internet protocols
here".
We are trying to encourage better designs for Internet protocols,
and equally well to encourage improvements for existing protocols
to enable them to run over such (multihop) networks.
Can you explain how your net is different from:
a) source-only or sink-only nodes
(which aren't relevant in a comm system)
b) DTN
?
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
