From Basavaraj.Patil@nokia.com Thu Oct 8 05:34:25 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779FA28C0FD for ; Thu, 8 Oct 2009 05:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 iBTGrUzKFK3H for ; Thu, 8 Oct 2009 05:34:24 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A3BE53A683E for ; Thu, 8 Oct 2009 05:34:24 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n98CZi4S019762 for ; Thu, 8 Oct 2009 07:36:05 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 15:35:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 15:35:59 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 8 Oct 2009 14:35:58 +0200 From: To: Date: Thu, 8 Oct 2009 14:35:58 +0200 Thread-Topic: Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc Thread-Index: AcpH27bd1/l4UbOZQmy4iz5/IQXOTA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FAAB54171A6C764E969E6B4CB3C2ADD20C855EDE6BNOKEUMSG03mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Oct 2009 12:35:59.0175 (UTC) FILETIME=[E37E1570:01CA4813] X-Nokia-AV: Clean Subject: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 12:34:25 -0000 --_000_FAAB54171A6C764E969E6B4CB3C2ADD20C855EDE6BNOKEUMSG03mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, One of the Netext WG milestones is: Sep 2009 Initial WG draft on LMA Redirection At IETF75, I-D draft-korhonen-netext-redirect was accepted as the baseline to be adopted as the doc. Process requires that we also run the consensus call on the WG ML. The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, draft-korhonen-netext-redirect-04.txt has now been posted and this is a consensus call for its adoption as WG doc. http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt Please respond by Oct 15th, 09. -Chairs --_000_FAAB54171A6C764E969E6B4CB3C2ADD20C855EDE6BNOKEUMSG03mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,
 
One of the Netext WG milestones is:
Sep 2009       &nb= sp;          Initial WG draft = on LMA Redirection
 
At IETF75, I-D draft-korhonen-netext-redirect was acc= epted as the
baseline to be adopted as the doc. Process requires t= hat we also run
the consensus call on the WG ML.
 
The I-D: Runtime LMA Assignment Support for Proxy Mob= ile IPv6,
draft-korhonen-netext-redirect-04.txt has now been po= sted and this is
a consensus call for its adoption as WG doc.
 
Please respond by Oct 15th, 09.
 
-Chairs
 
--_000_FAAB54171A6C764E969E6B4CB3C2ADD20C855EDE6BNOKEUMSG03mgd_-- From Basavaraj.Patil@nokia.com Mon Oct 12 05:51:19 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B211828C1BD for ; Mon, 12 Oct 2009 05:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.184 X-Spam-Level: X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, 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 Ux290jh-ChSv for ; Mon, 12 Oct 2009 05:51:18 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 92BEF28C18E for ; Mon, 12 Oct 2009 05:51:15 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9CCou6i025386 for ; Mon, 12 Oct 2009 07:51:15 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:50:40 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:50:29 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 12 Oct 2009 14:50:29 +0200 From: To: Date: Mon, 12 Oct 2009 14:50:28 +0200 Thread-Topic: Request for agenda slots at IETF76 Thread-Index: AcpLGlflH/rrxrvASAKC/nxiMYXDtQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FAAB54171A6C764E969E6B4CB3C2ADD20C8565BC78NOKEUMSG03mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Oct 2009 12:50:29.0823 (UTC) FILETIME=[94176CF0:01CA4B3A] X-Nokia-AV: Clean Subject: [netext] Request for agenda slots at IETF76 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 12:51:19 -0000 --_000_FAAB54171A6C764E969E6B4CB3C2ADD20C8565BC78NOKEUMSG03mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The Netext WG has been scheduled to meet on Wednesday, Nov 11th from 1300-1= 500 Afternoon Session I. If you need a time slot on the agenda, please send a request including: 1. I-D name 2. Time needed 3. Relevance to the Netext charter -Raj --_000_FAAB54171A6C764E969E6B4CB3C2ADD20C8565BC78NOKEUMSG03mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,
 
The Netext WG has been scheduled to meet on Wednesday= , Nov 11th from 1300-1500 Afternoon Session I.
If you need a time slot on the agenda, please send a = request including:
1. I-D name
2. Time needed
3. Relevance to the Netext charter
 
-Raj
 
--_000_FAAB54171A6C764E969E6B4CB3C2ADD20C8565BC78NOKEUMSG03mgd_-- From jonne.soininen@nsn.com Mon Oct 12 08:02:57 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21E03A69D2 for ; Mon, 12 Oct 2009 08:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 rd2PUvWyslBP for ; Mon, 12 Oct 2009 08:02:56 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 982723A68F4 for ; Mon, 12 Oct 2009 08:02:56 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9CF2t5l015355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Oct 2009 17:02:55 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9CF2qVc018415; Mon, 12 Oct 2009 17:02:54 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 17:02:45 +0200 Received: from 10.144.23.175 ([10.144.23.175]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.159.32.12]) with Microsoft Exchange Server HTTP-DAV ; Mon, 12 Oct 2009 15:02:44 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 12 Oct 2009 18:02:38 +0300 From: "Soininen, Jonne (NSN - FI/Espoo)" To: Basavaraj Patil , Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc Thread-Index: AcpH27bd1/l4UbOZQmy4iz5/IQXOTADcVLLZ In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Oct 2009 15:02:45.0349 (UTC) FILETIME=[0E089950:01CA4B4D] Subject: Re: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 15:02:57 -0000 Hi, I support this draft. I think it is a good starting point, going to the right direction to fulfill the WG milestone. Cheers, Jonne. On 10/8/09 3:35 PM, "Basavaraj Patil" wrote: > > Hello, > > One of the Netext WG milestones is: > Sep 2009 Initial WG draft on LMA Redirection > > At IETF75, I-D draft-korhonen-netext-redirect was accepted as the > baseline to be adopted as the doc. Process requires that we also run > the consensus call on the WG ML. > > The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, > draft-korhonen-netext-redirect-04.txt has now been posted and this is > a consensus call for its adoption as WG doc. > http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt > > Please respond by Oct 15th, 09. > > -Chairs > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: jonne.soininen@nsn.com From Telemaco.Melia@alcatel-lucent.com Mon Oct 12 13:55:35 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924FF3A67FD for ; Mon, 12 Oct 2009 13:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] 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 4PYaCpuJNHv4 for ; Mon, 12 Oct 2009 13:55:34 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 569253A6767 for ; Mon, 12 Oct 2009 13:55:34 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9CKtVRG020226; Mon, 12 Oct 2009 22:55:31 +0200 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 22:55:31 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4B7E.55BE7A42" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 12 Oct 2009 22:55:30 +0200 Message-ID: <853DD750D9C3724FBF2DF7164FCF641C03934F61@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc Thread-Index: AcpH27bd1/l4UbOZQmy4iz5/IQXOTADoegSQ References: From: "MELIA TELEMACO" To: , X-OriginalArrivalTime: 12 Oct 2009 20:55:31.0359 (UTC) FILETIME=[55F56AF0:01CA4B7E] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 20:55:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4B7E.55BE7A42 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I support the adoption of this ID. I wonder however if the mid-session = redirection described in section 5.5.2 brings more advantages than = complexity. The authors may want to comment on this. =20 Thanks, Telemaco=20 =20 ________________________________ De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Basavaraj.Patil@nokia.com Envoy=E9 : jeudi 8 octobre 2009 14:36 =C0 : netext@ietf.org Objet : [netext] Consensus call to adopt I-D: = draft-korhonen-netext-redirect as WG doc =20 =20 Hello, =20 One of the Netext WG milestones is: Sep 2009 Initial WG draft on LMA Redirection =20 At IETF75, I-D draft-korhonen-netext-redirect was accepted as the baseline to be adopted as the doc. Process requires that we also run the consensus call on the WG ML. =20 The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, draft-korhonen-netext-redirect-04.txt has now been posted and this is a consensus call for its adoption as WG doc. http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt =20 Please respond by Oct 15th, 09.=20 =20 -Chairs =20 ------_=_NextPart_001_01CA4B7E.55BE7A42 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I = support the adoption of this ID. I wonder however if the mid-session redirection described in section 5.5.2 brings more advantages than complexity. The authors may = want to comment on this.

 

Thanks,

Telemaco =

 


De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de = Basavaraj.Patil@nokia.com
Envoy=E9 : jeudi 8 = octobre 2009 14:36
=C0 : = netext@ietf.org
Objet : [netext] = Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG = doc

 

 

Hello,

 

One of the Netext WG milestones = is:

Sep 2009           &nb= sp;      Initial WG draft on LMA Redirection

 

At IETF75, I-D draft-korhonen-netext-redirect was = accepted as the

baseline to be adopted as the doc. Process requires = that we also run

the consensus call on the WG ML.

 

The I-D: Runtime LMA Assignment Support for Proxy = Mobile IPv6,

draft-korhonen-netext-redirect-04.txt has now been = posted and this is

a consensus call for its adoption as WG = doc.

 

Please respond by Oct 15th, 09.

 

-Chairs

 

------_=_NextPart_001_01CA4B7E.55BE7A42-- From xiajinwei@huawei.com Mon Oct 12 23:04:44 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027C53A6887 for ; Mon, 12 Oct 2009 23:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] 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 w4ojUw9IYR59 for ; Mon, 12 Oct 2009 23:04:43 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D9C373A6873 for ; Mon, 12 Oct 2009 23:04:42 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRF00BYGVJUM5@szxga04-in.huawei.com> for netext@ietf.org; Tue, 13 Oct 2009 14:04:42 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRF00GT2VJU2Y@szxga04-in.huawei.com> for netext@ietf.org; Tue, 13 Oct 2009 14:04:42 +0800 (CST) Received: from x65217 ([10.164.12.67]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRF005QOVJUJU@szxml06-in.huawei.com> for netext@ietf.org; Tue, 13 Oct 2009 14:04:42 +0800 (CST) Date: Tue, 13 Oct 2009 14:04:41 +0800 From: Jinwei Xia In-reply-to: To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <006b01ca4bcb$0e3b1dc0$430ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_JkZq6NUufOpNpqeN19Ogsw)" Thread-index: AcpH27bd1/l4UbOZQmy4iz5/IQXOTAD7ui8A Subject: Re: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 06:04:44 -0000 This is a multi-part message in MIME format. --Boundary_(ID_JkZq6NUufOpNpqeN19Ogsw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I support to adopt it to WG doc. It is appropriate time to go forward. Thank you~! BR Jinwei _____ From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Thursday, October 08, 2009 8:36 PM To: netext@ietf.org Subject: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc Hello, One of the Netext WG milestones is: Sep 2009 Initial WG draft on LMA Redirection At IETF75, I-D draft-korhonen-netext-redirect was accepted as the baseline to be adopted as the doc. Process requires that we also run the consensus call on the WG ML. The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, draft-korhonen-netext-redirect-04.txt has now been posted and this is a consensus call for its adoption as WG doc. http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt Please respond by Oct 15th, 09. -Chairs --Boundary_(ID_JkZq6NUufOpNpqeN19Ogsw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi,
 
I support to adopt it to WG doc. It is appropriate time to go forward. Thank you~!
 
 
BR
Jinwei


From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com
Sent: Thursday, October 08, 2009 8:36 PM
To: netext@ietf.org
Subject: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc

 
Hello,
 
One of the Netext WG milestones is:
Sep 2009                  Initial WG draft on LMA Redirection
 
At IETF75, I-D draft-korhonen-netext-redirect was accepted as the
baseline to be adopted as the doc. Process requires that we also run
the consensus call on the WG ML.
 
The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6,
draft-korhonen-netext-redirect-04.txt has now been posted and this is
a consensus call for its adoption as WG doc.
 
Please respond by Oct 15th, 09.
 
-Chairs
 
--Boundary_(ID_JkZq6NUufOpNpqeN19Ogsw)-- From cjbc@it.uc3m.es Mon Oct 12 23:19:37 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6539328C1E0 for ; Mon, 12 Oct 2009 23:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, 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 hZIKzLuza+BJ for ; Mon, 12 Oct 2009 23:19:36 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 2C1253A67EC for ; Mon, 12 Oct 2009 23:19:35 -0700 (PDT) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id D0705744B78; Tue, 13 Oct 2009 08:19:35 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Jinwei Xia In-Reply-To: <006b01ca4bcb$0e3b1dc0$430ca40a@china.huawei.com> References: <006b01ca4bcb$0e3b1dc0$430ca40a@china.huawei.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-gRu/x1eLyvCNj0innX+h" Organization: Universidad Carlos III de Madrid Date: Tue, 13 Oct 2009 08:20:24 +0200 Message-Id: <1255414824.4704.9.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16944.003 Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 06:19:37 -0000 --=-gRu/x1eLyvCNj0innX+h Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, I also support the adoption of the draft as WG document. Carlos On Tue, 2009-10-13 at 14:04 +0800, Jinwei Xia wrote: > Hi, > =20 > I support to adopt it to WG doc. It is appropriate time to go forward. > Thank you~! > =20 > =20 > BR > Jinwei >=20 >=20 > =20 > ______________________________________________________________ > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] > On Behalf Of Basavaraj.Patil@nokia.com > Sent: Thursday, October 08, 2009 8:36 PM > To: netext@ietf.org > Subject: [netext] Consensus call to adopt I-D: > draft-korhonen-netext-redirect as WG doc > =20 > =20 > =20 > =20 > Hello, > =20 > One of the Netext WG milestones is: > Sep 2009 Initial WG draft on LMA Redirection > =20 > At IETF75, I-D draft-korhonen-netext-redirect was accepted as > the > baseline to be adopted as the doc. Process requires that we > also run > the consensus call on the WG ML. > =20 > The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, > draft-korhonen-netext-redirect-04.txt has now been posted and > this is > a consensus call for its adoption as WG doc. > http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt > =20 > Please respond by Oct 15th, 09.=20 > =20 > -Chairs > =20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-gRu/x1eLyvCNj0innX+h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkrUHCgACgkQNdy6TdFwT2f9SwCeManiePjYc6MHZlGnTA5dB3cz 3GcAnjwPx2cFERf8JjI/7eKzNFQmupvH =/lKO -----END PGP SIGNATURE----- --=-gRu/x1eLyvCNj0innX+h-- From behcetsarikaya@yahoo.com Tue Oct 13 08:46:53 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D1C3A6867 for ; Tue, 13 Oct 2009 08:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 q-zvzadHJAt7 for ; Tue, 13 Oct 2009 08:46:53 -0700 (PDT) Received: from web111403.mail.gq1.yahoo.com (web111403.mail.gq1.yahoo.com [67.195.15.144]) by core3.amsl.com (Postfix) with SMTP id 57EAF3A6802 for ; Tue, 13 Oct 2009 08:46:53 -0700 (PDT) Received: (qmail 62799 invoked by uid 60001); 13 Oct 2009 15:46:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1255448814; bh=mhZ1AggDDBUFkDBGbFVX2mp+YWhNNEXTzmtp3ttYh6A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Yc2JK0mpZxAktxu3N6bTrCZTF0KzSytdaXbxa2kU2fBnM17hroXjYnwzZ/IesTHA5B7K0y7ml8kK5JQwqXuf8uBQRvagIohaZ49l4Cu5tlkByn2L4DkjS3D+RIU+uRIc2QWGf41SFoZUKKncoRsZShrVrV+wleKGpeP/E8OkqGQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CrIrZqK7zTQSZoaIwJqsjjoAxUcQpI1s308q7d9HlUX6hrvWRcIrtst2Ch7kdNTdiuTaaJv1jGuFOEyfyg76+QV8xTihihg9cByF30XzHaQ0OM5H2jH7uMMuYFVFguLZl225HTNQOuHmmBJS++r5knaicIK8CO6qf9sQ8AqRvv4=; Message-ID: <911281.62220.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: 0Tt74.sVM1mrnWhIhszwHB5FHDQKZoJKmlE52xO1lvpO5FrirxTTKw8My87i1zfiWDXHD17IhtbFl_zgJbo9uh0XBz3SILVc0k3SAuJr1SNfozr5.1ZLeKJRzU38oRjMQBrdOKZ.QaDCYZY1jGj7yEEKldtzJtAm5SpE8lNG9rByWZKED6ufWAQF7hx6Rbv_nwiUJpfBeOuaacb8Ds2K7yD5zCxZyfwfm_UPmhk074doVdX8Qjbq7fuu3qCqfPUkosUGFapuyHXBpRcZfvSDfpePRQDcTOjIMb.lTNTvL.7a6e_D.wfwMtgCis8DHmR3oXQOTwuhillFz6Fq1N4DNZkPPzTfgC4HgK.mXT2GDv2fV2_sNCSV Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Tue, 13 Oct 2009 08:46:54 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 References: <11879.19213.qm@web111410.mail.gq1.yahoo.com> <4954_1255027987_4ACE3513_4954_9356_1_94C682931C08B048B7A8645303FDC9F3078192F9D9@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 13 Oct 2009 08:46:54 -0700 (PDT) From: Behcet Sarikaya To: "shara@ietf.org" In-Reply-To: <4954_1255027987_4ACE3513_4954_9356_1_94C682931C08B048B7A8645303FDC9F3078192F9D9@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netext@ietf.org, netlmm@ietf.org Subject: [netext] aplusp for PMIPv6 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 15:46:54 -0000 A companion draft to aplusp-dsmip has been submitted for Proxy Mobile IPv6. It can be accessed at the following link. http://www.ietf.org/id/draft-sarikaya-aplusp-pmip-00.txt Regards, Behcet From sgundave@cisco.com Tue Oct 13 18:35:10 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BAA33A6991 for ; Tue, 13 Oct 2009 18:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 BjxxUNbeiCJG for ; Tue, 13 Oct 2009 18:35:09 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 019493A6992 for ; Tue, 13 Oct 2009 18:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3506; q=dns/txt; s=sjiport04001; t=1255484111; x=1256693711; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Sri=20Gundavelli=20|Subject: =20Gateway=20Initiated=20Dual-stack=20lite=20Support=20 |Date:=20Tue,=2013=20Oct=202009=2018:35:10=20-0700=20(PDT )|Message-ID:=20|To:=20netext@ietf.org|cc:=20Frank=20Brockn ers=20|MIME-Version:=201.0; bh=/gHZwzvn8wUA1x+WkutEn94Z/Pao8jYuGmO3Aspq0TY=; b=AWNEWgg/L43/dY44pvLWIyVbGA/hcgmEYphM1ikT6IZTTmkeQKl2jgwH WTBXPxYh6cAhR8rDv8Vmn4LyM4MNMub5xZtOCjgEjIF9ep/GGLRC9wZNc 0PVkrwlcDgVXdfoF7u1nmEWGR6YEjDXtdpUu5tin+HYR6zOie/L17CHPw c=; Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,554,1249257600"; d="scan'208";a="45420767" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 14 Oct 2009 01:35:11 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9E1ZAQU026130; Wed, 14 Oct 2009 01:35:11 GMT Date: Tue, 13 Oct 2009 18:35:10 -0700 (PDT) From: Sri Gundavelli To: netext@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Frank Brockners Subject: [netext] Gateway Initiated Dual-stack lite Support X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 01:35:10 -0000 We have posted a draft on using Gateway Initiated Dual-stack lite approach for IPv6 migration support. Following is the pointer to the draft. http://www.ietf.org/id/draft-gundavelli-softwire-gateway-init-ds-lite-00.txt The key aspect of this solution is the approach by which we are applying dual-stack lite solution to IP mobility architectures. In this gateway initiated dual-stack lite mode we are leveraging the mobile tunnel by extending it to the CGN, and by using a UE specific softwire for session identification. Please review and comment. Abstract Dual-Stack lite has been proposed as a IPv4 to IPv6 transition technology. Dual-stack lite allows a service provider to migrate his network to IPv6, while still offering IPv4 services to the end customer. The dual-stack lite solution uses an IPv4 over IPv6 tunnel between a host (or access device) and a dual-stack lite large scale NAT. Several existing network architectures (e.g. 3GPP, WiMAX, or PPP based broadband networks) already specify dual-stack deployment and leverage tunneling technology between the access device and an access gateway in the provider network. Applying the existing dual- stack lite concept to these networks will result in changes to the end-system and unnecessary tunneling overhead. This draft describes a modified implementation of dual-stack lite where existing access tunnels are extended beyond the access gateway to the dual-stack lite large scale NAT using softwires. This evolved approach applies to IPv4 as well as IPv6 networks. Regards ---------- Forwarded message ---------- Date: Tue, 13 Oct 2009 18:08:24 -0700 (PDT) From: IETF I-D Submission Tool To: sgundave@cisco.com Cc: fbrockne@cisco.com Subject: New Version Notification for draft-gundavelli-softwire-gateway-init-ds-lite-00 A new version of I-D, draft-gundavelli-softwire-gateway-init-ds-lite-00.txt has been successfuly submitted by Sri Gundavelli and posted to the IETF repository. Filename: draft-gundavelli-softwire-gateway-init-ds-lite Revision: 00 Title: Gateway Initiated Dual-Stack Lite Deployment Creation_date: 2009-10-13 WG ID: Independent Submission Number_of_pages: 21 Abstract: Dual-Stack lite has been proposed as a IPv4 to IPv6 transition technology. Dual-stack lite allows a service provider to migrate his network to IPv6, while still offering IPv4 services to the end customer. The dual-stack lite solution uses an IPv4 over IPv6 tunnel between a host (or access device) and a dual-stack lite large scale NAT. Several existing network architectures (e.g. 3GPP, WiMAX, or PPP based broadband networks) already specify dual-stack deployment and leverage tunneling technology between the access device and an access gateway in the provider network. Applying the existing dual- stack lite concept to these networks will result in changes to the end-system and unnecessary tunneling overhead. This draft describes a modified implementation of dual-stack lite where existing access tunnels are extended beyond the access gateway to the dual-stack lite large scale NAT using softwires. This evolved approach applies to IPv4 as well as IPv6 networks. The IETF Secretariat. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From ext-fuad.junior@nokia.com Wed Oct 14 04:47:45 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE243A69DE for ; Wed, 14 Oct 2009 04:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 hyVvGFTmuoRB for ; Wed, 14 Oct 2009 04:47:44 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id DBA333A69D8 for ; Wed, 14 Oct 2009 04:47:43 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9EBlQUb012660 for ; Wed, 14 Oct 2009 14:47:42 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 14:47:37 +0300 Received: from mzebe101.NOE.Nokia.com ([172.18.252.71]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 14:47:37 +0300 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: Wed, 14 Oct 2009 08:47:32 -0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc Thread-Index: AcpH27bd1/l4UbOZQmy4iz5/IQXOTAE6FTQQ References: From: To: , X-OriginalArrivalTime: 14 Oct 2009 11:47:37.0160 (UTC) FILETIME=[203C3C80:01CA4CC4] X-Nokia-AV: Clean Subject: Re: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 11:47:45 -0000 Hi all, I support the adoption of this draft as a WG document. Fuad Abinader ________________________________ From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of ext Basavaraj.Patil@nokia.com Sent: quinta-feira, 8 de outubro de 2009 08:36 To: netext@ietf.org Subject: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc =09 =09 =20 Hello, =20 One of the Netext WG milestones is: Sep 2009 Initial WG draft on LMA Redirection =20 At IETF75, I-D draft-korhonen-netext-redirect was accepted as the baseline to be adopted as the doc. Process requires that we also run the consensus call on the WG ML. =20 The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, draft-korhonen-netext-redirect-04.txt has now been posted and this is a consensus call for its adoption as WG doc. http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt =20 =20 Please respond by Oct 15th, 09.=20 =20 -Chairs =09 From AMUHANNA@nortel.com Wed Oct 14 07:15:58 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 900ED3A6A07 for ; Wed, 14 Oct 2009 07:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 o1qG-ldrSOad for ; Wed, 14 Oct 2009 07:15:57 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6968F3A6A09 for ; Wed, 14 Oct 2009 07:15:57 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n9EEFre03090; Wed, 14 Oct 2009 14:15:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4CD8.CDAE2963" Date: Wed, 14 Oct 2009 09:15:36 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc Thread-Index: AcpH27bd1/l4UbOZQmy4iz5/IQXOTAEOUhJQ X-Priority: 1 Priority: Urgent Importance: high X-Message-Flag: Follow up Reply-By: Thu, 15 Oct 2009 12:00:00 -0500 References: From: "Ahmad Muhanna" To: , Subject: Re: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 14:15:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4CD8.CDAE2963 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I read the draft and I believe, conceptually, the draft can work as a base to fulfill the LMA redirection WG item. However, I see few things in the draft that are beyond the scope of this WG charter "LMA Redirection" item: 1.=09 Allowing redirection during re-registration does not make sense. It is not within the scope of load balancing nor, after some short discussion with the authors, there is a strong usecase for it to be included. 2.=09 The draft demotes the use of IKEv2 for establishing the IPsec between the MAG and LMA from "SHOULD" to "MAY". I also, believe that this is not appropriate for the support of this functionality to override RFC5213 requirements. It seems that there is some concern about IPSec failing after the BCE has been created in the r2LMA but that concern can be addressed without the proposed demotion/change. 3.=09 The draft proposes a new error code to basically indicate to the MAG to use redirection functionality. Since, the LMA sends the new error code without a previous knowledge of whether the MAG is a legacy one or not, this cause value is NOT backward compatible. A proposal to use one of the error codes in RFC5213, should address this concern and be acceptable. Regards,=20 Ahmad ________________________________ From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Thursday, October 08, 2009 7:36 AM To: netext@ietf.org Subject: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc =09 =09 =09 =20 Hello, =20 One of the Netext WG milestones is: Sep 2009 Initial WG draft on LMA Redirection =20 At IETF75, I-D draft-korhonen-netext-redirect was accepted as the baseline to be adopted as the doc. Process requires that we also run the consensus call on the WG ML. =20 The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, draft-korhonen-netext-redirect-04.txt has now been posted and this is a consensus call for its adoption as WG doc. http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt =20 =20 Please respond by Oct 15th, 09.=20 =20 -Chairs =20 ------_=_NextPart_001_01CA4CD8.CDAE2963 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I read the draft and I believe, conceptually, = the draft=20 can work as a base to fulfill the LMA redirection WG item. However, I = see few=20 things in the draft that are beyond the scope of this WG = charter "LMA Redirection" = item:
  1. Allowing redirection during re-registration = does not=20 make sense. It is not within the = scope of=20 load balancing nor, after some short discussion with the = authors, there is a strong usecase = for it to be = included.
  2. The draft demotes the use of IKEv2 for establishing = the IPsec=20 between the MAG and LMA from "SHOULD" to "MAY". I also, believe that = this is=20 not appropriate for the support of this functionality to override = RFC5213=20 requirements. It seems that there is some concern about IPSec failing = after the=20 BCE has been created in the r2LMA but that concern can be=20 addressed without the proposed demotion/change.
  3. The draft proposes a new error code to = basically=20 indicate to the MAG to use redirection functionality. Since, the LMA = sends the=20 new error code without a previous knowledge of whether=20 the MAG is a legacy one or not, this cause = value is NOT=20 backward compatible. A proposal to use one of the error codes in=20 RFC5213, should address this concern and be=20 acceptable.

Regards, =
Ahmad



From: netext-bounces@ietf.org=20 [mailto:netext-bounces@ietf.org] On Behalf Of=20 Basavaraj.Patil@nokia.com
Sent: Thursday, October 08, = 2009 7:36=20 AM
To: netext@ietf.org
Subject: [netext] Consensus = call to=20 adopt I-D: draft-korhonen-netext-redirect as WG = doc

 
Hello,
 
One of the Netext WG milestones is:
Sep=20 = 2009           &nb= sp;     =20 Initial WG draft on LMA Redirection
 
At IETF75, I-D draft-korhonen-netext-redirect was = accepted=20 as the
baseline to be adopted as the doc. Process = requires that we=20 also run
the consensus call on the WG ML.
 
The I-D: Runtime LMA Assignment Support for Proxy = Mobile=20 IPv6,
draft-korhonen-netext-redirect-04.txt has now been = posted=20 and this is
a consensus call for its adoption as WG = doc.
http://www.ietf.org/id/draft-korhonen-netext-redirect-= 04.txt
 
Please respond by Oct 15th, 09.
 
-Chairs
 
------_=_NextPart_001_01CA4CD8.CDAE2963-- From jonne.soininen@nsn.com Wed Oct 14 07:31:24 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B70428C18F for ; Wed, 14 Oct 2009 07:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 RlP7qGzGaZ8u for ; Wed, 14 Oct 2009 07:31:23 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id DCF5128C103 for ; Wed, 14 Oct 2009 07:31:22 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9EEVI4R026346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Oct 2009 16:31:19 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9EEVGCY018420; Wed, 14 Oct 2009 16:31:17 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 16:31:11 +0200 Received: from 10.144.23.64 ([10.144.23.64]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.159.32.12]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Oct 2009 14:31:09 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 14 Oct 2009 17:31:06 +0300 From: "Soininen, Jonne (NSN - FI/Espoo)" To: Ahmad Muhanna , Basavaraj Patil , Message-ID: Thread-Topic: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc Thread-Index: AcpH27bd1/l4UbOZQmy4iz5/IQXOTAEOUhJQADF95/c= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Oct 2009 14:31:11.0085 (UTC) FILETIME=[F9CA59D0:01CA4CDA] Subject: Re: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 14:31:24 -0000 Hi Ahmad, Do I read you mail correctly that you do support the draft to become WG item and thus, the basis for the work? As accepting a draft as WG item is the start of the WG work, I guess your concerns are basis of normal discussion for the WG to proceed when the draft is accepted. Cheers, Jonne. On 10/14/09 5:15 PM, "Ahmad Muhanna" wrote: > Hi, > > I read the draft and I believe, conceptually, the draft can work as a > base to fulfill the LMA redirection WG item. However, I see few things > in the draft that are beyond the scope of this WG charter "LMA > Redirection" item: > > 1. > Allowing redirection during re-registration does not make sense. > It is not within the scope of load balancing nor, after some short > discussion with the authors, there is a strong usecase for it to be > included. > 2. > The draft demotes the use of IKEv2 for establishing the IPsec > between the MAG and LMA from "SHOULD" to "MAY". I also, believe that > this is not appropriate for the support of this functionality to > override RFC5213 requirements. It seems that there is some concern about > IPSec failing after the BCE has been created in the r2LMA but that > concern can be addressed without the proposed demotion/change. > 3. > The draft proposes a new error code to basically indicate to the > MAG to use redirection functionality. Since, the LMA sends the new error > code without a previous knowledge of whether the MAG is a legacy one or > not, this cause value is NOT backward compatible. A proposal to use one > of the error codes in RFC5213, should address this concern and be > acceptable. > > Regards, > Ahmad > > > ________________________________ > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] > On Behalf Of Basavaraj.Patil@nokia.com > Sent: Thursday, October 08, 2009 7:36 AM > To: netext@ietf.org > Subject: [netext] Consensus call to adopt I-D: > draft-korhonen-netext-redirect as WG doc > > > > > Hello, > > One of the Netext WG milestones is: > Sep 2009 Initial WG draft on LMA Redirection > > At IETF75, I-D draft-korhonen-netext-redirect was accepted as > the > baseline to be adopted as the doc. Process requires that we also > run > the consensus call on the WG ML. > > The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, > draft-korhonen-netext-redirect-04.txt has now been posted and > this is > a consensus call for its adoption as WG doc. > http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt > > > Please respond by Oct 15th, 09. > > -Chairs > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: jonne.soininen@nsn.com From AMUHANNA@nortel.com Wed Oct 14 07:33:13 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5FF33A68F4 for ; Wed, 14 Oct 2009 07:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 1Z9RKPjUhX-v for ; Wed, 14 Oct 2009 07:33:12 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E06D13A689C for ; Wed, 14 Oct 2009 07:33:05 -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 n9EEX2q08656; Wed, 14 Oct 2009 14:33:03 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: Wed, 14 Oct 2009 09:32:56 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc Thread-Index: AcpH27bd1/l4UbOZQmy4iz5/IQXOTAEOUhJQADF95/cAAA2poA== References: From: "Ahmad Muhanna" To: "Soininen, Jonne (NSN - FI/Espoo)" , "Basavaraj Patil" , Subject: Re: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 14:33:13 -0000 Hi Jonne, Agreed! Regards, Ahmad =20 > -----Original Message----- > From: Soininen, Jonne (NSN - FI/Espoo)=20 > [mailto:jonne.soininen@nsn.com]=20 > Sent: Wednesday, October 14, 2009 9:31 AM > To: Muhanna, Ahmad (RICH1:2H10); Basavaraj Patil; netext@ietf.org > Subject: Re: [netext] Consensus call to adopt I-D:=20 > draft-korhonen-netext-redirect as WG doc >=20 > Hi Ahmad, >=20 > Do I read you mail correctly that you do support the draft to=20 > become WG item and thus, the basis for the work? >=20 > As accepting a draft as WG item is the start of the WG work,=20 > I guess your concerns are basis of normal discussion for the=20 > WG to proceed when the draft is accepted. >=20 > Cheers, >=20 > Jonne. >=20 > On 10/14/09 5:15 PM, "Ahmad Muhanna" wrote: >=20 > > Hi, > > =20 > > I read the draft and I believe, conceptually, the draft can=20 > work as a=20 > > base to fulfill the LMA redirection WG item. However, I see=20 > few things=20 > > in the draft that are beyond the scope of this WG charter "LMA=20 > > Redirection" item: > >=20 > > 1.=20 > > Allowing redirection during re-registration does not make sense. > > It is not within the scope of load balancing nor, after some short=20 > > discussion with the authors, there is a strong usecase for it to be=20 > > included. > > 2.=20 > > The draft demotes the use of IKEv2 for establishing the=20 > IPsec between=20 > > the MAG and LMA from "SHOULD" to "MAY". I also, believe=20 > that this is=20 > > not appropriate for the support of this functionality to override=20 > > RFC5213 requirements. It seems that there is some concern=20 > about IPSec=20 > > failing after the BCE has been created in the r2LMA but=20 > that concern=20 > > can be addressed without the proposed demotion/change. > > 3.=20 > > The draft proposes a new error code to basically indicate=20 > to the MAG=20 > > to use redirection functionality. Since, the LMA sends the=20 > new error=20 > > code without a previous knowledge of whether the MAG is a=20 > legacy one=20 > > or not, this cause value is NOT backward compatible. A=20 > proposal to use=20 > > one of the error codes in RFC5213, should address this=20 > concern and be=20 > > acceptable. > >=20 > > Regards, > > Ahmad > >=20 > >=20 > > ________________________________ > >=20 > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On=20 > > Behalf Of Basavaraj.Patil@nokia.com > > Sent: Thursday, October 08, 2009 7:36 AM > > To: netext@ietf.org > > Subject: [netext] Consensus call to adopt I-D: > > draft-korhonen-netext-redirect as WG doc > >=20 > >=20 > >=20 > >=20 > > Hello, > >=20 > > One of the Netext WG milestones is: > > Sep 2009 Initial WG draft on LMA Redirection > >=20 > > At IETF75, I-D draft-korhonen-netext-redirect was accepted as the=20 > > baseline to be adopted as the doc. Process requires that we=20 > also run=20 > > the consensus call on the WG ML. > >=20 > > The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6,=20 > > draft-korhonen-netext-redirect-04.txt has now been posted=20 > and this is=20 > > a consensus call for its adoption as WG doc. > > http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt > > > >=20 > > Please respond by Oct 15th, 09. > >=20 > > -Chairs > >=20 > >=20 > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext >=20 > -- > Jonne Soininen > Nokia Siemens Networks >=20 > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nsn.com >=20 >=20 >=20 From suresh.krishnan@ericsson.com Wed Oct 14 11:39:04 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ADA03A6842 for ; Wed, 14 Oct 2009 11:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Zo2wFWq+YLFk for ; Wed, 14 Oct 2009 11:39:03 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 4E6B03A6960 for ; Wed, 14 Oct 2009 11:39:03 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n9EIcuOI001095; Wed, 14 Oct 2009 13:39:04 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 13:39:03 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 13:39:03 -0500 Received: from [142.133.10.113] (147.117.20.212) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.1.375.2; Wed, 14 Oct 2009 14:39:02 -0400 Message-ID: <4AD6195D.1090009@ericsson.com> Date: Wed, 14 Oct 2009 14:33:01 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Basavaraj.Patil@nokia.com" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2009 18:39:03.0065 (UTC) FILETIME=[9A2E6890:01CA4CFD] Cc: "netext@ietf.org" Subject: Re: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 18:39:04 -0000 Hi Chairs, I support the adoption of this draft as a wg item. Cheers Suresh On 09-10-08 08:35 AM, Basavaraj.Patil@nokia.com wrote: > > Hello, > > One of the Netext WG milestones is: > Sep 2009 Initial WG draft on LMA Redirection > > At IETF75, I-D draft-korhonen-netext-redirect was accepted as the > baseline to be adopted as the doc. Process requires that we also run > the consensus call on the WG ML. > > The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, > draft-korhonen-netext-redirect-04.txt has now been posted and this is > a consensus call for its adoption as WG doc. > _http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt_ > > Please respond by Oct 15th, 09. > > -Chairs > > From Mohana.Jeyatharan@sg.panasonic.com Wed Oct 14 17:27:06 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C373A6778 for ; Wed, 14 Oct 2009 17:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.32 X-Spam-Level: ** X-Spam-Status: No, score=2.32 tagged_above=-999 required=5 tests=[AWL=2.410, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 6s+hilz1dMED for ; Wed, 14 Oct 2009 17:27:06 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 0923F3A6838 for ; Wed, 14 Oct 2009 17:27:05 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id n9F0R6iB025169; Thu, 15 Oct 2009 09:27:06 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id n9F0R5601839; Thu, 15 Oct 2009 09:27:05 +0900 (JST) 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: Thu, 15 Oct 2009 08:22:54 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD039D8873@pslexc01.psl.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc Thread-Index: AcpH27bd1/l4UbOZQmy4iz5/IQXOTAFUxaAQ From: "Mohana Jeyatharan" To: , Subject: Re: [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 00:27:06 -0000 Hi all, I support the adoption of this draft as a WG draft. BR, Mohana ________________________________________ From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Basavaraj.Patil@nokia.com Sent: Thursday, October 08, 2009 8:36 PM To: netext@ietf.org Subject: [netext] Consensus call to adopt I-D: = draft-korhonen-netext-redirect as WG doc =A0 Hello, =A0 One of the Netext WG milestones is: Sep 2009=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Initial WG = draft on LMA Redirection =A0 At IETF75, I-D draft-korhonen-netext-redirect was accepted as the baseline to be adopted as the doc. Process requires that we also run the consensus call on the WG ML. =A0 The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, draft-korhonen-netext-redirect-04.txt has now been posted and this is a consensus call for its adoption as WG doc. http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt =A0 Please respond by Oct 15th, 09.=20 =A0 -Chairs =A0 From rkoodli@starentnetworks.com Wed Oct 14 23:04:09 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142E43A6841 for ; Wed, 14 Oct 2009 23:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 wCDjR2oNa0uJ for ; Wed, 14 Oct 2009 23:04:08 -0700 (PDT) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 2A7683A67A6 for ; Wed, 14 Oct 2009 23:04:08 -0700 (PDT) X-ASG-Debug-ID: 1255586648-246500780000-XzWF0g X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id BF46FEFC07F for ; Thu, 15 Oct 2009 02:04:08 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id fpCjrRelLlLCiVI4 for ; Thu, 15 Oct 2009 02:04:08 -0400 (EDT) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Oct 2009 02:02:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4D5D.05A948F8" X-ASG-Orig-Subj: Consensus call to adopt ID: draft-premec-netlmm-bulk-re-registration-03.txt as WG doc Date: Thu, 15 Oct 2009 02:02:05 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26660CAC545D@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call to adopt ID: draft-premec-netlmm-bulk-re-registration-03.txt as WG doc Thread-Index: AcpNXm8lPeSrMXWzQC+0mCg6gjMF5A== From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 15 Oct 2009 06:02:05.0599 (UTC) FILETIME=[05ACD2F0:01CA4D5D] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1255586648 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com Subject: [netext] Consensus call to adopt ID: draft-premec-netlmm-bulk-re-registration-03.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 06:04:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4D5D.05A948F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello, =20 One of the Netext WG items is: =20 Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC=20 =20 At the last IETF meeting, there was agreement to use draft-premec-netlmm-bulk-re-registration-02.txt as the baseline document for the above item. =20 This document has been revised to version 03 in which the Group ID proposal outlined in http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-01 has been merged based on author's agreement.=20 =20 This is a consensus call for adoption of http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-03 as the WG document.=20 =20 Please respond by October 21. =20 Thanks, =20 -Rajeev =20 =20 ------_=_NextPart_001_01CA4D5D.05A948F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,
 
One of = the Netext WG=20 items is:
 
Dec=20 2009  Submit Bulk Refresh to IESG for = publication as=20 a Proposed Standard RFC
 
At the last IETF = meeting, there=20 was agreement to use draft-premec-netlmm-bulk-re-registration-02.txt as = the=20 baseline document for the above item.
 
This = document has=20 been revised to version 03 in which the Group ID proposal outlined in http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-opt= ion-01=20 has been merged based on author's agreement.
 
This = is a consensus=20 call for adoption of http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registratio= n-03 as=20 the WG document.
 
Please = respond by=20 October 21.
 
Thanks,
 
-Rajeev
 
 
------_=_NextPart_001_01CA4D5D.05A948F8-- From sunseawq@huawei.com Thu Oct 15 00:30:32 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5309D3A6992 for ; Thu, 15 Oct 2009 00:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 KlGqJKOBYwfn for ; Thu, 15 Oct 2009 00:30:31 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 204293A6874 for ; Thu, 15 Oct 2009 00:30:31 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRJ00EG7OUNKF@szxga02-in.huawei.com> for netext@ietf.org; Thu, 15 Oct 2009 15:30:23 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRJ008ZZOUNM6@szxga02-in.huawei.com> for netext@ietf.org; Thu, 15 Oct 2009 15:30:23 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRJ0093YOUMVZ@szxml06-in.huawei.com> for netext@ietf.org; Thu, 15 Oct 2009 15:30:23 +0800 (CST) Date: Thu, 15 Oct 2009 15:30:22 +0800 From: Qin Wu To: "Koodli, Rajeev" , netext@ietf.org Message-id: <03e201ca4d69$5b03f010$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_jY3MoHqLgX7ODV+aR3oI6g)" X-Priority: 3 X-MSMail-priority: Normal References: <4D35478224365146822AE9E3AD4A26660CAC545D@exchtewks3.starentnetworks.com> Subject: Re: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 07:30:32 -0000 This is a multi-part message in MIME format. --Boundary_(ID_jY3MoHqLgX7ODV+aR3oI6g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, I think this I-D provide one efficient way for PMIP re-Registration and have already been well designed. I would like to support to adopt this I-D. Regards! -Qin ----- Original Message ----- From: Koodli, Rajeev To: netext@ietf.org Sent: Thursday, October 15, 2009 2:02 PM Subject: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc Hello, One of the Netext WG items is: Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC At the last IETF meeting, there was agreement to use draft-premec-netlmm-bulk-re-registration-02.txt as the baseline document for the above item. This document has been revised to version 03 in which the Group ID proposal outlined in http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-01 has been merged based on author's agreement. This is a consensus call for adoption of http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-03 as the WG document. Please respond by October 21. Thanks, -Rajeev ------------------------------------------------------------------------------ _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --Boundary_(ID_jY3MoHqLgX7ODV+aR3oI6g) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi,
I think this I-D provide one efficient way for PMIP re-Registration and have already been well designed. 
I would like to support to adopt this I-D.
 
Regards!
-Qin 
----- Original Message -----
Sent: Thursday, October 15, 2009 2:02 PM
Subject: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc

 
Hello,
 
One of the Netext WG items is:
 
Dec 2009  Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC
 
At the last IETF meeting, there was agreement to use draft-premec-netlmm-bulk-re-registration-02.txt as the baseline document for the above item.
 
This document has been revised to version 03 in which the Group ID proposal outlined in http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-01 has been merged based on author's agreement.
 
This is a consensus call for adoption of http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-03 as the WG document.
 
Please respond by October 21.
 
Thanks,
 
-Rajeev
 
 


