Re: [v6ops] draft-ietf-v6ops-slaac-renum and draft-ietf-v6ops-cpe-slaac-renum

> On May 22, 2020, at 12:06 PM, Fernando Gont <fgont@si6networks.com> wrote:
> 
> On 22/5/20 12:46, Philip Homburg wrote:
>>> In that case, how would the new CPE get its packets, anyway? I don't
>>> seem to see what you'd be "fixing" by manually extending the lifetimes.
>> I'm assume that there are and will be plenty of cases where hosts use
>> the public prefix to communicate internally, certainly if the customer
>> has a static prefix.
> 
> If the prefix is static, I wonder why you'd use DHCPv6. That said, a static prefix would be, I guess, a prefix with an infinite lifetime. So, if anything, one might consider this value as a special case -- i..e, if the DHCPv6 valid-lifetime is infinity (0xffffffff), set the RA lifetime to infinity.

Lots of ISPs use the DHCP process to trigger TACACS or RADIUS which is then used to hook in scripts that trigger things like static routes to customer CPE, etc.

Even though the prefix is very long lived, they use DHCP for configuration to reduce customer interactions required for CPE changes, etc.

>>> The recommendations in this document have to do with what the CE Router
>>> does, by default, without human intervention.
>>> 
>>> We're not precluding CE Routers to have other knobs to do other things.
>>> 
>>> So I fail to see why you say L-15 should be "relaxed". -- L-15 is not
>>> arguing that you should or should not manually configure stuff in your
>>> CE Router.
>> I assume that when RFC 2119 says about MUST NOT: 'This phrase, or the
>> phrase "SHALL NOT", mean that the definition is an absolute prohibition
>> of the specification.' it includes overrides by the user.
>> In particular when SHOULD NOT says: 'This phrase, or the phrase "NOT
>> RECOMMENDED" mean that there may exist valid reasons in particular
>> circumstances when the particular behavior is acceptable or even useful,
>> but the full implications should be understood and the case carefully
>> weighed before implementing any behavior described with this label.'
>> But maybe my interpretation is wrong.
>> BTW, I noticed that the draft does not have the boilerplate text that
>> refers to RFC 2119.
> 
> That is indeed a good point. Maybe we should copy the terminology section from RFC7084, which describes the usage of these terms in this document? Namely:
> 
> ---- cut here ----
> X.Y.  Requirements Language
> 
>   Take careful note: Unlike other IETF documents, the key words "MUST",
>   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
>   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as
>   described in RFC 2119 [RFC2119].  This document uses these keywords
>   not strictly for the purpose of interoperability, but rather for the
>   purpose of establishing industry-common baseline functionality.  As
>   such, the document points to several other specifications (preferable
>   in RFC or stable form) to provide additional guidance to implementers
>   regarding any protocol implementation required to produce a
>   successful CE router that interoperates successfully with a
>   particular subset of currently deploying and planned common IPv6
>   access networks.
> ---- cut here ----
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops