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: netlmm-bounces@ietf.org on behalf of Soininen, Jonne (NSN - FI/Espoo)
> Sent: Wed 4/15/2009 5:04 AM
> To: ext Sri Gundavelli; Vijay Devarapalli
> Cc: netlmm@ietf.org
> 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" <sgundave@cisco.com> 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
>> netlmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/netlmm
>
> --
> Jonne Soininen
> Nokia Siemens Networks
>
> Tel: +358 40 527 46 34
> E-mail: jonne.soininen@nsn.com
>
>
> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm
>
>
> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm
>