Le 19/01/2015 22:00, Templin, Fred L a écrit :
As I understand it, your draft is trying to establish the notion of
a multi-hop link but that is not architecturally correct
I tend to agree Fred. I think we need to clarify the word 'hop'.
A multi-IP-hop link does not really exist - it's an IP network.
A multi-subIP-hop link is made into a single-IP-hop by some subnetwork
non-IP 'routing' protocol.
'Route-over' and 'mesh-under' are hard to digest terms. 'Route-over'
should have been called 'IP-over-subnet' and 'mesh-under' should have
been called 'subIP switching'.
– 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.
I agree.
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.
That[NBMA tunnel virtual overlay] is one way of making a multi-subIP-hop
link into a good IP subnet. There are other ways: RPL tries to do the
same, and some times RIP-inspired below IP.
Alex
Thanks – Fred
[email protected]
*From:*[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] *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
