Skip to content

Commit

Permalink
Barry Leiba's No Objection on draft-ietf-roll-turnon-rfc8138-11: (wit…
Browse files Browse the repository at this point in the history 
…h COMMENT)

Hello Barry

Many thanks for your time and review. This is always appreciated : )

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Just a couple of very minor comments:
>
> “RPL” should be expanded on first use.
> We should probably ask the RFC Editor to mark “DAG” and “DODAG” as “well
> known”, but they are not yet so marked, so “DODAG” should be expanded on
> first use.

Yes, I expanded a bit the introduction.
Th efirst 2 paragraphs now say
"
   The design of Low Power and Lossy Networks (LLNs) is generally
   focused on saving energy, which is the most constrained resource of
   all.  The routing optimizations in the "Routing Protocol for Low
   Power and Lossy Networks" [RFC6550] (RPL) such as routing along a
   Destination-Oriented Directed Acyclic Graph (DODAG) to a Root Node
   and the associated packet compression technique [RFC8138] derive from
   that primary concern.

   Enabling [RFC8138] requires a Flag Day where the network is upgraded
   and rebooted.  Otherwise, if acting as a Leaf, a node that does not
   support the compression would fail to communicate; if acting as a
   router it would drop the compressed packets and black-hole a portion
   of the network.  This specification enables a hot upgrade where a
   live network is migrated.  During the migration, the compression
   remains inactive, until all nodes are upgraded.

"

> — Section 5.3 —
>
>    It is RECOMMENDED to only deploy nodes that support [RFC8138] in a
>    network where the compression is turned on.
>
> I think I misread this the first time; it’s ambiguous, so please reword it to make
> this clear.  What is it that’s recommended?: 1. In a network where compression
> is turned on, only deploy nodes that support 8138? 2. Don’t deploy nodes that
> support 8138 unless compression is turned on?

The former, 1. Interestingly, you used the same words. This is hitting my limits as a non-native.
I changed to the double negative that I wanted to avoid, hoping it is more readable in the end:
"
   Nodes that do not support [RFC8138] SHOULD NOT be deployed in a
   network where the compression is turned on.  If that it done, the
   node [RFC8138] can only operate as a RUL.
"

>
> — Section 7 —
>
>    An attacker in the middle of the network may reset the "T" flag
>
> Thank you for this phrasing; I like it.
>

I got help. Help is good.

Take care,

Pascal
  • Loading branch information
@pthubert
pthubert committed Sep 2, 2020
1 parent 1384773 commit 1832573
Show file tree
Hide file tree
Showing 2 changed files with 67 additions and 68 deletions.
90 changes: 45 additions & 45 deletions roll-turnon-rfc8138.txt
View file
Expand Up @@ -5,12 +5,12 @@
ROLL P. Thubert, Ed.
Internet-Draft L. Zhao
Updates: 8138 (if approved) Cisco Systems
Intended status: Standards Track 28 August 2020
Expires: 1 March 2021
Intended status: Standards Track September 2, 2020
Expires: March 6, 2021


A RPL DODAG Configuration Option for the 6LoWPAN Routing Header
draft-ietf-roll-turnon-rfc8138-11
draft-ietf-roll-turnon-rfc8138-12

Abstract

Expand All @@ -34,7 +34,7 @@ Status of This Memo
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 1 March 2021.
This Internet-Draft will expire on March 6, 2021.

Copyright Notice

Expand All @@ -53,9 +53,9 @@ Copyright Notice



Thubert & Zhao Expires 1 March 2021 [Page 1]
Thubert & Zhao Expires March 6, 2021 [Page 1]

Internet-Draft Turn On 6LoRH August 2020
Internet-Draft Turn On 6LoRH September 2020


Table of Contents
Expand All @@ -80,25 +80,27 @@ Table of Contents

1. Introduction

The packet compression technique defined in [RFC8138] can only be
activated in a RPL [RFC6550] network when all the nodes support it.
Otherwise, if acting as a leaf, a node that does not support the
compression would fail to communicate; if acting as a router it would
drop the compressed packets and black-hole a portion of the network.
The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is the most constrained resource of
all. The routing optimizations in the "Routing Protocol for Low
Power and Lossy Networks" [RFC6550] (RPL) such as routing along a
Destination-Oriented Directed Acyclic Graph (DODAG) to a Root Node
and the associated packet compression technique [RFC8138] derive from
that primary concern.

Enabling [RFC8138] requires a Flag Day where the network is upgraded
and rebooted. Otherwise, if acting as a Leaf, a node that does not
support the compression would fail to communicate; if acting as a
router it would drop the compressed packets and black-hole a portion
of the network. This specification enables a hot upgrade where a
live network is migrated. During the migration, the compression
remains inactive, until all nodes are upgraded.

