Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

["Bernie Volz (volz)" <[e-mail]>]

>My concern is that I got the impression that the addresses this document provides need to be tracked by the server, that is that they are stateful ...

I don't think that is the case. This is the address of a Rendezvous Point and the multicast group that the client needs to join. I think there is one set of these for each VNI (VXLAN Network Identifier). So the DHCP server needs to have a mapping from VNI to this information to return it to the client when requested, and this thus makes more careful review by the dhc likely a requirement before it becomes a 'standard'.

I'm not exactly sure why this isn't just a property of the scope or prefix the client is on (i.e., assigned addresses from - or if stateless is used, the address from which the "inform" is received) and why the VNI would have to be sent from client to server, but that's probably because of my lack of understanding as to this entire area.

> As for whether this should get a presentation in the DHC working group ...

That is also my concern. If nvo3 is not interested in this work, why should we be?

If this were targeted to be adopted by dhc (as it was originally) it would be more reasonable to request a presentation. 

However, I think it more appropriate in that this be a nvo3 draft as they better understand whether it is needed and appropriate; the dhc wg should certainly continue to monitor this work and provide suggestions and recommendations with respect to the dhc options format and processing requirements. Once adopted by nvo3 (or if the nvo3 chairs request an assessment by dhc), we can certainly take a more careful look including a presentation.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[e-mail]] 
Sent: Thursday, February 20, 2014 1:08 PM
To: <[e-mail]>; Behcet Sarikaya
Cc: [e-mail]; Dhc Chairs
Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

My concern is that I got the impression that the addresses this document provides need to be tracked by the server, that is that they are stateful.   I'm not sure that's the case-it just looked that way to me.

As for whether this should get a presentation in the DHC working group, that is of course up to the chairs, but given that this is work needed by another working group, it would be nice if the working group chairs for nvo3 were to tell the working group chairs of dhc that they are seriously looking to adopt this document as a working group item and want the DHC working group's advice.   Otherwise, what's the point?   I certainly wouldn't support advancing this document in the DHC working group without such a request, and then only if this is in fact a stateful option.