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

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 14 Feb 2014 11:36:20 -0600

Dear Chairs,

We submitted a draft, see below for details.
Please reserve a short slot in IETF 89.

Note that this is a revised and renamed version of
draft-sarikaya-dhc-vxlan-multicast-02.

A new version of I-D, draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-sarikaya-nvo3-dhc-vxlan-multicast
Revision:       00
Title:          DHCP Options for Configuring Multicast Addresses in VXLAN
Document date:  2014-02-14
Group:          Individual Submission
Pages:          12
URL:
http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
Status:
https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-dhc-vxlan-multicast/
Htmlized:
http://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-multicast-00

Abstract:
   This document defines DHCPv4 and DHCPv6 options for assigning
   multicast addresses for the Tunnel End Point in the Virtual
   eXtensible Local Area Network (VXLAN) environments.  New DHCP options
   are defined which allow a VXLAN Tunnel End Point to request any
   source multicast address for the newly created virtual machine and
   possibly IPv4/IPv6 address(es) for the virtual machine.

Regards,

Frank & Behcet

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 14 Feb 2014 20:46:28 +0000

Behcet:

Just so we can properly prioritize (though at present we seem to have sufficient time), is this intended to be an informational presentation, or do you have issues to discuss/resolve? We'll give preference to those drafts that have issues to discuss/resolve.

Also, as this is now (I think) primarily targeted for the NVO3 (Network Virtualization Overlays) WG, is there anything of significance to discuss in DHC - there does seem to be some server processing involved as the client supplied option triggers the server to return a specific multicast address.

A few comments from a quick look at the document:

1.       Why does the client set the address to 0 in the address option? Why have the client include this option at all (server can just add it either because the network identifier option is present or as client can request in PRL/ORO)?

2.       The option lengths are wrong? In DHCPv6 (& DHCPv4), the option length covers just the data itself (not the option code and option type).

3.       Why is the "VXLAN Identifier" apparently 3 bytes for the DHCPv6 option and 4 bytes for the DHCPv4 option? What is the relationship between this VXLAN Identifier and the "24-bit Virtual Subnet Identifier (VSID)"? It does state "Note that VSID is simlar to VNI" - but that is still something different than the VXLAN Identifier (though even earlier is stated "VXLAN header contains 24-bit VNI"). So I would guess this is 3 byte (octet) field and this is the VNI? Why call it something else then?

4.       There's no relay option ... perhaps that is intentional but can the client's "Network Identifier" option value be trusted? Would it make sense for a relay to provide this? Or is this something only the client would know and therefore it has to be trusted?
Probably some of the above is because of my lack of understanding of this entire space.

-          Bernie

From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Friday, February 14, 2014 12:36 PM
To: Dhc Chairs
Cc: [email-masked]
Subject: Fwd: New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

Dear Chairs,
We submitted a draft, see below for details.
Please reserve a short slot in IETF 89.
Note that this is a revised and renamed version of draft-sarikaya-dhc-vxlan-multicast-02.

Name:           draft-sarikaya-nvo3-dhc-vxlan-multicast
Revision:       00
Title:          DHCP Options for Configuring Multicast Addresses in VXLAN
Document date:  2014-02-14
Group:          Individual Submission
Pages:          12
URL:            http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
Status:         https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-dhc-vxlan-multicast/
Htmlized:       http://tools.ietf.org/html/draft-sarikaya-nvo3-dhc-vxlan-multicast-00

Abstract:

Regards,

Frank & Behcet

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Feb 2014 13:00:04 -0500

On Feb 14, 2014, at 12:36 PM, Behcet Sarikaya <[email-masked]> wrote:
> New DHCP options

This sounds like another set of stateful DHCP options.   Why not just use regular DHCP IA_NA or IA_PD?

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Feb 2014 11:28:16 -0600

Hi Bernie,

Thanks for your review, sorry for the delay in my reply, apologies.

Please see my replies inline.

Regards,

Behcet

On Fri, Feb 14, 2014 at 2:46 PM, Bernie Volz (volz) <[email-masked]> wrote:

>  Behcet:
>
>
>
> Just so we can properly prioritize (though at present we seem to have
> sufficient time), is this intended to be an informational presentation, or
> do you have issues to discuss/resolve? We'll give preference to those
> drafts that have issues to discuss/resolve.
>
>
>

Since we are defining several DHC options and related client/server
behaviour, we thought that it should also be presented in dhc WG, as is
customary, no?

 Also, as this is now (I think) primarily targeted for the NVO3 (Network
> Virtualization Overlays) WG, is there anything of significance to discuss
> in DHC - there does seem to be some server processing involved as the
> client supplied option triggers the server to return a specific multicast
> address.
>
>
>

The aim is to get dhc specific comments about our draft, much like what you
did below.

 A few comments from a quick look at the document:
>
> 1.       Why does the client set the address to 0 in the address option?
> Why have the client include this option at all (server can just add it
> either because the network identifier option is present or as client can
> request in PRL/ORO)?
>

Yes, I think this is another way of doing it. Is there a preference by dhc
WG on which way we should have it in the draft?

>  2.       The option lengths are wrong? In DHCPv6 (& DHCPv4), the option
> length covers just the data itself (not the option code and option type).
>
OK, to be corrected.

>  3.       Why is the "VXLAN Identifier" apparently 3 bytes for the DHCPv6
> option and 4 bytes for the DHCPv4 option? What is the relationship between
> this VXLAN Identifier and the "24-bit Virtual Subnet Identifier (VSID)"? It
> does state "Note that VSID is simlar to VNI" - but that is still something
> different than the VXLAN Identifier (though even earlier is stated "VXLAN
> header contains 24-bit VNI"). So I would guess this is 3 byte (octet) field
> and this is the VNI? Why call it something else then?
>

VNI is of size 24-bits, i.e. 3 octets. In DHCPv4   a4 is always set to
zero. Maybe we don't need to have a4, I thought DHCPv4 options are always
given in 4-octets?

 4.       There's no relay option ... perhaps that is intentional but can the
> client's "Network Identifier" option value be trusted? Would it make sense
> for a relay to provide this? Or is this something only the client would
> know and therefore it has to be trusted?
>

We can clarify and say that the client MUST set it to zero, would that be
OK?

>  Probably some of the above is because of my lack of understanding of

Thanks again for taking the time and giving us very nice feedback.

>  -          Bernie
>
>
>
> *From:* Behcet Sarikaya [mailto:[email-masked]]
> *Sent:* Friday, February 14, 2014 12:36 PM
> *To:* Dhc Chairs
> *Cc:* [email-masked]
> *Subject:* Fwd: New Version Notification for
> draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt
>
>
>
> Dear Chairs,
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 19 Feb 2014 18:56:29 +0000

>Since we are defining several DHC options and related client/server behaviour, we thought that it should also be presented in dhc WG, as is customary, no?

It is more important that it be "presented" on the mailing list than necessarily in a DHC WG session. If the draft is intended to be adopted by DHC WG, a presentation is typically a good idea to assure people know about it. But it is not required. Also, we are trying to move "simple" options (I.e., those that do not have an special processing requirements and follow the Option Guidelines drafts) work out of the DHC WG as other working groups should be able to handle those following the Option Guidelines.

>Yes, I think this is another way of doing it. Is there a preference by dhc WG on which way we should have it in the draft?

For options which are only intended for the information to go one way (I.e., server to client), having the client request the option in the PRL/ORO is the way to go; there's no benefit in having the client send the option. Only if the client must present some data to the server which the server needs to process the request, does it make sense for the client to include it (and in that case, either using two options (client -> server; server -> client) or using optional fields in the option makes more sense).

>VNI is of size 24-bits, i.e. 3 octets. In DHCPv4   a4 is always set to zero. Maybe we don't need to have a4, I thought DHCPv4 options are always given in 4-octets?

Field should be the size that the data is – padding isn't necessary. Alignment does make drawing the option diagrams easier, but there's really no benefit in client or server processing and it makes the packets larger for no good reason. So, if a field is 24-bits, only use 24-bits. (The examples typically used are for 8-bit, 16-bit, or 32-bit values as those line up with what usually makes the most sense, but that doesn't mean other sizes are not allowed.)

>4.       There’s no relay option … perhaps that is intentional but can the client’s “Network Identifier” option value be trusted? Would it make sense for a relay to provide this? Or is this something only the client would know and therefore it has to be trusted?

>We can clarify and say that the client MUST set it to zero, would that be OK?

I am not sure how this relates to my concern about whether a client or relay is best to provide this information. If the client has it and needs it, then client <-> server makes most sense. I suspect that this is a case where this is just client <-> server and relay is not involved.

- Bernie

From: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 19, 2014 12:28 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: Dhc Chairs <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

Hi Bernie,

Regards,

Behcet

On Fri, Feb 14, 2014 at 2:46 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
Behcet:

Just so we can properly prioritize (though at present we seem to have sufficient time), is this intended to be an informational presentation, or do you have issues to discuss/resolve? We’ll give preference to those drafts that have issues to discuss/resolve.

Since we are defining several DHC options and related client/server behaviour, we thought that it should also be presented in dhc WG, as is customary, no?

Also, as this is now (I think) primarily targeted for the NVO3 (Network Virtualization Overlays) WG, is there anything of significance to discuss in DHC – there does seem to be some server processing involved as the client supplied option triggers the server to return a specific multicast address.

The aim is to get dhc specific comments about our draft, much like what you did below.

Yes, I think this is another way of doing it. Is there a preference by dhc WG on which way we should have it in the draft?

OK, to be corrected.

3.       Why is the “VXLAN Identifier” apparently 3 bytes for the DHCPv6 option and 4 bytes for the DHCPv4 option? What is the relationship between this VXLAN Identifier and the “24-bit Virtual Subnet Identifier (VSID)”? It does state “Note that VSID is simlar to VNI” – but that is still something different than the VXLAN Identifier (though even earlier is stated “VXLAN header contains 24-bit VNI”). So I would guess this is 3 byte (octet) field and this is the VNI? Why call it something else then?

VNI is of size 24-bits, i.e. 3 octets. In DHCPv4   a4 is always set to zero. Maybe we don't need to have a4, I thought DHCPv4 options are always given in 4-octets?

4.       There’s no relay option … perhaps that is intentional but can the client’s “Network Identifier” option value be trusted? Would it make sense for a relay to provide this? Or is this something only the client would know and therefore it has to be trusted?

We can clarify and say that the client MUST set it to zero, would that be OK?

-          Bernie

From: Behcet Sarikaya [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, February 14, 2014 12:36 PM
To: Dhc Chairs
Cc: [email-masked]<mailto:[email-masked]>
Subject: Fwd: New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

Dear Chairs,

Abstract:

Regards,

Frank & Behcet

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2014 14:19:49 -0500

Before the working group hears a presentation on this, it would be good if Behcet could answer the question I asked on the mailing list.   If the draft isn't important enough to discuss on the mailing list, it surely doesn't need time on the schedule in London!

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Feb 2014 13:28:17 -0600

Hi Bernie,

We will revise the draft based on your review (see inline below). Of
course   more comments are always welcome.

As for the presentation, we leave it up to you.

Regards,

Behcet

On Wed, Feb 19, 2014 at 12:56 PM, Bernie Volz (volz) <[email-masked]> wrote:

>  It is more important that it be "presented" on the mailing list than
> necessarily in a DHC WG session. If the draft is intended to be adopted by
> DHC WG, a presentation is typically a good idea to assure people know about
> it. But it is not required. Also, we are trying to move "simple" options
> (I.e., those that do not have an special processing requirements and follow
> the Option Guidelines drafts) work out of the DHC WG as other working
> groups should be able to handle those following the Option Guidelines.
>
>  >Yes, I think this is another way of doing it. Is there a preference by
> dhc WG on which way we should have it in the draft?
>
>  For options which are only intended for the information to go one way
> (I.e., server to client), having the client request the option in the
> PRL/ORO is the way to go; there's no benefit in having the client send the
> option. Only if the client must present some data to the server which the
> server needs to process the request, does it make sense for the client to
> include it (and in that case, either using two options (client -> server;
> server -> client) or using optional fields in the option makes more sense).
>
>
OK, so we get the client to request it using ORO
so the client adds an ORO with OPTION_VNI in the Solicit message.

>  Field should be the size that the data is - padding isn't necessary.
> Alignment does make drawing the option diagrams easier, but there's really
> no benefit in client or server processing and it makes the packets larger
> for no good reason. So, if a field is 24-bits, only use 24-bits. (The
> examples typically used are for 8-bit, 16-bit, or 32-bit values as those
> line up with what usually makes the most sense, but that doesn't mean other
> sizes are not allowed.)
>
>
>
OK, so I remove a4.

>   >4.       There's no relay option ... perhaps that is intentional but can
>> the client's "Network Identifier" option value be trusted? Would it make
>> sense for a relay to provide this? Or is this something only the client
>> would know and therefore it has to be trusted?
>>
I think that with ORO, we don't need a relay option, do we?

>  I am not sure how this relates to my concern about whether a client or
> relay is best to provide this information. If the client has it and needs
> it, then client <-> server makes most sense. I suspect that this is a case
> where this is just client <-> server and relay is not involved.
>
>
Sure, it is client <-> server so relay is not involved.

Regards,

Behcet

>  - Bernie
>
>   From: Behcet Sarikaya <[email-masked]>
> Reply-To: "[email-masked]" <[email-masked]>
> To: Cisco Employee <[email-masked]>
> Cc: Dhc Chairs <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Subject: Re: New Version Notification for
> On Fri, Feb 14, 2014 at 2:46 PM, Bernie Volz (volz) <[email-masked]>wrote:
>
>>  Behcet:
>>
>>
>>
>    Also, as this is now (I think) primarily targeted for the NVO3
>> (Network Virtualization Overlays) WG, is there anything of significance to
>> discuss in DHC - there does seem to be some server processing involved as
>> the client supplied option triggers the server to return a specific
>> multicast address.
>>
>>
>>
>
>  Yes, I think this is another way of doing it. Is there a preference by
> dhc WG on which way we should have it in the draft?
>
>
>>   2.       The option lengths are wrong? In DHCPv6 (& DHCPv4), the
>> option length covers just the data itself (not the option code and option
>> type).
>>
> OK, to be corrected.
>
>>   3.       Why is the "VXLAN Identifier" apparently 3 bytes for the
>> DHCPv6 option and 4 bytes for the DHCPv4 option? What is the relationship
>> between this VXLAN Identifier and the "24-bit Virtual Subnet Identifier
>> (VSID)"? It does state "Note that VSID is simlar to VNI" - but that is
>> still something different than the VXLAN Identifier (though even earlier is
>> stated "VXLAN header contains 24-bit VNI"). So I would guess this is 3 byte
>> (octet) field and this is the VNI? Why call it something else then?
>>
>
>    4.       There's no relay option ... perhaps that is intentional but can
>> the client's "Network Identifier" option value be trusted? Would it make
>> sense for a relay to provide this? Or is this something only the client
>> would know and therefore it has to be trusted?
>>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Feb 2014 14:16:08 -0600

Hi Ted,

Apologies for my very belated reply. Just now I saw your message. Thanks
for reminding it.

Please see inline.

Regards,

Behcet

> regular DHCP IA_NA or IA_PD?
For IA_NA, are you suggesting to use this option to get multicast addresses?
I think that IA_NA is defined for unicast addresses.

The other option we need is for VXLAN Network Identifier (VNI) which is
certainly not an address.

For IA_PD, I believe also is not appropriate to request multicast address
to be assigned, as it is not related to prefix delegation.

Please advise.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 19 Feb 2014 21:54:09 +0000

I agree. Though there now has been some discussion :).

As this is now targeted at nvo3, I don't see a strong need for a presentation in dhc at this time. If the nvo3 adopts this work (i.e., believes it is a problem that needs a solution), we can revisit for a future presentation? Of course, you should continue to make the dhc aware of the progress of this draft and collecting input when offered or if you raise specific issues or questions.

It is odd that this isn't on the nvo3 agenda (at least at present), as it would seem to be more appropriate there as the intended WG.

---

General comment about many individual drafts:

I think that people that submit individual drafts don't always take the next [manual] step to notify the DHC WG of that draft. They (mistakenly) believe somehow that the "group" is notified when it isn't (the main ietf mailing list gets the notice, but not the dhc wg).

I would highly recommend that any new or updated draft posting (whether WG document or individual) is followed up with an email to the DHC WG:
- for new drafts, explain it (perhaps by using the abstract or introduction) and why you feel it is important to the WG and what you want the WG to do with the draft (if individual). Think of this as presenting the main points and what areas you feel the WG may want to review or have a particular concern about.
- for updates, indicate what has changed and why. And for individual, again indicate what you want the WG to do next with the draft. Is it FYI? Is it because you feel it is ready for adoption and will propose a call shortly? ...

There are some WGs where the chairs do post "a new draft or new revision has been posted" (for individual drafts related to the WG). But in the DHC WG we assume that the authors will do this and expect them to - the chairs have enough to do!

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Wednesday, February 19, 2014 2:20 PM
To: Bernie Volz (volz)
Cc: [email-masked]; Dhc Chairs
Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Feb 2014 11:49:53 -0600

On Wed, Feb 19, 2014 at 3:54 PM, Bernie Volz (volz) <[email-masked]> wrote:

> As this is now targeted at nvo3, I don't see a strong need for a
> presentation in dhc at this time. If the nvo3 adopts this work (i.e.,
> believes it is a problem that needs a solution), we can revisit for a
> future presentation? Of course, you should continue to make the dhc aware
> of the progress of this draft and collecting input when offered or if you
> raise specific issues or questions.
>
> It is odd that this isn't on the nvo3 agenda (at least at present), as it
> would seem to be more appropriate there as the intended WG.
>
>
Bernie, I presented it in nvo3 in Vancouver, this time we did not ask a
slot. About dhc presentation slot, it is up to you, I remember last time we
were assigned a slot but never had a chance.

We would like to clarify all the comments made so far, right now Ted's
comment has not yet been resolved, we are waiting for his reply.

Regards,

Behcet

> I think that people that submit individual drafts don't always take the
> next [manual] step to notify the DHC WG of that draft. They (mistakenly)
> believe somehow that the "group" is notified when it isn't (the main ietf
> mailing list gets the notice, but not the dhc wg).
>
> I would highly recommend that any new or updated draft posting (whether WG
> document or individual) is followed up with an email to the DHC WG:
> - for new drafts, explain it (perhaps by using the abstract or
> introduction) and why you feel it is important to the WG and what you want
> the WG to do with the draft (if individual). Think of this as presenting
> the main points and what areas you feel the WG may want to review or have a
> particular concern about.
> - for updates, indicate what has changed and why. And for individual,
> again indicate what you want the WG to do next with the draft. Is it FYI?
> Is it because you feel it is ready for adoption and will propose a call
> shortly? ...
>
> There are some WGs where the chairs do post "a new draft or new revision
> has been posted" (for individual drafts related to the WG). But in the DHC
> WG we assume that the authors will do this and expect them to - the chairs
> have enough to do!
>
> - Bernie
>
> Subject: Re: [dhcwg] New Version Notification for
> Before the working group hears a presentation on this, it would be good if
> Behcet could answer the question I asked on the mailing list.   If the
> draft isn't important enough to discuss on the mailing list, it surely
> doesn't need time on the schedule in London!
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Feb 2014 11:55:37 -0600

Hi Ted,

> regular DHCP IA_NA or IA_PD?
I discussed this with my co-author, our latest idea is that your comment
might be referring to this text we have in the abstract:

and possibly IPv4/IPv6 address(es) for the virtual machine.

We mentioned this but did not elaborate on it.
Yes in this case IA_NA or even IA_PD would need to be used.
We will add the text in the next revision, is this OK?

Regards,

Behcet

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 20 Feb 2014 18:02:44 +0000

> About dhc presentation slot, it is up to you, I remember last time we were assigned a slot but never had a chance.

That was actually two IETF's ago (IETF-87, Berlin) that you requested a slot but we ran out of time.

Your most recent nvo3 presentation is at:
http://www.ietf.org/proceedings/88/slides/slides-88-nvo3-7.pdf

-          Bernie

From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 12:50 PM
To: Bernie Volz (volz)
Cc: Ted Lemon; [email-masked]; Dhc Chairs
Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

On Wed, Feb 19, 2014 at 3:54 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
I agree. Though there now has been some discussion :).

