<div dir="ltr">Pascal, thank you, the draft at 

<a href="https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/" target="_blank">https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/</a>  is very informative.<div><br></div><div>You hit the nail on the head with your suggestion of confusion between the congruence of link and subnet.</div><div><br></div><div>However, I followed one of the references (RFC4903) in your draft and</div><div>it does not help that it (RFC4903) points to RFC4291's assertion that:</div><div>"Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link"</div><div><br></div><div>RFC4903 further states that:</div><div> "clearly, the notion of a multi-link subnet would be a change to the existing IP model.".</div><div><br></div><div>I confess: your assertion in the draft that:</div><div>"In Route-Over Multi-link subnets (MLSN) [RFC4903], </div><div>routers federate the links between nodes</div>that belong to the subnet, the subnet is not on-link and it extends<br><div>beyond any of the federated links"</div><div><br></div><div>is news to me.</div><div><br></div><div>Best regards,</div><div><br></div><div>Etienne</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 30, 2020 at 1:39 PM Pascal Thubert (pthubert) <<a href="mailto:pthubert@cisco.com">pthubert@cisco.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div dir="auto">
Hello Etienne Victor
<div><br>
</div>
<div>Maybe you’re confusing link and a subnet?</div>
<div><br>
</div>
<div>This is discussed at length here:<br>
<br>
</div>
<div><a href="https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/" target="_blank">https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/</a></div>
<div><br>
</div>
<div>RPL can route inside a subnet using host routes. This is how a multi link subnet can be made to work...<br>
<div dir="ltr">
<div><br>
</div>
Please let me know if the draft above helped and whether it is clear enough. The best way for that discussion would be to cc 6MAN.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Keep safe,<br>
<div><br>
</div>
<div>Pascal</div>
</div>
<div dir="ltr"><br>
<blockquote type="cite">Le 30 mai 2020 à 10:03, Etienne-Victor Depasquale <<a href="mailto:edepa@ieee.org" target="_blank">edepa@ieee.org</a>> a écrit :<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Thank you Carsten, and thank you Pacal. Your replies are valuable and packed with insight.
<div><br>
</div>
<div>I'll wrap up with how I interpret RPL's behaviour in terms of IP hops.</div>
<div><br>
</div>
<div>On one hand, RFC6775 defines a route-over topology as follows:</div>
<div>"A topology where hosts are connected to the 6LBR through the use of intermediate layer-3 (IP) routing. </div>
<div>Here, hosts are typically multiple IP hops away from a 6LBR. </div>
<div>The route-over topology typically consists of a 6LBR, a set of 6LRs, and hosts."</div>
<div>If RPL is route-over by definition, then RFC6775 would imply that there are typically multiple IP hops between a leaf and the border router.</div>
<div><br>
</div>
<div>On the other hand, there at least two contradictions (which I justify after stating them):</div>
<div>(a) RFC6550 states that "RPL also introduces the capability to bind a subnet together with a common prefix and to route within that subnet."</div>
<div>(b) Reduction of a DODAG to a single subnet prefix, albeit only only one parent-child relationship deep, is clearly shown at Contiki-NG's Github page (deep dive section).</div>
<div><br>
</div>
<div>The hinge on which my understanding revolves is that an IP hop traverses a router and ***results in a change of prefix of the link on which the packet travels*** :</div>
<div><br>
</div>
<div>--------<incoming packet; link prefix = p1>------><router> --------<outgoing packet; link prefix = p2>------></div>
<div><br>
</div>
<div>With RPL, the "hop" would look like as shown below:</div>
<div><br>
</div>
<div>  --------<incoming packet; link prefix = p1>------<router> --------<outgoing packet; link prefix = p1>------  <br>
</div>
<div><br>
</div>
<div>There seems to be a change in the meaning associated with "IP hop". </div>
<div>I guess that I can reconcile both cases through the observation that RPL actually does apply to a single, NBMA link and therefore the IP prefix ***is*** the same.</div>
<div>Then again, calling the RPL device involved in the packet forwarding by the name "router" feels like an uncomfortable stretch. </div>
<div>Don't routers sit at the meeting point of different layer 2 links?</div>
<div><br>
</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>Etienne</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, May 29, 2020 at 10:39 PM Pascal Thubert (pthubert) <<a href="mailto:pthubert@cisco.com" target="_blank">pthubert@cisco.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hello Etienne <br>
<br>
You may see ND as the host to * interface for any network and RPL as the router to router interface when the network is NBMA.<br>
<br>
Some of us cared about the interworking. <br>
<br>
Look at the RPL Unaware leaf I-draft and you’ll see that I’m sure.<br>
<br>
Keep safe,<br>
<br>
Pascal<br>
<br>
> Le 29 mai 2020 à 20:28, Carsten Bormann <<a href="mailto:cabo@tzi.org" target="_blank">cabo@tzi.org</a>> a écrit :<br>
> <br>
> Hi Etienne,<br>
> <br>
> I’m also not sure many of the classical network operators assembled in NANOG work with 6LoWPANs today, but I still can answer your question.<br>
> <br>
>> While trying to build a holistic view of LoWPANs, I'm consulting the IETF's informational and standards documents.<br>
>> <br>
>> I'm struck by the impression that, despite the significance of RFC6775's extension of Neighbor Discovery(ND) to low-power and lossy networks (LLNs),<br>
>> it is largely ignored by RFC6550 (RPL), with little to no reference to the ontological plane created in RFC6775's terminology section.<br>
> <br>
> Yes, you could say that.<br>
> <br>
> ND (Neighbor discovery) describes interfaces between hosts and between hosts and routers.<br>
> 6LoWPAN-ND does not use host-to-host interfaces (different from Ethernet, all traffic goes over routers, which RFC 4861 already forsaw in the L — on-link — bit, which isn’t set in 6LoWPAN-ND).<br>
> <br>
> RFC 6550 was completed at a time when many people who came in from the WSN (wireless sensor network) world thought they could get away with a network that is wholly composed of routers.<br>
> Even the “leaf” nodes in the RPL world were participating in the routing protocol and therefore didn’t really need a host-router interface.  There was no separate host-router interface in that world, because there were no non-router hosts.<br>
> <br>
>> (a) router advertisements and router solicitations are substituted by DAG information objects (DIO) and DAG information solicitations (DIS)<br>
> <br>
> Right, DIO and DAO are router-to-router messages.  If there are no hosts (and routers don’t bootstrap themselves as hosts), you don’t need ND.<br>
> <br>
>> (b) the terms "mesh-under" and "route-over" (widely cited), defined in RFC6775, are absent from RFC6550<br>
> <br>
> RFC6550 is route over by definition.  Actually, the term was coined by the people working closely with the RPL development; RFC 6775 does appropriate it as 6LoWPAN-ND is applicable in either case.<br>
> <br>
>> (c) jarringly: RFC6775 describes the route-over topologies as multi-IP-hop, while RFC6550 gathers DODAG nodes within the confines of the same IPv6 prefix as their border router - no multiple IP hops.<br>
> <br>
> I’m not sure where you get this interpretation: RFC 6550 (RPL) is very much about IP hops.<br>
> Maybe you mean the address architecture that was defined explicitly in RFC 6775; RFC 6550 does not really say much about addresses.<br>
> <br>
> Note that the RPL people have since proceeded to (at least partially) embrace the host-router concept from the IP architecture; RFC 8505 is an update to RFC 6775 that makes 6LoWPAN-ND more palatable to RPL people.<br>
> <br>
> I have CCed Pascal Thubert who, as a co-author to all three RFCs, certainly will have another perspective on this.<br>
> <br>
> Grüße, Carsten<br>
> <br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Ing. Etienne-Victor Depasquale</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif">
<span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Assistant Lecturer</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif">
<span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Department of Communications & Computer Engineering</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif">
<span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Faculty of Information & Communication Technology</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif">
<span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">University of Malta</span>
<div>Web. <a href="https://www.um.edu.mt/profile/etiennedepasquale" target="_blank">https://www.um.edu.mt/profile/etiennedepasquale</a><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Ing. Etienne-Victor Depasquale</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Assistant Lecturer</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Department of Communications & Computer Engineering</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">Faculty of Information & Communication Technology</span><br style="color:rgb(136,136,136);font-family:tahoma,sans-serif"><span style="color:rgb(136,136,136);font-family:tahoma,sans-serif">University of Malta</span><div>Web. <a href="https://www.um.edu.mt/profile/etiennedepasquale" target="_blank">https://www.um.edu.mt/profile/etiennedepasquale</a><br></div></div></div>