Re: [Roll] Opsdir last call review of draft-ietf-roll-turnon-rfc8138-10

["Nagendra Kumar Nainar (naikumar)" <[e-mail]>]

Hi Pascal,

The changes are fine.

Regards,
Nagendra

On 8/18/20, 10:03 AM, "Pascal Thubert (pthubert)" <[e-mail]> wrote:

    Hello Nagendra

    Many thanks for your review!

    Let's see below:



    > --> Section 3 assigns a bit from the Configuration Options. This flag
    > --> field is
    > instructed by RFC6550 to set to zero and should be ignored by the receiver. So
    > I think this draft should also update RFC6550 (in addition to RFC 8138).

    This looked reasonable, and we did that till version 7 (https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-07).
    It was our A-D comment that this was not actually an update. Quote from Alvaro in his "AD Review of draft-ietf-roll-turnon-rfc8138-07" on July 1st:
    "

    155	3.  Updating RFC 6550

    [major] I don't think that a formal Update to rfc6550 is necessary.
    In general, a formal Update indicates (at least to me) that an rfc6550 implementation has to also support this specification.  IOW, all RPL routers will have to support the new flag to be compliant with rfc6550.  Also, rfc8138 did not formally Update rfc6550.

    "

    > 
    > --> I understand that the T flag is mentioned as bit position 2 in section 6.
    > AFAIK, bit position may start from 0 and can be LSB/MSB. To avoid confusing
    > (and any interop issues), I think the flag can be clarified in Fig 1 (or by just
    > defining another figure with the updated flag field).

    I just added it based on the same comment by Stewart. It was not there so far because IANA did not confirm the bit position, now they did.


    > 
    > A node SHOULD source packets in the compressed form using [RFC8138]
    >    if and only if the "T" flag is set.  This behaviour can be overridden
    >    by e.g., configuration or network management.
    > 
    > --> It appears that the above overriding exception can be interpreted as
    > --> either
    > of the below:
    > 
    > Opt1 - A config knob can be used to let a node source packets in [RFC8138]
    > compressed form  even if T flag is not set. Opt2 - A config knob can be used to
    > let a node source packets without compression even if T flag is set.

    Both are valid. The next sentence says
    "
                                                                                            Overriding may be
       needed e.g., to cope with a legacy implementation of the Root that
       supports [RFC8138] but not this specification and cannot set the "T"
       flag.
    "
    This is a case where RFC 8138 can be used but the T flag cannot be set, so it is an example of opt1.

    > 
    > Further section 5.2 mentions the below:
    > 
    > "To ensure that a packet is forwarded across the RPL DODAG in the form
    >    in which it was generated, it is required that all the RPL nodes
    >    support [RFC8138] at the time of the switch."
    > 
    > So I assume that the config exception is applicable only for Opt2?. I think it is
    > good to clarify the same to avoid any misinterpretation.

    There is text that indicates that in a transition phase there will be packets in both forms. 
    The forwarding routers thus need to forward both forms. So all routers must support RFC8138.

    Proposed change:
    "
       A node SHOULD generate packets in the compressed form using [RFC8138]
       if and only if the "T" flag is set.  This behavior can be overridden
       by configuration or network management.  Overriding may be needed
       e.g., to turn on the compression in a network where all nodes support
       [RFC8138] but the Root does not support this specification and cannot
       set the "T" flag, or to disable it locally in case of a problem.

    "

    The resulting changes are visible at 
    https://github.com/roll-wg/roll-turnon-rfc8138/commit/5aee34e2ea2ccacd77df278638199b178d9bb2c7
    and the full text is 
    https://github.com/roll-wg/roll-turnon-rfc8138/blob/master/roll-turnon-rfc8138.txt

    Please let me know if we need more work.

    Many thanks again, Nagendra!

    Pascal