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

"Ahmad Muhanna" <amuhanna@nortel.com> Sun, 12 April 2009 20:45 UTC

Return-Path: <AMUHANNA@nortel.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 05B223A6BD5 for <netlmm@core3.amsl.com>; Sun, 12 Apr 2009 13:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level:
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 U4l4E+wfgWMZ for <netlmm@core3.amsl.com>; Sun, 12 Apr 2009 13:45:06 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 98A3F3A6C3F for <netlmm@ietf.org>; Sun, 12 Apr 2009 13:45:06 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3CKjPF17512; Sun, 12 Apr 2009 20:45:26 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 12 Apr 2009 15:46:03 -0500
Message-ID: <C5A96676FCD00745B64AE42D5FCC9B6E1E1E5285@zrc2hxm0.corp.nortel.com>
In-Reply-To: <BE82361A0E26874DBC2ED1BA244866B9382A2013@NALASEXMB08.na.qualcomm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netlmm] Consensus call: RFC5107 based DHCP messageintercept at MAG
Thread-Index: Acm5l5bZe/rw7pCLTNK7WcN/v0lm3AACK2k9AABlowAAE9VMIAANLIQgAGG8XIA=
References: <BE82361A0E26874DBC2ED1BA244866B9382A1F91@NALASEXMB08.na.qualcomm.com><DE33046582DF324092F2A982824D6B0305F9D2A7@mse15be2.mse15.exchange.ms> <BE82361A0E26874DBC2ED1BA244866B9382A2013@NALASEXMB08.na.qualcomm.com>
From: Ahmad Muhanna <amuhanna@nortel.com>
To: "Narayanan, Vidya" <vidyan@qualcomm.com>, Vijay Devarapalli <vijay@wichorus.com>, "Koodli, Rajeev" <rkoodli@starentnetworks.com>, netlmm@ietf.org
Subject: Re: [netlmm] Consensus call: RFC5107 based DHCP messageintercept at 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: Sun, 12 Apr 2009 20:45:08 -0000

Hi Vidya and Vijay,

> > -----Original Message-----
> > From: Vijay Devarapalli [mailto:vijay@wichorus.com]
> > Sent: Friday, April 10, 2009 8:34 AM
> > To: Narayanan, Vidya; Koodli, Rajeev; netlmm@ietf.org
> > 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. 

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.

  
> > 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: 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
> > > _______________________________________________
> > > 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
>