_______________________________________________
netext mailing list
netext@ietf.org
https://www.ietf.org/mailman/listinfo/netext
--Boundary_(ID_jY3MoHqLgX7ODV+aR3oI6g)-- From pierrick.seite@orange-ftgroup.com Thu Oct 15 00:53:33 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F283A6856 for ; Thu, 15 Oct 2009 00:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 ZJUEAP-hIht5 for ; Thu, 15 Oct 2009 00:53:32 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 2EB093A6A06 for ; Thu, 15 Oct 2009 00:53:11 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 09:53:10 +0200 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: Thu, 15 Oct 2009 09:53:09 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462652A51@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <5F09D220B62F79418461A978CA0921BD039D8873@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc Thread-Index: AcpH27bd1/l4UbOZQmy4iz5/IQXOTAFUxaAQAA9h+aA= References: <5F09D220B62F79418461A978CA0921BD039D8873@pslexc01.psl.local> From: To: , X-OriginalArrivalTime: 15 Oct 2009 07:53:10.0231 (UTC) FILETIME=[8A1AF670:01CA4D6C] Subject: Re: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 07:53:33 -0000 Hi all, =20 I support the adoption of this draft as a WG document. BR, Pierrick =20 ________________________________________ > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On = Behalf > Of Basavaraj.Patil@nokia.com > Sent: Thursday, October 08, 2009 8:36 PM > To: netext@ietf.org > Subject: [netext] Consensus call to adopt I-D: draft-korhonen-netext- > redirect as WG doc >=20 >=20 > Hello, >=20 > One of the Netext WG milestones is: > Sep 2009=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Initial WG = draft on LMA Redirection >=20 > At IETF75, I-D draft-korhonen-netext-redirect was accepted as the > baseline to be adopted as the doc. Process requires that we also run > the consensus call on the WG ML. >=20 > The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, > draft-korhonen-netext-redirect-04.txt has now been posted and this is > a consensus call for its adoption as WG doc. > http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt >=20 > Please respond by Oct 15th, 09. >=20 > -Chairs >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@nw.neclab.eu Thu Oct 15 09:27:58 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02AC3A68F5 for ; Thu, 15 Oct 2009 09:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 4mQlcGgr3srC for ; Thu, 15 Oct 2009 09:27:58 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C91B63A68A6 for ; Thu, 15 Oct 2009 09:27:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id E97832C0004D6; Thu, 15 Oct 2009 18:28:00 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22wuj8A7RUH5; Thu, 15 Oct 2009 18:28:00 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id C98DF2C0002FE; Thu, 15 Oct 2009 18:27:50 +0200 (CEST) Received: from [10.1.2.187] ([10.1.2.187]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 18:27:50 +0200 Message-ID: <4AD74D86.8050407@nw.neclab.eu> Date: Thu, 15 Oct 2009 18:27:50 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Oct 2009 16:27:50.0873 (UTC) FILETIME=[7066FC90:01CA4DB4] Cc: netext@ietf.org Subject: Re: [netext] Issue with I-D: draft-ietf-netext-pmip6-lr-ps-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 16:27:59 -0000 Hi Raj, looks like you propose to remove the complete IPv4 section. The comment to address IPv4 in the PS has been brought up during SF meeting and there was support for that comment as far as we understood. That was the reason to include such section in the individual draft. For the WG draft, we shortened this section according to the feedback we received in Stockholm and our understanding how this fits into the revised PS structure. Now you propose to remove IPv4 entirely. I (personally) still think that the PS can refer to a potential problem if it's valid and I see this independent of whether or not the solution will address all these problems. If the concern is that a particular issue described in the PS needs more time for discussion and that this may delay starting with the solution work, well, I don't see this problem as work on solution can start in parallel. I really don't persist in keeping the related text and if there is a good reason to remove some text or the complete IPv4 section, I am ok. But I think there are more opinions needed. marco Basavaraj.Patil@nokia.com schrieb: > Hello, > > Regarding the scope of localized routing for PMIP6, I believe the > current PS I-D has some issues w.r.t the following: > > 1. Localized routing for IPv4 HoA (Sec 3.3.1) > I do not believe we should work on supporting LR for IPv4 HoA at this > time. Given the possibility of multiple MNs with the same IPv4 HoA > (RFC1918 addresses) in a PMIP6 domain, we will be bogged down on this > capability. Lets just worry about LR for only the IPv6 > prefix/address. > > 2. Transport network between the MAGs (Sec 3.3.2) > Rather than making assumptions about the capability of MAGs in a PMIP6 > domain, and defining negotiation mechanisms, we can make an assumption > that MAGs support IPv6 transport. Keeping the scope constrained will > ensure we get something done here. > > So I would recommend (with chair hat on) that we delete secs 3.3, > 3.3.1 and 3.3.2. > > -Chairs > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Mohana.Jeyatharan@sg.panasonic.com Thu Oct 15 18:13:53 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7343A6810 for ; Thu, 15 Oct 2009 18:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.115 X-Spam-Level: * X-Spam-Status: No, score=1.115 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 TZ1MYWTiiung for ; Thu, 15 Oct 2009 18:13:53 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id BD4C63A6842 for ; Thu, 15 Oct 2009 18:13:52 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id n9G1DqcY023448 for ; Fri, 16 Oct 2009 10:13:52 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id n9G1DpF10267 for ; Fri, 16 Oct 2009 10:13:51 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA4DFD.56483C41" Date: Fri, 16 Oct 2009 09:09:40 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD039D8B2F@pslexc01.psl.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-jeyatharan-netext-pmip-dormant-binding-00.txt Thread-Index: AcpN903oNoBHdhSmTYunVdqX0Ov2mgABkQBA From: "Mohana Jeyatharan" To: Subject: [netext] FW: I-D Action:draft-jeyatharan-netext-pmip-dormant-binding-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:13:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4DFD.56483C41 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We have submitted this ID on fast handoff using dormant binding. Dormant binding described in draft is a binding which enables packets of one interface to be sent via another connected interface when disconnection happens and binding is kept dormant mode until the triggering event (disconnection) occurs. =20 This ID is focusing on sudden disconnection scenarios via unstable access, where such usage of dormant binding is useful to implement fast handoff. Any comments are appreciated. Thanks. BR, Mohana -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, October 16, 2009 8:30 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-jeyatharan-netext-pmip-dormant-binding-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Fast Handoff using Dormant Bindings in PMIPv6 Author(s) : M. Jeyatharan, C. Ng Filename : draft-jeyatharan-netext-pmip-dormant-binding-00.txt Pages : 14 Date : 2009-10-15 A multiple interfaced mobile node (MN) may be connected to Proxy Mobile Internet Protocol version 6 (PMIPv6) domain via a stable access connection (e.g. cellular) and an unstable access connection (e.g. IEEE 802.11). To eliminate packet loss and handoff delay due to disconnection of the unstable access, a dormant binding method is proposed access such that a binding is maintained in dormant mode in the network until the mobile node is disconnected from the unstable access. Once activated, the binding allows the network to route data packets intended for the unstable access via the stable access connection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-pmip-dormant -binding-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01CA4DFD.56483C41 Content-Type: application/octet-stream; name="draft-jeyatharan-netext-pmip-dormant-binding-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-jeyatharan-netext-pmip-dormant-binding-00.URL Content-Disposition: attachment; filename="draft-jeyatharan-netext-pmip-dormant-binding-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1qZXlhdGhhcmFuLW5ldGV4dC1wbWlwLWRvcm1hbnQtYmluZGluZy0wMC50eHQNCg== ------_=_NextPart_001_01CA4DFD.56483C41 Content-Type: text/plain; name="ATT11649902.txt" Content-Transfer-Encoding: base64 Content-Description: ATT11649902.txt Content-Disposition: attachment; filename="ATT11649902.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01CA4DFD.56483C41-- From Mohana.Jeyatharan@sg.panasonic.com Thu Oct 15 18:17:34 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437E53A6964 for ; Thu, 15 Oct 2009 18:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.713 X-Spam-Level: X-Spam-Status: No, score=0.713 tagged_above=-999 required=5 tests=[AWL=0.804, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 NJyj-Ps+ok5j for ; Thu, 15 Oct 2009 18:17:33 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 3FAE33A6977 for ; Thu, 15 Oct 2009 18:17:33 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id n9G1HakK027769 for ; Fri, 16 Oct 2009 10:17:36 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili02) with ESMTP id n9G1HX613042 for ; Fri, 16 Oct 2009 10:17:34 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA4DFD.D8F45169" Date: Fri, 16 Oct 2009 09:13:19 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD039D8B31@pslexc01.psl.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt Thread-Index: AcpN+3p+oEgli+0EStmXuvyI6Y/IYwAAyeqg From: "Mohana Jeyatharan" To: Subject: [netext] FW: I-D Action:draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 01:17:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4DFD.D8F45169 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This ID is highlighting a bulk PBU optimization approach using bit maps. This approach can be used to send multiple PBU signals of any type in a combined manner using bitmaps. This approach can work along with the MN group ID approach as well as highlighted in this draft. Please see. Comments are appreciated. Thanks. BR, Mohana -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, October 16, 2009 9:00 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Bulk PBU using Bitmaps Author(s) : M. Jeyatharan, C. Ng Filename : draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt Pages : 8 Date : 2009-10-15 In Proxy Mobile Internet Protocol version 6 (PMIPv6), each mobile node attached to a mobile access gateway (MAG) requires separate signaling. This might result in excessive network signaling if there a large number of mobile nodes attached to a MAG. In this draft we outline a bulk PBU optimization approach based on bitmap, in order to reduce the signaling load tied to numerous PBUs originating at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-pmip-bulkpbu -bitmap-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01CA4DFD.D8F45169 Content-Type: application/octet-stream; name="draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.URL Content-Disposition: attachment; filename="draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1qZXlhdGhhcmFuLW5ldGV4dC1wbWlwLWJ1bGtwYnUtYml0bWFwLTAwLnR4dA0K ------_=_NextPart_001_01CA4DFD.D8F45169 Content-Type: text/plain; name="ATT11657172.txt" Content-Transfer-Encoding: base64 Content-Description: ATT11657172.txt Content-Disposition: attachment; filename="ATT11657172.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01CA4DFD.D8F45169-- From xiajinwei@huawei.com Fri Oct 16 01:36:11 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95DE63A67AC for ; Fri, 16 Oct 2009 01:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.575 X-Spam-Level: X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=-0.965, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 XxFQskEvu2-n for ; Fri, 16 Oct 2009 01:36:10 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 45C633A659C for ; Fri, 16 Oct 2009 01:36:10 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRL00E8YMK2ZP@szxga03-in.huawei.com> for netext@ietf.org; Fri, 16 Oct 2009 16:36:02 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRL008N5MK27Z@szxga03-in.huawei.com> for netext@ietf.org; Fri, 16 Oct 2009 16:36:02 +0800 (CST) Received: from x65217 ([10.164.12.67]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRL00IU1MK1RH@szxml04-in.huawei.com> for netext@ietf.org; Fri, 16 Oct 2009 16:36:02 +0800 (CST) Date: Fri, 16 Oct 2009 16:36:01 +0800 From: Jinwei Xia In-reply-to: <853DD750D9C3724FBF2DF7164FCF641C03934F61@FRVELSMBS14.ad2.ad.alcatel.com> To: 'MELIA TELEMACO' , Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <008d01ca4e3b$b1b92ba0$430ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_bhU2kePTpBlRuTq1b2EF7g)" Thread-index: AcpH27bd1/l4UbOZQmy4iz5/IQXOTADoegSQAK4uwWA= Subject: Re: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 08:36:11 -0000 This is a multi-part message in MIME format. --Boundary_(ID_bhU2kePTpBlRuTq1b2EF7g) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Hi Telemaco, =20 I think mid-session redirection scenario makes some sense and should be taken into account. Some reasons have been given in section 4.2 of "draft-korhonen-netext-redirect-ps-00" (e.g. maintenance operation, = abrupt change of load condition etc). There is some other mid-redirection = scenario, for example, the failure of path between MAG and rfLMA can result in all mobility sessions of the MNs attached on the MAG corrupt. These sessions should be correctly redirected to r2LMA to mitigate avalanche. =20 =20 BR Jinwei _____ =20 From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of MELIA TELEMACO Sent: Tuesday, October 13, 2009 4:56 AM To: Basavaraj.Patil@nokia.com; netext@ietf.org Subject: Re: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc Hi, =20 I support the adoption of this ID. I wonder however if the mid-session redirection described in section 5.5.2 brings more advantages than complexity. The authors may want to comment on this. =20 Thanks, Telemaco=20 =20 _____ =20 De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part = de Basavaraj.Patil@nokia.com Envoy=E9 : jeudi 8 octobre 2009 14:36 =C0 : netext@ietf.org Objet : [netext] Consensus call to adopt I-D: = draft-korhonen-netext-redirect as WG doc =20 =20 Hello, =20 One of the Netext WG milestones is: Sep 2009 Initial WG draft on LMA Redirection =20 At IETF75, I-D draft-korhonen-netext-redirect was accepted as the baseline to be adopted as the doc. Process requires that we also run the consensus call on the WG ML. =20 The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, draft-korhonen-netext-redirect-04.txt has now been posted and this is a consensus call for its adoption as WG doc. http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt =20 Please respond by Oct 15th, 09.=20 =20 -Chairs =20 --Boundary_(ID_bhU2kePTpBlRuTq1b2EF7g) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable
Hi Telemaco,
 
I think=20 mid-session redirection scenario makes some sense and should be taken = into=20 account. Some reasons have been given in section 4.2 of=20 "draft-korhonen-netext-redirect-ps-00" (e.g. maintenance operation, = abrupt=20 change of load condition etc). There is some other mid-redirection = scenario, for=20 example, the failure of path between MAG and rfLMA can result=20 in all mobility sessions of the MNs attached on the MAG corrupt. = These=20 sessions should be correctly redirected to r2LMA to mitigate=20 avalanche.
 
 
BR
Jinwei


From: netext-bounces@ietf.org=20 [mailto:netext-bounces@ietf.org] On Behalf Of MELIA=20 TELEMACO
Sent: Tuesday, October 13, 2009 4:56 = AM
To:=20 Basavaraj.Patil@nokia.com; netext@ietf.org
Subject: Re: = [netext]=20 Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG=20 doc

Hi,

 

I=20 support the adoption of this ID. I wonder however if the mid-session=20 redirection described in section 5.5.2 brings more advantages than = complexity.=20 The authors may want to comment on this.

 

Thanks,

Telemaco

 


De :=20 netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de=20 Basavaraj.Patil@nokia.com
Envoy=E9 : jeudi 8 octobre = 2009=20 14:36
=C0 :=20 netext@ietf.org
Objet :=20 [netext] Consensus call to adopt I-D: draft-korhonen-netext-redirect = as WG=20 doc

 

 

Hello,

 

One of the Netext WG = milestones=20 is:

Sep=20 = 2009           &nb= sp;     =20 Initial WG draft on LMA Redirection

 

At IETF75, I-D=20 draft-korhonen-netext-redirect was accepted as the

baseline to be adopted = as the doc.=20 Process requires that we also run

the consensus call on = the WG=20 ML.

 

The I-D: Runtime LMA = Assignment=20 Support for Proxy Mobile IPv6,

draft-korhonen-netext-redirect-04.txt=20 has now been posted and this is

a consensus call for its = adoption=20 as WG doc.

htt= p://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt

 

Please respond by Oct = 15th, 09.=20

 

-Chairs

 

--Boundary_(ID_bhU2kePTpBlRuTq1b2EF7g)-- From AMUHANNA@nortel.com Fri Oct 16 06:41:49 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923F53A6A1D for ; Fri, 16 Oct 2009 06:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 nEwPMU4onVwu for ; Fri, 16 Oct 2009 06:41:45 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id F321C3A6873 for ; Fri, 16 Oct 2009 06:41:44 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n9GDfiX24804; Fri, 16 Oct 2009 13:41:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4E66.628F3147" Date: Fri, 16 Oct 2009 08:41:36 -0500 Message-ID: In-Reply-To: <008d01ca4e3b$b1b92ba0$430ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc Thread-Index: AcpH27bd1/l4UbOZQmy4iz5/IQXOTADoegSQAK4uwWAAC+VQcA== References: <853DD750D9C3724FBF2DF7164FCF641C03934F61@FRVELSMBS14.ad2.ad.alcatel.com> <008d01ca4e3b$b1b92ba0$430ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "Jinwei Xia" , "MELIA TELEMACO" , , Subject: Re: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 13:41:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4E66.628F3147 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Well, which operational maintenance you have in mind which wait for the = per-mobility session re-registration to come by to announce that hey.. = we are having maintenance here, please go somewhere else? Also, how long = that maintenance operation will last? =20 May be you can clarify that one, first. =20 Thanks. Regards,=20 Ahmad=20 =20 ________________________________ From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On = Behalf Of Jinwei Xia Sent: Friday, October 16, 2009 3:36 AM To: 'MELIA TELEMACO'; Basavaraj.Patil@nokia.com; netext@ietf.org Subject: Re: [netext] Consensus call to adopt = I-D:draft-korhonen-netext-redirect as WG doc =09 =09 Hi Telemaco, =20 I think mid-session redirection scenario makes some sense and should be = taken into account. Some reasons have been given in section 4.2 of = "draft-korhonen-netext-redirect-ps-00" (e.g. maintenance operation, = abrupt change of load condition etc). There is some other = mid-redirection scenario, for example, the failure of path between MAG = and rfLMA can result in all mobility sessions of the MNs attached on the = MAG corrupt. These sessions should be correctly redirected to r2LMA to = mitigate avalanche. =20 =20 BR Jinwei =09 =09 ________________________________ From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On = Behalf Of MELIA TELEMACO Sent: Tuesday, October 13, 2009 4:56 AM To: Basavaraj.Patil@nokia.com; netext@ietf.org Subject: Re: [netext] Consensus call to adopt = I-D:draft-korhonen-netext-redirect as WG doc =09 =09 Hi, =20 I support the adoption of this ID. I wonder however if the mid-session = redirection described in section 5.5.2 brings more advantages than = complexity. The authors may want to comment on this. =20 Thanks, Telemaco=20 =20 =09 ________________________________ De : netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la = part de Basavaraj.Patil@nokia.com Envoy=E9 : jeudi 8 octobre 2009 14:36 =C0 : netext@ietf.org Objet : [netext] Consensus call to adopt I-D: = draft-korhonen-netext-redirect as WG doc =20 =20 Hello, =20 One of the Netext WG milestones is: Sep 2009 Initial WG draft on LMA Redirection =20 At IETF75, I-D draft-korhonen-netext-redirect was accepted as the baseline to be adopted as the doc. Process requires that we also run the consensus call on the WG ML. =20 The I-D: Runtime LMA Assignment Support for Proxy Mobile IPv6, draft-korhonen-netext-redirect-04.txt has now been posted and this is a consensus call for its adoption as WG doc. http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt =20 Please respond by Oct 15th, 09.=20 =20 -Chairs =20 ------_=_NextPart_001_01CA4E66.628F3147 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Well, which operational maintenance you have in = mind which=20 wait for the per-mobility session re-registration to come by to announce = that=20 hey.. we are having maintenance here, please go somewhere else? Also, = how long=20 that maintenance operation will last?
 
May be you can clarify that one, = first.
 
Thanks.

Regards, =
Ahmad

 


From: netext-bounces@ietf.org=20 [mailto:netext-bounces@ietf.org] On Behalf Of Jinwei=20 Xia
Sent: Friday, October 16, 2009 3:36 AM
To: = 'MELIA=20 TELEMACO'; Basavaraj.Patil@nokia.com; = netext@ietf.org
Subject: Re:=20 [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as = WG=20 doc

Hi Telemaco,
 
I think=20 mid-session redirection scenario makes some sense and should be taken = into=20 account. Some reasons have been given in section 4.2 of=20 "draft-korhonen-netext-redirect-ps-00" (e.g. maintenance operation, = abrupt=20 change of load condition etc). There is some other mid-redirection = scenario,=20 for example, the failure of path between MAG and rfLMA can = result=20 in all mobility sessions of the MNs attached on the MAG corrupt. = These=20 sessions should be correctly redirected to r2LMA to mitigate=20 avalanche.
 
 
BR
Jinwei


From: netext-bounces@ietf.org=20 [mailto:netext-bounces@ietf.org] On Behalf Of MELIA=20 TELEMACO
Sent: Tuesday, October 13, 2009 4:56 = AM
To:=20 Basavaraj.Patil@nokia.com; netext@ietf.org
Subject: Re: = [netext]=20 Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG=20 doc

Hi,

 

I = support=20 the adoption of this ID. I wonder however if the mid-session = redirection=20 described in section 5.5.2 brings more advantages than complexity. = The=20 authors may want to comment on this.

 

Thanks,

Telemaco=20

 


De :=20 netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] De la part de=20 Basavaraj.Patil@nokia.com
Envoy=E9 : jeudi 8 = octobre 2009=20 14:36
=C0 :=20 netext@ietf.org
Objet : [netext] = Consensus call to=20 adopt I-D: draft-korhonen-netext-redirect as WG=20 doc

 

 

Hello,

 

One of the Netext WG = milestones=20 is:

Sep=20 = 2009           &nb= sp;     =20 Initial WG draft on LMA Redirection

 

At IETF75, I-D=20 draft-korhonen-netext-redirect was accepted as = the

baseline to be adopted = as the=20 doc. Process requires that we also run

the consensus call on = the WG=20 ML.

 

The I-D: Runtime LMA = Assignment=20 Support for Proxy Mobile IPv6,

draft-korhonen-netext-redirect-04.txt=20 has now been posted and this is

a consensus call for = its=20 adoption as WG doc.

htt= p://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt

 

Please respond by Oct = 15th, 09.=20

 

-Chairs

 

------_=_NextPart_001_01CA4E66.628F3147-- From xiayangsong@huawei.com Fri Oct 16 08:41:36 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F4928C22B for ; Fri, 16 Oct 2009 08:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 4wdM-Uq3wdlu for ; Fri, 16 Oct 2009 08:41:35 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 1F23228C0F9 for ; Fri, 16 Oct 2009 08:41:35 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRM00F7769DA6@usaga02-in.huawei.com> for netext@ietf.org; Fri, 16 Oct 2009 08:41:38 -0700 (PDT) Received: from X24512z ([10.124.12.62]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRM00H2569CYS@usaga02-in.huawei.com> for netext@ietf.org; Fri, 16 Oct 2009 08:41:37 -0700 (PDT) Date: Fri, 16 Oct 2009 10:41:34 -0500 From: Frank Xia To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <004201ca4e77$247fa3e0$3e0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_bkxuQIxEIS8HSzfuJgF9WA)" X-Priority: 3 X-MSMail-priority: Normal References: Cc: Behcet Sarikaya Subject: Re: [netext] Request for agenda slots at IETF76 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 15:41:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_bkxuQIxEIS8HSzfuJgF9WA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Raj Behcet and I would like to have a time slot. 1, I-D name: Differentiated Services Support for Proxy Mobile IPv6 2 time needed 5 minutes 3 Relevance to the Netext charter Not within current charter, hopefully can be included in the recartering. BR Frank ----- Original Message ----- From: Basavaraj.Patil@nokia.com To: netext@ietf.org Sent: Monday, October 12, 2009 7:50 AM Subject: [netext] Request for agenda slots at IETF76 Hello, The Netext WG has been scheduled to meet on Wednesday, Nov 11th from 1300-1500 Afternoon Session I. If you need a time slot on the agenda, please send a request including: 1. I-D name 2. Time needed 3. Relevance to the Netext charter -Raj ------------------------------------------------------------------------------ _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --Boundary_(ID_bkxuQIxEIS8HSzfuJgF9WA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Raj
 
Behcet and I would like to have a time slot.
 
1, I-D name:
   Differentiated Services Support for Proxy Mobile IPv6
2 time needed
   5 minutes
3 Relevance to the Netext charter
  Not within current charter, hopefully can be included in
  the recartering.
 
BR
Frank
 
----- Original Message -----
Sent: Monday, October 12, 2009 7:50 AM
Subject: [netext] Request for agenda slots at IETF76

 
Hello,
 
The Netext WG has been scheduled to meet on Wednesday, Nov 11th from 1300-1500 Afternoon Session I.
If you need a time slot on the agenda, please send a request including:
1. I-D name
2. Time needed
3. Relevance to the Netext charter
 
-Raj
 


_______________________________________________
netext mailing list
netext@ietf.org
https://www.ietf.org/mailman/listinfo/netext
--Boundary_(ID_bkxuQIxEIS8HSzfuJgF9WA)-- From sgundave@cisco.com Fri Oct 16 09:03:26 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFAD828C106 for ; Fri, 16 Oct 2009 09:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 7yWcyvuRLq0j for ; Fri, 16 Oct 2009 09:03:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E858328C0F1 for ; Fri, 16 Oct 2009 09:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1816; q=dns/txt; s=sjiport06001; t=1255709009; x=1256918609; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Sri=20Gundavelli=20|Subject: =20Re:=20[netext]=20Request=20for=20agenda=20slots=20at =20IETF76|Date:=20Fri,=2016=20Oct=202009=2009:03:30=20-07 00=20(PDT)|Message-ID:=20|To:=20netext@ietf.org|cc:=20Frank =20Brockners=20|MIME-Version:=201.0 |In-Reply-To:=20<004201ca4e77$247fa3e0$3e0c7c0a@china.hua wei.com>|References:=20=0D=0A=20<004201c a4e77$247fa3e0$3e0c7c0a@china.huawei.com>; bh=IFSymnLVRkO3vfYF/9vtzg20ULT6dHxFG8IpiRqhc54=; b=ORzTfwPsXbCibY/MIodG6q7/6caDEoYiRAd6L2E3csv1CcaYQJh46eC0 vtM9mZ2YLdCEwN3yWbjGUQf2kBe/4O8JMjh8Aqb9U73Og1KyjaqsvTui3 MIbXhZBcvRo/pwQpmXo9OAbTjenHXTO9YfWYmx4YqSHXgZOnHp6Kj511N Q=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,574,1249257600"; d="scan'208";a="410949499" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2009 16:03:29 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9GG3Uj5024382; Fri, 16 Oct 2009 16:03:30 GMT Date: Fri, 16 Oct 2009 09:03:30 -0700 (PDT) From: Sri Gundavelli To: netext@ietf.org In-Reply-To: <004201ca4e77$247fa3e0$3e0c7c0a@china.huawei.com> Message-ID: References: <004201ca4e77$247fa3e0$3e0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Frank Brockners Subject: Re: [netext] Request for agenda slots at IETF76 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 16:03:26 -0000 Chairs: Request for a presentation slot. Topic: IPv6 Migration support in Mobility Architectures Draft: http://www.ietf.org/id/draft-gundavelli-softwire-gateway-init-ds-lite-00.txt IPv6 migration is now a critical requirement for all mobile operators. There are several proposals and active work items in 3GPP and in WiMAX bodies. The requirement is common to all mobility architectures and to all interfaces, based on GTP, MIPv6 or PMIPv6. We have a proposal for IPv6 migration support, based on Dual-stack lite support, in the PDN/HA initiated mode. We believe, this is a very simple migration approach, requiring *zero host stack changes*, leveraging the mobility tunnels in a very affective way and allowing IPv4 or IPv6 core networks. This approach builds a UE specific softwire for chaining the mobility and CGN tunnels, requiring trivial changes on the PDNGW/HA and on the CGN. This topic is highly relevant to netext at this point of time. We are publishing the related CR's to 3GPP and WiMAX. Please give us a slot to present. Regards Sri > ----- Original Message ----- > From: Basavaraj.Patil@nokia.com > To: netext@ietf.org > Sent: Monday, October 12, 2009 7:50 AM > Subject: [netext] Request for agenda slots at IETF76 > > > > Hello, > > The Netext WG has been scheduled to meet on Wednesday, Nov 11th from 1300-1500 Afternoon Session I. > If you need a time slot on the agenda, please send a request including: > 1. I-D name > 2. Time needed > 3. Relevance to the Netext charter > > -Raj > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Basavaraj.Patil@nokia.com Fri Oct 16 13:19:41 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F26E3A681A for ; Fri, 16 Oct 2009 13:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 8QzY6vl195CI for ; Fri, 16 Oct 2009 13:19:40 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B7EF93A67EF for ; Fri, 16 Oct 2009 13:19:39 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9GKJdoo018032; Fri, 16 Oct 2009 23:19:40 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 23:19:40 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 23:19:39 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 16 Oct 2009 22:19:39 +0200 From: To: Date: Fri, 16 Oct 2009 22:19:49 +0200 Thread-Topic: [netext] Issue with I-D: draft-ietf-netext-pmip6-lr-ps-00 Thread-Index: AcpNtH1TKDfe2bjtTqKRL9i5Sj8G3gA6YVX4 Message-ID: In-Reply-To: <4AD74D86.8050407@nw.neclab.eu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Oct 2009 20:19:39.0582 (UTC) FILETIME=[FD0D4DE0:01CA4E9D] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Issue with I-D: draft-ietf-netext-pmip6-lr-ps-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 20:19:41 -0000 Hi Marco, On 10/15/09 11:27 AM, "ext Marco Liebsch" wrote: > Hi Raj, >=20 > looks like you propose to remove the complete IPv4 section. The comment > to address IPv4 in the PS has been brought up during SF meeting and > there was support for that comment as far as we understood. That was the > reason to include such section in the individual draft. For the WG draft,= we > shortened this section according to the feedback we received in Stockholm > and our understanding how this fits into the revised PS structure. Now yo= u > propose to remove IPv4 entirely. That was my originla suggestion in order to keep it simple. However Rajeev said that maybe it is okay to still allow localized routing for the assigne= d IPv4 HoA for the MN. But I think we should definitely not include the part about MAGs being assigned private IPv4 addresses and the mechanisms to deal with NATs etc. >=20 > I (personally) still think that the PS can refer to a potential problem > if it's > valid and I see this independent of whether or not the solution will addr= ess > all these problems. Well, the PS is going to act as the reference for the solution I-D and henc= e it is better to keep the PS scope limited to what we think is reasonable. > If the concern is that a particular issue described > in the > PS needs more time for discussion and that this may delay starting with t= he > solution work, well, I don't see this problem as work on solution can sta= rt > in parallel. We could always have a separate I-D to discuss the aspects which do not hav= e consensus at the moment as well, right? >=20 > I really don't persist in keeping the related text and if there is a > good reason to > remove some text or the complete IPv4 section, I am ok. But I think there > are more opinions needed. Sure. WG members should express opinion and feeback. We will go with whatever the WG believes is in the best interest. >From a chair perspective, I believe we should not chew off more than necessary; Rather focus on getting something done quickly that can be implemented and used. -Raj >=20 > marco >=20 >=20 > Basavaraj.Patil@nokia.com schrieb: >> Hello, >>=20 >> Regarding the scope of localized routing for PMIP6, I believe the >> current PS I-D has some issues w.r.t the following: >>=20 >> 1. Localized routing for IPv4 HoA (Sec 3.3.1) >> I do not believe we should work on supporting LR for IPv4 HoA at this >> time. Given the possibility of multiple MNs with the same IPv4 HoA >> (RFC1918 addresses) in a PMIP6 domain, we will be bogged down on this >> capability. Lets just worry about LR for only the IPv6 >> prefix/address. >>=20 >> 2. Transport network between the MAGs (Sec 3.3.2) >> Rather than making assumptions about the capability of MAGs in a PMIP6 >> domain, and defining negotiation mechanisms, we can make an assumption >> that MAGs support IPv6 transport. Keeping the scope constrained will >> ensure we get something done here. >>=20 >> So I would recommend (with chair hat on) that we delete secs 3.3, >> 3.3.1 and 3.3.2. >>=20 >> -Chairs >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> =20 >=20 From xiajinwei@huawei.com Fri Oct 16 19:36:05 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8881D3A6869 for ; Fri, 16 Oct 2009 19:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.696 X-Spam-Level: **** X-Spam-Status: No, score=4.696 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 6XnZcTOkVsNC for ; Fri, 16 Oct 2009 19:36:04 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 594313A67F7 for ; Fri, 16 Oct 2009 19:36:04 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRN00CPC0K46F@szxga04-in.huawei.com> for netext@ietf.org; Sat, 17 Oct 2009 10:36:04 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRN0022W0K4C2@szxga04-in.huawei.com> for netext@ietf.org; Sat, 17 Oct 2009 10:36:04 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [221.181.208.64]) by szxmc04-in.huawei.com (mshttpd); Sat, 17 Oct 2009 10:36:04 +0800 Date: Sat, 17 Oct 2009 10:36:04 +0800 From: xiajinwei 65217 In-reply-to: To: Ahmad Muhanna Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <853DD750D9C3724FBF2DF7164FCF641C03934F61@FRVELSMBS14.ad2.ad.alcatel.com> <008d01ca4e3b$b1b92ba0$430ca40a@china.huawei.com> Cc: netext@ietf.org, MELIA TELEMACO , Basavaraj.Patil@nokia.com Subject: [netext] =?gb2312?b?u9i4tCA6UkU6ICBDb25zZW5zdXMgY2FsbCB0byBhZG9w?= =?gb2312?b?dCBJLUQ6ZHJhZnQta29yaG9uZW4tbmV0ZXh0LXJlZGlyZWN0IGFzIFdHIGRv?= =?gb2312?b?Yw==?= X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 02:36:05 -0000 Hi Sure=2C I know your question=2E In my mind=2C we can use this mid-session= redirection associated with bulk-re-registration=2E = Therefore=2C the LMA can perform redirection per MAG=2E In such case=2C t= he operation time will be short=2E = In addtion=2C LMA can notify MAG the maintenance operation by out-of-band= means=2E = The path failure is another scenario describe how to redirect mobility se= ssions=2E Maybe somebody has different thought on mid-session redireciton scenario=2E= = BR Jinwei =3E Hi=2C =3E = =3E Well=2C which operational maintenance you have in mind which wait = =3E for the per-mobility session re-registration to come by to = =3E announce that hey=2E=2E we are having maintenance here=2C please go = =3E somewhere else=3F Also=2C how long that maintenance operation will la= st=3F =3E = =3E May be you can clarify that one=2C first=2E =3E = =3E Thanks=2E =3E = =3E Regards=2C = =3E Ahmad = =3E = =3E = =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F =3E = =3E From=3A netext-bounces=40ietf=2Eorg =5Bmailto=3Anetext-bounces=40iet= f=2Eorg=5D On = =3E Behalf Of Jinwei Xia =3E Sent=3A Friday=2C October 16=2C 2009 3=3A36 AM =3E To=3A =27MELIA TELEMACO=27=3B Basavaraj=2EPatil=40nokia=2Ecom=3B net= ext=40ietf=2Eorg =3E Subject=3A Re=3A =5Bnetext=5D Consensus call to adopt I-D=3Adraft-ko= rhonen- =3E netext-redirect as WG doc =3E = =3E = =3E Hi Telemaco=2C =3E = =3E I think mid-session redirection scenario makes some sense and = =3E should be taken into account=2E Some reasons have been given in = =3E section 4=2E2 of =22draft-korhonen-netext-redirect-ps-00=22 (e=2Eg=2E= = =3E maintenance operation=2C abrupt change of load condition etc)=2E Ther= e = =3E is some other mid-redirection scenario=2C for example=2C the failure = =3E of path between MAG and rfLMA can result in all mobility sessions = =3E of the MNs attached on the MAG corrupt=2E These sessions should be = =3E correctly redirected to r2LMA to mitigate avalanche=2E =3E = =3E = =3E BR =3E Jinwei =3E = =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F =3E = =3E From=3A netext-bounces=40ietf=2Eorg =5Bmailto=3Anetext- =3E bounces=40ietf=2Eorg=5D On Behalf Of MELIA TELEMACO =3E Sent=3A Tuesday=2C October 13=2C 2009 4=3A56 AM =3E To=3A Basavaraj=2EPatil=40nokia=2Ecom=3B netext=40ietf=2Eorg =3E Subject=3A Re=3A =5Bnetext=5D Consensus call to adopt I-D=3Ad= raft- =3E korhonen-netext-redirect as WG doc =3E = =3E = =3E = =3E Hi=2C =3E = =3E = =3E = =3E I support the adoption of this ID=2E I wonder however if = =3E the mid-session redirection described in section 5=2E5=2E2 brings mor= e = =3E advantages than complexity=2E The authors may want to comment on this= =2E =3E = =3E = =3E = =3E Thanks=2C =3E = =3E Telemaco = =3E = =3E = =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F =3E = =3E = =3E De =3A netext-bounces=40ietf=2Eorg =5Bmailto=3Anetext- =3E bounces=40ietf=2Eorg=5D De la part de Basavaraj=2EPatil=40nokia=2Ecom= =3E Envoy=A8=A6 =3A jeudi 8 octobre 2009 14=3A36 =3E =3F =3A netext=40ietf=2Eorg =3E Objet =3A =5Bnetext=5D Consensus call to adopt I-D=3A draft- =3E korhonen-netext-redirect as WG doc =3E = =3E = =3E = =3E = =3E = =3E Hello=2C =3E = =3E = =3E = =3E One of the Netext WG milestones is=3A =3E = =3E Sep 2009 Initial WG draft on LMA Redirection= =3E = =3E = =3E = =3E At IETF75=2C I-D draft-korhonen-netext-redirect was = =3E accepted as the =3E = =3E baseline to be adopted as the doc=2E Process requires that = =3E we also run =3E = =3E the consensus call on the WG ML=2E =3E = =3E = =3E = =3E The I-D=3A Runtime LMA Assignment Support for Proxy Mobile = =3E IPv6=2C =3E draft-korhonen-netext-redirect-04=2Etxt has now been posted = =3E and this is =3E = =3E a consensus call for its adoption as WG doc=2E =3E = =3E http=3A//www=2Eietf=2Eorg/id/draft-korhonen-netext-redirect-0= 4=2Etxt =3E = =3E = =3E = =3E Please respond by Oct 15th=2C 09=2E = =3E = =3E = =3E = =3E -Chairs =3E = =3E = =3E = =3E From AMUHANNA@nortel.com Fri Oct 16 20:52:57 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60D5B3A6945 for ; Fri, 16 Oct 2009 20:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.325 X-Spam-Level: X-Spam-Status: No, score=-5.325 tagged_above=-999 required=5 tests=[AWL=-1.176, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 rMlI5n-NWLcX for ; Fri, 16 Oct 2009 20:52:56 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 30C4C3A67E7 for ; Fri, 16 Oct 2009 20:52:56 -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 n9H3qtW27990; Sat, 17 Oct 2009 03:52:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2009 22:49:28 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc Thread-Index: AcpO0ps1G/28Jm5JQ+m3ciWBCkU+5wAAnS6Q References: <853DD750D9C3724FBF2DF7164FCF641C03934F61@FRVELSMBS14.ad2.ad.alcatel.com> <008d01ca4e3b$b1b92ba0$430ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "xiajinwei 65217" Cc: netext@ietf.org, MELIA TELEMACO , Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 03:52:57 -0000 Hi, Please see inline. Regards, Ahmad > -----Original Message----- > From: xiajinwei 65217 [mailto:xiajinwei@huawei.com]=20 > Sent: Friday, October 16, 2009 9:36 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: MELIA TELEMACO; Basavaraj.Patil@nokia.com; netext@ietf.org > Subject: =BB=D8=B8=B4:RE: [netext] Consensus call to adopt=20 > I-D:draft-korhonen-netext-redirect as WG doc >=20 > Hi >=20 > Sure, I know your question. In my mind, we can use this=20 > mid-session redirection associated with bulk-re-registration.=20 [Ahmad] Well, that still does not solve the issue of making administrative = maintenance which does not depend on this protocol to rely on sort of a = random time of when the mobility session lifetime expires. Imagine = having a 500,000 session on the LMA which spread across few MAGs, it is = a nightmare! > Therefore, the LMA can perform redirection per MAG.=20 [Ahmad] WOW! You think that the BULK registration is for re-registering all the = mobile node sessions on the MAG? I better check that draft? > In such=20 > case, the operation time will be short.=20 > In addtion, LMA can notify MAG the maintenance operation by=20 > out-of-band means.=20 [Ahmad] That is a very GOOD idea. Then this feature is NOT needed. If the LMA is GOING to provide this information out-of-band, then the = LMA can provide the MAG with the new LMA IP address? Right? Mission Accomplished. >=20 > The path failure is another scenario describe how to redirect=20 > mobility sessions. [Ahmad] Let us address one usecase at a time. >=20 > Maybe somebody has different thought on mid-session=20 > redireciton scenario.=20 >=20 >=20 > BR > Jinwei >=20 >=20 > > Hi, > >=20 > > Well, which operational maintenance you have in mind which wait for=20 > > the per-mobility session re-registration to come by to=20 > announce that=20 > > hey.. we are having maintenance here, please go somewhere=20 > else? Also,=20 > > how long that maintenance operation will last? > >=20 > > May be you can clarify that one, first. > >=20 > > Thanks. > >=20 > > Regards, > > Ahmad > >=20 > >=20 > >=20 > >=20 > > ________________________________ > >=20 > > From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On=20 > > Behalf Of Jinwei Xia > > Sent: Friday, October 16, 2009 3:36 AM > > To: 'MELIA TELEMACO'; Basavaraj.Patil@nokia.com; netext@ietf.org > > Subject: Re: [netext] Consensus call to adopt=20 > I-D:draft-korhonen-=20 > > netext-redirect as WG doc > > =09 > > =09 > > Hi Telemaco, > > =20 > > I think mid-session redirection scenario makes some=20 > sense and should=20 > > be taken into account. Some reasons have been given in=20 > section 4.2 of=20 > > "draft-korhonen-netext-redirect-ps-00" (e.g. > > maintenance operation, abrupt change of load condition=20 > etc). There is=20 > > some other mid-redirection scenario, for example, the=20 > failure of path=20 > > between MAG and rfLMA can result in all mobility sessions=20 > of the MNs=20 > > attached on the MAG corrupt. These sessions should be correctly=20 > > redirected to r2LMA to mitigate avalanche. > > =20 > > =20 > > BR > > Jinwei > > =09 > > =09 > >=20 > > ________________________________ > >=20 > > From: netext-bounces@ietf.org [mailto:netext-=20 > > bounces@ietf.org] On Behalf Of MELIA TELEMACO > > Sent: Tuesday, October 13, 2009 4:56 AM > > To: Basavaraj.Patil@nokia.com; netext@ietf.org > > Subject: Re: [netext] Consensus call to adopt=20 > I-D:draft-=20 > > korhonen-netext-redirect as WG doc > > =09 > > =09 > >=20 > > Hi, > >=20 > > =20 > >=20 > > I support the adoption of this ID. I wonder=20 > however if the=20 > > mid-session redirection described in section 5.5.2 brings more=20 > > advantages than complexity. The authors may want to comment on this. > >=20 > > =20 > >=20 > > Thanks, > >=20 > > Telemaco > >=20 > > =20 > >=20 > > =09 > > ________________________________ > >=20 > >=20 > > De : netext-bounces@ietf.org [mailto:netext-=20 > bounces@ietf.org]=20 > > De la part de Basavaraj.Patil@nokia.com > > Envoy=A8=A6 : jeudi 8 octobre 2009 14:36 > > ? : netext@ietf.org > > Objet : [netext] Consensus call to adopt I-D: draft-=20 > > korhonen-netext-redirect as WG doc > >=20 > > =20 > >=20 > > =20 > >=20 > > Hello, > >=20 > > =20 > >=20 > > One of the Netext WG milestones is: > >=20 > > Sep 2009 Initial WG draft on=20 > LMA Redirection > >=20 > > =20 > >=20 > > At IETF75, I-D draft-korhonen-netext-redirect=20 > was accepted as=20 > > the > >=20 > > baseline to be adopted as the doc. Process=20 > requires that we=20 > > also run > >=20 > > the consensus call on the WG ML. > >=20 > > =20 > >=20 > > The I-D: Runtime LMA Assignment Support for=20 > Proxy Mobile IPv6, > > draft-korhonen-netext-redirect-04.txt has now=20 > been posted and=20 > > this is > >=20 > > a consensus call for its adoption as WG doc. > >=20 > > =09 > http://www.ietf.org/id/draft-korhonen-netext-redirect-04.txt > >=20 > > =20 > >=20 > > Please respond by Oct 15th, 09.=20 > >=20 > > =20 > >=20 > > -Chairs > >=20 > > =20 > >=20 > >=20 >=20 From Xiangsong.Cui@huawei.com Sun Oct 18 17:55:32 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D528C3A68B5 for ; Sun, 18 Oct 2009 17:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] 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 ZdvuPiWyKH7b for ; Sun, 18 Oct 2009 17:55:32 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id D7C103A689F for ; Sun, 18 Oct 2009 17:55:31 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRQ00507L8OQ6@szxga01-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 08:55:36 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRQ00I1HL8N1N@szxga01-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 08:55:36 +0800 (CST) Date: Mon, 19 Oct 2009 08:55:35 +0800 From: Xiangsong Cui To: netext@ietf.org Message-id: <006701ca5056$de107330$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=utf-8; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [netext] Fw: New Version Notification for draft-cui-netext-route-optimization-agent-ext-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 00:55:32 -0000 Hi all, I have posted a new draft, and this draft may be accessed by the link: http://tools.ietf.org/id/draft-cui-netext-route-optimization-agent-ext-00.txt The goal of this draft is to extend the function of MAG to eliminate the gap between MIP and PMIP. Since the mobile node in PMIP domain, as the role of correspondent node, can't support route optimization, this draft introduces an extension solution for this shortage. If somebody is interested in this topic or has any comment on it, please let me know. All response are appreciated!! Thanks in advance. Regards Xiangsong ----- Original Message ----- From: "IETF I-D Submission Tool" To: Sent: Friday, October 16, 2009 5:37 PM Subject: New Version Notification for draft-cui-netext-route-optimization-agent-ext-00 > > A new version of I-D, draft-cui-netext-route-optimization-agent-ext-00.txt > has been successfuly submitted by Xiangsong Cui and posted to the IETF > repository. > > Filename: draft-cui-netext-route-optimization-agent-ext > Revision: 00 > Title: Reflector Extension for Route Optimization Agent > Creation_date: 2009-10-16 > WG ID: Independent Submission > Number_of_pages: 18 > > Abstract: > Route Optimization is a very useful feature in Mobile IPv6. Mobile > node can communicate with correspondent node without the involvement > of the home agent by Route Optimization. But there are some > limitations to this feature. One problem is that the mobile node and > the correspondent node must be capable for Route Optimization. This > document introduces an extension mechanism used for Route > Optimization and this extension mechanism can enable Route > Optimization be used between mobile node and simple IP node. In the > extension solution, the MAG can reflect the RO-related signal > messages and fulfill the Route Optimization procedure on behalf of > the simple IP node. > > > > > > Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > > The IETF Secretariat. > > From Xiangsong.Cui@huawei.com Sun Oct 18 18:35:11 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB923A688C for ; Sun, 18 Oct 2009 18:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 H13BeH3JZf75 for ; Sun, 18 Oct 2009 18:35:10 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 712EB3A67F4 for ; Sun, 18 Oct 2009 18:35:10 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRQ00DABN2ICJ@szxga03-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 09:35:06 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRQ00D8JN2HWQ@szxga03-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 09:35:05 +0800 (CST) Date: Mon, 19 Oct 2009 09:35:06 +0800 From: Xiangsong Cui To: "Koodli, Rajeev" , netext@ietf.org Message-id: <011501ca505c$6348d010$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4D35478224365146822AE9E3AD4A26660CAC545D@exchtewks3.starentnetworks.com> Subject: Re: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 01:35:11 -0000 Hi, I support the adoption of this draft as a WG document. Regards Xiangsong ----- Original Message ----- From: "Koodli, Rajeev" To: Sent: Thursday, October 15, 2009 2:02 PM Subject: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc Hello, One of the Netext WG items is: Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC At the last IETF meeting, there was agreement to use draft-premec-netlmm-bulk-re-registration-02.txt as the baseline document for the above item. This document has been revised to version 03 in which the Group ID proposal outlined in http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-01 has been merged based on author's agreement. This is a consensus call for adoption of http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-03 as the WG document. Please respond by October 21. Thanks, -Rajeev -------------------------------------------------------------------------------- > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From sunseawq@huawei.com Sun Oct 18 19:04:41 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DE9B3A6817 for ; Sun, 18 Oct 2009 19:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.409 X-Spam-Level: X-Spam-Status: No, score=0.409 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 xqyC042M2Vda for ; Sun, 18 Oct 2009 19:04:40 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id A0CCB3A67FA for ; Sun, 18 Oct 2009 19:04:40 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRQ001KROFKV0@szxga02-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 10:04:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRQ00GCROFK41@szxga02-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 10:04:32 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRQ0097HOFJVE@szxml04-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 10:04:32 +0800 (CST) Date: Mon, 19 Oct 2009 10:04:30 +0800 From: Qin Wu To: Glen Zorn , liebsch@nw.neclab.eu, sjjeong@etri.re.kr Message-id: <009401ca5060$7ee59ca0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <004e01ca4fda$7e2047b0$7a60d710$@net> Cc: netext@ietf.org Subject: Re: [netext] comment on draft-ietf-netext-pmip6-lr-ps-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 02:04:41 -0000 Hi, Although RFC 5213 considers local routing, however it is focusing on only one limited scenario where two communciating MNs attach to the same MAG and there is no localized routing signaling to be specified to allow two communciating MNs locally routing. Comparing with the section 6.10.3 of RFC 5213, what the abstract of I-D.ietf-netext-pmip6-lr-ps-00 is emphasizing is localized routing signaling design is not considered in the RFC5213. Therefore I think the abstract of I-D.ietf-netext-pmip6-lr-ps-00 has no conflict with what is described in the section 6.10.3 of RFC5213. As regarding the section 1, the only inconsistent text with the description of section 6.10.3 of RFC 5213 is " Even though two communicating MNs might be attached to the same MAG or to different MAGs of the same local mobility domain, packets will traverse the MNs' LMA(s). " therefore I would like suggest to remove this inconsistent text or reword this text as " Even though two communicating MNs might be attached to the same MAG or to different MAGs of the same local mobility domain, packets *USUALLY* traverse the MNs' LMA(s) as well. " Any thoughts? Regards! -Qin ----- Original Message ----- From: "Glen Zorn" To: ; "'Qin Wu'" ; Cc: Sent: Sunday, October 18, 2009 6:05 PM Subject: comment on draft-ietf-netext-pmip6-lr-ps-00.txt > The Abstract says: > In Proxy Mobile IPv6, mobile nodes are topologically > anchored at a Local Mobility Anchor, which forwards all data for > registered mobile nodes. The set up and maintenance of localized > routing, which allows forwarding of data packets between mobile nodes > and correspondent nodes directly without involvement of the Local > Mobility Anchor in forwarding, is not considered. > and section 1 says: > The IETF has specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as the > base protocol for network-based localized mobility management > (NetLMM), which takes basic operation for registration, de- > registration and handover into account. In scope of the base > protocol is the set up and maintenance of a forwarding tunnel between > an MN's Mobility Access Gateway (MAG) and its selected Local Mobility > Anchor (LMA). Data packets will always traverse the MN's MAG and its > LMA, irrespective of the location of the MN's remote communication > endpoint. Even though two communicating MNs might be attached to the > same MAG or to different MAGs of the same local mobility domain, > packets will traverse the MNs' LMA(s). > > However, it appears that both these passages are incorrect, since section > 6.10.3 of RFC 5213 both considers local routing and specifically permits it: > If there is data traffic between a visiting mobile node and a > correspondent node that is locally attached to an access link > connected to the mobile access gateway, the mobile access gateway MAY > optimize on the delivery efforts by locally routing the packets and > by not reverse tunneling them to the mobile node's local mobility > anchor. The flag EnableMAGLocalRouting MAY be used for controlling > this behavior. > From sunseawq@huawei.com Sun Oct 18 20:36:11 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3B23A6852 for ; Sun, 18 Oct 2009 20:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.548 X-Spam-Level: ** X-Spam-Status: No, score=2.548 tagged_above=-999 required=5 tests=[AWL=-2.334, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FM_RE_HELLO_SPAM=2.777, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 fOYygHOQx4sN for ; Sun, 18 Oct 2009 20:36:11 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id DDA743A6358 for ; Sun, 18 Oct 2009 20:36:10 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRQ00DIOSIPCJ@szxga03-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 11:32:49 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRQ00IRRSIPBA@szxga03-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 11:32:49 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRQ00JTISIO0H@szxml06-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 11:32:49 +0800 (CST) Date: Mon, 19 Oct 2009 11:32:49 +0800 From: Qin Wu To: Glen Zorn , liebsch@nw.neclab.eu, sjjeong@etri.re.kr Message-id: <01c701ca506c$d50fc130$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <004e01ca4fda$7e2047b0$7a60d710$@net> <009401ca5060$7ee59ca0$260ca40a@china.huawei.com> <013e01ca5067$72ed2c40$58c784c0$@net> Cc: netext@ietf.org Subject: Re: [netext] comment on draft-ietf-netext-pmip6-lr-ps-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 03:36:11 -0000 From: "Glen Zorn" To: "'Qin Wu'" ; ; Cc: Sent: Monday, October 19, 2009 10:54 AM Subject: RE: comment on draft-ietf-netext-pmip6-lr-ps-00.txt > Qin Wu [mailto:sunseawq@huawei.com] writes:> Hi, >> Although RFC 5213 considers local routing, however it is focusing on >> only one limited scenario where two communciating MNs attach to the >> same MAG and there is no localized routing signaling to be specified to >> allow two communciating MNs locally routing. >> Comparing with the section 6.10.3 of RFC 5213, what the abstract of I- >> D.ietf-netext-pmip6-lr-ps-00 is emphasizing is localized routing >> signaling design is not >> considered in the RFC5213. > > That seems like something of a straw man to me: if both MNs are attached to > the same MAG, how much signaling is required? [Qin]: Before the locally routing is allowed between the communicating attaching to the same access link connected to the mobile access gateway, the negotiation aspect between MAG and LMA is required to enforce localized routing on the given MAG. Because whether locally routing is allowed on the MAG can be controlled by the LMA.Otherwise, the manual configuration mechanism is required which is not flexible and scalable. From gwz@net-zen.net Sun Oct 18 03:05:34 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48583A6849 for ; Sun, 18 Oct 2009 03:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.704 X-Spam-Level: X-Spam-Status: No, score=0.704 tagged_above=-999 required=5 tests=[AWL=-1.690, BAYES_40=-0.185, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] 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 I65iE-S+Syoe for ; Sun, 18 Oct 2009 03:05:34 -0700 (PDT) Received: from smtpauth01.prod.mesa1.secureserver.net (smtpauth01.prod.mesa1.secureserver.net [64.202.165.181]) by core3.amsl.com (Postfix) with SMTP id EDEF73A681B for ; Sun, 18 Oct 2009 03:05:33 -0700 (PDT) Received: (qmail 28347 invoked from network); 18 Oct 2009 10:05:39 -0000 Received: from unknown (124.120.221.245) by smtpauth01.prod.mesa1.secureserver.net (64.202.165.181) with ESMTP; 18 Oct 2009 10:05:38 -0000 From: "Glen Zorn" To: , "'Qin Wu'" , Date: Sun, 18 Oct 2009 17:05:12 +0700 Organization: Network Zen Message-ID: <004e01ca4fda$7e2047b0$7a60d710$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpP2nsHevSerc+PSXiI8UjQIvCDpQ== Content-Language: en-us X-Mailman-Approved-At: Sun, 18 Oct 2009 20:38:00 -0700 Cc: netext@ietf.org Subject: [netext] comment on draft-ietf-netext-pmip6-lr-ps-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 10:05:34 -0000 The Abstract says: In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. and section 1 says: The IETF has specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as the base protocol for network-based localized mobility management (NetLMM), which takes basic operation for registration, de- registration and handover into account. In scope of the base protocol is the set up and maintenance of a forwarding tunnel between an MN's Mobility Access Gateway (MAG) and its selected Local Mobility Anchor (LMA). Data packets will always traverse the MN's MAG and its LMA, irrespective of the location of the MN's remote communication endpoint. Even though two communicating MNs might be attached to the same MAG or to different MAGs of the same local mobility domain, packets will traverse the MNs' LMA(s). However, it appears that both these passages are incorrect, since section 6.10.3 of RFC 5213 both considers local routing and specifically permits it: If there is data traffic between a visiting mobile node and a correspondent node that is locally attached to an access link connected to the mobile access gateway, the mobile access gateway MAY optimize on the delivery efforts by locally routing the packets and by not reverse tunneling them to the mobile node's local mobility anchor. The flag EnableMAGLocalRouting MAY be used for controlling this behavior. From gwz@net-zen.net Sun Oct 18 19:54:38 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA79D3A6861 for ; Sun, 18 Oct 2009 19:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.241 X-Spam-Level: X-Spam-Status: No, score=-1.241 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 3e8eTj8vSmLj for ; Sun, 18 Oct 2009 19:54:38 -0700 (PDT) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by core3.amsl.com (Postfix) with SMTP id 14E623A677C for ; Sun, 18 Oct 2009 19:54:37 -0700 (PDT) Received: (qmail 27272 invoked from network); 19 Oct 2009 02:54:43 -0000 Received: from unknown (124.120.221.245) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 19 Oct 2009 02:54:42 -0000 From: "Glen Zorn" To: "'Qin Wu'" , , References: <004e01ca4fda$7e2047b0$7a60d710$@net> <009401ca5060$7ee59ca0$260ca40a@china.huawei.com> In-Reply-To: <009401ca5060$7ee59ca0$260ca40a@china.huawei.com> Date: Mon, 19 Oct 2009 09:54:12 +0700 Organization: Network Zen Message-ID: <013e01ca5067$72ed2c40$58c784c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpQYIRJ2I3CJTNuRvOiSSUJDVnRRgABSzzA Content-Language: en-us X-Mailman-Approved-At: Sun, 18 Oct 2009 20:38:00 -0700 Cc: netext@ietf.org Subject: Re: [netext] comment on draft-ietf-netext-pmip6-lr-ps-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 02:54:38 -0000 Qin Wu [mailto:sunseawq@huawei.com] writes:> Hi, > Although RFC 5213 considers local routing, however it is focusing on > only one limited scenario where two communciating MNs attach to the > same MAG and there is no localized routing signaling to be specified to > allow two communciating MNs locally routing. > Comparing with the section 6.10.3 of RFC 5213, what the abstract of I- > D.ietf-netext-pmip6-lr-ps-00 is emphasizing is localized routing > signaling design is not > considered in the RFC5213. That seems like something of a straw man to me: if both MNs are attached to the same MAG, how much signaling is required? > Therefore I think the abstract of I-D.ietf- > netext-pmip6-lr-ps-00 has no conflict with what is described in the > section 6.10.3 of RFC5213. As regarding the section 1, the only > inconsistent text with the description of section 6.10.3 of RFC 5213 is > " > Even though two communicating MNs might be attached to the > same MAG or to different MAGs of the same local mobility domain, > packets will traverse the MNs' LMA(s). > > " > therefore I would like suggest to remove this inconsistent text or > reword this text as > " > Even though two communicating MNs might be attached to the > same MAG or to different MAGs of the same local mobility domain, > packets *USUALLY* traverse the MNs' LMA(s) as well. > " > Any thoughts? The draft as it is seems to imply that local routing in PMIPv6 is an entirely new concept, which just isn't true. I think that it would be a good thing if the draft made clear that it is just proposing that the optimization mentioned in 6.10.3 of RFC5213 be extended to include localized routing between any two mobile nodes in the same PMIPv6 Domain, not inventing localized routing. ... From sunseawq@huawei.com Sun Oct 18 20:45:18 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357C33A690C for ; Sun, 18 Oct 2009 20:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.691 X-Spam-Level: X-Spam-Status: No, score=0.691 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_50=0.001] 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 Jm-we2awB0El for ; Sun, 18 Oct 2009 20:45:17 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id BB0E23A6852 for ; Sun, 18 Oct 2009 20:45:12 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRQ00LQ0T3HNA@szxga01-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 11:45:17 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRQ00KCMT3HYG@szxga01-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 11:45:17 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRQ00JBFT3G0H@szxml06-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 11:45:17 +0800 (CST) Date: Mon, 19 Oct 2009 11:45:16 +0800 From: Qin Wu To: Glen Zorn , liebsch@nw.neclab.eu, sjjeong@etri.re.kr Message-id: <01f001ca506e$926e7ea0$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <004e01ca4fda$7e2047b0$7a60d710$@net> <009401ca5060$7ee59ca0$260ca40a@china.huawei.com> <013e01ca5067$72ed2c40$58c784c0$@net> Cc: netext@ietf.org Subject: Re: [netext] comment on draft-ietf-netext-pmip6-lr-ps-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 03:45:18 -0000 From: "Glen Zorn" To: "'Qin Wu'" ; ; Cc: Sent: Monday, October 19, 2009 10:54 AM Subject: RE: comment on draft-ietf-netext-pmip6-lr-ps-00.txt > Qin Wu [mailto:sunseawq@huawei.com] writes:> Hi, >> Although RFC 5213 considers local routing, however it is focusing on >> only one limited scenario where two communciating MNs attach to the >> same MAG and there is no localized routing signaling to be specified to >> allow two communciating MNs locally routing. >> Comparing with the section 6.10.3 of RFC 5213, what the abstract of I- >> D.ietf-netext-pmip6-lr-ps-00 is emphasizing is localized routing >> signaling design is not >> considered in the RFC5213. > > That seems like something of a straw man to me: if both MNs are attached to > the same MAG, how much signaling is required? [Qin]: Before the locally routing is allowed between two communicating MNs attaching to the same access link connected to the mobile access gateway, the negotiation aspect between MAG and LMA is required to enforce localized routing on the given MAG. Because whether locally routing is allowed on the MAG can be controlled by the LMA.Otherwise, the manual configuration mechanism is required which is not flexible and scalable. From xiajinwei@huawei.com Sun Oct 18 21:12:35 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB963A6863 for ; Sun, 18 Oct 2009 21:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.07 X-Spam-Level: X-Spam-Status: No, score=0.07 tagged_above=-999 required=5 tests=[AWL=-1.294, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 lEIK8gyqvfpL for ; Sun, 18 Oct 2009 21:12:35 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id D61EF3A6852 for ; Sun, 18 Oct 2009 21:12:34 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRQ00EY6UCUU7@szxga03-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 12:12:30 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRQ00C9CUCU5O@szxga03-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 12:12:30 +0800 (CST) Received: from x65217 ([10.164.12.67]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRQ00ER5UCTH6@szxml04-in.huawei.com> for netext@ietf.org; Mon, 19 Oct 2009 12:12:30 +0800 (CST) Date: Mon, 19 Oct 2009 12:12:29 +0800 From: Jinwei Xia In-reply-to: To: 'Ahmad Muhanna' Message-id: <00af01ca5072$5fedbc30$430ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpO0ps1G/28Jm5JQ+m3ciWBCkU+5wAAnS6QAGS/R7A= Cc: netext@ietf.org, 'MELIA TELEMACO' , Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 04:12:35 -0000 Hi, Please see inline > > > > Sure, I know your question. In my mind, we can use this mid-session > > redirection associated with bulk-re-registration. > [Ahmad] > Well, that still does not solve the issue of making > administrative maintenance which does not depend on this > protocol to rely on sort of a random time of when the > mobility session lifetime expires. Imagine having a 500,000 > session on the LMA which spread across few MAGs, it is a nightmare! Right, bulk-re-registration method is only auxiliary method to mitigate the network overhead, but which is unavoidable when a large amount of mobility sessions expire during a short period. Especially in the case that rfLMA suddenly crashes or the path between rfLMA and MAG fails, all related mobility sessions will be redirected to a new LMA even if this scenario belongs to LMA reliability other than load balance. > > > Therefore, the LMA can perform redirection per MAG. > [Ahmad] > WOW! > > You think that the BULK registration is for re-registering > all the mobile node sessions on the MAG? > I better check that draft? It is still bulk re-registration but not bulk registration, rfLMA must share all mobility sessions of the MAG with r2LMA before taking administrative maintenance. the sharing depends on possible context transfer and other coordination management between the rfLMA and the r2LMA. > > > > In such > > case, the operation time will be short. > > In addtion, LMA can notify MAG the maintenance operation by > > out-of-band means. > [Ahmad] > That is a very GOOD idea. Then this feature is NOT needed. > If the LMA is GOING to provide this information out-of-band, > then the LMA can provide the MAG with the new LMA IP address? Right? > Mission Accomplished. Sure, but out-of-band mean is another vague method and out of scope. > > > > > The path failure is another scenario describe how to > redirect mobility > > sessions. > [Ahmad] > Let us address one usecase at a time. "draft-wakikawa-netext-lma-reliability" is one case. BR Jinwei From gwz@net-zen.net Sun Oct 18 22:59:49 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBFE63A68D8 for ; Sun, 18 Oct 2009 22:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 BoeQLrkZ+8dZ for ; Sun, 18 Oct 2009 22:59:49 -0700 (PDT) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-01.prod.mesa1.secureserver.net [64.202.165.14]) by core3.amsl.com (Postfix) with SMTP id 3AC513A68C3 for ; Sun, 18 Oct 2009 22:59:49 -0700 (PDT) Received: (qmail 10200 invoked from network); 19 Oct 2009 05:59:54 -0000 Received: from unknown (124.120.221.245) by smtpout09.prod.mesa1.secureserver.net (64.202.165.14) with ESMTP; 19 Oct 2009 05:59:53 -0000 From: "Glen Zorn" To: "'Qin Wu'" References: <004e01ca4fda$7e2047b0$7a60d710$@net> <009401ca5060$7ee59ca0$260ca40a@china.huawei.com> <013e01ca5067$72ed2c40$58c784c0$@net> <01f001ca506e$926e7ea0$260ca40a@china.huawei.com> In-Reply-To: <01f001ca506e$926e7ea0$260ca40a@china.huawei.com> Date: Mon, 19 Oct 2009 12:59:23 +0700 Organization: Network Zen Message-ID: <017d01ca5081$5167f090$f437d1b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpQbqbj6dpidyXaSdWQffeYSavHJwAEa3Bw Content-Language: en-us Cc: liebsch@nw.neclab.eu, netext@ietf.org, sjjeong@etri.re.kr Subject: Re: [netext] comment on draft-ietf-netext-pmip6-lr-ps-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 05:59:50 -0000 Qin Wu [mailto:sunseawq@huawei.com] writes: ... > >> Although RFC 5213 considers local routing, however it is focusing on > >> only one limited scenario where two communciating MNs attach to the > >> same MAG and there is no localized routing signaling to be specified > to > >> allow two communciating MNs locally routing. > >> Comparing with the section 6.10.3 of RFC 5213, what the abstract of > I- > >> D.ietf-netext-pmip6-lr-ps-00 is emphasizing is localized routing > >> signaling design is not > >> considered in the RFC5213. > > > > That seems like something of a straw man to me: if both MNs are > attached to > > the same MAG, how much signaling is required? > > [Qin]: Before the locally routing is allowed between two communicating > MNs attaching to the same access link > connected to the mobile access gateway, the negotiation aspect between > MAG and LMA is required to > enforce localized routing on the given MAG. Because whether locally > routing is allowed on the MAG can > be controlled by the LMA.Otherwise, the manual configuration mechanism > is required which is not flexible > and scalable. Right, signaling isn't discussed because there is none: it's a matter of local MAG configuration (though how the LMA is supposed to "enforce" is a mystery to me -- maybe by refusing to tunnel traffic from a MAG to itself?). In any case the kinds of things that you mention above might be good to include in the problem statement draft, too. From Marco.Liebsch@nw.neclab.eu Mon Oct 19 01:31:03 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B7E28C114 for ; Mon, 19 Oct 2009 01:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FJDEkAF9E6VM for ; Mon, 19 Oct 2009 01:31:01 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 8FBC228C10C for ; Mon, 19 Oct 2009 01:31:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 138F42C019172; Mon, 19 Oct 2009 10:31:08 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbxzhE2r7Z+p; Mon, 19 Oct 2009 10:31:07 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id DCE2A2C0002FC; Mon, 19 Oct 2009 10:30:57 +0200 (CEST) Received: from [10.1.2.187] ([10.1.2.187]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 10:30:49 +0200 Message-ID: <4ADC23B9.5060207@nw.neclab.eu> Date: Mon, 19 Oct 2009 10:30:49 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2009 08:30:49.0918 (UTC) FILETIME=[76A2D5E0:01CA5096] Cc: netext@ietf.org Subject: Re: [netext] Issue with I-D: draft-ietf-netext-pmip6-lr-ps-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 08:31:03 -0000 Hi Raj, Basavaraj.Patil@nokia.com schrieb: > Hi Marco, > > > On 10/15/09 11:27 AM, "ext Marco Liebsch" > wrote: > > >> Hi Raj, >> >> looks like you propose to remove the complete IPv4 section. The comment >> to address IPv4 in the PS has been brought up during SF meeting and >> there was support for that comment as far as we understood. That was the >> reason to include such section in the individual draft. For the WG draft, we >> shortened this section according to the feedback we received in Stockholm >> and our understanding how this fits into the revised PS structure. Now you >> propose to remove IPv4 entirely. >> > > That was my originla suggestion in order to keep it simple. However Rajeev > said that maybe it is okay to still allow localized routing for the assigned > IPv4 HoA for the MN. But I think we should definitely not include the part > about MAGs being assigned private IPv4 addresses and the mechanisms to deal > with NATs etc. > Ok. > >> I (personally) still think that the PS can refer to a potential problem >> if it's >> valid and I see this independent of whether or not the solution will address >> all these problems. >> > > Well, the PS is going to act as the reference for the solution I-D and hence > it is better to keep the PS scope limited to what we think is reasonable. > > >> If the concern is that a particular issue described >> in the >> PS needs more time for discussion and that this may delay starting with the >> solution work, well, I don't see this problem as work on solution can start >> in parallel. >> > > We could always have a separate I-D to discuss the aspects which do not have > consensus at the moment as well, right? > What about having the "in scope" items in the core part of the PS, but to have a short reference to further possible issues, which we just summarize in the appendix without digging into detail. So, we don't lose time with discussing them, but future documents can take this PS as a hook to analyze associated issues in detail. Advantage would also be to show that we did not ignore such issues, but just left them aside as they are not conidered yet for the NetExt protocol solution. What do you think? > >> I really don't persist in keeping the related text and if there is a >> good reason to >> remove some text or the complete IPv4 section, I am ok. But I think there >> are more opinions needed. >> > > Sure. WG members should express opinion and feeback. We will go with > whatever the WG believes is in the best interest. > > From a chair perspective, I believe we should not chew off more than > necessary; Rather focus on getting something done quickly that can be > implemented and used. > Yes, I think my proposal above lets us proceed quickly. marco > -Raj > >> marco >> >> >> Basavaraj.Patil@nokia.com schrieb: >> >>> Hello, >>> >>> Regarding the scope of localized routing for PMIP6, I believe the >>> current PS I-D has some issues w.r.t the following: >>> >>> 1. Localized routing for IPv4 HoA (Sec 3.3.1) >>> I do not believe we should work on supporting LR for IPv4 HoA at this >>> time. Given the possibility of multiple MNs with the same IPv4 HoA >>> (RFC1918 addresses) in a PMIP6 domain, we will be bogged down on this >>> capability. Lets just worry about LR for only the IPv6 >>> prefix/address. >>> >>> 2. Transport network between the MAGs (Sec 3.3.2) >>> Rather than making assumptions about the capability of MAGs in a PMIP6 >>> domain, and defining negotiation mechanisms, we can make an assumption >>> that MAGs support IPv6 transport. Keeping the scope constrained will >>> ensure we get something done here. >>> >>> So I would recommend (with chair hat on) that we delete secs 3.3, >>> 3.3.1 and 3.3.2. >>> >>> -Chairs >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >>> > > From Marco.Liebsch@nw.neclab.eu Mon Oct 19 01:59:39 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00EE33A68F1 for ; Mon, 19 Oct 2009 01:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 qjIRQgj-kP+3 for ; Mon, 19 Oct 2009 01:59:38 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E28683A68C4 for ; Mon, 19 Oct 2009 01:59:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 6B43A2C019171; Mon, 19 Oct 2009 10:59:44 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C41l-sGcgQl3; Mon, 19 Oct 2009 10:59:44 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 46C552C01898B; Mon, 19 Oct 2009 10:59:24 +0200 (CEST) Received: from [10.1.2.187] ([10.1.2.187]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 10:59:17 +0200 Message-ID: <4ADC2A65.6050508@nw.neclab.eu> Date: Mon, 19 Oct 2009 10:59:17 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Glen Zorn References: <004e01ca4fda$7e2047b0$7a60d710$@net> <009401ca5060$7ee59ca0$260ca40a@china.huawei.com> <013e01ca5067$72ed2c40$58c784c0$@net> In-Reply-To: <013e01ca5067$72ed2c40$58c784c0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2009 08:59:17.0447 (UTC) FILETIME=[70671570:01CA509A] Cc: liebsch@nw.neclab.eu, netext@ietf.org, sjjeong@etri.re.kr Subject: Re: [netext] comment on draft-ietf-netext-pmip6-lr-ps-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 08:59:39 -0000 Hi Gle, just to complement what Qin already wrote, please see inline. Glen Zorn schrieb: > Qin Wu [mailto:sunseawq@huawei.com] writes:> Hi, > >> Although RFC 5213 considers local routing, however it is focusing on >> only one limited scenario where two communciating MNs attach to the >> same MAG and there is no localized routing signaling to be specified to >> allow two communciating MNs locally routing. >> Comparing with the section 6.10.3 of RFC 5213, what the abstract of I- >> D.ietf-netext-pmip6-lr-ps-00 is emphasizing is localized routing >> signaling design is not >> considered in the RFC5213. >> > > That seems like something of a straw man to me: if both MNs are attached to > the same MAG, how much signaling is required? > There is good reason to have signaling from the LMA. One is that RFC5213 requires the LMA to enforce localized routing for the case that both MNs share the same MAG. A further good reason to have singaling and some control from the LMA is that one or even both MNs may handover to a different MAG, hence it's good to have the LMA as common stateful entity. > >> Therefore I think the abstract of I-D.ietf- >> netext-pmip6-lr-ps-00 has no conflict with what is described in the >> section 6.10.3 of RFC5213. As regarding the section 1, the only >> inconsistent text with the description of section 6.10.3 of RFC 5213 is >> " >> Even though two communicating MNs might be attached to the >> same MAG or to different MAGs of the same local mobility domain, >> packets will traverse the MNs' LMA(s). >> >> " >> therefore I would like suggest to remove this inconsistent text or >> reword this text as >> " >> Even though two communicating MNs might be attached to the >> same MAG or to different MAGs of the same local mobility domain, >> packets *USUALLY* traverse the MNs' LMA(s) as well. >> " >> Any thoughts? >> > > The draft as it is seems to imply that local routing in PMIPv6 is an > entirely new concept, which just isn't true. I think that it would be a > good thing if the draft made clear that it is just proposing that the > optimization mentioned in 6.10.3 of RFC5213 be extended to include localized > routing between any two mobile nodes in the same PMIPv6 Domain, not > inventing localized routing. > > ... > It was not the intention to write the draft in such way. If you read it such as the PS invents localized routing, then we may need to rewrite associated sentences. Please point to them. Well, if the draft invents something then it may be problems, as it's a problem statement ;-) The draft does not ignore that RFC5213 writes about localized routing and covers some recommendations how to handle it. But it also sais that there are missing pieces. And the PS tries to analyze issues in the context of localized routing with PMIPv6 to find out which pieces the solution needs to provide. marco From root@core3.amsl.com Mon Oct 19 06:15:01 2009 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 91DC73A6961; Mon, 19 Oct 2009 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019131501.91DC73A6961@core3.amsl.com> Date: Mon, 19 Oct 2009 06:15:01 -0700 (PDT) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-redirect-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 13:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Runtime LMA Assignment Support for Proxy Mobile IPv6 Author(s) : J. Korhonen, et al. Filename : draft-ietf-netext-redirect-00.txt Pages : 24 Date : 2009-10-19 This document describes a redirect functionality and corresponding mobility options for Proxy Mobile IPv6. The redirect functionality allows a dynamic runtime assignment of a Local Mobility Anchor and redirecting the mobility session to the assigned Local Mobility Anchor. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-redirect-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-redirect-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19060132.I-D@ietf.org> --NextPart-- From Mohana.Jeyatharan@sg.panasonic.com Mon Oct 19 17:49:22 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C00B28C1BF for ; Mon, 19 Oct 2009 17:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.513 X-Spam-Level: X-Spam-Status: No, score=0.513 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 kwDICmhnxdTT for ; Mon, 19 Oct 2009 17:49:21 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 2454A28C196 for ; Mon, 19 Oct 2009 17:49:17 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id n9K0nNEr025197; Tue, 20 Oct 2009 09:49:23 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id n9K0nMG09124; Tue, 20 Oct 2009 09:49:22 +0900 (JST) 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: Tue, 20 Oct 2009 08:45:07 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD039D8EBE@pslexc01.psl.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Request for agenda slots at IETF76 Thread-Index: AcpLGlflH/rrxrvASAKC/nxiMYXDtQGBQNDQ From: "Mohana Jeyatharan" To: , Subject: Re: [netext] Request for agenda slots at IETF76 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 00:49:22 -0000 Dear Chairs, Requesting for presentation slot to present the IDs=20 [1]draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt and [10 minuites] [2]draft-jeyatharan-netext-pmip-dormant-binding-00.txt [10 minuites] The first ID is more related to charter items such as bulk registration. = The second one is more towards handoffs. Please give us a slot to present these. Thank you. BR, Mohana ________________________________________ From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Basavaraj.Patil@nokia.com Sent: Monday, October 12, 2009 8:50 PM To: netext@ietf.org Subject: [netext] Request for agenda slots at IETF76 =A0 Hello, =A0 The Netext WG has been scheduled to meet on Wednesday, Nov 11th from = 1300-1500 Afternoon Session I. If you need a time slot on the agenda, please send a request including: 1. I-D name 2. Time needed 3. Relevance to the Netext charter =A0 -Raj =A0 From huimin.cmcc@gmail.com Mon Oct 19 19:29:02 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04C63A672F for ; Mon, 19 Oct 2009 19:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 6tfxTmRd+3PP for ; Mon, 19 Oct 2009 19:29:02 -0700 (PDT) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 221C33A62C1 for ; Mon, 19 Oct 2009 19:29:02 -0700 (PDT) Received: by gxk4 with SMTP id 4so4032696gxk.8 for ; Mon, 19 Oct 2009 19:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=B2NotUuDYGV6daaNYDruML0D+3scmMD4ZieUyQegTeU=; b=jN1eiZQd3WJ5sr4d8CFhVKfY26duSSoGSWdNo+g9U1AL8C28Pafv3qNn3+nInkqg4E aEyk58PlsCAvkR1VPXwqyBveRiStUtNDmU3eWDWrqsbMt38+PY1siytVyGRbqV8ekQQc j12IiiLGhRvPNib97je4oV2Ym7eyTrmouotCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=eYYP3uqJjvmAUl56Kb/fR0tm6Yd96J2FR65p7d1H+PHwG0dtdCrUVX5Hn2M+KqyB+N 0/Y61FLrk2VRFo9bhsWq3w9pYSGuLnCDLBogeBX3XsSp7ozY6vL5cwFxQqhCaVTEnnp1 nlcyFw9vxaTuynHFti2v26bFCMPLmyvQt9qlw= MIME-Version: 1.0 Received: by 10.150.236.17 with SMTP id j17mr9463711ybh.229.1256005746727; Mon, 19 Oct 2009 19:29:06 -0700 (PDT) In-Reply-To: <5F09D220B62F79418461A978CA0921BD039D8EBE@pslexc01.psl.local> References: <5F09D220B62F79418461A978CA0921BD039D8EBE@pslexc01.psl.local> Date: Tue, 20 Oct 2009 10:29:06 +0800 Message-ID: <5dca10d30910191929n761b08d3t31323f1f0d2536e2@mail.gmail.com> From: Min Hui To: Basavaraj.Patil@nokia.com, netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] Request for agenda slots at IETF76 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 02:29:03 -0000 Dear Chairs, I would like request for the presentation slot 1. draft-hui-netext-multihoming-00.txt 10min 2. draft-hui-netext-service-flow-identifier-01.txt 10min They are related to PMIP multihoming and flow mobiltiy. Thanks a lot. - Hui Min 2009/10/20 Mohana Jeyatharan : > > Dear Chairs, > > Requesting for presentation slot to present the IDs > > [1]draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt and [10 minuites] > > [2]draft-jeyatharan-netext-pmip-dormant-binding-00.txt [10 minuites] > > > The first ID is more related to charter items such as bulk registration. = =A0The second one is more towards handoffs. > > Please give us a slot to present these. > > Thank you. > > BR, > Mohana > > > ________________________________________ > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Basavaraj.Patil@nokia.com > Sent: Monday, October 12, 2009 8:50 PM > To: netext@ietf.org > Subject: [netext] Request for agenda slots at IETF76 > > > Hello, > > The Netext WG has been scheduled to meet on Wednesday, Nov 11th from 1300= -1500 Afternoon Session I. > If you need a time slot on the agenda, please send a request including: > 1. I-D name > 2. Time needed > 3. Relevance to the Netext charter > > -Raj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Mohana.Jeyatharan@sg.panasonic.com Tue Oct 20 01:45:35 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F331428C0E3 for ; Tue, 20 Oct 2009 01:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] 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 g84Ygteh7166 for ; Tue, 20 Oct 2009 01:45:33 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id C081B28C0D7 for ; Tue, 20 Oct 2009 01:45:31 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id n9K8j9N8020963; Tue, 20 Oct 2009 17:45:09 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id n9K8j5F24111; Tue, 20 Oct 2009 17:45:05 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5160.F551BCF1" Date: Tue, 20 Oct 2009 16:40:20 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD039D908A@pslexc01.psl.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments on draft-ietf-netext-pmip6-lr-ps-00.txt Thread-Index: AcpRYj8v1g5fMF+ARiW4Mn+0dK4HJQ== From: "Mohana Jeyatharan" To: "Marco Liebsch" , "Qin Wu" Cc: netext@ietf.org Subject: [netext] Some comments on draft-ietf-netext-pmip6-lr-ps-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 08:45:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5160.F551BCF1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I went through the draft and have few comments. =20 =20 1)Introduction first para says " Even though two communicating MNs might be attached to the same MAG or to different MAGs of the same local mobility domain, packets will traverse the MNs' LMA(s)." [Mohana] Mn and CN may be better word. Bcos later in draft communication End points are defined as MN and CN. =20 2)Introduction second para says " Objectives of designing a solution for localized routing in PMIPv6 are to specify protocol messages and enable associated protocol operation between PMIPv6 components to support the set up of a direct routing path for data packets between the MNs' MAGs without forwarding these packets through the MNs' LMA(s) and to maintain localized routing in case one or both MNs handover to a different MAG." =20 [Mohana] Here again it says that direct path between MN's MAGs. I think it is between Mn's MAG and CN's MAG. =20 =20 3)In the conventions and terminology section =20 The second bullet: =20 Correspondent Node (CN): Correspondent Node with or without IP mobility support. The CN represents the communication peer of an MN, which is attached to a MAG and registered with an LMA according to the PMIPv6 specification. =20 [Mohana]The usage of "an" in front of MN and LMA should be changed to a. =20 4)In the conventions and terminology section =20 The third bullet: there is mentioning about a single PMIPv6 domain. [Mohana] Is it MN and CN placed in single operator/provider domain running PMIPv6? =20 5)In the conventions and terminology section Fourth bullet mentions about IDs =20 [Mohana] Is it only ID? What other information stored. What are these IDs? Perhaps a description will be good. =20 6)In section 3.1 general observation section 1st para =20 " Following the architecture of PMIPv6, rather entities of the network infrastructure are dedicated to perform signaling to set up a more direct route between an MN and a CN." =20 [Mohana] I am not sure the meaning of this. Does it mean that when PMIP is present, RO needs to be established by using signaling between network entities? Perhaps a rewording is useful. =20 7)In section 3.1 general observation section last paragraph [Mohana] It is mentioned two benefits of loacl MAG routing.There is mentioning about lower cost, lower delay, lower packet loss. But clear indication as to the two benefits was not present. =20 8) In section 3.2 all mentioning is about "PMIPv6 domain". =20 [Mohana] I do not want to start the discussion again. But, isn't it better to say what this PMIPv6 domain is. MN and CN in same operator domain or something like that. Bcos there is another section on roaming which is different from this. =20 9) [Mohana]Again in section 3.2, there is mentioning about some race issue in multiple LMA Case, when there is handoff. But no clear description of such issue is highlighted. A small description will be good. =20 10) In section 3.2, the local MAG issues are highlighted into cases(case A11, A..) and again some issues (multiple LMA, handoff in multiple LMA) are captured in bullet form. I am not sure whether there are any overlap in text here. =20 11)Section on IPv4 considerations. I think the current text is fine. It is not too complex and highlights how local MAG routing canbe done when there is IPv4 HoA or IPv4 transport.=20 =20 BR, Mohana =20 ------_=_NextPart_001_01CA5160.F551BCF1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I went through the draft and have few = comments.

 

 

1)Introduction first para says

" Even though two communicating MNs might be attached to = the

   same MAG or to different MAGs of the same local = mobility domain,

   packets will traverse the MNs' = LMA(s)."

[Mohana] Mn and CN may be better word. Bcos later in draft communication

End points are defined as MN and = CN.

 

2)Introduction second para says

" Objectives of designing a solution for localized routing = in PMIPv6

   are to specify protocol messages and enable = associated protocol

   operation between PMIPv6 components to support the = set up of a direct

   routing path for data packets between the MNs' MAGs without

   forwarding these packets through the MNs' LMA(s) = and to maintain

   localized routing in case one or both MNs handover = to a different

   MAG."

 

[Mohana] Here again it says that direct path between MN's MAGs. =  I think it is between Mn's MAG and CN's MAG. =  

 

3)In the conventions and terminology = section

 

The second bullet:

 

Correspondent Node (CN): Correspondent Node with or without = IP

      mobility support.  The CN represents the communication peer of an

      MN, which is attached to a MAG = and registered with an LMA

      according to the PMIPv6 = specification.

 

[Mohana]The usage of "an" in front of MN and LMA = should be changed to a.

 

4)In the conventions and terminology = section

 

