Subject: [netlmm] DHCP Scenarios in draft-ietf-netlmm-pmip6-ipv4-support

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 23 Oct 2008 14:16:26 -0400

At the last IETF meeting we had a discussion on whether we should
simplify the DHCP scenarios in draft-ietf-netlmm-pmip6-ipv4-support.

During the meeting, I had proposed simplifying the document to support
just one scenario, where the DHCP relay agent is co-located with the
MAG. This would remove the scenario where the DHCP server is co-located
with the MAG. The DHCP server with the MAG is more complicated and
requires extensions to make sure the mobile node either sees the same
DHCP server IP address after a handover or gets involved in a multiple
round-trip exchange with the new MAG to get the same IPv4 home address
(see section 3.4.1).

If there is a deployment need for the scenario where the DHCP server is
co-located with the MAG, we can standardize it later. For now, I think
we should simplify the IPv4 support document.

Comments?

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

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 23 Oct 2008 11:30:14 -0700 (PDT)

Hi Vijay,

> requires extensions to make sure the mobile node either sees the same

This mode is not requiring any extensions. Its about presenting a
fixed DHCP server address to the MN, that according to the DHCP folks
is more often the case or a goal to present a single address, while
a farm of DHCP server infrastructure supporting that node.  The other
approach is to use the force renew message. Clearly, protocol is
allowing this mode.

We should document both these basic modes of DHCP configuration. Clearly,
there are advantages by avoiding DHCP flows hitting the home and by
local termination. If we see any unsolvable issues, we can go this
path, but thats not the case.

Thanks
Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 Oct 2008 11:33:29 -0700

Hello Sri,

Do you really want to promote having dozens or
hundreds of DHCP databases for the poor network
administrator to configure, debug, update, and
manage?  Yow.

I should buy stock in companies selling medicine
for migraines.

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 23 Oct 2008 11:42:23 -0700 (PDT)

Hi Charlie,

> I should buy stock in companies selling medicine

I understand we have strong preferences for certain
modes and we may think its a head ache to support
some other modes. But, protocols have to reasonably
flexible and allow minimal configurations.

Forcing only one mode of DHCP configuration, co-location
on the LMA, will require every DHCP message to hit the
LMA. We already have a dependency for the PMIP signaling
to be complete and this requires DHCP messages to hit
all the way home. In some cases, this will eliminate that
extra round trip.

We should minimize configurations, but at the same time,
that goal should not endup imposing strong deployment
restrictions.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 23 Oct 2008 11:50:39 -0700

> path, but thats not the case.

This is where we disagree. If there is a need for the scenario where the 
DHCP server is co-located with the MAG, then its fine with me. I see the 
advantage with the DHCP messages being terminated at the MAG itself. But 
I don't think it is worth the extensions that is required on the MAG and 
having to manage the DHCP server function on each MAG. Removing this 
simplifies the document as well as the additional functions required on 
the MAG.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 23 Oct 2008 13:51:51 -0500

I agree that specifying only the relay function in the MAG would make the
spec simpler and avoid having to deal with the scenario about the DHCP
server being located at the previous MAG in the case of a handover.

Decoupling the DHCP server from the MAG would be good. So even if someone
wants to deploy a MAG which has a colocated DHCP server they can do so while
ensuring that other MAGs in that domain use DHCP relays which are configured
with the DHCP server in a specific MAG.

What added value exists by having the DHCP server function colocated with
the MAG? I don't believe this is clear in the I-D.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 23 Oct 2008 12:00:04 -0700 (PDT)

On Thu, 23 Oct 2008, Vijay Devarapalli wrote:

> This is where we disagree. If there is a need for the scenario where the DHCP 
> server is co-located with the MAG, then its fine with me. I see the advantage 
> with the DHCP messages being terminated at the MAG itself. But I don't think

Is that not a good reason ? There are advantages in that mode. Two sets of
round trip messages, one for PMIP and the other for DHCP, before the
mobile gets an address. Allowing that optimization will help and the DHCP
protocol is designed from binding it to a single server.

> it is worth the extensions that is required on the MAG and having to manage 
> the DHCP server function on each MAG. Removing this simplifies the document 
> as well as the additional functions required on the MAG.
>

We have to evaulate what is that complexity we are introducing by
supporting that mode, we dont see that complexity.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 23 Oct 2008 12:04:55 -0700 (PDT)

Hi Raj,

> the MAG? I don't believe this is clear in the I-D.

The added value is saving some round trip time on DHCP flows. We can force
every thing to hit LMA, but there is a cost. Secondly, the mode is common
even in fixed networks, there is no binding to a single server and the
scenario of DHCP server on the MAG is identical to this.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 23 Oct 2008 14:07:32 -0500

Sri,

> supporting that mode, we dont see that complexity.

There is the added complexity of the maintaining the assigned DHCP server in
the case of handover by an MN. I guess you believe this can be solved in a
fairly simple manner (which I guess is a matter of opinion).

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 23 Oct 2008 14:17:52 -0500

Hi Sri,

> scenario of DHCP server on the MAG is identical to this.

I don't think you can compare the fixed network model to PMIP6 where the MN
can change the NAS (MAGs). Regarding the optimization, the address
assignment and DHCP RT messages are not on the critical path per se. It is
not as if this is being done during a HO. Hence I don't see latency as being
an issue here. Only the additional RT. So between simplifying the protocol
vs optimizing a RT, I would at least choose on a simple approach (because
the gain is minimal).

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 23 Oct 2008 12:34:51 -0700 (PDT)

Hi Raj,

> fairly simple manner (which I guess is a matter of opinion).

Its a service configuration requirement, not sure where is that protocol
complexity. We are not introducing any protocol extensions, for that
matter, this entire DHCP address configuration is more a configuration
guidance, so dont agree with the tag that is complex and should be taken
out.

Regards
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 23 Oct 2008 13:53:58 -0700

Sri Gundavelli wrote:

>> This is where we disagree. If there is a need for the scenario where 
>> the DHCP server is co-located with the MAG, then its fine with me. I 
>> see the advantage with the DHCP messages being terminated at the MAG 
>> itself. But I don't think
> 
> mobile gets an address. 

Only during the initial attach and when the renew happens. Neither of 
them are often and they don't happen during a handover. I don't see the 
issue. In fact, apart from the initial attach, they might not even 
happen to gether.

Allowing that optimization will help and the DHCP
>> it is worth the extensions that is required on the MAG and having to 
>> manage the DHCP server function on each MAG. Removing this simplifies 
>> the document as well as the additional functions required on the MAG.
>>
> 

There is a new DHCP server function on every MAG. In addition, you need 
a mechanism to make sure the MN sees the same DHCP server address every 
time it performs a handover.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 23 Oct 2008 14:33:54 -0700 (PDT)

Hi Vijay,

On Thu, 23 Oct 2008, Vijay Devarapalli wrote:

>
> Only during the initial attach and when the renew happens. Neither of them 
> are often and they don't happen during a handover. I don't see the issue. In 
> fact, apart from the initial attach, they might not even happen to gether.
>

Sure, the delay is during only initial attach. We also look
at this from the capability perspective, the MAG in certain
supported address configuration modes, Ex: IKEv2, IPCP,
the address delivery function is on the MAG and I dont see
any reason why we cannot allow the same when using DHCP.

Also, as Behcet pointed out, we like it or not, WiMAX is using
this mode.

> There is a new DHCP server function on every MAG. In addition, you need a 
> mechanism to make sure the MN sees the same DHCP server address every time it 
> performs a handover.
>

No new DHCP server function. Its the same old DHCP server function, that
needs to be enabled on the MAG. The draft is only describing that
configuration mode. I totally agree with you, if we endup with lots of
changes, but what we have is just the text on how that mode works.

Regards
Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 23 Oct 2008 17:42:33 -0400

> any reason why we cannot allow the same when using DHCP.

That makes a big difference. Can we conclude that there is no issue with
additional round trips that were pointing out in your earlier email? 

> Also, as Behcet pointed out, we like it or not, WiMAX is using

Hmm... WiMAX uses something called the DHCP proxy on the ASN GW for
their own flavor of PMIPv4. I don't think that justifies us adding this
for PMIPv6. WiMAX has not adopted PMIPv6 yet. So I am not convinced.

> changes, but what we have is just the text on how that mode works.

There is a difference. The text in the draft describes two modes of
deploying DHCP functionality in a PMIPv6 network - one with DHCP server
on the MAG and the other with DHCP relay on the MAG. Not just describe
some additional configuration information. :)

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 23 Oct 2008 15:00:12 -0700 (PDT)

> additional round trips that were pointing out in your earlier email?

There is a cost, even if its for the initial attach, when ever the DHCP
messages are routed back home. That cannot be ignored.

> for PMIPv6. WiMAX has not adopted PMIPv6 yet. So I am not convinced.

