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

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Thu, 22 April 2021 10:31 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 60D5A3A0DCD; Thu, 22 Apr 2021 03:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 AtT0yHJgPB39; Thu, 22 Apr 2021 03:31:51 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 927C93A0DCA; Thu, 22 Apr 2021 03:31:50 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.40.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 13MAVlE8029380; Thu, 22 Apr 2021 12:31:47 +0200
Received: from wmail.entel.upc.edu (webmail.entel.upc.edu [147.83.40.6]) by entelserver.upc.edu (Postfix) with ESMTP id 7F82C1D53C1; Thu, 22 Apr 2021 12:31:46 +0200 (CEST)
Received: from 10.192.137.220 by wmail.entel.upc.edu with HTTP; Thu, 22 Apr 2021 12:39:37 +0200
Message-ID: <b8e8697b4be4c936844fa9e7d6fe796b.squirrel@wmail.entel.upc.edu>
In-Reply-To: <161421455243.10769.8266309895985939749@ietfa.amsl.com>
References: <161421455243.10769.8266309895985939749@ietfa.amsl.com>
Date: Thu, 22 Apr 2021 12:39:37 +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 violet
X-Virus-Status: Clean
X-Greylist: Delayed for 00:18:00 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Thu, 22 Apr 2021 12:31:48 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/S1vlDqPTbh7bRCYp-b8WFpxvuTY>
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: Thu, 22 Apr 2021 10:31:55 -0000

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
>