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

"Koodli, Rajeev" <rkoodli@starentnetworks.com> Fri, 10 April 2009 21:51 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 2820E3A67ED for <netlmm@core3.amsl.com>; Fri, 10 Apr 2009 14:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level:
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 efi290Vopkmi for <netlmm@core3.amsl.com>; Fri, 10 Apr 2009 14:51:09 -0700 (PDT)
Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 59BCA3A6D3F for <netlmm@ietf.org>; Fri, 10 Apr 2009 14:50:46 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id ACDAF90096 for <netlmm@ietf.org>; Fri, 10 Apr 2009 17:51:51 -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 04444-13 for <netlmm@ietf.org>; Fri, 10 Apr 2009 17:51:50 -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>; Fri, 10 Apr 2009 17:51:50 -0400 (EDT)
Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Apr 2009 17:50:16 -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: Fri, 10 Apr 2009 17:50:16 -0400
Message-ID: <4D35478224365146822AE9E3AD4A2666035AAAA5@exchtewks3.starentnetworks.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG
Thread-Index: Acm5l5bZe/rw7pCLTNK7WcN/v0lm3AACK2k9AABlowAAILDu3Q==
References: <BE82361A0E26874DBC2ED1BA244866B9382A1F89@NALASEXMB08.na.qualcomm.com> <4D35478224365146822AE9E3AD4A2666035AAAA2@exchtewks3.starentnetworks.com> <BE82361A0E26874DBC2ED1BA244866B9382A1F91@NALASEXMB08.na.qualcomm.com>
From: "Koodli, Rajeev" <rkoodli@starentnetworks.com>
To: netlmm@ietf.org
X-OriginalArrivalTime: 10 Apr 2009 21:50:16.0633 (UTC) FILETIME=[55B6B290:01C9BA26]
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: Fri, 10 Apr 2009 21:51:10 -0000

 
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:vidyan@qualcomm.com]
Sent: Thu 4/9/2009 11:11 PM
To: Koodli, Rajeev; netlmm@ietf.org
Subject: RE: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG



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

> -----Original Message-----
> From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On
> Behalf Of Koodli, Rajeev
> Sent: Thursday, April 09, 2009 10:51 PM
> To: netlmm@ietf.org
> 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: netlmm-bounces@ietf.org on behalf of Narayanan, Vidya
> Sent: Thu 4/9/2009 9:48 PM
> To: netlmm@ietf.org
> 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
> netlmm@ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm
>
>
> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm