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

Hi Carles,

My apologies -- I seem to have missed this when it first arrived.

Thanks for the updates in the -10 and the discussion below -- it all looks
good and I've cleared my discuss!

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 again,

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
> >
> 
> 