The third bullet: there is mentioning about a single PMIPv6 = domain.

[Mohana] Is it MN and CN placed in single operator/provider = domain running PMIPv6?

 

5)In the conventions and terminology = section

Fourth bullet mentions about IDs

 

[Mohana] Is it only ID? What other information stored. =  What are these IDs?

Perhaps a description will be good.

 

6)In section 3.1 general observation section 1st = para

 

" Following the architecture of PMIPv6, rather entities of = the network

   infrastructure are dedicated to perform signaling = to set up a more

   direct route between an MN and a = CN."

 

[Mohana] I am not sure the meaning of this.  Does it mean = that when PMIP is present, RO needs to be established by using signaling = between network entities? Perhaps a rewording is = useful.

 

7)In section 3.1 general observation section last = paragraph

[Mohana] It is mentioned two benefits of loacl MAG routing.There = is mentioning about lower cost, lower delay, lower packet loss.  But = clear indication as to the two benefits was not = present.

 

8) In section 3.2 all mentioning is about "PMIPv6 = domain".  

[Mohana] I do not want to start the discussion again. But, isn't = it better to say what this PMIPv6 domain is. MN and CN in same operator = domain or something like that. Bcos there is another section on roaming which is different from this.

 

9) [Mohana]Again in section 3.2, there is mentioning about some = race issue in multiple LMA