Bernie, I presented it in nvo3 in Vancouver, this time we did not ask a slot. About dhc presentation slot, it is up to you, I remember last time we were assigned a slot but never had a chance.
We would like to clarify all the comments made so far, right now Ted's comment has not yet been resolved, we are waiting for his reply.
Regards,
Behcet
---

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ted Lemon
Sent: Wednesday, February 19, 2014 2:20 PM
To: Bernie Volz (volz)
Cc: [email-masked]<mailto:[email-masked]>; Dhc Chairs
Subject: Re: [dhcwg] New Version Notification for draft-sarikaya-nvo3-dhc-vxlan-multicast-00.txt

Before the working group hears a presentation on this, it would be good if Behcet could answer the question I asked on the mailing list.   If the draft isn't important enough to discuss on the mailing list, it surely doesn't need time on the schedule in London!
_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Feb 2014 13:07:53 -0500

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.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 20 Feb 2014 18:21:33 +0000

>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:[email-masked]] 
Sent: Thursday, February 20, 2014 1:08 PM
To: <[email-masked]>; Behcet Sarikaya
Cc: [email-masked]; 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.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Feb 2014 15:05:18 -0600

Hi Ted, Bernie,

On Thu, Feb 20, 2014 at 12:21 PM, Bernie Volz (volz) <[email-masked]> wrote:

> >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'.
>
>
agreed.

> 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.
>
> We clarified this, client will not send VNI instead it will ask it with
ORO as you suggested.

> 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.
>
>
Agreed.

Regards,

Behcet

> 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.
>
>