Subject: [Roll] Review [raft-rahul-roll-mop-ext-00]

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Tue, 4 Jun 2019 15:26:58 +0200

Hello Rahul and co-authors, 

As promised during the last IETF meeting in Prague, here is my review.
Bellow is the draft contents with my annotations, starting with “[GP]".

Cheers,
Georgios

— — —

ROLL                                                      R. Jadhav, Ed.
Internet-Draft                                               Huawei Tech
Intended status: Standards Track                              P. Thubert
Expires: August 15, 2019                                           Cisco
                                                       February 11, 2019

                    RPL Mode of Operation extension
                      draft-rahul-roll-mop-ext-00

Abstract

   RPL allows different mode of operations which allows nodes to have a
   consensus on the basic primitives that must be supported to join the
   network.  The MOP field in RFC6550 is of 3 bits and is fast
   depleting.  This document extends the MOP field specification and
   adds a notion of capabilities using which the nodes can further
   advertise their support for, possibly optional, capabilities.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 15, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Jadhav & Thubert         Expires August 15, 2019                [Page 1]

Internet-Draft                MOP extension                February 2019

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language and Terminology . . . . . . . . . .   2
   2.  Requirements for this document  . . . . . . . . . . . . . . .   3
   3.  Extended MOP Control Message Option . . . . . . . . . . . . .   3
     3.1.  Final MOP . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Capabilities  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Capability Control Message Option . . . . . . . . . . . .   5
     4.2.  Capabilities Handshake  . . . . . . . . . . . . . . . . .   5
   5.  Implementations Consideration . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Capability Handshake Example . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   RPL [RFC6550] specifies a proactive distance-vector based routing
   scheme.  The protocol creates a DAG-like structure which operates
   with a given "Mode of Operation" (MOP) determining the minimal and
   mandatory set of primitives to be supported by all the participating
   nodes.

   MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is
   specific to the RPL Instance.  The receipient of the DIO message can
   join the specified network as a router only when it can support the
   primitives as required by the mode of operation value.  For example,
   in case of MOP=3 (Storing MOP with multicast support) the nodes can
   join the network as routers only when they can handle the DAO
   advertisements from the peers and manage routing tables.

1.1.  Requirements Language and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   MOP: Mode of Operation.  Identifies the mode of operation of the RPL
   Instance as administratively provisioned at and distributed by the
   DODAG root.

Jadhav & Thubert         Expires August 15, 2019                [Page 2]

Internet-Draft                MOP extension                February 2019

   DAO: DODAG Advertisement Object.  An RPL message used to advertise
   the target information in order to establish routing adjacencies.

   DIO: DODAG Information Object.  An RPL message initiated by the root
   and is used to advertise the network configuration information.

   Current parent: Parent 6LR node before switching to the new path.

   NPDAO: No-Path DAO.  A DAO message which has target with lifetime 0.

   MOPex: MOP extension as defined in this document.

   This document uses terminology described in [RFC6550].  For the sake
   of readability all the known relevant terms are repeated in this
   section.

2.  Requirements for this document

   Following are the requirements considered for this documents:

   REQ1:  MOP extension.  Current MOP of 3-bit is fast depleting.  An
          MOP extension needs to extend the possibility of adding new
          MOPs in the future.

   REQ2:  Optional capabilities handshake.  Capabilities are features,
          possibly optional, which could be handshaked between the nodes
          and the root within an RPL Instance.
[GP] Maybe few words (to give minimum background) earlier in the Introduction about the "capabilities handshake”? Otherwise it appears too unexpectedly.

   REQ3:  Backwards compatibility.  The new options and new fields in
          the DIO message should be backward compatible i.e. if there
          are nodes which support old MOPs they could still operate in
          their own instances.

   REQ4:  Capabilities handshake could be optionally added with existing
          MOPs.  Capabilities been optional in nature could be put to
          use with existing MOPs.  Capabilities and MOP-extension is
          mutually independent i.e. a DIO can have a capabilities
          option, MOP-extension option or both in the same message.
[GP] Structurally, I would push REQ4 before REQ3. Since both REQ2 and 4 are related with Capabilities handshake.

3.  Extended MOP Control Message Option
[GP] A structural comment here, I do not see a Subsection 3.2 and so on, then I do not see why there should be 3.1.

   This document reserves existing MOP value 7 to be used as an
   extender.
