[v6ops] Re: Correction: Re: Working group Last call: draft-ietf-v6ops-cpe-lan-pd

[Ted Lemon <[e-mail]>]

It's a bit challenging here. If we want to enable subdivisions longer than
64, I think we need actual protocol work, because /64 here is normative:
the proposal won't work if some other number is substituted. That is to
say, this really /is/ hard-coded into the deployment model, and I don't
think there's a way for us not to do this. We have to choose a prefix
length here. It can't be wider than /64 because that won't work in all
cases. It can't be narrower than /64 because that doesn't accomplish our
stated purpose.

So the way to fix this if we at some point reach consensus that /64 isn't
the right number is to update the document, not to try to soften the
requirement in this document.

On Thu, Aug 8, 2024 at 4:22 AM Tim Chown <Tim.Chown=
[e-mail]> wrote:

> Hi Tim,
>
>
>
> *From: *Timothy Winters <[e-mail]>
> *Date: *Wednesday, 7 August 2024 at 20:09
> *To: *Tim Chown <[e-mail]>
> *Cc: *Brian E Carpenter <[e-mail]>, Nick Buraglio <
> [e-mail]>, IPv6 Operations <[e-mail]>
> *Subject: *Re: [v6ops] Re: Correction: Re: Working group Last call:
> draft-ietf-v6ops-cpe-lan-pd
>
> Hi Tim,
>
>
>
>
>
> On Wed, Aug 7, 2024 at 7:24 AM Tim Chown <Tim.Chown=
> [e-mail]> wrote:
>
> Hi,
>
>
>
> *From: *Brian E Carpenter <[e-mail]>
> *Date: *Tuesday, 6 August 2024 at 21:53
> *To: *Nick Buraglio <[e-mail]>, IPv6 Operations <
> [e-mail]>
> *Subject: *[v6ops] Correction: Re: Working group Last call:
> draft-ietf-v6ops-cpe-lan-pd
>
> I support the draft going forward.
>
> I do have one comment on the scope of the document. I believe that it
> should also cover use of PD for a locally assigned ULA prefix. Please don't
> turn this into another endless ULA thread - but if the CE has assigned a
> ULA prefix, and supports PD for a GUA prefix, it should also support PD for
> the ULA prefix.
>
>
>
> This seems reasonable.
>
>
>
> Should /64 be hard coded in the document, or should it refer to a prefix
> of the length required to support SLAAC as currently defined?
>
> I'm concerned this will cause confusion amongst the CE Router community if
> I don't put an actual number.  If you really want we can 64 is based on the
> prefix length of SLAAC as currently defined.  How strong do you feel about
> this?
>
>
>
> Not strongly, but the WG has of late been trying not to unnecessarily hard
> code the 64 into documents. If 64 is used, then a short statement as to why
> would be good.
>
>
>
> The pd-per-device draft uses /64 in an example and says “Note that the prefix lengths used in the example are /64 because that is the prefix length currently supported by SLAAC and is not otherwise required by the proposed deployment model” and says a little more on /64 in section 8 which also refers to RFC 7084, and in section 11. The 64 isn’t “hard coded” in there, in that its use in the example is clearly explained.
>
> Minor nit – the “addresses” at the end of para 1 of the intro should
> probably say “prefixes”.
>
> thanks, fixed in -03.
>
>
>
> Best wishes,
>
> Tim
>
>
>
> Tim
>
>
>
> (There are several grammatical nits in the Introduction. I'll send them to
> the author off-list.)
>
> Regards
>      Brian Carpenter
>
> On 07-Aug-24 03:18, Nick Buraglio wrote:
> > All,
> >
> > This message begins the working group last call for
> draft-ietf-v6ops-cpe-lan-pd. Please read the draft and send your comments
> in response to this email.
> >
> > The draft can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd/ <
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd/>
> >
> > nb
> >
> > _______________________________________________
> > v6ops mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>