Re: [6lo] INT-DIR review of draft-ietf-6lo-dect-ule-05

[Jens Toftgaard Petersen <[e-mail]>]

Hi Pascal,

Thank you very much for your review - very much appreciated. I have just submitted a revised version that addresses all your comments.
See additional comments below in colour inline.

Best regards,
   Jens


From: 6lo [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
Sent: 27. september 2016 11:14
To: [e-mail]; [e-mail]
Subject: [6lo] INT-DIR review of draft-ietf-6lo-dect-ule-05

Dear all :

I am an assigned INT directorate reviewer for draft-ietf-6lo-dect-ule-05. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate.html.

Document: draft-ietf-6lo-dect-ule
Transmission of IPv6 Packets over DECT Ultra Low Energy
Reviewer: Pascal Thubert
Review Date: Sept 27, 2016
IETF Last Call Date: TBD

Summary: Issues concerning the subnet model that needs to be explicited.

Major issues:

- Reference to draft-ietf-6lo-privacy-considerations and privacy of addresses should be addressed (related to lifespan of IEEE EUI48 addresses, random but permanent is still not too good)   Reference has been added
- Subnet model (Section 3.3) should be described in more details, indicating NBMA Multi-Link SubNet (MLSN). Suggestion to review/emulate RFC 7668 (section 3.2.1 and last paragraph of 3.2.2)  Subnet model description has been revised and MLSN concept introduced
- Reference to draft-ietf-6lo-backbone-router could be made to address the L3 perspective of node mobility  Text and reference added
- Some IMPERATIVE is extraneous. (RFC2119: "Imperatives of the type defined in this memo must be used with care and sparingly.  In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm") Has been reviewed - further comments are appreciated

Minor issues:

- inline on the right of the original text, with a "<<" prefix

---





6Lo Working Group                                            P. Mariager
Internet-Draft                                          J. Petersen, Ed.
Intended status: Standards Track                                 RTX A/S
Expires: November 17, 2016                                     Z. Shelby
                                                                     ARM
                                                          M. Van de Logt
                                             Gigaset Communications GmbH
                                                              D. Barthel
                                                             Orange Labs
                                                            May 16, 2016


        Transmission of IPv6 Packets over DECT Ultra Low Energy


< snip>


1.  Introduction

   DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface       <<< spell DECT on first use
   technology building on the key fundamentals of traditional DECT /
   CAT-iq but with specific changes to significantly reduce the power
   consumption at the expense of data throughput.  DECT (Digital          <<<  DECT spelling
   Enhanced Cordless Telecommunications) is a standard series
   [EN300.175-part1-7] specified by ETSI and CAT-iq (Cordless Advanced
   Technology - internet and quality) is a set of product certication
   and interoperability profiles [CAT-iq] defined by DECT Forum.  DECT

Done
< snip>


   In its generic network topology, DECT is defined as a cellular
   network technology.  However, the most common configuration is a star
   network with a single FP defining the network with a number of PP
   attached.  The MAC layer supports both traditional DECT as this is          << "both" is unclear, can you rephrase?
   used for services like discovery, pairing, security features etc.
   All these features have been reused from DECT.


Wording is revised
< snip>




       [DECT ULE PP]-----\                 /-----[DECT ULE PP]
                          \               /
       [DECT ULE PP]-------+[DECT ULE FP]+-------[DECT ULE PP]
                          /               \
       [DECT ULE PP]-----/                 \-----[DECT ULE PP]


       Figure 2: DECT ULE star topology                                   << suggestion to place a forward reference to section 3.3  on how IP uses that (MLSN)



   A significant difference between IEEE 802.15.4 and DECT ULE is that
   the former supports both star and mesh topology (and requires a
   routing protocol), whereas DECT ULE in it's primary configuration
   does not support the formation of multihop networks at the link
   layer.  In consequence, the mesh header defined in [RFC4944] for mesh

 Reference added
< snip>


   When bound to a FP, a PP is assigned a 20 bit TPUI which is unique       << in reference to draft-ietf-6lo-privacy-considerations it would be good to indicate whether this is short lived or long lived, so as to figure if an IPv6 address can be derived or not.
   within the FP.  This TPUI is used for addressing (layer 2) in
   messages between FP and PP.

Reference added and additional description
< snip>


   Optionally each DECT PP and DECT FP can be assigned a unique (IEEE)
   MAC-48 address additionally to the DECT identities to be used by the     << same as above, it would be good to indicate whether this is short lived or long lived, so as to figure if an IPv6 address can be derived or not.
   6LoWPAN.  During the address registration of non-link-local addresses
   as specified by this document, the FP and PP can use such MAC-48 to
   construct the IID.

 Text revised and added
< snip>


   support complete IP packets, the DLC layer of DECT ULE SHALL per this    << there is a MUST later in the document, no need to uppercase here; whether this setting is needed is debatable
   specification be configured with a MTU size that fits the
   requirements from IPv6 data packets, hence [RFC4944] fragmentation/
   reassembly is not required.                                              << unclear. .. since DLC supports fragmentation there is no need for 6LoWPAN fragmentation is there? The adaptation described here only provides value if the DLC fragmentation is armful. Is that the case ?
Tried to make text for clear
   It is expected that the LOWPAN_IPHC packet will fulfil all the
   requirements for header compression without spending unnecessary
   overhead for mesh addressing.

   It is important to realize that the usage of larger packets will be
   at the expense of battery life, as a large packet inside the DECT ULE
   stack will be fragmented into several or many MAC layer packets, each
   consuming power to transmit / receive.                                  << proof? fragments increase reliability and reduce the size of retried pieces. is there a paper showing pros vs cons or is this the author intuition ?
Change wording to make more clear. MAC PDU size is not changed. Fragmentation is implemented in DECT ULE DLC instead of using RFC4944
2.5.  Additional Considerations

   The DECT ULE standard allows PP to be registered (bind) to multiple
   FP and roaming between these FP.  This draft does not consider the      << Why ?? this is where the backbone router becomes handy. If the subnet model is clarified to NBMA / MLSN then it is possible to assign the same prefix to multiple 6LBRs and connect them through a 6lo backbone router
   scenarios of PP roaming between multiple FP.  The use of repeater
   functionality is also not considered in this draft.
After some analysis we added this as an option
< snip>


3.1.  Protocol Stack

   In order to enable transmission of IPv6 packets over DECT ULE, a
   Permanent Virtual Circuit (PVC) has to be opened between FP and PP.
   This MUST be done by setting up a service call from PP to FP.  The PP   << is this MUST coming from this spec or from DECT? if the latter then just say "this is done by..."
   SHALL specify the <<IWU-ATTRIBUTES>> in a service-change (other)
   message before sending a service-change (resume) message as defined
   in [TS102.939-1].  The <<IWU-ATTRIBTES>> SHALL define the ULE
   Application Protocol Identifier to 0x06 and the MTU size to 1280
   octets or larger.  The FP MUST send a service-change-accept (resume)
   containing a valid paging descriptor.  The PP MUST be pageable.

Changed, and wording changed
< snip>


3.2.  Link Model

   The general model is that IPv6 is layer 3 and DECT ULE MAC+DLC is
   layer 2.  The DECT ULE implements already fragmentation and
   reassembly functionality, hence [RFC4944] fragmentation and             << this is repeating and sight contradictory. suggestions to keep the text starting at RFC4944, dropping the beginning of the sentence
   reassembly function MUST NOT be used.  The DECT ULE DLC link (PVC)
   MUST be configured with a minimum MTU size of at least 1280 octets in   << Not sure this is needed
   order to meet the size requirements of IPv6.

Wording changed

< snip>



   compression context if any, and from address registration information
   (see Section 3.2.2).

   Due to DECT ULE star topology, each branch of the star is considered
   to be an individual link and thus the PPs cannot directly hear one      << indicate that this is NBMA, multilink subnet. See related text in 6LoWPAN BTLE RFC 7668
   another and cannot talk to one another with link-local addresses.
   However, the FP acts as a 6LBR for communication between the PPs.
   After the FP and PPs have connected at the DECT ULE level, the link
   can be considered up and IPv6 address configuration and transmission
   can begin.  The FP ensures address collisions do not occur.
Wording changed and multilink subnet introduced
3.2.1.  Stateless Address Autoconfiguration

   At network interface initialization, both 6LN and 6LBR SHALL generate
   and assign to the DECT ULE network interface IPv6 link-local
   addresses [RFC4862] based on the DECT device addresses (see
   Section 2.3) that were used for establishing the underlying DECT ULE
   connection.

   The DECT device addresses IPEI and RFPI MUST be used to derive the      << SHOULD vs. MUST: with a MUST, this means that the 6LoWPAN code does never expect a link local that is not fully elided (3.2.4.1.)?
   IPv6 link-local 64 bit Interface Identifiers (IID) for 6LN and 6LBR,
   respectively.

MUST is ok

< snip>



   see [RFC7136].  For example from RFPI=11.22.33.44.55 the derived IID
   is 80:11:22:ff:fe:33:44:55 and from IPEI=01.23.45.67.89 the derived
   IID is 00:01:23:ff:fe:45:67:89.                                        << This seems to be setting permanent addresses (admittedly Link local), and the privacy properties of such addresses should be addressed, eg addresses do not (lust not) leak in app layer in any fashion

   As defined in [RFC4291], the IPv6 link-local address is formed by
   appending the IID, to the prefix FE80::/64, as shown in Figure 4.


Text added

< snip>


   (CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses
   (HBAs) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque     << This seems to be setting permanent addresses; discussion on renewing addresses would be good, ref to draft-ietf-6lo-privacy-considerations would help, and the security section could just point here as opposed to use IMPERATIVE
   addresses [RFC7217] SHOULD be used by default.  In situations where

Reference added

< snip>



   2.  A DECT ULE 6LN MUST NOT register its link-local address.  A DECT  << the registration has 2 roles, DAD (which can be avoided for globally unique addresses) and SLLA mapping. This seems to indicate that SLLA is deduced from the LL so there's special code to avoid using an ND cache?
   ULE 6LN MUST register its non-link-local addresses with the 6LBR by
Wording changed. There is are unique 1-to-1 mapping link-local addresses and LL addresses.

< snip>


   accordingly.  The NS with the ARO option MUST be sent irrespective of
   the method used to generate the IID.  The 6LN MUST register only one  << why can't a device form more than one address?
   IPv6 address per available IPv6 prefix.

After some analysis we have removed this restriction
< snip>

   the DAM field of the compressed IPv6 header as CID=1, DAC=1 and
   DAM=01 or DAM=11.  Note that when a context is defined for the IPv6   << considering the rest of the optimizations, why don't you have a /128 context for the 6LBR?
   destination address, the 6LBR can infer the elided destination prefix
   by using the context.

Wording has been changed - I am not sure if have completely understood your question/suggestion.

< snip>



3.3.  Subnets and Internet Connectivity Scenarios       << Missing scenario below, same /64, with backbone router




                         6LN                 6LN
                          \                 /
                           \               /
                    6LN --- 6LBR ------ 6LBR --- 6LN
                           /               \
                          /                 \
                         6LN                 6LN

                    <DECT ULE> <Backbone> <DECT ULE>

This optional scenario has been added


< snip>