[dhcwg] Re: Adoption of draft-porfiri-dhc-dhcpv4-over-dhcpv6 -ra?

"Eric Vyncke \(evyncke\)" <[email protected]> Thu, 11 Jul 2024 11:08:42 +0000
Newsgroups gmane.ietf.dhc
Message-ID <PH0PR11MB496639BB9F5CB3A8FA479A00A9A52@PH0PR11MB4966.namprd11.prod.outlook.com>
Bernie,

I like your problem statement below “to avoid having... easier to update” as it is shorter, straight to the fact, and more generic.

-éric

From: Bernie Volz <[email protected]>
Date: Thursday, 11 July 2024 at 12:51
To: Eric Vyncke (evyncke) <[email protected]>
Cc: Jari Arkko <[email protected]>, dhcwg <[email protected]>, Mirja Kuehlewind <[email protected]>, Suresh Krishnan (sureshk) <[email protected]>
Subject: Re: [dhcwg] Re: Adoption of draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra?
In my view it seems there’s a lot of unnecessary baggage here … basically this is just a way to avoid having to implement RFC 7413 in clients and instead do it in the Relay agents (there are a lot fewer of those and they are easier to update).

Maybe some of the baggage is needed as motivation, but even that seems simpler to do as per above?

But perhaps I’m missing something here?

- Bernie (from iPad)


On Jul 11, 2024, at 5:16 AM, Eric Vyncke (evyncke) <[email protected]> wrote:

Hello Jari, and authors,

Without any hat, I quickly reviewed this I-D in preparation for IETF-120 and here are some comments:
- a lot of text requires knowledge about RAN and its specific terms, e.g., s/amend/update/
- add Update tag for RFC 7413 ?
- why is Topology capitalized ?
- figure 1, it took me a (short) while to map RU to Radio Unit, please consider a legend, also use P1/P2/P3/P4 perhaps or is it on purpose ?
- figure 3, I guess it should be “DHCPv4 client”” rather than “4o6 client” ?
- the last paragraphs of section 5 would benefit from more specification/description, i.e., a clear description for mapping all DHCPv4 sent and received
- suggestion, I have seen in other I-D using “---” for IPv6 links and “....” for IPv4 links
- is this spec useful/valid if there are multiple DHCPv6 servers ?
- consider SVG graphics for the figure (there are nice tools such as https://github.com/martinthomson/aasvg

Finally, some justification would be welcome about why using DHCP for this rather than NETCONF collecting the IEEE LLDP information in the switches ? Perhaps in appendix or in the intro ?

Hope this helps,

Regards,

-éric




From: Jari Arkko <[email protected]>
Date: Friday, 5 July 2024 at 14:55
To: dhcwg <[email protected]>
Cc: Mirja Kuehlewind <[email protected]>
Subject: [dhcwg] Adoption of draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra?
Hi,

We've had some discussion of this topic in IETF-118. In that meeting and discussions afterwards, a new direction was found that leverages DHCPv4-over-DHCPv6 and relay agents. This does not introduce major new protocol machinery, rather it is a small amendment and documenting how existing features can be used together in a specific manner. There’s interest in the industry to apply this in large radio fronthaul networks.

We believe the draft is ready and could be adopted by the working group. Review, comments, etc. would of course be useful. Could we either conduct an adoption call on the list, or discuss in the meeting, or both?

Abstract:

   This document describes a general mechanism for networks with legacy
   IPv4 only clients to use DHCPv4-over-DHCPv6 (DHCP 4o6) for
   discovering information about network Topology.  To address this
   scenario, this document specifies an amendment to RFC7341 that allows
   a new 4o6 Relay Agent (4o6RA) to perform the 4o6 DHCP en- and
   decapsultion instead of the client.

Draft URL:

DHCPv4 over DHCPv6 with Relay Agent Support<https://datatracker.ietf.org/doc/html/draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra>
datatracker.ietf.org<https://datatracker.ietf.org/doc/html/draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra>
<https://datatracker.ietf.org/doc/html/draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra>
<ietf-logo-nor-180.png><https://datatracker.ietf.org/doc/html/draft-porfiri-dhc-dhcpv4-over-dhcpv6-ra>


Jari

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]