Le 19/01/2015 22:15, Emmanuel Baccelli a écrit :
Hi Fred,
On Mon, Jan 19, 2015 at 10: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.____
__
By design, the draft does not introduce any architectural notion. The
goal of the draft is rather to describe the physical reality
experienced over such networks.
I agree, that is a physical reality I also encountered.
I just am afraid of the conclusion.
When I say physical reality is that - by physics - 1 distanced listener
will hardly hear the exchanges between 2 computers close to each other.
Unless some above-PHY layer provides some extension. Just do not
recommend that to be IP.
Once this is clearly documented, we
might indeed have debates about which architecture to adopt over such
network above link layer ;) But in a separate draft.
I agree.
Alex
Best
Emmanuel
__
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]
<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