Hi Pascal, > Would you prefer a different wording ? Yes I would, what about the below?
OLD: because the RIO is explicitly not intended to serve in routing, and NEW: because the RIO is not intended to be sent by a host or consumed by a router as input to its routing protocol, Esko From: Pascal Thubert <pascal.thub...@gmail.com> Sent: Tuesday, November 19, 2024 17:59 To: Esko Dijk <esko.d...@iotconsultancy.nl> Cc: 6lo@ietf.org Subject: Re: [6lo] Updating 6Lo prefix registration Hello Esko The RIO is not supported to be used as a routing protocol. It the preference should not be a metric. It is meant to be issued by routers and consumed by hosts type C for their local routing table. This is as opposed to the prefix registration that consumed by routers and explicitly carries a request from the node to redistribute the prefix in an IGP or SGP. Would you prefer a different wording ? A bientôt; Pascal Le 18 nov. 2024 à 14:04, Esko Dijk <esko.d...@iotconsultancy.nl<mailto:esko.d...@iotconsultancy.nl>> a écrit : Thanks for adding these clarifications. One sentence part I don’t really understand: “because the RIO is explicitly not intended to serve in routing,” Do you mean here that the RIO (being inside an RA) is intended to be sent by an IPv6 router; while the thing you’re looking for is a way for an IPv6 host to send information about a prefix to an IPv6 router? ( That appears to be the opposite of what you wrote, at a first glance. That’s why it was unclear to me.) On the other hand, RIO does not “serve in routing” in the sense that’s it is not an option used in the routing protocol. (Rather for communication to non-routers.) So that view could support your text. But all in all it’s not clear to me what is intended. Esko From: pascal.thub...@gmail.com<mailto:pascal.thub...@gmail.com> <pascal.thub...@gmail.com<mailto:pascal.thub...@gmail.com>> Sent: Saturday, November 9, 2024 15:24 To: 6lo@ietf.org<mailto:6lo@ietf.org>; 6lo-...@ietf.org<mailto:6lo-...@ietf.org> Subject: [6lo] Updating 6Lo prefix registration Dear all : As requested during the 6lo meeting at IETF 121, I pushed an update to draft indicating why we are not using RA/RIO in this registration. Diff: draft-ietf-6lo-prefix-registration-05.txt - draft-ietf-6lo-prefix-registration-06.txt<https://author-tools.ietf.org/iddiff?url1=draft-ietf-6lo-prefix-registration-05&url2=draft-ietf-6lo-prefix-registration-06&difftype=--html> First I added a reminder on the protocol design elements that 6LoWPAN leverages for low energy operations (aka, green, or, low-carbon): 6LoWPAN was a pioneering attempt at the IETF to design protocols that conserve energy, with the primary goal to serve LLNs, though the general design could be applied in other environments where lowering carbon emissions is also a priority. The general design points include: * Placing the protocol complexity in the routers to simplify the host implementation and avoid expanding the control traffic to all nodes. * Restful operations from the host perspective to enable transient disconnections where the power usage can be lowered. This translates into: * Stateful proactive knowledge in the routers that is available at any point of time. * Unicast host to router operations stimulated by the host and its applications. * Minimal use of asynchronous broadcast operations that would keep the host awake and listening with no application-level need to do so. Then I added 2 sections at the end of the introduction to detail more specifically why IPv6 RA with RIO is not suited here, fails to respect the 6LoWPAN energy conservation principles above, lacks needful security, etc… “ This specification extends the above registration and subscription methods to enable a node to register a prefix to the routing system and get it injected in the routing protocol. As with [RFC8505], the prefix registration is agnostic to the routing protocol in which the router injects the prefix, and the router is agnostic to the method that was used to allocate the prefix to the node. The energy conservation principles in [RFC8505] are retained as well, meaning that the node does not have to send or expect asynchronous broadcast messages. It can be noted that an energy-conserving node is not necessarily a router, so even when advertising a prefix, it is a design choice not to use RA messages that would make the node appear as a router to peer nodes. From the design principles above, it is clearly a design choice not to leverage broadcasts from or to the node, or complex state machines in the node. It is also a design choice to use and extend the EARO as opposed to the Route Information Option (RIO) [RFC4191] because the RIO is explicitly not intended to serve in routing, and is lacking related control information like the R bit in the EARO. Additionally, an RA with RIO cannot be trusted for a safe injection in the routing protocol for the lack of the equivalent of the Registration Ownership Verifier (ROVR) [RFC8928] in the EARO. “ This was uploaded as version 06, so based on the WG meeting discussion, I believe a can now start the WGLC anytime. Many thanks to all! Pascal
_______________________________________________ 6lo mailing list -- 6lo@ietf.org To unsubscribe send an email to 6lo-le...@ietf.org
