Hi Ben, > Hi Carles, > > My apologies -- I seem to have missed this when it first arrived.
No worries! > Thanks for the updates in the -10 and the discussion below -- it all looks > good and I've cleared my discuss! Thank you. > Unfortunately, that still leaves it in a state where it "needs 2 more YES > or NO OBJECTION positions to pass", so Erik will need to wrangle a couple > more ADs to take a look. Thanks for pointing this out! I understand that this relates with a few former ADs who stepped down recently. > Thanks again, You are welcome, and thanks for your constructive review! Best regards, Carles > Ben > > On Thu, Apr 22, 2021 at 12:39:37PM +0200, Carles Gomez Montenegro wrote: >> Hi Benjamin, >> >> Thank you very much for your feedback, and apologies for the late >> response. >> >> We just published an updated version of the draft (revision -10). >> >> Please find below our inline responses to your comments: >> >> >> > Benjamin Kaduk has entered the following ballot position for >> > draft-ietf-6lo-blemesh-09: Discuss >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut >> this >> > introductory paragraph, however.) >> > >> > >> > Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-6lo-blemesh/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > >> > I may well just be confused about this, but let's discuss and find >> out. >> > Section 3.3.2 says "[a]s per RFC 8505, a 6LN MUST NOT register its >> > link-local address." Which part of RFC 8505 says this? Section 5.6 >> > thereof seems to enumerate some cases where link-local addresses MUST >> > (not MUST NOT) be registered, and there's not much other discussion of >> > link-local addresses that I saw. >> >> Thanks for noticing this. The sentence did not explicitly indicate that >> we >> referred to registration with the 6LBR. >> >> In -10 we have replaced the former sentence by the next new paragraph: >> >> NEW: >> As per RFC 8505, a 6LN link-local address does not need to be unique >> in the multilink subnet. A link-local address only needs to be >> unique from the perspective of the two nodes that use it to >> communicate (e.g., the 6LN and the 6LR in an NS/NA exchange). >> Therefore, the exchange of EDAR and EDAC messages between the 6LR and >> a 6LBR, which ensures that an address is unique across the domain >> covered by the 6LBR, does not need to take place for link-local >> addresses. >> >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > I support Martin (D)'s Discuss (though I think maybe the use-case that >> > is in question is the non-homogeneous-MTU case). At a minimum the >> > security considerations should be discussing this scenario as a risk, >> > but ideally it could be avoided altogether. >> >> "As per the present specification, the MTU size for IPv6 mesh over BLE >> links is 1280 octets." >> >> (Initially we thought that it might be a good idea to keep the >> flexibility >> offered by the IPSP in this regard, but we finally realized that it was >> not such a good idea.) >> >> > (I also agree with Martin (V)'s comment.) >> >> We have updated the draft accordingly, thanks to both. >> >> (Note: we did not receive an email message from Martin Vigoureux, but we >> were able to see his feedback on Datatracker.) >> >> > Section 3.1 >> > >> > Similarly to RFC 7668, fragmentation functionality from 6LoWPAN >> > standards is not used for IPv6 mesh over Bluetooth LE links. >> > Bluetooth LE's fragmentation support provided by L2CAP is used when >> > necessary. >> > >> > I don't really understand why it's necessary to say "when necessary". >> > If IPv6 requires an MTU of 1280 octets but the BLE link is doing 247 >> or >> > less, doesn't the L2CAP fragmentation always need to be enabled for >> the >> > IPv6 mesh? >> >> Yes. To avoid confusion, we have removed "when necessary". >> >> > Section 3.2 >> > >> > Is it worth reiterating that with the multi-link subnet model, the >> > routers have to take on responsibility for tracking multicast state >> and >> > forwarding multicast/broadcast in a loop-free manner? I think we do >> > talk about most of that elsewhere, but it could be useful to tie that >> in >> > with the tradeoffs that went into this decision. >> >> We added the following before the last sentence of the first paragraph >> (in >> section 3.2): >> >> NEW: >> "With the multilink subnet model, the routers have to take on >> responsibility for tracking multicast state and forwarding multicast >> in >> a loop-free manner." >> >> > (Does the "loop-free" part place any constraints on the IPv6 routing >> > protocol(s) that can be used with IPv6 mesh over BLE?) >> >> Implicitly, yes. One comment here is that wireless multihop networks are >> typically very dynamic (even if nodes are actually static), and >> therefore >> it would not be unusual that even a routing protocol that is "loop-free" >> may lead to temporary loops, the main point being that such loops (if >> any) >> are expected to be just temporary. >> >> > Section 3.3.2 >> > >> > 1. A Bluetooth LE 6LN SHOULD register its non-link-local addresses >> > with its routers by sending a Neighbor Solicitation (NS) message >> with >> > the Extended Address Registration Option (EARO) and process the >> > Neighbor Advertisement (NA) accordingly. Note that in some cases >> > (e.g., very short-lived connections) it may not be worthwhile for a >> > 6LN to send an NS with EARO for registering its address. However, >> > the consequences of not registering the address (including non- >> > reachability of the 6LN, and absence of DAD) need to be carefully >> > considered. [...] >> > >> > Where can an exhaustive list of the consequences of not registering be >> > found? >> > It might also be helpful to give an example of something that a 6LN >> > might do on such a very-short-lived connection where the >> non-link-local >> > address is not registered (since, obviously, only link-local traffic >> > would be possible). >> >> We discussed this comment with the WG. The outcome of the discussion was >> using 'MUST' instead of 'SHOULD' in this paragraph, in order to avoid >> any >> potential issues. >> >> > Section 3.3.3 >> > >> > To enable efficient header compression, when the 6LBR sends a >> Router >> > Advertisement it MAY include a 6LoWPAN Context Option (6CO) >> [RFC6775] >> > matching each address prefix advertised via a Prefix Information >> > Option (PIO) [RFC4861] for use in stateless address >> > autoconfiguration. Note that 6CO is not needed for context-based >> > compression when context is pre-provisioned or provided by out-of- >> > band means. >> > >> > I see that in RFC 7668 sending 6CO in this situation was MUST-level >> > required. Is the reasoning behind the weakening of the requirement >> just >> > the stated scenarios where pre-provisioned context renders the in-band >> > context indication superfluous? If so, it might be possible to reword >> > to be more clear about expectations. If not, some additional >> discussion >> > of the reasoning might be helpful. >> >> Yes, the reasoning behind the weakening of the requirement is that >> pre-provisioned or out-of-band-provided context renders the in-band >> context indication superfluous. >> >> We added the following text to make the above more explicit: >> >> NEW: >> Note that 6CO is not needed for context-based compression when >> context is >> pre-provisioned or provided by out-of-band means, as in these cases >> the >> in-band indication (6CO) becomes superfluous. >> >> > Section 8 >> > >> > connection with each 6LR (Step 3). After establishment of those >> link >> > layer connections (and after reception of Router Advertisements >> from >> > the 6LBR), Step 4, the 6LRs start operating as routers, and also >> > initiate the IPSP Router role (note: whether the IPSP Node role is >> > kept running simultaneously is an implementation decision). Then, >> > >> > (nit/editorial) The theme seems to be that "step N" is in parentheses >> > after the description of the step, done everywhere except for step 4. >> > So maybe " the 6LRs start operating as routers, and also initiate the >> > IPSP Router role (Step 4) (note: whether the IPSP Node role is kept >> > running simultaneously is an implementation decision)"? >> >> Agreed, and done in -10. >> >> Should you have any further comments, please let us know. >> >> Thanks, >> >> Carles (on behalf of the authors) >> >> >> > >> > _______________________________________________ >> > 6lo mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/6lo >> > >> >> > _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