[GP] To make it clear, the value 7 did not represent something till today?
   DIO messages with MOP value of 7 MUST refer to the
   Extended MOP (MOPex) option in the DIO message.  If the MOPex option
   is absent in the DIO whose MOP is 7, then the DIO message MUST be
   silently discarded.
[GP] with the current implementation if this value is 7, what would be the case? It will be silently discarded as well?

Jadhav & Thubert         Expires August 15, 2019                [Page 3]

Internet-Draft                MOP extension                February 2019

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = TODO |           Extended-MOP-value                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: Extended MOP Option
[GP] Is it possible to have this Extended MOP option Figure within the actual DIO message?

3.1.  Final MOP

   An implementation supporting this document MUST calculate the final
   MOP value as the sum of base MOP (as supported in Section 6.3.1. of
   [RFC6550]) plus the MOPex value.  Thus if the MOPex value is 0, it
   means the final MOP is 7 since the base MOP in this case will be set
   to 7.

                     +----------+-------+-----------+
                     | Base MOP | MOPex | Final MOP |
                     +----------+-------+-----------+
                     |    0     |   NA  |     0     |
                     |    1     |   NA  |     1     |
                     |    :     |   :   |     :     |
                     |    6     |   NA  |     6     |
                     |    7     |   0   |     7     |
                     |    7     |   1   |     8     |
                     |    7     |   2   |     9     |
                     |    :     |   :   |     :     |
                     +----------+-------+-----------+

                      Table 1: Final MOP calculation

4.  Capabilities

   Currently RPL specification does not have a mechanism whereby a node
   can signal the set of features that are available on its end.  Such a
   mechanism could help the root to advertise its capabilities and in
   response also determine some advanced information about the
   capabilities of the joining nodes.  The Mode of Operation field in
   RPL mandates the operational requirement and does not allow loose
   coupling of additional capabilities.  This document defines
   Capabilities as additional features which could be supported by the
   nodes and handshaked as part of RPL signaling.  Capabilities are
   embedded as RPL control message option as defined Section 6.7 of
   [RFC6550] in the base messages of DIO, DAO and DAO-ACK signaling.

Jadhav & Thubert         Expires August 15, 2019                [Page 4]

Internet-Draft                MOP extension                February 2019

4.1.  Capability Control Message Option
[GP] Is there room both for MOPex and for Capability options? Or it will either be one or the other one?

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = TODO |           Capabilities Flags                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2: Capabilities Option

   There are no capability flags defined by this document.

4.2.  Capabilities Handshake

   The root node could advertise the set of capabilities it supports in
   the DIO message.  A node could take advantage of the knowledge that
   the root supports a particular capability.  Similarly a node could
   advertise its capabilities in the DAO message using the capability
   control message option defined in this document.  Capabilities
   advertised by non-root nodes are strictly a subset of the
   capabilities advertised by the root.

   In storing MOP, the DAO message from the 6LR could contain multiple
   target options.  The targets of the capabilities option are indicated
   by one or more Target options that precede the Capabilties Option.
   This handling is similar to the Transit Information Option as
   supported in Section 6.7.8. of [RFC6550].

5.  Implementations Consideration

   The MOP-extension could cause 3-byte increase in memory in the RPL-
   Instance.  The MOP field in the RPL-Instance needs to be upgraded to
   a 32 bit integer.

   [RFC6550], it was possible to discard an unsupported DIO-MOP just by
   inspecting the base message.  With this document, the MOPex is a
   different control message option and thus the discarding of the DIO
   message could happen after inspecting the message options.

   A node in storing MOP could independently construct a DAO message
   with target options containing its child/sub-childs.  Thus with
   capabilities it needs to reconstruct the capabilities field as well.
   This may result in increase in the memory requirement on per routing-
   entry basis.

Jadhav & Thubert         Expires August 15, 2019                [Page 5]

Internet-Draft                MOP extension                February 2019

6.  Acknowledgements

   Thanks

7.  IANA Considerations

   IANA is requested to allocate MOP field value 0x7 in the DIO base
   object defined in RPL [RFC6550] section 6.3.1 for MOP extension.

   TODO

8.  Security Considerations

   The options defined in this document are carried in the base message
   objects as defined in [RFC6550].  The RPL control message options are
   protected by the same security mechanisms that protect the base
   messages.

   Capabilities flag can reveal that the node has been upgraded or is
   running a old feature set.  This document assumes that the base
   messages that carry these options are protected by RPL security
   mechanisms and thus are not visible to a malicious node.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

9.2.  Informative References

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

Appendix A.  Capability Handshake Example

Jadhav & Thubert         Expires August 15, 2019                [Page 6]

Internet-Draft                MOP extension                February 2019

       Root          6LR          6LN
        |             |            |
        |   DIO(CS1)  |            |
        |------------>|  DIO(CS1)  |
        |             |----------->|
        |             |            |
        |             |   DAO(CS2) |
        |             |<-----------|
        |   DAO(CS2)  |            |
        |<------------|            |
        |             |            |
        CS: Capabilities Set
        CS1: Capabilities set advertised by root
        CS2: Capabilities set advertised by node. CS2 is a subset of CS1.

                       Figure 3: Capabilities Option

Authors' Addresses

   Rahul Arvind Jadhav (editor)
   Huawei Tech
   Kundalahalli Village, Whitefield,
   Bangalore, Karnataka  560037
   India

   Phone: +91-080-49160700
   Email: [email-masked]

   Pascal Thubert
   Cisco Systems, Inc
   Building D
   45 Allee des Ormes - BP1200
   MOUGINS - Sophia Antipolis  06254
   France

   Phone: +33 497 23 26 34
   Email: [email-masked]

Jadhav & Thubert         Expires August 15, 2019                [Page 7]

____________________________________

Georgios Z. Papadopoulos, Ph.D.
Associate Professor, IMT Atlantique, Rennes

web: 	 www.georgiospapadopoulos.com <http://www.georgiospapadopoulos.com/>
twitter: 	@gzpapadopoulos <https://twitter.com/gzpapadopoulos?ref_src=twsrc%5Etfw&ref_url=http://georgiospapadopoulos.com/>
tel:		+33 (0)2 99 12 70 04
____________________________________

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Wed, 5 Jun 2019 00:53:27 +0000

Thank you Georgios for the review and feedback.
Please find my responses inline.

Regards,
Rahul

[RJ] Yes. Should have introduced capabilities in Introduction section. Will do.

          their own instances.

[RJ] Or I could swap REQ3 and REQ2 which will make related requirements club together? But yes, I get the point of structuring things together and will update in next ver.

[RJ] Will structure this properly. Should add a separate ‘Extended-MOP Base Rules’ section (which will be Section 3.2).

   extender.

   silently discarded.

[RJ] MOP=7 does not represent anything today. We have added IANA consideration to reserve MOP=7. This reminds me, I need to add Extended-MOP-Value and Capabilities flag registry in the IANA consideration.

[RJ] Thanks for raising this. I tried to check what happens as per 6550. As per 6550 Section 6.3.1, the node can still join the network with unknown MOP as a leaf node. This might have implications and may need handling.

        0                   1                   2                   3

[RJ] There are 7 bits in Reserved field in DIO base message. But I’m not sure if we can use those bits since otherwise there won’t be any Reserved space left for future play.

[RJ] The draft allows either or both options. Will make this explicit in next ver.

---

From: Georgios Z. Papadopoulos <[email-masked]>
Date: Thu, 6 Jun 2019 14:25:52 +0200

Hi Rahul,

Please find my responses inline:

Best,
Georgios

> On Jun 5, 2019, at 02:53, Rahul Arvind Jadhav <[email-masked]> wrote:
> 

[GP] Great.
 
> [RJ] Or I could swap REQ3 and REQ2 which will make related requirements club together? But yes, I get the point of structuring things together and will update in next ver.

[GP] Yes, it also make sense.

> [RJ] Will structure this properly. Should add a separate ‘Extended-MOP Base Rules’ section (which will be Section 3.2).

[GP] Great.
 
> [RJ] MOP=7 does not represent anything today. We have added IANA consideration to reserve MOP=7. This reminds me, I need to add Extended-MOP-Value and Capabilities flag registry in the IANA conside…

[GP] I see, good.

> [RJ] Thanks for raising this. I tried to check what happens as per 6550. As per 6550 Section 6.3.1, the node can still join the network with unknown MOP as a leaf node. This might have implications…

[GP] Keep us posted if you have some news on it, please.

[GP] I see. 

> [RJ] The draft allows either or both options. Will make this explicit in next ver.

[GP] Good.