Hello Joe,
Follow-up below...
On 1/23/2015 1:27 PM, Joe Touch wrote:
Charlie,
...
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.
Yes - it can, and does, fill books, and it's not a useful point to try
to summarize in an RFC.
Of course we are not trying to summarize why older protocols
don't easily work in the environment where nodes exhibit the
effects described in the draft. We are simply trying to point out
that the effects do matter, and are worthy of consideration when
designing IP protocols.
I'm struggling to find out what you want to do other than make us all
understand that what you want to do is really hard, that it makes IP
hard, and that you haven't explained it yet.
IP does work over these node populations (I have to be careful
not to use "network" in that clause if it might be misinterpreted
as in earlier emails). The result of IP working over such a population
of nodes is an IP network. We don't way it's hard, we say you have
to be careful.
Let's focus on the hidden receiver problem. So? It's reachable from
some nodes but not others. If it's truly hidden to the point where
it's only a sink, then that's what it is (and we've already discussed
why this isn't the primary concern here).
Check.
If not, then other nodes can relay traffic to it. Yes, that's hard.
Yes, that requires complicated routing. And yes, that's entirely a
problem within a single L2 *IF* it can be solved there.
In context, I am not quite sure what you mean by "a single L2". Regarding
sink nodes, the main problem is that by definition they can't provide much
protocol signaling with other nodes. Somehow that doesn't seem relevant
here, though...
If it cannot, but that sort of bidirectional reachability can be
solved using a L3 relay, then that's an L2VPN.
Well, I don't recall very much fixation on sink nodes in ad hoc networks
even though they could certainly exist. And, I really doubt that L2VPN
would work for ad hoc networks or other cases involving nodes exhibiting
the effects described in the draft.
Is there a third case here? The only one left is a network that you
can't fix inside L2 and can't be fixed with L3 relay. That's just
"disconnected" and there's no need to fix it.
We are not offering fixes. We are offering a description of some common
effects in wireless multihop networks which matter when designing protocols.
If you have a problem that isn't described above, it is you who need
to describe it. The burden of proof is on you to explain what's new.
What's new is collecting together these important matters
into a document that can be helpful. The lack of such a document
motivated the writing of the draft under discussion. Our indication
that it was needed came from experience in other working groups.
The rest of us (broadly speaking) already know what's not.
It seems to me that proposing L2VPN as a solution for ad hoc
networks (and probably other examples) is an example to show
that the document is needed. But maybe L2VPN has evolved
beyond VPN use cases. I'll have to check. Besides that, there are
other people who have encouraged us to produce this document,
and so I infer that some people see the need.
Regards,
Charlie P.
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