Case, when there is handoff.  But no clear description of = such issue is highlighted. A small description will be = good.

 

10) In section 3.2, the local MAG issues are highlighted into = cases(case A11, A..) and again some issues (multiple LMA, handoff in multiple LMA) = are captured in bullet form.  I am not sure whether there are any = overlap in text here.

 

11)Section on IPv4 considerations. I think the current text is = fine.  It is not too complex and highlights how local MAG routing canbe done when = there is IPv4 HoA or IPv4 transport.

 

BR,

Mohana

 

------_=_NextPart_001_01CA5160.F551BCF1-- From jouni.nospam@gmail.com Tue Oct 20 06:50:52 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A7E83A69B1 for ; Tue, 20 Oct 2009 06:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 QOjOIQzS7GOO for ; Tue, 20 Oct 2009 06:50:51 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 2B8C53A6961 for ; Tue, 20 Oct 2009 06:50:51 -0700 (PDT) Received: by fxm18 with SMTP id 18so6445056fxm.37 for ; Tue, 20 Oct 2009 06:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=r3Z+t0NMAegksW4srDJiZ14a7EJQF54B0wmxMBysugA=; b=rGM4TqBpSOswrZObEZNnw6nawPI5+P+8AAGtgqje45d++dt4BXKB7rhW8kycU3j9co 6hrYrYq0MwFNhQtsf8+mDdwbYwx9EOW7Z+gzxPlmo0JUnzKMNIiDjkMKGkOBHyF7Qo5k lh+YNugGqPzxGGDaxbdK+srvX/DaG9zgjldHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=nz52Q4/47eBDxfL6K9xK1QMEbGCPtgHRzhL+7MQsmepaBU6JS5Tt6MQCmsChflD5jQ mXyrJlkpZNg5TA+l4nWDi+HLm4A6whCKVtWg0k6eBZne0rL/pBjNj6GH6SFfrfJSkZ8t 66EQNe6bqiIB2vQlKP9r4b3RhnCHOas5XYnQY= Received: by 10.204.34.203 with SMTP id m11mr6455086bkd.79.1256046654124; Tue, 20 Oct 2009 06:50:54 -0700 (PDT) Received: from a88-114-71-193.elisa-laajakaista.fi (a88-114-71-193.elisa-laajakaista.fi [88.114.71.193]) by mx.google.com with ESMTPS id 13sm260608bwz.2.2009.10.20.06.50.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Oct 2009 06:50:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jouni korhonen In-Reply-To: Date: Tue, 20 Oct 2009 16:50:51 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: To: X-Mailer: Apple Mail (2.1076) Cc: netext@ietf.org Subject: Re: [netext] Request for agenda slots at IETF76 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 13:50:52 -0000 Hi, I'd like to have a slot for 1) draft-ietf-netext-redirect-00 2) 15mins should be enough 3) Recap of the new WG draft Cheers, Jouni On Oct 12, 2009, at 3:50 PM, wrote: > > Hello, > > The Netext WG has been scheduled to meet on Wednesday, Nov 11th from > 1300-1500 Afternoon Session I. > If you need a time slot on the agenda, please send a request > including: > 1. I-D name > 2. Time needed > 3. Relevance to the Netext charter > > -Raj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From AMUHANNA@nortel.com Wed Oct 21 00:20:41 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2CC3A6953 for ; Wed, 21 Oct 2009 00:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 mOOOkk6m8DKp for ; Wed, 21 Oct 2009 00:20:40 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 235D83A684E for ; Wed, 21 Oct 2009 00:20:37 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n9L7Keu22275; Wed, 21 Oct 2009 07:20:40 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: Wed, 21 Oct 2009 02:15:54 -0500 Message-ID: In-Reply-To: <00af01ca5072$5fedbc30$430ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc Thread-Index: AcpO0ps1G/28Jm5JQ+m3ciWBCkU+5wAAnS6QAGS/R7AAbV9nYA== References: <00af01ca5072$5fedbc30$430ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "Jinwei Xia" Cc: netext@ietf.org, MELIA TELEMACO , Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 07:20:41 -0000 Hi, > >=20 > > > In such > > > case, the operation time will be short.=20 > > > In addtion, LMA can notify MAG the maintenance operation by=20 > > > out-of-band means. > > [Ahmad] > > That is a very GOOD idea. Then this feature is NOT needed. > > If the LMA is GOING to provide this information out-of-band, then the=20 > > LMA can provide the MAG with the new LMA IP address? Right? > > Mission Accomplished. >=20 > Sure, but out-of-band mean is another vague method and out of scope. >=20 [Ahmad]=20 Almost forgot about this ...... How the MAG would know when to send the re-registration for a chance load balancing? By out-of-band signaling. Why Not using the same out-of-band to communicate the LMA address? Out-of-band signaling is vague and out of scope? Interesting logic. Regards, Ahmad >=20 >=20 >=20 From xiajinwei@huawei.com Wed Oct 21 00:48:13 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C4F3A6883 for ; Wed, 21 Oct 2009 00:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 CUndOBWTMumY for ; Wed, 21 Oct 2009 00:48:12 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 36EE13A67A1 for ; Wed, 21 Oct 2009 00:48:12 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU00DN8TJXKO@szxga04-in.huawei.com> for netext@ietf.org; Wed, 21 Oct 2009 15:45:33 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU003U0TJWIP@szxga04-in.huawei.com> for netext@ietf.org; Wed, 21 Oct 2009 15:45:32 +0800 (CST) Received: from x65217 ([10.164.12.67]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRU00KT8TJW6J@szxml06-in.huawei.com> for netext@ietf.org; Wed, 21 Oct 2009 15:45:32 +0800 (CST) Date: Wed, 21 Oct 2009 15:45:32 +0800 From: Jinwei Xia In-reply-to: To: 'Ahmad Muhanna' Message-id: <007d01ca5222$77e766e0$430ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpO0ps1G/28Jm5JQ+m3ciWBCkU+5wAAnS6QAGS/R7AAbV9nYAAA2v4A Cc: netext@ietf.org, 'MELIA TELEMACO' , Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 07:48:13 -0000 Hi, > > > > Sure, but out-of-band mean is another vague method and out of scope. > > > [Ahmad] > Almost forgot about this ...... > > How the MAG would know when to send the re-registration for a > chance load balancing? By out-of-band signaling. > Why Not using the same out-of-band to communicate the LMA address? > Out-of-band signaling is vague and out of scope? hmm~ this is not my meaning. EITHER sending redirection indiction OR providing r2LMA address to MAG is out-of-band signaling, which can be regarded as another method to solve maintenance operation. But this method is out of scope in this draft. BR Jinwei > > Interesting logic. > > Regards, > Ahmad > > > > > > From teemu.savolainen@nokia.com Wed Oct 21 05:50:51 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5035E28C0E4 for ; Wed, 21 Oct 2009 05:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 H05mxWH+s+5A for ; Wed, 21 Oct 2009 05:50:50 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 64F153A69D5 for ; Wed, 21 Oct 2009 05:50:50 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9LCojnO005319; Wed, 21 Oct 2009 07:50:58 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 15:50:50 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 15:50:50 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 21 Oct 2009 14:50:50 +0200 From: To: , Date: Wed, 21 Oct 2009 14:49:16 +0200 Thread-Topic: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc Thread-Index: AcpQXHc3MKj30mM+TSue2mkJ0Y0xNwB8DjSg Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EFC5C@NOK-EUMSG-01.mgdnok.nokia.com> References: <4D35478224365146822AE9E3AD4A26660CAC545D@exchtewks3.starentnetworks.com> <011501ca505c$6348d010$40106f0a@china.huawei.com> In-Reply-To: <011501ca505c$6348d010$40106f0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Oct 2009 12:50:50.0667 (UTC) FILETIME=[1E3BB7B0:01CA524D] X-Nokia-AV: Clean Subject: Re: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 12:50:51 -0000 Hi, As do I, Best regards, Teemu=20 >-----Original Message----- >From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org]=20 >On Behalf Of ext Xiangsong Cui >Sent: 19 October, 2009 04:35 >To: Koodli, Rajeev; netext@ietf.org >Subject: Re: [netext] Consensus call to adopt=20 >ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc > >Hi, > >I support the adoption of this draft as a WG document. > >Regards >Xiangsong > > >----- Original Message ----- >From: "Koodli, Rajeev" >To: >Sent: Thursday, October 15, 2009 2:02 PM >Subject: [netext] Consensus call to adopt=20 >ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc > > > >Hello, > >One of the Netext WG items is: > >Dec 2009 Submit Bulk Refresh to IESG for publication as a >Proposed Standard RFC > >At the last IETF meeting, there was agreement to use=20 >draft-premec-netlmm-bulk-re-registration-02.txt as the=20 >baseline document for the above item. > >This document has been revised to version 03 in which the=20 >Group ID proposal outlined in >http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-01 >has been merged based on author's agreement. > >This is a consensus call for adoption of >http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-03 >as the WG document. > >Please respond by October 21. > >Thanks, > >-Rajeev > > > > > >--------------------------------------------------------------- >----------------- > > >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >>=20 > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext >= From jouni.nospam@gmail.com Wed Oct 21 05:57:07 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1793A6949 for ; Wed, 21 Oct 2009 05:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 VjfTs0Xrvqz4 for ; Wed, 21 Oct 2009 05:57:06 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 016A23A68E0 for ; Wed, 21 Oct 2009 05:57:05 -0700 (PDT) Received: by fxm18 with SMTP id 18so7715664fxm.37 for ; Wed, 21 Oct 2009 05:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=ImlPvGHk3eKLC8xEwhgTXjwRbXls9LYzytHUb2n8IGM=; b=AjgyBGP8/wxzpV9+3vxHbL5KvkJOvbhQYfN7x2PRIyu7lRLdvHfrfLZ9s4obtpvt6w fs3pn5DP7+2ouKFNp1HAeRP9nRBPEzFBghP8h8iru0Eyi6PAuwG4LOA86+pMXtRDEA1Z tBYJZvFMsD5Jer0FcW5rWkoWP7+ApasXNinAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=NeO87a8tmYs/xCRIAqn4AKhhvwnhTJt/bWGbugPggeJpLAw/WPmOJWmkJv6xXew7UL jkJeGHW+fx516RRCeEVbbxzImIBu/ymAPiSmnFFHXh26je1KbyupkdrJ6iDzrfhKVy5g Pb5waCJR05y4eG915lH/ASn0I7bmgt8nPxcuc= Received: by 10.204.162.143 with SMTP id v15mr1104051bkx.50.1256129829932; Wed, 21 Oct 2009 05:57:09 -0700 (PDT) Received: from a88-114-71-193.elisa-laajakaista.fi (a88-114-71-193.elisa-laajakaista.fi [88.114.71.193]) by mx.google.com with ESMTPS id y15sm147100fkd.28.2009.10.21.05.57.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Oct 2009 05:57:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) From: jouni korhonen In-Reply-To: <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EFC5C@NOK-EUMSG-01.mgdnok.nokia.com> Date: Wed, 21 Oct 2009 15:57:06 +0300 Content-Transfer-Encoding: 7bit Message-Id: <755D906E-758D-4325-984B-8BF82DA7D1FB@gmail.com> References: <4D35478224365146822AE9E3AD4A26660CAC545D@exchtewks3.starentnetworks.com> <011501ca505c$6348d010$40106f0a@china.huawei.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EFC5C@NOK-EUMSG-01.mgdnok.nokia.com> To: Rajeev Koodli , netext@ietf.org X-Mailer: Apple Mail (2.1076) Subject: Re: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 12:57:07 -0000 +1 Cheers, Jouni On Oct 21, 2009, at 3:49 PM, wrote: > Hi, > > As do I, > > Best regards, > > Teemu > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] >> On Behalf Of ext Xiangsong Cui >> Sent: 19 October, 2009 04:35 >> To: Koodli, Rajeev; netext@ietf.org >> Subject: Re: [netext] Consensus call to adopt >> ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc >> >> Hi, >> >> I support the adoption of this draft as a WG document. >> >> Regards >> Xiangsong >> >> >> ----- Original Message ----- >> From: "Koodli, Rajeev" >> To: >> Sent: Thursday, October 15, 2009 2:02 PM >> Subject: [netext] Consensus call to adopt >> ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc >> >> >> >> Hello, >> >> One of the Netext WG items is: >> >> Dec 2009 Submit Bulk Refresh to IESG for publication as a >> Proposed Standard RFC >> >> At the last IETF meeting, there was agreement to use >> draft-premec-netlmm-bulk-re-registration-02.txt as the >> baseline document for the above item. >> >> This document has been revised to version 03 in which the >> Group ID proposal outlined in >> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-01 >> has been merged based on author's agreement. >> >> This is a consensus call for adoption of >> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re- >> registration-03 >> as the WG document. >> >> Please respond by October 21. >> >> Thanks, >> >> -Rajeev >> >> >> >> >> >> --------------------------------------------------------------- >> ----------------- >> >> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From AMUHANNA@nortel.com Wed Oct 21 07:13:56 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C2A3A677D for ; Wed, 21 Oct 2009 07:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 gPbDjEkYUM-Z for ; Wed, 21 Oct 2009 07:13:55 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2C6D03A68A6 for ; Wed, 21 Oct 2009 07:13:54 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n9LEDwu05820; Wed, 21 Oct 2009 14:13:58 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: Wed, 21 Oct 2009 09:12:43 -0500 Message-ID: In-Reply-To: <007d01ca5222$77e766e0$430ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc Thread-Index: AcpO0ps1G/28Jm5JQ+m3ciWBCkU+5wAAnS6QAGS/R7AAbV9nYAAA2v4AAA17UsA= References: <007d01ca5222$77e766e0$430ca40a@china.huawei.com> From: "Ahmad Muhanna" To: "Jinwei Xia" Cc: netext@ietf.org, MELIA TELEMACO , Basavaraj.Patil@nokia.com Subject: Re: [netext] Consensus call to adopt I-D:draft-korhonen-netext-redirect as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 14:13:56 -0000 Hi, > -----Original Message----- > I-D:draft-korhonen-netext-redirect as WG doc >=20 > Hi, >=20 > > >=20 > > > Sure, but out-of-band mean is another vague method and=20 > out of scope. > > >=20 > > [Ahmad] > > Almost forgot about this ...... > >=20 > > How the MAG would know when to send the re-registration for=20 > a chance=20 > > load balancing? By out-of-band signaling. > > Why Not using the same out-of-band to communicate the LMA address? > > Out-of-band signaling is vague and out of scope? >=20 > hmm~ this is not my meaning. EITHER sending redirection=20 > indiction OR providing r2LMA address to MAG is out-of-band=20 > signaling, which can be regarded as another method to solve=20 > maintenance operation. But this method is out of scope in this draft.=20 [Ahmad] It seems we are going in a circle! You mentioned that this feature is needed for maintenance event and load balancing. NO?=20 The argument, how this load balancing/maintenance feature relies on a re-registration which is by nature has nothing to do with maintenance and load balancing. You said, to inform the MAG that a re-registration is NEEDED you use an out-of-band signaling. see below from your earlier reply. " In addtion, LMA can notify MAG the maintenance operation by out-of-band means.=20 " The question is: if in order to enable this feature you need an out-of-band signaling ANYWAY! Why NOT include the LMA address in the out-of-band signaling? You said because this out-of-band signaling is VAGUE and out-of-scope. Is that clear to you?=20 My point is: this is a very interesting logic! Regards, Ahmad >=20 > BR > Jinwei >=20 > >=20 > > Interesting logic. > >=20 > > Regards, > > Ahmad > > >=20 > > >=20 > > >=20 >=20 >=20 From Dirk.von-Hugo@telekom.de Wed Oct 21 08:03:51 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939653A689A for ; Wed, 21 Oct 2009 08:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 XFZBumvmwTXN for ; Wed, 21 Oct 2009 08:03:50 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id E27173A6818 for ; Wed, 21 Oct 2009 08:03:49 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 21 Oct 2009 17:03:31 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 17:03:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA525F.A6C04789" Date: Wed, 21 Oct 2009 17:03:31 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC802784801765F58@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4D35478224365146822AE9E3AD4A26660CAC545D@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc Thread-Index: AcpNXm8lPeSrMXWzQC+0mCg6gjMF5AE+rwgQ References: <4D35478224365146822AE9E3AD4A26660CAC545D@exchtewks3.starentnetworks.com> From: To: , X-OriginalArrivalTime: 21 Oct 2009 15:03:31.0121 (UTC) FILETIME=[A7089A10:01CA525F] Cc: domagoj.premec@gmail.com Subject: Re: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 15:03:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA525F.A6C04789 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I also support WG adoption of this document. ;-)=20 BTW I detected some minor nits on page 4: remove double 'sending a' remeinder -> remainder=20 page 5: identifed -> identified page 6: identifiy -> identify =20 Best regards,=20 Dirk=20 ________________________________ Von: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] Im Auftrag von Koodli, Rajeev Gesendet: Donnerstag, 15. Oktober 2009 08:02 An: netext@ietf.org Betreff: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc =20 Hello, =20 One of the Netext WG items is: =20 Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC=20 =20 At the last IETF meeting, there was agreement to use draft-premec-netlmm-bulk-re-registration-02.txt as the baseline document for the above item. =20 This document has been revised to version 03 in which the Group ID proposal outlined in http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-01 has been merged based on author's agreement.=20 =20 This is a consensus call for adoption of http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-03 as the WG document.=20 =20 Please respond by October 21. =20 Thanks, =20 -Rajeev =20 =20 ------_=_NextPart_001_01CA525F.A6C04789 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear=20 all,
I also=20 support WG adoption of this document.
;-)=20
BTW I=20 detected some minor nits on
page=20 4: remove double 'sending a'
          &nbs= p; remeinder=20 -> remainder 
page=20 5: identifed -> identified
page 6: identifiy -> identify
  

Best regards, =
Dirk =



Von: netext-bounces@ietf.org=20 [mailto:netext-bounces@ietf.org] Im Auftrag von Koodli,=20 Rajeev
Gesendet: Donnerstag, 15. Oktober 2009 = 08:02
An:=20 netext@ietf.org
Betreff: [netext] Consensus call to adopt=20 ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG=20 doc

 
Hello,
 
One of = the Netext WG=20 items is:
 
Dec=20 2009  Submit Bulk Refresh to IESG for = publication as=20 a Proposed Standard RFC
 
At the last IETF = meeting, there=20 was agreement to use draft-premec-netlmm-bulk-re-registration-02.txt as = the=20 baseline document for the above item.
 
This = document has=20 been revised to version 03 in which the Group ID proposal outlined in http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-opt= ion-01=20 has been merged based on author's agreement.
 
This = is a consensus=20 call for adoption of http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registratio= n-03 as=20 the WG document.
 
Please = respond by=20 October 21.
 
Thanks,
 
-Rajeev
 
 
------_=_NextPart_001_01CA525F.A6C04789-- From jari.arkko@piuha.net Wed Oct 21 14:28:55 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503BD28C104 for ; Wed, 21 Oct 2009 14:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 jKyRt3pStL-Y for ; Wed, 21 Oct 2009 14:28:54 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 1361028C100 for ; Wed, 21 Oct 2009 14:28:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AE76CD495C for ; Thu, 22 Oct 2009 00:29:02 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSQIkgO95HvM for ; Thu, 22 Oct 2009 00:29:02 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 94519D4900 for ; Thu, 22 Oct 2009 00:29:01 +0300 (EEST) Message-ID: <4ADF7D1C.5000402@piuha.net> Date: Thu, 22 Oct 2009 00:29:00 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] NETEXT2 BOF conclusion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 21:28:55 -0000 I have been trying to come up with a way forward on this, but its hard. To recap, there are a few different technical possibilities for multi-interface mobility: 1) Link layer hides interface variants behind one logical interface. For instance, an IP stack does not see the change from GSM to UMTS radio or 802.11b to 802.11g; its handled as a part of the link layer. Such link layer operations need to be supported both by the host and the network. This approach has the minimum impacts on IP stack, but requires specification of the link layer mechanisms across the used interfaces. 2) Different interfaces are handled via existing host-based mobility mechanisms (Mobile IPv6, MOBIKE, HIP, application layer). Within one interface the link layer handles mobility, possibly using Proxy MIP internally. Both the host and the network need to support the host-based mobility mechanism, but the link layer does not have to aware of the other interfaces in any way. 3) We extend Proxy MIP with capabilities to handle cross-interface handovers. This is similar to approach #1, but the signaling messages are at the IP layer. The benefit is that this could be used across different types of link layers even if they do not support handovers. The downside is that just as with approach #2, the IP stack has to be capable of these operations. The big argument we have been stuck with since San Francisco is between #2 and #3. One group believes that existing mechanisms are sufficient, and they are -- it is indeed possible to do this. Another group believes that they need a different solution based on Proxy MIP. Such a solution is also of course possible. But we've made very little headway in resolving the question on what should be done. In particular, we've not been able to describe very well why some technical reasons would dictate one or the other solution. I believe that is likely because they are really very similar solutions. At this point I do not believe we have consensus to go forward. We left the BOF with the idea that requirements work would solve this issue. If I'm right the solutions really are very similar, this work may not be able to resolve the conflict, and it would take a long time. I think it would actually serve as better if we were to decide now, as opposed to pretending that more details will make the decision easier. With this in mind, I have a proposal for a way forward. Given that I do not see consensus for approach #3, I do not think we can go ahead with that. I also personally believe that #2 and #3 are functionally similar enough that there's no requirement that forces us to pick #3. In addition, approach makes mobility end-to-end between the host and a network node; approach #3 ties the use of mobility to a particular link. If the router on that link does not support the mobility mechanism, mobility service is not possible. I think it would be architecturally better to separate access and mobility. However, I would like to move forward with a different work item. The IETF has never really explored approach #1, even if it is commonly used. Of course, the IETF's role is not to design these link layer mechanisms, but I believe it would be valuable for the IETF to publish an informational document on considerations for building such mechanisms. This document would talk about the requirements that the mechanisms must fulfill in order for IP to work correctly, when such mechanisms are recommended and when not, what their advantages and downsides are, what happens if MTUs or routers differ, and so on. At the same time this document would describe the "virtual link" model that some people have been using in the context of Proxy MIP. The idea is to add this work to the NETEXT WG charter. I realize this does not make everyone happy, but I'm not sure there is an outcome that does. What we lose by not doing solution 3 is a design that that simultaneously allows something to be done in a link-layer agnostic manner _and_ employs PMIP as a part of the solution. Thoughts? Jari From behcetsarikaya@yahoo.com Wed Oct 21 16:34:03 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D45228C119 for ; Wed, 21 Oct 2009 16:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.243 X-Spam-Level: X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 NOr2MzjAeImN for ; Wed, 21 Oct 2009 16:34:02 -0700 (PDT) Received: from web111416.mail.gq1.yahoo.com (web111416.mail.gq1.yahoo.com [67.195.15.222]) by core3.amsl.com (Postfix) with SMTP id 13C1828C0DF for ; Wed, 21 Oct 2009 16:33:59 -0700 (PDT) Received: (qmail 69274 invoked by uid 60001); 21 Oct 2009 23:34:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1256168046; bh=ms46vNQwxeMRcm5m9SXbzNfiEZi2LissVhfROvcLop4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=j8QST38sStBOhcptRVBwrYNpglNpAAxMiWETpiqqmldFWyRcukO7m2vwr3rfZFS5xEEOP39wGGs/oXOQO25hGDYYjVD+yJR0hlZtZ8MrrBxk7LZe7WnNngdLsSfzWrZMeEcyIV9q2nbWR/y2D7YLqG3I5bX42DzpMbrRS1Cndoo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Kt7Y9j9INRL0K8GN0qTTPFcFrwr8y+aXHVPCOgEQkeORNw8dJoufdJ5h9m/6XhqrQGptWSQrnV1x+E66gnA1xZh6L2jz2qKQ3BbUcIv/7T0jtq1TYxraaVejcNb9M6XBtpnVraMFijN2un4aZKVVaj7KatfwLYvfqgCExYbuPs4=; Message-ID: <123184.66765.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: PvmTS7oVM1lf.EvTefDHIXos.1mHgTGaT8CaRQDHkz5z5o_COLmvRBKkB72PX2se3N1ZZD56zUsMIy.7N0N.OaxqNrkDOo.1Vk9BHnXC0nY2VCNHpKlYMGHmHzBkJT.Q_WJyKWj5NQJ5Ibhj_R46vQXSdVfjnBQkjlTn3acQkOexDPRIqs.cixQxCuUc7abPFXJhIU3POK2B..jIegPtJklexRddmpnE6ppYJW.gf8z60LwB7OKOrIKa5HcR1EfxTNtWW4xgcVemK.u5BroM3uBcyjcG2AAZWIryZX.87m8GX60skeMmnRNBtNkMqMxscg1nIY85tlLmneutqvadr3zGJQuCF6sO931GvRmF Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Wed, 21 Oct 2009 16:34:05 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.361.3 References: <4ADF7D1C.5000402@piuha.net> Date: Wed, 21 Oct 2009 16:34:05 -0700 (PDT) From: Behcet Sarikaya To: Jari Arkko , netext@ietf.org In-Reply-To: <4ADF7D1C.5000402@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] NETEXT2 BOF conclusion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 23:34:03 -0000 Hi Jari,=0A=A0 I could not understand approach #2 well.=0A=0AHowever, I thi= nk that PMIPv6 has some other problems when it comes to a MIPv6-like flow m= obility solution. This is addressed in some drafts like Conny's. How are we= going to address those issues that relate to the basic design of the proto= col?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----=0A> F= rom: Jari Arkko =0A> To: netext@ietf.org=0A> Sent: We= d, October 21, 2009 4:29:00 PM=0A> Subject: [netext] NETEXT2 BOF conclusion= =0A> =0A> I have been trying to come up with a way forward on this, but its= hard.=0A> To recap, there are a few different technical possibilities for= =0A> multi-interface mobility:=0A> =0A> 1) Link layer hides interface varia= nts behind one logical interface. For=0A> instance, an IP stack does not se= e the change from GSM to UMTS radio or=0A> 802.11b to 802.11g; its handled = as a part of the link layer. Such link=0A> layer operations need to be supp= orted both by the host and the network.=0A> This approach has the minimum i= mpacts on IP stack, but requires=0A> specification of the link layer mechan= isms across the used interfaces.=0A> =0A> 2) Different interfaces are handl= ed via existing host-based mobility=0A> mechanisms (Mobile IPv6, MOBIKE, HI= P, application layer). Within one=0A> interface the link layer handles mobi= lity, possibly using Proxy MIP=0A> internally. Both the host and the networ= k need to support the host-based=0A> mobility mechanism, but the link layer= does not have to aware of the=0A> other interfaces in any way.=0A> =0A> 3)= We extend Proxy MIP with capabilities to handle cross-interface=0A> handov= ers. This is similar to approach #1, but the signaling messages=0A> are at = the IP layer. The benefit is that this could be used across=0A> different t= ypes of link layers even if they do not support handovers.=0A> The downside= is that just as with approach #2, the IP stack has to be=0A> capable of th= ese operations.=0A> =0A> The big argument we have been stuck with since San= Francisco is between=0A> #2 and #3. One group believes that existing mecha= nisms are sufficient,=0A> and they are -- it is indeed possible to do this.= Another group believes=0A> that they need a different solution based on Pr= oxy MIP. Such a solution=0A> is also of course possible. But we've made ver= y little headway in=0A> resolving the question on what should be done. In p= articular, we've not=0A> been able to describe very well why some technical= reasons would dictate=0A> one or the other solution. I believe that is lik= ely because they are=0A> really very similar solutions.=0A> =0A> At this po= int I do not believe we have consensus to go forward. We left=0A> the BOF w= ith the idea that requirements work would solve this issue. If=0A> I'm righ= t the solutions really are very similar, this work may not be=0A> able to r= esolve the conflict, and it would take a long time. I think it=0A> would ac= tually serve as better if we were to decide now, as opposed to=0A> pretendi= ng that more details will make the decision easier.=0A> =0A> With this in m= ind, I have a proposal for a way forward. Given that I do=0A> not see conse= nsus for approach #3, I do not think we can go ahead with=0A> that. I also = personally believe that #2 and #3 are functionally similar=0A> enough that = there's no requirement that forces us to pick #3. In=0A> addition, approach= makes mobility end-to-end between the host and a=0A> network node; approac= h #3 ties the use of mobility to a particular link.=0A> If the router on th= at link does not support the mobility mechanism,=0A> mobility service is no= t possible. I think it would be architecturally=0A> better to separate acce= ss and mobility.=0A> =0A> However, I would like to move forward with a diff= erent work item. The=0A> IETF has never really explored approach #1, even i= f it is commonly used.=0A> Of course, the IETF's role is not to design thes= e link layer mechanisms,=0A> but I believe it would be valuable for the IET= F to publish an=0A> informational document on considerations for building s= uch mechanisms.=0A> This document would talk about the requirements that th= e mechanisms must=0A> fulfill in order for IP to work correctly, when such = mechanisms are=0A> recommended and when not, what their advantages and down= sides are, what=0A> happens if MTUs or routers differ, and so on. At the sa= me time this=0A> document would describe the "virtual link" model that some= people have=0A> been using in the context of Proxy MIP. The idea is to add= this work=0A> to the NETEXT WG charter.=0A> =0A> I realize this does not m= ake everyone happy, but I'm not sure there=0A> is an outcome that does. Wha= t we lose by not doing solution 3 is=0A> a design that that simultaneously = allows something to be done=0A> in a link-layer agnostic manner _and_ emplo= ys PMIP as a part of the=0A> solution.=0A> =0A> Thoughts?=0A> =0A> Jari=0A>= =0A> _______________________________________________=0A> netext mailing li= st=0A> netext@ietf.org=0A> https://www.ietf.org/mailman/listinfo/netext=0A= =0A=0A=0A From Mohana.Jeyatharan@sg.panasonic.com Wed Oct 21 17:34:01 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698EA3A6A25 for ; Wed, 21 Oct 2009 17:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 Tf+AynOCaxNl for ; Wed, 21 Oct 2009 17:34:00 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 44FC33A6955 for ; Wed, 21 Oct 2009 17:33:59 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id n9M0Y3Mf025872; Thu, 22 Oct 2009 09:34:03 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id n9M0Y2F22066; Thu, 22 Oct 2009 09:34:03 +0900 (JST) 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: Thu, 22 Oct 2009 08:29:42 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD039D93BA@pslexc01.psl.local> In-Reply-To: <4D35478224365146822AE9E3AD4A26660CAC545D@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc Thread-Index: AcpNXm8lPeSrMXWzQC+0mCg6gjMF5AFUPQuA From: "Mohana Jeyatharan" To: "Koodli, Rajeev" , Subject: Re: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 00:34:01 -0000 Hi all, I support the adoption of this document as a WG document. BR, Mohana ________________________________________ From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Koodli, Rajeev Sent: Thursday, October 15, 2009 2:02 PM To: netext@ietf.org Subject: [netext] Consensus call to adopt = ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc =A0 Hello, =A0 One of the Netext WG items is: =A0 Dec 2009=A0=A0Submit Bulk Refresh to IESG for publication as a Proposed = Standard RFC=20 =A0 At the last IETF meeting, there was agreement to use = draft-premec-netlmm-bulk-re-registration-02.txt as the baseline document = for the above item. =A0 This document has been revised to version 03 in which the Group ID = proposal outlined in = http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-01 = has been merged based on author's agreement.=20 =A0 This is a consensus call for adoption of = http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-03=A0= as the WG document.=20 =A0 Please respond by October 21. =A0 Thanks, =A0 -Rajeev =A0 =A0 From wudiyetc@gmail.com Wed Oct 21 19:22:07 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C606A3A689F for ; Wed, 21 Oct 2009 19:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 2b10k-LZBYdn for ; Wed, 21 Oct 2009 19:22:04 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id CA7E43A683B for ; Wed, 21 Oct 2009 19:22:03 -0700 (PDT) Received: by bwz23 with SMTP id 23so384829bwz.29 for ; Wed, 21 Oct 2009 19:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:x-mailer:mime-version:content-type; bh=31x2/u96OLdUmtm1aPkb1/lDT5Kw/mQocqREx23LO0g=; b=dARIe403hdtNFlLDyHuDW1rYnmMk7NT5FRiAwwyOO/Jb1FEZ5+dmgSD5ZGTf+ZbiDi 7b5VMFZ1FjAZgBFOe844Hr5mbliPmo6ewSJue/gvh8RgU+KD70sUNcU4dijXZ9dXLhZc gfs2OTwK2Q2x/VV49V8I2MrAVME18TPsjagNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type; b=TutQm27FsSgMyo7S7eKz8DxGerTqUroHThmnIw2AI73GI28eVtkJCPfuVkBzRLV+jj cEIUcuOF6EOYm15+zeREC4+r2kQSMqpGHMp11Fr1ym2qSY7siTLx2gySvxMTHIsrI9s5 8gpp+eQvfeNUAEcwkysX9yk7RsWHgow3RbAg4= Received: by 10.103.81.8 with SMTP id i8mr3679229mul.80.1256178129591; Wed, 21 Oct 2009 19:22:09 -0700 (PDT) Received: from bupt-feng ([123.112.6.178]) by mx.google.com with ESMTPS id 14sm1140962muo.15.2009.10.21.19.22.03 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Oct 2009 19:22:08 -0700 (PDT) Date: Thu, 22 Oct 2009 10:22:13 +0800 From: "wudiyetc" To: "huimin.cmcc" Message-ID: <200910221022078595121@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon183283411143_=====" Cc: netext Subject: [netext] Question about the draft-hui-netext-multihoming X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 02:22:07 -0000 This is a multi-part message in MIME format. --=====003_Dragon183283411143_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi ,hui I have read you draft, but I have some questions, please see inline. Wudi Ye In section 2 >The bandwidth of any of IF1 or IF2 is not enough to maintain the >video telephony traffic, so a possible solution is to enable the MN >to send and receive the traffic addressed to HNP1 via IF1 and IF2 >simultaneously. I guess you mean divide a flow to more than one interface. In section 4.1 >1) Service Flow Identifier, an additional sub-field. A service > flow identifier is used to indicate one of the flows binding to the > MAG associated with the set. When flows are binding to the MAG, the > sub-field would include multiple flow identifiers. The detailed > format of service flow Identifier is out of the scope of this > document, more information can be found in [draft-hui-netext-service- > flow-identifier]. but every packets of each flow has the same property. So if use the Flow Identifier, each flow can only bind to one MAG, how to divide one flow to more than one interface? --=====003_Dragon183283411143_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
 
Hi ,hui
 
    I have read you draft, but I have some questions, please see inline.
 
                                                                     Wudi Ye
In section 2
>The bandwidth of any of IF1 or IF2 is not enough to maintain the
>video telephony traffic, so a possible solution is to enable the MN
>to send and receive the traffic addressed to HNP1 via IF1 and IF2
>simultaneously.
 
I guess you mean divide a flow to more than one interface.
 
In section 4.1
 >1) Service Flow Identifier, an additional sub-field. A service
 >  flow identifier is used to indicate one of the flows binding to the
 >  MAG associated with the set. When flows are binding to the MAG, the
 >  sub-field would include multiple flow identifiers. The detailed
 >  format of service flow Identifier is out of the scope of this
 >  document, more information can be found in [draft-hui-netext-service-
 >  flow-identifier].
but every packets of each flow has the same property. So if use the Flow Identifier,
each flow can only bind to one MAG, how to divide one flow to more than one interface?
 
--=====003_Dragon183283411143_=====-- From Xiangsong.Cui@huawei.com Thu Oct 22 05:45:37 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758483A69E1 for ; Thu, 22 Oct 2009 05:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 BBbWKYkRI2BR for ; Thu, 22 Oct 2009 05:45:36 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id A0DB13A69AC for ; Thu, 22 Oct 2009 05:45:36 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRX00DOA23Z9E@szxga01-in.huawei.com> for netext@ietf.org; Thu, 22 Oct 2009 20:45:36 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRX00FMM23Z5X@szxga01-in.huawei.com> for netext@ietf.org; Thu, 22 Oct 2009 20:45:35 +0800 (CST) Date: Thu, 22 Oct 2009 20:45:35 +0800 From: Xiangsong Cui To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <016801ca5315$8ccc0540$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [netext] Request for agenda slots at IETF76 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 12:45:37 -0000 Dear chairs, I would like to request a slot for 1. http://tools.ietf.org/id/draft-cui-netext-route-optimization-agent-ext-00.txt 2. I wish 10 minutes 3. This draft is about Network-based Route Optimization, not in current charter. I wish this item may be added when rechartering. Thanks and regards Xiangsong ----- Original Message ----- From: To: Sent: Monday, October 12, 2009 8:50 PM Subject: [netext] Request for agenda slots at IETF76 Hello, The Netext WG has been scheduled to meet on Wednesday, Nov 11th from 1300-1500 Afternoon Session I. If you need a time slot on the agenda, please send a request including: 1. I-D name 2. Time needed 3. Relevance to the Netext charter -Raj -------------------------------------------------------------------------------- > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Mohana.Jeyatharan@sg.panasonic.com Thu Oct 22 17:57:35 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E683A635F for ; Thu, 22 Oct 2009 17:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 CuQjn2xdrwWN for ; Thu, 22 Oct 2009 17:57:34 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 0F40B3A66B4 for ; Thu, 22 Oct 2009 17:57:33 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id n9N0vgrs022568; Fri, 23 Oct 2009 09:57:42 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id n9N0vg509474; Fri, 23 Oct 2009 09:57:42 +0900 (JST) 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: Fri, 23 Oct 2009 08:53:26 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03A2C109@pslexc01.psl.local> In-Reply-To: <4ADF7D1C.5000402@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] NETEXT2 BOF conclusion Thread-Index: AcpSlO8LXYogBOOnRXqRMM7OSQXTDQA55Etg From: "Mohana Jeyatharan" To: "Jari Arkko" , Subject: Re: [netext] NETEXT2 BOF conclusion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 00:57:35 -0000 Hello Jari, Thanks for the mail. The informational document based on approach 1, is it going to analyze or identify requirements needed to perform inter RAT handoff and multihoming(flow mobility) etc for PMIP? Is that the goal of the document? BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Jari Arkko > Sent: Thursday, October 22, 2009 5:29 AM > To: netext@ietf.org > Subject: [netext] NETEXT2 BOF conclusion >=20 > I have been trying to come up with a way forward on this, but its hard. > To recap, there are a few different technical possibilities for > multi-interface mobility: >=20 > 1) Link layer hides interface variants behind one logical interface. For > instance, an IP stack does not see the change from GSM to UMTS radio or > 802.11b to 802.11g; its handled as a part of the link layer. Such link > layer operations need to be supported both by the host and the network. > This approach has the minimum impacts on IP stack, but requires > specification of the link layer mechanisms across the used interfaces. >=20 > 2) Different interfaces are handled via existing host-based mobility > mechanisms (Mobile IPv6, MOBIKE, HIP, application layer). Within one > interface the link layer handles mobility, possibly using Proxy MIP > internally. Both the host and the network need to support the host-based > mobility mechanism, but the link layer does not have to aware of the > other interfaces in any way. >=20 > 3) We extend Proxy MIP with capabilities to handle cross-interface > handovers. This is similar to approach #1, but the signaling messages > are at the IP layer. The benefit is that this could be used across > different types of link layers even if they do not support handovers. > The downside is that just as with approach #2, the IP stack has to be > capable of these operations. >=20 > The big argument we have been stuck with since San Francisco is between > #2 and #3. One group believes that existing mechanisms are sufficient, > and they are -- it is indeed possible to do this. Another group believes > that they need a different solution based on Proxy MIP. Such a solution > is also of course possible. But we've made very little headway in > resolving the question on what should be done. In particular, we've not > been able to describe very well why some technical reasons would dictate > one or the other solution. I believe that is likely because they are > really very similar solutions. >=20 > At this point I do not believe we have consensus to go forward. We left > the BOF with the idea that requirements work would solve this issue. If > I'm right the solutions really are very similar, this work may not be > able to resolve the conflict, and it would take a long time. I think it > would actually serve as better if we were to decide now, as opposed to > pretending that more details will make the decision easier. >=20 > With this in mind, I have a proposal for a way forward. Given that I do > not see consensus for approach #3, I do not think we can go ahead with > that. I also personally believe that #2 and #3 are functionally similar > enough that there's no requirement that forces us to pick #3. In > addition, approach makes mobility end-to-end between the host and a > network node; approach #3 ties the use of mobility to a particular link. > If the router on that link does not support the mobility mechanism, > mobility service is not possible. I think it would be architecturally > better to separate access and mobility. >=20 > However, I would like to move forward with a different work item. The > IETF has never really explored approach #1, even if it is commonly used. > Of course, the IETF's role is not to design these link layer mechanisms, > but I believe it would be valuable for the IETF to publish an > informational document on considerations for building such mechanisms. > This document would talk about the requirements that the mechanisms must > fulfill in order for IP to work correctly, when such mechanisms are > recommended and when not, what their advantages and downsides are, what > happens if MTUs or routers differ, and so on. At the same time this > document would describe the "virtual link" model that some people have > been using in the context of Proxy MIP. The idea is to add this work > to the NETEXT WG charter. >=20 > I realize this does not make everyone happy, but I'm not sure there > is an outcome that does. What we lose by not doing solution 3 is > a design that that simultaneously allows something to be done > in a link-layer agnostic manner _and_ employs PMIP as a part of the > solution. >=20 > Thoughts? >=20 > Jari >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@starentnetworks.com Fri Oct 23 14:05:08 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F293A68C0 for ; Fri, 23 Oct 2009 14:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 Krs-gAmz+F2a for ; Fri, 23 Oct 2009 14:05:07 -0700 (PDT) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 0120B3A68AC for ; Fri, 23 Oct 2009 14:05:07 -0700 (PDT) X-ASG-Debug-ID: 1256331916-3e2400550008-XzWF0g X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id 4549EEFC42F for ; Fri, 23 Oct 2009 17:05:17 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id gAXXbKHGlGTmpLan for ; Fri, 23 Oct 2009 17:05:17 -0400 (EDT) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Oct 2009 17:00:58 -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 X-ASG-Orig-Subj: RE: [netext] NETEXT2 BOF conclusion Date: Fri, 23 Oct 2009 16:49:18 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266609382B14@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] NETEXT2 BOF conclusion Thread-Index: AcpSlThjrPDjJmOlTPGNJAlLBHbGoABi0aec References: <4ADF7D1C.5000402@piuha.net> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 23 Oct 2009 21:00:58.0047 (UTC) FILETIME=[EB394CF0:01CA5423] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1256331917 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com Subject: Re: [netext] NETEXT2 BOF conclusion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 21:05:08 -0000 =20 Hi Jari, =20 thanks for following up on this. =20 If I understand correctly, the proposal is to develop recommendations = for link layers to support inter-access handovers and flow mobility. =20 I am not sure why link layer is the best way to handle this when we are = in fact traversing disparate link layers.=20 I would have thought extensions to Router Solicitations and Router = Advertisements would be appropriate. Granted this is an extension to the = host stack, but that should be made clear in an Applicability Statement. =20 Anyway, this is missing an important piece: the LMA - MAG protocol = interaction, assuming underlying support for what is necessary between = MN and MAG. Without LMA - MAG protocol, we cannot do inter-tech = handovers and flow mobility. We would need this regardless of how we = solve the MN - MAG part.This should be included in the charter.=20 =20 Regards, =20 -Rajeev =20 =20 ________________________________ From: netext-bounces@ietf.org on behalf of Jari Arkko Sent: Wed 10/21/2009 2:29 PM To: netext@ietf.org Subject: [netext] NETEXT2 BOF conclusion I have been trying to come up with a way forward on this, but its hard. To recap, there are a few different technical possibilities for multi-interface mobility: 1) Link layer hides interface variants behind one logical interface. For instance, an IP stack does not see the change from GSM to UMTS radio or 802.11b to 802.11g; its handled as a part of the link layer. Such link layer operations need to be supported both by the host and the network. This approach has the minimum impacts on IP stack, but requires specification of the link layer mechanisms across the used interfaces. 2) Different interfaces are handled via existing host-based mobility mechanisms (Mobile IPv6, MOBIKE, HIP, application layer). Within one interface the link layer handles mobility, possibly using Proxy MIP internally. Both the host and the network need to support the host-based mobility mechanism, but the link layer does not have to aware of the other interfaces in any way. 3) We extend Proxy MIP with capabilities to handle cross-interface handovers. This is similar to approach #1, but the signaling messages are at the IP layer. The benefit is that this could be used across different types of link layers even if they do not support handovers. The downside is that just as with approach #2, the IP stack has to be capable of these operations. The big argument we have been stuck with since San Francisco is between #2 and #3. One group believes that existing mechanisms are sufficient, and they are -- it is indeed possible to do this. Another group believes that they need a different solution based on Proxy MIP. Such a solution is also of course possible. But we've made very little headway in resolving the question on what should be done. In particular, we've not been able to describe very well why some technical reasons would dictate one or the other solution. I believe that is likely because they are really very similar solutions. At this point I do not believe we have consensus to go forward. We left the BOF with the idea that requirements work would solve this issue. If I'm right the solutions really are very similar, this work may not be able to resolve the conflict, and it would take a long time. I think it would actually serve as better if we were to decide now, as opposed to pretending that more details will make the decision easier. With this in mind, I have a proposal for a way forward. Given that I do not see consensus for approach #3, I do not think we can go ahead with that. I also personally believe that #2 and #3 are functionally similar enough that there's no requirement that forces us to pick #3. In addition, approach makes mobility end-to-end between the host and a network node; approach #3 ties the use of mobility to a particular link. If the router on that link does not support the mobility mechanism, mobility service is not possible. I think it would be architecturally better to separate access and mobility. However, I would like to move forward with a different work item. The IETF has never really explored approach #1, even if it is commonly used. Of course, the IETF's role is not to design these link layer mechanisms, but I believe it would be valuable for the IETF to publish an informational document on considerations for building such mechanisms. This document would talk about the requirements that the mechanisms must fulfill in order for IP to work correctly, when such mechanisms are recommended and when not, what their advantages and downsides are, what happens if MTUs or routers differ, and so on. At the same time this document would describe the "virtual link" model that some people have been using in the context of Proxy MIP. The idea is to add this work to the NETEXT WG charter. I realize this does not make everyone happy, but I'm not sure there is an outcome that does. What we lose by not doing solution 3 is a design that that simultaneously allows something to be done in a link-layer agnostic manner _and_ employs PMIP as a part of the solution. Thoughts? Jari _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Sat Oct 24 18:50:08 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94EF53A67C0 for ; Sat, 24 Oct 2009 18:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 n+AJg-IAADba for ; Sat, 24 Oct 2009 18:50:07 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A62FB3A677E for ; Sat, 24 Oct 2009 18:50:07 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9P1oHBS020808 for ; Sat, 24 Oct 2009 20:50:18 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 03:50:16 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 03:50:16 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Sun, 25 Oct 2009 02:50:16 +0100 From: To: Date: Sun, 25 Oct 2009 02:50:12 +0100 Thread-Topic: List of requests for agenda slots received Thread-Index: AcpUKbEzyfjfSSR+QbWr2OJYFu0uJA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FAAB54171A6C764E969E6B4CB3C2ADD20DD78DDB13NOKEUMSG03mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Oct 2009 01:50:16.0482 (UTC) FILETIME=[80120820:01CA5515] X-Nokia-AV: Clean Subject: [netext] List of requests for agenda slots received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 01:50:08 -0000 --_000_FAAB54171A6C764E969E6B4CB3C2ADD20DD78DDB13NOKEUMSG03mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These are the requests that we have received for a timeslot. If there is any that I have missed, please do let me know. 1. Carlos J. Bernardos - I-D ; 10 mins 2. Bechect S./Frank Xia - Differentiated Services Support for Proxy Mobile IPv6; 5 Mins 3. Marco Liebsch - I-D 5~10 Mins 4. Sri Gundavelli - I-D ; 5. Carlos J. Bernardos - I-D 6. Mohana Jeyatharan [1]draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt and [10 minutes] [2]draft-jeyatharan-netext-pmip-dormant-binding-00.txt [10 minutes] 7. Hui Min/Hui Deng 1. draft-hui-netext-multihoming-00.txt 10min 2. draft-hui-netext-service-flow-identifier-01.txt 10min 8. Jouni Korhonen - I-D 9. Marco Liebsch - I-D 10. Xiansong Cui - I-D ; 10 Mins 11. B. Patil/Sri G. - I-D ; 10 Mins -Raj --_000_FAAB54171A6C764E969E6B4CB3C2ADD20DD78DDB13NOKEUMSG03mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
These are the requests that we have received for a ti= meslot. If there
is any that I have missed, please do let me know.
 
1. Carlos J. Bernardos - I-D <draft-bernardos-mif-= pmip-00.txt>; 10 mins
 
2. Bechect S./Frank Xia - Differentiated Services Sup= port for Proxy
   Mobile IPv6; 5 Mins
 
3. Marco Liebsch - I-D <draft-loureiro-netext-pmip= v6-ro-01.txt> 5~10
   Mins
 
4. Sri Gundavelli - I-D
   <draft-gundavelli-softwire-gateway-in= it-ds-lite-00.txt>;
 
5. Carlos J. Bernardos - I-D
   <draft-bernardos-netext-pmipv6-nemo-p= s-00.txt>
 
6. Mohana Jeyatharan
   [1]draft-jeyatharan-netext-pmip-bulkpbu-= bitmap-00.txt and [10 minutes]
   [2]draft-jeyatharan-netext-pmip-dormant-= binding-00.txt [10 minutes]
 
7. Hui Min/Hui Deng
   1. draft-hui-netext-multihoming-00.txt&n= bsp; 10min
   2. draft-hui-netext-service-flow-identif= ier-01.txt  10min
 
8. Jouni Korhonen - I-D <draft-ietf-netext-redirec= t-00>
 
9. Marco Liebsch - I-D <draft-ietf-netext-pmip6-lr= -ps-00>
 
10. Xiansong Cui - I-D
    <draft-cui-netext-route-optimiz= ation-agent-ext-00.txt>; 10 Mins
 
11. B. Patil/Sri G. - I-D
    <draft-premec-netlmm-bulk-re-re= gistration-03> ; 10 Mins
 
-Raj
       
 
 
 
--_000_FAAB54171A6C764E969E6B4CB3C2ADD20DD78DDB13NOKEUMSG03mgd_-- From trungtm2909@gmail.com Sat Oct 24 18:59:19 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4ACD3A67C1 for ; Sat, 24 Oct 2009 18:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 1Xshjb6IZrw8 for ; Sat, 24 Oct 2009 18:59:18 -0700 (PDT) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id 8FD1E3A67FA for ; Sat, 24 Oct 2009 18:59:18 -0700 (PDT) Received: by iwn40 with SMTP id 40so5499030iwn.32 for ; Sat, 24 Oct 2009 18:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KApqmBfTLXlSY69896NKyEpbhujDa87o2ZtbpmHHLAg=; b=wTKKbR+NHcPWp2qNK1RbhHczWa4osqFtFdY1DruCEfRxV8Td29RlJlNpGrDexLJ7HS nHwYDFA+R1AgU2jFnEQnKA1H9qS6aGLEFgIMC1r3gw+nL4v1vSA62kCO3Rh9+nZC9s4u /K9OYdi7/ZYtyWmGb/eoz0imz4xnbd8LdLS/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rR443/nRkqCFvE8eI9IKCKE1rI7Tf7zPTNv0jH+z1IWvelLR3fxxlGGcma2aMwXCry AcdbmKQTSKn4ZOSJ4EErlcUfyQpI7EV/68gBO0DeP2cWtM/qdHn31MQWffXodxQVvxYW 4bY3OqTT5Ii/EheUkOwvTniwnaWiXkMBw8JIg= MIME-Version: 1.0 Received: by 10.231.120.90 with SMTP id c26mr2552834ibr.1.1256435967982; Sat, 24 Oct 2009 18:59:27 -0700 (PDT) In-Reply-To: References: Date: Sun, 25 Oct 2009 10:59:27 +0900 Message-ID: From: Tran Minh Trung To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org, "Hong. Yong Geun" Subject: Re: [netext] List of requests for agenda slots received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 01:59:20 -0000 Dear Raj, I would like to have a slot for: 1. http://tools.ietf.org/search/draft-trung-netext-virtual-interface-00 2. 10mins 3. It is about using of virtual interface to support multihoming and inter technology handover in PMIPv6. Best regards, Tran Minh Trung On Sun, Oct 25, 2009 at 10:50 AM, wrote: > > These are the requests that we have received for a timeslot. If there > is any that I have missed, please do let me know. > > 1. Carlos J. Bernardos - I-D ; 10 mins > > 2. Bechect S./Frank Xia - Differentiated Services Support for Proxy > =A0=A0 Mobile IPv6; 5 Mins > > 3. Marco Liebsch - I-D 5~10 > =A0=A0 Mins > > 4. Sri Gundavelli - I-D > =A0=A0 ; > > 5. Carlos J. Bernardos - I-D > =A0=A0 > > 6. Mohana Jeyatharan > =A0=A0 [1]draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt and [10 minu= tes] > =A0=A0 [2]draft-jeyatharan-netext-pmip-dormant-binding-00.txt [10 minutes= ] > > 7. Hui Min/Hui Deng > =A0=A0 1. draft-hui-netext-multihoming-00.txt=A0 10min > =A0=A0 2. draft-hui-netext-service-flow-identifier-01.txt=A0 10min > > 8. Jouni Korhonen - I-D > > 9. Marco Liebsch - I-D > > 10. Xiansong Cui - I-D > =A0=A0=A0 ; 10 Mins > > 11. B. Patil/Sri G. - I-D > =A0=A0=A0 ; 10 Mins > > -Raj > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132, Fax : +82-42-861-5404 From cjbc@it.uc3m.es Sun Oct 25 11:15:27 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA7F3A69B6 for ; Sun, 25 Oct 2009 11:15:27 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [quoted-printable] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, 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 Ve-mkF5OvH+Y for ; Sun, 25 Oct 2009 11:15:26 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 4D4C03A69B4 for ; Sun, 25 Oct 2009 11:15:26 -0700 (PDT) Received: from [192.168.1.209] (82.159.18.172.dyn.user.ono.com [82.159.18.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 2CA3FBA65DE; Sun, 25 Oct 2009 19:15:37 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: netext@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-3FPZyqrgBrtRyr9aLELd" Organization: Universidad Carlos III de Madrid Date: Sun, 25 Oct 2009 19:15:39 +0100 Message-Id: <1256494539.4766.87.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16970.000 Cc: =?ISO-8859-1?Q?Mar=EDa_Calder=F3n?= Subject: [netext] [Fwd: I-D Action:draft-bernardos-netext-pmipv6-nemo-ps-01.txt] X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 18:15:27 -0000 --=-3FPZyqrgBrtRyr9aLELd Content-Type: multipart/mixed; boundary="=-Al2YMiMIviOKMOQVP+15" --=-Al2YMiMIviOKMOQVP+15 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi all, We've submitted a draft describing the problem of fully supporting mobile networks in PMIPv6 (see attached for details). As usual, comments are very welcome. Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-Al2YMiMIviOKMOQVP+15 Content-Disposition: inline Content-Description: Forwarded message - I-D Action:draft-bernardos-netext-pmipv6-nemo-ps-01.txt Content-Type: message/rfc822 Return-Path: Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by shem.uc3m.es (Postfix) with ESMTP id 82042255EF; Sun, 25 Oct 2009 18:01:17 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by smtp03.uc3m.es (Postfix) with ESMTP id 4EF437F3751; Sun, 25 Oct 2009 18:01:16 +0100 (CET) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 680A13A6862; Sun, 25 Oct 2009 10:00:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-bernardos-netext-pmipv6-nemo-ps-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091025170003.680A13A6862@core3.amsl.com> Date: Sun, 25 Oct 2009 10:00:03 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : PMIPv6 and Network Mobility Problem Statement Author(s) : C. Bernardos, et al. Filename : draft-bernardos-netext-pmipv6-nemo-ps-01.txt Pages : 8 Date : 2009-10-25 The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing the IP address. Current PMIPv6 specification does only support the movement of hosts within the localized mobility domain. A mobile network (commonly referred to as a NEMO, NEtwork that MOves) can also benefit from the network-based localized mobility support provided by PMIPv6, but in a limited way. This I-D describes what can be done with current standardized protocols, and describes the problem statement of fully supporting network mobility in Proxy Mobile IPv6. The goal of this document is to present the problem -- and the use cases where this problem is relevant to be solved -- to collect feedback from the community about the interest in working on this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bernardos-netext-pmipv6-nemo-ps-0= 1.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-bernardos-netext-pmipv6-nemo-ps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <2009-10-25095944.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --=-Al2YMiMIviOKMOQVP+15-- --=-3FPZyqrgBrtRyr9aLELd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkrklcsACgkQNdy6TdFwT2dz7wCfaKqoWQBZYOq8eRrLhl+cqidR U18Ani05y+lmZ5U4ZN6JwR/HvyL//ecS =uLpv -----END PGP SIGNATURE----- --=-3FPZyqrgBrtRyr9aLELd-- From yokota@kddilabs.jp Sun Oct 25 19:58:32 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866093A680E for ; Sun, 25 Oct 2009 19:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=0.564, 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 58bl9StQVc-h for ; Sun, 25 Oct 2009 19:58:31 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id 836043A67C1 for ; Sun, 25 Oct 2009 19:58:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 6B96EEC8D4; Mon, 26 Oct 2009 11:58:40 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [2001:200:601:402::145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 04B2DEC8AD; Mon, 26 Oct 2009 11:58:40 +0900 (JST) Received: from [IPv6:::1] (unknown [IPv6:2001:200:601:400:3d37:d64f:ab45:e6c4]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id B35011BAA7; Mon, 26 Oct 2009 11:52:43 +0900 (JST) Message-ID: <4AE5104F.2040500@kddilabs.jp> Date: Mon, 26 Oct 2009 11:58:23 +0900 From: Hidetoshi Yokota User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: netext@ietf.org Subject: Re: [netext] List of requests for agenda slots received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 02:58:32 -0000 Hi Raj, Sorry for the late request, but could it be possible to assign a slot for the following? Sri Gundavelli/Hidetoshi Yokota I-D ; 5-10 min According to Jari's BOF conclusion, it will be a good and timely topic to discuss. Thanks in advance, -- Hidetoshi Basavaraj.Patil@nokia.com wrote: > > These are the requests that we have received for a timeslot. If there > is any that I have missed, please do let me know. > > 1. Carlos J. Bernardos - I-D ; 10 mins > > 2. Bechect S./Frank Xia - Differentiated Services Support for Proxy > Mobile IPv6; 5 Mins > > 3. Marco Liebsch - I-D 5~10 > Mins > > 4. Sri Gundavelli - I-D > ; > > 5. Carlos J. Bernardos - I-D > > > 6. Mohana Jeyatharan > [1]draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt and [10 minutes] > [2]draft-jeyatharan-netext-pmip-dormant-binding-00.txt [10 minutes] > > 7. Hui Min/Hui Deng > 1. draft-hui-netext-multihoming-00.txt 10min > 2. draft-hui-netext-service-flow-identifier-01.txt 10min > > 8. Jouni Korhonen - I-D > > 9. Marco Liebsch - I-D > > 10. Xiansong Cui - I-D > ; 10 Mins > > 11. B. Patil/Sri G. - I-D > ; 10 Mins > > -Raj > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From maxpassion@gmail.com Sun Oct 25 21:27:07 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB5528C1E4 for ; Sun, 25 Oct 2009 21:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Hg+LFBPa1qL8 for ; Sun, 25 Oct 2009 21:27:03 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 4B0CD28C1E6 for ; Sun, 25 Oct 2009 21:27:03 -0700 (PDT) Received: by pxi6 with SMTP id 6so114984pxi.31 for ; Sun, 25 Oct 2009 21:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZgavPgWwVUsMSTSbfwwhKyGU7E4qJoTJTy7F+9egME0=; b=ndoOLiBZQBUbOx+kl0oDcafQQWIirg3ohSQODDZabA13pnH+354qCmeinFsNo0KhqK OQ/+L0XD4AeziP3U0IlIXSBkIPP77uHNUIOmcim2Yp8yse7eqgfHfYGDc+6IAhHFjkIa tKr2b0HQCVpyb8xlvgsSlyJF+aBHyv0i5YwG8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=m93wf2KvLxX1amla1Yr583N76VAqmThUbimgByRiJIu6Vkkf0U2mFxCRzFcYX9bT3b pJjKV0tc3W0CzQ6BczrL+enWJdUBFlhGsDCc2+hq/4BfIOm9ro9+NzEGF10lA72vq9R8 bPvI4NjIu1Jr51u1RXW/PveiJkWuRov4IupMQ= MIME-Version: 1.0 Received: by 10.142.6.11 with SMTP id 11mr1059863wff.68.1256531230826; Sun, 25 Oct 2009 21:27:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Oct 2009 12:27:10 +0800 Message-ID: <25e1aaa40910252127k2ef76ddjaab4eb1a5a3b9b0a@mail.gmail.com> From: liu dapeng To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] List of requests for agenda slots received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 04:27:08 -0000 Hi Raj, In item 7, there is one additional draft: draft-liu-netext-singnaling-data-separation-00.txt that we would like to present, 10 mins will be sufficient. (by Hui Deng). Thanks. BR, Dapeng Liu 2009/10/25, Basavaraj.Patil@nokia.com : > > These are the requests that we have received for a timeslot. If there > is any that I have missed, please do let me know. > > 1. Carlos J. Bernardos - I-D ; 10 mins > > 2. Bechect S./Frank Xia - Differentiated Services Support for Proxy > Mobile IPv6; 5 Mins > > 3. Marco Liebsch - I-D 5~10 > Mins > > 4. Sri Gundavelli - I-D > ; > > 5. Carlos J. Bernardos - I-D > > > 6. Mohana Jeyatharan > [1]draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt and [10 minutes] > [2]draft-jeyatharan-netext-pmip-dormant-binding-00.txt [10 minutes] > > 7. Hui Min/Hui Deng > 1. draft-hui-netext-multihoming-00.txt 10min > 2. draft-hui-netext-service-flow-identifier-01.txt 10min > > 8. Jouni Korhonen - I-D > > 9. Marco Liebsch - I-D > > 10. Xiansong Cui - I-D > ; 10 Mins > > 11. B. Patil/Sri G. - I-D > ; 10 Mins > > -Raj > > > > > From Xiangsong.Cui@huawei.com Sun Oct 25 22:03:54 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5A043A6870 for ; Sun, 25 Oct 2009 22:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 5fdEvT4TYgZC for ; Sun, 25 Oct 2009 22:03:52 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id BEDCC3A6830 for ; Sun, 25 Oct 2009 22:03:52 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS3005A9VEFU4@szxga02-in.huawei.com> for netext@ietf.org; Mon, 26 Oct 2009 13:03:51 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS30078KVEFRR@szxga02-in.huawei.com> for netext@ietf.org; Mon, 26 Oct 2009 13:03:51 +0800 (CST) Date: Mon, 26 Oct 2009 13:03:50 +0800 From: Xiangsong Cui To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <01d901ca55f9$b5407b00$40106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [netext] List of requests for agenda slots received X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 05:03:54 -0000 Hi Raj, Thank you for your arrangement, and the draft draft-cui-netext-route-optimization-agent-ext-00.txt has been updated to version 01, http://tools.ietf.org/id/draft-cui-netext-route-optimization-agent-ext-01.txt The main modifications include following: Route Optimization requirements from 3GPP2; New concept definition, Route Optimization Agent and Agent Binding Cache; Source address replacement for incoming packet; Configuration variable; LMA/MAG implement; MAG handover consideration. Regards Xiangsong ----- Original Message ----- From: To: Sent: Sunday, October 25, 2009 9:50 AM Subject: [netext] List of requests for agenda slots received These are the requests that we have received for a timeslot. If there is any that I have missed, please do let me know. 1. Carlos J. Bernardos - I-D ; 10 mins 2. Bechect S./Frank Xia - Differentiated Services Support for Proxy Mobile IPv6; 5 Mins 3. Marco Liebsch - I-D 5~10 Mins 4. Sri Gundavelli - I-D ; 5. Carlos J. Bernardos - I-D 6. Mohana Jeyatharan [1]draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt and [10 minutes] [2]draft-jeyatharan-netext-pmip-dormant-binding-00.txt [10 minutes] 7. Hui Min/Hui Deng 1. draft-hui-netext-multihoming-00.txt 10min 2. draft-hui-netext-service-flow-identifier-01.txt 10min 8. Jouni Korhonen - I-D 9. Marco Liebsch - I-D 10. Xiansong Cui - I-D ; 10 Mins 11. B. Patil/Sri G. - I-D ; 10 Mins -Raj -------------------------------------------------------------------------------- > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From sunseawq@huawei.com Mon Oct 26 05:56:02 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4311428C0F0 for ; Mon, 26 Oct 2009 05:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.172 X-Spam-Level: X-Spam-Status: No, score=0.172 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 CkRDBUcObS8A for ; Mon, 26 Oct 2009 05:56:01 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id C60E328C0E7 for ; Mon, 26 Oct 2009 05:56:00 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS400AQGH9FPT@szxga01-in.huawei.com> for netext@ietf.org; Mon, 26 Oct 2009 20:56:03 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS4007A2H9FNH@szxga01-in.huawei.com> for netext@ietf.org; Mon, 26 Oct 2009 20:56:03 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS400FCRH9FYA@szxml04-in.huawei.com> for netext@ietf.org; Mon, 26 Oct 2009 20:56:03 +0800 (CST) Date: Mon, 26 Oct 2009 20:56:03 +0800 From: Qin Wu To: netext@ietf.org Message-id: <068801ca563b$acbce440$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4D35478224365146822AE9E3AD4A26660CAC545D@exchtewks3.starentnetworks.com> <011501ca505c$6348d010$40106f0a@china.huawei.com> <18034D4D7FE9AE48BF19AB1B0EF2729F3EF10EFC5C@NOK-EUMSG-01.mgdnok.nokia.com> <755D906E-758D-4325-984B-8BF82DA7D1FB@gmail.com> Subject: [netext] Comments on the draft-premec-netlmm-bulk-re-registration-03 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:56:02 -0000 Hi, May I have some comments on the draft-premec-netlmm-bulk-re-registration-03? It seems to me the Bulk registration Flag (B) are applied in two different cases: Case 1: The 'B' bit is used for requesting to extend lifetime for all MN that are part of bulk re-registration set. Case 2: The 'B' bit is used for requesting the MN to be added/removed to the bulk re-registration set. Suppose MAG requests to extend lifetime for a group of MNs and at the same time requests to remove another individual MN1 to one bulk registration set, How does the MAG set the 'B' bit in the PBU? Suppose MAG requests to bulk de-registration to LMA for a group of MNs by set 'B' to zero and at the same time requests to add another individual MN to one bulk registration set, How does the MAG set the 'B' bit in the PBU? Suppose MAG request to extend lifetime for one group of MNs and end lifetime for another group of MNs, how does the MAG set the 'B' bit in the PBU? Suppose MAG requests to extend lifetime for a group of MNs and at the same time requests to add another individual MN to one bulk registration set by sending PBU to LMA, how does LMA distinguish 'B' bit used for two different cases? If one PBU is sent to LMA with 'B' bit set to zero and group ID set to zero, non-zero MN HNP option included, how does LMA distinguish this PBU as one message used for removing MN from one bulk re-registration set or one message used for normal PBU? Therefore I am a little confused with the real purpose of 'B' bit in the PBU. Is it enough for defining only 'B' bit in the PBU? Is it necessary to define one more bit to indicate whether bulk re-registration is supported if 'B' is only used for adding or removing MN from one bulk re-registration set? or we constrain the solution scope into only some of scenarios? What am I missing? Who would like to clarify this to me? Thanks a lot! Regards! -Qin ----- Original Message ----- From: "jouni korhonen" To: "Rajeev Koodli" ; Sent: Wednesday, October 21, 2009 8:57 PM Subject: Re: [netext] Consensus call to adoptID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc > +1 > > Cheers, > Jouni > > On Oct 21, 2009, at 3:49 PM, > wrote: > >> Hi, >> >> As do I, >> >> Best regards, >> >> Teemu >> >>> -----Original Message----- >>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] >>> On Behalf Of ext Xiangsong Cui >>> Sent: 19 October, 2009 04:35 >>> To: Koodli, Rajeev; netext@ietf.org >>> Subject: Re: [netext] Consensus call to adopt >>> ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc >>> >>> Hi, >>> >>> I support the adoption of this draft as a WG document. >>> >>> Regards >>> Xiangsong >>> >>> >>> ----- Original Message ----- >>> From: "Koodli, Rajeev" >>> To: >>> Sent: Thursday, October 15, 2009 2:02 PM >>> Subject: [netext] Consensus call to adopt >>> ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc >>> >>> >>> >>> Hello, >>> >>> One of the Netext WG items is: >>> >>> Dec 2009 Submit Bulk Refresh to IESG for publication as a >>> Proposed Standard RFC >>> >>> At the last IETF meeting, there was agreement to use >>> draft-premec-netlmm-bulk-re-registration-02.txt as the >>> baseline document for the above item. >>> >>> This document has been revised to version 03 in which the >>> Group ID proposal outlined in >>> http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-01 >>> has been merged based on author's agreement. >>> >>> This is a consensus call for adoption of >>> http://tools.ietf.org/html/draft-premec-netlmm-bulk-re- >>> registration-03 >>> as the WG document. >>> >>> Please respond by October 21. >>> >>> Thanks, >>> >>> -Rajeev >>> >>> >>> >>> >>> >>> --------------------------------------------------------------- >>> ----------------- >>> >>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sunseawq@huawei.com Mon Oct 26 06:01:08 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EAC23A688A for ; Mon, 26 Oct 2009 06:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.077 X-Spam-Level: X-Spam-Status: No, score=0.077 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 1HSsh6Qj82p1 for ; Mon, 26 Oct 2009 06:01:07 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A33323A6860 for ; Mon, 26 Oct 2009 06:01:06 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS400D9SHA0GO@szxga04-in.huawei.com> for netext@ietf.org; Mon, 26 Oct 2009 20:56:24 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS4008UYHA02Z@szxga04-in.huawei.com> for netext@ietf.org; Mon, 26 Oct 2009 20:56:24 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS400EEBH9ZTH@szxml04-in.huawei.com> for netext@ietf.org; Mon, 26 Oct 2009 20:56:24 +0800 (CST) Date: Mon, 26 Oct 2009 20:56:23 +0800 From: Qin Wu To: Mohana Jeyatharan , netext@ietf.org Message-id: <068901ca563b$b91fd210$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5F09D220B62F79418461A978CA0921BD039D8B31@pslexc01.psl.local> Subject: [netext] Comments on draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:01:08 -0000 Hi, Mohana: I read your I-D about bitmap based PBU and would like to have some comments as follows: It seems to me the Bulk PBU using Bitmap is one robust header/packet compression mechanism. in other words, Bulk PBU can be further compressed or optimized using Bitmap which saves not only signaling but also packet size comparing with Bulk re-registration mechanism described in draft-premec-netlmm-bulk-re-registration-03. But what I am still difficult to understand is in which situation or scenario the Bitmap based Bulk PBU will be utitlized instead of Bulk re-registration ? As you said in the I-D, The PBU originating from the MAG can be of different types such as initial registration PBU, handoff PBU, re-registration PBU and de-registration PBU. If the PBU originating from the MAG is initial registraion PBU, how can you guarantee that MAG initializing Bulk PBU can be attached by several Mobile nodes at the same time during initial registration for all these mobile nodes? Without attachment by several mobile nodes simutanesouly, how does the MAG construct bitmap base Bulk PBU packet? I think the same applies to handoff PBU. If the PUB originating from the MAG is re-registraion PBU, I am afraid that the most efficient or optimized way is to only carry Bulk Set ID or grouped ID in the re-registration PBU, the other mobility options is not necessary to be included, because LMA has already maintained binding for all these mobile nodes pertained to Bulk Set ID or grouped ID. In this scenario, if we still choose to use bitmap based PBU, more packet size will be costed for bitmap option included. The same applies to de-registration PBU. Therefore the only two pratical scenarios occuring to me instead of using Bulk re-registration are a. Bitmap based Bulk PBU can be used when several MNs ask to be added into Bulk re-registration set. b. MAG sending a Bitmap based bulk PBU containing several Bulk Set IDs created during the Bulk re-registration and several other Individual mobile nodes who would like to be added to one specific bulk re-registration set. In these two scenarios, bitmap based PBU can be used to compress packet size of PBU that includes several MNs who ask to join several bulk re-registration sets by avoiding duplicate mobility options for different MNs. Am I right? Regards! -Qin ----- Original Message ----- From: "Mohana Jeyatharan" To: Sent: Friday, October 16, 2009 9:13 AM Subject: [netext] FW: I-DAction:draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt Hi all, This ID is highlighting a bulk PBU optimization approach using bit maps. This approach can be used to send multiple PBU signals of any type in a combined manner using bitmaps. This approach can work along with the MN group ID approach as well as highlighted in this draft. Please see. Comments are appreciated. Thanks. BR, Mohana -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, October 16, 2009 9:00 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Bulk PBU using Bitmaps Author(s) : M. Jeyatharan, C. Ng Filename : draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt Pages : 8 Date : 2009-10-15 In Proxy Mobile Internet Protocol version 6 (PMIPv6), each mobile node attached to a mobile access gateway (MAG) requires separate signaling. This might result in excessive network signaling if there a large number of mobile nodes attached to a MAG. In this draft we outline a bulk PBU optimization approach based on bitmap, in order to reduce the signaling load tied to numerous PBUs originating at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-pmip-bulkpbu -bitmap-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------------------- > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From desire.oulai@ericsson.com Mon Oct 26 06:47:25 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D95328C296 for ; Mon, 26 Oct 2009 06:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 n6kjJIdGBzPp for ; Mon, 26 Oct 2009 06:47:24 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 4EF3628C27E for ; Mon, 26 Oct 2009 06:47:24 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n9QDlYLL001588 for ; Mon, 26 Oct 2009 08:47:35 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 08:46:07 -0500 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 08:46:06 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 26 Oct 2009 09:46:06 -0400 From: Desire Oulai To: "netext@ietf.org" Date: Mon, 26 Oct 2009 09:46:04 -0400 Thread-Topic: New Version Notification for draft-oulai-netext-opt-local-routing-01 Thread-Index: AcpWQlzxb+wWXPwnRSSVWYFiCA79ygAAA2Nw Message-ID: <7309FCBCAE981B43ABBE69B31C8D2139F669FE70@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Oct 2009 13:46:06.0986 (UTC) FILETIME=[AAFA96A0:01CA5642] Subject: [netext] FW: New Version Notification for draft-oulai-netext-opt-local-routing-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:47:25 -0000 Hi all, We've submitted an updated version of our Local Routing draft. Comments a= re welcomed! Desire -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: October-26-09 9:43 AM To: Desire Oulai Cc: Suresh Krishnan Subject: New Version Notification for draft-oulai-netext-opt-local-routing-= 01=20 A new version of I-D, draft-oulai-netext-opt-local-routing-01.txt has been = successfuly submitted by Desire Oulai and posted to the IETF repository. Filename: draft-oulai-netext-opt-local-routing Revision: 01 Title: Optimized Local Routing for PMIPv6 Creation_date: 2009-10-26 WG ID: Independent Submission Number_of_pages: 19 Abstract: Base Proxy Mobile IPv6 requires all communications to go through the local = mobility anchor. As this can be suboptimal, local routing has been defined= to allow mobile nodes attached to the same or different mobile access gate= ways to exchange traffic by using local forwarding or a direct tunnel betwe= en the gateways. This document proposes an initiation method and fast hand= over mechanisms for local routing. The solutions aim at reducing handover delay and packet loss. = =20 The IETF Secretariat. From Basavaraj.Patil@nokia.com Mon Oct 26 06:57:42 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AA33A6A6A for ; Mon, 26 Oct 2009 06:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 X9+AUICPjkXj for ; Mon, 26 Oct 2009 06:57:42 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id EBC6A3A67FD for ; Mon, 26 Oct 2009 06:57:41 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9QDvE1l026039 for ; Mon, 26 Oct 2009 08:57:54 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 15:57:47 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 15:57:26 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 26 Oct 2009 14:57:17 +0100 From: To: Date: Mon, 26 Oct 2009 14:57:19 +0100 Thread-Topic: Agenda plan for IETF76 Thread-Index: AcpVGa7BBMJR7oWTSHy8XPo/gqfdtw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FAAB54171A6C764E969E6B4CB3C2ADD20DD8FD4C85NOKEUMSG03mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Oct 2009 13:57:26.0744 (UTC) FILETIME=[40256D80:01CA5644] X-Nokia-AV: Clean Subject: [netext] Agenda plan for IETF76 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:57:42 -0000 --_000_FAAB54171A6C764E969E6B4CB3C2ADD20DD8FD4C85NOKEUMSG03mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, We have a 2 hour slot at IETF76 for the Netext meeting. We will use the 1st hour for discussion of the WG related topics (i.e local= ized routing, runtime LMA selection and bulk re-reg). We will also schedule about 30 mins to discuss flow mobility and inter-tech= HO features for PMIP6. As a result we will have only about 30 mins for discussing some or the more= relevant I-Ds for which requests have been sent. -Raj --_000_FAAB54171A6C764E969E6B4CB3C2ADD20DD8FD4C85NOKEUMSG03mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,
 
We have a 2 hour slot at IETF76 for the Netext meetin= g.
We will use the 1st hour for discussion of the WG rel= ated topics (i.e localized routing, runtime LMA selection and bulk re-reg).=
We will also schedule about 30 mins to discuss flow m= obility and inter-tech HO features for PMIP6.
As a result we will have only about 30 mins for discu= ssing some or the more relevant I-Ds for which requests have been sent.
 
-Raj
 
