Subject: [6lo] AD Evaluation: draft-ietf-6lo-btle

From: Brian Haberman <[email-masked]>
Date: Wed, 20 May 2015 10:43:16 -0400

All,
     I have completed my AD evaluation of draft-ietf-6lo-btle as a part
of the publication process.  I have a few points to discuss with the
group before moving this document to IETF Last Call.

* Does the IETF have open access to the IPSP?

* Section 2.1

- Figure 1 shows several fields (Direct Test Mode & Security Manager)
that do not have any descriptive text included in the section.  A brief
mention of their use would be helpful.

- I had to wait until section 3.1 to figure out how IPv6 fit into the
protocol stack illustrated in Figure 1.  A forward pointer to 3.1 or a
brief mention of how IPv6 fits into the stack would be good.

* Section 2.2 : Please clarify that the hub and spoke model does not
preclude 2 peripherals from communicating. The sentence discussing
direct communication made me think momentarily that two peripherals
couldn't communicate.

* Section 3 : Related to the previous comment, the 2nd paragraph
precludes "multihop networks at the link layer".  I would clarify that
inter-peripheral communication is handled by the 6LBR routing function.

* Section 3.1 : It is unclear, to me, on how the IPSS/GATT/ATT blocks in
Figure 3 are supposed to be interpreted. Is IPv6 a GATT? 6LoWPAN an ATT?

* Section 3.2

- Please use a 2119 MUST for header compression.

- Can some clarifying text be added explaining why lengths and addresses
are being inferred?  Or is "inferred" the wrong term here?

- The *brief* discussion of the "multilink model" is too brief.
Something more is needed.  Is this the same multi-link model discussed
in RFC 4903?  If so, how is this case different.

* Section 3.2.1 : Please make an explicit statement on DAD.

* Section 3.2.4 : s/master/Central/

* I think it would be useful if the document contained a summary table
of what 6LoWPAN features are used or not used.  I am not requiring you
add one, but I would like you to consider it.

Regards,
Brian

---

From: "Savolainen Teemu (Nokia-TECH/Tampere)" <[email-masked]>
Date: Thu, 21 May 2015 07:22:49 +0000

Hi Brian,

>* Does the IETF have open access to the IPSP?

Yes, on this page:
https://www.bluetooth.org/en-us/specification/adopted-specifications
(direct URL being: https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=296307 )

>- Figure 1 shows several fields (Direct Test Mode & Security Manager) that do not have any descriptive text included in the section.  A brief mention of their use would be helpful.

Ok.

>- I had to wait until section 3.1 to figure out how IPv6 fit into the protocol stack illustrated in Figure 1.  A forward pointer to 3.1 or a brief mention of how IPv6 fits into the stack would be good.

Ok.

>* Section 2.2 : Please clarify that the hub and spoke model does not preclude 2 peripherals from communicating. The sentence discussing direct communication made me think momentarily that two peripherals couldn't communicate.

Right, the direct refers here to direct wireless communications..

>* Section 3 : Related to the previous comment, the 2nd paragraph precludes "multihop networks at the link layer".  I would clarify that inter-peripheral communication is handled by the 6LBR routing function.

Right, updating of this sentence was missed  when the subnet model text was otherwise clarified.

>* Section 3.1 : It is unclear, to me, on how the IPSS/GATT/ATT blocks in Figure 3 are supposed to be interpreted. Is IPv6 a GATT? 6LoWPAN an ATT?

The IPSS is used for discovering that a node supports IPv6. That happens using Bluetooth's GATT protocol. Once IPv6 support is discovered, IPv6 can be used - please see the IPSS. The stacks above L2CAP are parallel to each other, and for full IPv6 joy both stacks above L2CAP are used.

Would it help to update the caption to:"IPv6 and IPSS on Bluetooth LE Stack"?

>- Please use a 2119 MUST for header compression.

Ok.

> Can some clarifying text be added explaining why lengths and addresses are being inferred?  Or is "inferred" the wrong term here?

Because they are compressed away.. But let's see if additional clarity can be added.

>Something more is needed.  Is this the same multi-link model discussed in RFC 4903?  If so, how is this case different.

But what exactly.. Reference to Section 3.3 where we have some more text? Reference to RFC4903 and say that the issues in RFC 4903 have been recognized but for Bluetooth LE Internet of Things environment multi-link mode's benefits are considered to overweight its drawbacks?

> Section 3.2.1 : Please make an explicit statement on DAD.

Can you please elaborate a bit, we already have a statement:" Effectively duplicate address detection for link-local addresses is performed by the 6LBR's software responsible of discovery of IP-enabled Bluetooth LE nodes and of starting Bluetooth LE connection establishment procedures.". Or that DAD MUST NOT be used?

>Section 3.2.4 : s/master/Central/

OK.

>I think it would be useful if the document contained a summary table of what 6LoWPAN features are used or not used.  I am not requiring you add one, but I would like you to consider it.

... is there a table of 6LoWPAN features available somewhere?

Best regards,

	Teemu

---

From: Brian Haberman <[email-masked]>
Date: Thu, 21 May 2015 12:54:40 -0400

Hi Teemu,
     I snipped all the points where we have agreement on the action...

On 5/21/15 3:22 AM, Savolainen Teemu (Nokia-TECH/Tampere) wrote:
> (direct URL being:
> https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=296307
> )

I added an IESG note within the datatracker so that reviewers can find
the URL.  Any reason the URL can't be put into the reference?

