Subject: [netlmm] Consensus call: RFC5107 based DHCP message intercept at MAG

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 9 Apr 2009 21:48:27 -0700

An issue has been raised on the inclusion of the DHCP Server Identifier Override sub-option (specified in RFC5107) as a means for the MAG to intercept the MN's DHCP messages sent to the DHCP server.  This option allows the relay (MAG) to act like the DHCP server and more directly get the MN to even address the RENEW DHCP requests to itself, so that the MAG can include the Relay Agent option in those messages as well.  Without this option, the relay in the MAG would need to intercept all DHCP messages.  

In PMIPv6, all packets from the MN will go through the MAG - from an implementation perspective, my interpretation is that the use of RFC5107 is likely to make a difference in the extent of hardware based forwarding that is made feasible in the MAG.  Otherwise, functionally, the MAG should be able to intercept all DHCP messages even without this option.  

The issue raised is primarily from an IPR perspective - please see the following link for the IPR terms associated with RFC5107: 

https://datatracker.ietf.org/ipr/124/

I would like to hear WG input on whether you prefer to keep the option in the document or take it out.  If you can provide an explanation for the choice you make (IPR and/or technical), it will be useful.  

Please respond to the list by April 15th, 2009. 

Thanks,
Vidya <as co-chair>

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 9 Apr 2009 21:57:03 -0700 (PDT)

One comment:

All packets will surely go through MAG. In all  OS's, the forwarding
plane will simple route the packet through the tunnel and not punt it
up. With oth the MAG inserting iteself in the path by using this option,
every packet needs to be inspected for DHCP type and punted up. Will have
performance impact.

Also, Vijay will enlighten every one, one how an informational
text can create IPR issues.

Sri

On Thu, 9 Apr 2009, Narayanan, Vidya wrote:

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

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 10 Apr 2009 01:34:09 -0400

Hi Vidya,

One clarification. There is no need for the MAG to intercept the unciast
DHCP requests from the MN to the DHCP server co-located with the LMA. It
can treat the DHCP messages as regular traffic from the MN. The LMA
checks if the MN is requesting the same address it has been allocated.

On the consensus call, my preference is to remove this entire optional
mechanism.

Vijay

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Narayanan, Vidya
> Sent: Thursday, April 09, 2009 9:48 PM
> To: [email-masked]
> Subject: [netlmm] Consensus call: RFC5107 based DHCP message 
> intercept at MAG
> 
> An issue has been raised on the inclusion of the DHCP Server 
> Identifier Override sub-option (specified in RFC5107) as a 
> means for the MAG to intercept the MN's DHCP messages sent to 
> the DHCP server.  This option allows the relay (MAG) to act 
> like the DHCP server and more directly get the MN to even 
> address the RENEW DHCP requests to itself, so that the MAG 
> can include the Relay Agent option in those messages as well. 
>  Without this option, the relay in the MAG would need to 
> intercept all DHCP messages.  
> 
> In PMIPv6, all packets from the MN will go through the MAG - 
> from an implementation perspective, my interpretation is that 
> the use of RFC5107 is likely to make a difference in the 
> extent of hardware based forwarding that is made feasible in 
> the MAG.  Otherwise, functionally, the MAG should be able to 
> intercept all DHCP messages even without this option.  
> 
> The issue raised is primarily from an IPR perspective - 
> please see the following link for the IPR terms associated 
> with RFC5107: 
> 
> I would like to hear WG input on whether you prefer to keep 
> the option in the document or take it out.  If you can 
> provide an explanation for the choice you make (IPR and/or 
> technical), it will be useful.  
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 10 Apr 2009 01:50:35 -0400

Hi Vidya,
 
question for my clarification: why does the MAG need to intercept DHCP messages?
 
Thanks,
 
-Rajeev

________________________________

From: [email-masked] on behalf of Narayanan, Vidya
Sent: Thu 4/9/2009 9:48 PM
To: [email-masked]
Subject: [netlmm] Consensus call: RFC5107 based DHCP message intercept at MAG

Thanks,
Vidya <as co-chair>

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 9 Apr 2009 23:03:46 -0700 (PDT)

Hi Rajeev,

There are two signaling planes, LMA and MAG over PMIP.
LMA and MN over DHCP. We need to tie the flows to ensure
the integrity of the states. We dont want the MAG not to
be aware of what MN is requesting, releasing ..etc. MAG
by including this option, can be in path. This is optional,
a given implementation need not bother.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 9 Apr 2009 23:11:52 -0700

Hi Rajeev,
If the MAG does not intercept DHCP messages, it will be unaware of any DHCP state changes (e.g., lease termination, IP address change/release, etc.) for the MN.  We don't have mandatory defined behavior in the LMA to avoid such potential state changes.  So, short of using RFC5107, the MAG needs to intercept DHCP messages to figure this out. 

I also want to highlight the difference between using and not using RFC5107 behavior.  The use of RFC5107 will allow the MAG to do normal forwarding.  If not, the MAG will need to inspect on the {destination IP address, protocol, port} tuple to trap the DHCP packets destined to the server.  

Vidya

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Koodli, Rajeev
> Sent: Thursday, April 09, 2009 10:51 PM
> To: [email-masked]
> Subject: Re: [netlmm] Consensus call: RFC5107 based DHCP message
> intercept at MAG
> 
> 
> Hi Vidya,
> 
> An issue has been raised on the inclusion of the DHCP Server Identifier
> Override sub-option (specified in RFC5107) as a means for the MAG to
> intercept the MN's DHCP messages sent to the DHCP server.  This option
> allows the relay (MAG) to act like the DHCP server and more directly
> get the MN to even address the RENEW DHCP requests to itself, so that
> the MAG can include the Relay Agent option in those messages as well.
> Without this option, the relay in the MAG would need to intercept all
> DHCP messages.
> 
> In PMIPv6, all packets from the MN will go through the MAG - from an
> implementation perspective, my interpretation is that the use of
> RFC5107 is likely to make a difference in the extent of hardware based
> forwarding that is made feasible in the MAG.  Otherwise, functionally,
> the MAG should be able to intercept all DHCP messages even without this
> option.
> 
> The issue raised is primarily from an IPR perspective - please see the
> following link for the IPR terms associated with RFC5107:
> 
> I would like to hear WG input on whether you prefer to keep the option
> in the document or take it out.  If you can provide an explanation for
> the choice you make (IPR and/or technical), it will be useful.
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 10 Apr 2009 11:33:49 -0400

Hi Vidya, 

> Hi Rajeev,
> If the MAG does not intercept DHCP messages, it will be 
> unaware of any DHCP state changes (e.g., lease termination, 
> IP address change/release, etc.) for the MN.  We don't have 
> mandatory defined behavior in the LMA to avoid such potential 
> state changes.  So, short of using RFC5107, the MAG needs to 
> intercept DHCP messages to figure this out. 

The LMA sends a binding revocation to the MAG if it cannot grant the
request from the MN to renew the IPv4 address.

Similary, if the MN releases the IPv4 address, the LMA would again send
a binding revocation to the MAG to remove the IPv4 binding. 

Anyway, in PMIPv6, the renew lifetime to the IPv4 home address is tied
to the binding cache lifetime. These piece are not loosely connected. 

So you don't need the MAG to intercept the DHCPREQUEST messages sent for
renewing the IPv4 address.

> I also want to highlight the difference between using and not 
> using RFC5107 behavior.  The use of RFC5107 will allow the 
> MAG to do normal forwarding.  If not, the MAG will need to 
> inspect on the {destination IP address, protocol, port} tuple 
> to trap the DHCP packets destined to the server.  

No this is optional. The requirement for the MAG to be on the path for
the DHCP messages is optional. So it does not have to do any of the
above.

NOTE that initial DHCP request messages when the mobile node attaches
always go through the MAG, since it is the relay.

Vijay

> > question for my clarification: why does the MAG need to 
> intercept DHCP 
> > messages?
> > 
> > Thanks,
> > 
> > -Rajeev
> > 
> > 
> > Subject: [netlmm] Consensus call: RFC5107 based DHCP 
> message intercept 
> > at MAG
> > 
> > 
> > 
> means for 
> > the MAG to intercept the MN's DHCP messages sent to the 
> DHCP server.  
> > This option allows the relay (MAG) to act like the DHCP server and 
> > more directly get the MN to even address the RENEW DHCP requests to 
> > itself, so that the MAG can include the Relay Agent option 
> in those messages as well.
> > the MAG should be able to intercept all DHCP messages even without 
> > this option.
> > 
> please see the 
> the option

---

From: <[email-masked]>
Date: Fri, 10 Apr 2009 17:57:02 +0200

Technical:

Since there is really no useful purpose served by including this optional
mechanism I am in favor of removing the associated text from the I-D. I have
yet to see a good use case for including this option being stated on this
thread.

-Raj

On 4/9/09 11:48 PM, "ext Narayanan, Vidya" <[email-masked]> wrote:

> Override sub-option (specified in RFC5107) as a means for the MAG to intercept
> the MN's DHCP messages sent to the DHCP server.  This option allows the relay
> (MAG) to act like the DHCP server and more directly get the MN to even address
> the RENEW DHCP requests to itself, so that the MAG can include the Relay Agent
> option in those messages as well.  Without this option, the relay in the MAG
> would need to intercept all DHCP messages.
> 
> implementation perspective, my interpretation is that the use of RFC5107 is
> likely to make a difference in the extent of hardware based forwarding that is
> made feasible in the MAG.  Otherwise, functionally, the MAG should be able to
> I would like to hear WG input on whether you prefer to keep the option in the
> document or take it out.  If you can provide an explanation for the choice you
> make (IPR and/or technical), it will be useful.
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 10 Apr 2009 17:50:16 -0400

Thanks.
 
I think it is better to keep the LMA solely in charge of the DHCP, and use LMA - MAG signaling for state updates. It also simplifies the matter during handovers (how does the new MAG get the state synchronized, without MN involving in signaling? Does the MN have to send DHCP messages at each handover?). 
 
Having said that, I am okay with keeping the optional mechanism, *as long as*
 
1. we describe the two choices we have - LMA being the sole DHCP node on the network side, which is mandatory, and the optional mechanism of MAG-on-path for DHCP
 
2. Clearly state what needs to be done for handovers for the optional mechanism, in addition to what is the purpose of the optional mechanism (it could not be just informative). 
 
These have to be captured, say in separate paragraphs. 
 
-Rajeev

From: Narayanan, Vidya [mailto:[email-masked]]
Sent: Thu 4/9/2009 11:11 PM
To: Koodli, Rajeev; [email-masked]
Subject: RE: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG

Hi Rajeev,

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 10 Apr 2009 14:54:35 -0700

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Friday, April 10, 2009 8:34 AM
> To: Narayanan, Vidya; Koodli, Rajeev; [email-masked]
> Subject: RE: [netlmm] Consensus call: RFC5107 based DHCP
> messageintercept at MAG
> 
> Hi Vidya,
> 
> > Hi Rajeev,

Binding revocation is not part of the base spec - this assumes support for binding revocation on the LMA and MAG and we cannot write the IPv4 spec assuming that, unless we want to make it a normative requirement to do this.  

> to the binding cache lifetime. These piece are not loosely connected.

I'm not seeing text that mandates tying these two lifetimes together - can you please point me to it?  Again, unless the requirement is normative, we'll need to cover the cases when things can fall out of sync.  

> the DHCP messages is optional. So it does not have to do any of the

In the absence of binding revocation support and any normative requirement mandating the DHCP lease times to be identical to the binding lifetimes, the MAG will need to do this to stay in sync - I think that if it falls out of sync, the impact may not be serious perhaps, but I will need to think through that. 

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 10 Apr 2009 15:16:45 -0700

Hi Vidya,

On 4/10/09 2:54 PM, "Narayanan, Vidya" wrote:
> Binding revocation is not part of the base spec - this assumes support for
> binding revocation on the LMA and MAG and we cannot write the IPv4 spec
> assuming that, unless we want to make it a normative requirement to do this.

Good point.
 
> I'm not seeing text that mandates tying these two lifetimes together - can you
> please point me to it?  Again, unless the requirement is normative, we'll need
> to cover the cases when things can fall out of sync.

It is true that there isn't any text right now. But isn't it obvious? If
there binding is not there, then the MN cannot use the IPv4 address it has.
The MAG can't route the packets. Similarly if the binding is there and the
MN wants to renew the IPv4 address, why would the LMA deny it? IMO, the two
lifetimes are tied. The LMA ensures these two are consistent. Perhaps we
should add some text to make this explicit, if it is not obvious.
 
> In the absence of binding revocation support and any normative requirement
> mandating the DHCP lease times to be identical to the binding lifetimes, the
> MAG will need to do this to stay in sync - I think that if it falls out of
> sync, the impact may not be serious perhaps, but I will need to think through
> that.

Even if the binding revocation mechanism is not used, there isn't any issue.
When the mobile node releases the address, the binding could exist for a
little longer. The MAG will eventually delete the binding. It would delete
the binding sooner if there MN detaches from the MAG after the MN releases
the IPv4 address.

Vijay

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 11 Apr 2009 22:57:58 -0400

Hi Vijay and Vidya,

> checks if the MN is requesting the same address it has been allocated.

You are right only if DHCP server is co-located with the LMA.
This document also covers the other scenario where DHCP-server can be  
solely located in PMIP6 domain.
We should not mandate to locate DHCP server at LMA.

To verify renewing DHCP message at the solely located DHCP-server, we  
need additional interface
between DHCP server and LMA (to exchange binding status).
This is totally out of scope in this document.

Then, available options we have are
- using RFC 5107
- MAG inspects all the packets to capture DHCP unicast message for  
renew.

I don't want to increase the operator's opportunity of packets'  
inspection.
If MAG has packets inspection feature because of IPv4 support spec.,
operators can easily start some other operations (often annoying) by  
their nature..

As a conclusion I want to keep 5107 in the document.

thanks
ryuji

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 12 Apr 2009 15:25:44 -0500

Hi Vidya,

>From the beginning I hated the mess of the too many DHCP options and the
attempt to address all possible options despite if it is relevant to
PMIP6 or not.

My understanding, managing the MN PMIP6 BCE with respect to mobility,
binding an IPv4 address, etc. should be left to (P)MIP6 signaling, its
extensions, and any other relative signaling that is meant to manage the
PMIP6 BCE. 

I see this option as a kluge for forcing the use of DHCP signaling to
help manage the MN PMIP6 BCE and , IMO, this is something like
spaghetti. My understanding of every IP mobility protocol is that a node
called the anchor is the one which ensure the binding of the mobile node
home address to the address that the mobile node is reached at, care-of
address. This node call it HA, LMA, MAP, or whatever ...

Adding an IPv4 home address to the MN PMIP6 BCE SHOULD follow the same
concept. The anchor node (HA, LMA, etc.) should be the sole node which
manage this IP address while maintaining the reachability of this home
address. Yes, the LMA can use whatever means possible to allocate this
IP address dynamically BUT as long as the LMA is the node which ensures
the reachability of this address, the anchor node is the only node that
needs to manage this IPv4 home address.

After all, I strongly believe that in order to have a clean DHCP
interaction with PMIP6, the LMA SHOULD be the node which interacts with
DHCP infrastructure for the allocation of the IPv4 home address, i.e.
allocation, release, lifetime update, etc. On the other hand, if PMIP6
is not deployed, for sure all other kind of options can be considered
and probably we wont be discussing them here. 

Finally, regardless of the IPR declaration, I believe this option is a
complexity that is not needed. 

Regards,
Ahmad

> Sent: Thursday, April 09, 2009 11:48 PM
> To: [email-masked]

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 12 Apr 2009 15:46:03 -0500

Hi Vidya and Vijay,

> unaware of 
> > > any DHCP state changes (e.g., lease termination, IP address 
> > > change/release, etc.) for the MN.  We don't have 
> mandatory defined 
> > > behavior in the LMA to avoid such potential state changes.  So, 
> > > short of using RFC5107, the MAG needs to intercept DHCP 
> messages to 
> > > figure this out.
> > 
> > Similary, if the MN releases the IPv4 address, the LMA would again 
> > send a binding revocation to the MAG to remove the IPv4 binding.
> > 
> 
> Binding revocation is not part of the base spec - this 
> assumes support for binding revocation on the LMA and MAG and 
> we cannot write the IPv4 spec assuming that, unless we want 
> to make it a normative requirement to do this.  
>
[Ahmad]
I believe having a normative requirement to use Binding Revocation,
which is a MEXT/Netlmm wg item, is a much cleaner solution and
separation between the protocols that managed the MN BCE and those which
is meant for host configuration. 

May be another idea (I understand that is way too late) is to propose an
extension for the base protocol which allows the LMA to initiate an
update to the MAG by sending a Binding Update Trigger "BUT" informing
the MAG with the IPv4 home address release. The MAG either Ack by
sending a PBA or send a refresh PBU.

> I'm not seeing text that mandates tying these two lifetimes 
> together - can you please point me to it?  Again, unless the 
> requirement is normative, we'll need to cover the cases when 
> things can fall out of sync.  
> 
> > So you don't need the MAG to intercept the DHCPREQUEST 
> messages sent 
> > for renewing the IPv4 address.
> > 
> > > I also want to highlight the difference between using and 
> not using 
> > > RFC5107 behavior.  The use of RFC5107 will allow the MAG to do 
> > > normal forwarding.  If not, the MAG will need to inspect on the 
> > > {destination IP address, protocol, port} tuple to trap the DHCP 
> > > packets destined to the server.
> > 
> In the absence of binding revocation support and any 
> normative requirement mandating the DHCP lease times to be 
> identical to the binding lifetimes, the MAG will need to do 
> this to stay in sync - I think that if it falls out of sync, 
> the impact may not be serious perhaps, but I will need to 
> think through that. 
> 
> Vidya 
> 
> [mailto:[email-masked]] On 
> > > > Behalf Of Koodli, Rajeev
> > > > more directly get the MN to even address the RENEW DHCP 
> requests 
> > > > to itself, so that the MAG can include the Relay Agent option

---

From: Hidetoshi Yokota <[email-masked]>
Date: Mon, 13 Apr 2009 17:57:16 +0900

Hi Rajeev and all,

I have a bit of concern about the restriction that the DHCP server has
to be collocated with the LMA. Some deployment scenario may have
multiple LMAs and one DHCP server in a PMIPv6 domain and there is a
situation where the LMA for some mobile node gets changed to another for
failure recovery reason. If RFC5107 can allow this configuration and
handle this situation well, then it's worth keeping it in the document.
A further clarification will be helpful as you pointed out, though.

Regards,
-- 
Hidetoshi

---

From: KOIDE Kazuhide <[email-masked]>
Date: Mon, 13 Apr 2009 23:02:45 +0900

Hi Vidya,

I am not thoroughly familiar with this issue, but
I think MAGs need to intercept DHCP messages effectively
for DHCP relay functions
because MNs that have DHCP states come from other MAGs.

Best regards,

--koide

---

From: Frank Xia <[email-masked]>
Date: Mon, 13 Apr 2009 09:51:20 -0500

Hi all

Technically:

I am okay with keeping this optional mechanism.

BR
Frank

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 09, 2009 11:48 PM
Subject: [netlmm] Consensus call: RFC5107 based DHCP message intercept at 
MAG

> allows the relay (MAG) to act like the DHCP server and more directly get 
> the MN to even address the RENEW DHCP requests to itself, so that the MAG 
> can include the Relay Agent option in those messages as well.  Without 
> this option, the relay in the MAG would need to intercept all DHCP 
> messages.
>
> implementation perspective, my interpretation is that the use of RFC5107 
> is likely to make a difference in the extent of hardware based forwarding 
> that is made feasible in the MAG.  Otherwise, functionally, the MAG should 
> be able to intercept all DHCP messages even without this option.
>
> I would like to hear WG input on whether you prefer to keep the option in 
> the document or take it out.  If you can provide an explanation for the 
> choice you make (IPR and/or technical), it will be useful.
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 13 Apr 2009 09:15:50 -0700

Hello,

> A further clarification will be helpful as you pointed out, though.

LMA relocation while preserving the IP address for the mobile node is
something that is not supported even in RFC 5213. So can you describe the
above scenario in more detail?

If this is a failover case where another LMA takes over for a failed LMA,
and the state is synced between the two, this change should not even be
visible to the MAG or the MN. All the mobility sessions continue as is.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 13 Apr 2009 11:07:47 -0700

Hi Ryuji,

> We should not mandate to locate DHCP server at LMA.

We have discussed this scenario in the past. I don't think scenario is
necessary. IMO, the MAG should only talk to the LMA. If there is an external
DHCP server (not co-located with the LMA), then it should be the LMA taking
to the DHCP server. Having two control plane protocols on the MAG, both
managing the address for the mobile node is not a good idea.

In addition, you have the issue that Rajeev was brining up. Even in the DHCP
relay case, the client would now see different DHCP server IP address when
there is a MAG-MAG handover, if you force the MAG to be on the path for the
DHCP messages.

Vijay

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Tue, 14 Apr 2009 08:11:10 +0800

Hi Vidya,

This DHCP server identifier option is an optional mechanism and it is
not in the normative text, so I think it is no harm in keeping it in the
text.
Secondly it is useful for the MAG to know the state of the address
assignment procedure associated with the MN for better management. So,
some deployments can use this if they want to. So, I think it should be
kept
in the text and leave the implementors to decide how they want to
implement.

Thanks.

BR,
Mohana

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Narayanan, Vidya
> Sent: Friday, April 10, 2009 12:48 PM
> To: [email-masked]
Identifier
> allows the relay (MAG) to act like the DHCP server and more directly
get
> implementation perspective, my interpretation is that the use of
RFC5107
> I would like to hear WG input on whether you prefer to keep the option
in

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 14 Apr 2009 10:02:03 +0900

Hi Vijay,

> above scenario in more detail?

Here, I'm thinking of a real PMIPv6 deployment not limited to RFC5213.
5213 is the base spec and we all know that we need further extensions
including binding revocations, redirections, etc. The concern I raised
here is that it would be a bit restrictive if the collocation of the LMA
and DHCP server is mandated.

> visible to the MAG or the MN. All the mobility sessions continue as is.

If the state is synced between the two, yes. But in the collocated case,
a change of LMA means a change of DHCP server. DHCP and PMIP are
basically separate things in protocol and operations although their
states should be in sync. Here, I raised a question that this
collocation is a must or a choice.

Regards,
-- 
Hidetoshi

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 13 Apr 2009 18:43:31 -0700 (PDT)

Hi Vidya,
  I agree with Ryuji's conclusion and
 I prefer to keep the option in the document.

Regards,
Behcet

________________________________
From: Ryuji Wakikawa <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
Cc: [email-masked]
Sent: Saturday, April 11, 2009 9:57:58 PM
Subject: Re: [netlmm] Consensus call: RFC5107 based DHCP message intercept at MAG

Hi Vijay and Vidya,

You are right only if DHCP server is co-located with the LMA.
This document also covers the other scenario where DHCP-server can be solely located in PMIP6 domain.
We should not mandate to locate DHCP server at LMA.

To verify renewing DHCP message at the solely located DHCP-server, we need additional interface
between DHCP server and LMA (to exchange binding status).
This is totally out of scope in this document.

Then, available options we have are
- using RFC 5107
- MAG inspects all the packets to capture DHCP unicast message for renew.

I don't want to increase the operator's opportunity of packets' inspection.
If MAG has packets inspection feature because of IPv4 support spec.,
operators can easily start some other operations (often annoying) by their nature..

thanks
ryuji

---

From: xiajinwei <[email-masked]>
Date: Tue, 14 Apr 2009 12:01:55 +0800

Hi Vijay and Ryuji,
	
	Sorry for my jumping this thread. 

> We have discussed this scenario in the past. I don't think 
> scenario is necessary. IMO, the MAG should only talk to the 
> LMA. If there is an external DHCP server (not co-located with 
> the LMA), then it should be the LMA taking to the DHCP 
> server. Having two control plane protocols on the MAG, both 

I guess the scenario you describe is a set of LMA share sole DHCP-S, in this
case LMA should act as DHCP-R if it will be aware of DHCP state changes for
MN, thus it is LMA using RFC5107 rather than MAG.  it seems RFC5107 is still
kept in this document.

BR
	Jinwei

> 
> In addition, you have the issue that Rajeev was brining up. 
> Even in the DHCP relay case, the client would now see 
> different DHCP server IP address when there is a MAG-MAG 
> handover, if you force the MAG to be on the path for the DHCP 
> messages.
> 
> Vijay
>  
> > need additional interface between DHCP server and LMA (to exchange 
> > binding status).
> >> On the consensus call, my preference is to remove this entire 
> >> optional mechanism.
> >> 
> >> Vijay
> >> 
> >>> Identifier Override sub-option (specified in RFC5107) as 
> a means for 
> requests to 
> >>> itself, so that the MAG can include the Relay Agent 
> option in those 
> >>> messages as well.
> >>> Without this option, the relay in the MAG would need to intercept 
> >>> all DHCP messages.
> >>> 
> >>> RFC5107 is likely to make a difference in the extent of hardware 
> >>> based forwarding that is made feasible in the MAG.  Otherwise, 
> >>> functionally, the MAG should be able to intercept all 
> DHCP messages 
> >>> even without this option.
> >>> 
> please see 
> >>> the following link for the IPR terms associated with RFC5107:
> >>> 
> >>> I would like to hear WG input on whether you prefer to keep the 
> >>> option in the document or take it out.  If you can provide an 
> >>> explanation for the choice you make (IPR and/or 
> technical), it will 
> >>> be useful.
> >>>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 14 Apr 2009 01:30:32 -0400

Hi Ahmad,

> is meant for host configuration.

I can't agree on this. BR is now big spec., it is much better to refer  
to RFC5107 since DHCP is needed for IPv4 support.
The use of RFC5107 is much straightforward.

> sending a PBA or send a refresh PBU.

Hmm, i dont think this is good solution.
If MAG can detects DHCP renew, it can always send PBU to verify the  
IPv4 address leasing time.

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 14 Apr 2009 01:34:23 -0400

Hi Yokota-san,

> and DHCP server is mandated.

I agree. if there is a case to deploy DHCP server solely in PMIP6  
domain,
we need to keep RFC5107 or MAG promiscuous listening. I prefer using  
5107.

