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

[Timothy Winters <[e-mail]>]

Hi v6ops,

I have made all the agreed upon changes from WGLC.

https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-lan-pd/05/

Happy to discuss the next steps at IETF-120.

~Tim

On Mon, Aug 12, 2024 at 6:02 PM Ted Lemon <[e-mail]> wrote:

> Yes, we can do that, but that can lead to Xeno’s paradox if the upstream
> doesn’t renew that prefix: each renewal is for a shorter and shorter time,
> so as we get close to the end most of the traffic on the link is dhcp
> renewals.
>
> I think if we get to T2 and don’t have a renewal, we can’t renew
> downstream.
>
> Op ma 12 aug 2024 om 16:15 schreef Timothy Winters <[e-mail]>
>
>> Hi Ted,
>>
>>
>>
>> On Mon, Aug 12, 2024 at 11:15 AM Ted Lemon <[e-mail]> wrote:
>>
>>> Mow that you mention is, it does seem like a gap not to specify how the
>>> isp lifetime and dependent router lifetime interact.
>>>
>>> For example, it’s probably worth making sure we don’t get into a Xeno’s
>>> paradox situation with the downstream lease, because the remaining lifetime
>>> isn’t constant and hence the lifetime of the downstream lease could always
>>> be shorter than the lifetime of the prefix provided by the ISP. However,
>>> specifying that would complexify the document a bit.
>>>
>>> But the main point is that I can think of several ways to choose the
>>> lifetime of the downstream lease based on the current text, and that’s not
>>> good. :)
>>>
>> Ted, one idea is we can borrow this text from the CPE Renumbering draft
>> with a twist.
>>
>> LPD-X: IPv6 CE routers MUST NOT advertise prefixes via delegate prefixes
>> via DHCPv6 on the LAN side using lifetimes that exceed the remaining
>> lifetimes of the corresponding prefixes learned on the WAN side via
>> DHCPv6-PD. For more details, see 9096 Section 3.3
>> <https://datatracker.ietf.org/doc/html/rfc9096#section-3.3>.
>>
>>
>>> Op ma 12 aug 2024 om 10:29 schreef Jen Linkova <[e-mail]>
>>>
>>>> Hi Tim,
>>>>
>>>> Sorry, coming late to the party (..again...;( )
>>>>
>>>> On Fri, Aug 9, 2024 at 4:36 AM Timothy Winters <[e-mail]> wrote:
>>>> > LPD-7:
>>>> > The IPv6 CE Router MUST provision IA_PD prefixes with a prefix-length
>>>> of 64 unless configured to different prefix-length by the user. The prefix
>>>> length of 64 is used as that is the current prefix length supported by
>>>> SLAAC.
>>>>
>>>> While I do not have a strong opinion on that, I think that maybe
>>>> saying smth like 'MUST provision....a prefix length suitable for SLAAC
>>>> (currently /64)' would be better...
>>>>
>>>> I read the text you have in -04 as 'the router MUST provide /64 (btw
>>>> we chose that number because it's the current value for SLAAC)', so
>>>> the value is still hardcoded, so if we ever change the SLAAC prefix
>>>> length, this document would still require an update.
>>>>
>>>> What do you think?
>>>>
>>>> A few more comments:
>>>>
>>>> 1) shall the draft say anything about a flash renumbering/the change
>>>> of the delegated prefix?
>>>> LPD-3 allows the onlink prefix change if the topology or config
>>>> changes, but what about the pool? Would it be too much to ask for a
>>>> reconfigure message to be sent?
>>>> 2) is it assumed that T1/T2 values are consistent with T1/T2 received
>>>> from the ISP?
>>>> 3) It's been mentioned already, I believe, that the draft updates 7084
>>>> but there is no update text. In particular, I think, it needs to
>>>> update  WPD-5 to include packets to delegated prefixes.
>>>>
>>>>
>>>> > On Thu, Aug 8, 2024 at 2:15 PM Ted Lemon <[e-mail]> wrote:
>>>> >>
>>>> >> What happened to the updates we talked about earlier (e.g., MUST,
>>>> and explaining what "by default" means)? :)
>>>> >>
>>>> >> I'm otherwise okay with this text though.
>>>> >>
>>>> >> On Thu, Aug 8, 2024 at 2:04 PM Timothy Winters <[e-mail]>
>>>> wrote:
>>>> >>>
>>>> >>> Hi Tim,
>>>> >>>
>>>> >>> I can get on board with that.
>>>> >>>
>>>> >>> OLD:
>>>> >>>    LPD-7:  The IPv6 CE Router SHOULD by default provision IA_PD IA
>>>> prefixes with a prefix-length of 64.
>>>> >>>
>>>> >>> New:
>>>> >>>    LPD-7:  The IPv6 CE Router SHOULD by default provision IA_PD IA
>>>> prefixes with a prefix-length of 64. The prefix length of 64 is
>>>> >>>    used as that is the current prefix length supported by SLAAC.
>>>> >>>
>>>> >>> ~Tim
>>>> >>>
>>>> >>> On Thu, Aug 8, 2024 at 4:22 AM 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]
>>>> >
>>>> > _______________________________________________
>>>> > v6ops mailing list -- [e-mail]
>>>> > To unsubscribe send an email to [e-mail]
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers, Jen Linkova
>>>>
>>>