The original idea was to use a flag day but that proved impractical
in a number of situations such as a large metering network that is
used in production and incurs financial losses when interrupted.

This specification is designed for the scenario where a live network
is upgraded to support [RFC8138]. During the migration, the
compression should remain inactive, until all nodes are upgraded.
This document complements [RFC8138] and dedicates a flag in the RPL
DODAG Configuration Option to indicate whether the [RFC8138]
compression should be used within the RPL DODAG.

The setting of this new flag is controlled by the Root and propagates
as is in the whole network as part of the normal RPL signaling.
compression should be used within the RPL DODAG. The setting of this
new flag is controlled by the Root and propagates as is in the whole
network as part of the normal RPL signaling.

The flag is cleared to maintain the compression inactive during the
migration phase. When the migration is complete (e.g., as known by
Expand All @@ -107,11 +109,9 @@ Table of Contents





Thubert & Zhao Expires 1 March 2021 [Page 2]
Thubert & Zhao Expires March 6, 2021 [Page 2]

Internet-Draft Turn On 6LoRH August 2020
Internet-Draft Turn On 6LoRH September 2020


2. Terminology
Expand Down Expand Up @@ -165,9 +165,9 @@ Internet-Draft Turn On 6LoRH August 2020



Thubert & Zhao Expires 1 March 2021 [Page 3]
Thubert & Zhao Expires March 6, 2021 [Page 3]

Internet-Draft Turn On 6LoRH August 2020
Internet-Draft Turn On 6LoRH September 2020


2.3. Requirements Language
Expand Down Expand Up @@ -221,9 +221,9 @@ Internet-Draft Turn On 6LoRH August 2020



Thubert & Zhao Expires 1 March 2021 [Page 4]
Thubert & Zhao Expires March 6, 2021 [Page 4]

Internet-Draft Turn On 6LoRH August 2020
Internet-Draft Turn On 6LoRH September 2020


4. Updating RFC 8138
Expand Down Expand Up @@ -277,9 +277,9 @@ Internet-Draft Turn On 6LoRH August 2020



Thubert & Zhao Expires 1 March 2021 [Page 5]
Thubert & Zhao Expires March 6, 2021 [Page 5]

Internet-Draft Turn On 6LoRH August 2020
Internet-Draft Turn On 6LoRH September 2020


5.1. Coexistence
Expand Down Expand Up @@ -327,15 +327,15 @@ Internet-Draft Turn On 6LoRH August 2020
in the network. To that effect, whether the compression is active in
a node SHOULD be exposed the node's management interface.

It is RECOMMENDED to only deploy nodes that support [RFC8138] in a
network where the compression is turned on. A node that does not
support [RFC8138] MUST only be used as a RUL.
Nodes that do not support [RFC8138] SHOULD NOT be deployed in a
network where the compression is turned on. If that it done, the
node [RFC8138] can only operate as a RUL.



Thubert & Zhao Expires 1 March 2021 [Page 6]
Thubert & Zhao Expires March 6, 2021 [Page 6]

Internet-Draft Turn On 6LoRH August 2020
Internet-Draft Turn On 6LoRH September 2020


6. IANA Considerations
Expand All @@ -357,7 +357,7 @@ Internet-Draft Turn On 6LoRH August 2020
It is worth noting that with RPL [RFC6550], every node in the LLN
that is RPL-aware can inject any RPL-based attack in the network.
This document applies typically to an existing deployment and does
not change its security requirements and settings. It is assumed
not change its security requirements and operations. It is assumed
that the security mechanisms as defined for RPL are followed.

Setting the "T" flag before all routers are upgraded may cause a loss
Expand Down Expand Up @@ -389,9 +389,9 @@ Internet-Draft Turn On 6LoRH August 2020



Thubert & Zhao Expires 1 March 2021 [Page 7]
Thubert & Zhao Expires March 6, 2021 [Page 7]

Internet-Draft Turn On 6LoRH August 2020
Internet-Draft Turn On 6LoRH September 2020


8. Acknowledgments
Expand Down Expand Up @@ -439,15 +439,15 @@ Internet-Draft Turn On 6LoRH August 2020
[UNAWARE-LEAVES]
Thubert, P. and M. Richardson, "Routing for RPL Leaves",
Work in Progress, Internet-Draft, draft-ietf-roll-unaware-
leaves-18, 12 June 2020, <https://tools.ietf.org/html/
leaves-18, June 12, 2020, <https://tools.ietf.org/html/
draft-ietf-roll-unaware-leaves-18>.




Thubert & Zhao Expires 1 March 2021 [Page 8]
Thubert & Zhao Expires March 6, 2021 [Page 8]

Internet-Draft Turn On 6LoRH August 2020
Internet-Draft Turn On 6LoRH September 2020


10. Informative References
Expand All @@ -468,7 +468,7 @@ Internet-Draft Turn On 6LoRH August 2020
Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", Work in
Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-40,
25 June 2020, <https://tools.ietf.org/html/draft-ietf-
June 25, 2020, <https://tools.ietf.org/html/draft-ietf-
roll-useofrplinfo-40>.

Authors' Addresses
Expand Down Expand Up @@ -501,4 +501,4 @@ Authors' Addresses



Thubert & Zhao Expires 1 March 2021 [Page 9]
Thubert & Zhao Expires March 6, 2021 [Page 9]
45 changes: 22 additions & 23 deletions roll-turnon-rfc8138.xml
View file
Expand Up @@ -13,7 +13,7 @@
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr='trust200902' tocInclude="true" obsoletes="" updates="8138" consensus="true" submissionType="IETF" xml:lang="en" version="3" docName="draft-ietf-roll-turnon-rfc8138-11">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr='trust200902' tocInclude="true" obsoletes="" updates="8138" consensus="true" submissionType="IETF" xml:lang="en" version="3" docName="draft-ietf-roll-turnon-rfc8138-12">
<front>

<title abbrev='Turn On 6LoRH'>A RPL DODAG Configuration Option for the 6LoWPAN Routing Header</title>
Expand Down Expand Up @@ -67,28 +67,27 @@

<middle>
<section><name>Introduction</name>
<t>
The packet compression technique defined in <xref target='RFC8138'/> can
only be activated in a RPL <xref target='RFC6550'/> network when all the
nodes support it. Otherwise, if acting as a leaf, a node that does not
support the compression would fail to communicate; if acting as a router
it would drop the compressed packets and black-hole a portion of the
network.
</t>
<t>
The original idea was to use a flag day but that proved impractical in a
number of situations such as a large metering network that is used in
production and incurs financial losses when interrupted.

<t>
The design of Low Power and Lossy Networks (LLNs) is generally focused on
saving energy, which is the most constrained resource of all. The routing
optimizations in the <xref target='RFC6550'>"Routing Protocol for Low Power
and Lossy Networks"</xref> (RPL) such as routing along a
Destination-Oriented Directed Acyclic Graph (DODAG) to a Root Node and the
associated packet compression technique <xref target='RFC8138'/> derive
from that primary concern.
</t>
<t>
Enabling <xref target='RFC8138'/> requires a Flag Day where the network is
upgraded and rebooted. Otherwise, if acting as a Leaf, a node that does not
support the compression would fail to communicate; if acting as a router it
would drop the compressed packets and black-hole a portion of the network.
This specification enables a hot upgrade where a live network is migrated. During the migration, the compression remains inactive, until all nodes are upgraded.
</t>
<t>
This specification is designed for the scenario where a live network is
upgraded to support <xref target='RFC8138'/>. During the migration, the
compression should remain inactive, until all nodes are upgraded.
This document complements <xref target='RFC8138'/> and dedicates a flag in
This document complements <xref target='RFC8138'/> and dedicates a flag in
the RPL DODAG Configuration Option to indicate whether the
<xref target='RFC8138'/> compression should be used within the RPL DODAG.
</t>
<t>
The setting of this new flag is controlled by the Root and propagates as
is in the whole network as part of the normal RPL signaling.
</t>
Expand Down Expand Up @@ -373,9 +372,9 @@
</t>

<t>
It is RECOMMENDED to only deploy nodes that support <xref target='RFC8138'/>
in a network where the compression is turned on. A node that does not support
<xref target='RFC8138'/> MUST only be used as a RUL.
Nodes that do not support <xref target='RFC8138'/> SHOULD NOT be deployed
in a network where the compression is turned on. If that it done, the node
<xref target='RFC8138'/> can only operate as a RUL.
</t>

</section> <!-- Rolling Back -->
Expand Down Expand Up @@ -424,7 +423,7 @@
It is worth noting that with RPL <xref target='RFC6550'/>, every node in the
LLN that is RPL-aware can inject any RPL-based attack in the network.
This document applies typically to an existing deployment and does not change
its security requirements and settings.
its security requirements and operations.
It is assumed that the security mechanisms as defined for RPL are followed.

<!--
Expand Down

0 comments on commit 1832573

Please sign in to comment.