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, 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.
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.
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.
WiFi has a range of 50meter (depending mainly on regulating aspects by
geo-political, indoors/outdoors and other quirks like military
restrictions). By comparison, Ethernet cables of Category6 have a
maximum length of 100meter beyond which attenuation reduces effective
bandwidth by a certain amount.
This WiFi range problem is described only in this draft.
This Ethernet length problem is not described in any RFC.
Alex
Joe
On Jan 19, 2015, at 1:00 PM, Templin, Fred L <[email protected]
<mailto:[email protected]>> wrote:
As I understand it, your draft is trying to establish the notion of a
multi-hop link but
that is not architecturally correct – I think that was the point of
the PILC comment.
Instead of a multi-hop “link”, what you have is a multi-hop
“subnetwork” with
link segments joined together by subnetwork routing protocols. To
establish
a link in the normal sense, configure an NBMA tunnel virtual overlay
over the
subnetwork. IPv6 ND and DHCPv6 then work as-expected.
Thanks – Fred
[email protected] <mailto:[email protected]>
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of *Emmanuel Baccelli
*Sent:* Monday, January 19, 2015 12:36 PM
*To:* Joe Touch
*Cc:* Templin, Fred L; Brian E Carpenter; Alexandru Petrescu;
[email protected] <mailto:[email protected]>
*Subject:* Re: [Int-area] About
draft-baccelli-manet-multihop-communication-04
Hi Joe,
PILC is a great ref that should be cited indeed. Another relevant ref
is RFC 5889. One of the recommendations that RFC boils down to: *do
not* use on-link prefixes *at all* on interfaces to multi-hop wireless
networks -- the subject of the draft we discuss now.
The reason is: there is no planned structure at link-layer and you
cannot guarantee anything in terms of connectivity over such wireless
interfaces -- which does not however mean that these interfaces are
useless!
In short: this is not yet another simple case of NBMA. Ergo the need
for this draft.
Best,
Emmanuel
On Fri, Jan 16, 2015 at 9:58 PM, Joe Touch <[email protected]
<mailto:[email protected]>> wrote:
FYI, there's an RFC explaining all this already: 3819
Joe
On 1/16/2015 12:04 PM, Templin, Fred L wrote:
> +1
>
>> -----Original Message-----
>> From: Int-area [mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Brian E Carpenter
>> Sent: Friday, January 16, 2015 11:16 AM
>> To: Alexandru Petrescu; [email protected]
<mailto:[email protected]>
>> Subject: Re: [Int-area] About
draft-baccelli-manet-multihop-communication-04
>>
>> Alex,
>>
>>> but to improve the layers below IP such as to have IP run
unmodified.
>>
>> In the general case that is impossible, because the SDO that
develops
>> the lower layer isn't interested. If the lower layer is
intrinsically
>> NBMA then for sure ARP or ND+DAD will not work as designed. If
the lower
>> layer doesn't support a physical MTU of at least 1280 IPv6 will
not work
>> as designed. So in the general case both an adaptation layer and an
>> NBMA solution are required. And as you know, there are other
"Ethernet"
>> assumptions that don't apply in a low-power wireless scenario.
>>
>> Of course the goal is "IP over Everything" but that isn't the
same as
>> "Everything must be like Ethernet", which you seem to imply.
>>
>> In fact when you read draft-baccelli-manet-multihop-communication
>> (and imagine what its security section will say when it's been
>> written), I think the conclusion is that a great many things have
>> to change, not in the IP packet format, but in the ecosystem
>> currently provided by ARP/DHCP or RA/ND/DAD/SLAAC/DHCPv6.
>>
>> Brian
>>
>> _______________________________________________
>> Int-area mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> Int-area mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/int-area
>
_______________________________________________
Int-area mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
