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

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Wed, 09 June 2021 21:02 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722A03A260E; Wed, 9 Jun 2021 14:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1b1vmIhdKO4; Wed, 9 Jun 2021 14:02:34 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90DD43A260C; Wed, 9 Jun 2021 14:02:33 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.40.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 159L2UWh065187; Wed, 9 Jun 2021 23:02:30 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.40.6]) by entelserver.upc.edu (Postfix) with ESMTP id 7D1D31D53C1; Wed, 9 Jun 2021 23:02:29 +0200 (CEST)
Received: from 83.53.208.63 by webmail.entel.upc.edu with HTTP; Wed, 9 Jun 2021 23:34:56 +0200
Message-ID: <217d2f977d01989ac12f0ac2c4c09299.squirrel@webmail.entel.upc.edu>
In-Reply-To: <20210609200755.GR32395@kduck.mit.edu>
References: <161421455243.10769.8266309895985939749@ietfa.amsl.com> <b8e8697b4be4c936844fa9e7d6fe796b.squirrel@wmail.entel.upc.edu> <20210609200755.GR32395@kduck.mit.edu>
Date: Wed, 9 Jun 2021 23:34:56 +0200
From: "Carles Gomez Montenegro" <carlesgo@entel.upc.edu>
To: "Benjamin Kaduk" <kaduk@mit.edu>
Cc: "The IESG" <iesg@ietf.org>, rahul.ietf@gmail.com, 6lo-chairs@ietf.org, draft-ietf-6lo-blemesh@ietf.org, 6lo@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at dash
X-Virus-Status: Clean
X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Wed, 09 Jun 2021 23:02:30 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/adw5MSYWeq2KS_IjrOKZlcjfcQk>
Subject: Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-blemesh-09: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2021 21:02:39 -0000

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