+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.
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. Joe > On Jan 19, 2015, at 1:00 PM, Templin, Fred L <[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] > > 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]> 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]] On Behalf Of Brian E > >> Carpenter > >> Sent: Friday, January 16, 2015 11:16 AM > >> To: Alexandru Petrescu; [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] > >> https://www.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
