On 1/26/2015 9:17 AM, Dearlove, Christopher (UK) wrote:
Joe Touch
802.11 has a problem when *L2* reachability signals don't translate to
L3 reachability. RFC6130 gets around that by using control messages that
are sent inside L3.
Actually that's not the whole story for IEEE 802.11.
Let me be more clear.
The whole story for IP (L3) is:
(A)- an L2 subnet is *defined* as a L2 network in which
every endpoint can reach every other one
(directly or indirectly)
(B)- any group of L2 nodes that does not have property (A)
is a set of one or more L2 subnets.
(C) - Those subnets can be internetworked using L3 (routers)
ONLY where they overlap (i.e., share a node).
Unless you have some sort of filter in place, if HELLO in IP gets there
then IP gets there.
Nor is that. If you care (but this is an aside from the point here) I'd Google about the
802.11 "grey zone" problem.
But in the general case, ignore that.
Agreed; that problem is one where the routing protocol doesn't
fate-share the regular IP datagram path, and that's also a well-known
problem.
Some routing protocols assume bidirectional communication, i.e., if you
can send an IP datagram to me then I can send one to you. But that's
only a subset of routing protocols; routing protocols that support
unidirectional links have also been around for a long time.
In a MANET, they are definitely not the easiest things to do with any degree of
reliability.
Routing protocols don't need reliable links. The reliability of E2E
paths does depend on a variety of properties, and certainly maintaining
E2E reliability with wildly fluctuating links is a problem, but it is
addressed by using a different routing protocol (at best).
Joe Touch
>> You find them using local broadcast.
The PILC doc explains why this is a bad idea unless L2 is known to
support broadcast. The L2 you're describing fails that assumption.
Which L2 I'm describing? I haven't described an L2. (I made an aside
about 802.11, which actually does support local broadcast, so you can't
mean that.)
(I should have said "the L2 described in the draft")
The RFC implies that control reachability implies IP reachability.
No, it really doesn't for routing purposes (e.g. RFC 7181 - RFC 6130
is not itself a routing protocol).
It does as described in RFC6130. That doc makes no mention of the 802.11
gray zone issue of using a different encoding.
Again, it's well-understood that routing protocols need to fate-share
reachability of IP data packets. That's the assumption behind the
section I cited (HELLOs go in IP packets; if the HELLO gets there, an IP
packet got there).
> Because A can locally broadcast and
it reaches B, who A may not even know exists, does not make a unicast
link A to B useful.
I said "The RFC implies that control reachability implies IP
reachability." I didn't say that resulted in bidirectional reachability
- that's for a routing protocol to determine based on unicast discovery.
(though RFC6130 isn't quite a full routing protocol; it's just the
discovery portion)
It does not imply that unidirectional reachability implies bidirectional
reachability. When B receives a HELLO from A, then B knows it can get IP
datagrams from A (that's a leap that the doc makes because it HELLOs are
sent inside IP datagrams).
It knows it can get locally broadcast IP datagrams from A. Not sufficient.
Agreed - 6130 isn't a full routing protocol; the full protocol is
required to take the *unidirectional* reachability of 6130 and determine
bidirectional reachability.
It might help us understand what you want to do if you just say it:
You realise I'm not an author of the current document? I'm just
pointing out you're missing things when you're attempting to say
"nothing new here, all completely understood". We have experience that's
not so.
So far, "your" experience (you, the authors, the MANET community) keeps
asserting that there's something magic about that environment that the
Internet architecture and protocols haven't considered.
That has still not proven to be the case.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
