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. <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> > > >> 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 >> >> 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) > >> 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 > >> 1. >> 2. S 1: suggest removing the sentences and reference to SFAAC as it >> is mostly a distraction >> >> Removed the ref to SFAAC. > >> 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"? > >> 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. > >> 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. > >> 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. " > >> 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 > >> 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" > >> 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 RFC 6724 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. > >> 1. >> 2. S 3.3: avoid having a ‘+’ between HUB-LINK in Fig 3 >> >> I did not get that one > >> 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]. " >> 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. > >> 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? > >> 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. " >> 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. > >> 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 > >> 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 > >> >> Ouf! please let me know if we need a second pass. Many thanks again! -- Pascal
_______________________________________________ 6lo mailing list -- 6lo@ietf.org To unsubscribe send an email to 6lo-le...@ietf.org
