Hi Fred, On Mon, Jan 19, 2015 at 10: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. > > > 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. 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. 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] > > > > *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
