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

"Koodli, Rajeev" <rkoodli@starentnetworks.com> Wed, 15 April 2009 17:25 UTC

Return-Path: <rkoodli@starentnetworks.com>
X-Original-To: netlmm@core3.amsl.com
Delivered-To: netlmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AC03A6BBE for <netlmm@core3.amsl.com>; Wed, 15 Apr 2009 10:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0QN9Pmxro1S for <netlmm@core3.amsl.com>; Wed, 15 Apr 2009 10:25:32 -0700 (PDT)
Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id B29AC3A6B43 for <netlmm@ietf.org>; Wed, 15 Apr 2009 10:25:27 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 996C0905A0 for <netlmm@ietf.org>; Wed, 15 Apr 2009 13:26:35 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10995-10 for <netlmm@ietf.org>; Wed, 15 Apr 2009 13:26:34 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for <netlmm@ietf.org>; Wed, 15 Apr 2009 13:26:34 -0400 (EDT)
Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 13:26:34 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 15 Apr 2009 13:26:34 -0400
Message-ID: <4D35478224365146822AE9E3AD4A2666035AAAB6@exchtewks3.starentnetworks.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netlmm] Consensus call: RFC5107 based DHCP message interceptatMAG
Thread-Index: Acm9wkLfxsB84v3LBE+SeSEdSBiUqAAK8u7w
References: <C60BA7E0.8C5E4%jonne.soininen@nsn.com>
From: "Koodli, Rajeev" <rkoodli@starentnetworks.com>
To: netlmm@ietf.org
X-OriginalArrivalTime: 15 Apr 2009 17:26:34.0742 (UTC) FILETIME=[53327960:01C9BDEF]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
Subject: Re: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Apr 2009 17:25:34 -0000

 
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