" Multi links subnets are not a figment of my mind. ". Precisely.
Two years ago, while lecturing a related study-unit for the first time, I encountered this document: http://www.ti.com/lit/pdf/swry013 and it was by then already 4 years old. Figure 1 is inexplicable without the concept of the multi-link subnet. Cheers, Etienne On Sun, Jun 7, 2020 at 9:05 PM Pascal Thubert (pthubert) <pthub...@cisco.com> wrote: > Hello Joel: > > The draft is supposed to be factual not divagations; if I went too far > somewhere I need to fix the draft. As you said it is early personal > submission. > > Multi links subnets are not a figment of my mind. We have millions of > routers deployed that way, using RPL as the subnet routing protocol. > Admittedly this is IoT but this is true nevertheless. > > Keep safe, > > Pascal > > > Le 7 juin 2020 à 21:00, Joel Halpern <j...@joelhalpern.com> a écrit : > > > > Just to clarify context, at this stage this is just Pascal's > interesting idea for how to make ND work better on wireless. No IETF > working group has adopted this. Various people seem to be interested, but > it will be some time before we know if his approach gets traction. > > > > The biggest difference between this and earlier changes along this line > is that the wireless broadcast problem provides motivation for the change, > where earlier efforts were more ~wouldn't it just be simpler if...~ > > > > Yours, > > Joel Halpern > > > >> On 6/7/2020 2:28 PM, Etienne-Victor Depasquale wrote: > >> What I'm amazed at is the concept of multi-link subnet and the change > in IP model being proposed. > >> See, for example, section 4 of > https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-05 > >> Has anyone felt the same about the change being proposed? This swept > away 25 years of thinking about IP subnets and IP links for me. > >> Etienne > >> On Sun, Jun 7, 2020 at 6:03 PM Brandon Martin <lists.na...@monmotha.net > <mailto:lists.na...@monmotha.net>> wrote: > >> On 6/7/20 6:01 AM, Denys Fedoryshchenko wrote: > >> > There are very interesting and unobvious moments on IPv4 vs IPv6, > >> for > >> > example related to battery lifetime in embedded electronics. In > >> ipv4, > >> > many devices are forced to send "keepalives" so that the NAT > >> entry does > >> > not disappear, with IPv6 it is not required and bidirectional > >> > communications possible at any time. And in fact, it has a huge > >> impact > >> > on the cost and battery life of IoT devices. > >> > When I developed some IoT devices for clients, it turned out that > if > >> > "IPv6-only" is possible, this significantly reduces the cost of > the > >> > solution and simplify setup. > >> This is difficult to understate. "People" are continually amazed > >> when I > >> show them that I can leave TCP sessions up for days at a time (with > >> properly configured endpoints) with absolutely zero keepalive traffic > >> being exchanged. > >> As amusingly useful as this may be, it pales in comparison to the > >> ability to do the same on deeply embedded devices running off small > >> primary cell batteries. I've got an industrial sensor network > product > >> where the device poll interval is upwards of 10 minutes, and even > then > >> it only turns on its receiver. The transmitter only gets lit up > about > >> once a day for a "yes I'm still here" notification unless it has > >> something else to say. > >> In the end, we made it work across IPv4 by inserting an application > >> level gateway. We just couldn't get reliable, transparent IPv6 > >> full-prefix connectivity from any of the cellular telematics > providers > >> at the time. I don't know if this has changed. For our application, > >> this was fine, but for mixed vendor "IoT" devices, it would probably > >> not > >> work out well. > >> -- Brandon Martin > >> -- > >> Ing. Etienne-Victor Depasquale > >> Assistant Lecturer > >> Department of Communications & Computer Engineering > >> Faculty of Information & Communication Technology > >> University of Malta > >> Web. https://www.um.edu.mt/profile/etiennedepasquale > > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale