Re: [netlmm] Consensus call: RFC5107 based DHCP messageintercept at MAG

[Ryuji Wakikawa <[e-mail]>]

Hi Ahmad,

On 2009/04/15, at 11:38, Ahmad Muhanna wrote:

> Hi Ryuji,
>
>>
>>> Hi Vidya and Vijay,
>>>
>>>>> -----Original Message-----
>>>>> From: Vijay Devarapalli [mailto:[e-mail]]
>>>>> Sent: Friday, April 10, 2009 8:34 AM
>>>>> To: Narayanan, Vidya; Koodli, Rajeev; [e-mail]
>>>>> Subject: RE: [netlmm] Consensus call: RFC5107 based DHCP
>>>>> messageintercept at MAG
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> 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.
>>
>> 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.
>>
> [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:)

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

>>> 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.
>>
>> 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.
>
> [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:)

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?


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

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



>
>
> 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
>>
>>
>>>
>>>>> Anyway, in PMIPv6, the renew lifetime to the IPv4 home
>>>> address is tied
>>>>> 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.
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> 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
>>>>
>>>>> NOTE that initial DHCP request messages when the mobile
>>>> node attaches
>>>>> always go through the MAG, since it is the relay.
>>>>>
>>>>> Vijay
>>>>>
>>>>>
>>>>>>
>>>>>> Vidya
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [e-mail]
>>>> [mailto:[e-mail]] On
>>>>>>> Behalf Of Koodli, Rajeev
>>>>>>> Sent: Thursday, April 09, 2009 10:51 PM
>>>>>>> To: [e-mail]
>>>>>>> Subject: Re: [netlmm] Consensus call: RFC5107 based
>>>> DHCP message
>>>>>>> intercept at MAG
>>>>>>>
>>>>>>>
>>>>>>> Hi Vidya,
>>>>>>>
>>>>>>> question for my clarification: why does the MAG need to
>>>>>> intercept DHCP
>>>>>>> messages?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Rajeev
>>>>>>>
>>>>>>>
>>>>>>> ________________________________
>>>>>>>
>>>>>>> From: [e-mail] on behalf of Narayanan, Vidya
>>>>>>> Sent: Thu 4/9/2009 9:48 PM
>>>>>>> To: [e-mail]
>>>>>>> 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:
>>>>>>>
>>>>>>> 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>
>>>>>>> _______________________________________________
>>>>>>> netlmm mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netlmm mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>> _______________________________________________
>>>>>> netlmm mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>>>
>>>> _______________________________________________
>>>> netlmm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>>
>>> _______________________________________________
>>> netlmm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>>