Re: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG

[Sri Gundavelli <[e-mail]>]

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

Regards
Sri



On Wed, 15 Apr 2009, Koodli, Rajeev wrote:

>
> 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*
>
> 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."
>
> Thanks,
>
> -Rajeev
>
>
>
>
>
>
>
> ________________________________
>
> From: Sri Gundavelli [mailto:[e-mail]]
> Sent: Wed 4/15/2009 10:45 AM
> To: Koodli, Rajeev
> Cc: [e-mail]
> Subject: Re: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG
>
>
>
> 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
>
>
>
> On Wed, 15 Apr 2009, Koodli, Rajeev wrote:
>
>>
>> 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: [e-mail] on behalf of Soininen, Jonne (NSN - FI/Espoo)
>> Sent: Wed 4/15/2009 5:04 AM
>> To: ext Sri Gundavelli; Vijay Devarapalli
>> Cc: [e-mail]
>> Subject: Re: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG
>>
>>
>>
>> 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.
>>
>>
>> On 4/14/09 9:58 PM, "ext Sri Gundavelli" <[e-mail]> wrote:
>>
>>> Vijay,
>>>
>>>
>>>
>>> On Tue, 14 Apr 2009, Vijay Devarapalli wrote:
>>>
>>>> Sri,
>>>>
>>>> Sri Gundavelli wrote:
>>>>>>>   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.
>>>>>>
>>>>>>  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.
>>>>>>
>>>>>
>>>>>  We can argue, even if the MN releases the address, the LMA should
>>>>>  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.
>>>>
>>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> netlmm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>> --
>> Jonne Soininen
>> Nokia Siemens Networks
>>
>> Tel: [phone]
>> E-mail: [e-mail]
>>
>>
>> _______________________________________________
>> 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
>