> 
>> * Section 3.1 : It is unclear, to me, on how the IPSS/GATT/ATT
>> blocks in Figure 3 are supposed to be interpreted. Is IPv6 a GATT?
>> 6LoWPAN an ATT?
> 
> The IPSS is used for discovering that a node supports IPv6. That
> happens using Bluetooth's GATT protocol. Once IPv6 support is
> discovered, IPv6 can be used - please see the IPSS. The stacks above
> L2CAP are parallel to each other, and for full IPv6 joy both stacks
> above L2CAP are used.
> 

I think the above would help.  I would also think that adding a
variation of your brief synopsis above to 3.1 could help.

>> Something more is needed.  Is this the same multi-link model
>> discussed in RFC 4903?  If so, how is this case different.
> 
> But what exactly.. Reference to Section 3.3 where we have some more
> text? Reference to RFC4903 and say that the issues in RFC 4903 have
> been recognized but for Bluetooth LE Internet of Things environment
> multi-link mode's benefits are considered to overweight its
> drawbacks?

I think adding a forward pointer to 3.3 will help.  I also think that
referencing 4903 and saying why this draft contradicts it would be
useful.  That will preclude future readers from saying "what about RFC
4903?"

> Can you please elaborate a bit, we already have a statement:"
> Effectively duplicate address detection for link-local addresses is
> performed by the 6LBR's software responsible of discovery of
> IP-enabled Bluetooth LE nodes and of starting Bluetooth LE connection
> establishment procedures.". Or that DAD MUST NOT be used?

Disregard.  I missed the "Effectively" sentence while reviewing.

>> I think it would be useful if the document contained a summary
>> table of what 6LoWPAN features are used or not used.  I am not
>> requiring you add one, but I would like you to consider it.
> 

I am not aware of one, but let me ask a clarifying question.  Is it just
the fragmentation support from 4944 that is not used in this spec?

Regards,
Brian

---

From: "Savolainen Teemu (Nokia-TECH/Tampere)" <[email-masked]>
Date: Fri, 22 May 2015 10:57:37 +0000

Hi Brian,

Please find our comments inline as well. We have already prepared -13 , but we wanted to share these comments first before uploading the next rev.

>I added an IESG note within the datatracker so that reviewers can find the URL.  Any reason the URL can't be put into the reference?

I was unsure whether URLs are welcome in references.. but the to-be-13 has now:

   [BTCorev4.1]
              Bluetooth Special Interest Group, "Bluetooth Core
              Specification Version 4.1", December 2013,
              <https://www.bluetooth.org/en-us/specification/adopted-
              specifications>.

   [IPSP]     Bluetooth Special Interest Group, "Bluetooth Internet
              Protocol Support Profile Specification Version 1.0.0",
              December 2014, <https://www.bluetooth.org/en-
              us/specification/adopted-specifications>.

>I think the above would help.  I would also think that adding a variation of your brief synopsis above to 3.1 could help.

We changed the caption and modified text to:
   Figure 3 illustrates how IPv6 stack works in parallel to GATT stack
   on top of Bluetooth LE L2CAP layer.  GATT stack is needed herein for
   discovering nodes supporting Internet Protocol Support Service.  UDP
   and TCP are provided as examples of transport protocols, but the
   stack can be used by any other upper layer protocol capable of
   running atop of IPv6.
 
>I think adding a forward pointer to 3.3 will help.  I also think that referencing 4903 and saying why this draft contradicts it would be useful.  That will >preclude future readers from saying "what about RFC 4903?"

New text:
   Bluetooth LE connections used to build a star topology are point-to-
   point in nature, as Bluetooth broadcast features are not used for
   IPv6 over Bluetooth LE (except for discovery of nodes supporting
   IPSS).  As the IPv6 over Bluetooth LE is intended for constrained
   nodes, and for Internet of Things use cases and environments,
   multilink model's benefits are considered to overweight multilink
   model's drawbacks described in RFC 4903 [RFC4903].  Hence a multilink
   model has been chosen, as further illustrated in Section 3.3.
   Because of this, link-local multicast communications can happen only
   within a single Bluetooth LE connection, and thus 6LN-to-6LN
   communications using link-local addresses are not possible. 6LNs
   connected to the same 6LBR have to communicate with each other by
   using the shared prefix used on the subnet.  The 6LBR ensures address
   collisions do not occur (see Section 3.2.2) and forwards packets sent
   by one 6LN to another.

>I am not aware of one, but let me ask a clarifying question.  Is it just the fragmentation support from 4944 that is not used in this spec?

Well quite a lot of stuff from 4944 are not used, for example mesh support. We noticed that the introduction was making too much noise out of 4944, which we actually don't use that much (it is just informational reference). Thus we updated the last paragraph of 1. Introduction to:

   RFCs 4944, 6282, and 6775 [RFC4944][RFC6282][RFC6775] specify the
   transmission of IPv6 over IEEE 802.15.4.  The Bluetooth LE link in
   many respects has similar characteristics to that of IEEE 802.15.4
   and many of the mechanisms defined for the IPv6 over IEEE 802.15.4
   can be applied to the transmission of IPv6 on Bluetooth LE links.
   This document specifies the details of IPv6 transmission over
   Bluetooth LE links.

Would that help, i.e. not highlight 4944 as much as before (which I think was artefact from long ago).

Best regards,

	Teemu