> basically separate things in protocol and operations although their

This is good point.  It's useful to have just normative reference to  
5107.

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 14 Apr 2009 01:39:36 -0400

Hi Vijay,

> necessary. IMO, the MAG should only talk to the LMA. If there is an  

I know you don't agree on the scenario, but there are people who think  
the scenario is valid..
> there is a MAG-MAG handover, if you force the MAG to be on the path  

Why different DHCP server? The MAG-MAG handover is transparent to MN.
DHCP client does not get any influence from the handover.
I probably miss something here, can you explain this? Is this new issue?

ryuji

>>> optional

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 14 Apr 2009 01:47:32 -0400

Hi Rajeev,

On 2009/04/10, at 17:50, Koodli, Rajeev wrote:

>
> Thanks.
>
> I think it is better to keep the LMA solely in charge of the DHCP,  
> and use LMA - MAG signaling for state updates. It also simplifies  
> the matter during handovers (how does the new MAG get the state  
> synchronized, without MN involving in signaling? Does the MN have to  
> send DHCP messages at each handover?).

MN does not send any DHCP messages at handover, because HO is  
transparent to MN.
When MN renew the  IP address, the new MAG (DHCP-relay) will intercept  
the packets with RFC5107 or promiscuous interception to sync the state  
(verify the IPv4 leasing time. DHCP relay does not maintain any states  
of DHCP clients).

regards,
ryuji

> 1. we describe the two choices we have - LMA being the sole DHCP  
> node on the network side, which is mandatory, and the optional  
> mechanism of MAG-on-path for DHCP
>
> 2. Clearly state what needs to be done for handovers for the  
> optional mechanism, in addition to what is the purpose of the  
> optional mechanism (it could not be just informative).
>
> If the MAG does not intercept DHCP messages, it will be unaware of  
> any DHCP state changes (e.g., lease termination, IP address change/ 
> release, etc.) for the MN.  We don't have mandatory defined behavior  
> in the LMA to avoid such potential state changes.  So, short of  
> using RFC5107, the MAG needs to intercept DHCP messages to figure  
> this out.
>
> I also want to highlight the difference between using and not using  
>> question for my clarification: why does the MAG need to intercept  
>> DHCP
>> messages?
>>
>> Thanks,
>>
>> -Rajeev
>>
>>
>> intercept
>> based
>> this
>> option

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 14 Apr 2009 11:23:11 -0400

Hi Ryuji,

>(verify the IPv4 leasing time. DHCP relay does not maintain any states 

Until the MN sends any DHCP messages, the new MAG will not have the consistent DHCP state then right?
Also, all the MAGs should be configured with this support.
 
Thanks,
 
-Rajeev

regards,
ryuji

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 14 Apr 2009 08:33:21 -0700 (PDT)

Rajeev:

On Tue, 14 Apr 2009, Ryuji Wakikawa wrote:

>> I think it is better to keep the LMA solely in charge of the DHCP, and use 
>> LMA - MAG signaling for state updates. It also simplifies the matter during 
>> handovers (how does the new MAG get the state synchronized, without MN 
>> involving in signaling? Does the MN have to send DHCP messages at each 
>> handover?).
>
> MN does not send any DHCP messages at handover, because HO is transparent to 
> MN.

Yes. HO is transparent. The DHCP entity address on the link that the
MN sees, is the default-router address for that MN, that never changes.
This is true for both when MAG is the DHCP relay and DHCP-S. Even after
a handoff, if the MN triggers the DHCP or not, after handoff it wont see
any change.

So, the address change of the MAG after HO is not an issue at all.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 14 Apr 2009 08:39:16 -0700 (PDT)

Rajeev:

> Also, all the MAGs should be configured with this support.

For the scenario where the DHCP server is collocated with LMA, all MAG's
need to enable DHCP relay service on that link. Yes, thats required,
as in any fixed links where DHCP relay is needed when the server is
outside the link where the host is attached.

The mobile after handoff should trigger DNAv4 procedures for detecting
onlink presence. MAG would complete the PMIP signaling and obtain all
the state from the LMA, during this time.

Sri

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 14 Apr 2009 12:01:48 -0400

Hi Rajeev,

> consistent DHCP state then right?

The general DHCP relay does not keep any states of MN. All the states  
are managed at DHCP server.
We don't need to introduce any new states on DHCP relay for PMIP.

In PMIP, we have decided to manage the address assignment by LMA  
(PMIP) and use DHCP to deliver the assigned address to MN.
To co-operate DHCP and PMIP, we don't need any MN's actions to keep  
consistency of DHCP states.

> Also, all the MAGs should be configured with this support.

Yes, all the MAGs has to be either DHCP relay or server.

regards,
ryuji

>>> all

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 14 Apr 2009 12:46:05 -0400

Hi,
 
there seem to be some loose ends here. The reasoning given for the need to intercept DHCP messages at MAG was to allow for the state consistency between LMA and MAG. Your e-mail below suggests no such actions are necessary (at least for the DHCP-relay functionality). Sri's e-mail (as a reply to my previous e-mail) suggests using DNAv4 on the MN so that the MAG can synchronize the state:
 
"The mobile after handoff should trigger DNAv4 procedures for detecting
onlink presence. MAG would complete the PMIP signaling and obtain all
the state from the LMA, during this time."

If we need DNAv4 for MAG and LMA synchronization, why could we not rely on LMA - MAG signaling in the first place?
 
It would be good to have some clarity (and the corresponding text for revision) :-)
 
Regards,
 
-Rajeev

From: Ryuji Wakikawa [mailto:[email-masked]]
Sent: Tue 4/14/2009 9:01 AM
To: Koodli, Rajeev
Cc: [email-masked]
Subject: Re: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG

Hi Rajeev,

regards,
ryuji

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 14 Apr 2009 10:06:58 -0700 (PDT)

> there seem to be some loose ends here. The reasoning given for the need to intercept DHCP messages at MAG was to allow for the state consistency between LMA and MAG. Your e-mail below suggests no s…

Ok. Probably the way we both said it. Lets look at what we both said.

1. About DNAv4. The mobile node's typically apply DNAv4 for detecting
on-link presence. If DNAv4 procedure is trigerred, the MN will detect
the same link and will not perform DHCP specifically due to handoff
event. If DNAv4 procedure is not used, still the link that we present
from the perspective of layer-2, DHCP, default-router is consistent
and the MN will not detect a change. This is also the HO transparency
that Ryuji was talking about, it needs to be looked at in the context
of the DNA used or not used.

2. DNAv4 procedure has no bearing on the network. Its for the MN
to detect a link change. On the network, for the MAG to trigger
PMIP signaling, the MN-Attach, acces auth, a trigger from the network,
or even a CT from the prev MAG wil trigger the MAG to perform PMIP
signaling.

3. MAG will certainly synchroized the state from LMA through PMIP
signaling, only after each handoff. The MAG will not be in path for
subsequent DHCP events after handoff. This option will enable the MAG
to register itself to be in path for all messages. If a MN releases
an address, if the LMA recycles the address and allocates to some
other node. We will have two host routes one from the MAG1 to LMA,
LMA to MAG2. The kind of inconsistent states can be avoided, by
ensuring the node that created the routing state is aware of all
the DHCP transactions.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Apr 2009 10:49:07 -0700

Hello,

> and DHCP server is mandated.

There are a lot more issues you need to handle with LMA relocation. In
case you want address LMA relocation, I think a separate document which
describes the scenario, how the LMA is changed, how the LMA and the DHCP
server interact, what happens to the mobility sessions that the mobile
node is required.

> collocation is a must or a choice.

ahh.. This is one of my main concerns. We don't want to protocols both
managing the IPv4 address for the mobile node. It should be just the
PMIPv6 protocol. If there is a need for a separate DHCP server in the
PMIPv6 domain, it should be the LMA that interacts with it. Not the MAG.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Apr 2009 10:59:59 -0700

Sri Gundavelli wrote:

> other node. 

This will not happen. If the LMA has a valid binding cache entry for the 
mobile node's IPv4 address, it is not going to allocate the IPv4 address 
to another mobile node.

Vijay

We will have two host routes one from the MAG1 to LMA,
>> If we need DNAv4 for MAG and LMA synchronization, why could we not 
>> rely on LMA - MAG signaling in the first place?
>>
>> interceptat MAG

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Apr 2009 11:05:06 -0700

Hi Ryjji,

> I probably miss something here, can you explain this? Is this new issue?

Sure. When the new MAG uses RFC 5107 to insert itself in the path for 
all DHCP messages, the mobile node sees a different IP address for the 
DHCP server. It earlier had the old MAG as the DHCP server because the 
old MAG had also used RFC 5107 to appear as the DHCP server.

Note that the IPv4 support document currently does not require all the 
MAGs to configure a fixed IP address for the DHCP server IP address in 
the DHCP relay case. The MAGs are required to configure a fixed DHCP 
server IP address only for scenario where the DHCP server is co-located 
with the MAG. You have to now introduce this requirement even for the 
DHCP relay case to avoid the change in the DHCP server IP address as a 
result of a handover.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 14 Apr 2009 11:46:32 -0700 (PDT)

> server interact, what happens to the mobility sessions that the mobile

You can certainly write such document. The question we are discussing
is about the two line informational pointer to 5107, that MAG
implementations can use to keep track of DHCP transactions. I dont
see a point in requiring such documents for adding this informational
reference.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 14 Apr 2009 11:49:10 -0700 (PDT)

On Tue, 14 Apr 2009, Vijay Devarapalli wrote:

> mobile node's IPv4 address, it is not going to allocate the IPv4 address to 
> another mobile node.
>

We can argue, even if the MN releases the address, the LMA should
keep a floating BCE, or it can cleanup the state. The point is the
need for the PMIP and DHCP entities aware of all transactions,
ensuring the address that the MN requests is the same as what it
obtained PMIP or being aware of MN releasing its address, or about
extending lifetimes for the MAG to ensure the PMIP tunnel life is
valid for the DHCP state.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 14 Apr 2009 11:51:05 -0700 (PDT)

On Tue, 14 Apr 2009, Vijay Devarapalli wrote:

> Sure. When the new MAG uses RFC 5107 to insert itself in the path for all 
> DHCP messages, the mobile node sees a different IP address for the DHCP 
> server. It earlier had the old MAG as the DHCP server because the old MAG had 
> also used RFC 5107 to appear as the DHCP server.
>

No. We already talked about this. The Def-Router address, the link-layer
address that the MN sees on any link is fixed. So, the MN will not see
the prev MAG in path, as you describe.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Apr 2009 11:54:30 -0700

Sri,

Sri Gundavelli wrote:
>> This will not happen. If the LMA has a valid binding cache entry for 
>> the mobile node's IPv4 address, it is not going to allocate the IPv4 
>> address to another mobile node.
>>
> 
> keep a floating BCE, or it can cleanup the state. 

The MAG has not removed the binding yet. So the LMA cannot cleanup the 
state or remove the binding. It has to at least send a binding 
revocation message to the MAG and get a response to the that. It won't 
allocate the IPv4 address to another mobile node until that. It is a 
really bad idea for the LMA to remove the binding that the MAG created 
based on the DHCP release message from the mobile node.

Vijay

> The point is the

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 14 Apr 2009 11:58:12 -0700 (PDT)

Vijay,

On Tue, 14 Apr 2009, Vijay Devarapalli wrote:

> The MAG has not removed the binding yet. So the LMA cannot cleanup the state 
> or remove the binding. It has to at least send a binding revocation message 
> to the MAG and get a response to the that. It won't allocate the IPv4 address 
> to another mobile node until that. It is a really bad idea for the LMA to 
> remove the binding that the MAG created based on the DHCP release message 
> from the mobile node.
>

Dont bring revocation into picture. We are not talking about
a revoked session. There is a spec 5107, or if not the MAG can
certainly intercept all DHCP packets. Either way, revocation
has no business here.

Like I said, you can argue LMA need not remove the MN state
even if the address is released, it can hang on to it for
ever. The point is for the MAG to be aware of the MN-LMA
DHCP states.

Sri

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 15 Apr 2009 15:04:00 +0300

Hello everybody,

I looked at the discussion and the draft, and here are my thoughts for this
discussion. I'm not sure if really helps to find the consensus, but perhaps
to structure the thinking:

Basically the MAG understanding the DHCP state is optional:

The document says basically the the Mag could, perhaps, follow the DHCP
signalling between the MN and the LMA (or DHCP server at the LMA) if it
really so wishes. If it does follow that signalling it may then even do
something with the information.

The RFC-5107 use is an optional way to implement an optional feature:

It is a way to make sure the MAG is in the signalling path, if the MAG even
should be in the Signalling path.

So, my question is: What would break if the optional way to implement an
optional feature wouldn't be in the spec? Would that create an
interoperability issue? Would it prohibit using of RFC-5107 if an
implementation would need it?

The negative side of having the feature in is the spec is longer, and more
complex without really giving any real support for the implementers or
without addressing really any real issues.

How does the tradeoff analysis look like?

Cheers,

Jonne. 

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 15 Apr 2009 10:38:51 -0500

Hi Ryuji,

> >> Binding revocation is not part of the base spec - this assumes 
> >> support for binding revocation on the LMA and MAG and we 
> cannot write 
> >> the IPv4 spec assuming that, unless we want to make it a normative 
> >> requirement to do this.
> >>
> > [Ahmad]
> > separation between the protocols that managed the MN BCE and those 
> > which is meant for host configuration.
> 
> I can't agree on this. BR is now big spec., it is much better 
> to refer to RFC5107 since DHCP is needed for IPv4 support.
[Ahmad]
This is absolutely a very interesting argument.
The whole concept of this DHCP kluge (as I prefer to call it) is for the
MAG to be aware of the state of the IPv4 address. In other words, in
order for the MAG and the LMA to stay in sync with respect to resources
and state of the MN BCE. Is NOT that what we are trying to do here?

If maintaining a synchronized state between the MAG and the LMA with
respect to MN BCE is important, then I assume that other scenarios where
synchronization between the MAG and the LMA is important too. Right? 
Then using the same logic, BR should be as important to be used. If BR
is needed anyway, it seems that you do not have a problem solving this
issue by a normative text to BR:)

> > May be another idea (I understand that is way too late) is 
> to propose 
> > an extension for the base protocol which allows the LMA to 
> initiate an 

[Ahmad]
Okay, you should take that suggestion with a grain of salt:) Although,
this is nothing but another way of using BR message and calling it
something else:) In other words, if BR is used, then we do not have any
problem in the case of IPv4 address release. However, in the renewal
case, BR can still be used if the proper trigger is defined and used.

However, the fundamental issue here is the clean separation between two
control protocols that are used for two different things. Otherwise, as
I said, it becomes spaghetti, and from architectural point of view, that
is not good and a recipe for more kluges in the future. 

For example, If I remember correctly, MIP4-gen-ext did not advance,
after passing wg LC, because DHCP experts told us that Host
configuration needs to be left for DHCP and MIP4 signaling for mobility
management. I personally supported that view. In that case, MIP4
signaling should be enhanced to make DHCP works naturally without MIP4
signaling involvement or kluge:)

Similarly, we should propose a PMIP6 system that works naturally with
other control protocols without further inter-protocol mixing here and
there. 

BTW: When the DHCP-Relay adds its Identities sub-option to force the MN
to send its future DHCP requests to it, is that server still called a
Relay-DHCP server? I think it should be called Half-Relay-Half-Server:)

> >> I'm not seeing text that mandates tying these two 
> lifetimes together 
> >> - can you please point me to it?  Again, unless the requirement is 
> >> normative, we'll need to cover the cases when things can 
> fall out of 
> >> sync.
> >>
> >> In the absence of binding revocation support and any normative 
> >> requirement mandating the DHCP lease times to be identical to the 
> >> binding lifetimes, the MAG will need to do this to stay in 
> sync - I 
> >> think that if it falls out of sync, the impact may not be serious 
> >> perhaps, but I will need to think through that.
> >>
> >> Vidya
> >>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 15 Apr 2009 13:26:34 -0400

Hi Jonne,
 
the issue is not so much whether this is optional or not, and not even about what would break if an optional feature is included.
 
The reasoning is not clear, at least ambiguous based on the e-mail replies I have seen.
 
It is not well-drawn out. Even optional mechanisms need to be specified clearly (assuming that someone may be interested in them or make an informed choice based on what to expect). I think this needs a little bit of work. 
 
The idea that DHCP interaction could be in a separate document is not bad, after all..
 
Regards,
 
-Rajeev

From: [email-masked] on behalf of Soininen, Jonne (NSN - FI/Espoo)
Sent: Wed 4/15/2009 5:04 AM
To: ext Sri Gundavelli; Vijay Devarapalli
Cc: [email-masked]
Subject: Re: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG

Hello everybody,

Cheers,

Jonne.

--
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 15 Apr 2009 10:45:09 -0700 (PDT)

Rajeev,

I thought we clarified to your last email. I'm not sure, if
you disagreed with that email or if you think thats not of
a concern, or still not clear.

The question is very simple, are we ok, MAG not being aware of
the DHCP flows between MN and LMA/DHCP-S. There is no other
reasoning beyond this, we want the MAG to be in path for ensuring
the address that the MN obtains, or when it extends the DHCP
leases, or releases, the MAG can be aware of it. We want both the
PMIP states and DHCP states to be identical. There is nothing more
or to this. Keeping the MAG aware of it will allow ensure, it will
keep the PMIP states in sync. If the negotiated address is different
or released, it can do appropriate PMIP signaling and keep the
states in sync.

Sri

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 15 Apr 2009 13:46:44 -0400

Sri,
 
the reasoning needs to be in the document. The handover part needs to be described. 
 
Please see my previous e-mail (4/10).
 
"Having said that, I am okay with keeping the optional mechanism, *as long as*

These have to be captured, say in separate paragraphs."

Thanks,

-Rajeev

From: Sri Gundavelli [mailto:[email-masked]]
Sent: Wed 4/15/2009 10:45 AM
To: Koodli, Rajeev
Cc: [email-masked]
Subject: Re: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG

Rajeev,

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 15 Apr 2009 10:57:13 -0700 (PDT)

Ok. This is a positive feedback. We will check and ensure this clearly
covered.

Regards
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 15 Apr 2009 16:36:48 -0500

Hi Ryuji,

Just as a follow up on this topic. 

Under section 3.4.2, the following text describes the available options
for the MAG in order to be aware of the state of the MN IPv4 address. It
reads as follows:

"
   IPv4 Home Address Renewal to the same DHCP server: (No Handover)

   o  When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it
      directly unicasts DHCPREQUEST message to the DHCP server.  The
      DHCP relay agent may not detect these unicasted DHCPREQUEST
      messages for renewing the address.  Thus, any of the following
      approaches can be adopted.

.....
.....
"

My concern here is: "Thus, any of the following approaches can be
adopted." 
In other words, the MAG needs to ONLY implement ONE of these options.
Right?

My Question is the following: Since implementation of the "DHCP Server
Identifier Override Sub-option" as per RFC5107 is OPTIONAL on the DHCP
server, the DHCP server MAY ignore this sub-option.
 
NOW: In that case, what the MAG (DHCP Relay), which implemented this
sub-option, is supposed to do in order to be aware of the state of the
MN IPv4 address? 

Thanks!

Regards,
Ahmad

> From: Muhanna, Ahmad (RICH1:2H10) 
> Sent: Wednesday, April 15, 2009 10:39 AM
> To: 'Ryuji Wakikawa'
> Cc: 'Narayanan, Vidya'; 'Vijay Devarapalli'; 'Koodli, 
> Rajeev'; [email-masked]'
> The whole concept of this DHCP kluge (as I prefer to call it) 
> is for the MAG to be aware of the state of the IPv4 address. 
> In other words, in order for the MAG and the LMA to stay in 
> sync with respect to resources and state of the MN BCE. Is 
> NOT that what we are trying to do here?
> 
> If maintaining a synchronized state between the MAG and the 
> LMA with respect to MN BCE is important, then I assume that 
> other scenarios where synchronization between the MAG and the 
> LMA is important too. Right? 
> Then using the same logic, BR should be as important to be 
> used. If BR is needed anyway, it seems that you do not have a 
> problem solving this issue by a normative text to BR:)
> 
> 
> Okay, you should take that suggestion with a grain of salt:) 
> Although, this is nothing but another way of using BR message 
> and calling it something else:) In other words, if BR is 
> used, then we do not have any problem in the case of IPv4 
> address release. However, in the renewal case, BR can still 
> be used if the proper trigger is defined and used.
> 
> However, the fundamental issue here is the clean separation 
> between two control protocols that are used for two different 
> things. Otherwise, as I said, it becomes spaghetti, and from 
> architectural point of view, that is not good and a recipe 
> for more kluges in the future. 
> 
> For example, If I remember correctly, MIP4-gen-ext did not 
> advance, after passing wg LC, because DHCP experts told us 
> that Host configuration needs to be left for DHCP and MIP4 
> signaling for mobility management. I personally supported 
> that view. In that case, MIP4 signaling should be enhanced to 
> make DHCP works naturally without MIP4 signaling involvement 
> or kluge:)
> 
> Similarly, we should propose a PMIP6 system that works 
> naturally with other control protocols without further 
> inter-protocol mixing here and there. 
> 
> BTW: When the DHCP-Relay adds its Identities sub-option to 
> force the MN to send its future DHCP requests to it, is that 
> server still called a Relay-DHCP server? I think it should be 
> called Half-Relay-Half-Server:)
> 
> > 
> > ryuji
> > 
> > 
> > >

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 16 Apr 2009 01:48:45 -0400

Hi Ahmad,

> issue by a normative text to BR:)

This synchronization is not done between MAG and LMA,
but DHCP-entity (i.e. MAG) and LMA.

> signaling involvement or kluge:)

BR can solve this issue, but BR is a bit overload for this tiny issue.

In MIPSHOP, you have transient BCE which can be partially solved with  
MCoA.
But you have dedicated solution for this, don't you?

> other control protocols without further inter-protocol mixing here and

Right, but we don't need any modification to either PMIP6 and DHCP.
The informative reference is RFC, which is already standardized...

Ahmad, I am not against to BR, but we should keep this discussion
whether we need the informative reference to RFC5107 or not.

thanks,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 16 Apr 2009 01:54:46 -0400

Hi Ahmad,

> sub-option, is supposed to do in order to be aware of the state of the

The operator needs to place the DHCP entities supporting RFC5107 in  
their PMIP domain.
RFC5107 said
"When configuring a DHCP relay agent to use this suboption, the  
administrator of the relay agent should take into account whether or  
not the DHCP server to which the message will be relayed will  
correctly understand this suboption."

If DHCP server does not support RFC5107, it should perform promiscuous  
interception of all the MN's packets.

regards,
ryuji

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 16 Apr 2009 10:39:42 -0500

Hi Ryuji,

> 
> The operator needs to place the DHCP entities supporting 
> RFC5107 in their PMIP domain.
> RFC5107 said
> "When configuring a DHCP relay agent to use this suboption, 
> the administrator of the relay agent should take into account 
> whether or not the DHCP server to which the message will be 
> relayed will correctly understand this suboption."
> 
> If DHCP server does not support RFC5107, it should perform 
> promiscuous interception of all the MN's packets.

[Ahmad]
Then, there is a potential for the MAG to do both of these options NOT
only one. I believe that should be captured in the draft some how.

> >> Cc: 'Narayanan, Vidya'; 'Vijay Devarapalli'; 'Koodli, Rajeev'; 
> >> [email-masked]'
> >> The whole concept of this DHCP kluge (as I prefer to call 
> it) is for 
> >> the MAG to be aware of the state of the IPv4 address.
> >> In other words, in order for the MAG and the LMA to stay 
> in sync with 
> >> respect to resources and state of the MN BCE. Is NOT that 
> what we are 
> >> trying to do here?
> >>
> >> respect to MN BCE is important, then I assume that other scenarios 
> >> where synchronization between the MAG and the LMA is 
> important too. 
> >> Right?
> used. If 
> >> BR is needed anyway, it seems that you do not have a 
> problem solving 
> >> Although, this is nothing but another way of using BR message and 
> >> calling it something else:) In other words, if BR is used, 
> then we do 
> >> not have any problem in the case of IPv4 address release. 
> However, in 
> >> the renewal case, BR can still be used if the proper trigger is 
> >> defined and used.
> >>
> >> However, the fundamental issue here is the clean 
> separation between 
> >> two control protocols that are used for two different things. 
> >> Otherwise, as I said, it becomes spaghetti, and from architectural 
> >> point of view, that is not good and a recipe for more 
> kluges in the 
> >> future.
> >>
> advance, 
> >> configuration needs to be left for DHCP and MIP4 signaling for 
> >> mobility management. I personally supported that view. In 
> that case, 
> >> MIP4 signaling should be enhanced to make DHCP works naturally 
> >> without MIP4 signaling involvement or kluge:)
> >>
> naturally with 
> >> other control protocols without further inter-protocol mixing here 
> >> and there.
> >>
> force the 
> >> MN to send its future DHCP requests to it, is that server still 
> >> called a Relay-DHCP server? I think it should be called 
> >> Half-Relay-Half-Server:)
> >>
> >>>
> >>> ryuji
> >>>
> >>>
> >>>>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 16 Apr 2009 10:49:17 -0500

Hi Ryuji,

> > MIP4 signaling should be enhanced to make DHCP works 
> naturally without 
> > MIP4 signaling involvement or kluge:)
> 
> In MIPSHOP, you have transient BCE which can be partially 
> solved with MCoA.

[Ahmad]
I am NOT sure how this is relevant to the discussion here:)

> Ahmad, I am not against to BR, but we should keep this 
> discussion whether we need the informative reference to 
> RFC5107 or not.

[Ahmad]
I am absolutely not after a normative reference for BR nor suggesting
that you are against BR:) Also, the BR piece was NOT suggested by me:)
Although, handling that scenario is already captured in the BR draft.
However, I am interested in less inter-protocol
dependencies/interactions/mixing. I believe the more separation we have
between the different protocols, which handle different functionalities,
the better.

That's all. Nothing personal Ryuji:)

Cheers!
Ahmad

> > MN to send its future DHCP requests to it, is that server 
> still called 
> > a Relay-DHCP server? I think it should be called Half-Relay-Half-
> > Server:)
> >
> >>
> >> ryuji
> >>
> >>
> >>>