Re: [Roll] Datatracker State Update Notice: <draft-ietf-roll-useofrplinfo-23.txt>

[Alvaro Retana <[e-mail]>]

On January 23, 2019 at 5:06:24 PM, Ines Robles (
[e-mail]) wrote:

[Explicitly adding the Chairs, the Shepherd and the Authors’ alias…just for
completeness, even though everyone should be in the WG list and there’s
overlap. ;-)  ]

Ines:

Hi!

I have some comments below, please take a look.  Many of these comments are
minor and nits — the significant items that I think we should settle on
before starting the IETF LC are:

- “normative examples” (point #1 below): I’ll let you chose how you want to
move forward (see below)
- Operational Considerations (§9) is WIP
- dependency on I-D.thubert-roll-unaware-leaves (look for line 894)

Thanks!!

Alvaro.


...

(1) [major] Where is the specification of the data-plane behavior?


> This document does a couple of things: it Updates several other RFCs, and
> presents a list of *example* flows where the expected behavior is
> illustrated.  The Updates are mostly about the new RPI value (0x23), but
> not about the behavior of the nodes.
>
> Most of the examples are worded such that they describe actions
> (encapsulate, remove, etc.)...and some even include rfc2119 Normative
> Keywords.  But they are called examples!  So...my questions are: is the
> behavior illustrated in §6 and §7 intended to be Normative?



[authors]The examples are intended to illustrate the result of the
normative language in RFC8200 and RFC6553.
So the examples are intended to be normative explanation of the results of
executing that language.



> IOW, do these sections include both examples and specify the behavior
> expected in the LLN?  Is the behavior already specified somewhere else (and
> this document is just illustrating)?


[authors]The normative language is in RFC8200 (ipv6bis) section 4.2 and
section 4, “The Hop-by-Hop Options…”
Combined with the desired results of  RFC6553, we conclude that we have to
change the option value in order to make things work.

I understand what you’re trying to do.
To me, a “Normative example” is an impossible oxymoron: it’s either an
example or it is a Normative specification of the behavior.

In this document, the scenarios (maybe a better word than example,
specially given how exhaustive the document is in considering all the
possibilities) are not consistently treated as not all of them are
described using Normative language.  Being consistent is *very* important
given that we’re dealing with Normative language...

**But** my heartburn really flares up when you mention "the normative
language in RFC8200...” because rfc8200 doesn’t use rfc2119 keywords at
all. :-(  The use of rfc2119 language is a completely separate discussion,
but using it here as an interpretation of what is meant in rfc8200 is a
stretch…at least to me.

What do I want to see?  I would prefer to see the scenarios described NOT
using rfc2119 keywords: simply changing the case would be enough.

I don’t want to turn this review into a debate around rfc2119 and much less
about how to interpret rfc8200.  If you really, really prefer to keep the
Normative language, please be consistent (use it in all the scenarios).  We
can see if anyone else in the IESG picks up on this same point or not…

...

(2) [major] Operational Considerations
>
> Non-storing mode networks don't need the change to 0x23 (§8.2)...but
> making the change creates a flag day, and even then, implementations should
> still process both values (§3.1).  I would really like to see text about
> the operational considerations of introducing 0x23.  It concerns me that a
> significant change that most[*] networks don't need is being introduced.
> Please take a look at rfc5706 (Guidelines for Considering Operations and
> Management of New Protocols and Protocol Extensions), specially §2.
>
> [*] Most deployed networks work in non-storing mode, right?
>

[authors]following our understanding, mostly yes.
but, e.g. Anima network in storing mode. Not having loop detection.
https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-18#section-6.11.1.3


Thanks for including Operational Considerations.  §8 looks good to me…and I
see that §9 is still WIP.


...

[nit] I think the Introduction would benefit from an overview of the
> document; something like "section X talks about abc, section Y presents
> examples, etc.".


[authors]added

This new section mentions the old §9.


...

187   Flag day: A "flag day" is a procedure in which the network, or a part
> 188   of it, is changed during a planned outage, or suddenly, causing an
> 189   outage while the network recovers [RFC4192]
>
> [nit] rfc4192 seems like an odd place to pull a reference to "flag day" --
> specially as it is being defined as "a procedure" and not the effect it
> causes, which seems to be how it is used in the text: "creates a flag day",
> "will experience a flag day", "avoid a flag day".  This is not a big issue
> -- if it was up to me, I would either make my own definition, or just not
> define it at all: I think it is a well known term...
>

[authors]fixed. rewritten

New text:

217	   Flag Day: A transition that involves have a network with different
218	   values of RPL Option Type.  Thus the network do not work correctly.

s/involves have a network/involves having a network

s/network do not work/network does not work

Also, the reference to rfc4192 is not needed anymore.

...

...

266   When forwarding packets, implementations SHOULD use the same value as
> 267   it was received (This is required because, RPI type code can not be
> 268   changed by [RFC8200]).  It allows to the network to be incrementally
> 269   upgraded, and for the DODAG root to know which parts of the network
> 270   are upgraded.
>
> [major] There seems to be a contradiction above: "SHOULD use the same
> value...this is required..."   If required by rfc8200, why not use MUST?
>
[authors]rewritten

>
> 272   When originating new packets, implementations SHOULD have an option
> 273   to determine which value to originate with, this option is controlled
> 274   by the DIO option described below.
>
> [minor] §3.3 defines the option...but it doesn't explicitly say what the
> receivers should do with it.  It may be obvious, but it should be explicit
> for completeness.
>
[authors]rewritten

>
> [major] It seems to me that the paragraph above may be out of place,
> doesn't say much, may be wrong...or maybe all 3.  The text says that the
> originating value is controlled by the option in §3.3 (again, but that
> section doesn't explicitly say what should be done)...but it also says
> (with the SHOULD) that an implementation may have valid reasons to not pay
> attention to the option -- what are those??
>

[authors]rewritten to
"In the cases where a forwarding node is forwarding traffic that is not
           addressed directly to it (such as when the outer IPv6-in-IPv6
header is not a Link-Local address),
           then RFC8200 forbids changing the RPI type code when forwarding.

           When forwarding traffic that is wrapped in Link-Local
IPv6-in-IPv6 headers,
           the forwarding node is in effect originating new packets,
           and it MAY make a choice as to whether to use the old (0x63) RPI
Type code,
           or the new (0x23) RPI Type code. In that situation,
implementations SHOULD
           use the same value as was received.  This allows to the network
to be incrementally upgraded,
           and in some cases may allow the DODAG root to know which parts
of the network are upgraded."

Ok, that looks good.

You also added:

323	   Non-constrained uses of RPL are not in scope of this document, and
324	   applicability statements for those uses MAY provide different advice,
325	   E.g.  [I-D.ietf-anima-autonomic-control-plane].

If out of scope, don’t use Normative language there.

...

613             Figure 7: IP-in-IP encapsulation in Storing mode.



[nit] The table above is called Figure… There are also some Tables.  Maybe
be consistent about what is called a Table and what is called a Figure.
Personally, I don’t care…I just would prefer consistency.

...

894   Note that there is a requirement that the final node be able to

895   remove one or more IP-in-IP headers which are all addressed to it,
> 896   mentioned in [I-D.thubert-roll-unaware-leaves] :
>
> 898   "RPL data packets are often encapsulated using IP in IP.  The 6LN
> 899   MUST be able to decapsulate a packet when it is the destination of
> 900   the outer header and process correctly the inner header."
>
> [major] I realize that we're not reviewing I-D.thubert-roll-unaware-leaves
> at this point, but how can a requirement be placed on a not-RPL-aware-leaf
> if, by definition, it is not aware of RPL??   ...and I don't think we can
> assume it is aware of any other requirement...
>
[authors] We understand that the requirements are placed on the 6LR that
accepts the 6LN
   registration and also inject the relevant routing information on its
behalf.

The text above talks abut the 6LN, not the 6LR.

If this document depends on the requirement in
> I-D.thubert-roll-unaware-leaves, then the reference should be Normative (it
> is now listed as Informative).
>
[authors]fixed

I still don’t feel too good about depending on requirements for
not-RPL-aware nodes in the network…. In this case, this document will not
be able to be published as an RFC until that *individual* draft is
published.  Is that what you want?  Is there any way to work around this
dependency?  Why isn’t rfc8200 support enough in this case?


...

1194 7.1.1.  Non-SM: Example of Flow from RPL-aware-leaf to root
>
> 1196   In non-storing mode the leaf node uses default routing to send
> 1197   traffic to the root.  The RPI header must be included to
> avoid/detect
> 1198   loops.
>
> [major] Should that "must" be Normative?
>
[authors] fixed.

1322	   In non-storing mode the leaf node uses default routing to send
1323	   traffic to the root.  The RPI header MUST be included since contains
1324	   the rank information, which is used to avoid/detect loops.

s/be included since contains/be included since it contains


...

1254 7.1.3.  Non-SM: Example of Flow from root to not-RPL-aware-leaf

...
> 1267   In 6LBR the RH3 is added, it is modified at each intermediate 6LR
> 1268   (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n),
> 1269   but left there.  If RPI is left present, the IPv6 node which does
> not
> 1270   understand it will ignore it (following RFC8200), thus encapsulation
> 1271   is not necesary.  Due the complete knowledge of the topology at the
> 1272   root, the 6LBR may optionally address the IP-in-IP header to the
> last
> 1273   6LR, such that it is removed prior to the IPv6 node.
>
> s/necesary/necessary
>
> [major] So...encapsulation is not needed, but an IP-in-IP header is
> optional.  When?  Are there advantages, disadvantages?   Same questions
> about the RPI.
>
[authors]rewritten.

s/Due the complete/Due to the complete


...

1731 9.  6LoRH Compression cases


> 1733   The [RFC8138] proposes a compression method for RPI, RH3 and
> IPv6-in-
> 1734   IPv6.
>
> 1736   In Storing Mode, for the examples of Flow from RPL-aware-leaf to
> non-
> 1737   RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise
> 1738   an IP-in-IP and RPI compression headers.  The type of this case is
> 1739   critical since IP-in-IP is encapsulating a RPI header.
>
> 1741
>  +--+-----+---+--------------+-----------+-------------+-------------+
> 1742   |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC
> |
> 1743
>  +--+-----+---+--------------+-----------+-------------+-------------+
>
> 1745                    Figure 9: Critical IP-in-IP (RPI).
>
> [major] Shouldn't this section also be an Update to rfc8138?
>
> [major] 6LoRH Type 6 is defined in rfc8138 as an elective type, but it is
> introduced as Critical here.  The header must then be completely specified
> in this document and the appropriate registry must be updated (in the IANA
> Consideration section).
>
> Specifically...referring to rfc8138...
>    - the meaning of the TSE depends on the Type (§4.2),
>    - the Hop Limit is defined in §7, should it have the same
> behavior/meaning here?
>    - does the "RPI - 6LoRH" field correspond to the RPI-6LoRH header
> (§6.3)?
>    - I'm assuming that the "LOWPAN IPHC" field refers to LOWPAN_IPHC
> (rfc6282).
>

[authors] we think that the confusion is because we wrote: “The type of
this case”...
which sounds like we are changing 8138, when what we mean is that use of
this elective type is a MUST for RPL.
Type 6 (compressed RPI) is elective in 8138 because non-RPL uses of 6lowpan
do not
need to support (compressed) RPI headers, but this document makes it a MUST
because
RPL uses of 6lowpan need it. Is there text that we need to update?

I see that you moved this text to §3.2.  The Figure (now 3) is still
labeled as “critical”.


...
> 1774 11.  Security Considerations


Your responses to trisection indicated several times “Discussion on the
list”, but I could’t find those discussions.  Did they happen already?

I would prefer it if the document has mitigation suggestions (at least) in
it; that usually makes the SecDir happier. ;-)  But that is not an absolute
requirement before moving this document forward.

...

[major] What does "SHOULD be suspicious" mean?  How is that a Normative
> behavior?  Would being suspicious include dropping the packet or some other
> similar action?  When would the router *not* be suspicious?  Why is that
> not a "MUST"?


[authors]The presence of the second RH3 means that there is a configuration
 mistake somewhere else in the network.  It would be reasonable to increment
  a counter in a MIB (if we had a MIB) when this occurs.  Based upon the
Postel
   doctrine, ignoring the extra header (not acting on it), is the best
policy.
    An RH3 header was not completely consumed is discussed in RFC

https://tools.ietf.org/html/rfc6554#section-4.2 says that an RH3 header with
 additional “non-zero Segments Left value, if the IPv6 Destination Address
is
  not on-link” should be dropped.  In this case, the RH3 header is *inside*
  the outer IPv6-in-IPv6 header, which has then been forwarded.
We think that this header should simply be ignored in processing the packet.
 To do otherwise (such as forwarding) would permit external attackers to
send
 traffic that appears to originate inside the LLN.

 To be discussed on list

Ok…whatever the outcome is, to “be suspicious” is not something that can be
enforced normatively.  SHOULD log and error, etc..is something actionable.