Re: [dhcwg] Some questions regarding draft-bvtm-dhc-mac-assign-00

Hi:

Few notes inline (BV>) below.

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Monday, March 05, 2018 5:58 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Some questions regarding draft-bvtm-dhc-mac-assign-00

Hi,

Thanks to Bernie for pushing forward, editing and uploading the draft.

BV> Well, Tomek did most of the work on writing the draft.

This is an initial proposal for a new mechanism in DHCPv6. It looks a bit odd at first (why would a device request MAC address if it's able to transmit DHCPv6 packets already), but there are at least two scenarios where this is justified.

I'd like to encourage people to read the draft. It short - 4 pages of the actual proposal text (or 7 if you count option format sections).

There are couple questions we'd like to hear your comments on:

1. Does it make sense to reuse DHCPv6 mechanisms to solve this problem?
Several current and former IESG members think so, but we'd like to hear your opinion on this.

2. Would such a topic be interesting to the WG?

3. Do we want to allow or even mandate Reconfigure here? One of the objections raised to DHCPv6 protocol in general was that it's not always possible to change the configuration at moment's notice.

BV> I would suspect we would, but this also raises the issue, especially for hypervisor or another entity that gets a block of mac addresses and assigns to "devices", exactly what actions are needed when the assigned addresses "expire" - for example, does the hypervisor "kill" (terminate) the device? (Would there potentially also be some "connection" between the mac-addresses and DHCPv6 assigned addresses or delegated prefixes to these devices).

4. We haven't really figured out whether it would be better to have always one LLADDR per IA_LL or one or more? Arguments can be made both ways. We're eager to hear what's the preference here.

BV> My feeling is we should be flexible and allow any number. Not sure what advantage there is to limit this? There is also a question as to whether the link-layer-type/link-layer-len should be moved into the IA_LL as then there could be 0 or more LLADDR (for example, a device wanting just one address would not need to include a OPTION_LLADDR)? But I don't think there is necessarily any good argument over current (LLADDR) vs IA_LL approach.

On a related note, we organized the repo for this work here:
https://github.com/dhcwg/dhcp-mac. Feel free to comment on existing issues or open new ones. Keep the discussion on dhcwg list, though.

BV> I also started a few issues at https://github.com/dhcwg/dhcp-mac/issues.

Thanks,

Bernie & Tomek

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg