Le 26/01/2015 19:31, Joe Touch a écrit :
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.
Maybe we should document what is fate-sharing with routing protocols
(ref.) and tell how MANET routing protocols don't really do fate-sharing
when applied in a WiFi ad-hoc mode network.
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).
I agree routing protocols dont need reliable links. When a link flaps a
routing protocol declares it as off.
There are some gray zones in which links are characterized by their
bandwidth instead of on/off (OSPF). But there are no metrics which
characterize wifi links as this draft characterizes them.
E.g. a metric 'link ends kind' could value 1 if both its ends where
hidden terminals, 0 otherwise.
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.
I work in these environments. I know they are different than wired,
even though maybe not magic.
The problem with MANET routing protocols is that they try to accommodate
all possible kinds of networks made of wireless links, with purely
arbitrary mouvement patterns.
Whereas most wireless links are designed with particular topologies and
use-cases in mind. There's not a single 'universal' wireless link.
Some apps are possible on some links and other apps on other links.
That said, I still think a draft about the peculiar behaviour of WiFi,
especially in ad-hoc mode, is worth documenting, because it has
implications on other protocols.
Of course its contents and potential recommendation should be agreed on.
Alex
That has still not proven to be the case.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
