Re: [v6ops] New Version Notification for draft-collink-v6ops-ent64pd-01.txt

----
nb

On Mon, Dec 19, 2022 at 2:08 AM Vasilenko Eduard <vasilenko.eduard=
40huawei.com@dmarc.ietf.org> wrote:

> It would need standardization. But why not?
> Despite that the proposed solution is all about "local code", it is a big
> change anyway.
> A little more change, a little less -> it does not matter.
>
> Let's think about what could be the value of additional singling in both
> directions.
>
> Keep in mind that with the proposed solution, we could have situations:
> 1. Only routers support it
> 2. Only some hosts support it
> 3. All routers and some hosts support it
> 4. All nodes support the new solution
>

Isn't this the case with literally any change to the protocol?  There is
always going to be a sliding window of patching and / or hardware and
software updates.

> If hosts would not receive signaling that routers support the new solution
> (flag?),
> then hosts could save messages for DHCP requests to non-supportive routers.
> This signaling would become redundant (flag wasted) after all routers
> would support the new solution.
>
> If the router would not receive the information from some host that it
> supports the new solution (new option?),
> Then the router needs to reserve a separate /64 for SLAAC (for outdated
> hosts) and announce PIO for the such host.
> It could not save /64 prefix because the router should have this prefix
> reserved by the administrator upfront anyway.
> It has a small value to save on PIO announcements but RA would be needed
> anyway to show "default router status".
> In the future, this optimization would happen automatically because the
> admin would not provide the prefix for SLAAC.
>
> Conclusion (IMHO):
> 1. not very valuable standardization (not much to save, temporary
> savings), but possible.
> 2. in both cases it is not good that the other side makes the conclusion
> not on the presence of the signal but on the absence.
> It would look ridiculous in the far future after the Enterprise market
> transition (after people would forget what was SLAAC).
> They would be asking: why we are sending these flag (from the router) and
> option (from the host)?
>
> Ed/
> -----Original Message-----
> From: Fred Baker [mailto:fredbaker.ietf@gmail.com]
> Sent: Monday, December 19, 2022 7:19 AM
> To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
> Cc: Jen Linkova <furry13@gmail.com>; V6 Ops List <v6ops@ietf.org>;
> draft-collink-v6ops-ent64pd@ietf.org; xiaom@google.com
> Subject: Re: [v6ops] New Version Notification for
> draft-collink-v6ops-ent64pd-01.txt
>
>
>
> > On Dec 15, 2022, at 6:23 AM, Vasilenko Eduard <vasilenko.eduard=
> 40huawei.com@dmarc.ietf.org> wrote:
> >
> > 1.    What is the point to keep SLAAC if DHCP infrastructure is
> mandatory?
>
> What I might suggest is to make SLAAC normal (as s the current case, e.g.,
> retaining backward compatibility) and provide a way to tell hosts that they
> should request a prefix via DHCP-PD.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>