That's the term they chose. But, for all practical purposes that is a
DHCP server. So, we have clearly a requirement for this configuration
mode. I dont see the issue, as why we cant support that mode, clearly
when we are just documenting how that works.

> some additional configuration information. :)

:) Well, we are not defining a "new DHCP server" for PMIP. We are only
stating that the function as specified in RFC-2131 needs to be enabled
on a box that is running a MAG function.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 23 Oct 2008 22:48:51 -0700

It does seem to me that having every MAG be a DHCP server is adding to configuration complexity, without really bringing much benefit, as some people point out.  Just the fact that another SDO has adopted something cannot mean that we put that solution in an RFC.  And, it also cannot just be about giving all options - it would be preferable for us to recommend one option where possible.  

Sri, in this case, what is the downside of not having a DHCP server on the MAG, other than the extra roundtrip at startup time? 

Regards,
Vidya 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sri Gundavelli
> Sent: Thursday, October 23, 2008 3:00 PM
> To: Vijay Devarapalli
> Cc: Ryuji Wakikawa; [email-masked]
> Subject: Re: [netlmm] DHCP Scenarios in 
> draft-ietf-netlmm-pmip6-ipv4-support
> 
> 
> 
> >> Sure, the delay is during only initial attach. We also 
> look at this 
> >> from the capability perspective, the MAG in certain 
> supported address 
> >> configuration modes, Ex: IKEv2, IPCP, the address delivery 
> function 
> >> is on the MAG and I dont see any reason why we cannot 
> allow the same 
> >> when using DHCP.
> >
> > That makes a big difference. Can we conclude that there is no issue 
> > with additional round trips that were pointing out in your 
> earlier email?
> >
> 
> There is a cost, even if its for the initial attach, when 
> ever the DHCP messages are routed back home. That cannot be ignored.
> 
> 
> 
> >> Also, as Behcet pointed out, we like it or not, WiMAX is 
> using this 
> >> mode.
> >
> > their own flavor of PMIPv4. I don't think that justifies us adding 
> > this for PMIPv6. WiMAX has not adopted PMIPv6 yet. So I am 
> not convinced.
> >
> 
> That's the term they chose. But, for all practical purposes 
> that is a DHCP server. So, we have clearly a requirement for 
> this configuration mode. I dont see the issue, as why we cant 
> support that mode, clearly when we are just documenting how 
> that works.
> 
> 
> >> No new DHCP server function. Its the same old DHCP server 
> function, 
> >> that needs to be enabled on the MAG. The draft is only describing 
> >> that configuration mode. I totally agree with you, if we 
> endup with 
> >> lots of changes, but what we have is just the text on how 
> that mode 
> >> works.
> >
> > deploying DHCP functionality in a PMIPv6 network - one with DHCP 
> > server on the MAG and the other with DHCP relay on the MAG. 
> Not just 
> > describe some additional configuration information. :)
> >
> 
> :) Well, we are not defining a "new DHCP server" for PMIP. We 
> are only stating that the function as specified in RFC-2131 
> needs to be enabled on a box that is running a MAG function.
> 
> Sri

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 24 Oct 2008 15:47:28 +0900

Hi Vijay,

Thanks for comments. 

When we have discussed possible DHCP scenarios (We originally had 4
different scenarios) in DT, the DHCP server co-located with MAG were
kept for WiMAX deployments. I am not following WiMAX forum network
design so much, but I've remembered somebody mentioned that WiMAX uses
"virtual? DHCP server" running on MAG to interact with MS.

Thus, I thought we had deployment need for this scenario. 

Are there some network design changes in WiMAX forum?

regards,
ryuji

At Thu, 23 Oct 2008 14:16:26 -0400,

---

From: [email-masked]
Date: Fri, 24 Oct 2008 15:48:07 +0900

Hi Vijay,

Thanks for comments. 

regards,
ryuji

---

From: [email-masked]
Date: Fri, 24 Oct 2008 16:05:57 +0900

At Thu, 23 Oct 2008 12:00:04 -0700 (PDT),
> protocol is designed from binding it to a single server.

We had same discussion a long time ago.
Reasons we placed DHCP server at MAG are redundant round trip and unsecured signaling.

-DHCP messages can be terminated at MAG. We use PBU/PBA for signaling
between MAG and LMA.

-DHCP messages are not always secured signalings, it's better to
terminate DHCP signaling between MAG and MN.

These possible issues were originally raised by Vijay last year.

> supporting that mode, we dont see that complexity.

