Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-blemesh-09: (with DISCUSS and COMMENT)

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
>> > 6lo@ietf.org
>> > https://www.ietf.org/mailman/listinfo/6lo
>> >
>>
>>
>