Subject: Re: [v6ops] Éric Vyncke's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT)

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 10 Feb 2021 07:38:38 +0000

Hello Fernando,

Sorry for belated reply. See in-line for EV>

I used the published -06 (dated 11th December 2020 so after the IESG evaluation) as the basis for the discussion.  The -06 is now BCP, contains the right BCP 14 boilerplate, and a Last Call has completed, so, I will clear my DISCUSS later today (but still supporting Erik Kline's DISCUSS).

Also, I wonder whether a -07 is in preparation to better fit your comments below ?
-  Suresh Krishnan's IoT directorate review:
	https://datatracker.ietf.org/doc/review-ietf-v6ops-cpe-slaac-renum-05-iotdir-telechat-krishnan-2020-10-21/ 
- Sheng Jiang's Internet directorate review: 
	https://datatracker.ietf.org/doc/review-ietf-v6ops-cpe-slaac-renum-05-intdir-telechat-jiang-2020-10-19/ 

Finally, did the authors replied to the IoT and INT directorates reviews ?

Regards

-éric

-----Original Message-----
From: Fernando Gont <[email-masked]>
Date: Thursday, 28 January 2021 at 01:17
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Owen DeLong <[email-masked]>, Suresh Krishnan <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT)

    Hi, Eric,

    It seems that I somehow failed to respond to your message in time. My 
    apologies for that. IN-line....

    On 22/10/20 08:17, Éric Vyncke via Datatracker wrote:
    [...]
    > -- Abstract --
    > I wonder why the word "IPv6" is never mentioned in the abstract while the whole
    > document is about IPv6. OTOH, perhaps the default IP version in 2020 is indeed
    > IPv6 ;-)

    I've know included it :-)

EV> Looking at the -06 version, but, I guess that -07 will contain it

    > -- Section 3 --
    > Should the L-13 of RFC 7084 be also updated ? Briefly discussed in section 3.3

    Good grief. My take is that requirement L-13 is replaced with what's 
    requirement L-17 in our document.

    So, maybe in Section 3 we should say:

    "Requirement L-13 from RFC7084 is replaced with:

        o  L-13: CE routers MUST signal stale configuration information as
           specified in Section 3.3.

    And the renumber (! :-) ) our list, so the current L-18 becomes L-17?

EV> this sounds good to me (including the renumbering ;-) )

    > I wonder what is the actual structure of this section? There are 4 L-XX
    > requirements followed by 3 subsections and mapping between L-15 with section
    > 3.1 and the same for L-16, L-17 but not for L-18 ?

    That's correct. Sections 3.1-3.3 essentially spell out the details for 
    reqs L-15-17.

    There's no much more to add, but, for the sake of consistency we could 
    add a short Section 3.4 with something like:

    ---- cut here ----
    3.4. Automatic DHCPv6 RELEASEs

    Some CE Routers are known to automatically CE send DHCPv6-PD RELEASE 
    messages upon reboot events. However, this may inadvertently trigger a 
    flash-renumbering scenario, along with the associated problems discussed 
    in [draft-ietf-v6ops-slaac-renum], that this document tries to mitigate.

    As a result, L-18 specifies that CE routers SHOULD NOT automatically 
    send DHCPv6-PD RELEASE messages upon reboot events.
    ---- cut here ----

    ?

EV>  beside the spurious 'CE' in the proposed text, I support this change as it improves the readability

    > As noted in section 3.1, L-13 is actually Section 6.3 of [RFC8415] that is
    > standard track

    How about changing:
           *  The recommendations in this section expand from requirement
              L-13 in Section 4.3 of [RFC7084].

    to

           *  The recommendations in this section expand from requirement
              L-13 in Section 4.3 of [RFC7084] and Section 6.3 of [RFC8415].

    ?

EV> actually no more required IMHO with the above change about L-13

    > 
    > -- Section 3.2 --
    > There is a reference to section 2.1 of this document but the authors probably
    > meant section 3.1 of this document or Section 6.3 of [RFC8415].

    Yep. Good grief! Fixed.

EV> ;-)

    > Should the list of ND options include by default all options ? or at least
    > indicate that this is not an exhaustive list to allow for future ND options ?

    The thing is that not all options have lifetimes. (TBH, I just looked at 
    https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 
    , and probably many of them wouldn't even apply).

EV> agreed but what about future options ?

    So I'd leave "as is", or add a parenthetical note right after the second 
    paragraph of Section 3.2 that says:

         NOTE:
         We note that the above text refers to the Neighbor Discovery Options
         that may typically be employed by CE Routers. A CE Router may need
         to apply the same policy for setting the lifetime of other Neighbor
         Discovery options it may employ, if and where applicable.

    ?

EV> this sounds good to me as it does not close the way for future options

    > -- Section 3.3 --
    > I agree with "IPv6 network renumbering is expected to take place in a planned
    > manner," but this sentence seems to contradict the premisses of
    > draft-ietf-v6ops-slaac-renum. Unsure how to reconciliate the two I-D (sharing
    > some authors ;-) ).

    At least in my mental model, the two documents are reconciliated as follows:

    "IPv6 network renumbering is expected to take place in a planned manner. 
    Now, welcome to the real world" :-)

EV> you can leave it like it is anyway, it is a NON blocking comment ;-)

    > " since we acknowledge " suggest to slightly rewrite this sentence to make it
    > less personal.

    Done.

EV> good

    > Suggestion to mention whether RA are sent only on received RS, multicasted
    > immediately (the document mention periodically), or unicasted when possible
    > (some CPE keeps the mapping of all its unicast client notably on the Wi-Fi
    > side).

    That's a good point. I wonder how to do it without getting into too much 
    detail that might e.g. override good possible behavior such as the one 
    you describe.

    I wonder if we should add to this sentence:
    "The aforementioned advertisement SHOULD be performed for at least the 
    "Valid Lifetime" previously employed for such prefix."

    Something like:
    "The CE Router MUST advertise this information with unsolicited Router 
    Advertisements as described in Section 6.2.4 of [RFC4861]. A CE Router 
    MAY advertise this information via unicast Router Advertisement, when 
    possible and applicable"

    My rationale is that the unsolicted RAs are the catch-all case. Whereas 
    the unicasted RAs are desirable.

    Thoughts?

EV> it works for me as it take into account unicast RA (used in some places as multicast RA are not reliable)

    Thanks!

    Regards,
    -- 
    Fernando Gont
    SI6 Networks
    e-mail: [email-masked]
    PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Wed, 10 Feb 2021 10:14:07 -0300

Hi, Eric,

On 10/2/21 04:38, Eric Vyncke (evyncke) wrote:
> I used the published -06 (dated 11th December 2020 so after the IESG
> evaluation) as the basis for the discussion.  The -06 is now BCP,
> contains the right BCP 14 boilerplate, and a Last Call has completed,
> so, I will clear my DISCUSS later today (but still supporting Erik
> Kline's DISCUSS).
> 

Yep. We're just awaiting for Erik Kline's response to make sure his 
comments are addressed. ONce we have double-checked that, we'll post the 
rev.

>  Finally, did the authors replied to the IoT and INT directorates

Yep. The associated changes will be incorporated in the next rev.

[....]
> Hi, Eric,
> 
> It seems that I somehow failed to respond to your message in time.
> My apologies for that. IN-line....
> 
> On 22/10/20 08:17, Éric Vyncke via Datatracker wrote: [...]
>> -- Abstract -- I wonder why the word "IPv6" is never mentioned in
>> the abstract while the whole document is about IPv6. OTOH, perhaps
>> the default IP version in 2020 is indeed IPv6 ;-)
> 

Yep. Sorry for the sloppy wording -- I should have said "in my working 
copy".

>> -- Section 3 -- Should the L-13 of RFC 7084 be also updated ?
>> Briefly discussed in section 3.3
> 

Will do.

>> I wonder what is the actual structure of this section? There are 4
>> L-XX requirements followed by 3 subsections and mapping between
>> L-15 with section 3.1 and the same for L-16, L-17 but not for L-18
>> ?
> 
> That's correct. Sections 3.1-3.3 essentially spell out the details
> for reqs L-15-17.
> 
> There's no much more to add, but, for the sake of consistency we
> could add a short Section 3.4 with something like:
> 
> ---- cut here ---- 3.4. Automatic DHCPv6 RELEASEs
> 
> messages upon reboot events. However, this may inadvertently trigger
> a flash-renumbering scenario, along with the associated problems
> discussed in [draft-ietf-v6ops-slaac-renum], that this document tries
> to mitigate.
> 
> send DHCPv6-PD RELEASE messages upon reboot events. ---- cut here
> ----
> 
> ?
> 

Great. Thanks!

>> As noted in section 3.1, L-13 is actually Section 6.3 of [RFC8415]
>> that is standard track
> 
> How about changing: *  The recommendations in this section expand
> from requirement L-13 in Section 4.3 of [RFC7084].
> 
> to
> 
> *  The recommendations in this section expand from requirement L-13
> in Section 4.3 of [RFC7084] and Section 6.3 of [RFC8415].
> 
> ?
> 
>> -- Section 3.2 -- There is a reference to section 2.1 of this
>> document but the authors probably meant section 3.1 of this
>> document or Section 6.3 of [RFC8415].
> 
> Yep. Good grief! Fixed.
> 
> EV> ;-)

FWIW, it seems that the text contained the literal "Section 2.1" rather 
than an xml -- that's why the reference had not been automatically updated.

Thanks a lot!

Regards,