--_000_FAAB54171A6C764E969E6B4CB3C2ADD20DD8FD4C85NOKEUMSG03mgd_-- From root@core3.amsl.com Mon Oct 26 14:30:02 2009 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 48E1328C12D; Mon, 26 Oct 2009 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026213002.48E1328C12D@core3.amsl.com> Date: Mon, 26 Oct 2009 14:30:02 -0700 (PDT) Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : PMIPv6 Localized Routing Problem Statement Author(s) : M. Liebsch, et al. Filename : draft-ietf-netext-pmip6-lr-ps-01.txt Pages : 17 Date : 2009-10-26 Proxy Mobile IPv6 is the IETF standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip6-lr-ps-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-pmip6-lr-ps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26142550.I-D@ietf.org> --NextPart-- From Marco.Liebsch@nw.neclab.eu Mon Oct 26 14:41:32 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B093A67CC for ; Mon, 26 Oct 2009 14:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 J6OYOCHftA1C for ; Mon, 26 Oct 2009 14:41:30 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5140D28C0DB for ; Mon, 26 Oct 2009 14:41:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C486A2C019170 for ; Mon, 26 Oct 2009 22:41:43 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeXH0hGulcri for ; Mon, 26 Oct 2009 22:41:43 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id A61872C017B2F for ; Mon, 26 Oct 2009 22:41:38 +0100 (CET) Received: from [10.7.0.67] ([10.7.0.67]) by VENUS.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 22:41:38 +0100 Message-ID: <4AE61790.6040002@nw.neclab.eu> Date: Mon, 26 Oct 2009 22:41:36 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2009 21:41:38.0679 (UTC) FILETIME=[19317070:01CA5685] Subject: [netext] Localized Routing PS update X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:41:32 -0000 Folks, please find an update of the Localized Routing PS for the next meeting on the IETF drafts repository. So far, the update solely considers a revision of the IPv4 sections and includes a Change Notes section. We plan to update again just after the next IETF meeting, which will take further comments after clarification, such as from Glen and Mohana, into account. marco From Mohana.Jeyatharan@sg.panasonic.com Mon Oct 26 17:43:26 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9883A69D6 for ; Mon, 26 Oct 2009 17:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 Bex30UO0n+tF for ; Mon, 26 Oct 2009 17:43:19 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id A81143A69D3 for ; Mon, 26 Oct 2009 17:43:17 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id n9R0hF6e028684; Tue, 27 Oct 2009 09:43:15 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili03) with ESMTP id n9R0hGU19569; Tue, 27 Oct 2009 09:43:17 +0900 (JST) 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: Tue, 27 Oct 2009 08:38:57 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03A2C53E@pslexc01.psl.local> In-Reply-To: <068901ca563b$b91fd210$260ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt Thread-Index: AcpWOy3juSjK2CwmSKma8IsMcMyiHAAXZx2w From: "Mohana Jeyatharan" To: "Qin Wu" , Subject: Re: [netext] Comments on draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 00:43:26 -0000 Hi Qin, Thanks for your comments on this bitmap ID. Please see replies below. BR, Mohana > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Monday, October 26, 2009 8:56 PM > To: Mohana Jeyatharan; netext@ietf.org > Subject: Comments on draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt >=20 > Hi, Mohana: > I read your I-D about bitmap based PBU and would like to have some > comments as follows: > It seems to me the Bulk PBU using Bitmap is one robust header/packet > compression mechanism. > in other words, Bulk PBU can be further compressed or optimized using > Bitmap which saves > not only signaling but also packet size comparing with Bulk re- > registration mechanism described > in draft-premec-netlmm-bulk-re-registration-03. [Mohana] Yes, as you have mentioned the bitmap based approach is not only reducing number of signals but also a mechanism to reduce packet size. The mechanism in draft premec-netlmm-bulk-re-registration is for re-registration and de-registration of a group of MN's that belong to a certain group identified by a group identifier. However the bit map approach is a general approach that can be used with or without the group ID approach. Furthermore the bitmap approach is not restricted to bulk re-registration or bulk de-registration scenarios. It is more of bulk PBU... However I agree that for bulk re-registration of a group, the ideal way is to use a group ID to refresh the bindings. > But what I am still difficult to understand is in which situation or > scenario the Bitmap based > Bulk PBU will be utilized instead of Bulk re-registration ? >=20 > As you said in the I-D, The PBU originating from the MAG can be of > different types > such as initial registration PBU, handoff PBU, re-registration PBU and de- > registration PBU. > If the PBU originating from the MAG is initial registraion PBU, how can > you guarantee that > MAG initializing Bulk PBU can be attached by several Mobile nodes at the > same time > during initial registration for all these mobile nodes?=20 [Mohana] Bulk attachments to a MAG can take place in many practical scenarios. For example many users performing initial attachment at the same time. A densely populated urban area or train station etc, we may experience a bulk arrival of initial attachment messages. Without attachment > by several mobile > nodes simutanesouly, how does the MAG construct bitmap base Bulk PBU > packet?=20 [Mohana] Yes, the MAG needs to check its state and identify such multiple simultaneous registrations from numerous MNs and plan the PBU. The MAG should construct the bulk PBU using bitmaps to compress the bulk PBU. I think > the same applies to handoff PBU. [Mohana] The same for handoff. There can be cases where multiple MNs attach to certain MAG due to handoff. This can happen in real cases. I agree to some extent that the=20 >=20 > If the PUB originating from the MAG is re-registraion PBU, I am afraid > that the most efficient > or optimized way is to only carry Bulk Set ID or grouped ID in the re- > registration PBU, the > other mobility options is not necessary to be included, because LMA has > already maintained > binding for all these mobile nodes pertained to Bulk Set ID or grouped ID. > In this scenario, > if we still choose to use bitmap based PBU, more packet size will be > costed for bitmap option included. [Mohana] Well, I agree that for re-registration PBU, once all nodes have joined a group, the group ID is ideal way. Infact, in such cases we have mentioned that in section 3, that if multiple group IDs are used then probably the bit map option can be used in case there are multiple re-registration taking place for these group IDs at the same time. Here the bitmap approach is highlighted as interworking with group ID approach, which is ideal for re-registration PBus. > The same applies to de-registration PBU. [Mohana] For the de-registration case, if we are sure that all deregistration can be tied to one group, then group ID based approach is more of a neater way of doing it. What if random movement from the service area of MAG. Then the MN deregistration pattern cannot be grouped into a single group ID. In such a case, the bitmap approach can be used. However I agree that as mentioned in draft-premec-bulk-registration, if LMA uses blade architecture and all MNs are tied to groups, then deregistration only needs the MN group identifier. This is deterministic grouping. I think for random grouping bitmap way can be used. > Therefore the only two pratical scenarios occuring to me instead of using > Bulk re-registration are > a. Bitmap based Bulk PBU can be used when several MNs ask to be added into > Bulk re-registration set. > b. MAG sending a Bitmap based bulk PBU containing several Bulk Set IDs > created during the Bulk > re-registration and several other Individual mobile nodes who would like > to be added to one specific > bulk re-registration set. > In these two scenarios, bitmap based PBU can be used to compress packet > size of PBU that includes > several MNs who ask to join several bulk re-registration sets by avoiding > duplicate mobility options for different > MNs. >=20 > Am I right? [Mohana] Yes, you are absolutely right. Thanks for pointing out these two scenarios. Another scenario is where there is a LMA failure and the MAGs choose another LMA. Another scenario is bulk deregistration of MNs that do not belong to an MN group identifier as mentioned previously. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Mohana Jeyatharan" > To: > Sent: Friday, October 16, 2009 9:13 AM > Subject: [netext] FW: I-DAction:draft-jeyatharan-netext-pmip-bulkpbu- > bitmap-00.txt >=20 >=20 > Hi all, >=20 > This ID is highlighting a bulk PBU optimization approach using bit maps. >=20 > This approach can be used to send multiple PBU signals of any type in a > combined manner using bitmaps. This approach can work along with the MN > group ID approach as well as highlighted in this draft. >=20 > Please see. >=20 > Comments are appreciated. > Thanks. >=20 > BR, > Mohana > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Friday, October 16, 2009 9:00 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : Bulk PBU using Bitmaps > Author(s) : M. Jeyatharan, C. Ng > Filename : > draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00.txt > Pages : 8 > Date : 2009-10-15 >=20 > In Proxy Mobile Internet Protocol version 6 (PMIPv6), each mobile > node attached to a mobile access gateway (MAG) requires separate > signaling. This might result in excessive network signaling if there > a large number of mobile nodes attached to a MAG. In this draft we > outline a bulk PBU optimization approach based on bitmap, in order to > reduce the signaling load tied to numerous PBUs originating at the > same time. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-pmip-bulkpbu > -bitmap-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 >=20 > ------------------------------------------------------------------------ -- > ------ >=20 >=20 > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > From trungtm2909@gmail.com Mon Oct 26 17:59:03 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106413A688F for ; Mon, 26 Oct 2009 17:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 uxJYVqPZSDjv for ; Mon, 26 Oct 2009 17:59:02 -0700 (PDT) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id 392003A67F7 for ; Mon, 26 Oct 2009 17:59:02 -0700 (PDT) Received: by iwn40 with SMTP id 40so6589062iwn.32 for ; Mon, 26 Oct 2009 17:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=NAkbgtes/UAXDHexCR73yOl0hOTIVZ12YoLg4WkK1FA=; b=RJxSfjs7A8VqlEIW/+raBpbhhMzNEkw5PbCmcYYQVfVU9d3F9ptCol5ijr4dTMdR97 mEPuJpdg0vpinL34vuf+LMNJeVzOiKw6A2/f9NTLhDphEDInNch3U53yxJTL6o1fJLW8 60sHN9gCvkZf9qVInYTzlq985kAxbf4rDBdJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Fmj6J5f4BcEIWKDSRAft2V7EUwcX1D0ZwIVce+FuJhQO4nL4oLOzugAeWnz3THnS7L QzMkxan3I4Y1bWtCUqHemdUsqW4TAijRUhCrJ9HetYEj+H0udMN7rUAoECnS5gvcYsj1 soEs39qKw26k2d0FuVUEc2T+tsNqbz0J2PILw= MIME-Version: 1.0 Received: by 10.231.28.143 with SMTP id m15mr763221ibc.23.1256605151694; Mon, 26 Oct 2009 17:59:11 -0700 (PDT) Date: Tue, 27 Oct 2009 09:59:11 +0900 Message-ID: From: Tran Minh Trung To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [netext] New version of virtual interface draft (draft-trung-netext-virtual-interface-01) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 00:59:03 -0000 Hi all, We have updated new version of virtual interface draft at http://www.ietf.org/id/draft-trung-netext-virtual-interface-01.txt There have been several documents mentioning about virtual interface solution, but few of them discuss detail about how to change the PMIPv6 operations to support virtual interface. In this Internet draft we suggest the necessary changes in PMIPv6 operations to support virtual interface. This is just a primary version. We would like to improve it as an official document for PMIPv6 to support virtual interface. Your comments are always appreciated and welcomed. Regards, TrungTM ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Tue, Oct 27, 2009 at 8:57 AM Subject: New Version Notification for draft-trung-netext-virtual-interface-= 01 To: trungtm2909@gmail.com Cc: yonggeun.hong@gmail.com A new version of I-D, draft-trung-netext-virtual-interface-01.txt has been successfuly submitted by Tran Trung and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-trung-netext-virtual-interface Revision: =A0 =A0 =A0 =A001 Title: =A0 =A0 =A0 =A0 =A0 Virtual interface for supporting multihoming and inter technology handover Creation_date: =A0 2009-10-27 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 9 Abstract: The Proxy Mobile IPv6 supports a mobile node to perform inter- technology handover as well as multihoming. =A0However the inter- technology handover requires the new interface to use the same network prefix with the old one and all the IP address/prefix at the old interface are removed. =A0These requirements disable multihoming function which requires different network prefixes for different interfaces. =A0In this Internet draft we address this problem and suggest the necessary changes in PMIPv6 operations to support a mobile node to perform multihoming as well as seamless inter technology handover with virtual interface. The IETF Secretariat. --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132, Fax : +82-42-861-5404 From yuri.ismailov@ericsson.com Tue Oct 27 03:13:48 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4A23A6A07 for ; Tue, 27 Oct 2009 03:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.471 X-Spam-Level: X-Spam-Status: No, score=-5.471 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 eubug9n4-J+Y for ; Tue, 27 Oct 2009 03:13:47 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D38C23A68E8 for ; Tue, 27 Oct 2009 03:13:45 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-bf-4ae6c7d33d14 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 92.4D.24026.3D7C6EA4; Tue, 27 Oct 2009 11:13:40 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 11:13:38 +0100 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: Tue, 27 Oct 2009 11:13:37 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] New version of virtual interface draft(draft-trung-netext-virtual-interface-01) Thread-Index: AcpWoLcbywsWaI2GR3arBE1iZ9OkyAAS8cSw References: From: "Yuri Ismailov" To: "Tran Minh Trung" X-OriginalArrivalTime: 27 Oct 2009 10:13:38.0280 (UTC) FILETIME=[26922E80:01CA56EE] X-Brightmail-Tracker: AAAAAA== Cc: netext@ietf.org Subject: Re: [netext] New version of virtual interface draft(draft-trung-netext-virtual-interface-01) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 10:13:48 -0000 =20 Hi Trun, Read the draft, intresting piece of work. Was a bit puzzled about the following paragraph: "The mobile access gateway should include the flow information in the Proxy Binding Update sent to the local mobility anchor. To get the flow information, the mobile access gateway can collect information about the service identifier at layer 2 when a mobile node attach to it. We can refer to the draft [9] for more detail about the service identifier." Here are my questions 1. What is service identifier? I did not find any mentioning about it in = the referenced draft [9] 2. How does that relates to layer 2? Is that access specific? 3. Exchage of information about routing flows to a particular interface = in draft [9] is performed between MN and HA at layer 3. Do you mean that MN should send this info to MAG at layer 3? Regards Yuri -----Original Message----- From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Tran Minh Trung Sent: Tuesday, October 27, 2009 1:59 AM To: netext@ietf.org Subject: [netext] New version of virtual interface = draft(draft-trung-netext-virtual-interface-01) Hi all, We have updated new version of virtual interface draft at = http://www.ietf.org/id/draft-trung-netext-virtual-interface-01.txt There have been several documents mentioning about virtual interface = solution, but few of them discuss detail about how to change the PMIPv6 operations to support virtual interface. In this Internet draft we suggest the necessary changes in PMIPv6 = operations to support virtual interface. This is just a primary = version. We would like to improve it as an official document for PMIPv6 to support virtual interface. Your comments are always appreciated and welcomed. Regards, TrungTM ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Tue, Oct 27, 2009 at 8:57 AM Subject: New Version Notification for = draft-trung-netext-virtual-interface-01 To: trungtm2909@gmail.com Cc: yonggeun.hong@gmail.com A new version of I-D, draft-trung-netext-virtual-interface-01.txt has = been successfuly submitted by Tran Trung and posted to the IETF = repository. Filename: =A0 =A0 =A0 =A0draft-trung-netext-virtual-interface Revision: =A0 =A0 =A0 =A001 Title: =A0 =A0 =A0 =A0 =A0 Virtual interface for supporting multihoming = and inter technology handover Creation_date: =A0 2009-10-27 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 9 Abstract: The Proxy Mobile IPv6 supports a mobile node to perform inter- = technology handover as well as multihoming. =A0However the inter- = technology handover requires the new interface to use the same network = prefix with the old one and all the IP address/prefix at the old = interface are removed. =A0These requirements disable multihoming = function which requires different network prefixes for different = interfaces. =A0In this Internet draft we address this problem and = suggest the necessary changes in PMIPv6 operations to support a mobile = node to perform multihoming as well as seamless inter technology = handover with virtual interface. The IETF Secretariat. -- Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research = Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132, Fax : +82-42-861-5404 _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From trungtm2909@gmail.com Tue Oct 27 18:21:51 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5243A67B0 for ; Tue, 27 Oct 2009 18:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 vZZliJXfy6cp for ; Tue, 27 Oct 2009 18:21:50 -0700 (PDT) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id B3DB13A6860 for ; Tue, 27 Oct 2009 18:21:50 -0700 (PDT) Received: by iwn40 with SMTP id 40so274336iwn.32 for ; Tue, 27 Oct 2009 18:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D6pYq1mXDkmgWTGRiJjBN6HzHUsrciQZRMG5/btPtS4=; b=WuOsNc7p/27N9mColMgjtjIqu8Am7k4jpxrn2UAaFgCKX8RBpqIkdRiLejZex7USbd GA9S1/O07nhbxNDw9lBvDItht+tZz8O5kIO3vb3Bfvph/in5IDrjkzuneKx3p+kXx5Mf 7qDgW/YR0sV21FSNs/oo7+aPthFfDxqbkME5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gKxaREgazwFcH4E3ZYEXBp6wtZTBtjiMKXjPzCsbmtyfGUhm7dxbWDm3idr1aQG0kq 5d7RBNhmJ8JbQsRHvFCqdt6cju9IO+rKI0zvsVKJzhV6ge06owslgh60M4inWCKReyHH qjxXJTRw0AzvE2ERRqAGvYotvj60hGnlcglNQ= MIME-Version: 1.0 Received: by 10.231.153.69 with SMTP id j5mr1490677ibw.33.1256692919414; Tue, 27 Oct 2009 18:21:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Oct 2009 10:21:59 +0900 Message-ID: From: Tran Minh Trung To: Yuri Ismailov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netext@ietf.org Subject: Re: [netext] New version of virtual interface draft(draft-trung-netext-virtual-interface-01) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 01:21:51 -0000 Thank Yuri! The following are our answers to your questions: > 1. What is service identifier? I did not find any mentioning about it in = the referenced draft [9] Ans.: Service identifier is a string used to identify the requested service. You can refer to the RFC5149, section 3. I should change the reference from [9] -> [2] > 2. How does that relates to layer 2? Is that access specific? Ans.: When the MN attach with new MAG via layer 2, it can indicate access specific to MAG. > 3. Exchage of information about routing flows to a particular interface i= n draft [9] is performed between MN and HA at layer 3. > Do you mean that MN should send this info to MAG at layer 3? Ans.: Since the involvement of the MN at layer 3 should be minimized, the MAG can check which flows will be sent via new attachment when MAG identifies the mobile node and acquire its MN-Identifier. However the layer 2 operation is out of scope so we are thinking about layer 3 solutions without any modifications and involvement of the MN. It is nice if you have some hints or ideas about that. Regards, TrungTM On Tue, Oct 27, 2009 at 7:13 PM, Yuri Ismailov wrote: > > Hi Trun, > Read the draft, intresting piece of work. > > Was a bit puzzled about the following paragraph: > > "The mobile access gateway should include the flow information in the > Proxy Binding Update sent to the local mobility anchor. =A0To get the > flow information, the mobile access gateway can collect information > about the service identifier at layer 2 when a mobile node attach to > it. =A0We can refer to the draft [9] for more detail about the service > identifier." > > Here are my questions > 1. What is service identifier? I did not find any mentioning about it in = the referenced draft [9] > 2. How does that relates to layer 2? Is that access specific? > 3. Exchage of information about routing flows to a particular interface i= n draft [9] is performed between MN and HA at layer 3. > Do you mean that MN should send this info to MAG at layer 3? > > Regards > Yuri > > > > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf = Of Tran Minh Trung > Sent: Tuesday, October 27, 2009 1:59 AM > To: netext@ietf.org > Subject: [netext] New version of virtual interface draft(draft-trung-nete= xt-virtual-interface-01) > > Hi all, > > We have updated new version of virtual interface draft at http://www.ietf= .org/id/draft-trung-netext-virtual-interface-01.txt > > There have been several documents mentioning about virtual interface solu= tion, but few of them discuss detail about how to change the > PMIPv6 operations to support virtual interface. > > In this Internet draft we suggest the necessary changes in PMIPv6 operati= ons to support virtual interface. =A0This is just a primary version. We wou= ld like to improve it as an official document for > PMIPv6 to support virtual interface. > > Your comments are always appreciated and welcomed. > > Regards, > TrungTM > > > > ---------- Forwarded message ---------- > From: IETF I-D Submission Tool > Date: Tue, Oct 27, 2009 at 8:57 AM > Subject: New Version Notification for draft-trung-netext-virtual-interfac= e-01 > To: trungtm2909@gmail.com > Cc: yonggeun.hong@gmail.com > > > > A new version of I-D, draft-trung-netext-virtual-interface-01.txt has bee= n successfuly submitted by Tran Trung and posted to the IETF repository. > > Filename: =A0 =A0 =A0 =A0draft-trung-netext-virtual-interface > Revision: =A0 =A0 =A0 =A001 > Title: =A0 =A0 =A0 =A0 =A0 Virtual interface for supporting multihoming a= nd inter technology handover > Creation_date: =A0 2009-10-27 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 9 > > Abstract: > The Proxy Mobile IPv6 supports a mobile node to perform inter- technology= handover as well as multihoming. =A0However the inter- technology handover= requires the new interface to use the same network prefix with the old one= and all the IP address/prefix at the old interface are removed. =A0These r= equirements disable multihoming function which requires different network p= refixes for different interfaces. =A0In this Internet draft we address this= problem and suggest the necessary changes in PMIPv6 operations to support = a mobile node to perform multihoming as well as seamless inter technology h= andover with virtual interface. > > > > The IETF Secretariat. > > > > > > -- > Ph.D., Senior Member > Electronics and Telecommunications Research Institute Standards Research = Center > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA > Tel : +82-42-860-1132, =A0 Fax : +82-42-861-5404 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --=20 Ph.D., Senior Member Electronics and Telecommunications Research Institute Standards Research Center 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-1132, Fax : +82-42-861-5404 From sgundave@cisco.com Tue Oct 27 20:34:24 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32EA3A68E4 for ; Tue, 27 Oct 2009 20:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 mbRqHLHAtCDE for ; Tue, 27 Oct 2009 20:34:23 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6227228C151 for ; Tue, 27 Oct 2009 20:34:23 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcFAA9Y50qrRN+J/2dsb2JhbACQFQGxJJhZhD8EgV8 X-IronPort-AV: E=Sophos;i="4.44,637,1249257600"; d="scan'208";a="262498070" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 28 Oct 2009 03:34:38 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n9S3YcTc014508; Wed, 28 Oct 2009 03:34:38 GMT Date: Tue, 27 Oct 2009 20:34:38 -0700 (PDT) From: Sri Gundavelli To: Jari Arkko Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: netext@ietf.org Subject: Re: [netext] NETEXT2 BOF conclusion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 03:34:25 -0000 Hi Jari, Thanks for the mail presenting your views on how to move forward. Few comments below. > > I also personally believe that #2 and #3 are functionally > similar enough that there's no requirement that forces us to > pick #3. > This would certainly be a key point of debate. Its unfortunate that few folks who are in the client-mobility camp managed to make it appear option#2 and option#3 are almost the same and hence go for client-based mobility protocols. But, if we look at the details and place them side-by-side, however I look at it, to the point of hypnotising myself to be part of a client mobility camp, I cannot convince myself that option #2 and option #3 are equal. To me and having been involved in Mobile IPv6 development and having some understanding of both the protocols, I'm not able equate the complexities involved in each of those appraoches. Option-2: focussing on MIPv6 stack requirements: a.) Implementation of MIPv6, IKEv2, DSMIP6, MCOA specs and on million platforms. b.) Requires the host to be involved in mobility management, tunnel management. c.) Requires significant amount of system resources, CPU, Memory ..etc d.) And we have one or two vendors who ship those stacks. With no industry experience on the client stack, or with close to one or two serious interoperability attempts and years back. Option-3: identifying the minimal needed signaling giving the ability for the stack to deliver certain handoff hints to the affect: a.) a given attachment is a new interface attachment and these are the interface properties b.) a given attachment is due to a handoff between IF-1 and IF-2 c.) a given flow with the following flow parameters, should be moved from IF-1 to IF-2. These minor data elements are the attachment preferences, gives the network the ability to determine if the given attachment is due to multi-homing or due to inter-technology handoff and to perform flow management. Jari, With Proxy Mobile IPv6, we practically built 90% of the features that client-based mobility can offer and with zero changes to the host. Its the basic design choice of client complexity that to most part kept the Mobile IP technology as a failed protocol with no deployments or commercial success. Proxy Mobile IPv6 atleast has a ray of hope to be deployed. These two features flow mobility and inter-tech handoffs (with client expressed preference), will give the protocol the completeness and for the valid reasons that these attach preferences have to come from the host and not from the network, we need the host to deliver those hints. But, moving to client-based mobility for fixing this gap wont help this protocol, but will certainly keep the client-based mobility in business, the last hope. Now, focussing on option-1, building virtualized interface, hiding the physical interface variants, does give the ability to perform inter-tech handoffs and multi-homing, as supported by RFC5213. But, it wont give the needed hints from the client and does not allow us to build flow mobility support. But, either way, this requires us to specify how host stack can achieve that and it certainly helps if we can move that work forward while we are discussing this. Bottom line, I believe, there are enough folks who wants to use network-based mobility technology and they should have the choice, however difficult it may be for folks in the client-based mobility camp. My humble 2c. Regards Sri ----- Original Message ---- > From: Jari Arkko > To: netext at ietf.org > Sent: Wed, October 21, 2009 4:29:00 PM > Subject: [netext] NETEXT2 BOF conclusion > > I have been trying to come up with a way forward on this, but its hard. > To recap, there are a few different technical possibilities for > multi-interface mobility: > > 1) Link layer hides interface variants behind one logical interface. For > instance, an IP stack does not see the change from GSM to UMTS radio or > 802.11b to 802.11g; its handled as a part of the link layer. Such link > layer operations need to be supported both by the host and the network. > This approach has the minimum impacts on IP stack, but requires > specification of the link layer mechanisms across the used interfaces. > > 2) Different interfaces are handled via existing host-based mobility > mechanisms (Mobile IPv6, MOBIKE, HIP, application layer). Within one > interface the link layer handles mobility, possibly using Proxy MIP > internally. Both the host and the network need to support the host-based > mobility mechanism, but the link layer does not have to aware of the > other interfaces in any way. > > 3) We extend Proxy MIP with capabilities to handle cross-interface > handovers. This is similar to approach #1, but the signaling messages > are at the IP layer. The benefit is that this could be used across > different types of link layers even if they do not support handovers. > The downside is that just as with approach #2, the IP stack has to be > capable of these operations. > > The big argument we have been stuck with since San Francisco is between > #2 and #3. One group believes that existing mechanisms are sufficient, > and they are -- it is indeed possible to do this. Another group believes > that they need a different solution based on Proxy MIP. Such a solution > is also of course possible. But we've made very little headway in > resolving the question on what should be done. In particular, we've not > been able to describe very well why some technical reasons would dictate > one or the other solution. I believe that is likely because they are > really very similar solutions. > > At this point I do not believe we have consensus to go forward. We left > the BOF with the idea that requirements work would solve this issue. If > I'm right the solutions really are very similar, this work may not be > able to resolve the conflict, and it would take a long time. I think it > would actually serve as better if we were to decide now, as opposed to > pretending that more details will make the decision easier. > > With this in mind, I have a proposal for a way forward. Given that I do > not see consensus for approach #3, I do not think we can go ahead with > that. I also personally believe that #2 and #3 are functionally similar > enough that there's no requirement that forces us to pick #3. In > addition, approach makes mobility end-to-end between the host and a > network node; approach #3 ties the use of mobility to a particular link. > If the router on that link does not support the mobility mechanism, > mobility service is not possible. I think it would be architecturally > better to separate access and mobility. > > However, I would like to move forward with a different work item. The > IETF has never really explored approach #1, even if it is commonly used. > Of course, the IETF's role is not to design these link layer mechanisms, > but I believe it would be valuable for the IETF to publish an > informational document on considerations for building such mechanisms. > This document would talk about the requirements that the mechanisms must > fulfill in order for IP to work correctly, when such mechanisms are > recommended and when not, what their advantages and downsides are, what > happens if MTUs or routers differ, and so on. At the same time this > document would describe the "virtual link" model that some people have > been using in the context of Proxy MIP. The idea is to add this work > to the NETEXT WG charter. > > I realize this does not make everyone happy, but I'm not sure there > is an outcome that does. What we lose by not doing solution 3 is > a design that that simultaneously allows something to be done > in a link-layer agnostic manner _and_ employs PMIP as a part of the > solution. > > Thoughts? > > Jari From karagian@cs.utwente.nl Wed Oct 28 00:58:18 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83EB3A68DB for ; Wed, 28 Oct 2009 00:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 zJ2QqR2YmNu3 for ; Wed, 28 Oct 2009 00:58:18 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 7D2F13A6881 for ; Wed, 28 Oct 2009 00:58:18 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id n9S7wUW5011588; Wed, 28 Oct 2009 08:58:31 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 28 Oct 2009 07:58:30 +0000 To: netext@ietf.org Date: Wed, 28 Oct 2009 07:58:30 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 28 Oct 2009 08:58:33 +0100 (MET) Cc: "ryuji@jp.toyota-itc.com" , "john@jbkenney.com" Subject: [netext] updated draft on requirements imposed by traffic safety applications on network/transport layers X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 07:58:19 -0000 Hi all An updated version of an Internet draft has been submitted to the IETF that describes a number of communication performance requirements that are imposed by traffic safety applications on a network layer, see: http://www.ietf.org/id/draft-karagiannis-traffic-safety-requirements-01.txt These traffic safety applications and requirements have been derived by the USA VSC (Vehicular Safety Communications)and VSC-A (VSC-Applications) projects and by the European Car to Car Communication Consortium (C2C-CC) and the ETSI TC ITS standardization body. The goal of this document is to stimulate the discussion on judging whether these performance requirements could or could not be supported (currently and in the future) by IP based network solutions. The goal of this document is to stimulate the discussion on judging whether these performance requirements could or could not be supported (currently and in the future) by IP based network and transport solutions. Best regards, Georgios From jari.arkko@piuha.net Wed Oct 28 03:25:47 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BCF03A679C for ; Wed, 28 Oct 2009 03:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 s0zpN-6cKOkz for ; Wed, 28 Oct 2009 03:25:46 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 3B7273A6875 for ; Wed, 28 Oct 2009 03:25:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 12EA9D497E; Wed, 28 Oct 2009 12:26:01 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gGO7hi81WgZ; Wed, 28 Oct 2009 12:26:00 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9CB3BD4900; Wed, 28 Oct 2009 12:26:00 +0200 (EET) Message-ID: <4AE81C38.3020504@piuha.net> Date: Wed, 28 Oct 2009 12:26:00 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mohana Jeyatharan References: <5F09D220B62F79418461A978CA0921BD03A2C109@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD03A2C109@pslexc01.psl.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] NETEXT2 BOF conclusion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 10:25:47 -0000 Mohana Jeyatharan wrote: > Hello Jari, > > Thanks for the mail. > > The informational document based on approach 1, is it going to analyze > or identify requirements needed to perform inter RAT handoff and > multihoming(flow mobility) etc for PMIP? Is that the goal of the > document? > Maybe. My idea of the scope was to provide guidance for creating link layers that hide movements. What the requirements are so that IP layer is not affected, what are the difficult points, etc. I think PMIP virtual interfaces are one example of these link layer mechanisms. But I am not suggesting a L3 solution for PMIP multihoming to be within the scope. Jari From Basavaraj.Patil@nokia.com Wed Oct 28 15:43:42 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDEFF28C10B for ; Wed, 28 Oct 2009 15:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 gktNz8DFhm5N for ; Wed, 28 Oct 2009 15:43:41 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 77D5628C104 for ; Wed, 28 Oct 2009 15:43:41 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9SMhqFH020323 for ; Thu, 29 Oct 2009 00:43:53 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 00:43:48 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 00:43:43 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 00:43:39 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 28 Oct 2009 23:43:37 +0100 From: To: Date: Wed, 28 Oct 2009 23:43:47 +0100 Thread-Topic: Agenda for meeting at IETF76 Thread-Index: AcpYIBxFT4TMMVQBUkiJkH9vIK5W0w== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Oct 2009 22:43:39.0352 (UTC) FILETIME=[17B69580:01CA5820] X-Nokia-AV: Clean Subject: [netext] Agenda for meeting at IETF76 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 22:43:42 -0000 Note: Changes to the agenda are still possible Agenda: IETF76 Network-Based Mobility Extensions (netext) Wednesday, Nov 11th 1300-1500 Afternoon Session I Chairs: Basavaraj Patil Rajeev Koodli ------------------------------------------------------- 1. Bluesheets, Notes takers, Jabber scribe and agenda review 5 Mins 2. WG status update Chairs 5 Mins Currently approved WG items: 3. Runtime LMA Assignment Support for Proxy Mobile IPv6 I-D: draft-ietf-netext-redirect-00 15 Mins J. Korhonen 4. Bulk Re-registration for Proxy Mobile IPv6 I-D: draft-premec-netlmm-bulk-re-registration-03 10 Mins TBD 5. Localized routing - PS and solutions discussion 25 Mins PS I-D: draft-ietf-netext-pmip6-lr-ps-01.txt - Solution I-Ds: 1. draft-oulai-netext-opt-local-routing-01 2. draft-loureiro-netext-pmipv6-ro-01.txt 3. draft-wu-netext-local-ro-04.txt 4. draft-koodli-netext-local-forwarding-01.txt - Conclusions and next steps for solution Flow Mobility and Inter-technology handovers (30 mins): - LMA-MAG extensions to support FM and ITHO 10 Mins - MN-MAG approaches to enable FM and ITHO 10 Mins - Discuss Jari's proposal on moving forward w.r.t the flowmob and ITHO features =20 http://www.ietf.org/mail-archive/web/netext/current/msg00881.html - Conclusions to be drawn and consensus sought on the way forward Chairs 10 Mins New proposals (30 Mins): - Multihoming extensions for Proxy Mobile IPv6 Carlos J. I-D 5 mins - Service Flow Identifier in Proxy Mobile IPv6 Hui Deng - draft-hui-netext-service-flow-identifier-01.txt 5 Mins - Bulk PBU using Bitmaps Mohana J. - draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00 5 Mins - Virtual interface for supporting multihoming and inter technology handove= r Tranh M. Trung - draft-trung-netext-virtual-interface-01 5 Mins - Reflector Extension for Route Optimization Agent Xiansong Cui draft-cui-netext-route-optimization-agent-ext-01.txt 5 Mins - Bechect S./Frank Xia - Differentiated Services Support for Proxy Mobile IPv6 From Mohana.Jeyatharan@sg.panasonic.com Wed Oct 28 17:40:03 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1941A3A692E for ; Wed, 28 Oct 2009 17:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 xD6Y2B1f0Q+e for ; Wed, 28 Oct 2009 17:40:02 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 078013A6973 for ; Wed, 28 Oct 2009 17:40:01 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id n9T0eGl1001114; Thu, 29 Oct 2009 09:40:16 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id n9T0eFG27868; Thu, 29 Oct 2009 09:40:15 +0900 (JST) 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: Thu, 29 Oct 2009 08:35:55 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03A2CB00@pslexc01.psl.local> In-Reply-To: <4AE81C38.3020504@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] NETEXT2 BOF conclusion Thread-Index: AcpXuHS0zigUAKAwTPmTNLmZPXxj1wAdqnZQ From: "Mohana Jeyatharan" To: "Jari Arkko" Cc: netext@ietf.org Subject: Re: [netext] NETEXT2 BOF conclusion X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 00:40:03 -0000 Hi Jari, Thanks for your reply. I understand your intention is to explore whether inter RAT handoff and multhoming in PMIP can be done in L2 and identify the requirements. Also explore whether we can do it without any changes to L3. Consider virtual interfaces or any other minor host fixes to achieve the goal. =20 Also as many other folks feel, I too think that aproach 3 is also a neater way of doing this and use the MN-MAG interface to indicate MN state to the MAG. This is different from appraoch 2 because the MN is not doing mobility signaling as in approach 2. It is just indicating some state/prefernce information for inter RAT handoff and flow mobility. Thanks. BR, Mohana =20 > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Jari Arkko > Sent: Wednesday, October 28, 2009 6:26 PM > To: Mohana Jeyatharan > Cc: netext@ietf.org > Subject: Re: [netext] NETEXT2 BOF conclusion >=20 > Mohana Jeyatharan wrote: > > Hello Jari, > > > > Thanks for the mail. > > > > The informational document based on approach 1, is it going to analyze > > or identify requirements needed to perform inter RAT handoff and > > multihoming(flow mobility) etc for PMIP? Is that the goal of the > > document? > > >=20 > Maybe. My idea of the scope was to provide guidance for creating link > layers that hide movements. What the requirements are so that IP layer > is not affected, what are the difficult points, etc. I think PMIP > virtual interfaces are one example of these link layer mechanisms. But I > am not suggesting a L3 solution for PMIP multihoming to be within the > scope. >=20 > Jari >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From maxpassion@gmail.com Wed Oct 28 19:57:06 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8C728C0F8 for ; Wed, 28 Oct 2009 19:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 xm-BiTYN4nTk for ; Wed, 28 Oct 2009 19:57:05 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 75A053A67B0 for ; Wed, 28 Oct 2009 19:57:05 -0700 (PDT) Received: by pzk42 with SMTP id 42so1120584pzk.31 for ; Wed, 28 Oct 2009 19:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zRF7f4vtkNrEIituiF0atiSnVvcBGpZpWo0WwVaj+QI=; b=VfFOB+xw10WxPqwUkHCdErHB1iMsCCTzMreCu/1rvHmj8SIC0AHL2rR7h+HBSRpPti 6vIQ2Hop0nOrg8gG83ygaR25BwU24QNWy3tyI6w9O6B7HvnzwXgtMFoklJVrutISmiht qHqZV4o2mIgPngV+tBGtyNWHG24Xj8HwMNiWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cERiD8i4fUc9FdnsRnIVKskiHBJEYAsiniPAoaykpauPIWw5QNZI2b+HCfCOjXfJZN QWrvMTWipQnPhw+vgIwt0aPvps38ZKR20HHNjVoUxk7wFxmUa43FtTSQPstk+MTS2FDs ZWzNkLVp4pOwh2ZNfrwz9Ff28E3Qx+MXqjePI= MIME-Version: 1.0 Received: by 10.142.75.15 with SMTP id x15mr1507642wfa.152.1256785038774; Wed, 28 Oct 2009 19:57:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Oct 2009 10:57:18 +0800 Message-ID: <25e1aaa40910281957w602e442fo5c9ad033f5ee9a4d@mail.gmail.com> From: liu dapeng To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org Subject: Re: [netext] Agenda for meeting at IETF76 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 02:57:06 -0000 Hi Raj, There is one additional draft: draft-liu-netext-singnaling-data-separation-00.txt (belongs to New proposals) that we would like to present (by Hui Deng, 5 Mins). Would it possible that you kindly help to arrange a time slot? Thanks a lot. BR, Dapeng Liu 2009/10/29, Basavaraj.Patil@nokia.com : > > Note: Changes to the agenda are still possible > > > Agenda: > > IETF76 > Network-Based Mobility Extensions (netext) > Wednesday, Nov 11th 1300-1500 Afternoon Session I > > Chairs: Basavaraj Patil > Rajeev Koodli > > ------------------------------------------------------- > > 1. Bluesheets, Notes takers, Jabber scribe and agenda review 5 Mins > > 2. WG status update Chairs 5 Mins > > Currently approved WG items: > > 3. Runtime LMA Assignment Support for Proxy Mobile IPv6 > I-D: draft-ietf-netext-redirect-00 15 Mins J. Korhonen > > 4. Bulk Re-registration for Proxy Mobile IPv6 > I-D: draft-premec-netlmm-bulk-re-registration-03 10 Mins TBD > > 5. Localized routing - PS and solutions discussion 25 Mins > PS I-D: draft-ietf-netext-pmip6-lr-ps-01.txt > - Solution I-Ds: > 1. draft-oulai-netext-opt-local-routing-01 > 2. draft-loureiro-netext-pmipv6-ro-01.txt > 3. draft-wu-netext-local-ro-04.txt > 4. draft-koodli-netext-local-forwarding-01.txt > - Conclusions and next steps for solution > > Flow Mobility and Inter-technology handovers (30 mins): > > - LMA-MAG extensions to support FM and ITHO 10 Mins > - MN-MAG approaches to enable FM and ITHO 10 Mins > - Discuss Jari's proposal on moving forward w.r.t the flowmob and ITHO > features > http://www.ietf.org/mail-archive/web/netext/current/msg00881.html > > - Conclusions to be drawn and consensus sought on the way forward > Chairs 10 Mins > > New proposals (30 Mins): > > - Multihoming extensions for Proxy Mobile IPv6 > Carlos J. I-D 5 mins > > - Service Flow Identifier in Proxy Mobile IPv6 > Hui Deng - draft-hui-netext-service-flow-identifier-01.txt 5 Mins > > - Bulk PBU using Bitmaps > Mohana J. - draft-jeyatharan-netext-pmip-bulkpbu-bitmap-00 5 Mins > > - Virtual interface for supporting multihoming and inter technology handover > Tranh M. Trung - draft-trung-netext-virtual-interface-01 5 Mins > > - Reflector Extension for Route Optimization Agent > Xiansong Cui draft-cui-netext-route-optimization-agent-ext-01.txt 5 Mins > > - Bechect S./Frank Xia - Differentiated Services Support for Proxy > Mobile IPv6 > > > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From rkoodli@starentnetworks.com Thu Oct 29 08:52:16 2009 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AEA93A682A for ; Thu, 29 Oct 2009 08:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 j9Zk4bkAu26O for ; Thu, 29 Oct 2009 08:52:15 -0700 (PDT) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id B86B03A6835 for ; Thu, 29 Oct 2009 08:52:15 -0700 (PDT) X-ASG-Debug-ID: 1256831543-1f7600370008-XzWF0g X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id 64C67EFC995 for ; Thu, 29 Oct 2009 11:52:24 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id Kd5M5kulb9221Yiu for ; Thu, 29 Oct 2009 11:52:24 -0400 (EDT) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Oct 2009 11:34:39 -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 X-ASG-Orig-Subj: RE: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc Date: Thu, 29 Oct 2009 11:33:02 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266609382B31@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc Thread-Index: AcpNXm8lPeSrMXWzQC+0mCg6gjMF5ALTqsHP References: <4D35478224365146822AE9E3AD4A26660CAC545D@exchtewks3.starentnetworks.com> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 29 Oct 2009 15:34:39.0617 (UTC) FILETIME=[540C7710:01CA58AD] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1256831544 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com Subject: Re: [netext] Consensus call to adopt ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 15:52:16 -0000 =20 Hello, =20 based on the input received on the ML, the adoption of the ID as WG = document is confirmed. =20 Authors: please submit a 00 version once the ID gate opens. =20 Regards, =20 -Rajeev =20 ________________________________ From: netext-bounces@ietf.org on behalf of Koodli, Rajeev Sent: Wed 10/14/2009 11:02 PM To: netext@ietf.org Subject: [netext] Consensus call to adopt = ID:draft-premec-netlmm-bulk-re-registration-03.txt as WG doc =20 Hello, =20 One of the Netext WG items is: =20 Dec 2009 Submit Bulk Refresh to IESG for publication as a Proposed = Standard RFC=20 =20 At the last IETF meeting, there was agreement to use = draft-premec-netlmm-bulk-re-registration-02.txt as the baseline document = for the above item. =20 This document has been revised to version 03 in which the Group ID = proposal outlined in = http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-01 = has been merged based on author's agreement.=20 =20 This is a consensus call for adoption of = http://tools.ietf.org/html/draft-premec-netlmm-bulk-re-registration-03 = as the WG document.=20 =20 Please respond by October 21. =20 Thanks, =20 -Rajeev =20 =20