Possible complexity is assigning the same IP address to multiple DHCP servers..
But I thought this is somehow de-facto configuration style for large network.

regards,
ryuji

---

From: [email-masked]
Date: Fri, 24 Oct 2008 16:17:35 +0900

At Thu, 23 Oct 2008 12:04:55 -0700 (PDT),
> scenario of DHCP server on the MAG is identical to this.

Another value is unsecured DHCP message exchange. DHCP messages can be
exchanged securely in PPP link without any security mechanism. 

If we use DHCP relay, we might consider to protect DHCP messages
between relay and server.  However, both entities are in the same
administrative domain (NETLMM domain), there are many way to provide
this security.

regards,
ryuji

---

From: [email-masked]
Date: Fri, 24 Oct 2008 16:33:20 +0900

Hello Charlie,

Each DHCP server does not manage address pools. 
LMA manages the IPv4 address database and delivers assigned IPv4
address to DHCP server by PBU/PBA.

If DHCP databases are for the local parameters (such as DNS server),
you are right. We have to configure the same informatin to all the
DHCP servers. 

ryuji

At Thu, 23 Oct 2008 11:33:29 -0700,

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 24 Oct 2008 13:28:43 -0400

Hi Ryuji,

Current WiMAX specifications talk about a "DHCP proxy" on the ASN GW for
PMIPv4. Not PMIPv6. If there is a need for this scenario, we can revisit
and standardize it separately. For now, I think we should simplify the
PMIPv6 IPv4 support document by having just one scenario described in
it.

Vijay

Ryuji Wakikawa wrote:
>> During the meeting, I had proposed simplifying the document to
>> support just one scenario, where the DHCP relay agent is co-located
>> with the MAG. This would remove the scenario where the DHCP server
>> is co-located with the MAG. The DHCP server with the MAG is more
>> complicated and requires extensions to make sure the mobile node
>> either sees the same DHCP server IP address after a handover or gets
>> involved in a multiple round-trip exchange with the new MAG to get
>> the same IPv4 home address (see section 3.4.1). 
>> 
>> If there is a deployment need for the scenario where the DHCP server
>> is co-located with the MAG, we can standardize it later. For now, I
>> think we should simplify the IPv4 support document.
>> 
>> Comments?
>> 
>> Vijay

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 25 Oct 2008 08:50:58 +0900

Hi Vijay,

Do you think WiMAX forum will put DHCP relay for v4 support on PMIP6?
They have DHCP proxy on every ASN-GW and will not extend it for PMIP- 
v4 support ?
Will ASN-GW have both DHCP relay and server functions? I don't see  
good reason for that.

ryuji

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 24 Oct 2008 20:06:33 -0400

Ryuji Wakikawa wrote:
> v4 support ? Will ASN-GW have both DHCP relay and server functions? I
> don't see good reason for that. 

They have to sort it out. Nothing has been finalized yet. FWIW, the 3GPP
model as the DHCP relay on the MAG and the DHCP server in the LMA. I
expect the two SDOs to be aligned at some point. 

Vijay

>> Current WiMAX specifications talk about a "DHCP proxy" on the ASN GW
>> for PMIPv4. Not PMIPv6. If there is a need for this scenario, we can
>> revisit and standardize it separately. For now, I think we should
>> simplify the PMIPv6 IPv4 support document by having just one
>> scenario described in it. 
>> 
>> Vijay
>> 
>> Ryuji Wakikawa wrote:
>>> Hi Vijay,
>>> 
>>> Thanks for comments.
>>> 
>>> design so much, but I've remembered somebody mentioned that WiMAX
>>> uses "virtual? DHCP server" running on MAG to interact with MS.
>>> 
>>>> either sees the same DHCP server IP address after a handover or
>>>> gets involved in a multiple round-trip exchange with the new MAG
>>>> to get the same IPv4 home address (see section 3.4.1).
>>>> 
>>>> If there is a deployment need for the scenario where the DHCP
>>>> server is co-located with the MAG, we can standardize it later.
>>>> For now, I think we should simplify the IPv4 support document.
>>>> 
>>>> Comments?
>>>> 
>>>> Vijay

---

From: Julien Laganier <[email-masked]>
Date: Fri, 31 Oct 2008 14:58:07 +0100

On Thursday 23 October 2008, Vijay Devarapalli wrote:
> with the MAG. This would remove the scenario where the DHCP server is
> co-located with the MAG.

I support this. (I do not see a valid reason to support two modes of 
operations while the basic PMIPv6 support has only one.)

--julien