Hello Eric: Committed to github and published as -10. Please see Diff: draft-ietf-6lo-prefix-registration-09.txt - draft-ietf-6lo-prefix-registration-10.txt <https://author-tools.ietf.org/iddiff?url1=draft-ietf-6lo-prefix-registration-09&url2=draft-ietf-6lo-prefix-registration-10&difftype=--html> again, ton of thanks!
Please see below: <https://author-tools.ietf.org/iddiff?url1=draft-ietf-6lo-prefix-registration-09&url2=draft-ietf-6lo-prefix-registration-10&difftype=--html> Le mer. 16 avr. 2025 à 07:32, Eric Vyncke (evyncke) <evyn...@cisco.com> a écrit : > Bonjour Pascal, > > > > Thank you for the -09 and your answers below. > > > > My own comments are prefixed below with EVY>, i.e., would you mind > submitting a -10 with the minor changes below ? > > > > Anyway, I am trusting you to act promptly on the comments and I am > therefore requesting an IETF Last Call. > > > > Regards > > > > -éric > > > > > > *From: *Pascal Thubert <pascal.thub...@gmail.com> > *Date: *Tuesday, 15 April 2025 at 14:14 > *To: *Eric Vyncke (evyncke) <evyn...@cisco.com> > *Cc: *6lo@ietf.org <6lo@ietf.org>, adnanrashi...@gmail.com < > adnanrashi...@gmail.com>, shwetha.bhand...@gmail.com < > shwetha.bhand...@gmail.com> > *Subject: *Re: AD review of draft-ietf-6lo-prefix-registration > > Sorry the message flew too fast... continuing... > > > > Le lun. 14 avr. 2025 à 16:52, Pascal Thubert <pascal.thub...@gmail.com> a > écrit : > > > > > > Le lun. 14 avr. 2025 à 13:44, Eric Vyncke (evyncke) <evyn...@cisco.com> a > écrit : > > Pascal and 6LO WG, > > > > > > Hello Eric! > > > > Many thanks for your review. Yes, it's a deep one! Many thanks for that :) > > I published as 09 my proposed changes so you can observe them in the > datatracker; > > Diff: draft-ietf-6lo-prefix-registration-06.txt - > draft-ietf-6lo-prefix-registration-09.txt > <https://author-tools.ietf.org/iddiff?url1=draft-ietf-6lo-prefix-registration-08&url2=draft-ietf-6lo-prefix-registration-09&url1=draft-ietf-6lo-prefix-registration-06&difftype=--html> > is > probably the diff you want, since I injected the changes for the C flag in > 07. > > > > > > Thanks for the work done in this document (and the shepherd’s write-up). I > really like the quick summary in section 1 about the LLN differences wrt. > other networks as it will prevent some IPv6 objections. > > > > As usual, I am doing my AD review of draft-ietf-6lo-prefix-registration > before going forward with the publication process, i.e., the IETF Last Call > and the IESG evaluation. I request the author (or the WG) to address all > points below, either by a revised I-D or an explanation (telling me that I > am plain wrong is OK of course). > > > > As noted by Adnan, by the erratum #8340, and the 6LO chairs’ email: > https://mailarchive.ietf.org/arch/msg/6lo/ACVb0LmKUHLnpphjWuF87D4d34Y/, > the ‘fix’ will be a in separate short I-D and not in > draft-ietf-6lo-prefix-registration. > > > > I published 08 prior to handling it so we can have a clean diff on the > application of your comments below. 08 takes off the handling of the 'C' > flag which is now done by draft-ietf-6lo-updating-rfc-8928. > > > > Please rest assured that my only intents are to improve the document > quality and to prepare an easy publication path even if there are many > points to be addressed below > > > > > > : ) > > > > > > Nits: > > · S 1: `agnotic`? > > · S 2.4: s/A RPL router that merges becomes the origin of the > merged/A RPL router that merges *then* becomes the origin of the merged/ > > · S 3.2: s/more than one Prefix/more than one *p*refix/ > > · S 7.2: clarify “the packets will be not be filtered” > > > > I added the title of the BCP ( Network Ingress Filtering ) .so it's more > clear what filtering I'm talking about: > > " > > > This > means that the Registering Node relays packets that are sourced in > the Registered Prefix to the outside, in accordance with "Network > Ingress Filtering" [BCP38] . > > " > > · S 7.4: `existing registration state might be lost if it was not > persisted` use “persistent” perhaps ? > > > > No, I meant persisted in some remanent storage > > > > · S 7.4: s/the link local address/the link-local address/ or use > LLA > > > > EVY> you forgot about the link-local nit ;-) > > > > what about > > " > > if it was not safely stored, e.g., in persistent memory. > > " > > > > > > · > > · S 8: empty bullet > > · If the I-D uses Kramdown, then using aasvg in the .md file > would make some nice SVG rather than ASCII art > > sorry, not using md... > > > > Please find below some proposed changes to match your comments: > > > > > > Comments: > > 1. Abstract, the sentence starting with “The unicast prefix” is very > long and convoluted, i.e., please try to simplify it (perhaps by cutting is > smaller sentences ?) > > " > > The unicast > prefix registration allows to request neighbor router(s) to > redistribute the prefix in a larger routing domain regardless of the > routing protocol used in the larger domain. > > " > > > > 1. > > 2. S 1: please make `6LoWPAN was a pioneering attempt at the IETF ` > more factual (references) and less dramatic 😉 > > " > > LLNs and constrained devices are the original domain of application > for 6LoWPAN protocols. It is thus a foremost concern, when designing > those protocols, to minimize energy spendings. In non-LLN > environments where lowering carbon emissions is also a priority, it > could make sense to apply the 6LoWPAN designs and extend some of the > 6LoWPAN protocols. > > " > > > > 1. S 1: s/complexity in the routers/complexity in the always-powered > routers/ ? > > hum, RPL applies to battery operated routers (aka FFNs) vs tiny hosts (aka > LFNs) > > > > EVY> you may then write something about “less power constrained” ? > WFM, removing "power" since memory is also an issue which somehow may or may not derive from power > > > > > 1. S 1: `Restful operations` often means REST (Representational > state transfer) compatible operations in the IETF context, suggest using > another term > > " > > Using host-stimulated operations to enable transient > disconnections with the routers, e.g., to conserve power (sleep), > but also to cope with inconsistent connectivity. > > " > > > > 1. > > 2. S 1: is ‘proactive’ required and correct in `Stateful proactive > knowledge`? > > maybe "proactively-built" instead. Like all major routing protocols (but > not ND), 6LoWPAN ND builds its state proactively so it's there when needed. > > > > 1. > > 2. S 1: s/the power usage can be lowered/the power usage can be > *reduced*/ > > removed with the change above > > > > 1. > > 2. S 1: s/asynchronous broadcast operations/asynchronous *multicast* > operations/ and later s/when broadcast was cheap/when *multicast* was cheap/ > > It's *always* a broadcast at L2... changed "broadcast" to "L2-broadcast" > on both cases > > > > EVY> fair enough and more accurate indeed > > 1. > > 2. S 1: suggest removing the sentences and reference to SFAAC as it > is mostly a distraction > > Removed the ref to SFAAC. > > > > EVY> actually I suggested removing way more ;-) > Trouble is that text si nowhere else to be found and provides context for the whole thing > > > 1. > > 2. S 1: is it `router-protocol-agnostic interface` or > “rout*ing*-protocol-agnostic *way*” ? (as interface is overloaded at the > IETF) > > maybe, "method" instead of "interface"? > > > > EVY> I was also pointing to s/router/routing/ ;-) > oups, done > > > 1. > > 2. S 1: s/ to enable a node to register a prefix/ to enable a node > to register a *unicast* prefix/ > > done > > 1. > > 2. S 1: s/asynchronous broadcast messages/asynchronous *multicast* > messages/ > > done > > 1. > > 2. S 1: expand `RA` at first use > > done > > > > 1. > > 2. S 1: s/ RIO is explicitly not intended to serve in routing/ RIO > is explicitly not intended to inject routes in routing/ and I am not sure > whether RFC 4191 ‘explicitly’ says so... > > My memory is that Dave Thaler was explicit in email, and made a point that > the preference is not a metric.Sadly that's not as clear in the RFC. > > > > EVY> indeed, this is not clear at all and I am afraid that this I-D makes > assumption on that point. As you remove ‘explicitly’ this should be OK > already done : ) Since I'm pleading for proactive behaviors I guess I have to eat my own DF! > 1. > > 2. >>> S 2.1, a tough one, [I-D.kuehlewind-update-tag > <https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag-04>]is > used in a normative way to define “extends” and “amends”, i.e., it must be > normative. You may want to copy the definitions in this document (citing an > informative reference) though > > done > > > > 1. > > 2. S 2.3, a very long and dry list, are all acronyms used in this > I-D ? > > cleaned up > > > > 1. > > 2. S 3: ` can now attract the traffic for a full prefix` please do > not use ‘attract’ and be sure that the 6LN takes the traffic in charge (= > forward) > > The 6LN may consume the traffic for the whole prefix (can be a host) and > never forward. The key is to signal that it wishes to receive the > traffic.In routing protocols a border router advertises by injecting a > prefix in a routing protocol, and dong so it attracts the traffic for the > advertised prefix in one area to forward it in another. I changed "attract" > to "get". Not sure what else to use. > > > > EVY> “The traffic for a full prefix is now sent ...” is probably closer to > what you mean > I mean advertise a prefix in order to receive the traffic for all addresses in the prefix range. If the R flag is set, the router will redistribute in its routing protocol. What is being sent by whom and where is really the redistribution admin preference) rules, the routing operation in the routers, and load balancing, all at work after that. " With this extension, the 6LN can now express its willingness to receive the traffic for all addresses in the range of a prefix, using the P field value of 3 in the EARO to signal that the registration is for such prefix. Multiple 6LNs acting as border routers to the same external network or as access routers to the same subnet may register the same prefix to the same 6LR or to different 6LRs. " > 1. > > 2. S 3: s/in other routing protocol/in *an*other routing protocol/ ? > > done > > 1. > > 2. S 3: s/the 6LR is requested to redistribute/the 6LR MUST > redistribute/ ? (if SHOULD is preferred, then explain when this can be > bypassed) > > and > > > > 1. > > 2. S 3: strongly suggest removing the paragraph starting with `This > specification extends 6LoWPAN work, and it is *certainly* possible to > leverage it` > > > " > > If the R flag is set in the registration of one or more 6LNs for the > same > prefix, then, according to its redistribution policy, the 6LR MUST > redistribute the prefix in the routing protocol(s) (e.g., RPL) that > it participates to. The duration of the redistribution is > based on the longest registration lifetime across the > non-expired received registrations for the prefix. > > " > > > > EVY> unsure about your reply intent ? > Wrong pointer (oups, sorry). I replaced the paragraph with: " Examples of use-cases where this specification may apply include virtual links, shared links, and hub links as shown in Section 3.2 and Section 3.3, respectively. More generally, the 6LN may be a router running a different routing protocol in an external network, e.g., a stub network, and acting as a border router. Using the prefix registration method enables to decouple the routing protocol in the 6LN from the routing protocol that the 6LRs run in the main LLN and provide signaling to stimulate the redistribution. " > "1. > > 2. S 3.1: unsure whether “abstract” is correct in `abstract data > structure` also `registrar` is a *role* and not a data structure > > > > > > " > > Figure 1 illustrates the classical situation of an LLN as a single > IPv6 Subnet, with a 6LoWPAN Border Router (6LBR) that acts as Root > for RPL operations and as Address Registrar for 6LowPAN ND. > > " > > > > > > 1. > > 2. S 3.1: unsure whether the 3rd § is required > > reworded and moved to intro, as examples of LLNs. > > > > 1. > > 2. S 3.1: in Fig 1, is the Northbound if the 6LBR always “wired” ? > E.g., think about the “SNAC AIL”, which can be Wi-Fi > > agreed, I updated the fig > > > > EVY> thanks, suggest moving the “zzz” slightly on the right as they > collide with “and or” > done > > 1. > > 2. S 3.1: suggest to use specific name/id in Fig1 and the text for > `A leaf acting ` > > done. Also added > > " > > A RPL leaf L acting as a 6LN registers its addresses and prefixes to > > a RPL router acting as a 6LR, using a layer-2 unicast NS message with > an EARO as specified in [RFC8505] and [RFC9685]. Note that a RPL > leaf acting as 6LN may still be a border router for another routing > protocol, an access router for an IP link, or a virtual Router > serving virtual machines or applications within the same physical > node. > > " > > > > 1. > > 2. S 3.1: avoid any ambiguity in ` by the Registering Node`(is it > 6LR or 6LN in Fig 1?) > > done > > 1. > > 2. S 3.1 is it still worth referencing to an expired I-D > heile-lpwan-wisun-overview ? > > I'll trust you on this. Replaced with a simple link to the > alliance site.Did you know 6LoWPAN-ND - Reference | Mbed OS 5 > Documentation > <https://os.mbed.com/docs/mbed-os/v5.15/reference/6LoWPAN-ND-tech.html> ? > > > > > > 1. > > 2. S 3.2: explain ESS ? > > added "federating multiple Access Points" > > > > EVY> and expand ESS ? > done > > > 1. > > 2. S 3.2: s/Ethernet + Wi-Fi *ESS*/Ethernet *or* Wi-Fi/ > > done > > 1. > > 2. S 3.2: Fig 2 appears as upside-down, i.e., the global > connectivity/Internet is usually on the top of the graphic, please flip the > graphic > > done > > > > 1. > > 2. >>> S 3.2: in Fig 2, shouldn’t all nodes use SLAAC and have > addresses in P1 and P2 prefixes and use for source address/next hop > selection ? > > Everything is possible from SLAAC to full registration, or a mix. > The focus for us here is to get the route installed on P2. For the rest, > let us assume that the reader/admin knows ND when/where he applies it. > About his decision of using SLAAC or not, note that the path between P1 > and P2 nodes may be very complex at L2, e.g., involving LPWAP tunnels and > such. Rather than adding text, I removed the line on redirect. > > > EVY> my point was more about the nodes having 2 addresses or selecting to > have only one (similar discussion in SNAC BTW) > EVY> please keep the sentence about ICMP redirect > restored . Still I do not wish to start a discussion on what the host may or should do here. In IOT, we have use-cases where some devices may only join the prefix of a utility and be routed through the utility network. RPL forms a separate instance, and packets are routed along the topology indicated in the RPL option to the right gateway. So in a multihomed RPL network you do not need something like source/destination routing. RFC 8505 rejects the registrations that are not topologically correct in its sense. e.g., a router that does not belong in the aggregation will reject the registration with a status 8. And a host cannot use an address that is not registered, that's part of RFC 8505 used for SAVI. Finally, the ownership of the address can be validated with RFC 8928. > > > 1. > > 2. S 3.3: avoid having a ‘+’ between HUB-LINK in Fig 3 > > I did not get that one > > > > EVY> normal as I mistype ‘between STUB & LINK’ ... Sorry, is it clear now ? > > > yessss. Since I was at it, I added a 6LR4 in parallel of 6LR3. and text: " In this example, routers 6LR3 and 6LR4 both connect to the same stub link where subnet P3 is installed. They may both register P3 to 6LR1, and 6LR1 will apply its own load balancing logic to use either of the routers. " Nothing prevents 6LR3 and 6LR4 from using a RIO about P3 over the hub too. 1. > > 2. S 3.3: should DHCP-PD be mentioned in `If P2 was delegated by > 6LR1`? > > added a ref to RFC 8415 as first use of delegation > > " > > If P2 was delegated by 6LR1, e.g., using the "Dynamic Host > Configuration Protocol for IPv6" [RFC8415] (DHCPv6), then ... > > " > > > > 1. > > 2. S 4: should there be a note about the co-existence of RFC 8505 & > legacy nodes doing NS/NA ? Section 11 is mostly silent on this topic > > Coexistence is a different topic so neither sections 4 and 11 is > really ideal. > > Added at first chance (section 3.2) > > > > " > > > Note that the > shared link maybe operated with any combination of NDP and SND as > discussed in section 7 of [I-D.ietf-6man-ipv6-over-wireless]. > > " > > EVY> good idea thanks > > 1. > > 2. S 5: `updated by RFC Editor if needed` should rather be a > specific paragraph to ensure that this step will be executed > > done. I'm sure from experience that the RFC editor is very, very thorough, > and would not miss it either way. > > > > 1. > > 2. S 7.2 there is no `plen` in Fig 5 ;-) > > fixed > > > > 1. > > 2. S 7.2: `when the packets are sourced with the registered prefix` > is it ‘sourced’ or ‘destined’ ? > > sourced. tells the other routers to forward to self packets that would use > the wrong router . > > This serves multihoming cases, e.g., for legacy nodes that would not > comply with RFC 6724. > > > > EVY> ack > > 1. > > 2. S 7.3, as the terminology is silent, please add a normative > reference to the RFC defining EDAR > > added references to terminology > > > > 1. > > 2. S 7.3, define what to do when the padding of the prefix is != 0 > > " > > Prefix 15 bytes: up to 120 bits of prefix, it MUST be padded with > zeros, and the padding MUST be overwritten with zeros when the > prefix is being used by the receiver. > > " > > > > 1. > > 2. S 7.3, prefix length is not a `1-bit flag` > > fixed, and enforced the value range. is 16-120 OK? > > > > EVY> ok, except for s/7-bits integer/7-bit integer/ > oups > 1. > > 2. S 7.4 the paragraph starting with `The operation for registering > prefixes is similar ` is not really a behavior, i.e., remove it from the > bulleted list > > done > > > > 1. > > 2. S 7.4: s/FF02::1/ff02::1/ > > done > > > > 1. > > 2. S 7.4: what is an `unreliable environment`? > > " > > In an environment with unreliable transmissions, ... > > " > > > > 1. > > 2. S 7.4: what is a ‘proxy’ in `that a proxy registers a prefix ` ? > > Oh, great point. This is defined in RFC 8929 and the extension is to > support RFC 9685 and this is kinda obvious, but someone needs to write it > down somewhere. > > I added a small section > > " > > > 10. Extending RFC 8929 > > " > "IPv6 Backbone Router" [RFC8929] defines a proxy operation whereby a > 6LoWPAN Border Router (6LBR) may impersonate a 6LN when performing an > address registration. In that case, [RFC8505] messages are used as > is, with one change that the SLLAO in the proxied NS(EARO) messages > indicates the Registering Node (the 6LBR) as opposed to the > Registered Node (the 6LN). See figure 5 of [RFC8929] for an example > of proxy operation by the 6LBR, which generates an NS(EARO) upon > receiving an EDAR message. > > This specification Extends that proxy operation with the updates in > [RFC9685] and this on the formats and content of the EARO, the EDAR, > and the EDAC messages, to support the P-Field and the signaling of > prefixes. The proxy MUST use the P-Field as received in the EDAR or > NS(EARO) message to generate the proxied NS(EARO), and it MUST use > the exact same prefix and prefix length as received in the case of a > prefix registration. > > " > > the section discussing proxy becomes > > " > > > Overlaps may be desirable. It may happen for instance that a > router or a proxy (see Section 10) registers a prefix or an > aggregation while a host using an address from that prefix or a > prefix from that aggregation also registers its piece. > > " > > > > EVY> superb, thank you > > 1. > > 2. S 7.4: s/longest match/longest prefix match/ ? (several > occurrences) > > > > done > > 1. > > 2. S 7.4: in `it SHOULD register all those prefixes`, explain when > the SHOULD can be bypassed or what are the consequences of bypassing the > SHOULD > > " > > * If the 6LR acts as a border router to external prefixes or owns > the prefixes entirely, it SHOULD register all those prefixes with > on all interfaces from which it might be needed to relay traffic > to that prefix. It MUST set the P field in the EARO to 3 for > those prefixes, and the set R flag to receive the traffic > associated to the prefixes. It MAY refrain from registering a > prefix on one interface if that prefix is already successfully > registered on another interface, or the router handled the EDAR / > EDAC flow by itself, to ensure that the prefix ownership is known > and validated by the 6LBR. Additionally, if the router expect to > receive traffic for that prefix on that interface, it needs to > ensure that the prefix is advertised some other way, e.g., over a > routing protocol such as RPL. > > " > > > > 1. > > 2. >>> S 9: as there will be another I-D for the change C/P, simply > add a normative reference to this I-D (and I understand that this I-D > should be drafted first...) > > Adnan and I drafted that I-D. From there, we could ignore the C flag > entirely in this spec as we did (unwillingly) in RFC 8985, so we do not > create a dependency. > > > > EVY> correct, and both I-D will probably proceed together during IESG (as > there is a big queue nowadays) > > > > 1. > > 2. S 9: in `Prefixes are not always owned by one node` unsure what > “own” means here and perhaps use “owned by only on node” > > Done > > EVY> I do not see any change in the -09 though > the sentence is now "Prefixes are not always owned by only one node" ? I added "only". Now I'm not sure what you meant, so I removed the sentence altogether. > > > 1. > > 2. S 10: please explain when the “SHOULD” can be bypassed or what > are the consequences of bypassing it > > Not sure what to say. IU added > > " > > else > a rogue node with physical Access to the network may inject packets > and perform an attack from within. > > " > > > > 1. > > 2. S 12.2 as written above, remove this sub-section > > done > > 1. > > 2. S 13: s/for their early *INT-DIR* review/for their early > review*s*/ > > > > Done > > > > EVY> except for the plural form for review*s* ;-) > > > : ) > > > > > Ouf! please let me know if we need a second pass. Many thanks again! > > > > EVY> Ouf indeed (private French joke) > > EVY> You are welcome > > -- > > Pascal > -- Pascal
_______________________________________________ 6lo mailing list -- 6lo@ietf.org To unsubscribe send an email to 6lo-le...@ietf.org
