Le 20/01/2015 18:33, Joe Touch a écrit :
On 1/20/2015 9:18 AM, Alexandru Petrescu wrote:
Le 19/01/2015 22:45, Joe Touch a écrit :
+1
A link layer that cannot reach all its members isn't a link
layer - it's multiple link layers that need interconnection.
That's what routers are for.
I agree.
But we have no document that tells that a Router must have two
interfaces,
That's because that requirement does not exist.
A router can exist with one interface, e.g.:
- to forward between devices on the same subnet forwarding involves
both outgoing interface AND destination IP
That leads to undetermined and 'disconnected' subnets as long each
machine in it IP routes. And prefixes are off-link (RFC number).
- to perform filtering in the process of forwarding e.g.,
Right, but filtering should come after the subnet is established.
[...]
and hence Routers with 1 interface are built and hence the
confusion of 'multi-hop' which needs a clarification in the form
of the statement you put above.
In L3, hop is always to an IP address.
YEs, but the problem is when L3 and L2 are mixed by 1-interface routers
making up L2 subnets: two nodes in range are 1-hop away from each other,
be it a MAC hop or an IP hop. But when out of range they're 2 IP-hops
from each other, although they're still 1 MAC-hop away.
At this point it's hard to distinguish multi-hop from single subnet.
It never corresponds 1:1 to a subnet link unless the link is
unicast.
Full multihop reachability is common in link layers that are
complete.
Again, it'd be useful to show something the RFCs haven't already
described. Otherwise this would be better served by a
collection of existing approaches.
I think that's the only draft that describes the hidden terminal
problem in wifi environments.
Hidden terminal in Wifi is an L2 issue. The L3 issue is broadcast
reachability. PILC already discusses the hazards when a subnet
doesn't support (true) broadcast.
I.e., in a wifi net with hidden terminal issues, you no longer have
true broadcast, and shouldn't assume so. But that's also why most of
our protocols have shifted from use of broadcast to multicast --
which would work fine with hidden terminal IF the subnet layer
managed it properly.
Hmm, I agree with the first part. But if true broadcast is absent in
hidden-terminal wifi networks, multicast would be difficult to ensure as
well.
The draft also describes radio range limitations which are common
in WiFi, but have no related description in other RFC. I don't
mean the problem has no wired counterpart problem, but that they
are not described in existing RFCs.
You would then be describing the impact of existing RFCs in terms of
Wifi. That might be useful, but I don't think it warrants creating
new mechanisms or solutions unless you can demonstrate they don't
exist elsewhere.
However, limited radio range has been an issue for Internet
protocols since the ARPAnet days.
Uh? I guess when they came up with IP routing to offer range extension
the notion of IP subnet did not exist?
...
This WiFi range problem is described only in this draft.
This Ethernet length problem is not described in any RFC.
Right. The point is that there's a reason we don't bother with the
ethernet range issue in an RFC, and that same reason may apply here
to your wifi observations.
Maybe we need to explain in this draft this: why it would be good to
give less consideration to range issues, in wifi. Or to explain that
range is dictated by regulated power and spectrum sharing agreements. I
dont know?
Alex
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
