On 1/20/2015 10:04 AM, Alexandru Petrescu wrote:
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).
Please see RFC1812.
This method is used in exchange points, among other places.
...
[...]
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.
Link layer hops don't necessarily have anything to do with L3 hops.
But when out of range they're 2 IP-hops
from each other, although they're still 1 MAC-hop away.
That's an issue for L2.
...
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.
In that case, multicast support would be provided by unicast
reachability in L3.
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?
IP subnets have been around a very long time, but not all mechanisms are
developed in the context of what has already been done before. That's
what I'm suggesting should be avoided in this case.
...
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?
These all sound like L2 (or maybe even L1) issues, and out of scope for
RFCs AFAICT.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
