Hello Joe,
On 1/22/2015 4:25 PM, Joe Touch wrote:
We aren't claiming that the effects described in the draft are new.
But they are relevant to IP.
I'm baffled as to how.
O.K... it would be more accurate to say that the effects are
relevant to people interested in designing protocols that run
over IP.
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. 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.
And IP doesn't care whether L2 had to forward or store that message as
part of that delivery. It simply is irrelevant to L3.
Well, again, you are correct that my email ascribing "caring" and
"relevance" to IP was slightly inaccurate.
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"?
Can you suggest some unambiguous terminology that would be preferable?
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.
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.
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.
And, our message is not as quoted. Instead, the message is "It is O.K.
to design Internet protocols here, but please keep these points in mind".
In fact, we do not propose any techniques for dealing with the
problems. Our intended scope is far, far narrower than the broad
scope of PILC.
It would help if you would start by using existing terminology and
explaining what you hope to achieve in this document - IN the draft
itself.
That is exactly our goal. I hope you can suggest ways that we can
do that.
Regards,
Charlie P.
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
