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

[Fernando Gont <[e-mail]>]

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 :-)



> -- 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?



> 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 ----

?


> 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.




> 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).

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.

?



> -- 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" :-)




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

Done.


> 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?

Thanks!

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