From kaaspetersen@yahoo.dk Wed Apr 1 00:31:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F443A67A5 for ; Wed, 1 Apr 2009 00:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 vYjHsuG4Pz8E for ; Wed, 1 Apr 2009 00:31:00 -0700 (PDT) Received: from web27801.mail.ukl.yahoo.com (web27801.mail.ukl.yahoo.com [217.146.182.6]) by core3.amsl.com (Postfix) with SMTP id 58DD33A6B54 for ; Wed, 1 Apr 2009 00:31:00 -0700 (PDT) Received: (qmail 71654 invoked by uid 60001); 1 Apr 2009 07:31:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1238571119; bh=a7H6/qKEmNV3IWwaylJ9cngyFNIakUXG/uUzx+/phYw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XQNIzyFpAbed+V6xibFAuayddHcOuiR96+ntuZV3HgyJZGejvU2xVUxuG3z+lY+gvDrdi7caoibD4WBUPsH5qgEHNIm1T+0HvmbkoPyIJ3jSsOlDrdCCstQLNReS3m3n2X/IqlPKDHJ0Gv4Zrv88ZqBa50hAoaFPnvQqCOG6MUE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=X8xvf/1JNH4RIsXHVprF4eTV4OEKQxehOiXkfX8sQN0vMDvE1/YH7daO74F6XOhk0dJ8Xth01OAvulaUmbdcd8RVpBJOkS3MmJ6AaEqBbqKJYNrmk809Q1ffJKPepRpMqzfwZpM3+XxIgI7sCFkfCoQ3m+URfBzM029WG6N5luU=; Message-ID: <647825.69513.qm@web27801.mail.ukl.yahoo.com> X-YMail-OSG: uqMk.7IVM1ntVkz7KS95tFst_WhXaSSGc60xP_z505qAgRlntQZoRa8UcnIHIabf.NMvsfGcWaEVgDzj1i_qcFvrLx.oYMlO.1mg.ZlAuEqXMu.A3Hccrfv4AUbAp3Aa3Cm0hxKRpKtm.05P6Qaoef57eEJJn42HUnzgubRL.H8wKnqQRWWTGlfFARDaQRWj1dFlP_xZzquywpZqWwq7R4DDlkjiwnNDkSlMTLi4EZ92JROcT.Eacc7eQv9m30dwGVr7sUjx_7tN6XqxoMRSvChRcYRICTl7rF1.P.lfXNJzWlOARmayBN7OmGmHd.UvrCWzWlT9xtNPsfdfF0k1ckpSbALwoj7q2y5zcA0- Received: from [193.15.240.60] by web27801.mail.ukl.yahoo.com via HTTP; Wed, 01 Apr 2009 07:31:59 GMT X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1 Date: Wed, 1 Apr 2009 07:31:59 +0000 (GMT) From: Christian Kaas-Petersen To: mext@ietf.org, Behcet Sarikaya MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Charles E. Perkins" , Domagoj Premec Subject: Re: [MEXT] (no subject) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 07:31:01 -0000 The C flag, as defined in draft-devarapalli, means the home agent shall do various processing, but shall not create an entry in the binding cache. However, draft-premec requires an entry in the binding cache to be created in order to tunnel IPv4 packets. So, either the semantics of the C flag shall be extended or another flag shall be defined. What is your suggestion? Christian --- Den tirs 31/3/09 skrev Behcet Sarikaya : > Fra: Behcet Sarikaya > Emne: [MEXT] (no subject) > Til: mext@ietf.org > Cc: "Charles E. Perkins" , "Domagoj Premec" > Dato: tirsdag 31. marts 2009 22.19 > Hello all, > =A0 Regarding > draft-premec-mext-extended-home-link-01.txt, I noticed that > this draft is about what I asked Charlie last week during > his presentation, i.e. sending BU at the home link for > something other than deregistration. As the draft says in > Sec. 4.1: > When the MN returns home to an IPv6-only home network, > the MN sends ... BU > =A0 I agree with Vijay that a flag must be defined > and set for this purpose because normally this is not > allowed and HA must probably reject such a BU.=A0A flag > to this end has already been suggested in > draft-devarapalli-mext-mipv6-home-link-01 as C flag. > =A0 > Regards, > =A0 > Behcet >=20 >=20 > =20 > -----Inline-vedh=E6ftet fil f=F8lger----- >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig= gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From behcetsarikaya@yahoo.com Wed Apr 1 07:38:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E084728C0F2 for ; Wed, 1 Apr 2009 07:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 7eFQYt9h3lCT for ; Wed, 1 Apr 2009 07:38:06 -0700 (PDT) Received: from n70.bullet.mail.sp1.yahoo.com (n70.bullet.mail.sp1.yahoo.com [98.136.44.38]) by core3.amsl.com (Postfix) with SMTP id F201C28C0D6 for ; Wed, 1 Apr 2009 07:38:05 -0700 (PDT) Received: from [216.252.122.217] by n70.bullet.mail.sp1.yahoo.com with NNFMP; 01 Apr 2009 14:39:06 -0000 Received: from [67.195.9.81] by t2.bullet.sp1.yahoo.com with NNFMP; 01 Apr 2009 14:39:06 -0000 Received: from [67.195.9.108] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 01 Apr 2009 14:39:06 -0000 Received: from [127.0.0.1] by omp112.mail.gq1.yahoo.com with NNFMP; 01 Apr 2009 14:39:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 332236.91181.bm@omp112.mail.gq1.yahoo.com Received: (qmail 69799 invoked by uid 60001); 1 Apr 2009 14:39:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238596745; bh=3KasBTQV+YkgeOgz0RsHbpVLlDg2vENePkKpt/n8XqY=; 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=16Ntr1FRcO8WrqTptA6OwZdjSvDjpSajx48qmMExu/J2XfO666N5sGtLGRC670a9bH5wGHu8CII+Pz2EddEP6mryl8TpsbCnXroZMKVIRtAnkdmHNSe4S+dYpk8gAh+a7846TqxRKS4FYrrVyH8O8b1ann99j3OI1HzMCsFy/rU= 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=vziv1MKILyJr6nrz29bRpJmkr94lFJwFo9UjgagQPlGAWEF9tCaJaOsOw0zFVEqGzNfrMGeqJBDbKzpphVRTeN4VeGbhC5pA2UVS20xIl1kX/9L/t0QWusnpzDpe0Am+oseih9Vybwu8WzBRmfKsI71J6jL7HZzgEMI+0ZlgS9I=; Message-ID: <861701.32876.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: GSd2ZpUVM1k4ED_vdHgxIAoqtBnrmEhXoajRs2xNKFmYFS29.I9RM2euQmXTvpULSGsJaDagxUXxXG4cwhqm.KfwI6mMLYMR42U85aVjFLUkHiwF_0If22CE8zzGEEPXkPJWsByWE4k9il4bRj1D2PGTWqtDoDi4GWRcEcd7AWQNT8IEVeChxuuRF4mSKfG7n82YxZrq.kNpEJ_mhZkTYdku_WtK3g3sYbqWuCZXyrNPx1qO6AhUfCcCjDv87No6ExPwvLRaTmoVAS.Ko0j6_rQHsdtFCbBq._LJuLIIAp_oWcIlnPG2hhOjA5Rz4DbsE9rh Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Wed, 01 Apr 2009 07:39:05 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <647825.69513.qm@web27801.mail.ukl.yahoo.com> Date: Wed, 1 Apr 2009 07:39:05 -0700 (PDT) From: Behcet Sarikaya To: Christian Kaas-Petersen , mext@ietf.org In-Reply-To: <647825.69513.qm@web27801.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1592811511-1238596745=:32876" Cc: "Charles E. Perkins" , Domagoj Premec Subject: Re: [MEXT] draft-premec-mext-extended-home-link-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:38:07 -0000 --0-1592811511-1238596745=:32876 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christian,=0A=A0 I am OK redefining the C Flag for this purpose.=A0If ot= her uses come up they should make their own case, I think.=0A=0ARegards,=0A= =0ABehcet=0A=0A=0A=0A=0A________________________________=0AFrom: Christian = Kaas-Petersen =0ATo: mext@ietf.org; Behcet Sarikaya = =0ACc: Charles E. Perkins ; Domag= oj Premec =0ASent: Wednesday, April 1, 2009 2:3= 1:59 AM=0ASubject: SV: [MEXT] (no subject)=0A=0A=0AThe C flag, as defined i= n draft-devarapalli, means the home agent=0Ashall do various processing, bu= t shall not create an entry in the=0Abinding cache.=A0 However, draft-preme= c requires an entry in the=0Abinding cache to be created in order to tunnel= IPv4 packets.=0ASo, either the semantics of the C flag shall be extended o= r=0Aanother flag shall be defined.=A0 What is your suggestion?=0A=0AChristi= an=0A=0A=0A--- Den tirs 31/3/09 skrev Behcet Sarikaya :=0A=0A> Fra: Behcet Sarikaya =0A> Emne: [ME= XT] (no subject)=0A> Til: mext@ietf.org=0A> Cc: "Charles E. Perkins" , "Domagoj Premec" =0A> Dato: = tirsdag 31. marts 2009 22.19=0A> Hello all,=0A> =A0 Regarding=0A> draft-pre= mec-mext-extended-home-link-01.txt, I noticed that=0A> this draft is about = what I asked Charlie last week during=0A> his presentation, i.e. sending BU= at the home link for=0A> something other than deregistration. As the draft= says in=0A> Sec. 4.1:=0A> When the MN returns home to an IPv6-only home ne= twork,=0A> the MN sends ... BU=0A> =A0 I agree with Vijay that a flag must = be defined=0A> and set for this purpose because normally this is not=0A> al= lowed and HA must probably reject such a BU.=A0A flag=0A> to this end has a= lready been suggested in=0A> draft-devarapalli-mext-mipv6-home-link-01 as C= flag.=0A> =A0=0A> Regards,=0A> =A0=0A> Behcet=0A> =0A> =0A>=A0 =A0 =A0 =0A= > -----Inline-vedh=E6ftet fil f=F8lger-----=0A> =0A> ______________________= _________________________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https= ://www.ietf.org/mailman/listinfo/mext=0A> =0A=0A=0A=A0 =A0 =A0 Tr=E6nger du= til at se det store billede? Kelkoo giver dig gode tilbud p=E5 LCD TV! Se = her http://dk.yahoo.com/r/pat/lcd=0A=0A=0A=0A --0-1592811511-1238596745=:32876 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christian,
=0A
  I am OK redefining t= he C Flag for this purpose. If other uses come up they should make the= ir own case, I think.
=0A
 
=0A
Regards,
=0A 
=0A
Behcet
=0A

=0A
=0A
=0AFrom: Christian Kaas-Petersen <kaaspetersen@yahoo.dk>
To: mext@ietf.org; Behcet Sarikaya &= lt;sarikaya@ieee.org>
Cc:= Charles E. Perkins <charliep@wichorus.com>; Domagoj Premec <d= omagoj.premec.ext@nsn.com>
Sent:= Wednesday, April 1, 2009 2:31:59 AM
Subject: SV: [MEXT] (no subject)


= The C flag, as defined in draft-devarapalli, means the home agent
shall = do various processing, but shall not create an entry in the
binding cach= e.  However, draft-premec requires an entry in the
binding cache to= be created in order to tunnel IPv4 packets.
So, either the semantics of= the C flag shall be extended or
another flag shall be defined.  Wh= at is your suggestion?

Christian


--- Den tirs 31/3/09 skrev Behcet = Sarikaya <behcetsarikaya@yahoo.com>:

> Fra= : Behcet Sarikaya <behcetsarikaya@yahoo.com>
&g= t; Emne: [MEXT] (no subject)
> Til: mext@ietf.org
> Cc: "Charles E. = Perkins" <charliep@wichorus.com>, "Domagoj Premec" <domagoj.premec.ext@nsn.com>
> Dato: tirsdag 31. = marts 2009 22.19
> Hello all,
>   Regarding
> draft-= premec-mext-extended-home-link-01.txt, I noticed that
> this draft is= about what I asked Charlie last week during
> his presentation, i.e. sending BU a= t the home link for
> something other than deregistration. As the dra= ft says in
> Sec. 4.1:
> When the MN returns home to an IPv6-on= ly home network,
> the MN sends ... BU
>   I agree with Vi= jay that a flag must be defined
> and set for this purpose because no= rmally this is not
> allowed and HA must probably reject such a BU.&n= bsp;A flag
> to this end has already been suggested in
> draft-= devarapalli-mext-mipv6-home-link-01 as C flag.
>  
> Regar= ds,
>  
> Behcet
>
>
>    &n= bsp;
> -----Inline-vedh=E6ftet fil f=F8lger-----
>
> __= _____________________________________________
> MEXT mailing list
= > MEXT= @ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>

      Tr=E6nger du til at se det store billede? Kel= koo giver dig gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd=

=0A=0A=0A=0A --0-1592811511-1238596745=:32876-- From domagoj.premec.ext@nsn.com Thu Apr 2 02:39:24 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1DF3A69C4 for ; Thu, 2 Apr 2009 02:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 Sa+Zp4QWlNVI for ; Thu, 2 Apr 2009 02:39:23 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 131693A69E4 for ; Thu, 2 Apr 2009 02:39: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 n329eGe0017743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Apr 2009 11:40:17 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n329eCXA028200; Thu, 2 Apr 2009 11:40:16 +0200 Received: from FIESEXC022.nsn-intra.net ([10.135.48.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 11:40:16 +0200 Received: from hr1ch6td ([10.122.35.14]) by FIESEXC022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 12:40:15 +0300 From: "Domagoj Premec" To: "'Behcet Sarikaya'" , "'Christian Kaas-Petersen'" , References: <647825.69513.qm@web27801.mail.ukl.yahoo.com> <861701.32876.qm@web111405.mail.gq1.yahoo.com> Date: Thu, 2 Apr 2009 11:40:13 +0200 Message-ID: <120DABEC3AA34887A93421C7F848B0D3@ww300.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <861701.32876.qm@web111405.mail.gq1.yahoo.com> Thread-index: Acmy155H5VD+iYfBToCi3piMTATqbwAnk26Q X-OriginalArrivalTime: 02 Apr 2009 09:40:15.0273 (UTC) FILETIME=[06C39190:01C9B377] Cc: "'Charles E. Perkins'" Subject: Re: [MEXT] draft-premec-mext-extended-home-link-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 09:39:24 -0000 Behcet, In draft-devarapalli-mext-mipv6-home-link-01 the C flag is being defined = as part of the BU and Back messages. Given that = draft-premec-extended-home-link is about registering for the v4 service from the IPv6-only home link, = there is always the IPv4 HoA option included and in this case it may be more appropriate to define the new flag as part of the IPv4 HoA option. This would save the flag space in the BU/Back without having disadvantages in = the extended home link scenario. domagoj ________________________________ From: ext Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: 01. travanj 2009 16:39 To: Christian Kaas-Petersen; mext@ietf.org Cc: Charles E. Perkins; Domagoj Premec Subject: Re: SV: [MEXT] draft-premec-mext-extended-home-link-01 =09 =09 Hi Christian, I am OK redefining the C Flag for this purpose. If other uses come up they should make their own case, I think. =20 Regards, =20 Behcet =09 ________________________________ From: Christian Kaas-Petersen To: mext@ietf.org; Behcet Sarikaya Cc: Charles E. Perkins ; Domagoj Premec Sent: Wednesday, April 1, 2009 2:31:59 AM Subject: SV: [MEXT] (no subject) =09 =09 The C flag, as defined in draft-devarapalli, means the home agent shall do various processing, but shall not create an entry in the binding cache. However, draft-premec requires an entry in the binding cache to be created in order to tunnel IPv4 packets. So, either the semantics of the C flag shall be extended or another flag shall be defined. What is your suggestion? =09 Christian =09 =09 --- Den tirs 31/3/09 skrev Behcet Sarikaya : =09 > Fra: Behcet Sarikaya > Emne: [MEXT] (no subject) > Til: mext@ietf.org > Cc: "Charles E. Perkins" , "Domagoj Premec" > Dato: tirsdag 31. marts 2009 22.19 > Hello all, > Regarding > draft-premec-mext-extended-home-link-01.txt, I noticed that > this draft is about what I asked Charlie last week during > his presentation, i.e. sending BU at the home link for > something other than deregistration. As the draft says in > Sec. 4.1: > When the MN returns home to an IPv6-only home network, > the MN sends ... BU > I agree with Vijay that a flag must be defined > and set for this purpose because normally this is not > allowed and HA must probably reject such a BU. A flag > to this end has already been suggested in > draft-devarapalli-mext-mipv6-home-link-01 as C flag. > =20 > Regards, > =20 > Behcet >=20 >=20 > =20 > -----Inline-vedh=E6ftet fil f=F8lger----- >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 =09 =09 Tr=E6nger du til at se det store billede? Kelkoo giver dig gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd =09 From behcetsarikaya@yahoo.com Thu Apr 2 07:54:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262DB3A689A for ; Thu, 2 Apr 2009 07:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.331, 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 R-KfH-M8LBtB for ; Thu, 2 Apr 2009 07:54:34 -0700 (PDT) Received: from n9.bullet.re3.yahoo.com (n9.bullet.re3.yahoo.com [68.142.237.94]) by core3.amsl.com (Postfix) with SMTP id 8FAB93A686A for ; Thu, 2 Apr 2009 07:54:34 -0700 (PDT) Received: from [68.142.237.90] by n9.bullet.re3.yahoo.com with NNFMP; 02 Apr 2009 14:55:35 -0000 Received: from [67.195.9.82] by t6.bullet.re3.yahoo.com with NNFMP; 02 Apr 2009 14:55:35 -0000 Received: from [67.195.9.109] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 02 Apr 2009 14:55:34 -0000 Received: from [127.0.0.1] by omp113.mail.gq1.yahoo.com with NNFMP; 02 Apr 2009 14:54:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 194245.52652.bm@omp113.mail.gq1.yahoo.com Received: (qmail 92038 invoked by uid 60001); 2 Apr 2009 14:55:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238684134; bh=Gn9RvRfCyE5SZvtXTqF3B7BeYlZ95l3+l3rz0SYgqBs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=XE6C7PG6Cl2uwJU6sglBKUwHMpPqgEEbSwbYHYFUgLDCqs9mHO7AYwl5sjNylJ6QzyQiwcoAUEwDdHBxLgilMNfEW3XoE9FjQzTuII2NF20PEi9fgOAbhgUFcQHEJsqcZeKvC7oaWSCjYPQP+e8yi89Y8HAjaL64QWdNoYHNx14= 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; b=ZF4A6tg+aIou/z6urBNGX7sjvYOulTWTG6ezLBeDfUHI8pr616D3KNGmXJGoV1o8CVWx51ZknWWlH2imlQuJuvKFVf68Go7PEvEvxPs5880tBlA9bAcyUKDyJuwPND2+4GH3k6kcxwICjUrXtNPoc82XnFBV/TmU+n+x3iLfjd0=; Message-ID: <557697.88490.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: kTu1B3cVM1lggnc.NWwpwB2DaJmUSKCj3YhS_zOQF3F7MsgL6O9ulBGWGDP2MlFwvhb5OhClzo3xPePCa84GeT2XYxaBIJ5DHzxqpEBj7o2txfPKFd5eCAHagZ4p.mosXMk2Pyzfv4CV113uAliPTqykYE_rmscFHDcg4pZ9hMLh.NNHAuO9b7hKTZ7I6VMq_ofVkkWRD6JJL67TGFaJVY6N6k8zCtJQ4N1MYLicS_eLKxZAMK02AO2LV.QFKmx.gYV.4VNDDLQ_UmetW_DCDBbNAQwrjkv8vblj64qiijCZTqBvwU2h67V1fkNoJbAmdENv Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Thu, 02 Apr 2009 07:55:34 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <647825.69513.qm@web27801.mail.ukl.yahoo.com> <861701.32876.qm@web111405.mail.gq1.yahoo.com> <120DABEC3AA34887A93421C7F848B0D3@ww300.siemens.net> Date: Thu, 2 Apr 2009 07:55:34 -0700 (PDT) From: Behcet Sarikaya To: Domagoj Premec , Christian Kaas-Petersen , mext@ietf.org In-Reply-To: <120DABEC3AA34887A93421C7F848B0D3@ww300.siemens.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-840964550-1238684134=:88490" Subject: Re: [MEXT] draft-premec-mext-extended-home-link-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 14:54:36 -0000 --0-840964550-1238684134=:88490 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Domagoj,=0A=A0 You need to indicate to HA that this is a non-deregistrat= ion BU sent from the home link. So the correct way is to define a flag at t= he BU message like the C flag in http://tools.ietf.org/id/draft-devarapalli= -mext-mipv6-home-link-01.txt=0A=A0 Of course HA may also set the C flag in = its reply of BA message. I think this was what Vijay was commenting on last= week at the mext meeting.=0A=A0 Yes, IPv4 HoA option has some bits availab= le but these would apply to this option not to the BU message, I think it w= ould be wrong to define this bit there.=0A=A0 Regards,=0A=0ABehcet=0A=0A=0A= =0A=0A________________________________=0AFrom: Domagoj Premec =0ATo: Behcet Sarikaya ; Christian Kaas-P= etersen ; mext@ietf.org=0ACc: Charles E. Perkins =0ASent: Thursday, April 2, 2009 4:40:13 AM=0ASubject: = RE: SV: [MEXT] draft-premec-mext-extended-home-link-01=0A=0ABehcet,=0A=0AIn= draft-devarapalli-mext-mipv6-home-link-01 the C flag is being defined as= =0Apart of the BU and Back messages. Given that draft-premec-extended-home-= link=0Ais about registering for the v4 service from the IPv6-only home link= , there=0Ais always the IPv4 HoA option included and in this case it may be= more=0Aappropriate to define the new flag as part of the IPv4 HoA option. = This=0Awould save the flag space in the BU/Back without having disadvantage= s in the=0Aextended home link scenario.=0A=0Adomagoj=0A=0A=0A=0A___________= _____________________=0A=0A=A0=A0=A0 From: ext Behcet Sarikaya [mailto:behc= etsarikaya@yahoo.com] =0A=A0=A0=A0 Sent: 01. travanj 2009 16:39=0A=A0=A0=A0= To: Christian Kaas-Petersen; mext@ietf.org=0A=A0=A0=A0 Cc: Charles E. Perk= ins; Domagoj Premec=0A=A0=A0=A0 Subject: Re: SV: [MEXT] draft-premec-mext-e= xtended-home-link-01=0A=A0=A0=A0 =0A=A0=A0=A0 =0A=A0=A0=A0 Hi Christian,=0A= =A0=A0=A0 =A0 I am OK redefining the C Flag for this purpose. If other uses= come=0Aup they should make their own case, I think.=0A=A0=A0=A0 =0A=A0=A0= =A0 Regards,=0A=A0=A0=A0 =0A=A0=A0=A0 Behcet=0A=A0=A0=A0 =0A=0A=A0=A0=A0 __= ______________________________=0A=0A=A0=A0=A0 From: Christian Kaas-Petersen= =0A=A0=A0=A0 To: mext@ietf.org; Behcet Sarikaya =0A=A0=A0=A0 Cc: Charles E. Perkins = ; Domagoj Premec=0A=0A=A0=A0=A0 Sent: Wednesday= , April 1, 2009 2:31:59 AM=0A=A0=A0=A0 Subject: SV: [MEXT] (no subject)=0A= =A0=A0=A0 =0A=A0=A0=A0 =0A=A0=A0=A0 The C flag, as defined in draft-devarap= alli, means the home agent=0A=A0=A0=A0 shall do various processing, but sha= ll not create an entry in the=0A=A0=A0=A0 binding cache.=A0 However, draft-= premec requires an entry in the=0A=A0=A0=A0 binding cache to be created in = order to tunnel IPv4 packets.=0A=A0=A0=A0 So, either the semantics of the C= flag shall be extended or=0A=A0=A0=A0 another flag shall be defined.=A0 Wh= at is your suggestion?=0A=A0=A0=A0 =0A=A0=A0=A0 Christian=0A=A0=A0=A0 =0A= =A0=A0=A0 =0A=A0=A0=A0 --- Den tirs 31/3/09 skrev Behcet Sarikaya=0A:=0A=A0=A0=A0 =0A=A0=A0=A0 > Fra: Behcet Sarikaya =0A=A0=A0=A0 > Emne: [MEXT] (no subject)=0A=A0=A0=A0 > = Til: mext@ietf.org=0A=A0=A0=A0 > Cc: "Charles E. Perkins" , "Domagoj Premec"=0A=0A=A0=A0=A0 > Dato:= tirsdag 31. marts 2009 22.19=0A=A0=A0=A0 > Hello all,=0A=A0=A0=A0 >=A0 Reg= arding=0A=A0=A0=A0 > draft-premec-mext-extended-home-link-01.txt, I noticed= that=0A=A0=A0=A0 > this draft is about what I asked Charlie last week duri= ng=0A=A0=A0=A0 > his presentation, i.e. sending BU at the home link for=0A= =A0=A0=A0 > something other than deregistration. As the draft says in=0A=A0= =A0=A0 > Sec. 4.1:=0A=A0=A0=A0 > When the MN returns home to an IPv6-only h= ome network,=0A=A0=A0=A0 > the MN sends ... BU=0A=A0=A0=A0 >=A0 I agree wit= h Vijay that a flag must be defined=0A=A0=A0=A0 > and set for this purpose = because normally this is not=0A=A0=A0=A0 > allowed and HA must probably rej= ect such a BU. A flag=0A=A0=A0=A0 > to this end has already been suggested = in=0A=A0=A0=A0 > draft-devarapalli-mext-mipv6-home-link-01 as C flag.=0A=A0= =A0=A0 >=A0 =0A=A0=A0=A0 > Regards,=0A=A0=A0=A0 >=A0 =0A=A0=A0=A0 > Behcet= =0A=A0=A0=A0 > =0A=A0=A0=A0 > =0A=A0=A0=A0 >=A0 =A0 =A0 =0A=A0=A0=A0 > ----= -Inline-vedh=E6ftet fil f=F8lger-----=0A=A0=A0=A0 > =0A=A0=A0=A0 > ________= _______________________________________=0A=A0=A0=A0 > MEXT mailing list=0A= =A0=A0=A0 > MEXT@ietf.org=0A=A0=A0=A0 > https://www.ietf.org/mailman/listin= fo/mext=0A=A0=A0=A0 > =0A=A0=A0=A0 =0A=A0=A0=A0 =0A=A0=A0=A0 =A0 =A0 =A0 Tr= =E6nger du til at se det store billede? Kelkoo giver dig gode=0Atilbud p=E5= LCD TV! Se her http://dk.yahoo.com/r/pat/lcd=0A=0A=0A --0-840964550-1238684134=:88490 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Domagoj,
=0A
  You need to indicate t= o HA that this is a non-deregistration BU sent from the home link. So the c= orrect way is to define a flag at the BU message like the C flag in http://tools.ietf.org/id/draft-devarapalli-mext-mipv6-home-link-01.txt=
=0A
  Of course HA may also set the C flag in its reply of B= A message. I think this was what Vijay was commenting on last week at the m= ext meeting.
=0A
  Yes, IPv4 HoA option has some bits availab= le but these would apply to this option not to the BU message, I think it w= ould be wrong to define this bit there.
=0A
  Regards,
= =0A
 
=0A
Behcet
=0A

=0A
=0A
=0A= From: Domagoj Premec <domagoj.premec.ext@nsn.com>
To: Behcet Sarikaya <sarikaya= @ieee.org>; Christian Kaas-Petersen <kaaspetersen@yahoo.dk>; mext@= ietf.org
Cc: Charles E. = Perkins <charliep@wichorus.com>
Sent: Thursday, April 2, 2009 4:40:13 AM
Subject: RE: SV: [MEXT] draft-premec-mext-ex= tended-home-link-01

Behcet,

In draft-devarapalli-mext-= mipv6-home-link-01 the C flag is being defined as
part of the BU and Bac= k messages. Given that draft-premec-extended-home-link
is about register= ing for the v4 service from the IPv6-only home link, there
is always the= IPv4 HoA option included and in this case it may be more
appropriate to= define the new flag as part of the IPv4 HoA option. This
would save the flag space in the BU/Back without havin= g disadvantages in the
extended home link scenario.

domagoj


________________________________

    From: = ext Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
=     Sent: 01. travanj 2009 16:39
    To: C= hristian Kaas-Petersen; mext@ietf.org
    Cc: Charles E. Perki= ns; Domagoj Premec
    Subject: Re: SV: [MEXT] draft-prem= ec-mext-extended-home-link-01
   
    =
    Hi Christian,
      I am OK r= edefining the C Flag for this purpose. If other uses come
up they should= make their own case, I think.
   
    Regards,
   
    Behcet
 &nbs= p; 

    ________________________________
    From: Christian Kaas-Petersen <kaaspetersen@y= ahoo.dk>
    To: mext@ietf.org; Behcet Sarikaya <sari= kaya@ieee.org>
    Cc: Charles E. Perkins <charliep@wichorus.com>; Domagoj Premec
<do= magoj.premec.ext@nsn.com>
    Sent: Wednesday, Apr= il 1, 2009 2:31:59 AM
    Subject: SV: [MEXT] (no subject)
   
   
  &nbs= p; The C flag, as defined in draft-devarapalli, means the home agent
&nb= sp;   shall do various processing, but shall not create an entry = in the
    binding cache.  However, draft-premec req= uires an entry in the
    binding cache to be created in = order to tunnel IPv4 packets.
    So, either the semantic= s of the C flag shall be extended or
    another flag sha= ll be defined.  What is your suggestion?
   
&nb= sp;   Christian
   
   
=     --- Den tirs 31/3/09 skrev Behcet Sarikaya
<behcetsarikaya@yahoo.com>:
   
 &n= bsp;  > Fra: Behcet Sarikaya <behcetsarikaya@yahoo.com>
    > Emne= : [MEXT] (no subject)
    > Til: mext@ietf.org
 &nb= sp;  > Cc: "Charles E. Perkins" <charliep@wichorus.com>, "Domagoj Premec"
<domagoj.premec.ext@nsn.com<= /A>>
    > Dato: tirsdag 31. marts 2009 22.19
&n= bsp;   > Hello all,
    >  Regarding=
    > draft-premec-mext-extended-home-link-01.txt, I = noticed that
    > this draft is about what I asked Ch= arlie last week during
    > his presentation, i.e. se= nding BU at the home link for
    > something other than dereg= istration. As the draft says in
    > Sec. 4.1:
&nb= sp;   > When the MN returns home to an IPv6-only home network,=
    > the MN sends ... BU
    >&= nbsp; I agree with Vijay that a flag must be defined
    = > and set for this purpose because normally this is not
  &= nbsp; > allowed and HA must probably reject such a BU. A flag
 &= nbsp;  > to this end has already been suggested in
  &= nbsp; > draft-devarapalli-mext-mipv6-home-link-01 as C flag.
 &n= bsp;  > 
    > Regards,
  &= nbsp; > 
    > Behcet
    &= gt;
    >
    >    &n= bsp;
    > -----Inline-vedh=E6ftet fil f=F8lger-----
    >
    > _____= __________________________________________
    > MEXT = mailing list
    > MEXT@ietf.org
    >= htt= ps://www.ietf.org/mailman/listinfo/mext
    >
=    
   
      &nb= sp;   Tr=E6nger du til at se det store billede? Kelkoo giver dig gode<= BR>tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd
  =  




=0A=0A --0-840964550-1238684134=:88490-- From kaaspetersen@yahoo.dk Fri Apr 3 01:35:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF593A6C2B for ; Fri, 3 Apr 2009 01:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, J_CHICKENPOX_13=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 a0qYeKenYZhB for ; Fri, 3 Apr 2009 01:35:43 -0700 (PDT) Received: from web27807.mail.ukl.yahoo.com (web27807.mail.ukl.yahoo.com [217.146.182.12]) by core3.amsl.com (Postfix) with SMTP id 1AAED3A6A92 for ; Fri, 3 Apr 2009 01:35:42 -0700 (PDT) Received: (qmail 51865 invoked by uid 60001); 3 Apr 2009 08:36:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1238747804; bh=KJ4Llv17CjbAQ/XJ3+10NUe4UW1Vy5GVjNxNI3PBHAE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Zawoys64mrAh93dwMxMg4vp5mTglpMovC0fJqz/IkmWIlMG53HaBrx/zyvuSbef2D5tQQJG4E20h5QJOnFk6EdjzbTEt4GbMoi6MVUei2Du7pqgDSch7peBMaHUfWvdshXygGSy2I6VFOvBku8DYkjZ7aEUVy5UbzMtlmQLpK0s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QTvWwYmJbeqxZvoOGeXBvSR3lvbBXaWrN+0rAnlrN418rah2Mt/KO79xcmWe3N1vj66FIy5OAmVEBkiyjl8YfZKokjKML1gr0sbxNPt2r/x6sNz4uETcrSDnLQ93/JXc4/2oycZx/7Ncs2lGVfkZBknQLZIRV6C0j1KSh+t6KC0=; Message-ID: <845063.45120.qm@web27807.mail.ukl.yahoo.com> X-YMail-OSG: kufNgkkVM1ms1kuzosp4zH40NcIHZYoQueJBJ.1T_pB2LkdUJBNYQ8K2spc3olNPvTV.AZ_muxRuDqKVKSyR1RuO1BXio.TyB4Mzfg7CHNtwpbigxUV0o8PWe8_gLTFXhtAl80._qh7xPLiYP8Sk_6sdMKrklSWKbJdbbPTRBe0a04VtdrodiBhoEcd8gUhZ.FAoSscpDIJH4p2nEzo1tANpGDbDnDheh7BpS3rHnQmFOdGBEvTPMEqvxT7DqFA43UHJ.evcHpxXyVXAHGZB8zCux5SOIHdI_byvcvloo1qKk0bOq.LzFS1no6RHyh_Hk5QABQNnFBDoNk2IhIbSWL2N4QV9BWXuzqQi076k9ACCCg.u_o1M6bHTeA-- Received: from [193.15.240.60] by web27807.mail.ukl.yahoo.com via HTTP; Fri, 03 Apr 2009 08:36:44 GMT X-Mailer: YahooMailClassic/5.2.15 YahooMailWebService/0.7.289.1 Date: Fri, 3 Apr 2009 08:36:44 +0000 (GMT) From: Christian Kaas-Petersen To: Domagoj Premec , mext@ietf.org, Behcet Sarikaya MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] draft-premec-mext-extended-home-link-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 08:35:44 -0000 Proposal: Introduce a Tunnel (T) bit in the BU to signal an=20 IPv4 tunnel to be created on the home link. Introducing modified semantics on mobility options appearing in=20 BUs sent the home link (as done in draft-premec) is not the way ahead. =20 The reason is simplificy of design: one option has one purpose. The C-bit in the BU has been suggested as a way to signal the BU is sent on the home link for the purpose of configuration (done in draft-devarapalli). What exactly to be configured depends on the mobility options present. This mail suggest a T-bit in the BU as a way to signal a tunnel to be established. Currently, only one tunnel is foreseen, namely the IPv4-in-IPv6 tunnel for IPv4 traffic over an IPv6-only home link. The tunnel is indicated with the IPv4 Home Address mobility option. The tunnel could be established as the entry v4HoA -> v6HoA in the binding cache. The T-bit may be set, only when also the C-bit is set. Having T-bit set and C-bit clear is an error. Having T-bit set and IPv4 Home Address mobility option missing is probly an error. There should be no need=20 to include IPv4 Care-of Address mobility option, as its content will be the same as the IPv4 Home Address mobility option. Not clear what the BU's lifetime should be. With the C-bit set, configurations can be done, for example to obtain an IPv4 home address or a NEMO mobile network prefix. The values returned may be dynamically assigned by the home agent. The home agent would probably be interested in knowing for how long time the assigned values will be used. A practical solution for this is to say the assignment is valid as long as the mobile node remains on the home link and as long as the IKE session is alive between the mobile node and the home agent.=20 Christian --- Den tors 2/4/09 skrev Behcet Sarikaya : Fra: Behcet Sarikaya Emne: Re: SV: [MEXT] draft-premec-mext-extended-home-link-01 Til: "Domagoj Premec" , "Christian Kaas-Peterse= n" , mext@ietf.org Dato: torsdag 2. april 2009 16.55 Hi Domagoj, =A0 You need to indicate to HA that this is a non-deregistration BU sent fr= om the home link. So the correct way is to define a flag at the BU message = like the C flag in http://tools.ietf.org/id/draft-devarapalli-mext-mipv6-ho= me-link-01.txt =A0 Of course HA may also set the C flag in its reply of BA message. I thin= k this was what Vijay was commenting on last week at the mext meeting. =A0 Yes, IPv4 HoA option has some bits available but these would apply to t= his option not to the BU message, I think it would be wrong to define this = bit there. =A0 Regards, =A0 Behcet From: Domagoj Premec To: Behcet Sarikaya ; Christian Kaas-Petersen ; mext@ietf.org Cc: Charles E. Perkins Sent: Thursday, April 2, 2009 4:40:13 AM Subject: RE: SV: [MEXT] draft-premec-mext-extended-home-link-01 Behcet, In draft-devarapalli-mext-mipv6-home-link-01 the C flag is being defined as part of the BU and Back messages. Given that draft-premec-extended-home-lin= k is about registering for the v4 service from the IPv6-only home link, there is always the IPv4 HoA option included and in this case it may be more appropriate to define the new flag as part of the IPv4 HoA option. This would save the flag space in the BU/Back without having disadvantages in th= e extended home link scenario. domagoj ________________________________ =A0=A0=A0 From: ext Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 =A0=A0=A0 Sent: 01. travanj 2009 16:39 =A0=A0=A0 To: Christian Kaas-Petersen; mext@ietf.org =A0=A0=A0 Cc: Charles E. Perkins; Domagoj Premec =A0=A0=A0 Subject: Re: SV: [MEXT] draft-premec-mext-extended-home-link-01 =A0=A0=A0=20 =A0=A0=A0=20 =A0=A0=A0 Hi Christian, =A0=A0=A0 =A0 I am OK redefining the C Flag for this purpose. If other uses= come up they should make their own case, I think. =A0=A0=A0=20 =A0=A0=A0 Regards, =A0=A0=A0=20 =A0=A0=A0 Behcet =A0=A0=A0=20 =A0=A0=A0 ________________________________ =A0=A0=A0 From: Christian Kaas-Petersen =A0=A0=A0 To: mext@ietf.org; Behcet Sarikaya =A0=A0=A0 Cc: Charles E. Perkins ; Domagoj Premec =A0=A0=A0 Sent: Wednesday, April 1, 2009 2:31:59 AM =A0=A0=A0 Subject: SV: [MEXT] (no subject) =A0=A0=A0=20 =A0=A0=A0=20 =A0=A0=A0 The C flag, as defined in draft-devarapalli, means the home agent =A0=A0=A0 shall do various processing, but shall not create an entry in the =A0=A0=A0 binding cache.=A0 However, draft-premec requires an entry in the =A0=A0=A0 binding cache to be created in order to tunnel IPv4 packets. =A0=A0=A0 So, either the semantics of the C flag shall be extended or =A0=A0=A0 another flag shall be defined.=A0 What is your suggestion? =A0=A0=A0=20 =A0=A0=A0 Christian =A0=A0=A0=20 =A0=A0=A0=20 =A0=A0=A0 --- Den tirs 31/3/09 skrev Behcet Sarikaya : =A0=A0=A0=20 =A0=A0=A0 > Fra: Behcet Sarikaya =A0=A0=A0 > Emne: [MEXT] (no subject) =A0=A0=A0 > Til: mext@ietf.org =A0=A0=A0 > Cc: "Charles E. Perkins" , "Domagoj Prem= ec" =A0=A0=A0 > Dato: tirsdag 31. marts 2009 22.19 =A0=A0=A0 > Hello all, =A0=A0=A0 >=A0 Regarding =A0=A0=A0 > draft-premec-mext-extended-home-link-01.txt, I noticed that =A0=A0=A0 > this draft is about what I asked Charlie last week during =A0=A0=A0 > his presentation, i.e. sending BU at the home link for =A0=A0=A0 > something other than deregistration. As the draft says in =A0=A0=A0 > Sec. 4.1: =A0=A0=A0 > When the MN returns home to an IPv6-only home network, =A0=A0=A0 > the MN sends ... BU =A0=A0=A0 >=A0 I agree with Vijay that a flag must be defined =A0=A0=A0 > and set for this purpose because normally this is not =A0=A0=A0 > allowed and HA must probably reject such a BU. A flag =A0=A0=A0 > to this end has already been suggested in =A0=A0=A0 > draft-devarapalli-mext-mipv6-home-link-01 as C flag. =A0=A0=A0 >=A0=20 =A0=A0=A0 > Regards, =A0=A0=A0 >=A0=20 =A0=A0=A0 > Behcet =A0=A0=A0 >=20 =A0=A0=A0 >=20 =A0=A0=A0 >=A0 =A0 =A0=20 =A0=A0=A0 > -----Inline-vedh=E6ftet fil f=F8lger----- =A0=A0=A0 >=20 =A0=A0=A0 > _______________________________________________ =A0=A0=A0 > MEXT mailing list =A0=A0=A0 > MEXT@ietf.org =A0=A0=A0 > https://www.ietf.org/mailman/listinfo/mext =A0=A0=A0 >=20 =A0=A0=A0 =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo g= iver dig gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From Priyanka.RAWAT@telecom-bretagne.eu Fri Apr 3 07:41:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39A13A688D for ; Fri, 3 Apr 2009 07:41:44 -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.328, BAYES_05=-1.11, 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 tY3aMsNRn+4I for ; Fri, 3 Apr 2009 07:41:44 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id 3F0883A6E63 for ; Fri, 3 Apr 2009 07:41:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id n33EgmTg032484; Fri, 3 Apr 2009 16:42:48 +0200 Received: from courrier.enst-bretagne.fr (smtps.telecom-bretagne.eu [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2008.01.11) with ESMTP id n33EghI9032431; Fri, 3 Apr 2009 16:42:47 +0200 Received: from telecom-bretagne.eu (smtps.enst-bretagne.fr [10.29.90.4]) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2006.06.07) with ESMTP id n33EgdLb022513; Fri, 3 Apr 2009 16:42:39 +0200 Received: from srv-disi-b1-02.priv.enst-bretagne.fr (srv-disi-b1-02.priv.enst-bretagne.fr [10.29.96.3]) by webmail.telecom-bretagne.eu (Horde Framework) with HTTP; Fri, 03 Apr 2009 16:42:39 +0200 Message-ID: <20090403164239.15992mx5onag6w68@webmail.telecom-bretagne.eu> Date: Fri, 03 Apr 2009 16:42:39 +0200 From: Priyanka.RAWAT@telecom-bretagne.eu To: Thierry Ernst References: <47575AC5.1090401@inria.fr> In-Reply-To: <47575AC5.1090401@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) /ENSTB X-Originating-IP: 192.44.77.81 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: mext@ietf.org Subject: [MEXT] (TuCP) Tunneling Header Compression in mobile networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:41:44 -0000 Hello Thierry We have submitted a new draft to ietf. It specifies a method to =20 compress IPv6 tunnel, thus enhancing IPv6 tunneling efficiency in =20 mobile networks. Since we are interested in continuing this work further, it would be =20 good for us to receive feedback on the draft. I thought this might be of interest to you. The document is available at http://tools.ietf.org/html/draft-rawat-mext-hc-tunneling-00 Please let me know your opinion. Regards Priyanka Rawat IT/TELECOM Bretagne Thierry Ernst a =C3=A9crit : > > A paper about ROHC with NEMO was published at WONEMO 2007 and =20 > another one about ROHC in nested NEMO this year at ICLAN 2007. Also =20 > draft-minaburo-rohc-nemo.txt (expired) > > See http://www.rennes.enst-bretagne.fr/~prawat/ > > Thierry > > > > Wassim Haddad wrote: >> Hi Vidya, >> >> Just to add one thing: >> >> ROHC is deployed *only* in particular networks and in these =20 >> networks when you switch between BS, ROHC has to "reboot". So for =20 >> mobility protocols in >> general (including the RO mode), this proposal is much more efficient. >> >> >> Regards, >> >> Wassim H. >> >> >> >> On Wed, 5 Dec 2007, Narayanan, Vidya wrote: >>> >>> Hi Hesham, >>> >>>> >>>> =3D> ROHC has several limitations. One of them is that it works >>>> on p2p links. >>>> Another is it's complexity of course. This solution is >>>> independent of the link layer, which is good. Even when >>>> combined with ROHC it can easily address the triple header scenarios. >>>> >>> >>> Okay, I'm speaking prematurely, since I haven't looked at the draft yet >>> :) I was trying to understand where we see the use. Even from the p2p >>> perspective of ROHC, I suppose one could say that the MN-HA IP-in-IP >>> tunnel is a virtual p2p link. That is philosophy behind the ongoing >>> work on ROHC for IPsec. But, I'll take a look at the draft first (I >>> assume there is one :)). >>> >>> Vidya >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mext >>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mext > > From behcetsarikaya@yahoo.com Fri Apr 3 08:55:49 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8D928C139 for ; Fri, 3 Apr 2009 08:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.268 X-Spam-Level: X-Spam-Status: No, score=-1.268 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] 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 v5HJcKd25sKI for ; Fri, 3 Apr 2009 08:55:47 -0700 (PDT) Received: from n9.bullet.re3.yahoo.com (n9.bullet.re3.yahoo.com [68.142.237.94]) by core3.amsl.com (Postfix) with SMTP id 6317E28C12A for ; Fri, 3 Apr 2009 08:55:47 -0700 (PDT) Received: from [68.142.230.29] by n9.bullet.re3.yahoo.com with NNFMP; 03 Apr 2009 15:56:49 -0000 Received: from [67.195.9.82] by t2.bullet.re2.yahoo.com with NNFMP; 03 Apr 2009 15:56:49 -0000 Received: from [67.195.9.100] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 03 Apr 2009 15:56:49 -0000 Received: from [127.0.0.1] by omp104.mail.gq1.yahoo.com with NNFMP; 03 Apr 2009 15:56:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 32416.79382.bm@omp104.mail.gq1.yahoo.com Received: (qmail 80953 invoked by uid 60001); 3 Apr 2009 15:56:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238774193; bh=F+EKygwJbjpKjlWru2ECcQjLhzZx8PO8zzEslRpPLwA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=IYoD6znSOV7vRElNgBu7PgE8lJ12B2N3lNRaMwjiji8b1jePa+trfa1itMvdMi/o5MoH6Jce7KQ0HKEeXM1bE8+nDSj1SdvsUlktHDl0jkMPVzr1clgrW7ZhSBrCXX+0h0OCxUpHqkKikoKVCd/bd6oqhHtagwPRhEKw7C8xFQk= 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; b=e3ygRcwJcyIvXLFNXLRU05y2yrm9h2OQPcxT5l7Nc1qmMEBtpoAv40vme3xdFg2gI0wpDXIK9TvoglxCY21fJ6tox2oRnphVDn2IfHr8NXzW+OJ0rElCpmgnfODyTjwIb8EPuwVwqy148NaXVgm05WbkVvMmR+ZmRPfEToiiGUw=; Message-ID: <587157.77230.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: PrMPwmMVM1mxOlwHCF5.b4A6vvhrGYfXfFpMWQSajZToi4RGlJ7ZEcEiuar9UXasordBZBkRxRh67HGoZYuhZ.5lxlly35K9loXqfYvqifHQCVZn1j6mo7NU1QqERYOLJumajSyCASyPmND7wiA5nwl7wYC0kWRoLFeKYihfTUmCrvUEktwRPufHot6pEiHqUx_ikReqsIGBL.Y1PIAumfDlX2lFQwtnxGFFd6XXfd073ZUFUqL7jWv6BGPNifd2.nPQ9oJM9w9KSUhGAiLu0EXSO2.vnHK5MPUDMBwA9ci6Dtm1HlbbfRSwIwl9XM0z75vw Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Fri, 03 Apr 2009 08:56:33 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <845063.45120.qm@web27807.mail.ukl.yahoo.com> Date: Fri, 3 Apr 2009 08:56:33 -0700 (PDT) From: Behcet Sarikaya To: Christian Kaas-Petersen , Domagoj Premec , mext@ietf.org In-Reply-To: <845063.45120.qm@web27807.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1706999005-1238774193=:77230" Subject: Re: [MEXT] draft-premec-mext-extended-home-link-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:55:49 -0000 --0-1706999005-1238774193=:77230 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable A bit (C-bit, whatever bit) is needed to indicate a non-deregistration BU s= ent at the home link. Maybe the right place is 3775bis. I was trying to ind= icate this last week in mext session, but Marcelo cut me off saying that th= e issues with 3775bis have been closed.=0A=0AOnce this bit is defined, draf= t-premec can have a normative statement to require this bit be set and then= introduce IPv4 HoA issue.=0A=0AThis is my understanding.=0A=0ARegards,=0A= =0ABehcet=0A=0A=0A=0A=0A________________________________=0AFrom: Christian = Kaas-Petersen =0ATo: Domagoj Premec ; mext@ietf.org; Behcet Sarikaya =0ASent: Fr= iday, April 3, 2009 3:36:44 AM=0ASubject: Re: SV: [MEXT] draft-premec-mext-= extended-home-link-01=0A=0A=0AProposal: Introduce a Tunnel (T) bit in the B= U to signal an =0AIPv4 tunnel to be created on the home link.=0A=0AIntroduc= ing modified semantics on mobility options appearing in =0ABUs sent the hom= e link (as done in draft-premec) is not the way ahead.=A0 =0AThe reason is = simplificy of design: one option has one purpose.=0A=0AThe C-bit in the BU = has been suggested as a way to signal the=0ABU is sent on the home link for= the purpose of configuration=0A(done in draft-devarapalli).=A0 What exactl= y to be configured=0Adepends on the mobility options present.=0A=0AThis mai= l suggest a T-bit in the BU as a way to signal a tunnel=0Ato be established= ..=A0 Currently, only one tunnel is foreseen, namely=0Athe IPv4-in-IPv6 tunn= el for IPv4 traffic over an IPv6-only home=0Alink.=A0 The tunnel is indicat= ed with the IPv4 Home Address mobility=0Aoption.=A0 The tunnel could be est= ablished as the entry=0Av4HoA -> v6HoA in the binding cache.=A0 The T-bit m= ay be set, only=0Awhen also the C-bit is set.=A0 Having T-bit set and C-bit= clear=0Ais an error.=A0 Having T-bit set and IPv4 Home Address mobility=0A= option missing is probly an error.=A0 There should be no need =0Ato include= IPv4 Care-of Address mobility option, as its content=0Awill be the same as= the IPv4 Home Address mobility option.=0A=0ANot clear what the BU's lifeti= me should be.=A0 With the C-bit set,=0Aconfigurations can be done, for exam= ple to obtain an IPv4 home=0Aaddress or a NEMO mobile network prefix.=A0 Th= e values returned=0Amay be dynamically assigned by the home agent.=A0 The h= ome agent=0Awould probably be interested in knowing for how long time the= =0Aassigned values will be used.=A0 A practical solution for this=0Ais to s= ay the assignment is valid as long as the mobile node=0Aremains on the home= link and as long as the IKE session=0Ais alive between the mobile node and= the home agent. =0A=0AChristian=0A=0A=0A=0A=0A=0A--- Den tors 2/4/09 skrev= Behcet Sarikaya :=0A=0A=0AFra: Behcet Sarikaya <= behcetsarikaya@yahoo.com>=0AEmne: Re: SV: [MEXT] draft-premec-mext-extended= -home-link-01=0ATil: "Domagoj Premec" , "Christ= ian Kaas-Petersen" , mext@ietf.org=0ADato: torsdag 2= .. april 2009 16.55=0A=0A=0A=0A=0A=0A=0AHi Domagoj,=0A=A0 You need to indica= te to HA that this is a non-deregistration BU sent from the home link. So t= he correct way is to define a flag at the BU message like the C flag in htt= p://tools.ietf.org/id/draft-devarapalli-mext-mipv6-home-link-01.txt=0A=A0 O= f course HA may also set the C flag in its reply of BA message. I think thi= s was what Vijay was commenting on last week at the mext meeting.=0A=A0 Yes= , IPv4 HoA option has some bits available but these would apply to this opt= ion not to the BU message, I think it would be wrong to define this bit the= re.=0A=A0 Regards,=0A=A0=0ABehcet=0A=0A=0A=0A=0A=0AFrom: Domagoj Premec =0ATo: Behcet Sarikaya ; Christ= ian Kaas-Petersen ; mext@ietf.org=0ACc: Charles E. P= erkins =0ASent: Thursday, April 2, 2009 4:40:13 AM= =0ASubject: RE: SV: [MEXT] draft-premec-mext-extended-home-link-01=0A=0ABeh= cet,=0A=0AIn draft-devarapalli-mext-mipv6-home-link-01 the C flag is being = defined as=0Apart of the BU and Back messages. Given that draft-premec-exte= nded-home-link=0Ais about registering for the v4 service from the IPv6-only= home link, there=0Ais always the IPv4 HoA option included and in this case= it may be more=0Aappropriate to define the new flag as part of the IPv4 Ho= A option. This=0Awould save the flag space in the BU/Back without having di= sadvantages in the=0Aextended home link scenario.=0A=0Adomagoj=0A=0A=0A=0A_= _______________________________=0A=0A=A0=A0=A0 From: ext Behcet Sarikaya [m= ailto:behcetsarikaya@yahoo.com] =0A=A0=A0=A0 Sent: 01. travanj 2009 16:39= =0A=A0=A0=A0 To: Christian Kaas-Petersen; mext@ietf.org=0A=A0=A0=A0 Cc: Cha= rles E. Perkins; Domagoj Premec=0A=A0=A0=A0 Subject: Re: SV: [MEXT] draft-p= remec-mext-extended-home-link-01=0A=A0=A0=A0 =0A=A0=A0=A0 =0A=A0=A0=A0 Hi C= hristian,=0A=A0=A0=A0 =A0 I am OK redefining the C Flag for this purpose. I= f other uses come=0Aup they should make their own case, I think.=0A=A0=A0= =A0 =0A=A0=A0=A0 Regards,=0A=A0=A0=A0 =0A=A0=A0=A0 Behcet=0A=A0=A0=A0 =0A= =0A=A0=A0=A0 ________________________________=0A=0A=A0=A0=A0 From: Christia= n Kaas-Petersen =0A=A0=A0=A0 To: mext@ietf.org; Behc= et Sarikaya =0A=A0=A0=A0 Cc: Charles E. Perkins ; Domagoj Premec=0A=0A=A0=A0=A0 = Sent: Wednesday, April 1, 2009 2:31:59 AM=0A=A0=A0=A0 Subject: SV: [MEXT] (= no subject)=0A=A0=A0=A0 =0A=A0=A0=A0 =0A=A0=A0=A0 The C flag, as defined in= draft-devarapalli, means the home agent=0A=A0=A0=A0 shall do various proce= ssing, but shall not create an entry in the=0A=A0=A0=A0 binding cache.=A0 H= owever, draft-premec requires an entry in the=0A=A0=A0=A0 binding cache to = be created in order to tunnel IPv4 packets.=0A=A0=A0=A0 So, either the sema= ntics of the C flag shall be extended or=0A=A0=A0=A0 another flag shall be = defined.=A0 What is your suggestion?=0A=A0=A0=A0 =0A=A0=A0=A0 Christian=0A= =A0=A0=A0 =0A=A0=A0=A0 =0A=A0=A0=A0 --- Den tirs 31/3/09 skrev Behcet Sarik= aya=0A:=0A=A0=A0=A0 =0A=A0=A0=A0 > Fra: Behcet Sa= rikaya =0A=A0=A0=A0 > Emne: [MEXT] (no subject)= =0A=A0=A0=A0 > Til: mext@ietf.org=0A=A0=A0=A0 > Cc: "Charles E. Perkins" , "Domagoj Premec"=0A=0A= =A0=A0=A0 > Dato: tirsdag 31. marts 2009 22.19=0A=A0=A0=A0 > Hello all,=0A= =A0=A0=A0 >=A0 Regarding=0A=A0=A0=A0 > draft-premec-mext-extended-home-link= -01.txt, I noticed that=0A=A0=A0=A0 > this draft is about what I asked Char= lie last week during=0A=A0=A0=A0 > his presentation, i.e. sending BU at the= home link for=0A=A0=A0=A0 > something other than deregistration. As the dr= aft says in=0A=A0=A0=A0 > Sec. 4.1:=0A=A0=A0=A0 > When the MN returns home = to an IPv6-only home network,=0A=A0=A0=A0 > the MN sends ... BU=0A=A0=A0=A0= >=A0 I agree with Vijay that a flag must be defined=0A=A0=A0=A0 > and set = for this purpose because normally this is not=0A=A0=A0=A0 > allowed and HA = must probably reject such a BU. A flag=0A=A0=A0=A0 > to this end has alread= y been suggested in=0A=A0=A0=A0 > draft-devarapalli-mext-mipv6-home-link-01= as C flag.=0A=A0=A0=A0 >=A0 =0A=A0=A0=A0 > Regards,=0A=A0=A0=A0 >=A0 =0A= =A0=A0=A0 > Behcet=0A=A0=A0=A0 > =0A=A0=A0=A0 > =0A=A0=A0=A0 >=A0 =A0 =A0 = =0A=A0=A0=A0 > -----Inline-vedh=E6ftet fil f=F8lger-----=0A=A0=A0=A0 > =0A= =A0=A0=A0 > _______________________________________________=0A=A0=A0=A0 > M= EXT mailing list=0A=A0=A0=A0 > MEXT@ietf.org=0A=A0=A0=A0 > https://www.ietf= ..org/mailman/listinfo/mext=0A=A0=A0=A0 > =0A=A0=A0=A0 =0A=0A=0A=A0 =A0 =A0 = Tr=E6nger du til at se det store billede? Kelkoo giver dig gode tilbud p=E5= LCD TV! Se her http://dk.yahoo.com/r/pat/lcd=0A=0A=0A=0A --0-1706999005-1238774193=:77230 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
A bit (C-bit, whatever bit) is needed to indicate a no= n-deregistration BU sent at the home link. Maybe the right place is 3775bis= .. I was trying to indicate this last week in mext session, but Marcelo cut = me off saying that the issues with 3775bis have been closed.
=0A
&= nbsp;
=0A
Once this bit is defined, draft-premec can have a normat= ive statement to require this bit be set and then introduce IPv4 HoA issue.=
=0A
 
=0A
This is my understanding.
=0A
&n= bsp;
=0A
Regards,
=0A
 
=0A
Behcet
=0A

=0A
=0A
=0AFrom: Christian Kaas-Petersen <= kaaspetersen@yahoo.dk>
To: Domagoj Premec <domagoj.premec.ext@nsn.com>; mext@ietf.org; Beh= cet Sarikaya <sarikaya@ieee.org>
Sent: Friday, April 3, 2009 3:36:44 AM
Subject: Re: SV: [MEXT] draft-premec-mext-ext= ended-home-link-01


Proposal: Introduce a Tunnel (T) bit i= n the BU to signal an
IPv4 tunnel to be created on the home link.
Introducing modified semantics on mobility options appearing in
BUs s= ent the home link (as done in draft-premec) is not the way ahead.  The reason is simplificy of design: one option has one purpose.

The= C-bit in the BU has been suggested as a way to signal the
BU is sent on= the home link for the purpose of configuration
(done in draft-devarapalli).  What exactly to be configured
depends on the = mobility options present.

This mail suggest a T-bit in the BU as a w= ay to signal a tunnel
to be established.  Currently, only one tunne= l is foreseen, namely
the IPv4-in-IPv6 tunnel for IPv4 traffic over an I= Pv6-only home
link.  The tunnel is indicated with the IPv4 Home Add= ress mobility
option.  The tunnel could be established as the entry=
v4HoA -> v6HoA in the binding cache.  The T-bit may be set, onl= y
when also the C-bit is set.  Having T-bit set and C-bit clear
= is an error.  Having T-bit set and IPv4 Home Address mobility
optio= n missing is probly an error.  There should be no need
to include = IPv4 Care-of Address mobility option, as its content
will be the same as= the IPv4 Home Address mobility option.

Not clear what the BU's life= time should be.  With the C-bit set,
configurations can be done, for example to obtain an IPv4 home
address or a NEMO mobile netwo= rk prefix.  The values returned
may be dynamically assigned by the = home agent.  The home agent
would probably be interested in knowing= for how long time the
assigned values will be used.  A practical s= olution for this
is to say the assignment is valid as long as the mobile= node
remains on the home link and as long as the IKE session
is aliv= e between the mobile node and the home agent.

Christian


=


--- Den tors 2/4/09 skrev Behcet Sarikaya <behc= etsarikaya@yahoo.com>:


Fra: Behcet Sarikaya <behcetsarikaya@yahoo.com>
Emne: Re: SV: [MEXT] draft-premec= -mext-extended-home-link-01
Til: "Domagoj Premec" <domagoj.premec.ext@nsn.com>, "Christian Kaas-Petersen= " <kaaspetersen@yahoo.dk>, mext@ietf.org
Dato: torsdag 2. ap= ril 2009 16.55






Hi Domagoj,
  You need to= indicate to HA that this is a non-deregistration BU sent from the home lin= k. So the correct way is to define a flag at the BU message like the C flag= in http://tools.ietf.org/id/draft-devarapalli-mext-mipv6-home-link-01.txt<= BR>  Of course HA may also set the C flag in its reply of BA message. = I think this was what Vijay was commenting on last week at the mext meeting= ..
  Yes, IPv4 HoA option has some bits available but these would ap= ply to this option not to the BU message, I think it would be wrong to defi= ne this bit there.
  Regards,
 
Behcet




=
From: Domagoj Premec <domagoj.premec.ext@nsn.com>
To: Behcet Sarikaya <sarikaya@ieee.org>; Christian Kaas-P= etersen <kaaspetersen@yahoo.dk>; mext@ietf.org
Cc: Charles E= .. Perkins <charliep@wichorus.com>
Sent: Thursday, April= 2, 2009 4:40:13 AM
Subject: RE: SV: [MEXT] draft-premec-mext-extended-h= ome-link-01

Behcet,

In draft-devarapalli-mext-mipv6-home-link= -01 the C flag is being defined as
part of the BU and Back messages. Giv= en that draft-premec-extended-home-link
is about registering for the v4 service= from the IPv6-only home link, there
is always the IPv4 HoA option inclu= ded and in this case it may be more
appropriate to define the new flag a= s part of the IPv4 HoA option. This
would save the flag space in the BU/= Back without having disadvantages in the
extended home link scenario.
domagoj



________________________________

 &= nbsp;  From: ext Behcet Sarikaya [mailto:behcetsarikaya@y= ahoo.com]
    Sent: 01. travanj 2009 16:39
 =    To: Christian Kaas-Petersen; mext@ietf.org
    Cc= : Charles E. Perkins; Domagoj Premec
    Subject: Re: SV:= [MEXT] draft-premec-mext-extended-home-link-01
   
   
    Hi Christian,
  = ;    I am OK redefining the C Flag for this purpose. If other use= s come
up they should make their own case, I think.
   = ;
    Regards,
   
  &nb= sp; Behcet
   

    _______________= _________________

    From: Christian Kaas-Petersen &= lt;kaaspetersen@yahoo.dk>
    To: mext@ietf.org; Behcet Sarikaya <sarikaya@ieee.org>
    Cc: C= harles E. Perkins <charliep@wichorus.com>; Domagoj Premec<= BR><domagoj.premec.ext@nsn.com>
    Sen= t: Wednesday, April 1, 2009 2:31:59 AM
    Subject: SV: [= MEXT] (no subject)
   
   
 &= nbsp;  The C flag, as defined in draft-devarapalli, means the home age= nt
    shall do various processing, but shall not create = an entry in the
    binding cache.  However, draft-p= remec requires an entry in the
    binding cache to be cr= eated in order to tunnel IPv4 packets.
    So, either the= semantics of the C flag shall be extended or
    another= flag shall be defined.  What is your suggestion?
   = ;
    Christian
   
  &n= bsp;
    --- Den tirs 31/3/09 skrev Behcet Sarikaya
<behcetsarikaya@yahoo.com>:
 &n= bsp; 
    > Fra: Behcet Sarikaya <behcetsarikaya@yahoo.com>
    > Emne: [MEXT] = (no subject)
    > Til: mext@ietf.org
   = > Cc: "Charles E. Perkins" <charliep@wichorus.com>, "D= omagoj Premec"
<domagoj.premec.ext@nsn.com>    > Dato: tirsdag 31. marts 2009 22.19
  = ;  > Hello all,
    >  Regarding
 = ;   > draft-premec-mext-extended-home-link-01.txt, I noticed that
 =    > this draft is about what I asked Charlie last week during=
    > his presentation, i.e. sending BU at the home l= ink for
    > something other than deregistration. As = the draft says in
    > Sec. 4.1:
   = ; > When the MN returns home to an IPv6-only home network,
 &nbs= p;  > the MN sends ... BU
    >  I agree = with Vijay that a flag must be defined
    > and set f= or this purpose because normally this is not
    > all= owed and HA must probably reject such a BU. A flag
    &g= t; to this end has already been suggested in
    > dra= ft-devarapalli-mext-mipv6-home-link-01 as C flag.
    >= ; 
    > Regards,
    > 
    > Behcet
    > <= BR>    >
    >      =
    > -----Inline-vedh=E6ftet fil f=F8lger-----
&n= bsp;   >
    > _________________________= ______________________
    > MEXT mailing list
&nbs= p;   > MEXT@ietf.org
    > https://www.ietf.org/ma= ilman/listinfo/mext
    >
    <= BR>

      Tr=E6nger du til at se det store billede? K= elkoo giver dig gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/l= cd

=0A=0A=0A=0A --0-1706999005-1238774193=:77230-- From vidyan@qualcomm.com Mon Apr 6 15:08:03 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B043A67AE; Mon, 6 Apr 2009 15:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.222 X-Spam-Level: X-Spam-Status: No, score=-103.222 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 LV1YYmYKSKHs; Mon, 6 Apr 2009 15:08:02 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C41C03A67E3; Mon, 6 Apr 2009 15:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1239055749; x=1270591749; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"netlmm@ietf.org"=20|CC:=20"mext@ietf .org"=20|Date:=20Mon,=206=20Apr=202009=201 5:09:03=20-0700|Subject:=20RE:=20WGLC=20on=20draft-ietf-n etlmm-mip-interactions|Thread-Topic:=20WGLC=20on=20draft- ietf-netlmm-mip-interactions|Thread-Index:=20AcmmfqWxriK7 5kW8TA2R0bgUstwKaQHKeUcgAlNvl/A=3D|Message-ID:=20|References:=20=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5576"=3B=20a=3D"16917063"; bh=EfItv4UBPSisasyaI8b6JrB4wE/qRkoXHZLUnV6W/cs=; b=o/vrzzhf5jEQdHjYrKxTVPQMK/HJh6X0sPoMRd+rdWYKQpgun+YL+kNy 32CLmWt/RDLeEo1evy7m7mgcNNetW95BKLinGMOzBOVKHTqqkeqMQc5EF szQK8yRmntwbHWBSqQnpu7P6W6yskFbrYZV/q4hYGttWkOXriO3uLqdAF 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5576"; a="16917063" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2009 15:09:08 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n36M98kW024935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Apr 2009 15:09:08 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n36M9734029476 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 6 Apr 2009 15:09:07 -0700 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 6 Apr 2009 15:09:06 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.12]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Mon, 6 Apr 2009 15:09:05 -0700 From: "Narayanan, Vidya" To: "netlmm@ietf.org" Date: Mon, 6 Apr 2009 15:09:03 -0700 Thread-Topic: WGLC on draft-ietf-netlmm-mip-interactions Thread-Index: AcmmfqWxriK75kW8TA2R0bgUstwKaQHKeUcgAlNvl/A= Message-ID: References: In-Reply-To: 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 Cc: "mext@ietf.org" Subject: Re: [MEXT] WGLC on draft-ietf-netlmm-mip-interactions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 22:08:03 -0000 We have had exactly 3 responses to this LC. The document cannot move forwa= rd without sufficient indication of WG review and support. I am extending = this LC until April 15th, to give people a bit after Easter to respond. I = believe there is a 3gpp dependency on this document, but, if we don't see e= nough interest from the WG in reviewing this document, we will be unable to= publish it.=20 Thanks, Vidya > -----Original Message----- > From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On > Behalf Of Narayanan, Vidya > Sent: Wednesday, March 25, 2009 5:21 PM > To: netlmm@ietf.org > Cc: mext@ietf.org > Subject: Re: [netlmm] WGLC on draft-ietf-netlmm-mip-interactions >=20 > Hi, > This is a reminder of the last call. No reviews or comments have been > received so far. If you have read it and have no comments, please at > least respond to let us know if it is ready for publication. >=20 > Thanks, > Vidya >=20 > > -----Original Message----- > > From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On > > Behalf Of Narayanan, Vidya > > Sent: Monday, March 16, 2009 2:32 PM > > To: netlmm@ietf.org > > Subject: [netlmm] WGLC on draft-ietf-netlmm-mip-interactions > > > > Hi, > > This commences a WG last call on draft-ietf-netlmm-mip-interactions. > > The last call will end on April 3rd, 2009. The extra week is to > > accommodate for having the IETF meeting in the middle. > > > > Please review and post comments on the mailing list by this > timeframe. > > If you reviewed and think the document is ready for publication, > please > > also let us know that. > > > > Thanks, > > Vidya > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www.ietf.org/mailman/listinfo/netlmm > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm From charles.perkins@earthlink.net Mon Apr 6 15:38:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B4D3A6B77 for ; Mon, 6 Apr 2009 15:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.220, 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 MKYgg5KgkWGk for ; Mon, 6 Apr 2009 15:38:03 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id B4EF23A67FD for ; Mon, 6 Apr 2009 15:38:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZizGlQF4LjJwe+Nfb2xOEpFGVhfzbcbLlQHjMGbtIUo32bF5jL9qf/gR3s+iHipI; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.138]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LqxSm-0007S1-6j; Mon, 06 Apr 2009 18:38:44 -0400 Message-ID: <49DA845A.2050704@earthlink.net> Date: Mon, 06 Apr 2009 15:38:18 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Vijay Devarapalli References: <49D0F194.9050708@wichorus.com> In-Reply-To: <49D0F194.9050708@wichorus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ce24296476e2c591561323d6e78e9fd2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: mext Subject: Re: [MEXT] Text for Binding Update Race condition issue X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 22:38:05 -0000 Hello Vijay, I think that the proper home for the text you contributed is in section 10.3.2. Primary Care-of Address De-Registration. Unfortunately, it isn't very natural to drop the text in directly as given without any changes. I thought it would be best to rearrange the text a bit, essentially putting all of the text for handling the deferred BCE removal after the description for sending the Binding Acknowledgement. Here is the result: ======================================================================== A Binding Update is validated and authorized in the manner described in the previous section; note that when the mobile node de-registers when it is at home, it MAY choose to omit the Home Address destination option, in which case the mobile node's home address is the source IP address of the de-registration Binding Update. This section describes the processing of a valid Binding Update that requests the receiving node to no longer serve as its home agent, de-registering its primary care-of address. To begin processing the Binding Update, the home agent MUST perform the following test: o If the receiving node has no entry marked as a home registration in its Binding Cache for this mobile node, then this node MUST reject the Binding Update and SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to 133 (not home agent for this mobile node). If the home agent does not reject the Binding Update as described above, then the home agent MUST return a Binding Acknowledgement to the mobile node, constructed as follows: o The Status field MUST be set to a value 0, indicating success. o The Key Management Mobility Capability (K) bit is set or cleared and actions based on its value are performed as described in the previous section. The mobile node's home address is used as its new care-of address for the purposes of moving the key management connection to a new endpoint. o The Sequence Number field MUST be copied from the Sequence Number given in the Binding Update. o The Lifetime field MUST be set to zero. o The Binding Refresh Advice mobility option MUST be omitted. The rules for selecting the Destination IP address (and, if required, routing header construction) for the Binding Acknowledgement to the mobile node are the same as in the previous section. When the Status field in the Binding Acknowledgement is greater than or equal to 128 and the Source Address of the Binding Update is on the home link, the home agent MUST send it to the mobile node's link layer address (retrieved either from the Binding Update or through Neighbor Solicitation). When a mobile node sends a binding update to refresh the binding from the visited link and soon after moves to the home link and sends a de-registration binding update, a race condition can happen if the first binding update gets delayed. The delayed binding update can cause the home agent to create a new binding cache entry for a mobile node that had just attached to the home link and successfully deleted the binding. This would prevent the mobile node from using its home address from the home link. In order to prevent this, the home agent SHOULD NOT remove the binding cache entry immediately after receiving the deregistration binding update from the mobile node. It SHOULD mark the binding cache entry as invalid, and MUST stop intercepting packets on the mobile node's home link that are addressed to the mobile node (Section 10.4.1). The home agent should wait for MAX_DELETE_BCE_TIMEOUT seconds before removing the binding cache entry completely. In the scenario described above, if the home agent receives the delayed binding update that the mobile node sent from the visited link, it would reject the message since the sequence number would be less than the last received deregistration binding update from the home link. The home agent would then send a Binding Acknowledgment with status '135' (Sequence number out of window) to the care of address on the visited link. The mobile node can continue using the home address from the home link. ======================================================== I also fixed a minor problem with wording in the section using an ambiguous "may not". Comments? Regards, Charlie P. Vijay Devarapalli wrote: > George Tsirtsis wrote: >> Hi Vijay, >> >> The logic of the text is fine with me, thanks. >> >> I am not so sure about the 120sec timeout though...it sounds completly >> over the top. This is supposed to catch packets that have been delayed >> in reaching the HA. That should not be much more than the max >> half-RTT for the Internet. Typical values >> these days are usualy some hundreds of milliseconds, so a few seconds >> would suffice as a MAX ... I would say no more than 10seconds. >> >> Thoughts? > > Agree. 10 seconds or less makes more sense for the default value. > > Vijay > >> George >> >> On Wed, Mar 25, 2009 at 10:30 PM, Vijay Devarapalli >> wrote: >>> Hi Charlie, >>> >>> Here is some text that you could perhaps use for the issue you pointed >>> out on slide 7 at >>> http://www3.ietf.org/proceedings/09mar/slides/mext-0.ppt >>> >>> >>> When a mobile node sends a binding update to refresh the binding >>> from the visited link and soon after moves to the home link and >>> sends a de-registration binding update, a race condition can >>> happen if the first binding update gets delayed. The delayed >>> binding update can cause the home agent to create a new binding >>> cache entry for a mobile node that had just attached to the home >>> link and successfully deleted the binding. This would prevent the >>> mobile node from using its home address from the home link. >>> >>> In order to prevent this, the home agent SHOULD NOT remove the >>> binding cache entry immediately after receiving the deregistration >>> binding update from the mobile node. It SHOULD mark the binding >>> cache entry as invalid, and stop proxying for the mobile node's >>> home address. The home agent should wait for MAX_DELETE_BCE_TIMEOUT >>> seconds before removing the binding cache entry completely. In the >>> scenario described above, if the home agent receives the delayed >>> binding update that the mobile node sent from the visited link, it >>> would reject the message since the sequence number would be less >>> than the last received deregistration binding update from the home >>> link. The home agent would then send a Binding Acknowledgment with >>> status '135' (Sequence number out of window) to the care of address >>> on the visited link. The mobile node can continue using the home >>> address from the home link. >>> >>> >>> MAX_DELETE_BCE_TIMEOUT 120 seconds >>> >>> I didn't try to figure out which section this text would go into. >>> >>> Feel free to modify the text. >>> >>> Vijay >>> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From vijay@wichorus.com Mon Apr 6 17:30:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F2F3A693E for ; Mon, 6 Apr 2009 17:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Md6RmEEQT1sp for ; Mon, 6 Apr 2009 17:30:51 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 29DF03A6D40 for ; Mon, 6 Apr 2009 17:30:49 -0700 (PDT) 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: Mon, 6 Apr 2009 20:31:51 -0400 Message-ID: In-Reply-To: <49DA845A.2050704@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Text for Binding Update Race condition issue Thread-Index: Acm3CIDhFjHAqOfXRgOPahSxBoDmBAAD4dIg References: <49D0F194.9050708@wichorus.com> <49DA845A.2050704@earthlink.net> From: "Vijay Devarapalli" To: "Charles E. Perkins" Cc: mext Subject: Re: [MEXT] Text for Binding Update Race condition issue X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 00:30:56 -0000 Hi Charlie, It looks good. Thanks Vijay > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@earthlink.net]=20 > Sent: Monday, April 06, 2009 3:38 PM > To: Vijay Devarapalli > Cc: mext > Subject: Re: [MEXT] Text for Binding Update Race condition issue >=20 >=20 > Hello Vijay, >=20 > I think that the proper home for the text you contributed is in > section 10.3.2. Primary Care-of Address De-Registration. >=20 > Unfortunately, it isn't very natural to drop the text in directly as > given without any changes. I thought it would be best to rearrange > the text a bit, essentially putting all of the text for handling the > deferred BCE removal after the description for sending the > Binding Acknowledgement. >=20 > Here is the result: >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > A Binding Update is validated and authorized in the manner=20 > described > in the previous section; note that when the mobile node=20 > de-registers > when it is at home, it MAY choose to omit the Home Address=20 > destination > option, in which case the mobile node's home address is=20 > the source IP > address of the de-registration Binding Update. This section > describes the processing of a valid Binding Update that=20 > requests the > receiving node to no longer serve as its home agent, de-registering > its primary care-of address. >=20 > To begin processing the Binding Update, the home agent MUST perform > the following test: >=20 > o If the receiving node has no entry marked as a home registration > in its Binding Cache for this mobile node, then this node MUST > reject the Binding Update and SHOULD return a Binding > Acknowledgement to the mobile node, in which the Status field is > set to 133 (not home agent for this mobile node). >=20 > If the home agent does not reject the Binding Update as described > above, then the home agent MUST return a Binding Acknowledgement > to the mobile node, constructed as follows: >=20 > o The Status field MUST be set to a value 0, indicating success. >=20 > o The Key Management Mobility Capability (K) bit is set or cleared > and actions based on its value are performed as described in the > previous section. The mobile node's home address is used as its > new care-of address for the purposes of moving the key=20 > management > connection to a new endpoint. >=20 > o The Sequence Number field MUST be copied from the=20 > Sequence Number > given in the Binding Update. >=20 > o The Lifetime field MUST be set to zero. >=20 > o The Binding Refresh Advice mobility option MUST be omitted. >=20 > The rules for selecting the Destination IP address (and,=20 > if required, > routing header construction) for the Binding Acknowledgement to the > mobile node are the same as in the previous section. When=20 > the Status > field in the Binding Acknowledgement is greater than or=20 > equal to 128 > and the Source Address of the Binding Update is on the=20 > home link, the > home agent MUST send it to the mobile node's link layer address > (retrieved either from the Binding Update or through Neighbor > Solicitation). >=20 > When a mobile node sends a binding update to refresh the binding > from the visited link and soon after moves to the home link and > sends a de-registration binding update, a race condition can > happen if the first binding update gets delayed. The delayed > binding update can cause the home agent to create a new binding > cache entry for a mobile node that had just attached to the home > link and successfully deleted the binding. This would prevent the > mobile node from using its home address from the home link. > =20 > In order to prevent this, the home agent SHOULD NOT remove the > binding cache entry immediately after receiving the deregistration > binding update from the mobile node. It SHOULD mark the binding > cache entry as invalid, and MUST stop intercepting packets on the > mobile node's home link that are addressed to the mobile node > (Section 10.4.1). The home agent should wait for=20 > MAX_DELETE_BCE_TIMEOUT > seconds before removing the binding cache entry completely. In the > scenario described above, if the home agent receives the delayed > binding update that the mobile node sent from the visited link, it > would reject the message since the sequence number would be less > than the last received deregistration binding update from the home > link. The home agent would then send a Binding Acknowledgment with > status '135' (Sequence number out of window) to the care of address > on the visited link. The mobile node can continue using the home > address from the home link. > =20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > I also fixed a minor problem with wording in the section using > an ambiguous "may not". >=20 > Comments? >=20 > Regards, > Charlie P. >=20 >=20 >=20 >=20 > Vijay Devarapalli wrote: > > George Tsirtsis wrote: > >> Hi Vijay, > >> > >> The logic of the text is fine with me, thanks. > >> > >> I am not so sure about the 120sec timeout though...it=20 > sounds completly > >> over the top. This is supposed to catch packets that have=20 > been delayed > >> in reaching the HA. That should not be much more than the max > >> half-RTT for the Internet. Typical values > >> these days are usualy some hundreds of milliseconds, so a=20 > few seconds > >> would suffice as a MAX ... I would say no more than 10seconds. > >> > >> Thoughts? > > > > Agree. 10 seconds or less makes more sense for the default value. > > > > Vijay > > > >> George > >> > >> On Wed, Mar 25, 2009 at 10:30 PM, Vijay Devarapalli=20 > >> wrote: > >>> Hi Charlie, > >>> > >>> Here is some text that you could perhaps use for the=20 > issue you pointed > >>> out on slide 7 at > >>> http://www3.ietf.org/proceedings/09mar/slides/mext-0.ppt > >>> > >>> > >>> When a mobile node sends a binding update to refresh the binding > >>> from the visited link and soon after moves to the home link and > >>> sends a de-registration binding update, a race condition can > >>> happen if the first binding update gets delayed. The delayed > >>> binding update can cause the home agent to create a new binding > >>> cache entry for a mobile node that had just attached to the home > >>> link and successfully deleted the binding. This would prevent the > >>> mobile node from using its home address from the home link. > >>> > >>> In order to prevent this, the home agent SHOULD NOT remove the > >>> binding cache entry immediately after receiving the=20 > deregistration > >>> binding update from the mobile node. It SHOULD mark the binding > >>> cache entry as invalid, and stop proxying for the mobile node's > >>> home address. The home agent should wait for=20 > MAX_DELETE_BCE_TIMEOUT > >>> seconds before removing the binding cache entry=20 > completely. In the > >>> scenario described above, if the home agent receives the delayed > >>> binding update that the mobile node sent from the=20 > visited link, it > >>> would reject the message since the sequence number would be less > >>> than the last received deregistration binding update=20 > from the home > >>> link. The home agent would then send a Binding=20 > Acknowledgment with > >>> status '135' (Sequence number out of window) to the care=20 > of address > >>> on the visited link. The mobile node can continue using the home > >>> address from the home link. > >>> > >>> > >>> MAX_DELETE_BCE_TIMEOUT 120 seconds > >>> > >>> I didn't try to figure out which section this text would go into. > >>> > >>> Feel free to modify the text. > >>> > >>> Vijay > >>> > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > >=20 >=20 From root@core3.amsl.com Tue Apr 7 03:15:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A7CCD3A6DC2; Tue, 7 Apr 2009 03: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: <20090407101501.A7CCD3A6DC2@core3.amsl.com> Date: Tue, 7 Apr 2009 03:15:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-nemo-v4traversal-10.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 10: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 Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobile IPv6 Support for Dual Stack Hosts and Routers Author(s) : H. Soliman Filename : draft-ietf-mext-nemo-v4traversal-10.txt Pages : 48 Date : 2009-04-07 The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-10.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-mext-nemo-v4traversal-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-07030743.I-D@ietf.org> --NextPart-- From domagoj.premec@siemens.com Tue Apr 7 06:54:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0930B3A6818 for ; Tue, 7 Apr 2009 06:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=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 Z6ABXU5RcPBu for ; Tue, 7 Apr 2009 06:54:14 -0700 (PDT) Received: from mxs2.siemens.at (mxs2.siemens.at [194.138.12.133]) by core3.amsl.com (Postfix) with ESMTP id 847933A67AA for ; Tue, 7 Apr 2009 06:54:12 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id n37DtId4013073; Tue, 7 Apr 2009 15:55:18 +0200 Received: from nets138a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id n37Dt8wp011271; Tue, 7 Apr 2009 15:55:09 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 15:55:08 +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: Tue, 7 Apr 2009 15:55:03 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD68050FC914@zagh223a.ww300.siemens.net> In-Reply-To: <845063.45120.qm@web27807.mail.ukl.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SV: [MEXT] draft-premec-mext-extended-home-link-01 Thread-Index: Acm0N1NEhgAIbBDKQQCKvAAZAfNOswDTzvqQ References: <845063.45120.qm@web27807.mail.ukl.yahoo.com> From: "Premec, Domagoj" To: "ext Christian Kaas-Petersen" , , "Behcet Sarikaya" X-OriginalArrivalTime: 07 Apr 2009 13:55:08.0224 (UTC) FILETIME=[76237400:01C9B788] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::090407155518-088A2BA0-05C5F048/0-0/0-15 X-purgate-size: 8209/999999 Subject: Re: [MEXT] draft-premec-mext-extended-home-link-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 13:54:15 -0000 Christian, Behcet, I'm not clear on benefits of using the C bit, is there really a need to = require usage of two separate bits in the BU in the context of extended = home link support? I'd like the draft to be as self-contained as it = gets, this should help speed up the progress of the draft and avoiding = references to other drafts should help in that regard. It seems to me = that using only the T bit should suffice, are there any concerns that = make the use of C bit as defined in = draft-devarapalli-mext-mipv6-home-link necessary? Domagoj > -----Original Message----- > From: ext Christian Kaas-Petersen [mailto:kaaspetersen@yahoo.dk]=20 > Sent: 03. travanj 2009 10:37 > To: Domagoj Premec; mext@ietf.org; Behcet Sarikaya > Subject: Re: SV: [MEXT] draft-premec-mext-extended-home-link-01 >=20 >=20 > Proposal: Introduce a Tunnel (T) bit in the BU to signal an > IPv4 tunnel to be created on the home link. >=20 > Introducing modified semantics on mobility options appearing=20 > in BUs sent the home link (as done in draft-premec) is not=20 > the way ahead. =20 > The reason is simplificy of design: one option has one purpose. >=20 > The C-bit in the BU has been suggested as a way to signal the=20 > BU is sent on the home link for the purpose of configuration=20 > (done in draft-devarapalli). What exactly to be configured=20 > depends on the mobility options present. >=20 > This mail suggest a T-bit in the BU as a way to signal a=20 > tunnel to be established. Currently, only one tunnel is=20 > foreseen, namely the IPv4-in-IPv6 tunnel for IPv4 traffic=20 > over an IPv6-only home link. The tunnel is indicated with=20 > the IPv4 Home Address mobility option. The tunnel could be=20 > established as the entry v4HoA -> v6HoA in the binding cache.=20 > The T-bit may be set, only when also the C-bit is set. =20 > Having T-bit set and C-bit clear is an error. Having T-bit=20 > set and IPv4 Home Address mobility option missing is probly=20 > an error. There should be no need to include IPv4 Care-of=20 > Address mobility option, as its content will be the same as=20 > the IPv4 Home Address mobility option. >=20 > Not clear what the BU's lifetime should be. With the C-bit=20 > set, configurations can be done, for example to obtain an=20 > IPv4 home address or a NEMO mobile network prefix. The=20 > values returned may be dynamically assigned by the home=20 > agent. The home agent would probably be interested in=20 > knowing for how long time the assigned values will be used. =20 > A practical solution for this is to say the assignment is=20 > valid as long as the mobile node remains on the home link and=20 > as long as the IKE session is alive between the mobile node=20 > and the home agent.=20 >=20 > Christian >=20 >=20 >=20 >=20 >=20 > --- Den tors 2/4/09 skrev Behcet Sarikaya : >=20 >=20 > Fra: Behcet Sarikaya > Emne: Re: SV: [MEXT] draft-premec-mext-extended-home-link-01 > Til: "Domagoj Premec" ,=20 > "Christian Kaas-Petersen" , mext@ietf.org > Dato: torsdag 2. april 2009 16.55 >=20 >=20 >=20 >=20 >=20 >=20 > Hi Domagoj, > =A0 You need to indicate to HA that this is a=20 > non-deregistration BU sent from the home link. So the correct=20 > way is to define a flag at the BU message like the C flag in=20 > http://tools.ietf.org/id/draft-devarapalli-mext-mipv6-home-link-01.txt > =A0 Of course HA may also set the C flag in its reply of BA=20 > message. I think this was what Vijay was commenting on last=20 > week at the mext meeting. > =A0 Yes, IPv4 HoA option has some bits available but these=20 > would apply to this option not to the BU message, I think it=20 > would be wrong to define this bit there. > =A0 Regards, > =A0 > Behcet >=20 >=20 >=20 >=20 >=20 > From: Domagoj Premec > To: Behcet Sarikaya ; Christian=20 > Kaas-Petersen ; mext@ietf.org > Cc: Charles E. Perkins > Sent: Thursday, April 2, 2009 4:40:13 AM > Subject: RE: SV: [MEXT] draft-premec-mext-extended-home-link-01 >=20 > Behcet, >=20 > In draft-devarapalli-mext-mipv6-home-link-01 the C flag is=20 > being defined as part of the BU and Back messages. Given that=20 > draft-premec-extended-home-link is about registering for the=20 > v4 service from the IPv6-only home link, there is always the=20 > IPv4 HoA option included and in this case it may be more=20 > appropriate to define the new flag as part of the IPv4 HoA=20 > option. This would save the flag space in the BU/Back without=20 > having disadvantages in the extended home link scenario. >=20 > domagoj >=20 >=20 >=20 > ________________________________ >=20 > =A0=A0=A0 From: ext Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > =A0=A0=A0 Sent: 01. travanj 2009 16:39 > =A0=A0=A0 To: Christian Kaas-Petersen; mext@ietf.org > =A0=A0=A0 Cc: Charles E. Perkins; Domagoj Premec > =A0=A0=A0 Subject: Re: SV: [MEXT] = draft-premec-mext-extended-home-link-01 > =A0=A0=A0=20 > =A0=A0=A0=20 > =A0=A0=A0 Hi Christian, > =A0=A0=A0 =A0 I am OK redefining the C Flag for this purpose. If=20 > other uses come up they should make their own case, I think. > =A0=A0=A0=20 > =A0=A0=A0 Regards, > =A0=A0=A0=20 > =A0=A0=A0 Behcet > =A0=A0=A0=20 >=20 > =A0=A0=A0 ________________________________ >=20 > =A0=A0=A0 From: Christian Kaas-Petersen > =A0=A0=A0 To: mext@ietf.org; Behcet Sarikaya > =A0=A0=A0 Cc: Charles E. Perkins ; Domagoj=20 > Premec > =A0=A0=A0 Sent: Wednesday, April 1, 2009 2:31:59 AM > =A0=A0=A0 Subject: SV: [MEXT] (no subject) > =A0=A0=A0=20 > =A0=A0=A0=20 > =A0=A0=A0 The C flag, as defined in draft-devarapalli, means the home = agent > =A0=A0=A0 shall do various processing, but shall not create an entry = in the > =A0=A0=A0 binding cache.=A0 However, draft-premec requires an entry in = the > =A0=A0=A0 binding cache to be created in order to tunnel IPv4 packets. > =A0=A0=A0 So, either the semantics of the C flag shall be extended or > =A0=A0=A0 another flag shall be defined.=A0 What is your suggestion? > =A0=A0=A0=20 > =A0=A0=A0 Christian > =A0=A0=A0=20 > =A0=A0=A0=20 > =A0=A0=A0 --- Den tirs 31/3/09 skrev Behcet Sarikaya > : > =A0=A0=A0=20 > =A0=A0=A0 > Fra: Behcet Sarikaya > =A0=A0=A0 > Emne: [MEXT] (no subject) > =A0=A0=A0 > Til: mext@ietf.org > =A0=A0=A0 > Cc: "Charles E. Perkins" ,=20 > "Domagoj Premec" > > =A0=A0=A0 > Dato: tirsdag 31. marts 2009 22.19 > =A0=A0=A0 > Hello all, > =A0=A0=A0 >=A0 Regarding > =A0=A0=A0 > draft-premec-mext-extended-home-link-01.txt, I noticed = that > =A0=A0=A0 > this draft is about what I asked Charlie last week during > =A0=A0=A0 > his presentation, i.e. sending BU at the home link for > =A0=A0=A0 > something other than deregistration. As the draft says in > =A0=A0=A0 > Sec. 4.1: > =A0=A0=A0 > When the MN returns home to an IPv6-only home network, > =A0=A0=A0 > the MN sends ... BU > =A0=A0=A0 >=A0 I agree with Vijay that a flag must be defined > =A0=A0=A0 > and set for this purpose because normally this is not > =A0=A0=A0 > allowed and HA must probably reject such a BU. A flag > =A0=A0=A0 > to this end has already been suggested in > =A0=A0=A0 > draft-devarapalli-mext-mipv6-home-link-01 as C flag. > =A0=A0=A0 > > =A0=A0=A0 > Regards, > =A0=A0=A0 > > =A0=A0=A0 > Behcet > =A0=A0=A0 > > =A0=A0=A0 > > =A0=A0=A0 > > =A0=A0=A0 > -----Inline-vedh=E6ftet fil f=F8lger----- > =A0=A0=A0 > > =A0=A0=A0 > _______________________________________________ > =A0=A0=A0 > MEXT mailing list > =A0=A0=A0 > MEXT@ietf.org > =A0=A0=A0 > https://www.ietf.org/mailman/listinfo/mext > =A0=A0=A0 >=20 > =A0=A0=A0=20 >=20 >=20 > Tr=E6nger du til at se det store billede? Kelkoo giver=20 > dig gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd >=20 From behcetsarikaya@yahoo.com Tue Apr 7 07:42:24 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322A43A68D1 for ; Tue, 7 Apr 2009 07:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=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 JBGT9n8G-wEu for ; Tue, 7 Apr 2009 07:42:22 -0700 (PDT) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id 892E73A67D2 for ; Tue, 7 Apr 2009 07:42:22 -0700 (PDT) Received: (qmail 10447 invoked by uid 60001); 7 Apr 2009 14:42:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1239115375; bh=QlIgSWNTLRtVlOQEHP6wjzTnCXFbh56hR5itckiPmos=; 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=yv6t29hskyRsTgjSwCVusH20O468TCEXergta97RzzZ+8STQjN4hEaLzplACwkV30zPRKliNIBInumzlM9Ks2YDpjTHHxiW7YY6q9gxE5r3LAPoeZBWZTY/Po1WEeWtL4sdTIZ/mGCLakjuGUYEXHhwoMUkmsDryVJFigHe1naE= 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=WACr66tlOoHPg8hlvpjTwbeWZqWRk4hD6VlsUSkhzBFMsohVgxG9b/NlfgbL+OiK6bl8LgXOvpGInm8d64hHnj8QCPSp+RdLStpnNkW9eIdFt2ijhEv9QVr1zqBch3sJSfe6oBqoYd7Sduio0VXqSbGUCetkQb2q9AMnCDRQ4/E=; Message-ID: <467756.4723.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: 2nUTVGQVM1laDYMg9rmCQZL9j8uCfUjuitz5K7jMradsry.Ls5F7Nz84KWDjklu2UPma92.WM5nqfCuma6KUKFv9.0Z5motWZ5mRWMoxIwd7nnuICJZKCTKMuGLq7e9TXpq3Pu9oZTlCZCxlz4TieGcmO_O1mM_zzO711Waf1PCEuocY6Wy_QwQG_02VwXTB7dd70N1lFAhn9vRSTDPPUVJJTs8ZFjC8MIpyDp31ggrBOnquq8LD6b1bB.BWSqck9dpV7LdhyZRmnDdXbk3fIDOTEG_lT4CvgnUZFrOXZ.LUAoqFhJYS56.JL.ngTrzsizxU Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Tue, 07 Apr 2009 07:42:55 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <845063.45120.qm@web27807.mail.ukl.yahoo.com> <3C31CDD06342EA4A8137716247B1CD68050FC914@zagh223a.ww300.siemens.net> Date: Tue, 7 Apr 2009 07:42:55 -0700 (PDT) From: Behcet Sarikaya To: "Premec, Domagoj" , ext Christian Kaas-Petersen , mext@ietf.org In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68050FC914@zagh223a.ww300.siemens.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1028573066-1239115375=:4723" Cc: "Charles E. Perkins" Subject: Re: [MEXT] draft-premec-mext-extended-home-link-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 14:42:24 -0000 --0-1028573066-1239115375=:4723 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Domagoj,=0A=A0 I am not sure if you can avoid the C bit because without it = HA will reject the BU before it gets to the T bit.=0A=A0 Because of that I = am not sure if T bit is of any use at all.=0A=A0 Maybe you can negotiate wi= th Charlie/Vijay?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A_________________= _______________=0AFrom: "Premec, Domagoj" =0ATo= : ext Christian Kaas-Petersen ; mext@ietf.org; Behce= t Sarikaya =0ASent: Tuesday, April 7, 2009 8:55:03 AM=0A= Subject: RE: SV: [MEXT] draft-premec-mext-extended-home-link-01=0A=0AChrist= ian, Behcet,=0A=0AI'm not clear on benefits of using the C bit, is there re= ally a need to require usage of two separate bits in the BU in the context = of extended home link support? I'd like the draft to be as self-contained a= s it gets, this should help speed up the progress of the draft and avoiding= references to other drafts should help in that regard. It seems to me that= using only the T bit should suffice, are there any concerns that make the = use of C bit as defined in draft-devarapalli-mext-mipv6-home-link necessary= ?=0A=0ADomagoj=0A=0A> -----Original Message-----=0A> From: ext Christian Ka= as-Petersen [mailto:kaaspetersen@yahoo.dk] =0A> Sent: 03. travanj 2009 10:3= 7=0A> To: Domagoj Premec; mext@ietf.org; Behcet Sarikaya=0A> Subject: Re: S= V: [MEXT] draft-premec-mext-extended-home-link-01=0A> =0A> =0A> Proposal: I= ntroduce a Tunnel (T) bit in the BU to signal an=0A> IPv4 tunnel to be crea= ted on the home link.=0A> =0A> Introducing modified semantics on mobility o= ptions appearing =0A> in BUs sent the home link (as done in draft-premec) i= s not =0A> the way ahead.=A0 =0A> The reason is simplificy of design: one o= ption has one purpose.=0A> =0A> The C-bit in the BU has been suggested as a= way to signal the =0A> BU is sent on the home link for the purpose of conf= iguration =0A> (done in draft-devarapalli).=A0 What exactly to be configure= d =0A> depends on the mobility options present.=0A> =0A> This mail suggest = a T-bit in the BU as a way to signal a =0A> tunnel to be established.=A0 Cu= rrently, only one tunnel is =0A> foreseen, namely the IPv4-in-IPv6 tunnel f= or IPv4 traffic =0A> over an IPv6-only home link.=A0 The tunnel is indicate= d with =0A> the IPv4 Home Address mobility option.=A0 The tunnel could be = =0A> established as the entry v4HoA -> v6HoA in the binding cache. =0A>=A0 = The T-bit may be set, only when also the C-bit is set.=A0 =0A> Having T-bit= set and C-bit clear is an error.=A0 Having T-bit =0A> set and IPv4 Home Ad= dress mobility option missing is probly =0A> an error.=A0 There should be n= o need to include IPv4 Care-of =0A> Address mobility option, as its content= will be the same as =0A> the IPv4 Home Address mobility option.=0A> =0A> N= ot clear what the BU's lifetime should be.=A0 With the C-bit =0A> set, conf= igurations can be done, for example to obtain an =0A> IPv4 home address or = a NEMO mobile network prefix.=A0 The =0A> values returned may be dynamicall= y assigned by the home =0A> agent.=A0 The home agent would probably be inte= rested in =0A> knowing for how long time the assigned values will be used.= =A0 =0A> A practical solution for this is to say the assignment is =0A> val= id as long as the mobile node remains on the home link and =0A> as long as = the IKE session is alive between the mobile node =0A> and the home agent. = =0A> =0A> Christian=0A> =0A> =0A> =0A> =0A> =0A> --- Den tors 2/4/09 skrev = Behcet Sarikaya :=0A> =0A> =0A> Fra: Behcet Sarik= aya =0A> Emne: Re: SV: [MEXT] draft-premec-mext-e= xtended-home-link-01=0A> Til: "Domagoj Premec" = , =0A> "Christian Kaas-Petersen" , mext@ietf.org=0A>= Dato: torsdag 2. april 2009 16.55=0A> =0A> =0A> =0A> =0A> =0A> =0A> Hi Dom= agoj,=0A> =A0 You need to indicate to HA that this is a =0A> non-deregistra= tion BU sent from the home link. So the correct =0A> way is to define a fla= g at the BU message like the C flag in =0A> http://tools.ietf.org/id/draft-= devarapalli-mext-mipv6-home-link-01.txt=0A> =A0 Of course HA may also set t= he C flag in its reply of BA =0A> message. I think this was what Vijay was = commenting on last =0A> week at the mext meeting.=0A> =A0 Yes, IPv4 HoA opt= ion has some bits available but these =0A> would apply to this option not t= o the BU message, I think it =0A> would be wrong to define this bit there.= =0A> =A0 Regards,=0A> =A0=0A> Behcet=0A> =0A> =0A> =0A> =0A> =0A> From: Dom= agoj Premec =0A> To: Behcet Sarikaya ; Christian =0A> Kaas-Petersen ; mext@ietf.= org=0A> Cc: Charles E. Perkins =0A> Sent: Thursday, = April 2, 2009 4:40:13 AM=0A> Subject: RE: SV: [MEXT] draft-premec-mext-exte= nded-home-link-01=0A> =0A> Behcet,=0A> =0A> In draft-devarapalli-mext-mipv6= -home-link-01 the C flag is =0A> being defined as part of the BU and Back m= essages. Given that =0A> draft-premec-extended-home-link is about registeri= ng for the =0A> v4 service from the IPv6-only home link, there is always th= e =0A> IPv4 HoA option included and in this case it may be more =0A> approp= riate to define the new flag as part of the IPv4 HoA =0A> option. This woul= d save the flag space in the BU/Back without =0A> having disadvantages in t= he extended home link scenario.=0A> =0A> domagoj=0A> =0A> =0A> =0A> _______= _________________________=0A> =0A> =A0=A0=A0 From: ext Behcet Sarikaya [mai= lto:behcetsarikaya@yahoo.com]=0A> =A0=A0=A0 Sent: 01. travanj 2009 16:39=0A= > =A0=A0=A0 To: Christian Kaas-Petersen; mext@ietf.org=0A> =A0=A0=A0 Cc: Ch= arles E. Perkins; Domagoj Premec=0A> =A0=A0=A0 Subject: Re: SV: [MEXT] draf= t-premec-mext-extended-home-link-01=0A> =A0=A0=A0 =0A> =A0=A0=A0 =0A> =A0= =A0=A0 Hi Christian,=0A> =A0=A0=A0 =A0 I am OK redefining the C Flag for th= is purpose. If =0A> other uses come up they should make their own case, I t= hink.=0A> =A0=A0=A0 =0A> =A0=A0=A0 Regards,=0A> =A0=A0=A0 =0A> =A0=A0=A0 Be= hcet=0A> =A0=A0=A0 =0A> =0A> =A0=A0=A0 ________________________________=0A>= =0A> =A0=A0=A0 From: Christian Kaas-Petersen =0A> = =A0=A0=A0 To: mext@ietf.org; Behcet Sarikaya =0A> =A0=A0= =A0 Cc: Charles E. Perkins ; Domagoj =0A> Premec =0A> =A0=A0=A0 Sent: Wednesday, April 1, 2009 2:31= :59 AM=0A> =A0=A0=A0 Subject: SV: [MEXT] (no subject)=0A> =A0=A0=A0 =0A> = =A0=A0=A0 =0A> =A0=A0=A0 The C flag, as defined in draft-devarapalli, means= the home agent=0A> =A0=A0=A0 shall do various processing, but shall not cr= eate an entry in the=0A> =A0=A0=A0 binding cache.=A0 However, draft-premec = requires an entry in the=0A> =A0=A0=A0 binding cache to be created in order= to tunnel IPv4 packets.=0A> =A0=A0=A0 So, either the semantics of the C fl= ag shall be extended or=0A> =A0=A0=A0 another flag shall be defined.=A0 Wha= t is your suggestion?=0A> =A0=A0=A0 =0A> =A0=A0=A0 Christian=0A> =A0=A0=A0 = =0A> =A0=A0=A0 =0A> =A0=A0=A0 --- Den tirs 31/3/09 skrev Behcet Sarikaya=0A= > :=0A> =A0=A0=A0 =0A> =A0=A0=A0 > Fra: Behcet Sa= rikaya =0A> =A0=A0=A0 > Emne: [MEXT] (no subject)= =0A> =A0=A0=A0 > Til: mext@ietf.org=0A> =A0=A0=A0 > Cc: "Charles E. Perkins= " , =0A> "Domagoj Premec"=0A> =0A> =A0=A0=A0 > Dato: tirsdag 31. marts 2009 22.19=0A> =A0=A0=A0 > H= ello all,=0A> =A0=A0=A0 >=A0 Regarding=0A> =A0=A0=A0 > draft-premec-mext-ex= tended-home-link-01.txt, I noticed that=0A> =A0=A0=A0 > this draft is about= what I asked Charlie last week during=0A> =A0=A0=A0 > his presentation, i.= e. sending BU at the home link for=0A> =A0=A0=A0 > something other than der= egistration. As the draft says in=0A> =A0=A0=A0 > Sec. 4.1:=0A> =A0=A0=A0 >= When the MN returns home to an IPv6-only home network,=0A> =A0=A0=A0 > the= MN sends ... BU=0A> =A0=A0=A0 >=A0 I agree with Vijay that a flag must be = defined=0A> =A0=A0=A0 > and set for this purpose because normally this is n= ot=0A> =A0=A0=A0 > allowed and HA must probably reject such a BU. A flag=0A= > =A0=A0=A0 > to this end has already been suggested in=0A> =A0=A0=A0 > dra= ft-devarapalli-mext-mipv6-home-link-01 as C flag.=0A> =A0=A0=A0 >=0A> =A0= =A0=A0 > Regards,=0A> =A0=A0=A0 >=0A> =A0=A0=A0 > Behcet=0A> =A0=A0=A0 >=0A= > =A0=A0=A0 >=0A> =A0=A0=A0 >=0A> =A0=A0=A0 > -----Inline-vedh=E6ftet fil f= =F8lger-----=0A> =A0=A0=A0 >=0A> =A0=A0=A0 > ______________________________= _________________=0A> =A0=A0=A0 > MEXT mailing list=0A> =A0=A0=A0 > MEXT@ie= tf.org=0A> =A0=A0=A0 > https://www.ietf.org/mailman/listinfo/mext=0A> =A0= =A0=A0 > =0A> =A0=A0=A0 =0A> =0A> =0A>=A0 =A0 =A0 Tr=E6nger du til at se de= t store billede? Kelkoo giver =0A> dig gode tilbud p=E5 LCD TV! Se her http= ://dk.yahoo.com/r/pat/lcd=0A> =0A=0A=0A=0A --0-1028573066-1239115375=:4723 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Domagoj,
=0A
  I am not sure if you can = avoid the C bit because without it HA will reject the BU before it gets to = the T bit.
=0A
  Because of that I am not sure if T bit is of= any use at all.
=0A
  Maybe you can negotiate with Charlie/V= ijay?
=0A
 
=0A
Regards,
=0A
 
= =0A
Behcet
=0A

=0A
=0A=
=0AFrom: "Prem= ec, Domagoj" <domagoj.premec@siemens.com>
To: ext Christian Kaas-Petersen <kaaspetersen@ya= hoo.dk>; mext@ietf.org; Behcet Sarikaya <sarikaya@ieee.org>
= Sent: Tuesday, April 7, 2009 8= :55:03 AM
Subject: RE: S= V: [MEXT] draft-premec-mext-extended-home-link-01

Christian, = Behcet,

I'm not clear on benefits of using the C bit, is there reall= y a need to require usage of two separate bits in the BU in the context of = extended home link support? I'd like the draft to be as self-contained as i= t gets, this should help speed up the progress of the draft and avoiding re= ferences to other drafts should help in that regard. It seems to me that us= ing only the T bit should suffice, are there any concerns that make the use= of C bit as defined in draft-devarapalli-mext-mipv6-home-link necessary?

Domago= j

> -----Original Message-----
> From: ext Christian Kaas-P= etersen [mailto:kaaspetersen@yahoo.dk]
> Sent: 03. travan= j 2009 10:37
> To: Domagoj Premec; mext@ietf.org; Behcet Sarikaya
> = Subject: Re: SV: [MEXT] draft-premec-mext-extended-home-link-01
> >
> Proposal: Introduce a Tunnel (T) bit in the BU to signal an<= BR>> IPv4 tunnel to be created on the home link.
>
> Introd= ucing modified semantics on mobility options appearing
> in BUs sent= the home link (as done in draft-premec) is not
> the way ahead.&nbs= p;
> The reason is simplificy of design: one option has one purpose.=
>
> The C-bit in the BU has been suggested as a way to signal the
> BU is sent on the home link for the purpose of configuration =
> (done in draft-devarapalli).  What exactly to be configured <= BR>> depends on the mobility options present.
>
> This mail= suggest a T-bit in the BU as a way to signal a
> tunnel to be estab= lished.  Currently, only one tunnel is
> foreseen, namely the I= Pv4-in-IPv6 tunnel for IPv4 traffic
> over an IPv6-only home link.&n= bsp; The tunnel is indicated with
> the IPv4 Home Address mobility o= ption.  The tunnel could be
> established as the entry v4HoA -&= gt; v6HoA in the binding cache.
>  The T-bit may be set, only w= hen also the C-bit is set. 
> Having T-bit set and C-bit clear = is an error.  Having T-bit
> set and IPv4 Home Address mobility= option missing is probly
> an error.  There should be no need = to include IPv4 Care-of
> Address mobility option, as its content will be the same as
> the IPv4 Home Address mobility option= .
>
> Not clear what the BU's lifetime should be.  With t= he C-bit
> set, configurations can be done, for example to obtain an=
> IPv4 home address or a NEMO mobile network prefix.  The
= > values returned may be dynamically assigned by the home
> agent= .  The home agent would probably be interested in
> knowing for= how long time the assigned values will be used. 
> A practical= solution for this is to say the assignment is
> valid as long as th= e mobile node remains on the home link and
> as long as the IKE sess= ion is alive between the mobile node
> and the home agent.
> =
> Christian
>
>
>
>
>
> ---= Den tors 2/4/09 skrev Behcet Sarikaya <behcetsarikaya@yahoo.com&g= t;:
>
>
> Fra: Behcet Sarikaya <behcets= arikaya@yahoo.com>
> Emne: Re: SV: [MEXT] draft-premec-mext-ex= tended-home-link-01
> Til: "Domagoj Premec" <doma= goj.premec.ext@nsn.com>,
> "Christian Kaas-Petersen" <kaaspetersen@yahoo.dk>, mext@ietf.org
> Dato: torsdag 2. april = 2009 16.55
>
>
>
>
>
>
> Hi= Domagoj,
>   You need to indicate to HA that this is a
>= non-deregistration BU sent from the home link. So the correct
> way= is to define a flag at the BU message like the C flag in
> http://tools.i= etf.org/id/draft-devarapalli-mext-mipv6-home-link-01.txt
>   Of = course HA may also set the C flag in its reply of BA
> message. I th= ink this was what Vijay was commenting on last
> week at the mext me= eting.
>   Yes, IPv4 HoA option has some bits available but thes= e
> would apply to this option not to the BU message, I think it > would be wrong to define this bit there.
>   Regards,
&= gt;  
> Behcet
>
>
>
>
>
&= gt; From: Domagoj Premec <domagoj.premec.ext@nsn.com>
> To: Behcet Sarikaya <sarikaya@ieee.org>; Christian <= BR>> Kaas-Petersen <kaaspetersen@yahoo.dk>; mext@ietf.o= rg
> Cc: Charles E. Perkins <charliep@wichorus.com&= gt;
> Sent: Thursday, April 2, 2009 4:40:13 AM
> Subject: RE: S= V: [MEXT] draft-premec-mext-extended-home-link-01
>
> Behcet,<= BR>>
> In draft-devarapalli-mext-mipv6-home-link-01 the C flag is=
> being defined as part of the BU and Back messages. Given that > draft-premec-extended-home-link is about registering for the
>= v4 service from the IPv6-only home link, there is always the
> IPv4= HoA option included and in this case it may be more
> appropriate t= o define the new flag as part of the IPv4 HoA
> option. This would s= ave the flag space in the BU/Back without
> having disadvantages in = the extended home link scenario.
>
> domagoj
>
> >
> ________________________________
>
>  &nbs= p;  From: ext Behcet Sarikaya [mailto:behcetsarikaya@yaho= o.com]
>     Sent: 01. travanj 2009 16:39
> =     To: Christian Kaas-Petersen; mext@ietf.org
>  &nbs= p;  Cc: Charles E. Perkins; Domagoj Premec
>     = Subject: Re: SV: [MEXT] draft-premec-mext-extended-home-link-01
> &nb= sp;  
>    
>     Hi = Christian,
>       I am OK redefining the C Flag = for this purpose. If
> other uses come up they should make their own= case, I think.
>    
>     Regards,
>    
>     Behcet
= >    
>
>     ______________= __________________
>
>     From: Christian Kaas= -Petersen <kaaspetersen@yahoo.dk>
>   &nbs= p; To: me= xt@ietf.org; Behcet Sarikaya <sarikaya@ieee.org>
>  = ;   Cc: Charles E. Perkins <charliep@wichorus.com&g= t;; Domagoj
> Premec <domagoj.premec.ext@nsn.com= >
>     Sent: Wednesday, April 1, 2009 2:31:59 = AM
>     Subject: SV: [MEXT] (no subject)
>   &n= bsp;
>    
>     The C flag, as= defined in draft-devarapalli, means the home agent
>   &nb= sp; shall do various processing, but shall not create an entry in the
&g= t;     binding cache.  However, draft-premec requires a= n entry in the
>     binding cache to be created in or= der to tunnel IPv4 packets.
>     So, either the seman= tics of the C flag shall be extended or
>     another = flag shall be defined.  What is your suggestion?
>   &= nbsp;
>     Christian
>    
= >    
>     --- Den tirs 31/3/09 sk= rev Behcet Sarikaya
> <behcetsarikaya@yahoo.com&g= t;:
>    
>     > Fra: Behcet= Sarikaya <behcetsarikaya@yahoo.com>
>  &= nbsp;  > Emne: [MEXT] (no subject)
>     > = Til: mext= @ietf.org
>     > Cc: "Charles E. Perkins" <= charliep@wichorus.com>,
> "Domagoj Premec"
> <= ;domagoj.premec.ext@nsn.com>
>   &n= bsp; > Dato: tirsdag 31. marts 2009 22.19
>     >= ; Hello all,
>     >  Regarding
>     > draft-premec-mext-extended-home-link-01.txt, I not= iced that
>     > this draft is about what I asked = Charlie last week during
>     > his presentation, = i.e. sending BU at the home link for
>     > someth= ing other than deregistration. As the draft says in
>   &nb= sp; > Sec. 4.1:
>     > When the MN returns home= to an IPv6-only home network,
>     > the MN sends= ... BU
>     >  I agree with Vijay that a fla= g must be defined
>     > and set for this purpose = because normally this is not
>     > allowed and HA= must probably reject such a BU. A flag
>     > to = this end has already been suggested in
>     > draf= t-devarapalli-mext-mipv6-home-link-01 as C flag.
>     >
>     > Regards,
> &= nbsp;   >
>     > Behcet
>  = ;   >
>     >
>   &nbs= p; >
>     > -----Inline-vedh=E6ftet fil f=F8lge= r-----
>     >
>     > ____= ___________________________________________
>     >= MEXT mailing list
>     > MEXT@ietf.org
>  &= nbsp;  > https://www.ietf.org/mailman/listinfo/mext
>  &= nbsp;  >
>    
>
>
>&nbs= p;     Tr=E6nger du til at se det store billede? Kelkoo giver > dig gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd
= >

=0A=0A=0A=0A --0-1028573066-1239115375=:4723-- From kaaspetersen@yahoo.dk Tue Apr 7 22:58:34 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4913A6D6B for ; Tue, 7 Apr 2009 22:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[AWL=-1.178, BAYES_05=-1.11, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 Qhfiwj1ARsNS for ; Tue, 7 Apr 2009 22:58:33 -0700 (PDT) Received: from web27804.mail.ukl.yahoo.com (web27804.mail.ukl.yahoo.com [217.146.182.9]) by core3.amsl.com (Postfix) with SMTP id 1C3F33A6E35 for ; Tue, 7 Apr 2009 22:58:32 -0700 (PDT) Received: (qmail 95053 invoked by uid 60001); 8 Apr 2009 05:59:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1239170379; bh=ufBMz/hYTYF4kkGop5h1DAf3ibBg062JR7naVbLmeic=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tp4ZDbjDxaAi4HxWbqVoPb09I5Spk7Hv0k8u7F65b8uguIP/5/Key4U7q/LCIufRnzMwwZIG0eySwWE0Omi9De+fuyB/egusrFI55nPVRv3Pu1PcfKNy7fCDHFDtuBp0p5IuF/zqdVUgdZoigcJ328u1KcRdWPQFytwOXpnYVNA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=16Gh9roQFkGIQkd3TTADbbhyE/hoZil/h63gmopA5w2TLZee24UkoOXkd8G9g5BO5sMWfj+Fye7E7Czn0WwhdJE8EbW4+2+FZkP+J/dEMoHL5HIJpjF9dsVc3Jbk2Cu4osQr3JV2thlrIgFj52om7n3Ye73poiJd7TeJZAOwGEk=; Message-ID: <533187.94578.qm@web27804.mail.ukl.yahoo.com> X-YMail-OSG: 68YDJBsVM1m0uGtsV_FRo3BnbCk.u8O4dh2QfzBhWQOKFQt0TCcGoBDbmqmMgRwtbHy80loGIElrJWFbWSmh81IKIb399TY.cIVKe3fapdsN4pIcaAV8Eysfl_.q01uCwnzphVh0gK6JKxMRMAxpPw_cY6F1P6OfIgOCdVH5wYg64NJjgYf40qq1I1OAgawTyrSZsKloHfPktAG9m7Wa6Sb3F42Ddz3iiW_3I9Ers7L85n3o3GRpKov93RfXlRZ4ck7QwNC67UiV5xP9KYxrNQejRCRhkewUpw_aIMKXZSLz8x9tpzUJXqoX7sUbgn0a1lWtumBsdTpIOdZeFbjYaGcVn6aAJenywkhmIzNvi5.IH4ZNFsahsPuF6xGN5a4- Received: from [193.15.240.60] by web27804.mail.ukl.yahoo.com via HTTP; Wed, 08 Apr 2009 05:59:38 GMT X-Mailer: YahooMailClassic/5.2.15 YahooMailWebService/0.7.289.1 Date: Wed, 8 Apr 2009 05:59:38 +0000 (GMT) From: Christian Kaas-Petersen To: mext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [MEXT] DSMIP draft 10 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 05:58:34 -0000 Reading draft 10, I did not find any text on the case of a mobile node attaching to an IPv4-only home network, ie the case where the mobile node has the address v4HoA, and the home agent in its binding cache has the entry v6HoA -> v4HoA Given this case is of particular interest to 3GPP, I think it should be mentioned explicitly somewhere, for example as one of the scenarios in Section 2. Reading draft 10, I think some small details on NAT traversal should be clarified. Section 4.2.2 defines the NAT=20 Detection option. The option suggests a Refresh Time to the mobile node. =20 If Refresh Time =3D 0, then there was a NAT in the path, but it is not clear if the mobile node is informed that NAT refresh may be omitted, or if the mobile node shall make an attempt to refresh the NAT binding using some refresh time configured into the mobile node. The parameter NATKATIMEOUT is only for use in the home agent. Another item on NAT, in four places (section 5.2, para 5; section 5.4.3, para 3; section 5.4.3, para 5; section 5.5.1, para 3) are stated, that the home agent may force UDP encapsulation. Also the mobile node may force UDP encapsulation. Related to this, section 5.4.2, bullet 6, ought to have a "MUST" instead of "should". Section 5.5.1, first packet, shall have UDP Header in square brackets. For the packets in section 6.2.1 and 6.2.2 I think it should be stated, that V4ADDR can mean either the care-of address or the address assigned by the NAT box. Christian=0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo gi= ver dig gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From hesham@elevatemobile.com Wed Apr 8 00:05:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957AC3A68B5 for ; Wed, 8 Apr 2009 00:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-1.063, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396] 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 CGvxFHcLcKwc for ; Wed, 8 Apr 2009 00:05:13 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id B30683A699E for ; Wed, 8 Apr 2009 00:05:12 -0700 (PDT) Received: from [60.224.66.46] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LrRom-00064g-TI; Wed, 08 Apr 2009 17:06:17 +1000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 08 Apr 2009 17:03:23 +1100 From: Hesham Soliman To: Christian Kaas-Petersen , Message-ID: Thread-Topic: [MEXT] DSMIP draft 10 Thread-Index: Acm4GBsXJgvTZiTd+UyQ2Ka7twI02A== In-Reply-To: <533187.94578.qm@web27804.mail.ukl.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [MEXT] DSMIP draft 10 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 07:05:14 -0000 Christian, The draft has now all IESG comments addressed. >=20 > Reading draft 10, I did not find any text on the case of a > mobile node attaching to an IPv4-only home network, ie the > case where the mobile node has the address v4HoA, and > the home agent in its binding cache has the entry >=20 > v6HoA -> v4HoA =3D> The text of how to do this was added two revisions ago as follows: 5.4.2.1. Removing Bindings Mobile nodes will remove bindings from the home agent's binding cache whenever they move to the home link, or simply when mobility support is not needed. De-registering the IPv6 home address is described in [RFC3775]. The same mechanism applies in this specification. Mobile nodes may remove the binding for the IPv4 home address only, by sending a binding update that does not include the IPv4 home address option. Upon receiving this binding update, the home agent will replace the existing cache entries with the content of the new message. This ensures that the IPv4 home address binding is removed, while maintining an IPv6 binding. Note that the mobile node cannot remove the IPv6 home address binding while maintaining an IPv4 home address binding. A binding update message with a lifetime of zero, will remove all bindings for the mobile node. >=20 > Given this case is of particular interest to 3GPP, > I think it should be mentioned explicitly somewhere, for > example as one of the scenarios in Section 2. >=20 > Reading draft 10, I think some small details on NAT traversal > should be clarified. Section 4.2.2 defines the NAT > Detection option. The option suggests a Refresh Time to > the mobile node.=20 >=20 > If Refresh Time =3D 0, then there was a NAT in the path, > but it is not clear if the mobile node is informed that > NAT refresh may be omitted, or if the mobile node shall > make an attempt to refresh the NAT binding using some > refresh time configured into the mobile node. The > parameter NATKATIMEOUT is only for use in the home agent. =3D> The MN always does the refresh otherwise it's unreachable. The value is only a suggestion if the HA wants to make one but has no effect on whether the MN should regularly update the NAT binding. >=20 > Another item on NAT, in four places (section 5.2, para 5; > section 5.4.3, para 3; section 5.4.3, para 5; section 5.5.1, > para 3) are stated, that the home agent may force UDP > encapsulation. Also the mobile node may force UDP > encapsulation. =3D> So what's the comment? >=20 > Related to this, section 5.4.2, bullet 6, ought to have > a "MUST" instead of "should". >=20 > Section 5.5.1, first packet, shall have UDP Header in > square brackets. =3D> Ok these typos can be added to RFC notes. >=20 > For the packets in section 6.2.1 and 6.2.2 I think it should > be stated, that V4ADDR can mean either the care-of address > or the address assigned by the NAT box. =3D> ditto. Hesham >=20 > Christian >=20 >=20 > Tr=E6nger du til at se det store billede? Kelkoo giver dig gode tilbu= d p=E5 > LCD TV! Se her http://dk.yahoo.com/r/pat/lcd > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From kaaspetersen@yahoo.dk Wed Apr 8 01:22:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F1F3A6962 for ; Wed, 8 Apr 2009 01:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, J_CHICKENPOX_13=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 VpSNnpR1x8pg for ; Wed, 8 Apr 2009 01:22:43 -0700 (PDT) Received: from web27805.mail.ukl.yahoo.com (web27805.mail.ukl.yahoo.com [217.146.182.10]) by core3.amsl.com (Postfix) with SMTP id 0154B3A67EB for ; Wed, 8 Apr 2009 01:22:42 -0700 (PDT) Received: (qmail 41184 invoked by uid 60001); 8 Apr 2009 08:23:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1239179029; bh=A2qbVZiZKkFZ4noYwRP2WbSt8oWClw18ZgZ6Ei/T0TQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nFwfFD7y3AW6eQSL2CQFd3Xf0Ul6FENl1zpwgT6aQO714JgTRQg+MRi5Y8o8edzKO5jkA+ZliwBgGuF+ri0/2zBEv02J83VBIkZ7LYVTvJIWBDi6qFdTdDLSSkkO8jvNONpCxaPUD4j0KEe2m96tphmw8nWSb/XdQlFbpS/MD4M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=k0d3PYc9N97/x/NtIfiQSEIZC90F5j3ImSQS2IYhEFaJCADfwcO5xRdRqOnYMUzftb+U/k6YjPQ3/F9x9yP31P1+uPEfIqlfA/XdYL/SAEQVcGTREb1nPajWSGxISf/hVdEKu/dL4fMEoU6YskfY8rEnKMXQgXk4uS23h22yz7Q=; Message-ID: <589535.40208.qm@web27805.mail.ukl.yahoo.com> X-YMail-OSG: d36NCBQVM1kgrcZNRLvhfsoKzdzfCfJy8Q1fXGGBOzMh82PSax.Kadwn Received: from [193.15.240.60] by web27805.mail.ukl.yahoo.com via HTTP; Wed, 08 Apr 2009 08:23:49 GMT X-Mailer: YahooMailClassic/5.2.15 YahooMailWebService/0.7.289.1 Date: Wed, 8 Apr 2009 08:23:49 +0000 (GMT) From: Christian Kaas-Petersen To: mext@ietf.org, Behcet Sarikaya , DomagojPremec MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] draft-premec-mext-extended-home-link-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 08:22:44 -0000 I think you are right. The T-bit does not depend on the C-bit. The T-bit indicates, that the Binding Update / Binding Acknowledgement is sent from the home link and is used to tunnel IPv4 traffic. It may be used with the C-bit if configuration of the IPv4 home address is also wanted. Christian --- Den tirs 7/4/09 skrev Premec, Domagoj : > Fra: Premec, Domagoj > Emne: RE: SV: [MEXT] draft-premec-mext-extended-home-link-01 > Til: "ext Christian Kaas-Petersen" , mext@ietf.org= , "Behcet Sarikaya" > Dato: tirsdag 7. april 2009 15.55 > Christian, Behcet, >=20 > I'm not clear on benefits of using the C bit, is there > really a need to require usage of two separate bits in the > BU in the context of extended home link support? I'd like > the draft to be as self-contained as it gets, this should > help speed up the progress of the draft and avoiding > references to other drafts should help in that regard. It > seems to me that using only the T bit should suffice, are > there any concerns that make the use of C bit as defined in > draft-devarapalli-mext-mipv6-home-link necessary? >=20 > Domagoj >=20 > > -----Original Message----- > > From: ext Christian Kaas-Petersen [mailto:kaaspetersen@yahoo.dk] >=20 > > Sent: 03. travanj 2009 10:37 > > To: Domagoj Premec; mext@ietf.org; > Behcet Sarikaya > > Subject: Re: SV: [MEXT] > draft-premec-mext-extended-home-link-01 > >=20 > >=20 > > Proposal: Introduce a Tunnel (T) bit in the BU to > signal an > > IPv4 tunnel to be created on the home link. > >=20 > > Introducing modified semantics on mobility options > appearing=20 > > in BUs sent the home link (as done in draft-premec) is > not=20 > > the way ahead.=A0=20 > > The reason is simplificy of design: one option has one > purpose. > >=20 > > The C-bit in the BU has been suggested as a way to > signal the=20 > > BU is sent on the home link for the purpose of > configuration=20 > > (done in draft-devarapalli).=A0 What exactly to be > configured=20 > > depends on the mobility options present. > >=20 > > This mail suggest a T-bit in the BU as a way to signal > a=20 > > tunnel to be established.=A0 Currently, only one > tunnel is=20 > > foreseen, namely the IPv4-in-IPv6 tunnel for IPv4 > traffic=20 > > over an IPv6-only home link.=A0 The tunnel is > indicated with=20 > > the IPv4 Home Address mobility option.=A0 The > tunnel could be=20 > > established as the entry v4HoA -> v6HoA in the > binding cache.=20 > >=A0 The T-bit may be set, only when also the C-bit > is set.=A0=20 > > Having T-bit set and C-bit clear is an error.=A0 > Having T-bit=20 > > set and IPv4 Home Address mobility option missing is > probly=20 > > an error.=A0 There should be no need to include > IPv4 Care-of=20 > > Address mobility option, as its content will be the > same as=20 > > the IPv4 Home Address mobility option. > >=20 > > Not clear what the BU's lifetime should be.=A0 With > the C-bit=20 > > set, configurations can be done, for example to obtain > an=20 > > IPv4 home address or a NEMO mobile network > prefix.=A0 The=20 > > values returned may be dynamically assigned by the > home=20 > > agent.=A0 The home agent would probably be > interested in=20 > > knowing for how long time the assigned values will be > used.=A0=20 > > A practical solution for this is to say the assignment > is=20 > > valid as long as the mobile node remains on the home > link and=20 > > as long as the IKE session is alive between the mobile > node=20 > > and the home agent.=20 > >=20 > > Christian > >=20 > >=20 > >=20 > >=20 > >=20 > > --- Den tors 2/4/09 skrev Behcet Sarikaya : > >=20 > >=20 > > Fra: Behcet Sarikaya > > Emne: Re: SV: [MEXT] > draft-premec-mext-extended-home-link-01 > > Til: "Domagoj Premec" , >=20 > > "Christian Kaas-Petersen" , > mext@ietf.org > > Dato: torsdag 2. april 2009 16.55 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Hi Domagoj, > > =A0 You need to indicate to HA that this is a=20 > > non-deregistration BU sent from the home link. So the > correct=20 > > way is to define a flag at the BU message like the C > flag in=20 > > http://tools.ietf.org/id/draft-devarapalli-mext-mipv6-home-link-01.txt > > =A0 Of course HA may also set the C flag in its reply > of BA=20 > > message. I think this was what Vijay was commenting on > last=20 > > week at the mext meeting. > > =A0 Yes, IPv4 HoA option has some bits available but > these=20 > > would apply to this option not to the BU message, I > think it=20 > > would be wrong to define this bit there. > > =A0 Regards, > > =A0 > > Behcet > >=20 > >=20 > >=20 > >=20 > >=20 > > From: Domagoj Premec > > To: Behcet Sarikaya ; > Christian=20 > > Kaas-Petersen ; > mext@ietf.org > > Cc: Charles E. Perkins > > Sent: Thursday, April 2, 2009 4:40:13 AM > > Subject: RE: SV: [MEXT] > draft-premec-mext-extended-home-link-01 > >=20 > > Behcet, > >=20 > > In draft-devarapalli-mext-mipv6-home-link-01 the C > flag is=20 > > being defined as part of the BU and Back messages. > Given that=20 > > draft-premec-extended-home-link is about registering > for the=20 > > v4 service from the IPv6-only home link, there is > always the=20 > > IPv4 HoA option included and in this case it may be > more=20 > > appropriate to define the new flag as part of the IPv4 > HoA=20 > > option. This would save the flag space in the BU/Back > without=20 > > having disadvantages in the extended home link > scenario. > >=20 > > domagoj > >=20 > >=20 > >=20 > > ________________________________ > >=20 > > =A0=A0=A0 From: ext Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > > =A0=A0=A0 Sent: 01. travanj 2009 16:39 > > =A0=A0=A0 To: Christian Kaas-Petersen; mext@ietf.org > > =A0=A0=A0 Cc: Charles E. Perkins; Domagoj Premec > > =A0=A0=A0 Subject: Re: SV: [MEXT] > draft-premec-mext-extended-home-link-01 > > =A0=A0=A0=20 > > =A0=A0=A0=20 > > =A0=A0=A0 Hi Christian, > > =A0=A0=A0 =A0 I am OK redefining the C Flag for this > purpose. If=20 > > other uses come up they should make their own case, I > think. > > =A0=A0=A0=20 > > =A0=A0=A0 Regards, > > =A0=A0=A0=20 > > =A0=A0=A0 Behcet > > =A0=A0=A0=20 > >=20 > > =A0=A0=A0 ________________________________ > >=20 > > =A0=A0=A0 From: Christian Kaas-Petersen > > =A0=A0=A0 To: mext@ietf.org; > Behcet Sarikaya > > =A0=A0=A0 Cc: Charles E. Perkins ; > Domagoj=20 > > Premec > > =A0=A0=A0 Sent: Wednesday, April 1, 2009 2:31:59 AM > > =A0=A0=A0 Subject: SV: [MEXT] (no subject) > > =A0=A0=A0=20 > > =A0=A0=A0=20 > > =A0=A0=A0 The C flag, as defined in draft-devarapalli, > means the home agent > > =A0=A0=A0 shall do various processing, but shall not > create an entry in the > > =A0=A0=A0 binding cache.=A0 However, draft-premec requires > an entry in the > > =A0=A0=A0 binding cache to be created in order to tunnel > IPv4 packets. > > =A0=A0=A0 So, either the semantics of the C flag shall be > extended or > > =A0=A0=A0 another flag shall be defined.=A0 What is your > suggestion? > > =A0=A0=A0=20 > > =A0=A0=A0 Christian > > =A0=A0=A0=20 > > =A0=A0=A0=20 > > =A0=A0=A0 --- Den tirs 31/3/09 skrev Behcet Sarikaya > > : > > =A0=A0=A0=20 > > =A0=A0=A0 > Fra: Behcet Sarikaya > > =A0=A0=A0 > Emne: [MEXT] (no subject) > > =A0=A0=A0 > Til: mext@ietf.org > > =A0=A0=A0 > Cc: "Charles E. Perkins" , >=20 > > "Domagoj Premec" > > > > =A0=A0=A0 > Dato: tirsdag 31. marts 2009 22.19 > > =A0=A0=A0 > Hello all, > > =A0=A0=A0 >=A0 Regarding > > =A0=A0=A0 > > draft-premec-mext-extended-home-link-01.txt, I noticed that > > =A0=A0=A0 > this draft is about what I asked Charlie > last week during > > =A0=A0=A0 > his presentation, i.e. sending BU at the > home link for > > =A0=A0=A0 > something other than deregistration. As > the draft says in > > =A0=A0=A0 > Sec. 4.1: > > =A0=A0=A0 > When the MN returns home to an IPv6-only > home network, > > =A0=A0=A0 > the MN sends ... BU > > =A0=A0=A0 >=A0 I agree with Vijay that a flag must be > defined > > =A0=A0=A0 > and set for this purpose because normally > this is not > > =A0=A0=A0 > allowed and HA must probably reject such a > BU. A flag > > =A0=A0=A0 > to this end has already been suggested in > > =A0=A0=A0 > draft-devarapalli-mext-mipv6-home-link-01 > as C flag. > > =A0=A0=A0 > > > =A0=A0=A0 > Regards, > > =A0=A0=A0 > > > =A0=A0=A0 > Behcet > > =A0=A0=A0 > > > =A0=A0=A0 > > > =A0=A0=A0 > > > =A0=A0=A0 > -----Inline-vedh=E6ftet fil f=F8lger----- > > =A0=A0=A0 > > > =A0=A0=A0 > > _______________________________________________ > > =A0=A0=A0 > MEXT mailing list > > =A0=A0=A0 > MEXT@ietf.org > > =A0=A0=A0 > https://www.ietf.org/mailman/listinfo/mext > > =A0=A0=A0 >=20 > > =A0=A0=A0=20 > >=20 > >=20 > >=A0 =A0 =A0=A0=A0Tr=E6nger du til at se > det store billede? Kelkoo giver=20 > > dig gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd > >=20 > =0A=0A=0A Tr=E6nger du til at se det store billede? Kelkoo giver dig= gode tilbud p=E5 LCD TV! Se her http://dk.yahoo.com/r/pat/lcd From domagoj.premec@siemens.com Fri Apr 10 05:27:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D713A6AF3; Fri, 10 Apr 2009 05:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.87 X-Spam-Level: X-Spam-Status: No, score=-3.87 tagged_above=-999 required=5 tests=[AWL=1.560, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 ez97j-JziPik; Fri, 10 Apr 2009 05:27:15 -0700 (PDT) Received: from mxs1.siemens.at (mxs1.siemens.at [194.138.12.131]) by core3.amsl.com (Postfix) with ESMTP id 1702D3A686E; Fri, 10 Apr 2009 05:27:14 -0700 (PDT) Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id n3ACSKr4000725; Fri, 10 Apr 2009 14:28:20 +0200 Received: from nets139a.ww300.siemens.net ([192.168.217.3]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id n3ACSJ4d032012; Fri, 10 Apr 2009 14:28:20 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Apr 2009 14:28:19 +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: Fri, 10 Apr 2009 14:28:17 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6805123B30@zagh223a.ww300.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] WGLC on draft-ietf-netlmm-mip-interactions Thread-Index: AcmmfqWxriK75kW8TA2R0bgUstwKaQHKeUcgAlNvl/AAuB5sQA== References: From: "Premec, Domagoj" To: "Narayanan, Vidya" , X-OriginalArrivalTime: 10 Apr 2009 12:28:19.0082 (UTC) FILETIME=[D47CB6A0:01C9B9D7] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::090410142820-0B9D7BA0-3147E027/0-0/0-15 X-purgate-size: 2670/0 Cc: mext@ietf.org Subject: Re: [MEXT] [netlmm] WGLC on draft-ietf-netlmm-mip-interactions X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 12:27:16 -0000 Hi Vidya, I have read the document and I think it is in a good shape and ready to = be progressed. Domagoj =20 > -----Original Message----- > From: netlmm-bounces@ietf.org=20 > [mailto:netlmm-bounces@ietf.org] On Behalf Of Narayanan, Vidya > Sent: 07. travanj 2009 00:09 > To: netlmm@ietf.org > Cc: mext@ietf.org > Subject: Re: [netlmm] WGLC on draft-ietf-netlmm-mip-interactions >=20 > We have had exactly 3 responses to this LC. The document=20 > cannot move forward without sufficient indication of WG=20 > review and support. I am extending this LC until April 15th,=20 > to give people a bit after Easter to respond. I believe=20 > there is a 3gpp dependency on this document, but, if we don't=20 > see enough interest from the WG in reviewing this document,=20 > we will be unable to publish it.=20 >=20 > Thanks, > Vidya >=20 > > -----Original Message----- > > From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On=20 > > Behalf Of Narayanan, Vidya > > Sent: Wednesday, March 25, 2009 5:21 PM > > To: netlmm@ietf.org > > Cc: mext@ietf.org > > Subject: Re: [netlmm] WGLC on draft-ietf-netlmm-mip-interactions > >=20 > > Hi, > > This is a reminder of the last call. No reviews or=20 > comments have been=20 > > received so far. If you have read it and have no comments,=20 > please at=20 > > least respond to let us know if it is ready for publication. > >=20 > > Thanks, > > Vidya > >=20 > > > -----Original Message----- > > > From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On=20 > > > Behalf Of Narayanan, Vidya > > > Sent: Monday, March 16, 2009 2:32 PM > > > To: netlmm@ietf.org > > > Subject: [netlmm] WGLC on draft-ietf-netlmm-mip-interactions > > > > > > Hi, > > > This commences a WG last call on=20 > draft-ietf-netlmm-mip-interactions. > > > The last call will end on April 3rd, 2009. The extra week is to=20 > > > accommodate for having the IETF meeting in the middle. > > > > > > Please review and post comments on the mailing list by this > > timeframe. > > > If you reviewed and think the document is ready for publication, > > please > > > also let us know that. > > > > > > Thanks, > > > Vidya > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www.ietf.org/mailman/listinfo/netlmm > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www.ietf.org/mailman/listinfo/netlmm >=20 From marcelo@it.uc3m.es Sun Apr 12 07:46:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA013A690C for ; Sun, 12 Apr 2009 07:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.425 X-Spam-Level: X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 cdWkP-jS5jB4 for ; Sun, 12 Apr 2009 07:46:37 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id E82973A68A6 for ; Sun, 12 Apr 2009 07:46:35 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (138.pool85-53-140.dynamic.orange.es [85.53.140.138]) by smtp02.uc3m.es (Postfix) with ESMTP id C760365A390; Sun, 12 Apr 2009 16:47:38 +0200 (CEST) Message-ID: <49E1FF0A.8040407@it.uc3m.es> Date: Sun, 12 Apr 2009 16:47:38 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext , Julien Laganier Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16578.000 Subject: [MEXT] IETF74 mext draft minutes X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 14:46:37 -0000 The draft minutes of the MEXT meeting are posted. http://www.ietf.org/proceedings/09mar/minutes/mext.txt Let us know if you have comments corrections. Thanks Ed Jankiewicz for taking the notes! Regards, marcelo From tsirtsis@googlemail.com Sun Apr 12 11:16:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEFC33A683A for ; Sun, 12 Apr 2009 11:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] 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 DGn2cCpFvZ8f for ; Sun, 12 Apr 2009 11:16:33 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id F00723A67B7 for ; Sun, 12 Apr 2009 11:16:32 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so1776762wfg.31 for ; Sun, 12 Apr 2009 11:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=Th/tmpg7PoZ4Aaq+nV0/dHVGuYptIYLF/P4z9MBL9VE=; b=mB6QNNHdbknPMzi1/odaQh+Q4sLA1ZDmoHl2RxDdi0C78wUhMKWKpNSF6k9Ixg6Gj9 as9oKThT5BI7QFfvvi1o+4I08BH7Lpwkm0KJhiowsC8MnQc3C2FieacZnIId5U5LcTuI iLd9CxsgCwD7U8hoCPuD1ryYZXdSf1zwDQJvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Lovoa0Ys7DVXUEcZp/615H2Lx456gAkTtxYxcRZg+2royIfJKj0QOluhYnNpo9uPca /KnT2cXKutGbNN90sgj5sJ8cGEjHonaP0ucX2LP0jVgev5Wu348nGo58+Q2ChsBaBtnP Xtg/qpPH/jLGbmKyebZdgEXVEiePMf2WeYgkk= MIME-Version: 1.0 Received: by 10.142.238.20 with SMTP id l20mr2277331wfh.139.1239560263129; Sun, 12 Apr 2009 11:17:43 -0700 (PDT) In-Reply-To: <49E1FF0A.8040407@it.uc3m.es> References: <49E1FF0A.8040407@it.uc3m.es> Date: Sun, 12 Apr 2009 19:17:43 +0100 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Julien Laganier , mext Subject: Re: [MEXT] IETF74 mext draft minutes X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 18:16:33 -0000 Marcelo, See a correction below. Thanks George --------------------------------------------------------------------------------------------------- MEXT meeting minutes TUESDAY, March 24, 2009 1520-1700 Afternoon Session II --------------------------------------------------------------------------------------------------- Minutes by: Ed Jankiewicz --------------------------------------------------------------------------------------------------- ... - Open Issues with RFC 3775 bis - Charles Perkins http://tools.ietf.org/html/draft-ietf-mext-rfc3775bis-03 Recent revision including updates for all previous issues, closed or soon to be Four new issues raise 1. BU de-reg race 2. malicious RA => MN 3. additional spec for handling alt-CoA, how long to keep 4. relax mandate to use IPsec, given RFC 4285 Race condition on BU de-register When MN sends BU de-reg, the HA deletes the BCE. What if MN previous BU was delayed? May arrive and HA interpret as a new registration (not checking the sequence#) Marcelo - do we want to deal with and how? Vijay - the previous BU was a refresh? Yes. Right, may create a new BCE Hesham - we have to solve it. George - yes it is an issue, but what is the solution Raj Patel - corner case, may not worth solving in the 3775bis, but if the fix is simple Marcelo - yes, we should solve. How? Hesham - need state - sequence number, security association, George - timeout, 5 minutes maybe, max time for BUs to arrive thru net. GT> I think what I said was that: " max time for BU to arrive over the internet should have something to do with half an max RTT over the Internet. That is in the 100s of msecs. So the timeout of a few seconds should be sufficient e.g., 5sec". I also think Vijay below agreed with that suggestions. Marcelo - reasonable? Vijay - tentative delete? New binding update arrives - ack or drop? Sequence out of order? Silent drop? ... From marcelo@it.uc3m.es Sun Apr 12 11:53:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51EA3A6BCF for ; Sun, 12 Apr 2009 11:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 FxabQJlp5bSy for ; Sun, 12 Apr 2009 11:53:13 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B39983A67B7 for ; Sun, 12 Apr 2009 11:53:12 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (138.pool85-53-140.dynamic.orange.es [85.53.140.138]) by smtp03.uc3m.es (Postfix) with ESMTP id B890B733E23; Sun, 12 Apr 2009 20:54:20 +0200 (CEST) Message-ID: <49E238DC.3010602@it.uc3m.es> Date: Sun, 12 Apr 2009 20:54:20 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Tsirtsis References: <49E1FF0A.8040407@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16578.001 Cc: Julien Laganier , mext Subject: Re: [MEXT] IETF74 mext draft minutes X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 18:53:13 -0000 corrected and posted thanks! regards, marcelo George Tsirtsis escribió: > Marcelo, > > See a correction below. > > Thanks > George > > --------------------------------------------------------------------------------------------------- > MEXT meeting minutes > TUESDAY, March 24, 2009 > 1520-1700 Afternoon Session II > --------------------------------------------------------------------------------------------------- > Minutes by: Ed Jankiewicz > --------------------------------------------------------------------------------------------------- > ... > > - Open Issues with RFC 3775 bis - Charles Perkins > http://tools.ietf.org/html/draft-ietf-mext-rfc3775bis-03 > > Recent revision including updates for all previous issues, closed or soon to be > Four new issues raise > 1. BU de-reg race > 2. malicious RA => MN > 3. additional spec for handling alt-CoA, how long to keep > 4. relax mandate to use IPsec, given RFC 4285 > > Race condition on BU de-register > When MN sends BU de-reg, the HA deletes the BCE. What if MN previous BU was > delayed? May arrive and HA interpret as a new registration (not > checking the sequence#) > Marcelo - do we want to deal with and how? > Vijay - the previous BU was a refresh? Yes. Right, may create a new BCE > Hesham - we have to solve it. > George - yes it is an issue, but what is the solution > Raj Patel - corner case, may not worth solving in the 3775bis, but if > the fix is simple > Marcelo - yes, we should solve. How? > Hesham - need state - sequence number, security association, > George - timeout, 5 minutes maybe, max time for BUs to arrive thru net. > > GT> I think what I said was that: " max time for BU to arrive over the > internet should have something to do with half an max RTT over the > Internet. That is in the 100s of msecs. So the timeout of a few > seconds should be sufficient e.g., 5sec". I also think Vijay below > agreed with that suggestions. > > Marcelo - reasonable? > Vijay - tentative delete? New binding update arrives - ack or drop? > Sequence out of > order? Silent drop? > ... > > From conny.larsson@ericsson.com Tue Apr 14 08:34:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DFB528C177 for ; Tue, 14 Apr 2009 08:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 v2100dsF61XE for ; Tue, 14 Apr 2009 08:34:22 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 828E928C172 for ; Tue, 14 Apr 2009 08:34:22 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DF915201B0; Tue, 14 Apr 2009 17:35:32 +0200 (CEST) X-AuditID: c1b4fb3e-aa81cbb0000024d5-b8-49e4ad44193c Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BF8ED20059; Tue, 14 Apr 2009 17:35:32 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 17:35:32 +0200 Received: from [127.0.0.1] ([153.88.44.169]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 17:35:31 +0200 Message-ID: <49E4AD42.5000800@ericsson.com> Date: Tue, 14 Apr 2009 17:35:30 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mext , marcelo bagnulo , julien.laganier.IETF@googlemail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2009 15:35:31.0944 (UTC) FILETIME=[A5726E80:01C9BD16] X-Brightmail-Tracker: AAAAAA== Subject: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 15:34:23 -0000 Hi, This is a request to the MEXT working group to adopt draft-larsson-mext-flow-distribution-rules to cover the charter item: (A.3) Use of multiple interfaces. ... Deliverables related to this include - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. The status of the working group is that we have a draft (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for registration of multiple care-of addresses to one home address. There exist one draft (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for transport of the rules that decides how each flow is sent over the available network interfaces. What is currently missing is the part that defines the rules. draft-larsson-mext-flow-distribution-rules defines a rule language that can be used for this. The document can be found at: http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 Please express your opinion on whether this should become a WG document. Regards Conny From marcelo@it.uc3m.es Tue Apr 14 08:44:48 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C5528C181 for ; Tue, 14 Apr 2009 08:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 MF1ikCF8SVc7 for ; Tue, 14 Apr 2009 08:44:47 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 4910D28C177 for ; Tue, 14 Apr 2009 08:44:46 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (123.pool85-53-140.dynamic.orange.es [85.53.140.123]) by smtp02.uc3m.es (Postfix) with ESMTP id 955956BA6EF; Tue, 14 Apr 2009 17:45:56 +0200 (CEST) Message-ID: <49E4AFB4.5080004@it.uc3m.es> Date: Tue, 14 Apr 2009 17:45:56 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Conny Larsson References: <49E4AD42.5000800@ericsson.com> In-Reply-To: <49E4AD42.5000800@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16582.000 Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 15:44:48 -0000 People are of course to comment on this mail, but by no means this is a call for adoption of this document since, to the best of my knowledge, issuing the call for adoption of a WG document is prerogative of the WG chairs Regards, marcelo Conny Larsson escribió: > Hi, > > This is a request to the MEXT working group to adopt > draft-larsson-mext-flow-distribution-rules to cover the charter item: > > (A.3) Use of multiple interfaces. > ... > Deliverables related to this include > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > > The status of the working group is that we have a draft > (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for > registration of multiple care-of addresses to one home address. > There exist one draft > (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for > transport of the rules that decides how each flow is sent over the > available network interfaces. > > What is currently missing is the part that defines the rules. > draft-larsson-mext-flow-distribution-rules defines a rule language > that can be used for this. The document can be found at: > > http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 > > Please express your opinion on whether this should become a WG document. > > > Regards > Conny > > From ryuji.wakikawa@gmail.com Tue Apr 14 08:55:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DD3528C166 for ; Tue, 14 Apr 2009 08:55:17 -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 Zwqy9PpLujqR for ; Tue, 14 Apr 2009 08:55:16 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 8DA183A6E33 for ; Tue, 14 Apr 2009 08:55:16 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so2282431rvb.49 for ; Tue, 14 Apr 2009 08:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=CpTMfT/9pvG04kTy3T4D8gT3mYEDwAQiusLD+993LYQ=; b=hIslX/EilLhxBBuIYAg6ge7D8c2cDHuHVOxNfP3AZUq0EfErLcyhwPMJH9CZor4tvz pSc1PARoizzAnPBlolwzK3HVmkhSpdq933rq2L8B1ttouWbF4u5G4Jtu3/yzBmCnoWku 0OBMx1Wphc7XFMZZmCuTkFtH6+44/MDNyb4l4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=Ihd2hfUbwFQLjg8F2wC/IGo68wA1MsR/DXEm9BPL2RbfKKYQ9g8/eI3OlFbVS4/Wxz 7/vLecwvMrouoljsj+cl/ptwiVNtn01bkasGW72nzXsv6QJfL4beGM2fLv/hm8e/S8d7 XZzxrGlFQHxYPDkFmsjzBZ+GPWOVC5Bdq4G9k= Received: by 10.141.113.3 with SMTP id q3mr3248120rvm.12.1239724588094; Tue, 14 Apr 2009 08:56:28 -0700 (PDT) Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id k41sm9603986rvb.36.2009.04.14.08.56.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 08:56:27 -0700 (PDT) From: Ryuji Wakikawa To: marcelo bagnulo braun In-Reply-To: <49E4AFB4.5080004@it.uc3m.es> References: <49E4AD42.5000800@ericsson.com> <49E4AFB4.5080004@it.uc3m.es> Message-Id: <0C468C8C-2B70-48A8-9ABD-A2CEAFBB34D4@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 11:56:17 -0400 X-Mailer: Apple Mail (2.930.3) Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 15:55:17 -0000 Hi Marcelo, I would like you (chairs) to issue the call for adaptation:-) This document has been discussed as an alternate mechanism of flow =20 bindings. It basically provides flows description rules and very useful in some =20= scenarios. regards, ryuji On 2009/04/14, at 11:45, marcelo bagnulo braun wrote: > People are of course to comment on this mail, but by no means this =20 > is a call for adoption of this document since, to the best of my =20 > knowledge, issuing the call for adoption of a WG document is =20 > prerogative of the WG chairs > > Regards, marcelo > > > Conny Larsson escribi=F3: >> Hi, >> >> This is a request to the MEXT working group to adopt draft-larsson-=20= >> mext-flow-distribution-rules to cover the charter item: >> >> (A.3) Use of multiple interfaces. >> ... >> Deliverables related to this include >> - A "Flow/binding policies exchange" solution for an exchange of >> policies from the mobile host/router to the Home Agent and from the >> Home Agent to the mobile host/router influencing the choice of the >> Care-of Address and Home Agent address. The solution involves two >> specifications, one for the policy format and another for its >> transport [both Standard Track]. >> >> >> The status of the working group is that we have a draft = (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12=20 >> ) for registration of multiple care-of addresses to one home address. >> There exist one draft = (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01=20 >> ) for transport of the rules that decides how each flow is sent =20 >> over the available network interfaces. >> >> What is currently missing is the part that defines the rules. draft-=20= >> larsson-mext-flow-distribution-rules defines a rule language that =20 >> can be used for this. The document can be found at: >> >> = http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >> >> Please express your opinion on whether this should become a WG =20 >> document. >> >> >> Regards >> Conny >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Tue Apr 14 09:06:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 700E728C180 for ; Tue, 14 Apr 2009 09:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 DisE1PJcBAqT for ; Tue, 14 Apr 2009 09:06:04 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1C8A33A6E35 for ; Tue, 14 Apr 2009 09:05:38 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (123.pool85-53-140.dynamic.orange.es [85.53.140.123]) by smtp02.uc3m.es (Postfix) with ESMTP id DA2956C13F6; Tue, 14 Apr 2009 18:06:48 +0200 (CEST) Message-ID: <49E4B498.2080003@it.uc3m.es> Date: Tue, 14 Apr 2009 18:06:48 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ryuji Wakikawa References: <49E4AD42.5000800@ericsson.com> <49E4AFB4.5080004@it.uc3m.es> <0C468C8C-2B70-48A8-9ABD-A2CEAFBB34D4@gmail.com> In-Reply-To: <0C468C8C-2B70-48A8-9ABD-A2CEAFBB34D4@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16582.000 Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 16:06:05 -0000 We have several documents that need to progress. Let us figure out what is the right order to handle the different calls and we will issue them. Regards, marcelo Ryuji Wakikawa escribió: > Hi Marcelo, > > I would like you (chairs) to issue the call for adaptation:-) > > This document has been discussed as an alternate mechanism of flow > bindings. > It basically provides flows description rules and very useful in some > scenarios. > > regards, > ryuji > > > On 2009/04/14, at 11:45, marcelo bagnulo braun wrote: > >> People are of course to comment on this mail, but by no means this is >> a call for adoption of this document since, to the best of my >> knowledge, issuing the call for adoption of a WG document is >> prerogative of the WG chairs >> >> Regards, marcelo >> >> >> Conny Larsson escribió: >>> Hi, >>> >>> This is a request to the MEXT working group to adopt >>> draft-larsson-mext-flow-distribution-rules to cover the charter item: >>> >>> (A.3) Use of multiple interfaces. >>> ... >>> Deliverables related to this include >>> - A "Flow/binding policies exchange" solution for an exchange of >>> policies from the mobile host/router to the Home Agent and from the >>> Home Agent to the mobile host/router influencing the choice of the >>> Care-of Address and Home Agent address. The solution involves two >>> specifications, one for the policy format and another for its >>> transport [both Standard Track]. >>> >>> >>> The status of the working group is that we have a draft >>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>> registration of multiple care-of addresses to one home address. >>> There exist one draft >>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>> transport of the rules that decides how each flow is sent over the >>> available network interfaces. >>> >>> What is currently missing is the part that defines the rules. >>> draft-larsson-mext-flow-distribution-rules defines a rule language >>> that can be used for this. The document can be found at: >>> >>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>> >>> >>> Please express your opinion on whether this should become a WG >>> document. >>> >>> >>> Regards >>> Conny >>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > From tsirtsis@googlemail.com Tue Apr 14 09:07:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD433A6E40 for ; Tue, 14 Apr 2009 09:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 9Xe3z9yyJxxa for ; Tue, 14 Apr 2009 09:07:35 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id BD7BD3A6E35 for ; Tue, 14 Apr 2009 09:07:35 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so2287686rvb.49 for ; Tue, 14 Apr 2009 09:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=SwT65hl57nZ1yJL3iWXoqo4ZFwmHJhjUUDzTjp0Qgjs=; b=dg0CR5HLT4SiDWFNXj5yxh9jf4rBvcVJtSYA/BRqptcmaVcJuhiVWb3Oc9EpCfYGYx 4xCllarE5a6roGCPEcbhs1HqzZrR/Viz+ht7YzZivkgu9AvPvKFo+qCG77Rf1cyO8dC0 +9SEW0Gm5wCTdOpsla5OTNbQjGt6U7ddFUVDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GfPOgcW7z5oCkBluauV1kyHxVqvTG3d/q2ZhV3n0FtxUSkCp4Z3OIp+ErrkYVRGFn2 GisqPxLL1NHtPjTy9gDS5B/bzb6QIMM06UyZNbml97cuZ4Dv7310I/jQKv4T8NoCy4ZQ BCre5FMpqtpdOZAdhrGXuXFn+5vV6aRGob9Xk= MIME-Version: 1.0 Received: by 10.143.2.20 with SMTP id e20mr3142569wfi.269.1239725327318; Tue, 14 Apr 2009 09:08:47 -0700 (PDT) In-Reply-To: <49E4AD42.5000800@ericsson.com> References: <49E4AD42.5000800@ericsson.com> Date: Tue, 14 Apr 2009 17:08:47 +0100 Message-ID: From: George Tsirtsis To: Conny Larsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 16:07:36 -0000 Hi Conny, Good to see you are resurrecting this draft. I think we need this as one of the alternatives. We also need a binary version which I will be working on with others after I am done updating the Flow Bindings draft. Thanks George On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson wrote: > Hi, > > This is a request to the MEXT working group to adopt > draft-larsson-mext-flow-distribution-rules to cover the charter item: > > (A.3) Use of multiple interfaces. > ... > Deliverables related to this include > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > > The status of the working group is that we have a draft > (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for > registration of multiple care-of addresses to one home address. > There exist one draft > (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for transport > of the rules that decides how each flow is sent over the available network > interfaces. > > What is currently missing is the part that defines the rules. > draft-larsson-mext-flow-distribution-rules defines a rule language that can > be used for this. The document can be found at: > > http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 > > Please express your opinion on whether this should become a WG document. > > > Regards > Conny > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From marcelo@it.uc3m.es Tue Apr 14 09:11:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4A73A69B7 for ; Tue, 14 Apr 2009 09:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 sjlNgJribDDL for ; Tue, 14 Apr 2009 09:11:19 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 243223A6909 for ; Tue, 14 Apr 2009 09:11:18 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (123.pool85-53-140.dynamic.orange.es [85.53.140.123]) by smtp02.uc3m.es (Postfix) with ESMTP id B5EBE6C13EB; Tue, 14 Apr 2009 18:12:28 +0200 (CEST) Message-ID: <49E4B5EC.6090701@it.uc3m.es> Date: Tue, 14 Apr 2009 18:12:28 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Tsirtsis References: <49E4AD42.5000800@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16582.000 Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 16:11:20 -0000 George Tsirtsis escribió: > Hi Conny, > > Good to see you are resurrecting this draft. I think we need this as > one of the alternatives. We also need a binary version which I will be > working on with others after I am done updating the Flow Bindings > draft. > could you expand on this? I mean, are you saying that we need two ways of describing flows? Regards, marcelo > Thanks > George > > On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson > wrote: > >> Hi, >> >> This is a request to the MEXT working group to adopt >> draft-larsson-mext-flow-distribution-rules to cover the charter item: >> >> (A.3) Use of multiple interfaces. >> ... >> Deliverables related to this include >> - A "Flow/binding policies exchange" solution for an exchange of >> policies from the mobile host/router to the Home Agent and from the >> Home Agent to the mobile host/router influencing the choice of the >> Care-of Address and Home Agent address. The solution involves two >> specifications, one for the policy format and another for its >> transport [both Standard Track]. >> >> >> The status of the working group is that we have a draft >> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >> registration of multiple care-of addresses to one home address. >> There exist one draft >> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for transport >> of the rules that decides how each flow is sent over the available network >> interfaces. >> >> What is currently missing is the part that defines the rules. >> draft-larsson-mext-flow-distribution-rules defines a rule language that can >> be used for this. The document can be found at: >> >> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >> >> Please express your opinion on whether this should become a WG document. >> >> >> Regards >> Conny >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > From tsirtsis@googlemail.com Tue Apr 14 09:30:30 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8221A28C1B1 for ; Tue, 14 Apr 2009 09:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 rFp6yVsTkGKk for ; Tue, 14 Apr 2009 09:30:29 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id A2A4A28C1AE for ; Tue, 14 Apr 2009 09:30:29 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so2297938rvb.49 for ; Tue, 14 Apr 2009 09:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=sYi177nX8cuFpJ+XHEpzbVoNdWci5dci+ybTJnqNjjU=; b=l+SjI6RzQo8ggtMPUshzN9pYk3M1BJ5mJwx1+Ezsw++nJlYO7+jVdIOngsU2NHoocT quxOURFb17PBmW6AP4v62rCIRyHbY13oLboUd+XowXpFNefvZvs/CPpm2Qi8DYQQTJD4 X+NAH7yhZVjJpAlls5eMdr5MUXuuSZpRois3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bbQ0vn3wUMQNI9KdY5CXwbNHpbQr9jJOaYPtxNycwEe9TlvMbsaPU3QLF3LtWlvC75 Vij0zIR8IrAGRP/1lAAPq1+7SgWXz4uEnyIyqzvz5/1tvWE0PJgnVfj20CZpKrYb4DSG g2Azyq1HmAlIFXe8Dr+SmGWzPux2cXlOvPFz4= MIME-Version: 1.0 Received: by 10.142.230.11 with SMTP id c11mr3176552wfh.305.1239726701077; Tue, 14 Apr 2009 09:31:41 -0700 (PDT) In-Reply-To: <49E4B5EC.6090701@it.uc3m.es> References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> Date: Tue, 14 Apr 2009 17:31:41 +0100 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 16:30:30 -0000 Hi Marcelo, In the Monami6 days, the Flow Bindings draft used to include a binary Flow Descriptor as part of the FID option. This was basically a typical fixed length binary format defining a classifier filterm including source and destination addresses, protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not forget something; both IPv4 and IPv6 can be supported with this. Some people, however, thought that more flexible FDs should be allowed and Conny's draft describes a text based format which is clearly more flexible but also more verbose. At the time, the WG decided that the FD format should be taken out of the Flow Bindings draft. I am not sure I like that but this is indeed what happened. So, now the Flow Bindings draft allows for different FD formats, but it does not define any of them. As a minimum, IMO the protocol should define one format as the default that all implementations MUST support, so that we can have interoperable implementations. IMO this should be the binary format which is the most compact and will work for most of the cases anyway. I do not care too much if this is defined in the same or on a separate (albeit tightly coupled) drafts. It is also ok with me to have other optional formats (like Conny's) for more advanced use cases. I hope this helps George Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun w= rote: > George Tsirtsis escribi=C3=B3: >> >> Hi Conny, >> >> Good to see you are resurrecting this draft. I think we need this as >> one of the alternatives. We also need a binary version which I will be >> working on with others after I am done updating the Flow Bindings >> draft. >> > > could you expand on this? > I mean, are you saying that we need two ways of describing flows? > > Regards, marcelo > >> Thanks >> George >> >> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >> wrote: >> >>> >>> Hi, >>> >>> This is a request to the MEXT working group to adopt >>> draft-larsson-mext-flow-distribution-rules to cover the charter item: >>> >>> (A.3) Use of multiple interfaces. >>> ... >>> Deliverables related to this include >>> - A "Flow/binding policies exchange" solution for an exchange of >>> policies from the mobile host/router to the Home Agent and from the >>> Home Agent to the mobile host/router influencing the choice of the >>> Care-of Address and Home Agent address. The solution involves two >>> specifications, one for the policy format and another for its >>> transport [both Standard Track]. >>> >>> >>> The status of the working group is that we have a draft >>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>> registration of multiple care-of addresses to one home address. >>> There exist one draft >>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>> transport >>> of the rules that decides how each flow is sent over the available >>> network >>> interfaces. >>> >>> What is currently missing is the part that defines the rules. >>> draft-larsson-mext-flow-distribution-rules defines a rule language that >>> can >>> be used for this. The document can be found at: >>> >>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-0= 2 >>> >>> Please express your opinion on whether this should become a WG document= . >>> >>> >>> Regards >>> Conny >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> >> > > From marcelo@it.uc3m.es Tue Apr 14 09:34:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71A628C0D9 for ; Tue, 14 Apr 2009 09:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 bFIawQN4qYc5 for ; Tue, 14 Apr 2009 09:34:56 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id AA5FE3A6BAC for ; Tue, 14 Apr 2009 09:34:55 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (123.pool85-53-140.dynamic.orange.es [85.53.140.123]) by smtp01.uc3m.es (Postfix) with ESMTP id DE291B9FD5B; Tue, 14 Apr 2009 18:36:00 +0200 (CEST) Message-ID: <49E4BB6C.6030702@it.uc3m.es> Date: Tue, 14 Apr 2009 18:35:56 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Tsirtsis References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16582.000 Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 16:34:57 -0000 i wonder if we need the advanced features at this point I mean, we are just defining this, wouldn't make sense to wait and see if with the basic procedure is enough and do the extnesions later? Or is the basic mechanism so limited that is not enough to handle simple basic scenarios? If that is the case, does it makes sense to even define it? Bottom line, we need strong reasons to do things in multiple different ways. Unless clear reasons are described, i fail to see why we should standardize multiple approaches Regards, marcelo George Tsirtsis escribió: > Hi Marcelo, > > In the Monami6 days, the Flow Bindings draft used to include a binary > Flow Descriptor as part of the FID option. > This was basically a typical fixed length binary format defining a > classifier filterm including source and destination addresses, > protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not > forget something; both IPv4 and IPv6 can be supported with this. > > Some people, however, thought that more flexible FDs should be allowed > and Conny's draft describes a text based format which is clearly more > flexible but also more verbose. > > At the time, the WG decided that the FD format should be taken out of > the Flow Bindings draft. I am not sure I like that but this is indeed > what happened. > So, now the Flow Bindings draft allows for different FD formats, but > it does not define any of them. > > As a minimum, IMO the protocol should define one format as the default > that all implementations MUST support, so that we can have > interoperable implementations. > IMO this should be the binary format which is the most compact and > will work for most of the cases anyway. I do not care too much if this > is defined in the same or on a separate (albeit tightly coupled) > drafts. > > It is also ok with me to have other optional formats (like Conny's) > for more advanced use cases. > > I hope this helps > > George > > Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun wrote: > >> George Tsirtsis escribió: >> >>> Hi Conny, >>> >>> Good to see you are resurrecting this draft. I think we need this as >>> one of the alternatives. We also need a binary version which I will be >>> working on with others after I am done updating the Flow Bindings >>> draft. >>> >>> >> could you expand on this? >> I mean, are you saying that we need two ways of describing flows? >> >> Regards, marcelo >> >> >>> Thanks >>> George >>> >>> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >>> wrote: >>> >>> >>>> Hi, >>>> >>>> This is a request to the MEXT working group to adopt >>>> draft-larsson-mext-flow-distribution-rules to cover the charter item: >>>> >>>> (A.3) Use of multiple interfaces. >>>> ... >>>> Deliverables related to this include >>>> - A "Flow/binding policies exchange" solution for an exchange of >>>> policies from the mobile host/router to the Home Agent and from the >>>> Home Agent to the mobile host/router influencing the choice of the >>>> Care-of Address and Home Agent address. The solution involves two >>>> specifications, one for the policy format and another for its >>>> transport [both Standard Track]. >>>> >>>> >>>> The status of the working group is that we have a draft >>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>> registration of multiple care-of addresses to one home address. >>>> There exist one draft >>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>> transport >>>> of the rules that decides how each flow is sent over the available >>>> network >>>> interfaces. >>>> >>>> What is currently missing is the part that defines the rules. >>>> draft-larsson-mext-flow-distribution-rules defines a rule language that >>>> can >>>> be used for this. The document can be found at: >>>> >>>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>> >>>> Please express your opinion on whether this should become a WG document. >>>> >>>> >>>> Regards >>>> Conny >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>>> >>> >> > > From conny.larsson@ericsson.com Tue Apr 14 12:23:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972953A6E31 for ; Tue, 14 Apr 2009 12:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 3-4YaVaDWF+3 for ; Tue, 14 Apr 2009 12:23:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 78D503A6B4F for ; Tue, 14 Apr 2009 12:23:37 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CD41220864; Tue, 14 Apr 2009 21:24:47 +0200 (CEST) X-AuditID: c1b4fb3c-aefd3bb00000238f-96-49e4e2fffa88 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AB58A20475; Tue, 14 Apr 2009 21:24:47 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 21:23:48 +0200 Received: from [127.0.0.1] ([153.88.50.36]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 21:23:48 +0200 Message-ID: <49E4E2C2.4070907@ericsson.com> Date: Tue, 14 Apr 2009 21:23:46 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <49E4AD42.5000800@ericsson.com> <49E4AFB4.5080004@it.uc3m.es> In-Reply-To: <49E4AFB4.5080004@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Apr 2009 19:23:48.0200 (UTC) FILETIME=[890D3E80:01C9BD36] X-Brightmail-Tracker: AAAAAA== Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 19:23:38 -0000 Hi Marcelo, Right. I was not sure about the procedure. The purpose of the mail is to get some feedback so that we know how to progress the draft. So, please comment on the draft and do not pay any attention "to the Call for adaptation" stuff. Marcelo and Julien will take care of that if we come that far :-) . /Conny marcelo bagnulo braun wrote: > People are of course to comment on this mail, but by no means this is > a call for adoption of this document since, to the best of my > knowledge, issuing the call for adoption of a WG document is > prerogative of the WG chairs > > Regards, marcelo > > > Conny Larsson escribió: >> Hi, >> >> This is a request to the MEXT working group to adopt >> draft-larsson-mext-flow-distribution-rules to cover the charter item: >> >> (A.3) Use of multiple interfaces. >> ... >> Deliverables related to this include >> - A "Flow/binding policies exchange" solution for an exchange of >> policies from the mobile host/router to the Home Agent and from the >> Home Agent to the mobile host/router influencing the choice of the >> Care-of Address and Home Agent address. The solution involves two >> specifications, one for the policy format and another for its >> transport [both Standard Track]. >> >> >> The status of the working group is that we have a draft >> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >> registration of multiple care-of addresses to one home address. >> There exist one draft >> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >> transport of the rules that decides how each flow is sent over the >> available network interfaces. >> >> What is currently missing is the part that defines the rules. >> draft-larsson-mext-flow-distribution-rules defines a rule language >> that can be used for this. The document can be found at: >> >> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >> >> Please express your opinion on whether this should become a WG document. >> >> >> Regards >> Conny >> >> > From hesham@elevatemobile.com Tue Apr 14 18:12:19 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6613A6B54 for ; Tue, 14 Apr 2009 18:12: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 TPzM-QTBUpW5 for ; Tue, 14 Apr 2009 18:12:18 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4C23F3A68E1 for ; Tue, 14 Apr 2009 18:12:17 -0700 (PDT) Received: from [211.27.108.142] (helo=[10.0.0.21]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Lttgl-0008Ag-Op; Wed, 15 Apr 2009 11:13:20 +1000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 15 Apr 2009 11:13:03 +1100 From: Hesham Soliman To: Ryuji Wakikawa , marcelo bagnulo braun Message-ID: Thread-Topic: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules Thread-Index: Acm9Z1MVBm2RitgPbEaILANcoIlQZg== In-Reply-To: <0C468C8C-2B70-48A8-9ABD-A2CEAFBB34D4@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 01:12:19 -0000 On 15/04/09 2:56 AM, "Ryuji Wakikawa" wrote: > Hi Marcelo, >=20 > I would like you (chairs) to issue the call for adaptation:-) >=20 > This document has been discussed as an alternate mechanism of flow > bindings. =3D> It is not alternate to flow bindings it's complementary. Hesham > It basically provides flows description rules and very useful in some > scenarios. >=20 > regards, > ryuji >=20 >=20 > On 2009/04/14, at 11:45, marcelo bagnulo braun wrote: >=20 >> People are of course to comment on this mail, but by no means this >> is a call for adoption of this document since, to the best of my >> knowledge, issuing the call for adoption of a WG document is >> prerogative of the WG chairs >>=20 >> Regards, marcelo >>=20 >>=20 >> Conny Larsson escribi=F3: >>> Hi, >>>=20 >>> This is a request to the MEXT working group to adopt draft-larsson- >>> mext-flow-distribution-rules to cover the charter item: >>>=20 >>> (A.3) Use of multiple interfaces. >>> ... >>> Deliverables related to this include >>> - A "Flow/binding policies exchange" solution for an exchange of >>> policies from the mobile host/router to the Home Agent and from the >>> Home Agent to the mobile host/router influencing the choice of the >>> Care-of Address and Home Agent address. The solution involves two >>> specifications, one for the policy format and another for its >>> transport [both Standard Track]. >>>=20 >>>=20 >>> The status of the working group is that we have a draft >>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12 >>> ) for registration of multiple care-of addresses to one home address. >>> There exist one draft >>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01 >>> ) for transport of the rules that decides how each flow is sent >>> over the available network interfaces. >>>=20 >>> What is currently missing is the part that defines the rules. draft- >>> larsson-mext-flow-distribution-rules defines a rule language that >>> can be used for this. The document can be found at: >>>=20 >>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-0= 2 >>>=20 >>> Please express your opinion on whether this should become a WG >>> document. >>>=20 >>>=20 >>> Regards >>> Conny >>>=20 >>>=20 >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Tue Apr 14 18:23:11 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C70D3A699D for ; Tue, 14 Apr 2009 18:23:11 -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 E5sP5VgZA-Cx for ; Tue, 14 Apr 2009 18:23:10 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id E123E3A690B for ; Tue, 14 Apr 2009 18:23:09 -0700 (PDT) Received: from [211.27.108.142] (helo=[10.0.0.21]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LttrL-0006hQ-Ln; Wed, 15 Apr 2009 11:24:16 +1000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 15 Apr 2009 11:24:07 +1100 From: Hesham Soliman To: marcelo bagnulo braun , George Tsirtsis Message-ID: Thread-Topic: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules Thread-Index: Acm9aN7ci1vo/fKjR0+p876kkQpmjw== In-Reply-To: <49E4BB6C.6030702@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 01:23:11 -0000 The binary description that George referred to covered the majority of use cases but it doesn't cover, for instance, a filter on the 75th byte in the packet. Draft-larsson covers those cases and is more generic. The problem with doing things sequentially is that there are different type= s of use cases that can occur from day 1 simultaneously. Use scenarios are no= t going to go from basic to advanced over time, they can start with advanced from day 1 sometimes. So, the safest option is to go with draft-larsson. But, the counter opinion here is that I'll be very surprised if organisations like 3GPP who already have binary filters (and love binary encoding) would want text encoding because they will likely feel that it's wasteful. It seems like both are needed but if you have to make something wait, I'd make the binary stuff wait till someone asks for it. It was in older versions of the draft and it would be very simple of us to take that out an= d put it in a separate draft. Hesham On 15/04/09 3:35 AM, "marcelo bagnulo braun" wrote: > i wonder if we need the advanced features at this point I mean, we are just > defining this, wouldn't make sense to wait and see if with the basic > procedure is enough and do the extnesions later? Or is the basic mechanism so > limited that is not enough to handle simple basic scenarios? If that is the > case, does it makes sense to even define it? Bottom line, we need strong > reasons to do things in multiple different ways. Unless clear reasons are > described, i fail to see why we should standardize multiple > approaches Regards, marcelo George Tsirtsis escribi=F3: > Hi Marcelo, > > In > the Monami6 days, the Flow Bindings draft used to include a binary > Flow > Descriptor as part of the FID option. > This was basically a typical fixed > length binary format defining a > classifier filterm including source and > destination addresses, > protocol number, port numbers, Flow ID, and IPSEC > SPI, if I do not > forget something; both IPv4 and IPv6 can be supported with > this. > > Some people, however, thought that more flexible FDs should be > allowed > and Conny's draft describes a text based format which is clearly > more > flexible but also more verbose. > > At the time, the WG decided that > the FD format should be taken out of > the Flow Bindings draft. I am not sure > I like that but this is indeed > what happened. > So, now the Flow Bindings > draft allows for different FD formats, but > it does not define any of > them. > > As a minimum, IMO the protocol should define one format as the > default > that all implementations MUST support, so that we can have > > interoperable implementations. > IMO this should be the binary format which is > the most compact and > will work for most of the cases anyway. I do not care > too much if this > is defined in the same or on a separate (albeit tightly > coupled) > drafts. > > It is also ok with me to have other optional formats > (like Conny's) > for more advanced use cases. > > I hope this helps > > > George > > Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun > wrote: > >> George Tsirtsis escribi=F3: >> >>> Hi > Conny, >>> >>> Good to see you are resurrecting this draft. I think we need > this as >>> one of the alternatives. We also need a binary version which I > will be >>> working on with others after I am done updating the Flow > Bindings >>> draft. >>> >>> >> could you expand on this? >> I mean, are > you saying that we need two ways of describing flows? >> >> Regards, > marcelo >> >> >>> Thanks >>> George >>> >>> On Tue, Apr 14, 2009 at 4:35 > PM, Conny Larsson >>> wrote: >>> >>> >>>> > Hi, >>>> >>>> This is a request to the MEXT working group to adopt >>>> > draft-larsson-mext-flow-distribution-rules to cover the charter > item: >>>> >>>> (A.3) Use of multiple interfaces. >>>> ... >>>> Deliverables > related to this include >>>> - A "Flow/binding policies exchange" solution for > an exchange of >>>> policies from the mobile host/router to the Home Agent and > from the >>>> Home Agent to the mobile host/router influencing the choice of > the >>>> Care-of Address and Home Agent address. The solution involves > two >>>> specifications, one for the policy format and another for its >>>> > transport [both Standard Track]. >>>> >>>> >>>> The status of the working > group is that we have a draft >>>> > (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>> > registration of multiple care-of addresses to one home address. >>>> There > exist one draft >>>> > (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>> > transport >>>> of the rules that decides how each flow is sent over the > available >>>> network >>>> interfaces. >>>> >>>> What is currently missing is > the part that defines the rules. >>>> > draft-larsson-mext-flow-distribution-rules defines a rule language that >>>> > can >>>> be used for this. The document can be found at: >>>> >>>> > http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>> > >>>> Please express your opinion on whether this should become a WG > document. >>>> >>>> >>>> Regards >>>> Conny >>>> >>>> > _______________________________________________ >>>> MEXT mailing list >>>> > MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>>> > >>> >> > > > _______________________________________________ MEXT mailing > list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From Xiangsong.Cui@huawei.com Tue Apr 14 21:12:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B83053A697F for ; Tue, 14 Apr 2009 21:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.92 X-Spam-Level: **** X-Spam-Status: No, score=4.92 tagged_above=-999 required=5 tests=[AWL=1.484, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MY_CID_AND_STYLE=1.54, T_TVD_FW_GRAPHIC_ID1=0.01] 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 WAnaonfy47wx for ; Tue, 14 Apr 2009 21:12:34 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 791283A6EF3 for ; Tue, 14 Apr 2009 21:12:33 -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 <0KI400DYGJQUWF@szxga02-in.huawei.com> for mext@ietf.org; Wed, 15 Apr 2009 12:13:42 +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 <0KI400C22JQT01@szxga02-in.huawei.com> for mext@ietf.org; Wed, 15 Apr 2009 12:13:42 +0800 (CST) Date: Wed, 15 Apr 2009 12:13:40 +0800 From: Xiangsong Cui To: Conny Larsson , mext , marcelo bagnulo , julien.laganier.IETF@googlemail.com Message-id: <008601c9bd80$8f409e10$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.3138 Content-type: multipart/related; boundary="Boundary_(ID_PFtgO9Mo8qg+C0Cxzwk6BQ)"; type="multipart/alternative" X-Priority: 3 X-MSMail-priority: Normal References: <49E4AD42.5000800@ericsson.com> Subject: Re: [MEXT] Call for adoptation ofdraft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 04:12:35 -0000 This is a multi-part message in MIME format. --Boundary_(ID_PFtgO9Mo8qg+C0Cxzwk6BQ) Content-type: multipart/alternative; boundary="Boundary_(ID_464vcgo+goKKKjz1Bt/9vA)" --Boundary_(ID_464vcgo+goKKKjz1Bt/9vA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGkgTGFyc3NvbiwNCg0KSSB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSwgSSBoYXZlIHNvbWUgY29t bWVudHMgYXMgZm9sbG93aW5nOg0KDQpGaXJzdGx5LCBJIHRoaW5rIGl0IGlzIGJldHRlciB0byBw cm92aWRlIGEgc3RhdGUgZGlhZ3JhbSANCmZvciB0aGUgY29ubmVjdGlvbiBtYW5hZ2VyIHNpbmNl IGl0IHJlbGF0ZXMgdG8gdGhlIGV4Y2hhbmdlIA0KYW5kIG5lZ290aWF0aW9uIG9uIGZsb3cgYmlu ZGluZy4gTWF5YmUgdGhlIHN0YXRlIGRpYWdyYW0gDQpsb29rcyBsaWtlOg0KICAgICAgICAgICAg ICAgICAgICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgICAgfCAgSWRsZSAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgfDwtLSAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tKyAgIFwgICAgICAgICAgICAgICAgICAgIHwgIA0KICAgICAgICAgICAg ICAgICAgICAgICAgXiAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgfCBzZW5kaW5nIG91dCBm bG93ICAgDQogICAgICAgICAgICAgICAgICAgID8/PyB8ICAgICAgICAgIFwgICAgICAgICAgICAg ICAgICB8IGJpbmRpbmcgcmVxdWVzdCAgIA0KICAgICAgICAgICAgICAgICAgICAtLS0tfCAgICAg ICAgICAgXCAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgIFwgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICBcICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgdg0KICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgfCAgICAgICArLS0tLS0tLS0tLS0tLSsNCiAgICAg ICAgICAgICAgfCAgICAgY2hhbmdlIGZsb3cgICAgfCAgICB8ICAgICAgIHxmbG93IGJpbmRpbmcg fCAgDQogICAgICAgICAgICAgIHwgIGJpbmRpbmcgcGVuZGluZyAgfCAgICB8ICAgICAgIHwgICBw ZW5kaW5nICAgfA0KICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgfCAgICAg ICArLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgIF4gICAgICAgfCAgICAg IHwgICAgICAgICAgICAgIHwNCiAgICBzZW5kaW5nIG91dCBjaGFuZ2UgIHwgICAgICAgfCAgICAg IHwgICAgICAgICAgICAgIHxyZWNlaXZpbmcgZmxvdw0KICAgICAgYmluZGluZyByZXF1ZXN0ICAg fCAgICA/PyB8ICAgICAgfD8/PyAgICAgICAgICAgfGJpbmRpbmcgcmVzcG9uc2UNCiAgICAgLS0t LS0tLS0tLS0tLS0tLS0tIHwgICAtLS0tfCAgICAgIHwtLS0tICAgICAgICAgIHwtLS0tLS0tLS0t LS0tLQ0KICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgfCAgICAgICAgICAg ICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgfCAgICAgICAgICAg ICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB2ICAgICAgfCAgICAgICAgICAg ICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgIFwgICAgKy0tLS0tLS0tLS0tLS0tLSsgICAg ICAvDQogICAgICAgICAgICAgICAgICAgICAgICAgIFwtLS18IGZsb3cgYmluZGluZyAgfDwtLS0t Lw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNCg0KDQpT ZWNvbmRseSwgdGhlcmUgYXJlIHNvbWUgaW50ZXItb3BlcmF0aW9uIHByb2JsZW1zLCBJIHRoaW5r Lg0KRm9yIGV4YW1wbGUsIHdoZW4gdGhlIG5vZGUsIHdoaWNoIGlzIG11bHRpaG9tZWQsIHJlY2Vp dmVkIHRoZSANCmNvbW1hbmQgZnJvbSB1c2VyIHRvIGJlZ2luIHNvbWUgZmxvdyB3aXRoIHRoZSBw ZWVyLCB0aGUgbm9kZSANCmRvIG5vdCBrbm93IHdoZXRoZXIgdGhlIHBlZXIgc3VwcG9ydCB0aGUg Y2FwYWJpbGl0eS4gSWYgdGhlIA0Kbm9kZSB1c2UgaW50ZXJmYWNlIEEgdG8gc2VuZCBwYWNrZXRz LCB3aGlsZSB0aGUgcGFja2V0cyBmcm9tIA0KcGVlciBtYXliZSBjb21lIHRocm91Z2ggaW50ZXJm YWNlIEIsIGhvdyB0byBhdm9pZCBpdCBoYXBwZW4/IA0KSWYgdGhlIG5vZGUgZmlyc3RseSBleGNo YW5nZSB0aGUgaW5mb3JtYXRpb24gd2l0aCB0aGUgcGVlciANCmFuZCBiZWdpbiBmbG93IGxhdGVy LCBob3cgYWJvdXQgdGhlIGRlbGF5IGR1cmluZyB0aGUgcHJvY2VkdXJlPw0KT3Igd2UgZG8gbm90 IGNhcmUgdGhlIGlzc3Vlcz8NCkFub3RoZXIgZXhhbXBsZSwgaWYgdGhlIG5vZGUgd2FudCB0byBj aGFuZ2UgdGhlIGZsb3cgYmluZGluZyANCmZyb20gaW50ZXJmYWNlIEEgdG8gaW50ZXJmYWNlIEIs IHdoZW4gc2hvdWxkIHRoZSBub2RlIGJlZ2luIHRvIA0Kc2VuZCBwYWNrZXQgdGhyb3VnaCBpbnRl cmZhY2UgQj8gQWZ0ZXIgc2VuZGluZyB0aGUgcmVxdWVzdCBvciANCmFmdGVyIHJlY2VpdmluZyB0 aGUgcmVzcG9uc2U/DQoNCkkgdGhpbmsgdGhlIHNvbHV0aW9uIG5lZWQgbW9yZSBkZXRhaWxlZCBz dGF0ZW1lbnQuDQoNClJlZ2FyZHMNCg0KWGlhbmdzb25nDQoNCg0K5Y2O5Li65oqA5pyv5pyJ6ZmQ 5YWs5Y+4ICANCg0KDQrlnLDlnYDvvJrmt7HlnLPluILpvpnlspfljLrlnYLnlLDljY7kuLrln7rl nLAg6YKu57yW77yaNTE4MTI5DQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4uuWFrOWPuOeahOS/neWvhuS/ oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4reWIl+WHuueahOS4quS6uuaI lue+pOe7hOOAguemgQ0K5q2i5Lu75L2V5YW25LuW5Lq65Lul5Lu75L2V5b2i5byP5L2/55So77yI 5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo5YiG5Zyw5rOE6Zyy44CB5aSN5Yi244CB5oiW 5pWj5Y+R77yJ5pys6YKu5Lu25LitDQrnmoTkv6Hmga/jgILlpoLmnpzmgqjplJnmlLbkuobmnKzp gq7ku7bvvIzor7fmgqjnq4vljbPnlLXor53miJbpgq7ku7bpgJrnn6Xlj5Hku7bkurrlubbliKDp maTmnKzpgq7ku7bvvIENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIA0KaXMgaW50ZW5kZWQg b25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJv dmUuIEFueSB1c2Ugb2YgdGhlIA0KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkg d2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCANCmRp c2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhl ciB0aGFuIHRoZSBpbnRlbmRlZCANCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3Ug cmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5 IA0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0KICAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBDb25ueSBMYXJzc29uIA0KICBUbzogbWV4 dCA7IG1hcmNlbG8gYmFnbnVsbyA7IGp1bGllbi5sYWdhbmllci5JRVRGQGdvb2dsZW1haWwuY29t IA0KICBTZW50OiBUdWVzZGF5LCBBcHJpbCAxNCwgMjAwOSAxMTozNSBQTQ0KICBTdWJqZWN0OiBb TUVYVF0gQ2FsbCBmb3IgYWRvcHRhdGlvbiBvZmRyYWZ0LWxhcnNzb24tbWV4dC1mbG93LWRpc3Ry aWJ1dGlvbi1ydWxlcw0KDQoNCiAgSGksDQoNCiAgVGhpcyBpcyBhIHJlcXVlc3QgdG8gdGhlIE1F WFQgd29ya2luZyBncm91cCB0byBhZG9wdCANCiAgZHJhZnQtbGFyc3Nvbi1tZXh0LWZsb3ctZGlz dHJpYnV0aW9uLXJ1bGVzIHRvIGNvdmVyIHRoZSBjaGFydGVyIGl0ZW06DQoNCiAgKEEuMykgVXNl IG9mIG11bHRpcGxlIGludGVyZmFjZXMuDQogIC4uLg0KICBEZWxpdmVyYWJsZXMgcmVsYXRlZCB0 byB0aGlzIGluY2x1ZGUNCiAgLSBBICJGbG93L2JpbmRpbmcgcG9saWNpZXMgZXhjaGFuZ2UiIHNv bHV0aW9uIGZvciBhbiBleGNoYW5nZSBvZg0KICBwb2xpY2llcyBmcm9tIHRoZSBtb2JpbGUgaG9z dC9yb3V0ZXIgdG8gdGhlIEhvbWUgQWdlbnQgYW5kIGZyb20gdGhlDQogIEhvbWUgQWdlbnQgdG8g dGhlIG1vYmlsZSBob3N0L3JvdXRlciBpbmZsdWVuY2luZyB0aGUgY2hvaWNlIG9mIHRoZQ0KICBD YXJlLW9mIEFkZHJlc3MgYW5kIEhvbWUgQWdlbnQgYWRkcmVzcy4gVGhlIHNvbHV0aW9uIGludm9s dmVzIHR3bw0KICBzcGVjaWZpY2F0aW9ucywgb25lIGZvciB0aGUgcG9saWN5IGZvcm1hdCBhbmQg YW5vdGhlciBmb3IgaXRzDQogIHRyYW5zcG9ydCBbYm90aCBTdGFuZGFyZCBUcmFja10uDQoNCg0K ICBUaGUgc3RhdHVzIG9mIHRoZSB3b3JraW5nIGdyb3VwIGlzIHRoYXQgd2UgaGF2ZSBhIGRyYWZ0 IA0KICAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tb25hbWk2LW11bHRp cGxlY29hLTEyKSBmb3IgDQogIHJlZ2lzdHJhdGlvbiBvZiBtdWx0aXBsZSBjYXJlLW9mIGFkZHJl c3NlcyB0byBvbmUgaG9tZSBhZGRyZXNzLg0KICBUaGVyZSBleGlzdCBvbmUgZHJhZnQgDQogICho dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1leHQtZmxvdy1iaW5kaW5nLTAx KSBmb3IgDQogIHRyYW5zcG9ydCBvZiB0aGUgcnVsZXMgdGhhdCBkZWNpZGVzIGhvdyBlYWNoIGZs b3cgaXMgc2VudCBvdmVyIHRoZSANCiAgYXZhaWxhYmxlIG5ldHdvcmsgaW50ZXJmYWNlcy4NCg0K ICBXaGF0IGlzIGN1cnJlbnRseSBtaXNzaW5nIGlzIHRoZSBwYXJ0IHRoYXQgZGVmaW5lcyB0aGUg cnVsZXMuIA0KICBkcmFmdC1sYXJzc29uLW1leHQtZmxvdy1kaXN0cmlidXRpb24tcnVsZXMgZGVm aW5lcyBhIHJ1bGUgbGFuZ3VhZ2UgdGhhdCANCiAgY2FuIGJlIHVzZWQgZm9yIHRoaXMuIFRoZSBk b2N1bWVudCBjYW4gYmUgZm91bmQgYXQ6DQoNCiAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbGFyc3Nvbi1tZXh0LWZsb3ctZGlzdHJpYnV0aW9uLXJ1bGVzLTAyDQoNCiAgUGxlYXNl IGV4cHJlc3MgeW91ciBvcGluaW9uIG9uIHdoZXRoZXIgdGhpcyBzaG91bGQgYmVjb21lIGEgV0cg ZG9jdW1lbnQuDQoNCg0KICBSZWdhcmRzDQogIENvbm55DQoNCiAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgTUVYVCBtYWlsaW5nIGxpc3QNCiAgTUVY VEBpZXRmLm9yZw0KICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQ= --Boundary_(ID_464vcgo+goKKKjz1Bt/9vA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPkhp IExhcnNzb24sPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+SSB0aGluayBp dCBpcyBhIGdvb2QgaWRlYSwgSSBoYXZlIHNvbWUgY29tbWVudHMgYXMgDQpmb2xsb3dpbmc6PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+Rmlyc3RseSwgSSB0aGluayBpdCBp cyBiZXR0ZXIgdG8gcHJvdmlkZSBhIHN0YXRlIA0KZGlhZ3JhbSA8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj5mb3IgdGhlIGNvbm5lY3Rpb24gbWFuYWdlciBzaW5j ZSA8L0ZPTlQ+PEZPTlQgZmFjZT3lrovkvZMgDQpzaXplPTI+aXQgcmVsYXRlcyB0byB0aGUgZXhj aGFuZ2UgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+YW5kIG5l Z290aWF0aW9uIG9uIGZsb3cgYmluZGluZy4gTWF5YmUgdGhlIHN0YXRlIA0KZGlhZ3JhbSA8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj5sb29rcyBsaWtlOjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KKy0tLS0tLS0tLSsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyBJZGxlJm5ic3A7Jm5ic3A7IA0KfC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KfCZsdDstLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KKy0tLS0tLS0tLSsmbmJzcDsmbmJzcDsgDQpc Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KfCZuYnNwOyANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpeJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KXCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwgc2VuZGluZyBvdXQgZmxvdyZu YnNwOyZuYnNwOyANCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQombmJzcDs/Pz8mbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KXCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCnwgYmluZGluZyANCnJlcXVlc3QmbmJzcDsmbmJzcDsmbmJz cDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KLS0tLXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQpcJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KfC0tLS0tLS0tLS0tLS0tLS0tLTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KXCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnw8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQp8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KdjxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQorLS0tLS0tLS0tLS0tLS0tLS0tLSsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistLS0tLS0tLS0tLS0tKzxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNoYW5nZSBm bG93Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxmbG93IGJpbmRpbmcgfCZuYnNwOyANCjxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7IGJpbmRpbmcgcGVuZGluZyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7IHBlbmRpbmcmbmJzcDsmbmJzcDsgDQp8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCistLS0tLS0tLS0tLS0tLS0tLS0tKyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KKy0tLS0tLS0tLS0tLS0rPEJSPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyANCl4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8 PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBzZW5kaW5nIG91dCBjaGFuZ2UmbmJzcDsgDQp8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfHJlY2VpdmluZyBmbG93PEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiaW5kaW5nIHJlcXVlc3QmbmJzcDsmbmJzcDsgDQp8 Jm5ic3A7Jm5ic3A7Jm5ic3A7ID8/IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8 Pz8/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHxiaW5kaW5nIA0KcmVzcG9uc2U8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0t LS0tLS0tLS0tLS0tLS0tLSB8Jm5ic3A7Jm5ic3A7IA0KLS0tLXwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQp8LS0tLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCnwtLS0tLS0tLS0tLS0tLTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfDxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KfDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHYmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQp8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KfDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQpcJm5ic3A7Jm5ic3A7Jm5ic3A7ICstLS0tLS0tLS0tLS0tLS0rJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KLzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQpcLS0tfCBmbG93IGJpbmRpbmcmbmJzcDsgDQp8Jmx0Oy0tLS0vPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCistLS0tLS0t LS0tLS0tLS0rPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+U2Vjb25kbHksIHRoZXJl Jm5ic3A7YXJlIHNvbWUgaW50ZXItb3BlcmF0aW9uIA0KcHJvYmxlbXMsIEkgdGhpbmsuPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+Rm9yIGV4YW1wbGUsIHdoZW4g dGhlIG5vZGUsIHdoaWNoIGlzIG11bHRpaG9tZWQsIA0KcmVjZWl2ZWQgdGhlIDwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPmNvbW1hbmQgZnJvbSB1c2VyIHRvIGJl Z2luJm5ic3A7c29tZSBmbG93IDwvRk9OVD48Rk9OVCANCmZhY2U95a6L5L2TIHNpemU9Mj53aXRo IHRoZSBwZWVyLCB0aGUgbm9kZSA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2T IHNpemU9Mj5kbyBub3Qga25vdyB3aGV0aGVyIHRoZSBwZWVyIHN1cHBvcnQgPC9GT05UPjxGT05U IA0KZmFjZT3lrovkvZMgc2l6ZT0yPnRoZSBjYXBhYmlsaXR5LiZuYnNwO0lmIHRoZSA8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj5ub2RlIHVzZSBpbnRlcmZhY2Ug QSB0byBzZW5kIHBhY2tldHMsIDwvRk9OVD48Rk9OVCANCmZhY2U95a6L5L2TIHNpemU9Mj53aGls ZSA8L0ZPTlQ+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPnRoZSBwYWNrZXRzIGZyb20gPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+cGVlciBtYXliZSBjb21lIHRo cm91Z2ggaW50ZXJmYWNlIEIsIGhvdyB0byANCjwvRk9OVD48Rk9OVCBmYWNlPeWui+S9kyBzaXpl PTI+YXZvaWQgaXQgaGFwcGVuPyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2T IHNpemU9Mj5JZiB0aGUgPC9GT05UPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj5ub2RlIGZpcnN0 bHkgDQpleGNoYW5nZSB0aGUgaW5mb3JtYXRpb24gPC9GT05UPjxGT05UIGZhY2U95a6L5L2TIHNp emU9Mj53aXRoIHRoZSBwZWVyIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMg c2l6ZT0yPmFuZCBiZWdpbiA8L0ZPTlQ+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPmZsb3cgbGF0 ZXIsIGhvdyANCmFib3V0IHRoZSBkZWxheSBkdXJpbmcgPC9GT05UPjxGT05UIGZhY2U95a6L5L2T IHNpemU9Mj50aGUgcHJvY2VkdXJlPzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovk vZMgc2l6ZT0yPk9yIHdlIGRvIG5vdCBjYXJlIHRoZSBpc3N1ZXM/PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+QW5vdGhlciBleGFtcGxlLCZuYnNwO2lmIHRoZSBu b2RlIHdhbnQgdG8gY2hhbmdlIHRoZSANCmZsb3cgYmluZGluZyA8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj5mcm9tJm5ic3A7aW50ZXJmYWNlIEEgdG8gaW50ZXJm YWNlIEIsIHdoZW4gc2hvdWxkIHRoZSANCm5vZGUgYmVnaW4gdG8gPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+c2VuZCA8L0ZPTlQ+PEZPTlQgZmFjZT3lrovkvZMg c2l6ZT0yPnBhY2tldCZuYnNwO3Rocm91Z2ggDQppbnRlcmZhY2UgQj8gQWZ0ZXIgc2VuZGluZyB0 aGUgcmVxdWVzdCBvciA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9 Mj5hZnRlciA8L0ZPTlQ+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPnJlY2VpdmluZyB0aGUgDQpy ZXNwb25zZT88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj5JIHRoaW5rIHRo ZSBzb2x1dGlvbiBuZWVkIG1vcmUgZGV0YWlsZWQgDQpzdGF0ZW1lbnQuPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+UmVnYXJkczwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT3lrovkvZMgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3l rovkvZMgc2l6ZT0yPlhpYW5nc29uZzwvRk9OVD48L0RJVj4NCjxESVY+DQo8UD48L1A+DQo8UD48 L1A+PEZPTlQgZmFjZT3ljY7mlofnu4bpu5EgY29sb3I9YmxhY2sgc2l6ZT0yPjwvRk9OVD48Rk9O VCBmYWNlPeWNjuaWh+e7hum7kSBjb2xvcj1ncmF5IA0Kc2l6ZT0yPuWNjuS4uuaKgOacr+aciemZ kOWFrOWPuCA8L0ZPTlQ+PElNRyBpZD1yaWRJbWcgYWx0PWh1YXdlaV9sb2dvIGhzcGFjZT0wIA0K c3JjPSJjaWQ6MDA4MTAxYzliZDgwJDhlZjQ1MmQwJDQwMTA2ZjBhQGNoaW5hLmh1YXdlaS5jb20i IGFsaWduPWxlZnQ+IA0KPFA+PC9QPjxCUj48Rk9OVCBmYWNlPeWNjuaWh+e7hum7kSBjb2xvcj1n cmF5IHNpemU9MT7lnLDlnYDvvJrmt7HlnLPluILpvpnlspfljLrlnYLnlLDljY7kuLrln7rlnLAg 6YKu57yW77yaNTE4MTI5PEJSPjxBIA0KaHJlZj0iaHR0cDovL3d3dy5odWF3ZWkuY29tIj5odHRw Oi8vd3d3Lmh1YXdlaS5jb208L0E+PEJSPjwvRk9OVD48Rk9OVCBmYWNlPeWNjuaWh+e7hum7kSAN CmNvbG9yPWdyYXkgDQpzaXplPTE+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj7mnKzpgq7ku7blj4rl hbbpmYTku7blkKvmnInljY7kuLrlhazlj7jnmoTkv53lr4bkv6Hmga/vvIzku4XpmZDkuo7lj5Hp gIHnu5nkuIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrkurrmiJbnvqTnu4TjgILnpoE8QlI+5q2i 5Lu75L2V5YW25LuW5Lq65Lul5Lu75L2V5b2i5byP5L2/55So77yI5YyF5ous5L2G5LiN6ZmQ5LqO 5YWo6YOo5oiW6YOo5YiG5Zyw5rOE6Zyy44CB5aSN5Yi244CB5oiW5pWj5Y+R77yJ5pys6YKu5Lu2 5LitPEJSPueahOS/oeaBr+OAguWmguaenOaCqOmUmeaUtuS6huacrOmCruS7tu+8jOivt+aCqOer i+WNs+eUteivneaIlumCruS7tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZpOacrOmCruS7tu+8gTxC Uj48L0ZPTlQ+PEZPTlQgDQpmYWNlPUFyaWFsIGNvbG9yPWdyYXkgc2l6ZT0xPlRoaXMgZS1tYWls IGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiANCmNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBm cm9tIEhVQVdFSSwgd2hpY2ggPEJSPmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gDQpv ciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIDxC Uj5pbmZvcm1hdGlvbiANCmNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBi dXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgDQo8QlI+ZGlzY2xvc3VyZSwgcmVw cm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIA0K aW50ZW5kZWQgPEJSPnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0 aGlzIGUtbWFpbCBpbiBlcnJvciwgDQpwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgPEJSPnBo b25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgDQppdCE8QlI+PC9GT05UPjwvRElW Pg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6 IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBN QVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkJBQ0tHUk9VTkQ6 ICNlNGU0ZTQ7IEZPTlQ6IDlwdCDlrovkvZM7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwv Qj4gDQogIDxBIHRpdGxlPWNvbm55LmxhcnNzb25AZXJpY3Nzb24uY29tIA0KICBocmVmPSJtYWls dG86Y29ubnkubGFyc3NvbkBlcmljc3Nvbi5jb20iPkNvbm55IExhcnNzb248L0E+IDwvRElWPg0K ICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPW1leHRA aWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzptZXh0QGlldGYub3JnIj5tZXh0PC9BPiA7IDxBIHRp dGxlPW1hcmNlbG9AaXQudWMzbS5lcyANCiAgaHJlZj0ibWFpbHRvOm1hcmNlbG9AaXQudWMzbS5l cyI+bWFyY2VsbyBiYWdudWxvPC9BPiA7IDxBIA0KICB0aXRsZT1qdWxpZW4ubGFnYW5pZXIuSUVU RkBnb29nbGVtYWlsLmNvbSANCiAgaHJlZj0ibWFpbHRvOmp1bGllbi5sYWdhbmllci5JRVRGQGdv b2dsZW1haWwuY29tIj5qdWxpZW4ubGFnYW5pZXIuSUVURkBnb29nbGVtYWlsLmNvbTwvQT4gDQog IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TZW50OjwvQj4gVHVl c2RheSwgQXByaWwgMTQsIDIwMDkgMTE6MzUgUE08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDog OXB0IOWui+S9kyI+PEI+U3ViamVjdDo8L0I+IFtNRVhUXSBDYWxsIGZvciBhZG9wdGF0aW9uIA0K ICBvZmRyYWZ0LWxhcnNzb24tbWV4dC1mbG93LWRpc3RyaWJ1dGlvbi1ydWxlczwvRElWPg0KICA8 RElWPjxCUj48L0RJVj5IaSw8QlI+PEJSPlRoaXMgaXMgYSByZXF1ZXN0IHRvIHRoZSBNRVhUIHdv cmtpbmcgZ3JvdXAgdG8gYWRvcHQgDQogIDxCUj5kcmFmdC1sYXJzc29uLW1leHQtZmxvdy1kaXN0 cmlidXRpb24tcnVsZXMgdG8gY292ZXIgdGhlIGNoYXJ0ZXIgDQogIGl0ZW06PEJSPjxCUj4oQS4z KSBVc2Ugb2YgbXVsdGlwbGUgaW50ZXJmYWNlcy48QlI+Li4uPEJSPkRlbGl2ZXJhYmxlcyByZWxh dGVkIA0KICB0byB0aGlzIGluY2x1ZGU8QlI+LSBBICJGbG93L2JpbmRpbmcgcG9saWNpZXMgZXhj aGFuZ2UiIHNvbHV0aW9uIGZvciBhbiANCiAgZXhjaGFuZ2Ugb2Y8QlI+cG9saWNpZXMgZnJvbSB0 aGUgbW9iaWxlIGhvc3Qvcm91dGVyIHRvIHRoZSBIb21lIEFnZW50IGFuZCBmcm9tIA0KICB0aGU8 QlI+SG9tZSBBZ2VudCB0byB0aGUgbW9iaWxlIGhvc3Qvcm91dGVyIGluZmx1ZW5jaW5nIHRoZSBj aG9pY2Ugb2YgDQogIHRoZTxCUj5DYXJlLW9mIEFkZHJlc3MgYW5kIEhvbWUgQWdlbnQgYWRkcmVz cy4gVGhlIHNvbHV0aW9uIGludm9sdmVzIA0KICB0d288QlI+c3BlY2lmaWNhdGlvbnMsIG9uZSBm b3IgdGhlIHBvbGljeSBmb3JtYXQgYW5kIGFub3RoZXIgZm9yIA0KICBpdHM8QlI+dHJhbnNwb3J0 IFtib3RoIFN0YW5kYXJkIFRyYWNrXS48QlI+PEJSPjxCUj5UaGUgc3RhdHVzIG9mIHRoZSB3b3Jr aW5nIA0KICBncm91cCBpcyB0aGF0IHdlIGhhdmUgYSBkcmFmdCA8QlI+KDxBIA0KICBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1vbmFtaTYtbXVsdGlwbGVjb2Et MTIiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW9uYW1pNi1tdWx0aXBs ZWNvYS0xMjwvQT4pIA0KICBmb3IgPEJSPnJlZ2lzdHJhdGlvbiBvZiBtdWx0aXBsZSBjYXJlLW9m IGFkZHJlc3NlcyB0byBvbmUgaG9tZSANCiAgYWRkcmVzcy48QlI+VGhlcmUgZXhpc3Qgb25lIGRy YWZ0IDxCUj4oPEEgDQogIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbWV4dC1mbG93LWJpbmRpbmctMDEiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtbWV4dC1mbG93LWJpbmRpbmctMDE8L0E+KSANCiAgZm9yIDxCUj50cmFuc3BvcnQgb2Yg dGhlIHJ1bGVzIHRoYXQgZGVjaWRlcyBob3cgZWFjaCBmbG93IGlzIHNlbnQgb3ZlciB0aGUgDQog IDxCUj5hdmFpbGFibGUgbmV0d29yayBpbnRlcmZhY2VzLjxCUj48QlI+V2hhdCBpcyBjdXJyZW50 bHkgbWlzc2luZyBpcyB0aGUgcGFydCANCiAgdGhhdCBkZWZpbmVzIHRoZSBydWxlcy4gPEJSPmRy YWZ0LWxhcnNzb24tbWV4dC1mbG93LWRpc3RyaWJ1dGlvbi1ydWxlcyBkZWZpbmVzIA0KICBhIHJ1 bGUgbGFuZ3VhZ2UgdGhhdCA8QlI+Y2FuIGJlIHVzZWQgZm9yIHRoaXMuIFRoZSBkb2N1bWVudCBj YW4gYmUgZm91bmQgDQogIGF0OjxCUj48QlI+PEEgDQogIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWxhcnNzb24tbWV4dC1mbG93LWRpc3RyaWJ1dGlvbi1ydWxlcy0wMiI+ aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGFyc3Nvbi1tZXh0LWZsb3ctZGlzdHJp YnV0aW9uLXJ1bGVzLTAyPC9BPjxCUj48QlI+UGxlYXNlIA0KICBleHByZXNzIHlvdXIgb3Bpbmlv biBvbiB3aGV0aGVyIHRoaXMgc2hvdWxkIGJlY29tZSBhIFdHIA0KICBkb2N1bWVudC48QlI+PEJS PjxCUj5SZWdhcmRzPEJSPkNvbm55PEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxCUj5NRVhUIA0KICBtYWlsaW5nIGxpc3Q8QlI+PEEgaHJlZj0i bWFpbHRvOk1FWFRAaWV0Zi5vcmciPk1FWFRAaWV0Zi5vcmc8L0E+PEJSPjxBIA0KICBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dDwvQT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRN TD4NCg== --Boundary_(ID_464vcgo+goKKKjz1Bt/9vA)-- --Boundary_(ID_PFtgO9Mo8qg+C0Cxzwk6BQ) Content-id: <008101c9bd80$8ef452d0$40106f0a@china.huawei.com> Content-type: image/jpeg; name=outlook_huawei_logo_cn.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_cn.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_PFtgO9Mo8qg+C0Cxzwk6BQ)-- From tsirtsis@googlemail.com Wed Apr 15 01:48:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D684A3A6A99 for ; Wed, 15 Apr 2009 01:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 hyVnFIzfcs1u for ; Wed, 15 Apr 2009 01:48:01 -0700 (PDT) Received: from mail-gx0-f208.google.com (mail-gx0-f208.google.com [209.85.217.208]) by core3.amsl.com (Postfix) with ESMTP id 674DF3A6A21 for ; Wed, 15 Apr 2009 01:48:01 -0700 (PDT) Received: by gxk4 with SMTP id 4so6509477gxk.13 for ; Wed, 15 Apr 2009 01:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=5Hnrbycfab2muXkbyZEnul1OdoiJ7TOpIeecrJUkIYQ=; b=AoaFGv99Ii539lRfn1s7cwkzeFlEKR2hes+rngl9qcGTxTjV2UWUAI3L2jA6jREwjr 1fNNjmN6N5Gi6e/SVGBWav8f1gb5pMaX3G7fZVQa6xlq2ew6tDOv9/HPVRlJ6dfp92Zq 0YsXJjx0YowxZTG5SPg0YHlsiagGNfPWs2KCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VGjBX+5qGy4RUqmDRGk42gP9X82KQ8XpeqjyAlCpUDipXlEeY+p2gerdRrOF4J4xHb gihuf6i49qgBWZavgkl5iGAei7jolfnE+RA2gEW7Le4Pw9SOpEq6MVvclyunfOJ0F81H uKjDkrntyZjnrCGqa2KIY1UCITna9BCdpGF/k= MIME-Version: 1.0 Received: by 10.90.106.4 with SMTP id e4mr4171438agc.78.1239785353161; Wed, 15 Apr 2009 01:49:13 -0700 (PDT) In-Reply-To: References: <49E4BB6C.6030702@it.uc3m.es> Date: Wed, 15 Apr 2009 09:49:13 +0100 Message-ID: From: George Tsirtsis To: Hesham Soliman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 08:48:02 -0000 Hi Hesham, I think in fact the binary mechanism can easily be much more flexible if we want to. All we have to do it to allow for matching to an "Offset" + "Number of bytes". The Offset would be a pointer to X number of bytes from the beginning of the IP header, and then the Number of Bytes, would be the field that you are trying to match. This has been used by classifiers for long time now (e.g., Linux, look for U32 Selector). In that case, the fixed binary format can cover most of the cases and also provide a mechanism for matching anything else in the packet, which makes this really powerful. Having said that, while I agree with Marcelo that we should only define what we need, there is little harm in defining additional optional Flow Description formats, as long as it is clear what is actually required for interop vs what is optional. Thoughts? George On Wed, Apr 15, 2009 at 1:24 AM, Hesham Soliman wrote: > The binary description that George referred to covered the majority of us= e > cases but it doesn't cover, for instance, a filter on the 75th byte in th= e > packet. Draft-larsson covers those cases and is more generic. > The problem with doing things sequentially is that there are different ty= pes > of use cases that can occur from day 1 simultaneously. Use scenarios are = not > going to go from basic to advanced over time, they can start with advance= d > from day 1 sometimes. > > So, the safest option is to go with draft-larsson. But, the counter opini= on > here is that I'll be very surprised if organisations like 3GPP who alread= y > have binary filters (and love binary encoding) would want text encoding > because they will likely feel that it's wasteful. > > It seems like both are needed but if you have to make something wait, I'd > make the binary stuff wait till someone asks for it. It was in older > versions of the draft and it would be very simple of us to take that out = and > put it in a separate draft. > > Hesham > > > On 15/04/09 3:35 AM, "marcelo bagnulo braun" wrote: > >> i wonder if we need the advanced features at this point > I mean, we are just >> defining this, wouldn't make sense to wait and see > if with the basic >> procedure is enough and do the extnesions later? Or is > the basic mechanism so >> limited that is not enough to handle simple basic > scenarios? If that is the >> case, does it makes sense to even define it? > > Bottom line, we need strong >> reasons to do things in multiple different > ways. Unless clear reasons are >> described, i fail to see why we should > standardize multiple >> approaches > > Regards, marcelo > > > > George Tsirtsis escribi=C3=B3: >> Hi Marcelo, >> >> In >> the Monami6 days, the Flow Bindings draft used to include a binary >> Flow >> Descriptor as part of the FID option. >> This was basically a typical fixed >> length binary format defining a >> classifier filterm including source and >> destination addresses, >> protocol number, port numbers, Flow ID, and IPSEC >> SPI, if I do not >> forget something; both IPv4 and IPv6 can be supported with >> this. >> >> Some people, however, thought that more flexible FDs should be >> allowed >> and Conny's draft describes a text based format which is clearly >> more >> flexible but also more verbose. >> >> At the time, the WG decided that >> the FD format should be taken out of >> the Flow Bindings draft. I am not sure >> I like that but this is indeed >> what happened. >> So, now the Flow Bindings >> draft allows for different FD formats, but >> it does not define any of >> them. >> >> As a minimum, IMO the protocol should define one format as the >> default >> that all implementations MUST support, so that we can have >> >> interoperable implementations. >> IMO this should be the binary format which is >> the most compact and >> will work for most of the cases anyway. I do not care >> too much if this >> is defined in the same or on a separate (albeit tightly >> coupled) >> drafts. >> >> It is also ok with me to have other optional formats >> (like Conny's) >> for more advanced use cases. >> >> I hope this helps >> >> >> George >> >> =C2=A0Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >> wrote: >> >>> George Tsirtsis escribi=C3=B3: >>> >>>> Hi >> Conny, >>>> >>>> Good to see you are resurrecting this draft. I think we need >> this as >>>> one of the alternatives. We also need a binary version which I >> will be >>>> working on with others after I am done updating the Flow >> Bindings >>>> draft. >>>> >>>> >>> could you expand on this? >>> I mean, are >> you saying that we need two ways of describing flows? >>> >>> Regards, >> marcelo >>> >>> >>>> Thanks >>>> George >>>> >>>> On Tue, Apr 14, 2009 at 4:35 >> PM, Conny Larsson >>>> wrote: >>>> >>>> >>>>> >> Hi, >>>>> >>>>> This is a request to the MEXT working group to adopt >>>>> >> draft-larsson-mext-flow-distribution-rules to cover the charter >> item: >>>>> >>>>> (A.3) Use of multiple interfaces. >>>>> ... >>>>> Deliverables >> related to this include >>>>> - A "Flow/binding policies exchange" solution for >> an exchange of >>>>> policies from the mobile host/router to the Home Agent and >> from the >>>>> Home Agent to the mobile host/router influencing the choice of >> the >>>>> Care-of Address and Home Agent address. The solution involves >> two >>>>> specifications, one for the policy format and another for its >>>>> >> transport [both Standard Track]. >>>>> >>>>> >>>>> The status of the working >> group is that we have a draft >>>>> >> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>>> >> registration of multiple care-of addresses to one home address. >>>>> There >> exist one draft >>>>> >> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>> >> transport >>>>> of the rules that decides how each flow is sent over the >> available >>>>> network >>>>> interfaces. >>>>> >>>>> What is currently missing is >> the part that defines the rules. >>>>> >> draft-larsson-mext-flow-distribution-rules defines a rule language that >>>>> >> can >>>>> be used for this. The document can be found at: >>>>> >>>>> >> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>>> > >> >>>> Please express your opinion on whether this should become a WG >> document. >>>>> >>>>> >>>>> Regards >>>>> Conny >>>>> >>>>> >> _______________________________________________ >>>>> MEXT mailing list >>>>> >> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>>>> >> >>>> >>> >> >> >> > > _______________________________________________ > MEXT mailing >> list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > > From marcelo@it.uc3m.es Wed Apr 15 02:04:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3283A6911 for ; Wed, 15 Apr 2009 02:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 IyA4VR1Pi49L for ; Wed, 15 Apr 2009 02:04:38 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 838063A68DA for ; Wed, 15 Apr 2009 02:04:37 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (193.pool85-53-143.dynamic.orange.es [85.53.143.193]) by smtp03.uc3m.es (Postfix) with ESMTP id 977BD730F25; Wed, 15 Apr 2009 11:05:47 +0200 (CEST) Message-ID: <49E5A36B.3000102@it.uc3m.es> Date: Wed, 15 Apr 2009 11:05:47 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: George Tsirtsis References: <49E4BB6C.6030702@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16582.006 Cc: mext , julien.laganier.IETF@googlemail.com Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 09:04:39 -0000 George Tsirtsis escribió: > Hi Hesham, > > I think in fact the binary mechanism can easily be much more flexible > if we want to. > > All we have to do it to allow for matching to an "Offset" + "Number of > bytes". The Offset would be a pointer to X number of bytes from the > beginning of the IP header, and then the Number of Bytes, would be the > field that you are trying to match. > This has been used by classifiers for long time now (e.g., Linux, look > for U32 Selector). > > In that case, the fixed binary format can cover most of the cases and > also provide a mechanism for matching anything else in the packet, > which makes this really powerful. > > Having said that, while I agree with Marcelo that we should only > define what we need, there is little harm in defining additional > optional Flow Description formats, here is disagree there is harm and it is in term of energy of the WG and in term of the effectiveness of a standard. as people may have noticed, we do have a problem finding reviews for some documents (other documents otoh, get plenty of reviews) So, i am concerned to disipate energy through multiple documents, and i preffer to concentrate the enrgey in a single proposal the other harm is that having two standards for the same function is clearly less optimal than having only one, i guess people will not argue against that (i do understand that the path of less resistance is to get all the solutions approved and published, but if we do that, standards are meaningless, so i guess it is the chairs role to make that resistance) So, my take in the general case, is that by default we make only one standard for a given function Which one, it is up to the WG to decide regards, marcelo > as long as it is clear what is > actually required for interop vs what is optional. > > Thoughts? > George > > On Wed, Apr 15, 2009 at 1:24 AM, Hesham Soliman > wrote: > >> The binary description that George referred to covered the majority of use >> cases but it doesn't cover, for instance, a filter on the 75th byte in the >> packet. Draft-larsson covers those cases and is more generic. >> The problem with doing things sequentially is that there are different types >> of use cases that can occur from day 1 simultaneously. Use scenarios are not >> going to go from basic to advanced over time, they can start with advanced >> from day 1 sometimes. >> >> So, the safest option is to go with draft-larsson. But, the counter opinion >> here is that I'll be very surprised if organisations like 3GPP who already >> have binary filters (and love binary encoding) would want text encoding >> because they will likely feel that it's wasteful. >> >> It seems like both are needed but if you have to make something wait, I'd >> make the binary stuff wait till someone asks for it. It was in older >> versions of the draft and it would be very simple of us to take that out and >> put it in a separate draft. >> >> Hesham >> >> >> On 15/04/09 3:35 AM, "marcelo bagnulo braun" wrote: >> >> >>> i wonder if we need the advanced features at this point >>> >> I mean, we are just >> >>> defining this, wouldn't make sense to wait and see >>> >> if with the basic >> >>> procedure is enough and do the extnesions later? Or is >>> >> the basic mechanism so >> >>> limited that is not enough to handle simple basic >>> >> scenarios? If that is the >> >>> case, does it makes sense to even define it? >>> >> Bottom line, we need strong >> >>> reasons to do things in multiple different >>> >> ways. Unless clear reasons are >> >>> described, i fail to see why we should >>> >> standardize multiple >> >>> approaches >>> >> Regards, marcelo >> >> >> >> George Tsirtsis escribió: >> >>> Hi Marcelo, >>> >>> In >>> the Monami6 days, the Flow Bindings draft used to include a binary >>> Flow >>> Descriptor as part of the FID option. >>> This was basically a typical fixed >>> length binary format defining a >>> classifier filterm including source and >>> destination addresses, >>> protocol number, port numbers, Flow ID, and IPSEC >>> SPI, if I do not >>> forget something; both IPv4 and IPv6 can be supported with >>> this. >>> >>> Some people, however, thought that more flexible FDs should be >>> allowed >>> and Conny's draft describes a text based format which is clearly >>> more >>> flexible but also more verbose. >>> >>> At the time, the WG decided that >>> the FD format should be taken out of >>> the Flow Bindings draft. I am not sure >>> I like that but this is indeed >>> what happened. >>> So, now the Flow Bindings >>> draft allows for different FD formats, but >>> it does not define any of >>> them. >>> >>> As a minimum, IMO the protocol should define one format as the >>> default >>> that all implementations MUST support, so that we can have >>> >>> interoperable implementations. >>> IMO this should be the binary format which is >>> the most compact and >>> will work for most of the cases anyway. I do not care >>> too much if this >>> is defined in the same or on a separate (albeit tightly >>> coupled) >>> drafts. >>> >>> It is also ok with me to have other optional formats >>> (like Conny's) >>> for more advanced use cases. >>> >>> I hope this helps >>> >>> >>> George >>> >>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>> wrote: >>> >>> >>>> George Tsirtsis escribió: >>>> >>>> >>>>> Hi >>>>> >>> Conny, >>> >>>>> Good to see you are resurrecting this draft. I think we need >>>>> >>> this as >>> >>>>> one of the alternatives. We also need a binary version which I >>>>> >>> will be >>> >>>>> working on with others after I am done updating the Flow >>>>> >>> Bindings >>> >>>>> draft. >>>>> >>>>> >>>>> >>>> could you expand on this? >>>> I mean, are >>>> >>> you saying that we need two ways of describing flows? >>> >>>> Regards, >>>> >>> marcelo >>> >>>> >>>>> Thanks >>>>> George >>>>> >>>>> On Tue, Apr 14, 2009 at 4:35 >>>>> >>> PM, Conny Larsson >>> >>>>> wrote: >>>>> >>>>> >>>>> >>> Hi, >>> >>>>>> This is a request to the MEXT working group to adopt >>>>>> >>>>>> >>> draft-larsson-mext-flow-distribution-rules to cover the charter >>> item: >>> >>>>>> (A.3) Use of multiple interfaces. >>>>>> ... >>>>>> Deliverables >>>>>> >>> related to this include >>> >>>>>> - A "Flow/binding policies exchange" solution for >>>>>> >>> an exchange of >>> >>>>>> policies from the mobile host/router to the Home Agent and >>>>>> >>> from the >>> >>>>>> Home Agent to the mobile host/router influencing the choice of >>>>>> >>> the >>> >>>>>> Care-of Address and Home Agent address. The solution involves >>>>>> >>> two >>> >>>>>> specifications, one for the policy format and another for its >>>>>> >>>>>> >>> transport [both Standard Track]. >>> >>>>>> The status of the working >>>>>> >>> group is that we have a draft >>> >>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>> >>> registration of multiple care-of addresses to one home address. >>> >>>>>> There >>>>>> >>> exist one draft >>> >>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>> >>> transport >>> >>>>>> of the rules that decides how each flow is sent over the >>>>>> >>> available >>> >>>>>> network >>>>>> interfaces. >>>>>> >>>>>> What is currently missing is >>>>>> >>> the part that defines the rules. >>> >>> draft-larsson-mext-flow-distribution-rules defines a rule language that >>> >>> can >>> >>>>>> be used for this. The document can be found at: >>>>>> >>>>>> >>>>>> >>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>> >>>>>>> Please express your opinion on whether this should become a WG >>>>>>> >>> document. >>> >>>>>> Regards >>>>>> Conny >>>>>> >>>>>> >>>>>> >>> _______________________________________________ >>> >>>>>> MEXT mailing list >>>>>> >>>>>> >>> MEXT@ietf.org >>> >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>>>> >>>>>> >>> >>> >> _______________________________________________ >> MEXT mailing >> >>> list >>> >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> >> >> >> > > From tsirtsis@googlemail.com Wed Apr 15 02:11:24 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2ABE3A6C0C for ; Wed, 15 Apr 2009 02:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 QCYiuPjdWHc0 for ; Wed, 15 Apr 2009 02:11:23 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id C0D153A6A74 for ; Wed, 15 Apr 2009 02:11:21 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so3969447yxm.49 for ; Wed, 15 Apr 2009 02:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=DKh/Vg6dGM677ZX7V19BzwcmPXpyjioIWMZY3Ipc6vI=; b=gpFysSwHysjilIr50twLK5Ra/c4lSKz4MQV+SlBbIqBCH5WcZIfKi7Opfe1UNw3ZYO 4lM6kssPRibt5qnFaXl5JoYO2MvLnxPEl0BQjnta45adDC8+sQAOUZlpjEJOvQkVfWyR ey2u5Tg5/lcJn7o7FcvlQ5T4Px5CHfpCccJzE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ie6TdEhX6GGAkAOx+WvYt1UOp0R1409832v34ldyRkEGFHsyk77C/tpJgb+ewkHARR s/D+rjGWV5Vc/E6hUZy0y0qGA21prkKEk6WI7MDl2E1h7viQQMVrBQLTsN4VWen/yCaG KTK9wnEH7LA1tNdFQFBD2NrJ9gCpJOvv3OtWk= MIME-Version: 1.0 Received: by 10.90.101.17 with SMTP id y17mr8298agb.26.1239786735641; Wed, 15 Apr 2009 02:12:15 -0700 (PDT) In-Reply-To: <49E5A36B.3000102@it.uc3m.es> References: <49E4BB6C.6030702@it.uc3m.es> <49E5A36B.3000102@it.uc3m.es> Date: Wed, 15 Apr 2009 10:12:15 +0100 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext , julien.laganier.IETF@googlemail.com Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 09:11:24 -0000 OK Marcelo, I see. I said I am not against multiple solutions in this case because they are not in direct competition with each other. I see your point regarding reviews, however, which is a separate issue. George On Wed, Apr 15, 2009 at 10:05 AM, marcelo bagnulo braun wrote: > George Tsirtsis escribi=C3=B3: >> >> Hi Hesham, >> >> I think in fact the binary mechanism can easily be much more flexible >> if we want to. >> >> All we have to do it to allow for matching to an "Offset" + "Number of >> bytes". The Offset would be a pointer to X number of bytes from the >> beginning of the IP header, and then the Number of Bytes, would be the >> field that you are trying to match. >> This has been used by classifiers for long time now (e.g., Linux, look >> for U32 Selector). >> >> In that case, the fixed binary format can cover most of the cases and >> also provide a mechanism for matching anything else in the packet, >> which makes this really powerful. >> >> Having said that, while I agree with Marcelo that we should only >> define what we need, there is little harm in defining additional >> optional Flow Description formats, > > here is disagree > > there is harm and it is in term of energy of the WG and in term of the > effectiveness of a standard. > > as people may have noticed, we do have a problem finding reviews for some > documents (other documents otoh, get plenty of reviews) > So, i am concerned to disipate energy through multiple documents, and i > preffer to concentrate the enrgey in a single proposal > > the other harm is that having two standards for the same function is clea= rly > less optimal than having only one, i guess people will not argue against > that > > (i do understand that the path of less resistance is to get all the > solutions approved and published, but if we do that, standards are > meaningless, so i guess it is the chairs role to make that resistance) > > So, my take in the general case, is that by default we make only one > standard for a given function > > Which one, it is up to the WG to decide > > regards, marcelo > >> =C2=A0as long as it is clear what is >> actually required for interop vs what is optional. >> >> Thoughts? >> George >> >> On Wed, Apr 15, 2009 at 1:24 AM, Hesham Soliman >> wrote: >> >>> >>> The binary description that George referred to covered the majority of >>> use >>> cases but it doesn't cover, for instance, a filter on the 75th byte in >>> the >>> packet. Draft-larsson covers those cases and is more generic. >>> The problem with doing things sequentially is that there are different >>> types >>> of use cases that can occur from day 1 simultaneously. Use scenarios ar= e >>> not >>> going to go from basic to advanced over time, they can start with >>> advanced >>> from day 1 sometimes. >>> >>> So, the safest option is to go with draft-larsson. But, the counter >>> opinion >>> here is that I'll be very surprised if organisations like 3GPP who >>> already >>> have binary filters (and love binary encoding) would want text encoding >>> because they will likely feel that it's wasteful. >>> >>> It seems like both are needed but if you have to make something wait, I= 'd >>> make the binary stuff wait till someone asks for it. It was in older >>> versions of the draft and it would be very simple of us to take that ou= t >>> and >>> put it in a separate draft. >>> >>> Hesham >>> >>> >>> On 15/04/09 3:35 AM, "marcelo bagnulo braun" wrote= : >>> >>> >>>> >>>> i wonder if we need the advanced features at this point >>>> >>> >>> I mean, we are just >>> >>>> >>>> defining this, wouldn't make sense to wait and see >>>> >>> >>> if with the basic >>> >>>> >>>> procedure is enough and do the extnesions later? Or is >>>> >>> >>> the basic mechanism so >>> >>>> >>>> limited that is not enough to handle simple basic >>>> >>> >>> scenarios? If that is the >>> >>>> >>>> case, does it makes sense to even define it? >>>> >>> >>> Bottom line, we need strong >>> >>>> >>>> reasons to do things in multiple different >>>> >>> >>> ways. Unless clear reasons are >>> >>>> >>>> described, i fail to see why we should >>>> >>> >>> standardize multiple >>> >>>> >>>> approaches >>>> >>> >>> Regards, marcelo >>> >>> >>> >>> George Tsirtsis escribi=C3=B3: >>> >>>> >>>> Hi Marcelo, >>>> >>>> In >>>> the Monami6 days, the Flow Bindings draft used to include a binary >>>> Flow >>>> Descriptor as part of the FID option. >>>> This was basically a typical fixed >>>> length binary format defining a >>>> classifier filterm including source and >>>> destination addresses, >>>> protocol number, port numbers, Flow ID, and IPSEC >>>> SPI, if I do not >>>> forget something; both IPv4 and IPv6 can be supported with >>>> this. >>>> >>>> Some people, however, thought that more flexible FDs should be >>>> allowed >>>> and Conny's draft describes a text based format which is clearly >>>> more >>>> flexible but also more verbose. >>>> >>>> At the time, the WG decided that >>>> the FD format should be taken out of >>>> the Flow Bindings draft. I am not sure >>>> I like that but this is indeed >>>> what happened. >>>> So, now the Flow Bindings >>>> draft allows for different FD formats, but >>>> it does not define any of >>>> them. >>>> >>>> As a minimum, IMO the protocol should define one format as the >>>> default >>>> that all implementations MUST support, so that we can have >>>> >>>> interoperable implementations. >>>> IMO this should be the binary format which is >>>> the most compact and >>>> will work for most of the cases anyway. I do not care >>>> too much if this >>>> is defined in the same or on a separate (albeit tightly >>>> coupled) >>>> drafts. >>>> >>>> It is also ok with me to have other optional formats >>>> (like Conny's) >>>> for more advanced use cases. >>>> >>>> I hope this helps >>>> >>>> >>>> George >>>> >>>> =C2=A0Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>> wrote: >>>> >>>> >>>>> >>>>> George Tsirtsis escribi=C3=B3: >>>>> >>>>> >>>>>> >>>>>> Hi >>>>>> >>>> >>>> Conny, >>>> >>>>>> >>>>>> Good to see you are resurrecting this draft. I think we need >>>>>> >>>> >>>> this as >>>> >>>>>> >>>>>> one of the alternatives. We also need a binary version which I >>>>>> >>>> >>>> will be >>>> >>>>>> >>>>>> working on with others after I am done updating the Flow >>>>>> >>>> >>>> Bindings >>>> >>>>>> >>>>>> draft. >>>>>> >>>>>> >>>>>> >>>>> >>>>> could you expand on this? >>>>> I mean, are >>>>> >>>> >>>> you saying that we need two ways of describing flows? >>>> >>>>> >>>>> Regards, >>>>> >>>> >>>> marcelo >>>> >>>>> >>>>> >>>>>> >>>>>> Thanks >>>>>> George >>>>>> >>>>>> On Tue, Apr 14, 2009 at 4:35 >>>>>> >>>> >>>> PM, Conny Larsson >>>> >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>> >>>> Hi, >>>> >>>>>>> >>>>>>> This is a request to the MEXT working group to adopt >>>>>>> >>>>>>> >>>> >>>> draft-larsson-mext-flow-distribution-rules to cover the charter >>>> item: >>>> >>>>>>> >>>>>>> (A.3) Use of multiple interfaces. >>>>>>> ... >>>>>>> Deliverables >>>>>>> >>>> >>>> related to this include >>>> >>>>>>> >>>>>>> - A "Flow/binding policies exchange" solution for >>>>>>> >>>> >>>> an exchange of >>>> >>>>>>> >>>>>>> policies from the mobile host/router to the Home Agent and >>>>>>> >>>> >>>> from the >>>> >>>>>>> >>>>>>> Home Agent to the mobile host/router influencing the choice of >>>>>>> >>>> >>>> the >>>> >>>>>>> >>>>>>> Care-of Address and Home Agent address. The solution involves >>>>>>> >>>> >>>> two >>>> >>>>>>> >>>>>>> specifications, one for the policy format and another for its >>>>>>> >>>>>>> >>>> >>>> transport [both Standard Track]. >>>> >>>>>>> >>>>>>> The status of the working >>>>>>> >>>> >>>> group is that we have a draft >>>> =C2=A0 =C2=A0 =C2=A0(http://tools.ietf.org/html/draft-ietf-monami6-mul= tiplecoa-12) for >>>> =C2=A0 =C2=A0 =C2=A0registration of multiple care-of addresses to one = home address. >>>> >>>>>>> >>>>>>> There >>>>>>> >>>> >>>> exist one draft >>>> =C2=A0 =C2=A0 =C2=A0(http://tools.ietf.org/html/draft-ietf-mext-flow-b= inding-01) for >>>> =C2=A0 =C2=A0 =C2=A0transport >>>> >>>>>>> >>>>>>> of the rules that decides how each flow is sent over the >>>>>>> >>>> >>>> available >>>> >>>>>>> >>>>>>> network >>>>>>> interfaces. >>>>>>> >>>>>>> What is currently missing is >>>>>>> >>>> >>>> the part that defines the rules. >>>> =C2=A0 =C2=A0 =C2=A0draft-larsson-mext-flow-distribution-rules defines= a rule language >>>> that >>>> =C2=A0 =C2=A0 =C2=A0can >>>> >>>>>>> >>>>>>> be used for this. The document can be found at: >>>>>>> >>>>>>> >>>>>>> >>>> >>>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-= 02 >>>> >>>>>>>> >>>>>>>> Please express your opinion on whether this should become a WG >>>>>>>> >>>> >>>> document. >>>> >>>>>>> >>>>>>> Regards >>>>>>> Conny >>>>>>> >>>>>>> >>>>>>> >>>> >>>> _______________________________________________ >>>> >>>>>>> >>>>>>> MEXT mailing list >>>>>>> >>>>>>> >>>> >>>> MEXT@ietf.org >>>> >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> >>>> >>> >>> _______________________________________________ >>> MEXT mailing >>> >>>> >>>> list >>>> >>> >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> >>> >> >> > > From kaaspetersen@yahoo.dk Wed Apr 15 02:22:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D457C3A68E6 for ; Wed, 15 Apr 2009 02:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 vsaLhE0UPKYM for ; Wed, 15 Apr 2009 02:22:40 -0700 (PDT) Received: from web27807.mail.ukl.yahoo.com (web27807.mail.ukl.yahoo.com [217.146.182.12]) by core3.amsl.com (Postfix) with SMTP id 034C53A67F1 for ; Wed, 15 Apr 2009 02:22:39 -0700 (PDT) Received: (qmail 86137 invoked by uid 60001); 15 Apr 2009 09:23:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.dk; s=s1024; t=1239787431; bh=wRwK6zEvrvd18gSILR3EyPQje3Wu5LuWQTfMvmZIPuI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SgrHUHaw9gdpLfKifYEY95O3476U69dLEF2H3xoQsD11QEoWS9/69sbqHGLumxS/G0GbzN96mmvTcdc5qx8gaO2OEDLTeyhngTuNxB/p0S4YwtD2OKTVsnz9BnqlyZaIMR9oW4V1Uzg/yIZZgszKX1nbY2rtMse9/M6aaWoe9gk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.dk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HG8bg+OCGCZQjmeaHj3MTOleIXk5s8YSeI2RkrWFm6fByMf6kEmx8PekUNmVancJTbk2ODnGM/Et2QMZZgnbP1hPjw+O0ylFezqO0qoz0IAhmyIvYxK6XOvF7jqBC1G8836RM3dl5EEfDWZO1+c8JKF1Vn7LWULAeau1CqundAs=; Message-ID: <657051.66216.qm@web27807.mail.ukl.yahoo.com> X-YMail-OSG: nzmy_SQVM1l4cFY_FU_yoX8RPp6vBe4CpijB1NXVktMnlw8U.3vv4bhCoxD781wFIHK1lU3wsXd.6HkR4or6DEaEJavnZaa_STiylzCcde5N6X3buALeyW735iwBY962C_bXelLfm9jhOBlwHPxX9.e8ltC5D7Lwc4dhkSgPxtREH6xdJH1mfECEYRPiHQNec4lKt._595._CjUws.8C7HPEabqk8xUjxhaRD9Yw6rO3iTdkG_y0VFKaw2w5LIXsK2pKi9hsDb2aoXrCGkXnDiFm9gCweBreuTdkEa6Yuqvh9wBeR5p1bxamott_aPVO182nIZ0LZ9ulhiFHU7qM5IfisMSLvioWY6H4pHg- Received: from [193.15.240.60] by web27807.mail.ukl.yahoo.com via HTTP; Wed, 15 Apr 2009 09:23:51 GMT X-Mailer: YahooMailClassic/5.2.15 YahooMailWebService/0.7.289.1 Date: Wed, 15 Apr 2009 09:23:51 +0000 (GMT) From: Christian Kaas-Petersen To: George Tsirtsis , marcelo bagnulo braun MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 09:22:46 -0000 Actually, IETF 74th Thursday plenary on MPLS discussed the situation of have alternative protocols (LDP vs RSVP was just one example) doing the same thing. The statements made by the speakers and from the floor were: Yes it is a pain to implement two protocols, and yes it is a pain to deploy two protocols. However, most often it turns out, that one of the protocols is left in oblivion when it has been seen running in practice, and most often taking a second approach gives renewed input or energy to the first approach, making it clear which of the two approaches is the favoured one. Thus I went away with the impression, that staying with one approach is in fact not always the obvious thing to do. Christian=20 --- Den ons 15/4/09 skrev marcelo bagnulo braun : > Fra: marcelo bagnulo braun > Emne: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribut= ion-rules > Til: "George Tsirtsis" > Cc: "mext" , julien.laganier.IETF@googlemail.com > Dato: onsdag 15. april 2009 11.05 > George Tsirtsis escribi=F3: > > Hi Hesham, > > > > I think in fact the binary mechanism can easily be > much more flexible > > if we want to. > > > > All we have to do it to allow for matching to an > "Offset" + "Number of > > bytes". The Offset would be a pointer to X number of > bytes from the > > beginning of the IP header, and then the Number of > Bytes, would be the > > field that you are trying to match. > > This has been used by classifiers for long time now > (e.g., Linux, look > > for U32 Selector). > > > > In that case, the fixed binary format can cover most > of the cases and > > also provide a mechanism for matching anything else in > the packet, > > which makes this really powerful. > > > > Having said that, while I agree with Marcelo that we > should only > > define what we need, there is little harm in defining > additional > > optional Flow Description formats, >=20 > here is disagree >=20 > there is harm and it is in term of energy of the WG and in > term of the=20 > effectiveness of a standard. >=20 > as people may have noticed, we do have a problem finding > reviews for=20 > some documents (other documents otoh, get plenty of > reviews) > So, i am concerned to disipate energy through multiple > documents, and i=20 > preffer to concentrate the enrgey in a single proposal >=20 > the other harm is that having two standards for the same > function is=20 > clearly less optimal than having only one, i guess people > will not argue=20 > against that >=20 > (i do understand that the path of less resistance is to get > all the=20 > solutions approved and published, but if we do that, > standards are=20 > meaningless, so i guess it is the chairs role to make that > resistance) >=20 > So, my take in the general case, is that by default we make > only one=20 > standard for a given function >=20 > Which one, it is up to the WG to decide >=20 > regards, marcelo =0A=0A=0A __________________________________________________________ = =0AFind din nye laptop p=E5 kelkoo.dk. Se de gode tilbud her - http://dk.ya= hoo.com/r/pat/mm From Xiangsong.Cui@huawei.com Wed Apr 15 02:31:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C02A3A693C for ; Wed, 15 Apr 2009 02:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.548 X-Spam-Level: **** X-Spam-Status: No, score=4.548 tagged_above=-999 required=5 tests=[AWL=1.608, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MY_CID_AND_STYLE=1.54, RDNS_NONE=0.1, T_TVD_FW_GRAPHIC_ID1=0.01] 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 peFJ4hhIFrry for ; Wed, 15 Apr 2009 02:31:33 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 620F43A6403 for ; Wed, 15 Apr 2009 02:31:32 -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 <0KI400KQ7YHD25@szxga03-in.huawei.com> for mext@ietf.org; Wed, 15 Apr 2009 17:32:02 +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 <0KI40050XYHCAR@szxga03-in.huawei.com> for mext@ietf.org; Wed, 15 Apr 2009 17:32:01 +0800 (CST) Date: Wed, 15 Apr 2009 17:32:00 +0800 From: Xiangsong Cui To: marcelo bagnulo braun , George Tsirtsis Message-id: <0b3a01c9bdad$076967b0$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.3138 Content-type: multipart/related; boundary="Boundary_(ID_j5bdNkblIRt3jr6AEdDKHw)"; type="multipart/alternative" X-Priority: 3 X-MSMail-priority: Normal References: <49E4BB6C.6030702@it.uc3m.es> <49E5A36B.3000102@it.uc3m.es> Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation ofdraft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 09:31:35 -0000 This is a multi-part message in MIME format. --Boundary_(ID_j5bdNkblIRt3jr6AEdDKHw) Content-type: multipart/alternative; boundary="Boundary_(ID_cj42c7adv3uxHg4+l6yoqg)" --Boundary_(ID_cj42c7adv3uxHg4+l6yoqg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGksDQoNCj4gYXMgcGVvcGxlIG1heSBoYXZlIG5vdGljZWQsIHdlIGRvIGhhdmUgYSBwcm9ibGVt IGZpbmRpbmcgcmV2aWV3cyBmb3IgDQo+IHNvbWUgZG9jdW1lbnRzIChvdGhlciBkb2N1bWVudHMg b3RvaCwgZ2V0IHBsZW50eSBvZiByZXZpZXdzKQ0KPiBTbywgaSBhbSBjb25jZXJuZWQgdG8gZGlz aXBhdGUgZW5lcmd5IHRocm91Z2ggbXVsdGlwbGUgZG9jdW1lbnRzLCBhbmQgaSANCj4gcHJlZmZl ciB0byBjb25jZW50cmF0ZSB0aGUgZW5yZ2V5IGluIGEgc2luZ2xlIHByb3Bvc2FsDQoNCj09PT09 PiBJIGNhbWUgdG8gSUVURiByZWNlbnRseSBhbmQgSSB2b2x1bnRlZXIgdG8gd29ya3MgaW4gV29y ayBHcm91cC4NCiAgICAgICBJIHdpbGwgdHJ5IHRvIGRvIHRoZSBqb2IgYmV0dGVyLiA6KQ0KDQpy ZWdhcmRzDQoNClhpYW5nc29uZw0KDQoNCuWNjuS4uuaKgOacr+aciemZkOWFrOWPuCAgDQoNCg0K 5Zyw5Z2A77ya5rex5Zyz5biC6b6Z5bKX5Yy65Z2C55Sw5Y2O5Li65Z+65ZywIOmCrue8lu+8mjUx ODEyOQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQrmnKzpgq7k u7blj4rlhbbpmYTku7blkKvmnInljY7kuLrlhazlj7jnmoTkv53lr4bkv6Hmga/vvIzku4XpmZDk uo7lj5HpgIHnu5nkuIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrkurrmiJbnvqTnu4TjgILnpoEN CuatouS7u+S9leWFtuS7luS6uuS7peS7u+S9leW9ouW8j+S9v+eUqO+8iOWMheaLrOS9huS4jemZ kOS6juWFqOmDqOaIlumDqOWIhuWcsOazhOmcsuOAgeWkjeWItuOAgeaIluaVo+WPke+8ieacrOmC ruS7tuS4rQ0K55qE5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM6K+35oKo 56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu5Lu277yB DQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGlu Zm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCANCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBw ZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9m IHRoZSANCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5n LCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgDQpkaXNjbG9zdXJlLCByZXBy b2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50 ZW5kZWQgDQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBl LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSANCnBob25lIG9yIGVt YWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCiAgRnJvbTogbWFyY2VsbyBiYWdudWxvIGJyYXVuIA0KICBUbzogR2VvcmdlIFRz aXJ0c2lzIA0KICBDYzogbWV4dCA7IGp1bGllbi5sYWdhbmllci5JRVRGQGdvb2dsZW1haWwuY29t IA0KICBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE1LCAyMDA5IDU6MDUgUE0NCiAgU3ViamVjdDog UmU6IFtNRVhUXSBDYWxsIGZvciBhZG9wdGF0aW9uIG9mZHJhZnQtbGFyc3Nvbi1tZXh0LWZsb3ct ZGlzdHJpYnV0aW9uLXJ1bGVzDQoNCg0KICBHZW9yZ2UgVHNpcnRzaXMgZXNjcmliacOzOg0KICA+ IEhpIEhlc2hhbSwNCiAgPg0KICA+IEkgdGhpbmsgaW4gZmFjdCB0aGUgYmluYXJ5IG1lY2hhbmlz bSBjYW4gZWFzaWx5IGJlIG11Y2ggbW9yZSBmbGV4aWJsZQ0KICA+IGlmIHdlIHdhbnQgdG8uDQog ID4NCiAgPiBBbGwgd2UgaGF2ZSB0byBkbyBpdCB0byBhbGxvdyBmb3IgbWF0Y2hpbmcgdG8gYW4g Ik9mZnNldCIgKyAiTnVtYmVyIG9mDQogID4gYnl0ZXMiLiBUaGUgT2Zmc2V0IHdvdWxkIGJlIGEg cG9pbnRlciB0byBYIG51bWJlciBvZiBieXRlcyBmcm9tIHRoZQ0KICA+IGJlZ2lubmluZyBvZiB0 aGUgSVAgaGVhZGVyLCBhbmQgdGhlbiB0aGUgTnVtYmVyIG9mIEJ5dGVzLCB3b3VsZCBiZSB0aGUN CiAgPiBmaWVsZCB0aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIG1hdGNoLg0KICA+IFRoaXMgaGFzIGJl ZW4gdXNlZCBieSBjbGFzc2lmaWVycyBmb3IgbG9uZyB0aW1lIG5vdyAoZS5nLiwgTGludXgsIGxv b2sNCiAgPiBmb3IgVTMyIFNlbGVjdG9yKS4NCiAgPg0KICA+IEluIHRoYXQgY2FzZSwgdGhlIGZp eGVkIGJpbmFyeSBmb3JtYXQgY2FuIGNvdmVyIG1vc3Qgb2YgdGhlIGNhc2VzIGFuZA0KICA+IGFs c28gcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IgbWF0Y2hpbmcgYW55dGhpbmcgZWxzZSBpbiB0aGUg cGFja2V0LA0KICA+IHdoaWNoIG1ha2VzIHRoaXMgcmVhbGx5IHBvd2VyZnVsLg0KICA+DQogID4g SGF2aW5nIHNhaWQgdGhhdCwgd2hpbGUgSSBhZ3JlZSB3aXRoIE1hcmNlbG8gdGhhdCB3ZSBzaG91 bGQgb25seQ0KICA+IGRlZmluZSB3aGF0IHdlIG5lZWQsIHRoZXJlIGlzIGxpdHRsZSBoYXJtIGlu IGRlZmluaW5nIGFkZGl0aW9uYWwNCiAgPiBvcHRpb25hbCBGbG93IERlc2NyaXB0aW9uIGZvcm1h dHMsDQoNCiAgaGVyZSBpcyBkaXNhZ3JlZQ0KDQogIHRoZXJlIGlzIGhhcm0gYW5kIGl0IGlzIGlu IHRlcm0gb2YgZW5lcmd5IG9mIHRoZSBXRyBhbmQgaW4gdGVybSBvZiB0aGUgDQogIGVmZmVjdGl2 ZW5lc3Mgb2YgYSBzdGFuZGFyZC4NCg0KICBhcyBwZW9wbGUgbWF5IGhhdmUgbm90aWNlZCwgd2Ug ZG8gaGF2ZSBhIHByb2JsZW0gZmluZGluZyByZXZpZXdzIGZvciANCiAgc29tZSBkb2N1bWVudHMg KG90aGVyIGRvY3VtZW50cyBvdG9oLCBnZXQgcGxlbnR5IG9mIHJldmlld3MpDQogIFNvLCBpIGFt IGNvbmNlcm5lZCB0byBkaXNpcGF0ZSBlbmVyZ3kgdGhyb3VnaCBtdWx0aXBsZSBkb2N1bWVudHMs IGFuZCBpIA0KICBwcmVmZmVyIHRvIGNvbmNlbnRyYXRlIHRoZSBlbnJnZXkgaW4gYSBzaW5nbGUg cHJvcG9zYWwNCg0KICB0aGUgb3RoZXIgaGFybSBpcyB0aGF0IGhhdmluZyB0d28gc3RhbmRhcmRz IGZvciB0aGUgc2FtZSBmdW5jdGlvbiBpcyANCiAgY2xlYXJseSBsZXNzIG9wdGltYWwgdGhhbiBo YXZpbmcgb25seSBvbmUsIGkgZ3Vlc3MgcGVvcGxlIHdpbGwgbm90IGFyZ3VlIA0KICBhZ2FpbnN0 IHRoYXQNCg0KICAoaSBkbyB1bmRlcnN0YW5kIHRoYXQgdGhlIHBhdGggb2YgbGVzcyByZXNpc3Rh bmNlIGlzIHRvIGdldCBhbGwgdGhlIA0KICBzb2x1dGlvbnMgYXBwcm92ZWQgYW5kIHB1Ymxpc2hl ZCwgYnV0IGlmIHdlIGRvIHRoYXQsIHN0YW5kYXJkcyBhcmUgDQogIG1lYW5pbmdsZXNzLCBzbyBp IGd1ZXNzIGl0IGlzIHRoZSBjaGFpcnMgcm9sZSB0byBtYWtlIHRoYXQgcmVzaXN0YW5jZSkNCg0K ICBTbywgbXkgdGFrZSBpbiB0aGUgZ2VuZXJhbCBjYXNlLCBpcyB0aGF0IGJ5IGRlZmF1bHQgd2Ug bWFrZSBvbmx5IG9uZSANCiAgc3RhbmRhcmQgZm9yIGEgZ2l2ZW4gZnVuY3Rpb24NCg0KICBXaGlj aCBvbmUsIGl0IGlzIHVwIHRvIHRoZSBXRyB0byBkZWNpZGUNCg0KICByZWdhcmRzLCBtYXJjZWxv DQoNCiAgPiAgYXMgbG9uZyBhcyBpdCBpcyBjbGVhciB3aGF0IGlzDQogID4gYWN0dWFsbHkgcmVx dWlyZWQgZm9yIGludGVyb3AgdnMgd2hhdCBpcyBvcHRpb25hbC4NCiAgPg0KICA+IFRob3VnaHRz Pw0KICA+IEdlb3JnZQ0KICA+DQogID4gT24gV2VkLCBBcHIgMTUsIDIwMDkgYXQgMToyNCBBTSwg SGVzaGFtIFNvbGltYW4NCiAgPiA8aGVzaGFtQGVsZXZhdGVtb2JpbGUuY29tPiB3cm90ZToNCiAg PiAgIA0KICA+PiBUaGUgYmluYXJ5IGRlc2NyaXB0aW9uIHRoYXQgR2VvcmdlIHJlZmVycmVkIHRv IGNvdmVyZWQgdGhlIG1ham9yaXR5IG9mIHVzZQ0KICA+PiBjYXNlcyBidXQgaXQgZG9lc24ndCBj b3ZlciwgZm9yIGluc3RhbmNlLCBhIGZpbHRlciBvbiB0aGUgNzV0aCBieXRlIGluIHRoZQ0KICA+ PiBwYWNrZXQuIERyYWZ0LWxhcnNzb24gY292ZXJzIHRob3NlIGNhc2VzIGFuZCBpcyBtb3JlIGdl bmVyaWMuDQogID4+IFRoZSBwcm9ibGVtIHdpdGggZG9pbmcgdGhpbmdzIHNlcXVlbnRpYWxseSBp cyB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbnQgdHlwZXMNCiAgPj4gb2YgdXNlIGNhc2VzIHRoYXQg Y2FuIG9jY3VyIGZyb20gZGF5IDEgc2ltdWx0YW5lb3VzbHkuIFVzZSBzY2VuYXJpb3MgYXJlIG5v dA0KICA+PiBnb2luZyB0byBnbyBmcm9tIGJhc2ljIHRvIGFkdmFuY2VkIG92ZXIgdGltZSwgdGhl eSBjYW4gc3RhcnQgd2l0aCBhZHZhbmNlZA0KICA+PiBmcm9tIGRheSAxIHNvbWV0aW1lcy4NCiAg Pj4NCiAgPj4gU28sIHRoZSBzYWZlc3Qgb3B0aW9uIGlzIHRvIGdvIHdpdGggZHJhZnQtbGFyc3Nv bi4gQnV0LCB0aGUgY291bnRlciBvcGluaW9uDQogID4+IGhlcmUgaXMgdGhhdCBJJ2xsIGJlIHZl cnkgc3VycHJpc2VkIGlmIG9yZ2FuaXNhdGlvbnMgbGlrZSAzR1BQIHdobyBhbHJlYWR5DQogID4+ IGhhdmUgYmluYXJ5IGZpbHRlcnMgKGFuZCBsb3ZlIGJpbmFyeSBlbmNvZGluZykgd291bGQgd2Fu dCB0ZXh0IGVuY29kaW5nDQogID4+IGJlY2F1c2UgdGhleSB3aWxsIGxpa2VseSBmZWVsIHRoYXQg aXQncyB3YXN0ZWZ1bC4NCiAgPj4NCiAgPj4gSXQgc2VlbXMgbGlrZSBib3RoIGFyZSBuZWVkZWQg YnV0IGlmIHlvdSBoYXZlIHRvIG1ha2Ugc29tZXRoaW5nIHdhaXQsIEknZA0KICA+PiBtYWtlIHRo ZSBiaW5hcnkgc3R1ZmYgd2FpdCB0aWxsIHNvbWVvbmUgYXNrcyBmb3IgaXQuIEl0IHdhcyBpbiBv bGRlcg0KICA+PiB2ZXJzaW9ucyBvZiB0aGUgZHJhZnQgYW5kIGl0IHdvdWxkIGJlIHZlcnkgc2lt cGxlIG9mIHVzIHRvIHRha2UgdGhhdCBvdXQgYW5kDQogID4+IHB1dCBpdCBpbiBhIHNlcGFyYXRl IGRyYWZ0Lg0KICA+Pg0KICA+PiBIZXNoYW0NCiAgPj4NCiAgPj4NCiAgPj4gT24gMTUvMDQvMDkg MzozNSBBTSwgIm1hcmNlbG8gYmFnbnVsbyBicmF1biIgPG1hcmNlbG9AaXQudWMzbS5lcz4gd3Jv dGU6DQogID4+DQogID4+ICAgICANCiAgPj4+IGkgd29uZGVyIGlmIHdlIG5lZWQgdGhlIGFkdmFu Y2VkIGZlYXR1cmVzIGF0IHRoaXMgcG9pbnQNCiAgPj4+ICAgICAgIA0KICA+PiBJIG1lYW4sIHdl IGFyZSBqdXN0DQogID4+ICAgICANCiAgPj4+IGRlZmluaW5nIHRoaXMsIHdvdWxkbid0IG1ha2Ug c2Vuc2UgdG8gd2FpdCBhbmQgc2VlDQogID4+PiAgICAgICANCiAgPj4gaWYgd2l0aCB0aGUgYmFz aWMNCiAgPj4gICAgIA0KICA+Pj4gcHJvY2VkdXJlIGlzIGVub3VnaCBhbmQgZG8gdGhlIGV4dG5l c2lvbnMgbGF0ZXI/IE9yIGlzDQogID4+PiAgICAgICANCiAgPj4gdGhlIGJhc2ljIG1lY2hhbmlz bSBzbw0KICA+PiAgICAgDQogID4+PiBsaW1pdGVkIHRoYXQgaXMgbm90IGVub3VnaCB0byBoYW5k bGUgc2ltcGxlIGJhc2ljDQogID4+PiAgICAgICANCiAgPj4gc2NlbmFyaW9zPyBJZiB0aGF0IGlz IHRoZQ0KICA+PiAgICAgDQogID4+PiBjYXNlLCBkb2VzIGl0IG1ha2VzIHNlbnNlIHRvIGV2ZW4g ZGVmaW5lIGl0Pw0KICA+Pj4gICAgICAgDQogID4+IEJvdHRvbSBsaW5lLCB3ZSBuZWVkIHN0cm9u Zw0KICA+PiAgICAgDQogID4+PiByZWFzb25zIHRvIGRvIHRoaW5ncyBpbiBtdWx0aXBsZSBkaWZm ZXJlbnQNCiAgPj4+ICAgICAgIA0KICA+PiB3YXlzLiBVbmxlc3MgY2xlYXIgcmVhc29ucyBhcmUN CiAgPj4gICAgIA0KICA+Pj4gZGVzY3JpYmVkLCBpIGZhaWwgdG8gc2VlIHdoeSB3ZSBzaG91bGQN CiAgPj4+ICAgICAgIA0KICA+PiBzdGFuZGFyZGl6ZSBtdWx0aXBsZQ0KICA+PiAgICAgDQogID4+ PiBhcHByb2FjaGVzDQogID4+PiAgICAgICANCiAgPj4gUmVnYXJkcywgbWFyY2Vsbw0KICA+Pg0K ICA+Pg0KICA+Pg0KICA+PiBHZW9yZ2UgVHNpcnRzaXMgZXNjcmliacOzOg0KICA+PiAgICAgDQog ID4+PiBIaSBNYXJjZWxvLA0KICA+Pj4NCiAgPj4+IEluDQogID4+PiB0aGUgTW9uYW1pNiBkYXlz LCB0aGUgRmxvdyBCaW5kaW5ncyBkcmFmdCB1c2VkIHRvIGluY2x1ZGUgYSBiaW5hcnkNCiAgPj4+ IEZsb3cNCiAgPj4+IERlc2NyaXB0b3IgYXMgcGFydCBvZiB0aGUgRklEIG9wdGlvbi4NCiAgPj4+ IFRoaXMgd2FzIGJhc2ljYWxseSBhIHR5cGljYWwgZml4ZWQNCiAgPj4+IGxlbmd0aCBiaW5hcnkg Zm9ybWF0IGRlZmluaW5nIGENCiAgPj4+IGNsYXNzaWZpZXIgZmlsdGVybSBpbmNsdWRpbmcgc291 cmNlIGFuZA0KICA+Pj4gZGVzdGluYXRpb24gYWRkcmVzc2VzLA0KICA+Pj4gcHJvdG9jb2wgbnVt YmVyLCBwb3J0IG51bWJlcnMsIEZsb3cgSUQsIGFuZCBJUFNFQw0KICA+Pj4gU1BJLCBpZiBJIGRv IG5vdA0KICA+Pj4gZm9yZ2V0IHNvbWV0aGluZzsgYm90aCBJUHY0IGFuZCBJUHY2IGNhbiBiZSBz dXBwb3J0ZWQgd2l0aA0KICA+Pj4gdGhpcy4NCiAgPj4+DQogID4+PiBTb21lIHBlb3BsZSwgaG93 ZXZlciwgdGhvdWdodCB0aGF0IG1vcmUgZmxleGlibGUgRkRzIHNob3VsZCBiZQ0KICA+Pj4gYWxs b3dlZA0KICA+Pj4gYW5kIENvbm55J3MgZHJhZnQgZGVzY3JpYmVzIGEgdGV4dCBiYXNlZCBmb3Jt YXQgd2hpY2ggaXMgY2xlYXJseQ0KICA+Pj4gbW9yZQ0KICA+Pj4gZmxleGlibGUgYnV0IGFsc28g bW9yZSB2ZXJib3NlLg0KICA+Pj4NCiAgPj4+IEF0IHRoZSB0aW1lLCB0aGUgV0cgZGVjaWRlZCB0 aGF0DQogID4+PiB0aGUgRkQgZm9ybWF0IHNob3VsZCBiZSB0YWtlbiBvdXQgb2YNCiAgPj4+IHRo ZSBGbG93IEJpbmRpbmdzIGRyYWZ0LiBJIGFtIG5vdCBzdXJlDQogID4+PiBJIGxpa2UgdGhhdCBi dXQgdGhpcyBpcyBpbmRlZWQNCiAgPj4+IHdoYXQgaGFwcGVuZWQuDQogID4+PiBTbywgbm93IHRo ZSBGbG93IEJpbmRpbmdzDQogID4+PiBkcmFmdCBhbGxvd3MgZm9yIGRpZmZlcmVudCBGRCBmb3Jt YXRzLCBidXQNCiAgPj4+IGl0IGRvZXMgbm90IGRlZmluZSBhbnkgb2YNCiAgPj4+IHRoZW0uDQog ID4+Pg0KICA+Pj4gQXMgYSBtaW5pbXVtLCBJTU8gdGhlIHByb3RvY29sIHNob3VsZCBkZWZpbmUg b25lIGZvcm1hdCBhcyB0aGUNCiAgPj4+IGRlZmF1bHQNCiAgPj4+IHRoYXQgYWxsIGltcGxlbWVu dGF0aW9ucyBNVVNUIHN1cHBvcnQsIHNvIHRoYXQgd2UgY2FuIGhhdmUNCiAgPj4+DQogID4+PiBp bnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4NCiAgPj4+IElNTyB0aGlzIHNob3VsZCBiZSB0 aGUgYmluYXJ5IGZvcm1hdCB3aGljaCBpcw0KICA+Pj4gdGhlIG1vc3QgY29tcGFjdCBhbmQNCiAg Pj4+IHdpbGwgd29yayBmb3IgbW9zdCBvZiB0aGUgY2FzZXMgYW55d2F5LiBJIGRvIG5vdCBjYXJl DQogID4+PiB0b28gbXVjaCBpZiB0aGlzDQogID4+PiBpcyBkZWZpbmVkIGluIHRoZSBzYW1lIG9y IG9uIGEgc2VwYXJhdGUgKGFsYmVpdCB0aWdodGx5DQogID4+PiBjb3VwbGVkKQ0KICA+Pj4gZHJh ZnRzLg0KICA+Pj4NCiAgPj4+IEl0IGlzIGFsc28gb2sgd2l0aCBtZSB0byBoYXZlIG90aGVyIG9w dGlvbmFsIGZvcm1hdHMNCiAgPj4+IChsaWtlIENvbm55J3MpDQogID4+PiBmb3IgbW9yZSBhZHZh bmNlZCB1c2UgY2FzZXMuDQogID4+Pg0KICA+Pj4gSSBob3BlIHRoaXMgaGVscHMNCiAgPj4+DQog ID4+Pg0KICA+Pj4gR2VvcmdlDQogID4+Pg0KICA+Pj4gIFR1ZSwgQXByIDE0LCAyMDA5IGF0IDU6 MTIgUE0sIG1hcmNlbG8gYmFnbnVsbyBicmF1bg0KICA+Pj4gPG1hcmNlbG9AaXQudWMzbS5lcz4g d3JvdGU6DQogID4+Pg0KICA+Pj4gICAgICAgDQogID4+Pj4gR2VvcmdlIFRzaXJ0c2lzIGVzY3Jp YmnDszoNCiAgPj4+Pg0KICA+Pj4+ICAgICAgICAgDQogID4+Pj4+IEhpDQogID4+Pj4+ICAgICAg ICAgICANCiAgPj4+IENvbm55LA0KICA+Pj4gICAgICAgDQogID4+Pj4+IEdvb2QgdG8gc2VlIHlv dSBhcmUgcmVzdXJyZWN0aW5nIHRoaXMgZHJhZnQuIEkgdGhpbmsgd2UgbmVlZA0KICA+Pj4+PiAg ICAgICAgICAgDQogID4+PiB0aGlzIGFzDQogID4+PiAgICAgICANCiAgPj4+Pj4gb25lIG9mIHRo ZSBhbHRlcm5hdGl2ZXMuIFdlIGFsc28gbmVlZCBhIGJpbmFyeSB2ZXJzaW9uIHdoaWNoIEkNCiAg Pj4+Pj4gICAgICAgICAgIA0KICA+Pj4gd2lsbCBiZQ0KICA+Pj4gICAgICAgDQogID4+Pj4+IHdv cmtpbmcgb24gd2l0aCBvdGhlcnMgYWZ0ZXIgSSBhbSBkb25lIHVwZGF0aW5nIHRoZSBGbG93DQog ID4+Pj4+ICAgICAgICAgICANCiAgPj4+IEJpbmRpbmdzDQogID4+PiAgICAgICANCiAgPj4+Pj4g ZHJhZnQuDQogID4+Pj4+DQogID4+Pj4+DQogID4+Pj4+ICAgICAgICAgICANCiAgPj4+PiBjb3Vs ZCB5b3UgZXhwYW5kIG9uIHRoaXM/DQogID4+Pj4gSSBtZWFuLCBhcmUNCiAgPj4+PiAgICAgICAg IA0KICA+Pj4geW91IHNheWluZyB0aGF0IHdlIG5lZWQgdHdvIHdheXMgb2YgZGVzY3JpYmluZyBm bG93cz8NCiAgPj4+ICAgICAgIA0KICA+Pj4+IFJlZ2FyZHMsDQogID4+Pj4gICAgICAgICANCiAg Pj4+IG1hcmNlbG8NCiAgPj4+ICAgICAgIA0KICA+Pj4+ICAgICAgICAgDQogID4+Pj4+IFRoYW5r cw0KICA+Pj4+PiBHZW9yZ2UNCiAgPj4+Pj4NCiAgPj4+Pj4gT24gVHVlLCBBcHIgMTQsIDIwMDkg YXQgNDozNQ0KICA+Pj4+PiAgICAgICAgICAgDQogID4+PiBQTSwgQ29ubnkgTGFyc3Nvbg0KICA+ Pj4gICAgICAgDQogID4+Pj4+IDxjb25ueS5sYXJzc29uQGVyaWNzc29uLmNvbT4gd3JvdGU6DQog ID4+Pj4+DQogID4+Pj4+DQogID4+Pj4+ICAgICAgICAgICANCiAgPj4+IEhpLA0KICA+Pj4gICAg ICAgDQogID4+Pj4+PiBUaGlzIGlzIGEgcmVxdWVzdCB0byB0aGUgTUVYVCB3b3JraW5nIGdyb3Vw IHRvIGFkb3B0DQogID4+Pj4+Pg0KICA+Pj4+Pj4gICAgICAgICAgICAgDQogID4+PiBkcmFmdC1s YXJzc29uLW1leHQtZmxvdy1kaXN0cmlidXRpb24tcnVsZXMgdG8gY292ZXIgdGhlIGNoYXJ0ZXIN CiAgPj4+IGl0ZW06DQogID4+PiAgICAgICANCiAgPj4+Pj4+IChBLjMpIFVzZSBvZiBtdWx0aXBs ZSBpbnRlcmZhY2VzLg0KICA+Pj4+Pj4gLi4uDQogID4+Pj4+PiBEZWxpdmVyYWJsZXMNCiAgPj4+ Pj4+ICAgICAgICAgICAgIA0KICA+Pj4gcmVsYXRlZCB0byB0aGlzIGluY2x1ZGUNCiAgPj4+ICAg ICAgIA0KICA+Pj4+Pj4gLSBBICJGbG93L2JpbmRpbmcgcG9saWNpZXMgZXhjaGFuZ2UiIHNvbHV0 aW9uIGZvcg0KICA+Pj4+Pj4gICAgICAgICAgICAgDQogID4+PiBhbiBleGNoYW5nZSBvZg0KICA+ Pj4gICAgICAgDQogID4+Pj4+PiBwb2xpY2llcyBmcm9tIHRoZSBtb2JpbGUgaG9zdC9yb3V0ZXIg dG8gdGhlIEhvbWUgQWdlbnQgYW5kDQogID4+Pj4+PiAgICAgICAgICAgICANCiAgPj4+IGZyb20g dGhlDQogID4+PiAgICAgICANCiAgPj4+Pj4+IEhvbWUgQWdlbnQgdG8gdGhlIG1vYmlsZSBob3N0 L3JvdXRlciBpbmZsdWVuY2luZyB0aGUgY2hvaWNlIG9mDQogID4+Pj4+PiAgICAgICAgICAgICAN CiAgPj4+IHRoZQ0KICA+Pj4gICAgICAgDQogID4+Pj4+PiBDYXJlLW9mIEFkZHJlc3MgYW5kIEhv bWUgQWdlbnQgYWRkcmVzcy4gVGhlIHNvbHV0aW9uIGludm9sdmVzDQogID4+Pj4+PiAgICAgICAg ICAgICANCiAgPj4+IHR3bw0KICA+Pj4gICAgICAgDQogID4+Pj4+PiBzcGVjaWZpY2F0aW9ucywg b25lIGZvciB0aGUgcG9saWN5IGZvcm1hdCBhbmQgYW5vdGhlciBmb3IgaXRzDQogID4+Pj4+Pg0K ICA+Pj4+Pj4gICAgICAgICAgICAgDQogID4+PiB0cmFuc3BvcnQgW2JvdGggU3RhbmRhcmQgVHJh Y2tdLg0KICA+Pj4gICAgICAgDQogID4+Pj4+PiBUaGUgc3RhdHVzIG9mIHRoZSB3b3JraW5nDQog ID4+Pj4+PiAgICAgICAgICAgICANCiAgPj4+IGdyb3VwIGlzIHRoYXQgd2UgaGF2ZSBhIGRyYWZ0 DQogID4+PiAgICAgICANCiAgPj4+IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW1vbmFtaTYtbXVsdGlwbGVjb2EtMTIpIGZvcg0KICA+Pj4gICAgICAgDQogID4+PiByZWdp c3RyYXRpb24gb2YgbXVsdGlwbGUgY2FyZS1vZiBhZGRyZXNzZXMgdG8gb25lIGhvbWUgYWRkcmVz cy4NCiAgPj4+ICAgICAgIA0KICA+Pj4+Pj4gVGhlcmUNCiAgPj4+Pj4+ICAgICAgICAgICAgIA0K ICA+Pj4gZXhpc3Qgb25lIGRyYWZ0DQogID4+PiAgICAgICANCiAgPj4+IChodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1leHQtZmxvdy1iaW5kaW5nLTAxKSBmb3INCiAgPj4+ ICAgICAgIA0KICA+Pj4gdHJhbnNwb3J0DQogID4+PiAgICAgICANCiAgPj4+Pj4+IG9mIHRoZSBy dWxlcyB0aGF0IGRlY2lkZXMgaG93IGVhY2ggZmxvdyBpcyBzZW50IG92ZXIgdGhlDQogID4+Pj4+ PiAgICAgICAgICAgICANCiAgPj4+IGF2YWlsYWJsZQ0KICA+Pj4gICAgICAgDQogID4+Pj4+PiBu ZXR3b3JrDQogID4+Pj4+PiBpbnRlcmZhY2VzLg0KICA+Pj4+Pj4NCiAgPj4+Pj4+IFdoYXQgaXMg Y3VycmVudGx5IG1pc3NpbmcgaXMNCiAgPj4+Pj4+ICAgICAgICAgICAgIA0KICA+Pj4gdGhlIHBh cnQgdGhhdCBkZWZpbmVzIHRoZSBydWxlcy4NCiAgPj4+ICAgICAgIA0KICA+Pj4gZHJhZnQtbGFy c3Nvbi1tZXh0LWZsb3ctZGlzdHJpYnV0aW9uLXJ1bGVzIGRlZmluZXMgYSBydWxlIGxhbmd1YWdl IHRoYXQNCiAgPj4+ICAgICAgIA0KICA+Pj4gY2FuDQogID4+PiAgICAgICANCiAgPj4+Pj4+IGJl IHVzZWQgZm9yIHRoaXMuIFRoZSBkb2N1bWVudCBjYW4gYmUgZm91bmQgYXQ6DQogID4+Pj4+Pg0K ICA+Pj4+Pj4NCiAgPj4+Pj4+ICAgICAgICAgICAgIA0KICA+Pj4gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbGFyc3Nvbi1tZXh0LWZsb3ctZGlzdHJpYnV0aW9uLXJ1bGVzLTAyDQog ID4+PiAgICAgICANCiAgPj4+Pj4+PiBQbGVhc2UgZXhwcmVzcyB5b3VyIG9waW5pb24gb24gd2hl dGhlciB0aGlzIHNob3VsZCBiZWNvbWUgYSBXRw0KICA+Pj4+Pj4+ICAgICAgICAgICAgICAgDQog ID4+PiBkb2N1bWVudC4NCiAgPj4+ICAgICAgIA0KICA+Pj4+Pj4gUmVnYXJkcw0KICA+Pj4+Pj4g Q29ubnkNCiAgPj4+Pj4+DQogID4+Pj4+Pg0KICA+Pj4+Pj4gICAgICAgICAgICAgDQogID4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICA+Pj4gICAg ICAgDQogID4+Pj4+PiBNRVhUIG1haWxpbmcgbGlzdA0KICA+Pj4+Pj4NCiAgPj4+Pj4+ICAgICAg ICAgICAgIA0KICA+Pj4gTUVYVEBpZXRmLm9yZw0KICA+Pj4gICAgICAgDQogID4+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQNCiAgPj4+Pj4+DQogID4+Pj4+ Pg0KICA+Pj4+Pj4NCiAgPj4+Pj4+ICAgICAgICAgICAgIA0KICA+Pj4NCiAgPj4+ICAgICAgIA0K ICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICA+ PiBNRVhUIG1haWxpbmcNCiAgPj4gICAgIA0KICA+Pj4gbGlzdA0KICA+Pj4gICAgICAgDQogID4+ IE1FWFRAaWV0Zi5vcmcNCiAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tZXh0DQogID4+DQogID4+DQogID4+DQogID4+DQogID4+ICAgICANCiAgPg0KICA+ICAgDQoN CiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgTUVY VCBtYWlsaW5nIGxpc3QNCiAgTUVYVEBpZXRmLm9yZw0KICBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21leHQNCg== --Boundary_(ID_cj42c7adv3uxHg4+l6yoqg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPkhp LDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZM+Jmd0OyBhcyBwZW9wbGUgbWF5IGhhdmUg bm90aWNlZCwgd2UgZG8gaGF2ZSBhIHByb2JsZW0gZmluZGluZyANCnJldmlld3MgZm9yIDxCUj4m Z3Q7IHNvbWUgZG9jdW1lbnRzIChvdGhlciBkb2N1bWVudHMgb3RvaCwgZ2V0IHBsZW50eSBvZiAN CnJldmlld3MpPEJSPiZndDsgU28sIGkgYW0gY29uY2VybmVkIHRvIGRpc2lwYXRlIGVuZXJneSB0 aHJvdWdoIG11bHRpcGxlIA0KZG9jdW1lbnRzLCBhbmQgaSA8QlI+Jmd0OyBwcmVmZmVyIHRvIGNv bmNlbnRyYXRlIHRoZSBlbnJnZXkgaW4gYSBzaW5nbGUgDQpwcm9wb3NhbDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPj09PT09Jmd0OyBJIGNhbWUgdG8gSUVURiByZWNlbnRs eSBhbmQgSSB2b2x1bnRlZXIgDQp0byZuYnNwO3dvcmtzIGluIFdvcmsgR3JvdXAuPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEkgd2lsbCB0cnkgdG8gZG8gDQp0aGUgam9iIGJldHRlci4gOik8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj5yZWdhcmRzPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+WGlhbmdzb25nPC9GT05UPjwvRElWPg0KPERJVj4NCjxQ PjwvUD4NCjxQPjwvUD48Rk9OVCBmYWNlPeWNjuaWh+e7hum7kSBjb2xvcj1ibGFjayBzaXplPTI+ PC9GT05UPjxGT05UIGZhY2U95Y2O5paH57uG6buRIGNvbG9yPWdyYXkgDQpzaXplPTI+5Y2O5Li6 5oqA5pyv5pyJ6ZmQ5YWs5Y+4IDwvRk9OVD48SU1HIGlkPXJpZEltZyBhbHQ9aHVhd2VpX2xvZ28g aHNwYWNlPTAgDQpzcmM9ImNpZDowYjM1MDFjOWJkYWQkMDcxYWFiNzAkNDAxMDZmMGFAY2hpbmEu aHVhd2VpLmNvbSIgYWxpZ249bGVmdD4gDQo8UD48L1A+PEJSPjxGT05UIGZhY2U95Y2O5paH57uG 6buRIGNvbG9yPWdyYXkgc2l6ZT0xPuWcsOWdgO+8mua3seWcs+W4gum+meWyl+WMuuWdgueUsOWN juS4uuWfuuWcsCDpgq7nvJbvvJo1MTgxMjk8QlI+PEEgDQpocmVmPSJodHRwOi8vd3d3Lmh1YXdl aS5jb20iPmh0dHA6Ly93d3cuaHVhd2VpLmNvbTwvQT48QlI+PC9GT05UPjxGT05UIGZhY2U95Y2O 5paH57uG6buRIA0KY29sb3I9Z3JheSANCnNpemU9MT4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPuac rOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7 hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4reWIl+WHuueahOS4quS6uuaIlue+pOe7hOOA guemgTxCUj7mraLku7vkvZXlhbbku5bkurrku6Xku7vkvZXlvaLlvI/kvb/nlKjvvIjljIXmi6zk vYbkuI3pmZDkuo7lhajpg6jmiJbpg6jliIblnLDms4TpnLLjgIHlpI3liLbjgIHmiJbmlaPlj5Hv vInmnKzpgq7ku7bkuK08QlI+55qE5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu2 77yM6K+35oKo56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys 6YKu5Lu277yBPEJSPjwvRk9OVD48Rk9OVCANCmZhY2U9QXJpYWwgY29sb3I9Z3JheSBzaXplPTE+ VGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIA0KY29uZmlkZW50aWFsIGlu Zm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCA8QlI+aXMgaW50ZW5kZWQgb25seSBmb3IgdGhl IHBlcnNvbiANCm9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVz ZSBvZiB0aGUgPEJSPmluZm9ybWF0aW9uIA0KY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChp bmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCANCjxCUj5kaXNj bG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIg dGhhbiB0aGUgDQppbnRlbmRlZCA8QlI+cmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlv dSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCANCnBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBieSA8QlI+cGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSANCml0ITxCUj48 L0ZPTlQ+PC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBB RERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAy cHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWu i+S9kyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBzdHlsZT0i QkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0IOWui+S9kzsgZm9udC1jb2xvcjogYmxhY2si PjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9bWFyY2Vsb0BpdC51YzNtLmVzIGhyZWY9Im1haWx0 bzptYXJjZWxvQGl0LnVjM20uZXMiPm1hcmNlbG8gYmFnbnVsbyANCiAgYnJhdW48L0E+IDwvRElW Pg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPXRz aXJ0c2lzQGdvb2dsZW1haWwuY29tIA0KICBocmVmPSJtYWlsdG86dHNpcnRzaXNAZ29vZ2xlbWFp bC5jb20iPkdlb3JnZSBUc2lydHNpczwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlw dCDlrovkvZMiPjxCPkNjOjwvQj4gPEEgdGl0bGU9bWV4dEBpZXRmLm9yZyANCiAgaHJlZj0ibWFp bHRvOm1leHRAaWV0Zi5vcmciPm1leHQ8L0E+IDsgPEEgDQogIHRpdGxlPWp1bGllbi5sYWdhbmll ci5JRVRGQGdvb2dsZW1haWwuY29tIA0KICBocmVmPSJtYWlsdG86anVsaWVuLmxhZ2FuaWVyLklF VEZAZ29vZ2xlbWFpbC5jb20iPmp1bGllbi5sYWdhbmllci5JRVRGQGdvb2dsZW1haWwuY29tPC9B PiANCiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlNlbnQ6PC9C PiBXZWRuZXNkYXksIEFwcmlsIDE1LCAyMDA5IDU6MDUgUE08L0RJVj4NCiAgPERJViBzdHlsZT0i Rk9OVDogOXB0IOWui+S9kyI+PEI+U3ViamVjdDo8L0I+IFJlOiBbTUVYVF0gQ2FsbCBmb3IgYWRv cHRhdGlvbiANCiAgb2ZkcmFmdC1sYXJzc29uLW1leHQtZmxvdy1kaXN0cmlidXRpb24tcnVsZXM8 L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+R2VvcmdlIFRzaXJ0c2lzIGVzY3JpYmnDszo8QlI+Jmd0 OyBIaSBIZXNoYW0sPEJSPiZndDs8QlI+Jmd0OyBJIA0KICB0aGluayBpbiBmYWN0IHRoZSBiaW5h cnkgbWVjaGFuaXNtIGNhbiBlYXNpbHkgYmUgbXVjaCBtb3JlIGZsZXhpYmxlPEJSPiZndDsgaWYg DQogIHdlIHdhbnQgdG8uPEJSPiZndDs8QlI+Jmd0OyBBbGwgd2UgaGF2ZSB0byBkbyBpdCB0byBh bGxvdyBmb3IgbWF0Y2hpbmcgdG8gYW4gDQogICJPZmZzZXQiICsgIk51bWJlciBvZjxCUj4mZ3Q7 IGJ5dGVzIi4gVGhlIE9mZnNldCB3b3VsZCBiZSBhIHBvaW50ZXIgdG8gWCANCiAgbnVtYmVyIG9m IGJ5dGVzIGZyb20gdGhlPEJSPiZndDsgYmVnaW5uaW5nIG9mIHRoZSBJUCBoZWFkZXIsIGFuZCB0 aGVuIHRoZSANCiAgTnVtYmVyIG9mIEJ5dGVzLCB3b3VsZCBiZSB0aGU8QlI+Jmd0OyBmaWVsZCB0 aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIA0KICBtYXRjaC48QlI+Jmd0OyBUaGlzIGhhcyBiZWVuIHVz ZWQgYnkgY2xhc3NpZmllcnMgZm9yIGxvbmcgdGltZSBub3cgKGUuZy4sIA0KICBMaW51eCwgbG9v azxCUj4mZ3Q7IGZvciBVMzIgU2VsZWN0b3IpLjxCUj4mZ3Q7PEJSPiZndDsgSW4gdGhhdCBjYXNl LCB0aGUgZml4ZWQgDQogIGJpbmFyeSBmb3JtYXQgY2FuIGNvdmVyIG1vc3Qgb2YgdGhlIGNhc2Vz IGFuZDxCUj4mZ3Q7IGFsc28gcHJvdmlkZSBhIG1lY2hhbmlzbSANCiAgZm9yIG1hdGNoaW5nIGFu eXRoaW5nIGVsc2UgaW4gdGhlIHBhY2tldCw8QlI+Jmd0OyB3aGljaCBtYWtlcyB0aGlzIHJlYWxs eSANCiAgcG93ZXJmdWwuPEJSPiZndDs8QlI+Jmd0OyBIYXZpbmcgc2FpZCB0aGF0LCB3aGlsZSBJ IGFncmVlIHdpdGggTWFyY2VsbyB0aGF0IHdlIA0KICBzaG91bGQgb25seTxCUj4mZ3Q7IGRlZmlu ZSB3aGF0IHdlIG5lZWQsIHRoZXJlIGlzIGxpdHRsZSBoYXJtIGluIGRlZmluaW5nIA0KICBhZGRp dGlvbmFsPEJSPiZndDsgb3B0aW9uYWwgRmxvdyBEZXNjcmlwdGlvbiBmb3JtYXRzLDxCUj48QlI+ aGVyZSBpcyANCiAgZGlzYWdyZWU8QlI+PEJSPnRoZXJlIGlzIGhhcm0gYW5kIGl0IGlzIGluIHRl cm0gb2YgZW5lcmd5IG9mIHRoZSBXRyBhbmQgaW4gDQogIHRlcm0gb2YgdGhlIDxCUj5lZmZlY3Rp dmVuZXNzIG9mIGEgc3RhbmRhcmQuPEJSPjxCUj5hcyBwZW9wbGUgbWF5IGhhdmUgDQogIG5vdGlj ZWQsIHdlIGRvIGhhdmUgYSBwcm9ibGVtIGZpbmRpbmcgcmV2aWV3cyBmb3IgPEJSPnNvbWUgZG9j dW1lbnRzIChvdGhlciANCiAgZG9jdW1lbnRzIG90b2gsIGdldCBwbGVudHkgb2YgcmV2aWV3cyk8 QlI+U28sIGkgYW0gY29uY2VybmVkIHRvIGRpc2lwYXRlIA0KICBlbmVyZ3kgdGhyb3VnaCBtdWx0 aXBsZSBkb2N1bWVudHMsIGFuZCBpIDxCUj5wcmVmZmVyIHRvIGNvbmNlbnRyYXRlIHRoZSBlbnJn ZXkgDQogIGluIGEgc2luZ2xlIHByb3Bvc2FsPEJSPjxCUj50aGUgb3RoZXIgaGFybSBpcyB0aGF0 IGhhdmluZyB0d28gc3RhbmRhcmRzIGZvciANCiAgdGhlIHNhbWUgZnVuY3Rpb24gaXMgPEJSPmNs ZWFybHkgbGVzcyBvcHRpbWFsIHRoYW4gaGF2aW5nIG9ubHkgb25lLCBpIGd1ZXNzIA0KICBwZW9w bGUgd2lsbCBub3QgYXJndWUgPEJSPmFnYWluc3QgdGhhdDxCUj48QlI+KGkgZG8gdW5kZXJzdGFu ZCB0aGF0IHRoZSBwYXRoIA0KICBvZiBsZXNzIHJlc2lzdGFuY2UgaXMgdG8gZ2V0IGFsbCB0aGUg PEJSPnNvbHV0aW9ucyBhcHByb3ZlZCBhbmQgcHVibGlzaGVkLCBidXQgDQogIGlmIHdlIGRvIHRo YXQsIHN0YW5kYXJkcyBhcmUgPEJSPm1lYW5pbmdsZXNzLCBzbyBpIGd1ZXNzIGl0IGlzIHRoZSBj aGFpcnMgcm9sZSANCiAgdG8gbWFrZSB0aGF0IHJlc2lzdGFuY2UpPEJSPjxCUj5TbywgbXkgdGFr ZSBpbiB0aGUgZ2VuZXJhbCBjYXNlLCBpcyB0aGF0IGJ5IA0KICBkZWZhdWx0IHdlIG1ha2Ugb25s eSBvbmUgPEJSPnN0YW5kYXJkIGZvciBhIGdpdmVuIGZ1bmN0aW9uPEJSPjxCUj5XaGljaCBvbmUs IA0KICBpdCBpcyB1cCB0byB0aGUgV0cgdG8gZGVjaWRlPEJSPjxCUj5yZWdhcmRzLCBtYXJjZWxv PEJSPjxCUj4mZ3Q7Jm5ic3A7IGFzIGxvbmcgDQogIGFzIGl0IGlzIGNsZWFyIHdoYXQgaXM8QlI+ Jmd0OyBhY3R1YWxseSByZXF1aXJlZCBmb3IgaW50ZXJvcCB2cyB3aGF0IGlzIA0KICBvcHRpb25h bC48QlI+Jmd0OzxCUj4mZ3Q7IFRob3VnaHRzPzxCUj4mZ3Q7IEdlb3JnZTxCUj4mZ3Q7PEJSPiZn dDsgT24gV2VkLCBBcHIgDQogIDE1LCAyMDA5IGF0IDE6MjQgQU0sIEhlc2hhbSBTb2xpbWFuPEJS PiZndDsgJmx0OzxBIA0KICBocmVmPSJtYWlsdG86aGVzaGFtQGVsZXZhdGVtb2JpbGUuY29tIj5o ZXNoYW1AZWxldmF0ZW1vYmlsZS5jb208L0E+Jmd0OyANCiAgd3JvdGU6PEJSPiZndDsmbmJzcDsm bmJzcDsgPEJSPiZndDsmZ3Q7IFRoZSBiaW5hcnkgZGVzY3JpcHRpb24gdGhhdCBHZW9yZ2UgDQog IHJlZmVycmVkIHRvIGNvdmVyZWQgdGhlIG1ham9yaXR5IG9mIHVzZTxCUj4mZ3Q7Jmd0OyBjYXNl cyBidXQgaXQgZG9lc24ndCANCiAgY292ZXIsIGZvciBpbnN0YW5jZSwgYSBmaWx0ZXIgb24gdGhl IDc1dGggYnl0ZSBpbiB0aGU8QlI+Jmd0OyZndDsgcGFja2V0LiANCiAgRHJhZnQtbGFyc3NvbiBj b3ZlcnMgdGhvc2UgY2FzZXMgYW5kIGlzIG1vcmUgZ2VuZXJpYy48QlI+Jmd0OyZndDsgVGhlIHBy b2JsZW0gDQogIHdpdGggZG9pbmcgdGhpbmdzIHNlcXVlbnRpYWxseSBpcyB0aGF0IHRoZXJlIGFy ZSBkaWZmZXJlbnQgdHlwZXM8QlI+Jmd0OyZndDsgDQogIG9mIHVzZSBjYXNlcyB0aGF0IGNhbiBv Y2N1ciBmcm9tIGRheSAxIHNpbXVsdGFuZW91c2x5LiBVc2Ugc2NlbmFyaW9zIGFyZSANCiAgbm90 PEJSPiZndDsmZ3Q7IGdvaW5nIHRvIGdvIGZyb20gYmFzaWMgdG8gYWR2YW5jZWQgb3ZlciB0aW1l LCB0aGV5IGNhbiBzdGFydCANCiAgd2l0aCBhZHZhbmNlZDxCUj4mZ3Q7Jmd0OyBmcm9tIGRheSAx IHNvbWV0aW1lcy48QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgU28sIA0KICB0aGUgc2FmZXN0IG9w dGlvbiBpcyB0byBnbyB3aXRoIGRyYWZ0LWxhcnNzb24uIEJ1dCwgdGhlIGNvdW50ZXIgDQogIG9w aW5pb248QlI+Jmd0OyZndDsgaGVyZSBpcyB0aGF0IEknbGwgYmUgdmVyeSBzdXJwcmlzZWQgaWYg b3JnYW5pc2F0aW9ucyBsaWtlIA0KICAzR1BQIHdobyBhbHJlYWR5PEJSPiZndDsmZ3Q7IGhhdmUg YmluYXJ5IGZpbHRlcnMgKGFuZCBsb3ZlIGJpbmFyeSBlbmNvZGluZykgDQogIHdvdWxkIHdhbnQg dGV4dCBlbmNvZGluZzxCUj4mZ3Q7Jmd0OyBiZWNhdXNlIHRoZXkgd2lsbCBsaWtlbHkgZmVlbCB0 aGF0IGl0J3MgDQogIHdhc3RlZnVsLjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyBJdCBzZWVtcyBs aWtlIGJvdGggYXJlIG5lZWRlZCBidXQgaWYgeW91IA0KICBoYXZlIHRvIG1ha2Ugc29tZXRoaW5n IHdhaXQsIEknZDxCUj4mZ3Q7Jmd0OyBtYWtlIHRoZSBiaW5hcnkgc3R1ZmYgd2FpdCB0aWxsIA0K ICBzb21lb25lIGFza3MgZm9yIGl0LiBJdCB3YXMgaW4gb2xkZXI8QlI+Jmd0OyZndDsgdmVyc2lv bnMgb2YgdGhlIGRyYWZ0IGFuZCBpdCANCiAgd291bGQgYmUgdmVyeSBzaW1wbGUgb2YgdXMgdG8g dGFrZSB0aGF0IG91dCBhbmQ8QlI+Jmd0OyZndDsgcHV0IGl0IGluIGEgDQogIHNlcGFyYXRlIGRy YWZ0LjxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyANCiAgSGVzaGFtPEJSPiZndDsmZ3Q7PEJSPiZn dDsmZ3Q7PEJSPiZndDsmZ3Q7IE9uIDE1LzA0LzA5IDM6MzUgQU0sICJtYXJjZWxvIA0KICBiYWdu dWxvIGJyYXVuIiAmbHQ7PEEgDQogIGhyZWY9Im1haWx0bzptYXJjZWxvQGl0LnVjM20uZXMiPm1h cmNlbG9AaXQudWMzbS5lczwvQT4mZ3Q7IA0KICB3cm90ZTo8QlI+Jmd0OyZndDs8QlI+Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZndDsmZ3Q7Jmd0OyBpIA0KICB3b25kZXIg aWYgd2UgbmVlZCB0aGUgYWR2YW5jZWQgZmVhdHVyZXMgYXQgdGhpcyANCiAgcG9pbnQ8QlI+Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxCUj4mZ3Q7Jmd0 OyBJIG1lYW4sIA0KICB3ZSBhcmUganVzdDxCUj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8QlI+Jmd0OyZndDsmZ3Q7IGRlZmluaW5nIA0KICB0aGlzLCB3b3VsZG4ndCBtYWtlIHNl bnNlIHRvIHdhaXQgYW5kIA0KICBzZWU8QlI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxCUj4mZ3Q7Jmd0OyBpZiB3aXRoIA0KICB0aGUgYmFzaWM8QlI+ Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZndDsmZ3Q7Jmd0OyBwcm9jZWR1 cmUgaXMgDQogIGVub3VnaCBhbmQgZG8gdGhlIGV4dG5lc2lvbnMgbGF0ZXI/IE9yIA0KICBpczxC Uj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZn dDsmZ3Q7IHRoZSBiYXNpYyANCiAgbWVjaGFuaXNtIHNvPEJSPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxCUj4mZ3Q7Jmd0OyZndDsgbGltaXRlZCB0aGF0IA0KICBpcyBub3QgZW5v dWdoIHRvIGhhbmRsZSBzaW1wbGUgDQogIGJhc2ljPEJSPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8QlI+Jmd0OyZndDsgDQogIHNjZW5hcmlvcz8gSWYg dGhhdCBpcyB0aGU8QlI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZndDsm Z3Q7Jmd0OyANCiAgY2FzZSwgZG9lcyBpdCBtYWtlcyBzZW5zZSB0byBldmVuIGRlZmluZSANCiAg aXQ/PEJSPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 QlI+Jmd0OyZndDsgQm90dG9tIA0KICBsaW5lLCB3ZSBuZWVkIHN0cm9uZzxCUj4mZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8QlI+Jmd0OyZndDsmZ3Q7IA0KICByZWFzb25zIHRvIGRv IHRoaW5ncyBpbiBtdWx0aXBsZSANCiAgZGlmZmVyZW50PEJSPiZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8QlI+Jmd0OyZndDsgDQogIHdheXMuIFVubGVz cyBjbGVhciByZWFzb25zIGFyZTxCUj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgPEJSPiZndDsmZ3Q7Jmd0OyBkZXNjcmliZWQsIGkgZmFpbCB0byBzZWUgd2h5IHdlIA0KICBz aG91bGQ8QlI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxCUj4mZ3Q7Jmd0OyANCiAgc3RhbmRhcmRpemUgbXVsdGlwbGU8QlI+Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZndDsmZ3Q7Jmd0OyANCiAgYXBwcm9hY2hlczxCUj4mZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZndDsmZ3Q7 IA0KICBSZWdhcmRzLCBtYXJjZWxvPEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7PEJSPiZndDsmZ3Q7 PEJSPiZndDsmZ3Q7IEdlb3JnZSANCiAgVHNpcnRzaXMgZXNjcmliacOzOjxCUj4mZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8QlI+Jmd0OyZndDsmZ3Q7IEhpIA0KICBNYXJjZWxvLDxC Uj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0OyZndDsmZ3Q7IEluPEJSPiZndDsmZ3Q7Jmd0OyB0aGUgTW9u YW1pNiBkYXlzLCANCiAgdGhlIEZsb3cgQmluZGluZ3MgZHJhZnQgdXNlZCB0byBpbmNsdWRlIGEg YmluYXJ5PEJSPiZndDsmZ3Q7Jmd0OyANCiAgRmxvdzxCUj4mZ3Q7Jmd0OyZndDsgRGVzY3JpcHRv ciBhcyBwYXJ0IG9mIHRoZSBGSUQgb3B0aW9uLjxCUj4mZ3Q7Jmd0OyZndDsgDQogIFRoaXMgd2Fz IGJhc2ljYWxseSBhIHR5cGljYWwgZml4ZWQ8QlI+Jmd0OyZndDsmZ3Q7IGxlbmd0aCBiaW5hcnkg Zm9ybWF0IA0KICBkZWZpbmluZyBhPEJSPiZndDsmZ3Q7Jmd0OyBjbGFzc2lmaWVyIGZpbHRlcm0g aW5jbHVkaW5nIHNvdXJjZSANCiAgYW5kPEJSPiZndDsmZ3Q7Jmd0OyBkZXN0aW5hdGlvbiBhZGRy ZXNzZXMsPEJSPiZndDsmZ3Q7Jmd0OyBwcm90b2NvbCBudW1iZXIsIA0KICBwb3J0IG51bWJlcnMs IEZsb3cgSUQsIGFuZCBJUFNFQzxCUj4mZ3Q7Jmd0OyZndDsgU1BJLCBpZiBJIGRvIA0KICBub3Q8 QlI+Jmd0OyZndDsmZ3Q7IGZvcmdldCBzb21ldGhpbmc7IGJvdGggSVB2NCBhbmQgSVB2NiBjYW4g YmUgc3VwcG9ydGVkIA0KICB3aXRoPEJSPiZndDsmZ3Q7Jmd0OyB0aGlzLjxCUj4mZ3Q7Jmd0OyZn dDs8QlI+Jmd0OyZndDsmZ3Q7IFNvbWUgcGVvcGxlLCANCiAgaG93ZXZlciwgdGhvdWdodCB0aGF0 IG1vcmUgZmxleGlibGUgRkRzIHNob3VsZCBiZTxCUj4mZ3Q7Jmd0OyZndDsgDQogIGFsbG93ZWQ8 QlI+Jmd0OyZndDsmZ3Q7IGFuZCBDb25ueSdzIGRyYWZ0IGRlc2NyaWJlcyBhIHRleHQgYmFzZWQg Zm9ybWF0IHdoaWNoIA0KICBpcyBjbGVhcmx5PEJSPiZndDsmZ3Q7Jmd0OyBtb3JlPEJSPiZndDsm Z3Q7Jmd0OyBmbGV4aWJsZSBidXQgYWxzbyBtb3JlIA0KICB2ZXJib3NlLjxCUj4mZ3Q7Jmd0OyZn dDs8QlI+Jmd0OyZndDsmZ3Q7IEF0IHRoZSB0aW1lLCB0aGUgV0cgZGVjaWRlZCANCiAgdGhhdDxC Uj4mZ3Q7Jmd0OyZndDsgdGhlIEZEIGZvcm1hdCBzaG91bGQgYmUgdGFrZW4gb3V0IG9mPEJSPiZn dDsmZ3Q7Jmd0OyB0aGUgDQogIEZsb3cgQmluZGluZ3MgZHJhZnQuIEkgYW0gbm90IHN1cmU8QlI+ Jmd0OyZndDsmZ3Q7IEkgbGlrZSB0aGF0IGJ1dCB0aGlzIGlzIA0KICBpbmRlZWQ8QlI+Jmd0OyZn dDsmZ3Q7IHdoYXQgaGFwcGVuZWQuPEJSPiZndDsmZ3Q7Jmd0OyBTbywgbm93IHRoZSBGbG93IA0K ICBCaW5kaW5nczxCUj4mZ3Q7Jmd0OyZndDsgZHJhZnQgYWxsb3dzIGZvciBkaWZmZXJlbnQgRkQg Zm9ybWF0cywgDQogIGJ1dDxCUj4mZ3Q7Jmd0OyZndDsgaXQgZG9lcyBub3QgZGVmaW5lIGFueSBv ZjxCUj4mZ3Q7Jmd0OyZndDsgDQogIHRoZW0uPEJSPiZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZn dDsgQXMgYSBtaW5pbXVtLCBJTU8gdGhlIHByb3RvY29sIHNob3VsZCANCiAgZGVmaW5lIG9uZSBm b3JtYXQgYXMgdGhlPEJSPiZndDsmZ3Q7Jmd0OyBkZWZhdWx0PEJSPiZndDsmZ3Q7Jmd0OyB0aGF0 IGFsbCANCiAgaW1wbGVtZW50YXRpb25zIE1VU1Qgc3VwcG9ydCwgc28gdGhhdCB3ZSBjYW4gDQog IGhhdmU8QlI+Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OyBpbnRlcm9wZXJhYmxlIA0KICBp bXBsZW1lbnRhdGlvbnMuPEJSPiZndDsmZ3Q7Jmd0OyBJTU8gdGhpcyBzaG91bGQgYmUgdGhlIGJp bmFyeSBmb3JtYXQgd2hpY2ggDQogIGlzPEJSPiZndDsmZ3Q7Jmd0OyB0aGUgbW9zdCBjb21wYWN0 IGFuZDxCUj4mZ3Q7Jmd0OyZndDsgd2lsbCB3b3JrIGZvciBtb3N0IG9mIA0KICB0aGUgY2FzZXMg YW55d2F5LiBJIGRvIG5vdCBjYXJlPEJSPiZndDsmZ3Q7Jmd0OyB0b28gbXVjaCBpZiANCiAgdGhp czxCUj4mZ3Q7Jmd0OyZndDsgaXMgZGVmaW5lZCBpbiB0aGUgc2FtZSBvciBvbiBhIHNlcGFyYXRl IChhbGJlaXQgDQogIHRpZ2h0bHk8QlI+Jmd0OyZndDsmZ3Q7IGNvdXBsZWQpPEJSPiZndDsmZ3Q7 Jmd0OyANCiAgZHJhZnRzLjxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0OyZndDsmZ3Q7IEl0IGlzIGFs c28gb2sgd2l0aCBtZSB0byBoYXZlIG90aGVyIA0KICBvcHRpb25hbCBmb3JtYXRzPEJSPiZndDsm Z3Q7Jmd0OyAobGlrZSBDb25ueSdzKTxCUj4mZ3Q7Jmd0OyZndDsgZm9yIG1vcmUgDQogIGFkdmFu Y2VkIHVzZSBjYXNlcy48QlI+Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OyBJIGhvcGUgdGhp cyANCiAgaGVscHM8QlI+Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZn dDsgDQogIEdlb3JnZTxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0OyZndDsmZ3Q7Jm5ic3A7IFR1ZSwg QXByIDE0LCAyMDA5IGF0IDU6MTIgUE0sIA0KICBtYXJjZWxvIGJhZ251bG8gYnJhdW48QlI+Jmd0 OyZndDsmZ3Q7ICZsdDs8QSANCiAgaHJlZj0ibWFpbHRvOm1hcmNlbG9AaXQudWMzbS5lcyI+bWFy Y2Vsb0BpdC51YzNtLmVzPC9BPiZndDsgDQogIHdyb3RlOjxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0 OyZndDsmZ3Q7Jmd0OyBHZW9yZ2UgVHNpcnRzaXMgDQogIGVzY3JpYmnDszo8QlI+Jmd0OyZndDsm Z3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgDQogIEhpPEJS PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7IENvbm55LDxCUj4m Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDxCUj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBHb29kIHRvIHNlZSB5b3UgYXJlIHJlc3VycmVjdGluZyB0aGlz IGRyYWZ0LiBJIHRoaW5rIA0KICB3ZSANCiAgbmVlZDxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCiAgPEJSPiZndDsmZ3Q7Jmd0OyB0aGlzIGFzPEJSPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9u ZSBvZiB0aGUgYWx0ZXJuYXRpdmVzLiBXZSBhbHNvIG5lZWQgYSBiaW5hcnkgDQogIHZlcnNpb24g d2hpY2ggDQogIEk8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDxCUj4mZ3Q7Jmd0OyZn dDsgd2lsbCBiZTxCUj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQogIDxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3b3JraW5nIG9uIHdpdGggb3RoZXJz IGFmdGVyIEkgYW0gZG9uZSB1cGRhdGluZyB0aGUgDQogIEZsb3c8QlI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQogIDxCUj4mZ3Q7Jmd0OyZndDsgQmluZGluZ3M8QlI+Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgDQogIGRyYWZ0LjxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7Jmd0OyZn dDsgY291bGQgeW91IGV4cGFuZCBvbiB0aGlzPzxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7IEkgbWVhbiwg DQogIGFyZTxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7IHlvdSBzYXlpbmcgdGhhdCB3 ZSBuZWVkIHR3byB3YXlzIG9mIGRlc2NyaWJpbmcgDQogIGZsb3dzPzxCUj4mZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDxCUj4mZ3Q7Jmd0OyZndDsm Z3Q7IA0KICBSZWdhcmRzLDxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7IG1hcmNlbG88 QlI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8 QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rczxCUj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyANCiAgR2VvcmdlPEJSPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PEJSPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE9uIFR1ZSwgQXByIDE0LCAyMDA5IGF0IA0KICA0OjM1PEJSPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7IFBNLCBDb25ueSANCiAgTGFy c3NvbjxCUj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogIDxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PEEgDQogIGhyZWY9Im1haWx0bzpjb25u eS5sYXJzc29uQGVyaWNzc29uLmNvbSI+Y29ubnkubGFyc3NvbkBlcmljc3Nvbi5jb208L0E+Jmd0 OyANCiAgd3JvdGU6PEJSPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PEJSPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7IEhpLDxC Uj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDxC Uj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBpcyBhIHJlcXVlc3QgdG8gdGhlIE1FWFQg d29ya2luZyBncm91cCB0byANCiAgYWRvcHQ8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PEJS PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7 Jmd0OyBkcmFmdC1sYXJzc29uLW1leHQtZmxvdy1kaXN0cmlidXRpb24tcnVsZXMgdG8gY292ZXIg dGhlIA0KICBjaGFydGVyPEJSPiZndDsmZ3Q7Jmd0OyANCiAgaXRlbTo8QlI+Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IChBLjMpIFVzZSBvZiBtdWx0aXBsZSANCiAgaW50ZXJmYWNlcy48QlI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC4uLjxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgDQog IERlbGl2ZXJhYmxlczxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogIDxCUj4mZ3Q7Jmd0OyZndDsgcmVsYXRlZCB0byB0aGlzIA0KICBpbmNsdWRlPEJSPiZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtIEEgIkZsb3cvYmluZGluZyBwb2xpY2llcyBleGNoYW5nZSIg c29sdXRpb24gDQogIGZvcjxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQogIDxCUj4mZ3Q7Jmd0OyZndDsgYW4gZXhjaGFuZ2UgDQogIG9mPEJSPiZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBwb2xpY2llcyBmcm9tIHRoZSBtb2JpbGUgaG9zdC9yb3V0ZXIgdG8gdGhl IEhvbWUgDQogIEFnZW50IA0KICBhbmQ8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7IGZyb20gdGhlPEJSPiZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBIb21lIEFnZW50IHRvIHRoZSBtb2JpbGUgaG9zdC9yb3V0ZXIgaW5mbHVlbmNp bmcgDQogIHRoZSBjaG9pY2UgDQogIG9mPEJSPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7Jmd0OyB0aGU8QlI+Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IENhcmUtb2YgQWRkcmVzcyBhbmQgSG9tZSBBZ2VudCBhZGRyZXNzLiBUaGUgDQogIHNv bHV0aW9uIA0KICBpbnZvbHZlczxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQogIDxCUj4mZ3Q7Jmd0OyZndDsgdHdvPEJSPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBzcGVjaWZpY2F0aW9ucywgb25lIGZvciB0aGUgcG9saWN5IGZvcm1hdCBhbmQgDQogIGFub3Ro ZXIgZm9yIA0KICBpdHM8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7Jmd0OyB0cmFuc3Bv cnQgW2JvdGggU3RhbmRhcmQgDQogIFRyYWNrXS48QlI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFRoZSBzdGF0dXMgb2YgdGhlIA0KICB3b3JraW5nPEJSPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7Jmd0OyBncm91cCBpcyB0aGF0IHdlIGhh dmUgYSANCiAgZHJhZnQ8QlI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDxCUj4mZ3Q7Jmd0OyZndDsgKDxBIA0KICBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1vbmFtaTYtbXVsdGlwbGVjb2EtMTIiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW9uYW1pNi1tdWx0aXBsZWNvYS0xMjwvQT4pIA0K ICBmb3I8QlI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxCUj4mZ3Q7Jmd0OyZndDsgDQogIHJlZ2lzdHJhdGlvbiBvZiBtdWx0aXBsZSBjYXJlLW9mIGFk ZHJlc3NlcyB0byBvbmUgaG9tZSANCiAgYWRkcmVzcy48QlI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IA0KICBUaGVyZTxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogIDxCUj4mZ3Q7Jmd0OyZndDsgZXhpc3Qgb25lIA0KICBkcmFmdDxCUj4mZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZndDsmZ3Q7Jmd0OyAoPEEg DQogIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWV4dC1mbG93 LWJpbmRpbmctMDEiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWV4dC1m bG93LWJpbmRpbmctMDE8L0E+KSANCiAgZm9yPEJSPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8QlI+Jmd0OyZndDsmZ3Q7IA0KICB0cmFuc3BvcnQ8QlI+ Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIHRoZSBydWxlcyB0aGF0IGRlY2lkZXMgaG93IGVh Y2ggZmxvdyBpcyBzZW50IA0KICBvdmVyIA0KICB0aGU8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7IGF2YWlsYWJsZTxCUj4mZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDxCUj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmV0d29yazxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg DQogIGludGVyZmFjZXMuPEJSPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgV2hhdCBpcyANCiAgY3VycmVudGx5IG1pc3NpbmcgDQogIGlzPEJSPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7Jmd0 OyB0aGUgcGFydCB0aGF0IGRlZmluZXMgdGhlIA0KICBydWxlcy48QlI+Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxCUj4mZ3Q7Jmd0OyZndDsgDQogIGRy YWZ0LWxhcnNzb24tbWV4dC1mbG93LWRpc3RyaWJ1dGlvbi1ydWxlcyBkZWZpbmVzIGEgcnVsZSBs YW5ndWFnZSANCiAgdGhhdDxCUj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPEJSPiZndDsmZ3Q7Jmd0OyANCiAgY2FuPEJSPiZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBiZSB1c2VkIGZvciB0aGlzLiBUaGUgZG9jdW1lbnQgY2FuIGJlIGZvdW5kIA0KICBh dDo8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OzxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDxCUj4mZ3Q7 Jmd0OyZndDsgPEEgDQogIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxh cnNzb24tbWV4dC1mbG93LWRpc3RyaWJ1dGlvbi1ydWxlcy0wMiI+aHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbGFyc3Nvbi1tZXh0LWZsb3ctZGlzdHJpYnV0aW9uLXJ1bGVzLTAyPC9B PjxCUj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQog IDxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBsZWFzZSBleHByZXNzIHlvdXIgb3Bp bmlvbiBvbiB3aGV0aGVyIHRoaXMgDQogIHNob3VsZCBiZWNvbWUgYSANCiAgV0c8QlI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJS PiZndDsmZ3Q7Jmd0OyBkb2N1bWVudC48QlI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlZ2Fy ZHM8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IA0KICBDb25ueTxCUj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDsmZ3Q7Jmd0OyANCiAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IE1FWFQgbWFpbGluZyANCiAgbGlzdDxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+ Jmd0OyZndDsmZ3Q7IDxBIA0KICBocmVmPSJtYWlsdG86TUVYVEBpZXRmLm9yZyI+TUVYVEBpZXRm Lm9yZzwvQT48QlI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KICA8QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxBIA0KICBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21leHQiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWV4dDwvQT48QlI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PEJS PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8QlI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8QlI+Jmd0OyZndDsm Z3Q7PEJSPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgPEJSPiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPEJSPiZndDsmZ3Q7IE1FWFQgDQogIG1haWxpbmc8QlI+Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPEJSPiZndDsmZ3Q7Jmd0OyANCiAgbGlzdDxCUj4mZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEJSPiZndDsmZ3Q7IDxBIA0KICBo cmVmPSJtYWlsdG86TUVYVEBpZXRmLm9yZyI+TUVYVEBpZXRmLm9yZzwvQT48QlI+Jmd0OyZndDsg PEEgDQogIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0PC9BPjxCUj4mZ3Q7Jmd0 OzxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCiAgPEJSPiZndDs8QlI+Jmd0OyZuYnNwOyZuYnNwOyANCiAgPEJS PjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5N RVhUIG1haWxpbmcgDQogIGxpc3Q8QlI+PEEgaHJlZj0ibWFpbHRvOk1FWFRAaWV0Zi5vcmciPk1F WFRAaWV0Zi5vcmc8L0E+PEJSPjxBIA0KICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21leHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWV4dDwvQT48QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_cj42c7adv3uxHg4+l6yoqg)-- --Boundary_(ID_j5bdNkblIRt3jr6AEdDKHw) Content-id: <0b3501c9bdad$071aab70$40106f0a@china.huawei.com> Content-type: image/jpeg; name=outlook_huawei_logo_cn.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_cn.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_j5bdNkblIRt3jr6AEdDKHw)-- From marcelo@it.uc3m.es Wed Apr 15 02:56:21 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471863A68CC for ; Wed, 15 Apr 2009 02:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 PvfAvEzg-eX6 for ; Wed, 15 Apr 2009 02:56:20 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 13D783A67DB for ; Wed, 15 Apr 2009 02:56:19 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (55.pool85-53-141.dynamic.orange.es [85.53.141.55]) by smtp01.uc3m.es (Postfix) with ESMTP id 1D333B9FDA1; Wed, 15 Apr 2009 11:57:29 +0200 (CEST) Message-ID: <49E5AF88.50306@it.uc3m.es> Date: Wed, 15 Apr 2009 11:57:28 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christian Kaas-Petersen References: <657051.66216.qm@web27807.mail.ukl.yahoo.com> In-Reply-To: <657051.66216.qm@web27807.mail.ukl.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16582.006 Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 09:56:21 -0000 Christian Kaas-Petersen escribió: > Actually, IETF 74th Thursday plenary on MPLS discussed the situation of > have alternative protocols (LDP vs RSVP was just one example) doing the > same thing. The statements made by the speakers and from the floor > were: Yes it is a pain to implement two protocols, and yes it is a > pain to deploy two protocols. However, most often it turns out, that > one of the protocols is left in oblivion when it has been seen running > in practice, and most often taking a second approach gives renewed input > or energy to the first approach, making it clear which of the two > approaches is the favoured one. Thus I went away with the impression, > that staying with one approach is in fact not always the obvious thing > to do. > I am not saying that we must define only one approach in all cases. What i am saying is that the default option is to define only one and we need strong reasons for do more than one Regards, marcelo > Christian > > --- Den ons 15/4/09 skrev marcelo bagnulo braun : > > >> Fra: marcelo bagnulo braun >> Emne: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules >> Til: "George Tsirtsis" >> Cc: "mext" , julien.laganier.IETF@googlemail.com >> Dato: onsdag 15. april 2009 11.05 >> George Tsirtsis escribió: >> >>> Hi Hesham, >>> >>> I think in fact the binary mechanism can easily be >>> >> much more flexible >> >>> if we want to. >>> >>> All we have to do it to allow for matching to an >>> >> "Offset" + "Number of >> >>> bytes". The Offset would be a pointer to X number of >>> >> bytes from the >> >>> beginning of the IP header, and then the Number of >>> >> Bytes, would be the >> >>> field that you are trying to match. >>> This has been used by classifiers for long time now >>> >> (e.g., Linux, look >> >>> for U32 Selector). >>> >>> In that case, the fixed binary format can cover most >>> >> of the cases and >> >>> also provide a mechanism for matching anything else in >>> >> the packet, >> >>> which makes this really powerful. >>> >>> Having said that, while I agree with Marcelo that we >>> >> should only >> >>> define what we need, there is little harm in defining >>> >> additional >> >>> optional Flow Description formats, >>> >> here is disagree >> >> there is harm and it is in term of energy of the WG and in >> term of the >> effectiveness of a standard. >> >> as people may have noticed, we do have a problem finding >> reviews for >> some documents (other documents otoh, get plenty of >> reviews) >> So, i am concerned to disipate energy through multiple >> documents, and i >> preffer to concentrate the enrgey in a single proposal >> >> the other harm is that having two standards for the same >> function is >> clearly less optimal than having only one, i guess people >> will not argue >> against that >> >> (i do understand that the path of less resistance is to get >> all the >> solutions approved and published, but if we do that, >> standards are >> meaningless, so i guess it is the chairs role to make that >> resistance) >> >> So, my take in the general case, is that by default we make >> only one >> standard for a given function >> >> Which one, it is up to the WG to decide >> >> regards, marcelo >> > > > > __________________________________________________________ > Find din nye laptop på kelkoo.dk. Se de gode tilbud her - http://dk.yahoo.com/r/pat/mm > > From Hannes.Tschofenig@gmx.net Wed Apr 15 03:07:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289F63A6B1C for ; Wed, 15 Apr 2009 03:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 Okrq6PVzBXOa for ; Wed, 15 Apr 2009 03:07:52 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 497CD3A69E2 for ; Wed, 15 Apr 2009 03:07:51 -0700 (PDT) Received: (qmail invoked by alias); 15 Apr 2009 10:09:02 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp059) with SMTP; 15 Apr 2009 12:09:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+WHf5QtbWWnba4MrDf3aNTIXsC6TQ6ebDh+dTP3v iW5Q90PgkcNpwX From: "Hannes Tschofenig" To: "'George Tsirtsis'" , "'Hesham Soliman'" References: <49E4BB6C.6030702@it.uc3m.es> Date: Wed, 15 Apr 2009 13:10:29 +0300 Message-ID: <012901c9bdb2$68393de0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm9pw/bkVMPk9oZSISeKD8n6qdLFgACRSjw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Cc: julien.laganier.IETF@googlemail.com, 'mext' Subject: Re: [MEXT] Call for adoptation ofdraft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 10:07:54 -0000 In the AAA space we have been working on two formats: * One format used the ipfw BSD packet filter syntax. See, for example, IPFilterRule in http://www.rfc-editor.org/rfc/rfc3588.txt. * A format that is more aligned with the Diameter AVP syntax, see http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-11.txt= We had discussions about other ideas, including the ability to carry something like the code understandable for a BPF virtual machine right = away. This would lead to the most compact representation and very likely to = the best performance.=20 We did pick the latter because folks didn't really understood how it = would work. Nobody in the DIME group has done such detailed work with packet filters implementations. =20 Ciao Hannes >-----Original Message----- >From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 >Behalf Of George Tsirtsis >Sent: 15 April, 2009 11:49 >To: Hesham Soliman >Cc: julien.laganier.IETF@googlemail.com; mext >Subject: Re: [MEXT] Call for adoptation=20 >ofdraft-larsson-mext-flow-distribution-rules > >Hi Hesham, > >I think in fact the binary mechanism can easily be much more=20 >flexible if we want to. > >All we have to do it to allow for matching to an "Offset" +=20 >"Number of bytes". The Offset would be a pointer to X number=20 >of bytes from the beginning of the IP header, and then the=20 >Number of Bytes, would be the field that you are trying to match. >This has been used by classifiers for long time now (e.g.,=20 >Linux, look for U32 Selector). > >In that case, the fixed binary format can cover most of the=20 >cases and also provide a mechanism for matching anything else=20 >in the packet, which makes this really powerful. > >Having said that, while I agree with Marcelo that we should=20 >only define what we need, there is little harm in defining=20 >additional optional Flow Description formats, as long as it is=20 >clear what is actually required for interop vs what is optional. > >Thoughts? >George > >On Wed, Apr 15, 2009 at 1:24 AM, Hesham Soliman=20 > wrote: >> The binary description that George referred to covered the=20 >majority of=20 >> use cases but it doesn't cover, for instance, a filter on the 75th=20 >> byte in the packet. Draft-larsson covers those cases and is=20 >more generic. >> The problem with doing things sequentially is that there are=20 >different=20 >> types of use cases that can occur from day 1 simultaneously. Use=20 >> scenarios are not going to go from basic to advanced over time, they=20 >> can start with advanced from day 1 sometimes. >> >> So, the safest option is to go with draft-larsson. But, the counter=20 >> opinion here is that I'll be very surprised if organisations=20 >like 3GPP=20 >> who already have binary filters (and love binary encoding)=20 >would want=20 >> text encoding because they will likely feel that it's wasteful. >> >> It seems like both are needed but if you have to make=20 >something wait,=20 >> I'd make the binary stuff wait till someone asks for it. It was in=20 >> older versions of the draft and it would be very simple of=20 >us to take=20 >> that out and put it in a separate draft. >> >> Hesham >> >> >> On 15/04/09 3:35 AM, "marcelo bagnulo braun"=20 > wrote: >> >>> i wonder if we need the advanced features at this point >> I mean, we are just >>> defining this, wouldn't make sense to wait and see >> if with the basic >>> procedure is enough and do the extnesions later? Or is >> the basic mechanism so >>> limited that is not enough to handle simple basic >> scenarios? If that is the >>> case, does it makes sense to even define it? >> >> Bottom line, we need strong >>> reasons to do things in multiple different >> ways. Unless clear reasons are >>> described, i fail to see why we should >> standardize multiple >>> approaches >> >> Regards, marcelo >> >> >> >> George Tsirtsis escribi=F3: >>> Hi Marcelo, >>> >>> In >>> the Monami6 days, the Flow Bindings draft used to include a binary=20 >>> Flow Descriptor as part of the FID option. >>> This was basically a typical fixed >>> length binary format defining a >>> classifier filterm including source and destination addresses,=20 >>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not=20 >>> forget something; both IPv4 and IPv6 can be supported with this. >>> >>> Some people, however, thought that more flexible FDs should be=20 >>> allowed and Conny's draft describes a text based format which is=20 >>> clearly more flexible but also more verbose. >>> >>> At the time, the WG decided that >>> the FD format should be taken out of >>> the Flow Bindings draft. I am not sure I like that but this=20 >is indeed=20 >>> what happened. >>> So, now the Flow Bindings >>> draft allows for different FD formats, but it does not=20 >define any of=20 >>> them. >>> >>> As a minimum, IMO the protocol should define one format as the=20 >>> default that all implementations MUST support, so that we can have >>> >>> interoperable implementations. >>> IMO this should be the binary format which is the most compact and=20 >>> will work for most of the cases anyway. I do not care too much if=20 >>> this is defined in the same or on a separate (albeit tightly >>> coupled) >>> drafts. >>> >>> It is also ok with me to have other optional formats (like Conny's)=20 >>> for more advanced use cases. >>> >>> I hope this helps >>> >>> >>> George >>> >>> =A0Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun=20 >>> wrote: >>> >>>> George Tsirtsis escribi=F3: >>>> >>>>> Hi >>> Conny, >>>>> >>>>> Good to see you are resurrecting this draft. I think we need >>> this as >>>>> one of the alternatives. We also need a binary version which I >>> will be >>>>> working on with others after I am done updating the Flow >>> Bindings >>>>> draft. >>>>> >>>>> >>>> could you expand on this? >>>> I mean, are >>> you saying that we need two ways of describing flows? >>>> >>>> Regards, >>> marcelo >>>> >>>> >>>>> Thanks >>>>> George >>>>> >>>>> On Tue, Apr 14, 2009 at 4:35 >>> PM, Conny Larsson >>>>> wrote: >>>>> >>>>> >>>>>> >>> Hi, >>>>>> >>>>>> This is a request to the MEXT working group to adopt >>>>>> >>> draft-larsson-mext-flow-distribution-rules to cover the charter >>> item: >>>>>> >>>>>> (A.3) Use of multiple interfaces. >>>>>> ... >>>>>> Deliverables >>> related to this include >>>>>> - A "Flow/binding policies exchange" solution for >>> an exchange of >>>>>> policies from the mobile host/router to the Home Agent and >>> from the >>>>>> Home Agent to the mobile host/router influencing the choice of >>> the >>>>>> Care-of Address and Home Agent address. The solution involves >>> two >>>>>> specifications, one for the policy format and another for its >>>>>> >>> transport [both Standard Track]. >>>>>> >>>>>> >>>>>> The status of the working >>> group is that we have a draft >>>>>> >>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>>>> >>> registration of multiple care-of addresses to one home address. >>>>>> There >>> exist one draft >>>>>> >>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>> >>> transport >>>>>> of the rules that decides how each flow is sent over the >>> available >>>>>> network >>>>>> interfaces. >>>>>> >>>>>> What is currently missing is >>> the part that defines the rules. >>>>>> >>> draft-larsson-mext-flow-distribution-rules defines a rule language=20 >>> that >>>>>> >>> can >>>>>> be used for this. The document can be found at: >>>>>> >>>>>> >>>=20 >http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules >>> -02 >>>>>> >> >>> >>>> Please express your opinion on whether this should become a WG >>> document. >>>>>> >>>>>> >>>>>> Regards >>>>>> Conny >>>>>> >>>>>> >>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> >>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>>>> >>> >>>>> >>>> >>> >>> >>> >> >> _______________________________________________ >> MEXT mailing >>> list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> >> >> >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext > From jonne.soininen@nsn.com Wed Apr 15 05:52:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1C443A697A for ; Wed, 15 Apr 2009 05:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.329 X-Spam-Level: X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=-0.730, 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 LL1GucJ7QICF for ; Wed, 15 Apr 2009 05:52:29 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id B33C73A6901 for ; Wed, 15 Apr 2009 05:52:28 -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 n3FCrdiE010604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 15 Apr 2009 14:53:39 +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 n3FCrb5s013533 for ; Wed, 15 Apr 2009 14:53:39 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 14:53:37 +0200 Received: from 10.144.22.150 ([10.144.22.150]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Apr 2009 12:53:34 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 15 Apr 2009 15:53:30 +0300 From: "Soininen, Jonne (NSN - FI/Espoo)" To: Message-ID: Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-05.txt Thread-Index: Acm9yS0hRY+oI7CgFUy6lXO0uGsgDw== In-Reply-To: <20090330214501.EFA0128C130@core3.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Apr 2009 12:53:37.0789 (UTC) FILETIME=[31C5C2D0:01C9BDC9] Subject: Re: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-05.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 12:52:29 -0000 Hello everybody, I read the draft, and it seems in quite good condition (even I understood it). What are the next steps with it, and when is the WG going to move forward with it? Cheers, Jonne. On 3/31/09 12:45 AM, "ext Internet-Drafts@ietf.org" wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobility EXTensions for IPv6 Working Group of > the IETF. > > > Title : Binding Revocation for IPv6 Mobility > Author(s) : A. Muhanna, et al. > Filename : draft-ietf-mext-binding-revocation-05.txt > Pages : 36 > Date : 2009-03-30 > > This document defines a binding revocation mechanism to terminate a > mobile node's mobility session and the associated resources. These > semantics are generic enough and can be used by mobility entities in > the case of Mobile IPv6 and its extensions. This mechanism allows > the mobility entity which initiates the revocation procedure to > request its corresponding one to terminate either one, multiple or > all specified binding cache entries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-05.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. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: jonne.soininen@nsn.com From ryuji.wakikawa@gmail.com Wed Apr 15 22:18:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45123A6987 for ; Wed, 15 Apr 2009 22:18:20 -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 pZZX72T2WC4a for ; Wed, 15 Apr 2009 22:18:19 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 8D0B93A67E4 for ; Wed, 15 Apr 2009 22:18:19 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so205783qwb.31 for ; Wed, 15 Apr 2009 22:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=47iD089g6OW2sTJ7EyfeRBbpm2iaffyoQZ1s6ZaZ09M=; b=bv9fGaUFz0c5vvrRuOgvDeQ/2uo9x+RjR6vfmKW6+KttJc+BLcOv8N1cfTdiGi13+T MF4536ivIpv/Lorh+wxQSvgO3OguQGRTdrIfB86ANeQGTHjy1Q4UiK+etoSFO7++sXDM wxZbXSYjCyYbyLg0AoK1SerhBNtffDT3aGsyo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=ioP4VD0gq4VeWg5fIMqaruKpNTB7DOyK5zYTDnV73hjNSNaQvOnox03suj+nFPI2Ss oNVKbXdS2EnrQ+t8JrBHEM65XdsPm+dnyeKAVVwO8+91vKAZAhrAiLVG1Y6tSjiZ8yY3 YflOYit0bkPizgKjz/Ruo6/R09kniyYQgfnHA= Received: by 10.224.60.135 with SMTP id p7mr1457191qah.62.1239859171937; Wed, 15 Apr 2009 22:19:31 -0700 (PDT) Received: from ?172.17.191.127? ([208.251.140.35]) by mx.google.com with ESMTPS id 5sm1194022qwh.39.2009.04.15.22.19.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Apr 2009 22:19:31 -0700 (PDT) From: Ryuji Wakikawa To: marcelo bagnulo braun In-Reply-To: <49E4BB6C.6030702@it.uc3m.es> References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> <49E4BB6C.6030702@it.uc3m.es> Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 01:19:28 -0400 X-Mailer: Apple Mail (2.930.3) Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 05:18:20 -0000 Hi Marcelo, When we have discussed flow management, there are two approaches (one =20= is flow binding). The other approach is to install flow filters statically at the HA and =20= MN and switch them according to binding cache. Let's say MN and HA are statically configured with these three filters =20= set. According to binding cache database, each node switch the filter. BID1 only -> filter1 BID1 and BID2 -> filter2 BID2 only -> filter3 Flow binding has advantages on dynamic updates, but, on the other =20 hand, some operators (let's say KDDI) prefer using more stable filter. The operator ships the terminal with pre-defined =20 filter rules. The dynamic management leads certain overhead, too. That' why we have this Conny's document. AFAIK, this document does not specify any transport mechanism, but =20 define only syntax of filters. Of course, you might use SSL, HTTPs, even flow binding (as George =20 said), and any other mechanism to exchange these filters (if you want =20= dynamic filters exchange). To define a general filter syntax is very useful. This can be =20 targetted to informational or experimental RFC. thanks ryuji On 2009/04/14, at 12:35, marcelo bagnulo braun wrote: > i wonder if we need the advanced features at this point > I mean, we are just defining this, wouldn't make sense to wait and =20 > see if with the basic procedure is enough and do the extnesions =20 > later? Or is the basic mechanism so limited that is not enough to =20 > handle simple basic scenarios? If that is the case, does it makes =20 > sense to even define it? > > Bottom line, we need strong reasons to do things in multiple =20 > different ways. Unless clear reasons are described, i fail to see =20 > why we should standardize multiple approaches > > Regards, marcelo > > > > George Tsirtsis escribi=C3=B3: >> Hi Marcelo, >> >> In the Monami6 days, the Flow Bindings draft used to include a binary >> Flow Descriptor as part of the FID option. >> This was basically a typical fixed length binary format defining a >> classifier filterm including source and destination addresses, >> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >> forget something; both IPv4 and IPv6 can be supported with this. >> >> Some people, however, thought that more flexible FDs should be =20 >> allowed >> and Conny's draft describes a text based format which is clearly more >> flexible but also more verbose. >> >> At the time, the WG decided that the FD format should be taken out of >> the Flow Bindings draft. I am not sure I like that but this is indeed >> what happened. >> So, now the Flow Bindings draft allows for different FD formats, but >> it does not define any of them. >> >> As a minimum, IMO the protocol should define one format as the =20 >> default >> that all implementations MUST support, so that we can have >> interoperable implementations. >> IMO this should be the binary format which is the most compact and >> will work for most of the cases anyway. I do not care too much if =20 >> this >> is defined in the same or on a separate (albeit tightly coupled) >> drafts. >> >> It is also ok with me to have other optional formats (like Conny's) >> for more advanced use cases. >> >> I hope this helps >> >> George >> >> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun = > > wrote: >> >>> George Tsirtsis escribi=C3=B3: >>> >>>> Hi Conny, >>>> >>>> Good to see you are resurrecting this draft. I think we need this =20= >>>> as >>>> one of the alternatives. We also need a binary version which I =20 >>>> will be >>>> working on with others after I am done updating the Flow Bindings >>>> draft. >>>> >>>> >>> could you expand on this? >>> I mean, are you saying that we need two ways of describing flows? >>> >>> Regards, marcelo >>> >>> >>>> Thanks >>>> George >>>> >>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >>>> wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> This is a request to the MEXT working group to adopt >>>>> draft-larsson-mext-flow-distribution-rules to cover the charter =20= >>>>> item: >>>>> >>>>> (A.3) Use of multiple interfaces. >>>>> ... >>>>> Deliverables related to this include >>>>> - A "Flow/binding policies exchange" solution for an exchange of >>>>> policies from the mobile host/router to the Home Agent and from =20= >>>>> the >>>>> Home Agent to the mobile host/router influencing the choice of the >>>>> Care-of Address and Home Agent address. The solution involves two >>>>> specifications, one for the policy format and another for its >>>>> transport [both Standard Track]. >>>>> >>>>> >>>>> The status of the working group is that we have a draft >>>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>>> registration of multiple care-of addresses to one home address. >>>>> There exist one draft >>>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>> transport >>>>> of the rules that decides how each flow is sent over the available >>>>> network >>>>> interfaces. >>>>> >>>>> What is currently missing is the part that defines the rules. >>>>> draft-larsson-mext-flow-distribution-rules defines a rule =20 >>>>> language that >>>>> can >>>>> be used for this. The document can be found at: >>>>> >>>>> = http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>>> >>>>> Please express your opinion on whether this should become a WG =20 >>>>> document. >>>>> >>>>> >>>>> Regards >>>>> Conny >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>>>> >>>> >>> >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Wed Apr 15 22:21:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F6B3A6ABF for ; Wed, 15 Apr 2009 22:21:57 -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 DjCaTPfxN51f for ; Wed, 15 Apr 2009 22:21:56 -0700 (PDT) Received: from mail-qy0-f121.google.com (mail-qy0-f121.google.com [209.85.221.121]) by core3.amsl.com (Postfix) with ESMTP id 725B63A6A89 for ; Wed, 15 Apr 2009 22:21:56 -0700 (PDT) Received: by qyk27 with SMTP id 27so460484qyk.29 for ; Wed, 15 Apr 2009 22:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=YHc7v6rT/QxJTv3WkZejW7u0iukkObTYDDbyFYIY+Qk=; b=nrFw3uxKeVyt8WQqzpf29XT7f7EI1wkNiUnSCEWR1KoTYy7MMIAqld9iWXX+fNWN3q YwSwYZ5GfBDWYDUYxth7PktwyzuKFASyg0w9mGxua1YnIRjOVLmhHS7m6OAmBKwYTVwn ahEtFHgRb2+SmFc1jGT8JM0SUVLBvV2N3KNro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=Ecq9wnQvF7It2HgfSMk73s6txHuXzbeAsvVBCA2GvB5L+HajnvmTIVo1vL7MuSyMx4 v2lg9eMZgK8h7AX9jhVCVdAkEFczCFAjtJeovNi34C+qrdvpwozBRNwOWf+qke3BURAD oucXiUku9mArZIQZCUh4R0q7QBZf0c4n7ptfc= Received: by 10.224.29.2 with SMTP id o2mr1460000qac.102.1239859388774; Wed, 15 Apr 2009 22:23:08 -0700 (PDT) Received: from ?172.17.191.127? ([208.251.140.35]) by mx.google.com with ESMTPS id 2sm1202008qwi.13.2009.04.15.22.23.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Apr 2009 22:23:08 -0700 (PDT) From: Ryuji Wakikawa To: George Tsirtsis In-Reply-To: References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> Message-Id: <5AED9BC3-FE88-4712-AC14-511981DC063A@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 01:22:51 -0400 X-Mailer: Apple Mail (2.930.3) Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 05:21:57 -0000 Hi George, On 2009/04/14, at 12:31, George Tsirtsis wrote: > Hi Marcelo, > > In the Monami6 days, the Flow Bindings draft used to include a binary > Flow Descriptor as part of the FID option. > This was basically a typical fixed length binary format defining a > classifier filterm including source and destination addresses, > protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not > forget something; both IPv4 and IPv6 can be supported with this. > > Some people, however, thought that more flexible FDs should be allowed > and Conny's draft describes a text based format which is clearly more > flexible but also more verbose. > > At the time, the WG decided that the FD format should be taken out of > the Flow Bindings draft. I am not sure I like that but this is indeed > what happened. > So, now the Flow Bindings draft allows for different FD formats, but > it does not define any of them. Ok, I didn't know this change. The current flow binding document =20 haven't followed this decision yet?! regards, ryuji > > > As a minimum, IMO the protocol should define one format as the default > that all implementations MUST support, so that we can have > interoperable implementations. > IMO this should be the binary format which is the most compact and > will work for most of the cases anyway. I do not care too much if this > is defined in the same or on a separate (albeit tightly coupled) > drafts. > > It is also ok with me to have other optional formats (like Conny's) > for more advanced use cases. > > I hope this helps > > George > > Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun = > wrote: >> George Tsirtsis escribi=C3=B3: >>> >>> Hi Conny, >>> >>> Good to see you are resurrecting this draft. I think we need this as >>> one of the alternatives. We also need a binary version which I =20 >>> will be >>> working on with others after I am done updating the Flow Bindings >>> draft. >>> >> >> could you expand on this? >> I mean, are you saying that we need two ways of describing flows? >> >> Regards, marcelo >> >>> Thanks >>> George >>> >>> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >>> wrote: >>> >>>> >>>> Hi, >>>> >>>> This is a request to the MEXT working group to adopt >>>> draft-larsson-mext-flow-distribution-rules to cover the charter =20 >>>> item: >>>> >>>> (A.3) Use of multiple interfaces. >>>> ... >>>> Deliverables related to this include >>>> - A "Flow/binding policies exchange" solution for an exchange of >>>> policies from the mobile host/router to the Home Agent and from the >>>> Home Agent to the mobile host/router influencing the choice of the >>>> Care-of Address and Home Agent address. The solution involves two >>>> specifications, one for the policy format and another for its >>>> transport [both Standard Track]. >>>> >>>> >>>> The status of the working group is that we have a draft >>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>> registration of multiple care-of addresses to one home address. >>>> There exist one draft >>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>> transport >>>> of the rules that decides how each flow is sent over the available >>>> network >>>> interfaces. >>>> >>>> What is currently missing is the part that defines the rules. >>>> draft-larsson-mext-flow-distribution-rules defines a rule =20 >>>> language that >>>> can >>>> be used for this. The document can be found at: >>>> >>>> = http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>> >>>> Please express your opinion on whether this should become a WG =20 >>>> document. >>>> >>>> >>>> Regards >>>> Conny >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>> >>> >> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Wed Apr 15 22:30:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A533A6A7F for ; Wed, 15 Apr 2009 22:30:05 -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 jmeV1Q1BMglv for ; Wed, 15 Apr 2009 22:30:04 -0700 (PDT) Received: from mail-qy0-f121.google.com (mail-qy0-f121.google.com [209.85.221.121]) by core3.amsl.com (Postfix) with ESMTP id B70F13A6A53 for ; Wed, 15 Apr 2009 22:30:03 -0700 (PDT) Received: by qyk27 with SMTP id 27so463333qyk.29 for ; Wed, 15 Apr 2009 22:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=cMCWtYhuR7EMbwrT5NKKcQZ5WrbqnnFdme3u5KuftXs=; b=iTmDSaQMkVh75WT+p5sANP/ur+Yz81N7i1kWbWMK1m4v1o5z8AQrg//Pp7u7pno5QS k30GYLVvZlngXcXfuBqA74cl4ST7cMuv6XgeNeQW801VBpbnohkdkrafpbxDxeEWDGt2 QtidyiZLu+vVtDOr/bBBkpDCUbHgqyMLlocMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=iYESTd8KylFOOShVKU05ClWYnf3CoeqbC3JXjaGR4kgDKY1uLZi+XTcnvJWtVqjswd l4ZkjamvMQbbBmuBejYin19Eq/Zz2sjYaxzthXwpIr7l6/+pT9IUuijwE30OK5oBHyQ1 uZsmf7tEdfXHOYfIgcDb2KYGw0pgyC/VmGBs8= Received: by 10.224.2.84 with SMTP id 20mr1463749qai.3.1239859876167; Wed, 15 Apr 2009 22:31:16 -0700 (PDT) Received: from ?172.17.191.127? ([208.251.140.35]) by mx.google.com with ESMTPS id 7sm1214951qwf.35.2009.04.15.22.31.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Apr 2009 22:31:15 -0700 (PDT) From: Ryuji Wakikawa To: Hannes Tschofenig In-Reply-To: <012901c9bdb2$68393de0$0201a8c0@nsnintra.net> References: <49E4BB6C.6030702@it.uc3m.es> <012901c9bdb2$68393de0$0201a8c0@nsnintra.net> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 01:31:11 -0400 X-Mailer: Apple Mail (2.930.3) Cc: 'mext' , julien.laganier.IETF@googlemail.com Subject: Re: [MEXT] Call for adoptation ofdraft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 05:30:05 -0000 Hi Hannes, I think what we have discussed now in MEXT is a bit similar to this =20 case. The Conny's draft is originally inspired from IPFW, which is most used =20= filter description and stable. The operator has certain experiences of using IPFW with operational =20 knowhow (for different purpose than multihoming, firewall setting etc). Since Conny's draft does not define transport mechanisms, we will not =20= have two "protocols" to do same things. We will have just multiple filter syntax. regards, ryuji On 2009/04/15, at 6:10, Hannes Tschofenig wrote: > In the AAA space we have been working on two formats: > > * One format used the ipfw BSD packet filter syntax. See, for example, > IPFilterRule in http://www.rfc-editor.org/rfc/rfc3588.txt. > > * A format that is more aligned with the Diameter AVP syntax, see > = http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-11.txt > > We had discussions about other ideas, including the ability to carry > something like the code understandable for a BPF virtual machine =20 > right away. > This would lead to the most compact representation and very likely =20 > to the > best performance. > > We did pick the latter because folks didn't really understood how it =20= > would > work. Nobody in the DIME group has done such detailed work with packet > filters implementations. > > Ciao > Hannes > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of George Tsirtsis >> Sent: 15 April, 2009 11:49 >> To: Hesham Soliman >> Cc: julien.laganier.IETF@googlemail.com; mext >> Subject: Re: [MEXT] Call for adoptation >> ofdraft-larsson-mext-flow-distribution-rules >> >> Hi Hesham, >> >> I think in fact the binary mechanism can easily be much more >> flexible if we want to. >> >> All we have to do it to allow for matching to an "Offset" + >> "Number of bytes". The Offset would be a pointer to X number >> of bytes from the beginning of the IP header, and then the >> Number of Bytes, would be the field that you are trying to match. >> This has been used by classifiers for long time now (e.g., >> Linux, look for U32 Selector). >> >> In that case, the fixed binary format can cover most of the >> cases and also provide a mechanism for matching anything else >> in the packet, which makes this really powerful. >> >> Having said that, while I agree with Marcelo that we should >> only define what we need, there is little harm in defining >> additional optional Flow Description formats, as long as it is >> clear what is actually required for interop vs what is optional. >> >> Thoughts? >> George >> >> On Wed, Apr 15, 2009 at 1:24 AM, Hesham Soliman >> wrote: >>> The binary description that George referred to covered the >> majority of >>> use cases but it doesn't cover, for instance, a filter on the 75th >>> byte in the packet. Draft-larsson covers those cases and is >> more generic. >>> The problem with doing things sequentially is that there are >> different >>> types of use cases that can occur from day 1 simultaneously. Use >>> scenarios are not going to go from basic to advanced over time, they >>> can start with advanced from day 1 sometimes. >>> >>> So, the safest option is to go with draft-larsson. But, the counter >>> opinion here is that I'll be very surprised if organisations >> like 3GPP >>> who already have binary filters (and love binary encoding) >> would want >>> text encoding because they will likely feel that it's wasteful. >>> >>> It seems like both are needed but if you have to make >> something wait, >>> I'd make the binary stuff wait till someone asks for it. It was in >>> older versions of the draft and it would be very simple of >> us to take >>> that out and put it in a separate draft. >>> >>> Hesham >>> >>> >>> On 15/04/09 3:35 AM, "marcelo bagnulo braun" >> wrote: >>> >>>> i wonder if we need the advanced features at this point >>> I mean, we are just >>>> defining this, wouldn't make sense to wait and see >>> if with the basic >>>> procedure is enough and do the extnesions later? Or is >>> the basic mechanism so >>>> limited that is not enough to handle simple basic >>> scenarios? If that is the >>>> case, does it makes sense to even define it? >>> >>> Bottom line, we need strong >>>> reasons to do things in multiple different >>> ways. Unless clear reasons are >>>> described, i fail to see why we should >>> standardize multiple >>>> approaches >>> >>> Regards, marcelo >>> >>> >>> >>> George Tsirtsis escribi=F3: >>>> Hi Marcelo, >>>> >>>> In >>>> the Monami6 days, the Flow Bindings draft used to include a binary >>>> Flow Descriptor as part of the FID option. >>>> This was basically a typical fixed >>>> length binary format defining a >>>> classifier filterm including source and destination addresses, >>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>> forget something; both IPv4 and IPv6 can be supported with this. >>>> >>>> Some people, however, thought that more flexible FDs should be >>>> allowed and Conny's draft describes a text based format which is >>>> clearly more flexible but also more verbose. >>>> >>>> At the time, the WG decided that >>>> the FD format should be taken out of >>>> the Flow Bindings draft. I am not sure I like that but this >> is indeed >>>> what happened. >>>> So, now the Flow Bindings >>>> draft allows for different FD formats, but it does not >> define any of >>>> them. >>>> >>>> As a minimum, IMO the protocol should define one format as the >>>> default that all implementations MUST support, so that we can have >>>> >>>> interoperable implementations. >>>> IMO this should be the binary format which is the most compact and >>>> will work for most of the cases anyway. I do not care too much if >>>> this is defined in the same or on a separate (albeit tightly >>>> coupled) >>>> drafts. >>>> >>>> It is also ok with me to have other optional formats (like Conny's) >>>> for more advanced use cases. >>>> >>>> I hope this helps >>>> >>>> >>>> George >>>> >>>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>> wrote: >>>> >>>>> George Tsirtsis escribi=F3: >>>>> >>>>>> Hi >>>> Conny, >>>>>> >>>>>> Good to see you are resurrecting this draft. I think we need >>>> this as >>>>>> one of the alternatives. We also need a binary version which I >>>> will be >>>>>> working on with others after I am done updating the Flow >>>> Bindings >>>>>> draft. >>>>>> >>>>>> >>>>> could you expand on this? >>>>> I mean, are >>>> you saying that we need two ways of describing flows? >>>>> >>>>> Regards, >>>> marcelo >>>>> >>>>> >>>>>> Thanks >>>>>> George >>>>>> >>>>>> On Tue, Apr 14, 2009 at 4:35 >>>> PM, Conny Larsson >>>>>> wrote: >>>>>> >>>>>> >>>>>>> >>>> Hi, >>>>>>> >>>>>>> This is a request to the MEXT working group to adopt >>>>>>> >>>> draft-larsson-mext-flow-distribution-rules to cover the charter >>>> item: >>>>>>> >>>>>>> (A.3) Use of multiple interfaces. >>>>>>> ... >>>>>>> Deliverables >>>> related to this include >>>>>>> - A "Flow/binding policies exchange" solution for >>>> an exchange of >>>>>>> policies from the mobile host/router to the Home Agent and >>>> from the >>>>>>> Home Agent to the mobile host/router influencing the choice of >>>> the >>>>>>> Care-of Address and Home Agent address. The solution involves >>>> two >>>>>>> specifications, one for the policy format and another for its >>>>>>> >>>> transport [both Standard Track]. >>>>>>> >>>>>>> >>>>>>> The status of the working >>>> group is that we have a draft >>>>>>> >>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>>>>> >>>> registration of multiple care-of addresses to one home address. >>>>>>> There >>>> exist one draft >>>>>>> >>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>>> >>>> transport >>>>>>> of the rules that decides how each flow is sent over the >>>> available >>>>>>> network >>>>>>> interfaces. >>>>>>> >>>>>>> What is currently missing is >>>> the part that defines the rules. >>>>>>> >>>> draft-larsson-mext-flow-distribution-rules defines a rule language >>>> that >>>>>>> >>>> can >>>>>>> be used for this. The document can be found at: >>>>>>> >>>>>>> >>>> >> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules >>>> -02 >>>>>>> >>> >>>>>>>> Please express your opinion on whether this should become a WG >>>> document. >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Conny >>>>>>> >>>>>>> >>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> >>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>>> >>>>>>> >>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> MEXT mailing >>>> list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Wed Apr 15 22:34:55 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613C33A682A for ; Wed, 15 Apr 2009 22:34: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 TMBBy3nxjRiA for ; Wed, 15 Apr 2009 22:34:54 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id B1B793A681E for ; Wed, 15 Apr 2009 22:34:53 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so208557qwb.31 for ; Wed, 15 Apr 2009 22:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=zgtB49N/o+hQu+mLfxPBNa2br1Jup2zMQStjNPWXB3g=; b=x8CAMrlYwGgKCtuu6nx0jasJHzMtPym0y+v2B4thQ4RqdJ+oG4+T8cGw+G7IHmqPXS nQGFVQViIHZ7nP4LoInENaFAq5ArVvedE59gFkjT6PUlbw/tqrGFVqQ5PPbfX4KHfjLk XLbc4q07j7X4G/tM4KyQOv1H07LFVxMG4OeZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=g/9sTMyXrKZ4cCbEiM6jb6VHdW0xUkkdKEZxufoDOuJn2nRV56r044IsUCkVX5dh/2 E97GJTKFtCDZQmH47Ex26yOEJCzmGAu7aVdzrR15SAOAjvnRPiA4C9SozjpjZNVHpQZW lEKO8D1FDkVKhj2VzTXYiWdzMdedDRgh4SdFw= Received: by 10.224.45.134 with SMTP id e6mr1467017qaf.237.1239860166168; Wed, 15 Apr 2009 22:36:06 -0700 (PDT) Received: from ?172.17.191.127? ([208.251.140.35]) by mx.google.com with ESMTPS id 26sm1225537qwa.32.2009.04.15.22.36.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Apr 2009 22:36:05 -0700 (PDT) From: Ryuji Wakikawa To: marcelo bagnulo braun In-Reply-To: <49E5A36B.3000102@it.uc3m.es> References: <49E4BB6C.6030702@it.uc3m.es> <49E5A36B.3000102@it.uc3m.es> Message-Id: <4B0BC1D0-565B-4906-87A1-B4E7F8743ADE@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 01:36:03 -0400 X-Mailer: Apple Mail (2.930.3) Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 05:34:55 -0000 Hi Marcelo, I agree with you that the WG interests are hard to control. I had some =20= experience of that;-p Regarding this document, it introduces filter's syntax based on =20 existing syntax set and is small document. You can probably start call for adaptation and see how many people is =20= interested in this document. Just suggestion;-) ryuji On 2009/04/15, at 5:05, marcelo bagnulo braun wrote: > George Tsirtsis escribi=C3=B3: >> Hi Hesham, >> >> I think in fact the binary mechanism can easily be much more flexible >> if we want to. >> >> All we have to do it to allow for matching to an "Offset" + "Number =20= >> of >> bytes". The Offset would be a pointer to X number of bytes from the >> beginning of the IP header, and then the Number of Bytes, would be =20= >> the >> field that you are trying to match. >> This has been used by classifiers for long time now (e.g., Linux, =20 >> look >> for U32 Selector). >> >> In that case, the fixed binary format can cover most of the cases and >> also provide a mechanism for matching anything else in the packet, >> which makes this really powerful. >> >> Having said that, while I agree with Marcelo that we should only >> define what we need, there is little harm in defining additional >> optional Flow Description formats, > > here is disagree > > there is harm and it is in term of energy of the WG and in term of =20 > the effectiveness of a standard. > > as people may have noticed, we do have a problem finding reviews for =20= > some documents (other documents otoh, get plenty of reviews) > So, i am concerned to disipate energy through multiple documents, =20 > and i preffer to concentrate the enrgey in a single proposal > > the other harm is that having two standards for the same function is =20= > clearly less optimal than having only one, i guess people will not =20 > argue against that > > (i do understand that the path of less resistance is to get all the =20= > solutions approved and published, but if we do that, standards are =20 > meaningless, so i guess it is the chairs role to make that resistance) > > So, my take in the general case, is that by default we make only one =20= > standard for a given function > > Which one, it is up to the WG to decide > > regards, marcelo > >> as long as it is clear what is >> actually required for interop vs what is optional. >> >> Thoughts? >> George >> >> On Wed, Apr 15, 2009 at 1:24 AM, Hesham Soliman >> wrote: >> >>> The binary description that George referred to covered the =20 >>> majority of use >>> cases but it doesn't cover, for instance, a filter on the 75th =20 >>> byte in the >>> packet. Draft-larsson covers those cases and is more generic. >>> The problem with doing things sequentially is that there are =20 >>> different types >>> of use cases that can occur from day 1 simultaneously. Use =20 >>> scenarios are not >>> going to go from basic to advanced over time, they can start with =20= >>> advanced >>> from day 1 sometimes. >>> >>> So, the safest option is to go with draft-larsson. But, the =20 >>> counter opinion >>> here is that I'll be very surprised if organisations like 3GPP who =20= >>> already >>> have binary filters (and love binary encoding) would want text =20 >>> encoding >>> because they will likely feel that it's wasteful. >>> >>> It seems like both are needed but if you have to make something =20 >>> wait, I'd >>> make the binary stuff wait till someone asks for it. It was in older >>> versions of the draft and it would be very simple of us to take =20 >>> that out and >>> put it in a separate draft. >>> >>> Hesham >>> >>> >>> On 15/04/09 3:35 AM, "marcelo bagnulo braun" =20= >>> wrote: >>> >>> >>>> i wonder if we need the advanced features at this point >>>> >>> I mean, we are just >>> >>>> defining this, wouldn't make sense to wait and see >>>> >>> if with the basic >>> >>>> procedure is enough and do the extnesions later? Or is >>>> >>> the basic mechanism so >>> >>>> limited that is not enough to handle simple basic >>>> >>> scenarios? If that is the >>> >>>> case, does it makes sense to even define it? >>>> >>> Bottom line, we need strong >>> >>>> reasons to do things in multiple different >>>> >>> ways. Unless clear reasons are >>> >>>> described, i fail to see why we should >>>> >>> standardize multiple >>> >>>> approaches >>>> >>> Regards, marcelo >>> >>> >>> >>> George Tsirtsis escribi=C3=B3: >>> >>>> Hi Marcelo, >>>> >>>> In >>>> the Monami6 days, the Flow Bindings draft used to include a binary >>>> Flow >>>> Descriptor as part of the FID option. >>>> This was basically a typical fixed >>>> length binary format defining a >>>> classifier filterm including source and >>>> destination addresses, >>>> protocol number, port numbers, Flow ID, and IPSEC >>>> SPI, if I do not >>>> forget something; both IPv4 and IPv6 can be supported with >>>> this. >>>> >>>> Some people, however, thought that more flexible FDs should be >>>> allowed >>>> and Conny's draft describes a text based format which is clearly >>>> more >>>> flexible but also more verbose. >>>> >>>> At the time, the WG decided that >>>> the FD format should be taken out of >>>> the Flow Bindings draft. I am not sure >>>> I like that but this is indeed >>>> what happened. >>>> So, now the Flow Bindings >>>> draft allows for different FD formats, but >>>> it does not define any of >>>> them. >>>> >>>> As a minimum, IMO the protocol should define one format as the >>>> default >>>> that all implementations MUST support, so that we can have >>>> >>>> interoperable implementations. >>>> IMO this should be the binary format which is >>>> the most compact and >>>> will work for most of the cases anyway. I do not care >>>> too much if this >>>> is defined in the same or on a separate (albeit tightly >>>> coupled) >>>> drafts. >>>> >>>> It is also ok with me to have other optional formats >>>> (like Conny's) >>>> for more advanced use cases. >>>> >>>> I hope this helps >>>> >>>> >>>> George >>>> >>>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>> wrote: >>>> >>>> >>>>> George Tsirtsis escribi=C3=B3: >>>>> >>>>> >>>>>> Hi >>>>>> >>>> Conny, >>>> >>>>>> Good to see you are resurrecting this draft. I think we need >>>>>> >>>> this as >>>> >>>>>> one of the alternatives. We also need a binary version which I >>>>>> >>>> will be >>>> >>>>>> working on with others after I am done updating the Flow >>>>>> >>>> Bindings >>>> >>>>>> draft. >>>>>> >>>>>> >>>>>> >>>>> could you expand on this? >>>>> I mean, are >>>>> >>>> you saying that we need two ways of describing flows? >>>> >>>>> Regards, >>>>> >>>> marcelo >>>> >>>>> >>>>>> Thanks >>>>>> George >>>>>> >>>>>> On Tue, Apr 14, 2009 at 4:35 >>>>>> >>>> PM, Conny Larsson >>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>> Hi, >>>> >>>>>>> This is a request to the MEXT working group to adopt >>>>>>> >>>>>>> >>>> draft-larsson-mext-flow-distribution-rules to cover the charter >>>> item: >>>> >>>>>>> (A.3) Use of multiple interfaces. >>>>>>> ... >>>>>>> Deliverables >>>>>>> >>>> related to this include >>>> >>>>>>> - A "Flow/binding policies exchange" solution for >>>>>>> >>>> an exchange of >>>> >>>>>>> policies from the mobile host/router to the Home Agent and >>>>>>> >>>> from the >>>> >>>>>>> Home Agent to the mobile host/router influencing the choice of >>>>>>> >>>> the >>>> >>>>>>> Care-of Address and Home Agent address. The solution involves >>>>>>> >>>> two >>>> >>>>>>> specifications, one for the policy format and another for its >>>>>>> >>>>>>> >>>> transport [both Standard Track]. >>>> >>>>>>> The status of the working >>>>>>> >>>> group is that we have a draft >>>> (http://tools.ietf.org/html/draft-ietf-monami6-=20 >>>> multiplecoa-12) for >>>> registration of multiple care-of addresses to one home =20 >>>> address. >>>> >>>>>>> There >>>>>>> >>>> exist one draft >>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) =20= >>>> for >>>> transport >>>> >>>>>>> of the rules that decides how each flow is sent over the >>>>>>> >>>> available >>>> >>>>>>> network >>>>>>> interfaces. >>>>>>> >>>>>>> What is currently missing is >>>>>>> >>>> the part that defines the rules. >>>> draft-larsson-mext-flow-distribution-rules defines a rule =20 >>>> language that >>>> can >>>> >>>>>>> be used for this. The document can be found at: >>>>>>> >>>>>>> >>>>>>> >>>> = http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>> >>>>>>>> Please express your opinion on whether this should become a WG >>>>>>>> >>>> document. >>>> >>>>>>> Regards >>>>>>> Conny >>>>>>> >>>>>>> >>>>>>> >>>> _______________________________________________ >>>> >>>>>>> MEXT mailing list >>>>>>> >>>>>>> >>>> MEXT@ietf.org >>>> >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> >>>> >>> _______________________________________________ >>> MEXT mailing >>> >>>> list >>>> >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> >>> >> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From conny.larsson@ericsson.com Wed Apr 15 23:23:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671303A67B4 for ; Wed, 15 Apr 2009 23:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, 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 LwRJ7YBbNlHd for ; Wed, 15 Apr 2009 23:23:14 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 850943A6B70 for ; Wed, 15 Apr 2009 23:23:14 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DBD45211F3; Thu, 16 Apr 2009 08:24:25 +0200 (CEST) X-AuditID: c1b4fb3e-ac01fbb0000024d5-21-49e6cf19684d Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B5BAF20253; Thu, 16 Apr 2009 08:24:25 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 08:24:08 +0200 Received: from [127.0.0.1] ([147.214.130.137]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 08:24:08 +0200 Message-ID: <49E6CF07.2050907@ericsson.com> Date: Thu, 16 Apr 2009 08:24:07 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <49AEE6DD.5040006@it.uc3m.es> In-Reply-To: <49AEE6DD.5040006@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2009 06:24:08.0392 (UTC) FILETIME=[F2F08480:01C9BE5B] X-Brightmail-Tracker: AAAAAA== Cc: mext Subject: Re: [MEXT] Call for adoption of draft-premec-mext-extended-home-link X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 06:23:15 -0000 Hi Marcelo, A bit late, but if you are still counting I support adopting this Internet draft as a WG item Regards Conny marcelo bagnulo braun wrote: > Hi, > > This is call for adoption for draft-premec-mext-extended-home-link-00 > as WG item to cover the charter item: > > (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes > the home network to be dual stack providing simultaneous IPv6 and > IPv4 network access. It is proposed to extend DSMIPv6 to support > home networks which provides IPv4, or IPv6 respectively, direct > network access only, but where virtual IPv6 home network > connectivity, or virtual IPv4 home network connectivity > respectively, may be obtained by tunneling to the HA. The latter > shall be obtained by DSMIPv6 operation using the v4HoA address as > Care-of-address for the v6HoA address, and vice versa, the v6HoA > address as care-of-address for the v4HoA address. > > The document can be found at: > > http://tools.ietf.org/html/draft-premec-mext-extended-home-link-00 > > Please express your opinion on whether this should become a WG > document before the march 19 > > thanks, Julien and marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Thu Apr 16 09:04:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741AB3A6F8F for ; Thu, 16 Apr 2009 09:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[AWL=0.499, 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 4dRCR+fveA-a for ; Thu, 16 Apr 2009 09:04:55 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id E032F3A6F60 for ; Thu, 16 Apr 2009 09:04:54 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 528B6B9FEBB; Thu, 16 Apr 2009 18:06:06 +0200 (CEST) Message-ID: <49E7576E.9010200@it.uc3m.es> Date: Thu, 16 Apr 2009 18:06:06 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ryuji Wakikawa References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> <49E4BB6C.6030702@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16586.000 Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 16:04:56 -0000 now i am lost, i understood that we had two ways to dynamically confgure filters, binary and conny's draft and that's what we were discussing... didn't thought that it was static versus dynamic configuration of filters...so what is it? Ryuji Wakikawa escribió: > Hi Marcelo, > > When we have discussed flow management, there are two approaches (one > is flow binding). > The other approach is to install flow filters statically at the HA and > MN and switch them according to binding cache. > > Let's say MN and HA are statically configured with these three filters > set. According to binding cache database, > each node switch the filter. > > BID1 only -> filter1 > BID1 and BID2 -> filter2 > BID2 only -> filter3 > > Flow binding has advantages on dynamic updates, but, on the other > hand, some operators (let's say KDDI) prefer using > more stable filter. The operator ships the terminal with pre-defined > filter rules. The dynamic management leads certain overhead, too. > That' why we have this Conny's document. > AFAIK, this document does not specify any transport mechanism, but > define only syntax of filters. > > Of course, you might use SSL, HTTPs, even flow binding (as George > said), and any other mechanism to exchange these filters (if you want > dynamic filters exchange). > To define a general filter syntax is very useful. This can be > targetted to informational or experimental RFC. > > thanks > ryuji > > > On 2009/04/14, at 12:35, marcelo bagnulo braun wrote: > >> i wonder if we need the advanced features at this point >> I mean, we are just defining this, wouldn't make sense to wait and >> see if with the basic procedure is enough and do the extnesions >> later? Or is the basic mechanism so limited that is not enough to >> handle simple basic scenarios? If that is the case, does it makes >> sense to even define it? >> >> Bottom line, we need strong reasons to do things in multiple >> different ways. Unless clear reasons are described, i fail to see why >> we should standardize multiple approaches >> >> Regards, marcelo >> >> >> >> George Tsirtsis escribió: >>> Hi Marcelo, >>> >>> In the Monami6 days, the Flow Bindings draft used to include a binary >>> Flow Descriptor as part of the FID option. >>> This was basically a typical fixed length binary format defining a >>> classifier filterm including source and destination addresses, >>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>> forget something; both IPv4 and IPv6 can be supported with this. >>> >>> Some people, however, thought that more flexible FDs should be allowed >>> and Conny's draft describes a text based format which is clearly more >>> flexible but also more verbose. >>> >>> At the time, the WG decided that the FD format should be taken out of >>> the Flow Bindings draft. I am not sure I like that but this is indeed >>> what happened. >>> So, now the Flow Bindings draft allows for different FD formats, but >>> it does not define any of them. >>> >>> As a minimum, IMO the protocol should define one format as the default >>> that all implementations MUST support, so that we can have >>> interoperable implementations. >>> IMO this should be the binary format which is the most compact and >>> will work for most of the cases anyway. I do not care too much if this >>> is defined in the same or on a separate (albeit tightly coupled) >>> drafts. >>> >>> It is also ok with me to have other optional formats (like Conny's) >>> for more advanced use cases. >>> >>> I hope this helps >>> >>> George >>> >>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>> wrote: >>> >>>> George Tsirtsis escribió: >>>> >>>>> Hi Conny, >>>>> >>>>> Good to see you are resurrecting this draft. I think we need this as >>>>> one of the alternatives. We also need a binary version which I >>>>> will be >>>>> working on with others after I am done updating the Flow Bindings >>>>> draft. >>>>> >>>>> >>>> could you expand on this? >>>> I mean, are you saying that we need two ways of describing flows? >>>> >>>> Regards, marcelo >>>> >>>> >>>>> Thanks >>>>> George >>>>> >>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >>>>> wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> This is a request to the MEXT working group to adopt >>>>>> draft-larsson-mext-flow-distribution-rules to cover the charter >>>>>> item: >>>>>> >>>>>> (A.3) Use of multiple interfaces. >>>>>> ... >>>>>> Deliverables related to this include >>>>>> - A "Flow/binding policies exchange" solution for an exchange of >>>>>> policies from the mobile host/router to the Home Agent and from the >>>>>> Home Agent to the mobile host/router influencing the choice of the >>>>>> Care-of Address and Home Agent address. The solution involves two >>>>>> specifications, one for the policy format and another for its >>>>>> transport [both Standard Track]. >>>>>> >>>>>> >>>>>> The status of the working group is that we have a draft >>>>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>>>> registration of multiple care-of addresses to one home address. >>>>>> There exist one draft >>>>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>> transport >>>>>> of the rules that decides how each flow is sent over the available >>>>>> network >>>>>> interfaces. >>>>>> >>>>>> What is currently missing is the part that defines the rules. >>>>>> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>> language that >>>>>> can >>>>>> be used for this. The document can be found at: >>>>>> >>>>>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>>>> >>>>>> >>>>>> Please express your opinion on whether this should become a WG >>>>>> document. >>>>>> >>>>>> >>>>>> Regards >>>>>> Conny >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > From ryuji.wakikawa@gmail.com Thu Apr 16 11:03:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918283A6925 for ; Thu, 16 Apr 2009 11:03:15 -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 r8lVyS7MuI8f for ; Thu, 16 Apr 2009 11:03:14 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 69D7D3A6885 for ; Thu, 16 Apr 2009 11:03:14 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so529037wfg.31 for ; Thu, 16 Apr 2009 11:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=CGyOT11caDZFMXoFDay2f9k9auD7AeREpIBZmSEVEzU=; b=NEnjaZREBhjyp+G06Vq/x4W37exEdM61ldTcf9bvj+aw2HUAXhwsgpYXtrLSUBNrfU rZiatrPaKQgME4pUt5CpHwyh1AMFBE3JvoIlPO57/QAMH+H0rtIPnFeAgkNy8ut3bdvH TlAcxsJ4o4ebNtWM6W6gGAlxw1iOIs3JUHLR0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=BTpSy9WZn3DcnA2fc+gAIop6piKWm1Rxu//JhjnhnVSThrTOWNLFORQkrmg/gfUMTz 5MGwhofeYHyvL6X/aqPtxcMkb4wz3ZGYYtjzfXZQp8/EprcxL+xhtC9CDOAD5Peb6WsY hWEp3URCNA2vjkGrIcIkmskEg1kzBqESRO/Ag= Received: by 10.142.51.4 with SMTP id y4mr2622861wfy.303.1239905067591; Thu, 16 Apr 2009 11:04:27 -0700 (PDT) Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id 30sm3710815wfd.29.2009.04.16.11.04.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Apr 2009 11:04:26 -0700 (PDT) From: Ryuji Wakikawa To: marcelo bagnulo braun In-Reply-To: <49E7576E.9010200@it.uc3m.es> References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> <49E4BB6C.6030702@it.uc3m.es> <49E7576E.9010200@it.uc3m.es> Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 14:04:23 -0400 X-Mailer: Apple Mail (2.930.3) Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 18:03:15 -0000 Hi Marcelo, Well, you are not lost, but I was actually lost. After reading the spec, they changed the draft a lot since I =20 contributed to.. I asked Tasaka (KDDI guy) to explain the position of this draft. thanks ryuji On 2009/04/16, at 12:06, marcelo bagnulo braun wrote: > now i am lost, i understood that we had two ways to dynamically =20 > confgure filters, binary and conny's draft and that's what we were =20 > discussing... didn't thought that it was static versus dynamic =20 > configuration of filters...so what is it? > > > Ryuji Wakikawa escribi=C3=B3: >> Hi Marcelo, >> >> When we have discussed flow management, there are two approaches =20 >> (one is flow binding). >> The other approach is to install flow filters statically at the HA =20= >> and MN and switch them according to binding cache. >> >> Let's say MN and HA are statically configured with these three =20 >> filters set. According to binding cache database, >> each node switch the filter. >> >> BID1 only -> filter1 >> BID1 and BID2 -> filter2 >> BID2 only -> filter3 >> >> Flow binding has advantages on dynamic updates, but, on the other =20 >> hand, some operators (let's say KDDI) prefer using >> more stable filter. The operator ships the terminal with pre-=20 >> defined filter rules. The dynamic management leads certain =20 >> overhead, too. >> That' why we have this Conny's document. >> AFAIK, this document does not specify any transport mechanism, but =20= >> define only syntax of filters. >> >> Of course, you might use SSL, HTTPs, even flow binding (as George =20 >> said), and any other mechanism to exchange these filters (if you =20 >> want dynamic filters exchange). >> To define a general filter syntax is very useful. This can be =20 >> targetted to informational or experimental RFC. >> >> thanks >> ryuji >> >> >> On 2009/04/14, at 12:35, marcelo bagnulo braun wrote: >> >>> i wonder if we need the advanced features at this point >>> I mean, we are just defining this, wouldn't make sense to wait and =20= >>> see if with the basic procedure is enough and do the extnesions =20 >>> later? Or is the basic mechanism so limited that is not enough to =20= >>> handle simple basic scenarios? If that is the case, does it makes =20= >>> sense to even define it? >>> >>> Bottom line, we need strong reasons to do things in multiple =20 >>> different ways. Unless clear reasons are described, i fail to see =20= >>> why we should standardize multiple approaches >>> >>> Regards, marcelo >>> >>> >>> >>> George Tsirtsis escribi=C3=B3: >>>> Hi Marcelo, >>>> >>>> In the Monami6 days, the Flow Bindings draft used to include a =20 >>>> binary >>>> Flow Descriptor as part of the FID option. >>>> This was basically a typical fixed length binary format defining a >>>> classifier filterm including source and destination addresses, >>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>> forget something; both IPv4 and IPv6 can be supported with this. >>>> >>>> Some people, however, thought that more flexible FDs should be =20 >>>> allowed >>>> and Conny's draft describes a text based format which is clearly =20= >>>> more >>>> flexible but also more verbose. >>>> >>>> At the time, the WG decided that the FD format should be taken =20 >>>> out of >>>> the Flow Bindings draft. I am not sure I like that but this is =20 >>>> indeed >>>> what happened. >>>> So, now the Flow Bindings draft allows for different FD formats, =20= >>>> but >>>> it does not define any of them. >>>> >>>> As a minimum, IMO the protocol should define one format as the =20 >>>> default >>>> that all implementations MUST support, so that we can have >>>> interoperable implementations. >>>> IMO this should be the binary format which is the most compact and >>>> will work for most of the cases anyway. I do not care too much if =20= >>>> this >>>> is defined in the same or on a separate (albeit tightly coupled) >>>> drafts. >>>> >>>> It is also ok with me to have other optional formats (like Conny's) >>>> for more advanced use cases. >>>> >>>> I hope this helps >>>> >>>> George >>>> >>>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun = >>> > wrote: >>>> >>>>> George Tsirtsis escribi=C3=B3: >>>>> >>>>>> Hi Conny, >>>>>> >>>>>> Good to see you are resurrecting this draft. I think we need =20 >>>>>> this as >>>>>> one of the alternatives. We also need a binary version which I =20= >>>>>> will be >>>>>> working on with others after I am done updating the Flow Bindings >>>>>> draft. >>>>>> >>>>>> >>>>> could you expand on this? >>>>> I mean, are you saying that we need two ways of describing flows? >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>>> Thanks >>>>>> George >>>>>> >>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >>>>>> wrote: >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This is a request to the MEXT working group to adopt >>>>>>> draft-larsson-mext-flow-distribution-rules to cover the =20 >>>>>>> charter item: >>>>>>> >>>>>>> (A.3) Use of multiple interfaces. >>>>>>> ... >>>>>>> Deliverables related to this include >>>>>>> - A "Flow/binding policies exchange" solution for an exchange of >>>>>>> policies from the mobile host/router to the Home Agent and =20 >>>>>>> from the >>>>>>> Home Agent to the mobile host/router influencing the choice of =20= >>>>>>> the >>>>>>> Care-of Address and Home Agent address. The solution involves =20= >>>>>>> two >>>>>>> specifications, one for the policy format and another for its >>>>>>> transport [both Standard Track]. >>>>>>> >>>>>>> >>>>>>> The status of the working group is that we have a draft >>>>>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) =20= >>>>>>> for >>>>>>> registration of multiple care-of addresses to one home address. >>>>>>> There exist one draft >>>>>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>>> transport >>>>>>> of the rules that decides how each flow is sent over the =20 >>>>>>> available >>>>>>> network >>>>>>> interfaces. >>>>>>> >>>>>>> What is currently missing is the part that defines the rules. >>>>>>> draft-larsson-mext-flow-distribution-rules defines a rule =20 >>>>>>> language that >>>>>>> can >>>>>>> be used for this. The document can be found at: >>>>>>> >>>>>>> = http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>>>>> >>>>>>> Please express your opinion on whether this should become a WG =20= >>>>>>> document. >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Conny >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> > From ka-tasaka@kddilabs.jp Thu Apr 16 12:06:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FBE43A69F7 for ; Thu, 16 Apr 2009 12:06:06 -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 iTvVdD50V-Qs for ; Thu, 16 Apr 2009 12:06:04 -0700 (PDT) Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id 277D83A6934 for ; Thu, 16 Apr 2009 12:05:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id C5396EC870; Fri, 17 Apr 2009 04:06:45 +0900 (JST) Received: from spears.ast.kddilabs.jp (unknown [2001:200:601:800::168]) by mandala.kddilabs.jp (Postfix) with ESMTP id 8C06AEC82F; Fri, 17 Apr 2009 04:06:44 +0900 (JST) Received: from [127.0.0.1] (ova158.vpn.kddilabs.jp [172.19.112.158]) by spears.ast.kddilabs.jp (Postfix) with ESMTP id 7BF89690541; Fri, 17 Apr 2009 04:06:43 +0900 (JST) Message-ID: <49E781C0.7070900@kddilabs.jp> Date: Fri, 17 Apr 2009 04:06:40 +0900 From: Kazuyuki Tasaka User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun , Ryuji Wakikawa References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> <49E4BB6C.6030702@it.uc3m.es> <49E7576E.9010200@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:06:06 -0000 Hi Marcelo and Ryuji, Conny's document only defines generic rule language as a mean to define and perform per flow path selection for a multi-homed node. I think this document can provide static and dynamic configuration of filters. Flow filters are installed statically at the HA and MN. On the other hands, in case of dynamic configuration, this document depends on the transport protocol (e.g. flow bindings) to exchange flow filters with other nodes . But the transport protocol is outside the scope of this document and generic rule languages to statically and dynamically configure are difined. Regards, tasaka. Ryuji Wakikawa Wrote: > Hi Marcelo, >=20 > Well, you are not lost, but I was actually lost. > After reading the spec, they changed the draft a lot since I contribute= d=20 > to.. > I asked Tasaka (KDDI guy) to explain the position of this draft. >=20 > thanks > ryuji >=20 > On 2009/04/16, at 12:06, marcelo bagnulo braun wrote: >=20 >> now i am lost, i understood that we had two ways to dynamically=20 >> confgure filters, binary and conny's draft and that's what we were=20 >> discussing... didn't thought that it was static versus dynamic=20 >> configuration of filters...so what is it? >> >> >> Ryuji Wakikawa escribi=C3=B3: >>> Hi Marcelo, >>> >>> When we have discussed flow management, there are two approaches (one= =20 >>> is flow binding). >>> The other approach is to install flow filters statically at the HA=20 >>> and MN and switch them according to binding cache. >>> >>> Let's say MN and HA are statically configured with these three=20 >>> filters set. According to binding cache database, >>> each node switch the filter. >>> >>> BID1 only -> filter1 >>> BID1 and BID2 -> filter2 >>> BID2 only -> filter3 >>> >>> Flow binding has advantages on dynamic updates, but, on the other=20 >>> hand, some operators (let's say KDDI) prefer using >>> more stable filter. The operator ships the terminal with pre-defined=20 >>> filter rules. The dynamic management leads certain overhead, too. >>> That' why we have this Conny's document. >>> AFAIK, this document does not specify any transport mechanism, but=20 >>> define only syntax of filters. >>> >>> Of course, you might use SSL, HTTPs, even flow binding (as George=20 >>> said), and any other mechanism to exchange these filters (if you want= =20 >>> dynamic filters exchange). >>> To define a general filter syntax is very useful. This can be=20 >>> targetted to informational or experimental RFC. >>> >>> thanks >>> ryuji >>> >>> >>> On 2009/04/14, at 12:35, marcelo bagnulo braun wrote: >>> >>>> i wonder if we need the advanced features at this point >>>> I mean, we are just defining this, wouldn't make sense to wait and=20 >>>> see if with the basic procedure is enough and do the extnesions=20 >>>> later? Or is the basic mechanism so limited that is not enough to=20 >>>> handle simple basic scenarios? If that is the case, does it makes=20 >>>> sense to even define it? >>>> >>>> Bottom line, we need strong reasons to do things in multiple=20 >>>> different ways. Unless clear reasons are described, i fail to see=20 >>>> why we should standardize multiple approaches >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> George Tsirtsis escribi=C3=B3: >>>>> Hi Marcelo, >>>>> >>>>> In the Monami6 days, the Flow Bindings draft used to include a bina= ry >>>>> Flow Descriptor as part of the FID option. >>>>> This was basically a typical fixed length binary format defining a >>>>> classifier filterm including source and destination addresses, >>>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>>> forget something; both IPv4 and IPv6 can be supported with this. >>>>> >>>>> Some people, however, thought that more flexible FDs should be allo= wed >>>>> and Conny's draft describes a text based format which is clearly mo= re >>>>> flexible but also more verbose. >>>>> >>>>> At the time, the WG decided that the FD format should be taken out = of >>>>> the Flow Bindings draft. I am not sure I like that but this is inde= ed >>>>> what happened. >>>>> So, now the Flow Bindings draft allows for different FD formats, bu= t >>>>> it does not define any of them. >>>>> >>>>> As a minimum, IMO the protocol should define one format as the defa= ult >>>>> that all implementations MUST support, so that we can have >>>>> interoperable implementations. >>>>> IMO this should be the binary format which is the most compact and >>>>> will work for most of the cases anyway. I do not care too much if t= his >>>>> is defined in the same or on a separate (albeit tightly coupled) >>>>> drafts. >>>>> >>>>> It is also ok with me to have other optional formats (like Conny's) >>>>> for more advanced use cases. >>>>> >>>>> I hope this helps >>>>> >>>>> George >>>>> >>>>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun=20 >>>>> wrote: >>>>> >>>>>> George Tsirtsis escribi=C3=B3: >>>>>> >>>>>>> Hi Conny, >>>>>>> >>>>>>> Good to see you are resurrecting this draft. I think we need this= as >>>>>>> one of the alternatives. We also need a binary version which I=20 >>>>>>> will be >>>>>>> working on with others after I am done updating the Flow Bindings >>>>>>> draft. >>>>>>> >>>>>>> >>>>>> could you expand on this? >>>>>> I mean, are you saying that we need two ways of describing flows? >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>>> Thanks >>>>>>> George >>>>>>> >>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> This is a request to the MEXT working group to adopt >>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the charter=20 >>>>>>>> item: >>>>>>>> >>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>> ... >>>>>>>> Deliverables related to this include >>>>>>>> - A "Flow/binding policies exchange" solution for an exchange of >>>>>>>> policies from the mobile host/router to the Home Agent and from = the >>>>>>>> Home Agent to the mobile host/router influencing the choice of t= he >>>>>>>> Care-of Address and Home Agent address. The solution involves tw= o >>>>>>>> specifications, one for the policy format and another for its >>>>>>>> transport [both Standard Track]. >>>>>>>> >>>>>>>> >>>>>>>> The status of the working group is that we have a draft >>>>>>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) f= or >>>>>>>> registration of multiple care-of addresses to one home address. >>>>>>>> There exist one draft >>>>>>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>>>> transport >>>>>>>> of the rules that decides how each flow is sent over the availab= le >>>>>>>> network >>>>>>>> interfaces. >>>>>>>> >>>>>>>> What is currently missing is the part that defines the rules. >>>>>>>> draft-larsson-mext-flow-distribution-rules defines a rule=20 >>>>>>>> language that >>>>>>>> can >>>>>>>> be used for this. The document can be found at: >>>>>>>> >>>>>>>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-= rules-02=20 >>>>>>>> >>>>>>>> >>>>>>>> Please express your opinion on whether this should become a WG=20 >>>>>>>> document. >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> Conny >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Thu Apr 16 12:17:49 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C5BF3A6E06 for ; Thu, 16 Apr 2009 12:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[AWL=3.817, 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 t8KK2asA4Z4z for ; Thu, 16 Apr 2009 12:17:48 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id CE4723A6D9C for ; Thu, 16 Apr 2009 12:17:47 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (29.pool85-59-200.dynamic.orange.es [85.59.200.29]) by smtp03.uc3m.es (Postfix) with ESMTP id BC214732B49; Thu, 16 Apr 2009 21:18:58 +0200 (CEST) Message-ID: <49E784A2.6080000@it.uc3m.es> Date: Thu, 16 Apr 2009 21:18:58 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Kazuyuki Tasaka References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> <49E4BB6C.6030702@it.uc3m.es> <49E7576E.9010200@it.uc3m.es> <49E781C0.7070900@kddilabs.jp> In-Reply-To: <49E781C0.7070900@kddilabs.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16586.001 Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:17:49 -0000 Right, i understand that the transport of these rules is done using draft-ietf-mext-flow-binding, right? so what we need to agree next is what encoding we use to specify a flow, either the one or larson draft or the binary encoding (or maybe both, but strong reasons would be needed for that imho) Kazuyuki Tasaka escribió: > Hi Marcelo and Ryuji, > > Conny's document only defines generic rule language as a mean to > define and perform per flow path selection for a multi-homed node. > I think this document can provide static and dynamic configuration of > filters. > Flow filters are installed statically at the HA and MN. On the other > hands, in case of dynamic configuration, this document depends on > the transport protocol (e.g. flow bindings) to exchange flow filters > with other nodes . But the transport protocol is outside the scope of > this document and generic rule languages to statically and dynamically > configure are difined. > > Regards, tasaka. > > Ryuji Wakikawa Wrote: >> Hi Marcelo, >> >> Well, you are not lost, but I was actually lost. >> After reading the spec, they changed the draft a lot since I >> contributed to.. >> I asked Tasaka (KDDI guy) to explain the position of this draft. >> >> thanks >> ryuji >> >> On 2009/04/16, at 12:06, marcelo bagnulo braun wrote: >> >>> now i am lost, i understood that we had two ways to dynamically >>> confgure filters, binary and conny's draft and that's what we were >>> discussing... didn't thought that it was static versus dynamic >>> configuration of filters...so what is it? >>> >>> >>> Ryuji Wakikawa escribió: >>>> Hi Marcelo, >>>> >>>> When we have discussed flow management, there are two approaches >>>> (one is flow binding). >>>> The other approach is to install flow filters statically at the HA >>>> and MN and switch them according to binding cache. >>>> >>>> Let's say MN and HA are statically configured with these three >>>> filters set. According to binding cache database, >>>> each node switch the filter. >>>> >>>> BID1 only -> filter1 >>>> BID1 and BID2 -> filter2 >>>> BID2 only -> filter3 >>>> >>>> Flow binding has advantages on dynamic updates, but, on the other >>>> hand, some operators (let's say KDDI) prefer using >>>> more stable filter. The operator ships the terminal with >>>> pre-defined filter rules. The dynamic management leads certain >>>> overhead, too. >>>> That' why we have this Conny's document. >>>> AFAIK, this document does not specify any transport mechanism, but >>>> define only syntax of filters. >>>> >>>> Of course, you might use SSL, HTTPs, even flow binding (as George >>>> said), and any other mechanism to exchange these filters (if you >>>> want dynamic filters exchange). >>>> To define a general filter syntax is very useful. This can be >>>> targetted to informational or experimental RFC. >>>> >>>> thanks >>>> ryuji >>>> >>>> >>>> On 2009/04/14, at 12:35, marcelo bagnulo braun wrote: >>>> >>>>> i wonder if we need the advanced features at this point >>>>> I mean, we are just defining this, wouldn't make sense to wait and >>>>> see if with the basic procedure is enough and do the extnesions >>>>> later? Or is the basic mechanism so limited that is not enough to >>>>> handle simple basic scenarios? If that is the case, does it makes >>>>> sense to even define it? >>>>> >>>>> Bottom line, we need strong reasons to do things in multiple >>>>> different ways. Unless clear reasons are described, i fail to see >>>>> why we should standardize multiple approaches >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> >>>>> George Tsirtsis escribió: >>>>>> Hi Marcelo, >>>>>> >>>>>> In the Monami6 days, the Flow Bindings draft used to include a >>>>>> binary >>>>>> Flow Descriptor as part of the FID option. >>>>>> This was basically a typical fixed length binary format defining a >>>>>> classifier filterm including source and destination addresses, >>>>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>>>> forget something; both IPv4 and IPv6 can be supported with this. >>>>>> >>>>>> Some people, however, thought that more flexible FDs should be >>>>>> allowed >>>>>> and Conny's draft describes a text based format which is clearly >>>>>> more >>>>>> flexible but also more verbose. >>>>>> >>>>>> At the time, the WG decided that the FD format should be taken >>>>>> out of >>>>>> the Flow Bindings draft. I am not sure I like that but this is >>>>>> indeed >>>>>> what happened. >>>>>> So, now the Flow Bindings draft allows for different FD formats, but >>>>>> it does not define any of them. >>>>>> >>>>>> As a minimum, IMO the protocol should define one format as the >>>>>> default >>>>>> that all implementations MUST support, so that we can have >>>>>> interoperable implementations. >>>>>> IMO this should be the binary format which is the most compact and >>>>>> will work for most of the cases anyway. I do not care too much if >>>>>> this >>>>>> is defined in the same or on a separate (albeit tightly coupled) >>>>>> drafts. >>>>>> >>>>>> It is also ok with me to have other optional formats (like Conny's) >>>>>> for more advanced use cases. >>>>>> >>>>>> I hope this helps >>>>>> >>>>>> George >>>>>> >>>>>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>>> wrote: >>>>>> >>>>>>> George Tsirtsis escribió: >>>>>>> >>>>>>>> Hi Conny, >>>>>>>> >>>>>>>> Good to see you are resurrecting this draft. I think we need >>>>>>>> this as >>>>>>>> one of the alternatives. We also need a binary version which I >>>>>>>> will be >>>>>>>> working on with others after I am done updating the Flow Bindings >>>>>>>> draft. >>>>>>>> >>>>>>>> >>>>>>> could you expand on this? >>>>>>> I mean, are you saying that we need two ways of describing flows? >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>>> Thanks >>>>>>>> George >>>>>>>> >>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> This is a request to the MEXT working group to adopt >>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the >>>>>>>>> charter item: >>>>>>>>> >>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>> ... >>>>>>>>> Deliverables related to this include >>>>>>>>> - A "Flow/binding policies exchange" solution for an exchange of >>>>>>>>> policies from the mobile host/router to the Home Agent and >>>>>>>>> from the >>>>>>>>> Home Agent to the mobile host/router influencing the choice of >>>>>>>>> the >>>>>>>>> Care-of Address and Home Agent address. The solution involves two >>>>>>>>> specifications, one for the policy format and another for its >>>>>>>>> transport [both Standard Track]. >>>>>>>>> >>>>>>>>> >>>>>>>>> The status of the working group is that we have a draft >>>>>>>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) >>>>>>>>> for >>>>>>>>> registration of multiple care-of addresses to one home address. >>>>>>>>> There exist one draft >>>>>>>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>>>>> transport >>>>>>>>> of the rules that decides how each flow is sent over the >>>>>>>>> available >>>>>>>>> network >>>>>>>>> interfaces. >>>>>>>>> >>>>>>>>> What is currently missing is the part that defines the rules. >>>>>>>>> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>>> language that >>>>>>>>> can >>>>>>>>> be used for this. The document can be found at: >>>>>>>>> >>>>>>>>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>>>>>>> >>>>>>>>> >>>>>>>>> Please express your opinion on whether this should become a WG >>>>>>>>> document. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Conny >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > From ryuji.wakikawa@gmail.com Thu Apr 16 12:25:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728BD28C14F for ; Thu, 16 Apr 2009 12:25: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 bLmCReDm-Mmp for ; Thu, 16 Apr 2009 12:25:05 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 6D93328C19F for ; Thu, 16 Apr 2009 12:25:04 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so560716wfg.31 for ; Thu, 16 Apr 2009 12:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=rCOGRK1ctTdV+u6eavOWMRSQ6CBPQdSTYMQrvMU9fdY=; b=v0PFHBcsHj4b4+OJVdl7TPV1X1aqYxDuQaN3cLLoxOMZvL1y7dGT0O7syvCALveGzi H7KQX6+GFXTYx2kgATqZ2O4epR+AlBchd/fQhn6/BVgxPoGtMHAMvvTU5NPF6+ORe/wz WwblY6+csKPBt8hyGgA1DPzRWDXXfXXWIDmo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=Uk71oQBgKf2/EJco9gc/qgeLbxQ7Zg9zuIFqxzMyW2+WHjvj49SecoOaHd9NLez94H Nhi8lYElCbu1BdIzE4juH+vJ8mxWswVFfe0OsqFyLqWxsjDUY+wGRn+AcEMAsH/JCb76 PK292t/YwhUs2DZImK3lbUzmrIHc5eJgCF7WA= Received: by 10.142.192.1 with SMTP id p1mr2756401wff.316.1239909977428; Thu, 16 Apr 2009 12:26:17 -0700 (PDT) Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id 22sm4384400wfi.21.2009.04.16.12.26.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Apr 2009 12:26:16 -0700 (PDT) From: Ryuji Wakikawa To: marcelo bagnulo braun In-Reply-To: <49E784A2.6080000@it.uc3m.es> References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> <49E4BB6C.6030702@it.uc3m.es> <49E7576E.9010200@it.uc3m.es> <49E781C0.7070900@kddilabs.jp> <49E784A2.6080000@it.uc3m.es> Message-Id: <5CB005C7-4196-4025-AFC6-452302679F99@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 15:26:12 -0400 X-Mailer: Apple Mail (2.930.3) Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:25:07 -0000 Hi Marcelo and Tasaka, On 2009/04/16, at 15:18, marcelo bagnulo braun wrote: > Right, i understand that the transport of these rules is done using =20= > draft-ietf-mext-flow-binding, right? The flow binding is just one of transport protocol to carry the rules. This document deals with rules syntax and is independent from the flow =20= binding. Anyone can pick any transport protocol to exchange these rules or can =20= install the filters with out any dynamic exchange. regards, ryuji > so what we need to agree next is what encoding we use to specify a =20 > flow, either the one or larson draft or the binary encoding (or =20 > maybe both, but strong reasons would be needed for that imho) > > > Kazuyuki Tasaka escribi=C3=B3: >> Hi Marcelo and Ryuji, >> >> Conny's document only defines generic rule language as a mean to >> define and perform per flow path selection for a multi-homed node. >> I think this document can provide static and dynamic configuration of >> filters. >> Flow filters are installed statically at the HA and MN. On the other >> hands, in case of dynamic configuration, this document depends on >> the transport protocol (e.g. flow bindings) to exchange flow filters >> with other nodes . But the transport protocol is outside the scope of >> this document and generic rule languages to statically and =20 >> dynamically >> configure are difined. >> >> Regards, tasaka. >> >> Ryuji Wakikawa Wrote: >>> Hi Marcelo, >>> >>> Well, you are not lost, but I was actually lost. >>> After reading the spec, they changed the draft a lot since I =20 >>> contributed to.. >>> I asked Tasaka (KDDI guy) to explain the position of this draft. >>> >>> thanks >>> ryuji >>> >>> On 2009/04/16, at 12:06, marcelo bagnulo braun wrote: >>> >>>> now i am lost, i understood that we had two ways to dynamically =20 >>>> confgure filters, binary and conny's draft and that's what we =20 >>>> were discussing... didn't thought that it was static versus =20 >>>> dynamic configuration of filters...so what is it? >>>> >>>> >>>> Ryuji Wakikawa escribi=C3=B3: >>>>> Hi Marcelo, >>>>> >>>>> When we have discussed flow management, there are two approaches =20= >>>>> (one is flow binding). >>>>> The other approach is to install flow filters statically at the =20= >>>>> HA and MN and switch them according to binding cache. >>>>> >>>>> Let's say MN and HA are statically configured with these three =20 >>>>> filters set. According to binding cache database, >>>>> each node switch the filter. >>>>> >>>>> BID1 only -> filter1 >>>>> BID1 and BID2 -> filter2 >>>>> BID2 only -> filter3 >>>>> >>>>> Flow binding has advantages on dynamic updates, but, on the =20 >>>>> other hand, some operators (let's say KDDI) prefer using >>>>> more stable filter. The operator ships the terminal with pre-=20 >>>>> defined filter rules. The dynamic management leads certain =20 >>>>> overhead, too. >>>>> That' why we have this Conny's document. >>>>> AFAIK, this document does not specify any transport mechanism, =20 >>>>> but define only syntax of filters. >>>>> >>>>> Of course, you might use SSL, HTTPs, even flow binding (as =20 >>>>> George said), and any other mechanism to exchange these filters =20= >>>>> (if you want dynamic filters exchange). >>>>> To define a general filter syntax is very useful. This can be =20 >>>>> targetted to informational or experimental RFC. >>>>> >>>>> thanks >>>>> ryuji >>>>> >>>>> >>>>> On 2009/04/14, at 12:35, marcelo bagnulo braun wrote: >>>>> >>>>>> i wonder if we need the advanced features at this point >>>>>> I mean, we are just defining this, wouldn't make sense to wait =20= >>>>>> and see if with the basic procedure is enough and do the =20 >>>>>> extnesions later? Or is the basic mechanism so limited that is =20= >>>>>> not enough to handle simple basic scenarios? If that is the =20 >>>>>> case, does it makes sense to even define it? >>>>>> >>>>>> Bottom line, we need strong reasons to do things in multiple =20 >>>>>> different ways. Unless clear reasons are described, i fail to =20 >>>>>> see why we should standardize multiple approaches >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> >>>>>> George Tsirtsis escribi=C3=B3: >>>>>>> Hi Marcelo, >>>>>>> >>>>>>> In the Monami6 days, the Flow Bindings draft used to include a =20= >>>>>>> binary >>>>>>> Flow Descriptor as part of the FID option. >>>>>>> This was basically a typical fixed length binary format =20 >>>>>>> defining a >>>>>>> classifier filterm including source and destination addresses, >>>>>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do =20= >>>>>>> not >>>>>>> forget something; both IPv4 and IPv6 can be supported with this. >>>>>>> >>>>>>> Some people, however, thought that more flexible FDs should be =20= >>>>>>> allowed >>>>>>> and Conny's draft describes a text based format which is =20 >>>>>>> clearly more >>>>>>> flexible but also more verbose. >>>>>>> >>>>>>> At the time, the WG decided that the FD format should be taken =20= >>>>>>> out of >>>>>>> the Flow Bindings draft. I am not sure I like that but this is =20= >>>>>>> indeed >>>>>>> what happened. >>>>>>> So, now the Flow Bindings draft allows for different FD =20 >>>>>>> formats, but >>>>>>> it does not define any of them. >>>>>>> >>>>>>> As a minimum, IMO the protocol should define one format as the =20= >>>>>>> default >>>>>>> that all implementations MUST support, so that we can have >>>>>>> interoperable implementations. >>>>>>> IMO this should be the binary format which is the most compact =20= >>>>>>> and >>>>>>> will work for most of the cases anyway. I do not care too much =20= >>>>>>> if this >>>>>>> is defined in the same or on a separate (albeit tightly coupled) >>>>>>> drafts. >>>>>>> >>>>>>> It is also ok with me to have other optional formats (like =20 >>>>>>> Conny's) >>>>>>> for more advanced use cases. >>>>>>> >>>>>>> I hope this helps >>>>>>> >>>>>>> George >>>>>>> >>>>>>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun = >>>>>> > wrote: >>>>>>> >>>>>>>> George Tsirtsis escribi=C3=B3: >>>>>>>> >>>>>>>>> Hi Conny, >>>>>>>>> >>>>>>>>> Good to see you are resurrecting this draft. I think we need =20= >>>>>>>>> this as >>>>>>>>> one of the alternatives. We also need a binary version which =20= >>>>>>>>> I will be >>>>>>>>> working on with others after I am done updating the Flow =20 >>>>>>>>> Bindings >>>>>>>>> draft. >>>>>>>>> >>>>>>>>> >>>>>>>> could you expand on this? >>>>>>>> I mean, are you saying that we need two ways of describing =20 >>>>>>>> flows? >>>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>>> Thanks >>>>>>>>> George >>>>>>>>> >>>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> This is a request to the MEXT working group to adopt >>>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the =20 >>>>>>>>>> charter item: >>>>>>>>>> >>>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>>> ... >>>>>>>>>> Deliverables related to this include >>>>>>>>>> - A "Flow/binding policies exchange" solution for an =20 >>>>>>>>>> exchange of >>>>>>>>>> policies from the mobile host/router to the Home Agent and =20= >>>>>>>>>> from the >>>>>>>>>> Home Agent to the mobile host/router influencing the choice =20= >>>>>>>>>> of the >>>>>>>>>> Care-of Address and Home Agent address. The solution =20 >>>>>>>>>> involves two >>>>>>>>>> specifications, one for the policy format and another for its >>>>>>>>>> transport [both Standard Track]. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The status of the working group is that we have a draft >>>>>>>>>> (http://tools.ietf.org/html/draft-ietf-monami6-=20 >>>>>>>>>> multiplecoa-12) for >>>>>>>>>> registration of multiple care-of addresses to one home =20 >>>>>>>>>> address. >>>>>>>>>> There exist one draft >>>>>>>>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-=20 >>>>>>>>>> binding-01) for >>>>>>>>>> transport >>>>>>>>>> of the rules that decides how each flow is sent over the =20 >>>>>>>>>> available >>>>>>>>>> network >>>>>>>>>> interfaces. >>>>>>>>>> >>>>>>>>>> What is currently missing is the part that defines the rules. >>>>>>>>>> draft-larsson-mext-flow-distribution-rules defines a rule =20 >>>>>>>>>> language that >>>>>>>>>> can >>>>>>>>>> be used for this. The document can be found at: >>>>>>>>>> >>>>>>>>>> = http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>>>>>>>> >>>>>>>>>> Please express your opinion on whether this should become a =20= >>>>>>>>>> WG document. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Conny >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> >> > From tsirtsis@googlemail.com Thu Apr 16 12:32:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B223A689B for ; Thu, 16 Apr 2009 12:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.839 X-Spam-Level: X-Spam-Status: No, score=-1.839 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 t6jAfVgtlX7K for ; Thu, 16 Apr 2009 12:32:03 -0700 (PDT) Received: from mail-gx0-f160.google.com (mail-gx0-f160.google.com [209.85.217.160]) by core3.amsl.com (Postfix) with ESMTP id 8F45F3A6B44 for ; Thu, 16 Apr 2009 12:32:03 -0700 (PDT) Received: by gxk4 with SMTP id 4so1348920gxk.13 for ; Thu, 16 Apr 2009 12:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=SUqvR7wXbvHR/75p7k4B1py9/z5TLU+vf37HCjrHJYA=; b=cJBq1raMRXWMKgWO4ovH2bCBkDludY3Pu7u5g8NllLCOWDtfLeR7egBklyc5E7R7ac K5yi6loT4lD0256Gc5+L66dqj6IlSgHv7KIe7hjF15g5q0mRewymCHaxXKY2iNNWwZMv x0G6mRBB9HFiBYSQLv77vlVyY7TIuYwpVdjng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sb9QQ2RZfXCVclqEpk/Mlr6YoBrTKTXmxxyXyRbFb++Add1sVFCQFBr7fea5Kl+I5h GaLvN0W/mQ0xkzj019VemuX4XoA03Fme8uExXsZY+9O3Q5gSuYUhAg8k0LzpLu3uw7yZ sqp7LEIqcxdkr9FEVdpV9qc6mXWA3c1avp48w= MIME-Version: 1.0 Received: by 10.90.53.5 with SMTP id b5mr316984aga.24.1239910395526; Thu, 16 Apr 2009 12:33:15 -0700 (PDT) In-Reply-To: <5CB005C7-4196-4025-AFC6-452302679F99@gmail.com> References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> <49E4BB6C.6030702@it.uc3m.es> <49E7576E.9010200@it.uc3m.es> <49E781C0.7070900@kddilabs.jp> <49E784A2.6080000@it.uc3m.es> <5CB005C7-4196-4025-AFC6-452302679F99@gmail.com> Date: Thu, 16 Apr 2009 20:33:15 +0100 Message-ID: From: George Tsirtsis To: Ryuji Wakikawa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:32:05 -0000 Ryuji, I know we have been saying this for a while now but I am not sure to what extend it holds water. If you want an out of band mechanism for controlling filters in a box there are specific protocols for that kind of thing e.g., MIDCOM, and they define the whole thing, including encoding and transport. As I said before, I am not against having multiple flow description necodings for Flow Bindings, but the generality argument is a bit of a stretch IMHO. Regards George On Thu, Apr 16, 2009 at 8:26 PM, Ryuji Wakikawa wrote: > Hi Marcelo and Tasaka, > > On 2009/04/16, at 15:18, marcelo bagnulo braun wrote: > >> Right, i understand that the transport of these rules is done using >> draft-ietf-mext-flow-binding, right? > > The flow binding is just one of transport protocol to carry the rules. > > This document deals with rules syntax and is independent from the flow > binding. > Anyone can pick any transport protocol to exchange these rules or can > install the filters with out any dynamic exchange. > > regards, > ryuji > >> so what we need to agree next is what encoding we use to specify a flow, >> either the one or larson draft or the binary encoding (or maybe both, bu= t >> strong reasons would be needed for that imho) >> >> >> Kazuyuki Tasaka escribi=C3=B3: >>> >>> Hi Marcelo and Ryuji, >>> >>> Conny's document only defines generic rule language as a mean to >>> define and perform per flow path selection for a multi-homed node. >>> I think this document can provide static and dynamic configuration of >>> filters. >>> Flow filters are installed statically at the HA and MN. On the other >>> hands, in case of dynamic configuration, this document depends on >>> the transport protocol (e.g. flow bindings) to exchange flow filters >>> with other nodes . But the transport protocol is outside the scope of >>> this document and generic rule languages to statically and dynamically >>> configure are difined. >>> >>> Regards, tasaka. >>> >>> Ryuji Wakikawa Wrote: >>>> >>>> Hi Marcelo, >>>> >>>> Well, you are not lost, but I was actually lost. >>>> After reading the spec, they changed the draft a lot since I contribut= ed >>>> to.. >>>> I asked Tasaka (KDDI guy) to explain the position of this draft. >>>> >>>> thanks >>>> ryuji >>>> >>>> On 2009/04/16, at 12:06, marcelo bagnulo braun wrote: >>>> >>>>> now i am lost, i understood that we had two ways to dynamically >>>>> confgure filters, binary and conny's draft and that's what we were >>>>> discussing... didn't thought that it was static versus dynamic config= uration >>>>> of filters...so what is it? >>>>> >>>>> >>>>> Ryuji Wakikawa escribi=C3=B3: >>>>>> >>>>>> Hi Marcelo, >>>>>> >>>>>> When we have discussed flow management, there are two approaches (on= e >>>>>> is flow binding). >>>>>> The other approach is to install flow filters statically at the HA a= nd >>>>>> MN and switch them according to binding cache. >>>>>> >>>>>> Let's say MN and HA are statically configured with these three filte= rs >>>>>> set. According to binding cache database, >>>>>> each node switch the filter. >>>>>> >>>>>> BID1 only -> filter1 >>>>>> BID1 and BID2 -> filter2 >>>>>> BID2 only -> filter3 >>>>>> >>>>>> Flow binding has advantages on dynamic updates, but, on the other >>>>>> hand, some operators (let's say KDDI) prefer using >>>>>> more stable filter. The operator ships the terminal with pre-defined >>>>>> filter rules. The dynamic management leads certain overhead, too. >>>>>> That' why we have this Conny's document. >>>>>> AFAIK, this document does not specify any transport mechanism, but >>>>>> define only syntax of filters. >>>>>> >>>>>> Of course, you might use SSL, HTTPs, even flow binding (as George >>>>>> said), and any other mechanism to exchange these filters (if you wan= t >>>>>> dynamic filters exchange). >>>>>> To define a general filter syntax is very useful. This can be >>>>>> targetted to informational or experimental RFC. >>>>>> >>>>>> thanks >>>>>> ryuji >>>>>> >>>>>> >>>>>> On 2009/04/14, at 12:35, marcelo bagnulo braun wrote: >>>>>> >>>>>>> i wonder if we need the advanced features at this point >>>>>>> I mean, we are just defining this, wouldn't make sense to wait and >>>>>>> see if with the basic procedure is enough and do the extnesions lat= er? Or is >>>>>>> the basic mechanism so limited that is not enough to handle simple = basic >>>>>>> scenarios? If that is the case, does it makes sense to even define = it? >>>>>>> >>>>>>> Bottom line, we need strong reasons to do things in multiple >>>>>>> different ways. Unless clear reasons are described, i fail to see w= hy we >>>>>>> should standardize multiple approaches >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>> >>>>>>> George Tsirtsis escribi=C3=B3: >>>>>>>> >>>>>>>> Hi Marcelo, >>>>>>>> >>>>>>>> In the Monami6 days, the Flow Bindings draft used to include a >>>>>>>> binary >>>>>>>> Flow Descriptor as part of the FID option. >>>>>>>> This was basically a typical fixed length binary format defining a >>>>>>>> classifier filterm including source and destination addresses, >>>>>>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>>>>>> forget something; both IPv4 and IPv6 can be supported with this. >>>>>>>> >>>>>>>> Some people, however, thought that more flexible FDs should be >>>>>>>> allowed >>>>>>>> and Conny's draft describes a text based format which is clearly >>>>>>>> more >>>>>>>> flexible but also more verbose. >>>>>>>> >>>>>>>> At the time, the WG decided that the FD format should be taken out >>>>>>>> of >>>>>>>> the Flow Bindings draft. I am not sure I like that but this is >>>>>>>> indeed >>>>>>>> what happened. >>>>>>>> So, now the Flow Bindings draft allows for different FD formats, b= ut >>>>>>>> it does not define any of them. >>>>>>>> >>>>>>>> As a minimum, IMO the protocol should define one format as the >>>>>>>> default >>>>>>>> that all implementations MUST support, so that we can have >>>>>>>> interoperable implementations. >>>>>>>> IMO this should be the binary format which is the most compact and >>>>>>>> will work for most of the cases anyway. I do not care too much if >>>>>>>> this >>>>>>>> is defined in the same or on a separate (albeit tightly coupled) >>>>>>>> drafts. >>>>>>>> >>>>>>>> It is also ok with me to have other optional formats (like Conny's= ) >>>>>>>> for more advanced use cases. >>>>>>>> >>>>>>>> I hope this helps >>>>>>>> >>>>>>>> George >>>>>>>> >>>>>>>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>>>>> wrote: >>>>>>>> >>>>>>>>> George Tsirtsis escribi=C3=B3: >>>>>>>>> >>>>>>>>>> Hi Conny, >>>>>>>>>> >>>>>>>>>> Good to see you are resurrecting this draft. I think we need thi= s >>>>>>>>>> as >>>>>>>>>> one of the alternatives. We also need a binary version which I >>>>>>>>>> will be >>>>>>>>>> working on with others after I am done updating the Flow Binding= s >>>>>>>>>> draft. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> could you expand on this? >>>>>>>>> I mean, are you saying that we need two ways of describing flows? >>>>>>>>> >>>>>>>>> Regards, marcelo >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> George >>>>>>>>>> >>>>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This is a request to the MEXT working group to adopt >>>>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the charter >>>>>>>>>>> item: >>>>>>>>>>> >>>>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>>>> ... >>>>>>>>>>> Deliverables related to this include >>>>>>>>>>> - A "Flow/binding policies exchange" solution for an exchange o= f >>>>>>>>>>> policies from the mobile host/router to the Home Agent and from >>>>>>>>>>> the >>>>>>>>>>> Home Agent to the mobile host/router influencing the choice of >>>>>>>>>>> the >>>>>>>>>>> Care-of Address and Home Agent address. The solution involves t= wo >>>>>>>>>>> specifications, one for the policy format and another for its >>>>>>>>>>> transport [both Standard Track]. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The status of the working group is that we have a draft >>>>>>>>>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) >>>>>>>>>>> for >>>>>>>>>>> registration of multiple care-of addresses to one home address. >>>>>>>>>>> There exist one draft >>>>>>>>>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) fo= r >>>>>>>>>>> transport >>>>>>>>>>> of the rules that decides how each flow is sent over the >>>>>>>>>>> available >>>>>>>>>>> network >>>>>>>>>>> interfaces. >>>>>>>>>>> >>>>>>>>>>> What is currently missing is the part that defines the rules. >>>>>>>>>>> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>>>>> language that >>>>>>>>>>> can >>>>>>>>>>> be used for this. The document can be found at: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution= -rules-02 >>>>>>>>>>> >>>>>>>>>>> Please express your opinion on whether this should become a WG >>>>>>>>>>> document. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Conny >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From marcelo@it.uc3m.es Thu Apr 16 12:37:30 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52EA13A68F8 for ; Thu, 16 Apr 2009 12:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.054 X-Spam-Level: X-Spam-Status: No, score=-4.054 tagged_above=-999 required=5 tests=[AWL=2.545, 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 S0PJ1vyz3HJ6 for ; Thu, 16 Apr 2009 12:37:29 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 94BF03A6D3C for ; Thu, 16 Apr 2009 12:37:28 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (29.pool85-59-200.dynamic.orange.es [85.59.200.29]) by smtp01.uc3m.es (Postfix) with ESMTP id 569AFB9FEED; Thu, 16 Apr 2009 21:38:39 +0200 (CEST) Message-ID: <49E7893F.2040707@it.uc3m.es> Date: Thu, 16 Apr 2009 21:38:39 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ryuji Wakikawa References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> <49E4BB6C.6030702@it.uc3m.es> <49E7576E.9010200@it.uc3m.es> <49E781C0.7070900@kddilabs.jp> <49E784A2.6080000@it.uc3m.es> <5CB005C7-4196-4025-AFC6-452302679F99@gmail.com> In-Reply-To: <5CB005C7-4196-4025-AFC6-452302679F99@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16586.001 Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:37:30 -0000 Ryuji Wakikawa escribió: > Hi Marcelo and Tasaka, > > On 2009/04/16, at 15:18, marcelo bagnulo braun wrote: > >> Right, i understand that the transport of these rules is done using >> draft-ietf-mext-flow-binding, right? > > The flow binding is just one of transport protocol to carry the rules. > > This document deals with rules syntax and is independent from the flow > binding. > Anyone can pick any transport protocol to exchange these rules or can > install the filters with out any dynamic exchange. > right > regards, > ryuji > >> so what we need to agree next is what encoding we use to specify a >> flow, either the one or larson draft or the binary encoding (or maybe >> both, but strong reasons would be needed for that imho) >> >> >> Kazuyuki Tasaka escribió: >>> Hi Marcelo and Ryuji, >>> >>> Conny's document only defines generic rule language as a mean to >>> define and perform per flow path selection for a multi-homed node. >>> I think this document can provide static and dynamic configuration of >>> filters. >>> Flow filters are installed statically at the HA and MN. On the other >>> hands, in case of dynamic configuration, this document depends on >>> the transport protocol (e.g. flow bindings) to exchange flow filters >>> with other nodes . But the transport protocol is outside the scope of >>> this document and generic rule languages to statically and dynamically >>> configure are difined. >>> >>> Regards, tasaka. >>> >>> Ryuji Wakikawa Wrote: >>>> Hi Marcelo, >>>> >>>> Well, you are not lost, but I was actually lost. >>>> After reading the spec, they changed the draft a lot since I >>>> contributed to.. >>>> I asked Tasaka (KDDI guy) to explain the position of this draft. >>>> >>>> thanks >>>> ryuji >>>> >>>> On 2009/04/16, at 12:06, marcelo bagnulo braun wrote: >>>> >>>>> now i am lost, i understood that we had two ways to dynamically >>>>> confgure filters, binary and conny's draft and that's what we were >>>>> discussing... didn't thought that it was static versus dynamic >>>>> configuration of filters...so what is it? >>>>> >>>>> >>>>> Ryuji Wakikawa escribió: >>>>>> Hi Marcelo, >>>>>> >>>>>> When we have discussed flow management, there are two approaches >>>>>> (one is flow binding). >>>>>> The other approach is to install flow filters statically at the >>>>>> HA and MN and switch them according to binding cache. >>>>>> >>>>>> Let's say MN and HA are statically configured with these three >>>>>> filters set. According to binding cache database, >>>>>> each node switch the filter. >>>>>> >>>>>> BID1 only -> filter1 >>>>>> BID1 and BID2 -> filter2 >>>>>> BID2 only -> filter3 >>>>>> >>>>>> Flow binding has advantages on dynamic updates, but, on the other >>>>>> hand, some operators (let's say KDDI) prefer using >>>>>> more stable filter. The operator ships the terminal with >>>>>> pre-defined filter rules. The dynamic management leads certain >>>>>> overhead, too. >>>>>> That' why we have this Conny's document. >>>>>> AFAIK, this document does not specify any transport mechanism, >>>>>> but define only syntax of filters. >>>>>> >>>>>> Of course, you might use SSL, HTTPs, even flow binding (as George >>>>>> said), and any other mechanism to exchange these filters (if you >>>>>> want dynamic filters exchange). >>>>>> To define a general filter syntax is very useful. This can be >>>>>> targetted to informational or experimental RFC. >>>>>> >>>>>> thanks >>>>>> ryuji >>>>>> >>>>>> >>>>>> On 2009/04/14, at 12:35, marcelo bagnulo braun wrote: >>>>>> >>>>>>> i wonder if we need the advanced features at this point >>>>>>> I mean, we are just defining this, wouldn't make sense to wait >>>>>>> and see if with the basic procedure is enough and do the >>>>>>> extnesions later? Or is the basic mechanism so limited that is >>>>>>> not enough to handle simple basic scenarios? If that is the >>>>>>> case, does it makes sense to even define it? >>>>>>> >>>>>>> Bottom line, we need strong reasons to do things in multiple >>>>>>> different ways. Unless clear reasons are described, i fail to >>>>>>> see why we should standardize multiple approaches >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>> >>>>>>> George Tsirtsis escribió: >>>>>>>> Hi Marcelo, >>>>>>>> >>>>>>>> In the Monami6 days, the Flow Bindings draft used to include a >>>>>>>> binary >>>>>>>> Flow Descriptor as part of the FID option. >>>>>>>> This was basically a typical fixed length binary format defining a >>>>>>>> classifier filterm including source and destination addresses, >>>>>>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>>>>>> forget something; both IPv4 and IPv6 can be supported with this. >>>>>>>> >>>>>>>> Some people, however, thought that more flexible FDs should be >>>>>>>> allowed >>>>>>>> and Conny's draft describes a text based format which is >>>>>>>> clearly more >>>>>>>> flexible but also more verbose. >>>>>>>> >>>>>>>> At the time, the WG decided that the FD format should be taken >>>>>>>> out of >>>>>>>> the Flow Bindings draft. I am not sure I like that but this is >>>>>>>> indeed >>>>>>>> what happened. >>>>>>>> So, now the Flow Bindings draft allows for different FD >>>>>>>> formats, but >>>>>>>> it does not define any of them. >>>>>>>> >>>>>>>> As a minimum, IMO the protocol should define one format as the >>>>>>>> default >>>>>>>> that all implementations MUST support, so that we can have >>>>>>>> interoperable implementations. >>>>>>>> IMO this should be the binary format which is the most compact and >>>>>>>> will work for most of the cases anyway. I do not care too much >>>>>>>> if this >>>>>>>> is defined in the same or on a separate (albeit tightly coupled) >>>>>>>> drafts. >>>>>>>> >>>>>>>> It is also ok with me to have other optional formats (like >>>>>>>> Conny's) >>>>>>>> for more advanced use cases. >>>>>>>> >>>>>>>> I hope this helps >>>>>>>> >>>>>>>> George >>>>>>>> >>>>>>>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>>>>> wrote: >>>>>>>> >>>>>>>>> George Tsirtsis escribió: >>>>>>>>> >>>>>>>>>> Hi Conny, >>>>>>>>>> >>>>>>>>>> Good to see you are resurrecting this draft. I think we need >>>>>>>>>> this as >>>>>>>>>> one of the alternatives. We also need a binary version which >>>>>>>>>> I will be >>>>>>>>>> working on with others after I am done updating the Flow >>>>>>>>>> Bindings >>>>>>>>>> draft. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> could you expand on this? >>>>>>>>> I mean, are you saying that we need two ways of describing flows? >>>>>>>>> >>>>>>>>> Regards, marcelo >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> George >>>>>>>>>> >>>>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This is a request to the MEXT working group to adopt >>>>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the >>>>>>>>>>> charter item: >>>>>>>>>>> >>>>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>>>> ... >>>>>>>>>>> Deliverables related to this include >>>>>>>>>>> - A "Flow/binding policies exchange" solution for an >>>>>>>>>>> exchange of >>>>>>>>>>> policies from the mobile host/router to the Home Agent and >>>>>>>>>>> from the >>>>>>>>>>> Home Agent to the mobile host/router influencing the choice >>>>>>>>>>> of the >>>>>>>>>>> Care-of Address and Home Agent address. The solution >>>>>>>>>>> involves two >>>>>>>>>>> specifications, one for the policy format and another for its >>>>>>>>>>> transport [both Standard Track]. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The status of the working group is that we have a draft >>>>>>>>>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) >>>>>>>>>>> for >>>>>>>>>>> registration of multiple care-of addresses to one home address. >>>>>>>>>>> There exist one draft >>>>>>>>>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) >>>>>>>>>>> for >>>>>>>>>>> transport >>>>>>>>>>> of the rules that decides how each flow is sent over the >>>>>>>>>>> available >>>>>>>>>>> network >>>>>>>>>>> interfaces. >>>>>>>>>>> >>>>>>>>>>> What is currently missing is the part that defines the rules. >>>>>>>>>>> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>>>>> language that >>>>>>>>>>> can >>>>>>>>>>> be used for this. The document can be found at: >>>>>>>>>>> >>>>>>>>>>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please express your opinion on whether this should become a >>>>>>>>>>> WG document. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Conny >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >> > > From behcetsarikaya@yahoo.com Thu Apr 16 15:26:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033753A6946 for ; Thu, 16 Apr 2009 15:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 uNwnJLWv74xv for ; Thu, 16 Apr 2009 15:26:13 -0700 (PDT) Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by core3.amsl.com (Postfix) with SMTP id 2D7933A6DF4 for ; Thu, 16 Apr 2009 15:25:49 -0700 (PDT) Received: from [68.142.230.28] by n7.bullet.re3.yahoo.com with NNFMP; 16 Apr 2009 22:27:02 -0000 Received: from [67.195.9.83] by t1.bullet.re2.yahoo.com with NNFMP; 16 Apr 2009 22:27:01 -0000 Received: from [67.195.9.111] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 16 Apr 2009 22:27:01 -0000 Received: from [127.0.0.1] by omp115.mail.gq1.yahoo.com with NNFMP; 16 Apr 2009 22:27:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 398918.44697.bm@omp115.mail.gq1.yahoo.com Received: (qmail 73311 invoked by uid 60001); 16 Apr 2009 22:27:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1239920821; bh=QXqqD8Fo6nL2jgWUEcKyXG828HnJAkDKMBIohbn3bEY=; 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=aROH7GH2maXjsQPkJ6oqjFDQAMJCI3QjvQQJemX9BqCeo+FzHySlSLxRdx80I21UDenthOeA9jRwLXkKKCbF5wjFhG556dfWPowSUQ0nhYPwSlt0ef/D8bUrihMeO6M5EXiFhIoz561eBGvKYiJdwNGj7HHLPwJ/lRcgkbiNY9M= 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=2hOaPw58i+TxtL/IfNgu3qCVZU9g8wCsyTgvJK3aiFz9Y9q+2Y3E3Xkx5ep5P7dXswoMEzlFhg4G8xAjCWcY8VWognxHmYixq+Lrx+fOxmKhTQZR+NSugXf8Li0oWGd7eyuzJ3tsO+IqwYwM8RxyekaM4y1F7KDomOUnfyopH/4=; Message-ID: <505075.72451.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: x1zN5RoVM1kqArNwtB0FfUP07izTmSU2MnKtR566M2R80ho_izRM5noSbr_sPDqDx1NJz64P1sjWE6LRwAHzIBHoTNBTOafsudDqCd4xb8Tq4gFOZHXcu9u_7L8rDpgMu38_yHkH39_NzHPwB4CQ3EJdpn6j3x1hGC..PEr.e7a8AEiFowMlfEq5E8ZE4vwyELxFc6u9gKGCf0Jbt6ZaoYdPR7haJwGRpGYq.Io4jH8073YVz0iCi8Y60FqEodRFRi3X6IGJlFqZvGMCQxoEyqGsGmzARb7RnpGUvAMnNLt9OOn9FKAc6hvDlm19kkaKneLo Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Thu, 16 Apr 2009 15:27:01 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <657051.66216.qm@web27807.mail.ukl.yahoo.com> <49E5AF88.50306@it.uc3m.es> Date: Thu, 16 Apr 2009 15:27:01 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo braun , Christian Kaas-Petersen In-Reply-To: <49E5AF88.50306@it.uc3m.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1909198063-1239920821=:72451" Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 22:26:14 -0000 --0-1909198063-1239920821=:72451 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A________________________________=0A=0AFrom: marcelo bagnulo bra= un =0ATo: Christian Kaas-Petersen =0ACc: julien.laganier.IETF@googlemail.com; mext =0ASent: = Wednesday, April 15, 2009 4:57:28 AM=0ASubject: Re: [MEXT] Call for adoptat= ion of draft-larsson-mext-flow-distribution-rules=0A=0AMy case in point wil= l be Nemo PD. We have only one Nemo base protocol. But Nemo PD is a feature= , it has been left out when the base protocol was defined. Defining two app= roaches to Nemo PD was already accepted in Nemo WG some time back. I don't = understand why we don't do the same in Mext WG? In fact if you consider bas= e protocol operations you will see that the protocol usually allows more th= an one option to be taken. Nemo PD can be viewed the same way allowing more= than one option to be taken.=0A=A0=0ARegards,=0A=A0=0ABehcet=0A=A0=0A=A0= =0AChristian Kaas-Petersen escribi=F3:=0A> Actually, IETF 74th Thursday ple= nary on MPLS discussed the situation of=0A> have alternative protocols (LDP= vs RSVP was just one example) doing the=0A> same thing.=A0 The statements = made by the speakers and from the floor=0A> were: Yes it is a pain to imple= ment two protocols, and yes it is a=0A> pain to deploy two protocols.=A0 Ho= wever, most often it turns out, that=0A> one of the protocols is left in ob= livion when it has been seen running=0A> in practice, and most often taking= a second approach gives renewed input=0A> or energy to the first approach,= making it clear which of the two=0A> approaches is the favoured one.=A0 Th= us I went away with the impression,=0A> that staying with one approach is i= n fact not always the obvious thing=0A> to do.=0A>=A0 =0AI am not saying th= at we must define only one approach in all cases. What i am saying is that = the default option is to define only one and we need strong reasons for do = more than one=0A=0ARegards, marcelo=0A=0A=0A=0A[behcet] My idea in deciding= one approach or second approach is that we should define only one base pro= tocol. When it comes to feature extensions we may consider more than one so= lutions.=0A=0A=0A --0-1909198063-1239920821=:72451 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A

=0A
=0A
=0A
=0A
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
To: Christian Kaas-Petersen <kaaspete= rsen@yahoo.dk>
Cc: ju= lien.laganier.IETF@googlemail.com; mext <mext@ietf.org>
Sent: Wednesday, April 15, 2009 4:57:= 28 AM
Subject: Re: [MEXT= ] Call for adoptation of draft-larsson-mext-flow-distribution-rules

Christian Kaas-Petersen escribi=F3:
> Actually, IETF 74th Thur= sday plenary on MPLS discussed the situation of
> have alternative pr= otocols (LDP vs RSVP was just one example) doing the
> same thing.&nb= sp; The statements made by the speakers and from the floor
> were: Ye= s it is a pain to implement two protocols, and yes it is a
> pain to deploy two protocols.  How= ever, most often it turns out, that
> one of the protocols is left in= oblivion when it has been seen running
> in practice, and most often= taking a second approach gives renewed input
> or energy to the firs= t approach, making it clear which of the two
> approaches is the favo= ured one.  Thus I went away with the impression,
> that staying = with one approach is in fact not always the obvious thing
> to do.> 
I am not saying that we must define only one approach in al= l cases. What i am saying is that the default option is to define only one = and we need strong reasons for do more than one

Regards, marcelo
=


[behcet] My idea in deciding one = approach or second approach is that we should define only one base protocol= .. When it comes to feature extensions we may consider more than one solutions.
=0A
My case in= point will be Nemo PD. We have only one Nemo base protocol. But Nemo PD is= a feature, it has been left out when the base protocol was defined. Defini= ng two approaches to Nemo PD was already accepted in Nemo WG some time back= .. I don't understand why we don't do the same in Mext WG? In fact if you co= nsider base protocol operations you will see that the protocol usually allo= ws more than one option to be taken. Nemo PD can be viewed the same way all= owing more than one option to be taken.
=0A
 
=0A
Regards,
=0A
 
=0A
Behcet=0A
 
=0A
<= FONT color=3D#40007f> 

=0A=0A = --0-1909198063-1239920821=:72451-- From hesham@elevatemobile.com Thu Apr 16 17:32:49 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C48C3A6997 for ; Thu, 16 Apr 2009 17:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 ocnICtAwVJKI for ; Thu, 16 Apr 2009 17:32:47 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 662093A6917 for ; Thu, 16 Apr 2009 17:32:46 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Luc1e-0004S4-Fs; Fri, 17 Apr 2009 10:33:51 +1000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 17 Apr 2009 10:33:40 +1100 From: Hesham Soliman To: Kazuyuki Tasaka , marcelo bagnulo braun , Ryuji Wakikawa Message-ID: Thread-Topic: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules Thread-Index: Acm+9Cd00FQdpNlDnkKd3qJEIU11qA== In-Reply-To: <49E781C0.7070900@kddilabs.jp> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 00:32:49 -0000 On 17/04/09 6:06 AM, "Kazuyuki Tasaka" wrote: > Hi Marcelo and Ryuji, Conny's document only defines generic rule language as > a mean to define and perform per flow path selection for a multi-homed node. I > think this document can provide static and dynamic configuration > of filters. Flow filters are installed statically at the HA and MN. =3D> Which drafts are you talking about? Are you talkig about this WG's documents and charter or something that you would like to have? None of thi= s is in the WG docs or charter. We don't have static rules and draft-larsson is not about filter installation, that's done in the flow bindings draft. I find this thread very confusing, please read the drafts in question! Hesham On the=20 > other hands, in case of dynamic configuration, this document depends on the > transport protocol (e.g. flow bindings) to exchange flow filters with other > nodes . But the transport protocol is outside the scope of this document and > generic rule languages to statically and dynamically configure are > difined. Regards, tasaka. Ryuji Wakikawa Wrote: > Hi Marcelo, > > Well, you > are not lost, but I was actually lost. > After reading the spec, they changed > the draft a lot since I contributed > to.. > I asked Tasaka (KDDI guy) to > explain the position of this draft. > > thanks > ryuji > > On 2009/04/16, at > 12:06, marcelo bagnulo braun wrote: > >> now i am lost, i understood that we > had two ways to dynamically >> confgure filters, binary and conny's draft and > that's what we were >> discussing... didn't thought that it was static versus > dynamic >> configuration of filters...so what is it? >> >> >> Ryuji Wakikawa > escribi=F3: >>> Hi Marcelo, >>> >>> When we have discussed flow management, > there are two approaches (one >>> is flow binding). >>> The other approach is > to install flow filters statically at the HA >>> and MN and switch them > according to binding cache. >>> >>> Let's say MN and HA are statically > configured with these three >>> filters set. According to binding cache > database, >>> each node switch the filter. >>> >>> BID1 only -> filter1 >>> > BID1 and BID2 -> filter2 >>> BID2 only -> filter3 >>> >>> Flow binding has > advantages on dynamic updates, but, on the other >>> hand, some operators > (let's say KDDI) prefer using >>> more stable filter. The operator ships the > terminal with pre-defined >>> filter rules. The dynamic management leads > certain overhead, too. >>> That' why we have this Conny's document. >>> AFAIK, > this document does not specify any transport mechanism, but >>> define only > syntax of filters. >>> >>> Of course, you might use SSL, HTTPs, even flow > binding (as George >>> said), and any other mechanism to exchange these > filters (if you want >>> dynamic filters exchange). >>> To define a general > filter syntax is very useful. This can be >>> targetted to informational or > experimental RFC. >>> >>> thanks >>> ryuji >>> >>> >>> On 2009/04/14, at > 12:35, marcelo bagnulo braun wrote: >>> >>>> i wonder if we need the advanced > features at this point >>>> I mean, we are just defining this, wouldn't make > sense to wait and >>>> see if with the basic procedure is enough and do the > extnesions >>>> later? Or is the basic mechanism so limited that is not > enough to >>>> handle simple basic scenarios? If that is the case, does it > makes >>>> sense to even define it? >>>> >>>> Bottom line, we need strong > reasons to do things in multiple >>>> different ways. Unless clear reasons > are described, i fail to see >>>> why we should standardize multiple > approaches >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> George Tsirtsis > escribi=F3: >>>>> Hi Marcelo, >>>>> >>>>> In the Monami6 days, the Flow Bindings > draft used to include a binary >>>>> Flow Descriptor as part of the FID > option. >>>>> This was basically a typical fixed length binary format defining > a >>>>> classifier filterm including source and destination addresses, >>>>> > protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>>> > forget something; both IPv4 and IPv6 can be supported with this. >>>>> >>>>> > Some people, however, thought that more flexible FDs should be allowed >>>>> > and Conny's draft describes a text based format which is clearly more >>>>> > flexible but also more verbose. >>>>> >>>>> At the time, the WG decided that > the FD format should be taken out of >>>>> the Flow Bindings draft. I am not > sure I like that but this is indeed >>>>> what happened. >>>>> So, now the > Flow Bindings draft allows for different FD formats, but >>>>> it does not > define any of them. >>>>> >>>>> As a minimum, IMO the protocol should define > one format as the default >>>>> that all implementations MUST support, so that > we can have >>>>> interoperable implementations. >>>>> IMO this should be the > binary format which is the most compact and >>>>> will work for most of the > cases anyway. I do not care too much if this >>>>> is defined in the same or > on a separate (albeit tightly coupled) >>>>> drafts. >>>>> >>>>> It is also ok > with me to have other optional formats (like Conny's) >>>>> for more advanced > use cases. >>>>> >>>>> I hope this helps >>>>> >>>>> George >>>>> >>>>> Tue, > Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>> > wrote: >>>>> >>>>>> George Tsirtsis escribi=F3: >>>>>> >>>>>>> Hi > Conny, >>>>>>> >>>>>>> Good to see you are resurrecting this draft. I think we > need this as >>>>>>> one of the alternatives. We also need a binary version > which I >>>>>>> will be >>>>>>> working on with others after I am done > updating the Flow Bindings >>>>>>> draft. >>>>>>> >>>>>>> >>>>>> could you > expand on this? >>>>>> I mean, are you saying that we need two ways of > describing flows? >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>>> > Thanks >>>>>>> George >>>>>>> >>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny > Larsson >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> > Hi, >>>>>>>> >>>>>>>> This is a request to the MEXT working group to > adopt >>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the charter > >>>>>>>> item: >>>>>>>> >>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>> > ... >>>>>>>> Deliverables related to this include >>>>>>>> - A "Flow/binding > policies exchange" solution for an exchange of >>>>>>>> policies from the > mobile host/router to the Home Agent and from the >>>>>>>> Home Agent to the > mobile host/router influencing the choice of the >>>>>>>> Care-of Address and > Home Agent address. The solution involves two >>>>>>>> specifications, one for > the policy format and another for its >>>>>>>> transport [both Standard > Track]. >>>>>>>> >>>>>>>> >>>>>>>> The status of the working group is that we > have a draft >>>>>>>> > (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>>>>>> > registration of multiple care-of addresses to one home address. >>>>>>>> There > exist one draft >>>>>>>> > (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>>>> > transport >>>>>>>> of the rules that decides how each flow is sent over the > available >>>>>>>> network >>>>>>>> interfaces. >>>>>>>> >>>>>>>> What is > currently missing is the part that defines the rules. >>>>>>>> > draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>> language > that >>>>>>>> can >>>>>>>> be used for this. The document can be found > at: >>>>>>>> >>>>>>>> > http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 > >>>>>>>> >>>>>>>> >>>>>>>> Please express your opinion on whether this should > become a WG >>>>>>>> document. >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> > Conny >>>>>>>> >>>>>>>> > _______________________________________________ >>>>>>>> MEXT mailing > list >>>>>>>> MEXT@ietf.org >>>>>>>> > https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> > >>>>>> >>>>> >>>>> >>>> >>>> > _______________________________________________ >>>> MEXT mailing list >>>> > MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> > > > _______________________________________________ > MEXT mailing list > > MEXT@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/mext _________________________________ > ______________ MEXT mailing > list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From ka-tasaka@kddilabs.jp Thu Apr 16 21:41:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1766C3A6A31 for ; Thu, 16 Apr 2009 21:41:09 -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 yVTHJAD2G2ad for ; Thu, 16 Apr 2009 21:41:07 -0700 (PDT) Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id F0B1A3A68B2 for ; Thu, 16 Apr 2009 21:41:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id B906DEC8E9; Fri, 17 Apr 2009 13:42:18 +0900 (JST) Received: from spears.ast.kddilabs.jp (unknown [2001:200:601:800::168]) by mandala.kddilabs.jp (Postfix) with ESMTP id 63E2FEC8E5; Fri, 17 Apr 2009 13:42:17 +0900 (JST) Received: from [127.0.0.1] (ova158.vpn.kddilabs.jp [172.19.112.158]) by spears.ast.kddilabs.jp (Postfix) with ESMTP id 216DB270143; Fri, 17 Apr 2009 13:42:13 +0900 (JST) Message-ID: <49E808A2.70600@kddilabs.jp> Date: Fri, 17 Apr 2009 13:42:10 +0900 From: Kazuyuki Tasaka User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:41:09 -0000 Hi Hesham, Hesham Soliman Wrote: >=20 >=20 > On 17/04/09 6:06 AM, "Kazuyuki Tasaka" wrote: >=20 >> Hi Marcelo and Ryuji, >=20 > Conny's document only defines generic rule language as >> a mean to > define and perform per flow path selection for a multi-homed node. > I >> think this document can provide static and dynamic configuration >> of > filters. > Flow filters are installed statically at the HA and MN. >=20 > =3D> Which drafts are you talking about? Are you talkig about this WG's > documents and charter or something that you would like to have? None of= this > is in the WG docs or charter. We don't have static rules and draft-lars= son > is not about filter installation, that's done in the flow bindings draf= t. I taked about the position of draft-larsson. But, there was a lack of talk. This is one use case of filter rules defined in draft-larsson. For example, when some operators prefer using more stable filter, operator ships the terminal with pre-defined filter rules. Regards, tasaka. > I find this thread very confusing, please read the drafts in question! >=20 > Hesham >=20 >=20 >=20 > On the=20 >> other > hands, in case of dynamic configuration, this document depends on > the >> transport protocol (e.g. flow bindings) to exchange flow filters > with other >> nodes . But the transport protocol is outside the scope of > this document and >> generic rule languages to statically and dynamically > configure are >> difined. >=20 > Regards, tasaka. >=20 > Ryuji Wakikawa Wrote: >> Hi Marcelo, >> >> Well, you >> are not lost, but I was actually lost. >> After reading the spec, they changed >> the draft a lot since I contributed=20 >> to.. >> I asked Tasaka (KDDI guy) to >> explain the position of this draft. >> >> thanks >> ryuji >> >> On 2009/04/16, at >> 12:06, marcelo bagnulo braun wrote: >> >>> now i am lost, i understood that we >> had two ways to dynamically=20 >>> confgure filters, binary and conny's draft and >> that's what we were=20 >>> discussing... didn't thought that it was static versus >> dynamic=20 >>> configuration of filters...so what is it? >>> >>> >>> Ryuji Wakikawa >> escribi=F3: >>>> Hi Marcelo, >>>> >>>> When we have discussed flow management, >> there are two approaches (one=20 >>>> is flow binding). >>>> The other approach is >> to install flow filters statically at the HA=20 >>>> and MN and switch them >> according to binding cache. >>>> Let's say MN and HA are statically >> configured with these three=20 >>>> filters set. According to binding cache >> database, >>>> each node switch the filter. >>>> >>>> BID1 only -> filter1 >>>> >> BID1 and BID2 -> filter2 >>>> BID2 only -> filter3 >>>> >>>> Flow binding has >> advantages on dynamic updates, but, on the other=20 >>>> hand, some operators >> (let's say KDDI) prefer using >>>> more stable filter. The operator ships the >> terminal with pre-defined=20 >>>> filter rules. The dynamic management leads >> certain overhead, too. >>>> That' why we have this Conny's document. >>>> AFAIK, >> this document does not specify any transport mechanism, but=20 >>>> define only >> syntax of filters. >>>> Of course, you might use SSL, HTTPs, even flow >> binding (as George=20 >>>> said), and any other mechanism to exchange these >> filters (if you want=20 >>>> dynamic filters exchange). >>>> To define a general >> filter syntax is very useful. This can be=20 >>>> targetted to informational or >> experimental RFC. >>>> thanks >>>> ryuji >>>> >>>> >>>> On 2009/04/14, at >> 12:35, marcelo bagnulo braun wrote: >>>>> i wonder if we need the advanced >> features at this point >>>>> I mean, we are just defining this, wouldn't make >> sense to wait and=20 >>>>> see if with the basic procedure is enough and do the >> extnesions=20 >>>>> later? Or is the basic mechanism so limited that is not >> enough to=20 >>>>> handle simple basic scenarios? If that is the case, does it >> makes=20 >>>>> sense to even define it? >>>>> >>>>> Bottom line, we need strong >> reasons to do things in multiple=20 >>>>> different ways. Unless clear reasons >> are described, i fail to see=20 >>>>> why we should standardize multiple >> approaches >>>>> Regards, marcelo >>>>> >>>>> >>>>> >>>>> George Tsirtsis >> escribi=F3: >>>>>> Hi Marcelo, >>>>>> >>>>>> In the Monami6 days, the Flow Bindings >> draft used to include a binary >>>>>> Flow Descriptor as part of the FID >> option. >>>>>> This was basically a typical fixed length binary format defining >> a >>>>>> classifier filterm including source and destination addresses, >>>>>> >> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >> forget something; both IPv4 and IPv6 can be supported with this. >>>>>> >> Some people, however, thought that more flexible FDs should be allowed >> and Conny's draft describes a text based format which is clearly more >> flexible but also more verbose. >>>>>> At the time, the WG decided that >> the FD format should be taken out of >>>>>> the Flow Bindings draft. I am not >> sure I like that but this is indeed >>>>>> what happened. >>>>>> So, now the >> Flow Bindings draft allows for different FD formats, but >>>>>> it does not >> define any of them. >>>>>> As a minimum, IMO the protocol should define >> one format as the default >>>>>> that all implementations MUST support, so that >> we can have >>>>>> interoperable implementations. >>>>>> IMO this should be the >> binary format which is the most compact and >>>>>> will work for most of the >> cases anyway. I do not care too much if this >>>>>> is defined in the same or >> on a separate (albeit tightly coupled) >>>>>> drafts. >>>>>> >>>>>> It is also ok >> with me to have other optional formats (like Conny's) >>>>>> for more advanced >> use cases. >>>>>> I hope this helps >>>>>> >>>>>> George >>>>>> >>>>>> Tue, >> Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun=20 >>>>>> >> wrote: >>>>>>> George Tsirtsis escribi=F3: >>>>>>> >>>>>>>> Hi >> Conny, >>>>>>>> Good to see you are resurrecting this draft. I think we >> need this as >>>>>>>> one of the alternatives. We also need a binary version >> which I=20 >>>>>>>> will be >>>>>>>> working on with others after I am done >> updating the Flow Bindings >>>>>>>> draft. >>>>>>>> >>>>>>>> >>>>>>> could you >> expand on this? >>>>>>> I mean, are you saying that we need two ways of >> describing flows? >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >> Thanks >>>>>>>> George >>>>>>>> >>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny >> Larsson >>>>>>>> wrote: >>>>>>>> >>>>>>>> >> Hi, >>>>>>>>> This is a request to the MEXT working group to >> adopt >>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the charter >>>>>>>>> item: >>>>>>>>> >>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>> >> ... >>>>>>>>> Deliverables related to this include >>>>>>>>> - A "Flow/binding >> policies exchange" solution for an exchange of >>>>>>>>> policies from the >> mobile host/router to the Home Agent and from the >>>>>>>>> Home Agent to the >> mobile host/router influencing the choice of the >>>>>>>>> Care-of Address and >> Home Agent address. The solution involves two >>>>>>>>> specifications, one for >> the policy format and another for its >>>>>>>>> transport [both Standard >> Track]. >>>>>>>>> >>>>>>>>> The status of the working group is that we >> have a draft >> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >> registration of multiple care-of addresses to one home address. >>>>>>>>> There >> exist one draft >> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >> transport >>>>>>>>> of the rules that decides how each flow is sent over the >> available >>>>>>>>> network >>>>>>>>> interfaces. >>>>>>>>> >>>>>>>>> What is >> currently missing is the part that defines the rules. >> draft-larsson-mext-flow-distribution-rules defines a rule=20 >>>>>>>>> language >> that >>>>>>>>> can >>>>>>>>> be used for this. The document can be found >> at: >>>>>>>>> >> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-= 02 >> >>>>>>>>> >>>>>>>>> Please express your opinion on whether this should >> become a WG=20 >>>>>>>>> document. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >> Conny >>>>>>>>> >> _______________________________________________ >>>>>>>>> MEXT mailing >> list >>>>>>>>> MEXT@ietf.org >>>>>>>>> >> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> >>>>>>>>> >=20 >>>>>> >>>>> >> _______________________________________________ >>>>> MEXT mailing list >>>>> >> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >> >> _______________________________________________ >> MEXT mailing list >> >> MEXT@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mext >=20 >=20 > _________________________________ >> ______________ > MEXT mailing >> list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 >=20 >=20 >=20 >=20 From ryuji.wakikawa@gmail.com Thu Apr 16 21:49:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F123A6CE9 for ; Thu, 16 Apr 2009 21:49:12 -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 U+p6-vDMRNsu for ; Thu, 16 Apr 2009 21:49:10 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id 20B713A6D1F for ; Thu, 16 Apr 2009 21:49:10 -0700 (PDT) Received: by qyk42 with SMTP id 42so410361qyk.29 for ; Thu, 16 Apr 2009 21:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=8FUF52/FKYeNvaK/lHpSYYtzuvbwHqpYMR/t7NuWf3o=; b=h3Kv5T95IYD/tTOSatzk/aym98hVL3tMrFUX7/qeP6g2O8ZCYKVTZ+zQ2qrGQFIDcm MahsVbUE3NWQBshHXCkKRLHzwNQD0BkmBYfLFGiMIy7N35hI4zWJxGv8nkgZCWsnBNt+ 8PttqCtFmqSyvBC780SzWPPo35gC9vqWaM2Jg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=UbceZHJ1i8+q9VUJ2nf6a70baLasSwNpGCVzKtdsLdr7rQlvK+u+Bb4wHMCCTz7HaL MbFeSZTGw2qdVp6HDQbwKFB9GK/AdYpSjhbEHbmbuK5zNaGaB81JRPQiT665Dx93ClPt 2iFvyWrKypNM/tMJKx0wx25ETKUiN5gAUFoig= Received: by 10.224.67.7 with SMTP id p7mr2932259qai.265.1239943823243; Thu, 16 Apr 2009 21:50:23 -0700 (PDT) Received: from ?172.17.191.127? ([208.251.140.35]) by mx.google.com with ESMTPS id 7sm3391452qwf.25.2009.04.16.21.50.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Apr 2009 21:50:22 -0700 (PDT) From: Ryuji Wakikawa To: George Tsirtsis In-Reply-To: References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> <49E4BB6C.6030702@it.uc3m.es> <49E7576E.9010200@it.uc3m.es> <49E781C0.7070900@kddilabs.jp> <49E784A2.6080000@it.uc3m.es> <5CB005C7-4196-4025-AFC6-452302679F99@gmail.com> Message-Id: <4B32C435-87A1-4CCB-94E8-6AA40E460364@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 00:50:19 -0400 X-Mailer: Apple Mail (2.930.3) Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:49:12 -0000 Hi George, I mean once we define a common syntax, operator can pick any transport =20= mechanism as they wish. The transport mechanism will not be discussed in MEXT. Well if they statically configure the filters, we don't need any =20 transport mechanism:-) regards, ryuij On 2009/04/16, at 15:33, George Tsirtsis wrote: > Ryuji, > > I know we have been saying this for a while now but I am not sure to > what extend it holds water. If you want an out of band mechanism for > controlling filters in a box there are specific protocols for that > kind of thing e.g., MIDCOM, and they define the whole thing, including > encoding and transport. > > As I said before, I am not against having multiple flow description > necodings for Flow Bindings, but the generality argument is a bit of a > stretch IMHO. > > Regards > George > > > On Thu, Apr 16, 2009 at 8:26 PM, Ryuji Wakikawa > wrote: >> Hi Marcelo and Tasaka, >> >> On 2009/04/16, at 15:18, marcelo bagnulo braun wrote: >> >>> Right, i understand that the transport of these rules is done using >>> draft-ietf-mext-flow-binding, right? >> >> The flow binding is just one of transport protocol to carry the =20 >> rules. >> >> This document deals with rules syntax and is independent from the =20 >> flow >> binding. >> Anyone can pick any transport protocol to exchange these rules or can >> install the filters with out any dynamic exchange. >> >> regards, >> ryuji >> >>> so what we need to agree next is what encoding we use to specify a =20= >>> flow, >>> either the one or larson draft or the binary encoding (or maybe =20 >>> both, but >>> strong reasons would be needed for that imho) >>> >>> >>> Kazuyuki Tasaka escribi=C3=B3: >>>> >>>> Hi Marcelo and Ryuji, >>>> >>>> Conny's document only defines generic rule language as a mean to >>>> define and perform per flow path selection for a multi-homed node. >>>> I think this document can provide static and dynamic =20 >>>> configuration of >>>> filters. >>>> Flow filters are installed statically at the HA and MN. On the =20 >>>> other >>>> hands, in case of dynamic configuration, this document depends on >>>> the transport protocol (e.g. flow bindings) to exchange flow =20 >>>> filters >>>> with other nodes . But the transport protocol is outside the =20 >>>> scope of >>>> this document and generic rule languages to statically and =20 >>>> dynamically >>>> configure are difined. >>>> >>>> Regards, tasaka. >>>> >>>> Ryuji Wakikawa Wrote: >>>>> >>>>> Hi Marcelo, >>>>> >>>>> Well, you are not lost, but I was actually lost. >>>>> After reading the spec, they changed the draft a lot since I =20 >>>>> contributed >>>>> to.. >>>>> I asked Tasaka (KDDI guy) to explain the position of this draft. >>>>> >>>>> thanks >>>>> ryuji >>>>> >>>>> On 2009/04/16, at 12:06, marcelo bagnulo braun wrote: >>>>> >>>>>> now i am lost, i understood that we had two ways to dynamically >>>>>> confgure filters, binary and conny's draft and that's what we =20 >>>>>> were >>>>>> discussing... didn't thought that it was static versus dynamic =20= >>>>>> configuration >>>>>> of filters...so what is it? >>>>>> >>>>>> >>>>>> Ryuji Wakikawa escribi=C3=B3: >>>>>>> >>>>>>> Hi Marcelo, >>>>>>> >>>>>>> When we have discussed flow management, there are two =20 >>>>>>> approaches (one >>>>>>> is flow binding). >>>>>>> The other approach is to install flow filters statically at =20 >>>>>>> the HA and >>>>>>> MN and switch them according to binding cache. >>>>>>> >>>>>>> Let's say MN and HA are statically configured with these three =20= >>>>>>> filters >>>>>>> set. According to binding cache database, >>>>>>> each node switch the filter. >>>>>>> >>>>>>> BID1 only -> filter1 >>>>>>> BID1 and BID2 -> filter2 >>>>>>> BID2 only -> filter3 >>>>>>> >>>>>>> Flow binding has advantages on dynamic updates, but, on the =20 >>>>>>> other >>>>>>> hand, some operators (let's say KDDI) prefer using >>>>>>> more stable filter. The operator ships the terminal with pre-=20 >>>>>>> defined >>>>>>> filter rules. The dynamic management leads certain overhead, =20 >>>>>>> too. >>>>>>> That' why we have this Conny's document. >>>>>>> AFAIK, this document does not specify any transport mechanism, =20= >>>>>>> but >>>>>>> define only syntax of filters. >>>>>>> >>>>>>> Of course, you might use SSL, HTTPs, even flow binding (as =20 >>>>>>> George >>>>>>> said), and any other mechanism to exchange these filters (if =20 >>>>>>> you want >>>>>>> dynamic filters exchange). >>>>>>> To define a general filter syntax is very useful. This can be >>>>>>> targetted to informational or experimental RFC. >>>>>>> >>>>>>> thanks >>>>>>> ryuji >>>>>>> >>>>>>> >>>>>>> On 2009/04/14, at 12:35, marcelo bagnulo braun wrote: >>>>>>> >>>>>>>> i wonder if we need the advanced features at this point >>>>>>>> I mean, we are just defining this, wouldn't make sense to =20 >>>>>>>> wait and >>>>>>>> see if with the basic procedure is enough and do the =20 >>>>>>>> extnesions later? Or is >>>>>>>> the basic mechanism so limited that is not enough to handle =20 >>>>>>>> simple basic >>>>>>>> scenarios? If that is the case, does it makes sense to even =20 >>>>>>>> define it? >>>>>>>> >>>>>>>> Bottom line, we need strong reasons to do things in multiple >>>>>>>> different ways. Unless clear reasons are described, i fail to =20= >>>>>>>> see why we >>>>>>>> should standardize multiple approaches >>>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> George Tsirtsis escribi=C3=B3: >>>>>>>>> >>>>>>>>> Hi Marcelo, >>>>>>>>> >>>>>>>>> In the Monami6 days, the Flow Bindings draft used to include a >>>>>>>>> binary >>>>>>>>> Flow Descriptor as part of the FID option. >>>>>>>>> This was basically a typical fixed length binary format =20 >>>>>>>>> defining a >>>>>>>>> classifier filterm including source and destination addresses, >>>>>>>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I =20= >>>>>>>>> do not >>>>>>>>> forget something; both IPv4 and IPv6 can be supported with =20 >>>>>>>>> this. >>>>>>>>> >>>>>>>>> Some people, however, thought that more flexible FDs should be >>>>>>>>> allowed >>>>>>>>> and Conny's draft describes a text based format which is =20 >>>>>>>>> clearly >>>>>>>>> more >>>>>>>>> flexible but also more verbose. >>>>>>>>> >>>>>>>>> At the time, the WG decided that the FD format should be =20 >>>>>>>>> taken out >>>>>>>>> of >>>>>>>>> the Flow Bindings draft. I am not sure I like that but this is >>>>>>>>> indeed >>>>>>>>> what happened. >>>>>>>>> So, now the Flow Bindings draft allows for different FD =20 >>>>>>>>> formats, but >>>>>>>>> it does not define any of them. >>>>>>>>> >>>>>>>>> As a minimum, IMO the protocol should define one format as the >>>>>>>>> default >>>>>>>>> that all implementations MUST support, so that we can have >>>>>>>>> interoperable implementations. >>>>>>>>> IMO this should be the binary format which is the most =20 >>>>>>>>> compact and >>>>>>>>> will work for most of the cases anyway. I do not care too =20 >>>>>>>>> much if >>>>>>>>> this >>>>>>>>> is defined in the same or on a separate (albeit tightly =20 >>>>>>>>> coupled) >>>>>>>>> drafts. >>>>>>>>> >>>>>>>>> It is also ok with me to have other optional formats (like =20 >>>>>>>>> Conny's) >>>>>>>>> for more advanced use cases. >>>>>>>>> >>>>>>>>> I hope this helps >>>>>>>>> >>>>>>>>> George >>>>>>>>> >>>>>>>>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> George Tsirtsis escribi=C3=B3: >>>>>>>>>> >>>>>>>>>>> Hi Conny, >>>>>>>>>>> >>>>>>>>>>> Good to see you are resurrecting this draft. I think we =20 >>>>>>>>>>> need this >>>>>>>>>>> as >>>>>>>>>>> one of the alternatives. We also need a binary version =20 >>>>>>>>>>> which I >>>>>>>>>>> will be >>>>>>>>>>> working on with others after I am done updating the Flow =20 >>>>>>>>>>> Bindings >>>>>>>>>>> draft. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> could you expand on this? >>>>>>>>>> I mean, are you saying that we need two ways of describing =20= >>>>>>>>>> flows? >>>>>>>>>> >>>>>>>>>> Regards, marcelo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> George >>>>>>>>>>> >>>>>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> This is a request to the MEXT working group to adopt >>>>>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the =20 >>>>>>>>>>>> charter >>>>>>>>>>>> item: >>>>>>>>>>>> >>>>>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>>>>> ... >>>>>>>>>>>> Deliverables related to this include >>>>>>>>>>>> - A "Flow/binding policies exchange" solution for an =20 >>>>>>>>>>>> exchange of >>>>>>>>>>>> policies from the mobile host/router to the Home Agent =20 >>>>>>>>>>>> and from >>>>>>>>>>>> the >>>>>>>>>>>> Home Agent to the mobile host/router influencing the =20 >>>>>>>>>>>> choice of >>>>>>>>>>>> the >>>>>>>>>>>> Care-of Address and Home Agent address. The solution =20 >>>>>>>>>>>> involves two >>>>>>>>>>>> specifications, one for the policy format and another for =20= >>>>>>>>>>>> its >>>>>>>>>>>> transport [both Standard Track]. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The status of the working group is that we have a draft >>>>>>>>>>>> = (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12=20 >>>>>>>>>>>> ) >>>>>>>>>>>> for >>>>>>>>>>>> registration of multiple care-of addresses to one home =20 >>>>>>>>>>>> address. >>>>>>>>>>>> There exist one draft >>>>>>>>>>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-=20 >>>>>>>>>>>> binding-01) for >>>>>>>>>>>> transport >>>>>>>>>>>> of the rules that decides how each flow is sent over the >>>>>>>>>>>> available >>>>>>>>>>>> network >>>>>>>>>>>> interfaces. >>>>>>>>>>>> >>>>>>>>>>>> What is currently missing is the part that defines the =20 >>>>>>>>>>>> rules. >>>>>>>>>>>> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>>>>>> language that >>>>>>>>>>>> can >>>>>>>>>>>> be used for this. The document can be found at: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> = http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>>>>>>>>>> >>>>>>>>>>>> Please express your opinion on whether this should become =20= >>>>>>>>>>>> a WG >>>>>>>>>>>> document. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Conny >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> From ryuji.wakikawa@gmail.com Thu Apr 16 21:52:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBBC3A6A39 for ; Thu, 16 Apr 2009 21:52:29 -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 s+00lOjQ4Udd for ; Thu, 16 Apr 2009 21:52:27 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id 8A4B33A6CE9 for ; Thu, 16 Apr 2009 21:52:26 -0700 (PDT) Received: by qyk42 with SMTP id 42so412287qyk.29 for ; Thu, 16 Apr 2009 21:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=PoDOnEtjIfdF77paiskca0NaefA0Pb8VhrKPn8xpx28=; b=lIRqWdrtSZcYKfoWKH+mQ5bxR0d/iPhrRsdxmkhc8kGiEWCYkw57ib1DZgHVyJEd1j uC/JGyXMKVMSt3YOqFXFQGhEFu1930TLOVVGhgPBVn2Owt2mndAHv8YguSVdxEPFqMDD M+Y6fdszfaL6+57f6Tq8+jZfRW1sUkOir8Ofc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=SrmcWDx+KLabGWWnX153CFQX6KBW+p8dnKerQuVJR2Uo25CarD0p+pUVAyI4jk7HqB mG4L4XoTIlJKVRXOeHisOmoOMYLW//SUd4RNqc+OFcnXJ7Avzn2/hjdbd7Jt/mW3z7VZ 4DMbHP7z06tv7r4cSjlm+bsGRCAqr9NPo+JtI= Received: by 10.224.6.136 with SMTP id 8mr2933839qaz.212.1239944018517; Thu, 16 Apr 2009 21:53:38 -0700 (PDT) Received: from ?172.17.191.127? ([208.251.140.35]) by mx.google.com with ESMTPS id 8sm3397627qwj.36.2009.04.16.21.53.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Apr 2009 21:53:38 -0700 (PDT) From: Ryuji Wakikawa To: Hesham Soliman In-Reply-To: References: Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 00:53:36 -0400 X-Mailer: Apple Mail (2.930.3) Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:52:29 -0000 On 2009/04/16, at 19:33, Hesham Soliman wrote: > > > > On 17/04/09 6:06 AM, "Kazuyuki Tasaka" wrote: > >> Hi Marcelo and Ryuji, > > Conny's document only defines generic rule language as >> a mean to > define and perform per flow path selection for a multi-homed node. > I >> think this document can provide static and dynamic configuration >> of > filters. > Flow filters are installed statically at the HA and MN. > > =3D> Which drafts are you talking about? Are you talkig about this = WG's > documents and charter or something that you would like to have? None =20= > of this Conny's draft. The Charter clearly mentioned the policy format. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. > > is in the WG docs or charter. We don't have static rules and draft-=20 > larsson > is not about filter installation, that's done in the flow bindings =20 > draft. If it is static, we need neither a transport protocol nor dynamic =20 installation . As you pointed out, the Conny's draft is not discussed any alternative =20= transport mechanism. regards, ryuji > > > I find this thread very confusing, please read the drafts in question! > > Hesham > > > > On the >> other > hands, in case of dynamic configuration, this document depends on > the >> transport protocol (e.g. flow bindings) to exchange flow filters > with other >> nodes . But the transport protocol is outside the scope of > this document and >> generic rule languages to statically and dynamically > configure are >> difined. > > Regards, tasaka. > > Ryuji Wakikawa Wrote: >> Hi Marcelo, >> >> Well, you >> are not lost, but I was actually lost. >> After reading the spec, they changed >> the draft a lot since I contributed >> to.. >> I asked Tasaka (KDDI guy) to >> explain the position of this draft. >> >> thanks >> ryuji >> >> On 2009/04/16, at >> 12:06, marcelo bagnulo braun wrote: >> >>> now i am lost, i understood that we >> had two ways to dynamically >>> confgure filters, binary and conny's draft and >> that's what we were >>> discussing... didn't thought that it was static versus >> dynamic >>> configuration of filters...so what is it? >>> >>> >>> Ryuji Wakikawa >> escribi=F3: >>>> Hi Marcelo, >>>> >>>> When we have discussed flow management, >> there are two approaches (one >>>> is flow binding). >>>> The other approach is >> to install flow filters statically at the HA >>>> and MN and switch them >> according to binding cache. >>>> >>>> Let's say MN and HA are statically >> configured with these three >>>> filters set. According to binding cache >> database, >>>> each node switch the filter. >>>> >>>> BID1 only -> filter1 >>>> >> BID1 and BID2 -> filter2 >>>> BID2 only -> filter3 >>>> >>>> Flow binding has >> advantages on dynamic updates, but, on the other >>>> hand, some operators >> (let's say KDDI) prefer using >>>> more stable filter. The operator ships the >> terminal with pre-defined >>>> filter rules. The dynamic management leads >> certain overhead, too. >>>> That' why we have this Conny's document. >>>> AFAIK, >> this document does not specify any transport mechanism, but >>>> define only >> syntax of filters. >>>> >>>> Of course, you might use SSL, HTTPs, even flow >> binding (as George >>>> said), and any other mechanism to exchange these >> filters (if you want >>>> dynamic filters exchange). >>>> To define a general >> filter syntax is very useful. This can be >>>> targetted to informational or >> experimental RFC. >>>> >>>> thanks >>>> ryuji >>>> >>>> >>>> On 2009/04/14, at >> 12:35, marcelo bagnulo braun wrote: >>>> >>>>> i wonder if we need the advanced >> features at this point >>>>> I mean, we are just defining this, wouldn't make >> sense to wait and >>>>> see if with the basic procedure is enough and do the >> extnesions >>>>> later? Or is the basic mechanism so limited that is not >> enough to >>>>> handle simple basic scenarios? If that is the case, does it >> makes >>>>> sense to even define it? >>>>> >>>>> Bottom line, we need strong >> reasons to do things in multiple >>>>> different ways. Unless clear reasons >> are described, i fail to see >>>>> why we should standardize multiple >> approaches >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> >>>>> George Tsirtsis >> escribi=F3: >>>>>> Hi Marcelo, >>>>>> >>>>>> In the Monami6 days, the Flow Bindings >> draft used to include a binary >>>>>> Flow Descriptor as part of the FID >> option. >>>>>> This was basically a typical fixed length binary format defining >> a >>>>>> classifier filterm including source and destination addresses, >>>>>> >> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>>>> >> forget something; both IPv4 and IPv6 can be supported with this. >>>>>> >>>>>> >> Some people, however, thought that more flexible FDs should be =20 >> allowed >>>>>> >> and Conny's draft describes a text based format which is clearly more >>>>>> >> flexible but also more verbose. >>>>>> >>>>>> At the time, the WG decided that >> the FD format should be taken out of >>>>>> the Flow Bindings draft. I am not >> sure I like that but this is indeed >>>>>> what happened. >>>>>> So, now the >> Flow Bindings draft allows for different FD formats, but >>>>>> it does not >> define any of them. >>>>>> >>>>>> As a minimum, IMO the protocol should define >> one format as the default >>>>>> that all implementations MUST support, so that >> we can have >>>>>> interoperable implementations. >>>>>> IMO this should be the >> binary format which is the most compact and >>>>>> will work for most of the >> cases anyway. I do not care too much if this >>>>>> is defined in the same or >> on a separate (albeit tightly coupled) >>>>>> drafts. >>>>>> >>>>>> It is also ok >> with me to have other optional formats (like Conny's) >>>>>> for more advanced >> use cases. >>>>>> >>>>>> I hope this helps >>>>>> >>>>>> George >>>>>> >>>>>> Tue, >> Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>>> >> wrote: >>>>>> >>>>>>> George Tsirtsis escribi=F3: >>>>>>> >>>>>>>> Hi >> Conny, >>>>>>>> >>>>>>>> Good to see you are resurrecting this draft. I think we >> need this as >>>>>>>> one of the alternatives. We also need a binary version >> which I >>>>>>>> will be >>>>>>>> working on with others after I am done >> updating the Flow Bindings >>>>>>>> draft. >>>>>>>> >>>>>>>> >>>>>>> could you >> expand on this? >>>>>>> I mean, are you saying that we need two ways of >> describing flows? >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>>> >> Thanks >>>>>>>> George >>>>>>>> >>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny >> Larsson >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> >> Hi, >>>>>>>>> >>>>>>>>> This is a request to the MEXT working group to >> adopt >>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the =20 >>>>>>>>> charter >> >>>>>>>>> item: >>>>>>>>> >>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>> >> ... >>>>>>>>> Deliverables related to this include >>>>>>>>> - A "Flow/binding >> policies exchange" solution for an exchange of >>>>>>>>> policies from the >> mobile host/router to the Home Agent and from the >>>>>>>>> Home Agent to the >> mobile host/router influencing the choice of the >>>>>>>>> Care-of Address and >> Home Agent address. The solution involves two >>>>>>>>> specifications, one for >> the policy format and another for its >>>>>>>>> transport [both Standard >> Track]. >>>>>>>>> >>>>>>>>> >>>>>>>>> The status of the working group is that we >> have a draft >>>>>>>>> >> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>>>>>>> >> registration of multiple care-of addresses to one home address. >>>>>>>>> There >> exist one draft >>>>>>>>> >> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>>>>> >> transport >>>>>>>>> of the rules that decides how each flow is sent over the >> available >>>>>>>>> network >>>>>>>>> interfaces. >>>>>>>>> >>>>>>>>> What is >> currently missing is the part that defines the rules. >>>>>>>>> >> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>>> language >> that >>>>>>>>> can >>>>>>>>> be used for this. The document can be found >> at: >>>>>>>>> >>>>>>>>> >> = http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >> >>>>>>>>> >>>>>>>>> >>>>>>>>> Please express your opinion on whether this should >> become a WG >>>>>>>>> document. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >> Conny >>>>>>>>> >>>>>>>>> >> _______________________________________________ >>>>>>>>> MEXT mailing >> list >>>>>>>>> MEXT@ietf.org >>>>>>>>> >> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> > >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >> _______________________________________________ >>>>> MEXT mailing list >>>>> >> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>> >> >> >> _______________________________________________ >> MEXT mailing list >> >> MEXT@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mext > > > _________________________________ >> ______________ > MEXT mailing >> list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > From hesham@elevatemobile.com Thu Apr 16 21:53:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC4B3A6D3F for ; Thu, 16 Apr 2009 21:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.265, 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 nnLZZOZToM25 for ; Thu, 16 Apr 2009 21:53:09 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id B14423A6889 for ; Thu, 16 Apr 2009 21:53:08 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Lug5c-0000jh-3M; Fri, 17 Apr 2009 14:54:12 +1000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 17 Apr 2009 14:54:01 +1100 From: Hesham Soliman To: Kazuyuki Tasaka Message-ID: Thread-Topic: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules Thread-Index: Acm/GIZLjMcFWavndUuLFq0y727Cjg== In-Reply-To: <49E808A2.70600@kddilabs.jp> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:53:11 -0000 >> Conny's document only defines generic rule language as >>> a mean to >> define and perform per flow path selection for a multi-homed node. >> I >>> think this document can provide static and dynamic configuration >>> of >> filters. >> Flow filters are installed statically at the HA and MN. >>=20 >> =3D> Which drafts are you talking about? Are you talkig about this WG's >> documents and charter or something that you would like to have? None of = this >> is in the WG docs or charter. We don't have static rules and draft-larss= on >> is not about filter installation, that's done in the flow bindings draft= . >=20 > I taked about the position of draft-larsson. > But, there was a lack of talk. > This is one use case of filter rules defined in draft-larsson. > For example, when some operators prefer using more stable filter, > operator ships the terminal with pre-defined filter rules. =3D> I don't think it makes sense for someone to have predefined filters because the interface selection, by nature, is a dynamic and iterative process. Anyway, people can do what they like in their networks but the discussion in this WG, based on it's charter, is related to producing two docs: 1. Flow bindings. This is a WG draft 2. Filter description. Draft-larsson does that So please be clear in the discussion on whether you want to add a new charter item or you're discussing the current drafts, because the current drafts don't do what you're talking about and it's confusing to have this discussion on a thread about the current drafts. Hesham >=20 > Regards, tasaka. >=20 >> I find this thread very confusing, please read the drafts in question! >>=20 >> Hesham >>=20 >>=20 >>=20 >> On the=20 >>> other >> hands, in case of dynamic configuration, this document depends on >> the >>> transport protocol (e.g. flow bindings) to exchange flow filters >> with other >>> nodes . But the transport protocol is outside the scope of >> this document and >>> generic rule languages to statically and dynamically >> configure are >>> difined. >>=20 >> Regards, tasaka. >>=20 >> Ryuji Wakikawa Wrote: >>> Hi Marcelo, >>>=20 >>> Well, you >>> are not lost, but I was actually lost. >>> After reading the spec, they changed >>> the draft a lot since I contributed >>> to.. >>> I asked Tasaka (KDDI guy) to >>> explain the position of this draft. >>>=20 >>> thanks >>> ryuji >>>=20 >>> On 2009/04/16, at >>> 12:06, marcelo bagnulo braun wrote: >>>=20 >>>> now i am lost, i understood that we >>> had two ways to dynamically >>>> confgure filters, binary and conny's draft and >>> that's what we were >>>> discussing... didn't thought that it was static versus >>> dynamic=20 >>>> configuration of filters...so what is it? >>>>=20 >>>>=20 >>>> Ryuji Wakikawa >>> escribi=F3: >>>>> Hi Marcelo, >>>>>=20 >>>>> When we have discussed flow management, >>> there are two approaches (one >>>>> is flow binding). >>>>> The other approach is >>> to install flow filters statically at the HA >>>>> and MN and switch them >>> according to binding cache. >>>>> Let's say MN and HA are statically >>> configured with these three >>>>> filters set. According to binding cache >>> database, >>>>> each node switch the filter. >>>>>=20 >>>>> BID1 only -> filter1 >>>>>=20 >>> BID1 and BID2 -> filter2 >>>>> BID2 only -> filter3 >>>>>=20 >>>>> Flow binding has >>> advantages on dynamic updates, but, on the other >>>>> hand, some operators >>> (let's say KDDI) prefer using >>>>> more stable filter. The operator ships the >>> terminal with pre-defined >>>>> filter rules. The dynamic management leads >>> certain overhead, too. >>>>> That' why we have this Conny's document. >>>>> AFAIK, >>> this document does not specify any transport mechanism, but >>>>> define only >>> syntax of filters. >>>>> Of course, you might use SSL, HTTPs, even flow >>> binding (as George >>>>> said), and any other mechanism to exchange these >>> filters (if you want >>>>> dynamic filters exchange). >>>>> To define a general >>> filter syntax is very useful. This can be >>>>> targetted to informational or >>> experimental RFC. >>>>> thanks >>>>> ryuji >>>>>=20 >>>>>=20 >>>>> On 2009/04/14, at >>> 12:35, marcelo bagnulo braun wrote: >>>>>> i wonder if we need the advanced >>> features at this point >>>>>> I mean, we are just defining this, wouldn't make >>> sense to wait and >>>>>> see if with the basic procedure is enough and do the >>> extnesions=20 >>>>>> later? Or is the basic mechanism so limited that is not >>> enough to=20 >>>>>> handle simple basic scenarios? If that is the case, does it >>> makes=20 >>>>>> sense to even define it? >>>>>>=20 >>>>>> Bottom line, we need strong >>> reasons to do things in multiple >>>>>> different ways. Unless clear reasons >>> are described, i fail to see >>>>>> why we should standardize multiple >>> approaches >>>>>> Regards, marcelo >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> George Tsirtsis >>> escribi=F3: >>>>>>> Hi Marcelo, >>>>>>>=20 >>>>>>> In the Monami6 days, the Flow Bindings >>> draft used to include a binary >>>>>>> Flow Descriptor as part of the FID >>> option. >>>>>>> This was basically a typical fixed length binary format defining >>> a >>>>>>> classifier filterm including source and destination addresses, >>>>>>>=20 >>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>> forget something; both IPv4 and IPv6 can be supported with this. >>>>>>>=20 >>> Some people, however, thought that more flexible FDs should be allowed >>> and Conny's draft describes a text based format which is clearly more >>> flexible but also more verbose. >>>>>>> At the time, the WG decided that >>> the FD format should be taken out of >>>>>>> the Flow Bindings draft. I am not >>> sure I like that but this is indeed >>>>>>> what happened. >>>>>>> So, now the >>> Flow Bindings draft allows for different FD formats, but >>>>>>> it does not >>> define any of them. >>>>>>> As a minimum, IMO the protocol should define >>> one format as the default >>>>>>> that all implementations MUST support, so that >>> we can have >>>>>>> interoperable implementations. >>>>>>> IMO this should be the >>> binary format which is the most compact and >>>>>>> will work for most of the >>> cases anyway. I do not care too much if this >>>>>>> is defined in the same or >>> on a separate (albeit tightly coupled) >>>>>>> drafts. >>>>>>>=20 >>>>>>> It is also ok >>> with me to have other optional formats (like Conny's) >>>>>>> for more advanced >>> use cases. >>>>>>> I hope this helps >>>>>>>=20 >>>>>>> George >>>>>>>=20 >>>>>>> Tue, >>> Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>>>> >>> wrote: >>>>>>>> George Tsirtsis escribi=F3: >>>>>>>>=20 >>>>>>>>> Hi >>> Conny, >>>>>>>>> Good to see you are resurrecting this draft. I think we >>> need this as >>>>>>>>> one of the alternatives. We also need a binary version >>> which I=20 >>>>>>>>> will be >>>>>>>>> working on with others after I am done >>> updating the Flow Bindings >>>>>>>>> draft. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>> could you >>> expand on this? >>>>>>>> I mean, are you saying that we need two ways of >>> describing flows? >>>>>>>> Regards, marcelo >>>>>>>>=20 >>>>>>>>=20 >>> Thanks >>>>>>>>> George >>>>>>>>>=20 >>>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny >>> Larsson >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>> Hi, >>>>>>>>>> This is a request to the MEXT working group to >>> adopt >>>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the charter >>>>>>>>>> item: >>>>>>>>>>=20 >>>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>>>=20 >>> ... >>>>>>>>>> Deliverables related to this include >>>>>>>>>> - A "Flow/binding >>> policies exchange" solution for an exchange of >>>>>>>>>> policies from the >>> mobile host/router to the Home Agent and from the >>>>>>>>>> Home Agent to the >>> mobile host/router influencing the choice of the >>>>>>>>>> Care-of Address and >>> Home Agent address. The solution involves two >>>>>>>>>> specifications, one for >>> the policy format and another for its >>>>>>>>>> transport [both Standard >>> Track]. >>>>>>>>>>=20 >>>>>>>>>> The status of the working group is that we >>> have a draft >>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>> registration of multiple care-of addresses to one home address. >>>>>>>>>> There >>> exist one draft >>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>> transport >>>>>>>>>> of the rules that decides how each flow is sent over the >>> available >>>>>>>>>> network >>>>>>>>>> interfaces. >>>>>>>>>>=20 >>>>>>>>>> What is >>> currently missing is the part that defines the rules. >>> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>>>> language >>> that >>>>>>>>>> can >>>>>>>>>> be used for this. The document can be found >>> at: >>>>>>>>>>=20 >>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-0= 2 >>>=20 >>>>>>>>>>=20 >>>>>>>>>> Please express your opinion on whether this should >>> become a WG=20 >>>>>>>>>> document. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards >>>>>>>>>>=20 >>> Conny >>>>>>>>>>=20 >>> _______________________________________________ >>>>>>>>>> MEXT mailing >>> list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>>=20 >>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>=20 >>>>>>>>>>=20 >>=20 >>>>>>>=20 >>>>>>=20 >>> _______________________________________________ >>>>>> MEXT mailing list >>>>>>=20 >>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>>=20 >>> MEXT@ietf.org >>>=20 >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >>=20 >> _________________________________ >>> ______________ >> MEXT mailing >>> list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 From hesham@elevatemobile.com Thu Apr 16 21:56:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482D23A6DCE for ; Thu, 16 Apr 2009 21:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 5X3ksr+LKp7W for ; Thu, 16 Apr 2009 21:56:13 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 6B31E3A6D29 for ; Thu, 16 Apr 2009 21:56:12 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Lug8e-0000st-4u; Fri, 17 Apr 2009 14:57:20 +1000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 17 Apr 2009 14:57:15 +1100 From: Hesham Soliman To: Ryuji Wakikawa Message-ID: Thread-Topic: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules Thread-Index: Acm/GPntJ4SHQv3xMEa7HCipzIx4Xw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:56:17 -0000 >>> think this document can provide static and dynamic configuration >>> of >> filters. >> Flow filters are installed statically at the HA and MN. >>=20 >> =3D> Which drafts are you talking about? Are you talkig about this WG's >> documents and charter or something that you would like to have? None >> of this >=20 > Conny's draft. =3D> It doesn't talk about static and dynamic, and it shouldn't! It's about filter descriptions. >=20 > The Charter clearly mentioned the policy format. >=20 > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. =3D> Yes I read it. >=20 >>=20 >> is in the WG docs or charter. We don't have static rules and draft- >> larsson >> is not about filter installation, that's done in the flow bindings >> draft. >=20 > If it is static, we need neither a transport protocol nor dynamic > installation . > As you pointed out, the Conny's draft is not discussed any alternative > transport mechanism. =3D> Exactly, so can we please keep this thread about the drafts in question instead of losing track by adding unrelated topics? If you want to statically define things (very strange but it's up to you) that's fine, but this is not what we're doing in this WG. Hesham >=20 > regards, > ryuji >=20 >>=20 >>=20 >> I find this thread very confusing, please read the drafts in question! >>=20 >> Hesham >>=20 >>=20 >>=20 >> On the >>> other >> hands, in case of dynamic configuration, this document depends on >> the >>> transport protocol (e.g. flow bindings) to exchange flow filters >> with other >>> nodes . But the transport protocol is outside the scope of >> this document and >>> generic rule languages to statically and dynamically >> configure are >>> difined. >>=20 >> Regards, tasaka. >>=20 >> Ryuji Wakikawa Wrote: >>> Hi Marcelo, >>>=20 >>> Well, you >>> are not lost, but I was actually lost. >>> After reading the spec, they changed >>> the draft a lot since I contributed >>> to.. >>> I asked Tasaka (KDDI guy) to >>> explain the position of this draft. >>>=20 >>> thanks >>> ryuji >>>=20 >>> On 2009/04/16, at >>> 12:06, marcelo bagnulo braun wrote: >>>=20 >>>> now i am lost, i understood that we >>> had two ways to dynamically >>>> confgure filters, binary and conny's draft and >>> that's what we were >>>> discussing... didn't thought that it was static versus >>> dynamic >>>> configuration of filters...so what is it? >>>>=20 >>>>=20 >>>> Ryuji Wakikawa >>> escribi=F3: >>>>> Hi Marcelo, >>>>>=20 >>>>> When we have discussed flow management, >>> there are two approaches (one >>>>> is flow binding). >>>>> The other approach is >>> to install flow filters statically at the HA >>>>> and MN and switch them >>> according to binding cache. >>>>>=20 >>>>> Let's say MN and HA are statically >>> configured with these three >>>>> filters set. According to binding cache >>> database, >>>>> each node switch the filter. >>>>>=20 >>>>> BID1 only -> filter1 >>>>>=20 >>> BID1 and BID2 -> filter2 >>>>> BID2 only -> filter3 >>>>>=20 >>>>> Flow binding has >>> advantages on dynamic updates, but, on the other >>>>> hand, some operators >>> (let's say KDDI) prefer using >>>>> more stable filter. The operator ships the >>> terminal with pre-defined >>>>> filter rules. The dynamic management leads >>> certain overhead, too. >>>>> That' why we have this Conny's document. >>>>> AFAIK, >>> this document does not specify any transport mechanism, but >>>>> define only >>> syntax of filters. >>>>>=20 >>>>> Of course, you might use SSL, HTTPs, even flow >>> binding (as George >>>>> said), and any other mechanism to exchange these >>> filters (if you want >>>>> dynamic filters exchange). >>>>> To define a general >>> filter syntax is very useful. This can be >>>>> targetted to informational or >>> experimental RFC. >>>>>=20 >>>>> thanks >>>>> ryuji >>>>>=20 >>>>>=20 >>>>> On 2009/04/14, at >>> 12:35, marcelo bagnulo braun wrote: >>>>>=20 >>>>>> i wonder if we need the advanced >>> features at this point >>>>>> I mean, we are just defining this, wouldn't make >>> sense to wait and >>>>>> see if with the basic procedure is enough and do the >>> extnesions >>>>>> later? Or is the basic mechanism so limited that is not >>> enough to >>>>>> handle simple basic scenarios? If that is the case, does it >>> makes >>>>>> sense to even define it? >>>>>>=20 >>>>>> Bottom line, we need strong >>> reasons to do things in multiple >>>>>> different ways. Unless clear reasons >>> are described, i fail to see >>>>>> why we should standardize multiple >>> approaches >>>>>>=20 >>>>>> Regards, marcelo >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> George Tsirtsis >>> escribi=F3: >>>>>>> Hi Marcelo, >>>>>>>=20 >>>>>>> In the Monami6 days, the Flow Bindings >>> draft used to include a binary >>>>>>> Flow Descriptor as part of the FID >>> option. >>>>>>> This was basically a typical fixed length binary format defining >>> a >>>>>>> classifier filterm including source and destination addresses, >>>>>>>=20 >>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>>>>>=20 >>> forget something; both IPv4 and IPv6 can be supported with this. >>>>>>>=20 >>>>>>>=20 >>> Some people, however, thought that more flexible FDs should be >>> allowed >>>>>>>=20 >>> and Conny's draft describes a text based format which is clearly more >>>>>>>=20 >>> flexible but also more verbose. >>>>>>>=20 >>>>>>> At the time, the WG decided that >>> the FD format should be taken out of >>>>>>> the Flow Bindings draft. I am not >>> sure I like that but this is indeed >>>>>>> what happened. >>>>>>> So, now the >>> Flow Bindings draft allows for different FD formats, but >>>>>>> it does not >>> define any of them. >>>>>>>=20 >>>>>>> As a minimum, IMO the protocol should define >>> one format as the default >>>>>>> that all implementations MUST support, so that >>> we can have >>>>>>> interoperable implementations. >>>>>>> IMO this should be the >>> binary format which is the most compact and >>>>>>> will work for most of the >>> cases anyway. I do not care too much if this >>>>>>> is defined in the same or >>> on a separate (albeit tightly coupled) >>>>>>> drafts. >>>>>>>=20 >>>>>>> It is also ok >>> with me to have other optional formats (like Conny's) >>>>>>> for more advanced >>> use cases. >>>>>>>=20 >>>>>>> I hope this helps >>>>>>>=20 >>>>>>> George >>>>>>>=20 >>>>>>> Tue, >>> Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>>>> >>> wrote: >>>>>>>=20 >>>>>>>> George Tsirtsis escribi=F3: >>>>>>>>=20 >>>>>>>>> Hi >>> Conny, >>>>>>>>>=20 >>>>>>>>> Good to see you are resurrecting this draft. I think we >>> need this as >>>>>>>>> one of the alternatives. We also need a binary version >>> which I >>>>>>>>> will be >>>>>>>>> working on with others after I am done >>> updating the Flow Bindings >>>>>>>>> draft. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>> could you >>> expand on this? >>>>>>>> I mean, are you saying that we need two ways of >>> describing flows? >>>>>>>>=20 >>>>>>>> Regards, marcelo >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>> Thanks >>>>>>>>> George >>>>>>>>>=20 >>>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny >>> Larsson >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>> Hi, >>>>>>>>>>=20 >>>>>>>>>> This is a request to the MEXT working group to >>> adopt >>>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the >>>>>>>>>> charter >>>=20 >>>>>>>>>> item: >>>>>>>>>>=20 >>>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>>>=20 >>> ... >>>>>>>>>> Deliverables related to this include >>>>>>>>>> - A "Flow/binding >>> policies exchange" solution for an exchange of >>>>>>>>>> policies from the >>> mobile host/router to the Home Agent and from the >>>>>>>>>> Home Agent to the >>> mobile host/router influencing the choice of the >>>>>>>>>> Care-of Address and >>> Home Agent address. The solution involves two >>>>>>>>>> specifications, one for >>> the policy format and another for its >>>>>>>>>> transport [both Standard >>> Track]. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The status of the working group is that we >>> have a draft >>>>>>>>>>=20 >>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>>>>>>>>=20 >>> registration of multiple care-of addresses to one home address. >>>>>>>>>> There >>> exist one draft >>>>>>>>>>=20 >>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>>>>>>=20 >>> transport >>>>>>>>>> of the rules that decides how each flow is sent over the >>> available >>>>>>>>>> network >>>>>>>>>> interfaces. >>>>>>>>>>=20 >>>>>>>>>> What is >>> currently missing is the part that defines the rules. >>>>>>>>>>=20 >>> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>>>> language >>> that >>>>>>>>>> can >>>>>>>>>> be used for this. The document can be found >>> at: >>>>>>>>>>=20 >>>>>>>>>>=20 >>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-0= 2 >>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Please express your opinion on whether this should >>> become a WG >>>>>>>>>> document. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards >>>>>>>>>>=20 >>> Conny >>>>>>>>>>=20 >>>>>>>>>>=20 >>> _______________________________________________ >>>>>>>>>> MEXT mailing >>> list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>>=20 >>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>> _______________________________________________ >>>>>> MEXT mailing list >>>>>>=20 >>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>>=20 >>> MEXT@ietf.org >>>=20 >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >>=20 >> _________________________________ >>> ______________ >> MEXT mailing >>> list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >>=20 >>=20 >>=20 >=20 From ryuji.wakikawa@gmail.com Thu Apr 16 22:03:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646553A67F3 for ; Thu, 16 Apr 2009 22:03:42 -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 7-Dz6-aMi0XA for ; Thu, 16 Apr 2009 22:03:40 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 99B213A695C for ; Thu, 16 Apr 2009 22:03:40 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so673047qwb.31 for ; Thu, 16 Apr 2009 22:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=eUj2ng/NIs+QH59lzsT0m3hSdpDgyRa8fh9gWXBK5pA=; b=SENrlgepEIry0qScgPrTB4UDcATH4cxlwyanidbvF+efJXujtVdnlzyXxwN1m0nb0g WgkEQNhD5PTT4mnHWnRj9xrqDfh4XGcbo0HYXMDhuZFFsRp/EZN/AwZ2/IXwi1mIxBXU uN0BhpWiEcXAwBBYtYZSrZrk8eEsIu5tObRvE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=djsi/f6ft3yxX2GIysPB2xUGb7gjAm5A4rZkJPZveNga6BgKsNEA/7P7iz6yEqzSM3 ttnb7pZMaTPGis/7j+Zqqhb/gmcbjHHrBKUGonqwrEqPLOOx+LgE1p/sv/DtH7ICFejK 0eNPpKXgc/daThWCNPi2JK3upf7DW54NRKin8= Received: by 10.224.54.76 with SMTP id p12mr2942511qag.101.1239944693840; Thu, 16 Apr 2009 22:04:53 -0700 (PDT) Received: from ?172.17.191.127? ([208.251.140.35]) by mx.google.com with ESMTPS id 5sm319055qwg.37.2009.04.16.22.04.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Apr 2009 22:04:53 -0700 (PDT) From: Ryuji Wakikawa To: Hesham Soliman In-Reply-To: References: Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 01:04:51 -0400 X-Mailer: Apple Mail (2.930.3) Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:03:42 -0000 On 2009/04/16, at 23:57, Hesham Soliman wrote: > > >>>> think this document can provide static and dynamic configuration >>>> of >>> filters. >>> Flow filters are installed statically at the HA and MN. >>> >>> =3D> Which drafts are you talking about? Are you talkig about this =20= >>> WG's >>> documents and charter or something that you would like to have? None >>> of this >> >> Conny's draft. > > =3D> It doesn't talk about static and dynamic, and it shouldn't! It's =20= > about > filter descriptions. > >> >> The Charter clearly mentioned the policy format. >> >> - A "Flow/binding policies exchange" solution for an exchange of >> policies from the mobile host/router to the Home Agent and from the >> Home Agent to the mobile host/router influencing the choice of the >> Care-of Address and Home Agent address. The solution involves two >> specifications, one for the policy format and another for its >> transport [both Standard Track]. > > =3D> Yes I read it. > >> >>> >>> is in the WG docs or charter. We don't have static rules and draft- >>> larsson >>> is not about filter installation, that's done in the flow bindings >>> draft. >> >> If it is static, we need neither a transport protocol nor dynamic >> installation . >> As you pointed out, the Conny's draft is not discussed any =20 >> alternative >> transport mechanism. > > =3D> Exactly, so can we please keep this thread about the drafts in =20= > question > instead of losing track by adding unrelated topics? If you want to > statically define things (very strange but it's up to you) that's =20 > fine, but > this is not what we're doing in this WG. There is use-case and one operator shows their interests, even though =20= you feel it's strange. What we have discussed here is the need of this document. Why not discussing the use case of this document? It's related to the =20= topic. This discussion will help to see certain motivation to have separate =20 document for filters syntax. ryuji > > > Hesham > >> >> regards, >> ryuji >> >>> >>> >>> I find this thread very confusing, please read the drafts in =20 >>> question! >>> >>> Hesham >>> >>> >>> >>> On the >>>> other >>> hands, in case of dynamic configuration, this document depends on >>> the >>>> transport protocol (e.g. flow bindings) to exchange flow filters >>> with other >>>> nodes . But the transport protocol is outside the scope of >>> this document and >>>> generic rule languages to statically and dynamically >>> configure are >>>> difined. >>> >>> Regards, tasaka. >>> >>> Ryuji Wakikawa Wrote: >>>> Hi Marcelo, >>>> >>>> Well, you >>>> are not lost, but I was actually lost. >>>> After reading the spec, they changed >>>> the draft a lot since I contributed >>>> to.. >>>> I asked Tasaka (KDDI guy) to >>>> explain the position of this draft. >>>> >>>> thanks >>>> ryuji >>>> >>>> On 2009/04/16, at >>>> 12:06, marcelo bagnulo braun wrote: >>>> >>>>> now i am lost, i understood that we >>>> had two ways to dynamically >>>>> confgure filters, binary and conny's draft and >>>> that's what we were >>>>> discussing... didn't thought that it was static versus >>>> dynamic >>>>> configuration of filters...so what is it? >>>>> >>>>> >>>>> Ryuji Wakikawa >>>> escribi=F3: >>>>>> Hi Marcelo, >>>>>> >>>>>> When we have discussed flow management, >>>> there are two approaches (one >>>>>> is flow binding). >>>>>> The other approach is >>>> to install flow filters statically at the HA >>>>>> and MN and switch them >>>> according to binding cache. >>>>>> >>>>>> Let's say MN and HA are statically >>>> configured with these three >>>>>> filters set. According to binding cache >>>> database, >>>>>> each node switch the filter. >>>>>> >>>>>> BID1 only -> filter1 >>>>>> >>>> BID1 and BID2 -> filter2 >>>>>> BID2 only -> filter3 >>>>>> >>>>>> Flow binding has >>>> advantages on dynamic updates, but, on the other >>>>>> hand, some operators >>>> (let's say KDDI) prefer using >>>>>> more stable filter. The operator ships the >>>> terminal with pre-defined >>>>>> filter rules. The dynamic management leads >>>> certain overhead, too. >>>>>> That' why we have this Conny's document. >>>>>> AFAIK, >>>> this document does not specify any transport mechanism, but >>>>>> define only >>>> syntax of filters. >>>>>> >>>>>> Of course, you might use SSL, HTTPs, even flow >>>> binding (as George >>>>>> said), and any other mechanism to exchange these >>>> filters (if you want >>>>>> dynamic filters exchange). >>>>>> To define a general >>>> filter syntax is very useful. This can be >>>>>> targetted to informational or >>>> experimental RFC. >>>>>> >>>>>> thanks >>>>>> ryuji >>>>>> >>>>>> >>>>>> On 2009/04/14, at >>>> 12:35, marcelo bagnulo braun wrote: >>>>>> >>>>>>> i wonder if we need the advanced >>>> features at this point >>>>>>> I mean, we are just defining this, wouldn't make >>>> sense to wait and >>>>>>> see if with the basic procedure is enough and do the >>>> extnesions >>>>>>> later? Or is the basic mechanism so limited that is not >>>> enough to >>>>>>> handle simple basic scenarios? If that is the case, does it >>>> makes >>>>>>> sense to even define it? >>>>>>> >>>>>>> Bottom line, we need strong >>>> reasons to do things in multiple >>>>>>> different ways. Unless clear reasons >>>> are described, i fail to see >>>>>>> why we should standardize multiple >>>> approaches >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>> >>>>>>> George Tsirtsis >>>> escribi=F3: >>>>>>>> Hi Marcelo, >>>>>>>> >>>>>>>> In the Monami6 days, the Flow Bindings >>>> draft used to include a binary >>>>>>>> Flow Descriptor as part of the FID >>>> option. >>>>>>>> This was basically a typical fixed length binary format =20 >>>>>>>> defining >>>> a >>>>>>>> classifier filterm including source and destination addresses, >>>>>>>> >>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>>>>>> >>>> forget something; both IPv4 and IPv6 can be supported with this. >>>>>>>> >>>>>>>> >>>> Some people, however, thought that more flexible FDs should be >>>> allowed >>>>>>>> >>>> and Conny's draft describes a text based format which is clearly =20= >>>> more >>>>>>>> >>>> flexible but also more verbose. >>>>>>>> >>>>>>>> At the time, the WG decided that >>>> the FD format should be taken out of >>>>>>>> the Flow Bindings draft. I am not >>>> sure I like that but this is indeed >>>>>>>> what happened. >>>>>>>> So, now the >>>> Flow Bindings draft allows for different FD formats, but >>>>>>>> it does not >>>> define any of them. >>>>>>>> >>>>>>>> As a minimum, IMO the protocol should define >>>> one format as the default >>>>>>>> that all implementations MUST support, so that >>>> we can have >>>>>>>> interoperable implementations. >>>>>>>> IMO this should be the >>>> binary format which is the most compact and >>>>>>>> will work for most of the >>>> cases anyway. I do not care too much if this >>>>>>>> is defined in the same or >>>> on a separate (albeit tightly coupled) >>>>>>>> drafts. >>>>>>>> >>>>>>>> It is also ok >>>> with me to have other optional formats (like Conny's) >>>>>>>> for more advanced >>>> use cases. >>>>>>>> >>>>>>>> I hope this helps >>>>>>>> >>>>>>>> George >>>>>>>> >>>>>>>> Tue, >>>> Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>>>>> >>>> wrote: >>>>>>>> >>>>>>>>> George Tsirtsis escribi=F3: >>>>>>>>> >>>>>>>>>> Hi >>>> Conny, >>>>>>>>>> >>>>>>>>>> Good to see you are resurrecting this draft. I think we >>>> need this as >>>>>>>>>> one of the alternatives. We also need a binary version >>>> which I >>>>>>>>>> will be >>>>>>>>>> working on with others after I am done >>>> updating the Flow Bindings >>>>>>>>>> draft. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> could you >>>> expand on this? >>>>>>>>> I mean, are you saying that we need two ways of >>>> describing flows? >>>>>>>>> >>>>>>>>> Regards, marcelo >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>> Thanks >>>>>>>>>> George >>>>>>>>>> >>>>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny >>>> Larsson >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This is a request to the MEXT working group to >>>> adopt >>>>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the >>>>>>>>>>> charter >>>> >>>>>>>>>>> item: >>>>>>>>>>> >>>>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>>>> >>>> ... >>>>>>>>>>> Deliverables related to this include >>>>>>>>>>> - A "Flow/binding >>>> policies exchange" solution for an exchange of >>>>>>>>>>> policies from the >>>> mobile host/router to the Home Agent and from the >>>>>>>>>>> Home Agent to the >>>> mobile host/router influencing the choice of the >>>>>>>>>>> Care-of Address and >>>> Home Agent address. The solution involves two >>>>>>>>>>> specifications, one for >>>> the policy format and another for its >>>>>>>>>>> transport [both Standard >>>> Track]. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The status of the working group is that we >>>> have a draft >>>>>>>>>>> >>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>>>>>>>>> >>>> registration of multiple care-of addresses to one home address. >>>>>>>>>>> There >>>> exist one draft >>>>>>>>>>> >>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>>>>>>> >>>> transport >>>>>>>>>>> of the rules that decides how each flow is sent over the >>>> available >>>>>>>>>>> network >>>>>>>>>>> interfaces. >>>>>>>>>>> >>>>>>>>>>> What is >>>> currently missing is the part that defines the rules. >>>>>>>>>>> >>>> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>>>>> language >>>> that >>>>>>>>>>> can >>>>>>>>>>> be used for this. The document can be found >>>> at: >>>>>>>>>>> >>>>>>>>>>> >>>> = http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please express your opinion on whether this should >>>> become a WG >>>>>>>>>>> document. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>> Conny >>>>>>>>>>> >>>>>>>>>>> >>>> _______________________________________________ >>>>>>>>>>> MEXT mailing >>>> list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> >>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> >>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> >>>> MEXT@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> _________________________________ >>>> ______________ >>> MEXT mailing >>>> list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >> > > From ka-tasaka@kddilabs.jp Thu Apr 16 22:08:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D1A3A6DCE for ; Thu, 16 Apr 2009 22:08:18 -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 Se4lYwvQfThR for ; Thu, 16 Apr 2009 22:08:16 -0700 (PDT) Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id EE7423A6D61 for ; Thu, 16 Apr 2009 22:08:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 7C7D1EC88A; Fri, 17 Apr 2009 14:09:28 +0900 (JST) Received: from spears.ast.kddilabs.jp (unknown [2001:200:601:800::168]) by mandala.kddilabs.jp (Postfix) with ESMTP id 16C1DEC8C5; Fri, 17 Apr 2009 14:09:27 +0900 (JST) Received: from [127.0.0.1] (ova158.vpn.kddilabs.jp [172.19.112.158]) by spears.ast.kddilabs.jp (Postfix) with ESMTP id EF1631F0007; Fri, 17 Apr 2009 14:09:22 +0900 (JST) Message-ID: <49E80EFF.20306@kddilabs.jp> Date: Fri, 17 Apr 2009 14:09:19 +0900 From: Kazuyuki Tasaka User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:08:18 -0000 Hi Hesham, Hesham Soliman Wrote: >=20 >>> Conny's document only defines generic rule language as >>>> a mean to >>> define and perform per flow path selection for a multi-homed node. >>> I >>>> think this document can provide static and dynamic configuration >>>> of >>> filters. >>> Flow filters are installed statically at the HA and MN. >>> >>> =3D> Which drafts are you talking about? Are you talkig about this WG= 's >>> documents and charter or something that you would like to have? None = of this >>> is in the WG docs or charter. We don't have static rules and draft-la= rsson >>> is not about filter installation, that's done in the flow bindings dr= aft. >> I taked about the position of draft-larsson. >> But, there was a lack of talk. >> This is one use case of filter rules defined in draft-larsson. >> For example, when some operators prefer using more stable filter, >> operator ships the terminal with pre-defined filter rules. >=20 > =3D> I don't think it makes sense for someone to have predefined filter= s > because the interface selection, by nature, is a dynamic and iterative > process. Anyway, people can do what they like in their networks but the > discussion in this WG, based on it's charter, is related to producing t= wo > docs: > 1. Flow bindings. This is a WG draft > 2. Filter description. Draft-larsson does that >=20 > So please be clear in the discussion on whether you want to add a new > charter item or you're discussing the current drafts, because the curre= nt > drafts don't do what you're talking about and it's confusing to have th= is > discussion on a thread about the current drafts. I'm one of authors of draft-larsson. I don't talk about a new charter item and want discuss filter descriptions of the current drafts. Regards, tasaka >=20 > Hesham >> Regards, tasaka. >> >>> I find this thread very confusing, please read the drafts in question= ! >>> >>> Hesham >>> >>> >>> >>> On the=20 >>>> other >>> hands, in case of dynamic configuration, this document depends on >>> the >>>> transport protocol (e.g. flow bindings) to exchange flow filters >>> with other >>>> nodes . But the transport protocol is outside the scope of >>> this document and >>>> generic rule languages to statically and dynamically >>> configure are >>>> difined. >>> Regards, tasaka. >>> >>> Ryuji Wakikawa Wrote: >>>> Hi Marcelo, >>>> >>>> Well, you >>>> are not lost, but I was actually lost. >>>> After reading the spec, they changed >>>> the draft a lot since I contributed >>>> to.. >>>> I asked Tasaka (KDDI guy) to >>>> explain the position of this draft. >>>> >>>> thanks >>>> ryuji >>>> >>>> On 2009/04/16, at >>>> 12:06, marcelo bagnulo braun wrote: >>>> >>>>> now i am lost, i understood that we >>>> had two ways to dynamically >>>>> confgure filters, binary and conny's draft and >>>> that's what we were >>>>> discussing... didn't thought that it was static versus >>>> dynamic=20 >>>>> configuration of filters...so what is it? >>>>> >>>>> >>>>> Ryuji Wakikawa >>>> escribi=F3: >>>>>> Hi Marcelo, >>>>>> >>>>>> When we have discussed flow management, >>>> there are two approaches (one >>>>>> is flow binding). >>>>>> The other approach is >>>> to install flow filters statically at the HA >>>>>> and MN and switch them >>>> according to binding cache. >>>>>> Let's say MN and HA are statically >>>> configured with these three >>>>>> filters set. According to binding cache >>>> database, >>>>>> each node switch the filter. >>>>>> >>>>>> BID1 only -> filter1 >>>>>> >>>> BID1 and BID2 -> filter2 >>>>>> BID2 only -> filter3 >>>>>> >>>>>> Flow binding has >>>> advantages on dynamic updates, but, on the other >>>>>> hand, some operators >>>> (let's say KDDI) prefer using >>>>>> more stable filter. The operator ships the >>>> terminal with pre-defined >>>>>> filter rules. The dynamic management leads >>>> certain overhead, too. >>>>>> That' why we have this Conny's document. >>>>>> AFAIK, >>>> this document does not specify any transport mechanism, but >>>>>> define only >>>> syntax of filters. >>>>>> Of course, you might use SSL, HTTPs, even flow >>>> binding (as George >>>>>> said), and any other mechanism to exchange these >>>> filters (if you want >>>>>> dynamic filters exchange). >>>>>> To define a general >>>> filter syntax is very useful. This can be >>>>>> targetted to informational or >>>> experimental RFC. >>>>>> thanks >>>>>> ryuji >>>>>> >>>>>> >>>>>> On 2009/04/14, at >>>> 12:35, marcelo bagnulo braun wrote: >>>>>>> i wonder if we need the advanced >>>> features at this point >>>>>>> I mean, we are just defining this, wouldn't make >>>> sense to wait and >>>>>>> see if with the basic procedure is enough and do the >>>> extnesions=20 >>>>>>> later? Or is the basic mechanism so limited that is not >>>> enough to=20 >>>>>>> handle simple basic scenarios? If that is the case, does it >>>> makes=20 >>>>>>> sense to even define it? >>>>>>> >>>>>>> Bottom line, we need strong >>>> reasons to do things in multiple >>>>>>> different ways. Unless clear reasons >>>> are described, i fail to see >>>>>>> why we should standardize multiple >>>> approaches >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>> >>>>>>> George Tsirtsis >>>> escribi=F3: >>>>>>>> Hi Marcelo, >>>>>>>> >>>>>>>> In the Monami6 days, the Flow Bindings >>>> draft used to include a binary >>>>>>>> Flow Descriptor as part of the FID >>>> option. >>>>>>>> This was basically a typical fixed length binary format defining >>>> a >>>>>>>> classifier filterm including source and destination addresses, >>>>>>>> >>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>> forget something; both IPv4 and IPv6 can be supported with this. >>>> Some people, however, thought that more flexible FDs should be allow= ed >>>> and Conny's draft describes a text based format which is clearly mor= e >>>> flexible but also more verbose. >>>>>>>> At the time, the WG decided that >>>> the FD format should be taken out of >>>>>>>> the Flow Bindings draft. I am not >>>> sure I like that but this is indeed >>>>>>>> what happened. >>>>>>>> So, now the >>>> Flow Bindings draft allows for different FD formats, but >>>>>>>> it does not >>>> define any of them. >>>>>>>> As a minimum, IMO the protocol should define >>>> one format as the default >>>>>>>> that all implementations MUST support, so that >>>> we can have >>>>>>>> interoperable implementations. >>>>>>>> IMO this should be the >>>> binary format which is the most compact and >>>>>>>> will work for most of the >>>> cases anyway. I do not care too much if this >>>>>>>> is defined in the same or >>>> on a separate (albeit tightly coupled) >>>>>>>> drafts. >>>>>>>> >>>>>>>> It is also ok >>>> with me to have other optional formats (like Conny's) >>>>>>>> for more advanced >>>> use cases. >>>>>>>> I hope this helps >>>>>>>> >>>>>>>> George >>>>>>>> >>>>>>>> Tue, >>>> Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>>>>> >>>> wrote: >>>>>>>>> George Tsirtsis escribi=F3: >>>>>>>>> >>>>>>>>>> Hi >>>> Conny, >>>>>>>>>> Good to see you are resurrecting this draft. I think we >>>> need this as >>>>>>>>>> one of the alternatives. We also need a binary version >>>> which I=20 >>>>>>>>>> will be >>>>>>>>>> working on with others after I am done >>>> updating the Flow Bindings >>>>>>>>>> draft. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> could you >>>> expand on this? >>>>>>>>> I mean, are you saying that we need two ways of >>>> describing flows? >>>>>>>>> Regards, marcelo >>>>>>>>> >>>>>>>>> >>>> Thanks >>>>>>>>>> George >>>>>>>>>> >>>>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny >>>> Larsson >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>> Hi, >>>>>>>>>>> This is a request to the MEXT working group to >>>> adopt >>>>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the chart= er >>>>>>>>>>> item: >>>>>>>>>>> >>>>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>>>> >>>> ... >>>>>>>>>>> Deliverables related to this include >>>>>>>>>>> - A "Flow/binding >>>> policies exchange" solution for an exchange of >>>>>>>>>>> policies from the >>>> mobile host/router to the Home Agent and from the >>>>>>>>>>> Home Agent to the >>>> mobile host/router influencing the choice of the >>>>>>>>>>> Care-of Address and >>>> Home Agent address. The solution involves two >>>>>>>>>>> specifications, one for >>>> the policy format and another for its >>>>>>>>>>> transport [both Standard >>>> Track]. >>>>>>>>>>> The status of the working group is that we >>>> have a draft >>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>> registration of multiple care-of addresses to one home address. >>>>>>>>>>> There >>>> exist one draft >>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>> transport >>>>>>>>>>> of the rules that decides how each flow is sent over the >>>> available >>>>>>>>>>> network >>>>>>>>>>> interfaces. >>>>>>>>>>> >>>>>>>>>>> What is >>>> currently missing is the part that defines the rules. >>>> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>>>>> language >>>> that >>>>>>>>>>> can >>>>>>>>>>> be used for this. The document can be found >>>> at: >>>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rule= s-02 >>>> >>>>>>>>>>> Please express your opinion on whether this should >>>> become a WG=20 >>>>>>>>>>> document. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>> Conny >>>> _______________________________________________ >>>>>>>>>>> MEXT mailing >>>> list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> >>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>> >>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> >>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>> _______________________________________________ >>>> MEXT mailing list >>>> >>>> MEXT@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> _________________________________ >>>> ______________ >>> MEXT mailing >>>> list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> >>> >> >=20 >=20 >=20 >=20 From hesham@elevatemobile.com Thu Apr 16 22:17:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA3528C0EA for ; Thu, 16 Apr 2009 22:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 zkZF6PGB1SI8 for ; Thu, 16 Apr 2009 22:17:16 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 75A553A6935 for ; Thu, 16 Apr 2009 22:17:15 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LugT1-0001uq-G2; Fri, 17 Apr 2009 15:18:24 +1000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 17 Apr 2009 15:18:18 +1100 From: Hesham Soliman To: Ryuji Wakikawa Message-ID: Thread-Topic: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules Thread-Index: Acm/G+q8cKdwALPCaE+bv2UiQmctyw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:17:18 -0000 >> =3D> Exactly, so can we please keep this thread about the drafts in >> question >> instead of losing track by adding unrelated topics? If you want to >> statically define things (very strange but it's up to you) that's >> fine, but >> this is not what we're doing in this WG. >=20 > There is use-case and one operator shows their interests, even though > you feel it's strange. >=20 > What we have discussed here is the need of this document. > Why not discussing the use case of this document? It's related to the > topic. =3D> What is the impact of the scenario you want to support on this doc (draft-larsson)? I mean is there anything that needs to be changed in the draft for this? I find it confusing because you started off saying that this document is an alternate solution to flow bindings, which is not true according to the charter, then you said nothing needs to be done in MEXT to support your scenario. So why are we having this discussion on this thread? > This discussion will help to see certain motivation to have separate > document for filters syntax. =3D> It's 2 years late to have this discussion then! We agreed on a separate draft (draft-larsson) 2 years ago.... Hesham >=20 > ryuji >=20 >=20 >>=20 >>=20 >> Hesham >>=20 >>>=20 >>> regards, >>> ryuji >>>=20 >>>>=20 >>>>=20 >>>> I find this thread very confusing, please read the drafts in >>>> question! >>>>=20 >>>> Hesham >>>>=20 >>>>=20 >>>>=20 >>>> On the >>>>> other >>>> hands, in case of dynamic configuration, this document depends on >>>> the >>>>> transport protocol (e.g. flow bindings) to exchange flow filters >>>> with other >>>>> nodes . But the transport protocol is outside the scope of >>>> this document and >>>>> generic rule languages to statically and dynamically >>>> configure are >>>>> difined. >>>>=20 >>>> Regards, tasaka. >>>>=20 >>>> Ryuji Wakikawa Wrote: >>>>> Hi Marcelo, >>>>>=20 >>>>> Well, you >>>>> are not lost, but I was actually lost. >>>>> After reading the spec, they changed >>>>> the draft a lot since I contributed >>>>> to.. >>>>> I asked Tasaka (KDDI guy) to >>>>> explain the position of this draft. >>>>>=20 >>>>> thanks >>>>> ryuji >>>>>=20 >>>>> On 2009/04/16, at >>>>> 12:06, marcelo bagnulo braun wrote: >>>>>=20 >>>>>> now i am lost, i understood that we >>>>> had two ways to dynamically >>>>>> confgure filters, binary and conny's draft and >>>>> that's what we were >>>>>> discussing... didn't thought that it was static versus >>>>> dynamic >>>>>> configuration of filters...so what is it? >>>>>>=20 >>>>>>=20 >>>>>> Ryuji Wakikawa >>>>> escribi=F3: >>>>>>> Hi Marcelo, >>>>>>>=20 >>>>>>> When we have discussed flow management, >>>>> there are two approaches (one >>>>>>> is flow binding). >>>>>>> The other approach is >>>>> to install flow filters statically at the HA >>>>>>> and MN and switch them >>>>> according to binding cache. >>>>>>>=20 >>>>>>> Let's say MN and HA are statically >>>>> configured with these three >>>>>>> filters set. According to binding cache >>>>> database, >>>>>>> each node switch the filter. >>>>>>>=20 >>>>>>> BID1 only -> filter1 >>>>>>>=20 >>>>> BID1 and BID2 -> filter2 >>>>>>> BID2 only -> filter3 >>>>>>>=20 >>>>>>> Flow binding has >>>>> advantages on dynamic updates, but, on the other >>>>>>> hand, some operators >>>>> (let's say KDDI) prefer using >>>>>>> more stable filter. The operator ships the >>>>> terminal with pre-defined >>>>>>> filter rules. The dynamic management leads >>>>> certain overhead, too. >>>>>>> That' why we have this Conny's document. >>>>>>> AFAIK, >>>>> this document does not specify any transport mechanism, but >>>>>>> define only >>>>> syntax of filters. >>>>>>>=20 >>>>>>> Of course, you might use SSL, HTTPs, even flow >>>>> binding (as George >>>>>>> said), and any other mechanism to exchange these >>>>> filters (if you want >>>>>>> dynamic filters exchange). >>>>>>> To define a general >>>>> filter syntax is very useful. This can be >>>>>>> targetted to informational or >>>>> experimental RFC. >>>>>>>=20 >>>>>>> thanks >>>>>>> ryuji >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2009/04/14, at >>>>> 12:35, marcelo bagnulo braun wrote: >>>>>>>=20 >>>>>>>> i wonder if we need the advanced >>>>> features at this point >>>>>>>> I mean, we are just defining this, wouldn't make >>>>> sense to wait and >>>>>>>> see if with the basic procedure is enough and do the >>>>> extnesions >>>>>>>> later? Or is the basic mechanism so limited that is not >>>>> enough to >>>>>>>> handle simple basic scenarios? If that is the case, does it >>>>> makes >>>>>>>> sense to even define it? >>>>>>>>=20 >>>>>>>> Bottom line, we need strong >>>>> reasons to do things in multiple >>>>>>>> different ways. Unless clear reasons >>>>> are described, i fail to see >>>>>>>> why we should standardize multiple >>>>> approaches >>>>>>>>=20 >>>>>>>> Regards, marcelo >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> George Tsirtsis >>>>> escribi=F3: >>>>>>>>> Hi Marcelo, >>>>>>>>>=20 >>>>>>>>> In the Monami6 days, the Flow Bindings >>>>> draft used to include a binary >>>>>>>>> Flow Descriptor as part of the FID >>>>> option. >>>>>>>>> This was basically a typical fixed length binary format >>>>>>>>> defining >>>>> a >>>>>>>>> classifier filterm including source and destination addresses, >>>>>>>>>=20 >>>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>>>>>>>=20 >>>>> forget something; both IPv4 and IPv6 can be supported with this. >>>>>>>>>=20 >>>>>>>>>=20 >>>>> Some people, however, thought that more flexible FDs should be >>>>> allowed >>>>>>>>>=20 >>>>> and Conny's draft describes a text based format which is clearly >>>>> more >>>>>>>>>=20 >>>>> flexible but also more verbose. >>>>>>>>>=20 >>>>>>>>> At the time, the WG decided that >>>>> the FD format should be taken out of >>>>>>>>> the Flow Bindings draft. I am not >>>>> sure I like that but this is indeed >>>>>>>>> what happened. >>>>>>>>> So, now the >>>>> Flow Bindings draft allows for different FD formats, but >>>>>>>>> it does not >>>>> define any of them. >>>>>>>>>=20 >>>>>>>>> As a minimum, IMO the protocol should define >>>>> one format as the default >>>>>>>>> that all implementations MUST support, so that >>>>> we can have >>>>>>>>> interoperable implementations. >>>>>>>>> IMO this should be the >>>>> binary format which is the most compact and >>>>>>>>> will work for most of the >>>>> cases anyway. I do not care too much if this >>>>>>>>> is defined in the same or >>>>> on a separate (albeit tightly coupled) >>>>>>>>> drafts. >>>>>>>>>=20 >>>>>>>>> It is also ok >>>>> with me to have other optional formats (like Conny's) >>>>>>>>> for more advanced >>>>> use cases. >>>>>>>>>=20 >>>>>>>>> I hope this helps >>>>>>>>>=20 >>>>>>>>> George >>>>>>>>>=20 >>>>>>>>> Tue, >>>>> Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>>>>>> >>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> George Tsirtsis escribi=F3: >>>>>>>>>>=20 >>>>>>>>>>> Hi >>>>> Conny, >>>>>>>>>>>=20 >>>>>>>>>>> Good to see you are resurrecting this draft. I think we >>>>> need this as >>>>>>>>>>> one of the alternatives. We also need a binary version >>>>> which I >>>>>>>>>>> will be >>>>>>>>>>> working on with others after I am done >>>>> updating the Flow Bindings >>>>>>>>>>> draft. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>> could you >>>>> expand on this? >>>>>>>>>> I mean, are you saying that we need two ways of >>>>> describing flows? >>>>>>>>>>=20 >>>>>>>>>> Regards, marcelo >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>> Thanks >>>>>>>>>>> George >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny >>>>> Larsson >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>> This is a request to the MEXT working group to >>>>> adopt >>>>>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the >>>>>>>>>>>> charter >>>>>=20 >>>>>>>>>>>> item: >>>>>>>>>>>>=20 >>>>>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>>>>>=20 >>>>> ... >>>>>>>>>>>> Deliverables related to this include >>>>>>>>>>>> - A "Flow/binding >>>>> policies exchange" solution for an exchange of >>>>>>>>>>>> policies from the >>>>> mobile host/router to the Home Agent and from the >>>>>>>>>>>> Home Agent to the >>>>> mobile host/router influencing the choice of the >>>>>>>>>>>> Care-of Address and >>>>> Home Agent address. The solution involves two >>>>>>>>>>>> specifications, one for >>>>> the policy format and another for its >>>>>>>>>>>> transport [both Standard >>>>> Track]. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The status of the working group is that we >>>>> have a draft >>>>>>>>>>>>=20 >>>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for >>>>>>>>>>>>=20 >>>>> registration of multiple care-of addresses to one home address. >>>>>>>>>>>> There >>>>> exist one draft >>>>>>>>>>>>=20 >>>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>>>>>>>>=20 >>>>> transport >>>>>>>>>>>> of the rules that decides how each flow is sent over the >>>>> available >>>>>>>>>>>> network >>>>>>>>>>>> interfaces. >>>>>>>>>>>>=20 >>>>>>>>>>>> What is >>>>> currently missing is the part that defines the rules. >>>>>>>>>>>>=20 >>>>> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>>>>>> language >>>>> that >>>>>>>>>>>> can >>>>>>>>>>>> be used for this. The document can be found >>>>> at: >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules= -02 >>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Please express your opinion on whether this should >>>>> become a WG >>>>>>>>>>>> document. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards >>>>>>>>>>>>=20 >>>>> Conny >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>> _______________________________________________ >>>>>>>>>>>> MEXT mailing >>>>> list >>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>>=20 >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>>=20 >>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>>=20 >>>>> MEXT@ietf.org >>>>>=20 >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>=20 >>>>=20 >>>> _________________________________ >>>>> ______________ >>>> MEXT mailing >>>>> list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 From ryuji.wakikawa@gmail.com Thu Apr 16 22:31:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81AB03A687B for ; Thu, 16 Apr 2009 22:31:20 -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 XEClN9wWR57f for ; Thu, 16 Apr 2009 22:31:19 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id E9F113A67F3 for ; Thu, 16 Apr 2009 22:31:18 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so680697qwb.31 for ; Thu, 16 Apr 2009 22:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=BFbx1cJgUKgkwTNiV4SJAY4/J8+4V6lO/2QJ+ZlqiwM=; b=HaPUe6HEOHv9Tb3xPJ8w3R07vCQywbWH/h062vcDwr1g5Zx2AocjlKj2Zcfk1cQhYp JfmyGqR8pcqs8l4HoTvgF9qhENn19t9Kqv3AgNL8Fh3riASiCeleYJ93jjV+zJmh+FRm C52oZwOgBUmeWWdXtNjEumq4F7O9IOFmgvVps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=YGmdv+KL3g++34y2pgQVKpN3j61oE2paa0bCBWm5NiJVKp+6n8hTPCMDeu3AtSgPIG xeQaBztpizxBVbFzZQeO2/oiPnl4p9T8lG2085CnYKj/OUbGpVh+gXv+Knwg1d43DHBe XsvpkQBKj9Vlb7KwooDfKLoUro8BtVy5L0Mf4= Received: by 10.224.6.136 with SMTP id 8mr2972716qaz.212.1239946352153; Thu, 16 Apr 2009 22:32:32 -0700 (PDT) Received: from ?172.17.191.127? ([208.251.140.35]) by mx.google.com with ESMTPS id 8sm3467738qwj.16.2009.04.16.22.32.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Apr 2009 22:32:31 -0700 (PDT) From: Ryuji Wakikawa To: Hesham Soliman In-Reply-To: References: Message-Id: <442B8D7F-0015-4E07-A500-FE381E6FA4B8@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 01:32:20 -0400 X-Mailer: Apple Mail (2.930.3) Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:31:20 -0000 On 2009/04/17, at 0:18, Hesham Soliman wrote: > > >>> =3D> Exactly, so can we please keep this thread about the drafts in >>> question >>> instead of losing track by adding unrelated topics? If you want to >>> statically define things (very strange but it's up to you) that's >>> fine, but >>> this is not what we're doing in this WG. >> >> There is use-case and one operator shows their interests, even though >> you feel it's strange. >> >> What we have discussed here is the need of this document. >> Why not discussing the use case of this document? It's related to =20= >> the >> topic. > > =3D> What is the impact of the scenario you want to support on this = doc > (draft-larsson)? I mean is there anything that needs to be changed =20 > in the > draft for this? actually none. > I find it confusing because you started off saying that this =20 > document is an > alternate solution to flow bindings, which is not true according to =20= > the > charter, then you said nothing needs to be done in MEXT to support =20 > your > scenario. So why are we having this discussion on this thread? I stated why I support this document. >> This discussion will help to see certain motivation to have separate >> document for filters syntax. > > =3D> It's 2 years late to have this discussion then! We agreed on a =20= > separate > draft (draft-larsson) 2 years ago.... But unfortunately this document it not yet WG document in these two =20 years. MEXT should work on this item if we have agreement ! ryuji > > > Hesham > >> >> ryuji >> >> >>> >>> >>> Hesham >>> >>>> >>>> regards, >>>> ryuji >>>> >>>>> >>>>> >>>>> I find this thread very confusing, please read the drafts in >>>>> question! >>>>> >>>>> Hesham >>>>> >>>>> >>>>> >>>>> On the >>>>>> other >>>>> hands, in case of dynamic configuration, this document depends on >>>>> the >>>>>> transport protocol (e.g. flow bindings) to exchange flow filters >>>>> with other >>>>>> nodes . But the transport protocol is outside the scope of >>>>> this document and >>>>>> generic rule languages to statically and dynamically >>>>> configure are >>>>>> difined. >>>>> >>>>> Regards, tasaka. >>>>> >>>>> Ryuji Wakikawa Wrote: >>>>>> Hi Marcelo, >>>>>> >>>>>> Well, you >>>>>> are not lost, but I was actually lost. >>>>>> After reading the spec, they changed >>>>>> the draft a lot since I contributed >>>>>> to.. >>>>>> I asked Tasaka (KDDI guy) to >>>>>> explain the position of this draft. >>>>>> >>>>>> thanks >>>>>> ryuji >>>>>> >>>>>> On 2009/04/16, at >>>>>> 12:06, marcelo bagnulo braun wrote: >>>>>> >>>>>>> now i am lost, i understood that we >>>>>> had two ways to dynamically >>>>>>> confgure filters, binary and conny's draft and >>>>>> that's what we were >>>>>>> discussing... didn't thought that it was static versus >>>>>> dynamic >>>>>>> configuration of filters...so what is it? >>>>>>> >>>>>>> >>>>>>> Ryuji Wakikawa >>>>>> escribi=F3: >>>>>>>> Hi Marcelo, >>>>>>>> >>>>>>>> When we have discussed flow management, >>>>>> there are two approaches (one >>>>>>>> is flow binding). >>>>>>>> The other approach is >>>>>> to install flow filters statically at the HA >>>>>>>> and MN and switch them >>>>>> according to binding cache. >>>>>>>> >>>>>>>> Let's say MN and HA are statically >>>>>> configured with these three >>>>>>>> filters set. According to binding cache >>>>>> database, >>>>>>>> each node switch the filter. >>>>>>>> >>>>>>>> BID1 only -> filter1 >>>>>>>> >>>>>> BID1 and BID2 -> filter2 >>>>>>>> BID2 only -> filter3 >>>>>>>> >>>>>>>> Flow binding has >>>>>> advantages on dynamic updates, but, on the other >>>>>>>> hand, some operators >>>>>> (let's say KDDI) prefer using >>>>>>>> more stable filter. The operator ships the >>>>>> terminal with pre-defined >>>>>>>> filter rules. The dynamic management leads >>>>>> certain overhead, too. >>>>>>>> That' why we have this Conny's document. >>>>>>>> AFAIK, >>>>>> this document does not specify any transport mechanism, but >>>>>>>> define only >>>>>> syntax of filters. >>>>>>>> >>>>>>>> Of course, you might use SSL, HTTPs, even flow >>>>>> binding (as George >>>>>>>> said), and any other mechanism to exchange these >>>>>> filters (if you want >>>>>>>> dynamic filters exchange). >>>>>>>> To define a general >>>>>> filter syntax is very useful. This can be >>>>>>>> targetted to informational or >>>>>> experimental RFC. >>>>>>>> >>>>>>>> thanks >>>>>>>> ryuji >>>>>>>> >>>>>>>> >>>>>>>> On 2009/04/14, at >>>>>> 12:35, marcelo bagnulo braun wrote: >>>>>>>> >>>>>>>>> i wonder if we need the advanced >>>>>> features at this point >>>>>>>>> I mean, we are just defining this, wouldn't make >>>>>> sense to wait and >>>>>>>>> see if with the basic procedure is enough and do the >>>>>> extnesions >>>>>>>>> later? Or is the basic mechanism so limited that is not >>>>>> enough to >>>>>>>>> handle simple basic scenarios? If that is the case, does it >>>>>> makes >>>>>>>>> sense to even define it? >>>>>>>>> >>>>>>>>> Bottom line, we need strong >>>>>> reasons to do things in multiple >>>>>>>>> different ways. Unless clear reasons >>>>>> are described, i fail to see >>>>>>>>> why we should standardize multiple >>>>>> approaches >>>>>>>>> >>>>>>>>> Regards, marcelo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> George Tsirtsis >>>>>> escribi=F3: >>>>>>>>>> Hi Marcelo, >>>>>>>>>> >>>>>>>>>> In the Monami6 days, the Flow Bindings >>>>>> draft used to include a binary >>>>>>>>>> Flow Descriptor as part of the FID >>>>>> option. >>>>>>>>>> This was basically a typical fixed length binary format >>>>>>>>>> defining >>>>>> a >>>>>>>>>> classifier filterm including source and destination =20 >>>>>>>>>> addresses, >>>>>>>>>> >>>>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do =20= >>>>>> not >>>>>>>>>> >>>>>> forget something; both IPv4 and IPv6 can be supported with this. >>>>>>>>>> >>>>>>>>>> >>>>>> Some people, however, thought that more flexible FDs should be >>>>>> allowed >>>>>>>>>> >>>>>> and Conny's draft describes a text based format which is clearly >>>>>> more >>>>>>>>>> >>>>>> flexible but also more verbose. >>>>>>>>>> >>>>>>>>>> At the time, the WG decided that >>>>>> the FD format should be taken out of >>>>>>>>>> the Flow Bindings draft. I am not >>>>>> sure I like that but this is indeed >>>>>>>>>> what happened. >>>>>>>>>> So, now the >>>>>> Flow Bindings draft allows for different FD formats, but >>>>>>>>>> it does not >>>>>> define any of them. >>>>>>>>>> >>>>>>>>>> As a minimum, IMO the protocol should define >>>>>> one format as the default >>>>>>>>>> that all implementations MUST support, so that >>>>>> we can have >>>>>>>>>> interoperable implementations. >>>>>>>>>> IMO this should be the >>>>>> binary format which is the most compact and >>>>>>>>>> will work for most of the >>>>>> cases anyway. I do not care too much if this >>>>>>>>>> is defined in the same or >>>>>> on a separate (albeit tightly coupled) >>>>>>>>>> drafts. >>>>>>>>>> >>>>>>>>>> It is also ok >>>>>> with me to have other optional formats (like Conny's) >>>>>>>>>> for more advanced >>>>>> use cases. >>>>>>>>>> >>>>>>>>>> I hope this helps >>>>>>>>>> >>>>>>>>>> George >>>>>>>>>> >>>>>>>>>> Tue, >>>>>> Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>>>>>>> >>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> George Tsirtsis escribi=F3: >>>>>>>>>>> >>>>>>>>>>>> Hi >>>>>> Conny, >>>>>>>>>>>> >>>>>>>>>>>> Good to see you are resurrecting this draft. I think we >>>>>> need this as >>>>>>>>>>>> one of the alternatives. We also need a binary version >>>>>> which I >>>>>>>>>>>> will be >>>>>>>>>>>> working on with others after I am done >>>>>> updating the Flow Bindings >>>>>>>>>>>> draft. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> could you >>>>>> expand on this? >>>>>>>>>>> I mean, are you saying that we need two ways of >>>>>> describing flows? >>>>>>>>>>> >>>>>>>>>>> Regards, marcelo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>> Thanks >>>>>>>>>>>> George >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny >>>>>> Larsson >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> This is a request to the MEXT working group to >>>>>> adopt >>>>>>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the >>>>>>>>>>>>> charter >>>>>> >>>>>>>>>>>>> item: >>>>>>>>>>>>> >>>>>>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>>>>>> >>>>>> ... >>>>>>>>>>>>> Deliverables related to this include >>>>>>>>>>>>> - A "Flow/binding >>>>>> policies exchange" solution for an exchange of >>>>>>>>>>>>> policies from the >>>>>> mobile host/router to the Home Agent and from the >>>>>>>>>>>>> Home Agent to the >>>>>> mobile host/router influencing the choice of the >>>>>>>>>>>>> Care-of Address and >>>>>> Home Agent address. The solution involves two >>>>>>>>>>>>> specifications, one for >>>>>> the policy format and another for its >>>>>>>>>>>>> transport [both Standard >>>>>> Track]. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The status of the working group is that we >>>>>> have a draft >>>>>>>>>>>>> >>>>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) =20= >>>>>> for >>>>>>>>>>>>> >>>>>> registration of multiple care-of addresses to one home address. >>>>>>>>>>>>> There >>>>>> exist one draft >>>>>>>>>>>>> >>>>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>>>>>>>>> >>>>>> transport >>>>>>>>>>>>> of the rules that decides how each flow is sent over the >>>>>> available >>>>>>>>>>>>> network >>>>>>>>>>>>> interfaces. >>>>>>>>>>>>> >>>>>>>>>>>>> What is >>>>>> currently missing is the part that defines the rules. >>>>>>>>>>>>> >>>>>> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>>>>>>> language >>>>>> that >>>>>>>>>>>>> can >>>>>>>>>>>>> be used for this. The document can be found >>>>>> at: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> = http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Please express your opinion on whether this should >>>>>> become a WG >>>>>>>>>>>>> document. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> >>>>>> Conny >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> _______________________________________________ >>>>>>>>>>>>> MEXT mailing >>>>>> list >>>>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> >>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> >>>>>> MEXT@ietf.org >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>>>> _________________________________ >>>>>> ______________ >>>>> MEXT mailing >>>>>> list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>>>> >>>> >>> >>> >> > > From hesham@elevatemobile.com Thu Apr 16 22:49:07 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B28A3A6D2E for ; Thu, 16 Apr 2009 22:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 ijH68Jz5R9sa for ; Thu, 16 Apr 2009 22:49:02 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 790233A69A9 for ; Thu, 16 Apr 2009 22:49:01 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Lugxi-0003Lw-QN; Fri, 17 Apr 2009 15:50:06 +1000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 17 Apr 2009 15:50:02 +1100 From: Hesham Soliman To: Ryuji Wakikawa Message-ID: Thread-Topic: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules Thread-Index: Acm/IFmb/nxA/FGRGEaDXSPtVCZ3tw== In-Reply-To: <442B8D7F-0015-4E07-A500-FE381E6FA4B8@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 05:49:07 -0000 >> >> => What is the impact of the scenario you want to support on this doc >> (draft-larsson)? I mean is there anything that needs to be changed >> in the >> draft for this? > > actually none. => great, that's why I was confused about the reason of this discussion. >> => It's 2 years late to have this discussion then! We agreed on a >> separate >> draft (draft-larsson) 2 years ago.... > > But unfortunately this document it not yet WG document in these two > years. => Ah, that's because the document expired and was not re-submitted with the changes we agreed on and therefore it's hard to make it a WG doc. Hesham From marcelo@it.uc3m.es Fri Apr 17 00:44:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A633A6AC5 for ; Fri, 17 Apr 2009 00:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 FS-bFr4pJkDQ for ; Fri, 17 Apr 2009 00:44:09 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 6BEB73A6AB8 for ; Fri, 17 Apr 2009 00:44:09 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (215.pool85-53-142.dynamic.orange.es [85.53.142.215]) by smtp01.uc3m.es (Postfix) with ESMTP id 050A6BA4FC5 for ; Fri, 17 Apr 2009 09:45:20 +0200 (CEST) Message-ID: <49E83390.30507@it.uc3m.es> Date: Fri, 17 Apr 2009 09:45:20 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16586.005 Subject: [MEXT] clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 07:44:10 -0000 Let me see if we are all on the same page on this. In the charter we have: - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. For this deliverable we have: draft-ietf-mext-flow-binding-01.txt defines the format part of the last sentence in the paragraph above. draft-larsson-mext-flow-distribution-rules and the other binary encoding (we don't have a draft for this yet, right?) defines the policy format of the last sentence of the charter paragraph above. We all agree? Regards, marcelo From w52006@huawei.com Fri Apr 17 01:14:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8469F3A6C1B for ; Fri, 17 Apr 2009 01:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.877, 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 9cfSuaLNpS+5 for ; Fri, 17 Apr 2009 01:14:22 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 75BFB3A69CA for ; Fri, 17 Apr 2009 01:14:22 -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 <0KI800JSGK9XA7@szxga04-in.huawei.com> for mext@ietf.org; Fri, 17 Apr 2009 16:15:33 +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 <0KI800NO3K9X4G@szxga04-in.huawei.com> for mext@ietf.org; Fri, 17 Apr 2009 16:15:33 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI800608K9WC9@szxml04-in.huawei.com> for mext@ietf.org; Fri, 17 Apr 2009 16:15:33 +0800 (CST) Date: Fri, 17 Apr 2009 16:15:32 +0800 From: Yungui Wang In-reply-to: <49E83390.30507@it.uc3m.es> To: 'marcelo bagnulo braun' , 'mext' Message-id: <007701c9bf34$adb191f0$150ca40a@china.huawei.com> Organization: huawei 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: Acm/MJxlZarClSU0SUKV43dDdy4z8wAATrvg Subject: Re: [MEXT] clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:14:23 -0000 Hello Thanks for your clarification. I had read these two drafts. In my understanding, a flow distribution rule defined in ID-larsson is not equal to Flow Description (left part of FID option), but including parameters FID, action, etc in ID-Flow-Binding. Does they need to be further coordinated, e.g. to merge these repeated parameters? Or, should each rule be interpreted by MN to fit FID option before it is sent to network? B.R. Yungui > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On > Behalf Of marcelo bagnulo braun > Sent: Friday, April 17, 2009 3:45 PM > To: mext > Subject: [MEXT] clarification on flow binding documents > > Let me see if we are all on the same page on this. > > In the charter we have: > > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > For this deliverable we have: > > draft-ietf-mext-flow-binding-01.txt defines the format part > of the last > sentence in the paragraph above. > > draft-larsson-mext-flow-distribution-rules and the other > binary encoding > (we don't have a draft for this yet, right?) defines the > policy format > of the last sentence of the charter paragraph above. > > We all agree? > > Regards, marcelo > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From conny.larsson@ericsson.com Fri Apr 17 01:16:44 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB6F3A6AC2 for ; Fri, 17 Apr 2009 01:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[AWL=-1.443, BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, OBSCURED_EMAIL=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 5z+lWrpa8uBm for ; Fri, 17 Apr 2009 01:16:35 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6B5B03A6821 for ; Fri, 17 Apr 2009 01:16:34 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BF4F22210B; Fri, 17 Apr 2009 10:17:46 +0200 (CEST) X-AuditID: c1b4fb3e-ad021bb0000024d5-58-49e831ae2f8b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 70DD12217E; Fri, 17 Apr 2009 09:37:18 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 09:37:17 +0200 Received: from [127.0.0.1] ([147.214.130.137]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 09:37:17 +0200 Message-ID: <49E831A9.1080505@ericsson.com> Date: Fri, 17 Apr 2009 09:37:13 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Xiangsong Cui References: <49E4AD42.5000800@ericsson.com> <008601c9bd80$8f409e10$40106f0a@china.huawei.com> In-Reply-To: <008601c9bd80$8f409e10$40106f0a@china.huawei.com> Content-Type: multipart/alternative; boundary="------------080601000100060200050603" X-OriginalArrivalTime: 17 Apr 2009 07:37:17.0110 (UTC) FILETIME=[553B7D60:01C9BF2F] X-Brightmail-Tracker: AAAAAA== Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation ofdraft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:16:44 -0000 This is a multi-part message in MIME format. --------------080601000100060200050603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Xiangsong, Xiangsong Cui wrote: >  > Hi Larsson, > > I think it is a good idea, I have some comments as following: > > Firstly, I think it is better to provide a state diagram > for the connection manager since it relates to the exchange > and negotiation on flow binding. Maybe the state diagram > looks like: > +---------+ > | Idle |------------------------ > | |<-- \ > +---------+ \ | > ^ \ | sending out > flow > ??? | \ | binding request > ----| \ |------------------ > | \ | > | \ | > | | v > +-------------------+ | +-------------+ > | change flow | | |flow binding | > | binding pending | | | pending | > +-------------------+ | +-------------+ > ^ | | | > sending out change | | | |receiving flow > binding request | ?? | |??? |binding response > ------------------ | ----| |---- |-------------- > | | | | > | | | | > | v | | > \ +---------------+ / > \---| flow binding |<----/ > +---------------+ The purpose with the draft is to define the rule language to be used for creating routing rules. Section 3 "Conceptual Model" was added to highlight the difference between policies and routing rules. The exact behavior of the "Connection Manager" is outside the scope of the draft and so would the state diagram be. > > Secondly, there are some inter-operation problems, I think. > For example, when the node, which is multihomed, received the > command from user to begin some flow with the peer, the node > do not know whether the peer support the capability. If the > node use interface A to send packets, while the packets from > peer maybe come through interface B, how to avoid it happen? > If the node firstly exchange the information with the peer > and begin flow later, how about the delay during the procedure? > Or we do not care the issues? > Another example, if the node want to change the flow binding > from interface A to interface B, when should the node begin to > send packet through interface B? After sending the request or > after receiving the response? Very good questions and they definitely have to be outlined. I believe the issues you brought up here should be outlined in Hesham's draft, which defines how the Routing Rules are transported from the MN to the HA/CN. This draft should explain the procedure in the MN/HA/CN when the Routing Rules are accepted/not accepted, i.e., when to start sending traffic using the new Routing Rules. Thanks for your review. Regards Conny Larsson > > I think the solution need more detailed statement. > > Regards > > Xiangsong > å?Z(为æS(EURæoe¯æoe0/00é^(TM)?å...¬å?¸ huawei_logo > åoe°å?EURï¼s(æ·±åoe³å¸,é¾^(TM)å²---åOEºå?,ç"°å?Z(为åY"ºåoe° > é,®ç¼--ï¼s(518129 > http://www.huawei.com > ------------------------------------------------------------------------------------------------------------------------------------- > æoe¬é,®ä»¶å?S(å...¶é^(TM)"件å?«æoe0/00å?Z(为å...¬å?¸çs("ä¿?å¯+ä¿¡æ?¯ï¼OEä»...é^(TM)?äºZ(å?'éEUR?ç»^(TM)ä¸S(é?¢åoe°å?EUR中å^---å++ºçs("个人æ^--群ç»"ãEUR,ç¦? > 止任ä½.å...¶ä»--人以任ä½.å½¢å¼?使ç"¨ï¼^åOE...æ<¬ä½+ä¸?é^(TM)?äºZ(å...¨éf¨æ^--éf¨å^+åoe°æ³"éoe²ãEUR?å¤?å^¶ãEUR?æ^--æ.£å?'ï¼0/00æoe¬é,®ä»¶ä¸­ > çs("ä¿¡æ?¯ãEUR,å¦,æz(oeæ,¨é"^(TM)æ"¶äº+æoe¬é,®ä»¶ï¼OE请æ,¨ç«<å?³ç"µè¯?æ^--é,®ä»¶éEURs(çY"¥å?'件人并å^ é^(TM)¤æoe¬é,®ä»¶ï¼? > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed > above. Any use of the > information contained herein in any way (including, but not limited > to, total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, > please notify the sender by > phone or email immediately and delete it! > > ----- Original Message ----- > *From:* Conny Larsson > *To:* mext ; marcelo bagnulo > ; julien.laganier.IETF@googlemail.com > > *Sent:* Tuesday, April 14, 2009 11:35 PM > *Subject:* [MEXT] Call for adoptation > ofdraft-larsson-mext-flow-distribution-rules > > Hi, > > This is a request to the MEXT working group to adopt > draft-larsson-mext-flow-distribution-rules to cover the charter item: > > (A.3) Use of multiple interfaces. > ... > Deliverables related to this include > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > > The status of the working group is that we have a draft > (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for > registration of multiple care-of addresses to one home address. > There exist one draft > (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for > transport of the rules that decides how each flow is sent over the > available network interfaces. > > What is currently missing is the part that defines the rules. > draft-larsson-mext-flow-distribution-rules defines a rule language > that > can be used for this. The document can be found at: > > http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 > > Please express your opinion on whether this should become a WG > document. > > > Regards > Conny > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --------------080601000100060200050603 Content-Type: multipart/related; boundary="------------010507030001050604040606" --------------010507030001050604040606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Xiangsong,

Xiangsong Cui wrote:

Hi Larsson,
 
I think it is a good idea, I have some comments as following:
 
Firstly, I think it is better to provide a state diagram
for the connection manager since it relates to the exchange
and negotiation on flow binding. Maybe the state diagram
looks like:
                   +---------+                       
                   |  Idle   |------------------------
                   |         |<--                     \
                   +---------+   \                    | 
                        ^         \                   | sending out flow  
                    ??? |          \                  | binding request   
                    ----|           \                 |------------------
                        |            \                |
                        |             \               |
                        |              |              v
              +-------------------+    |       +-------------+
              |     change flow    |    |       |flow binding | 
              |  binding pending  |    |       |   pending   |
              +-------------------+    |       +-------------+
                        ^       |      |              |
    sending out change  |       |      |              |receiving flow
      binding request   |    ?? |      |???           |binding response
     ------------------ |   ----|      |----          |--------------
                        |       |      |              |
                        |       |      |              |
                        |       v      |              |
                         \    +---------------+      /
                          \---| flow binding  |<----/
                              +---------------+
The purpose with the draft is to define the rule language to be used for creating routing rules. Section 3 "Conceptual Model" was added to highlight the difference between policies and routing rules. The exact behavior of the "Connection Manager" is outside the scope of the draft and so would the state diagram be.
 
Secondly, there are some inter-operation problems, I think.
For example, when the node, which is multihomed, received the
command from user to begin some flow with the peer, the node
do not know whether the peer support the capability. If the
node use interface A to send packets, while the packets from
peer maybe come through interface B, how to avoid it happen?
If the node firstly exchange the information with the peer
and begin flow later, how about the delay during the procedure?
Or we do not care the issues?
Another example, if the node want to change the flow binding
from interface A to interface B, when should the node begin to
send packet through interface B? After sending the request or
after receiving the response?
Very good questions and they definitely have to be outlined. I believe the issues you brought up here should be outlined in Hesham's draft, which defines how the Routing Rules are transported from the MN to the HA/CN. This draft should explain the procedure in the MN/HA/CN when the Routing Rules are accepted/not accepted, i.e., when to start sending traffic using the new Routing Rules.

Thanks for your review.

Regards
Conny Larsson
 
I think the solution need more detailed statement.
 
Regards
 
Xiangsong
华为技术有限公司 huawei_logo
地址：深圳市龙岗区坂田华为基地 邮编：518129
http://www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
----- Original Message -----
Sent: Tuesday, April 14, 2009 11:35 PM
Subject: [MEXT] Call for adoptation ofdraft-larsson-mext-flow-distribution-rules

Hi,

This is a request to the MEXT working group to adopt
draft-larsson-mext-flow-distribution-rules to cover the charter item:

(A.3) Use of multiple interfaces.
...
Deliverables related to this include
- A "Flow/binding policies exchange" solution for an exchange of
policies from the mobile host/router to the Home Agent and from the
Home Agent to the mobile host/router influencing the choice of the
Care-of Address and Home Agent address. The solution involves two
specifications, one for the policy format and another for its
transport [both Standard Track].


The status of the working group is that we have a draft
(http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for
registration of multiple care-of addresses to one home address.
There exist one draft
(http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for
transport of the rules that decides how each flow is sent over the
available network interfaces.

What is currently missing is the part that defines the rules.
draft-larsson-mext-flow-distribution-rules defines a rule language that
can be used for this. The document can be found at:

http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02

Please express your opinion on whether this should become a WG document.


Regards
Conny

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext
--------------010507030001050604040606 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAA AAAAAAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAA AAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAA AAkAAAAAAAAAAAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1 AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAG AAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4AAAAAABwAAD///////////////////// ////////A+gAAAAA/////////////////////////////wPoAAAAAP////////////////// //////////8D6AAAAAD/////////////////////////////A+gAADhCSU0EAAAAAAAAAgAA OEJJTQQCAAAAAAACAAA4QklNBDAAAAAAAAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAA AAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4AAAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAA AAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAEA AAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBs b25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAgAAAAAFJnaHRsb25nAAAA ZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAASAAAAB3NsaWNlSURs b25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxFU2xpY2VPcmln aW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAAAEltZyAA AAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhU AAAAAQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAA CWhvcnpBbGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFs aWduZW51bQAAAA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVu dW0AAAARRVNsaWNlQkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAA AApsZWZ0T3V0c2V0bG9uZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRP dXRzZXRsb25nAAAAAAA4QklNBCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhC SU0EFAAAAAAABAAAAAg4QklNBAwAAAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB /9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCE AAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQEDEQH/3QAEAAf/xAE/AAAB BQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFD ByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1 VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFx IhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhED EQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7 +GUsVaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3Xnyaf ZWP5VtnsU/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyT vaUukP7/AA/9w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3x ZG32z/KVpx3XSWVhfWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtv c4ANO8bhsPySU6iS53pX146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8A YyQ30wB6m8u9L0ts7dzXJKehSWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/H zrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+ 4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWU vaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6x xc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nU xv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/usXoXVejYPVqfSymuDm/Qt rJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/jQHLVL1Z4/KJx4sfF /nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6jkWGik/s97t1 YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n0VmOzOrN r+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnTgMK9 mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLn fpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAA EwBBAGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAA AAcABQAAAAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAA GwEFAAEAAABqAAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEA AACiAAAAzAAAAID8CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MA MjAwNzowMjoyNiAxNjoxODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAA IAAAAAAAAAAGAAMBAwABAAAABgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAA AgAAAAECBAABAAAAKgEAAAICBAABAAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQ SkZJRgABAgAASABIAAD/7QAMQWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJ CAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEB AQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQB AwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh 8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGR FKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePz RpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVJ AIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDH l/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/ AA/9w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KV px3XSWVhfWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bh sPySU6iS53pX146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6 m8u9L0ts7dzXJKehSWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLl dRyscD7SzFr3isn8yx8tbvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn// 0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua782 2m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/ 76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG /n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7 VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/ AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6jkWGik/s97t1YJ2zX6AZ v21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n0VmOzOrNr+sXU+n4 mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnTgMK9mEHusfRY fe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpfUrPrNjfV rIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNjXu9R m5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8n OT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEB AQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFB BhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1 tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEB AQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYS QVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMR AD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tgema5X4j67qukeObG5hdkhto1e3H8L 5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimnyx0sz6zLsihOj7WtrzxbXk/8 7a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytraSvNOfYHhfqTgVJ4G8R6 nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/gdz1+iszX9at/Dug3 mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf03xbY6n4juND hjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l6J4hn1eD TkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo9p4N svE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAn go45RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNby EHHcEdDVzQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8 NNp8ssEvm+RcTtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V 7Frnh6w8QWohvEcMv3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/Uc LaWtRbXWl++/57dNCp8SreR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2d I+6MHjK7MZwP6V73RXcfLHj8V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPG WsaXpl/HJ4lu4rPTPMhZXIwQ0hGMqAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJI HPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB9 1ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58LeLfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+ haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74xke3tRX0lRQB//9k= --------------010507030001050604040606-- --------------080601000100060200050603-- From kuntz@lsiit.u-strasbg.fr Fri Apr 17 01:30:00 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FCFB3A696B for ; Fri, 17 Apr 2009 01:30:00 -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 0Vw1o7y6Ak5i for ; Fri, 17 Apr 2009 01:29:59 -0700 (PDT) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.153]) by core3.amsl.com (Postfix) with ESMTP id 12EFB3A692D for ; Fri, 17 Apr 2009 01:29:58 -0700 (PDT) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.91.200]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id n3H8Ttmi035113 ; Fri, 17 Apr 2009 10:29:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 17E28B5EAB1; Fri, 17 Apr 2009 10:29:55 +0200 (CEST) Received: from clarinet.u-strasbg.fr ([127.0.0.1]) by localhost (clarinet.u-strasbg.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eyn9P87uhki; Fri, 17 Apr 2009 10:29:54 +0200 (CEST) Received: from frynet.u-strasbg.fr (frynet.u-strasbg.fr [130.79.91.222]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kuntz) by clarinet.u-strasbg.fr (Postfix) with ESMTP id 9E586B5EAA2; Fri, 17 Apr 2009 10:29:54 +0200 (CEST) Message-Id: <4C51279E-272C-4C8F-A7B1-938014312287@lsiit.u-strasbg.fr> From: Romain KUNTZ To: marcelo bagnulo braun In-Reply-To: <49E83390.30507@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 10:29:53 +0200 References: <49E83390.30507@it.uc3m.es> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (mailhost.u-strasbg.fr [130.79.200.153]); Fri, 17 Apr 2009 10:29:55 +0200 (CEST) X-Virus-Scanned: ClamAV 0.94.2/9250/Fri Apr 17 08:37:45 2009 on mr3.u-strasbg.fr X-Virus-Status: Clean Cc: mext Subject: Re: [MEXT] clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:30:00 -0000 Hi, On 2009/04/17, at 9:45, marcelo bagnulo braun wrote: > In the charter we have: > > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > For this deliverable we have: > > draft-ietf-mext-flow-binding-01.txt defines the format part of the > last sentence in the paragraph above. I think you meant *transport* and not format here. Note that an alternative transport solution using Generic Notification Messages was also proposed here: http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules-00 > draft-larsson-mext-flow-distribution-rules and the other binary > encoding (we don't have a draft for this yet, right?) defines the > policy format of the last sentence of the charter paragraph above. > > We all agree? Yes, Cheers, -- Romain KUNTZ kuntz@lsiit.u-strasbg.fr LSIIT - Networks and Protocols Team http://clarinet.u-strasbg.fr/~kuntz/ From marcelo@it.uc3m.es Fri Apr 17 01:51:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28CA3A696B for ; Fri, 17 Apr 2009 01:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.470, 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 2fMSuXeDTNkg for ; Fri, 17 Apr 2009 01:51:57 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id B26EA3A6841 for ; Fri, 17 Apr 2009 01:51:56 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 596CABA58C8; Fri, 17 Apr 2009 10:53:08 +0200 (CEST) Message-ID: <49E84374.6030808@it.uc3m.es> Date: Fri, 17 Apr 2009 10:53:08 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Romain KUNTZ References: <49E83390.30507@it.uc3m.es> <4C51279E-272C-4C8F-A7B1-938014312287@lsiit.u-strasbg.fr> In-Reply-To: <4C51279E-272C-4C8F-A7B1-938014312287@lsiit.u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16586.006 Cc: mext Subject: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 08:51:58 -0000 thanks Romain sigh, i should never ever send emails to public mls before breakfast!!! Let me try again (and i am sorry for this In the charter we have: - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. For this deliverable we have: draft-ietf-mext-flow-binding-01.txt defines the transport part of the last sentence in the paragraph above. draft-larsson-mext-flow-distribution-rules and the other binary encoding defines the policy format of the last sentence of the charter paragraph above. We all agree? Regards, marcelo Romain KUNTZ escribió: > Hi, > > On 2009/04/17, at 9:45, marcelo bagnulo braun wrote: >> In the charter we have: >> >> - A "Flow/binding policies exchange" solution for an exchange of >> policies from the mobile host/router to the Home Agent and from the >> Home Agent to the mobile host/router influencing the choice of the >> Care-of Address and Home Agent address. The solution involves two >> specifications, one for the policy format and another for its >> transport [both Standard Track]. >> >> For this deliverable we have: >> >> draft-ietf-mext-flow-binding-01.txt defines the format part of the >> last sentence in the paragraph above. > > I think you meant *transport* and not format here. Note that an > alternative transport solution using Generic Notification Messages was > also proposed here: > http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules-00 > >> draft-larsson-mext-flow-distribution-rules and the other binary >> encoding (we don't have a draft for this yet, right?) defines the >> policy format of the last sentence of the charter paragraph above. >> >> We all agree? > > Yes, > > Cheers, From tsirtsis@googlemail.com Fri Apr 17 02:22:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF873A6A42 for ; Fri, 17 Apr 2009 02:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 NvRgk5D6oj07 for ; Fri, 17 Apr 2009 02:22:53 -0700 (PDT) Received: from mail-gx0-f160.google.com (mail-gx0-f160.google.com [209.85.217.160]) by core3.amsl.com (Postfix) with ESMTP id 2E2BD3A68AC for ; Fri, 17 Apr 2009 02:22:53 -0700 (PDT) Received: by gxk4 with SMTP id 4so1761209gxk.13 for ; Fri, 17 Apr 2009 02:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=/diFXPiGcfO6fahXLUeLHNN/MrDRSygCczIdP0BHATA=; b=jYA87TLMPOmkrWWhRuq9Ze1k2ZNDDy4bWI56J5+jWUPHBnUuWCkx5UktR6uwqKRG7+ p4PW34rgHXycKxzoC63pKJsIbhbfCPYrWiAV3ukZmMP3JFj46IJY4BzC1FEcX5nmIPm/ IO7Ia0lP2q0jEkl3CILAGvRUmOzjhvCkyF6to= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VlXVJ67boOvZ1lwKIKd07U9TjZh8w4FemGO9pGz091vAKYG0GidXiRoP3+bPo1TVHd CB+j50CTjLK4pCt9p0EUxvkGNXFerlkHDsHCte6b+v60ScevkAraSzsgcy7PqzehnViE dFy+LZk9Wo1x8F4easnyue5iwKYAYi1h6K79o= MIME-Version: 1.0 Received: by 10.90.115.17 with SMTP id n17mr1475653agc.44.1239960246398; Fri, 17 Apr 2009 02:24:06 -0700 (PDT) In-Reply-To: <49E84374.6030808@it.uc3m.es> References: <49E83390.30507@it.uc3m.es> <4C51279E-272C-4C8F-A7B1-938014312287@lsiit.u-strasbg.fr> <49E84374.6030808@it.uc3m.es> Date: Fri, 17 Apr 2009 10:24:06 +0100 Message-ID: From: George Tsirtsis To: marcelo bagnulo braun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:22:54 -0000 Yes :-) ,,,and the binary format will be available soon. George On Fri, Apr 17, 2009 at 9:53 AM, marcelo bagnulo braun wrote: > thanks Romain > > sigh, i should never ever send emails to public mls before breakfast!!! > > Let me try again (and i am sorry for this > > > In the charter we have: > > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > For this deliverable we have: > > draft-ietf-mext-flow-binding-01.txt defines the transport part of the las= t > sentence in the paragraph above. > > draft-larsson-mext-flow-distribution-rules and the other binary encoding > defines the policy format of the last sentence of the charter paragraph > above. > > We all agree? > > Regards, marcelo > > > Romain KUNTZ escribi=C3=B3: >> >> Hi, >> >> On 2009/04/17, at 9:45, marcelo bagnulo braun wrote: >>> >>> In the charter we have: >>> >>> - A "Flow/binding policies exchange" solution for an exchange of >>> policies from the mobile host/router to the Home Agent and from the >>> Home Agent to the mobile host/router influencing the choice of the >>> Care-of Address and Home Agent address. The solution involves two >>> specifications, one for the policy format and another for its >>> transport [both Standard Track]. >>> >>> For this deliverable we have: >>> >>> draft-ietf-mext-flow-binding-01.txt defines the format part of the last >>> sentence in the paragraph above. >> >> I think you meant *transport* and not format here. Note that an >> alternative transport solution using Generic Notification Messages was a= lso >> proposed here: >> http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules-00 >> >>> draft-larsson-mext-flow-distribution-rules and the other binary encodin= g >>> (we don't have a draft for this yet, right?) defines the policy format = of >>> the last sentence of the charter paragraph above. >>> >>> We all agree? >> >> Yes, >> >> Cheers, > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From Xiangsong.Cui@huawei.com Fri Apr 17 02:50:36 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047283A68E7 for ; Fri, 17 Apr 2009 02:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.579 X-Spam-Level: **** X-Spam-Status: No, score=4.579 tagged_above=-999 required=5 tests=[AWL=1.329, BAYES_40=-0.185, EXTRA_MPART_TYPE=1, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MY_CID_AND_STYLE=1.54, T_TVD_FW_GRAPHIC_ID1=0.01] 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 GGayYP5XF88n for ; Fri, 17 Apr 2009 02:50:34 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 109453A6AF2 for ; Fri, 17 Apr 2009 02:50:32 -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 <0KI800JS5OLUA7@szxga04-in.huawei.com> for mext@ietf.org; Fri, 17 Apr 2009 17:49:06 +0800 (CST) Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI800HRIOLSJ8@szxga04-in.huawei.com> for mext@ietf.org; Fri, 17 Apr 2009 17:49:06 +0800 (CST) Date: Fri, 17 Apr 2009 17:49:02 +0800 From: Xiangsong Cui To: Conny Larsson Message-id: <0d3401c9bf41$bdcd0800$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.3138 Content-type: multipart/related; boundary="Boundary_(ID_HjhngwGM60NOakMDepQRJg)"; type="multipart/alternative" X-Priority: 3 X-MSMail-priority: Normal References: <49E4AD42.5000800@ericsson.com> <008601c9bd80$8f409e10$40106f0a@china.huawei.com> <49E831A9.1080505@ericsson.com> Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation ofdraft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 09:50:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_HjhngwGM60NOakMDepQRJg) Content-type: multipart/alternative; boundary="Boundary_(ID_z9rgn1uxni/8jNTkvBKSog)" --Boundary_(ID_z9rgn1uxni/8jNTkvBKSog) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 PiBWZXJ5IGdvb2QgcXVlc3Rpb25zIGFuZCB0aGV5IGRlZmluaXRlbHkgaGF2ZSB0byBiZSBvdXRs aW5lZC4gSSBiZWxpZXZlIHRoZSBpc3N1ZXMgeW91IGJyb3VnaHQgdXAgaGVyZSBzaG91bGQgYmUg DQo+IG91dGxpbmVkIGluIEhlc2hhbSdzIGRyYWZ0LCB3aGljaCBkZWZpbmVzIGhvdyB0aGUgUm91 dGluZyBSdWxlcyBhcmUgdHJhbnNwb3J0ZWQgZnJvbSB0aGUgTU4gdG8gdGhlIEhBL0NOLiBUaGlz IGRyYWZ0DQo+IHNob3VsZCA/IGV4cGxhaW4gdGhlIHByb2NlZHVyZSBpbiB0aGUgTU4vSEEvQ04g d2hlbiB0aGUgUm91dGluZyBSdWxlcyBhcmUgYWNjZXB0ZWQvbm90IGFjY2VwdGVkLCBpLmUuLCB3 aGVuIHRvIHN0YXJ0IA0KPiBzZW5kaW5nIHRyYWZmaWMgdXNpbmcgdGhlIG5ldyBSb3V0aW5nIFJ1 bGVzLg0KDQpUaGFuayB5b3UsIEkgdW5kZXJzdGFuZCB0aGUgcmVsYXRpb24gYmV0d2VlbiB0aGUg dHdvIGRyYWZ0cyBhZnRlciBJIGhhdmUgcmVhZCBIZXNoYW0ncyBkcmFmdC4NCg0KSSBqdXN0IHdh bnQgdG8gc2F5LCBJTU8sIGl0IGlzIGJldHRlciB0byBwcm92aWRlIGEgdGhvcm91Z2ggc29sdXRp b24uDQoNClJlZ2FyZHMNClhpYW5nc29uZw0KDQoNCg0K5Y2O5Li65oqA5pyv5pyJ6ZmQ5YWs5Y+4 ICANCg0KDQrlnLDlnYDvvJrmt7HlnLPluILpvpnlspfljLrlnYLnlLDljY7kuLrln7rlnLAg6YKu 57yW77yaNTE4MTI5DQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4uuWFrOWPuOeahOS/neWvhuS/oeaBr++8 jOS7hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4reWIl+WHuueahOS4quS6uuaIlue+pOe7 hOOAguemgQ0K5q2i5Lu75L2V5YW25LuW5Lq65Lul5Lu75L2V5b2i5byP5L2/55So77yI5YyF5ous 5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo5YiG5Zyw5rOE6Zyy44CB5aSN5Yi244CB5oiW5pWj5Y+R 77yJ5pys6YKu5Lu25LitDQrnmoTkv6Hmga/jgILlpoLmnpzmgqjplJnmlLbkuobmnKzpgq7ku7bv vIzor7fmgqjnq4vljbPnlLXor53miJbpgq7ku7bpgJrnn6Xlj5Hku7bkurrlubbliKDpmaTmnKzp gq7ku7bvvIENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRl bnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIA0KaXMgaW50ZW5kZWQgb25seSBm b3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFu eSB1c2Ugb2YgdGhlIA0KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChp bmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCANCmRpc2Nsb3N1 cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFu IHRoZSBpbnRlbmRlZCANCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2 ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IA0KcGhv bmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0KICAtLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBDb25ueSBMYXJzc29uIA0KICBUbzogWGlhbmdzb25n IEN1aSANCiAgQ2M6IG1leHQgOyBtYXJjZWxvIGJhZ251bG8gOyBqdWxpZW4ubGFnYW5pZXIuSUVU RkBnb29nbGVtYWlsLmNvbSANCiAgU2VudDogRnJpZGF5LCBBcHJpbCAxNywgMjAwOSAzOjM3IFBN DQogIFN1YmplY3Q6IFJlOiBbTUVYVF0gQ2FsbCBmb3IgYWRvcHRhdGlvbiBvZmRyYWZ0LWxhcnNz b24tbWV4dC1mbG93LWRpc3RyaWJ1dGlvbi1ydWxlcw0KDQoNCiAgSGkgWGlhbmdzb25nLA0KDQog IFhpYW5nc29uZyBDdWkgd3JvdGU6IA0KICAgIMOvwrvCvyANCiAgICBIaSBMYXJzc29uLA0KDQog ICAgSSB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSwgSSBoYXZlIHNvbWUgY29tbWVudHMgYXMgZm9s bG93aW5nOg0KDQogICAgRmlyc3RseSwgSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gcHJvdmlkZSBh IHN0YXRlIGRpYWdyYW0gDQogICAgZm9yIHRoZSBjb25uZWN0aW9uIG1hbmFnZXIgc2luY2UgaXQg cmVsYXRlcyB0byB0aGUgZXhjaGFuZ2UgDQogICAgYW5kIG5lZ290aWF0aW9uIG9uIGZsb3cgYmlu ZGluZy4gTWF5YmUgdGhlIHN0YXRlIGRpYWdyYW0gDQogICAgbG9va3MgbGlrZToNCiAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAgICAgICAgICAgICAgfCAgSWRsZSAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgIHw8LS0gICAgICAgICAgICAgICAgICAgICBc DQogICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgXCAgICAgICAgICAgICAgICAg ICAgfCAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgXiAgICAgICAgIFwgICAgICAgICAg ICAgICAgICAgfCBzZW5kaW5nIG91dCBmbG93ICAgDQogICAgICAgICAgICAgICAgICAgICAgICA/ Pz8gfCAgICAgICAgICBcICAgICAgICAgICAgICAgICAgfCBiaW5kaW5nIHJlcXVlc3QgICANCiAg ICAgICAgICAgICAgICAgICAgICAgIC0tLS18ICAgICAgICAgICBcICAgICAgICAgICAgICAgICB8 LS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgIFwgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgXCAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB2DQogICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tLS0tLSsgICAgfCAgICAgICArLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAg ICAgIHwgICAgIGNoYW5nZSBmbG93ICAgIHwgICAgfCAgICAgICB8ZmxvdyBiaW5kaW5nIHwgIA0K ICAgICAgICAgICAgICAgICAgfCAgYmluZGluZyBwZW5kaW5nICB8ICAgIHwgICAgICAgfCAgIHBl bmRpbmcgICB8DQogICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgfCAg ICAgICArLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgICAg IHwgICAgICB8ICAgICAgICAgICAgICB8DQogICAgICAgIHNlbmRpbmcgb3V0IGNoYW5nZSAgfCAg ICAgICB8ICAgICAgfCAgICAgICAgICAgICAgfHJlY2VpdmluZyBmbG93DQogICAgICAgICAgYmlu ZGluZyByZXF1ZXN0ICAgfCAgICA/PyB8ICAgICAgfD8/PyAgICAgICAgICAgfGJpbmRpbmcgcmVz cG9uc2UNCiAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLSB8ICAgLS0tLXwgICAgICB8LS0tLSAg ICAgICAgICB8LS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgIHwgICAgICB8ICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICB8ICAgICAgfCAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgdiAgICAgIHwgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgXCAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgIC8NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFwtLS18IGZsb3cgYmluZGluZyAgfDwtLS0tLw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rDQogIFRoZSBwdXJwb3NlIHdpdGgg dGhlIGRyYWZ0IGlzIHRvIGRlZmluZSB0aGUgcnVsZSBsYW5ndWFnZSB0byBiZSB1c2VkIGZvciBj cmVhdGluZyByb3V0aW5nIHJ1bGVzLiBTZWN0aW9uIDMgIkNvbmNlcHR1YWwgTW9kZWwiIHdhcyBh ZGRlZCB0byBoaWdobGlnaHQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBwb2xpY2llcyBhbmQgcm91 dGluZyBydWxlcy4gVGhlIGV4YWN0IGJlaGF2aW9yIG9mIHRoZSAiQ29ubmVjdGlvbiBNYW5hZ2Vy IiBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgZHJhZnQgYW5kIHNvIHdvdWxkIHRoZSBzdGF0 ZSBkaWFncmFtIGJlLg0KDQoNCiAgICBTZWNvbmRseSwgdGhlcmUgYXJlIHNvbWUgaW50ZXItb3Bl cmF0aW9uIHByb2JsZW1zLCBJIHRoaW5rLg0KICAgIEZvciBleGFtcGxlLCB3aGVuIHRoZSBub2Rl LCB3aGljaCBpcyBtdWx0aWhvbWVkLCByZWNlaXZlZCB0aGUgDQogICAgY29tbWFuZCBmcm9tIHVz ZXIgdG8gYmVnaW4gc29tZSBmbG93IHdpdGggdGhlIHBlZXIsIHRoZSBub2RlIA0KICAgIGRvIG5v dCBrbm93IHdoZXRoZXIgdGhlIHBlZXIgc3VwcG9ydCB0aGUgY2FwYWJpbGl0eS4gSWYgdGhlIA0K ICAgIG5vZGUgdXNlIGludGVyZmFjZSBBIHRvIHNlbmQgcGFja2V0cywgd2hpbGUgdGhlIHBhY2tl dHMgZnJvbSANCiAgICBwZWVyIG1heWJlIGNvbWUgdGhyb3VnaCBpbnRlcmZhY2UgQiwgaG93IHRv IGF2b2lkIGl0IGhhcHBlbj8gDQogICAgSWYgdGhlIG5vZGUgZmlyc3RseSBleGNoYW5nZSB0aGUg aW5mb3JtYXRpb24gd2l0aCB0aGUgcGVlciANCiAgICBhbmQgYmVnaW4gZmxvdyBsYXRlciwgaG93 IGFib3V0IHRoZSBkZWxheSBkdXJpbmcgdGhlIHByb2NlZHVyZT8NCiAgICBPciB3ZSBkbyBub3Qg Y2FyZSB0aGUgaXNzdWVzPw0KICAgIEFub3RoZXIgZXhhbXBsZSwgaWYgdGhlIG5vZGUgd2FudCB0 byBjaGFuZ2UgdGhlIGZsb3cgYmluZGluZyANCiAgICBmcm9tIGludGVyZmFjZSBBIHRvIGludGVy ZmFjZSBCLCB3aGVuIHNob3VsZCB0aGUgbm9kZSBiZWdpbiB0byANCiAgICBzZW5kIHBhY2tldCB0 aHJvdWdoIGludGVyZmFjZSBCPyBBZnRlciBzZW5kaW5nIHRoZSByZXF1ZXN0IG9yIA0KICAgIGFm dGVyIHJlY2VpdmluZyB0aGUgcmVzcG9uc2U/DQogIFZlcnkgZ29vZCBxdWVzdGlvbnMgYW5kIHRo ZXkgZGVmaW5pdGVseSBoYXZlIHRvIGJlIG91dGxpbmVkLiBJIGJlbGlldmUgdGhlIGlzc3VlcyB5 b3UgYnJvdWdodCB1cCBoZXJlIHNob3VsZCBiZSBvdXRsaW5lZCBpbiBIZXNoYW0ncyBkcmFmdCwg d2hpY2ggZGVmaW5lcyBob3cgdGhlIFJvdXRpbmcgUnVsZXMgYXJlIHRyYW5zcG9ydGVkIGZyb20g dGhlIE1OIHRvIHRoZSBIQS9DTi4gVGhpcyBkcmFmdCBzaG91bGQgZXhwbGFpbiB0aGUgcHJvY2Vk dXJlIGluIHRoZSBNTi9IQS9DTiB3aGVuIHRoZSBSb3V0aW5nIFJ1bGVzIGFyZSBhY2NlcHRlZC9u b3QgYWNjZXB0ZWQsIGkuZS4sIHdoZW4gdG8gc3RhcnQgc2VuZGluZyB0cmFmZmljIHVzaW5nIHRo ZSBuZXcgUm91dGluZyBSdWxlcy4NCg0KICBUaGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KDQogIFJl Z2FyZHMNCiAgQ29ubnkgTGFyc3Nvbg0KDQoNCiAgICBJIHRoaW5rIHRoZSBzb2x1dGlvbiBuZWVk IG1vcmUgZGV0YWlsZWQgc3RhdGVtZW50Lg0KDQogICAgUmVnYXJkcw0KDQogICAgWGlhbmdzb25n DQogICAgw6XCjcW9w6TCuMK6w6bFoOKCrMOmxZPCr8OmxZPigLDDqeKEosKQw6XigKbCrMOlwo/C uCAgDQogICAgw6XFk8Kww6XCneKCrMOvwrzFocOmwrfCscOlxZPCs8OlwrjigJrDqcK+4oSiw6XC suKAlMOlxZLCusOlwp3igJrDp+KAncKww6XCjcW9w6TCuMK6w6XFuMK6w6XFk8KwIMOp4oCawq7D p8K84oCTw6/CvMWhNTE4MTI5DQogICAgaHR0cDovL3d3dy5odWF3ZWkuY29tDQogICAgLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KICAgIMOmxZPCrMOp4oCawq7DpMK7wrbDpcKPxaDDpeKApsK2w6nihKLi gJ7DpMK7wrbDpcKQwqvDpsWT4oCww6XCjcW9w6TCuMK6w6XigKbCrMOlwo/CuMOnxaHigJ7DpMK/ wp3DpcKv4oCgw6TCv8Khw6bCgcKvw6/CvMWSw6TCu+KApsOp4oSiwpDDpMK6xb3DpcKP4oCYw6ni gqzCgcOnwrvihKLDpMK4xaDDqcKdwqLDpcWTwrDDpcKd4oKsw6TCuMKtw6XLhuKAlMOl4oChwrrD p8Wh4oCew6TCuMKqw6TCusK6w6bLhuKAk8Onwr7CpMOnwrvigJ7Do+KCrOKAmsOnwqbCgQ0KICAg IMOmwq3CosOkwrvCu8Okwr3igKLDpeKApsK2w6TCu+KAk8OkwrrCusOkwrvCpcOkwrvCu8Okwr3i gKLDpcK9wqLDpcK8wo/DpMK9wr/Dp+KAncKow6/CvMuGw6XFkuKApsOm4oC5wqzDpMK94oCgw6TC uMKNw6nihKLCkMOkwrrFvcOl4oCmwqjDqcaSwqjDpsuG4oCTw6nGksKow6XLhuKAoMOlxZPCsMOm wrPigJ7DqcWTwrLDo+KCrMKBw6XCpMKNw6XLhsK2w6PigqzCgcOmy4bigJPDpuKAosKjw6XCj+KA mMOvwrzigLDDpsWTwqzDqeKAmsKuw6TCu8K2w6TCuMKtDQogICAgw6fFoeKAnsOkwr/CocOmwoHC r8Oj4oKs4oCaw6XCpuKAmsOmxb7Fk8Om4oCawqjDqeKAneKEosOm4oCdwrbDpMK64oCgw6bFk8Ks w6nigJrCrsOkwrvCtsOvwrzFksOowq/Ct8Om4oCawqjDp8Kr4oC5w6XCjcKzw6figJ3CtcOowq/C ncOmy4bigJPDqeKAmsKuw6TCu8K2w6nigqzFocOnxbjCpcOlwo/igJjDpMK7wrbDpMK6wrrDpcK5 wrbDpcuGIMOp4oSiwqTDpsWTwqzDqeKAmsKuw6TCu8K2w6/CvMKBDQogICAgVGhpcyBlLW1haWwg YW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9t IEhVQVdFSSwgd2hpY2ggDQogICAgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBl bnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIA0KICAg IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQg bm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgDQogICAgZGlzY2xvc3VyZSwgcmVwcm9k dWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVu ZGVkIA0KICAgIHJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlz IGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IA0KICAgIHBob25l IG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCiAgICAgIC0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0gDQogICAgICBGcm9tOiBDb25ueSBMYXJzc29uIA0KICAgICAgVG86 IG1leHQgOyBtYXJjZWxvIGJhZ251bG8gOyBqdWxpZW4ubGFnYW5pZXIuSUVURkBnb29nbGVtYWls LmNvbSANCiAgICAgIFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE0LCAyMDA5IDExOjM1IFBNDQogICAg ICBTdWJqZWN0OiBbTUVYVF0gQ2FsbCBmb3IgYWRvcHRhdGlvbiBvZmRyYWZ0LWxhcnNzb24tbWV4 dC1mbG93LWRpc3RyaWJ1dGlvbi1ydWxlcw0KDQoNCiAgICAgIEhpLA0KDQogICAgICBUaGlzIGlz IGEgcmVxdWVzdCB0byB0aGUgTUVYVCB3b3JraW5nIGdyb3VwIHRvIGFkb3B0IA0KICAgICAgZHJh ZnQtbGFyc3Nvbi1tZXh0LWZsb3ctZGlzdHJpYnV0aW9uLXJ1bGVzIHRvIGNvdmVyIHRoZSBjaGFy dGVyIGl0ZW06DQoNCiAgICAgIChBLjMpIFVzZSBvZiBtdWx0aXBsZSBpbnRlcmZhY2VzLg0KICAg ICAgLi4uDQogICAgICBEZWxpdmVyYWJsZXMgcmVsYXRlZCB0byB0aGlzIGluY2x1ZGUNCiAgICAg IC0gQSAiRmxvdy9iaW5kaW5nIHBvbGljaWVzIGV4Y2hhbmdlIiBzb2x1dGlvbiBmb3IgYW4gZXhj aGFuZ2Ugb2YNCiAgICAgIHBvbGljaWVzIGZyb20gdGhlIG1vYmlsZSBob3N0L3JvdXRlciB0byB0 aGUgSG9tZSBBZ2VudCBhbmQgZnJvbSB0aGUNCiAgICAgIEhvbWUgQWdlbnQgdG8gdGhlIG1vYmls ZSBob3N0L3JvdXRlciBpbmZsdWVuY2luZyB0aGUgY2hvaWNlIG9mIHRoZQ0KICAgICAgQ2FyZS1v ZiBBZGRyZXNzIGFuZCBIb21lIEFnZW50IGFkZHJlc3MuIFRoZSBzb2x1dGlvbiBpbnZvbHZlcyB0 d28NCiAgICAgIHNwZWNpZmljYXRpb25zLCBvbmUgZm9yIHRoZSBwb2xpY3kgZm9ybWF0IGFuZCBh bm90aGVyIGZvciBpdHMNCiAgICAgIHRyYW5zcG9ydCBbYm90aCBTdGFuZGFyZCBUcmFja10uDQoN Cg0KICAgICAgVGhlIHN0YXR1cyBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0aGF0IHdlIGhhdmUg YSBkcmFmdCANCiAgICAgIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1v bmFtaTYtbXVsdGlwbGVjb2EtMTIpIGZvciANCiAgICAgIHJlZ2lzdHJhdGlvbiBvZiBtdWx0aXBs ZSBjYXJlLW9mIGFkZHJlc3NlcyB0byBvbmUgaG9tZSBhZGRyZXNzLg0KICAgICAgVGhlcmUgZXhp c3Qgb25lIGRyYWZ0IA0KICAgICAgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbWV4dC1mbG93LWJpbmRpbmctMDEpIGZvciANCiAgICAgIHRyYW5zcG9ydCBvZiB0aGUgcnVs ZXMgdGhhdCBkZWNpZGVzIGhvdyBlYWNoIGZsb3cgaXMgc2VudCBvdmVyIHRoZSANCiAgICAgIGF2 YWlsYWJsZSBuZXR3b3JrIGludGVyZmFjZXMuDQoNCiAgICAgIFdoYXQgaXMgY3VycmVudGx5IG1p c3NpbmcgaXMgdGhlIHBhcnQgdGhhdCBkZWZpbmVzIHRoZSBydWxlcy4gDQogICAgICBkcmFmdC1s YXJzc29uLW1leHQtZmxvdy1kaXN0cmlidXRpb24tcnVsZXMgZGVmaW5lcyBhIHJ1bGUgbGFuZ3Vh Z2UgdGhhdCANCiAgICAgIGNhbiBiZSB1c2VkIGZvciB0aGlzLiBUaGUgZG9jdW1lbnQgY2FuIGJl IGZvdW5kIGF0Og0KDQogICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sYXJz c29uLW1leHQtZmxvdy1kaXN0cmlidXRpb24tcnVsZXMtMDINCg0KICAgICAgUGxlYXNlIGV4cHJl c3MgeW91ciBvcGluaW9uIG9uIHdoZXRoZXIgdGhpcyBzaG91bGQgYmVjb21lIGEgV0cgZG9jdW1l bnQuDQoNCg0KICAgICAgUmVnYXJkcw0KICAgICAgQ29ubnkNCg0KICAgICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgIE1FWFQgbWFpbGluZyBs aXN0DQogICAgICBNRVhUQGlldGYub3JnDQogICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21leHQ= --Boundary_(ID_z9rgn1uxni/8jNTkvBKSog) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1D b250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNv bnRlbnQ9Ik1TSFRNTCA2LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJP RFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMg c2l6ZT0yPiZndDsgPEZPTlQgc2l6ZT0zPlZlcnkgZ29vZCBxdWVzdGlvbnMgYW5kIHRoZXkgDQpk ZWZpbml0ZWx5IGhhdmUgdG8gYmUgb3V0bGluZWQuIEkgYmVsaWV2ZSB0aGUgaXNzdWVzIHlvdSBi cm91Z2h0IHVwIGhlcmUgc2hvdWxkIA0KYmUgPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT3lrovkvZMgc2l6ZT0yPjxGT05UIHNpemU9Mz4mZ3Q7IG91dGxpbmVkIGluIEhlc2hh bSdzIGRyYWZ0LCB3aGljaCANCmRlZmluZXMgaG93IHRoZSBSb3V0aW5nIFJ1bGVzIGFyZSB0cmFu c3BvcnRlZCBmcm9tIHRoZSBNTiB0byB0aGUgSEEvQ04uIFRoaXMgDQpkcmFmdDwvRk9OVD48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj48Rk9OVCBzaXplPTM+Jmd0 OyBzaG91bGQgPyBleHBsYWluIHRoZSBwcm9jZWR1cmUgaW4gDQp0aGUgTU4vSEEvQ04gd2hlbiB0 aGUgUm91dGluZyBSdWxlcyBhcmUgYWNjZXB0ZWQvbm90IGFjY2VwdGVkLCBpLmUuLCB3aGVuIHRv IA0Kc3RhcnQgPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6 ZT0yPjxGT05UIHNpemU9Mz4mZ3Q7IHNlbmRpbmcgdHJhZmZpYyB1c2luZyB0aGUgbmV3IA0KUm91 dGluZyBSdWxlcy48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kz48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TPlRoYW5rIHlvdSwgSSZu YnNwO3VuZGVyc3RhbmQgdGhlIHJlbGF0aW9uJm5ic3A7YmV0d2VlbiB0aGUgDQp0d28gZHJhZnRz IGFmdGVyIEkgaGF2ZSByZWFkIEhlc2hhbSdzIGRyYWZ0LjwvRk9OVD48Rk9OVCBmYWNlPeWui+S9 kz48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZM+SSBqdXN0IHdhbnQgdG8gc2F5LCBJTU8sIGl0IGlz IGJldHRlciB0byBwcm92aWRlIGEgdGhvcm91Z2ggDQpzb2x1dGlvbi48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U95a6L5L2TPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT3lrovkvZM+UmVnYXJkczwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZM+WGlh bmdzb25nPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kz48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPg0KPFA+PC9QPg0KPFA+PC9QPjxGT05UIGZhY2U95Y2O5paH57uG6buRIGNv bG9yPWJsYWNrIHNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT3ljY7mlofnu4bpu5EgY29sb3I9Z3Jh eSANCnNpemU9Mj7ljY7kuLrmioDmnK/mnInpmZDlhazlj7ggPC9GT05UPjxJTUcgaWQ9cmlkSW1n IGFsdD1odWF3ZWlfbG9nbyBoc3BhY2U9MCANCnNyYz0iY2lkOjBkMmEwMWM5YmY0MSRiZDc5OTBk MCQ0MDEwNmYwYUBjaGluYS5odWF3ZWkuY29tIiBhbGlnbj1sZWZ0PiANCjxQPjwvUD48Rk9OVCBm YWNlPeWNjuaWh+e7hum7kSBjb2xvcj0jODA4MDgwIHNpemU9Mj48L0ZPTlQ+PEJSPjxGT05UIGZh Y2U95Y2O5paH57uG6buRIA0KY29sb3I9Z3JheSBzaXplPTE+5Zyw5Z2A77ya5rex5Zyz5biC6b6Z 5bKX5Yy65Z2C55Sw5Y2O5Li65Z+65ZywIA0K6YKu57yW77yaNTE4MTI5PEJSPmh0dHA6Ly93d3cu aHVhd2VpLmNvbTxCUj48L0ZPTlQ+PEZPTlQgZmFjZT3ljY7mlofnu4bpu5EgY29sb3I9Z3JheSAN CnNpemU9MT4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+ac ieWNjuS4uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWc sOWdgOS4reWIl+WHuueahOS4quS6uuaIlue+pOe7hOOAguemgTxCUj7mraLku7vkvZXlhbbku5bk urrku6Xku7vkvZXlvaLlvI/kvb/nlKjvvIjljIXmi6zkvYbkuI3pmZDkuo7lhajpg6jmiJbpg6jl iIblnLDms4TpnLLjgIHlpI3liLbjgIHmiJbmlaPlj5HvvInmnKzpgq7ku7bkuK08QlI+55qE5L+h 5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW 6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu5Lu277yBPEJSPjwvRk9OVD48Rk9O VCANCmZhY2U9QXJpYWwgY29sb3I9Z3JheSBzaXplPTE+VGhpcyBlLW1haWwgYW5kIGl0cyBhdHRh Y2htZW50cyBjb250YWluIA0KY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3 aGljaCA8QlI+aXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiANCm9yIGVudGl0eSB3aG9z ZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUgPEJSPmluZm9ybWF0aW9u IA0KY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRl ZCB0bywgdG90YWwgb3IgcGFydGlhbCANCjxCUj5kaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9y IGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgDQppbnRlbmRlZCA8QlI+ cmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGlu IGVycm9yLCANCnBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSA8QlI+cGhvbmUgb3IgZW1haWwg aW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSANCml0ITxCUj48L0ZPTlQ+PC9ESVY+DQo8QkxPQ0tRVU9U RSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7 IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lO LVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj4tLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRl NGU0OyBGT05UOiA5cHQg5a6L5L2TOyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0K ICA8QSB0aXRsZT1jb25ueS5sYXJzc29uQGVyaWNzc29uLmNvbSANCiAgaHJlZj0ibWFpbHRvOmNv bm55LmxhcnNzb25AZXJpY3Nzb24uY29tIj5Db25ueSBMYXJzc29uPC9BPiA8L0RJVj4NCiAgPERJ ViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+VG86PC9CPiA8QSB0aXRsZT1YaWFuZ3Nvbmcu Q3VpQGh1YXdlaS5jb20gDQogIGhyZWY9Im1haWx0bzpYaWFuZ3NvbmcuQ3VpQGh1YXdlaS5jb20i PlhpYW5nc29uZyBDdWk8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2T Ij48Qj5DYzo8L0I+IDxBIHRpdGxlPW1leHRAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzptZXh0 QGlldGYub3JnIj5tZXh0PC9BPiA7IDxBIHRpdGxlPW1hcmNlbG9AaXQudWMzbS5lcyANCiAgaHJl Zj0ibWFpbHRvOm1hcmNlbG9AaXQudWMzbS5lcyI+bWFyY2VsbyBiYWdudWxvPC9BPiA7IDxBIA0K ICB0aXRsZT1qdWxpZW4ubGFnYW5pZXIuSUVURkBnb29nbGVtYWlsLmNvbSANCiAgaHJlZj0ibWFp bHRvOmp1bGllbi5sYWdhbmllci5JRVRGQGdvb2dsZW1haWwuY29tIj5qdWxpZW4ubGFnYW5pZXIu SUVURkBnb29nbGVtYWlsLmNvbTwvQT4gDQogIDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5 cHQg5a6L5L2TIj48Qj5TZW50OjwvQj4gRnJpZGF5LCBBcHJpbCAxNywgMjAwOSAzOjM3IFBNPC9E SVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlN1YmplY3Q6PC9CPiBSZTog W01FWFRdIENhbGwgZm9yIGFkb3B0YXRpb24gDQogIG9mZHJhZnQtbGFyc3Nvbi1tZXh0LWZsb3ct ZGlzdHJpYnV0aW9uLXJ1bGVzPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPjxUVD5IaSA8L1RUPlhp YW5nc29uZyw8QlI+PEJSPlhpYW5nc29uZyBDdWkgd3JvdGU6IA0KICA8QkxPQ0tRVU9URSBjaXRl PW1pZDowMDg2MDFjOWJkODAkOGY0MDllMTAkNDAxMDZmMGFAY2hpbmEuaHVhd2VpLmNvbSANCiAg dHlwZT0iY2l0ZSI+w6/Cu8K/IA0KICAgIDxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI5MDAu MzQ5MiIgbmFtZT1HRU5FUkFUT1I+DQogICAgPFNUWUxFPjwvU1RZTEU+DQoNCiAgICA8RElWPjxG T05UIGZhY2U9w6XCruKAucOkwr3igJwgc2l6ZT0yPkhpIExhcnNzb24sPC9GT05UPjwvRElWPg0K ICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPcOlwq7igLnDpMK94oCc IHNpemU9Mj5JIHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVhLCBJIGhhdmUgc29tZSANCiAgICBjb21t ZW50cyBhcyBmb2xsb3dpbmc6PC9GT05UPjwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQog ICAgPERJVj48Rk9OVCBmYWNlPcOlwq7igLnDpMK94oCcIHNpemU9Mj5GaXJzdGx5LCBJIHRoaW5r IGl0IGlzIGJldHRlciB0byBwcm92aWRlIGEgDQogICAgc3RhdGUgZGlhZ3JhbSA8L0ZPTlQ+PC9E SVY+DQogICAgPERJVj48Rk9OVCBmYWNlPcOlwq7igLnDpMK94oCcIHNpemU9Mj5mb3IgdGhlIGNv bm5lY3Rpb24gbWFuYWdlciBzaW5jZSA8L0ZPTlQ+PEZPTlQgDQogICAgZmFjZT3DpcKu4oC5w6TC veKAnCBzaXplPTI+aXQgcmVsYXRlcyB0byB0aGUgZXhjaGFuZ2UgPC9GT05UPjwvRElWPg0KICAg IDxESVY+PEZPTlQgZmFjZT3DpcKu4oC5w6TCveKAnCBzaXplPTI+YW5kIG5lZ290aWF0aW9uIG9u IGZsb3cgYmluZGluZy4gTWF5YmUgdGhlIA0KICAgIHN0YXRlIGRpYWdyYW0gPC9GT05UPjwvRElW Pg0KICAgIDxESVY+PEZPTlQgZmFjZT3DpcKu4oC5w6TCveKAnCBzaXplPTI+bG9va3MgbGlrZTo8 L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPcOlwq7igLnDpMK94oCcIA0KICAgIHNp emU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogICAgKy0tLS0tLS0tLSsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICB8Jm5i c3A7IElkbGUmbmJzcDsmbmJzcDsgDQogICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICB8 Jmx0Oy0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KICAgIFw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgICstLS0tLS0tLS0rJm5ic3A7Jm5ic3A7IA0KICAgIFwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogICAgfCZuYnNwOyANCiAgICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIF4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgXCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICB8 IHNlbmRpbmcgb3V0IGZsb3cmbmJzcDsmbmJzcDsgDQogICAgPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAmbmJzcDs/Pz8mbmJzcDt8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICAgIFwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAg fCBiaW5kaW5nIA0KICAgIHJlcXVlc3QmbmJzcDsmbmJzcDsmbmJzcDs8QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIC0tLS18 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KICAgIFwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAg fC0tLS0tLS0tLS0tLS0tLS0tLTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCiAgICBcJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIHw8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAg XCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICB8PEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCiAgICB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQogICAgdjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgKy0tLS0tLS0t LS0tLS0tLS0tLS0rJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgDQogICAgKy0tLS0tLS0tLS0tLS0rPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCiAgICB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNoYW5nZSBmbG93Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8ZmxvdyBiaW5kaW5nIHwmbmJzcDsgDQogICAgPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCiAgICB8Jm5ic3A7IGJpbmRpbmcgcGVuZGluZyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KICAgIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyBwZW5kaW5nJm5ic3A7Jm5ic3A7IA0KICAgIHw8QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KICAgICstLS0tLS0tLS0tLS0tLS0tLS0tKyZuYnNwOyZuYnNwOyZuYnNw OyANCiAgICB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgICstLS0t LS0tLS0tLS0tKzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgXiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KICAgIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgfDxCUj4mbmJzcDsmbmJzcDsmbmJz cDsgc2VuZGluZyBvdXQgY2hhbmdlJm5ic3A7IA0KICAgIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIHxyZWNlaXZpbmcgZmxvdzxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgYmluZGluZyANCiAgICByZXF1ZXN0Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsgPz8gfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICB8 Pz8/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHxiaW5kaW5nIA0KICAgIHJlc3BvbnNlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtLS0tLS0tLS0tLS0tLS0tLS0gfCZuYnNwOyZuYnNwOyANCiAgICAtLS0tfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICB8LS0tLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICB8LS0tLS0tLS0tLS0tLS08QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KICAgIHw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyANCiAgICB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIHw8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KICAgIHw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAg IFwmbmJzcDsmbmJzcDsmbmJzcDsgKy0tLS0tLS0tLS0tLS0tLSsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQogICAgLzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQogICAgXC0tLXwgZmxvdyBiaW5kaW5nJm5ic3A7IA0KICAgIHwmbHQ7LS0tLS88QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KICAgICstLS0tLS0tLS0tLS0tLS0rPC9GT05UPjwvRElWPjwvQkxPQ0tRVU9URT5UaGUgcHVy cG9zZSB3aXRoIHRoZSBkcmFmdCBpcyB0byANCiAgZGVmaW5lIHRoZSBydWxlIGxhbmd1YWdlIHRv IGJlIHVzZWQgZm9yIGNyZWF0aW5nIHJvdXRpbmcgcnVsZXMuIFNlY3Rpb24gMyANCiAgIkNvbmNl cHR1YWwgTW9kZWwiIHdhcyBhZGRlZCB0byBoaWdobGlnaHQgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl biBwb2xpY2llcyBhbmQgDQogIHJvdXRpbmcgcnVsZXMuIFRoZSBleGFjdCBiZWhhdmlvciBvZiB0 aGUgIkNvbm5lY3Rpb24gTWFuYWdlciIgaXMgb3V0c2lkZSB0aGUgDQogIHNjb3BlIG9mIHRoZSBk cmFmdCBhbmQgc28gd291bGQgdGhlIHN0YXRlIGRpYWdyYW0gYmUuPEJSPg0KICA8QkxPQ0tRVU9U RSBjaXRlPW1pZDowMDg2MDFjOWJkODAkOGY0MDllMTAkNDAxMDZmMGFAY2hpbmEuaHVhd2VpLmNv bSANCiAgdHlwZT0iY2l0ZSI+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05U IGZhY2U9w6XCruKAucOkwr3igJwgc2l6ZT0yPlNlY29uZGx5LCB0aGVyZSZuYnNwO2FyZSBzb21l IGludGVyLW9wZXJhdGlvbiANCiAgICBwcm9ibGVtcywgSSB0aGluay48L0ZPTlQ+PC9ESVY+DQog ICAgPERJVj48Rk9OVCBmYWNlPcOlwq7igLnDpMK94oCcIHNpemU9Mj5Gb3IgZXhhbXBsZSwgd2hl biB0aGUgbm9kZSwgd2hpY2ggaXMgDQogICAgbXVsdGlob21lZCwgcmVjZWl2ZWQgdGhlIDwvRk9O VD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9w6XCruKAucOkwr3igJwgc2l6ZT0yPmNvbW1h bmQgZnJvbSB1c2VyIHRvIGJlZ2luJm5ic3A7c29tZSBmbG93IA0KICAgIDwvRk9OVD48Rk9OVCBm YWNlPcOlwq7igLnDpMK94oCcIHNpemU9Mj53aXRoIHRoZSBwZWVyLCB0aGUgbm9kZSA8L0ZPTlQ+ PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPcOlwq7igLnDpMK94oCcIHNpemU9Mj5kbyBub3Qg a25vdyB3aGV0aGVyIHRoZSBwZWVyIHN1cHBvcnQgDQogICAgPC9GT05UPjxGT05UIGZhY2U9w6XC ruKAucOkwr3igJwgc2l6ZT0yPnRoZSBjYXBhYmlsaXR5LiZuYnNwO0lmIHRoZSA8L0ZPTlQ+PC9E SVY+DQogICAgPERJVj48Rk9OVCBmYWNlPcOlwq7igLnDpMK94oCcIHNpemU9Mj5ub2RlIHVzZSBp bnRlcmZhY2UgQSB0byBzZW5kIHBhY2tldHMsIA0KICAgIDwvRk9OVD48Rk9OVCBmYWNlPcOlwq7i gLnDpMK94oCcIHNpemU9Mj53aGlsZSA8L0ZPTlQ+PEZPTlQgZmFjZT3DpcKu4oC5w6TCveKAnCBz aXplPTI+dGhlIA0KICAgIHBhY2tldHMgZnJvbSA8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9O VCBmYWNlPcOlwq7igLnDpMK94oCcIHNpemU9Mj5wZWVyIG1heWJlIGNvbWUgdGhyb3VnaCBpbnRl cmZhY2UgQiwgaG93IHRvIA0KICAgIDwvRk9OVD48Rk9OVCBmYWNlPcOlwq7igLnDpMK94oCcIHNp emU9Mj5hdm9pZCBpdCBoYXBwZW4/IDwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9 w6XCruKAucOkwr3igJwgc2l6ZT0yPklmIHRoZSA8L0ZPTlQ+PEZPTlQgZmFjZT3DpcKu4oC5w6TC veKAnCBzaXplPTI+bm9kZSANCiAgICBmaXJzdGx5IGV4Y2hhbmdlIHRoZSBpbmZvcm1hdGlvbiA8 L0ZPTlQ+PEZPTlQgZmFjZT3DpcKu4oC5w6TCveKAnCBzaXplPTI+d2l0aCB0aGUgDQogICAgcGVl ciA8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPcOlwq7igLnDpMK94oCcIHNpemU9 Mj5hbmQgYmVnaW4gPC9GT05UPjxGT05UIGZhY2U9w6XCruKAucOkwr3igJwgc2l6ZT0yPmZsb3cg DQogICAgbGF0ZXIsIGhvdyBhYm91dCB0aGUgZGVsYXkgZHVyaW5nIDwvRk9OVD48Rk9OVCBmYWNl PcOlwq7igLnDpMK94oCcIHNpemU9Mj50aGUgDQogICAgcHJvY2VkdXJlPzwvRk9OVD48L0RJVj4N CiAgICA8RElWPjxGT05UIGZhY2U9w6XCruKAucOkwr3igJwgc2l6ZT0yPk9yIHdlIGRvIG5vdCBj YXJlIHRoZSBpc3N1ZXM/PC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT3DpcKu4oC5 w6TCveKAnCBzaXplPTI+QW5vdGhlciBleGFtcGxlLCZuYnNwO2lmIHRoZSBub2RlIHdhbnQgdG8g DQogICAgY2hhbmdlIHRoZSBmbG93IGJpbmRpbmcgPC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZP TlQgZmFjZT3DpcKu4oC5w6TCveKAnCBzaXplPTI+ZnJvbSZuYnNwO2ludGVyZmFjZSBBIHRvIGlu dGVyZmFjZSBCLCB3aGVuIA0KICAgIHNob3VsZCB0aGUgbm9kZSBiZWdpbiB0byA8L0ZPTlQ+PC9E SVY+DQogICAgPERJVj48Rk9OVCBmYWNlPcOlwq7igLnDpMK94oCcIHNpemU9Mj5zZW5kIDwvRk9O VD48Rk9OVCBmYWNlPcOlwq7igLnDpMK94oCcIA0KICAgIHNpemU9Mj5wYWNrZXQmbmJzcDt0aHJv dWdoIGludGVyZmFjZSBCPyBBZnRlciBzZW5kaW5nIHRoZSByZXF1ZXN0IG9yIA0KICAgIDwvRk9O VD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9w6XCruKAucOkwr3igJwgc2l6ZT0yPmFmdGVy IDwvRk9OVD48Rk9OVCBmYWNlPcOlwq7igLnDpMK94oCcIA0KICAgIHNpemU9Mj5yZWNlaXZpbmcg dGhlIHJlc3BvbnNlPzwvRk9OVD48L0RJVj48L0JMT0NLUVVPVEU+DQogIDxESVY+VmVyeSBnb29k IHF1ZXN0aW9ucyBhbmQgdGhleSBkZWZpbml0ZWx5IGhhdmUgdG8gYmUgb3V0bGluZWQuIEkgYmVs aWV2ZSANCiAgdGhlIGlzc3VlcyB5b3UgYnJvdWdodCB1cCBoZXJlIHNob3VsZCBiZSBvdXRsaW5l ZCBpbiBIZXNoYW0ncyBkcmFmdCwgd2hpY2ggDQogIGRlZmluZXMgaG93IHRoZSBSb3V0aW5nIFJ1 bGVzIGFyZSB0cmFuc3BvcnRlZCBmcm9tIHRoZSBNTiB0byB0aGUgSEEvQ04uIFRoaXMgDQogIGRy YWZ0IHNob3VsZCBleHBsYWluIHRoZSBwcm9jZWR1cmUgaW4gdGhlIE1OL0hBL0NOIHdoZW4gdGhl IFJvdXRpbmcgUnVsZXMgYXJlIA0KICBhY2NlcHRlZC9ub3QgYWNjZXB0ZWQsIGkuZS4sIHdoZW4g dG8gc3RhcnQgc2VuZGluZyB0cmFmZmljIHVzaW5nIHRoZSBuZXcgDQogIFJvdXRpbmcgUnVsZXMu PEJSPjxCUj5UaGFua3MgZm9yIHlvdXIgcmV2aWV3LjxCUj48QlI+UmVnYXJkczxCUj5Db25ueSAN CiAgTGFyc3NvbjxCUj48L0RJVj48L0JMT0NLUVVPVEU+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0K c3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZU OiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgi Pg0KICA8QkxPQ0tRVU9URSBjaXRlPW1pZDowMDg2MDFjOWJkODAkOGY0MDllMTAkNDAxMDZmMGFA Y2hpbmEuaHVhd2VpLmNvbSANCiAgdHlwZT0iY2l0ZSI+DQogICAgPERJVj48Rk9OVCBmYWNlPeWu i+S9kyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT3DpcKu 4oC5w6TCveKAnCBzaXplPTI+SSB0aGluayB0aGUgc29sdXRpb24gbmVlZCBtb3JlIGRldGFpbGVk IA0KICAgIHN0YXRlbWVudC48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAg ICA8RElWPjxGT05UIGZhY2U9w6XCruKAucOkwr3igJwgc2l6ZT0yPlJlZ2FyZHM8L0ZPTlQ+PC9E SVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9w6XCruKAucOk wr3igJwgc2l6ZT0yPlhpYW5nc29uZzwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9 w6XCjcW9w6bigJPigKHDp8K74oCgw6nCu+KAmCBjb2xvcj1ncmF5IHNpemU9Mj7DpcKNxb3DpMK4 wrrDpsWg4oKsw6bFk8Kvw6bFk+KAsMOp4oSiwpDDpeKApsKsw6XCj8K4IA0KICAgIDwvRk9OVD48 SU1HIGlkPXJpZEltZyBhbHQ9aHVhd2VpX2xvZ28gaHNwYWNlPTAgDQogICAgc3JjPSJjaWQ6MGQy YzAxYzliZjQxJGJkNzk5MGQwJDQwMTA2ZjBhQGNoaW5hLmh1YXdlaS5jb20iIGFsaWduPWxlZnQ+ IA0KICAgIDxCUj48Rk9OVCBmYWNlPcOlwo3FvcOm4oCT4oChw6fCu+KAoMOpwrvigJggY29sb3I9 Z3JheSANCiAgICBzaXplPTE+w6XFk8Kww6XCneKCrMOvwrzFocOmwrfCscOlxZPCs8OlwrjigJrD qcK+4oSiw6XCsuKAlMOlxZLCusOlwp3igJrDp+KAncKww6XCjcW9w6TCuMK6w6XFuMK6w6XFk8Kw IMOp4oCawq7Dp8K84oCTw6/CvMWhNTE4MTI5PEJSPjxBIA0KICAgIGhyZWY9Imh0dHA6Ly93d3cu aHVhd2VpLmNvbSIgDQogICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwOi8vd3d3Lmh1YXdl aS5jb208L0E+PEJSPjwvRk9OVD48Rk9OVCANCiAgICBmYWNlPcOlwo3FvcOm4oCT4oChw6fCu+KA oMOpwrvigJggY29sb3I9Z3JheSANCiAgICBzaXplPTE+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj7D psWTwqzDqeKAmsKuw6TCu8K2w6XCj8Wgw6XigKbCtsOp4oSi4oCew6TCu8K2w6XCkMKrw6bFk+KA sMOlwo3FvcOkwrjCusOl4oCmwqzDpcKPwrjDp8Wh4oCew6TCv8Kdw6XCr+KAoMOkwr/CocOmwoHC r8OvwrzFksOkwrvigKbDqeKEosKQw6TCusW9w6XCj+KAmMOp4oKswoHDp8K74oSiw6TCuMWgw6nC ncKiw6XFk8Kww6XCneKCrMOkwrgmc2h5O8Oly4bigJTDpeKAocK6w6fFoeKAnsOkwrjCqsOkwrrC usOmy4bigJPDp8K+wqTDp8K74oCew6PigqzigJrDp8KmwoE8QlI+w6Ymc2h5O8Kiw6TCu8K7w6TC veKAosOl4oCmwrbDpMK74oCTw6TCusK6w6TCu8Klw6TCu8K7w6TCveKAosOlwr3CosOlwrzCj8Ok wr3Cv8On4oCdwqjDr8K8y4bDpcWS4oCmw6bigLnCrMOkwr3igKDDpMK4wo3DqeKEosKQw6TCusW9 w6XigKbCqMOpxpLCqMOmy4bigJPDqcaSwqjDpcuG4oCgw6XFk8Kww6bCs+KAnsOpxZPCssOj4oKs woHDpcKkwo3DpcuGwrbDo+KCrMKBw6bLhuKAk8Om4oCiwqPDpcKP4oCYw6/CvOKAsMOmxZPCrMOp 4oCawq7DpMK7wrbDpMK4JnNoeTs8QlI+w6fFoeKAnsOkwr/CocOmwoHCr8Oj4oKs4oCaw6XCpuKA msOmxb7Fk8Om4oCawqjDqeKAneKEosOm4oCdwrbDpMK64oCgw6bFk8Ksw6nigJrCrsOkwrvCtsOv wrzFksOowq/Ct8Om4oCawqjDp8Kr4oC5w6XCjcKzw6figJ3CtcOowq/CncOmy4bigJPDqeKAmsKu w6TCu8K2w6nigqzFocOnxbjCpcOlwo/igJjDpMK7wrbDpMK6wrrDpcK5wrbDpcuGJm5ic3A7w6ni hKLCpMOmxZPCrMOp4oCawq7DpMK7wrbDr8K8woE8QlI+PC9GT05UPjxGT05UIA0KICAgIGZhY2U9 QXJpYWwgY29sb3I9Z3JheSBzaXplPTE+VGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBj b250YWluIA0KICAgIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2gg PEJSPmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSANCiAgICBwZXJzb24gb3IgZW50aXR5IHdob3Nl IGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSANCiAgICA8QlI+aW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGlt aXRlZCB0bywgDQogICAgdG90YWwgb3IgcGFydGlhbCA8QlI+ZGlzY2xvc3VyZSwgcmVwcm9kdWN0 aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIA0KICAgIG90aGVyIHRoYW4gdGhlIGlu dGVuZGVkIDxCUj5yZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhp cyANCiAgICBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSA8QlI+ cGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgDQogICAgYW5kIGRlbGV0ZSBpdCE8QlI+PC9GT05U PjwvRElWPg0KICAgIDxCTE9DS1FVT1RFIA0KICAgIHN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7 IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogcmdiKDAs MCwwKSAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICAgIDxESVYgDQogICAgICBz dHlsZT0iRk9OVDogOXB0IMOlwq7igLnDpMK94oCcOyBmb250LXNpemUtYWRqdXN0OiBub25lOyBm b250LXN0cmV0Y2g6IG5vcm1hbCI+LS0tLS0gDQogICAgICBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IDwvRElWPg0KICAgICAgPERJViANCiAgICAgIHN0eWxlPSJCQUNLR1JPVU5EOiByZ2IoMjI4LDIy OCwyMjgpIDAlIDUwJTsgRk9OVDogOXB0IMOlwq7igLnDpMK94oCcOyBmb250LXNpemUtYWRqdXN0 OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1hbDsgbW96LWJhY2tncm91bmQtY2xpcDogLW1vei1p bml0aWFsOyBtb3otYmFja2dyb3VuZC1vcmlnaW46IC1tb3otaW5pdGlhbDsgbW96LWJhY2tncm91 bmQtaW5saW5lLXBvbGljeTogLW1vei1pbml0aWFsIj48Qj5Gcm9tOjwvQj4gDQogICAgICA8QSB0 aXRsZT1jb25ueS5sYXJzc29uQGVyaWNzc29uLmNvbSANCiAgICAgIGhyZWY9Im1haWx0bzpjb25u eS5sYXJzc29uQGVyaWNzc29uLmNvbSIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5Db25ueSANCiAg ICAgIExhcnNzb248L0E+IDwvRElWPg0KICAgICAgPERJViANCiAgICAgIHN0eWxlPSJGT05UOiA5 cHQgw6XCruKAucOkwr3igJw7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZvbnQtc3RyZXRjaDog bm9ybWFsIj48Qj5Ubzo8L0I+IA0KICAgICAgPEEgdGl0bGU9bWV4dEBpZXRmLm9yZyBocmVmPSJt YWlsdG86bWV4dEBpZXRmLm9yZyIgDQogICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPm1leHQ8 L0E+IDsgPEEgdGl0bGU9bWFyY2Vsb0BpdC51YzNtLmVzIA0KICAgICAgaHJlZj0ibWFpbHRvOm1h cmNlbG9AaXQudWMzbS5lcyIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5tYXJjZWxvIA0KICAgICAg YmFnbnVsbzwvQT4gOyA8QSB0aXRsZT1qdWxpZW4ubGFnYW5pZXIuSUVURkBnb29nbGVtYWlsLmNv bSANCiAgICAgIGhyZWY9Im1haWx0bzpqdWxpZW4ubGFnYW5pZXIuSUVURkBnb29nbGVtYWlsLmNv bSIgDQogICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmp1bGllbi5sYWdhbmllci5JRVRGQGdv b2dsZW1haWwuY29tPC9BPiA8L0RJVj4NCiAgICAgIDxESVYgDQogICAgICBzdHlsZT0iRk9OVDog OXB0IMOlwq7igLnDpMK94oCcOyBmb250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6 IG5vcm1hbCI+PEI+U2VudDo8L0I+IA0KICAgICAgVHVlc2RheSwgQXByaWwgMTQsIDIwMDkgMTE6 MzUgUE08L0RJVj4NCiAgICAgIDxESVYgDQogICAgICBzdHlsZT0iRk9OVDogOXB0IMOlwq7igLnD pMK94oCcOyBmb250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1hbCI+PEI+ U3ViamVjdDo8L0I+IA0KICAgICAgW01FWFRdIENhbGwgZm9yIGFkb3B0YXRpb24gDQogICAgICBv ZmRyYWZ0LWxhcnNzb24tbWV4dC1mbG93LWRpc3RyaWJ1dGlvbi1ydWxlczwvRElWPg0KICAgICAg PERJVj48QlI+PC9ESVY+SGksPEJSPjxCUj5UaGlzIGlzIGEgcmVxdWVzdCB0byB0aGUgTUVYVCB3 b3JraW5nIGdyb3VwIHRvIA0KICAgICAgYWRvcHQgPEJSPmRyYWZ0LWxhcnNzb24tbWV4dC1mbG93 LWRpc3RyaWJ1dGlvbi1ydWxlcyB0byBjb3ZlciB0aGUgY2hhcnRlciANCiAgICAgIGl0ZW06PEJS PjxCUj4oQS4zKSBVc2Ugb2YgbXVsdGlwbGUgaW50ZXJmYWNlcy48QlI+Li4uPEJSPkRlbGl2ZXJh YmxlcyANCiAgICAgIHJlbGF0ZWQgdG8gdGhpcyBpbmNsdWRlPEJSPi0gQSAiRmxvdy9iaW5kaW5n IHBvbGljaWVzIGV4Y2hhbmdlIiBzb2x1dGlvbiANCiAgICAgIGZvciBhbiBleGNoYW5nZSBvZjxC Uj5wb2xpY2llcyBmcm9tIHRoZSBtb2JpbGUgaG9zdC9yb3V0ZXIgdG8gdGhlIEhvbWUgDQogICAg ICBBZ2VudCBhbmQgZnJvbSB0aGU8QlI+SG9tZSBBZ2VudCB0byB0aGUgbW9iaWxlIGhvc3Qvcm91 dGVyIGluZmx1ZW5jaW5nIHRoZSANCiAgICAgIGNob2ljZSBvZiB0aGU8QlI+Q2FyZS1vZiBBZGRy ZXNzIGFuZCBIb21lIEFnZW50IGFkZHJlc3MuIFRoZSBzb2x1dGlvbiANCiAgICAgIGludm9sdmVz IHR3bzxCUj5zcGVjaWZpY2F0aW9ucywgb25lIGZvciB0aGUgcG9saWN5IGZvcm1hdCBhbmQgYW5v dGhlciBmb3IgDQogICAgICBpdHM8QlI+dHJhbnNwb3J0IFtib3RoIFN0YW5kYXJkIFRyYWNrXS48 QlI+PEJSPjxCUj5UaGUgc3RhdHVzIG9mIHRoZSANCiAgICAgIHdvcmtpbmcgZ3JvdXAgaXMgdGhh dCB3ZSBoYXZlIGEgZHJhZnQgPEJSPig8QSANCiAgICAgIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbW9uYW1pNi1tdWx0aXBsZWNvYS0xMiIgDQogICAgICBtb3ot ZG8tbm90LXNlbmQ9InRydWUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bW9uYW1pNi1tdWx0aXBsZWNvYS0xMjwvQT4pIA0KICAgICAgZm9yIDxCUj5yZWdpc3RyYXRpb24g b2YgbXVsdGlwbGUgY2FyZS1vZiBhZGRyZXNzZXMgdG8gb25lIGhvbWUgDQogICAgICBhZGRyZXNz LjxCUj5UaGVyZSBleGlzdCBvbmUgZHJhZnQgPEJSPig8QSANCiAgICAgIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWV4dC1mbG93LWJpbmRpbmctMDEiIA0KICAg ICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1leHQtZmxvdy1iaW5kaW5nLTAxPC9BPikgDQogICAgICBmb3IgPEJSPnRyYW5zcG9y dCBvZiB0aGUgcnVsZXMgdGhhdCBkZWNpZGVzIGhvdyBlYWNoIGZsb3cgaXMgc2VudCBvdmVyIHRo ZSANCiAgICAgIDxCUj5hdmFpbGFibGUgbmV0d29yayBpbnRlcmZhY2VzLjxCUj48QlI+V2hhdCBp cyBjdXJyZW50bHkgbWlzc2luZyBpcyB0aGUgDQogICAgICBwYXJ0IHRoYXQgZGVmaW5lcyB0aGUg cnVsZXMuIA0KICAgICAgPEJSPmRyYWZ0LWxhcnNzb24tbWV4dC1mbG93LWRpc3RyaWJ1dGlvbi1y dWxlcyBkZWZpbmVzIGEgcnVsZSBsYW5ndWFnZSANCiAgICAgIHRoYXQgPEJSPmNhbiBiZSB1c2Vk IGZvciB0aGlzLiBUaGUgZG9jdW1lbnQgY2FuIGJlIGZvdW5kIGF0OjxCUj48QlI+PEEgDQogICAg ICBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sYXJzc29uLW1leHQtZmxv dy1kaXN0cmlidXRpb24tcnVsZXMtMDIiIA0KICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sYXJzc29uLW1leHQtZmxvdy1kaXN0cmli dXRpb24tcnVsZXMtMDI8L0E+PEJSPjxCUj5QbGVhc2UgDQogICAgICBleHByZXNzIHlvdXIgb3Bp bmlvbiBvbiB3aGV0aGVyIHRoaXMgc2hvdWxkIGJlY29tZSBhIFdHIA0KICAgICAgZG9jdW1lbnQu PEJSPjxCUj48QlI+UmVnYXJkczxCUj5Db25ueTxCUj48QlI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188QlI+TUVYVCANCiAgICAgIG1haWxpbmcgbGlzdDxC Uj48QSBocmVmPSJtYWlsdG86TUVYVEBpZXRmLm9yZyIgDQogICAgICBtb3otZG8tbm90LXNlbmQ9 InRydWUiPk1FWFRAaWV0Zi5vcmc8L0E+PEJSPjxBIA0KICAgICAgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0IiANCiAgICAgIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0PC9BPjwvQkxP Q0tRVU9URT48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_z9rgn1uxni/8jNTkvBKSog)-- --Boundary_(ID_HjhngwGM60NOakMDepQRJg) Content-id: <0d2a01c9bf41$bd7990d0$40106f0a@china.huawei.com> Content-type: image/jpeg; name=outlook_huawei_logo_cn.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_cn.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_HjhngwGM60NOakMDepQRJg) Content-id: <0d2c01c9bf41$bd7990d0$40106f0a@china.huawei.com> Content-type: image/jpeg Content-transfer-encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_HjhngwGM60NOakMDepQRJg)-- From conny.larsson@ericsson.com Fri Apr 17 04:09:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C09828C126 for ; Fri, 17 Apr 2009 04:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.228 X-Spam-Level: X-Spam-Status: No, score=-5.228 tagged_above=-999 required=5 tests=[AWL=1.021, 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 Vlr93m2uB6Hc for ; Fri, 17 Apr 2009 04:09:04 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0072828C0F7 for ; Fri, 17 Apr 2009 04:09:03 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 56C772583E; Fri, 17 Apr 2009 13:05:13 +0200 (CEST) X-AuditID: c1b4fb3e-ad021bb0000024d5-c8-49e8511eb546 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 657C523716; Fri, 17 Apr 2009 11:51:26 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 11:47:21 +0200 Received: from [127.0.0.1] ([147.214.130.137]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 11:47:21 +0200 Message-ID: <49E85026.9040307@ericsson.com> Date: Fri, 17 Apr 2009 11:47:18 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <49E83390.30507@it.uc3m.es> <4C51279E-272C-4C8F-A7B1-938014312287@lsiit.u-strasbg.fr> <49E84374.6030808@it.uc3m.es> In-Reply-To: <49E84374.6030808@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 Apr 2009 09:47:21.0929 (UTC) FILETIME=[81445B90:01C9BF41] X-Brightmail-Tracker: AAAAAA== Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 11:09:05 -0000 Hi Marcelo, I agree. Regards marcelo bagnulo braun wrote: > thanks Romain > > sigh, i should never ever send emails to public mls before breakfast!!! > > Let me try again (and i am sorry for this > > > In the charter we have: > > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > For this deliverable we have: > > draft-ietf-mext-flow-binding-01.txt defines the transport part of the > last sentence in the paragraph above. > > draft-larsson-mext-flow-distribution-rules and the other binary > encoding defines the policy format of the last sentence of the charter > paragraph above. > > We all agree? > > Regards, marcelo > > > Romain KUNTZ escribió: >> Hi, >> >> On 2009/04/17, at 9:45, marcelo bagnulo braun wrote: >>> In the charter we have: >>> >>> - A "Flow/binding policies exchange" solution for an exchange of >>> policies from the mobile host/router to the Home Agent and from the >>> Home Agent to the mobile host/router influencing the choice of the >>> Care-of Address and Home Agent address. The solution involves two >>> specifications, one for the policy format and another for its >>> transport [both Standard Track]. >>> >>> For this deliverable we have: >>> >>> draft-ietf-mext-flow-binding-01.txt defines the format part of the >>> last sentence in the paragraph above. >> >> I think you meant *transport* and not format here. Note that an >> alternative transport solution using Generic Notification Messages >> was also proposed here: >> http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules-00 >> >>> draft-larsson-mext-flow-distribution-rules and the other binary >>> encoding (we don't have a draft for this yet, right?) defines the >>> policy format of the last sentence of the charter paragraph above. >>> >>> We all agree? >> >> Yes, >> >> Cheers, > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From rfc-editor@rfc-editor.org Tue Apr 14 14:06:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54D83A6879; Tue, 14 Apr 2009 14:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.93 X-Spam-Level: X-Spam-Status: No, score=-16.93 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 mKDjijwBKwfv; Tue, 14 Apr 2009 14:06:20 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 0C9843A659C; Tue, 14 Apr 2009 14:06:20 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id CBF6A28145F; Tue, 14 Apr 2009 14:05:52 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090414210552.CBF6A28145F@bosco.isi.edu> Date: Tue, 14 Apr 2009 14:05:52 -0700 (PDT) X-Mailman-Approved-At: Fri, 17 Apr 2009 05:53:41 -0700 Cc: mext@ietf.org, rfc-editor@rfc-editor.org Subject: [MEXT] RFC 5488 on Network Mobility (NEMO) Management Information Base X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 21:06:20 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5488 Title: Network Mobility (NEMO) Management Information Base Author: S. Gundavelli, G. Keeni, K. Koide, K. Nagami Status: Standards Track Date: April 2009 Mailbox: sgundave@cisco.com, glenn@cysols.com, ka-koide@kddi.com, nagami@inetcore.com Pages: 44 Characters: 87041 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mext-nemo-mib-06.txt URL: http://www.rfc-editor.org/rfc/rfc5488.txt This memo defines a portion of the Management Information Base (MIB), the Network Mobility (NEMO) support MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. [STANDARDS TRACK] This document is a product of the Mobility EXTensions for IPv6 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From conny.larsson@ericsson.com Fri Apr 17 06:18:51 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01AF3A6A5D for ; Fri, 17 Apr 2009 06:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.568 X-Spam-Level: X-Spam-Status: No, score=-5.568 tagged_above=-999 required=5 tests=[AWL=0.681, 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 Qfy9DY4CRSVV for ; Fri, 17 Apr 2009 06:18:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4DA3E3A6868 for ; Fri, 17 Apr 2009 06:18:50 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9D79323AAD; Fri, 17 Apr 2009 15:19:26 +0200 (CEST) X-AuditID: c1b4fb3e-ae023bb0000024d5-ca-49e8665624c9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 86ECE23B1C; Fri, 17 Apr 2009 13:21:58 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 13:21:31 +0200 Received: from [127.0.0.1] ([147.214.130.137]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 13:21:30 +0200 Message-ID: <49E86639.1000804@ericsson.com> Date: Fri, 17 Apr 2009 13:21:29 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Kazuyuki Tasaka References: <49E4AD42.5000800@ericsson.com> <49E4B5EC.6090701@it.uc3m.es> <49E4BB6C.6030702@it.uc3m.es> <49E7576E.9010200@it.uc3m.es> <49E781C0.7070900@kddilabs.jp> In-Reply-To: <49E781C0.7070900@kddilabs.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 Apr 2009 11:21:30.0494 (UTC) FILETIME=[A812F9E0:01C9BF4E] X-Brightmail-Tracker: AAAAAA== Cc: julien.laganier.IETF@googlemail.com, mext Subject: Re: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 13:18:52 -0000 Hi Tasaka, Yes you are right, both static and dynamic configuration of filters are supported. In section 5.3 "Conditional Rule-Sets" there is an example of how a static configuration of the rules can be used. Regards Conny Kazuyuki Tasaka wrote: > Hi Marcelo and Ryuji, > > Conny's document only defines generic rule language as a mean to > define and perform per flow path selection for a multi-homed node. > I think this document can provide static and dynamic configuration of > filters. > Flow filters are installed statically at the HA and MN. On the other > hands, in case of dynamic configuration, this document depends on > the transport protocol (e.g. flow bindings) to exchange flow filters > with other nodes . But the transport protocol is outside the scope of > this document and generic rule languages to statically and dynamically > configure are difined. > > Regards, tasaka. > > Ryuji Wakikawa Wrote: >> Hi Marcelo, >> >> Well, you are not lost, but I was actually lost. >> After reading the spec, they changed the draft a lot since I >> contributed to.. >> I asked Tasaka (KDDI guy) to explain the position of this draft. >> >> thanks >> ryuji >> >> On 2009/04/16, at 12:06, marcelo bagnulo braun wrote: >> >>> now i am lost, i understood that we had two ways to dynamically >>> confgure filters, binary and conny's draft and that's what we were >>> discussing... didn't thought that it was static versus dynamic >>> configuration of filters...so what is it? >>> >>> >>> Ryuji Wakikawa escribió: >>>> Hi Marcelo, >>>> >>>> When we have discussed flow management, there are two approaches >>>> (one is flow binding). >>>> The other approach is to install flow filters statically at the HA >>>> and MN and switch them according to binding cache. >>>> >>>> Let's say MN and HA are statically configured with these three >>>> filters set. According to binding cache database, >>>> each node switch the filter. >>>> >>>> BID1 only -> filter1 >>>> BID1 and BID2 -> filter2 >>>> BID2 only -> filter3 >>>> >>>> Flow binding has advantages on dynamic updates, but, on the other >>>> hand, some operators (let's say KDDI) prefer using >>>> more stable filter. The operator ships the terminal with >>>> pre-defined filter rules. The dynamic management leads certain >>>> overhead, too. >>>> That' why we have this Conny's document. >>>> AFAIK, this document does not specify any transport mechanism, but >>>> define only syntax of filters. >>>> >>>> Of course, you might use SSL, HTTPs, even flow binding (as George >>>> said), and any other mechanism to exchange these filters (if you >>>> want dynamic filters exchange). >>>> To define a general filter syntax is very useful. This can be >>>> targetted to informational or experimental RFC. >>>> >>>> thanks >>>> ryuji >>>> >>>> >>>> On 2009/04/14, at 12:35, marcelo bagnulo braun wrote: >>>> >>>>> i wonder if we need the advanced features at this point >>>>> I mean, we are just defining this, wouldn't make sense to wait and >>>>> see if with the basic procedure is enough and do the extnesions >>>>> later? Or is the basic mechanism so limited that is not enough to >>>>> handle simple basic scenarios? If that is the case, does it makes >>>>> sense to even define it? >>>>> >>>>> Bottom line, we need strong reasons to do things in multiple >>>>> different ways. Unless clear reasons are described, i fail to see >>>>> why we should standardize multiple approaches >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> >>>>> George Tsirtsis escribió: >>>>>> Hi Marcelo, >>>>>> >>>>>> In the Monami6 days, the Flow Bindings draft used to include a >>>>>> binary >>>>>> Flow Descriptor as part of the FID option. >>>>>> This was basically a typical fixed length binary format defining a >>>>>> classifier filterm including source and destination addresses, >>>>>> protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not >>>>>> forget something; both IPv4 and IPv6 can be supported with this. >>>>>> >>>>>> Some people, however, thought that more flexible FDs should be >>>>>> allowed >>>>>> and Conny's draft describes a text based format which is clearly >>>>>> more >>>>>> flexible but also more verbose. >>>>>> >>>>>> At the time, the WG decided that the FD format should be taken >>>>>> out of >>>>>> the Flow Bindings draft. I am not sure I like that but this is >>>>>> indeed >>>>>> what happened. >>>>>> So, now the Flow Bindings draft allows for different FD formats, but >>>>>> it does not define any of them. >>>>>> >>>>>> As a minimum, IMO the protocol should define one format as the >>>>>> default >>>>>> that all implementations MUST support, so that we can have >>>>>> interoperable implementations. >>>>>> IMO this should be the binary format which is the most compact and >>>>>> will work for most of the cases anyway. I do not care too much if >>>>>> this >>>>>> is defined in the same or on a separate (albeit tightly coupled) >>>>>> drafts. >>>>>> >>>>>> It is also ok with me to have other optional formats (like Conny's) >>>>>> for more advanced use cases. >>>>>> >>>>>> I hope this helps >>>>>> >>>>>> George >>>>>> >>>>>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun >>>>>> wrote: >>>>>> >>>>>>> George Tsirtsis escribió: >>>>>>> >>>>>>>> Hi Conny, >>>>>>>> >>>>>>>> Good to see you are resurrecting this draft. I think we need >>>>>>>> this as >>>>>>>> one of the alternatives. We also need a binary version which I >>>>>>>> will be >>>>>>>> working on with others after I am done updating the Flow Bindings >>>>>>>> draft. >>>>>>>> >>>>>>>> >>>>>>> could you expand on this? >>>>>>> I mean, are you saying that we need two ways of describing flows? >>>>>>> >>>>>>> Regards, marcelo >>>>>>> >>>>>>> >>>>>>>> Thanks >>>>>>>> George >>>>>>>> >>>>>>>> On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> This is a request to the MEXT working group to adopt >>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the >>>>>>>>> charter item: >>>>>>>>> >>>>>>>>> (A.3) Use of multiple interfaces. >>>>>>>>> ... >>>>>>>>> Deliverables related to this include >>>>>>>>> - A "Flow/binding policies exchange" solution for an exchange of >>>>>>>>> policies from the mobile host/router to the Home Agent and >>>>>>>>> from the >>>>>>>>> Home Agent to the mobile host/router influencing the choice of >>>>>>>>> the >>>>>>>>> Care-of Address and Home Agent address. The solution involves two >>>>>>>>> specifications, one for the policy format and another for its >>>>>>>>> transport [both Standard Track]. >>>>>>>>> >>>>>>>>> >>>>>>>>> The status of the working group is that we have a draft >>>>>>>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) >>>>>>>>> for >>>>>>>>> registration of multiple care-of addresses to one home address. >>>>>>>>> There exist one draft >>>>>>>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for >>>>>>>>> transport >>>>>>>>> of the rules that decides how each flow is sent over the >>>>>>>>> available >>>>>>>>> network >>>>>>>>> interfaces. >>>>>>>>> >>>>>>>>> What is currently missing is the part that defines the rules. >>>>>>>>> draft-larsson-mext-flow-distribution-rules defines a rule >>>>>>>>> language that >>>>>>>>> can >>>>>>>>> be used for this. The document can be found at: >>>>>>>>> >>>>>>>>> http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02 >>>>>>>>> >>>>>>>>> >>>>>>>>> Please express your opinion on whether this should become a WG >>>>>>>>> document. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Conny >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Fri Apr 17 06:32:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8403A690D for ; Fri, 17 Apr 2009 06:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 iItVOc86kT3E for ; Fri, 17 Apr 2009 06:32:03 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B9C623A677C for ; Fri, 17 Apr 2009 06:32:03 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap002.it.uc3m.es [163.117.139.44]) by smtp02.uc3m.es (Postfix) with ESMTP id 7958C6C15F2; Fri, 17 Apr 2009 15:33:15 +0200 (CEST) Message-ID: <49E8851B.50407@it.uc3m.es> Date: Fri, 17 Apr 2009 15:33:15 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext , Julien Laganier , Jari Arkko Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16586.007 Subject: [MEXT] New ground rules for adopting WG documents and to forward documents to IESG X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 13:32:04 -0000 Hi, There is one issue that we (the chairs) have been concerned about lately is the lack of energy in some documents. This lack of energy results in lack of thorough reviews of the documents and decrease the quality of the output of the WG. In order to address this concern, we propose the following ground rules to progress documents in the MEXT WG. In order for a document to be adopted as a WG document, the document MUST have 5 thorough reviews. Similarly, in order for the document to be sent to the IESG, the document MUST have 5 thorough reviews. So, the proposed procedure is as follows. The Chairs will issue a call for adoption/WGLC for a given document. The call will include a deadline (normally 2 or 3 weeks, as usual). The decision of the adoption will be taken when the deadline is over AND 5 thorough reviews have been received. This means that if the deadline has passed and we haven't received the number of reviews, the decision will wait until we receive the reviews. It should be noted that the reviews must be serious, in depth reviews. Light reviews will not count as one of the required reviews. There are not so clear definition about what a serious review is but i guess we all recognize one when we see it. We propose that we adopt this procedure from now on. Regards, marcelo (on behalf of the chairs) From Basavaraj.Patil@nokia.com Fri Apr 17 14:29:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719C83A6A10 for ; Fri, 17 Apr 2009 14:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 F9P4PDtwUFWu for ; Fri, 17 Apr 2009 14:29:49 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 40C103A6EAB for ; Fri, 17 Apr 2009 14:29:49 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3HLUtQp002878; Fri, 17 Apr 2009 16:30:59 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 18 Apr 2009 00:30:51 +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); Sat, 18 Apr 2009 00:30:47 +0300 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 17 Apr 2009 23:30:46 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.108]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Fri, 17 Apr 2009 23:30:46 +0200 From: To: , , , Date: Fri, 17 Apr 2009 23:30:55 +0200 Thread-Topic: [MEXT] New ground rules for adopting WG documents and to forward documents to IESG Thread-Index: Acm/YSAwKKvaWN8WQgugMtD/4EG/+QAQqoGM Message-ID: In-Reply-To: <49E8851B.50407@it.uc3m.es> 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: 17 Apr 2009 21:30:47.0088 (UTC) FILETIME=[C5808B00:01C9BFA3] X-Nokia-AV: Clean Subject: Re: [MEXT] New ground rules for adopting WG documents and to forward documents to IESG X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 21:29:50 -0000 Hi Marcelo, Does it mean that any I-D that is able to receive 5 reviews will be automatically accepted as WG documents? This is a flawed approach. Ensuring that a document gets sufficient review is something that the chair= s can proactively work on. I have no problem in the MEXT WG trying this approach to see if you get mor= e independent reviews vs a document author/editor signing up 5 of his buddies to submit reviews :) Is it the number of reviews that matter or the quality of reviews? Cheers, -Raj On 4/17/09 8:33 AM, "Marcelo Bagnulo" wrote: > Hi, >=20 > There is one issue that we (the chairs) have been concerned about lately > is the lack of energy in some documents. This lack of energy results in > lack of thorough reviews of the documents and decrease the quality of > the output of the WG. >=20 > In order to address this concern, we propose the following ground rules > to progress documents in the MEXT WG. >=20 > In order for a document to be adopted as a WG document, the document > MUST have 5 thorough reviews. >=20 > Similarly, in order for the document to be sent to the IESG, the > document MUST have 5 thorough reviews. >=20 > So, the proposed procedure is as follows. >=20 > The Chairs will issue a call for adoption/WGLC for a given document. The > call will include a deadline (normally 2 or 3 weeks, as usual). The > decision of the adoption will be taken when the deadline is over AND 5 > thorough reviews have been received. This means that if the deadline has > passed and we haven't received the number of reviews, the decision will > wait until we receive the reviews. >=20 > It should be noted that the reviews must be serious, in depth reviews. > Light reviews will not count as one of the required reviews. There are > not so clear definition about what a serious review is but i guess we > all recognize one when we see it. >=20 > We propose that we adopt this procedure from now on. >=20 > Regards, marcelo > (on behalf of the chairs) > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Sat Apr 18 00:33:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2873A6AB5 for ; Sat, 18 Apr 2009 00:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 iYA2W-OMjJOx for ; Sat, 18 Apr 2009 00:33:44 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id E07DC3A6AB3 for ; Sat, 18 Apr 2009 00:33:43 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (146.pool85-53-143.dynamic.orange.es [85.53.143.146]) by smtp01.uc3m.es (Postfix) with ESMTP id DA2DFBA4FE2; Sat, 18 Apr 2009 09:34:53 +0200 (CEST) Message-ID: <49E9829E.2020809@it.uc3m.es> Date: Sat, 18 Apr 2009 09:34:54 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) 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: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16588.005 Cc: jari.arkko@piuha.net, julien.laganier.ietf@googlemail.com, mext@ietf.org Subject: Re: [MEXT] New ground rules for adopting WG documents and to forward documents to IESG X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 07:33:45 -0000 Hi Raj, replies below... Basavaraj.Patil@nokia.com escribió: > Hi Marcelo, > > Does it mean that any I-D that is able to receive 5 reviews will be > automatically accepted as WG documents? by no means it means that in order to accept a ID, we need rough consensus (as always) _and_ 5 reviews. In other words, what we need is people who have actually seriously reviewed the document and reach rough consensus that we need to accept it > This is a flawed approach. > i hope that with the clarification above, it makes more sense to you > Ensuring that a document gets sufficient review is something that the chairs > can proactively work on. > > haven't worked for us so far and believe me, we tried. We tried asking people for reviews in indiviudual emails, we have tried doing it in the public ml we have tried to get people committing to make reviews when we do the recharter process and then remind them about their commitment both privately and publicly and while some people do react, we still have insufficient level of reviews. So, we think this approach can improve that > I have no problem in the MEXT WG trying this approach to see if you get more > independent reviews vs a document author/editor signing up 5 of his buddies > to submit reviews :) > right but the reviews need to be throrough to improve the quality of the document I mean, if you get a buddy to do a thorough review, it is much better that if you get no one to do a thorough review, don't you think? In other words, the goal of a thorough review is not to destroy the document but to make it better. So a buddy can help you with that and that is good for the document quality. Besides, people that dont like the document will comment anyway, whether the author like it or not > Is it the number of reviews that matter or the quality of reviews? > > both in what i mean is that we need a given number of good reviews as stated in the original mail, we are asking for 5 thorough reviews i.e. 5 good reviews of the documents. makes sense? regards, marcelo > Cheers, > -Raj > > > On 4/17/09 8:33 AM, "Marcelo Bagnulo" wrote: > > >> Hi, >> >> There is one issue that we (the chairs) have been concerned about lately >> is the lack of energy in some documents. This lack of energy results in >> lack of thorough reviews of the documents and decrease the quality of >> the output of the WG. >> >> In order to address this concern, we propose the following ground rules >> to progress documents in the MEXT WG. >> >> In order for a document to be adopted as a WG document, the document >> MUST have 5 thorough reviews. >> >> Similarly, in order for the document to be sent to the IESG, the >> document MUST have 5 thorough reviews. >> >> So, the proposed procedure is as follows. >> >> The Chairs will issue a call for adoption/WGLC for a given document. The >> call will include a deadline (normally 2 or 3 weeks, as usual). The >> decision of the adoption will be taken when the deadline is over AND 5 >> thorough reviews have been received. This means that if the deadline has >> passed and we haven't received the number of reviews, the decision will >> wait until we receive the reviews. >> >> It should be noted that the reviews must be serious, in depth reviews. >> Light reviews will not count as one of the required reviews. There are >> not so clear definition about what a serious review is but i guess we >> all recognize one when we see it. >> >> We propose that we adopt this procedure from now on. >> >> Regards, marcelo >> (on behalf of the chairs) >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > > From wesley.m.eddy@nasa.gov Sat Apr 18 17:57:33 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09953A6C02 for ; Sat, 18 Apr 2009 17:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 ql30TqNceboc for ; Sat, 18 Apr 2009 17:57:32 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id BB6653A67AD for ; Sat, 18 Apr 2009 17:57:32 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 68684A800A; Sat, 18 Apr 2009 19:58:46 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n3J0wlw0032003; Sat, 18 Apr 2009 19:58:47 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Sat, 18 Apr 2009 19:58:47 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: marcelo bagnulo braun , mext , Julien Laganier , Jari Arkko Date: Sat, 18 Apr 2009 19:58:45 -0500 Thread-Topic: [MEXT] New ground rules for adopting WG documents and to forward documents to IESG Thread-Index: Acm/YR1teEuQVlbKRnqthNO/Oh5S4wBJzuDB Message-ID: References: <49E8851B.50407@it.uc3m.es> In-Reply-To: <49E8851B.50407@it.uc3m.es> 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 Subject: Re: [MEXT] New ground rules for adopting WG documents and to forward documents to IESG X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 00:57:33 -0000 This issue is common in many working groups; as a co-chair of other groups,= I've been faced with it myself. I think this is a good approach that the MEXT chairs have outlined. At lea= st it sets a clear bar and criteria for moving documents forward and eases = the burden somewhat of determining when a document is ready to move on. Wh= ile the number 5 is somewhat arbitrary and judging thoroughness of a review= can be subjective, I don't think these are really worth quibbling about. Thank you to the MEXT chairs for being proactive about this issue! I fully= support adopting these rules. ________________________________________ From: mext-bounces@ietf.org [mext-bounces@ietf.org] On Behalf Of marcelo ba= gnulo braun [marcelo@it.uc3m.es] Sent: Friday, April 17, 2009 9:33 AM To: mext; Julien Laganier; Jari Arkko Subject: [MEXT] New ground rules for adopting WG documents and to forward d= ocuments to IESG Hi, There is one issue that we (the chairs) have been concerned about lately is the lack of energy in some documents. This lack of energy results in lack of thorough reviews of the documents and decrease the quality of the output of the WG. In order to address this concern, we propose the following ground rules to progress documents in the MEXT WG. In order for a document to be adopted as a WG document, the document MUST have 5 thorough reviews. Similarly, in order for the document to be sent to the IESG, the document MUST have 5 thorough reviews. So, the proposed procedure is as follows. The Chairs will issue a call for adoption/WGLC for a given document. The call will include a deadline (normally 2 or 3 weeks, as usual). The decision of the adoption will be taken when the deadline is over AND 5 thorough reviews have been received. This means that if the deadline has passed and we haven't received the number of reviews, the decision will wait until we receive the reviews. It should be noted that the reviews must be serious, in depth reviews. Light reviews will not count as one of the required reviews. There are not so clear definition about what a serious review is but i guess we all recognize one when we see it. We propose that we adopt this procedure from now on. Regards, marcelo (on behalf of the chairs) _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext= From root@core3.amsl.com Mon Apr 20 08:30:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BB2B33A6DE9; Mon, 20 Apr 2009 08: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: <20090420153001.BB2B33A6DE9@core3.amsl.com> Date: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Multiple Care-of Addresses Registration Author(s) : R. Wakikawa, et al. Filename : draft-ietf-monami6-multiplecoa-13.txt Pages : 44 Date : 2009-04-20 According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.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-monami6-multiplecoa-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-20082837.I-D@ietf.org> --NextPart-- From ryuji.wakikawa@gmail.com Mon Apr 20 08:35:32 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596E43A6B2B for ; Mon, 20 Apr 2009 08:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 9sY6Fv-JILKm for ; Mon, 20 Apr 2009 08:35:31 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id 1A3763A6C54 for ; Mon, 20 Apr 2009 08:35:31 -0700 (PDT) Received: by qyk42 with SMTP id 42so2488751qyk.29 for ; Mon, 20 Apr 2009 08:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:subject:mime-version:date:cc :x-mailer; bh=cFj9gUZVC51UUrwDIKSlHlejbytMWrd2kKQqWu/QVIs=; b=orcRGO518dqv5+vZehQHX8illAHP6cwVms0MH/v2+V68TFqLEfWBzhPE4gF9ft8hnD 6Dxc2Xp2QbqpKDpG60oniTETjZg7Lawq8VnAVHN5jCsi3adsX5fhZ3zojJJ9BxD9IQNE EtWyQgHnQgS8hNcwupeQ8ONdmOOIgmb4td/lM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:subject :mime-version:date:cc:x-mailer; b=NxilBkiNkwGm1uYV3IvxQM+OZaPdRX8LVAjAzTJomADu5raPD+98OdH9vF3WD2hDEo sh3cPX1aOc4EtMYKr2sLAeieGwO3Cf1RGPkOL49cD04F1CP2xdxGHvq3n+PyaJu41tPI KDAfcPEJyVphybcSFpsVIS95eb2LGb88OiSL8= Received: by 10.224.29.13 with SMTP id o13mr6333980qac.206.1240241802145; Mon, 20 Apr 2009 08:36:42 -0700 (PDT) Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id 6sm6967110ywn.22.2009.04.20.08.36.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Apr 2009 08:36:41 -0700 (PDT) Message-Id: <24B90FDA-7E8C-4F6A-8E59-0E37BFD9F8A6@gmail.com> From: Ryuji Wakikawa To: mext mext Content-Type: text/plain; charset=ISO-2022-JP; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 20 Apr 2009 11:36:38 -0400 X-Mailer: Apple Mail (2.930.3) Cc: Jari Arkko , Julien Laganier Subject: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 15:35:32 -0000 Hi all, #Cc: MEXT chairs and Jari We completed IESG review and submitted a new version of the multiplecoa document (ver13) . The following changes were implemented in ver13 of the MCoAv6 draft: 1) Home Registrations Based on draft v12 there are two way of achieving simultaneous home and foreign link registrations. - One does NOT associate the home link with a BID and it is based on a deregistration at a home link. - The other DOES associate the home link with a BID and it is based on a registration with a BID option including CoA=HoA and the H=1. V13 of the draft has been updated so that simultaneous use of home and foreign links requires a home registration with BID including CoA=HoA and H=1. This simplifies the protocol and unifies all bindings by associating all of them with BIDs. Due to the structure of the document, to implement this change a lot of text, mostly under section 5.6, had to be re-written and/or rearranged so the diff between v12 and v13 may give the impression of major changes. In fact, material was mostly removed, moved, or rephrased, and nothing new was added, since all we did is to remove one of the options. 2) CoA field in BID option. According to draft v12, the CoA may not be included in a BID in some cases. The rules for when the CoA is needed or not are however overly complex. For example the CoA MAY NOT be included when a BID is deregistered but they MUST be included in Bulk Registrations. Draft v12 also allows the CoA associated with a BID to be learned from the source address of the packet or the Alt-Coa, which results in additional rules about how to handle this. Draft v13 reduces the complexity of the protocol by simplifying these rules as follows: - Any BID that is registered for the first time MUST include the CoA associated with it. - Any BID refreshed, deregistered or otherwise manipulated MAY NOT include the CoA This change was easier to implement. A clear statement defining this rules is added at the end of 5.1 and then several references to use of Alt-CoA have been cleaned up. 3) Updated Error Codes The MCOA BID CONFLICT code is removed since it became unnecessary when the $B!F(BO$B!G(B flag was introduced. Instead two new error codes are added - MCOA NON-BID BINDING EXISTS, to indicate that an MN attempted to bootstrap MCoA without $B!F(BO$B!G(B flag set. (Replacement of BID CONFLICT) - MCOA UNKNOWN COA, to indicate that the MN send a BID option w/o a CoA but the receiver has no record of the BID. 4) Updated Security Section 9.5.2 1. clarified that the check on the outer IPv6 header source address is not required 2. Added text that showed how you can figure out the right CoA for the destination address on the outer IP header while using just one IPsec SA. From behcetsarikaya@yahoo.com Mon Apr 20 13:01:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205BE3A6951 for ; Mon, 20 Apr 2009 13:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_QP_LONG_LINE=1.396] 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 5ReZ0ZEtuIbm for ; Mon, 20 Apr 2009 13:01:11 -0700 (PDT) Received: from n57.bullet.mail.sp1.yahoo.com (n57.bullet.mail.sp1.yahoo.com [98.136.44.49]) by core3.amsl.com (Postfix) with SMTP id E56EC3A6FA2 for ; Mon, 20 Apr 2009 13:00:59 -0700 (PDT) Received: from [69.147.84.144] by n57.bullet.mail.sp1.yahoo.com with NNFMP; 20 Apr 2009 20:02:16 -0000 Received: from [68.142.237.90] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 20 Apr 2009 20:02:16 -0000 Received: from [67.195.9.82] by t6.bullet.re3.yahoo.com with NNFMP; 20 Apr 2009 20:02:15 -0000 Received: from [67.195.9.101] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 20 Apr 2009 20:02:15 -0000 Received: from [127.0.0.1] by omp105.mail.gq1.yahoo.com with NNFMP; 20 Apr 2009 20:02:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 290480.83257.bm@omp105.mail.gq1.yahoo.com Received: (qmail 86154 invoked by uid 60001); 20 Apr 2009 20:02:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240257734; bh=u4KqEG7M+zdzbUWLepdWFoAh6FKTnLwvR+ODx+0gftA=; 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=sG1RQLhLLTu9+ybzj2f9WWKxwMzezbjYUPIySUV4qUQg7m6iofrvAPkl4O1Zj5Qw0BR0CpKP6beaWjQiDcYMJa2JRmHNmckMRrFblIumwgsOYIh5/JdoxYd8FHwK9RwSKKMXCCAuy0otAC5J/VALZAWKs42e8Djdudhvy/fsrx0= 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=rJ8O7AaY3bn3Gjdm5oPPtoTpKPIpkY4CaAUmrsAJp7VDWlDHU2tiLRED4zNebbQUTwwQGlrNH49CAoWhLEjJzZfAAg0OW+ip5fb3M1PjXXESbv+3AqOLsInHKO+t9vWeAFrNVft8rtJQW0NKoErh+fFLRGnExTY/UQLrU/E8jbc=; Message-ID: <617661.83572.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: aU5F9o0VM1mTh2GPBg_muF8Km6MlIxCwhPyc3O_rKhfWnv4LKcPQEYdcrpLM246pQ0WgAp53N3D1MgYU3Hl0zxjDFl6d.3Jfg5YQp08ltRdrsT4ghGcdAmTE2u01PFfRWQ5F1j6aCRDF6obI9FyPf5Aw_CEr2W1BT3mUY3tabUSp3WcTGMl8zG2kH5RmkNomgg.MS8WXs_ntX8lhHl8IUFvuTrbTdLQxflbsUftCAkSBErD8fORKZi1DkTMVGMdwVlC3cj.9bmKCSyP5wD0zIjpvMPC6otEqEjyPDbEsdaVHaGSL2oqHDuETcykwrsOE6WLpJF0- Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Mon, 20 Apr 2009 13:02:14 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <24B90FDA-7E8C-4F6A-8E59-0E37BFD9F8A6@gmail.com> Date: Mon, 20 Apr 2009 13:02:14 -0700 (PDT) From: Behcet Sarikaya To: Ryuji Wakikawa , mext mext In-Reply-To: <24B90FDA-7E8C-4F6A-8E59-0E37BFD9F8A6@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-931058371-1240257734=:83572" Cc: Julien Laganier , Jari Arkko Subject: Re: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:01:13 -0000 --0-931058371-1240257734=:83572 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ryuji, the problem I mentioned previously:=0Ahttp://www.ietf.org/mail-archi= ve/web/mext/current/msg02759.html=0A=0Astays the same in this version. The = draft gives the impression that the same prefix, e.g. 2001:db8:: is require= d to support multiple interfaces of MN. This is not stated anywhere in the = draft but is drawn in Figures 1, 2 and 3.=0A=0ARegards,=0A=0ABehcet=0A=0A= =0A=0A________________________________=0AFrom: Ryuji Wakikawa =0ATo: mext mext =0ACc: Jari Arkko ; Julien Laganier =0ASent: M= onday, April 20, 2009 10:36:38 AM=0ASubject: [MEXT] A new version of draft-= ietf-monami6-multiplecoa (13.txt)=0A=0AHi all,=0A#Cc: MEXT chairs and Jari= =0A=0AWe completed IESG review and submitted a new version of the multiplec= oa document (ver13) .=0AThe following changes were implemented in ver13 of = the MCoAv6 draft:=0A=0A1)=C2=A0 =C2=A0 =C2=A0 Home Registrations=0ABased on= draft v12 there are two way of achieving simultaneous home and foreign lin= k registrations.=0A-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One does NOT associa= te the home link with a BID and it is based on a deregistration at a home l= ink.=0A-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The other DOES associate the hom= e link with a BID and it is based on a registration with a BID option inclu= ding CoA=3DHoA and the H=3D1.=0A=0AV13 of the draft has been updated so tha= t simultaneous use of home and foreign links requires a home registration w= ith BID including CoA=3DHoA and H=3D1. This simplifies the protocol and uni= fies all bindings by associating all of them with BIDs.=0A=0ADue to the str= ucture of the document, to implement this change a lot of text, mostly unde= r section 5.6, had to be re-written and/or rearranged so the diff between v= 12 and v13 may give the impression of major changes. In fact, material was = mostly removed, moved, or rephrased, and nothing new was added, since all w= e did is to remove one of the options.=0A=0A2)=C2=A0 =C2=A0 =C2=A0 CoA fiel= d in BID option.=0AAccording to draft v12, the CoA may not be included in a= BID in some cases. The rules for when the CoA is needed or not are however= overly complex. For example the CoA MAY NOT be included when a BID is dere= gistered but they MUST be included in Bulk Registrations. Draft v12 also al= lows the CoA associated with a BID to=C2=A0 be learned from the source addr= ess of the packet or the Alt-Coa, which results in additional rules about h= ow to handle this.=0A=0ADraft v13 reduces the complexity of the protocol by= simplifying these rules as follows:=0A-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Any BID that is registered for the first time MUST include the CoA associat= ed with it.=0A-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Any BID refreshed, deregi= stered or otherwise manipulated MAY NOT include the CoA=0AThis change was e= asier to implement. A clear statement defining this rules is added at the e= nd of 5.1 and then several references to use of Alt-CoA have been cleaned u= p.=0A=0A3)=C2=A0 =C2=A0 =C2=A0 Updated Error Codes=0AThe MCOA BID CONFLICT = code is removed since it became unnecessary when the =E2=80=98O=E2=80=99 fl= ag was introduced. Instead two new error codes are added=0A-=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 MCOA NON-BID BINDING EXISTS, to indicate that an MN at= tempted to bootstrap MCoA without =E2=80=98O=E2=80=99 flag set. (Replacemen= t of BID CONFLICT)=0A-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MCOA UNKNOWN COA, = to indicate that the MN send a BID option w/o a CoA but the receiver has no= record of the BID.=0A=0A4)=C2=A0 =C2=A0 Updated Security Section 9.5.2=0A1= .. clarified that the check on the outer IPv6 header source address is not r= equired=0A2. Added text that showed how you can figure out the right CoA fo= r the destination address on the outer IP header while using just one IPsec= SA.=0A_______________________________________________=0AMEXT mailing list= =0AMEXT@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mext=0A=0A=0A=0A = --0-931058371-1240257734=:83572 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ryuji, the problem I mentioned previously:
=0Ahttp://www.ietf.org/mail-archive/web/mext/current/msg02759.html
<= /DIV>=0A
stays the same in this version. The draft gives the impression= that the same prefix, e.g. 2001:db8:: is required to support multiple inte= rfaces of MN. This is not stated anywhere in the draft but is drawn in Figu= res 1, 2 and 3.
=0A
 
=0A
Regards,
=0A
&nbs= p;
=0A
Behcet
=0A

=0A
=0A
=0AFrom: R= yuji Wakikawa <ryuji.wakikawa@gmail.com>
To: mext mext <mext@ietf.org>
Cc: Jari Arkko <jari.arkko@piuha.net&= gt;; Julien Laganier <julien.laganier.ietf@googlemail.com>
Sent: Monday, April 20, 2009 10:36= :38 AM
Subject: [MEXT] A= new version of draft-ietf-monami6-multiplecoa (13.txt)

Hi al= l,
#Cc: MEXT chairs and Jari

We completed IESG review and submitt= ed a new version of the multiplecoa document (ver13) .
The following cha= nges were implemented in ver13 of the MCoAv6 draft:

1)    =   Home Registrations
Based on draft v12 there are two way of achiev= ing simultaneous home and foreign link registrations.
-    &nb= sp;     One does NOT associate the home link with a BID and it is based on a deregistr= ation at a home link.
-          The other DOES= associate the home link with a BID and it is based on a registration with = a BID option including CoA=3DHoA and the H=3D1.

V13 of the draft has= been updated so that simultaneous use of home and foreign links requires a= home registration with BID including CoA=3DHoA and H=3D1. This simplifies = the protocol and unifies all bindings by associating all of them with BIDs.=

Due to the structure of the document, to implement this change a lo= t of text, mostly under section 5.6, had to be re-written and/or rearranged= so the diff between v12 and v13 may give the impression of major changes. = In fact, material was mostly removed, moved, or rephrased, and nothing new = was added, since all we did is to remove one of the options.

2) = ;     CoA field in BID option.
According to draft v12, the CoA may not be included in a BID in some cases. The rules for when the CoA is = needed or not are however overly complex. For example the CoA MAY NOT be in= cluded when a BID is deregistered but they MUST be included in Bulk Registr= ations. Draft v12 also allows the CoA associated with a BID to  be lea= rned from the source address of the packet or the Alt-Coa, which results in= additional rules about how to handle this.

Draft v13 reduces the co= mplexity of the protocol by simplifying these rules as follows:
-  =         Any BID that is registered for the first time M= UST include the CoA associated with it.
-        &nb= sp; Any BID refreshed, deregistered or otherwise manipulated MAY NOT includ= e the CoA
This change was easier to implement. A clear statement definin= g this rules is added at the end of 5.1 and then several references to use = of Alt-CoA have been cleaned up.

3)      Updated Error Codes
The MCOA BID CONFLICT code is removed since it beca= me unnecessary when the =E2=80=98O=E2=80=99 flag was introduced. Instead tw= o new error codes are added
-          MCOA NON= -BID BINDING EXISTS, to indicate that an MN attempted to bootstrap MCoA wit= hout =E2=80=98O=E2=80=99 flag set. (Replacement of BID CONFLICT)
- =         MCOA UNKNOWN COA, to indicate that the MN send= a BID option w/o a CoA but the receiver has no record of the BID.

4= )    Updated Security Section 9.5.2
1. clarified that the chec= k on the outer IPv6 header source address is not required
2. Added text = that showed how you can figure out the right CoA for the destination addres= s on the outer IP header while using just one IPsec SA.
________________= _______________________________
MEXT mailing list
MEXT@ietf.org
https:= //www.ietf.org/mailman/listinfo/mext

=0A=0A=0A= =0A --0-931058371-1240257734=:83572-- From ryuji.wakikawa@gmail.com Mon Apr 20 13:18:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F101D3A6FED for ; Mon, 20 Apr 2009 13:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_33=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 vqBZFvv7m+ki for ; Mon, 20 Apr 2009 13:18:01 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id D96B83A6F7E for ; Mon, 20 Apr 2009 13:18:00 -0700 (PDT) Received: by qyk42 with SMTP id 42so2755135qyk.29 for ; Mon, 20 Apr 2009 13:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=EbzluKl4jnoeGgecOEuatVTi6EiULz1YB7Bw7NKp1Yo=; b=MX+mKeRMWvopUT9Q7AHrJlZ9QstOa0eKh9YhLRu6EC+zWX9FJyITYFKGutHuNtO4w0 dZqdCRkYht5KDDOoXVXnXzSKZJK620r+He9D7BfF2EZP5SGeFL5mg1zixiOXO2nEbHgF r4TlyvdvyoSLXndpWrqUi5bd6JvV9YfPE/mhE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=C7K8J6LG2jqmTV8T+z7pjNJciz7SkjjDMCrKAYwgO9X41b9LEPDJEiQOYRuq9wEBcw MzOaTKuEZQow0YD84mk9Xn2K5/7hVn3U3lYZX2TfkrPMjH7e0nc5Q74DtOASmgL68LDh L6df5wM3kDduCpWcXunWXo+MJlmS07Gunc13Q= Received: by 10.224.28.199 with SMTP id n7mr6848071qac.90.1240258756233; Mon, 20 Apr 2009 13:19:16 -0700 (PDT) Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id 6sm7659628ywp.11.2009.04.20.13.19.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Apr 2009 13:19:15 -0700 (PDT) From: Ryuji Wakikawa To: Behcet Sarikaya In-Reply-To: <617661.83572.qm@web111405.mail.gq1.yahoo.com> References: <24B90FDA-7E8C-4F6A-8E59-0E37BFD9F8A6@gmail.com> <617661.83572.qm@web111405.mail.gq1.yahoo.com> Message-Id: <8DA860D8-8418-4EEE-80D4-C38E462ADBAF@gmail.com> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 20 Apr 2009 16:19:11 -0400 X-Mailer: Apple Mail (2.930.3) Cc: Julien Laganier , Jari Arkko , mext mext Subject: Re: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:18:02 -0000 Hi Behcet, Again, why do you say prefix? A home address is shared among multiple interfaces. George have already answered to you. This MCoA is an extension to Mobile IP. Proxy Mobile IPv6 is not supported in this document. thanks ryuji On 2009/04/20, at 16:02, Behcet Sarikaya wrote: > Ryuji, the problem I mentioned previously: > http://www.ietf.org/mail-archive/web/mext/current/msg02759.html > stays the same in this version. The draft gives the impression that > the same prefix, e.g. 2001:db8:: is required to support multiple > interfaces of MN. This is not stated anywhere in the draft but is > drawn in Figures 1, 2 and 3. > > Regards, > > Behcet > > From: Ryuji Wakikawa > To: mext mext > Cc: Jari Arkko ; Julien Laganier > > Sent: Monday, April 20, 2009 10:36:38 AM > Subject: [MEXT] A new version of draft-ietf-monami6-multiplecoa > (13.txt) > > Hi all, > #Cc: MEXT chairs and Jari > > We completed IESG review and submitted a new version of the > multiplecoa document (ver13) . > The following changes were implemented in ver13 of the MCoAv6 draft: > > 1) Home Registrations > Based on draft v12 there are two way of achieving simultaneous home > and foreign link registrations. > - One does NOT associate the home link with a BID and it is > based on a deregistration at a home link. > - The other DOES associate the home link with a BID and it > is based on a registration with a BID option including CoA=HoA and > the H=1. > > V13 of the draft has been updated so that simultaneous use of home > and foreign links requires a home registration with BID including > CoA=HoA and H=1. This simplifies the protocol and unifies all > bindings by associating all of them with BIDs. > > Due to the structure of the document, to implement this change a lot > of text, mostly under section 5.6, had to be re-written and/or > rearranged so the diff between v12 and v13 may give the impression > of major changes. In fact, material was mostly removed, moved, or > rephrased, and nothing new was added, since all we did is to remove > one of the options. > > 2) CoA field in BID option. > According to draft v12, the CoA may not be included in a BID in some > cases. The rules for when the CoA is needed or not are however > overly complex. For example the CoA MAY NOT be included when a BID > is deregistered but they MUST be included in Bulk Registrations. > Draft v12 also allows the CoA associated with a BID to be learned > from the source address of the packet or the Alt-Coa, which results > in additional rules about how to handle this. > > Draft v13 reduces the complexity of the protocol by simplifying > these rules as follows: > - Any BID that is registered for the first time MUST > include the CoA associated with it. > - Any BID refreshed, deregistered or otherwise manipulated > MAY NOT include the CoA > This change was easier to implement. A clear statement defining this > rules is added at the end of 5.1 and then several references to use > of Alt-CoA have been cleaned up. > > 3) Updated Error Codes > The MCOA BID CONFLICT code is removed since it became unnecessary > when the $B!F(BO$B!G(B flag was introduced. Instead two new error > codes are added > - MCOA NON-BID BINDING EXISTS, to indicate that an MN > attempted to bootstrap MCoA without $B!F(BO$B!G(B flag set. > (Replacement of BID CONFLICT) > - MCOA UNKNOWN COA, to indicate that the MN send a BID > option w/o a CoA but the receiver has no record of the BID. > > 4) Updated Security Section 9.5.2 > 1. clarified that the check on the outer IPv6 header source address > is not required > 2. Added text that showed how you can figure out the right CoA for > the destination address on the outer IP header while using just one > IPsec SA. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From behcetsarikaya@yahoo.com Mon Apr 20 13:37:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423533A68AC for ; Mon, 20 Apr 2009 13:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.237 X-Spam-Level: X-Spam-Status: No, score=-1.237 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_QP_LONG_LINE=1.396] 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 RahIAtw9MdSq for ; Mon, 20 Apr 2009 13:37:11 -0700 (PDT) Received: from n75.bullet.mail.sp1.yahoo.com (n75.bullet.mail.sp1.yahoo.com [98.136.44.51]) by core3.amsl.com (Postfix) with SMTP id 4C2683A6E90 for ; Mon, 20 Apr 2009 13:36:59 -0700 (PDT) Received: from [216.252.122.216] by n75.bullet.mail.sp1.yahoo.com with NNFMP; 20 Apr 2009 20:38:15 -0000 Received: from [67.195.9.83] by t1.bullet.sp1.yahoo.com with NNFMP; 20 Apr 2009 20:38:15 -0000 Received: from [67.195.9.106] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 20 Apr 2009 20:38:15 -0000 Received: from [127.0.0.1] by omp110.mail.gq1.yahoo.com with NNFMP; 20 Apr 2009 20:36:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 846550.90039.bm@omp110.mail.gq1.yahoo.com Received: (qmail 12228 invoked by uid 60001); 20 Apr 2009 20:38:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240259894; bh=ekx0LuWFzvaWCEv+y8wRnt068StfDyYO+C8xJyMi6Hs=; 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=xer0vGGM+vCWsXFji8SNdEAHkSUCtL/9mTw/+JUUGx/4Js4DSRmoeEL7qh8tZbuf7zHUSqwJg8Ch3MpC6itgzU0/Z2HLTvbhMgCE+mYsXzLeNAw6+IzpxYE7ku3kzhtXS/Ml4Onutrc9MHZGuRZUtV9lerJvOvGNEZun53nmeQ0= 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=pUoZ6iVeqbFzVvRArxdTdm5DQ3tG7dkPSzyE5UkfBi8lvrWM7hfavF08nID8HhDwJWWSZu7r9zf7xcIXxlH+Uz8n5nwTKMgjJirDZlRveVv5n/knfCx6vQcyzBZD3DacSf8ZrIstGqMcOfYxCjNC+UZOrB8wqZoboneQMpUUonY=; Message-ID: <970819.11318.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: 8WdnUk4VM1l_NvBs2VwlHxyqNT6tbGM7oE1U5Gg9fmDzVmiKjrENHj1xhIFWXPynEmc9igl2HjjzQwPTzUeJY__EbYIY3EUAb8In9iuwcP56xXPFfwZUkOE6Dh2B9Wgy5XaHl_5XZFOYcbLhoKXUMMzG24ls6pFKHGIHl.O3RSch8unA3OvgAqASeoMIimURJICMrfzC.k4FwZh0LtMoJONsfD54jDq1FNnS1RI0IQDVfFbuWdkgwM6yhw9sL3SoWBVAzoM64JC3woQFHwHVssYdPMqMv5f9_B8W2tKhXlZVIEp0c9RPANIipeh48Pn6W13sGcM- Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Mon, 20 Apr 2009 13:38:14 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <24B90FDA-7E8C-4F6A-8E59-0E37BFD9F8A6@gmail.com> <617661.83572.qm@web111405.mail.gq1.yahoo.com> <8DA860D8-8418-4EEE-80D4-C38E462ADBAF@gmail.com> Date: Mon, 20 Apr 2009 13:38:14 -0700 (PDT) From: Behcet Sarikaya To: Ryuji Wakikawa In-Reply-To: <8DA860D8-8418-4EEE-80D4-C38E462ADBAF@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1808884809-1240259894=:11318" Cc: Julien Laganier , Jari Arkko , mext mext Subject: Re: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:37:12 -0000 --0-1808884809-1240259894=:11318 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=C2=A0=0A=0A=0A________________________________=0A=0AFrom: Ryuji Wakikaw= a =0ATo: Behcet Sarikaya =0ACc= : mext mext ; Jari Arkko ; Julien Laga= nier =0ASent: Monday, April 20, 2009 3= :19:11 PM=0ASubject: Re: [MEXT] A new version of draft-ietf-monami6-multipl= ecoa (13.txt)=0A=0A=0A[behcet] Is this the mail you are talking about=C2=A0= http://www.ietf.org/mail-archive/web/mext/current/msg02758.html?=0AI don't = think he answered it.=0A=0AThis MCoA is an extension to Mobile IP. Proxy Mo= bile IPv6 is not supported in this document.=0A=0A[behcet] You mean point-t= o-point links only in PMIPv6? I don't think so, RFC 4903 is not just for PM= IPv6.=0A=0Athanks=0Aryuji=0A=0AOn 2009/04/20, at 16:02, Behcet Sarikaya wro= te:=0A=0A> Ryuji, the problem I mentioned previously:=0A> http://www.ietf.o= rg/mail-archive/web/mext/current/msg02759.html=0A> stays the same in this v= ersion. The draft gives the impression that the same prefix, e.g. 2001:db8:= : is required to support multiple interfaces of MN. This is not stated anyw= here in the draft but is drawn in Figures 1, 2 and 3.=0A> =0A> Regards,=0A>= =0A> Behcet=0A> =0A> From: Ryuji Wakikawa =0A> T= o: mext mext =0A> Cc: Jari Arkko ; Jul= ien Laganier =0A> Sent: Monday, April = 20, 2009 10:36:38 AM=0A> Subject: [MEXT] A new version of draft-ietf-monami= 6-multiplecoa (13.txt)=0A> =0A> Hi all,=0A> #Cc: MEXT chairs and Jari=0A> = =0A> We completed IESG review and submitted a new version of the multipleco= a document (ver13) .=0A> The following changes were implemented in ver13 of= the MCoAv6 draft:=0A> =0A> 1)=C2=A0 =C2=A0 =C2=A0 Home Registrations=0A> B= ased on draft v12 there are two way of achieving simultaneous home and fore= ign link registrations.=0A> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One does NO= T associate the home link with a BID and it is based on a deregistration at= a home link.=0A> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The other DOES associ= ate the home link with a BID and it is based on a registration with a BID o= ption including CoA=3DHoA and the H=3D1.=0A> =0A> V13 of the draft has been= updated so that simultaneous use of home and foreign links requires a home= registration with BID including CoA=3DHoA and H=3D1. This simplifies the p= rotocol and unifies all bindings by associating all of them with BIDs.=0A> = =0A> Due to the structure of the document, to implement this change a lot o= f text, mostly under section 5.6, had to be re-written and/or rearranged so= the diff between v12 and v13 may give the impression of major changes. In = fact, material was mostly removed, moved, or rephrased, and nothing new was= added, since all we did is to remove one of the options.=0A> =0A> 2)=C2=A0= =C2=A0 =C2=A0 CoA field in BID option.=0A> According to draft v12, the CoA= may not be included in a BID in some cases. The rules for when the CoA is = needed or not are however overly complex. For example the CoA MAY NOT be in= cluded when a BID is deregistered but they MUST be included in Bulk Registr= ations. Draft v12 also allows the CoA associated with a BID to=C2=A0 be lea= rned from the source address of the packet or the Alt-Coa, which results in= additional rules about how to handle this.=0A> =0A> Draft v13 reduces the = complexity of the protocol by simplifying these rules as follows:=0A> -=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Any BID that is registered for the first ti= me MUST include the CoA associated with it.=0A> -=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Any BID refreshed, deregistered or otherwise manipulated MAY NOT= include the CoA=0A> This change was easier to implement. A clear statement= defining this rules is added at the end of 5.1 and then several references= to use of Alt-CoA have been cleaned up.=0A> =0A> 3)=C2=A0 =C2=A0 =C2=A0 Up= dated Error Codes=0A> The MCOA BID CONFLICT code is removed since it became= unnecessary when the =E2=80=98O=E2=80=99 flag was introduced. Instead two = new error codes are added=0A> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MCOA NON-= BID BINDING EXISTS, to indicate that an MN attempted to bootstrap MCoA with= out =E2=80=98O=E2=80=99 flag set. (Replacement of BID CONFLICT)=0A> -=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 MCOA UNKNOWN COA, to indicate that the MN send= a BID option w/o a CoA but the receiver has no record of the BID.=0A> =0A>= 4)=C2=A0 =C2=A0 Updated Security Section 9.5.2=0A> 1. clarified that the c= heck on the outer IPv6 header source address is not required=0A> 2. Added t= ext that showed how you can figure out the right CoA for the destination ad= dress on the outer IP header while using just one IPsec SA.=0A> ___________= ____________________________________=0A> MEXT mailing list=0A> MEXT@ietf.or= g=0A> https://www.ietf.org/mailman/listinfo/mext=0A> =0A> =0A=0A=0AHi Behce= t,=0A=0AAgain, why do you say prefix? A home address is shared among multip= le interfaces.=0AGeorge have already answered to you.=0A=0A=0A --0-1808884809-1240259894=:11318 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

 
=0A

=0A
=0A
=0A
=0A
F= rom: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
To: Behcet Sarikaya <sarikaya@ie= ee.org>
Cc: mext mext= <mext@ietf.org>; Jari Arkko <jari.arkko@piuha.net>; Julien Lag= anier <julien.laganier.ietf@googlemail.com>
Sent: Monday, April 20, 2009 3:19:11 PM
Subject: Re: [MEXT] A new version= of draft-ietf-monami6-multiplecoa (13.txt)

Hi Behcet,
Again, why do you say prefix? A home address is shared among multiple inte= rfaces.
George have already answered to you.
=0A
 
=0A
[behcet] Is this the mail you are talking about&nbs= p;http://www.ietf.org/mail-archive/web/mext/current/msg02= 758.html?
=0A
I don't think he answered it.
=0A

This MCoA is an extension to Mobile = IP. Proxy Mobile IPv6 is not supported in this document.
=0A
[behcet] You mean point-to-point links only in PMIPv= 6? I don't think so, RFC 4903 is not just for PMIPv6.
= =0A
ryuji.wakikawa@gmail.com>
> To: mext mext = <mext@= ietf.org>
> Cc: Jari Arkko <jari.arkko@piuha.net&g= t;; Julien Laganier <julien.laganier.ietf@googl= email.com>
> Sent: Monday, April 20, 2009 10:36:38 AM
> = Subject: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt)>
> Hi all,
> #Cc: MEXT chairs and Jari
>
> W= e completed IESG review and submitted a new version of the multiplecoa docu= ment (ver13) .
> The following changes were implemented in ver13 of t= he MCoAv6 draft:
>
> 1)      Home Registrations=
> Based on draft v12 there are two way of achieving simultaneous hom= e and foreign link registrations.
> -        &nbs= p; One does NOT associate the home link with a BID and it is based on a der= egistration at a home link.
> -          The= other DOES associate the home link with a BID and it is based on a registration with a BID option including CoA=3DHoA and the H=3D1.
> =
> V13 of the draft has been updated so that simultaneous use of home= and foreign links requires a home registration with BID including CoA=3DHo= A and H=3D1. This simplifies the protocol and unifies all bindings by assoc= iating all of them with BIDs.
>
> Due to the structure of the = document, to implement this change a lot of text, mostly under section 5.6,= had to be re-written and/or rearranged so the diff between v12 and v13 may= give the impression of major changes. In fact, material was mostly removed= , moved, or rephrased, and nothing new was added, since all we did is to re= move one of the options.
>
> 2)      CoA field = in BID option.
> According to draft v12, the CoA may not be included = in a BID in some cases. The rules for when the CoA is needed or not are how= ever overly complex. For example the CoA MAY NOT be included when a BID is deregistered but they MUST be included in Bulk Registrations. Draft v12 al= so allows the CoA associated with a BID to  be learned from the source= address of the packet or the Alt-Coa, which results in additional rules ab= out how to handle this.
>
> Draft v13 reduces the complexity o= f the protocol by simplifying these rules as follows:
> -   = ;       Any BID that is registered for the first time MUST i= nclude the CoA associated with it.
> -        &nb= sp; Any BID refreshed, deregistered or otherwise manipulated MAY NOT includ= e the CoA
> This change was easier to implement. A clear statement de= fining this rules is added at the end of 5.1 and then several references to= use of Alt-CoA have been cleaned up.
>
> 3)    &nbs= p; Updated Error Codes
> The MCOA BID CONFLICT code is removed since = it became unnecessary when the =E2=80=98O=E2=80=99 flag was introduced. Ins= tead two new error codes are added
> -          = MCOA NON-BID BINDING EXISTS, to indicate that an MN attempted to bootstrap = MCoA without =E2=80=98O=E2=80=99 flag set. (Replacement of BID CONFLICT)> -          MCOA UNKNOWN COA, to indicate tha= t the MN send a BID option w/o a CoA but the receiver has no record of the = BID.
>
> 4)    Updated Security Section 9.5.2
>= ; 1. clarified that the check on the outer IPv6 header source address is no= t required
> 2. Added text that showed how you can figure out the rig= ht CoA for the destination address on the outer IP header while using just = one IPsec SA.
> _______________________________________________
&g= t; MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
> >


=0A=0A --0-1808884809-1240259894=:11318-- From tsirtsis@googlemail.com Mon Apr 20 13:53:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7DFD3A692C for ; Mon, 20 Apr 2009 13:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=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 ISIGX69sUBmY for ; Mon, 20 Apr 2009 13:53:09 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id 7775D3A67B6 for ; Mon, 20 Apr 2009 13:53:09 -0700 (PDT) Received: by gxk10 with SMTP id 10so982472gxk.13 for ; Mon, 20 Apr 2009 13:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=KNbqw9XOL2RyJCcuzVpdwBhXrHTTZ21Au1GfKSyOR5o=; b=e5pNhcAjPufHv7jyCWLGOVzSE6sqVnZmOIm3CHY1ZcDTqi6uE4gmSUsXWfaayLNXn2 d+93XkaLCtvT60OTnBmwK42UD7leAI25ZRpqFT7bKWmJjSKZErnTQ0yLW8RgWQaCQJum ESYiKSyKjfp1spz59hbxP6uT4NdkHpGR5oZbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BQ3GJKx5eqU2wdMycHuHTEzcbu7ESHKOEnShC0FVZb7Pkmix2H82iXhRKST5gg14mj WiQ6CJf5vUm80+z19WpLekiy6mFVEPIRW3OsYQxn0ju+d+831tt5GUmLNobseQnzm4vG O1In+vGnGNoXFaIDnZ3ST4p7i+YsrSC4j67JY= MIME-Version: 1.0 Received: by 10.90.120.17 with SMTP id s17mr1248207agc.63.1240260865205; Mon, 20 Apr 2009 13:54:25 -0700 (PDT) In-Reply-To: <970819.11318.qm@web111405.mail.gq1.yahoo.com> References: <24B90FDA-7E8C-4F6A-8E59-0E37BFD9F8A6@gmail.com> <617661.83572.qm@web111405.mail.gq1.yahoo.com> <8DA860D8-8418-4EEE-80D4-C38E462ADBAF@gmail.com> <970819.11318.qm@web111405.mail.gq1.yahoo.com> Date: Mon, 20 Apr 2009 21:54:25 +0100 Message-ID: From: George Tsirtsis To: Behcet Sarikaya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , Jari Arkko , mext mext Subject: Re: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 20:53:10 -0000 Bechet, The prefix you are talking about is the home address. The home address in MIPv6 sits on a single MIPv6 Interface in the MN which from the perspective of the host IP stack is unique, fixed, does not move, does not change...nothing. All the other (physical) interfaces that come and go have addresses that become CoAs in the context of MIPv6. I do not think there is anything strange here. George On Mon, Apr 20, 2009 at 9:38 PM, Behcet Sarikaya wrote: > > > ________________________________ > From: Ryuji Wakikawa > To: Behcet Sarikaya > Cc: mext mext ; Jari Arkko ; Julien > Laganier > Sent: Monday, April 20, 2009 3:19:11 PM > Subject: Re: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.t= xt) > > Hi Behcet, > > Again, why do you say prefix? A home address is shared among multiple > interfaces. > George have already answered to you. > > [behcet] Is this the mail you are talking > about=C2=A0http://www.ietf.org/mail-archive/web/mext/current/msg02758.htm= l? > I don't think he answered it. > This MCoA is an extension to Mobile IP. Proxy Mobile IPv6 is not supporte= d > in this document. > [behcet] You mean point-to-point links only in PMIPv6? I don't think so, = RFC > 4903 is not just for PMIPv6. > thanks > ryuji > > On 2009/04/20, at 16:02, Behcet Sarikaya wrote: > >> Ryuji, the problem I mentioned previously: >> http://www..ietf.org/mail-archive/web/mext/current/msg02759.html >> stays the same in this version. The draft gives the impression that the >> same prefix, e.g.. 2001:db8:: is required to support multiple interfaces= of >> MN. This is not stated anywhere in the draft but is drawn in Figures 1, = 2 >> and 3. >> >> Regards, >> >> Behcet >> >> From: Ryuji Wakikawa >> To: mext mext >> Cc: Jari Arkko ; Julien Laganier >> >> Sent: Monday, April 20, 2009 10:36:38 AM >> Subject: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt) >> >> Hi all, >> #Cc: MEXT chairs and Jari >> >> We completed IESG review and submitted a new version of the multiplecoa >> document (ver13) . >> The following changes were implemented in ver13 of the MCoAv6 draft: >> >> 1)=C2=A0 =C2=A0 =C2=A0 Home Registrations >> Based on draft v12 there are two way of achieving simultaneous home and >> foreign link registrations. >> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One does NOT associate the home link= with a BID and it is based >> on a deregistration at a home link. >> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The other DOES associate the home li= nk with a BID and it is >> based on a registration with a BID option including CoA=3DHoA and the H= =3D1. >> >> V13 of the draft has been updated so that simultaneous use of home and >> foreign links requires a home registration with BID including CoA=3DHoA = and >> H=3D1. This simplifies the protocol and unifies all bindings by associat= ing >> all of them with BIDs. >> >> Due to the structure of the document, to implement this change a lot of >> text, mostly under section 5.6, had to be re-written and/or rearranged s= o >> the diff between v12 and v13 may give the impression of major changes. I= n >> fact, material was mostly removed, moved, or rephrased, and nothing new = was >> added, since all we did is to remove one of the options. >> >> 2)=C2=A0 =C2=A0 =C2=A0 CoA field in BID option. >> According to draft v12, the CoA may not be included in a BID in some >> cases. The rules for when the CoA is needed or not are however overly >> complex. For example the CoA MAY NOT be included when a BID is deregiste= red >> but they MUST be included in Bulk Registrations. Draft v12 also allows t= he >> CoA associated with a BID to=C2=A0 be learned from the source address of= the >> packet or the Alt-Coa, which results in additional rules about how to ha= ndle >> this. >> >> Draft v13 reduces the complexity of the protocol by simplifying these >> rules as follows: >> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Any BID that is registered for the f= irst time MUST include the >> CoA associated with it. >> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Any BID refreshed, deregistered or o= therwise manipulated MAY >> NOT include the CoA >> This change was easier to implement. A clear statement defining this rul= es >> is added at the end of 5.1 and then several references to use of Alt-CoA >> have been cleaned up. >> >> 3)=C2=A0 =C2=A0 =C2=A0 Updated Error Codes >> The MCOA BID CONFLICT code is removed since it became unnecessary when t= he >> =E2=80=98O=E2=80=99 flag was introduced. Instead two new error codes are= added >> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MCOA NON-BID BINDING EXISTS, to indi= cate that an MN attempted >> to bootstrap MCoA without =E2=80=98O=E2=80=99 flag set. (Replacement of = BID CONFLICT) >> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MCOA UNKNOWN COA, to indicate that t= he MN send a BID option w/o >> a CoA but the receiver has no record of the BID. >> >> 4)=C2=A0 =C2=A0 Updated Security Section 9.5.2 >> 1. clarified that the check on the outer IPv6 header source address is n= ot >> required >> 2. Added text that showed how you can figure out the right CoA for the >> destination address on the outer IP header while using just one IPsec SA= . >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From behcetsarikaya@yahoo.com Mon Apr 20 14:06:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155E93A6D9A for ; Mon, 20 Apr 2009 14:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_QP_LONG_LINE=1.396] 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 qqcOxaVJ2LX9 for ; Mon, 20 Apr 2009 14:06:12 -0700 (PDT) Received: from n76.bullet.mail.sp1.yahoo.com (n76.bullet.mail.sp1.yahoo.com [98.136.44.48]) by core3.amsl.com (Postfix) with SMTP id AA6E43A6D98 for ; Mon, 20 Apr 2009 14:05:44 -0700 (PDT) Received: from [69.147.84.145] by n76.bullet.mail.sp1.yahoo.com with NNFMP; 20 Apr 2009 21:07:00 -0000 Received: from [67.195.9.83] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 20 Apr 2009 21:07:00 -0000 Received: from [67.195.9.97] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 20 Apr 2009 21:07:00 -0000 Received: from [127.0.0.1] by omp101.mail.gq1.yahoo.com with NNFMP; 20 Apr 2009 21:06:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 140269.42642.bm@omp101.mail.gq1.yahoo.com Received: (qmail 1721 invoked by uid 60001); 20 Apr 2009 21:07:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240261620; bh=keWVh9eysZd8vMcGgYMiFZI1OuuSz+5S0yDlV6k2kjA=; 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=BTM1VTdvjblctELT07NzZz1cdpjoai5FDoLM9D1VG4Zn/fAF+CBioauNxUdWvqV1PNMjOR2gx3YDEPiCQzhOdzAelWcQu7P2ALFKm+GytFt0NAnFg4GPQxr5CSS7ydVz/kYZZCdxSMjJvUdFJ9aIxujdmrc3B/6UwhIAikkTEMA= 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=hHDoHZWTuqiI48tSvW4b6IlYYHbDmKUevn3LJFgZ9oVTIZVN0MSfz5/3DmkrBRw8qB4dxl4BRgye/W0anovklLgE1cZ3Tt07jqKM1nL6gMY5lFVFlraFKkHLInnKWDMXVs5t+LLj0vQZN9fmuBWFV+6OGVgyZy8taSV2HHT4kj8=; Message-ID: <218141.98505.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: 6fERe1AVM1mWPI7ckU.Op47RfPNkoJBM2b9S5H4yG4PO.ciYeM6wBiz_NTF1VbLJPFlKxR6yfhDNe5lDYGPgbfCl4kqV5TJ2kpm9AWu6VZPzC2qYVakC5kxaKC7EZm0DNdLOGY5DCe5J2ifiPwehPGp7yRfqaMTr32Iu7v5L_KqmekYZUDEOopzk9H3kXgix8WayUKuDCc9VcEyWlALiYN28RgY9oD_di_TO.zNJu9vxstJqJTUqaTNK446ktBr.nC4gUH3O8YGxD.vRtDrwGev9PXz1ZI053xFZD9zgeOqjVlqjSmuw.3tGNx3f0x8Sc6q4dgM- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Mon, 20 Apr 2009 14:07:00 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <24B90FDA-7E8C-4F6A-8E59-0E37BFD9F8A6@gmail.com> <617661.83572.qm@web111405.mail.gq1.yahoo.com> <8DA860D8-8418-4EEE-80D4-C38E462ADBAF@gmail.com> <970819.11318.qm@web111405.mail.gq1.yahoo.com> Date: Mon, 20 Apr 2009 14:07:00 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2076581365-1240261620=:98505" Cc: Julien Laganier , Jari Arkko , mext mext Subject: Re: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:06:14 -0000 --0-2076581365-1240261620=:98505 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable George,=0A=C2=A0 So you are saying that my observation (single prefix is us= ed/must be used on all interfaces of MN) is correct.=0A=C2=A0 I think that = this would create multi-link subnets at the home link and RFC 4903 says we = should avoid them by simply assigning different prefixes to each.=0A=0ARega= rds,=0A=0ABehcet=0A=0A=0A=0A=0A________________________________=0AFrom: Geo= rge Tsirtsis =0ATo: Behcet Sarikaya =0ACc: Ryuji Wakikawa ; Julien Laganier ; Jari Arkko ; mext = mext =0ASent: Monday, April 20, 2009 3:54:25 PM=0ASubject: R= e: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt)=0A=0ABec= het,=0A=0AThe prefix you are talking about is the home address. The home ad= dress=0Ain MIPv6 sits on a single MIPv6 Interface in the MN which from the= =0Aperspective of the host IP stack is unique, fixed, does not move, does= =0Anot change...nothing.=0A=0AAll the other (physical) interfaces that come= and go have addresses=0Athat become CoAs in the context of MIPv6.=0A=0AI d= o not think there is anything strange here.=0A=0AGeorge=0A=0AOn Mon, Apr 20= , 2009 at 9:38 PM, Behcet Sarikaya=0A wrote:=0A>= =0A>=0A> ________________________________=0A> From: Ryuji Wakikawa =0A> To: Behcet Sarikaya =0A> Cc: mext= mext ; Jari Arkko ; Julien=0A> Lagani= er =0A> Sent: Monday, April 20, 2009 3= :19:11 PM=0A> Subject: Re: [MEXT] A new version of draft-ietf-monami6-multi= plecoa (13.txt)=0A>=0A> Hi Behcet,=0A>=0A> Again, why do you say prefix? A = home address is shared among multiple=0A> interfaces.=0A> George have alrea= dy answered to you.=0A>=0A> [behcet] Is this the mail you are talking=0A> a= bout=C2=A0http://www.ietf.org/mail-archive/web/mext/current/msg02758.html?= =0A> I don't think he answered it.=0A> This MCoA is an extension to Mobile = IP. Proxy Mobile IPv6 is not supported=0A> in this document.=0A> [behcet] Y= ou mean point-to-point links only in PMIPv6? I don't think so, RFC=0A> 4903= is not just for PMIPv6.=0A> thanks=0A> ryuji=0A>=0A> On 2009/04/20, at 16:= 02, Behcet Sarikaya wrote:=0A>=0A>> Ryuji, the problem I mentioned previous= ly:=0A>> http://www..ietf.org/mail-archive/web/mext/current/msg02759.html= =0A>> stays the same in this version. The draft gives the impression that t= he=0A>> same prefix, e.g.. 2001:db8:: is required to support multiple inter= faces of=0A>> MN. This is not stated anywhere in the draft but is drawn in = Figures 1, 2=0A>> and 3.=0A>>=0A>> Regards,=0A>>=0A>> Behcet=0A>>=0A>> From= : Ryuji Wakikawa =0A>> To: mext mext =0A>> Cc: Jari Arkko ; Julien Laganier=0A>> =0A>> Sent: Monday, April 20, 2009 10:36:38 = AM=0A>> Subject: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13= ..txt)=0A>>=0A>> Hi all,=0A>> #Cc: MEXT chairs and Jari=0A>>=0A>> We complet= ed IESG review and submitted a new version of the multiplecoa=0A>> document= (ver13) .=0A>> The following changes were implemented in ver13 of the MCoA= v6 draft:=0A>>=0A>> 1)=C2=A0 =C2=A0 =C2=A0 Home Registrations=0A>> Based on= draft v12 there are two way of achieving simultaneous home and=0A>> foreig= n link registrations.=0A>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One does NOT= associate the home link with a BID and it is based=0A>> on a deregistratio= n at a home link.=0A>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The other DOES a= ssociate the home link with a BID and it is=0A>> based on a registration wi= th a BID option including CoA=3DHoA and the H=3D1.=0A>>=0A>> V13 of the dra= ft has been updated so that simultaneous use of home and=0A>> foreign links= requires a home registration with BID including CoA=3DHoA and=0A>> H=3D1. = This simplifies the protocol and unifies all bindings by associating=0A>> a= ll of them with BIDs.=0A>>=0A>> Due to the structure of the document, to im= plement this change a lot of=0A>> text, mostly under section 5.6, had to be= re-written and/or rearranged so=0A>> the diff between v12 and v13 may give= the impression of major changes. In=0A>> fact, material was mostly removed= , moved, or rephrased, and nothing new was=0A>> added, since all we did is = to remove one of the options.=0A>>=0A>> 2)=C2=A0 =C2=A0 =C2=A0 CoA field in= BID option.=0A>> According to draft v12, the CoA may not be included in a = BID in some=0A>> cases. The rules for when the CoA is needed or not are how= ever overly=0A>> complex. For example the CoA MAY NOT be included when a BI= D is deregistered=0A>> but they MUST be included in Bulk Registrations. Dra= ft v12 also allows the=0A>> CoA associated with a BID to=C2=A0 be learned f= rom the source address of the=0A>> packet or the Alt-Coa, which results in = additional rules about how to handle=0A>> this.=0A>>=0A>> Draft v13 reduces= the complexity of the protocol by simplifying these=0A>> rules as follows:= =0A>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Any BID that is registered for th= e first time MUST include the=0A>> CoA associated with it.=0A>> -=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Any BID refreshed, deregistered or otherwise manip= ulated MAY=0A>> NOT include the CoA=0A>> This change was easier to implemen= t. A clear statement defining this rules=0A>> is added at the end of 5.1 an= d then several references to use of Alt-CoA=0A>> have been cleaned up.=0A>>= =0A>> 3)=C2=A0 =C2=A0 =C2=A0 Updated Error Codes=0A>> The MCOA BID CONFLICT= code is removed since it became unnecessary when the=0A>> =E2=80=98O=E2=80= =99 flag was introduced. Instead two new error codes are added=0A>> -=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 MCOA NON-BID BINDING EXISTS, to indicate that = an MN attempted=0A>> to bootstrap MCoA without =E2=80=98O=E2=80=99 flag set= .. (Replacement of BID CONFLICT)=0A>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MC= OA UNKNOWN COA, to indicate that the MN send a BID option w/o=0A>> a CoA bu= t the receiver has no record of the BID.=0A>>=0A>> 4)=C2=A0 =C2=A0 Updated = Security Section 9.5.2=0A>> 1. clarified that the check on the outer IPv6 h= eader source address is not=0A>> required=0A>> 2. Added text that showed ho= w you can figure out the right CoA for the=0A>> destination address on the = outer IP header while using just one IPsec SA.=0A>> _______________________= ________________________=0A>> MEXT mailing list=0A>> MEXT@ietf.org=0A>> htt= ps://www.ietf.org/mailman/listinfo/mext=0A>>=0A>>=0A>=0A>=0A>=0A> _________= ______________________________________=0A> MEXT mailing list=0A> MEXT@ietf.= org=0A> https://www.ietf.org/mailman/listinfo/mext=0A>=0A>=0A=0A=0A=0A = --0-2076581365-1240261620=:98505 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
George,
=0A
  So you are saying that my = observation (single prefix is used/must be used on all interfaces of MN) is= correct.
=0A
  I think that this would create multi-link sub= nets at the home link and RFC 4903 says we should avoid them by simply assi= gning different prefixes to each.
=0A
 
=0A
Regards,=
=0A
 
=0A
Behcet
=0A

=0A
=0A
=0AFrom: George Tsirtsis <tsirtsis@googlemail.com>
= To: Behcet Sarikaya <sarika= ya@ieee.org>
Cc: Ryuj= i Wakikawa <ryuji.wakikawa@gmail.com>; Julien Laganier <julien.lag= anier.ietf@googlemail.com>; Jari Arkko <jari.arkko@piuha.net>; mex= t mext <mext@ietf.org>
Sent:<= /SPAN> Monday, April 20, 2009 3:54:25 PM
Subject: Re: [MEXT] A new version of draft-ietf-monami= 6-multiplecoa (13.txt)

Bechet,

The prefix you are talk= ing about is the home address. The home address
in MIPv6 sits on a singl= e MIPv6 Interface in the MN which from the
perspective of the host IP st= ack is unique, fixed, does not move, does
not change...nothing.

A= ll the other (physical) interfaces that come and go have addresses
that become CoAs in the context of MIPv6.

= I do not think there is anything strange here.

George

On Mon,= Apr 20, 2009 at 9:38 PM, Behcet Sarikaya
<behcetsarikay= a@yahoo.com> wrote:
>
>
> ________________________= ________
> From: Ryuji Wakikawa <ryuji.wakikawa@gmail= ..com>
> To: Behcet Sarikaya <sarikaya@ieee.org>
&g= t; Cc: mext mext <mext@ietf.org>; Jari Arkko <jari.arkko@piuha.net= >; Julien
> Laganier <julien.laganier.ietf@googlemail.com>= ;
> Sent: Monday, April 20, 2009 3:19:11 PM
> Subject: Re: [MEX= T] A new version of draft-ietf-monami6-multiplecoa (13.txt)
>
>= Hi Behcet,
>
> Again, why do you say prefix? A home address is= shared among multiple
> interfaces.
> George have already answ= ered to you.
>
> [behcet] Is this the mail you are talking
&= gt; about http://www.ietf.org/mail-archive/web/mext/current/msg02758.h= tml?
> I don't think he answered it.
> This MCoA is an extensio= n to Mobile IP. Proxy Mobile IPv6 is not supported
> in this document= ..
> [behcet] You mean point-to-point links only in PMIPv6? I don't th= ink so, RFC
> 4903 is not just for PMIPv6.
> thanks
> ryu= ji
>
> On 2009/04/20, at 16:02, Behcet Sarikaya wrote:
>
>> Ryuji, the problem I mentioned previously:
&= gt;> http://www..ietf.org/mail-archive/web/mext/current/msg02759.html>> stays the same in this version. The draft gives the impression th= at the
>> same prefix, e.g.. 2001:db8:: is required to support mul= tiple interfaces of
>> MN. This is not stated anywhere in the draf= t but is drawn in Figures 1, 2
>> and 3.
>>
>> R= egards,
>>
>> Behcet
>>
>> From: Ryuji = Wakikawa <ryuji.wakikawa@gmail.com>
>> To: = mext mext <mext@ietf.org>
>> Cc: Jari Arkko <jari.arkko@p= iuha.net>; Julien Laganier
>> <julien.laganier.ietf@googlemail.com>= ;
>> Sent: Monday, April 20, 2009 10:36:38 AM
>> Subject:= [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt)
>>= ;
>> Hi all,
>> #Cc: MEXT chairs and Jari
>>
= >> We completed IESG review and submitted a new version of the multip= lecoa
>> document (ver13) .
>> The following changes were= implemented in ver13 of the MCoAv6 draft:
>>
>> 1) =     Home Registrations
>> Based on draft v12 there are = two way of achieving simultaneous home and
>> foreign link registr= ations.
>> -          One does NOT associ= ate the home link with a BID and it is based
>> on a deregistratio= n at a home link.
>> -          The other DOES associate the home link with a BID and it is
>> based = on a registration with a BID option including CoA=3DHoA and the H=3D1.
&= gt;>
>> V13 of the draft has been updated so that simultaneous = use of home and
>> foreign links requires a home registration with= BID including CoA=3DHoA and
>> H=3D1. This simplifies the protoco= l and unifies all bindings by associating
>> all of them with BIDs= ..
>>
>> Due to the structure of the document, to implemen= t this change a lot of
>> text, mostly under section 5.6, had to b= e re-written and/or rearranged so
>> the diff between v12 and v13 = may give the impression of major changes. In
>> fact, material was= mostly removed, moved, or rephrased, and nothing new was
>> added= , since all we did is to remove one of the options.
>>
>>= 2)      CoA field in BID option.
>> According to draft v12, the CoA may not be included in a BID in some
>> cases.= The rules for when the CoA is needed or not are however overly
>>= complex. For example the CoA MAY NOT be included when a BID is deregistere= d
>> but they MUST be included in Bulk Registrations. Draft v12 al= so allows the
>> CoA associated with a BID to  be learned fro= m the source address of the
>> packet or the Alt-Coa, which result= s in additional rules about how to handle
>> this.
>>
= >> Draft v13 reduces the complexity of the protocol by simplifying th= ese
>> rules as follows:
>> -        =   Any BID that is registered for the first time MUST include the
&g= t;> CoA associated with it.
>> -        &nb= sp; Any BID refreshed, deregistered or otherwise manipulated MAY
>>= ; NOT include the CoA
>> This change was easier to implement. A clear statement defining this rules
>> is added at t= he end of 5.1 and then several references to use of Alt-CoA
>> hav= e been cleaned up.
>>
>> 3)      Updated E= rror Codes
>> The MCOA BID CONFLICT code is removed since it becam= e unnecessary when the
>> =E2=80=98O=E2=80=99 flag was introduced.= Instead two new error codes are added
>> -      &n= bsp;   MCOA NON-BID BINDING EXISTS, to indicate that an MN attempted>> to bootstrap MCoA without =E2=80=98O=E2=80=99 flag set. (Replace= ment of BID CONFLICT)
>> -          MCOA = UNKNOWN COA, to indicate that the MN send a BID option w/o
>> a Co= A but the receiver has no record of the BID.
>>
>> 4)&nbs= p;   Updated Security Section 9.5.2
>> 1. clarified that the = check on the outer IPv6 header source address is not
>> required>> 2. Added text that showed how you can figure out the right CoA for the
>= ;> destination address on the outer IP header while using just one IPsec= SA.
>> _______________________________________________
>>= ; MEXT mailing list
>> MEXT@ietf.org
>> https://www.ietf.org/mailm= an/listinfo/mext
>>
>>
>
>
>
>= ; _______________________________________________
> MEXT mailing list=
> = MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>= ;
>

=0A=0A=0A=0A --0-2076581365-1240261620=:98505-- From tsirtsis@googlemail.com Mon Apr 20 14:11:47 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562B33A6E39 for ; Mon, 20 Apr 2009 14:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=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 nppnOFcgYvQj for ; Mon, 20 Apr 2009 14:11:46 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id 075F33A6E4C for ; Mon, 20 Apr 2009 14:10:52 -0700 (PDT) Received: by gxk10 with SMTP id 10so1000933gxk.13 for ; Mon, 20 Apr 2009 14:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=ZVF+ktSYL3Mp5R0kv2rf9BlMNLwUpwmwfpWtavl6dx0=; b=K+dUaO1XareflDJvvqXmP1xOrSQ+LLhQYZ+/XZ0N6wgfkkU1VPKgo5vEOHSvkTs8Dz xqdyoyFyeB0jCFMePxCA/91NfR7lth89DpJgHvr5ixvqifMTD3fWtSnXpEiVORJHd7/7 tnBULe3pyuEWIrHeuNwgZxqA0/prbiUFyG9fk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=K9Y8VfWjBGcvzOedAFsvag2maH2yoF54gYZBEkf05EGtiMSn4tISIYMupttyzXu475 z/NiJ7zxP4PLUU2loVzcob7ehzqfJdfNSwTcPL4yeyzuuGj8IaBR1XFJPo4E1T9C/sVG QlIdBI7XBWdRdR9BYuW3jzXPfCIU22pcQBOsg= MIME-Version: 1.0 Received: by 10.90.116.9 with SMTP id o9mr7605940agc.121.1240261928123; Mon, 20 Apr 2009 14:12:08 -0700 (PDT) In-Reply-To: <218141.98505.qm@web111404.mail.gq1.yahoo.com> References: <24B90FDA-7E8C-4F6A-8E59-0E37BFD9F8A6@gmail.com> <617661.83572.qm@web111405.mail.gq1.yahoo.com> <8DA860D8-8418-4EEE-80D4-C38E462ADBAF@gmail.com> <970819.11318.qm@web111405.mail.gq1.yahoo.com> <218141.98505.qm@web111404.mail.gq1.yahoo.com> Date: Mon, 20 Apr 2009 22:12:08 +0100 Message-ID: From: George Tsirtsis To: Behcet Sarikaya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , Jari Arkko , mext mext Subject: Re: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:11:47 -0000 sorry Bechet but I think you are missing the point. As far as the Host IP stack is concerned there is only a SINGLE Interface (the one presented by MIPv6), the address of which is the home address or prefix. Under that virtual MIPv6 Interface, MIPv6 stack hides multiple physical interfaces. Each of these interfaces has its own separate prefix. There is no 'monkey business' of sharing prefixes between interfaces here. George On Mon, Apr 20, 2009 at 10:07 PM, Behcet Sarikaya wrote: > George, > =C2=A0 So you are saying that my observation (single prefix is used/must = be used > on all interfaces of MN) is correct. > =C2=A0 I think that this would create multi-link subnets at the home link= and RFC > 4903 says we should avoid them by simply assigning different prefixes to > each. > > Regards, > > Behcet > > ________________________________ > From: George Tsirtsis > To: Behcet Sarikaya > Cc: Ryuji Wakikawa ; Julien Laganier > ; Jari Arkko ; > mext mext > Sent: Monday, April 20, 2009 3:54:25 PM > Subject: Re: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.t= xt) > > Bechet, > > The prefix you are talking about is the home address. The home address > in MIPv6 sits on a single MIPv6 Interface in the MN which from the > perspective of the host IP stack is unique, fixed, does not move, does > not change...nothing. > > All the other (physical) interfaces that come and go have addresses > that become CoAs in the context of MIPv6. > > I do not think there is anything strange here. > > George > > On Mon, Apr 20, 2009 at 9:38 PM, Behcet Sarikaya > wrote: >> >> >> ________________________________ >> From: Ryuji Wakikawa >> To: Behcet Sarikaya >> Cc: mext mext ; Jari Arkko ; Julien >> Laganier >> Sent: Monday, April 20, 2009 3:19:11 PM >> Subject: Re: [MEXT] A new version of draft-ietf-monami6-multiplecoa >> (13.txt) >> >> Hi Behcet, >> >> Again, why do you say prefix? A home address is shared among multiple >> interfaces. >> George have already answered to you. >> >> [behcet] Is this the mail you are talking >> about=C2=A0http://www.ietf.org/mail-archive/web/mext/current/msg02758.ht= ml? >> I don't think he answered it. >> This MCoA is an extension to Mobile IP. Proxy Mobile IPv6 is not support= ed >> in this document.. >> [behcet] You mean point-to-point links only in PMIPv6? I don't think so, >> RFC >> 4903 is not just for PMIPv6. >> thanks >> ryuji >> >> On 2009/04/20, at 16:02, Behcet Sarikaya wrote: >> >>> Ryuji, the problem I mentioned previously: >>> http://www..ietf.org/mail-archive/web/mext/current/msg02759.html >>> stays the same in this version. The draft gives the impression that the >>> same prefix, e.g.. 2001:db8:: is required to support multiple interface= s >>> of >>> MN. This is not stated anywhere in the draft but is drawn in Figures 1,= 2 >>> and 3. >>> >>> Regards, >>> >>> Behcet >>> >>> From: Ryuji Wakikawa >>> To: mext mext >>> Cc: Jari Arkko ; Julien Laganier >>> >>> Sent: Monday, April 20, 2009 10:36:38 AM >>> Subject: [MEXT] A new version of draft-ietf-monami6-multiplecoa (13.txt= ) >>> >>> Hi all, >>> #Cc: MEXT chairs and Jari >>> >>> We completed IESG review and submitted a new version of the multiplecoa >>> document (ver13) . >>> The following changes were implemented in ver13 of the MCoAv6 draft: >>> >>> 1)=C2=A0 =C2=A0 =C2=A0 Home Registrations >>> Based on draft v12 there are two way of achieving simultaneous home and >>> foreign link registrations. >>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One does NOT associate the home lin= k with a BID and it is >>> based >>> on a deregistration at a home link. >>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The other DOES associate the home l= ink with a BID and it is >>> based on a registration with a BID option including CoA=3DHoA and the H= =3D1. >>> >>> V13 of the draft has been updated so that simultaneous use of home and >>> foreign links requires a home registration with BID including CoA=3DHoA= and >>> H=3D1. This simplifies the protocol and unifies all bindings by associa= ting >>> all of them with BIDs.. >>> >>> Due to the structure of the document, to implement this change a lot of >>> text, mostly under section 5.6, had to be re-written and/or rearranged = so >>> the diff between v12 and v13 may give the impression of major changes. = In >>> fact, material was mostly removed, moved, or rephrased, and nothing new >>> was >>> added, since all we did is to remove one of the options. >>> >>> 2)=C2=A0 =C2=A0 =C2=A0 CoA field in BID option. >>> According to draft v12, the CoA may not be included in a BID in some >>> cases. The rules for when the CoA is needed or not are however overly >>> complex. For example the CoA MAY NOT be included when a BID is >>> deregistered >>> but they MUST be included in Bulk Registrations. Draft v12 also allows >>> the >>> CoA associated with a BID to=C2=A0 be learned from the source address o= f the >>> packet or the Alt-Coa, which results in additional rules about how to >>> handle >>> this. >>> >>> Draft v13 reduces the complexity of the protocol by simplifying these >>> rules as follows: >>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Any BID that is registered for the = first time MUST include the >>> CoA associated with it. >>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Any BID refreshed, deregistered or = otherwise manipulated MAY >>> NOT include the CoA >>> This change was easier to implement. A clear statement defining this >>> rules >>> is added at the end of 5.1 and then several references to use of Alt-Co= A >>> have been cleaned up. >>> >>> 3)=C2=A0 =C2=A0 =C2=A0 Updated Error Codes >>> The MCOA BID CONFLICT code is removed since it became unnecessary when >>> the >>> =E2=80=98O=E2=80=99 flag was introduced. Instead two new error codes ar= e added >>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MCOA NON-BID BINDING EXISTS, to ind= icate that an MN attempted >>> to bootstrap MCoA without =E2=80=98O=E2=80=99 flag set. (Replacement of= BID CONFLICT) >>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MCOA UNKNOWN COA, to indicate that = the MN send a BID option >>> w/o >>> a CoA but the receiver has no record of the BID. >>> >>> 4)=C2=A0 =C2=A0 Updated Security Section 9.5.2 >>> 1. clarified that the check on the outer IPv6 header source address is >>> not >>> required >>> 2. Added text that showed how you can figure out the right CoA for the >>> destination address on the outer IP header while using just one IPsec S= A. >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > > From mer@kafka.verkstad.net Tue Apr 21 03:52:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249743A6AD3 for ; Tue, 21 Apr 2009 03:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 Mtn+ta-YiKfQ for ; Tue, 21 Apr 2009 03:52:11 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id EF9233A69CC for ; Tue, 21 Apr 2009 03:52:10 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 3C84E710A95; Tue, 21 Apr 2009 12:53:26 +0200 (CEST) Date: Tue, 21 Apr 2009 12:53:26 +0200 From: Michael Eriksson To: marcelo bagnulo braun Message-ID: <20090421105326.GA20775@kafka.verkstad.net> References: <4C51279E-272C-4C8F-A7B1-938014312287@lsiit.u-strasbg.fr> <49E84374.6030808@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E84374.6030808@it.uc3m.es> Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 10:52:12 -0000 On Fri, Apr 17, 2009 at 10:53:08 +0200, marcelo bagnulo braun wrote: > In the charter we have: > > - A "Flow/binding policies exchange" solution for an exchange of > policies from the mobile host/router to the Home Agent and from the > Home Agent to the mobile host/router influencing the choice of the > Care-of Address and Home Agent address. The solution involves two > specifications, one for the policy format and another for its > transport [both Standard Track]. > > For this deliverable we have: > > draft-ietf-mext-flow-binding-01.txt defines the transport part of the > last sentence in the paragraph above. > > draft-larsson-mext-flow-distribution-rules and the other binary encoding > defines the policy format of the last sentence of the charter paragraph > above. > > We all agree? Well, now that we are taking a new grip on flow routing, I would like to push draft-eriksson-mext-mipv6-routing-rules-00, which Romain also pointed at. http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules draft-eriksson describes a new way to transfer flow routing rules. It is thus an alternative to draft-ietf-mext-flow-binding. Notable differences between the drafts: - draft-eriksson supports transferring of rules in both directions, MN to HA as well as HA to MN. The flow-binding draft only supports one way rule transmission, MN to HA. This means that the flow-binding draft does not fulfill the requirements from the wg charter, which includes HA to MN rule transfer. - draft-eriksson separates rule updates from handovers (BUs), since they are completely separate events. Separating them leads to a protocol that is both simpler and more efficient. - The rule format in draft-eriksson is completely open. The format in the flow-binding draft is very complex, and difficult to adapt to other rule formats than what it was originally designed for. draft-eriksson has currently expired, but can of course be revived after feedback from the mailing list. Regards, Michael From marcelo@it.uc3m.es Tue Apr 21 04:01:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34D183A68CC for ; Tue, 21 Apr 2009 04:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 6QCaeFPEwS5z for ; Tue, 21 Apr 2009 04:01:49 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id EB17B3A68AF for ; Tue, 21 Apr 2009 04:01:48 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (220.pool85-53-141.dynamic.orange.es [85.53.141.220]) by smtp02.uc3m.es (Postfix) with ESMTP id 502D26BAD1B; Tue, 21 Apr 2009 13:03:03 +0200 (CEST) Message-ID: <49EDA7E7.60102@it.uc3m.es> Date: Tue, 21 Apr 2009 13:03:03 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Michael Eriksson References: <4C51279E-272C-4C8F-A7B1-938014312287@lsiit.u-strasbg.fr> <49E84374.6030808@it.uc3m.es> <20090421105326.GA20775@kafka.verkstad.net> In-Reply-To: <20090421105326.GA20775@kafka.verkstad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16594.005 Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 11:01:50 -0000 I understand that we do have a WG document for this and we had several rounds of reviews which show interest, so i don't see any reason to revisit the decision of using draft-ietf-flow-binding at this point. regards, marcelo Michael Eriksson escribió: > On Fri, Apr 17, 2009 at 10:53:08 +0200, marcelo bagnulo braun wrote: > >> In the charter we have: >> >> - A "Flow/binding policies exchange" solution for an exchange of >> policies from the mobile host/router to the Home Agent and from the >> Home Agent to the mobile host/router influencing the choice of the >> Care-of Address and Home Agent address. The solution involves two >> specifications, one for the policy format and another for its >> transport [both Standard Track]. >> >> For this deliverable we have: >> >> draft-ietf-mext-flow-binding-01.txt defines the transport part of the >> last sentence in the paragraph above. >> >> draft-larsson-mext-flow-distribution-rules and the other binary encoding >> defines the policy format of the last sentence of the charter paragraph >> above. >> >> We all agree? >> > > Well, now that we are taking a new grip on flow routing, I would like > to push draft-eriksson-mext-mipv6-routing-rules-00, which Romain also > pointed at. > > http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules > > draft-eriksson describes a new way to transfer flow routing rules. It > is thus an alternative to draft-ietf-mext-flow-binding. Notable > differences between the drafts: > > - draft-eriksson supports transferring of rules in both directions, MN > to HA as well as HA to MN. > > The flow-binding draft only supports one way rule transmission, MN > to HA. This means that the flow-binding draft does not fulfill the > requirements from the wg charter, which includes HA to MN rule > transfer. > > - draft-eriksson separates rule updates from handovers (BUs), since > they are completely separate events. Separating them leads to a > protocol that is both simpler and more efficient. > > - The rule format in draft-eriksson is completely open. The format in > the flow-binding draft is very complex, and difficult to adapt to > other rule formats than what it was originally designed for. > > > draft-eriksson has currently expired, but can of course be revived > after feedback from the mailing list. > > > Regards, > Michael > > From mer@kafka.verkstad.net Tue Apr 21 04:27:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E0A28C1D8 for ; Tue, 21 Apr 2009 04:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 E53B1U1lxgde for ; Tue, 21 Apr 2009 04:27:51 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 34A7B28C1C7 for ; Tue, 21 Apr 2009 04:27:51 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 5801C710AC6; Tue, 21 Apr 2009 13:29:07 +0200 (CEST) Date: Tue, 21 Apr 2009 13:29:07 +0200 From: Michael Eriksson To: marcelo bagnulo braun Message-ID: <20090421112907.GB20775@kafka.verkstad.net> References: <4C51279E-272C-4C8F-A7B1-938014312287@lsiit.u-strasbg.fr> <49E84374.6030808@it.uc3m.es> <20090421105326.GA20775@kafka.verkstad.net> <49EDA7E7.60102@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49EDA7E7.60102@it.uc3m.es> Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 11:27:52 -0000 On Tue, Apr 21, 2009 at 13:03:03 +0200, marcelo bagnulo braun wrote: > > Well, now that we are taking a new grip on flow routing, I would like > > to push draft-eriksson-mext-mipv6-routing-rules-00, which Romain also > > pointed at. > > > > http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules > > I understand that we do have a WG document for this and we had several > rounds of reviews which show interest, so i don't see any reason to > revisit the decision of using draft-ietf-flow-binding at this point. > regards, marcelo Well, the WG document has had exactly zero progress since the 00 version was adopted almost a full year ago. It's not like chosing another way to transfer routing rules would be a last minute stop to something that has already been finished. It is also the case that the suggested rule format is what is defined in draft-larsson-mext-flow-distribution-rules. As a co-author of that draft, I want to stress that the rule transfer format in the flow-binding draft is very inflexible. Finally, that I am pushing draft-eriksson doesn't mean that we would have to adopt it as is (even if I would be happy if that happened :-)). See it as input on how we think flow rule transfer should be done. I think I mentioned some valid advantages compared to the flow-binding draft in my last e-mail. Regards, Michael From hesham@elevatemobile.com Tue Apr 21 04:34:47 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F523A701E for ; Tue, 21 Apr 2009 04:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 84RxQ2v2H31P for ; Tue, 21 Apr 2009 04:34:46 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 437C73A701B for ; Tue, 21 Apr 2009 04:34:45 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LwEGZ-0000vr-Uc; Tue, 21 Apr 2009 21:35:56 +1000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 21 Apr 2009 21:35:47 +1100 From: Hesham Soliman To: Michael Eriksson , marcelo bagnulo braun Message-ID: Thread-Topic: [MEXT] One more try (was Re: clarification on flow binding documents Thread-Index: AcnCdVA+9Z9vrAg0gEmfAWjdTNoGzg== In-Reply-To: <20090421112907.GB20775@kafka.verkstad.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 11:34:47 -0000 On 21/04/09 10:29 PM, "Michael Eriksson" wrote: > On Tue, Apr 21, 2009 at 13:03:03 +0200, marcelo bagnulo braun wrote: >>> Well, now that we are taking a new grip on flow routing, I would like >>> to push draft-eriksson-mext-mipv6-routing-rules-00, which Romain also >>> pointed at. >>> >>> http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules >> >> I understand that we do have a WG document for this and we had several >> rounds of reviews which show interest, so i don't see any reason to >> revisit the decision of using draft-ietf-flow-binding at this point. >> regards, marcelo > > Well, the WG document has had exactly zero progress since the 00 > version was adopted almost a full year ago. It's not like chosing > another way to transfer routing rules would be a last minute stop to > something that has already been finished. => Nonsense. The WG document has been depending on the progress of MCoA and now that MCoA is done we will have a new near final version by the weekend. This version has already received numerous reviews and some feedback from implementations. We expect this to go to LC before the next meeting. Please get those facts straight. BTW, the 00 version was around for discussions and review for a couple of years as a monami6 WG doc before it was adopted by the MEXT WG. Hesham From yuri.ismailov@ericsson.com Tue Apr 21 05:04:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6241D28C1E4 for ; Tue, 21 Apr 2009 05:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 X1r5mt8ur00j for ; Tue, 21 Apr 2009 05:04:19 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4317028C1E1 for ; Tue, 21 Apr 2009 05:04:19 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8091A206AE; Tue, 21 Apr 2009 14:05:34 +0200 (CEST) X-AuditID: c1b4fb3e-ab784bb000005486-a1-49edb68e3b59 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6AAD82008D; Tue, 21 Apr 2009 14:05:34 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 14:04:44 +0200 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, 21 Apr 2009 14:04:43 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] One more try (was Re: clarification on flow binding documents Thread-Index: AcnCdVA+9Z9vrAg0gEmfAWjdTNoGzgAAx4xQ References: <20090421112907.GB20775@kafka.verkstad.net> From: "Yuri Ismailov" To: "Hesham Soliman" , "Michael Eriksson" , "marcelo bagnulo braun" X-OriginalArrivalTime: 21 Apr 2009 12:04:44.0747 (UTC) FILETIME=[5C0591B0:01C9C279] X-Brightmail-Tracker: AAAAAA== Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 12:04:20 -0000 =3D> Nonsence. Consider this is yet another feedback from = implementation. Another intresting thing is that technical arguments are answered back with procedural arguments. Suggest not to mess up those otherwise it sounds too bureaucratic. Documents having RFC status can be obsoleted as well. /yuri -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Hesham Soliman Sent: Tuesday, April 21, 2009 12:36 PM To: Michael Eriksson; marcelo bagnulo braun Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents On 21/04/09 10:29 PM, "Michael Eriksson" wrote: > On Tue, Apr 21, 2009 at 13:03:03 +0200, marcelo bagnulo braun wrote: >>> Well, now that we are taking a new grip on flow routing, I would=20 >>> like to push draft-eriksson-mext-mipv6-routing-rules-00, which=20 >>> Romain also pointed at. >>>=20 >>> http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules >>=20 >> I understand that we do have a WG document for this and we had=20 >> several rounds of reviews which show interest, so i don't see any=20 >> reason to revisit the decision of using draft-ietf-flow-binding at this point. >> regards, marcelo >=20 > Well, the WG document has had exactly zero progress since the 00=20 > version was adopted almost a full year ago. It's not like chosing=20 > another way to transfer routing rules would be a last minute stop to=20 > something that has already been finished. =3D> Nonsense. The WG document has been depending on the progress of = MCoA and now that MCoA is done we will have a new near final version by the weekend. This version has already received numerous reviews and some feedback from implementations. We expect this to go to LC before the next meeting. Please get those facts straight. BTW, the 00 version was around for discussions and review for a couple of years as a monami6 WG doc before it was adopted by the MEXT WG.=20 Hesham _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Tue Apr 21 05:13:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABBD23A6B32 for ; Tue, 21 Apr 2009 05:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 WBgAM0ULbEyp for ; Tue, 21 Apr 2009 05:13:36 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id C39563A67E7 for ; Tue, 21 Apr 2009 05:13:35 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LwEs9-0001fj-Ow; Tue, 21 Apr 2009 22:14:46 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Tue, 21 Apr 2009 22:14:40 +1000 From: Hesham Soliman To: Yuri Ismailov , Michael Eriksson , marcelo bagnulo braun Message-ID: Thread-Topic: [MEXT] One more try (was Re: clarification on flow binding documents Thread-Index: AcnCdVA+9Z9vrAg0gEmfAWjdTNoGzgAAx4xQAACUGIQ= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 12:13:37 -0000 Yuri, What is nonsense? And what is the feedback from implementations? I'm responding to the comment that there was zero progress and that the draft is not near completion, both of which are wrong. What are you calling nonsesnse and what is the feedback you're offering? Hesham On 21/04/09 10:04 PM, "Yuri Ismailov" wrote: > => Nonsence. Consider this is yet another feedback from implementation. > Another intresting thing is that technical arguments are answered back > with procedural arguments. > Suggest not to mess up those otherwise it sounds too bureaucratic. > Documents having RFC status can be obsoleted as well. > > /yuri > > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Hesham Soliman > Sent: Tuesday, April 21, 2009 12:36 PM > To: Michael Eriksson; marcelo bagnulo braun > Cc: mext > Subject: Re: [MEXT] One more try (was Re: clarification on flow binding > documents > > > > > On 21/04/09 10:29 PM, "Michael Eriksson" > wrote: > >> On Tue, Apr 21, 2009 at 13:03:03 +0200, marcelo bagnulo braun wrote: >>>> Well, now that we are taking a new grip on flow routing, I would >>>> like to push draft-eriksson-mext-mipv6-routing-rules-00, which >>>> Romain also pointed at. >>>> >>>> http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules >>> >>> I understand that we do have a WG document for this and we had >>> several rounds of reviews which show interest, so i don't see any >>> reason to revisit the decision of using draft-ietf-flow-binding at > this point. >>> regards, marcelo >> >> Well, the WG document has had exactly zero progress since the 00 >> version was adopted almost a full year ago. It's not like chosing >> another way to transfer routing rules would be a last minute stop to >> something that has already been finished. > > => Nonsense. The WG document has been depending on the progress of MCoA > and now that MCoA is done we will have a new near final version by the > weekend. > This version has already received numerous reviews and some feedback > from implementations. We expect this to go to LC before the next > meeting. Please get those facts straight. BTW, the 00 version was around > for discussions and review for a couple of years as a monami6 WG doc > before it was adopted by the MEXT WG. > > Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Tue Apr 21 05:31:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D9628C1BE for ; Tue, 21 Apr 2009 05:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 xo8fTkYSu6L5 for ; Tue, 21 Apr 2009 05:31:57 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id D1FF328C19C for ; Tue, 21 Apr 2009 05:31:56 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (220.pool85-53-141.dynamic.orange.es [85.53.141.220]) by smtp03.uc3m.es (Postfix) with ESMTP id 9980C731B66; Tue, 21 Apr 2009 14:33:10 +0200 (CEST) Message-ID: <49EDBD06.40802@it.uc3m.es> Date: Tue, 21 Apr 2009 14:33:10 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Michael Eriksson References: <4C51279E-272C-4C8F-A7B1-938014312287@lsiit.u-strasbg.fr> <49E84374.6030808@it.uc3m.es> <20090421105326.GA20775@kafka.verkstad.net> <49EDA7E7.60102@it.uc3m.es> <20090421112907.GB20775@kafka.verkstad.net> In-Reply-To: <20090421112907.GB20775@kafka.verkstad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16594.007 Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 12:31:58 -0000 Michael Eriksson escribió: > On Tue, Apr 21, 2009 at 13:03:03 +0200, marcelo bagnulo braun wrote: > >>> Well, now that we are taking a new grip on flow routing, I would like >>> to push draft-eriksson-mext-mipv6-routing-rules-00, which Romain also >>> pointed at. >>> >>> http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules >>> >> I understand that we do have a WG document for this and we had several >> rounds of reviews which show interest, so i don't see any reason to >> revisit the decision of using draft-ietf-flow-binding at this point. >> regards, marcelo >> > > Well, the WG document has had exactly zero progress since the 00 > version was adopted almost a full year ago. It's not like chosing > another way to transfer routing rules would be a last minute stop to > something that has already been finished. > in general, as a chair, i like to make progress forward in the process i.e. wg doc adoption, WGLC, IESG, RFC, rather than in the oposite direction, i.e. adopting a WG document, disadopting a WG doc and so on Of course, things are not always forward and sometimes the WG consensus is that we were wrong in the first approach and we need to change. What i am saying that i don't see this trend here. We had considerable amount of activivty and reviews in this doc lately, so to me that epxresses that the WG feels this doc is in good shape > It is also the case that the suggested rule format is what is defined > in draft-larsson-mext-flow-distribution-rules. As a co-author of that > draft, I want to stress that the rule transfer format in the > flow-binding draft is very inflexible. > > this would then make the case that the format defined in draft-larson is not very suitbale for the transport that the WG has chosen, which would then mean that we probably want to use the bit pattern rules instead, right? > Finally, that I am pushing draft-eriksson doesn't mean that we would > have to adopt it as is (even if I would be happy if that happened > :-)). See it as input on how we think flow rule transfer should be > done. I think I mentioned some valid advantages compared to the > flow-binding draft in my last e-mail. > > sure, any WG member is entitled to make any comments they feel like. I am just saying that the current plan is to make progress with the doc the WG has chosen, but i guess that's obvious. Regards, marcelo > Regards, > Michael > > From tsirtsis@googlemail.com Tue Apr 21 05:35:05 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE873A701C for ; Tue, 21 Apr 2009 05:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 pHj72jaxta2c for ; Tue, 21 Apr 2009 05:35:04 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 68A693A701D for ; Tue, 21 Apr 2009 05:35:04 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so929530yxb.49 for ; Tue, 21 Apr 2009 05:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=n3crHgOpoo1uBDR05igIcb3ZjIcBi17eUN6hTublbZ8=; b=cCsu7RTE61j2ehRsqP3qdkSnqBIXYBVQ7pRJqGXoSZpcFTb00z0kAvFSovqkxSPXrf I3Bg7ASrDhZlKT6pTePcOlpBgMLBQsm5IoB4eRac6yFZvf0PjHNctuWaVsqPTnbCOvpM S5yb4ejbgxeg+m7r7gEAZOd1QXt27BcFgkJS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=moQhbwBYWqwfMYYBBJlevXDN8JKRHh0JxL8+74yIpAV7DnCqwIbbYTUGPAOUJUpYeU 2ep2muX7RgT2Iulgx/cXGKeX2q0HLSKMWwQxkhs+JUstmDlhKYBwmp49GrB6YpY2Nbhg DUu+aKAL4jNN1eZCI7SxU71ewKouyY74PNLro= MIME-Version: 1.0 Received: by 10.90.99.6 with SMTP id w6mr5851135agb.90.1240317380484; Tue, 21 Apr 2009 05:36:20 -0700 (PDT) In-Reply-To: References: <20090421112907.GB20775@kafka.verkstad.net> Date: Tue, 21 Apr 2009 13:36:20 +0100 Message-ID: From: George Tsirtsis To: Yuri Ismailov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext , Michael Eriksson Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 12:35:05 -0000 Yuri, What you guys are proposing is architecturaly significantly different from what this WG has agreed to do and what the Flow Bindings draft is all about. For example, allowing the HA to send rules to the MN are both significant departures from the current agreement. I would also point out that in theory there is nothing preventing us from extending the Flow Bindings work to any of the directions you are talking about, except from the fact that some of us might disagree...especially with the HA sending rules to the MN part. Instead of trying to reinvent the wheel, which will likely be futile, I would suggest you wait for the new version of the Flow Bindings draft. Then write a draft (or e-mail) proposing ways of extending Flow Bindings with your desired features. Then, we can have a discussion about whether such changes are useful and desirable. Regards George Tue, Apr 21, 2009 at 1:04 PM, Yuri Ismailov w= rote: > =3D> Nonsence. Consider this is yet another feedback from implementation. > Another intresting thing is that technical arguments are answered back > with procedural arguments. > Suggest not to mess up those otherwise it sounds too bureaucratic. > Documents having RFC status can be obsoleted as well. > > /yuri > > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Hesham Soliman > Sent: Tuesday, April 21, 2009 12:36 PM > To: Michael Eriksson; marcelo bagnulo braun > Cc: mext > Subject: Re: [MEXT] One more try (was Re: clarification on flow binding > documents > > > > > On 21/04/09 10:29 PM, "Michael Eriksson" > wrote: > >> On Tue, Apr 21, 2009 at 13:03:03 +0200, marcelo bagnulo braun wrote: >>>> Well, now that we are taking a new grip on flow routing, I would >>>> like to push draft-eriksson-mext-mipv6-routing-rules-00, which >>>> Romain also pointed at. >>>> >>>> =C2=A0 http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-ru= les >>> >>> I understand that we do have a WG document for this and we had >>> several rounds of reviews which show interest, so i don't see any >>> reason to revisit the decision of using draft-ietf-flow-binding at > this point. >>> regards, marcelo >> >> Well, the WG document has had exactly zero progress since the 00 >> version was adopted almost a full year ago. It's not like chosing >> another way to transfer routing rules would be a last minute stop to >> something that has already been finished. > > =3D> Nonsense. The WG document has been depending on the progress of MCoA > and now that MCoA is done we will have a new near final version by the > weekend. > This version has already received numerous reviews and some feedback > from implementations. We expect this to go to LC before the next > meeting. Please get those facts straight. BTW, the 00 version was around > for discussions and review for a couple of years as a monami6 WG doc > before it was adopted by the MEXT WG. > > Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From conny.larsson@ericsson.com Tue Apr 21 08:13:35 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E0328C1DF for ; Tue, 21 Apr 2009 08:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.738 X-Spam-Level: X-Spam-Status: No, score=-5.738 tagged_above=-999 required=5 tests=[AWL=0.511, 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 xYhQ3OR2YX0x for ; Tue, 21 Apr 2009 08:13:34 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 450E728C194 for ; Tue, 21 Apr 2009 08:13:34 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B2B9920772; Tue, 21 Apr 2009 17:14:49 +0200 (CEST) X-AuditID: c1b4fb3c-ae7d2bb00000238f-89-49ede2e990b2 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 980E020503; Tue, 21 Apr 2009 17:14:49 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 17:14:49 +0200 Received: from [127.0.0.1] ([147.214.130.137]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 17:14:48 +0200 Message-ID: <49EDE2E8.20601@ericsson.com> Date: Tue, 21 Apr 2009 17:14:48 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4C51279E-272C-4C8F-A7B1-938014312287@lsiit.u-strasbg.fr> <49E84374.6030808@it.uc3m.es> <20090421105326.GA20775@kafka.verkstad.net> <49EDA7E7.60102@it.uc3m.es> <20090421112907.GB20775@kafka.verkstad.net> <49EDBD06.40802@it.uc3m.es> In-Reply-To: <49EDBD06.40802@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2009 15:14:48.0930 (UTC) FILETIME=[E971CC20:01C9C293] X-Brightmail-Tracker: AAAAAA== Cc: Michael Eriksson , mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 15:13:35 -0000 Hi Marcelo, marcelo bagnulo braun wrote: > >> It is also the case that the suggested rule format is what is defined >> in draft-larsson-mext-flow-distribution-rules. As a co-author of that >> draft, I want to stress that the rule transfer format in the >> flow-binding draft is very inflexible. >> >> > this would then make the case that the format defined in draft-larson > is not very suitbale for the transport that the WG has chosen, which > would then mean that we probably want to use the bit pattern rules > instead, right? Or that the transport protocol are making assumptions that are not needed since they are only applicable for one type of solution. Regards Conny From ryuji.wakikawa@gmail.com Tue Apr 21 08:28:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16413A6BB1 for ; Tue, 21 Apr 2009 08:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 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 KPrtdcmppzS9 for ; Tue, 21 Apr 2009 08:28:13 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id B034B3A6B13 for ; Tue, 21 Apr 2009 08:28:12 -0700 (PDT) Received: by qyk42 with SMTP id 42so3444602qyk.29 for ; Tue, 21 Apr 2009 08:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=LuuwENZK60Cgjg9Gfc0XFSfKraBluc4U70LlLwTvvuQ=; b=jBqSo8v1nqZocmmmVfodboFEBKjWLfktS0RV+Otfac4uBTVvRaU0IA6g7fgBr0zF7E lo6S9hz97Tvw/nE57GqXrxbvGVtAnxCIgqIu34sWwMZLjFHwHCFOe1y/UGI2O5b4okCe wutH8ZxtKNwqu5QgXHyKyG35CWMtJZh4D/yqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=e2PBpptJnQtyGWd+o5dquNH64BsC7TAlfviLnPMct+mCVYU5wSPMsPlLdOJlmtzGpQ XRV4jpkl8wUG83FSR/qovOhlAQ2V7u3WnSfPahKgay0nG2spM6f2wrlyFB1cWXomsVyf GA8Aj2F0tI9BhbxPOdeTqnsYDMdDEuC6WkllU= Received: by 10.224.67.133 with SMTP id r5mr7836820qai.285.1240327768148; Tue, 21 Apr 2009 08:29:28 -0700 (PDT) Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id 6sm10308128ywc.23.2009.04.21.08.29.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Apr 2009 08:29:27 -0700 (PDT) From: Ryuji Wakikawa To: George Tsirtsis In-Reply-To: References: <20090421112907.GB20775@kafka.verkstad.net> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 11:29:26 -0400 X-Mailer: Apple Mail (2.930.3) Cc: Michael Eriksson , mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 15:28:14 -0000 Hi George, one comment. On 2009/04/21, at 8:36, George Tsirtsis wrote: > Yuri, > > What you guys are proposing is architecturaly significantly different > from what this WG has agreed to do and what the Flow Bindings draft is > all about. > > For example, allowing the HA to send rules to the MN are both > significant departures from the current agreement. I asked to support this feature in the flow binding several times (1-2 years ago?) This is somewhat related what we have discussed (defining MH type for flow exchange) at the previous IETF. There are some scenarios triggering the flow exchange from the network side (HA). regards, ryuji > > > I would also point out that in theory there is nothing preventing us > from extending the Flow Bindings work to any of the directions you are > talking about, except from the fact that some of us might > disagree...especially with the HA sending rules to the MN part. > > Instead of trying to reinvent the wheel, which will likely be futile, > I would suggest you wait for the new version of the Flow Bindings > draft. Then write a draft (or e-mail) proposing ways of extending Flow > Bindings with your desired features. Then, we can have a discussion > about whether such changes are useful and desirable. > > Regards > George > > Tue, Apr 21, 2009 at 1:04 PM, Yuri Ismailov > wrote: >> => Nonsence. Consider this is yet another feedback from >> implementation. >> Another intresting thing is that technical arguments are answered >> back >> with procedural arguments. >> Suggest not to mess up those otherwise it sounds too bureaucratic. >> Documents having RFC status can be obsoleted as well. >> >> /yuri >> >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On >> Behalf Of >> Hesham Soliman >> Sent: Tuesday, April 21, 2009 12:36 PM >> To: Michael Eriksson; marcelo bagnulo braun >> Cc: mext >> Subject: Re: [MEXT] One more try (was Re: clarification on flow >> binding >> documents >> >> >> >> >> On 21/04/09 10:29 PM, "Michael Eriksson" > > >> wrote: >> >>> On Tue, Apr 21, 2009 at 13:03:03 +0200, marcelo bagnulo braun wrote: >>>>> Well, now that we are taking a new grip on flow routing, I would >>>>> like to push draft-eriksson-mext-mipv6-routing-rules-00, which >>>>> Romain also pointed at. >>>>> >>>>> http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules >>>> >>>> I understand that we do have a WG document for this and we had >>>> several rounds of reviews which show interest, so i don't see any >>>> reason to revisit the decision of using draft-ietf-flow-binding at >> this point. >>>> regards, marcelo >>> >>> Well, the WG document has had exactly zero progress since the 00 >>> version was adopted almost a full year ago. It's not like chosing >>> another way to transfer routing rules would be a last minute stop to >>> something that has already been finished. >> >> => Nonsense. The WG document has been depending on the progress of >> MCoA >> and now that MCoA is done we will have a new near final version by >> the >> weekend. >> This version has already received numerous reviews and some feedback >> from implementations. We expect this to go to LC before the next >> meeting. Please get those facts straight. BTW, the 00 version was >> around >> for discussions and review for a couple of years as a monami6 WG doc >> before it was adopted by the MEXT WG. >> >> Hesham >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Tue Apr 21 08:30:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E153A6BB1 for ; Tue, 21 Apr 2009 08:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 6TraKuAWFWZv for ; Tue, 21 Apr 2009 08:30:14 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id A84753A6DCF for ; Tue, 21 Apr 2009 08:30:14 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so1406688qwe.31 for ; Tue, 21 Apr 2009 08:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=Ne1dsYQgKUmxKAsgvMvrsIFQ9ZwaF2W3J/s0dOWyyZs=; b=ULkF+7MEVZ1unzI3EgwzVDduGVNW9cNNvncwMBc+dHZKqh5ecMCYEX49Dlev+fKlxO zDDZt0zrmjYZojXg3+uCsY5yLBjTD1LUuSKSoOeR/74mtM9cQez5HiREoa3BMb5jpHtr GFm1m3Yx+TsFK9S+EM0GvsykoaRuOYfWIJ93U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=RYjodxad6iWJ3dK+p5a0EDpaGe2n1hdINoPIgtZnwfgzRB78ZXOD4Zr+4gbP6h6Ngr 5ZcoO8cA7OEewFX2G5zGUO96vdvj0t69eihW075S/Jrnbw730WMVGI1g3cw/8IYiGF7+ mFL7GBhDoy6aEzO2w7MogWqgDWgsa2fuWaRrY= Received: by 10.229.84.213 with SMTP id k21mr1074631qcl.19.1240327869190; Tue, 21 Apr 2009 08:31:09 -0700 (PDT) Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id 9sm5668ywf.16.2009.04.21.08.31.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Apr 2009 08:31:08 -0700 (PDT) From: Ryuji Wakikawa To: Hesham Soliman In-Reply-To: References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 11:31:07 -0400 X-Mailer: Apple Mail (2.930.3) Cc: Michael Eriksson , mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 15:30:15 -0000 Hi Hesham, I am collecting the implementation info of MCoA or flow binding. Which implementation's' are you referring to ? Romain's one? Please share the implementations info if you can. thanks, ryuji On 2009/04/21, at 6:35, Hesham Soliman wrote: > > > > On 21/04/09 10:29 PM, "Michael Eriksson" > > wrote: > >> On Tue, Apr 21, 2009 at 13:03:03 +0200, marcelo bagnulo braun wrote: >>>> Well, now that we are taking a new grip on flow routing, I would >>>> like >>>> to push draft-eriksson-mext-mipv6-routing-rules-00, which Romain >>>> also >>>> pointed at. >>>> >>>> http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules >>> >>> I understand that we do have a WG document for this and we had >>> several >>> rounds of reviews which show interest, so i don't see any reason to >>> revisit the decision of using draft-ietf-flow-binding at this point. >>> regards, marcelo >> >> Well, the WG document has had exactly zero progress since the 00 >> version was adopted almost a full year ago. It's not like chosing >> another way to transfer routing rules would be a last minute stop to >> something that has already been finished. > > => Nonsense. The WG document has been depending on the progress of > MCoA and > now that MCoA is done we will have a new near final version by the > weekend. > This version has already received numerous reviews and some feedback > from > implementations. We expect this to go to LC before the next meeting. > Please > get those facts straight. BTW, the 00 version was around for > discussions and > review for a couple of years as a monami6 WG doc before it was > adopted by > the MEXT WG. > > Hesham > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From marcelo@it.uc3m.es Tue Apr 21 09:01:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C573A7010 for ; Tue, 21 Apr 2009 09:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 VTOaqwcfRCho for ; Tue, 21 Apr 2009 09:01:53 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id D43543A6B8E for ; Tue, 21 Apr 2009 09:01:50 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 7F3846C18DC; Tue, 21 Apr 2009 18:03:05 +0200 (CEST) Message-ID: <49EDEE39.50000@it.uc3m.es> Date: Tue, 21 Apr 2009 18:03:05 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext , Julien Laganier , Jari Arkko Content-Type: multipart/mixed; boundary="------------010307030406070703090702" Subject: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 16:01:54 -0000 This is a multi-part message in MIME format. --------------010307030406070703090702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We have this new version of the MCOA document that addresses the comments received, including IESG review comments. To the best of my knowledge, the IESG is ok with the doc and ready for publication. I am planning to ask our AD to move forward in a week or so, so, if you have comments on the document please provide them before the 1st of may. Regards, marcelo (mcoa doc shepherd) -------- Mensaje original -------- Asunto: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) De: Internet-Drafts@ietf.org Para: i-d-announce@ietf.org CC: mext@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Multiple Care-of Addresses Registration Author(s) : R. Wakikawa, et al. Filename : draft-ietf-monami6-multiplecoa-13.txt Pages : 44 Date : 2009-04-20 According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.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. --------------010307030406070703090702 Content-Type: Message/External-body; name="draft-ietf-monami6-multiplecoa-13.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-monami6-multiplecoa-13.txt" Content-Type: text/plain Content-ID: <2009-04-20082837.I-D@ietf.org> --------------010307030406070703090702 Content-Type: text/plain; name="Parte del mensaje adjunto" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Parte del mensaje adjunto" _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext --------------010307030406070703090702-- From behcetsarikaya@yahoo.com Tue Apr 21 09:18:02 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDDD23A6AC8 for ; Tue, 21 Apr 2009 09:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.389, 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 1BSviH2qkPh4 for ; Tue, 21 Apr 2009 09:18:01 -0700 (PDT) Received: from n2.bullet.mail.re3.yahoo.com (n2.bullet.mail.re3.yahoo.com [68.142.237.109]) by core3.amsl.com (Postfix) with SMTP id 7E42C3A6A0D for ; Tue, 21 Apr 2009 09:18:01 -0700 (PDT) Received: from [68.142.230.28] by n2.bullet.mail.re3.yahoo.com with NNFMP; 21 Apr 2009 16:18:14 -0000 Received: from [67.195.9.82] by t1.bullet.re2.yahoo.com with NNFMP; 21 Apr 2009 16:18:13 -0000 Received: from [67.195.9.101] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 21 Apr 2009 16:18:13 -0000 Received: from [127.0.0.1] by omp105.mail.gq1.yahoo.com with NNFMP; 21 Apr 2009 16:18:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 598676.63280.bm@omp105.mail.gq1.yahoo.com Received: (qmail 86717 invoked by uid 60001); 21 Apr 2009 16:18:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240330693; bh=ab3lnWsGDK1HSb38g8aviEem0kua8lbAQMU5NmX84qk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ORW1K/Z1Ou7zVIPT6qZ76ih32C3ZPkgXiDt5S/9A+4iZJGVVJxbZvbMLGZGJ5lE9CcButJZP5uxQLtuJEePi33CyRuxbGZLDNGKfnLAFVlvLZkXVIK2wyeNpFW0jFVTApZDoXuD2lQMUdFZPoFVjGtxAI0HIvInIa48yIPbAI0Y= 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; b=s0ETvL/n0HfL9wB4AHG1460sLATCbTT+FEAy9V0m7bu3SH0w39jEq19xPU2bd3jTYvTJU+uHqjZLCT3AcB3UL93WXQW7h98+7/m/vuUlkqmRZCQwUPzb1QtuCPFCZ0alMBbJyRinWR9IONnBYtS+CaZrOxK9afHeZSyIhLRedgY=; Message-ID: <307819.85927.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: ZTIXhbEVM1kTdjwPoU2_cSi.xfI.ActxYAeKUnzGZu_MSrZ1wR4TH2yvwbAnAeoN.cCYYGfVYM8Y4YQA6KcHgAZSvcxI59CneL20aWRGFgfAoXXLoQ2hWawXfHOxvgMUqhOwFYZzHt9pNeufkgrsYcdt4PycUC9_wfX8gsy4.pINMnwI0MWJCdlaKJMSXvnL1Yozw1VvDSJqeOhZ5AMAH0AOrgJOnD9BXHJ9RFAw197xHmP15vbbEHQMSRDxRavhiVCjFICxp1o559dEL31FGGoQoQUAuR4sICcOoUAbng70U2UbwpTI_ETvTJkFn52J2dez Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Tue, 21 Apr 2009 09:18:12 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> Date: Tue, 21 Apr 2009 09:18:12 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo braun , mext , Julien Laganier , Jari Arkko In-Reply-To: <49EDEE39.50000@it.uc3m.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1771764853-1240330692=:85927" Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 16:18:02 -0000 --0-1771764853-1240330692=:85927 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marcelo,=0A=A0 Do you consider the issue raised on the prefixes which af= fects Figures 1, 2 and 3 and possibly some other text closed?=0A=A0 If yes,= how is it closed? I for one is still confused especially with George's rep= ly that talks about virtual interfaces.=0A=A0 Also I have a question to Ryu= ji: does this draft send a non-deregistration BU at the home link? If yes, = is he familiar with the discussion going on on this subject? This is anothe= r point of confusion for me.=0A=A0 Sorry if I am too=A0 much confused =0APl= ease don't get me wrong, I am not trying to slow down the progress of this = document.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A_______________________________= _=0AFrom: marcelo bagnulo braun =0ATo: mext ; Julien Laganier ; Jari Arkko =0ASent: Tuesday, April 21, 2009 11:03:05 AM=0ASubject: = [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A=0AWe have= this new version of the MCOA document that addresses the comments received= , including IESG review comments.=0ATo the best of my knowledge, the IESG i= s ok with the doc and ready for publication.=0AI am planning to ask our AD = to move forward in a week or so, so, if you have comments on the document p= lease provide them before the 1st of may.=0A=0ARegards, marcelo=0A(mcoa doc= shepherd)=0A=0A-------- Mensaje original --------=0AAsunto: =A0=A0=A0 [MEX= T] I-D Action:draft-ietf-monami6-multiplecoa-13.txt=0AFecha: =A0=A0=A0 Mon,= 20 Apr 2009 08:30:01 -0700 (PDT)=0ADe: =A0=A0=A0 Internet-Drafts@ietf.org= =0APara: =A0=A0=A0 i-d-announce@ietf.org=0ACC: =A0=A0=A0 mext@ietf.org=0A= =0A=0A=0AA New Internet-Draft is available from the on-line Internet-Drafts= directories.=0AThis draft is a work item of the Mobility EXTensions for IP= v6 Working Group of the IETF.=0A=0A=0A=A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0 : = Multiple Care-of Addresses Registration=0A=A0=A0=A0 Author(s)=A0 =A0 =A0 : = R. Wakikawa, et al.=0A=A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-monami= 6-multiplecoa-13.txt=0A=A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0 : 44=0A=A0=A0=A0 = Date=A0 =A0 =A0 =A0 =A0 =A0 : 2009-04-20=0A=0AAccording to the current Mobi= le IPv6 specification, a mobile node may=0Ahave several care-of addresses, = but only one, called the primary=0Acare-of address, that can be registered = with its home agent and the=0Acorrespondent nodes.=A0 However, for matters = of cost, bandwidth, delay,=0Aetc, it is useful for the mobile node to get I= nternet access through=0Amultiple accesses simultaneously, in which case th= e mobile node would=0Abe configured with multiple active IPv6 care-of addre= sses.=A0 This=0Adocument proposes extensions to the Mobile IPv6 protocol to= register=0Aand use multiple care-of addresses.=A0 The extensions proposed = in this=0Adocument can be used by Mobile Routers using the NEMO (Network=0A= Mobility) Basic Support protocol as well.=0A=0AA URL for this Internet-Draf= t is:=0Ahttp://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-= 13.txt=0A=0AInternet-Drafts are also available by anonymous FTP at:=0Aftp:/= /ftp.ietf.org/internet-drafts/=0A=0ABelow is the data which will enable a M= IME compliant mail reader=0Aimplementation to automatically retrieve the AS= CII version of the=0AInternet-Draft.=0A=0A=0A --0-1771764853-1240330692=:85927 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Marcelo,
=0A
  Do you consider the is= sue raised on the prefixes which affects Figures 1, 2 and 3 and possibly so= me other text closed?
=0A
  If yes, how is it closed? I for o= ne is still confused especially with George's reply that talks about virtua= l interfaces.
=0A
  Also I have a question to Ryuji: does thi= s draft send a non-deregistration BU at the home link? If yes, is he famili= ar with the discussion going on on this subject? This is another point of c= onfusion for me.
=0A
  Sorry if I am too  much confused =
Please don'= t get me wrong, I am not trying to slow down the progress of this document.=
=0A
 
=0A
Regards,
=0A
 =0A
Behcet
=0A
=0A
=0AFrom: marcelo bagnu= lo braun <marcelo@it.uc3m.es>
To: mext <mext@ietf.org>; Julien Laganier <julien.laga= nier.ietf@googlemail.com>; Jari Arkko <jari.arkko@piuha.net>
Sent: Tuesday, April 21, 2009= 11:03:05 AM
Subject: [M= EXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

= We have this new version of the MCOA document that addresses the comments r= eceived, including IESG review comments.
To the best of my knowledge, th= e IESG is ok with the doc and ready for publication.
I am planning to as= k our AD to move forward in a week or so, so, if you have comments on the d= ocument please provide them before the 1st of may.

Regards, marcelo<= BR>(mcoa doc shepherd)

-------- Mensaje original --------
Asunto:     [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt=
Fecha:     Mon, 20 Apr 2009 08:30:01 -0700 (PDT)
De: =     Internet-Drafts@ietf.org
Para:  = ;   i-d-announce@ietf.org
CC:     mext@ietf.o= rg



A New Internet-Draft is available from the on-line In= ternet-Drafts directories.
This draft is a work item of the Mobility EXT= ensions for IPv6 Working Group of the IETF.


    T= itle          : Multiple Care-of Addresses Registr= ation
    Author(s)      : R. Wakikawa, et= al.
    Filename        : draft-ietf-monami6-multiplecoa-13.txt
    Pages  &n= bsp;       : 44
    Date    &nbs= p;       : 2009-04-20

According to the current Mobile= IPv6 specification, a mobile node may
have several care-of addresses, b= ut only one, called the primary
care-of address, that can be registered = with its home agent and the
correspondent nodes.  However, for matt= ers of cost, bandwidth, delay,
etc, it is useful for the mobile node to = get Internet access through
multiple accesses simultaneously, in which c= ase the mobile node would
be configured with multiple active IPv6 care-o= f addresses.  This
document proposes extensions to the Mobile IPv6 = protocol to register
and use multiple care-of addresses.  The exten= sions proposed in this
document can be used by Mobile Routers using the = NEMO (Network
Mobility) Basic Support protocol as well.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/dra= ft-ietf-monami6-multiplecoa-13.txt

Internet-Drafts are also availabl= e by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the = data which will enable a MIME compliant mail reader
implementation to au= tomatically retrieve the ASCII version of the
Internet-Draft.


=0A=0A --0-1771764853-1240330692=:85927-- From ryuji.wakikawa@gmail.com Tue Apr 21 10:02:03 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6893A68CD for ; Tue, 21 Apr 2009 10:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 sfdFxeCSpWWH for ; Tue, 21 Apr 2009 10:02:02 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id 3D76A3A684C for ; Tue, 21 Apr 2009 10:02:02 -0700 (PDT) Received: by qyk42 with SMTP id 42so3534915qyk.29 for ; Tue, 21 Apr 2009 10:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=QbnBwHQJHb5bCUFvQPF1czFTxkWNcMcYUJ0P1u5kBMM=; b=uMS1a1KabBDZJxfeXm7zTBf7XYcqoaqv9hhTHk3oi9c5jlhk1UqGJkpW+2W+zb6DfE VPgLRdlnHTQTERmcwBN9Fm88DuPTLr28yrb7ZdecSUIs8JKZKL/Uw/cxhdVR50FA1JiP hPSgcjycZ5Hjuh04+ZWMRTte0hr3ME1ol5tkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=erwJj1Q3tSgwOLM/EBU1rJJTvwOAAExB7WQFms8j4XQHeefdbEZwbdBtLDWlHHYWGt rvYRIfqfJtlIs0KIzlrNm1WwCuau/1qAHEnVBUw8ebA+rUNM7iFgxs/K3pDN7h0h9s5z ZiPk3/KYrRV2yho5wdfNP7coNtrE60sXGxHlc= Received: by 10.229.81.139 with SMTP id x11mr1244346qck.14.1240333381419; Tue, 21 Apr 2009 10:03:01 -0700 (PDT) Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id 9sm11070ywf.56.2009.04.21.10.02.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Apr 2009 10:03:00 -0700 (PDT) From: Ryuji Wakikawa To: Behcet Sarikaya In-Reply-To: <307819.85927.qm@web111409.mail.gq1.yahoo.com> References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 13:02:56 -0400 X-Mailer: Apple Mail (2.930.3) Cc: Jari Arkko , Julien Laganier , mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 17:02:03 -0000 Hi Behcet, On 2009/04/21, at 12:18, Behcet Sarikaya wrote: > Hi Marcelo, > Do you consider the issue raised on the prefixes which affects > Figures 1, 2 and 3 and possibly some other text closed? > If yes, how is it closed? I for one is still confused especially > with George's reply that talks about virtual interfaces. I don't get your point. This document is about binding a home address to multiple CoAs. Why you bring up with prefix here. I think you are confused something. > Also I have a question to Ryuji: does this draft send a non- > deregistration BU at the home link? If yes, is he familiar with the > discussion going on on this subject? This is another point of > confusion for me. This has been discussed for a long time in MEXT. who is familiar with which discussions? I don't know your concern here. > Sorry if I am too much confused > Please don't get me wrong, I am not trying to slow down the progress > of this document. sure, but please explain your issue more precisely. thanks! ryuji > > Regards, > > Behcet > From: marcelo bagnulo braun > To: mext ; Julien Laganier >; Jari Arkko > Sent: Tuesday, April 21, 2009 11:03:05 AM > Subject: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > We have this new version of the MCOA document that addresses the > comments received, including IESG review comments. > To the best of my knowledge, the IESG is ok with the doc and ready > for publication. > I am planning to ask our AD to move forward in a week or so, so, if > you have comments on the document please provide them before the 1st > of may. > > Regards, marcelo > (mcoa doc shepherd) > > -------- Mensaje original -------- > Asunto: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt > Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) > De: Internet-Drafts@ietf.org > Para: i-d-announce@ietf.org > CC: mext@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobility EXTensions for IPv6 > Working Group of the IETF. > > > Title : Multiple Care-of Addresses Registration > Author(s) : R. Wakikawa, et al. > Filename : draft-ietf-monami6-multiplecoa-13.txt > Pages : 44 > Date : 2009-04-20 > > According to the current Mobile IPv6 specification, a mobile node may > have several care-of addresses, but only one, called the primary > care-of address, that can be registered with its home agent and the > correspondent nodes. However, for matters of cost, bandwidth, delay, > etc, it is useful for the mobile node to get Internet access through > multiple accesses simultaneously, in which case the mobile node would > be configured with multiple active IPv6 care-of addresses. This > document proposes extensions to the Mobile IPv6 protocol to register > and use multiple care-of addresses. The extensions proposed in this > document can be used by Mobile Routers using the NEMO (Network > Mobility) Basic Support protocol as well. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.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. > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From behcetsarikaya@yahoo.com Tue Apr 21 11:42:00 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66DD3A68A7 for ; Tue, 21 Apr 2009 11:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 K3mHX7DzkOaP for ; Tue, 21 Apr 2009 11:41:59 -0700 (PDT) Received: from n57.bullet.mail.sp1.yahoo.com (n57.bullet.mail.sp1.yahoo.com [98.136.44.49]) by core3.amsl.com (Postfix) with SMTP id 634383A6FD0 for ; Tue, 21 Apr 2009 11:41:59 -0700 (PDT) Received: from [216.252.122.216] by n57.bullet.mail.sp1.yahoo.com with NNFMP; 21 Apr 2009 18:43:16 -0000 Received: from [67.195.9.83] by t1.bullet.sp1.yahoo.com with NNFMP; 21 Apr 2009 18:43:16 -0000 Received: from [67.195.9.110] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 21 Apr 2009 18:43:15 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 21 Apr 2009 18:41:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 512225.97652.bm@omp114.mail.gq1.yahoo.com Received: (qmail 47683 invoked by uid 60001); 21 Apr 2009 18:43:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240339395; bh=lrzhoBSxJDH589SyyRJ48XTR5/RuHwMDVeBKZbrk6zY=; 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=CcxUCUUszsoxotI/+LhJmM3am9lVdqtODTvijIwjuQtR/dBuEM5r193qLJmdY1LmSnuVD96RMSeK8+A3yt5Yjz7C2SEEAfvPEVhMCPPHHHd756Vrj4x+U6L5Yt7K5VE/HsxwuAgFkSoKyodJkLrk7zNsvlXvtPrt0x4a06dbgw8= 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=n3NKvMRjYChUjwVHDc+QCotmozbaEWRvVR4N2dba6RenZkZLbBStCKmh+Qvqy5p4wlmqZsisx8/d2XOa8Z9fQf/2NK4HeSiels4wG5YkKXNJDjy5RpUlHNZLOD/OX96CaLh1mGzXlLKP6myfXoC/LF6iajdEsFb4kmJPnPPcoj8=; Message-ID: <729718.46356.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: 6b.jyKUVM1kxTBjXI.dQEJYZcRuJNOpaPJTrahfKvOKFBpVgqFc3Iun8AMVpLNKTaMYgxaT9GLlkzf67a._p_eOdxbmUcLQF.BUpBQOQCFM6f88IykW1hzLsmv6e7M7bMG6L_iTcaY4g4rcRBnNNMG7lMLkPmiPSI.gasryFpQzfGs0L4AzxfJL1.EhKFwPxnFv2HmtyvwXCkRzRsQAqzBtHcx_jQ.jBwfKuEeP0LLueQlRK48W_tZcXrNCSISdzYVl_AwC2xx1wm5bijFpSt5YBOelKQSVaIvWtI1izkJUE63C5LOS8oge3Q6YAj3Z6tM2v Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Tue, 21 Apr 2009 11:43:15 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> Date: Tue, 21 Apr 2009 11:43:15 -0700 (PDT) From: Behcet Sarikaya To: Ryuji Wakikawa In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1290920086-1240339395=:46356" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 18:42:00 -0000 --0-1290920086-1240339395=:46356 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ryuji,=0A=0A=A0 Please see inline.=0A=0ARegards,=0A=0ABehcet=0A=0A______= __________________________=0A=0AFrom: Ryuji Wakikawa =0ATo: Behcet Sarikaya =0ACc: marcelo bagnulo braun = ; mext ; Julien Laganier ; Jari Arkko =0ASent: Tuesday, = April 21, 2009 12:02:56 PM=0ASubject: Re: [MEXT] [Fwd: I-D Action:draft-iet= f-monami6-multiplecoa-13.txt]=0A=0A=0A[behcet] Yes but each interface will = appear to HA as a different device and HA needs to assign a different HoA. = Then MCoA problem disappears.=0ASo George is saying that this is avoided by= some virtual interfaces so that HA does not see each interface separately.= =0AIs this explained anywhere in the draft?=0AIf yes then I am OK.=0A>=A0 = Also I have a question to Ryuji: does this draft send a non-deregistration = BU at the home link? If yes, is he familiar with the discussion going on on= this subject? This is another point of confusion for me.=0A=0AThis has bee= n discussed for a long time in MEXT.=0Awho is familiar with which discussio= ns? I don't know your concern here.=0A=0A=0A[behcet] So your answer is yes = the draft sends a non-deregistration BU (kind of bulk registration) at the = home link.=0AThe discussion I mentioned was related to draft-premec-mext-ex= tended-home-link. This draft also sends non-deregistration BU at the home l= ink. So does a few more drafts likedraft-devarapalli-mext-mipv6-home-link.= =0A=A0=0A[behcet] You mentioned some bit is set but I could not understand = which. One idea is since so many drafts need this, why not factor this out = and define whatever the mechanism to enable sending non-deregistration BU i= n 3775bis. What do you think about that?=0A=A0>=A0 Sorry if I am too=A0 muc= h confused=0A> Please don't get me wrong, I am not trying to slow down the = progress of this document.=0A=0Asure, but please explain your issue more pr= ecisely.=0A=0Athanks!=0Aryuji=0A=0A> =0A> Regards,=0A> =0A> Behcet=0A> From= : marcelo bagnulo braun =0A> To: mext ; = Julien Laganier ; Jari Arkko =0A> Sent: Tuesday, April 21, 2009 11:03:05 AM=0A> Subject: [M= EXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> =0A> We ha= ve this new version of the MCOA document that addresses the comments receiv= ed, including IESG review comments.=0A> To the best of my knowledge, the IE= SG is ok with the doc and ready for publication.=0A> I am planning to ask o= ur AD to move forward in a week or so, so, if you have comments on the docu= ment please provide them before the 1st of may.=0A> =0A> Regards, marcelo= =0A> (mcoa doc shepherd)=0A> =0A> -------- Mensaje original --------=0A> As= unto:=A0 =A0 [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt=0A> Fe= cha:=A0 =A0 Mon, 20 Apr 2009 08:30:01 -0700 (PDT)=0A> De:=A0 =A0 Internet-D= rafts@ietf.org=0A> Para:=A0 =A0 i-d-announce@ietf.org=0A> CC:=A0 =A0 mext@i= etf.org=0A> =0A> =0A> =0A> A New Internet-Draft is available from the on-li= ne Internet-Drafts directories.=0A> This draft is a work item of the Mobili= ty EXTensions for IPv6 Working Group of the IETF.=0A> =0A> =0A>=A0 =A0 Titl= e=A0 =A0 =A0 =A0 =A0 : Multiple Care-of Addresses Registration=0A>=A0 =A0 A= uthor(s)=A0 =A0 =A0 : R. Wakikawa, et al.=0A>=A0 =A0 Filename=A0 =A0 =A0 = =A0 : draft-ietf-monami6-multiplecoa-13.txt=0A>=A0 =A0 Pages=A0 =A0 =A0 =A0= =A0 : 44=0A>=A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2009-04-20=0A> =0A> Acco= rding to the current Mobile IPv6 specification, a mobile node may=0A> have = several care-of addresses, but only one, called the primary=0A> care-of add= ress, that can be registered with its home agent and the=0A> correspondent = nodes.=A0 However, for matters of cost, bandwidth, delay,=0A> etc, it is us= eful for the mobile node to get Internet access through=0A> multiple access= es simultaneously, in which case the mobile node would=0A> be configured wi= th multiple active IPv6 care-of addresses.=A0 This=0A> document proposes ex= tensions to the Mobile IPv6 protocol to register=0A> and use multiple care-= of addresses.=A0 The extensions proposed in this=0A> document can be used b= y Mobile Routers using the NEMO (Network=0A> Mobility) Basic Support protoc= ol as well.=0A> =0A> A URL for this Internet-Draft is:=0A> http://www.ietf.= org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt=0A> =0A> Internet= -Drafts are also available by anonymous FTP at:=0A> ftp://ftp.ietf.org/inte= rnet-drafts/=0A> =0A> Below is the data which will enable a MIME compliant = mail reader=0A> implementation to automatically retrieve the ASCII version = of the=0A> Internet-Draft.=0A> =0A> =0A> =0A> _____________________________= __________________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.= ietf.org/mailman/listinfo/mext=0A=0A=0A=0AHi Behcet,=0A=0AOn 2009/04/21, at= 12:18, Behcet Sarikaya wrote:=0A=0A> Hi Marcelo,=0A>=A0 Do you consider th= e issue raised on the prefixes which affects Figures 1, 2 and 3 and possibl= y some other text closed?=0A>=A0 If yes, how is it closed? I for one is sti= ll confused especially with George's reply that talks about virtual interfa= ces.=0A=0AI don't get your point. This document is about binding a home add= ress to multiple CoAs.=0AWhy you bring up with prefix here.=0AI think you a= re confused something.=0A=0A=0A=0A --0-1290920086-1240339395=:46356 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ryuji,
=0A
  Please see inli= ne.
=0A
 
=0A
Regards,
=0A
=  
=0A
Behcet
=0A=0A=
=0A
=0A
From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>Cc: marcelo bagnulo braun = <marcelo@it.uc3m.es>; mext <mext@ietf.org>; Julien Laganier <= ;julien.laganier.ietf@googlemail.com>; Jari Arkko <jari.arkko@piuha.n= et>
Sent: Tuesday, Ap= ril 21, 2009 12:02:56 PM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt= ]

Hi Behcet,

On 2009/04/21, at 12:18, Behcet Sarikaya = wrote:

> Hi Marcelo,
>  Do you consider the issue rais= ed on the prefixes which affects Figures 1, 2 and 3 and possibly some other= text closed?
>  If yes, how is it closed? I for one is still confused especially with George'= s reply that talks about virtual interfaces.

I don't get your point.= This document is about binding a home address to multiple CoAs.
Why you= bring up with prefix here.
I think you are confused something.
=0A
 
=0A
[behcet] Yes but each interf= ace will appear to HA as a different device and HA needs to assign a differ= ent HoA. Then MCoA problem disappears.
=0A
So George is saying that this is avoided by some virtual= interfaces so that HA does not see each interface separately.
=0A
Is this explained anywhere in the= draft?
=0A
If yes then I = am OK.
>  Also I have a question to Ryuji: does = this draft send a non-deregistration BU at the home link? If yes, is he fam= iliar with the discussion going on on this subject? This is another point o= f confusion for me.

This has been discussed for a long time in MEXT.=
who is familiar with which discussions? I don't know your concern here.=
=0A
 
=0A
[behcet] So your an= swer is yes the draft sends a non-deregistration BU (kind of bulk registrat= ion) at the home link.
=0A
The discussion I mentioned was related to draft-premec-mext-extended-home-link. This draft also sends non-deregistration= BU at the home link. So does a few more drafts like = draft-devarapalli-mext= -mipv6-home-link.
=0A

=  

=0A

[behcet] You mentioned some bit is set but I could not understand whi= ch. One idea is since so many drafts need this, why not factor this out and= define whatever the mechanism to enable sending non-deregistration BU in 3= 775bis. What do you think about that?

=0A

 

=0A>  Sorry if I am too  much confused
> Please don= 't get me wrong, I am not trying to slow down the progress of this document= ..

sure, but please explain your issue more precisely.

thanks!=
ryuji

>
> Regards,
>
> Behcet
> Fro= m: marcelo bagnulo braun <marcelo@it.uc3m.es>
> To: mext = <mext@= ietf.org>; Julien Laganier <ju= lien.laganier.ietf@googlemail.com>; Jari Arkko <jari.arkko@p= iuha.net>
> Sent: Tuesday, April 21, 2009 11:03:05 AM
> = Subject: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
> > We have this new version of the MCOA document that addresses the comm= ents received, including IESG review comments.
> To the best of my kn= owledge, the IESG is ok with the doc and ready for publication.
> I a= m planning to ask our AD to move forward in a week or so, so, if you have c= omments on the document please provide them before the 1st of may.
> =
> Regards, marcelo
> (mcoa doc shepherd)
>
> ----= ---- Mensaje original --------
> Asunto:    [MEXT] I-D Acti= on:draft-ietf-monami6-multiplecoa-13.txt
> Fecha:    Mon, 2= 0 Apr 2009 08:30:01 -0700 (PDT)
> De:    Inter= net-Drafts@ietf.org
> Para:    i-d-announce@ietf.org
>= CC:    mext@ietf.org
>
>
>
> A New Interne= t-Draft is available from the on-line Internet-Drafts directories.
> = This draft is a work item of the Mobility EXTensions for IPv6 Working Group= of the IETF.
>
>
>    Title    &nb= sp;     : Multiple Care-of Addresses Registration
>  &= nbsp; Author(s)      : R. Wakikawa, et al.
>  &nb= sp; Filename        : draft-ietf-monami6-multiplecoa-13= ..txt
>    Pages          : 44
&= gt;    Date            : 2009-04-20=
>
> According to the current Mobile IPv6 specification, a mob= ile node may
> have several care-of addresses, but only one, called the primary
> care-of address, that can be registered with its home = agent and the
> correspondent nodes.  However, for matters of co= st, bandwidth, delay,
> etc, it is useful for the mobile node to get = Internet access through
> multiple accesses simultaneously, in which = case the mobile node would
> be configured with multiple active IPv6 = care-of addresses.  This
> document proposes extensions to the M= obile IPv6 protocol to register
> and use multiple care-of addresses.=   The extensions proposed in this
> document can be used by Mobi= le Routers using the NEMO (Network
> Mobility) Basic Support protocol= as well.
>
> A URL for this Internet-Draft is:
> http:/= /www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt
>=
> Internet-Drafts are also available by anonymous FTP at:
> <= A href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D_blank>ftp://ftp.ietf.org/internet-drafts/
>
> B= elow is the data which will enable a MIME compliant mail reader
> imp= lementation to automatically retrieve the ASCII version of the
> Inte= rnet-Draft.
>
>
>
> ____________________________= ___________________
> MEXT mailing list
> MEXT@ietf.org
> https://= www.ietf.org/mailman/listinfo/mext


=0A=0A <= /body> --0-1290920086-1240339395=:46356-- From vijay@wichorus.com Tue Apr 21 11:57:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9263A28C2BD for ; Tue, 21 Apr 2009 11:57:17 -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 nmbsMYS1h-0F for ; Tue, 21 Apr 2009 11:57:16 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id DDEC728C111 for ; Tue, 21 Apr 2009 11:57:13 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA06.westchester.pa.mail.comcast.net with comcast id iCkT1b0030cZkys56JxlGJ; Tue, 21 Apr 2009 18:57:45 +0000 Received: from [10.166.254.159] ([38.104.122.206]) by OMTA10.westchester.pa.mail.comcast.net with comcast id iJyC1b0084THdvq3WJyJek; Tue, 21 Apr 2009 18:58:27 +0000 Message-ID: <49EE173F.2090800@wichorus.com> Date: Tue, 21 Apr 2009 11:58:07 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Behcet Sarikaya References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> In-Reply-To: <729718.46356.qm@web111410.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 18:57:17 -0000 Behcet, Behcet Sarikaya wrote: > *[behcet] Yes but each interface will appear to HA as a different device > and HA needs to assign a different HoA. Then MCoA problem disappears.* > *So George is saying that this is avoided by some virtual interfaces so > that HA does not see each interface separately. * > *Is this explained anywhere in the draft?* > *If yes then I am OK.* The home agent does not care about the multiple interfaces on the mobile node. It only sees the mobile node as one entity and allocates a home address to it. The multiple care-of addresses that the mobile node has will be used by the home agent as tunnel end points. That is all. So there is no issue. Vijay > > Also I have a question to Ryuji: does this draft send a > non-deregistration BU at the home link? If yes, is he familiar with the > discussion going on on this subject? This is another point of confusion > for me. > > This has been discussed for a long time in MEXT. > who is familiar with which discussions? I don't know your concern here. > > *[behcet] So your answer is yes the draft sends a non-deregistration BU > (kind of bulk registration) at the home link.* > *The discussion I mentioned was related to > draft-premec-mext-extended-home-link. This draft also sends > non-deregistration BU at the home link. So does a few more drafts like > **draft-devarapalli-mext-mipv6-home-link.* > > ** > > *[behcet] You mentioned some bit is set but I could not understand > which. One idea is since so many drafts need this, why not factor this > out and define whatever the mechanism to enable sending > non-deregistration BU in 3775bis. What do you think about that?* > > ** > > > > Sorry if I am too much confused > > Please don't get me wrong, I am not trying to slow down the progress > of this document.. > > sure, but please explain your issue more precisely. > > thanks! > ryuji > > > > > Regards, > > > > Behcet > > From: marcelo bagnulo braun > > > To: mext >; Julien Laganier > >; Jari Arkko > > > > Sent: Tuesday, April 21, 2009 11:03:05 AM > > Subject: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] > > > > We have this new version of the MCOA document that addresses the > comments received, including IESG review comments. > > To the best of my knowledge, the IESG is ok with the doc and ready > for publication. > > I am planning to ask our AD to move forward in a week or so, so, if > you have comments on the document please provide them before the 1st of may. > > > > Regards, marcelo > > (mcoa doc shepherd) > > > > -------- Mensaje original -------- > > Asunto: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt > > Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) > > De: Internet-Drafts@ietf.org > > Para: i-d-announce@ietf.org > > CC: mext@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Mobility EXTensions for IPv6 Working > Group of the IETF. > > > > > > Title : Multiple Care-of Addresses Registration > > Author(s) : R. Wakikawa, et al. > > Filename : draft-ietf-monami6-multiplecoa-13..txt > > Pages : 44 > > Date : 2009-04-20 > > > > According to the current Mobile IPv6 specification, a mobile node may > > have several care-of addresses, but only one, called the primary > > care-of address, that can be registered with its home agent and the > > correspondent nodes. However, for matters of cost, bandwidth, delay, > > etc, it is useful for the mobile node to get Internet access through > > multiple accesses simultaneously, in which case the mobile node would > > be configured with multiple active IPv6 care-of addresses. This > > document proposes extensions to the Mobile IPv6 protocol to register > > and use multiple care-of addresses. The extensions proposed in this > > document can be used by Mobile Routers using the NEMO (Network > > Mobility) Basic Support protocol as well. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.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. > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From behcetsarikaya@yahoo.com Tue Apr 21 12:03:08 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECAD43A68C2 for ; Tue, 21 Apr 2009 12:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=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 CnBrnSGLj7R2 for ; Tue, 21 Apr 2009 12:03:07 -0700 (PDT) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id A430028C309 for ; Tue, 21 Apr 2009 12:03:07 -0700 (PDT) Received: (qmail 76410 invoked by uid 60001); 21 Apr 2009 19:04:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240340664; bh=MOmFopXquhI2GWH+8ovSqGBV8FX7bVeWu8CbAr9bUq4=; 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=F3mvU08eM7z66yr2o72mKZOjvbpjQfltoF5VNn4OWTx7Sj3gIDN4JHVlY4GBL8A/ep1cBFSI9ADupI64vqc2F6/S9Ig2cO1Lc4UyXH7oEJk7c13PkDisxVEGgUrn/MGlzl6WWG5JlJoKya3ZhPfnmwi7UCjGSnuFfen+Nqr4Fyw= 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=ZGP1wKTgqqy3iDBhCGHECAdaucl3OF6BCjiJsCDMqNsnAsW1dcdbc9VrieEKxjMjZh8BWOIeLs5OasJsMjzqLb1DCo6ueWPmdB0BmKXvPXtYJB+oue/wokEDGpwPgXgLgKxXiGwgY2OznVYD9qHuwCEARE7EaHzLEz3NF2EKxYY=; Message-ID: <431126.68078.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: PC2p0uMVM1m_U3xUwfknieVXy1VTLPfj_p5591hAuBwC40lxsiw_C49ylaRhtfX7yR.2iRjmCsknknrLM6gciOlPbxHaaiMA9Aq8KqR8dMI5qowXhGFqZZW4Jb25q7uzBp_ZbQU8QHdzvPXBfyy1uCx5iWX.qxASVjS1DrDRs56.TvpNa3K2vwZHmliFTmn.P04NCeIEe0pF59UUZqKjVMJfnQWZGsPar5sBZvlN.I1ERYY.7Nu5YI9nmrGLW1bM4YvRoWohGdgHhFTDrnDHZpWf0rZ5oRx0jlSm_5Mu1TfM.EB6oChLbMfMbmX8ov.n5P8k Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Tue, 21 Apr 2009 12:04:24 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> Date: Tue, 21 Apr 2009 12:04:24 -0700 (PDT) From: Behcet Sarikaya To: Vijay Devarapalli In-Reply-To: <49EE173F.2090800@wichorus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2051789051-1240340664=:68078" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 19:03:09 -0000 --0-2051789051-1240340664=:68078 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So you are saying that there could be a single HA?=0A=0ARegards,=0A=0ABehce= t=0A=0A=0A=0A=0A________________________________=0AFrom: Vijay Devarapalli = =0ATo: Behcet Sarikaya =0ACc: Ryuji = Wakikawa ; mext =0ASent: Tuesday, = April 21, 2009 1:58:07 PM=0ASubject: Re: [MEXT] [Fwd: I-D Action:draft-ietf= -monami6-multiplecoa-13.txt]=0A=0ABehcet,=0A=0ABehcet Sarikaya wrote:=0A> *= [behcet] Yes but each interface will appear to HA as a different device and= HA needs to assign a different HoA. Then MCoA problem disappears.*=0A> *So= George is saying that this is avoided by some virtual interfaces so that H= A does not see each interface separately. *=0A> *Is this explained anywhere= in the draft?*=0A> *If yes then I am OK.*=0A=0AThe home agent does not car= e about the multiple interfaces on the mobile node. It only sees the mobile= node as one entity and allocates a home address to it. The multiple care-o= f addresses that the mobile node has will be used by the home agent as tunn= el end points. That is all. So there is no issue.=0A=0AVijay=0A=0A>=A0 >=A0= Also I have a question to Ryuji: does this draft send a non-deregistration= BU at the home link? If yes, is he familiar with the discussion going on o= n this subject? This is another point of confusion for me.=0A> =0A> This ha= s been discussed for a long time in MEXT.=0A> who is familiar with which di= scussions? I don't know your concern here.=0A>=A0 *[behcet] So your answer = is yes the draft sends a non-deregistration BU (kind of bulk registration) = at the home link.*=0A> *The discussion I mentioned was related to draft-pre= mec-mext-extended-home-link. This draft also sends non-deregistration BU at= the home link. So does a few more drafts like **draft-devarapalli-mext-mip= v6-home-link.*=0A> =0A> ** =0A> *[behcet] You mentioned some bit is set but= I could not understand which. One idea is since so many drafts need this, = why not factor this out and define whatever the mechanism to enable sending= non-deregistration BU in 3775bis. What do you think about that?*=0A> =0A> = ** =0A> =0A>=A0 >=A0 Sorry if I am too=A0 much confused=0A>=A0 > Please don= 't get me wrong, I am not trying to slow down the progress of this document= ..=0A> =0A> sure, but please explain your issue more precisely.=0A> =0A> th= anks!=0A> ryuji=0A> =0A>=A0 >=0A>=A0 > Regards,=0A>=A0 >=0A>=A0 > Behcet=0A= >=A0 > From: marcelo bagnulo braun >=0A>=A0 > To: mext >; Julien L= aganier >; Jari Arkko >=0A>=A0 > Sent: Tuesday, April 21, 2009 11:03:05 AM=0A>=A0 > Subject: = [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A>=A0 >=0A>= =A0 > We have this new version of the MCOA document that addresses the comm= ents received, including IESG review comments.=0A>=A0 > To the best of my k= nowledge, the IESG is ok with the doc and ready for publication.=0A>=A0 > I= am planning to ask our AD to move forward in a week or so, so, if you have= comments on the document please provide them before the 1st of may.=0A>=A0= >=0A>=A0 > Regards, marcelo=0A>=A0 > (mcoa doc shepherd)=0A>=A0 >=0A>=A0 >= -------- Mensaje original --------=0A>=A0 > Asunto:=A0 =A0 [MEXT] I-D Acti= on:draft-ietf-monami6-multiplecoa-13.txt=0A>=A0 > Fecha:=A0 =A0 Mon, 20 Apr= 2009 08:30:01 -0700 (PDT)=0A>=A0 > De:=A0 =A0 Internet-Drafts@ietf.org =0A>=A0 > Para:=A0 =A0 i-d-announce@ietf.org = =0A>=A0 > CC:=A0 =A0 mext@ietf.org =0A>=A0 >=0A>=A0 >=0A>=A0 >=0A>=A0 > A New Internet-Draft is av= ailable from the on-line Internet-Drafts directories.=0A>=A0 > This draft i= s a work item of the Mobility EXTensions for IPv6 Working Group of the IETF= .=0A>=A0 >=0A>=A0 >=0A>=A0 >=A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : Multiple Car= e-of Addresses Registration=0A>=A0 >=A0 =A0 Author(s)=A0 =A0 =A0 : R. Wakik= awa, et al.=0A>=A0 >=A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-monami6-mu= ltiplecoa-13..txt=0A>=A0 >=A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 : 44=0A>=A0 >=A0= =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2009-04-20=0A>=A0 >=0A>=A0 > According t= o the current Mobile IPv6 specification, a mobile node may=0A>=A0 > have se= veral care-of addresses, but only one, called the primary=0A>=A0 > care-of = address, that can be registered with its home agent and the=0A>=A0 > corres= pondent nodes.=A0 However, for matters of cost, bandwidth, delay,=0A>=A0 > = etc, it is useful for the mobile node to get Internet access through=0A>=A0= > multiple accesses simultaneously, in which case the mobile node would=0A= >=A0 > be configured with multiple active IPv6 care-of addresses.=A0 This= =0A>=A0 > document proposes extensions to the Mobile IPv6 protocol to regis= ter=0A>=A0 > and use multiple care-of addresses.=A0 The extensions proposed= in this=0A>=A0 > document can be used by Mobile Routers using the NEMO (Ne= twork=0A>=A0 > Mobility) Basic Support protocol as well.=0A>=A0 >=0A>=A0 > = A URL for this Internet-Draft is:=0A>=A0 > http://www.ietf.org/internet-dra= fts/draft-ietf-monami6-multiplecoa-13.txt=0A>=A0 >=0A>=A0 > Internet-Drafts= are also available by anonymous FTP at:=0A>=A0 > ftp://ftp.ietf.org/intern= et-drafts/=0A>=A0 >=0A>=A0 > Below is the data which will enable a MIME com= pliant mail reader=0A>=A0 > implementation to automatically retrieve the AS= CII version of the=0A>=A0 > Internet-Draft.=0A>=A0 >=0A>=A0 >=0A>=A0 >=0A>= =A0 > _______________________________________________=0A>=A0 > MEXT mailing= list=0A>=A0 > MEXT@ietf.org =0A>=A0 > https://www.ie= tf.org/mailman/listinfo/mext=0A> =0A> =0A> =0A> ---------------------------= ---------------------------------------------=0A> =0A> ____________________= ___________________________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> htt= ps://www.ietf.org/mailman/listinfo/mext=0A=0A=0A --0-2051789051-1240340664=:68078 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=0A=0A --0-65840825-1240411767=:35111-- From behcetsarikaya@yahoo.com Wed Apr 22 07:57:58 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BECA28C123 for ; Wed, 22 Apr 2009 07:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_00=-2.599, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 4QoVA1wo-1UA for ; Wed, 22 Apr 2009 07:57:57 -0700 (PDT) Received: from n10.bullet.re3.yahoo.com (n10.bullet.re3.yahoo.com [68.142.237.123]) by core3.amsl.com (Postfix) with SMTP id 2A6C028C0F0 for ; Wed, 22 Apr 2009 07:57:57 -0700 (PDT) Received: from [68.142.237.90] by n10.bullet.re3.yahoo.com with NNFMP; 22 Apr 2009 14:59:14 -0000 Received: from [67.195.9.81] by t6.bullet.re3.yahoo.com with NNFMP; 22 Apr 2009 14:59:14 -0000 Received: from [67.195.9.106] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 14:59:14 -0000 Received: from [127.0.0.1] by omp110.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 14:57:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 610263.85726.bm@omp110.mail.gq1.yahoo.com Received: (qmail 40888 invoked by uid 60001); 22 Apr 2009 14:59:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240412353; bh=TBkyIV1ZMIjGJle90ubAoHJRulS9dRFSafwrseEvPmc=; 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=kfh6Rva0Nglkv4ihvf3Nlvvw1DhoRkYhdB82am/qDlPSIPzVH5z2ymISm0fXKRSaaXOLbFb9AZoYgsSW/0OVJUhdXzVKcgniVPrePIjedDe6jysr2090LQslpP0tydNT/tJvd+fWQKANnh88l8j4qtLsPyOzVkKk/9GezKe7jZs= 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=A/0NssgG0uDhKsxSoJklexQ9wbzSqZa+z1ju1zLjQIRxTVhDzakhb50LAfdWMxoHfxPClxQRWU7hsSXMQ6dsfesLSr9tQHJTkfqtsMZSuH5k2UftDf3bVu6T0NiTF+BsAdWbUCdF7jy/uAUGSm69Kwusx9ITrNezbKcAElTTpRs=; Message-ID: <869311.39916.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: nVNhLaUVM1kGuHOOzOSNtmTj9EnK6Un1WuJm.5A0bHsn_8B4x9BABu5uUL_Ck1JJ3Y204ltpTOGrDzSj93F3bKORQqsdHZl8F6mQVwPyH.RWYFazIskz5piUN8a39e.0sAmZySmpjMXd5ibLbUSILC.J0uZUoXIPM7GxhV.RMZs7gOcjyZtaJosaSNLYzCj.TlYYadnI6apgfJUIdP2CBIqNmCs0twzRM2MVA3MlY3qREnYm4_TVckX2eGSeMHp_iDxfbON7flWp3bejRqimvC2wSTG11CFV8TdMewCx_MrUT2HAsaAVYA_t53T20m5X.6Zr1GHw4cs- Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Wed, 22 Apr 2009 07:59:13 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> Date: Wed, 22 Apr 2009 07:59:13 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1826846370-1240412353=:39916" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 14:57:58 -0000 --0-1826846370-1240412353=:39916 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi George,=0A=A0 It seems like now you are telling the truth =0ABasically M= CoA draft wishes to establish some hierarchy of the interfaces. There is on= e which is the main interface (Vijay calls this main entity but as we ALL k= now addresses as Layer 3 identities=A0are assigned to the interfaces not th= e the entities). There are other interfaces=A0which are the lowest level in= terfaces.=0AMN does INE using the main interface. Uses IKEv2 and gets HoA a= ssigned establishes secure tunnel with the HA on this interface.=0A=0ASomew= hat magically the lowest level interfaces become active and connect to some= other domains and get CoA1 then MCoA draft kicks in and starts assigning t= hese BIDs.=0A=0AMy suggestion is that the draft should explain this clearly= in textual form.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A____________________= ____________=0AFrom: George Tsirtsis =0ATo: Vijay = Devarapalli =0ACc: Behcet Sarikaya ;= mext =0ASent: Tuesday, April 21, 2009 2:14:55 PM=0ASubject:= Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A=0A..= ..also wrt the home link registration, I do not think what you=0Asuggest is = necessary.=0A=0AAs far as I see the other documents are informational, and = they do not=0Ayet have a formal standing in the WG. If and when they do, as= =0AInformational documents,=A0 they should not require normative changes to= =0Aanything. They should make sure what they describe (mostly=0Aimplementat= ion options in this case) are compatible not only with=0ARFC3775 but also w= ith extensions to it, including Flow Bindings. .=0A=0A=0ARegards=0AGeorge= =0A=0A=0A --0-1826846370-1240412353=:39916 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi George,
=0A
  It seems like now you a= re telling the truth
Basically MCoA draft wishes to establish some hierarchy of the in= terfaces. There is one which is the main interface (Vijay calls this main e= ntity but as we ALL know addresses as Layer 3 identities are assigned = to the interfaces not the the entities). There are other interfaces wh= ich are the lowest level interfaces.
=0A
MN does INE using the mai= n interface. Uses IKEv2 and gets HoA assigned establishes secure tunnel wit= h the HA on this interface.
=0A
 
=0A
Somewhat magic= ally the lowest level interfaces become active and connect to some other do= mains and get CoA1 then MCoA draft kicks in and starts assigning these BIDs= ..
=0A
 
=0A
My suggestion is that the draft should e= xplain this clearly in textual form.
=0A
 
=0A
Regar= ds,
=0A
 
=0A
Behcet
=0A

=0A
=0A
=0AFrom: George Tsirtsis <tsirtsis@googlemail.com>
<= SPAN style=3D"FONT-WEIGHT: bold">To: Vijay Devarapalli <vijay= @wichorus.com>
Cc: Be= hcet Sarikaya <sarikaya@ieee.org>; mext <mext@ietf.org>
<= SPAN style=3D"FONT-WEIGHT: bold">Sent: Tuesday, April 21, 2009 2= :14:55 PM
Subject: Re: [= MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
...also wrt the home link registration, I do not think what you
suggest= is necessary.

As far as I see the other documents are informational= , and they do not
yet have a formal standing in the WG. If and when they= do, as
Informational documents,  they should not require normative= changes to
anything. They should make sure what they describe (mostlyimplementation options in this case) are compatible not only with
RFC3775 but also with extensions to it, includ= ing Flow Bindings. .


Regards
George

=
=0A=0A --0-1826846370-1240412353=:39916-- From behcetsarikaya@yahoo.com Wed Apr 22 08:04:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F94928C184 for ; Wed, 22 Apr 2009 08:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 3McMkeBfQ2dh for ; Wed, 22 Apr 2009 08:04:50 -0700 (PDT) Received: from n2.bullet.mail.re3.yahoo.com (n2.bullet.mail.re3.yahoo.com [68.142.237.109]) by core3.amsl.com (Postfix) with SMTP id 80AD628C1BB for ; Wed, 22 Apr 2009 08:04:50 -0700 (PDT) Received: from [68.142.230.28] by n2.bullet.mail.re3.yahoo.com with NNFMP; 22 Apr 2009 15:06:07 -0000 Received: from [67.195.9.82] by t1.bullet.re2.yahoo.com with NNFMP; 22 Apr 2009 15:06:07 -0000 Received: from [67.195.9.111] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 15:06:07 -0000 Received: from [127.0.0.1] by omp115.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 15:06:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 825747.35619.bm@omp115.mail.gq1.yahoo.com Received: (qmail 92728 invoked by uid 60001); 22 Apr 2009 15:06:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240412767; bh=gcOzrurWAcTKmjPPa5u/fTVaMZU7qIoHSnSfcSSiaG0=; 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=is9UqlaVpKLq23MlPFNLuVLOoweR5wGxiIL+fUAZma/QEuaJXLL1BKkM/kOTOHKNk9Qv+uMx2oOl5swLeBQFMD02z77ECS7/I4TRtRhgZgcjaSLzSxB394o8h5bon8cUxceZe5SK4J5wpStnNpYNxfIdSyFTN5KP/AvnW7EbKBI= 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=xJSglVa65tUAaGmHuhAWoSOiWcPgYeR7spnzyKJbLmRJLjmUNEdSTDMM/Iu7rq8eLJ+tB7636EnxEzZtWppZd/yRx/5HurCEnv2ixwS7gcVIfj+kq/ZuGh0MV8Rna1w0kqlOIjRlTMn6U6cqDIEBUWliCpTGTZQxhwovkwa2DCY=; Message-ID: <61210.92209.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: 7LPKg7UVM1lBTstsbkXhVOdwr0pnP3DRrp4WbyHwAW0kUGyd_SH7fdbCK9_nhhj8NZ9nOjn.IvoWl4mkbthIoBzaYIt7dBJvy7vRLPW_sEOECi2pzTLJgkKAb5OZM6bSGL44W15vGqnUK6xt9smIiPoNE3vgdDTvL0V5YhabqMAnamsVJlBmH0UxJpHzDnVVg0CpBzPf9SSD6xGk0lMb4r.ioNFF.elhR1qYphwepLT80DclosaQ8ijc5vVP7_B3gg6pT11AOdjEjc410Ml4czkadZ5JE1roOwirt0_lECZ2twI.Z5KfxK4njXCAuQQwo4rW Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Wed, 22 Apr 2009 08:06:06 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> Date: Wed, 22 Apr 2009 08:06:06 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2099263579-1240412766=:92209" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 15:04:52 -0000 --0-2099263579-1240412766=:92209 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi George,=0A=A0 It seems in my=A0previous reply I replied to this mail of = yours which was unrelated to the other mail you sent to which I was really = replying, apologies.=0A=A0 Now regarding home link registration, what is th= e mechanism MCoA draft uses? Ryuji mentioned some H bit but I read the draf= t and couldn't confirm it.=0A=0A=A0 My suggestion was building on this, i.e= .. I suggested that whatever you came up with can be moved to 3775bis so tha= t other people would not have to make normative references to your draft.= =0A=0AThat's all.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A_________________= _______________=0AFrom: George Tsirtsis =0ATo: Vij= ay Devarapalli =0ACc: Behcet Sarikaya ; mext =0ASent: Tuesday, April 21, 2009 2:14:55 PM=0ASubje= ct: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A= =0A...also wrt the home link registration, I do not think what you=0Asugges= t is necessary.=0A=0AAs far as I see the other documents are informational,= and they do not=0Ayet have a formal standing in the WG. If and when they d= o, as=0AInformational documents,=A0 they should not require normative chang= es to=0Aanything. They should make sure what they describe (mostly=0Aimplem= entation options in this case) are compatible not only with=0ARFC3775 but a= lso with extensions to it, including Flow Bindings. .=0A=0A=0ARegards=0AGeo= rge=0A=0AOn Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli wrote:=0A> Behcet,=0A>=0A> Behcet Sarikaya wrote:=0A>>=0A>> *[behcet]= Yes but each interface will appear to HA as a different device=0A>> and HA= needs to assign a different HoA. Then MCoA problem disappears.*=0A>> *So G= eorge is saying that this is avoided by some virtual interfaces so=0A>> tha= t HA does not see each interface separately. *=0A>> *Is this explained anyw= here in the draft?*=0A>> *If yes then I am OK.*=0A>=0A> The home agent does= not care about the multiple interfaces on the mobile=0A> node. It only see= s the mobile node as one entity and allocates a home=0A> address to it. The= multiple care-of addresses that the mobile node has will=0A> be used by th= e home agent as tunnel end points. That is all. So there is no=0A> issue.= =0A>=0A> Vijay=0A>=0A>> =A0> =A0Also I have a question to Ryuji: does this = draft send a=0A>> non-deregistration BU at the home link? If yes, is he fam= iliar with the=0A>> discussion going on on this subject? This is another po= int of confusion for=0A>> me.=0A>>=0A>> This has been discussed for a long = time in MEXT.=0A>> who is familiar with which discussions? I don't know you= r concern here.=0A>> =A0*[behcet] So your answer is yes the draft sends a n= on-deregistration BU=0A>> (kind of bulk registration) at the home link.*=0A= >> *The discussion I mentioned was related to=0A>> draft-premec-mext-extend= ed-home-link. This draft also sends=0A>> non-deregistration BU at the home = link. So does a few more drafts like=0A>> **draft-devarapalli-mext-mipv6-ho= me-link.*=0A>>=0A>> **=0A>> *[behcet] You mentioned some bit is set but I c= ould not understand which.=0A>> One idea is since so many drafts need this,= why not factor this out and=0A>> define whatever the mechanism to enable s= ending non-deregistration BU in=0A>> 3775bis. What do you think about that?= *=0A>>=0A>> **=0A>>=0A>> =A0> =A0Sorry if I am too =A0much confused=0A>> = =A0> Please don't get me wrong, I am not trying to slow down the progress o= f=0A>> this document..=0A>>=0A>> sure, but please explain your issue more p= recisely.=0A>>=0A>> thanks!=0A>> ryuji=0A>>=0A>> =A0>=0A>> =A0> Regards,=0A= >> =A0>=0A>> =A0> Behcet=0A>> =A0> From: marcelo bagnulo braun > >=0A>> =A0> To: mext >; Julien Laganier=0A>> > >; Jari Arkko=0A>= > >=0A>> =A0> Sent: Tues= day, April 21, 2009 11:03:05 AM=0A>> =A0> Subject: [MEXT] [Fwd: I-D Action:= draft-ietf-monami6-multiplecoa-13.txt]=0A>> =A0>=0A>> =A0> We have this new= version of the MCOA document that addresses the=0A>> comments received, in= cluding IESG review comments.=0A>> =A0> To the best of my knowledge, the IE= SG is ok with the doc and ready for=0A>> publication.=0A>> =A0> I am planni= ng to ask our AD to move forward in a week or so, so, if you=0A>> have comm= ents on the document please provide them before the 1st of may.=0A>> =A0>= =0A>> =A0> Regards, marcelo=0A>> =A0> (mcoa doc shepherd)=0A>> =A0>=0A>> = =A0> -------- Mensaje original --------=0A>> =A0> Asunto: =A0 =A0[MEXT] I-D= Action:draft-ietf-monami6-multiplecoa-13.txt=0A>> =A0> Fecha: =A0 =A0Mon, = 20 Apr 2009 08:30:01 -0700 (PDT)=0A>> =A0> De: =A0 =A0Internet-Drafts@ietf.= org =0A>> =A0> Para: =A0 =A0i-d-announce@i= etf.org =0A>> =A0> CC: =A0 =A0mext@ietf.org <= mailto:mext@ietf.org>=0A>> =A0>=0A>> =A0>=0A>> =A0>=0A>> =A0> A New Interne= t-Draft is available from the on-line Internet-Drafts=0A>> directories.=0A>= > =A0> This draft is a work item of the Mobility EXTensions for IPv6 Workin= g=0A>> Group of the IETF.=0A>> =A0>=0A>> =A0>=0A>> =A0> =A0 =A0Title =A0 = =A0 =A0 =A0 =A0: Multiple Care-of Addresses Registration=0A>> =A0> =A0 =A0A= uthor(s) =A0 =A0 =A0: R. Wakikawa, et al.=0A>> =A0> =A0 =A0Filename =A0 =A0= =A0 =A0: draft-ietf-monami6-multiplecoa-13..txt=0A>> =A0> =A0 =A0Pages =A0= =A0 =A0 =A0 =A0: 44=0A>> =A0> =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-04= -20=0A>> =A0>=0A>> =A0> According to the current Mobile IPv6 specification,= a mobile node may=0A>> =A0> have several care-of addresses, but only one, = called the primary=0A>> =A0> care-of address, that can be registered with i= ts home agent and the=0A>> =A0> correspondent nodes. =A0However, for matter= s of cost, bandwidth, delay,=0A>> =A0> etc, it is useful for the mobile nod= e to get Internet access through=0A>> =A0> multiple accesses simultaneously= , in which case the mobile node would=0A>> =A0> be configured with multiple= active IPv6 care-of addresses. =A0This=0A>> =A0> document proposes extensi= ons to the Mobile IPv6 protocol to register=0A>> =A0> and use multiple care= -of addresses. =A0The extensions proposed in this=0A>> =A0> document can be= used by Mobile Routers using the NEMO (Network=0A>> =A0> Mobility) Basic S= upport protocol as well.=0A>> =A0>=0A>> =A0> A URL for this Internet-Draft = is:=0A>> =A0>=0A>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-m= ultiplecoa-13.txt=0A>> =A0>=0A>> =A0> Internet-Drafts are also available by= anonymous FTP at:=0A>> =A0> ftp://ftp.ietf.org/internet-drafts/=0A>> =A0>= =0A>> =A0> Below is the data which will enable a MIME compliant mail reader= =0A>> =A0> implementation to automatically retrieve the ASCII version of th= e=0A>> =A0> Internet-Draft.=0A>> =A0>=0A>> =A0>=0A>> =A0>=0A>> =A0> _______= ________________________________________=0A>> =A0> MEXT mailing list=0A>> = =A0> MEXT@ietf.org =0A>> =A0> https://www.ietf.org/ma= ilman/listinfo/mext=0A>>=0A>>=0A>>=0A>> -----------------------------------= -------------------------------------=0A>>=0A>> ___________________________= ____________________=0A>> MEXT mailing list=0A>> MEXT@ietf.org=0A>> https:/= /www.ietf.org/mailman/listinfo/mext=0A>=0A> _______________________________= ________________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.ie= tf.org/mailman/listinfo/mext=0A>=0A=0A=0A=0A --0-2099263579-1240412766=:92209 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
So you are saying that there could be a single HA?=0A
 
=0A
Regards,
=0A
 
=0A
Beh= cet
=0A

=0A
=0A
=0AFrom: Vijay Devarapall= i <vijay@wichorus.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: Ryuji Wakikawa <ryuji.wakikawa@gmail.com&= gt;; mext <mext@ietf.org>
Sen= t: Tuesday, April 21, 2009 1:58:07 PM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-mo= nami6-multiplecoa-13.txt]

Behcet,

Behcet Sarikaya wrot= e:
> *[behcet] Yes but each interface will appear to HA as a differen= t device and HA needs to assign a different HoA. Then MCoA problem disappea= rs.*
> *So George is saying that this is avoided by some virtual inte= rfaces so that HA does not see each interface separately. *
> *Is thi= s explained anywhere in the draft?*
> *If yes then I am OK.*

T= he home agent does not care about the multiple interfaces on the mobile node. It o= nly sees the mobile node as one entity and allocates a home address to it. = The multiple care-of addresses that the mobile node has will be used by the= home agent as tunnel end points. That is all. So there is no issue.
Vijay

>  >  Also I have a question to Ryuji: does t= his draft send a non-deregistration BU at the home link? If yes, is he fami= liar with the discussion going on on this subject? This is another point of= confusion for me.
>
> This has been discussed for a long time= in MEXT.
> who is familiar with which discussions? I don't know your= concern here.
>  *[behcet] So your answer is yes the draft send= s a non-deregistration BU (kind of bulk registration) at the home link.*> *The discussion I mentioned was related to draft-premec-mext-extended= -home-link. This draft also sends non-deregistration BU at the home link. So does a few more drafts like **draft-devarapalli-mext-mipv6-home-l= ink.*
>
> **
> *[behcet] You mentioned some bit is set = but I could not understand which. One idea is since so many drafts need thi= s, why not factor this out and define whatever the mechanism to enable send= ing non-deregistration BU in 3775bis. What do you think about that?*
>= ;
> **
>
>  >  Sorry if I am too  mu= ch confused
>  > Please don't get me wrong, I am not trying t= o slow down the progress of this document..
>
> sure, but plea= se explain your issue more precisely.
>
> thanks!
> ryuj= i
>
>  >
>  > Regards,
>  >= ;
>  > Behcet
>  > From: marcelo bagnulo braun = <marcelo@it.uc3m.es <mailto:m= arcelo@it.uc3m.es>>
>  > To: mext <mext@ietf.org <= mailto:me= xt@ietf.org>>; Julien Laganier <julien.laganier.ietf@googlemail.com <mailto:julien.laganier.ietf@googlemail.com>>; Jari Arkko= <jari.arkko@piuha.net <mailto:jari.arkko@piuha.net= >>
>  > Sent: Tuesday, April 21, 2009 11:03:05 AM
&g= t;  > Subject: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]>  >
>  > We have this new version of the MCOA do= cument that addresses the comments received, including IESG review comments= .
>  > To the best of my knowledge, the IESG is ok with the d= oc and ready for publication.
>  > I am planning to ask our A= D to move forward in a week or so, so, if you have comments on the document= please provide them before the 1st of may.
>  >
> = ; > Regards, marcelo
>  > (mcoa doc shepherd)
> = ; >
>  > -------- Mensaje original --------
>  = > Asunto:    [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-= 13.txt
>  > Fecha:    Mon, 20 Apr 2009 08:30:01 -07= 00 (PDT)
>  > De:    Internet-Drafts@ietf.org &= lt;mailto:Internet-Drafts@ietf.org>
>  > = Para:    i-d-announce@ietf.org <mailto:i-d-a= nnounce@ietf.org>
>  > CC:    mext@ietf.org <m= ailto:mex= t@ietf.org>
>  >
>  >
>  >=
>  > A New Internet-Draft is available from the on-line Inte= rnet-Drafts directories.
>  > This draft is a work item of th= e Mobility EXTensions for IPv6 Working Group of the IETF.
>  >= ;
>  >
>  >    Title        &nbs= p; : Multiple Care-of Addresses Registration
>  >   = ; Author(s)      : R. Wakikawa, et al.
>  >&nb= sp;   Filename        : draft-ietf-monami6-multipl= ecoa-13..txt
>  >    Pages      &nbs= p;   : 44
>  >    Date      &nb= sp;     : 2009-04-20
>  >
>  > Accord= ing to the current Mobile IPv6 specification, a mobile node may
>&nbs= p; > have several care-of addresses, but only one, called the primary>  > care-of address, that can be registered with its home agen= t and the
>  > correspondent nodes.  However, for matter= s of cost, bandwidth, delay,
>  > etc, it is useful for the m= obile node to get Internet access through
>  > multiple accesses simultaneously, in which case the mobile node would
&= gt;  > be configured with multiple active IPv6 care-of addresses.&n= bsp; This
>  > document proposes extensions to the Mobile IPv= 6 protocol to register
>  > and use multiple care-of addresse= s.  The extensions proposed in this
>  > document can be= used by Mobile Routers using the NEMO (Network
>  > Mobility= ) Basic Support protocol as well.
>  >
>  > A U= RL for this Internet-Draft is:
>  > http://www.ietf.org/inter= net-drafts/draft-ietf-monami6-multiplecoa-13.txt
>  >
>=   > Internet-Drafts are also available by anonymous FTP at:
>=   > ftp://ftp.ietf.org/internet-drafts/
>  >
>  &= gt; Below is the data which will enable a MIME compliant mail reader
>  > implementation to automatically retrieve the ASC= II version of the
>  > Internet-Draft.
>  >
= >  >
>  >
>  > _____________________= __________________________
>  > MEXT mailing list
>&nbs= p; > M= EXT@ietf.org <mailto:MEXT@ietf.org>
>  > https://www.ietf.or= g/mailman/listinfo/mext
>
>
>
> ------------= ------------------------------------------------------------
>
&g= t; _______________________________________________
> MEXT mailing lis= t
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext


=0A=0A --0-2051789051-1240340664=:68078-- From tsirtsis@googlemail.com Tue Apr 21 12:13:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873F228C237 for ; Tue, 21 Apr 2009 12:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 424EL8absWJE for ; Tue, 21 Apr 2009 12:13:39 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 1C0D628C233 for ; Tue, 21 Apr 2009 12:13:39 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1159996yxb.49 for ; Tue, 21 Apr 2009 12:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=sgixo46Opjp5P4q3PAF7DudI6nTaDADit1Fin6bjklM=; b=wfY0C3j81ulSWkHREhkUaN41X25+g6aqM9L1KbMTl4znjWqU7WKXB8NARvuf+OVE0x oE+q7KPARXyA9+zjib76n1eVfOa95NeJzixOfK2GHatlpMXhFwrP4Z62UAZNOXUWnFNi LlhFGqe6Q4w+HCUfzlEFHXB8nngpDL2ZhSkok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=exILx88MLnq3vAb/QpNBBK9x/aBeHVzzqJ8AuyMos8c1raKI/aGGb+B3oKZi2m20tX /3NubjMFhD4OoOnP1LxE74TMLUM+bqpeBqHpiz5JwKlVh5Y98INFA6OAuKDBGEUJJH3Q hJ6VCqDMRcT6n6KQICAQiEiKL2/5sR9UbMHk0= MIME-Version: 1.0 Received: by 10.90.75.13 with SMTP id x13mr9214890aga.102.1240341295457; Tue, 21 Apr 2009 12:14:55 -0700 (PDT) In-Reply-To: <49EE173F.2090800@wichorus.com> References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> Date: Tue, 21 Apr 2009 20:14:55 +0100 Message-ID: From: George Tsirtsis To: Vijay Devarapalli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 19:13:40 -0000 ...also wrt the home link registration, I do not think what you suggest is necessary. As far as I see the other documents are informational, and they do not yet have a formal standing in the WG. If and when they do, as Informational documents, they should not require normative changes to anything. They should make sure what they describe (mostly implementation options in this case) are compatible not only with RFC3775 but also with extensions to it, including Flow Bindings. . Regards George On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli wro= te: > Behcet, > > Behcet Sarikaya wrote: >> >> *[behcet] Yes but each interface will appear to HA as a different device >> and HA needs to assign a different HoA. Then MCoA problem disappears.* >> *So George is saying that this is avoided by some virtual interfaces so >> that HA does not see each interface separately. * >> *Is this explained anywhere in the draft?* >> *If yes then I am OK.* > > The home agent does not care about the multiple interfaces on the mobile > node. It only sees the mobile node as one entity and allocates a home > address to it. The multiple care-of addresses that the mobile node has wi= ll > be used by the home agent as tunnel end points. That is all. So there is = no > issue. > > Vijay > >> =C2=A0> =C2=A0Also I have a question to Ryuji: does this draft send a >> non-deregistration BU at the home link? If yes, is he familiar with the >> discussion going on on this subject? This is another point of confusion = for >> me. >> >> This has been discussed for a long time in MEXT. >> who is familiar with which discussions? I don't know your concern here. >> =C2=A0*[behcet] So your answer is yes the draft sends a non-deregistrati= on BU >> (kind of bulk registration) at the home link.* >> *The discussion I mentioned was related to >> draft-premec-mext-extended-home-link. This draft also sends >> non-deregistration BU at the home link. So does a few more drafts like >> **draft-devarapalli-mext-mipv6-home-link.* >> >> ** >> *[behcet] You mentioned some bit is set but I could not understand which= . >> One idea is since so many drafts need this, why not factor this out and >> define whatever the mechanism to enable sending non-deregistration BU in >> 3775bis. What do you think about that?* >> >> ** >> >> =C2=A0> =C2=A0Sorry if I am too =C2=A0much confused >> =C2=A0> Please don't get me wrong, I am not trying to slow down the prog= ress of >> this document.. >> >> sure, but please explain your issue more precisely. >> >> thanks! >> ryuji >> >> =C2=A0> >> =C2=A0> Regards, >> =C2=A0> >> =C2=A0> Behcet >> =C2=A0> From: marcelo bagnulo braun > > >> =C2=A0> To: mext >; Julien Laganier >> > >; Jari Arkko >> > >> =C2=A0> Sent: Tuesday, April 21, 2009 11:03:05 AM >> =C2=A0> Subject: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-= 13.txt] >> =C2=A0> >> =C2=A0> We have this new version of the MCOA document that addresses the >> comments received, including IESG review comments. >> =C2=A0> To the best of my knowledge, the IESG is ok with the doc and rea= dy for >> publication. >> =C2=A0> I am planning to ask our AD to move forward in a week or so, so,= if you >> have comments on the document please provide them before the 1st of may. >> =C2=A0> >> =C2=A0> Regards, marcelo >> =C2=A0> (mcoa doc shepherd) >> =C2=A0> >> =C2=A0> -------- Mensaje original -------- >> =C2=A0> Asunto: =C2=A0 =C2=A0[MEXT] I-D Action:draft-ietf-monami6-multip= lecoa-13.txt >> =C2=A0> Fecha: =C2=A0 =C2=A0Mon, 20 Apr 2009 08:30:01 -0700 (PDT) >> =C2=A0> De: =C2=A0 =C2=A0Internet-Drafts@ietf.org >> =C2=A0> Para: =C2=A0 =C2=A0i-d-announce@ietf.org >> =C2=A0> CC: =C2=A0 =C2=A0mext@ietf.org >> =C2=A0> >> =C2=A0> >> =C2=A0> >> =C2=A0> A New Internet-Draft is available from the on-line Internet-Draf= ts >> directories. >> =C2=A0> This draft is a work item of the Mobility EXTensions for IPv6 Wo= rking >> Group of the IETF. >> =C2=A0> >> =C2=A0> >> =C2=A0> =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Multiple = Care-of Addresses Registration >> =C2=A0> =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0: R. Wakikawa, et al. >> =C2=A0> =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-mo= nami6-multiplecoa-13..txt >> =C2=A0> =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 44 >> =C2=A0> =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 200= 9-04-20 >> =C2=A0> >> =C2=A0> According to the current Mobile IPv6 specification, a mobile nod= e may >> =C2=A0> have several care-of addresses, but only one, called the primary >> =C2=A0> care-of address, that can be registered with its home agent and = the >> =C2=A0> correspondent nodes. =C2=A0However, for matters of cost, bandwid= th, delay, >> =C2=A0> etc, it is useful for the mobile node to get Internet access thr= ough >> =C2=A0> multiple accesses simultaneously, in which case the mobile node = would >> =C2=A0> be configured with multiple active IPv6 care-of addresses. =C2= =A0This >> =C2=A0> document proposes extensions to the Mobile IPv6 protocol to regi= ster >> =C2=A0> and use multiple care-of addresses. =C2=A0The extensions propose= d in this >> =C2=A0> document can be used by Mobile Routers using the NEMO (Network >> =C2=A0> Mobility) Basic Support protocol as well. >> =C2=A0> >> =C2=A0> A URL for this Internet-Draft is: >> =C2=A0> >> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.tx= t >> =C2=A0> >> =C2=A0> Internet-Drafts are also available by anonymous FTP at: >> =C2=A0> ftp://ftp.ietf.org/internet-drafts/ >> =C2=A0> >> =C2=A0> Below is the data which will enable a MIME compliant mail reader >> =C2=A0> implementation to automatically retrieve the ASCII version of th= e >> =C2=A0> Internet-Draft. >> =C2=A0> >> =C2=A0> >> =C2=A0> >> =C2=A0> _______________________________________________ >> =C2=A0> MEXT mailing list >> =C2=A0> MEXT@ietf.org >> =C2=A0> https://www.ietf.org/mailman/listinfo/mext >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From tsirtsis@googlemail.com Tue Apr 21 12:37:53 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF5F3A6E5A for ; Tue, 21 Apr 2009 12:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 AWariY2oQsnM for ; Tue, 21 Apr 2009 12:37:52 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id EA15E3A6933 for ; Tue, 21 Apr 2009 12:37:51 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1174779yxb.49 for ; Tue, 21 Apr 2009 12:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=p00acJjI2ZCbCciA8o88Rz9HijzPuMQSWqDKvsHjlVc=; b=OXMEFNG3fkbpS6iaoGRJZCEBNRkcsYgwxBbulJzuSrU1M3eWxntSWaeJWBg9emp/EC G7tNL12pd28lHwTmFTlY1CmRB1r6UyzKBjg4FXMiHzg2/ZRM3hVY6Hj7+0b6a3w0ur4X icrPhp71Ok+fSmmO+XmD+AjepAn/FviAVc8fE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dfo9y4HslxVqmIvLA3LF4yjfh1A6C8TNYgUlue8e0LSQK4a8xdXC7ZTFbpaY2Ic9WX hbAnaWclEK1VhKkIEZswABy5ZlYP5SxnuBwq1n6w86L6sq7Jgf7xfyU2/PquMqu8uatb xBIzeUB6EQUtPLQnJISSW+Cu9N7wiQSIgXSQI= MIME-Version: 1.0 Received: by 10.101.69.6 with SMTP id w6mr3804043ank.8.1240342748231; Tue, 21 Apr 2009 12:39:08 -0700 (PDT) In-Reply-To: <431126.68078.qm@web111407.mail.gq1.yahoo.com> References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <431126.68078.qm@web111407.mail.gq1.yahoo.com> Date: Tue, 21 Apr 2009 20:39:08 +0100 Message-ID: From: George Tsirtsis To: Behcet Sarikaya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 19:37:53 -0000 Behcet, I do not understand your latest question, but that's OK. I am going to try to read between the lines to see if I can help with this. Based on your last e-mail, I think you now understand that according to the MCoA draft the HA must treat all tunnels to the different CoAs of an MN as indeed belonging to the same MN, and not as interfaces to different MNs (which would indeed require different prefixis) as you originally thought. This has always been clear, however, since all CoAs are registered using the MNs home address as the MN identifier, and are secured by the same MN-HA security association. So there can be no doubt that a given set of CoAs belong to a given MN. I hope this helps. George On Tue, Apr 21, 2009 at 8:04 PM, Behcet Sarikaya wrote: > So you are saying that there could be a single HA? > > Regards, > > Behcet > > ________________________________ > From: Vijay Devarapalli > To: Behcet Sarikaya > Cc: Ryuji Wakikawa ; mext > Sent: Tuesday, April 21, 2009 1:58:07 PM > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.tx= t] > > Behcet, > > Behcet Sarikaya wrote: >> *[behcet] Yes but each interface will appear to HA as a different device >> and HA needs to assign a different HoA. Then MCoA problem disappears.* >> *So George is saying that this is avoided by some virtual interfaces so >> that HA does not see each interface separately. * >> *Is this explained anywhere in the draft?* >> *If yes then I am OK.* > > The home agent does not care about the multiple interfaces on the mobile > node. It only sees the mobile node as one entity and allocates a home > address to it. The multiple care-of addresses that the mobile node has wi= ll > be used by the home agent as tunnel end points. That is all. So there is = no > issue. > > Vijay > >>=C2=A0 >=C2=A0 Also I have a question to Ryuji: does this draft send a >> non-deregistration BU at the home link? If yes, is he familiar with the >> discussion going on on this subject? This is another point of confusion = for >> me. >> >> This has been discussed for a long time in MEXT. >> who is familiar with which discussions? I don't know your concern here. >>=C2=A0 *[behcet] So your answer is yes the draft sends a non-deregistrati= on BU >> (kind of bulk registration) at the home link.* >> *The discussion I mentioned was related to >> draft-premec-mext-extended-home-link. This draft also sends >> non-deregistration BU at the home link. So does a few more drafts like >> **draft-devarapalli-mext-mipv6-home-link.* >> >> ** >> *[behcet] You mentioned some bit is set but I could not understand which= . >> One idea is since so many drafts need this, why not factor this out and >> define whatever the mechanism to enable sending non-deregistration BU in >> 3775bis. What do you think about that?* >> >> ** >> >>=C2=A0 >=C2=A0 Sorry if I am too=C2=A0 much confused >>=C2=A0 > Please don't get me wrong, I am not trying to slow down the prog= ress of >> this document.. >> >> sure, but please explain your issue more precisely. >> >> thanks! >> ryuji >> >>=C2=A0 > >>=C2=A0 > Regards, >>=C2=A0 > >>=C2=A0 > Behcet >>=C2=A0 > From: marcelo bagnulo braun > > >>=C2=A0 > To: mext >; Julien Laganier >> > >; Jari Arkko >> > >>=C2=A0 > Sent: Tuesday, April 21, 2009 11:03:05 AM >>=C2=A0 > Subject: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-= 13.txt] >>=C2=A0 > >>=C2=A0 > We have this new version of the MCOA document that addresses the >> comments received, including IESG review comments. >>=C2=A0 > To the best of my knowledge, the IESG is ok with the doc and rea= dy for >> publication. >>=C2=A0 > I am planning to ask our AD to move forward in a week or so, so,= if you >> have comments on the document please provide them before the 1st of may. >>=C2=A0 > >>=C2=A0 > Regards, marcelo >>=C2=A0 > (mcoa doc shepherd) >>=C2=A0 > >>=C2=A0 > -------- Mensaje original -------- >>=C2=A0 > Asunto:=C2=A0 =C2=A0 [MEXT] I-D Action:draft-ietf-monami6-multip= lecoa-13.txt >>=C2=A0 > Fecha:=C2=A0 =C2=A0 Mon, 20 Apr 2009 08:30:01 -0700 (PDT) >>=C2=A0 > De:=C2=A0 =C2=A0 Internet-Drafts@ietf.org >>=C2=A0 > Para:=C2=A0 =C2=A0 i-d-announce@ietf.org >>=C2=A0 > CC:=C2=A0 =C2=A0 mext@ietf.org >>=C2=A0 > >>=C2=A0 > >>=C2=A0 > >>=C2=A0 > A New Internet-Draft is available from the on-line Internet-Draf= ts >> directories. >>=C2=A0 > This draft is a work item of the Mobility EXTensions for IPv6 Wo= rking >> Group of the IETF. >>=C2=A0 > >>=C2=A0 > >>=C2=A0 >=C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Multiple = Care-of Addresses Registration >>=C2=A0 >=C2=A0 =C2=A0 Author(s)=C2=A0 =C2=A0 =C2=A0 : R. Wakikawa, et al. >>=C2=A0 >=C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-mo= nami6-multiplecoa-13..txt >>=C2=A0 >=C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 44 >>=C2=A0 >=C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 200= 9-04-20 >>=C2=A0 > >>=C2=A0 > According to the current Mobile IPv6 specification, a mobile nod= e may >>=C2=A0 > have several care-of addresses, but only one, called the primary >>=C2=A0 > care-of address, that can be registered with its home agent and = the >>=C2=A0 > correspondent nodes.=C2=A0 However, for matters of cost, bandwid= th, delay, >>=C2=A0 > etc, it is useful for the mobile node to get Internet access thr= ough >>=C2=A0 > multiple accesses simultaneously, in which case the mobile node = would >>=C2=A0 > be configured with multiple active IPv6 care-of addresses.=C2=A0= This >>=C2=A0 > document proposes extensions to the Mobile IPv6 protocol to regi= ster >>=C2=A0 > and use multiple care-of addresses.=C2=A0 The extensions propose= d in this >>=C2=A0 > document can be used by Mobile Routers using the NEMO (Network >>=C2=A0 > Mobility) Basic Support protocol as well. >>=C2=A0 > >>=C2=A0 > A URL for this Internet-Draft is: >>=C2=A0 > >> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.tx= t >>=C2=A0 > >>=C2=A0 > Internet-Drafts are also available by anonymous FTP at: >>=C2=A0 > ftp://ftp.ietf.org/internet-drafts/ >>=C2=A0 > >>=C2=A0 > Below is the data which will enable a MIME compliant mail reader >>=C2=A0 > implementation to automatically retrieve the ASCII version of th= e >>=C2=A0 > Internet-Draft. >>=C2=A0 > >>=C2=A0 > >>=C2=A0 > >>=C2=A0 > _______________________________________________ >>=C2=A0 > MEXT mailing list >>=C2=A0 > MEXT@ietf.org >>=C2=A0 > https://www.ietf.org/mailman/listinfo/mext >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From hesham@elevatemobile.com Tue Apr 21 18:06:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 228383A6AE1 for ; Tue, 21 Apr 2009 18:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 NzwIGxCl7psQ for ; Tue, 21 Apr 2009 18:06:13 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 325083A67AD for ; Tue, 21 Apr 2009 18:06:12 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LwQve-0005eG-Oc; Wed, 22 Apr 2009 11:07:10 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 22 Apr 2009 11:06:21 +1000 From: Hesham Soliman To: Ryuji Wakikawa Message-ID: Thread-Topic: [MEXT] One more try (was Re: clarification on flow binding documents Thread-Index: AcnC5oxd8gdkfINFIEGhrhNAKTEiIg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Michael Eriksson , mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 01:06:14 -0000 Hi Ryuji, There was a long detailed presentation made in monami6 by one of Koojana's colleagues (the name escapes me) where he gave detailed feedback based on their implementation. Also Nicolas gave some feedback based on their MR implementation and use scenarios. The former is in the public domain and the latter was part of the discussion for the next rev. Hesham On 22/04/09 1:31 AM, "Ryuji Wakikawa" wrote: > Hi Hesham, > > I am collecting the implementation info of MCoA or flow binding. > Which implementation's' are you referring to ? Romain's one? > Please share the implementations info if you can. > > thanks, > ryuji > > On 2009/04/21, at 6:35, Hesham Soliman wrote: > >> >> >> >> On 21/04/09 10:29 PM, "Michael Eriksson" >> >> wrote: >> >>> On Tue, Apr 21, 2009 at 13:03:03 +0200, marcelo bagnulo braun wrote: >>>>> Well, now that we are taking a new grip on flow routing, I would >>>>> like >>>>> to push draft-eriksson-mext-mipv6-routing-rules-00, which Romain >>>>> also >>>>> pointed at. >>>>> >>>>> http://tools.ietf.org/html/draft-eriksson-mext-mipv6-routing-rules >>>> >>>> I understand that we do have a WG document for this and we had >>>> several >>>> rounds of reviews which show interest, so i don't see any reason to >>>> revisit the decision of using draft-ietf-flow-binding at this point. >>>> regards, marcelo >>> >>> Well, the WG document has had exactly zero progress since the 00 >>> version was adopted almost a full year ago. It's not like chosing >>> another way to transfer routing rules would be a last minute stop to >>> something that has already been finished. >> >> => Nonsense. The WG document has been depending on the progress of >> MCoA and >> now that MCoA is done we will have a new near final version by the >> weekend. >> This version has already received numerous reviews and some feedback >> from >> implementations. We expect this to go to LC before the next meeting. >> Please >> get those facts straight. BTW, the 00 version was around for >> discussions and >> review for a couple of years as a monami6 WG doc before it was >> adopted by >> the MEXT WG. >> >> Hesham >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > From mer@kafka.verkstad.net Wed Apr 22 03:11:48 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110573A68B4 for ; Wed, 22 Apr 2009 03:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 NmBN9aVgL3ZH for ; Wed, 22 Apr 2009 03:11:47 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id 0BCCD3A6945 for ; Wed, 22 Apr 2009 03:11:46 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id 9E3B6710A95; Wed, 22 Apr 2009 12:13:02 +0200 (CEST) Date: Wed, 22 Apr 2009 12:13:02 +0200 From: Michael Eriksson To: marcelo bagnulo braun Message-ID: <20090422101302.GC3296@kafka.verkstad.net> References: <4C51279E-272C-4C8F-A7B1-938014312287@lsiit.u-strasbg.fr> <49E84374.6030808@it.uc3m.es> <20090421105326.GA20775@kafka.verkstad.net> <49EDA7E7.60102@it.uc3m.es> <20090421112907.GB20775@kafka.verkstad.net> <49EDBD06.40802@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <49EDBD06.40802@it.uc3m.es> Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 10:11:48 -0000 On Tue, Apr 21, 2009 at 14:33:10 +0200, marcelo bagnulo braun wrote: > Michael Eriksson escribió: > > Well, the WG document has had exactly zero progress since the 00 > > version was adopted almost a full year ago. It's not like chosing > > another way to transfer routing rules would be a last minute stop to > > something that has already been finished. > > > in general, as a chair, i like to make progress forward in the process > i.e. wg doc adoption, WGLC, IESG, RFC, rather than in the oposite > direction, i.e. adopting a WG document, disadopting a WG doc and so on > > Of course, things are not always forward and sometimes the WG consensus > is that we were wrong in the first approach and we need to change. I agree that moving things forward is generally positive... My impression from your original mail was that we should focus on flow routing now, to make progress in that area. When we make a decision on what solution to select to be an RFC, we should at least be sure that all relevant input is taken into account. I have pushed our draft, since I think that it is technically superior for a number of reasons that I have already mentioned. draft-eriksson is almost a year old and has been announced on the mext mailing list, so I am not throwing in any last-minute idea. >From my point of view, the flow routing issue has made very little progress in the last few years. Now is the time to finally make some progress. It would be sad if "progress" was just rubber stamping the oldest solution, which was selected as WG item two years ago when it was the only solution available, without proper evaluation of the alternative solutions that have been developed since then. > > It is also the case that the suggested rule format is what is defined > > in draft-larsson-mext-flow-distribution-rules. As a co-author of that > > draft, I want to stress that the rule transfer format in the > > flow-binding draft is very inflexible. > > > > > this would then make the case that the format defined in draft-larson is > not very suitbale for the transport that the WG has chosen, which would > then mean that we probably want to use the bit pattern rules instead, right? I thought that the idea with the flow-binding draft was to make a /generic/ format for distribution of flow rules. Our experience, from designing a flow rule language, is that it is not generic enough and still is very tailored to the rule format that it was originally designed for. If we want just one single binary format, we can revert to draft-soliman-monami6-flow-binding-04, but I obviously think that that would be a mistake. > > Finally, that I am pushing draft-eriksson doesn't mean that we would > > have to adopt it as is (even if I would be happy if that happened > > :-)). See it as input on how we think flow rule transfer should be > > done. I think I mentioned some valid advantages compared to the > > flow-binding draft in my last e-mail. > > > > > sure, any WG member is entitled to make any comments they feel like. I > am just saying that the current plan is to make progress with the doc > the WG has chosen, but i guess that's obvious. Yes, but I think that the WG members should at least know about the alternative solutions before we go for a solution that might have unwanted limitations. Regards, Michael From marcelo@it.uc3m.es Wed Apr 22 03:20:22 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3EC3A6AB8 for ; Wed, 22 Apr 2009 03:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 ShId5AXdkbE9 for ; Wed, 22 Apr 2009 03:20:22 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id AC2A13A69D2 for ; Wed, 22 Apr 2009 03:20:21 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id D71BC6BAD80; Wed, 22 Apr 2009 12:21:36 +0200 (CEST) Message-ID: <49EEEFB0.5030500@it.uc3m.es> Date: Wed, 22 Apr 2009 12:21:36 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Michael Eriksson References: <4C51279E-272C-4C8F-A7B1-938014312287@lsiit.u-strasbg.fr> <49E84374.6030808@it.uc3m.es> <20090421105326.GA20775@kafka.verkstad.net> <49EDA7E7.60102@it.uc3m.es> <20090421112907.GB20775@kafka.verkstad.net> <49EDBD06.40802@it.uc3m.es> <20090422101302.GC3296@kafka.verkstad.net> In-Reply-To: <20090422101302.GC3296@kafka.verkstad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16596.005 Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 10:20:23 -0000 Michael Eriksson escribió: > On Tue, Apr 21, 2009 at 14:33:10 +0200, marcelo bagnulo braun wrote: > >> Michael Eriksson escribió: >> >>> Well, the WG document has had exactly zero progress since the 00 >>> version was adopted almost a full year ago. It's not like chosing >>> another way to transfer routing rules would be a last minute stop to >>> something that has already been finished. >>> >>> >> in general, as a chair, i like to make progress forward in the process >> i.e. wg doc adoption, WGLC, IESG, RFC, rather than in the oposite >> direction, i.e. adopting a WG document, disadopting a WG doc and so on >> >> Of course, things are not always forward and sometimes the WG consensus >> is that we were wrong in the first approach and we need to change. >> > > I agree that moving things forward is generally positive... > > My impression from your original mail was that we should focus on flow > routing now, to make progress in that area. well, we have this deliverable in the charter for a long time now, so, any progress in any of the deliverables we have is always welcome. there is nothing special with this deliverable at this point it time (other than peopel are working on it, which is good) > When we make a decision on > what solution to select to be an RFC, we should at least be sure that > all relevant input is taken into account. > sure but we cannot rehash the same discussions over and over again > I have pushed our draft, since I think that it is technically superior > for a number of reasons that I have already mentioned. draft-eriksson > is almost a year old and has been announced on the mext mailing list, > so I am not throwing in any last-minute idea. > ok > >From my point of view, the flow routing issue has made very little > progress in the last few years. Now is the time to finally make some > progress. It would be sad if "progress" was just rubber stamping the > oldest solution, which was selected as WG item two years ago when it > was the only solution available, without proper evaluation of the > alternative solutions that have been developed since then. > > mmm, that's not my recollection of these topic, I undersrnad that when adopting this document there was a lot of debate on what solution was better and there were several apporaches considered (don't know if multiple drafts, but certainly i recall several presentations) So, i don't think this draft was adopted lightly >>> It is also the case that the suggested rule format is what is defined >>> in draft-larsson-mext-flow-distribution-rules. As a co-author of that >>> draft, I want to stress that the rule transfer format in the >>> flow-binding draft is very inflexible. >>> >>> >>> >> this would then make the case that the format defined in draft-larson is >> not very suitbale for the transport that the WG has chosen, which would >> then mean that we probably want to use the bit pattern rules instead, right? >> > > I thought that the idea with the flow-binding draft was to make a > /generic/ format for distribution of flow rules. Our experience, from > designing a flow rule language, is that it is not generic enough and > still is very tailored to the rule format that it was originally > designed for. If we want just one single binary format, we can revert > to draft-soliman-monami6-flow-binding-04, but I obviously think that > that would be a mistake. > > this is up for the wg to comment, >>> Finally, that I am pushing draft-eriksson doesn't mean that we would >>> have to adopt it as is (even if I would be happy if that happened >>> :-)). See it as input on how we think flow rule transfer should be >>> done. I think I mentioned some valid advantages compared to the >>> flow-binding draft in my last e-mail. >>> >>> >>> >> sure, any WG member is entitled to make any comments they feel like. I >> am just saying that the current plan is to make progress with the doc >> the WG has chosen, but i guess that's obvious. >> > > Yes, but I think that the WG members should at least know about the > alternative solutions before we go for a solution that might have > unwanted limitations. > > sure, again this is up to the WG regards, marcelo > Regards, > Michael > > From mer@kafka.verkstad.net Wed Apr 22 03:23:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A933A68B4 for ; Wed, 22 Apr 2009 03:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 nPm6BTR7dt0c for ; Wed, 22 Apr 2009 03:23:42 -0700 (PDT) Received: from kafka.verkstad.net (kafka.v6lab.net [IPv6:2001:1b70:8142::2]) by core3.amsl.com (Postfix) with ESMTP id DD6BD3A6D0B for ; Wed, 22 Apr 2009 03:23:41 -0700 (PDT) Received: by kafka.verkstad.net (Postfix, from userid 20078) id B08A0710A15; Wed, 22 Apr 2009 12:24:58 +0200 (CEST) Date: Wed, 22 Apr 2009 12:24:58 +0200 From: Michael Eriksson To: George Tsirtsis Message-ID: <20090422102458.GD3296@kafka.verkstad.net> References: <20090421112907.GB20775@kafka.verkstad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: mext Subject: Re: [MEXT] One more try (was Re: clarification on flow binding documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 10:23:43 -0000 On Tue, Apr 21, 2009 at 14:36:20 +0200, George Tsirtsis wrote: > What you guys are proposing is architecturaly significantly different > from what this WG has agreed to do and what the Flow Bindings draft is > all about. > > For example, allowing the HA to send rules to the MN are both > significant departures from the current agreement. What "current agreement"? The mext charter /explicitly/ says that the flow routing rules should be sent in both directions: - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. Additionally, there has been explicit interest shown on this mailing list for sending flow routing rules also from HA to MN. > I would also point out that in theory there is nothing preventing us > from extending the Flow Bindings work to any of the directions you are > talking about, except from the fact that some of us might > disagree...especially with the HA sending rules to the MN part. That does not seem very constructive, if other people are interested in sending flow routing rules from the HA to the MN. Your MIP implementation is of course welcome to reject any incoming rules to the MN. > Instead of trying to reinvent the wheel, which will likely be futile, > I would suggest you wait for the new version of the Flow Bindings > draft. Then write a draft (or e-mail) proposing ways of extending Flow > Bindings with your desired features. Then, we can have a discussion > about whether such changes are useful and desirable. We have not "reinvented the wheel". We have done an alternative solution, which we think is technically superior due to advantages that I have listed in a separate e-mail. Regards, Michael From xiayangsong@huawei.com Wed Apr 22 06:26:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA8E3A714B for ; Wed, 22 Apr 2009 06:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[AWL=-1.511, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 RXuKcWueCAyZ for ; Wed, 22 Apr 2009 06:26:15 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5042D3A7141 for ; Wed, 22 Apr 2009 06:26: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 <0KII00IFW7KEU6@szxga04-in.huawei.com> for mext@ietf.org; Wed, 22 Apr 2009 21:17:02 +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 <0KII0024Q7KEIX@szxga04-in.huawei.com> for mext@ietf.org; Wed, 22 Apr 2009 21:17:02 +0800 (CST) Received: from X24512z ([10.51.0.58]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KII0004F7KBBW@szxml06-in.huawei.com> for mext@ietf.org; Wed, 22 Apr 2009 21:17:02 +0800 (CST) Date: Wed, 22 Apr 2009 08:16:58 -0500 From: Frank Xia To: mext@ietf.org Message-id: <001801c9c34c$9f4db2d0$4201a8c0@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.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_kj4rrgEQRQC48194ORDaIg)" X-Priority: 3 X-MSMail-priority: Normal Subject: [MEXT] new draft: Home Agent Initiated Flow Binding for Mobile IPv6 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:26:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_kj4rrgEQRQC48194ORDaIg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi guys We just submitted the draft http://www.ietf.org/internet-drafts/draft-xia-mext-ha-init-flow-binding-00.txt. Abstract This document defines two new Mobility Headers for a home agent to control flow binding in a mobile node. comments are very welcome! BR Frank --Boundary_(ID_kj4rrgEQRQC48194ORDaIg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi guys
 
We just submitted the draft
 
Abstract
   This document defines two new Mobility Headers
   for a home agent to  control flow binding in a mobile node.
 
comments are very welcome!
 
 
BR
Frank
 


 --Boundary_(ID_kj4rrgEQRQC48194ORDaIg)-- From behcetsarikaya@yahoo.com Wed Apr 22 07:48:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472223A6807 for ; Wed, 22 Apr 2009 07:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.517 X-Spam-Level: X-Spam-Status: No, score=-1.517 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 1+SvlsLQCOD0 for ; Wed, 22 Apr 2009 07:48:11 -0700 (PDT) Received: from n55.bullet.mail.sp1.yahoo.com (n55.bullet.mail.sp1.yahoo.com [98.136.44.188]) by core3.amsl.com (Postfix) with SMTP id CAE9D3A67BD for ; Wed, 22 Apr 2009 07:48:11 -0700 (PDT) Received: from [216.252.122.217] by n55.bullet.mail.sp1.yahoo.com with NNFMP; 22 Apr 2009 14:49:29 -0000 Received: from [68.142.230.29] by t2.bullet.sp1.yahoo.com with NNFMP; 22 Apr 2009 14:49:28 -0000 Received: from [67.195.9.81] by t2.bullet.re2.yahoo.com with NNFMP; 22 Apr 2009 14:49:28 -0000 Received: from [67.195.9.99] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 14:49:28 -0000 Received: from [127.0.0.1] by omp103.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 14:46:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 936986.38016.bm@omp103.mail.gq1.yahoo.com Received: (qmail 35286 invoked by uid 60001); 22 Apr 2009 14:49:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240411767; bh=1ieARVQX8bKupwMfMucyI99PBQLRXuRt9fX34f17uYM=; 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=EQsYTx3pMqI3GL9VBXKcR8z9BqBxITpCvojoJ2xBPw5IxcBlS9shLL/5oLhZhrE+dMJHK2VcSC74DD87F1loKPwFbhFlBDXYbHhlODkmmVjYaqWUOOtUFuA9+kTsPO6nBPmrzUzAW3v9OqSHztV/tBswlkag1uvMcj1dHNr6RLE= 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=1sF/BtsCQEin3nxtDwfYU50T4zXUpIM+o+KZ7Gqj3VX1EUCNym4//iMm8AWS7i05+4l39q9yMJsOy08rLSc6P9FyKRiN/n2GXYA5Ie1surXyTDozkGpe9V2ZmN8oBfvg3daiFcswMNRz054NsHI6aYyx7zxeCB/rCHN995AyQ/A=; Message-ID: <903041.35111.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: 6pLItjwVM1k5piZWFes324GXBMi0rOCqtTlCHwmWjGg0tiuVeu3Qzot14b7M5eqTknwpeNsvuTdnaNgJP6N_9c4ZUoWW1jzV12h_u3F4TcLPed3OqQNx3Vpy5dbCeuynuP1xZZZ81.yBIYEHgP57YlE.lWkHd78rnBDpTbKCs1rAVzceL9Rj_iebwPTkAp6krGGQ8hzfO_Y96iZiClVzOYpe_Eivaef7_hoJaKh4Abe6qJBlX7pGlFNb7biIeetv8TiXJ0ue4rbk5coXkePtxrUBWrXJXG4iRVh6PrSN6CZ0uC1NdmRgEDJyeH1kVMuJfjPW Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Wed, 22 Apr 2009 07:49:27 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <431126.68078.qm@web111407.mail.gq1.yahoo.com> <219059.99370.qm@web111414.mail.gq1.yahoo.com> Date: Wed, 22 Apr 2009 07:49:27 -0700 (PDT) From: Behcet Sarikaya To: Vijay Devarapalli In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-65840825-1240411767=:35111" Cc: mext@ietf.org Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 14:48:13 -0000 --0-65840825-1240411767=:35111 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Why not?=0AEach interface having a different HA is a viable scenario IMHO.= =0A=0AI think this is where MCoA assumptions start to crack.=0A=0A=0A=A0=0A= =0A=0A=0A________________________________=0AFrom: Vijay Devarapalli =0ATo: Behcet Sarikaya =0ASent: Tuesday, Ap= ril 21, 2009 2:09:57 PM=0ASubject: RE: [MEXT] [Fwd: I-D Action:draft-ietf-m= onami6-multiplecoa-13.txt]=0A=0A=0AHow is that relevant?=0A=0A=0A__________= ______________________=0AFrom: Behcet Sarikaya [mailto:behcetsarikaya@yahoo= ..com] =0ASent: Tuesday, April 21, 2009 12:09 PM=0ATo: Vijay Devarapalli; Be= hcet Sarikaya=0ASubject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-mul= tiplecoa-13.txt]=0A=0A=0APer MN.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A__= ______________________________=0AFrom: Vijay Devarapalli =0ATo: Behcet Sarikaya =0ASent: Tuesday, April 21, 200= 9 2:06:42 PM=0ASubject: RE: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-mult= iplecoa-13.txt]=0A=0A=0AHi Behcet,=0A=A0=0AWhat do=A0 you mean by single ho= me agent?=0A=A0=0AVijay=0A=0A=0A________________________________=0AFrom: Be= hcet Sarikaya [mailto:behcetsarikaya@yahoo.com] =0ASent: Tuesday, April 21,= 2009 12:04 PM=0ATo: Vijay Devarapalli=0ACc: mext=0ASubject: Re: [MEXT] [Fw= d: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A=0A=0ASo you are say= ing that there could be a single HA?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A= =0A________________________________=0AFrom: Vijay Devarapalli =0ATo: Behcet Sarikaya =0ACc: Ryuji Wakikawa ; mext =0ASent: Tuesday, April 21, 200= 9 1:58:07 PM=0ASubject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-mult= iplecoa-13.txt]=0A=0ABehcet,=0A=0ABehcet Sarikaya wrote:=0A> *[behcet] Yes = but each interface will appear to HA as a different device and HA needs to = assign a different HoA. Then MCoA problem disappears.*=0A> *So George is sa= ying that this is avoided by some virtual interfaces so that HA does not se= e each interface separately. *=0A> *Is this explained anywhere in the draft= ?*=0A> *If yes then I am OK.*=0A=0AThe home agent does not care about the m= ultiple interfaces on the mobile node. It only sees the mobile node as one = entity and allocates a home address to it. The multiple care-of addresses t= hat the mobile node has will be used by the home agent as tunnel end points= .. That is all. So there is no issue.=0A=0AVijay=0A=0A>=A0 >=A0 Also I have = a question to Ryuji: does this draft send a non-deregistration BU at the ho= me link? If yes, is he familiar with the discussion going on on this subjec= t? This is another point of confusion for me.=0A> =0A> This has been discus= sed for a long time in MEXT.=0A> who is familiar with which discussions? I = don't know your concern here.=0A>=A0 *[behcet] So your answer is yes the dr= aft sends a non-deregistration BU (kind of bulk registration) at the home l= ink.*=0A> *The discussion I mentioned was related to draft-premec-mext-exte= nded-home-link. This draft also sends non-deregistration BU at the home lin= k. So does a few more drafts like **draft-devarapalli-mext-mipv6-home-link.= *=0A> =0A> ** =0A> *[behcet] You mentioned some bit is set but I could not = understand which. One idea is since so many drafts need this, why not facto= r this out and define whatever the mechanism to enable sending non-deregist= ration BU in 3775bis. What do you think about that?*=0A> =0A> ** =0A> =0A>= =A0 >=A0 Sorry if I am too=A0 much confused=0A>=A0 > Please don't get me wr= ong, I am not trying to slow down the progress of this document..=0A> =0A> = sure, but please explain your issue more precisely.=0A> =0A> thanks!=0A> ry= uji=0A> =0A>=A0 >=0A>=A0 > Regards,=0A>=A0 >=0A>=A0 > Behcet=0A>=A0 > From:= marcelo bagnulo braun >=0A>= =A0 > To: mext >; Julien Laganier >; Jari Arkko >=0A>=A0= > Sent: Tuesday, April 21, 2009 11:03:05 AM=0A>=A0 > Subject: [MEXT] [Fwd:= I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A>=A0 >=0A>=A0 > We hav= e this new version of the MCOA document that addresses the comments receive= d, including IESG review comments.=0A>=A0 > To the best of my knowledge, th= e IESG is ok with the doc and ready for publication.=0A>=A0 > I am planning= to ask our AD to move forward in a week or so, so, if you have comments on= the document please provide them before the 1st of may.=0A>=A0 >=0A>=A0 > = Regards, marcelo=0A>=A0 > (mcoa doc shepherd)=0A>=A0 >=0A>=A0 > -------- Me= nsaje original --------=0A>=A0 > Asunto:=A0 =A0 [MEXT] I-D Action:draft-iet= f-monami6-multiplecoa-13.txt=0A>=A0 > Fecha:=A0 =A0 Mon, 20 Apr 2009 08:30:= 01 -0700 (PDT)=0A>=A0 > De:=A0 =A0 Internet-Drafts@ietf.org =0A>=A0 > Para:=A0 =A0 i-d-announce@ietf.org =0A>=A0 > CC:=A0 =A0 mext@ietf.org = =0A>=A0 >=0A>=A0 >=0A>=A0 >=0A>=A0 > A New Internet-Draft is available from= the on-line Internet-Drafts directories.=0A>=A0 > This draft is a work ite= m of the Mobility EXTensions for IPv6 Working Group of the IETF.=0A>=A0 >= =0A>=A0 >=0A>=A0 >=A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : Multiple Care-of Addre= sses Registration=0A>=A0 >=A0 =A0 Author(s)=A0 =A0 =A0 : R. Wakikawa, et al= ..=0A>=A0 >=A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-monami6-multiplecoa-= 13..txt=0A>=A0 >=A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 : 44=0A>=A0 >=A0 =A0 Date= =A0 =A0 =A0 =A0 =A0 =A0 : 2009-04-20=0A>=A0 >=0A>=A0 > According to the cur= rent Mobile IPv6 specification, a mobile node may=0A>=A0 > have several car= e-of addresses, but only one, called the primary=0A>=A0 > care-of address, = that can be registered with its home agent and the=0A>=A0 > correspondent n= odes.=A0 However, for matters of cost, bandwidth, delay,=0A>=A0 > etc, it i= s useful for the mobile node to get Internet access through=0A>=A0 > multip= le accesses simultaneously, in which case the mobile node would=0A>=A0 > be= configured with multiple active IPv6 care-of addresses.=A0 This=0A>=A0 > d= ocument proposes extensions to the Mobile IPv6 protocol to register=0A>=A0 = > and use multiple care-of addresses.=A0 The extensions proposed in this=0A= >=A0 > document can be used by Mobile Routers using the NEMO (Network=0A>= =A0 > Mobility) Basic Support protocol as well.=0A>=A0 >=0A>=A0 > A URL for= this Internet-Draft is:=0A>=A0 > http://www.ietf.org/internet-drafts/draft= -ietf-monami6-multiplecoa-13.txt=0A>=A0 >=0A>=A0 > Internet-Drafts are also= available by anonymous FTP at:=0A>=A0 > ftp://ftp.ietf.org/internet-drafts= /=0A>=A0 >=0A>=A0 > Below is the data which will enable a MIME compliant ma= il reader=0A>=A0 > implementation to automatically retrieve the ASCII versi= on of the=0A>=A0 > Internet-Draft.=0A>=A0 >=0A>=A0 >=0A>=A0 >=0A>=A0 > ____= ___________________________________________=0A>=A0 > MEXT mailing list=0A>= =A0 > MEXT@ietf.org =0A>=A0 > https://www.ietf.org/ma= ilman/listinfo/mext=0A> =0A> =0A> =0A> ------------------------------------= ------------------------------------=0A> =0A> _____________________________= __________________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.= ietf.org/mailman/listinfo/mext=0A=0A=0A --0-65840825-1240411767=:35111 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Why not?
=0A
Each interface having a differen= t HA is a viable scenario IMHO.
=0A
 
=0A
I think th= is is where MCoA assumptions start to crack.
=0A
 
=0A
 
=0A

=0A
=0A
=0AFrom: Vijay Devarapalli <vijay@wichorus.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Sent: Tuesday, April 21, 2009= 2:09:57 PM
Subject: RE:= [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
<= BR>=0A=0A=0A
How is that relevant?

=0A=0A
=0A
=0AFrom: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
= Sent: Tuesday, April 21, 2009 12:09 PM
To: Vijay Devarapalli;= Behcet Sarikaya
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-= monami6-multiplecoa-13.txt]

=0A
=0A
= =0A
Per MN.
=0A
 
=0A
Regards,
=0A
&nbs= p;
=0A
Behcet
=0A

=0A
=0A
=0AFro= m: Vijay Devarapalli <vijay@wichorus.com>
To: Behcet Sarikaya <sarikaya@ieee.or= g>
Sent: Tuesday, Apr= il 21, 2009 2:06:42 PM
Subject: RE: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]<= BR>
=0A=0A= =0A
Hi Behcet,
=0A
 
=0A
What do  you mean by single home agent?
=0A 
=0A
Vijay

=0A
=0A
=0A
=0AFrom: Behcet S= arikaya [mailto:behcetsarikaya@yahoo.com]
Sent: Tuesday, April 2= 1, 2009 12:04 PM
To: Vijay Devarapalli
Cc: mext
S= ubject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.t= xt]

=0A
=0A
=0A
So you are sayin= g that there could be a single HA?
=0A
 
=0A
Regards= ,
=0A
 
=0A
Behcet
=0A

=0A=0A
=0AFrom: Vijay Devarapalli <vijay@wichorus.com>
To: Behcet Sarikaya <sarikaya= @ieee.org>
Cc: Ryuji = Wakikawa <ryuji.wakikawa@gmail.com>; mext <mext@ietf.org>
Sent: Tuesday, April 21, 2009= 1:58:07 PM
Subject: Re:= [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
<= BR>Behcet,

Behcet Sarikaya wrote:
> *[behcet] Yes but each int= erface will appear to HA as a different device and HA needs to assign a dif= ferent HoA. Then MCoA problem disappears.*
> *So George is saying tha= t this is avoided by some virtual interfaces so that HA does not see each i= nterface separately. *
> *Is this explained anywhere in the draft?*> *If yes then I am OK.*

The home agent does not care about the multiple interfaces on the mobile node. It o= nly sees the mobile node as one entity and allocates a home address to it. = The multiple care-of addresses that the mobile node has will be used by the= home agent as tunnel end points. That is all. So there is no issue.
Vijay

>  >  Also I have a question to Ryuji: does t= his draft send a non-deregistration BU at the home link? If yes, is he fami= liar with the discussion going on on this subject? This is another point of= confusion for me.
>
> This has been discussed for a long time= in MEXT.
> who is familiar with which discussions? I don't know your= concern here.
>  *[behcet] So your answer is yes the draft send= s a non-deregistration BU (kind of bulk registration) at the home link.*> *The discussion I mentioned was related to draft-premec-mext-extended= -home-link. This draft also sends non-deregistration BU at the home link. So does a few more drafts like **draft-devarapalli-mext-mipv6-home-l= ink.*
>
> **
> *[behcet] You mentioned some bit is set = but I could not understand which. One idea is since so many drafts need thi= s, why not factor this out and define whatever the mechanism to enable send= ing non-deregistration BU in 3775bis. What do you think about that?*
>= ;
> **
>
>  >  Sorry if I am too  mu= ch confused
>  > Please don't get me wrong, I am not trying t= o slow down the progress of this document..
>
> sure, but plea= se explain your issue more precisely.
>
> thanks!
> ryuj= i
>
>  >
>  > Regards,
>  >= ;
>  > Behcet
>  > From: marcelo bagnulo braun = <marcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>>
> = > To: mext <mext@ietf.org <mailto:mext@ietf.org>>; Julien Laganier <julien.laganier.ietf= @googlemail.com <mailto:julien.laganier.ietf@googlemail.com>>; Jari= Arkko <jari.arkko@piuha.net <= ;mailto:jari.arkko@piuha.net>>
>&= nbsp; > Sent: Tuesday, April 21, 2009 11:03:05 AM
>  > Sub= ject: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
>= ;  >
>  > We have this new version of the MCOA docume= nt that addresses the comments received, including IESG review comments.>  > To the best of my knowledge, the IESG is ok with the doc a= nd ready for publication.
>  > I am planning to ask our AD to= move forward in a week or so, so, if you have comments on the document ple= ase provide them before the 1st of may.
>  >
>  &g= t; Regards, marcelo
>  > (mcoa doc shepherd)
>  &g= t;
>  > -------- Mensaje original --------
>  >= Asunto:    [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt
>  > Fecha:&nbs= p;   Mon, 20 Apr 2009 08:30:01 -0700 (PDT)
>  > De: = ;   Internet-Drafts@ietf.o= rg <mailto:Internet-Draf= ts@ietf.org>
>  > Para:    i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>  > CC:&n= bsp;   mext@ietf.org <mailto:mext@ietf.org>
&= gt;  >
>  >
>  >
>  > A N= ew Internet-Draft is available from the on-line Internet-Drafts directories= ..
>  > This draft is a work item of the Mobility EXTensions f= or IPv6 Working Group of the IETF.
>  >
>  >>  >    Title          : Mul= tiple Care-of Addresses Registration
>  >    Author= (s)      : R. Wakikawa, et al.
>  >  &nbs= p; Filename        : draft-ietf-monami6-multiplecoa-13.= ..txt
>  >    Pages         = ; : 44
>  >    Date        &nbs= p;   : 2009-04-20
>  >
>  > According to t= he current Mobile IPv6 specification, a mobile node may
>  > have several care-of addresses, but only one, called the primary
&= gt;  > care-of address, that can be registered with its home agent = and the
>  > correspondent nodes.  However, for matters = of cost, bandwidth, delay,
>  > etc, it is useful for the mob= ile node to get Internet access through
>  > multiple accesse= s simultaneously, in which case the mobile node would
>  > be= configured with multiple active IPv6 care-of addresses.  This
>=   > document proposes extensions to the Mobile IPv6 protocol to reg= ister
>  > and use multiple care-of addresses.  The exte= nsions proposed in this
>  > document can be used by Mobile R= outers using the NEMO (Network
>  > Mobility) Basic Support p= rotocol as well.
>  >
>  > A URL for this Inter= net-Draft is:
>  > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt<= BR>>  >
>  > Internet-Drafts are also available by= anonymous FTP at:
>  > ftp://ftp.ietf.org/internet-draft= s/
>  >
>  > Below is the data which will e= nable a MIME compliant mail reader
>  > implementation to aut= omatically retrieve the ASCII version of the
>  > Internet-Dr= aft.
>  >
>  >
>  >
> = > _______________________________________________
>  > ME= XT mailing list
>  > MEXT@ietf.org= <mailto:MEXT@ietf.org>
>  > = https://www.ietf.org/mailman/listinfo/mext
>
> >
> -----------------------------------------------------------= -------------
>
> ____________________________________________= ___
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext


Hi George,
=0A
  It seems in my pre= vious reply I replied to this mail of yours which was unrelated to the othe= r mail you sent to which I was really replying, apologies.
=0A
&nb= sp; Now regarding home link registration, what is the mechanism MCoA draft = uses? Ryuji mentioned some H bit but I read the draft and couldn't confirm = it.
=0A
 
=0A
  My suggestion was building on t= his, i.e. I suggested that whatever you came up with can be moved to 3775bi= s so that other people would not have to make normative references to your = draft.
=0A
 
=0A
That's all.
=0A
 =0A
Regards,
=0A
 
=0A
Behcet
=0A
=0A
=0A
=0AFrom: George Tsirtsis <tsirtsis@google= mail.com>
To: Vijay D= evarapalli <vijay@wichorus.com>
Cc: Behcet Sarikaya <sarikaya@ieee.org>; mext <mext@= ietf.org>
Sent: Tuesd= ay, April 21, 2009 2:14:55 PM
Subje= ct: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-1= 3.txt]

...also wrt the home link registration, I do not think= what you
suggest is necessary.

As far as I see the other documen= ts are informational, and they do not
yet have a formal standing in the = WG. If and when they do, as
Informational documents,  they should n= ot require normative changes to
anything. They should make sure what the= y describe (mostly
implementation options in this case) are compatible not only with
RFC3775 but also with extensions to it, includ= ing Flow Bindings. .


Regards
George

On Tue, Apr 21, 20= 09 at 7:58 PM, Vijay Devarapalli <vijay@wichorus.com> wrote:
= > Behcet,
>
> Behcet Sarikaya wrote:
>>
>>= *[behcet] Yes but each interface will appear to HA as a different device>> and HA needs to assign a different HoA. Then MCoA problem disapp= ears.*
>> *So George is saying that this is avoided by some virtua= l interfaces so
>> that HA does not see each interface separately.= *
>> *Is this explained anywhere in the draft?*
>> *If y= es then I am OK.*
>
> The home agent does not care about the mu= ltiple interfaces on the mobile
> node. It only sees the mobile node = as one entity and allocates a home
> address to it. The multiple care-of addresses that the mobile node has will
> be used by the hom= e agent as tunnel end points. That is all. So there is no
> issue.>
> Vijay
>
>>  >  Also I have a ques= tion to Ryuji: does this draft send a
>> non-deregistration BU at = the home link? If yes, is he familiar with the
>> discussion going= on on this subject? This is another point of confusion for
>> me.=
>>
>> This has been discussed for a long time in MEXT.>> who is familiar with which discussions? I don't know your concer= n here.
>>  *[behcet] So your answer is yes the draft sends a= non-deregistration BU
>> (kind of bulk registration) at the home = link.*
>> *The discussion I mentioned was related to
>> d= raft-premec-mext-extended-home-link. This draft also sends
>> non-= deregistration BU at the home link. So does a few more drafts like
>> **draft-devarapalli-mext-mipv6-home-link.*
>>>> **
>> *[behcet] You mentioned some bit is set but I coul= d not understand which.
>> One idea is since so many drafts need t= his, why not factor this out and
>> define whatever the mechanism = to enable sending non-deregistration BU in
>> 3775bis. What do you= think about that?*
>>
>> **
>>
>> &nbs= p;>  Sorry if I am too  much confused
>>  > P= lease don't get me wrong, I am not trying to slow down the progress of
&= gt;> this document..
>>
>> sure, but please explain yo= ur issue more precisely.
>>
>> thanks!
>> ryuji<= BR>>>
>>  >
>>  > Regards,
>&= gt;  >
>>  > Behcet
>>  > From: m= arcelo bagnulo braun <marcelo@it.uc3m.es
>> &= lt;mailto:marcelo@it.uc3m.es>>
>>  > To: mext &= lt;mext@i= etf.org <mailto:mext@ietf.org>>; Julien Laganier
>> <julien.laganier.ietf@googlemail.com>> <mailto:julien.laganier.iet= f@googlemail.com>>; Jari Arkko
>> <jari.arkko@pi= uha.net <mailto:jari.arkko@piuha.net>>>>  > Sent: Tuesday, April 21, 2009 11:03:05 AM
>>=  > Subject: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa= -13.txt]
>>  >
>>  > We have this new ver= sion of the MCOA document that addresses the
>> comments received,= including IESG review comments.
>>  > To the best of my k= nowledge, the IESG is ok with the doc and ready for
>> publication= ..
>>  > I am planning to ask our AD to move forward in a w= eek or so, so, if you
>> have comments on the document please prov= ide them before the 1st of may.
>>  >
>>  &g= t; Regards, marcelo
>>  > (mcoa doc shepherd)
>> =  >
>>  > -------- Mensaje original --------
>= ;>  > Asunto:    [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt
>>  > Fecha:=    Mon, 20 Apr 2009 08:30:01 -0700 (PDT)
>>  > = De:    Internet-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org>
>>  > Para:  = ;  i-d-announce@ietf.org <mailto:i-d-announce@iet= f.org>
>>  > CC:    mext@ietf.org <mailto:<= A href=3D"mailto:mext@ietf.org" ymailto=3D"mailto:mext@ietf.org">mext@ietf.= org>
>>  >
>>  >
>>  = ;>
>>  > A New Internet-Draft is available from the on-line Internet-Dra= fts
>> directories.
>>  > This draft is a work it= em of the Mobility EXTensions for IPv6 Working
>> Group of the IET= F.
>>  >
>>  >
>>  > &nb= sp;  Title          : Multiple Care-of Addres= ses Registration
>>  >    Author(s)    = ;  : R. Wakikawa, et al.
>>  >    Filename =        : draft-ietf-monami6-multiplecoa-13..txt
>= >  >    Pages          : 44>>  >    Date           =  : 2009-04-20
>>  >
>>  > According = to the current Mobile IPv6 specification, a mobile node may
>> &nb= sp;> have several care-of addresses, but only one, called the primary
>>  > care-of address, that can be registered wit= h its home agent and the
>>  > correspondent nodes.  = However, for matters of cost, bandwidth, delay,
>>  > etc,= it is useful for the mobile node to get Internet access through
>>= ;  > multiple accesses simultaneously, in which case the mobile nod= e would
>>  > be configured with multiple active IPv6 care= -of addresses.  This
>>  > document proposes extensio= ns to the Mobile IPv6 protocol to register
>>  > and use m= ultiple care-of addresses.  The extensions proposed in this
>>= ;  > document can be used by Mobile Routers using the NEMO (Network=
>>  > Mobility) Basic Support protocol as well.
>&g= t;  >
>>  > A URL for this Internet-Draft is:
&= gt;>  >
>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt<= BR>>>  >
>>  > Internet-Drafts are also avai= lable by anonymous FTP at:
>>  > ftp://ftp.ietf.org/internet-drafts/<= /A>
>>  >
>>  > Below is the data which w= ill enable a MIME compliant mail reader
>>  > implementati= on to automatically retrieve the ASCII version of the
>>  >= ; Internet-Draft.
>>  >
>>  >
>>=  >
>>  > ________________________________________= _______
>>  > MEXT mailing list
>>  > MEXT@ietf.or= g <mailto:MEXT@ietf.org>
>>  > https:= //www.ietf.org/mailman/listinfo/mext
>>
>>
>>= ;
>> -------------------------------------------------------------= -----------
>>
>> _______________________________________= ________
>> MEXT mailing list
>> MEXT@ietf.org
>> https:/= /www.ietf.org/mailman/listinfo/mext
>
> ___________________= ____________________________
> MEXT mailing list
> MEXT@ietf.org
= > https://www.ietf.org/mailman/listinfo/mext
>

=0A=0A --0-2099263579-1240412766=:92209-- From tsirtsis@googlemail.com Wed Apr 22 08:05:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310F428C4E9 for ; Wed, 22 Apr 2009 08:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 IiTl2P55a2P5 for ; Wed, 22 Apr 2009 08:05:14 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 1546128C1BB for ; Wed, 22 Apr 2009 08:05:14 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so8028yxb.49 for ; Wed, 22 Apr 2009 08:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=x4yc0AgudUvSWQmsxeP1JBrxJqYRtNP5ZrrK+8PcBtw=; b=S/WLjce08kbQgw+Xx1m8BEW5+mua31Kp+PkHnczPzzb2eahhU/IMy2aDLP9eKR34rw ZaGcrT1aBg6dhXBzIwB/EIucb5/lUSUiDJ8XQHiCkGuX+/ghhRf4qZg3YNrFscvLy3qo 6bB8EZu/FjFHkt2rjMHluZdVA/eriC9Lk0F5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Rtu92UgdMH88xW0QhYtF3hvHHASYj5SeTQzDTyJsmTVeDX+kdR/vuS64i9VeSUS+IJ 0DZ6+rEPFImA3l+H2pj+w4jRVx+DINN7FV9uSV02GfJDTL3ZLKll6GbxZ3P34x4vrbSJ xrQDnsefmx18r8sBcvCZJKjaEXPqeYsLhmnXE= MIME-Version: 1.0 Received: by 10.90.113.11 with SMTP id l11mr10410661agc.87.1240412790995; Wed, 22 Apr 2009 08:06:30 -0700 (PDT) In-Reply-To: <869311.39916.qm@web111412.mail.gq1.yahoo.com> References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <869311.39916.qm@web111412.mail.gq1.yahoo.com> Date: Wed, 22 Apr 2009 16:06:18 +0100 Message-ID: From: George Tsirtsis To: Behcet Sarikaya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 15:05:15 -0000 On Wed, Apr 22, 2009 at 3:59 PM, Behcet Sarikaya wrote: > Hi George, > =C2=A0 It seems like now you are telling the truth GT> I always try :-) > Basically MCoA draft wishes to establish some hierarchy of the interfaces= . > There is one which is the main interface (Vijay calls this main entity bu= t > as we ALL know addresses as Layer 3 identities=C2=A0are assigned to the > interfaces not the the entities). There are other interfaces=C2=A0which a= re the > lowest level interfaces. > MN does INE using the main interface. Uses IKEv2 and gets HoA assigned > establishes secure tunnel with the HA on this interface. > GT> Not sure what INE is > Somewhat magically the lowest level interfaces become active and connect = to > some other domains and get CoA1 then MCoA draft kicks in and starts > assigning these BIDs.. > GT> You are missing the fact that the lowest interface can actually come up first so that the MN gets a CoA, which is then using to bootstrap with the HA. > My suggestion is that the draft should explain this clearly in textual fo= rm. > GT> Behcet, all this is already known and obvious. We can add any number of obvious things to every document but I do not think it is useful. RFCs are not tutorials. The reader is expected to be familiar with the subject, especially when looking at an extension of a base protocol like MCoA is to MIP. > Regards, > > Behcet > ________________________________ > From: George Tsirtsis > To: Vijay Devarapalli > Cc: Behcet Sarikaya ; mext > Sent: Tuesday, April 21, 2009 2:14:55 PM > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.tx= t] > > ...also wrt the home link registration, I do not think what you > suggest is necessary. > > As far as I see the other documents are informational, and they do not > yet have a formal standing in the WG. If and when they do, as > Informational documents,=C2=A0 they should not require normative changes = to > anything. They should make sure what they describe (mostly > implementation options in this case) are compatible not only with > RFC3775 but also with extensions to it, including Flow Bindings. . > > > Regards > George > > > From tsirtsis@googlemail.com Wed Apr 22 08:08:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A5A28C525 for ; Wed, 22 Apr 2009 08:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 VXunJM12vHvP for ; Wed, 22 Apr 2009 08:08:51 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 1C3DC3A6CDA for ; Wed, 22 Apr 2009 08:08:51 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so10193yxb.49 for ; Wed, 22 Apr 2009 08:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=vZKB/sYCMpTo6cSb5eS9PoTG3RITul07531wfh7BLrM=; b=E6fEUuM33uT2JVay1Mp/uK+ScYUL8ic7BPKaxUfjmGyHUtLQvgNR0Vhlp44lR2Ys8P R8yj4w7ugB6iF81VaKCixknbbeTZcdbFMBERWCZVRH3pavdwm/YriaZ939LZo7rvY+67 7rvS6wUyU8pAGoVVOnm7CPYEBBuFeVuBEs0TY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FoYlTbZnFN3uqJbP+B8/IIWg+UveT4H2W1cpEimQdy9FAG1ouGckgJVuNYcFf3sPQL Gs4ELKR0V2srIO9NcEL02ahRejr7dZIaCMmvo64MHmbz+RaZNlz/q6SDLxuot6MV7/we lX92htV54IitZMPql252T+idssmNGFJvbtUt8= MIME-Version: 1.0 Received: by 10.90.75.13 with SMTP id x13mr10426173aga.71.1240413008112; Wed, 22 Apr 2009 08:10:08 -0700 (PDT) In-Reply-To: <61210.92209.qm@web111410.mail.gq1.yahoo.com> References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> Date: Wed, 22 Apr 2009 16:10:08 +0100 Message-ID: From: George Tsirtsis To: Behcet Sarikaya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 15:08:52 -0000 I do not think that adding home link registration to RFC3775bis is feasible= . This requires logic in the MN and HA that is not directly compatible to RFC3775. The aim of RFC3775bis is to make minimal changes for clarification reasons and to correct errors. Home Link Registration as defined in MCoA is neither. On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya wrote: > Hi George, > =C2=A0 It seems in my=C2=A0previous reply I replied to this mail of yours= which was > unrelated to the other mail you sent to which I was really replying, > apologies. > =C2=A0 Now regarding home link registration, what is the mechanism MCoA d= raft > uses? Ryuji mentioned some H bit but I read the draft and couldn't confir= m > it. > > =C2=A0 My suggestion was building on this, i.e. I suggested that whatever= you > came up with can be moved to 3775bis so that other people would not have = to > make normative references to your draft. > > That's all. > > Regards, > > Behcet > > ________________________________ > From: George Tsirtsis > To: Vijay Devarapalli > Cc: Behcet Sarikaya ; mext > Sent: Tuesday, April 21, 2009 2:14:55 PM > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.tx= t] > > ...also wrt the home link registration, I do not think what you > suggest is necessary. > > As far as I see the other documents are informational, and they do not > yet have a formal standing in the WG. If and when they do, as > Informational documents,=C2=A0 they should not require normative changes = to > anything. They should make sure what they describe (mostly > implementation options in this case) are compatible not only with > RFC3775 but also with extensions to it, including Flow Bindings. . > > > Regards > George > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli > wrote: >> Behcet, >> >> Behcet Sarikaya wrote: >>> >>> *[behcet] Yes but each interface will appear to HA as a different devic= e >>> and HA needs to assign a different HoA. Then MCoA problem disappears.* >>> *So George is saying that this is avoided by some virtual interfaces so >>> that HA does not see each interface separately. * >>> *Is this explained anywhere in the draft?* >>> *If yes then I am OK.* >> >> The home agent does not care about the multiple interfaces on the mobile >> node. It only sees the mobile node as one entity and allocates a home >> address to it. The multiple care-of addresses that the mobile node has >> will >> be used by the home agent as tunnel end points. That is all. So there is >> no >> issue. >> >> Vijay >> >>> =C2=A0> =C2=A0Also I have a question to Ryuji: does this draft send a >>> non-deregistration BU at the home link? If yes, is he familiar with the >>> discussion going on on this subject? This is another point of confusion >>> for >>> me. >>> >>> This has been discussed for a long time in MEXT. >>> who is familiar with which discussions? I don't know your concern here. >>> =C2=A0*[behcet] So your answer is yes the draft sends a non-deregistrat= ion BU >>> (kind of bulk registration) at the home link.* >>> *The discussion I mentioned was related to >>> draft-premec-mext-extended-home-link. This draft also sends >>> non-deregistration BU at the home link. So does a few more drafts like >>> **draft-devarapalli-mext-mipv6-home-link.* >>> >>> ** >>> *[behcet] You mentioned some bit is set but I could not understand whic= h. >>> One idea is since so many drafts need this, why not factor this out and >>> define whatever the mechanism to enable sending non-deregistration BU i= n >>> 3775bis. What do you think about that?* >>> >>> ** >>> >>> =C2=A0> =C2=A0Sorry if I am too =C2=A0much confused >>> =C2=A0> Please don't get me wrong, I am not trying to slow down the pro= gress >>> of >>> this document.. >>> >>> sure, but please explain your issue more precisely. >>> >>> thanks! >>> ryuji >>> >>> =C2=A0> >>> =C2=A0> Regards, >>> =C2=A0> >>> =C2=A0> Behcet >>> =C2=A0> From: marcelo bagnulo braun >> > >>> =C2=A0> To: mext >; Julien Laganie= r >>> >> >; Jari Arkko >>> > >>> =C2=A0> Sent: Tuesday, April 21, 2009 11:03:05 AM >>> =C2=A0> Subject: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>> =C2=A0> >>> =C2=A0> We have this new version of the MCOA document that addresses th= e >>> comments received, including IESG review comments. >>> =C2=A0> To the best of my knowledge, the IESG is ok with the doc and re= ady for >>> publication.. >>> =C2=A0> I am planning to ask our AD to move forward in a week or so, so= , if >>> you >>> have comments on the document please provide them before the 1st of may= . >>> =C2=A0> >>> =C2=A0> Regards, marcelo >>> =C2=A0> (mcoa doc shepherd) >>> =C2=A0> >>> =C2=A0> -------- Mensaje original -------- >>> =C2=A0> Asunto: =C2=A0 =C2=A0[MEXT] I-D Action:draft-ietf-monami6-multi= plecoa-13.txt >>> =C2=A0> Fecha: =C2=A0 =C2=A0Mon, 20 Apr 2009 08:30:01 -0700 (PDT) >>> =C2=A0> De: =C2=A0 =C2=A0Internet-Drafts@ietf.org >>> =C2=A0> Para: =C2=A0 =C2=A0i-d-announce@ietf.org >>> =C2=A0> CC: =C2=A0 =C2=A0mext@ietf.org >>> =C2=A0> >>> =C2=A0> >>> =C2=A0> >>> =C2=A0> A New Internet-Draft is available from the on-line Internet-Dra= fts >>> directories. >>> =C2=A0> This draft is a work item of the Mobility EXTensions for IPv6 W= orking >>> Group of the IETF. >>> =C2=A0> >>> =C2=A0> >>> =C2=A0> =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Multiple= Care-of Addresses Registration >>> =C2=A0> =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0: R. Wakikawa, et al= . >>> =C2=A0> =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-m= onami6-multiplecoa-13..txt >>> =C2=A0> =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 44 >>> =C2=A0> =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 20= 09-04-20 >>> =C2=A0> >>> =C2=A0> According to the current Mobile IPv6 specification, a mobile no= de may >>> =C2=A0> have several care-of addresses, but only one, called the primar= y >>> =C2=A0> care-of address, that can be registered with its home agent and= the >>> =C2=A0> correspondent nodes. =C2=A0However, for matters of cost, bandwi= dth, delay, >>> =C2=A0> etc, it is useful for the mobile node to get Internet access th= rough >>> =C2=A0> multiple accesses simultaneously, in which case the mobile node= would >>> =C2=A0> be configured with multiple active IPv6 care-of addresses. =C2= =A0This >>> =C2=A0> document proposes extensions to the Mobile IPv6 protocol to reg= ister >>> =C2=A0> and use multiple care-of addresses. =C2=A0The extensions propos= ed in this >>> =C2=A0> document can be used by Mobile Routers using the NEMO (Network >>> =C2=A0> Mobility) Basic Support protocol as well. >>> =C2=A0> >>> =C2=A0> A URL for this Internet-Draft is: >>> =C2=A0> >>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.t= xt >>> =C2=A0> >>> =C2=A0> Internet-Drafts are also available by anonymous FTP at: >>> =C2=A0> ftp://ftp.ietf.org/internet-drafts/ >>> =C2=A0> >>> =C2=A0> Below is the data which will enable a MIME compliant mail reade= r >>> =C2=A0> implementation to automatically retrieve the ASCII version of t= he >>> =C2=A0> Internet-Draft. >>> =C2=A0> >>> =C2=A0> >>> =C2=A0> >>> =C2=A0> _______________________________________________ >>> =C2=A0> MEXT mailing list >>> =C2=A0> MEXT@ietf.org >>> =C2=A0> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> -----------------------------------------------------------------------= - >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > From behcetsarikaya@yahoo.com Wed Apr 22 08:24:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC7D28C27F for ; Wed, 22 Apr 2009 08:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.414, 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 NnwW9ibtOuvo for ; Wed, 22 Apr 2009 08:24:53 -0700 (PDT) Received: from n2.bullet.mail.re3.yahoo.com (n2.bullet.mail.re3.yahoo.com [68.142.237.109]) by core3.amsl.com (Postfix) with SMTP id 4F79828C228 for ; Wed, 22 Apr 2009 08:24:53 -0700 (PDT) Received: from [68.142.230.29] by n2.bullet.mail.re3.yahoo.com with NNFMP; 22 Apr 2009 15:25:59 -0000 Received: from [67.195.9.81] by t2.bullet.re2.yahoo.com with NNFMP; 22 Apr 2009 15:25:58 -0000 Received: from [67.195.9.108] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 15:25:58 -0000 Received: from [127.0.0.1] by omp112.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 15:25:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 352788.35307.bm@omp112.mail.gq1.yahoo.com Received: (qmail 82550 invoked by uid 60001); 22 Apr 2009 15:25:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240413958; bh=uMu5Jbq9iJycfAgWGvti7+r0GfnVHzNP1EYBRcvKgD4=; 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=wdJfOTy/rSSIQONP442845fk7L2a7MulAfBLzHpveDp3GSi7oQUdlF+anSYEOmE6YENO4EtVb+7vGIptlLHbCCn4Kz2u1mjelIIvur5gHZAias+qCoi6PGPkOrqCMwY8wIaw3qUKXP070ABs0c4Dc3p9z2EVY+0hB+BqgciU54s= 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=r/Y0P1lJDL4zSmdbNZCx0Py4UPcyAZiVSrYA72QTORFJtwBGlG9chbbXI/4GqjmKJPASBjOT0uO2CAmUCnxTKDtlcOvTh13XU4pWp7zfBVLeXqLfqKIj7oM4A79eL/gNp0O19i5D94nddYNkI06LhYx5kTbNAAB4ef6dbrBSelY=; Message-ID: <92139.81999.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: m992r.MVM1nNGKmnP3.njwVXgdG43hbSafgvsVaFhCGjAchqK0V1e0hFfEeCAceKeCHgxM5MQVz.agKmP78ITxxtZtxIknUOThfuaMOPrOG1f_e0Vyv9DFbIkUZsu9Tcn136cjUVWIZJfWfwrwqrq44DCmlovJXRRNv43tmz_qI1YVwgVLkHvf_hsC_oW6JP5TFU8HbUNx2CaHzTGsLieDvCqtigSJ1lTa1lM5C6OEnlJnH2l4R3Pqs9w9i0INZfW4bP03nxCTw8Gv4UL1Y6DiNN7.M5S0rBykmW894tnpUHZqIyiUYl_ZuDgBjS1lJO.4xiLTZPqpE- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Wed, 22 Apr 2009 08:25:58 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <869311.39916.qm@web111412.mail.gq1.yahoo.com> Date: Wed, 22 Apr 2009 08:25:58 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1499751624-1240413958=:81999" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 15:24:54 -0000 --0-1499751624-1240413958=:81999 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So the first interface that does INE (initial network entry, SDO terminolog= y) becomes the main interface and grabs the HoA.=0AI don't think stating th= is basic assumption is not good. Many people including Vijay had some diffe= rent thoughts.=0A=0A--behcet=0A=0A=0A=0A=0A________________________________= =0AFrom: George Tsirtsis =0ATo: Behcet Sarikaya =0ACc: mext =0ASent: Wednesday, April 22, 2= 009 10:06:18 AM=0ASubject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-m= ultiplecoa-13.txt]=0A=0AOn Wed, Apr 22, 2009 at 3:59 PM, Behcet Sarikaya=0A= wrote:=0A> Hi George,=0A> =A0 It seems like now = you are telling the truth=0A=0AGT> I always try :-)=0A=0A> Basically MCoA d= raft wishes to establish some hierarchy of the interfaces.=0A> There is one= which is the main interface (Vijay calls this main entity but=0A> as we AL= L know addresses as Layer 3 identities=A0are assigned to the=0A> interfaces= not the the entities). There are other interfaces=A0which are the=0A> lowe= st level interfaces.=0A> MN does INE using the main interface. Uses IKEv2 a= nd gets HoA assigned=0A> establishes secure tunnel with the HA on this inte= rface.=0A>=0A=0AGT> Not sure what INE is=0A=0A> Somewhat magically the lowe= st level interfaces become active and connect to=0A> some other domains and= get CoA1 then MCoA draft kicks in and starts=0A> assigning these BIDs..=0A= >=0A=0AGT> You are missing the fact that the lowest interface can actually= =0Acome up first so that the MN gets a CoA, which is then using to=0Abootst= rap with the HA.=0A=0A> My suggestion is that the draft should explain this= clearly in textual form.=0A>=0A=0AGT> Behcet, all this is already known an= d obvious. We can add any=0Anumber of obvious things to every document but = I do not think it is=0Auseful. RFCs are not tutorials. The reader is expect= ed to be familiar=0Awith the subject, especially when looking at an extensi= on of a base=0Aprotocol like MCoA is to MIP.=0A=0A> Regards,=0A>=0A> Behcet= =0A> ________________________________=0A> From: George Tsirtsis =0A> To: Vijay Devarapalli =0A> Cc: Behce= t Sarikaya ; mext =0A> Sent: Tuesday, Apr= il 21, 2009 2:14:55 PM=0A> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-= monami6-multiplecoa-13.txt]=0A>=0A> ...also wrt the home link registration,= I do not think what you=0A> suggest is necessary.=0A>=0A> As far as I see = the other documents are informational, and they do not=0A> yet have a forma= l standing in the WG. If and when they do, as=0A> Informational documents,= =A0 they should not require normative changes to=0A> anything. They should = make sure what they describe (mostly=0A> implementation options in this cas= e) are compatible not only with=0A> RFC3775 but also with extensions to it,= including Flow Bindings. .=0A>=0A>=0A> Regards=0A> George=0A>=0A>=0A>=0A= =0A=0A=0A --0-1499751624-1240413958=:81999 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
So the first interface that does INE (initial network = entry, SDO terminology) becomes the main interface and grabs the HoA.
= =0A
I don't think stating this basic assumption is not good. Many peopl= e including Vijay had some different thoughts.
=0A
 
=0A=
--behcet
=0A

=0A
=0A<= HR SIZE=3D1>=0AFrom: George= Tsirtsis <tsirtsis@googlemail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: mext <mext@ietf.org>
<= B>Sent: Wednesday, April 22, 2= 009 10:06:18 AM
Subject:= Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

On Wed, Apr 22, 2009 at 3:59 PM, Behcet Sarikaya
<behcetsarikaya@yahoo.com> wrote:
> Hi George,
>   = It seems like now you are telling the truth

GT> I always try :-)<= BR>
> Basically MCoA draft wishes to establish some hierarchy of the = interfaces.
> There is one which is the main interface (Vijay calls t= his main entity but
> as we ALL know addresses as Layer 3 identities are assign= ed to the
> interfaces not the the entities). There are other interfa= ces which are the
> lowest level interfaces.
> MN does INE= using the main interface. Uses IKEv2 and gets HoA assigned
> establi= shes secure tunnel with the HA on this interface.
>

GT> Not= sure what INE is

> Somewhat magically the lowest level interface= s become active and connect to
> some other domains and get CoA1 then= MCoA draft kicks in and starts
> assigning these BIDs..
>
<= BR>GT> You are missing the fact that the lowest interface can actuallycome up first so that the MN gets a CoA, which is then using to
bootst= rap with the HA.

> My suggestion is that the draft should explain= this clearly in textual form.
>

GT> Behcet, all this is al= ready known and obvious. We can add any
number of obvious things to every document but I do not think it is
useful. RFCs are not tutoria= ls. The reader is expected to be familiar
with the subject, especially w= hen looking at an extension of a base
protocol like MCoA is to MIP.
<= BR>> Regards,
>
> Behcet
> ___________________________= _____
> From: George Tsirtsis <tsirtsis@googlemail.com<= /A>>
> To: Vijay Devarapalli <vijay@wichorus.com>
&g= t; Cc: Behcet Sarikaya <sarikaya@ieee.org>; mext <mext@ietf.org><= BR>> Sent: Tuesday, April 21, 2009 2:14:55 PM
> Subject: Re: [MEXT= ] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
>
> .= ...also wrt the home link registration, I do not think what you
> suggest is= necessary.
>
> As far as I see the other documents are informa= tional, and they do not
> yet have a formal standing in the WG. If an= d when they do, as
> Informational documents,  they should not r= equire normative changes to
> anything. They should make sure what th= ey describe (mostly
> implementation options in this case) are compat= ible not only with
> RFC3775 but also with extensions to it, includin= g Flow Bindings. .
>
>
> Regards
> George
>>
>

=0A=0A=0A=0A --0-1499751624-1240413958=:81999-- From tsirtsis@googlemail.com Wed Apr 22 08:28:08 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F7D28C265 for ; Wed, 22 Apr 2009 08:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 39rqLsc45sEc for ; Wed, 22 Apr 2009 08:28:07 -0700 (PDT) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by core3.amsl.com (Postfix) with ESMTP id 158DE3A6C0C for ; Wed, 22 Apr 2009 08:28:06 -0700 (PDT) Received: by gxk10 with SMTP id 10so48721gxk.13 for ; Wed, 22 Apr 2009 08:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=wKT3enLSSsAwloPa2plomKW1tAbmz/wDCs/TmxRhxvY=; b=DXDAHwE6h41Xi7jAJ5QjqPhZClqV+B6aZpumBNl48SKemTgP1EU+DuXEPJySCMqdmB 3Q+VAoU6DWvYXBjKmOYHFH+hyDO7R+dPwO/EaKjB1spS6kMdRwWTwzejbOdN1r0x+MdC LMcvJA+yk0CDNtmf2p/jKFrsSMLtVpk+KeW+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=V3AvSOc+PgcYAl/Q5yfcTGUjWHoAK0OCvLSvWq1VCpqxKxQG9gQo98nK7Hs8tzrS0N koeOzTr7ctD8T1T4gkSK8fD8e5sEW/izJNdOAss+gDQ3jOyG1DfRrWJJ6m2G7VrD507U KZHwJTidsJxbAH66o+TmgJvJnFd/uDUa2wAqU= MIME-Version: 1.0 Received: by 10.90.106.4 with SMTP id e4mr1446290agc.84.1240414148771; Wed, 22 Apr 2009 08:29:08 -0700 (PDT) In-Reply-To: <92139.81999.qm@web111404.mail.gq1.yahoo.com> References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <869311.39916.qm@web111412.mail.gq1.yahoo.com> <92139.81999.qm@web111404.mail.gq1.yahoo.com> Date: Wed, 22 Apr 2009 16:29:08 +0100 Message-ID: From: George Tsirtsis To: Behcet Sarikaya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 15:28:08 -0000 sigh... this is not what I said.... Also Vijay has the same thoughts with me on the subject...this does not happen often, but it does happen! On Wed, Apr 22, 2009 at 4:25 PM, Behcet Sarikaya wrote: > So the first interface that does INE (initial network entry, SDO > terminology) becomes the main interface and grabs the HoA. > I don't think stating this basic assumption is not good. Many people > including Vijay had some different thoughts. > > --behcet > > ________________________________ > From: George Tsirtsis > To: Behcet Sarikaya > Cc: mext > Sent: Wednesday, April 22, 2009 10:06:18 AM > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.tx= t] > > On Wed, Apr 22, 2009 at 3:59 PM, Behcet Sarikaya > wrote: >> Hi George, >> =C2=A0 It seems like now you are telling the truth > > GT> I always try :-) > >> Basically MCoA draft wishes to establish some hierarchy of the interface= s. >> There is one which is the main interface (Vijay calls this main entity b= ut >> as we ALL know addresses as Layer 3 identities=C2=A0are assigned to the >> interfaces not the the entities). There are other interfaces=C2=A0which = are the >> lowest level interfaces. >> MN does INE using the main interface. Uses IKEv2 and gets HoA assigned >> establishes secure tunnel with the HA on this interface. >> > > GT> Not sure what INE is > >> Somewhat magically the lowest level interfaces become active and connect >> to >> some other domains and get CoA1 then MCoA draft kicks in and starts >> assigning these BIDs.. >> > > GT> You are missing the fact that the lowest interface can actually > come up first so that the MN gets a CoA, which is then using to > bootstrap with the HA. > >> My suggestion is that the draft should explain this clearly in textual >> form. >> > > GT> Behcet, all this is already known and obvious. We can add any > number of obvious things to every document but I do not think it is > useful. RFCs are not tutorials. The reader is expected to be familiar > with the subject, especially when looking at an extension of a base > protocol like MCoA is to MIP. > >> Regards, >> >> Behcet >> ________________________________ >> From: George Tsirtsis >> To: Vijay Devarapalli >> Cc: Behcet Sarikaya ; mext >> Sent: Tuesday, April 21, 2009 2:14:55 PM >> Subject: Re: [MEXT] [Fwd: I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt] >> >> ....also wrt the home link registration, I do not think what you >> suggest is necessary. >> >> As far as I see the other documents are informational, and they do not >> yet have a formal standing in the WG. If and when they do, as >> Informational documents,=C2=A0 they should not require normative changes= to >> anything. They should make sure what they describe (mostly >> implementation options in this case) are compatible not only with >> RFC3775 but also with extensions to it, including Flow Bindings. . >> >> >> Regards >> George >> >> >> > > From marcelo@it.uc3m.es Wed Apr 22 08:28:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360AE28C228 for ; Wed, 22 Apr 2009 08:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361, 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 KuGkHPzOZ+hy for ; Wed, 22 Apr 2009 08:28:37 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5EA583A684F for ; Wed, 22 Apr 2009 08:28:37 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 45E2FBA0340; Wed, 22 Apr 2009 17:29:28 +0200 (CEST) Message-ID: <49EF37D8.2010408@it.uc3m.es> Date: Wed, 22 Apr 2009 17:29:28 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16598.000 Cc: Jari Arkko Subject: [MEXT] Moving forward with MEXT documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 15:28:38 -0000 Hi, At this point in time, the WG has the following documents that are ready for WGLC: draft-ietf-mext-firewall-admin-00 draft-ietf-mext-firewall-vendor-00 draft-ietf-mip6-hareliability-04 draft-ietf-monami6-mipv6-analysis-05 draft-ietf-monami6-multihoming-motivation-scenario-03 And the following document that we need to ask for adoption: draft-premec-mext-extended-home-link-01 According to our new ground rules, each of these documents to proceed will need 5 thorough reviews. Since this is a considerable amount of effort from the WG, we would like soem feedback on how to manage this effort. In particular, we would like to get feedback from the WG about which documents should we issue the WGLC or adoption call first and if possible volunteers to do the reviews for the documents. We will receive input on this till the 3rd of may and then decide how to move forward. Regards, marcelo From behcetsarikaya@yahoo.com Wed Apr 22 08:30:14 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29EF928C57E for ; Wed, 22 Apr 2009 08:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 DW5QV3sjkB+J for ; Wed, 22 Apr 2009 08:30:01 -0700 (PDT) Received: from n8.bullet.re3.yahoo.com (n8.bullet.re3.yahoo.com [68.142.237.93]) by core3.amsl.com (Postfix) with SMTP id 65E8F28C228 for ; Wed, 22 Apr 2009 08:30:01 -0700 (PDT) Received: from [68.142.237.89] by n8.bullet.re3.yahoo.com with NNFMP; 22 Apr 2009 15:31:18 -0000 Received: from [67.195.9.81] by t5.bullet.re3.yahoo.com with NNFMP; 22 Apr 2009 15:31:17 -0000 Received: from [67.195.9.111] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 15:31:17 -0000 Received: from [127.0.0.1] by omp115.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 15:31:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 130711.35724.bm@omp115.mail.gq1.yahoo.com Received: (qmail 21829 invoked by uid 60001); 22 Apr 2009 15:31:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240414277; bh=x0kIqpeRw+Qe1znNrlnUgR8SRKrlDKdP7ax/XbTgUM8=; 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=IoaYb+8b3fgS0tlX+e1fX3+HGBmQz1cEf+Le1eHamgJNIC5DbmiePTZNsw/ahvJbVpQ9i3etfH03ztnJZS54rpkM/pbLXIAZ2nI7zy+6lCq+gU7dUL2bQYHm7SLeeZuxrW+6tSLLKtlpzGN8pShjc1iYQ5Rpk8ZW9UD3ISvwIvY= 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=JZ5fis/Nx4Av2jFylX2ay3vOauX0sv29cKQ+R03O3iR7h0CjDV7duAIKNz4eSuRLLcvMNC8OzmaJUWK2C34aW0p7IPHOrc+9bI126PhyLugE5qybaBBp38pBpHI1OP2UaKcXjnW5XcfejS9dQ9ZQJHLDb6sYLofQiYWOIcl7rBY=; Message-ID: <375902.20727.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: 4EzVb_gVM1n3icQNoavtqLVZHcsLoKgPH_yREovA140kT6ypkDPU_aNAN8mTybuDHxAbwq6aeXXKx5aeGfXXSwaDyLHN542IfhqQDkYBNemngSkjAdEeHYRjZ44v1J.t0ZKO3A65tx.x55a_mhjD4lPohKJfHu2IlOEaZAJ64cpc3adbyO6pe8W5KUwzSzsdKcfiKlKsspV37gVhB2PWOylJg75UjeYPrD0UoMkEjnqfZBVAP7b5DGDvVv9duQjB1DjltTT2S1QLvd9ksnj.8XnGRu_ikWh3GDscCRc.z00xAXURHbxKrNnTT025BJJPy091 Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Wed, 22 Apr 2009 08:31:17 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> Date: Wed, 22 Apr 2009 08:31:17 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1237103063-1240414277=:20727" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 15:30:14 -0000 --0-1237103063-1240414277=:20727 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A________________________________=0A=0AFrom: George Tsirtsis =0ATo: Behcet Sarikaya =0ACc: mext= =0ASent: Wednesday, April 22, 2009 10:10:08 AM=0ASubject: R= e: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A=0A[beh= cet] Why not? If it is needed in so many instances, that qualifies it to be= come a base protocol feature, at least to me.=0AI do not think that adding = home link registration to RFC3775bis is feasible.=0AThis requires logic in = the MN and HA that is not directly compatible=0Ato RFC3775. The aim of RFC3= 775bis is to make minimal changes for=0Aclarification reasons and to correc= t errors. Home Link Registration as=0Adefined in MCoA is neither.=0A=0A=0AO= n Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya=0A wrote:=0A> Hi George,=0A> =A0 It seems in my=A0previous reply I replied t= o this mail of yours which was=0A> unrelated to the other mail you sent to = which I was really replying,=0A> apologies.=0A> =A0 Now regarding home link= registration, what is the mechanism MCoA draft=0A> uses? Ryuji mentioned s= ome H bit but I read the draft and couldn't confirm=0A> it.=0A>=0A> =A0 My = suggestion was building on this, i.e. I suggested that whatever you=0A> cam= e up with can be moved to 3775bis so that other people would not have to=0A= > make normative references to your draft.=0A>=0A> That's all.=0A>=0A> Rega= rds,=0A>=0A> Behcet=0A>=0A> ________________________________=0A> From: Geor= ge Tsirtsis =0A> To: Vijay Devarapalli =0A> Cc: Behcet Sarikaya ; mext = =0A> Sent: Tuesday, April 21, 2009 2:14:55 PM=0A> Subject: Re: [MEXT] [Fwd:= I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A>=0A> ...also wrt the = home link registration, I do not think what you=0A> suggest is necessary.= =0A>=0A> As far as I see the other documents are informational, and they do= not=0A> yet have a formal standing in the WG. If and when they do, as=0A> = Informational documents,=A0 they should not require normative changes to=0A= > anything. They should make sure what they describe (mostly=0A> implementa= tion options in this case) are compatible not only with=0A> RFC3775 but als= o with extensions to it, including Flow Bindings. .=0A>=0A>=0A> Regards=0A>= George=0A>=0A> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli =0A> wrote:=0A>> Behcet,=0A>>=0A>> Behcet Sarikaya wrote:=0A>>>= =0A>>> *[behcet] Yes but each interface will appear to HA as a different de= vice=0A>>> and HA needs to assign a different HoA. Then MCoA problem disapp= ears.*=0A>>> *So George is saying that this is avoided by some virtual inte= rfaces so=0A>>> that HA does not see each interface separately. *=0A>>> *Is= this explained anywhere in the draft?*=0A>>> *If yes then I am OK.*=0A>>= =0A>> The home agent does not care about the multiple interfaces on the mob= ile=0A>> node. It only sees the mobile node as one entity and allocates a h= ome=0A>> address to it. The multiple care-of addresses that the mobile node= has=0A>> will=0A>> be used by the home agent as tunnel end points. That is= all. So there is=0A>> no=0A>> issue.=0A>>=0A>> Vijay=0A>>=0A>>> =A0> =A0Al= so I have a question to Ryuji: does this draft send a=0A>>> non-deregistrat= ion BU at the home link? If yes, is he familiar with the=0A>>> discussion g= oing on on this subject? This is another point of confusion=0A>>> for=0A>>>= me.=0A>>>=0A>>> This has been discussed for a long time in MEXT.=0A>>> who= is familiar with which discussions? I don't know your concern here.=0A>>> = =A0*[behcet] So your answer is yes the draft sends a non-deregistration BU= =0A>>> (kind of bulk registration) at the home link.*=0A>>> *The discussion= I mentioned was related to=0A>>> draft-premec-mext-extended-home-link. Thi= s draft also sends=0A>>> non-deregistration BU at the home link. So does a = few more drafts like=0A>>> **draft-devarapalli-mext-mipv6-home-link.*=0A>>>= =0A>>> **=0A>>> *[behcet] You mentioned some bit is set but I could not und= erstand which.=0A>>> One idea is since so many drafts need this, why not fa= ctor this out and=0A>>> define whatever the mechanism to enable sending non= -deregistration BU in=0A>>> 3775bis. What do you think about that?*=0A>>>= =0A>>> **=0A>>>=0A>>> =A0> =A0Sorry if I am too =A0much confused=0A>>> =A0>= Please don't get me wrong, I am not trying to slow down the progress=0A>>>= of=0A>>> this document..=0A>>>=0A>>> sure, but please explain your issue m= ore precisely.=0A>>>=0A>>> thanks!=0A>>> ryuji=0A>>>=0A>>> =A0>=0A>>> =A0> = Regards,=0A>>> =A0>=0A>>> =A0> Behcet=0A>>> =A0> From: marcelo bagnulo brau= n >> >=0A>>> =A0> To: mex= t >; Julien Laganier=0A>>> >> >; Jari Arkko=0A>>> >= =0A>>> =A0> Sent: Tuesday, April 21, 2009 11:03:05 AM=0A>>> =A0> Subject: [= MEXT] [Fwd: I-D=0A>>> Action:draft-ietf-monami6-multiplecoa-13.txt]=0A>>> = =A0>=0A>>> =A0> We have this new version of the MCOA document that addresse= s the=0A>>> comments received, including IESG review comments.=0A>>> =A0> T= o the best of my knowledge, the IESG is ok with the doc and ready for=0A>>>= publication..=0A>>> =A0> I am planning to ask our AD to move forward in a = week or so, so, if=0A>>> you=0A>>> have comments on the document please pro= vide them before the 1st of may.=0A>>> =A0>=0A>>> =A0> Regards, marcelo=0A>= >> =A0> (mcoa doc shepherd)=0A>>> =A0>=0A>>> =A0> -------- Mensaje original= --------=0A>>> =A0> Asunto: =A0 =A0[MEXT] I-D Action:draft-ietf-monami6-mu= ltiplecoa-13.txt=0A>>> =A0> Fecha: =A0 =A0Mon, 20 Apr 2009 08:30:01 -0700 (= PDT)=0A>>> =A0> De: =A0 =A0Internet-Drafts@ietf.org =0A>>> =A0> Para: =A0 =A0i-d-announce@ietf.org =0A>>> =A0> CC: =A0 =A0mext@ietf.org =0A>= >> =A0>=0A>>> =A0>=0A>>> =A0>=0A>>> =A0> A New Internet-Draft is available = from the on-line Internet-Drafts=0A>>> directories.=0A>>> =A0> This draft i= s a work item of the Mobility EXTensions for IPv6 Working=0A>>> Group of th= e IETF.=0A>>> =A0>=0A>>> =A0>=0A>>> =A0> =A0 =A0Title =A0 =A0 =A0 =A0 =A0: = Multiple Care-of Addresses Registration=0A>>> =A0> =A0 =A0Author(s) =A0 =A0= =A0: R. Wakikawa, et al.=0A>>> =A0> =A0 =A0Filename =A0 =A0 =A0 =A0: draft= -ietf-monami6-multiplecoa-13..txt=0A>>> =A0> =A0 =A0Pages =A0 =A0 =A0 =A0 = =A0: 44=0A>>> =A0> =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-04-20=0A>>> = =A0>=0A>>> =A0> According to the current Mobile IPv6 specification, a mobil= e node may=0A>>> =A0> have several care-of addresses, but only one, called = the primary=0A>>> =A0> care-of address, that can be registered with its hom= e agent and the=0A>>> =A0> correspondent nodes. =A0However, for matters of = cost, bandwidth, delay,=0A>>> =A0> etc, it is useful for the mobile node to= get Internet access through=0A>>> =A0> multiple accesses simultaneously, i= n which case the mobile node would=0A>>> =A0> be configured with multiple a= ctive IPv6 care-of addresses. =A0This=0A>>> =A0> document proposes extensio= ns to the Mobile IPv6 protocol to register=0A>>> =A0> and use multiple care= -of addresses. =A0The extensions proposed in this=0A>>> =A0> document can b= e used by Mobile Routers using the NEMO (Network=0A>>> =A0> Mobility) Basic= Support protocol as well.=0A>>> =A0>=0A>>> =A0> A URL for this Internet-Dr= aft is:=0A>>> =A0>=0A>>> http://www.ietf.org/internet-drafts/draft-ietf-mon= ami6-multiplecoa-13.txt=0A>>> =A0>=0A>>> =A0> Internet-Drafts are also avai= lable by anonymous FTP at:=0A>>> =A0> ftp://ftp.ietf.org/internet-drafts/= =0A>>> =A0>=0A>>> =A0> Below is the data which will enable a MIME compliant= mail reader=0A>>> =A0> implementation to automatically retrieve the ASCII = version of the=0A>>> =A0> Internet-Draft.=0A>>> =A0>=0A>>> =A0>=0A>>> =A0>= =0A>>> =A0> _______________________________________________=0A>>> =A0> MEXT= mailing list=0A>>> =A0> MEXT@ietf.org =0A>>> =A0> ht= tps://www.ietf.org/mailman/listinfo/mext=0A>>>=0A>>>=0A>>>=0A>>> ----------= --------------------------------------------------------------=0A>>>=0A>>> = _______________________________________________=0A>>> MEXT mailing list=0A>= >> MEXT@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/mext=0A>>=0A>>= _______________________________________________=0A>> MEXT mailing list=0A>= > MEXT@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/mext=0A>>=0A>=0A= >=0A=0A=0A=0A --0-1237103063-1240414277=:20727 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A

=0A
=0A
=0A
=0A
From: George Tsirtsis <tsirtsis@googlemail.com>
To: Behcet Sarikaya <sarikaya@ieee.org= >
Cc: mext <mext@i= etf.org>
Sent: Wednes= day, April 22, 2009 10:10:08 AM
Sub= ject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa= -13.txt]

I do not think that adding home link registration to= RFC3775bis is feasible.
This requires logic in the MN and HA that is no= t directly compatible
to RFC3775. The aim of RFC3775bis is to make minim= al changes for
clarification reasons and to correct errors. Home Link Re= gistration as
defined in MCoA is neither.
=0A
[behcet] Why not? If it is needed in so many inst= ances, that qualifies it to become a base protocol feature, at least to me.=
=
=0A
=0A

On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya<behcetsarikaya@yahoo.com> wrote:
> Hi Georg= e,
>   It seems in my previous reply I replied to this mail= of yours which was
> unrelated to the other mail you sent to which I= was really replying,
> apologies.
>   Now regarding home = link registration, what is the mechanism MCoA draft
> uses? Ryuji men= tioned some H bit but I read the draft and couldn't confirm
> it.
= >
>   My suggestion was building on this, i.e. I suggested th= at whatever you
> came up with can be moved to 3775bis so that other = people would not have to
> make normative references to your draft.>
> That's all.
>
> Regards,
>
> Behcet<= BR>>
> ________________________________
> From: George Tsirtsis <tsirtsis@googlemail.com>
> To: Vijay Devarapalli <vija= y@wichorus.com>
> Cc: Behcet Sarikaya <sarikaya@ieee.org= >; mext <mext@ietf.org>
> Sent: Tuesday, April 21, 2009 2:14:55 P= M
> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplec= oa-13.txt]
>
> ...also wrt the home link registration, I do not= think what you
> suggest is necessary.
>
> As far as I s= ee the other documents are informational, and they do not
> yet have = a formal standing in the WG. If and when they do, as
> Informational documents,  they should not require normative changes to
> anyt= hing. They should make sure what they describe (mostly
> implementati= on options in this case) are compatible not only with
> RFC3775 but a= lso with extensions to it, including Flow Bindings. .
>
>
&g= t; Regards
> George
>
> On Tue, Apr 21, 2009 at 7:58 PM, = Vijay Devarapalli <vijay@wichorus.com>
> wrote:
>>= ; Behcet,
>>
>> Behcet Sarikaya wrote:
>>>>>> *[behcet] Yes but each interface will appear to HA as a diffe= rent device
>>> and HA needs to assign a different HoA. Then MC= oA problem disappears.*
>>> *So George is saying that this is a= voided by some virtual interfaces so
>>> that HA does not see e= ach interface separately. *
>>> *Is this explained anywhere in the draft?*
>>> *If yes then I am OK.*
>>
>&= gt; The home agent does not care about the multiple interfaces on the mobil= e
>> node. It only sees the mobile node as one entity and allocate= s a home
>> address to it. The multiple care-of addresses that the= mobile node has
>> will
>> be used by the home agent as = tunnel end points. That is all. So there is
>> no
>> issu= e.
>>
>> Vijay
>>
>>>  > &nb= sp;Also I have a question to Ryuji: does this draft send a
>>> = non-deregistration BU at the home link? If yes, is he familiar with the
= >>> discussion going on on this subject? This is another point of = confusion
>>> for
>>> me.
>>>
>&g= t;> This has been discussed for a long time in MEXT.
>>> who= is familiar with which discussions? I don't know your concern here.
>>>  *[behcet] So your answer is yes the draft send= s a non-deregistration BU
>>> (kind of bulk registration) at th= e home link.*
>>> *The discussion I mentioned was related to>>> draft-premec-mext-extended-home-link. This draft also sends>>> non-deregistration BU at the home link. So does a few more d= rafts like
>>> **draft-devarapalli-mext-mipv6-home-link.*
&g= t;>>
>>> **
>>> *[behcet] You mentioned some = bit is set but I could not understand which.
>>> One idea is si= nce so many drafts need this, why not factor this out and
>>> d= efine whatever the mechanism to enable sending non-deregistration BU in
= >>> 3775bis. What do you think about that?*
>>>
>= ;>> **
>>>
>>>  >  Sorry if I am= too  much confused
>>>  > Please don't get me wrong, I am not trying to slow down the progress
>>> of
= >>> this document..
>>>
>>> sure, but plea= se explain your issue more precisely.
>>>
>>> thank= s!
>>> ryuji
>>>
>>>  >
>= >>  > Regards,
>>>  >
>>> &nb= sp;> Behcet
>>>  > From: marcelo bagnulo braun <<= A href=3D"mailto:marcelo@it.uc3m.es" ymailto=3D"mailto:marcelo@it.uc3m.es">= marcelo@it.uc3m.es
>>> <mailto:marcelo@it.uc3m.es&g= t;>
>>>  > To: mext <mext@ietf.org <mailto:mext@ietf.org>>; Julien Laganier
>>> <julien.laganier.ietf@googlemail.com>>> <mailto:julien.laganier= ..ietf@googlemail.com>>; Jari Arkko
>>> <jari.= arkko@piuha.net <mailto:jari.arkko@piuha.net>>
>= ;>>  > Sent: Tuesday, April 21, 2009 11:03:05 AM
>>&= gt;  > Subject: [MEXT] [Fwd: I-D
>>> Action:draft-ietf-= monami6-multiplecoa-13.txt]
>>>  >
>>> &nbs= p;> We have this new version of the MCOA document that addresses the
= >>> comments received, including IESG review comments.
>>= >  > To the best of my knowledge, the IESG is ok with the doc and re= ady for
>>> publication..
>>>  > I am plann= ing to ask our AD to move forward in a week or so, so, if
>>> y= ou
>>> have comments on the document please provide them before= the 1st of may.
>>>  >
>>>  > Rega= rds, marcelo
>>>  > (mcoa doc shepherd)
>>>=  >
>>>  > -------- Mensaje original -------->>>  > Asunto:    [MEXT] I-D Action:draft-ietf= -monami6-multiplecoa-13.txt
>>>  > Fecha:    = Mon, 20 Apr 2009 08:30:01 -0700 (PDT)
>>>  > De:  =  Internet-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org&g= t;
>>>  > Para:    i-d-announce@ietf.o= rg <mailto:i-d-announce@ietf.org>
>>> &nbs= p;> CC:    mext@ietf.org <mailto:mext@ietf.org>
>>> &n= bsp;>
>>>  >
>>>  >
>>&= gt;  > A New Internet-Draft is available from the on-line Internet-= Drafts
>>> directories.
>>>  > This draft i= s a work item of the Mobility EXTensions for IPv6 Working
>>> G= roup of the IETF.
>>>  >
>>>  >
>>>  >    Title     &nb= sp;    : Multiple Care-of Addresses Registration
>>> =  >    Author(s)      : R. Wakikawa, et al.=
>>>  >    Filename       &nbs= p;: draft-ietf-monami6-multiplecoa-13..txt
>>>  >  = ;  Pages          : 44
>>>  = >    Date            : 2009-04-2= 0
>>>  >
>>>  > According to the cu= rrent Mobile IPv6 specification, a mobile node may
>>>  &g= t; have several care-of addresses, but only one, called the primary
>= >>  > care-of address, that can be registered with its home a= gent and the
>>>  > correspondent nodes.  However,= for matters of cost, bandwidth, delay,
>>>  > etc, it is useful for the mobile node to get Internet access through
&g= t;>>  > multiple accesses simultaneously, in which case the m= obile node would
>>>  > be configured with multiple act= ive IPv6 care-of addresses.  This
>>>  > document = proposes extensions to the Mobile IPv6 protocol to register
>>>=  > and use multiple care-of addresses.  The extensions propos= ed in this
>>>  > document can be used by Mobile Router= s using the NEMO (Network
>>>  > Mobility) Basic Suppor= t protocol as well.
>>>  >
>>>  > A= URL for this Internet-Draft is:
>>>  >
>>>= http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt<= BR>>>>  >
>>>  > Internet-Drafts are a= lso available by anonymous FTP at:
>>>  > ftp://ftp.iet= f.org/internet-drafts/
>>>  >
>>>  = ;> Below is the data which will enable a MIME compliant mail reader
&= gt;>>  > implementation to automatically retrieve the ASCII v= ersion of the
>>>  > Internet-Draft.
>>> &n= bsp;>
>>>  >
>>>  >
>>&= gt;  > _______________________________________________
>>&= gt;  > MEXT mailing list
>>>  > MEXT@ietf.org <ma= ilto:MEXT= @ietf.org>
>>>  > https://www.ietf.org/mailman/listi= nfo/mext
>>>
>>>
>>>
>>>= ; ------------------------------------------------------------------------>>>
>>> ____________________________________________= ___
>>> MEXT mailing list
>>> MEXT@ietf.org
>>&= gt; = https://www.ietf.org/mailman/listinfo/mext
>>
>> ____= ___________________________________________
>> MEXT mailing list>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listinfo/mext<= BR>>>
>
>

=0A=0A --0-1237103063-1240414277=:20727-- From behcetsarikaya@yahoo.com Wed Apr 22 13:01:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4903B3A6B4B for ; Wed, 22 Apr 2009 13:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.412, 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 HLvvMVHPB1+9 for ; Wed, 22 Apr 2009 13:01:37 -0700 (PDT) Received: from n71.bullet.mail.sp1.yahoo.com (n71.bullet.mail.sp1.yahoo.com [98.136.44.36]) by core3.amsl.com (Postfix) with SMTP id CD3673A6C21 for ; Wed, 22 Apr 2009 13:01:30 -0700 (PDT) Received: from [216.252.122.216] by n71.bullet.mail.sp1.yahoo.com with NNFMP; 22 Apr 2009 20:02:48 -0000 Received: from [67.195.9.82] by t1.bullet.sp1.yahoo.com with NNFMP; 22 Apr 2009 20:02:48 -0000 Received: from [67.195.9.100] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 20:02:48 -0000 Received: from [127.0.0.1] by omp104.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 20:02:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 18747.11476.bm@omp104.mail.gq1.yahoo.com Received: (qmail 81601 invoked by uid 60001); 22 Apr 2009 20:02:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240430568; bh=+G8VDnYI4MLIPmW+b5Z3kNPghh/CeDgRdgQ7kfVUNZg=; 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=NIEyApq2E+t4cV+jkkc0zluo6I9zQrBaqC3t8f4tsVaCni0wTwkJQuEeA5hqzSGc/n75B/AE5da8xhwNpqPPepuyoinkN4tOekloyHD5vb+R7WX7sjwTBDOCr4KgRKVe5mZL9GxoVmoh0yLlUvuDEtD7hWl+eUNsIhuoZ+jCTbI= 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=jxDll7zeMh1yX9sjNyx1wE94uCPezJaNKzR0YKy9/hueXZxyfAG6v2o56K+5VWiZXJfgDa5AGyJRpx1g8zXF5hhEY5uyGXrocQyFpR7Ub2swLGReqKabY97gfkEp1mRO+OAnIIAOCwksV160vnAn9XwmEtdG/EtycdgGfaUcTjw=; Message-ID: <96848.91350.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: H755MhYVM1kiES.T2AMFRQ_3ifDOaUZOKSf4EKKTWGOZdFBEXOZ6Iop8HGf9wbg8KZ_Kqgw1B_dMx31.UZk2dToHZEVDmEsZLt8264f8J4ST4cmabtlFG2pqg61r1bUfEYFFPqtLKAKpPNl10jJgdzaZoeYRS9yVJ_0eMhcYjIL5AP870IspGelx1xWLNnPDeZGv3tc1GNNlxZqwwsLBgFrofu3s3r_nplDLuoXRAEkHu5S6bKe4OhnHVURGb64LToTSbZUnDJjdjJs7O49SS_0LVMGXu1pgiT9Zu_4Dk3F8ekNx1YDwRKr1unFG.ivO_CVxlHr0n4A- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Wed, 22 Apr 2009 13:02:47 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <869311.39916.qm@web111412.mail.gq1.yahoo.com> <92139.81999.qm@web111404.mail.gq1.yahoo.com> Date: Wed, 22 Apr 2009 13:02:47 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2033643042-1240430567=:91350" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 20:01:38 -0000 --0-2033643042-1240430567=:91350 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable George, =0A=0A=A0=A0 I checked 3775, =0AHome Address A unicast routable add= ress assigned to a mobile node, used as the=0A=A0=A0=A0=A0=A0 permanent add= ress of the mobile node.=0A=0AHoA can be used as source addresses in IP pac= kets and it=A0is not Host=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Identity T= ag (HIT)=A0of HIP, as Vijay may possibly wish to identify.=0A=0ARFC 5026 de= fines how HoA can be configured from the prefix and IID just like any IPv6 = address. This address is assigned to the interface with which MN connects t= o the home link.=0A=0AHIT on the other hand is also of the same length but = it is generated from HI using hashed encoding. It is not an IPv6 address.= =0A=0A=0ABR,=0A=0ABehcet=A0=0A=0A=0A________________________________=0AFrom= : George Tsirtsis =0ATo: Behcet Sarikaya =0ACc: mext =0ASent: Wednesday, April 22, 2009 10:= 29:08 AM=0ASubject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiple= coa-13.txt]=0A=0Asigh... this is not what I said....=0AAlso Vijay has the s= ame thoughts with me on the subject...this does=0Anot happen often, but it = does happen!=0A=0AOn Wed, Apr 22, 2009 at 4:25 PM, Behcet Sarikaya=0A wrote:=0A> So the first interface that does INE (initi= al network entry, SDO=0A> terminology) becomes the main interface and grabs= the HoA.=0A> I don't think stating this basic assumption is not good. Many= people=0A> including Vijay had some different thoughts.=0A>=0A> --behcet= =0A>=0A> ________________________________=0A> From: George Tsirtsis =0A> To: Behcet Sarikaya =0A> Cc: mext= =0A> Sent: Wednesday, April 22, 2009 10:06:18 AM=0A> Subjec= t: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A>= =0A> On Wed, Apr 22, 2009 at 3:59 PM, Behcet Sarikaya=0A> wrote:=0A>> Hi George,=0A>> =A0 It seems like now you are telling= the truth=0A>=0A> GT> I always try :-)=0A>=0A>> Basically MCoA draft wishe= s to establish some hierarchy of the interfaces.=0A>> There is one which is= the main interface (Vijay calls this main entity but=0A>> as we ALL know a= ddresses as Layer 3 identities=A0are assigned to the=0A>> interfaces not th= e the entities). There are other interfaces=A0which are the=0A>> lowest lev= el interfaces.=0A>> MN does INE using the main interface. Uses IKEv2 and ge= ts HoA assigned=0A>> establishes secure tunnel with the HA on this interfac= e.=0A>>=0A>=0A> GT> Not sure what INE is=0A>=0A>> Somewhat magically the lo= west level interfaces become active and connect=0A>> to=0A>> some other dom= ains and get CoA1 then MCoA draft kicks in and starts=0A>> assigning these = BIDs..=0A>>=0A>=0A> GT> You are missing the fact that the lowest interface = can actually=0A> come up first so that the MN gets a CoA, which is then usi= ng to=0A> bootstrap with the HA.=0A>=0A>> My suggestion is that the draft s= hould explain this clearly in textual=0A>> form.=0A>>=0A>=0A> GT> Behcet, a= ll this is already known and obvious. We can add any=0A> number of obvious = things to every document but I do not think it is=0A> useful. RFCs are not = tutorials. The reader is expected to be familiar=0A> with the subject, espe= cially when looking at an extension of a base=0A> protocol like MCoA is to = MIP.=0A>=0A>> Regards,=0A>>=0A>> Behcet=0A>> ______________________________= __=0A>> From: George Tsirtsis =0A>> To: Vijay Deva= rapalli =0A>> Cc: Behcet Sarikaya ; = mext =0A>> Sent: Tuesday, April 21, 2009 2:14:55 PM=0A>> Sub= ject: Re: [MEXT] [Fwd: I-D=0A>> Action:draft-ietf-monami6-multiplecoa-13.tx= t]=0A>>=0A>> ....also wrt the home link registration, I do not think what y= ou=0A>> suggest is necessary.=0A>>=0A>> As far as I see the other documents= are informational, and they do not=0A>> yet have a formal standing in the = WG. If and when they do, as=0A>> Informational documents,=A0 they should no= t require normative changes to=0A>> anything. They should make sure what th= ey describe (mostly=0A>> implementation options in this case) are compatibl= e not only with=0A>> RFC3775 but also with extensions to it, including Flow= Bindings. .=0A>>=0A>>=0A>> Regards=0A>> George=0A>>=0A>>=0A>>=0A>=0A>=0A= =0A=0A=0A --0-2033643042-1240430567=:91350 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
George,
=0A
 
=0A
  = I checked 3775,
=0A
Home Address A unicast routable address assi= gned to a mobile node, used as the
      perman= ent address of the mobile node.
=0A
HoA can be used as so= urce addresses in IP packets and it is not Host
   &= nbsp;         Identity Tag (HIT)&nb= sp;of HIP, as Vijay may possibly wish to identify.
=0A
 =
=0A
RFC 5026 defines how HoA can be configured from the pref= ix and IID just like any IPv6 address. This address is assigned to the inte= rface with which MN connects to the home link.
=0A
 =0A
HIT on the other hand is also of the same length but it is g= enerated from HI using hashed encoding. It is not an IPv6 address.
=0A=
 
=0A
 
=0A
BR,
=0A 
=0A
Behcet 
=0A
=0A
=0AFrom: George Tsirtsis <tsirtsis@googlemail.com>
To: Behcet Sarikaya <sarikaya@ieee.org= >
Cc: mext <mext@i= etf.org>
Sent: Wednes= day, April 22, 2009 10:29:08 AM
Sub= ject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa= -13.txt]

sigh... this is not what I said....
Also Vijay ha= s the same thoughts with me on the subject...this does
not happen often,= but it does happen!

On Wed, Apr 22, 2009 at 4:25 PM, Behcet Sarikay= a
<behcetsarikaya@yahoo.com> wrote:
> So th= e first interface that does INE (initial network entry, SDO
> termino= logy) becomes the main interface and grabs the HoA.
> I don't think stating this basic assumption is not = good. Many people
> including Vijay had some different thoughts.
&= gt;
> --behcet
>
> ________________________________
&g= t; From: George Tsirtsis <tsirtsis@googlemail.com>
= > To: Behcet Sarikaya <sarikaya@ieee.org>
> Cc: mext &l= t;mext@ie= tf.org>
> Sent: Wednesday, April 22, 2009 10:06:18 AM
> = Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=
>
> On Wed, Apr 22, 2009 at 3:59 PM, Behcet Sarikaya
> &= lt;behcetsarikaya@yahoo.com> wrote:
>> Hi George,
>>   It seems like now you are telling the truth
= >
> GT> I always try :-)
>
>> Basically MCoA dra= ft wishes to establish some hierarchy of the interfaces.
>> There = is one which is the main interface (Vijay calls this main entity but
>= ;> as we ALL know addresses as Layer 3 identities are assigned to t= he
>> interfaces not the the entities). There are other interfaces=  which are the
>> lowest level interfaces.
>> MN doe= s INE using the main interface. Uses IKEv2 and gets HoA assigned
>>= ; establishes secure tunnel with the HA on this interface.
>>
&= gt;
> GT> Not sure what INE is
>
>> Somewhat magica= lly the lowest level interfaces become active and connect
>> to>> some other domains and get CoA1 then MCoA draft kicks in and star= ts
>> assigning these BIDs..
>>
>
> GT> You are missing the fact that the lowest interface can actually
= > come up first so that the MN gets a CoA, which is then using to
>= ; bootstrap with the HA.
>
>> My suggestion is that the draf= t should explain this clearly in textual
>> form.
>>
&= gt;
> GT> Behcet, all this is already known and obvious. We can ad= d any
> number of obvious things to every document but I do not think= it is
> useful. RFCs are not tutorials. The reader is expected to be= familiar
> with the subject, especially when looking at an extension= of a base
> protocol like MCoA is to MIP.
>
>> Regard= s,
>>
>> Behcet
>> _____________________________= ___
>> From: George Tsirtsis <tsirtsis@googlemail.co= m>
>> To: Vijay Devarapalli <v= ijay@wichorus.com>
>> Cc: Behcet Sarikaya <sarikaya@ieee.= org>; mext <mext@ietf.org>
>> Sent: Tuesday, April 21, 200= 9 2:14:55 PM
>> Subject: Re: [MEXT] [Fwd: I-D
>> Action:d= raft-ietf-monami6-multiplecoa-13.txt]
>>
>> ....also wrt = the home link registration, I do not think what you
>> suggest is = necessary.
>>
>> As far as I see the other documents are = informational, and they do not
>> yet have a formal standing in th= e WG. If and when they do, as
>> Informational documents,  th= ey should not require normative changes to
>> anything. They shoul= d make sure what they describe (mostly
>> implementation options i= n this case) are compatible not only with
>> RFC3775 but also with = extensions to it, including Flow Bindings. .
>>
>>
>= ;> Regards
>> George
>>
>>
>>
>= ;
>

=0A=0A --0-2033643042-1240430567=:91350-- From ryuji.wakikawa@gmail.com Wed Apr 22 14:17:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D9B3A6F6E for ; Wed, 22 Apr 2009 14:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 Bm2ZGJomK7u7 for ; Wed, 22 Apr 2009 14:17:55 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id DD1633A6F77 for ; Wed, 22 Apr 2009 14:17:13 -0700 (PDT) Received: by qyk42 with SMTP id 42so394983qyk.29 for ; Wed, 22 Apr 2009 14:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=YYQGUw3bACzXQGoqGxQUb8apTkRpvsWAFUyb6HeHgbc=; b=ZNV+UazSJ++CRtQ7YkUEPSTnXdp8q3aHc6tI2McZBku0XYvKL7kXWwomcbh45JxBwa /H/Q2dc1k6sKsa98RhRz3u63HoYa6s5VPbEuyJiFuqvsaWrt6GJRuDsXbl8eMEGmKTCk mX691PoMV42SvKL/IRyJNfqfwhmU0u1AtrBns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=GEBx1yC08r0NMPEksv6X7b4bm70EFZpkU0qPCTqIb92zgTlaFBozY4FDIdRNuSU8gY Ou/TYBohnL4zYlU3+CDHCG2SM2Dj6lhORo4UAfAOusloA9b42IAwUmVvXIfDHpAQqEho zHSSoMP2dWGB+i4CZoRlZbQ7djufHSdPtM+cE= Received: by 10.224.45.141 with SMTP id e13mr429616qaf.165.1240435111106; Wed, 22 Apr 2009 14:18:31 -0700 (PDT) Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id 4sm1496083yxj.17.2009.04.22.14.18.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Apr 2009 14:18:30 -0700 (PDT) From: Ryuji Wakikawa To: Behcet Sarikaya In-Reply-To: <375902.20727.qm@web111403.mail.gq1.yahoo.com> References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> <375902.20727.qm@web111403.mail.gq1.yahoo.com> Message-Id: <8CF30647-6A19-4391-BE7E-CFE87EFD8EAD@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 17:18:28 -0400 X-Mailer: Apple Mail (2.930.3) Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:17:57 -0000 Hi Behcet, On 2009/04/22, at 11:31, Behcet Sarikaya wrote: > > > From: George Tsirtsis > To: Behcet Sarikaya > Cc: mext > Sent: Wednesday, April 22, 2009 10:10:08 AM > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > I do not think that adding home link registration to RFC3775bis is > feasible. > This requires logic in the MN and HA that is not directly compatible > to RFC3775. The aim of RFC3775bis is to make minimal changes for > clarification reasons and to correct errors. Home Link Registration as > defined in MCoA is neither. > [behcet] Why not? If it is needed in so many instances, that > qualifies it to become a base protocol feature, at least to me. We cannot add a new feature to 3775. That is the ground rule of -bis. The chairs can clarify this. regards, ryuji > > On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya > wrote: > > Hi George, > > It seems in my previous reply I replied to this mail of yours > which was > > unrelated to the other mail you sent to which I was really replying, > > apologies. > > Now regarding home link registration, what is the mechanism MCoA > draft > > uses? Ryuji mentioned some H bit but I read the draft and couldn't > confirm > > it. > > > > My suggestion was building on this, i.e. I suggested that > whatever you > > came up with can be moved to 3775bis so that other people would > not have to > > make normative references to your draft. > > > > That's all. > > > > Regards, > > > > Behcet > > > > ________________________________ > > From: George Tsirtsis > > To: Vijay Devarapalli > > Cc: Behcet Sarikaya ; mext > > Sent: Tuesday, April 21, 2009 2:14:55 PM > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > ...also wrt the home link registration, I do not think what you > > suggest is necessary. > > > > As far as I see the other documents are informational, and they do > not > > yet have a formal standing in the WG. If and when they do, as > > Informational documents, they should not require normative > changes to > > anything. They should make sure what they describe (mostly > > implementation options in this case) are compatible not only with > > RFC3775 but also with extensions to it, including Flow Bindings. . > > > > > > Regards > > George > > > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli > > > wrote: > >> Behcet, > >> > >> Behcet Sarikaya wrote: > >>> > >>> *[behcet] Yes but each interface will appear to HA as a > different device > >>> and HA needs to assign a different HoA. Then MCoA problem > disappears.* > >>> *So George is saying that this is avoided by some virtual > interfaces so > >>> that HA does not see each interface separately. * > >>> *Is this explained anywhere in the draft?* > >>> *If yes then I am OK.* > >> > >> The home agent does not care about the multiple interfaces on the > mobile > >> node. It only sees the mobile node as one entity and allocates a > home > >> address to it. The multiple care-of addresses that the mobile > node has > >> will > >> be used by the home agent as tunnel end points. That is all. So > there is > >> no > >> issue. > >> > >> Vijay > >> > >>> > Also I have a question to Ryuji: does this draft send a > >>> non-deregistration BU at the home link? If yes, is he familiar > with the > >>> discussion going on on this subject? This is another point of > confusion > >>> for > >>> me. > >>> > >>> This has been discussed for a long time in MEXT. > >>> who is familiar with which discussions? I don't know your > concern here. > >>> *[behcet] So your answer is yes the draft sends a non- > deregistration BU > >>> (kind of bulk registration) at the home link.* > >>> *The discussion I mentioned was related to > >>> draft-premec-mext-extended-home-link. This draft also sends > >>> non-deregistration BU at the home link. So does a few more > drafts like > >>> **draft-devarapalli-mext-mipv6-home-link.* > >>> > >>> ** > >>> *[behcet] You mentioned some bit is set but I could not > understand which. > >>> One idea is since so many drafts need this, why not factor this > out and > >>> define whatever the mechanism to enable sending non- > deregistration BU in > >>> 3775bis. What do you think about that?* > >>> > >>> ** > >>> > >>> > Sorry if I am too much confused > >>> > Please don't get me wrong, I am not trying to slow down the > progress > >>> of > >>> this document.. > >>> > >>> sure, but please explain your issue more precisely. > >>> > >>> thanks! > >>> ryuji > >>> > >>> > > >>> > Regards, > >>> > > >>> > Behcet > >>> > From: marcelo bagnulo braun >>> > > >>> > To: mext >; Julien > Laganier > >>> >>> >; Jari Arkko > >>> > > >>> > Sent: Tuesday, April 21, 2009 11:03:05 AM > >>> > Subject: [MEXT] [Fwd: I-D > >>> Action:draft-ietf-monami6-multiplecoa-13.txt] > >>> > > >>> > We have this new version of the MCOA document that addresses > the > >>> comments received, including IESG review comments. > >>> > To the best of my knowledge, the IESG is ok with the doc and > ready for > >>> publication.. > >>> > I am planning to ask our AD to move forward in a week or so, > so, if > >>> you > >>> have comments on the document please provide them before the 1st > of may. > >>> > > >>> > Regards, marcelo > >>> > (mcoa doc shepherd) > >>> > > >>> > -------- Mensaje original -------- > >>> > Asunto: [MEXT] I-D Action:draft-ietf-monami6- > multiplecoa-13.txt > >>> > Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) > >>> > De: Internet-Drafts@ietf.org > > >>> > Para: i-d-announce@ietf.org > >>> > CC: mext@ietf.org > >>> > > >>> > > >>> > > >>> > A New Internet-Draft is available from the on-line Internet- > Drafts > >>> directories. > >>> > This draft is a work item of the Mobility EXTensions for IPv6 > Working > >>> Group of the IETF. > >>> > > >>> > > >>> > Title : Multiple Care-of Addresses Registration > >>> > Author(s) : R. Wakikawa, et al. > >>> > Filename : draft-ietf-monami6-multiplecoa-13..txt > >>> > Pages : 44 > >>> > Date : 2009-04-20 > >>> > > >>> > According to the current Mobile IPv6 specification, a mobile > node may > >>> > have several care-of addresses, but only one, called the > primary > >>> > care-of address, that can be registered with its home agent > and the > >>> > correspondent nodes. However, for matters of cost, > bandwidth, delay, > >>> > etc, it is useful for the mobile node to get Internet access > through > >>> > multiple accesses simultaneously, in which case the mobile > node would > >>> > be configured with multiple active IPv6 care-of addresses. > This > >>> > document proposes extensions to the Mobile IPv6 protocol to > register > >>> > and use multiple care-of addresses. The extensions proposed > in this > >>> > document can be used by Mobile Routers using the NEMO (Network > >>> > Mobility) Basic Support protocol as well. > >>> > > >>> > A URL for this Internet-Draft is: > >>> > > >>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.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. > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > MEXT mailing list > >>> > MEXT@ietf.org > >>> > https://www.ietf.org/mailman/listinfo/mext > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Wed Apr 22 14:21:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1F43A6F29 for ; Wed, 22 Apr 2009 14:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 7GSWvHl0IIKW for ; Wed, 22 Apr 2009 14:21:41 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id E038D28C2AC for ; Wed, 22 Apr 2009 14:21:29 -0700 (PDT) Received: by qyk42 with SMTP id 42so398832qyk.29 for ; Wed, 22 Apr 2009 14:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=CdwIQBSWs4dOGV424u0uG2aDJIEbwgoWGRZ4gWIWzAU=; b=KcUyAE1bSl1/kdLzGVSffVgIMQBYD367bclWm+tWpHd8jsmf71SeVQQ23JUqEym8zO 526dOHRR8X4e924MudMgEJpnGqyJ9sahIPXXwg/gWDp7qS3ZugmuKS/SxMlc7HT2FPqc EVvH4VkS301FUJ3rRQhqrbcCMMMW8/N05EqiM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=QR3ZsjdsyUFybUTLz7Ow0X13Bsd/Ad9xqweQkhpblAB9eimaMi5f27PdobG5iQlvFF h4HbeYKQEkl2+JWxm76/DZTlw68+/EJCb04848c79afcuP8UrjlsPRr2N8rzSgYWRUOf gfJhQdwZBB7g5jhsBkZ4vrtT8lHbdgxsL9y5I= Received: by 10.224.28.73 with SMTP id l9mr397151qac.288.1240435365817; Wed, 22 Apr 2009 14:22:45 -0700 (PDT) Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id 34sm423509yxm.21.2009.04.22.14.22.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Apr 2009 14:22:45 -0700 (PDT) From: Ryuji Wakikawa To: Behcet Sarikaya In-Reply-To: <96848.91350.qm@web111411.mail.gq1.yahoo.com> References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <869311.39916.qm@web111412.mail.gq1.yahoo.com> <92139.81999.qm@web111404.mail.gq1.yahoo.com> <96848.91350.qm@web111411.mail.gq1.yahoo.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 17:22:43 -0400 X-Mailer: Apple Mail (2.930.3) Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:21:42 -0000 Hi Behet. We don't treat HoA as HIT in MCoA, but just follows how RFC3775 defines HoA. regards, ryuji On 2009/04/22, at 16:02, Behcet Sarikaya wrote: > George, > > I checked 3775, > Home Address A unicast routable address assigned to a mobile node, > used as the > permanent address of the mobile node. > HoA can be used as source addresses in IP packets and it is not Host > Identity Tag (HIT) of HIP, as Vijay may possibly wish > to identify. > > RFC 5026 defines how HoA can be configured from the prefix and IID > just like any IPv6 address. This address is assigned to the > interface with which MN connects to the home link. > > HIT on the other hand is also of the same length but it is generated > from HI using hashed encoding. It is not an IPv6 address. > > > BR, > > Behcet > From: George Tsirtsis > To: Behcet Sarikaya > Cc: mext > Sent: Wednesday, April 22, 2009 10:29:08 AM > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > sigh... this is not what I said.... > Also Vijay has the same thoughts with me on the subject...this does > not happen often, but it does happen! > > On Wed, Apr 22, 2009 at 4:25 PM, Behcet Sarikaya > wrote: > > So the first interface that does INE (initial network entry, SDO > > terminology) becomes the main interface and grabs the HoA. > > I don't think stating this basic assumption is not good. Many people > > including Vijay had some different thoughts. > > > > --behcet > > > > ________________________________ > > From: George Tsirtsis > > To: Behcet Sarikaya > > Cc: mext > > Sent: Wednesday, April 22, 2009 10:06:18 AM > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > On Wed, Apr 22, 2009 at 3:59 PM, Behcet Sarikaya > > wrote: > >> Hi George, > >> It seems like now you are telling the truth > > > > GT> I always try :-) > > > >> Basically MCoA draft wishes to establish some hierarchy of the > interfaces. > >> There is one which is the main interface (Vijay calls this main > entity but > >> as we ALL know addresses as Layer 3 identities are assigned to the > >> interfaces not the the entities). There are other interfaces > which are the > >> lowest level interfaces. > >> MN does INE using the main interface. Uses IKEv2 and gets HoA > assigned > >> establishes secure tunnel with the HA on this interface. > >> > > > > GT> Not sure what INE is > > > >> Somewhat magically the lowest level interfaces become active and > connect > >> to > >> some other domains and get CoA1 then MCoA draft kicks in and starts > >> assigning these BIDs.. > >> > > > > GT> You are missing the fact that the lowest interface can actually > > come up first so that the MN gets a CoA, which is then using to > > bootstrap with the HA. > > > >> My suggestion is that the draft should explain this clearly in > textual > >> form. > >> > > > > GT> Behcet, all this is already known and obvious. We can add any > > number of obvious things to every document but I do not think it is > > useful. RFCs are not tutorials. The reader is expected to be > familiar > > with the subject, especially when looking at an extension of a base > > protocol like MCoA is to MIP. > > > >> Regards, > >> > >> Behcet > >> ________________________________ > >> From: George Tsirtsis > >> To: Vijay Devarapalli > >> Cc: Behcet Sarikaya ; mext > >> Sent: Tuesday, April 21, 2009 2:14:55 PM > >> Subject: Re: [MEXT] [Fwd: I-D > >> Action:draft-ietf-monami6-multiplecoa-13.txt] > >> > >> ....also wrt the home link registration, I do not think what you > >> suggest is necessary. > >> > >> As far as I see the other documents are informational, and they > do not > >> yet have a formal standing in the WG. If and when they do, as > >> Informational documents, they should not require normative > changes to > >> anything. They should make sure what they describe (mostly > >> implementation options in this case) are compatible not only with > >> RFC3775 but also with extensions to it, including Flow Bindings. . > >> > >> > >> Regards > >> George > >> > >> > >> > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From behcetsarikaya@yahoo.com Wed Apr 22 14:40:15 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB993A70A4 for ; Wed, 22 Apr 2009 14:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 INFh-Y7O3TBh for ; Wed, 22 Apr 2009 14:40:14 -0700 (PDT) Received: from n10.bullet.re3.yahoo.com (n10.bullet.re3.yahoo.com [68.142.237.123]) by core3.amsl.com (Postfix) with SMTP id 4CC3D3A6C2E for ; Wed, 22 Apr 2009 14:40:14 -0700 (PDT) Received: from [68.142.230.29] by n10.bullet.re3.yahoo.com with NNFMP; 22 Apr 2009 21:41:31 -0000 Received: from [67.195.9.83] by t2.bullet.re2.yahoo.com with NNFMP; 22 Apr 2009 21:41:31 -0000 Received: from [67.195.9.108] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 21:41:31 -0000 Received: from [127.0.0.1] by omp112.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 21:41:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 10000.73143.bm@omp112.mail.gq1.yahoo.com Received: (qmail 19676 invoked by uid 60001); 22 Apr 2009 21:41:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240436490; bh=DhvJyDHRmHwY2a5h3fq1MfGLi2DwZC7YRj93BzNKt8E=; 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=4V6on643997CHovYIk7/yDtevh+7Oz4SCMVYK/+XZp9+2lajNHAnDntuqD7NP7oQAvowGxpbGtyYBctkcIfqTrHzeKhTHic8t1ZO8gEPi15uc+dHyiejYCM2dDm6QCtz/zZ/Paj3eWvqIuwsHgZeig6AIHPCJ/v9Ww+smyJfY2I= 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=Ap9fSiG/CybkeVoBTh0eGtEuXf38uiO5oDjUWlOKfSLNvJBtpK8HqXIoMHoLAk4/yu4FRimCKhmOR8okV54sta027htT4KCHMSNX0Leb7jsDXc57gbLFB/XXp6tUMwJYNd0aVsT8DnNJRf8YmUNJot9cahwakpxGgJYQasRlzvI=; Message-ID: <764540.19643.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: .vinJMgVM1nrWkXC19D9oeXXcbclMUHm47SD84cmInWyJ6jSfbD4aDjKnHnQ8zL3Nenit6IABBia3doZ8yKctN4IA2dfF232cOQs6Vz8jRr7n0ikj8LyGIzNLfH6yA0MlgoKaC5ibVkQNKnPBQx.rPBCYmme_Pw7oBkYp2Hf.zCR36IO2_rCVCc_ZaqEezP.ANmzzXn_dkh79CdTkX1ADwhI9Oe60pOg9NBbcvQVEDpwUCX1zqMDPo_QBflBXw0mtzFHzjBV1JfUtqXJecT3g4OlrumPGkXZ0HMOxGpDsNoRB_RCvIchjmQWL6khrOhsgDGJzDrtRDA- Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Wed, 22 Apr 2009 14:41:30 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <869311.39916.qm@web111412.mail.gq1.yahoo.com> <92139.81999.qm@web111404.mail.gq1.yahoo.com> <96848.91350.qm@web111411.mail.gq1.yahoo.com> Date: Wed, 22 Apr 2009 14:41:30 -0700 (PDT) From: Behcet Sarikaya To: Ryuji Wakikawa In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-511870484-1240436490=:19643" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:40:16 -0000 --0-511870484-1240436490=:19643 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ryuji,=0A=A0 So you agree that a clarification is needed regarding the m= ain interface and other or auxiliary interfaces that I was trying to expres= s in my previous mails. =0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A__________= ______________________=0AFrom: Ryuji Wakikawa =0A= To: Behcet Sarikaya =0ACc: George Tsirtsis ; mext =0ASent: Wednesday, April 22, 2009 4:22:4= 3 PM=0ASubject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-= 13.txt]=0A=0AHi Behet.=0A=0AWe don't treat HoA as HIT in MCoA, but just fol= lows how RFC3775 defines HoA.=0A=0Aregards,=0Aryuji=0A=0A=0AOn 2009/04/22, = at 16:02, Behcet Sarikaya wrote:=0A=0A> George,=0A> =0A>=A0 =A0 I checked 3= 775,=0A> Home Address A unicast routable address assigned to a mobile node,= used as the=0A>=A0 =A0 =A0 permanent address of the mobile node.=0A> HoA c= an be used as source addresses in IP packets and it is not Host=0A>=A0 =A0 = =A0 =A0 =A0 =A0 =A0 Identity Tag (HIT) of HIP, as Vijay may possibly wish t= o identify.=0A> =0A> RFC 5026 defines how HoA can be configured from the pr= efix and IID just like any IPv6 address. This address is assigned to the in= terface with which MN connects to the home link.=0A> =0A> HIT on the other = hand is also of the same length but it is generated from HI using hashed en= coding. It is not an IPv6 address.=0A> =0A> =0A> BR,=0A> =0A> Behcet=0A> Fr= om: George Tsirtsis =0A> To: Behcet Sarikaya =0A> Cc: mext =0A> Sent: Wednesday, April 22, = 2009 10:29:08 AM=0A> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami= 6-multiplecoa-13.txt]=0A> =0A> sigh... this is not what I said....=0A> Also= Vijay has the same thoughts with me on the subject...this does=0A> not hap= pen often, but it does happen!=0A> =0A> On Wed, Apr 22, 2009 at 4:25 PM, Be= hcet Sarikaya=0A> wrote:=0A> > So the first inte= rface that does INE (initial network entry, SDO=0A> > terminology) becomes = the main interface and grabs the HoA.=0A> > I don't think stating this basi= c assumption is not good. Many people=0A> > including Vijay had some differ= ent thoughts.=0A> >=0A> > --behcet=0A> >=0A> > ____________________________= ____=0A> > From: George Tsirtsis =0A> > To: Behcet= Sarikaya =0A> > Cc: mext =0A> > Sent: We= dnesday, April 22, 2009 10:06:18 AM=0A> > Subject: Re: [MEXT] [Fwd: I-D Act= ion:draft-ietf-monami6-multiplecoa-13.txt]=0A> >=0A> > On Wed, Apr 22, 2009= at 3:59 PM, Behcet Sarikaya=0A> > wrote:=0A> >>= Hi George,=0A> >>=A0 It seems like now you are telling the truth=0A> >=0A>= > GT> I always try :-)=0A> >=0A> >> Basically MCoA draft wishes to establi= sh some hierarchy of the interfaces.=0A> >> There is one which is the main = interface (Vijay calls this main entity but=0A> >> as we ALL know addresses= as Layer 3 identities are assigned to the=0A> >> interfaces not the the en= tities). There are other interfaces which are the=0A> >> lowest level inter= faces.=0A> >> MN does INE using the main interface. Uses IKEv2 and gets HoA= assigned=0A> >> establishes secure tunnel with the HA on this interface.= =0A> >>=0A> >=0A> > GT> Not sure what INE is=0A> >=0A> >> Somewhat magicall= y the lowest level interfaces become active and connect=0A> >> to=0A> >> so= me other domains and get CoA1 then MCoA draft kicks in and starts=0A> >> as= signing these BIDs..=0A> >>=0A> >=0A> > GT> You are missing the fact that t= he lowest interface can actually=0A> > come up first so that the MN gets a = CoA, which is then using to=0A> > bootstrap with the HA.=0A> >=0A> >> My su= ggestion is that the draft should explain this clearly in textual=0A> >> fo= rm.=0A> >>=0A> >=0A> > GT> Behcet, all this is already known and obvious. W= e can add any=0A> > number of obvious things to every document but I do not= think it is=0A> > useful. RFCs are not tutorials. The reader is expected t= o be familiar=0A> > with the subject, especially when looking at an extensi= on of a base=0A> > protocol like MCoA is to MIP.=0A> >=0A> >> Regards,=0A> = >>=0A> >> Behcet=0A> >> ________________________________=0A> >> From: Georg= e Tsirtsis =0A> >> To: Vijay Devarapalli =0A> >> Cc: Behcet Sarikaya ; mext =0A> >> Sent: Tuesday, April 21, 2009 2:14:55 PM=0A> >> Subject: Re: [= MEXT] [Fwd: I-D=0A> >> Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> >>= =0A> >> ....also wrt the home link registration, I do not think what you=0A= > >> suggest is necessary.=0A> >>=0A> >> As far as I see the other document= s are informational, and they do not=0A> >> yet have a formal standing in t= he WG. If and when they do, as=0A> >> Informational documents,=A0 they shou= ld not require normative changes to=0A> >> anything. They should make sure = what they describe (mostly=0A> >> implementation options in this case) are = compatible not only with=0A> >> RFC3775 but also with extensions to it, inc= luding Flow Bindings. .=0A> >>=0A> >>=0A> >> Regards=0A> >> George=0A> >>= =0A> >>=0A> >>=0A> >=0A> >=0A> =0A> _______________________________________= ________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.ietf.org/m= ailman/listinfo/mext=0A=0A=0A --0-511870484-1240436490=:19643 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ryuji,
=0A
  So you agree that a clar= ification is needed regarding the main interface and other or auxiliary int= erfaces that I was trying to express in my previous mails.
=0A
&n= bsp;
=0A
Regards,
=0A
 
=0A
Behcet
=0A

=0A
=0A
=0AFrom: Ryuji Wakikawa <ryuji.wak= ikawa@gmail.com>
To: = Behcet Sarikaya <sarikaya@ieee.org>
Cc: George Tsirtsis <tsirtsis@googlemail.com>; mext= <mext@ietf.org>
Sent:= Wednesday, April 22, 2009 4:22:43 PM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-m= ultiplecoa-13.txt]

Hi Behet.

We don't treat HoA as HIT= in MCoA, but just follows how RFC3775 defines HoA.

regards,
ryuj= i


On 2009/04/22, at 16:02, Behcet Sarikaya wrote:

> Ge= orge,
>
>    I checked 3775,
> Home Address A = unicast routable address assigned to a mobile node, used as the
>&nbs= p;     permanent address of the mobile node.
> HoA can be used as source addresses in IP packets and it is not Host
> =             Identity Tag (HIT) of HIP, as Vi= jay may possibly wish to identify.
>
> RFC 5026 defines how Ho= A can be configured from the prefix and IID just like any IPv6 address. Thi= s address is assigned to the interface with which MN connects to the home l= ink.
>
> HIT on the other hand is also of the same length but = it is generated from HI using hashed encoding. It is not an IPv6 address.>
>
> BR,
>
> Behcet
> From: George T= sirtsis <tsirtsis@googlemail.com>
> To: Behcet S= arikaya <sarikaya@ieee.org>
> Cc: mext <mext@ietf.org>
&= gt; Sent: Wednesday, April 22, 2009 10:29:08 AM
> Subject: Re: [MEXT] [F= wd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
>
> sigh= .... this is not what I said....
> Also Vijay has the same thoughts wi= th me on the subject...this does
> not happen often, but it does happ= en!
>
> On Wed, Apr 22, 2009 at 4:25 PM, Behcet Sarikaya
&g= t; <behcetsarikaya@yahoo.com> wrote:
> > So= the first interface that does INE (initial network entry, SDO
> >= terminology) becomes the main interface and grabs the HoA.
> > I = don't think stating this basic assumption is not good. Many people
> = > including Vijay had some different thoughts.
> >
> >= --behcet
> >
> > ________________________________
>= ; > From: George Tsirtsis <tsirtsis@googlemail.com>
> > To: Behcet Sarikaya &= lt;sarikaya@ieee.org>
> > Cc: mext <mext@ietf.org>
> = > Sent: Wednesday, April 22, 2009 10:06:18 AM
> > Subject: Re: = [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
> >=
> > On Wed, Apr 22, 2009 at 3:59 PM, Behcet Sarikaya
> >= <behcetsarikaya@yahoo.com> wrote:
> >> = Hi George,
> >>  It seems like now you are telling the tru= th
> >
> > GT> I always try :-)
> >
> &= gt;> Basically MCoA draft wishes to establish some hierarchy of the interfaces.
> >> There is one which is the main interface (Vij= ay calls this main entity but
> >> as we ALL know addresses as = Layer 3 identities are assigned to the
> >> interfaces not the = the entities). There are other interfaces which are the
> >> lo= west level interfaces.
> >> MN does INE using the main interfac= e. Uses IKEv2 and gets HoA assigned
> >> establishes secure tun= nel with the HA on this interface.
> >>
> >
> &g= t; GT> Not sure what INE is
> >
> >> Somewhat magic= ally the lowest level interfaces become active and connect
> >>= to
> >> some other domains and get CoA1 then MCoA draft kicks = in and starts
> >> assigning these BIDs..
> >>
&= gt; >
> > GT> You are missing the fact that the lowest inter= face can actually
> > come up first so that the MN gets a CoA, which is then using to
> > bootstrap with the HA.
> &g= t;
> >> My suggestion is that the draft should explain this cle= arly in textual
> >> form.
> >>
> >
>= ; > GT> Behcet, all this is already known and obvious. We can add any=
> > number of obvious things to every document but I do not think= it is
> > useful. RFCs are not tutorials. The reader is expected = to be familiar
> > with the subject, especially when looking at an= extension of a base
> > protocol like MCoA is to MIP.
> >= ;
> >> Regards,
> >>
> >> Behcet
>= ; >> ________________________________
> >> From: George T= sirtsis <tsirtsis@googlemail.com>
> >> To:= Vijay Devarapalli <vijay@wichorus.com>
> &= gt;> Cc: Behcet Sarikaya <sarikaya@ieee.org>; mext <mext@ietf.org>
> >> Sent: Tuesday, April 21, 2009 2:14:55 PM
> >= ;> Subject: Re: [MEXT] [Fwd: I-D
> >> Action:draft-ietf-mona= mi6-multiplecoa-13.txt]
> >>
> >> ....also wrt the = home link registration, I do not think what you
> >> suggest is= necessary.
> >>
> >> As far as I see the other doc= uments are informational, and they do not
> >> yet have a forma= l standing in the WG. If and when they do, as
> >> Informationa= l documents,  they should not require normative changes to
> >= ;> anything. They should make sure what they describe (mostly
> >> implementation options in this case) are compatible not only with=
> >> RFC3775 but also with extensions to it, including Flow Bi= ndings. .
> >>
> >>
> >> Regards
>= ; >> George
> >>
> >>
> >>
>= ; >
> >
>
> ______________________________________= _________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.o= rg/mailman/listinfo/mext


=0A=0A --0-511870484-1240436490=:19643-- From behcetsarikaya@yahoo.com Wed Apr 22 14:44:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF9D3A70A4 for ; Wed, 22 Apr 2009 14:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HTML_MESSAGE=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 CGzsxBCg0A5X for ; Wed, 22 Apr 2009 14:44:35 -0700 (PDT) Received: from web111407.mail.gq1.yahoo.com (web111407.mail.gq1.yahoo.com [67.195.15.168]) by core3.amsl.com (Postfix) with SMTP id ACE2A3A6E7D for ; Wed, 22 Apr 2009 14:44:35 -0700 (PDT) Received: (qmail 2071 invoked by uid 60001); 22 Apr 2009 21:45:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240436753; bh=szXDXzRxbB0Xhfq6h7NaXfaw6Y6XBHluNgOQtuohQBM=; 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=Z3j8xqdtsQhTOr26jfJsWws3Cux8nq3s+PZffIuEvLHICn4fLsjHWSL0RpRuqIvvt87r5EQe5FdThnqbrB/stfCV54PColoPJfSKHMvtkyPrh3O1XXYfFE1BOU4Ek1+B/ZzMWJ38RxIkBO995KLgxTezSIxzajVH8e2zM4cqrxI= 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=seVl7bQpRdhvJ36lnDA2hTb8qCYmDWuV3Un1a6d9QJMPuAvV8HJpVX5/lJikGID4MRI8SW0LcY8M3Dpk3tn79DxLGI62tFDLHXji0vTqQZwM1tDQWcJZv9QKiX9ym/iVsNQjVefG0XhrcS6emclJlh28aZYdiPSuaAiyJF5PXuM=; Message-ID: <222821.303.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: Mzwd9oYVM1m4p.iHptLQivBEuykH4aoEkPM96iYU8w3iWRLKKrL1bnJTxWC56zCmxGGah_Z947eLwwzzOfoeTl5Q7T_AnUl3OLbddV3q.2M7PqMR6RADQsQlL1dZNdVE3c5.zjC0aoNEMg4yM02TQ4LB6rYLZ_QrR4YjD9RY.9j9RtmCKBfuVpIkHgToGAScRm0fM8KYkuQRweA6baTOtElMQmlAID6dUzRira0VHnpgFIacm9rIwWhLgVOXlQs7WnLHwoyU5_x_S6b46FkvOxDrui0iqTKyzdoSzR_Y1DNvcnrAu2n3SPetRq5Z8IVPZCr3 Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Wed, 22 Apr 2009 14:45:53 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> <375902.20727.qm@web111403.mail.gq1.yahoo.com> <8CF30647-6A19-4391-BE7E-CFE87EFD8EAD@gmail.com> Date: Wed, 22 Apr 2009 14:45:53 -0700 (PDT) From: Behcet Sarikaya To: Ryuji Wakikawa In-Reply-To: <8CF30647-6A19-4391-BE7E-CFE87EFD8EAD@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-742915476-1240436753=:303" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:44:37 -0000 --0-742915476-1240436753=:303 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ryuji,=0A=A0 I checked your draft. Again, I could not understand how you= are sending a registration BU at the home link as only an O-flag is define= d in your draft which is used for something else.=0A=A0 As I mentioned to y= ou, we discussed this related to draft-premec-homelink and it seems like HA= will reject such a BU unless something is done, I thought you were familia= r with the discussions as it relates to your draft too. I am surprised.=0A= =0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A________________________________=0AFr= om: Ryuji Wakikawa =0ATo: Behcet Sarikaya =0ACc: George Tsirtsis ; mext =0ASent: Wednesday, April 22, 2009 4:18:28 PM=0ASubject: Re: [MEXT] = [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A=0AHi Behcet,=0A= =0AOn 2009/04/22, at 11:31, Behcet Sarikaya wrote:=0A=0A> =0A> =0A> From: G= eorge Tsirtsis =0A> To: Behcet Sarikaya =0A> Cc: mext =0A> Sent: Wednesday, April 22, 2009 = 10:10:08 AM=0A> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-mul= tiplecoa-13.txt]=0A> =0A> I do not think that adding home link registration= to RFC3775bis is feasible.=0A> This requires logic in the MN and HA that i= s not directly compatible=0A> to RFC3775. The aim of RFC3775bis is to make = minimal changes for=0A> clarification reasons and to correct errors. Home L= ink Registration as=0A> defined in MCoA is neither.=0A> [behcet] Why not? I= f it is needed in so many instances, that qualifies it to become a base pro= tocol feature, at least to me.=0A=0AWe cannot add a new feature to 3775. Th= at is the ground rule of -bis. The chairs can clarify this.=0A=0Aregards,= =0Aryuji=0A=0A=0A=0A> =0A> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya= =0A> wrote:=0A> > Hi George,=0A> >=A0 It seems i= n my previous reply I replied to this mail of yours which was=0A> > unrelat= ed to the other mail you sent to which I was really replying,=0A> > apologi= es.=0A> >=A0 Now regarding home link registration, what is the mechanism MC= oA draft=0A> > uses? Ryuji mentioned some H bit but I read the draft and co= uldn't confirm=0A> > it.=0A> >=0A> >=A0 My suggestion was building on this,= i.e. I suggested that whatever you=0A> > came up with can be moved to 3775= bis so that other people would not have to=0A> > make normative references = to your draft.=0A> >=0A> > That's all.=0A> >=0A> > Regards,=0A> >=0A> > Beh= cet=0A> >=0A> > ________________________________=0A> > From: George Tsirtsi= s =0A> > To: Vijay Devarapalli =0A> > Cc: Behcet Sarikaya ; mext =0A> >= Sent: Tuesday, April 21, 2009 2:14:55 PM=0A> > Subject: Re: [MEXT] [Fwd: I= -D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> >=0A> > ...also wrt th= e home link registration, I do not think what you=0A> > suggest is necessar= y.=0A> >=0A> > As far as I see the other documents are informational, and t= hey do not=0A> > yet have a formal standing in the WG. If and when they do,= as=0A> > Informational documents,=A0 they should not require normative cha= nges to=0A> > anything. They should make sure what they describe (mostly=0A= > > implementation options in this case) are compatible not only with=0A> >= RFC3775 but also with extensions to it, including Flow Bindings. .=0A> >= =0A> >=0A> > Regards=0A> > George=0A> >=0A> > On Tue, Apr 21, 2009 at 7:58 = PM, Vijay Devarapalli =0A> > wrote:=0A> >> Behcet,=0A> = >>=0A> >> Behcet Sarikaya wrote:=0A> >>>=0A> >>> *[behcet] Yes but each int= erface will appear to HA as a different device=0A> >>> and HA needs to assi= gn a different HoA. Then MCoA problem disappears.*=0A> >>> *So George is sa= ying that this is avoided by some virtual interfaces so=0A> >>> that HA doe= s not see each interface separately. *=0A> >>> *Is this explained anywhere = in the draft?*=0A> >>> *If yes then I am OK.*=0A> >>=0A> >> The home agent = does not care about the multiple interfaces on the mobile=0A> >> node. It o= nly sees the mobile node as one entity and allocates a home=0A> >> address = to it. The multiple care-of addresses that the mobile node has=0A> >> will= =0A> >> be used by the home agent as tunnel end points. That is all. So the= re is=0A> >> no=0A> >> issue.=0A> >>=0A> >> Vijay=0A> >>=0A> >>>=A0 >=A0 Al= so I have a question to Ryuji: does this draft send a=0A> >>> non-deregistr= ation BU at the home link? If yes, is he familiar with the=0A> >>> discussi= on going on on this subject? This is another point of confusion=0A> >>> for= =0A> >>> me.=0A> >>>=0A> >>> This has been discussed for a long time in MEX= T.=0A> >>> who is familiar with which discussions? I don't know your concer= n here.=0A> >>>=A0 *[behcet] So your answer is yes the draft sends a non-de= registration BU=0A> >>> (kind of bulk registration) at the home link.*=0A> = >>> *The discussion I mentioned was related to=0A> >>> draft-premec-mext-ex= tended-home-link. This draft also sends=0A> >>> non-deregistration BU at th= e home link. So does a few more drafts like=0A> >>> **draft-devarapalli-mex= t-mipv6-home-link.*=0A> >>>=0A> >>> **=0A> >>> *[behcet] You mentioned some= bit is set but I could not understand which.=0A> >>> One idea is since so = many drafts need this, why not factor this out and=0A> >>> define whatever = the mechanism to enable sending non-deregistration BU in=0A> >>> 3775bis. W= hat do you think about that?*=0A> >>>=0A> >>> **=0A> >>>=0A> >>>=A0 >=A0 So= rry if I am too=A0 much confused=0A> >>>=A0 > Please don't get me wrong, I = am not trying to slow down the progress=0A> >>> of=0A> >>> this document..= =0A> >>>=0A> >>> sure, but please explain your issue more precisely.=0A> >>= >=0A> >>> thanks!=0A> >>> ryuji=0A> >>>=0A> >>>=A0 >=0A> >>>=A0 > Regards,= =0A> >>>=A0 >=0A> >>>=A0 > Behcet=0A> >>>=A0 > From: marcelo bagnulo braun = >>> >=0A> >>>=A0 > To: m= ext >; Julien Laganier=0A> >>> >>> >; Jari Arkko=0A> >>> >=0A> >>>=A0 > Sent: Tuesday, April 21, 2009 11:03:05 AM=0A> >>>=A0 >= Subject: [MEXT] [Fwd: I-D=0A> >>> Action:draft-ietf-monami6-multiplecoa-13= .txt]=0A> >>>=A0 >=0A> >>>=A0 > We have this new version of the MCOA docume= nt that addresses the=0A> >>> comments received, including IESG review comm= ents.=0A> >>>=A0 > To the best of my knowledge, the IESG is ok with the doc= and ready for=0A> >>> publication..=0A> >>>=A0 > I am planning to ask our = AD to move forward in a week or so, so, if=0A> >>> you=0A> >>> have comment= s on the document please provide them before the 1st of may.=0A> >>>=A0 >= =0A> >>>=A0 > Regards, marcelo=0A> >>>=A0 > (mcoa doc shepherd)=0A> >>>=A0 = >=0A> >>>=A0 > -------- Mensaje original --------=0A> >>>=A0 > Asunto:=A0 = =A0 [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt=0A> >>>=A0 > Fe= cha:=A0 =A0 Mon, 20 Apr 2009 08:30:01 -0700 (PDT)=0A> >>>=A0 > De:=A0 =A0 I= nternet-Drafts@ietf.org =0A> >>>=A0 > Para= :=A0 =A0 i-d-announce@ietf.org =0A> >>>=A0 > = CC:=A0 =A0 mext@ietf.org =0A> >>>=A0 >=0A> >>>=A0 >= =0A> >>>=A0 >=0A> >>>=A0 > A New Internet-Draft is available from the on-li= ne Internet-Drafts=0A> >>> directories.=0A> >>>=A0 > This draft is a work i= tem of the Mobility EXTensions for IPv6 Working=0A> >>> Group of the IETF.= =0A> >>>=A0 >=0A> >>>=A0 >=0A> >>>=A0 >=A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : M= ultiple Care-of Addresses Registration=0A> >>>=A0 >=A0 =A0 Author(s)=A0 =A0= =A0 : R. Wakikawa, et al.=0A> >>>=A0 >=A0 =A0 Filename=A0 =A0 =A0 =A0 : dr= aft-ietf-monami6-multiplecoa-13..txt=0A> >>>=A0 >=A0 =A0 Pages=A0 =A0 =A0 = =A0 =A0 : 44=0A> >>>=A0 >=A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2009-04-20= =0A> >>>=A0 >=0A> >>>=A0 > According to the current Mobile IPv6 specificati= on, a mobile node may=0A> >>>=A0 > have several care-of addresses, but only= one, called the primary=0A> >>>=A0 > care-of address, that can be register= ed with its home agent and the=0A> >>>=A0 > correspondent nodes.=A0 However= , for matters of cost, bandwidth, delay,=0A> >>>=A0 > etc, it is useful for= the mobile node to get Internet access through=0A> >>>=A0 > multiple acces= ses simultaneously, in which case the mobile node would=0A> >>>=A0 > be con= figured with multiple active IPv6 care-of addresses.=A0 This=0A> >>>=A0 > d= ocument proposes extensions to the Mobile IPv6 protocol to register=0A> >>>= =A0 > and use multiple care-of addresses.=A0 The extensions proposed in thi= s=0A> >>>=A0 > document can be used by Mobile Routers using the NEMO (Netwo= rk=0A> >>>=A0 > Mobility) Basic Support protocol as well.=0A> >>>=A0 >=0A> = >>>=A0 > A URL for this Internet-Draft is:=0A> >>>=A0 >=0A> >>> http://www.= ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt=0A> >>>=A0 >= =0A> >>>=A0 > Internet-Drafts are also available by anonymous FTP at:=0A> >= >>=A0 > ftp://ftp.ietf.org/internet-drafts/=0A> >>>=A0 >=0A> >>>=A0 > Below= is the data which will enable a MIME compliant mail reader=0A> >>>=A0 > im= plementation to automatically retrieve the ASCII version of the=0A> >>>=A0 = > Internet-Draft.=0A> >>>=A0 >=0A> >>>=A0 >=0A> >>>=A0 >=0A> >>>=A0 > _____= __________________________________________=0A> >>>=A0 > MEXT mailing list= =0A> >>>=A0 > MEXT@ietf.org =0A> >>>=A0 > https://www= .ietf.org/mailman/listinfo/mext=0A> >>>=0A> >>>=0A> >>>=0A> >>> -----------= -------------------------------------------------------------=0A> >>>=0A> >= >> _______________________________________________=0A> >>> MEXT mailing lis= t=0A> >>> MEXT@ietf.org=0A> >>> https://www.ietf.org/mailman/listinfo/mext= =0A> >>=0A> >> _______________________________________________=0A> >> MEXT = mailing list=0A> >> MEXT@ietf.org=0A> >> https://www.ietf.org/mailman/listi= nfo/mext=0A> >>=0A> >=0A> >=0A> =0A> ______________________________________= _________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.ietf.org/= mailman/listinfo/mext=0A=0A=0A --0-742915476-1240436753=:303 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ryuji,
=0A
  I checked your draft. Ag= ain, I could not understand how you are sending a registration BU at the ho= me link as only an O-flag is defined in your draft which is used for someth= ing else.
=0A
  As I mentioned to you, we discussed this rela= ted to draft-premec-homelink and it seems like HA will reject such a BU unl= ess something is done, I thought you were familiar with the discussions as = it relates to your draft too. I am surprised.
=0A
 
=0A<= DIV>Regards,
=0A
 
=0A
Behcet
=0A
=
=0A
=0A
=0AFrom: Ryuji Wakikawa <ryuji.wakikawa@gmail.co= m>
To: Behcet Sarikay= a <sarikaya@ieee.org>
Cc: George Tsirtsis <tsirtsis@googlemail.com>; mext <mext@ietf= .org>
Sent: Wednesday= , April 22, 2009 4:18:28 PM
Subject= : Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.= txt]

Hi Behcet,

On 2009/04/22, at 11:31, Behcet Sarika= ya wrote:

>
>
> From: George Tsirtsis <tsirtsis@googlemail.com>
> To: Behcet Sarikaya <sarikaya= @ieee.org>
> Cc: mext <mext@ietf.o= rg>
> Sent: Wednesday, April 22, 2009 10:10:08 AM
> Subj= ect: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
= >
> I do not think that adding home link registration to RFC3775b= is is feasible.
> This requires logic in the MN and HA that is not di= rectly compatible
> to RFC3775. The aim of RFC3775bis is to make mini= mal changes for
> clarification reasons and to correct errors. Home L= ink Registration as
> defined in MCoA is neither.
> [behcet] Wh= y not? If it is needed in so many instances, that qualifies it to become a = base protocol feature, at least to me.

We cannot add a new feature t= o 3775. That is the ground rule of -bis. The chairs can clarify this.
regards,
ryuji



>
> On Wed, Apr 22, 2009 at 4:= 06 PM, Behcet Sarikaya
> <behcetsarikaya@yahoo.com> wrote:
> > Hi George,<= BR>> >  It seems in my previous reply I replied to this mail of = yours which was
> > unrelated to the other mail you sent to which = I was really replying,
> > apologies.
> >  Now regar= ding home link registration, what is the mechanism MCoA draft
> > = uses? Ryuji mentioned some H bit but I read the draft and couldn't confirm<= BR>> > it.
> >
> >  My suggestion was building= on this, i.e. I suggested that whatever you
> > came up with can = be moved to 3775bis so that other people would not have to
> > mak= e normative references to your draft.
> >
> > That's all.=
> >
> > Regards,
> >
> > Behcet
>= ; >
> > ________________________________
> > From: George Tsirtsis <tsirtsis@googlemail.com>
> >= ; To: Vijay Devarapalli <vijay@wichorus.com>
> > Cc: = Behcet Sarikaya <sarikaya@ieee.org>; mext <mext@ietf.org>
>= > Sent: Tuesday, April 21, 2009 2:14:55 PM
> > Subject: Re: [M= EXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
> >> > ...also wrt the home link registration, I do not think what you=
> > suggest is necessary.
> >
> > As far as I s= ee the other documents are informational, and they do not
> > yet = have a formal standing in the WG. If and when they do, as
> > Info= rmational documents,  they should not require normative changes to
> >= anything. They should make sure what they describe (mostly
> > im= plementation options in this case) are compatible not only with
> >= ; RFC3775 but also with extensions to it, including Flow Bindings. .
>= ; >
> >
> > Regards
> > George
> >> > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli <vijay@= wichorus.com>
> > wrote:
> >> Behcet,
> &= gt;>
> >> Behcet Sarikaya wrote:
> >>>
>= ; >>> *[behcet] Yes but each interface will appear to HA as a diff= erent device
> >>> and HA needs to assign a different HoA. T= hen MCoA problem disappears.*
> >>> *So George is saying tha= t this is avoided by some virtual interfaces so
> >>> that HA does not see each interface separately. *
> >>> *Is this= explained anywhere in the draft?*
> >>> *If yes then I am O= K.*
> >>
> >> The home agent does not care about th= e multiple interfaces on the mobile
> >> node. It only sees the= mobile node as one entity and allocates a home
> >> address to= it. The multiple care-of addresses that the mobile node has
> >&g= t; will
> >> be used by the home agent as tunnel end points. Th= at is all. So there is
> >> no
> >> issue.
> = >>
> >> Vijay
> >>
> >>> = >  Also I have a question to Ryuji: does this draft send a
>= >>> non-deregistration BU at the home link? If yes, is he familia= r with the
> >>> discussion going on on this subject? This i= s another point of confusion
> >>> for
> >>> me.
> >>>
> >>> This has been d= iscussed for a long time in MEXT.
> >>> who is familiar with= which discussions? I don't know your concern here.
> >>>&nb= sp; *[behcet] So your answer is yes the draft sends a non-deregistration BU=
> >>> (kind of bulk registration) at the home link.*
>= ; >>> *The discussion I mentioned was related to
> >>&= gt; draft-premec-mext-extended-home-link. This draft also sends
> >= ;>> non-deregistration BU at the home link. So does a few more drafts= like
> >>> **draft-devarapalli-mext-mipv6-home-link.*
&g= t; >>>
> >>> **
> >>> *[behcet] You = mentioned some bit is set but I could not understand which.
> >>= ;> One idea is since so many drafts need this, why not factor this out a= nd
> >>> define whatever the mechanism to enable sending non-deregistration BU in
> >>> 3775bis. What do you= think about that?*
> >>>
> >>> **
> &g= t;>>
> >>>  >  Sorry if I am too  mu= ch confused
> >>>  > Please don't get me wrong, I am= not trying to slow down the progress
> >>> of
> >&= gt;> this document..
> >>>
> >>> sure, but= please explain your issue more precisely.
> >>>
> >= ;>> thanks!
> >>> ryuji
> >>>
> &= gt;>>  >
> >>>  > Regards,
> >= ;>>  >
> >>>  > Behcet
> >>= ;>  > From: marcelo bagnulo braun <marcelo@it.uc3m.es> >>> <mailto:marcelo@it.uc3m.es>>
&g= t; >>>  > To: mext <mext@ietf.org <mailto:mext@ietf.org>>= ;; Julien Laganier
> >>> <julien.laganier.ietf@googlemail.com
> >>> <mailto= :julien.laganier..ietf@googlemail.com<= /A>>>; Jari Arkko
> >>> <jari.arkko@piuha.net<= /A> <mailto:jari.arkko@piuha.net>>
> >>>&n= bsp; > Sent: Tuesday, April 21, 2009 11:03:05 AM
> >>>  > Subjec= t: [MEXT] [Fwd: I-D
> >>> Action:draft-ietf-monami6-multiple= coa-13.txt]
> >>>  >
> >>>  >= We have this new version of the MCOA document that addresses the
> &= gt;>> comments received, including IESG review comments.
> >= >>  > To the best of my knowledge, the IESG is ok with the do= c and ready for
> >>> publication..
> >>>&nbs= p; > I am planning to ask our AD to move forward in a week or so, so, if=
> >>> you
> >>> have comments on the documen= t please provide them before the 1st of may.
> >>>  >= ;
> >>>  > Regards, marcelo
> >>>&nbs= p; > (mcoa doc shepherd)
> >>>  >
> >>= ;>  > -------- Mensaje original --------
> >>>  > Asunto:    [MEXT] I-D Action:draft-ietf-= monami6-multiplecoa-13.txt
> >>>  > Fecha:  &nb= sp; Mon, 20 Apr 2009 08:30:01 -0700 (PDT)
> >>>  > D= e:    Internet-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org>
> >>>  > Par= a:    i-d-announce@ietf.org <mailto:i-d-anno= unce@ietf.org>
> >>>  > CC:    mext@ietf.org= <mailto:mext@ietf.org>
> >>>= ;  >
> >>>  >
> >>>  >= ;
> >>>  > A New Internet-Draft is available from th= e on-line Internet-Drafts
> >>> directories.
> >>= ;>  > This draft is a work item of the Mobility EXTensions for I= Pv6 Working
> >>> Group of the IETF.
> >>>&nb= sp; >
> >>>  >
> >>>  >&nb= sp;   Title          : Multiple Care-of Addre= sses Registration
> >>>  >    Author(s)&nb= sp;     : R. Wakikawa, et al.
> >>>  >&nbs= p;   Filename        : draft-ietf-monami6-multiple= coa-13..txt
> >>>  >    Pages   =       : 44
> >>>  >    Date            : 2009-04-20
> = >>>  >
> >>>  > According to the cu= rrent Mobile IPv6 specification, a mobile node may
> >>>&nbs= p; > have several care-of addresses, but only one, called the primary> >>>  > care-of address, that can be registered with = its home agent and the
> >>>  > correspondent nodes.=   However, for matters of cost, bandwidth, delay,
> >>>=   > etc, it is useful for the mobile node to get Internet access th= rough
> >>>  > multiple accesses simultaneously, in = which case the mobile node would
> >>>  > be configu= red with multiple active IPv6 care-of addresses.  This
> >>= ;>  > document proposes extensions to the Mobile IPv6 protocol t= o register
> >>>  > and use multiple care-of addresses.  The extensions proposed in this
> >>> = ; > document can be used by Mobile Routers using the NEMO (Network
&g= t; >>>  > Mobility) Basic Support protocol as well.
>= ; >>>  >
> >>>  > A URL for this In= ternet-Draft is:
> >>>  >
> >>> http:= //www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt
>= ; >>>  >
> >>>  > Internet-Drafts a= re also available by anonymous FTP at:
> >>>  > ftp://ftp.ietf.= org/internet-drafts/
> >>>  >
> >>&g= t;  > Below is the data which will enable a MIME compliant mail rea= der
> >>>  > implementation to automatically retriev= e the ASCII version of the
> >>>  > Internet-Draft.
> >>>  >
> >>> = >
> >>>  >
> >>>  > _____= __________________________________________
> >>>  > = MEXT mailing list
> >>>  > MEXT@ietf.org <mailto:MEXT@ietf.org<= /A>>
> >>>  > https://www.ietf.org/mailman/listinfo/m= ext
> >>>
> >>>
> >>>
&= gt; >>> ----------------------------------------------------------= --------------
> >>>
> >>> __________________= _____________________________
> >>> MEXT mailing list
>= ; >>> MEXT@ietf.org
> >>> https:= //www.ietf.org/mailman/listinfo/mext
> >>
> >> = _______________________________________________
> >> MEXT maili= ng list
> >> MEXT@ietf.org
> >> https://www.ietf.org/mailman= /listinfo/mext
> >>
> >
> >
>
&= gt; _______________________________________________
> MEXT mailing li= st
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
<= BR>

=0A=0A --0-742915476-1240436753=:303-- From ryuji.wakikawa@gmail.com Wed Apr 22 14:51:41 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2AA13A6BF1 for ; Wed, 22 Apr 2009 14:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 lCUysEluuKwn for ; Wed, 22 Apr 2009 14:51:40 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 5647028C4A6 for ; Wed, 22 Apr 2009 14:51:01 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so227514qwe.31 for ; Wed, 22 Apr 2009 14:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=BaWy84SucJZCmnhhbpn3fNmrMQhsr27v2WsgZ8BGEvY=; b=K/Bia8raGwLJrHrk8LVQSaHG/TZoCavvSyfYgVF/4MGiBKm6xXjIw9UsDEhmKGcTlC XoQlWocyAV7V/BZD2YkfE6NdXxuZIY2QAuwW3lrXZoYWCsY1GcDJWz/XFqd7hsgtt1xR ntmGlOnG+Tj0+7AiozvCNdQ4UHD52ys0cDtZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=ZuClpgWUsHq9jjLcVNAz+8T0smpbmFerNE2C9PCm7n2xAPMDwxj9BQoo64keaW9NoI YpdUj2XMzLCTLR/LwtQ585yxihLDDZloTBp3YKG42iQoqQ4rV8TsOcmpNGx8pu6KzM0d ccKKcS7FNmKI09W8KPzUU2MoCS6NOVRzXzLlI= Received: by 10.224.29.13 with SMTP id o13mr484723qac.98.1240437138315; Wed, 22 Apr 2009 14:52:18 -0700 (PDT) Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id 4sm1603173yxq.18.2009.04.22.14.52.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Apr 2009 14:52:17 -0700 (PDT) From: Ryuji Wakikawa To: Behcet Sarikaya In-Reply-To: <764540.19643.qm@web111416.mail.gq1.yahoo.com> References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <869311.39916.qm@web111412.mail.gq1.yahoo.com> <92139.81999.qm@web111404.mail.gq1.yahoo.com> <96848.91350.qm@web111411.mail.gq1.yahoo.com> <764540.19643.qm@web111416.mail.gq1.yahoo.com> Message-Id: <0456CA55-AD0C-409E-8AF9-CE14738E3219@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 17:52:15 -0400 X-Mailer: Apple Mail (2.930.3) Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:51:42 -0000 Hi Behcet, On 2009/04/22, at 17:41, Behcet Sarikaya wrote: > Hi Ryuji, > So you agree that a clarification is needed regarding the main > interface and other or auxiliary interfaces that I was trying to > express in my previous mails. I don't agree with you... We don't have the definition of neither main or auxiliary interfaces. Multiple CoAs are described in RFC3775. care-of address A unicast routable address associated with a mobile node while visiting a foreign link; the subnet prefix of this IP address is a foreign subnet prefix. Among the multiple care-of addresses that a mobile node may have at any given time (e.g., with different subnet prefixes), the one registered with the mobile node's home agent for a given home address is called its "primary" care-of address. MCoA is just extension how to register multiple COAs to HA. We don't need any special clarification in MCoA, because we didn't change anything here. regards, ryuji > > Regards, > > Behcet > > From: Ryuji Wakikawa > To: Behcet Sarikaya > Cc: George Tsirtsis ; mext > Sent: Wednesday, April 22, 2009 4:22:43 PM > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > Hi Behet. > > We don't treat HoA as HIT in MCoA, but just follows how RFC3775 > defines HoA. > > regards, > ryuji > > > On 2009/04/22, at 16:02, Behcet Sarikaya wrote: > > > George, > > > > I checked 3775, > > Home Address A unicast routable address assigned to a mobile node, > used as the > > permanent address of the mobile node. > > HoA can be used as source addresses in IP packets and it is not Host > > Identity Tag (HIT) of HIP, as Vijay may possibly wish > to identify. > > > > RFC 5026 defines how HoA can be configured from the prefix and IID > just like any IPv6 address. This address is assigned to the > interface with which MN connects to the home link. > > > > HIT on the other hand is also of the same length but it is > generated from HI using hashed encoding. It is not an IPv6 address. > > > > > > BR, > > > > Behcet > > From: George Tsirtsis > > To: Behcet Sarikaya > > Cc: mext > > Sent: Wednesday, April 22, 2009 10:29:08 AM > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > sigh.... this is not what I said.... > > Also Vijay has the same thoughts with me on the subject...this does > > not happen often, but it does happen! > > > > On Wed, Apr 22, 2009 at 4:25 PM, Behcet Sarikaya > > wrote: > > > So the first interface that does INE (initial network entry, SDO > > > terminology) becomes the main interface and grabs the HoA. > > > I don't think stating this basic assumption is not good. Many > people > > > including Vijay had some different thoughts. > > > > > > --behcet > > > > > > ________________________________ > > > From: George Tsirtsis > > > To: Behcet Sarikaya > > > Cc: mext > > > Sent: Wednesday, April 22, 2009 10:06:18 AM > > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > > > On Wed, Apr 22, 2009 at 3:59 PM, Behcet Sarikaya > > > wrote: > > >> Hi George, > > >> It seems like now you are telling the truth > > > > > > GT> I always try :-) > > > > > >> Basically MCoA draft wishes to establish some hierarchy of the > interfaces. > > >> There is one which is the main interface (Vijay calls this main > entity but > > >> as we ALL know addresses as Layer 3 identities are assigned to > the > > >> interfaces not the the entities). There are other interfaces > which are the > > >> lowest level interfaces. > > >> MN does INE using the main interface. Uses IKEv2 and gets HoA > assigned > > >> establishes secure tunnel with the HA on this interface. > > >> > > > > > > GT> Not sure what INE is > > > > > >> Somewhat magically the lowest level interfaces become active > and connect > > >> to > > >> some other domains and get CoA1 then MCoA draft kicks in and > starts > > >> assigning these BIDs.. > > >> > > > > > > GT> You are missing the fact that the lowest interface can > actually > > > come up first so that the MN gets a CoA, which is then using to > > > bootstrap with the HA. > > > > > >> My suggestion is that the draft should explain this clearly in > textual > > >> form. > > >> > > > > > > GT> Behcet, all this is already known and obvious. We can add any > > > number of obvious things to every document but I do not think it > is > > > useful. RFCs are not tutorials. The reader is expected to be > familiar > > > with the subject, especially when looking at an extension of a > base > > > protocol like MCoA is to MIP. > > > > > >> Regards, > > >> > > >> Behcet > > >> ________________________________ > > >> From: George Tsirtsis > > >> To: Vijay Devarapalli > > >> Cc: Behcet Sarikaya ; mext > > >> Sent: Tuesday, April 21, 2009 2:14:55 PM > > >> Subject: Re: [MEXT] [Fwd: I-D > > >> Action:draft-ietf-monami6-multiplecoa-13.txt] > > >> > > >> ....also wrt the home link registration, I do not think what you > > >> suggest is necessary. > > >> > > >> As far as I see the other documents are informational, and they > do not > > >> yet have a formal standing in the WG. If and when they do, as > > >> Informational documents, they should not require normative > changes to > > >> anything. They should make sure what they describe (mostly > > >> implementation options in this case) are compatible not only with > > >> RFC3775 but also with extensions to it, including Flow > Bindings. . > > >> > > >> > > >> Regards > > >> George > > >> > > >> > > >> > > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > From marcelo@it.uc3m.es Wed Apr 22 14:58:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E90428C183 for ; Wed, 22 Apr 2009 14:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 MnWJMaLj7hKR for ; Wed, 22 Apr 2009 14:58:38 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7119528C147 for ; Wed, 22 Apr 2009 14:58:38 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (220.pool85-53-141.dynamic.orange.es [85.53.141.220]) by smtp02.uc3m.es (Postfix) with ESMTP id 0F65E6C1967; Wed, 22 Apr 2009 23:59:51 +0200 (CEST) Message-ID: <49EF9356.8000504@it.uc3m.es> Date: Wed, 22 Apr 2009 23:59:50 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Behcet Sarikaya References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> <375902.20727.qm@web111403.mail.gq1.yahoo.com> <8CF30647-6A19-4391-BE7E-CFE87EFD8EAD@gmail.com> <222821.303.qm@web111407.mail.gq1.yahoo.com> In-Reply-To: <222821.303.qm@web111407.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16598.002 Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:58:40 -0000 Hi Bechet, could you send exactly what text do you think needs to be changed in the MCOA draft, so the WG can evaluate and figure out if the changes are needed? (i.e. please send OLD text NEW text) Please note that at this point in the life of the document, we only take changes that fix errors in the document, rather than getting more features in. Regards, marcelo Behcet Sarikaya escribió: > Hi Ryuji, > I checked your draft. Again, I could not understand how you are > sending a registration BU at the home link as only an O-flag is > defined in your draft which is used for something else. > As I mentioned to you, we discussed this related to > draft-premec-homelink and it seems like HA will reject such a BU > unless something is done, I thought you were familiar with the > discussions as it relates to your draft too. I am surprised. > > Regards, > > Behcet > > ------------------------------------------------------------------------ > *From:* Ryuji Wakikawa > *To:* Behcet Sarikaya > *Cc:* George Tsirtsis ; mext > *Sent:* Wednesday, April 22, 2009 4:18:28 PM > *Subject:* Re: [MEXT] [Fwd: I-D > Action:draft-ietf-monami6-multiplecoa-13.txt] > > Hi Behcet, > > On 2009/04/22, at 11:31, Behcet Sarikaya wrote: > > > > > > > From: George Tsirtsis > > > To: Behcet Sarikaya > > > Cc: mext > > > Sent: Wednesday, April 22, 2009 10:10:08 AM > > Subject: Re: [MEXT] [Fwd: I-D > Action:draft-ietf-monami6-multiplecoa-13.txt] > > > > I do not think that adding home link registration to RFC3775bis is > feasible. > > This requires logic in the MN and HA that is not directly compatible > > to RFC3775. The aim of RFC3775bis is to make minimal changes for > > clarification reasons and to correct errors. Home Link Registration as > > defined in MCoA is neither. > > [behcet] Why not? If it is needed in so many instances, that > qualifies it to become a base protocol feature, at least to me. > > We cannot add a new feature to 3775. That is the ground rule of -bis. > The chairs can clarify this. > > regards, > ryuji > > > > > > > On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya > > > wrote: > > > Hi George, > > > It seems in my previous reply I replied to this mail of yours > which was > > > unrelated to the other mail you sent to which I was really replying, > > > apologies. > > > Now regarding home link registration, what is the mechanism MCoA > draft > > > uses? Ryuji mentioned some H bit but I read the draft and couldn't > confirm > > > it. > > > > > > My suggestion was building on this, i.e. I suggested that > whatever you > > > came up with can be moved to 3775bis so that other people would > not have to > > > make normative references to your draft. > > > > > > That's all. > > > > > > Regards, > > > > > > Behcet > > > > > > ________________________________ > > > From: George Tsirtsis > > > > To: Vijay Devarapalli > > > > Cc: Behcet Sarikaya >; mext > > > > Sent: Tuesday, April 21, 2009 2:14:55 PM > > > Subject: Re: [MEXT] [Fwd: I-D > Action:draft-ietf-monami6-multiplecoa-13.txt] > > > > > > ...also wrt the home link registration, I do not think what you > > > suggest is necessary. > > > > > > As far as I see the other documents are informational, and they do not > > > yet have a formal standing in the WG. If and when they do, as > > > Informational documents, they should not require normative changes to > > > anything. They should make sure what they describe (mostly > > > implementation options in this case) are compatible not only with > > > RFC3775 but also with extensions to it, including Flow Bindings. . > > > > > > > > > Regards > > > George > > > > > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli > > > > > wrote: > > >> Behcet, > > >> > > >> Behcet Sarikaya wrote: > > >>> > > >>> *[behcet] Yes but each interface will appear to HA as a > different device > > >>> and HA needs to assign a different HoA. Then MCoA problem > disappears.* > > >>> *So George is saying that this is avoided by some virtual > interfaces so > > >>> that HA does not see each interface separately. * > > >>> *Is this explained anywhere in the draft?* > > >>> *If yes then I am OK.* > > >> > > >> The home agent does not care about the multiple interfaces on the > mobile > > >> node. It only sees the mobile node as one entity and allocates a home > > >> address to it. The multiple care-of addresses that the mobile > node has > > >> will > > >> be used by the home agent as tunnel end points. That is all. So > there is > > >> no > > >> issue. > > >> > > >> Vijay > > >> > > >>> > Also I have a question to Ryuji: does this draft send a > > >>> non-deregistration BU at the home link? If yes, is he familiar > with the > > >>> discussion going on on this subject? This is another point of > confusion > > >>> for > > >>> me. > > >>> > > >>> This has been discussed for a long time in MEXT. > > >>> who is familiar with which discussions? I don't know your > concern here. > > >>> *[behcet] So your answer is yes the draft sends a > non-deregistration BU > > >>> (kind of bulk registration) at the home link.* > > >>> *The discussion I mentioned was related to > > >>> draft-premec-mext-extended-home-link. This draft also sends > > >>> non-deregistration BU at the home link. So does a few more > drafts like > > >>> **draft-devarapalli-mext-mipv6-home-link.* > > >>> > > >>> ** > > >>> *[behcet] You mentioned some bit is set but I could not > understand which. > > >>> One idea is since so many drafts need this, why not factor this > out and > > >>> define whatever the mechanism to enable sending > non-deregistration BU in > > >>> 3775bis. What do you think about that?* > > >>> > > >>> ** > > >>> > > >>> > Sorry if I am too much confused > > >>> > Please don't get me wrong, I am not trying to slow down the > progress > > >>> of > > >>> this document.. > > >>> > > >>> sure, but please explain your issue more precisely. > > >>> > > >>> thanks! > > >>> ryuji > > >>> > > >>> > > > >>> > Regards, > > >>> > > > >>> > Behcet > > >>> > From: marcelo bagnulo braun > > >>> >> > > >>> > To: mext > >>; Julien Laganier > > >>> > > >>> >>; Jari Arkko > > >>> > >> > > >>> > Sent: Tuesday, April 21, 2009 11:03:05 AM > > >>> > Subject: [MEXT] [Fwd: I-D > > >>> Action:draft-ietf-monami6-multiplecoa-13.txt] > > >>> > > > >>> > We have this new version of the MCOA document that addresses the > > >>> comments received, including IESG review comments. > > >>> > To the best of my knowledge, the IESG is ok with the doc and > ready for > > >>> publication.. > > >>> > I am planning to ask our AD to move forward in a week or so, > so, if > > >>> you > > >>> have comments on the document please provide them before the 1st > of may. > > >>> > > > >>> > Regards, marcelo > > >>> > (mcoa doc shepherd) > > >>> > > > >>> > -------- Mensaje original -------- > > >>> > Asunto: [MEXT] I-D > Action:draft-ietf-monami6-multiplecoa-13.txt > > >>> > Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) > > >>> > De: Internet-Drafts@ietf.org > > > > >>> > Para: i-d-announce@ietf.org > > > > >>> > CC: mext@ietf.org > > > > >>> > > > >>> > > > >>> > > > >>> > A New Internet-Draft is available from the on-line > Internet-Drafts > > >>> directories. > > >>> > This draft is a work item of the Mobility EXTensions for IPv6 > Working > > >>> Group of the IETF. > > >>> > > > >>> > > > >>> > Title : Multiple Care-of Addresses Registration > > >>> > Author(s) : R. Wakikawa, et al. > > >>> > Filename : draft-ietf-monami6-multiplecoa-13..txt > > >>> > Pages : 44 > > >>> > Date : 2009-04-20 > > >>> > > > >>> > According to the current Mobile IPv6 specification, a mobile > node may > > >>> > have several care-of addresses, but only one, called the primary > > >>> > care-of address, that can be registered with its home agent > and the > > >>> > correspondent nodes. However, for matters of cost, > bandwidth, delay, > > >>> > etc, it is useful for the mobile node to get Internet access > through > > >>> > multiple accesses simultaneously, in which case the mobile > node would > > >>> > be configured with multiple active IPv6 care-of addresses. This > > >>> > document proposes extensions to the Mobile IPv6 protocol to > register > > >>> > and use multiple care-of addresses. The extensions proposed > in this > > >>> > document can be used by Mobile Routers using the NEMO (Network > > >>> > Mobility) Basic Support protocol as well. > > >>> > > > >>> > A URL for this Internet-Draft is: > > >>> > > > >>> > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.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. > > >>> > > > >>> > > > >>> > > > >>> > _______________________________________________ > > >>> > MEXT mailing list > > >>> > MEXT@ietf.org > > > >>> > https://www.ietf.org/mailman/listinfo/mext > > >>> > > >>> > > >>> > > >>> > ------------------------------------------------------------------------ > > >>> > > >>> _______________________________________________ > > >>> MEXT mailing list > > >>> MEXT@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mext > > >> > > >> _______________________________________________ > > >> MEXT mailing list > > >> MEXT@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mext > > >> > > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > ------------------------------------------------------------------------ > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From ryuji.wakikawa@gmail.com Wed Apr 22 15:01:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D3F3A6963 for ; Wed, 22 Apr 2009 15:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 i3oPIhnfIGMm for ; Wed, 22 Apr 2009 15:01:12 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id 09B0F3A6D4B for ; Wed, 22 Apr 2009 15:00:54 -0700 (PDT) Received: by qyk42 with SMTP id 42so432222qyk.29 for ; Wed, 22 Apr 2009 15:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=aoeoXKsy41f/yyPCMmGTS1Y6z3NVvuXwECLcrZ2czAI=; b=UYda4tVvf6tJrKhBrRZJjSyzstAWGz/FvCqWqbKAHe0VdSXSV+lvwbTxnBLzXuY5gQ BeO1pAddfVo+j0B4hfFqsaRxmz+tVnJyQW3GfjN34wLHzH5MweKgp0a+wcbsEtUOsnT7 WDWCLaS75zMYgm9xLTNxc6T1qvr/ZS8aaHZEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=Sc4ydNXERoN+wbnqycU4wSbTtpSIsfuzAGCZeEfZMnGd8fjAJoNGImidToCOdVAFcl ujavNeSVbNnw73MKVpmem8KG+E/H3JOPG2KEQ9ZEE1RlGREsST8wU3kDTfC7GZZvqToW YrphepewhmdT+gWJV7SFwj8ZKjl/05SCnrq0E= Received: by 10.224.53.203 with SMTP id n11mr471906qag.192.1240437732217; Wed, 22 Apr 2009 15:02:12 -0700 (PDT) Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id 4sm1608043yxq.28.2009.04.22.15.02.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Apr 2009 15:02:11 -0700 (PDT) From: Ryuji Wakikawa To: Behcet Sarikaya In-Reply-To: <222821.303.qm@web111407.mail.gq1.yahoo.com> References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> <375902.20727.qm@web111403.mail.gq1.yahoo.com> <8CF30647-6A19-4391-BE7E-CFE87EFD8EAD@gmail.com> <222821.303.qm@web111407.mail.gq1.yahoo.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 18:02:09 -0400 X-Mailer: Apple Mail (2.930.3) Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 22:01:13 -0000 Hi Behcet, On 2009/04/22, at 17:45, Behcet Sarikaya wrote: > Hi Ryuji, > I checked your draft. Again, I could not understand how you are > sending a registration BU at the home link as only an O-flag is > defined in your draft which is used for something else. Please see section 5.6.3 > As I mentioned to you, we discussed this related to draft-premec- > homelink and it seems like HA will reject such a BU unless something > is done, I thought you were familiar with the discussions as it > relates to your draft too. I am surprised. yes, I follow that discussion. RFC3775-bis should not include any additional features like sending BU from the home link. We should define this in MCoA. Only if needed, draft-homelink can refer to MCoA for this feature. regards, ryuji > > Regards, > > Behcet > > From: Ryuji Wakikawa > To: Behcet Sarikaya > Cc: George Tsirtsis ; mext > Sent: Wednesday, April 22, 2009 4:18:28 PM > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > Hi Behcet, > > On 2009/04/22, at 11:31, Behcet Sarikaya wrote: > > > > > > > From: George Tsirtsis > > To: Behcet Sarikaya > > Cc: mext > > Sent: Wednesday, April 22, 2009 10:10:08 AM > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > I do not think that adding home link registration to RFC3775bis is > feasible. > > This requires logic in the MN and HA that is not directly compatible > > to RFC3775. The aim of RFC3775bis is to make minimal changes for > > clarification reasons and to correct errors. Home Link > Registration as > > defined in MCoA is neither. > > [behcet] Why not? If it is needed in so many instances, that > qualifies it to become a base protocol feature, at least to me. > > We cannot add a new feature to 3775. That is the ground rule of - > bis. The chairs can clarify this. > > regards, > ryuji > > > > > > > On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya > > wrote: > > > Hi George, > > > It seems in my previous reply I replied to this mail of yours > which was > > > unrelated to the other mail you sent to which I was really > replying, > > > apologies. > > > Now regarding home link registration, what is the mechanism > MCoA draft > > > uses? Ryuji mentioned some H bit but I read the draft and > couldn't confirm > > > it. > > > > > > My suggestion was building on this, i.e. I suggested that > whatever you > > > came up with can be moved to 3775bis so that other people would > not have to > > > make normative references to your draft. > > > > > > That's all. > > > > > > Regards, > > > > > > Behcet > > > > > > ________________________________ > > > From: George Tsirtsis > > > To: Vijay Devarapalli > > > Cc: Behcet Sarikaya ; mext > > > Sent: Tuesday, April 21, 2009 2:14:55 PM > > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > > > ...also wrt the home link registration, I do not think what you > > > suggest is necessary. > > > > > > As far as I see the other documents are informational, and they > do not > > > yet have a formal standing in the WG. If and when they do, as > > > Informational documents, they should not require normative > changes to > > > anything. They should make sure what they describe (mostly > > > implementation options in this case) are compatible not only with > > > RFC3775 but also with extensions to it, including Flow Bindings. . > > > > > > > > > Regards > > > George > > > > > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli > > > > wrote: > > >> Behcet, > > >> > > >> Behcet Sarikaya wrote: > > >>> > > >>> *[behcet] Yes but each interface will appear to HA as a > different device > > >>> and HA needs to assign a different HoA. Then MCoA problem > disappears.* > > >>> *So George is saying that this is avoided by some virtual > interfaces so > > >>> that HA does not see each interface separately. * > > >>> *Is this explained anywhere in the draft?* > > >>> *If yes then I am OK.* > > >> > > >> The home agent does not care about the multiple interfaces on > the mobile > > >> node. It only sees the mobile node as one entity and allocates > a home > > >> address to it. The multiple care-of addresses that the mobile > node has > > >> will > > >> be used by the home agent as tunnel end points. That is all. So > there is > > >> no > > >> issue. > > >> > > >> Vijay > > >> > > >>> > Also I have a question to Ryuji: does this draft send a > > >>> non-deregistration BU at the home link? If yes, is he familiar > with the > > >>> discussion going on on this subject? This is another point of > confusion > > >>> for > > >>> me. > > >>> > > >>> This has been discussed for a long time in MEXT. > > >>> who is familiar with which discussions? I don't know your > concern here. > > >>> *[behcet] So your answer is yes the draft sends a non- > deregistration BU > > >>> (kind of bulk registration) at the home link.* > > >>> *The discussion I mentioned was related to > > >>> draft-premec-mext-extended-home-link. This draft also sends > > >>> non-deregistration BU at the home link. So does a few more > drafts like > > >>> **draft-devarapalli-mext-mipv6-home-link.* > > >>> > > >>> ** > > >>> *[behcet] You mentioned some bit is set but I could not > understand which. > > >>> One idea is since so many drafts need this, why not factor > this out and > > >>> define whatever the mechanism to enable sending non- > deregistration BU in > > >>> 3775bis. What do you think about that?* > > >>> > > >>> ** > > >>> > > >>> > Sorry if I am too much confused > > >>> > Please don't get me wrong, I am not trying to slow down the > progress > > >>> of > > >>> this document.. > > >>> > > >>> sure, but please explain your issue more precisely. > > >>> > > >>> thanks! > > >>> ryuji > > >>> > > >>> > > > >>> > Regards, > > >>> > > > >>> > Behcet > > >>> > From: marcelo bagnulo braun > >>> > > > >>> > To: mext >; Julien > Laganier > > >>> > >>> >; Jari Arkko > > >>> > > > >>> > Sent: Tuesday, April 21, 2009 11:03:05 AM > > >>> > Subject: [MEXT] [Fwd: I-D > > >>> Action:draft-ietf-monami6-multiplecoa-13.txt] > > >>> > > > >>> > We have this new version of the MCOA document that > addresses the > > >>> comments received, including IESG review comments. > > >>> > To the best of my knowledge, the IESG is ok with the doc > and ready for > > >>> publication.. > > >>> > I am planning to ask our AD to move forward in a week or > so, so, if > > >>> you > > >>> have comments on the document please provide them before the > 1st of may. > > >>> > > > >>> > Regards, marcelo > > >>> > (mcoa doc shepherd) > > >>> > > > >>> > -------- Mensaje original -------- > > >>> > Asunto: [MEXT] I-D Action:draft-ietf-monami6- > multiplecoa-13.txt > > >>> > Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) > > >>> > De: Internet-Drafts@ietf.org > > > >>> > Para: i-d-announce@ietf.org > > >>> > CC: mext@ietf.org > > >>> > > > >>> > > > >>> > > > >>> > A New Internet-Draft is available from the on-line Internet- > Drafts > > >>> directories. > > >>> > This draft is a work item of the Mobility EXTensions for > IPv6 Working > > >>> Group of the IETF. > > >>> > > > >>> > > > >>> > Title : Multiple Care-of Addresses Registration > > >>> > Author(s) : R. Wakikawa, et al. > > >>> > Filename : draft-ietf-monami6-multiplecoa-13..txt > > >>> > Pages : 44 > > >>> > Date : 2009-04-20 > > >>> > > > >>> > According to the current Mobile IPv6 specification, a > mobile node may > > >>> > have several care-of addresses, but only one, called the > primary > > >>> > care-of address, that can be registered with its home agent > and the > > >>> > correspondent nodes. However, for matters of cost, > bandwidth, delay, > > >>> > etc, it is useful for the mobile node to get Internet > access through > > >>> > multiple accesses simultaneously, in which case the mobile > node would > > >>> > be configured with multiple active IPv6 care-of addresses. > This > > >>> > document proposes extensions to the Mobile IPv6 protocol to > register > > >>> > and use multiple care-of addresses. The extensions > proposed in this > > >>> > document can be used by Mobile Routers using the NEMO > (Network > > >>> > Mobility) Basic Support protocol as well. > > >>> > > > >>> > A URL for this Internet-Draft is: > > >>> > > > >>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.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. > > >>> > > > >>> > > > >>> > > > >>> > _______________________________________________ > > >>> > MEXT mailing list > > >>> > MEXT@ietf.org > > >>> > https://www.ietf.org/mailman/listinfo/mext > > >>> > > >>> > > >>> > > >>> > ------------------------------------------------------------------------ > > >>> > > >>> _______________________________________________ > > >>> MEXT mailing list > > >>> MEXT@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mext > > >> > > >> _______________________________________________ > > >> MEXT mailing list > > >> MEXT@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mext > > >> > > > > > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > From behcetsarikaya@yahoo.com Wed Apr 22 15:53:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51863A6D04 for ; Wed, 22 Apr 2009 15:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 ZM9sHwj-mocA for ; Wed, 22 Apr 2009 15:53:02 -0700 (PDT) Received: from n62.bullet.mail.sp1.yahoo.com (n62.bullet.mail.sp1.yahoo.com [98.136.44.35]) by core3.amsl.com (Postfix) with SMTP id EE0503A6DD9 for ; Wed, 22 Apr 2009 15:53:02 -0700 (PDT) Received: from [69.147.84.145] by n62.bullet.mail.sp1.yahoo.com with NNFMP; 22 Apr 2009 22:54:20 -0000 Received: from [67.195.9.82] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 22 Apr 2009 22:54:20 -0000 Received: from [67.195.9.109] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 22:54:20 -0000 Received: from [127.0.0.1] by omp113.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 22:53:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 409896.71105.bm@omp113.mail.gq1.yahoo.com Received: (qmail 85065 invoked by uid 60001); 22 Apr 2009 22:54:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240440859; bh=nb7o/n5xrQvJQp2kulgkcT9xQWIjRSn+irwO9/rhEoM=; 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=gnyN69Gob2CSMSFGbDiB8s9MsuECN5QwzidFJ3JKBKtC54jhEY7CXOKtyd/Y+e55NGpW1ZBAsaTSPoMpDJtLa2rIWIILUrAaGRs11MsJVg4WGJsUIY8yweRbsOtHxu0y4t9fxpanleUnvnFGaWbZ/o+Pd/o/fcS6Dk28nZ5VAZU= 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=d4QcTQpWTT5I3oW5K7tEsHBwKOBA3VJ2ZqClKsJwyu7dlDMcNUFw9ENlzbxBvjkRq9W+m2Qe96ZsNiI1hianOet+/RnTmmEDJqOKvuVlFGmHTS/LOLQB7D5ZLBz2rgCaWyXU9uQigr+oyHcih0hKs/16cmzs7PbP8KTuTY0M/4U=; Message-ID: <954696.84777.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: H06tleYVM1msI.he8SPLp6xKdsW.5RFY..aXSPWKJAR99mLjyNj51jdKKD6C0zpjNpcGBHwPEThs30vTC9.ATaQKio1DSS9dleKwwaOwV7uQNix4iE1WOiFuYccNeAE2DPl8LYKeJuGdrNl3V_Jfb2O_vzoLFEAgNgS83LGz9voLXOpoWWKHOCqCnXRjdhNwkm8l.dzuaOXPkxiTXjYMsyDj2aam9kXpaFZbaM_lWuLoVfS9ckM4pSlbtmWUkw_vPEeQ8N95BLv7h7fxVStb8nwPRmI4Jt_tuN3RlDCe52MOXaIxO2EfrgIRvq7jdEMffTS1 Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Wed, 22 Apr 2009 15:54:19 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> <375902.20727.qm@web111403.mail.gq1.yahoo.com> <8CF30647-6A19-4391-BE7E-CFE87EFD8EAD@gmail.com> <222821.303.qm@web111407.mail.gq1.yahoo.com> Date: Wed, 22 Apr 2009 15:54:19 -0700 (PDT) From: Behcet Sarikaya To: Ryuji Wakikawa In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1433417315-1240440859=:84777" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 22:53:04 -0000 --0-1433417315-1240440859=:84777 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ryuji,=0A=A0 So you are going to define a C-Flag?=0AI am OK with it. But= I don't understand why the only right place is your draft. My idea is that= the right place for such a thing is 3775bis as this would avoid people wit= h drafts not related to MCoA having to refer to MCoA draft.=0A=0ARegards,= =0A=0ABehcet=0A=0A=0A=0A=0A________________________________=0AFrom: Ryuji W= akikawa =0ATo: Behcet Sarikaya =0ACc: mext =0ASent: Wednesday, April 22, 2009 5:02:09 PM= =0ASubject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.t= xt]=0A=0AHi Behcet,=0A=0AOn 2009/04/22, at 17:45, Behcet Sarikaya wrote:=0A= =0A> Hi Ryuji,=0A>=A0 I checked your draft. Again, I could not understand h= ow you are sending a registration BU at the home link as only an O-flag is = defined in your draft which is used for something else.=0A=0APlease see sec= tion 5.6.3=0A=0A>=A0 As I mentioned to you, we discussed this related to dr= aft-premec-homelink and it seems like HA will reject such a BU unless somet= hing is done, I thought you were familiar with the discussions as it relate= s to your draft too. I am surprised.=0A=0Ayes, I follow that discussion.=0A= RFC3775-bis should not include any additional features like sending BU from= the home link.=0AWe should define this in MCoA. Only if needed, draft-home= link can refer to MCoA for this feature.=0A=0Aregards,=0Aryuji=0A=0A=0A=0A= =0A=0A=0A> =0A> Regards,=0A> =0A> Behcet=0A> =0A> From: Ryuji Wakikawa =0A> To: Behcet Sarikaya =0A> Cc: = George Tsirtsis ; mext =0A> Sent: W= ednesday, April 22, 2009 4:18:28 PM=0A> Subject: Re: [MEXT] [Fwd: I-D Actio= n:draft-ietf-monami6-multiplecoa-13.txt]=0A> =0A> Hi Behcet,=0A> =0A> On 20= 09/04/22, at 11:31, Behcet Sarikaya wrote:=0A> =0A> >=0A> >=0A> > From: Geo= rge Tsirtsis =0A> > To: Behcet Sarikaya =0A> > Cc: mext =0A> > Sent: Wednesday, April 22, 2= 009 10:10:08 AM=0A> > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monam= i6-multiplecoa-13.txt]=0A> >=0A> > I do not think that adding home link reg= istration to RFC3775bis is feasible.=0A> > This requires logic in the MN an= d HA that is not directly compatible=0A> > to RFC3775. The aim of RFC3775bi= s is to make minimal changes for=0A> > clarification reasons and to correct= errors. Home Link Registration as=0A> > defined in MCoA is neither.=0A> > = [behcet] Why not? If it is needed in so many instances, that qualifies it t= o become a base protocol feature, at least to me.=0A> =0A> We cannot add a = new feature to 3775. That is the ground rule of -bis. The chairs can clarif= y this.=0A> =0A> regards,=0A> ryuji=0A> =0A> =0A> =0A> >=0A> > On Wed, Apr = 22, 2009 at 4:06 PM, Behcet Sarikaya=0A> > wrote= :=0A> > > Hi George,=0A> > >=A0 It seems in my previous reply I replied to = this mail of yours which was=0A> > > unrelated to the other mail you sent t= o which I was really replying,=0A> > > apologies.=0A> > >=A0 Now regarding = home link registration, what is the mechanism MCoA draft=0A> > > uses? Ryuj= i mentioned some H bit but I read the draft and couldn't confirm=0A> > > it= ..=0A> > >=0A> > >=A0 My suggestion was building on this, i.e. I suggested t= hat whatever you=0A> > > came up with can be moved to 3775bis so that other= people would not have to=0A> > > make normative references to your draft.= =0A> > >=0A> > > That's all.=0A> > >=0A> > > Regards,=0A> > >=0A> > > Behce= t=0A> > >=0A> > > ________________________________=0A> > > From: George Tsi= rtsis =0A> > > To: Vijay Devarapalli =0A> > > Cc: Behcet Sarikaya ; mext =0A> > > Sent: Tuesday, April 21, 2009 2:14:55 PM=0A> > > Subject: Re: [M= EXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> > >=0A> > = > ...also wrt the home link registration, I do not think what you=0A> > > s= uggest is necessary.=0A> > >=0A> > > As far as I see the other documents ar= e informational, and they do not=0A> > > yet have a formal standing in the = WG. If and when they do, as=0A> > > Informational documents,=A0 they should= not require normative changes to=0A> > > anything. They should make sure w= hat they describe (mostly=0A> > > implementation options in this case) are = compatible not only with=0A> > > RFC3775 but also with extensions to it, in= cluding Flow Bindings. .=0A> > >=0A> > >=0A> > > Regards=0A> > > George=0A>= > >=0A> > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli =0A> > > wrote:=0A> > >> Behcet,=0A> > >>=0A> > >> Behcet Sarikaya= wrote:=0A> > >>>=0A> > >>> *[behcet] Yes but each interface will appear to= HA as a different device=0A> > >>> and HA needs to assign a different HoA.= Then MCoA problem disappears.*=0A> > >>> *So George is saying that this is= avoided by some virtual interfaces so=0A> > >>> that HA does not see each = interface separately. *=0A> > >>> *Is this explained anywhere in the draft?= *=0A> > >>> *If yes then I am OK.*=0A> > >>=0A> > >> The home agent does no= t care about the multiple interfaces on the mobile=0A> > >> node. It only s= ees the mobile node as one entity and allocates a home=0A> > >> address to = it. The multiple care-of addresses that the mobile node has=0A> > >> will= =0A> > >> be used by the home agent as tunnel end points. That is all. So t= here is=0A> > >> no=0A> > >> issue.=0A> > >>=0A> > >> Vijay=0A> > >>=0A> > = >>>=A0 >=A0 Also I have a question to Ryuji: does this draft send a=0A> > >= >> non-deregistration BU at the home link? If yes, is he familiar with the= =0A> > >>> discussion going on on this subject? This is another point of co= nfusion=0A> > >>> for=0A> > >>> me.=0A> > >>>=0A> > >>> This has been discu= ssed for a long time in MEXT.=0A> > >>> who is familiar with which discussi= ons? I don't know your concern here.=0A> > >>>=A0 *[behcet] So your answer = is yes the draft sends a non-deregistration BU=0A> > >>> (kind of bulk regi= stration) at the home link.*=0A> > >>> *The discussion I mentioned was rela= ted to=0A> > >>> draft-premec-mext-extended-home-link. This draft also send= s=0A> > >>> non-deregistration BU at the home link. So does a few more draf= ts like=0A> > >>> **draft-devarapalli-mext-mipv6-home-link.*=0A> > >>>=0A> = > >>> **=0A> > >>> *[behcet] You mentioned some bit is set but I could not = understand which.=0A> > >>> One idea is since so many drafts need this, why= not factor this out and=0A> > >>> define whatever the mechanism to enable = sending non-deregistration BU in=0A> > >>> 3775bis. What do you think about= that?*=0A> > >>>=0A> > >>> **=0A> > >>>=0A> > >>>=A0 >=A0 Sorry if I am to= o=A0 much confused=0A> > >>>=A0 > Please don't get me wrong, I am not tryin= g to slow down the progress=0A> > >>> of=0A> > >>> this document..=0A> > >>= >=0A> > >>> sure, but please explain your issue more precisely.=0A> > >>>= =0A> > >>> thanks!=0A> > >>> ryuji=0A> > >>>=0A> > >>>=A0 >=0A> > >>>=A0 > = Regards,=0A> > >>>=A0 >=0A> > >>>=A0 > Behcet=0A> > >>>=A0 > From: marcelo = bagnulo braun > >>> >=0A= > > >>>=A0 > To: mext >; Julien Lagani= er=0A> > >>> > >>> >; Jari Arkko=0A> > >>> >=0A> > >>>=A0 > Sent: Tuesday, April 21, 200= 9 11:03:05 AM=0A> > >>>=A0 > Subject: [MEXT] [Fwd: I-D=0A> > >>> Action:dra= ft-ietf-monami6-multiplecoa-13.txt]=0A> > >>>=A0 >=0A> > >>>=A0 > We have t= his new version of the MCOA document that addresses the=0A> > >>> comments = received, including IESG review comments.=0A> > >>>=A0 > To the best of my = knowledge, the IESG is ok with the doc and ready for=0A> > >>> publication.= ..=0A> > >>>=A0 > I am planning to ask our AD to move forward in a week or s= o, so, if=0A> > >>> you=0A> > >>> have comments on the document please prov= ide them before the 1st of may.=0A> > >>>=A0 >=0A> > >>>=A0 > Regards, marc= elo=0A> > >>>=A0 > (mcoa doc shepherd)=0A> > >>>=A0 >=0A> > >>>=A0 > ------= -- Mensaje original --------=0A> > >>>=A0 > Asunto:=A0 =A0 [MEXT] I-D Actio= n:draft-ietf-monami6-multiplecoa-13.txt=0A> > >>>=A0 > Fecha:=A0 =A0 Mon, 2= 0 Apr 2009 08:30:01 -0700 (PDT)=0A> > >>>=A0 > De:=A0 =A0 Internet-Drafts@i= etf.org =0A> > >>>=A0 > Para:=A0 =A0 i-d-a= nnounce@ietf.org =0A> > >>>=A0 > CC:=A0 =A0 m= ext@ietf.org =0A> > >>>=A0 >=0A> > >>>=A0 >=0A> > >>>= =A0 >=0A> > >>>=A0 > A New Internet-Draft is available from the on-line Int= ernet-Drafts=0A> > >>> directories.=0A> > >>>=A0 > This draft is a work ite= m of the Mobility EXTensions for IPv6 Working=0A> > >>> Group of the IETF.= =0A> > >>>=A0 >=0A> > >>>=A0 >=0A> > >>>=A0 >=A0 =A0 Title=A0 =A0 =A0 =A0 = =A0 : Multiple Care-of Addresses Registration=0A> > >>>=A0 >=A0 =A0 Author(= s)=A0 =A0 =A0 : R. Wakikawa, et al.=0A> > >>>=A0 >=A0 =A0 Filename=A0 =A0 = =A0 =A0 : draft-ietf-monami6-multiplecoa-13..txt=0A> > >>>=A0 >=A0 =A0 Page= s=A0 =A0 =A0 =A0 =A0 : 44=0A> > >>>=A0 >=A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0= : 2009-04-20=0A> > >>>=A0 >=0A> > >>>=A0 > According to the current Mobile= IPv6 specification, a mobile node may=0A> > >>>=A0 > have several care-of = addresses, but only one, called the primary=0A> > >>>=A0 > care-of address,= that can be registered with its home agent and the=0A> > >>>=A0 > correspo= ndent nodes.=A0 However, for matters of cost, bandwidth, delay,=0A> > >>>= =A0 > etc, it is useful for the mobile node to get Internet access through= =0A> > >>>=A0 > multiple accesses simultaneously, in which case the mobile = node would=0A> > >>>=A0 > be configured with multiple active IPv6 care-of a= ddresses.=A0 This=0A> > >>>=A0 > document proposes extensions to the Mobile= IPv6 protocol to register=0A> > >>>=A0 > and use multiple care-of addresse= s.=A0 The extensions proposed in this=0A> > >>>=A0 > document can be used b= y Mobile Routers using the NEMO (Network=0A> > >>>=A0 > Mobility) Basic Sup= port protocol as well.=0A> > >>>=A0 >=0A> > >>>=A0 > A URL for this Interne= t-Draft is:=0A> > >>>=A0 >=0A> > >>> http://www.ietf.org/internet-drafts/dr= aft-ietf-monami6-multiplecoa-13.txt=0A> > >>>=A0 >=0A> > >>>=A0 > Internet-= Drafts are also available by anonymous FTP at:=0A> > >>>=A0 > ftp://ftp.iet= f.org/internet-drafts/=0A> > >>>=A0 >=0A> > >>>=A0 > Below is the data whic= h will enable a MIME compliant mail reader=0A> > >>>=A0 > implementation to= automatically retrieve the ASCII version of the=0A> > >>>=A0 > Internet-Dr= aft.=0A> > >>>=A0 >=0A> > >>>=A0 >=0A> > >>>=A0 >=0A> > >>>=A0 > __________= _____________________________________=0A> > >>>=A0 > MEXT mailing list=0A> = > >>>=A0 > MEXT@ietf.org =0A> > >>>=A0 > https://www.= ietf.org/mailman/listinfo/mext=0A> > >>>=0A> > >>>=0A> > >>>=0A> > >>> ----= --------------------------------------------------------------------=0A> > = >>>=0A> > >>> _______________________________________________=0A> > >>> MEX= T mailing list=0A> > >>> MEXT@ietf.org=0A> > >>> https://www.ietf.org/mailm= an/listinfo/mext=0A> > >>=0A> > >> ________________________________________= _______=0A> > >> MEXT mailing list=0A> > >> MEXT@ietf.org=0A> > >> https://= www.ietf.org/mailman/listinfo/mext=0A> > >>=0A> > >=0A> > >=0A> >=0A> > ___= ____________________________________________=0A> > MEXT mailing list=0A> > = MEXT@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/mext=0A> =0A> =0A= > =0A=0A=0A --0-1433417315-1240440859=:84777 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ryuji,
=0A
  So you are going to defi= ne a C-Flag?
=0A
I am OK with it. But I don't understand why the o= nly right place is your draft. My idea is that the right place for such a t= hing is 3775bis as this would avoid people with drafts not related to MCoA = having to refer to MCoA draft.
=0A
 
=0A
Regards,=0A
 
=0A
Behcet
=0A

=0A
=0A
=0AFrom: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
To: Behcet Sarikaya <sarikaya@= ieee.org>
Cc: mext &l= t;mext@ietf.org>
Sent: Wednesday, April 22, 2009 5:02:09 PM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-mult= iplecoa-13.txt]

Hi Behcet,

On 2009/04/22, at 17:45, Be= hcet Sarikaya wrote:

> Hi Ryuji,
>  I checked your dra= ft. Again, I could not understand how you are sending a registration BU at = the home link as only an O-flag is defined in your draft which is used for = something else.

Please see section 5.6.3

>  As I ment= ioned to you, we discussed this related to draft-premec-homelink and it see= ms like HA will reject such a BU unless something is done, I thought you were familiar with the discussions as it = relates to your draft too. I am surprised.

yes, I follow that discus= sion.
RFC3775-bis should not include any additional features like sendin= g BU from the home link.
We should define this in MCoA. Only if needed, = draft-homelink can refer to MCoA for this feature.

regards,
ryuji=






>
> Regards,
>
> Behcet<= BR>>
> From: Ryuji Wakikawa <ryuji.wakikawa@gmail= ..com>
> To: Behcet Sarikaya <sarikaya@ieee.org>
&g= t; Cc: George Tsirtsis <tsirtsis@googlemail.com>; mext= <mext@ietf.org>
> Sent: Wedne= sday, April 22, 2009 4:18:28 PM
> Subject: Re: [MEXT] [Fwd: I-D Actio= n:draft-ietf-monami6-multiplecoa-13.txt]
>
> Hi Behcet,
>= ;
> On 2009/04/22, at 11:31, Behcet Sarikaya wrote:
>
>= >
> >
> > From: George Tsirtsis <tsirts= is@googlemail.com>
> > To: Behcet Sarikaya <sarikaya@ieee= ..org>
> > Cc: mext <mext@ietf.org>
> > Sent: Wedn= esday, April 22, 2009 10:10:08 AM
> > Subject: Re: [MEXT] [Fwd: I-= D Action:draft-ietf-monami6-multiplecoa-13.txt]
> >
> > I= do not think that adding home link registration to RFC3775bis is feasible.
> > This requires logic in the MN and HA that is not di= rectly compatible
> > to RFC3775. The aim of RFC3775bis is to make= minimal changes for
> > clarification reasons and to correct erro= rs. Home Link Registration as
> > defined in MCoA is neither.
&= gt; > [behcet] Why not? If it is needed in so many instances, that quali= fies it to become a base protocol feature, at least to me.
>
>= We cannot add a new feature to 3775. That is the ground rule of -bis. The = chairs can clarify this.
>
> regards,
> ryuji
> >
>
> >
> > On Wed, Apr 22, 2009 at 4:06 PM,= Behcet Sarikaya
> > <behcetsarikaya@yahoo.com= > wrote:
> > > Hi George,
> > >  It seems i= n my previous reply I replied to this mail of yours which was
> > > unrelated to the other mail you sent to which I was really reply= ing,
> > > apologies.
> > >  Now regarding hom= e link registration, what is the mechanism MCoA draft
> > > use= s? Ryuji mentioned some H bit but I read the draft and couldn't confirm
= > > > it.
> > >
> > >  My suggestion = was building on this, i.e. I suggested that whatever you
> > > = came up with can be moved to 3775bis so that other people would not have to=
> > > make normative references to your draft.
> > &g= t;
> > > That's all.
> > >
> > > Regard= s,
> > >
> > > Behcet
> > >
> >= ; > ________________________________
> > > From: George Tsir= tsis <tsirtsis@googlemail.com>
> > > To: Vijay Devarapalli <vijay@wichorus.com>
> > > Cc= : Behcet Sarikaya <sarikaya@ieee.org>; mext <mext@ietf.org>
&g= t; > > Sent: Tuesday, April 21, 2009 2:14:55 PM
> > > Sub= ject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]> > >
> > > ...also wrt the home link registration, I= do not think what you
> > > suggest is necessary.
> >= >
> > > As far as I see the other documents are information= al, and they do not
> > > yet have a formal standing in the WG.= If and when they do, as
> > > Informational documents,  t= hey should not require normative changes to
> > > anything. The= y should make sure what they describe (mostly
> > > implementati= on options in this case) are compatible not only with
> > > RFC= 3775 but also with extensions to it, including Flow Bindings. .
> >= ; >
> > >
> > > Regards
> > > George=
> > >
> > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay= Devarapalli <vijay@wichorus.com>
> > > wrote:
&g= t; > >> Behcet,
> > >>
> > >> Behcet= Sarikaya wrote:
> > >>>
> > >>> *[behc= et] Yes but each interface will appear to HA as a different device
> = > >>> and HA needs to assign a different HoA. Then MCoA problem= disappears.*
> > >>> *So George is saying that this is a= voided by some virtual interfaces so
> > >>> that HA does not see each interface separately. *
> > >>> *Is th= is explained anywhere in the draft?*
> > >>> *If yes then= I am OK.*
> > >>
> > >> The home agent does = not care about the multiple interfaces on the mobile
> > >> = node. It only sees the mobile node as one entity and allocates a home
&g= t; > >> address to it. The multiple care-of addresses that the mob= ile node has
> > >> will
> > >> be used by th= e home agent as tunnel end points. That is all. So there is
> > &g= t;> no
> > >> issue.
> > >>
> > &= gt;> Vijay
> > >>
> > >>>  >&nb= sp; Also I have a question to Ryuji: does this draft send a
> > &g= t;>> non-deregistration BU at the home link? If yes, is he familiar w= ith the
> > >>> discussion going on on this subject? This is another point of confusion
> > >>> for<= BR>> > >>> me.
> > >>>
> > >&g= t;> This has been discussed for a long time in MEXT.
> > >&g= t;> who is familiar with which discussions? I don't know your concern he= re.
> > >>>  *[behcet] So your answer is yes the dra= ft sends a non-deregistration BU
> > >>> (kind of bulk re= gistration) at the home link.*
> > >>> *The discussion I = mentioned was related to
> > >>> draft-premec-mext-extend= ed-home-link. This draft also sends
> > >>> non-deregistr= ation BU at the home link. So does a few more drafts like
> > >= >> **draft-devarapalli-mext-mipv6-home-link.*
> > >>&g= t;
> > >>> **
> > >>> *[behcet] You men= tioned some bit is set but I could not understand which.
> > >>> One idea is since so many drafts need this, why not fact= or this out and
> > >>> define whatever the mechanism to = enable sending non-deregistration BU in
> > >>> 3775bis. = What do you think about that?*
> > >>>
> > >&= gt;> **
> > >>>
> > >>>  >&n= bsp; Sorry if I am too  much confused
> > >>>  = > Please don't get me wrong, I am not trying to slow down the progress> > >>> of
> > >>> this document..
&g= t; > >>>
> > >>> sure, but please explain you= r issue more precisely.
> > >>>
> > >>>= thanks!
> > >>> ryuji
> > >>>
> = > >>>  >
> > >>>  > Regards,<= BR>> > >>>  >
> > >>>  > Behcet
> > >>>  > From: marcelo bagnulo bra= un <marcelo@it.uc3m.es
> > >>> <mailto:marcel= o@it.uc3m.es>>
> > >>>  > To: mext <= mext@ietf= ..org <mailto:mext@ietf.org>>; Julien Laganier
> > >>= > <julien.laganier.ietf@googlemail= ..com
> > >>> <mailto:julien.laganier..ietf@googlemail.com>>; Jari Arkko
>= ; > >>> <jari.arkko@piuha.net <mailto:jari.arkko@= piuha.net>>
> > >>>  > Sent: Tuesday, A= pril 21, 2009 11:03:05 AM
> > >>>  > Subject: [ME= XT] [Fwd: I-D
> > >>> Action:draft-ietf-monami6-multiplec= oa-13.txt]
> > >>>  >
> > >>>&n= bsp; > We have this new version of the MCOA document that addresses the<= BR>> > >>> comments received, including IESG review comments= ..
> > >>>  > To the best of my knowledge, the IES= G is ok with the doc and ready for
> > >>> publication..<= BR>> > >>>  > I am planning to ask our AD to move fo= rward in a week or so, so, if
> > >>> you
> > >>> have comments on the document please provide them before the = 1st of may.
> > >>>  >
> > >>>&= nbsp; > Regards, marcelo
> > >>>  > (mcoa doc = shepherd)
> > >>>  >
> > >>>&nb= sp; > -------- Mensaje original --------
> > >>> = > Asunto:    [MEXT] I-D Action:draft-ietf-monami6-multiplecoa= -13.txt
> > >>>  > Fecha:    Mon, 20 Ap= r 2009 08:30:01 -0700 (PDT)
> > >>>  > De:  =   Internet-Drafts@ietf.org <mailto:In= ternet-Drafts@ietf.org>
> > >>>  > Para:&n= bsp;   i-d-announce@ietf.org <mai= lto:i-d-announce@ietf.org>
> > >>>  &g= t; CC:    mext@ietf.org <mailto:mext@ietf.org>
> > >>&= gt;  >
> > >>>  >
> > >>&g= t;  >
> > >>>  > A New Internet-Draft is = available from the on-line Internet-Drafts
> > >>> direct= ories.
> > >>>  > This draft is a work item of th= e Mobility EXTensions for IPv6 Working
> > >>> Group of t= he IETF.
> > >>>  >
> > >>>&nbs= p; >
> > >>>  >    Title   = ;       : Multiple Care-of Addresses Registration
> >= ; >>>  >    Author(s)      : R. W= akikawa, et al.
> > >>>  >    Filename&= nbsp;       : draft-ietf-monami6-multiplecoa-13..txt
>= > >>>  >    Pages       =   : 44
> > >>>  >    Date  &= nbsp;         : 2009-04-20
> > >>>&nb= sp; >
> > >>>  > According to the current Mobi= le IPv6 specification, a mobile node may
> > >>>  &g= t; have several care-of addresses, but only one, called the primary
>= > >>>  > care-of address, that can be registered with = its home agent and the
> > >>>  > correspondent n= odes.  However, for matters of cost, bandwidth, delay,
> > >>>  > etc, it is useful for the mobile node to get = Internet access through
> > >>>  > multiple acces= ses simultaneously, in which case the mobile node would
> > >&g= t;>  > be configured with multiple active IPv6 care-of addresses= ..  This
> > >>>  > document proposes extensi= ons to the Mobile IPv6 protocol to register
> > >>> = > and use multiple care-of addresses.  The extensions proposed in = this
> > >>>  > document can be used by Mobile Ro= uters using the NEMO (Network
> > >>>  > Mobility= ) Basic Support protocol as well.
> > >>>  >
&= gt; > >>>  > A URL for this Internet-Draft is:
> = > >>>  >
> > >>> http://www.ietf.org/= internet-drafts/draft-ietf-monami6-multiplecoa-13.txt
> > >>>  >
> > >>>  > Internet-Draf= ts are also available by anonymous FTP at:
> > >>>  = > ftp://= ftp.ietf.org/internet-drafts/
> > >>>  >
&= gt; > >>>  > Below is the data which will enable a MIME= compliant mail reader
> > >>>  > implementation = to automatically retrieve the ASCII version of the
> > >>>= ;  > Internet-Draft.
> > >>>  >
> &= gt; >>>  >
> > >>>  >
> &g= t; >>>  > _______________________________________________<= BR>> > >>>  > MEXT mailing list
> > >>= ;>  > MEXT@ietf.org <mailto:MEXT@ietf.org>
> > >&g= t;>  > https://www.ietf.org/mailman/listinfo/mext
> > &= gt;>>
> > >>>
> > >>>
> >= ; >>> ------------------------------------------------------------= ------------
> > >>>
> > >>> __________= _____________________________________
> > >>> MEXT mailin= g list
> > >>> MEXT@ietf.org
> > >>> https://w= ww.ietf.org/mailman/listinfo/mext
> > >>
> > &g= t;> _______________________________________________
> > >>= ; MEXT mailing list
> > >> MEXT@ietf.org
> > >> <= A href=3D"https://www.ietf.org/mailman/listinfo/mext" target=3D_blank>https= ://www.ietf.org/mailman/listinfo/mext
> > >>
> >= ; >
> > >
> >
> > ________________________= _______________________
> > MEXT mailing list
> > MEXT@ietf.org
> > https://www.ietf.org/mailman/listinfo/mext
>
> =
>


=0A=0A --0-1433417315-1240440859=:84777-- From behcetsarikaya@yahoo.com Wed Apr 22 16:06:39 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DAFB3A6F19 for ; Wed, 22 Apr 2009 16:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 sz3E4dpcYW4i for ; Wed, 22 Apr 2009 16:06:37 -0700 (PDT) Received: from n63.bullet.mail.sp1.yahoo.com (n63.bullet.mail.sp1.yahoo.com [98.136.44.33]) by core3.amsl.com (Postfix) with SMTP id 47E753A6EDA for ; Wed, 22 Apr 2009 16:06:33 -0700 (PDT) Received: from [216.252.122.218] by n63.bullet.mail.sp1.yahoo.com with NNFMP; 22 Apr 2009 23:07:51 -0000 Received: from [67.195.9.82] by t3.bullet.sp1.yahoo.com with NNFMP; 22 Apr 2009 23:07:51 -0000 Received: from [67.195.9.97] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 23:07:50 -0000 Received: from [127.0.0.1] by omp101.mail.gq1.yahoo.com with NNFMP; 22 Apr 2009 23:07:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 463632.19059.bm@omp101.mail.gq1.yahoo.com Received: (qmail 69626 invoked by uid 60001); 22 Apr 2009 23:07:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240441670; bh=Q/CcIlpDmqr9AkQ88Na/bn4za6eGjlXTEtAcgkrtEkU=; 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=LHw42nqKcSuccUYyqC7U7+uGZxmASvOPisG8e2/4ntH/MC3ZmMZnZK4Fe4v8/EwZ/3csuhCIxsv0Laipdcip0wHANUQgARtUbVkR7zI+txNA766hU0qcPxmHTnIl2rnTGaq0Svan6M5Xpg/zYbWwY2pAaFzFoo6bbjrP/pDPcQU= 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=kNw6X4IN8LHoJQSOtYD0l4Q9fzR4VBm0bOsTS/tKIjaD992hN7+F83VWjxFQyf545xyf28BQEy6bc51gRyPAyy0lyjIMnYHKcNPdVRDT1jkdQendkgqj5B+DoQ3Uc1+26B54mT3/9oL2cX3Q9rsJsphrKj59AdtKpnpT9FmVbqw=; Message-ID: <473113.45048.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: HY16fE4VM1lJqL5ipZDBYGXDCXuaU4iVRXW3r7Ju_vySuqvzzrdphTsR9uOHh46ooQBKHqiDtIFpc75Y2Vb2BHzbLfe1CJ472mfcQKD0hdKBAEhNO0oK6Ut1E6lGSQ0cauB6EUoQ80AsHO089p3FWwqmFK8gd7q4eWVNGT4l8q70TG5.Fax2z_e0hWlZpN6UzCD9G1gBOVCSmcSRk5AqMAC2GNn3sxv5cijHaaoIE3yTIC.6PlTf4hh5wlQuHog0fpLcq8QSYTe4DnybrPQZKgb323jZ_YFSnmDl1uWYTTHI1sYw9eBq_S2e_gCcQk2AF5Tk Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Wed, 22 Apr 2009 16:07:50 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> <375902.20727.qm@web111403.mail.gq1.yahoo.com> <8CF30647-6A19-4391-BE7E-CFE87EFD8EAD@gmail.com> <222821.303.qm@web111407.mail.gq1.yahoo.com> <49EF9356.8000504@it.uc3m.es> Date: Wed, 22 Apr 2009 16:07:50 -0700 (PDT) From: Behcet Sarikaya To: marcelo bagnulo braun In-Reply-To: <49EF9356.8000504@it.uc3m.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1541438532-1240441670=:45048" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 23:06:39 -0000 --0-1541438532-1240441670=:45048 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marcelo,=0A=A0 How about this little paragraph?=0A=0AIn this document it= is assumed that a multi-homed MN connects to the home link using only one = interface. Therefore this interface is=A0considered as the main interface a= s identified by the home address assigned by the home agent.=A0 The other o= r auxiliary interfaces may later on=A0become active and connect to some oth= er=A0networks and get their care-of addresses and=A0then=A0the procedures d= efined in this document allow such care-of addresses to be registered with = the home agent=A0apart from the registration of the care-of addresses assig= ned to the main interface which is already defined in RFC 3775.=0A=0ARegard= s,=0A=0ABehcet=0A=0A=0A________________________________=0AFrom: marcelo bag= nulo braun =0ATo: Behcet Sarikaya = =0ACc: Ryuji Wakikawa ; mext =0ASe= nt: Wednesday, April 22, 2009 4:59:50 PM=0ASubject: Re: [MEXT] [Fwd: I-D Ac= tion:draft-ietf-monami6-multiplecoa-13.txt]=0A=0AHi Bechet,=0A=0Acould you = send exactly what text do you think needs to be changed in the MCOA draft, = so the WG can evaluate and figure out if the changes are needed? (i.e. plea= se send OLD text NEW text)=0A=0APlease note that at this point in the life = of the document, we only take changes that fix errors in the document, rath= er than=A0 getting more features in.=0A=0ARegards, marcelo=0A=0A=0A=0ABehce= t Sarikaya escribi=F3:=0A> Hi Ryuji,=0A>=A0 I checked your draft. Again, I = could not understand how you are sending a registration BU at the home link= as only an O-flag is defined in your draft which is used for something els= e.=0A>=A0 As I mentioned to you, we discussed this related to draft-premec-= homelink and it seems like HA will reject such a BU unless something is don= e, I thought you were familiar with the discussions as it relates to your d= raft too. I am surprised.=0A>=A0 Regards,=0A>=A0 Behcet=0A> =0A> ----------= --------------------------------------------------------------=0A> *From:* = Ryuji Wakikawa =0A> *To:* Behcet Sarikaya =0A> *Cc:* George Tsirtsis ; mext =0A> *Sent:* Wednesday, April 22, 2009 4:18:28 PM=0A> *Subject:*= Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> =0A= > Hi Behcet,=0A> =0A> On 2009/04/22, at 11:31, Behcet Sarikaya wrote:=0A> = =0A> >=0A> >=0A> > From: George Tsirtsis >=0A> > To: Behcet Sarikaya >=0A> > Cc: mext = >=0A> > Sent: Wednesday, April 22, 2009 10:10:08 AM=0A> > Subject: Re: [MEX= T] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> >=0A> > I do= not think that adding home link registration to RFC3775bis is feasible.=0A= > > This requires logic in the MN and HA that is not directly compatible=0A= > > to RFC3775. The aim of RFC3775bis is to make minimal changes for=0A> > = clarification reasons and to correct errors. Home Link Registration as=0A> = > defined in MCoA is neither.=0A> > [behcet] Why not? If it is needed in so= many instances, that qualifies it to become a base protocol feature, at le= ast to me.=0A> =0A> We cannot add a new feature to 3775. That is the ground= rule of -bis. The chairs can clarify this.=0A> =0A> regards,=0A> ryuji=0A>= =0A> =0A> =0A> >=0A> > On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya=0A= > > > wrote:=0A>= > > Hi George,=0A> > >=A0 It seems in my previous reply I replied to this = mail of yours which was=0A> > > unrelated to the other mail you sent to whi= ch I was really replying,=0A> > > apologies.=0A> > >=A0 Now regarding home = link registration, what is the mechanism MCoA draft=0A> > > uses? Ryuji men= tioned some H bit but I read the draft and couldn't confirm=0A> > > it.=0A>= > >=0A> > >=A0 My suggestion was building on this, i.e. I suggested that w= hatever you=0A> > > came up with can be moved to 3775bis so that other peop= le would not have to=0A> > > make normative references to your draft.=0A> >= >=0A> > > That's all.=0A> > >=0A> > > Regards,=0A> > >=0A> > > Behcet=0A> = > >=0A> > > ________________________________=0A> > > From: George Tsirtsis = >=0A> > > To: Vija= y Devarapalli >=0A> > > Cc: = Behcet Sarikaya >; mext >=0A> > > Sent: Tuesday, April 21, 2009 2:14= :55 PM=0A> > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-mult= iplecoa-13.txt]=0A> > >=0A> > > ...also wrt the home link registration, I d= o not think what you=0A> > > suggest is necessary.=0A> > >=0A> > > As far a= s I see the other documents are informational, and they do not=0A> > > yet = have a formal standing in the WG. If and when they do, as=0A> > > Informati= onal documents,=A0 they should not require normative changes to=0A> > > any= thing. They should make sure what they describe (mostly=0A> > > implementat= ion options in this case) are compatible not only with=0A> > > RFC3775 but = also with extensions to it, including Flow Bindings. .=0A> > >=0A> > >=0A> = > > Regards=0A> > > George=0A> > >=0A> > > On Tue, Apr 21, 2009 at 7:58 PM,= Vijay Devarapalli >=0A> > >= wrote:=0A> > >> Behcet,=0A> > >>=0A> > >> Behcet Sarikaya wrote:=0A> > >>>= =0A> > >>> *[behcet] Yes but each interface will appear to HA as a differen= t device=0A> > >>> and HA needs to assign a different HoA. Then MCoA proble= m disappears.*=0A> > >>> *So George is saying that this is avoided by some = virtual interfaces so=0A> > >>> that HA does not see each interface separat= ely. *=0A> > >>> *Is this explained anywhere in the draft?*=0A> > >>> *If y= es then I am OK.*=0A> > >>=0A> > >> The home agent does not care about the = multiple interfaces on the mobile=0A> > >> node. It only sees the mobile no= de as one entity and allocates a home=0A> > >> address to it. The multiple = care-of addresses that the mobile node has=0A> > >> will=0A> > >> be used b= y the home agent as tunnel end points. That is all. So there is=0A> > >> no= =0A> > >> issue.=0A> > >>=0A> > >> Vijay=0A> > >>=0A> > >>>=A0 >=A0 Also I = have a question to Ryuji: does this draft send a=0A> > >>> non-deregistrati= on BU at the home link? If yes, is he familiar with the=0A> > >>> discussio= n going on on this subject? This is another point of confusion=0A> > >>> fo= r=0A> > >>> me.=0A> > >>>=0A> > >>> This has been discussed for a long time= in MEXT.=0A> > >>> who is familiar with which discussions? I don't know yo= ur concern here.=0A> > >>>=A0 *[behcet] So your answer is yes the draft sen= ds a non-deregistration BU=0A> > >>> (kind of bulk registration) at the hom= e link.*=0A> > >>> *The discussion I mentioned was related to=0A> > >>> dra= ft-premec-mext-extended-home-link. This draft also sends=0A> > >>> non-dere= gistration BU at the home link. So does a few more drafts like=0A> > >>> **= draft-devarapalli-mext-mipv6-home-link.*=0A> > >>>=0A> > >>> **=0A> > >>> *= [behcet] You mentioned some bit is set but I could not understand which.=0A= > > >>> One idea is since so many drafts need this, why not factor this out= and=0A> > >>> define whatever the mechanism to enable sending non-deregist= ration BU in=0A> > >>> 3775bis. What do you think about that?*=0A> > >>>=0A= > > >>> **=0A> > >>>=0A> > >>>=A0 >=A0 Sorry if I am too=A0 much confused= =0A> > >>>=A0 > Please don't get me wrong, I am not trying to slow down the= progress=0A> > >>> of=0A> > >>> this document..=0A> > >>>=0A> > >>> sure, = but please explain your issue more precisely.=0A> > >>>=0A> > >>> thanks!= =0A> > >>> ryuji=0A> > >>>=0A> > >>>=A0 >=0A> > >>>=A0 > Regards,=0A> > >>>= =A0 >=0A> > >>>=A0 > Behcet=0A> > >>>=A0 > From: marcelo bagnulo braun =0A> > >>> >>=0A> > >>>=A0 > To: mext >>; Juli= en Laganier=0A> > >>> =0A> > >>> >>; Jari Arkko=0A> > = >>> >>=0A> > >>>=A0 > Sent: Tuesday, Apr= il 21, 2009 11:03:05 AM=0A> > >>>=A0 > Subject: [MEXT] [Fwd: I-D=0A> > >>> = Action:draft-ietf-monami6-multiplecoa-13.txt]=0A> > >>>=A0 >=0A> > >>>=A0 >= We have this new version of the MCOA document that addresses the=0A> > >>>= comments received, including IESG review comments.=0A> > >>>=A0 > To the b= est of my knowledge, the IESG is ok with the doc and ready for=0A> > >>> pu= blication..=0A> > >>>=A0 > I am planning to ask our AD to move forward in a= week or so, so, if=0A> > >>> you=0A> > >>> have comments on the document p= lease provide them before the 1st of may.=0A> > >>>=A0 >=0A> > >>>=A0 > Reg= ards, marcelo=0A> > >>>=A0 > (mcoa doc shepherd)=0A> > >>>=A0 >=0A> > >>>= =A0 > -------- Mensaje original --------=0A> > >>>=A0 > Asunto:=A0 =A0 [MEX= T] I-D Action:draft-ietf-monami6-multiplecoa-13.txt=0A> > >>>=A0 > Fecha:= =A0 =A0 Mon, 20 Apr 2009 08:30:01 -0700 (PDT)=0A> > >>>=A0 > De:=A0 =A0 Int= ernet-Drafts@ietf.org >=0A> > >>>=A0 > Para:=A0 = =A0 i-d-announce@ietf.org >=0A> > >>>=A0 > CC:=A0 =A0 mext@= ietf.org >=0A> > >>>=A0 >=0A> > >>>=A0 >=0A> > >>>=A0 >=0A> > >>>=A0 > A New Intern= et-Draft is available from the on-line Internet-Drafts=0A> > >>> directorie= s.=0A> > >>>=A0 > This draft is a work item of the Mobility EXTensions for = IPv6 Working=0A> > >>> Group of the IETF.=0A> > >>>=A0 >=0A> > >>>=A0 >=0A>= > >>>=A0 >=A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : Multiple Care-of Addresses Re= gistration=0A> > >>>=A0 >=A0 =A0 Author(s)=A0 =A0 =A0 : R. Wakikawa, et al.= =0A> > >>>=A0 >=A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-monami6-multipl= ecoa-13..txt=0A> > >>>=A0 >=A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 : 44=0A> > >>>= =A0 >=A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2009-04-20=0A> > >>>=A0 >=0A> > = >>>=A0 > According to the current Mobile IPv6 specification, a mobile node = may=0A> > >>>=A0 > have several care-of addresses, but only one, called the= primary=0A> > >>>=A0 > care-of address, that can be registered with its ho= me agent and the=0A> > >>>=A0 > correspondent nodes.=A0 However, for matter= s of cost, bandwidth, delay,=0A> > >>>=A0 > etc, it is useful for the mobil= e node to get Internet access through=0A> > >>>=A0 > multiple accesses simu= ltaneously, in which case the mobile node would=0A> > >>>=A0 > be configure= d with multiple active IPv6 care-of addresses.=A0 This=0A> > >>>=A0 > docum= ent proposes extensions to the Mobile IPv6 protocol to register=0A> > >>>= =A0 > and use multiple care-of addresses.=A0 The extensions proposed in thi= s=0A> > >>>=A0 > document can be used by Mobile Routers using the NEMO (Net= work=0A> > >>>=A0 > Mobility) Basic Support protocol as well.=0A> > >>>=A0 = >=0A> > >>>=A0 > A URL for this Internet-Draft is:=0A> > >>>=A0 >=0A> > >>>= http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt= =0A> > >>>=A0 >=0A> > >>>=A0 > Internet-Drafts are also available by anonym= ous FTP at:=0A> > >>>=A0 > ftp://ftp.ietf.org/internet-drafts/=0A> > >>>=A0= >=0A> > >>>=A0 > Below is the data which will enable a MIME compliant mail= reader=0A> > >>>=A0 > implementation to automatically retrieve the ASCII v= ersion of the=0A> > >>>=A0 > Internet-Draft.=0A> > >>>=A0 >=0A> > >>>=A0 >= =0A> > >>>=A0 >=0A> > >>>=A0 > ____________________________________________= ___=0A> > >>>=A0 > MEXT mailing list=0A> > >>>=A0 > MEXT@ietf.org >=0A> > >>>=A0 > = https://www.ietf.org/mailman/listinfo/mext=0A> > >>>=0A> > >>>=0A> > >>>=0A= > > >>> -------------------------------------------------------------------= -----=0A> > >>>=0A> > >>> _______________________________________________= =0A> > >>> MEXT mailing list=0A> > >>> MEXT@ietf.org = =0A> > >>> https://www.ietf.org/mailman/listinfo/mext=0A> > >>=0A> > >> ___= ____________________________________________=0A> > >> MEXT mailing list=0A>= > >> MEXT@ietf.org =0A> > >> https://www.ietf.org/ma= ilman/listinfo/mext=0A> > >>=0A> > >=0A> > >=0A> >=0A> > __________________= _____________________________=0A> > MEXT mailing list=0A> > MEXT@ietf.org <= mailto:MEXT@ietf.org>=0A> > https://www.ietf.org/mailman/listinfo/mext=0A> = =0A> =0A> -----------------------------------------------------------------= -------=0A> =0A> _______________________________________________=0A> MEXT m= ailing list=0A> MEXT@ietf.org=0A> https://www.ietf.org/mailman/listinfo/mex= t=0A>=A0 =0A=0A=0A --0-1541438532-1240441670=:45048 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Marcelo,
=0A
  How about this little = paragraph?
=0A
 
=0A
In this document it is assumed = that a multi-homed MN connects to the home link using only one interface. T= herefore this interface is considered as the main interface as identif= ied by the home address assigned by the home agent.  The other or auxi= liary interfaces may later on become active and connect to some other&= nbsp;networks and get their care-of addresses and then the proced= ures defined in this document allow such care-of addresses to be registered= with the home agent apart from the registration of the care-of addres= ses assigned to the main interface which is already defined in RFC 3775.
=0A
Regards,
=0A
 
=0A
Beh= cet
=0A
=0A
=0AFrom: marcelo bagnulo braun <marcelo= @it.uc3m.es>
To: Behc= et Sarikaya <sarikaya@ieee.org>
Cc: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>; mext <= ;mext@ietf.org>
Sent:= Wednesday, April 22, 2009 4:59:50 PM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multi= plecoa-13.txt]

Hi Bechet,

could you send exactly what = text do you think needs to be changed in the MCOA draft, so the WG can eval= uate and figure out if the changes are needed? (i.e. please send OLD text N= EW text)

Please note that at this point in the life of the document,= we only take changes that fix errors in the document, rather than  ge= tting more features in.

Regards, marcelo



Behcet Sarikaya escribi=F3:
> Hi Ryuji,
&g= t;  I checked your draft. Again, I could not understand how you are se= nding a registration BU at the home link as only an O-flag is defined in yo= ur draft which is used for something else.
>  As I mentioned to = you, we discussed this related to draft-premec-homelink and it seems like H= A will reject such a BU unless something is done, I thought you were famili= ar with the discussions as it relates to your draft too. I am surprised.>  Regards,
>  Behcet
>
> ----------------= --------------------------------------------------------
> *From:* Ry= uji Wakikawa <ryuji.wakikawa@gmail.com>
> *To:= * Behcet Sarikaya <sarikaya@ieee.org>
> *Cc:* George Tsirtsi= s <tsirtsis@googlemail.com>; mext <mext@ietf.org>
&= gt; *Sent:* Wednesday, April 22, 2009 4:18:28 PM
> *Subject:* Re: [ME= XT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
>
>= ; Hi Behcet,
>
> On 2009/04/22, at 11:31, Behcet Sarikaya wrot= e:
>
> >
> >
> > From: George Tsirtsis &l= t;tsirtsis@googlemail.com <mailto:tsirtsis@goo= glemail.com>>
> > To: Behcet Sarikaya <sarikaya@ieee.o= rg <mailto:sarikaya@ieee.org>>
>= > Cc: mext <mext@ietf.org <mailto:mext@ietf.org>>
> > Sent: = Wednesday, April 22, 2009 10:10:08 AM
> > Subject: Re: [MEXT] [Fwd= : I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
> >
> &g= t; I do not think that adding home link registration to RFC3775bis is feasi= ble.
> > This requires logic in the MN and HA that is not directly= compatible
> > to RFC3775. The aim of RFC3775bis is to make minim= al changes for
> > clarification reasons and to correct errors. Ho= me Link Registration as
> > defined in MCoA is neither.
> &g= t; [behcet] Why not? If it is needed in so many instances, that qualifies i= t to become a base protocol feature, at least to me.
>
> We cannot add a new feature to 3775. That is the ground rule of -bis. The cha= irs can clarify this.
>
> regards,
> ryuji
>
&= gt;
>
> >
> > On Wed, Apr 22, 2009 at 4:06 PM, Be= hcet Sarikaya
> > <behcetsarikaya@yahoo.com &l= t;mailto:behcetsarikaya@yahoo.com>> wrote:
> &= gt; > Hi George,
> > >  It seems in my previous reply I= replied to this mail of yours which was
> > > unrelated to the= other mail you sent to which I was really replying,
> > > apol= ogies.
> > >  Now regarding home link registration, what i= s the mechanism MCoA draft
> > > uses? Ryuji mentioned some H b= it but I read the draft and couldn't confirm
> > > it.
> > >
> > >  My suggestion was building on this, i.e.= I suggested that whatever you
> > > came up with can be moved = to 3775bis so that other people would not have to
> > > make no= rmative references to your draft.
> > >
> > > That'= s all.
> > >
> > > Regards,
> > >
&g= t; > > Behcet
> > >
> > > ___________________= _____________
> > > From: George Tsirtsis <tsirts= is@googlemail.com <mailto:tsirtsis@googlemail.com>= >
> > > To: Vijay Devarapalli <vijay@wichorus.com &l= t;mailto:vijay@wichorus.com>>
&g= t; > > Cc: Behcet Sarikaya <sarikaya@ieee.org <mailto:sarikay= a@ieee.org>>; mext <mext@ietf.org <mailto:mext@ietf.org>>
= > > > Sent: Tuesday, April 21, 2009 2:14:55 PM
> > > S= ubject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]<= BR>> > >
> > > ...also wrt the home link registration,= I do not think what you
> > > suggest is necessary.
> &g= t; >
> > > As far as I see the other documents are informati= onal, and they do not
> > > yet have a formal standing in the W= G. If and when they do, as
> > > Informational documents,  they sho= uld not require normative changes to
> > > anything. They shoul= d make sure what they describe (mostly
> > > implementation opt= ions in this case) are compatible not only with
> > > RFC3775 b= ut also with extensions to it, including Flow Bindings. .
> > >=
> > >
> > > Regards
> > > George
&g= t; > >
> > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devar= apalli <vijay@wichorus.com <mailto:vijay@wichorus.com>&g= t;
> > > wrote:
> > >> Behcet,
> > >= >
> > >> Behcet Sarikaya wrote:
> > >>>=
> > >>> *[behcet] Yes but each interface will appear to HA as a different device
> > >>> and HA needs to assign = a different HoA. Then MCoA problem disappears.*
> > >>> *= So George is saying that this is avoided by some virtual interfaces so
&= gt; > >>> that HA does not see each interface separately. *
= > > >>> *Is this explained anywhere in the draft?*
> &= gt; >>> *If yes then I am OK.*
> > >>
> > = >> The home agent does not care about the multiple interfaces on the = mobile
> > >> node. It only sees the mobile node as one enti= ty and allocates a home
> > >> address to it. The multiple c= are-of addresses that the mobile node has
> > >> will
>= ; > >> be used by the home agent as tunnel end points. That is all= .. So there is
> > >> no
> > >> issue.
>= > >>
> > >> Vijay
> > >>
> > >>>  >  Also I have a question= to Ryuji: does this draft send a
> > >>> non-deregistrat= ion BU at the home link? If yes, is he familiar with the
> > >&= gt;> discussion going on on this subject? This is another point of confu= sion
> > >>> for
> > >>> me.
> &g= t; >>>
> > >>> This has been discussed for a lon= g time in MEXT.
> > >>> who is familiar with which discus= sions? I don't know your concern here.
> > >>>  *[be= hcet] So your answer is yes the draft sends a non-deregistration BU
>= > >>> (kind of bulk registration) at the home link.*
> &= gt; >>> *The discussion I mentioned was related to
> > &g= t;>> draft-premec-mext-extended-home-link. This draft also sends
&= gt; > >>> non-deregistration BU at the home link. So does a few more drafts like
> > >>> **draft-devarapalli-= mext-mipv6-home-link.*
> > >>>
> > >>> = **
> > >>> *[behcet] You mentioned some bit is set but I = could not understand which.
> > >>> One idea is since so = many drafts need this, why not factor this out and
> > >>>= ; define whatever the mechanism to enable sending non-deregistration BU in<= BR>> > >>> 3775bis. What do you think about that?*
> &= gt; >>>
> > >>> **
> > >>>
= > > >>>  >  Sorry if I am too  much confus= ed
> > >>>  > Please don't get me wrong, I am not= trying to slow down the progress
> > >>> of
> >= >>> this document..
> > >>>
> > >&g= t;> sure, but please explain your issue more precisely.
> > >>>
> > >>> thanks!
> > >>&= gt; ryuji
> > >>>
> > >>>  >> > >>>  > Regards,
> > >>> = >
> > >>>  > Behcet
> > >>>=   > From: marcelo bagnulo braun <marcelo@it.uc3m.es <mai= lto:marcelo@it.uc3m.es>
> > >>> <mailto:marce= lo@it.uc3m.es <mailto:marcelo@it.uc3m.es>>>
> &= gt; >>>  > To: mext <mext@ietf.org <mailto:mext@ietf.o= rg> <mailto:mext@ietf.org <mailto:mext@ietf.org>>>; Julien Laga= nier
> > >>> <julie= n.laganier.ietf@googlemail.com <mailto:julien.laganier.ietf@googlemail.com>
> > >>>= <mailto:julien.laganier..ietf@goog= lemail.com <mailto:julien.laganier..i= etf@googlemail.com>>>; Jari Arkko
> > >>> &l= t;jari.arkko@piuha.net <mailto:jari.arkko@piuha.net>= ; <mailto:jari.arkko@piuha.net <mailto:jari.arkko@piuha= ..net>>>
> > >>>  > Sent: Tuesday, Ap= ril 21, 2009 11:03:05 AM
> > >>>  > Subject: [MEX= T] [Fwd: I-D
> > >>> Action:draft-ietf-monami6-multipleco= a-13.txt]
> > >>>  >
> > >>>&nb= sp; > We have this new version of the MCOA document that addresses the> > >>> comments received, including IESG review comments.
> &g= t; >>>  > To the best of my knowledge, the IESG is ok with= the doc and ready for
> > >>> publication..
> >= >>>  > I am planning to ask our AD to move forward in a w= eek or so, so, if
> > >>> you
> > >>> h= ave comments on the document please provide them before the 1st of may.
= > > >>>  >
> > >>>  > Rega= rds, marcelo
> > >>>  > (mcoa doc shepherd)
&g= t; > >>>  >
> > >>>  > ------= -- Mensaje original --------
> > >>>  > Asunto:&n= bsp;   [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt
>= > >>>  > Fecha:    Mon, 20 Apr 2009 08:30:01= -0700 (PDT)
> > >>>  > De:    Internet-Drafts@ietf.org <mailto:Internet= -Drafts@ietf.org> <mailto:Internet-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org>>
> >= ; >>>  > Para:    i-d-announce@ietf.org <mailto:i-d-announce@ietf.org> <mailto:i-d-an= nounce@ietf.org <mailto:i-d-announce@ietf.org>>=
> > >>>  > CC:    mext@ietf.org <mailto:= mext@ietf= ..org> <mailto:mext@ietf.org <mailto:mext@ietf.org>>
> > &= gt;>>  >
> > >>>  >
> > &g= t;>>  >
> > >>>  > A New Internet-D= raft is available from the on-line Internet-Drafts
> > >>>= ; directories.
> > >>>  > This draft is a work it= em of the Mobility EXTensions for IPv6 Working
> > >>> Gr= oup of the IETF.
> > >>>  >
> > >>= >  >
> > >>>  >    Title    =       : Multiple Care-of Addresses Registration
> >= >>>  >    Author(s)      : R. Wa= kikawa, et al.
> > >>>  >    Filename&n= bsp;       : draft-ietf-monami6-multiplecoa-13..txt
> = > >>>  >    Pages        =   : 44
> > >>>  >    Date  &n= bsp;         : 2009-04-20
> > >>>&nbs= p; >
> > >>>  > According to the current Mobil= e IPv6 specification, a mobile node may
> > >>>  >= ; have several care-of addresses, but only one, called the primary
> = > >>>  > care-of address, that can be registered with i= ts home agent and the
> > >>>  > correspondent nodes.  However, for matters of cost, bandwidth, delay,=
> > >>>  > etc, it is useful for the mobile node= to get Internet access through
> > >>>  > multip= le accesses simultaneously, in which case the mobile node would
> >= ; >>>  > be configured with multiple active IPv6 care-of a= ddresses.  This
> > >>>  > document proposes= extensions to the Mobile IPv6 protocol to register
> > >>&g= t;  > and use multiple care-of addresses.  The extensions prop= osed in this
> > >>>  > document can be used by M= obile Routers using the NEMO (Network
> > >>>  > = Mobility) Basic Support protocol as well.
> > >>>  &= gt;
> > >>>  > A URL for this Internet-Draft is:<= BR>> > >>>  >
> > >>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt<= BR>> > >>>  >
> > >>>  > I= nternet-Drafts are also available by anonymous FTP at:
> > >>= ;>  > ftp://ftp.ietf.org/internet-drafts/
> > >>>&nbs= p; >
> > >>>  > Below is the data which will e= nable a MIME compliant mail reader
> > >>>  > imp= lementation to automatically retrieve the ASCII version of the
> >= >>>  > Internet-Draft.
> > >>>  &g= t;
> > >>>  >
> > >>>  >= ;
> > >>>  > ____________________________________= ___________
> > >>>  > MEXT mailing list
> = > >>>  > MEXT@ietf.org <mailto:MEXT@ietf.org>= <mailto:MEXT@ietf.org <mailto:MEXT@ietf.org>>
> > >>>&= nbsp; > https://www.ietf.org/mailman/listinfo/mext
> > >>= >
> > >>>
> > >>>
> > >&= gt;> -------------------------------------------------------------------= -----
> > >>>
> > >>> _________________= ______________________________
> > >>> MEXT mailing list<= BR>> > >>> MEXT@ietf.org <mailto:MEXT@ietf.org>
> > >&g= t;> https://www.ietf.org/mailman/listinfo/mext
> > >>
= > > >> _______________________________________________
> = > >> MEXT mailing list
> > >> MEXT@ietf.org <mailto:<= A href=3D"mailto:MEXT@ietf.org" ymailto=3D"mailto:MEXT@ietf.org">MEXT@ietf.= org>
> > >> https://www.ietf.org/mailman/listinfo/mext
> > >>
> > >
> > >
> >> > _______________________________________________
> > MEX= T mailing list
> > MEXT@ietf.org <mailto:MEXT@ietf.org>
> > https://ww= w.ietf.org/mailman/listinfo/mext
>
>
> ------------= ------------------------------------------------------------
>
&g= t; _______________________________________________
> MEXT mailing lis= t
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
&g= t; 


=0A=0A --0-1541438532-1240441670=:45048-- From vijay@wichorus.com Wed Apr 22 16:41:59 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A623A69BD for ; Wed, 22 Apr 2009 16:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=-1.034, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] 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 RQQD4j2Sz7Si for ; Wed, 22 Apr 2009 16:41:57 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 94EEC3A6946 for ; Wed, 22 Apr 2009 16:41:57 -0700 (PDT) Received: from 38.104.122.206 ([38.104.122.206]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Apr 2009 23:43:13 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 22 Apr 2009 16:43:13 -0700 From: Vijay Devarapalli To: Behcet Sarikaya , marcelo bagnulo braun Message-ID: Thread-Topic: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] Thread-Index: AcnDpBmzDEGuuQltCECBk7YQM6RNjg== In-Reply-To: <473113.45048.qm@web111406.mail.gq1.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 23:41:59 -0000 Hi Bechet, On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote: > Hi Marcelo, > How about this little paragraph? > =20 > In this document it is assumed that a multi-homed MN connects to the home= link > using only one interface. Therefore this interface is considered as the m= ain > interface as identified by the home address assigned by the home agent. I disagree with this. The mobile node can connect to the home link through any one of its interfaces. > The=20 > other or auxiliary interfaces may later on become active and connect to s= ome > other networks and get their care-of addresses and then the procedures de= fined > in this document allow such care-of addresses to be registered with the h= ome > agent apart from the registration of the care-of addresses assigned to th= e > main interface which is already defined in RFC 3775. There is no need for the home agent to identify one of the interfaces as a "main" interface. Vijay > Regards, > =20 > Behcet >=20 > From: marcelo bagnulo braun > To: Behcet Sarikaya > Cc: Ryuji Wakikawa ; mext > Sent: Wednesday, April 22, 2009 4:59:50 PM > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.tx= t] >=20 > Hi Bechet, >=20 > could you send exactly what text do you think needs to be changed in the = MCOA > draft, so the WG can evaluate and figure out if the changes are needed? (= i.e. > please send OLD text NEW text) >=20 > Please note that at this point in the life of the document, we only take > changes that fix errors in the document, rather than getting more featur= es > in. >=20 > Regards, marcelo >=20 >=20 >=20 > Behcet Sarikaya escribi=F3: >> Hi Ryuji, >> I checked your draft. Again, I could not understand how you are sending= a >> registration BU at the home link as only an O-flag is defined in your dr= aft >> which is used for something else. >> As I mentioned to you, we discussed this related to draft-premec-homeli= nk >> and it seems like HA will reject such a BU unless something is done, I >> thought you were familiar with the discussions as it relates to your dra= ft >> too. I am surprised. >> Regards, >> Behcet >>=20 >> ------------------------------------------------------------------------ >> *From:* Ryuji Wakikawa >> *To:* Behcet Sarikaya >> *Cc:* George Tsirtsis ; mext >> *Sent:* Wednesday, April 22, 2009 4:18:28 PM >> *Subject:* Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13= .txt] >>=20 >> Hi Behcet, >>=20 >> On 2009/04/22, at 11:31, Behcet Sarikaya wrote: >>=20 >>>=20 >>>=20 >>> From: George Tsirtsis >> > >>> To: Behcet Sarikaya > >>> Cc: mext > >>> Sent: Wednesday, April 22, 2009 10:10:08 AM >>> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.= txt] >>>=20 >>> I do not think that adding home link registration to RFC3775bis is feas= ible. >>> This requires logic in the MN and HA that is not directly compatible >>> to RFC3775. The aim of RFC3775bis is to make minimal changes for >>> clarification reasons and to correct errors. Home Link Registration as >>> defined in MCoA is neither. >>> [behcet] Why not? If it is needed in so many instances, that qualifies = it to >>> become a base protocol feature, at least to me. >>=20 >> We cannot add a new feature to 3775. That is the ground rule of -bis. Th= e >> chairs can clarify this. >>=20 >> regards, >> ryuji >>=20 >>=20 >>=20 >>>=20 >>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya >>> > wrote: >>>> Hi George, >>>> It seems in my previous reply I replied to this mail of yours which w= as >>>> unrelated to the other mail you sent to which I was really replying, >>>> apologies. >>>> Now regarding home link registration, what is the mechanism MCoA draf= t >>>> uses? Ryuji mentioned some H bit but I read the draft and couldn't con= firm >>>> it. >>>>=20 >>>> My suggestion was building on this, i.e. I suggested that whatever yo= u >>>> came up with can be moved to 3775bis so that other people would not ha= ve to >>>> make normative references to your draft. >>>>=20 >>>> That's all. >>>>=20 >>>> Regards, >>>>=20 >>>> Behcet >>>>=20 >>>> ________________________________ >>>> From: George Tsirtsis >>> > >>>> To: Vijay Devarapalli > >>>> Cc: Behcet Sarikaya >; me= xt >>>> > >>>> Sent: Tuesday, April 21, 2009 2:14:55 PM >>>> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13= .txt] >>>>=20 >>>> ...also wrt the home link registration, I do not think what you >>>> suggest is necessary. >>>>=20 >>>> As far as I see the other documents are informational, and they do not >>>> yet have a formal standing in the WG. If and when they do, as >>>> Informational documents, they should not require normative changes to >>>> anything. They should make sure what they describe (mostly >>>> implementation options in this case) are compatible not only with >>>> RFC3775 but also with extensions to it, including Flow Bindings. . >>>>=20 >>>>=20 >>>> Regards >>>> George >>>>=20 >>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli >>> > >>>> wrote: >>>>> Behcet, >>>>>=20 >>>>> Behcet Sarikaya wrote: >>>>>>=20 >>>>>> *[behcet] Yes but each interface will appear to HA as a different de= vice >>>>>> and HA needs to assign a different HoA. Then MCoA problem disappears= .* >>>>>> *So George is saying that this is avoided by some virtual interfaces= so >>>>>> that HA does not see each interface separately. * >>>>>> *Is this explained anywhere in the draft?* >>>>>> *If yes then I am OK.* >>>>>=20 >>>>> The home agent does not care about the multiple interfaces on the mob= ile >>>>> node. It only sees the mobile node as one entity and allocates a home >>>>> address to it. The multiple care-of addresses that the mobile node ha= s >>>>> will >>>>> be used by the home agent as tunnel end points. That is all.. So ther= e is >>>>> no >>>>> issue. >>>>>=20 >>>>> Vijay >>>>>=20 >>>>>>> Also I have a question to Ryuji: does this draft send a >>>>>> non-deregistration BU at the home link? If yes, is he familiar with = the >>>>>> discussion going on on this subject? This is another point of confus= ion >>>>>> for >>>>>> me. >>>>>>=20 >>>>>> This has been discussed for a long time in MEXT. >>>>>> who is familiar with which discussions? I don't know your concern he= re. >>>>>> *[behcet] So your answer is yes the draft sends a non-deregistratio= n BU >>>>>> (kind of bulk registration) at the home link.* >>>>>> *The discussion I mentioned was related to >>>>>> draft-premec-mext-extended-home-link. This draft also sends >>>>>> non-deregistration BU at the home link. So does a few more drafts li= ke >>>>>> **draft-devarapalli-mext-mipv6-home-link.* >>>>>>=20 >>>>>> ** >>>>>> *[behcet] You mentioned some bit is set but I could not understand w= hich. >>>>>> One idea is since so many drafts need this, why not factor this out = and >>>>>> define whatever the mechanism to enable sending non-deregistration B= U in >>>>>> 3775bis. What do you think about that?* >>>>>>=20 >>>>>> ** >>>>>>=20 >>>>>>> Sorry if I am too much confused >>>>>>> Please don't get me wrong, I am not trying to slow down the progres= s >>>>>> of >>>>>> this document.. >>>>>>=20 >>>>>> sure, but please explain your issue more precisely. >>>>>>=20 >>>>>> thanks! >>>>>> ryuji >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Behcet >>>>>>> From: marcelo bagnulo braun >>>>>> >>>>>> >> >>>>>>> To: mext >>>>>> >>; Julien Laganier >>>>>> >>>>> >>>>>> >>>>> >>; Jari Arkko >>>>>> >>>>>> >>>>> >>> >>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM >>>>>>> Subject: [MEXT] [Fwd: I-D >>>>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>>=20 >>>>>>> We have this new version of the MCOA document that addresses the >>>>>> comments received, including IESG review comments. >>>>>>> To the best of my knowledge, the IESG is ok with the doc and ready = for >>>>>> publication.. >>>>>>> I am planning to ask our AD to move forward in a week or so, so, if >>>>>> you >>>>>> have comments on the document please provide them before the 1st of = may. >>>>>>>=20 >>>>>>> Regards, marcelo >>>>>>> (mcoa doc shepherd) >>>>>>>=20 >>>>>>> -------- Mensaje original -------- >>>>>>> Asunto: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt >>>>>>> Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) >>>>>>> De: Internet-Drafts@ietf.org >>>>>>> > >>>>>>> Para: i-d-announce@ietf.org >>>>>>> > >>>>>>> CC: mext@ietf.org = > >>>>>>> > >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>>> This draft is a work item of the Mobility EXTensions for IPv6 Worki= ng >>>>>> Group of the IETF. >>>>>>>=20 >>>>>>>=20 >>>>>>> Title : Multiple Care-of Addresses Registration >>>>>>> Author(s) : R. Wakikawa, et al. >>>>>>> Filename : draft-ietf-monami6-multiplecoa-13..txt >>>>>>> Pages : 44 >>>>>>> Date : 2009-04-20 >>>>>>>=20 >>>>>>> According to the current Mobile IPv6 specification, a mobile node m= ay >>>>>>> have several care-of addresses, but only one, called the primary >>>>>>> care-of address, that can be registered with its home agent and the >>>>>>> correspondent nodes. However, for matters of cost, bandwidth, dela= y, >>>>>>> etc, it is useful for the mobile node to get Internet access throug= h >>>>>>> multiple accesses simultaneously, in which case the mobile node wou= ld >>>>>>> be configured with multiple active IPv6 care-of addresses. This >>>>>>> document proposes extensions to the Mobile IPv6 protocol to registe= r >>>>>>> and use multiple care-of addresses. The extensions proposed in thi= s >>>>>>> document can be used by Mobile Routers using the NEMO (Network >>>>>>> Mobility) Basic Support protocol as well. >>>>>>>=20 >>>>>>> A URL for this Internet-Draft is: >>>>>>>=20 >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-1= 3.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 >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>> > >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --------------------------------------------------------------------= ---- >>>>>>=20 >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >>=20 >> ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> =20 >=20 >=20 > =20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From Benjamin.Limck@sg.panasonic.com Wed Apr 22 21:14:51 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4D73A6A68 for ; Wed, 22 Apr 2009 21:14:51 -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.188, 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 0tit1n0bKEEx for ; Wed, 22 Apr 2009 21:14:50 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 453473A68D7 for ; Wed, 22 Apr 2009 21:14:50 -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 n3N4G6Za029915 for ; Thu, 23 Apr 2009 13:16:06 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlb3) with ESMTP id n3N4G7K11615 for ; Thu, 23 Apr 2009 13:16:07 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id n3N4G8Z22004 for ; Thu, 23 Apr 2009 13:16:08 +0900 (JST) Received: from [127.0.0.1] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 12:14:15 +0800 Message-ID: <49EFEB1F.7040602@sg.panasonic.com> Date: Thu, 23 Apr 2009 12:14:23 +0800 From: Benjamin Lim User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "mext@ietf.org" X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2009 04:14:15.0134 (UTC) FILETIME=[F6AFF7E0:01C9C3C9] Subject: [MEXT] Comments to draft-ietf-monami6-multiplecoa-13.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 04:14:51 -0000 Hi all, Following are some of my comments to v13 of the draft. Regards, Benjamin Lim ------------------- First comment. The mobile node returns home physically but shuts down the interface attached to the home link. As a result, a mobile node does not return home even though it attaches to the home link by one of interfaces. Before shutting down the interface, any binding for the care-of address previously associated with the interface should be deleted as defined in . ^^^ missing reference? Second comment. When a mobile node registers a given BID for the first time it MUST include the care of address field in the Binding Identifier mobility option. For any subsequent registrations that either re-register or de-register the same BID, the MN SHOULD NOT include the care of address field in the Binding Identifier mobility option. I think MN SHOULD NOT include CoA in BID option for subsequent registration is a bit too harsh. What is the justification of SHOULD NOT here? Suggest to change to 'MAY NOT'. Third comment. For section 6.2 on how HA/CN process BU. I believe it is mention in section 5.1 that when MN registers BID for first time, MN must include CoA field in BID option. For subsequent registration for this BID, MN can choose not include CoA field in BID option. I cannot find such action reflected in section 6.2. Propose to add the following for cases when BU is sent w/o bulk registration ----------------------- New text to section 6.2 ----------------------- If the Lifetime field is not set to zero and the Length value of the Binding Identifier mobility option is 4, the receiving node MUST check if the Binding Identifier specified in the Binding Identifier mobility option is an existing binding in its Binding Cache. * If the Binding Identifier is present in the Binding Cache, the receiving node MUST update the associated binding entry in its Binding Cache. * If the Binding Identifier is not present in the Binding Cache, the receiving node MUST reject the Binding Update and send a Binding Acknowledgment set to [MCOA UNKNOWN]. ------------------------------ End of new text to section 6.2 ------------------------------ Propose to add the following for cases when BU is sent with bulk registration ----------------------- New text to section 6.2 ----------------------- If the Lifetime field is not set to zero, the Length value of the Binding Identifier mobility option is 4 and when multiple Binding Identifier mobility options are present, the receiving node MUST check for each of the Binding Identifier mobility option present, if the Binding Identifier specified in the Binding Identifier mobility option is an existing binding in its Binding Cache. * If the Binding Identifier is present in the Binding Cache, the receiving node MUST update the associated binding entry in its Binding Cache. * If the Binding Identifier is not present in the Binding Cache, the receiving node MUST reject that Binding Identifier mobility option and send a Binding Acknowledgment with the status for that Binding Identifier mobility option set to [MCOA UNKNOWN]. ------------------------------ End of new text to section 6.2 ------------------------------ Fourth comment. For section 6.3 on how HA sends BA for home link registration. In section 4.4, it states a new status value for BA called [MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED]. This is not reflected in this section that when HA sends this. Propose to add ----------------------- New text to section 6.3 ----------------------- If the home agent is unable to support simultaneous home and foreign attachment operation for a mobile node (e.g. due to administrative policy), the home agent MUST reject the Binding Update and return [MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED] in the Status field of the Binding Identifier mobility option. ------------------------------ End of new text to section 6.3 ------------------------------ Fifth comment. To be inline with the fourth comment, section 5.7 should state the action for MN when receiving [MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED]. Propose to add text under the status code greater than 128 bullet. ----------------------- New text to section 5.7 ----------------------- If [MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED] is specified, it indicates that the home agent is unable to support the simultaneous home and foreign attachment operation for the mobile node. The mobile node SHOULD select to use either its home link attached interface or its foreign link attached interface. If the mobile node selects its home link interface, the mobile node SHOULD follow the procedure defined in section 5.5.1. If the mobile node selects its foreign link interface, the mobile node SHOULD follow the procedure defined in section 5.5.2. Alternatively, the mobile node can discover another home agent that is able to provide the simultaneous home and foreign attachment service. ------------------------------ End of new text to section 5.7 ------------------------------ Sixth comment. If BID option is not included in the Binding Acknowledgement, the home agent might not recognize the home registration. The home agent might have processed the home registration Binding Update as a regular de-registration as described in [RFC-3775] and deletes all the registered binding cache entries for the mobile node. Thus, the mobile node SHOULD stop using the interface attached to foreign link and use only the interface attached to the home link. The above text pertains more towards MN action rather that HA action. Suggest the following proposal: 1) Remove the below old text from section 6.3 ----------------------- Old text in section 6.3 ----------------------- If BID option is not included in the Binding Acknowledgement, the home agent might not recognize the home registration. The home agent might have processed the home registration Binding Update as a regular de-registration as described in [RFC-3775] and deletes all the registered binding cache entries for the mobile node. Thus, the mobile node SHOULD stop using the interface attached to foreign link and use only the interface attached to the home link. 2) Add new text to section 5.7 ----------------------- New text in section 5.7 ----------------------- If a mobile node attempts simultaneous home and foreign registration and receives a Binding Acknowledgment with no Binding Identifier mobility option present, the mobile node understands that the home agent does not support the simultaneous home and foreign attachment operation. Thus, the mobile node SHOULD select to use only one of its interface. If the mobile node selects its home link interface, the mobile node SHOULD follow the procedure defined in section 5.5.1. If the mobile node selects its foreign link interface, the mobile node SHOULD follow the procedure defined in section 5.5.2. ------------------------------ End of new text to section 5.7 ------------------------------ From marcelo@it.uc3m.es Wed Apr 22 23:53:03 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250A13A69B4 for ; Wed, 22 Apr 2009 23:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 V5DOd8DTp2vn for ; Wed, 22 Apr 2009 23:53:01 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0F40A3A68C8 for ; Wed, 22 Apr 2009 23:53:00 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (115.pool85-53-139.dynamic.orange.es [85.53.139.115]) by smtp02.uc3m.es (Postfix) with ESMTP id AEE7C6BADA5; Thu, 23 Apr 2009 08:54:16 +0200 (CEST) Message-ID: <49F01099.9000603@it.uc3m.es> Date: Thu, 23 Apr 2009 08:54:17 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Behcet Sarikaya References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> <375902.20727.qm@web111403.mail.gq1.yahoo.com> <8CF30647-6A19-4391-BE7E-CFE87EFD8EAD@gmail.com> <222821.303.qm@web111407.mail.gq1.yahoo.com> <49EF9356.8000504@it.uc3m.es> <473113.45048.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <473113.45048.qm@web111406.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16598.005 Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 06:53:03 -0000 To be placed where in the document? All the rest of the document stays the same? Behcet Sarikaya escribió: > Hi Marcelo, > How about this little paragraph? > > In this document it is assumed that a multi-homed MN connects to the > home link using only one interface. Therefore this interface > is considered as the main interface as identified by the home address > assigned by the home agent. The other or auxiliary interfaces may > later on become active and connect to some other networks and get > their care-of addresses and then the procedures defined in this > document allow such care-of addresses to be registered with the home > agent apart from the registration of the care-of addresses assigned to > the main interface which is already defined in RFC 3775. > Regards, > > Behcet > ------------------------------------------------------------------------ > *From:* marcelo bagnulo braun > *To:* Behcet Sarikaya > *Cc:* Ryuji Wakikawa ; mext > *Sent:* Wednesday, April 22, 2009 4:59:50 PM > *Subject:* Re: [MEXT] [Fwd: I-D > Action:draft-ietf-monami6-multiplecoa-13.txt] > > Hi Bechet, > > could you send exactly what text do you think needs to be changed in > the MCOA draft, so the WG can evaluate and figure out if the changes > are needed? (i.e. please send OLD text NEW text) > > Please note that at this point in the life of the document, we only > take changes that fix errors in the document, rather than getting > more features in. > > Regards, marcelo > > > > Behcet Sarikaya escribió: > > Hi Ryuji, > > I checked your draft. Again, I could not understand how you are > sending a registration BU at the home link as only an O-flag is > defined in your draft which is used for something else. > > As I mentioned to you, we discussed this related to > draft-premec-homelink and it seems like HA will reject such a BU > unless something is done, I thought you were familiar with the > discussions as it relates to your draft too. I am surprised. > > Regards, > > Behcet > > > > ------------------------------------------------------------------------ > > *From:* Ryuji Wakikawa > > > *To:* Behcet Sarikaya > > > *Cc:* George Tsirtsis >; mext > > > *Sent:* Wednesday, April 22, 2009 4:18:28 PM > > *Subject:* Re: [MEXT] [Fwd: I-D > Action:draft-ietf-monami6-multiplecoa-13.txt] > > > > Hi Behcet, > > > > On 2009/04/22, at 11:31, Behcet Sarikaya wrote: > > > > > > > > > > > From: George Tsirtsis >> > > > To: Behcet Sarikaya > >> > > > Cc: mext > >> > > > Sent: Wednesday, April 22, 2009 10:10:08 AM > > > Subject: Re: [MEXT] [Fwd: I-D > Action:draft-ietf-monami6-multiplecoa-13.txt] > > > > > > I do not think that adding home link registration to RFC3775bis is > feasible. > > > This requires logic in the MN and HA that is not directly compatible > > > to RFC3775. The aim of RFC3775bis is to make minimal changes for > > > clarification reasons and to correct errors. Home Link Registration as > > > defined in MCoA is neither. > > > [behcet] Why not? If it is needed in so many instances, that > qualifies it to become a base protocol feature, at least to me. > > > > We cannot add a new feature to 3775. That is the ground rule of > -bis. The chairs can clarify this. > > > > regards, > > ryuji > > > > > > > > > > > > On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya > > > > >> > wrote: > > > > Hi George, > > > > It seems in my previous reply I replied to this mail of yours > which was > > > > unrelated to the other mail you sent to which I was really replying, > > > > apologies. > > > > Now regarding home link registration, what is the mechanism > MCoA draft > > > > uses? Ryuji mentioned some H bit but I read the draft and > couldn't confirm > > > > it. > > > > > > > > My suggestion was building on this, i.e. I suggested that > whatever you > > > > came up with can be moved to 3775bis so that other people would > not have to > > > > make normative references to your draft. > > > > > > > > That's all. > > > > > > > > Regards, > > > > > > > > Behcet > > > > > > > > ________________________________ > > > > From: George Tsirtsis >> > > > > To: Vijay Devarapalli >> > > > > Cc: Behcet Sarikaya >>; mext >> > > > > Sent: Tuesday, April 21, 2009 2:14:55 PM > > > > Subject: Re: [MEXT] [Fwd: I-D > Action:draft-ietf-monami6-multiplecoa-13.txt] > > > > > > > > ...also wrt the home link registration, I do not think what you > > > > suggest is necessary. > > > > > > > > As far as I see the other documents are informational, and they > do not > > > > yet have a formal standing in the WG. If and when they do, as > > > > Informational documents, they should not require normative > changes to > > > > anything. They should make sure what they describe (mostly > > > > implementation options in this case) are compatible not only with > > > > RFC3775 but also with extensions to it, including Flow Bindings. . > > > > > > > > > > > > Regards > > > > George > > > > > > > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli > > >> > > > > wrote: > > > >> Behcet, > > > >> > > > >> Behcet Sarikaya wrote: > > > >>> > > > >>> *[behcet] Yes but each interface will appear to HA as a > different device > > > >>> and HA needs to assign a different HoA. Then MCoA problem > disappears.* > > > >>> *So George is saying that this is avoided by some virtual > interfaces so > > > >>> that HA does not see each interface separately. * > > > >>> *Is this explained anywhere in the draft?* > > > >>> *If yes then I am OK.* > > > >> > > > >> The home agent does not care about the multiple interfaces on > the mobile > > > >> node. It only sees the mobile node as one entity and allocates > a home > > > >> address to it. The multiple care-of addresses that the mobile > node has > > > >> will > > > >> be used by the home agent as tunnel end points. That is all.. > So there is > > > >> no > > > >> issue. > > > >> > > > >> Vijay > > > >> > > > >>> > Also I have a question to Ryuji: does this draft send a > > > >>> non-deregistration BU at the home link? If yes, is he familiar > with the > > > >>> discussion going on on this subject? This is another point of > confusion > > > >>> for > > > >>> me. > > > >>> > > > >>> This has been discussed for a long time in MEXT. > > > >>> who is familiar with which discussions? I don't know your > concern here. > > > >>> *[behcet] So your answer is yes the draft sends a > non-deregistration BU > > > >>> (kind of bulk registration) at the home link.* > > > >>> *The discussion I mentioned was related to > > > >>> draft-premec-mext-extended-home-link. This draft also sends > > > >>> non-deregistration BU at the home link. So does a few more > drafts like > > > >>> **draft-devarapalli-mext-mipv6-home-link.* > > > >>> > > > >>> ** > > > >>> *[behcet] You mentioned some bit is set but I could not > understand which. > > > >>> One idea is since so many drafts need this, why not factor > this out and > > > >>> define whatever the mechanism to enable sending > non-deregistration BU in > > > >>> 3775bis. What do you think about that?* > > > >>> > > > >>> ** > > > >>> > > > >>> > Sorry if I am too much confused > > > >>> > Please don't get me wrong, I am not trying to slow down the > progress > > > >>> of > > > >>> this document.. > > > >>> > > > >>> sure, but please explain your issue more precisely. > > > >>> > > > >>> thanks! > > > >>> ryuji > > > >>> > > > >>> > > > > >>> > Regards, > > > >>> > > > > >>> > Behcet > > > >>> > From: marcelo bagnulo braun > > > > >>> > >>> > > > >>> > To: mext > > >>>; Julien Laganier > > > >>> > > > > > >>> > >>>; Jari Arkko > > > >>> > > > > >>> > > > >>> > Sent: Tuesday, April 21, 2009 11:03:05 AM > > > >>> > Subject: [MEXT] [Fwd: I-D > > > >>> Action:draft-ietf-monami6-multiplecoa-13.txt] > > > >>> > > > > >>> > We have this new version of the MCOA document that > addresses the > > > >>> comments received, including IESG review comments. > > > >>> > To the best of my knowledge, the IESG is ok with the doc > and ready for > > > >>> publication.. > > > >>> > I am planning to ask our AD to move forward in a week or > so, so, if > > > >>> you > > > >>> have comments on the document please provide them before the > 1st of may. > > > >>> > > > > >>> > Regards, marcelo > > > >>> > (mcoa doc shepherd) > > > >>> > > > > >>> > -------- Mensaje original -------- > > > >>> > Asunto: [MEXT] I-D > Action:draft-ietf-monami6-multiplecoa-13.txt > > > >>> > Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) > > > >>> > De: Internet-Drafts@ietf.org > > >> > > > >>> > Para: i-d-announce@ietf.org > > >> > > > >>> > CC: mext@ietf.org > > >> > > > >>> > > > > >>> > > > > >>> > > > > >>> > A New Internet-Draft is available from the on-line > Internet-Drafts > > > >>> directories. > > > >>> > This draft is a work item of the Mobility EXTensions for > IPv6 Working > > > >>> Group of the IETF. > > > >>> > > > > >>> > > > > >>> > Title : Multiple Care-of Addresses Registration > > > >>> > Author(s) : R. Wakikawa, et al. > > > >>> > Filename : draft-ietf-monami6-multiplecoa-13..txt > > > >>> > Pages : 44 > > > >>> > Date : 2009-04-20 > > > >>> > > > > >>> > According to the current Mobile IPv6 specification, a > mobile node may > > > >>> > have several care-of addresses, but only one, called the > primary > > > >>> > care-of address, that can be registered with its home agent > and the > > > >>> > correspondent nodes. However, for matters of cost, > bandwidth, delay, > > > >>> > etc, it is useful for the mobile node to get Internet > access through > > > >>> > multiple accesses simultaneously, in which case the mobile > node would > > > >>> > be configured with multiple active IPv6 care-of addresses. > This > > > >>> > document proposes extensions to the Mobile IPv6 protocol to > register > > > >>> > and use multiple care-of addresses. The extensions > proposed in this > > > >>> > document can be used by Mobile Routers using the NEMO (Network > > > >>> > Mobility) Basic Support protocol as well. > > > >>> > > > > >>> > A URL for this Internet-Draft is: > > > >>> > > > > >>> > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.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. > > > >>> > > > > >>> > > > > >>> > > > > >>> > _______________________________________________ > > > >>> > MEXT mailing list > > > >>> > MEXT@ietf.org > > >> > > > >>> > https://www.ietf.org/mailman/listinfo/mext > > > >>> > > > >>> > > > >>> > > > >>> > ------------------------------------------------------------------------ > > > >>> > > > >>> _______________________________________________ > > > >>> MEXT mailing list > > > >>> MEXT@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/mext > > > >> > > > >> _______________________________________________ > > > >> MEXT mailing list > > > >> MEXT@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/mext > > > >> > > > > > > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > From qiuying@i2r.a-star.edu.sg Thu Apr 23 01:22:10 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF2D28C6D3 for ; Thu, 23 Apr 2009 01:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.968 X-Spam-Level: X-Spam-Status: No, score=-0.968 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_40=-0.185] 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 wYN7QiFrxkQd for ; Thu, 23 Apr 2009 01:22:09 -0700 (PDT) Received: from gw1.scei.a-star.edu.sg (gw1.scei.a-star.edu.sg [192.122.140.10]) by core3.amsl.com (Postfix) with ESMTP id 2AA9F28C6D0 for ; Thu, 23 Apr 2009 01:21:34 -0700 (PDT) Received: from mailfe01.teak.local.net (mailfe01.teak.local.net [192.122.134.9]) by gw1.scei.a-star.edu.sg (8.14.1/8.14.1) with ESMTP id n3N8Mn0K012116; Thu, 23 Apr 2009 16:22:50 +0800 Received: from t3400 ([10.217.141.170]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 16:24:09 +0800 Message-ID: <1285C0012533496C8CB9BEE0CA0D4C84@t3400> From: "QIU Ying" To: "marcelo bagnulo braun" , "mext" References: <49EF37D8.2010408@it.uc3m.es> Date: Thu, 23 Apr 2009 16:22:05 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 23 Apr 2009 08:24:09.0014 (UTC) FILETIME=[DFBC7D60:01C9C3EC] X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-04-23_04:2009-04-20, 2009-04-23, 2009-04-23 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0904230013 Cc: Jari Arkko Subject: Re: [MEXT] Moving forward with MEXT documents X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 08:22:10 -0000 Hi, Marcelo Please see my 2 cents inline. ----- Original Message ----- From: "marcelo bagnulo braun" Sent: Wednesday, April 22, 2009 11:29 PM > Hi, > > At this point in time, the WG has the following documents that are > ready for WGLC: > > draft-ietf-mext-firewall-admin-00 > draft-ietf-mext-firewall-vendor-00 > draft-ietf-mip6-hareliability-04 > draft-ietf-monami6-mipv6-analysis-05 > draft-ietf-monami6-multihoming-motivation-scenario-03 As regards these 2 firewall drafts, they are the products of the design team of 9 persons. I am sure that all these 9 persons know the documents very well due to a lot of discussions between them via email, phone meeting and face to face. Since only 4 names are listed as editors at each document, the other 5 persons could be considered as the thorough reviewers . Moreover, at the Philadelphia meeting, the mext attendees were given 10 minus specially to read the 2 documents throughly. Hence more people should understand the documents very well. > > And the following document that we need to ask for adoption: > > draft-premec-mext-extended-home-link-01 > > According to our new ground rules, each of these documents to proceed > will need 5 thorough reviews. Since this is a considerable amount of > effort from the WG, we would like soem feedback on how to manage this > effort. In particular, we would like to get feedback from the WG about > which documents should we issue the WGLC or adoption call first and if > possible volunteers to do the reviews for the documents. Regarding the documents processing in future, IMHO, we may require the authors to collect and edit all of comments from emails and discussion at the IETF meeting, and then ask the related providers of these comments (at least from 5 individuals) to endorse neatened reviews. Finally, push back the document with the neatened review to the WG to vote. I thought it could reduce the amount of review effort significantly. Regards Qiu Ying > > We will receive input on this till the 3rd of may and then decide how > to move forward. > > Regards, marcelo > > Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From tsirtsis@googlemail.com Thu Apr 23 01:40:12 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC443A71DC for ; Thu, 23 Apr 2009 01:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 11drJwB2chAh for ; Thu, 23 Apr 2009 01:40:10 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 80F7F3A68FA for ; Thu, 23 Apr 2009 01:40:10 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so159391ywj.49 for ; Thu, 23 Apr 2009 01:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=dc6JbLYBe8zxNsWIre2zbpaJDiXNX7zjguYEO7jJjYw=; b=XpAaGc1+XRClaO3Jpvq5z3TrFBwydWN8PjRltOXw7JAIxitwQyAfKTOCftrL4F0hQx zDwuidOEYvMR3kGuJzcb0ujwZ49uvHeVXA1xOHJZDALPIhUNOMnI5kZX+pdfp158zRON s7uTGbsgB0+a2ETAlUY+uAsBWuJTrNG3n69hg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qHTVHL04aYghRMCldI6zBxgYz5qEKtDyk25v3bpMS1msmdFXpek0lNCkVLp7ILQiSO n9M7KNS+D0p9JY+PeB0tO6DN/BiKvx/E7eC782aBDyGUTekiTGevkLKUIMXwOFUgTnzw uFZp5guZostfk9QM16UawwHISLtoaMFuJ6zXY= MIME-Version: 1.0 Received: by 10.90.52.1 with SMTP id z1mr812556agz.38.1240476087145; Thu, 23 Apr 2009 01:41:27 -0700 (PDT) In-Reply-To: References: <473113.45048.qm@web111406.mail.gq1.yahoo.com> Date: Thu, 23 Apr 2009 09:41:27 +0100 Message-ID: From: George Tsirtsis To: Vijay Devarapalli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 08:40:12 -0000 I also disagree... there is not such thing as a 'main' interface and there is no restriction on how many interfaces are connected to the home link, or whether aninterface connected on the home link then goes ahead is moved from the home link to a foreign link. George On Thu, Apr 23, 2009 at 12:43 AM, Vijay Devarapalli wr= ote: > Hi Bechet, > > On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote: > >> Hi Marcelo, >> =C2=A0 How about this little paragraph? >> >> In this document it is assumed that a multi-homed MN connects to the hom= e link >> using only one interface. Therefore this interface is considered as the = main >> interface as identified by the home address assigned by the home agent. > > I disagree with this. The mobile node can connect to the home link throug= h > any one of its interfaces. > >> The >> other or auxiliary interfaces may later on become active and connect to = some >> other networks and get their care-of addresses and then the procedures d= efined >> in this document allow such care-of addresses to be registered with the = home >> agent apart from the registration of the care-of addresses assigned to t= he >> main interface which is already defined in RFC 3775. > > There is no need for the home agent to identify one of the interfaces as = a > "main" interface. > > Vijay > >> Regards, >> >> Behcet >> >> From: marcelo bagnulo braun >> To: Behcet Sarikaya >> Cc: Ryuji Wakikawa ; mext >> Sent: Wednesday, April 22, 2009 4:59:50 PM >> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.t= xt] >> >> Hi Bechet, >> >> could you send exactly what text do you think needs to be changed in the= MCOA >> draft, so the WG can evaluate and figure out if the changes are needed? = (i.e. >> please send OLD text NEW text) >> >> Please note that at this point in the life of the document, we only take >> changes that fix errors in the document, rather than =C2=A0getting more = features >> in. >> >> Regards, marcelo >> >> >> >> Behcet Sarikaya escribi=C3=B3: >>> Hi Ryuji, >>> =C2=A0I checked your draft. Again, I could not understand how you are s= ending a >>> registration BU at the home link as only an O-flag is defined in your d= raft >>> which is used for something else. >>> =C2=A0As I mentioned to you, we discussed this related to draft-premec-= homelink >>> and it seems like HA will reject such a BU unless something is done, I >>> thought you were familiar with the discussions as it relates to your dr= aft >>> too. I am surprised. >>> =C2=A0Regards, >>> =C2=A0Behcet >>> >>> -----------------------------------------------------------------------= - >>> *From:* Ryuji Wakikawa >>> *To:* Behcet Sarikaya >>> *Cc:* George Tsirtsis ; mext >>> *Sent:* Wednesday, April 22, 2009 4:18:28 PM >>> *Subject:* Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-1= 3.txt] >>> >>> Hi Behcet, >>> >>> On 2009/04/22, at 11:31, Behcet Sarikaya wrote: >>> >>>> >>>> >>>> From: George Tsirtsis >>> > >>>> To: Behcet Sarikaya > >>>> Cc: mext > >>>> Sent: Wednesday, April 22, 2009 10:10:08 AM >>>> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13= .txt] >>>> >>>> I do not think that adding home link registration to RFC3775bis is fea= sible. >>>> This requires logic in the MN and HA that is not directly compatible >>>> to RFC3775. The aim of RFC3775bis is to make minimal changes for >>>> clarification reasons and to correct errors. Home Link Registration as >>>> defined in MCoA is neither. >>>> [behcet] Why not? If it is needed in so many instances, that qualifies= it to >>>> become a base protocol feature, at least to me. >>> >>> We cannot add a new feature to 3775. That is the ground rule of -bis. T= he >>> chairs can clarify this. >>> >>> regards, >>> ryuji >>> >>> >>> >>>> >>>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya >>>> > wrote: >>>>> Hi George, >>>>> =C2=A0It seems in my previous reply I replied to this mail of yours w= hich was >>>>> unrelated to the other mail you sent to which I was really replying, >>>>> apologies. >>>>> =C2=A0Now regarding home link registration, what is the mechanism MCo= A draft >>>>> uses? Ryuji mentioned some H bit but I read the draft and couldn't co= nfirm >>>>> it. >>>>> >>>>> =C2=A0My suggestion was building on this, i.e. I suggested that whate= ver you >>>>> came up with can be moved to 3775bis so that other people would not h= ave to >>>>> make normative references to your draft. >>>>> >>>>> That's all. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>> ________________________________ >>>>> From: George Tsirtsis >>>> > >>>>> To: Vijay Devarapalli = > >>>>> Cc: Behcet Sarikaya >; m= ext >>>>> > >>>>> Sent: Tuesday, April 21, 2009 2:14:55 PM >>>>> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-1= 3.txt] >>>>> >>>>> ...also wrt the home link registration, I do not think what you >>>>> suggest is necessary. >>>>> >>>>> As far as I see the other documents are informational, and they do no= t >>>>> yet have a formal standing in the WG. If and when they do, as >>>>> Informational documents, =C2=A0they should not require normative chan= ges to >>>>> anything. They should make sure what they describe (mostly >>>>> implementation options in this case) are compatible not only with >>>>> RFC3775 but also with extensions to it, including Flow Bindings. . >>>>> >>>>> >>>>> Regards >>>>> George >>>>> >>>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli >>>> > >>>>> wrote: >>>>>> Behcet, >>>>>> >>>>>> Behcet Sarikaya wrote: >>>>>>> >>>>>>> *[behcet] Yes but each interface will appear to HA as a different d= evice >>>>>>> and HA needs to assign a different HoA. Then MCoA problem disappear= s.* >>>>>>> *So George is saying that this is avoided by some virtual interface= s so >>>>>>> that HA does not see each interface separately. * >>>>>>> *Is this explained anywhere in the draft?* >>>>>>> *If yes then I am OK.* >>>>>> >>>>>> The home agent does not care about the multiple interfaces on the mo= bile >>>>>> node. It only sees the mobile node as one entity and allocates a hom= e >>>>>> address to it. The multiple care-of addresses that the mobile node h= as >>>>>> will >>>>>> be used by the home agent as tunnel end points. That is all.. So the= re is >>>>>> no >>>>>> issue. >>>>>> >>>>>> Vijay >>>>>> >>>>>>>> =C2=A0Also I have a question to Ryuji: does this draft send a >>>>>>> non-deregistration BU at the home link? If yes, is he familiar with= the >>>>>>> discussion going on on this subject? This is another point of confu= sion >>>>>>> for >>>>>>> me. >>>>>>> >>>>>>> This has been discussed for a long time in MEXT. >>>>>>> who is familiar with which discussions? I don't know your concern h= ere. >>>>>>> =C2=A0*[behcet] So your answer is yes the draft sends a non-deregis= tration BU >>>>>>> (kind of bulk registration) at the home link.* >>>>>>> *The discussion I mentioned was related to >>>>>>> draft-premec-mext-extended-home-link. This draft also sends >>>>>>> non-deregistration BU at the home link. So does a few more drafts l= ike >>>>>>> **draft-devarapalli-mext-mipv6-home-link.* >>>>>>> >>>>>>> ** >>>>>>> *[behcet] You mentioned some bit is set but I could not understand = which. >>>>>>> One idea is since so many drafts need this, why not factor this out= and >>>>>>> define whatever the mechanism to enable sending non-deregistration = BU in >>>>>>> 3775bis. What do you think about that?* >>>>>>> >>>>>>> ** >>>>>>> >>>>>>>> =C2=A0Sorry if I am too =C2=A0much confused >>>>>>>> Please don't get me wrong, I am not trying to slow down the progre= ss >>>>>>> of >>>>>>> this document.. >>>>>>> >>>>>>> sure, but please explain your issue more precisely. >>>>>>> >>>>>>> thanks! >>>>>>> ryuji >>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Behcet >>>>>>>> From: marcelo bagnulo braun >>>>>>> >>>>>>> >> >>>>>>>> To: mext >>>>>>> >>; Julien Laganier >>>>>>> >>>>>> >>>>>>> >>>>>> >>; Jari Arkko >>>>>>> >>>>>>> >>>>>> >>> >>>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM >>>>>>>> Subject: [MEXT] [Fwd: I-D >>>>>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>>> >>>>>>>> We have this new version of the MCOA document that addresses the >>>>>>> comments received, including IESG review comments. >>>>>>>> To the best of my knowledge, the IESG is ok with the doc and ready= for >>>>>>> publication.. >>>>>>>> I am planning to ask our AD to move forward in a week or so, so, i= f >>>>>>> you >>>>>>> have comments on the document please provide them before the 1st of= may. >>>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> (mcoa doc shepherd) >>>>>>>> >>>>>>>> -------- Mensaje original -------- >>>>>>>> Asunto: =C2=A0 =C2=A0[MEXT] I-D Action:draft-ietf-monami6-multiple= coa-13.txt >>>>>>>> Fecha: =C2=A0 =C2=A0Mon, 20 Apr 2009 08:30:01 -0700 (PDT) >>>>>>>> De: =C2=A0 =C2=A0Internet-Drafts@ietf.org >>>>>>>> = > >>>>>>>> Para: =C2=A0 =C2=A0i-d-announce@ietf.org >>>>>>>> > >>>>>>>> CC: =C2=A0 =C2=A0mext@ietf.org > >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>> directories. >>>>>>>> This draft is a work item of the Mobility EXTensions for IPv6 Work= ing >>>>>>> Group of the IETF. >>>>>>>> >>>>>>>> >>>>>>>> =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Multiple Ca= re-of Addresses Registration >>>>>>>> =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0: R. Wakikawa, et al. >>>>>>>> =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-mona= mi6-multiplecoa-13..txt >>>>>>>> =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 44 >>>>>>>> =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2009-= 04-20 >>>>>>>> >>>>>>>> According to the current Mobile IPv6 specification, a mobile node = may >>>>>>>> have several care-of addresses, but only one, called the primary >>>>>>>> care-of address, that can be registered with its home agent and th= e >>>>>>>> correspondent nodes. =C2=A0However, for matters of cost, bandwidth= , delay, >>>>>>>> etc, it is useful for the mobile node to get Internet access throu= gh >>>>>>>> multiple accesses simultaneously, in which case the mobile node wo= uld >>>>>>>> be configured with multiple active IPv6 care-of addresses. =C2=A0T= his >>>>>>>> document proposes extensions to the Mobile IPv6 protocol to regist= er >>>>>>>> and use multiple care-of addresses. =C2=A0The extensions proposed = in this >>>>>>>> document can be used by Mobile Routers using the NEMO (Network >>>>>>>> Mobility) Basic Support protocol as well. >>>>>>>> >>>>>>>> A URL for this Internet-Draft is: >>>>>>>> >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-= 13.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. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>> > >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>> >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------------------------= ----- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> -----------------------------------------------------------------------= - >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From hesham@elevatemobile.com Thu Apr 23 03:17:04 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628CD3A7217 for ; Thu, 23 Apr 2009 03:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 Ok6t0e9DtHwi for ; Thu, 23 Apr 2009 03:17:02 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 68B263A71CB for ; Thu, 23 Apr 2009 03:17:01 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Lww0N-0002RW-36; Thu, 23 Apr 2009 20:18:08 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 23 Apr 2009 20:17:59 +1000 From: Hesham Soliman To: marcelo bagnulo braun , Behcet Sarikaya Message-ID: Thread-Topic: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] Thread-Index: AcnD/Ma5zsu4Xfrhd06Za0nTOS/kFg== In-Reply-To: <49F01099.9000603@it.uc3m.es> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 10:17:04 -0000 Such restriction makes no sense for the document. The MN has to be able to use any interface.=20 Hesham =20 > Behcet Sarikaya escribi=F3: >> Hi Marcelo, >> How about this little paragraph? >> =20 >> In this document it is assumed that a multi-homed MN connects to the >> home link using only one interface. Therefore this interface >> is considered as the main interface as identified by the home address >> assigned by the home agent. The other or auxiliary interfaces may >> later on become active and connect to some other networks and get >> their care-of addresses and then the procedures defined in this >> document allow such care-of addresses to be registered with the home >> agent apart from the registration of the care-of addresses assigned to >> the main interface which is already defined in RFC 3775. >> Regards, >> =20 >> Behcet >> ------------------------------------------------------------------------ >> *From:* marcelo bagnulo braun >> *To:* Behcet Sarikaya >> *Cc:* Ryuji Wakikawa ; mext >> *Sent:* Wednesday, April 22, 2009 4:59:50 PM >> *Subject:* Re: [MEXT] [Fwd: I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt] >>=20 >> Hi Bechet, >>=20 >> could you send exactly what text do you think needs to be changed in >> the MCOA draft, so the WG can evaluate and figure out if the changes >> are needed? (i.e. please send OLD text NEW text) >>=20 >> Please note that at this point in the life of the document, we only >> take changes that fix errors in the document, rather than getting >> more features in. >>=20 >> Regards, marcelo >>=20 >>=20 >>=20 >> Behcet Sarikaya escribi=F3: >>> Hi Ryuji, >>> I checked your draft. Again, I could not understand how you are >> sending a registration BU at the home link as only an O-flag is >> defined in your draft which is used for something else. >>> As I mentioned to you, we discussed this related to >> draft-premec-homelink and it seems like HA will reject such a BU >> unless something is done, I thought you were familiar with the >> discussions as it relates to your draft too. I am surprised. >>> Regards, >>> Behcet >>>=20 >>> -----------------------------------------------------------------------= - >>> *From:* Ryuji Wakikawa > > >>> *To:* Behcet Sarikaya > >>> *Cc:* George Tsirtsis > >; mext > > >>> *Sent:* Wednesday, April 22, 2009 4:18:28 PM >>> *Subject:* Re: [MEXT] [Fwd: I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>=20 >>> Hi Behcet, >>>=20 >>> On 2009/04/22, at 11:31, Behcet Sarikaya wrote: >>>=20 >>>>=20 >>>>=20 >>>> From: George Tsirtsis > > >> >>>> To: Behcet Sarikaya >> >> >>>> Cc: mext >> >> >>>> Sent: Wednesday, April 22, 2009 10:10:08 AM >>>> Subject: Re: [MEXT] [Fwd: I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>=20 >>>> I do not think that adding home link registration to RFC3775bis is >> feasible. >>>> This requires logic in the MN and HA that is not directly compatible >>>> to RFC3775. The aim of RFC3775bis is to make minimal changes for >>>> clarification reasons and to correct errors. Home Link Registration as >>>> defined in MCoA is neither. >>>> [behcet] Why not? If it is needed in so many instances, that >> qualifies it to become a base protocol feature, at least to me. >>>=20 >>> We cannot add a new feature to 3775. That is the ground rule of >> -bis. The chairs can clarify this. >>>=20 >>> regards, >>> ryuji >>>=20 >>>=20 >>>=20 >>>>=20 >>>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya >>>> >> >> >> wrote: >>>>> Hi George, >>>>> It seems in my previous reply I replied to this mail of yours >> which was >>>>> unrelated to the other mail you sent to which I was really replying, >>>>> apologies. >>>>> Now regarding home link registration, what is the mechanism >> MCoA draft >>>>> uses? Ryuji mentioned some H bit but I read the draft and >> couldn't confirm >>>>> it. >>>>>=20 >>>>> My suggestion was building on this, i.e. I suggested that >> whatever you >>>>> came up with can be moved to 3775bis so that other people would >> not have to >>>>> make normative references to your draft. >>>>>=20 >>>>> That's all. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Behcet >>>>>=20 >>>>> ________________________________ >>>>> From: George Tsirtsis > > >> >>>>> To: Vijay Devarapalli > > >> >>>>> Cc: Behcet Sarikaya > > >>; mext > >> >>>>> Sent: Tuesday, April 21, 2009 2:14:55 PM >>>>> Subject: Re: [MEXT] [Fwd: I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>=20 >>>>> ...also wrt the home link registration, I do not think what you >>>>> suggest is necessary. >>>>>=20 >>>>> As far as I see the other documents are informational, and they >> do not >>>>> yet have a formal standing in the WG. If and when they do, as >>>>> Informational documents, they should not require normative >> changes to >>>>> anything. They should make sure what they describe (mostly >>>>> implementation options in this case) are compatible not only with >>>>> RFC3775 but also with extensions to it, including Flow Bindings. . >>>>>=20 >>>>>=20 >>>>> Regards >>>>> George >>>>>=20 >>>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli >> >> >> >>>>> wrote: >>>>>> Behcet, >>>>>>=20 >>>>>> Behcet Sarikaya wrote: >>>>>>>=20 >>>>>>> *[behcet] Yes but each interface will appear to HA as a >> different device >>>>>>> and HA needs to assign a different HoA. Then MCoA problem >> disappears.* >>>>>>> *So George is saying that this is avoided by some virtual >> interfaces so >>>>>>> that HA does not see each interface separately. * >>>>>>> *Is this explained anywhere in the draft?* >>>>>>> *If yes then I am OK.* >>>>>>=20 >>>>>> The home agent does not care about the multiple interfaces on >> the mobile >>>>>> node. It only sees the mobile node as one entity and allocates >> a home >>>>>> address to it. The multiple care-of addresses that the mobile >> node has >>>>>> will >>>>>> be used by the home agent as tunnel end points. That is all.. >> So there is >>>>>> no >>>>>> issue. >>>>>>=20 >>>>>> Vijay >>>>>>=20 >>>>>>>> Also I have a question to Ryuji: does this draft send a >>>>>>> non-deregistration BU at the home link? If yes, is he familiar >> with the >>>>>>> discussion going on on this subject? This is another point of >> confusion >>>>>>> for >>>>>>> me. >>>>>>>=20 >>>>>>> This has been discussed for a long time in MEXT. >>>>>>> who is familiar with which discussions? I don't know your >> concern here. >>>>>>> *[behcet] So your answer is yes the draft sends a >> non-deregistration BU >>>>>>> (kind of bulk registration) at the home link.* >>>>>>> *The discussion I mentioned was related to >>>>>>> draft-premec-mext-extended-home-link. This draft also sends >>>>>>> non-deregistration BU at the home link. So does a few more >> drafts like >>>>>>> **draft-devarapalli-mext-mipv6-home-link.* >>>>>>>=20 >>>>>>> ** >>>>>>> *[behcet] You mentioned some bit is set but I could not >> understand which. >>>>>>> One idea is since so many drafts need this, why not factor >> this out and >>>>>>> define whatever the mechanism to enable sending >> non-deregistration BU in >>>>>>> 3775bis. What do you think about that?* >>>>>>>=20 >>>>>>> ** >>>>>>>=20 >>>>>>>> Sorry if I am too much confused >>>>>>>> Please don't get me wrong, I am not trying to slow down the >> progress >>>>>>> of >>>>>>> this document.. >>>>>>>=20 >>>>>>> sure, but please explain your issue more precisely. >>>>>>>=20 >>>>>>> thanks! >>>>>>> ryuji >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Behcet >>>>>>>> From: marcelo bagnulo braun > > > >>>>>>> >> >>> >>>>>>>> To: mext >> > > > >>>; Julien Laganier >>>>>>> > >> > > >>>>>>> > >> > >>>; Jari Arkko >>>>>>> >> > >> >> >>> >>>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM >>>>>>>> Subject: [MEXT] [Fwd: I-D >>>>>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>>>=20 >>>>>>>> We have this new version of the MCOA document that >> addresses the >>>>>>> comments received, including IESG review comments. >>>>>>>> To the best of my knowledge, the IESG is ok with the doc >> and ready for >>>>>>> publication.. >>>>>>>> I am planning to ask our AD to move forward in a week or >> so, so, if >>>>>>> you >>>>>>> have comments on the document please provide them before the >> 1st of may. >>>>>>>>=20 >>>>>>>> Regards, marcelo >>>>>>>> (mcoa doc shepherd) >>>>>>>>=20 >>>>>>>> -------- Mensaje original -------- >>>>>>>> Asunto: [MEXT] I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt >>>>>>>> Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) >>>>>>>> De: Internet-Drafts@ietf.org >> > > > > >> >>>>>>>> Para: i-d-announce@ietf.org >> > > > > >> >>>>>>>> CC: mext@ietf.org >> > > >> >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> A New Internet-Draft is available from the on-line >> Internet-Drafts >>>>>>> directories. >>>>>>>> This draft is a work item of the Mobility EXTensions for >> IPv6 Working >>>>>>> Group of the IETF. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Title : Multiple Care-of Addresses Registration >>>>>>>> Author(s) : R. Wakikawa, et al. >>>>>>>> Filename : draft-ietf-monami6-multiplecoa-13..txt >>>>>>>> Pages : 44 >>>>>>>> Date : 2009-04-20 >>>>>>>>=20 >>>>>>>> According to the current Mobile IPv6 specification, a >> mobile node may >>>>>>>> have several care-of addresses, but only one, called the >> primary >>>>>>>> care-of address, that can be registered with its home agent >> and the >>>>>>>> correspondent nodes. However, for matters of cost, >> bandwidth, delay, >>>>>>>> etc, it is useful for the mobile node to get Internet >> access through >>>>>>>> multiple accesses simultaneously, in which case the mobile >> node would >>>>>>>> be configured with multiple active IPv6 care-of addresses. >> This >>>>>>>> document proposes extensions to the Mobile IPv6 protocol to >> register >>>>>>>> and use multiple care-of addresses. The extensions >> proposed in this >>>>>>>> document can be used by Mobile Routers using the NEMO (Network >>>>>>>> Mobility) Basic Support protocol as well. >>>>>>>>=20 >>>>>>>> A URL for this Internet-Draft is: >>>>>>>>=20 >>>>>>>=20 >> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.tx= t >>>>>>>>=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 >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org > > >> >> >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >> ------------------------------------------------------------------------ >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org > > >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>=20 >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>>=20 >>> -----------------------------------------------------------------------= - >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From conny.larsson@ericsson.com Thu Apr 23 04:31:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDD803A6FDA for ; Thu, 23 Apr 2009 04:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.84 X-Spam-Level: X-Spam-Status: No, score=-5.84 tagged_above=-999 required=5 tests=[AWL=0.409, 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 TalOeccMYLVG for ; Thu, 23 Apr 2009 04:31:38 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 237793A6E74 for ; Thu, 23 Apr 2009 04:31:32 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E788E23933; Thu, 23 Apr 2009 13:32:17 +0200 (CEST) X-AuditID: c1b4fb3c-adfd1bb00000238f-31-49f047c8c554 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7DC6C23C54; Thu, 23 Apr 2009 12:49:44 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 12:49:43 +0200 Received: from [127.0.0.1] ([147.214.130.137]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 12:49:42 +0200 Message-ID: <49F047C5.5000202@ericsson.com> Date: Thu, 23 Apr 2009 12:49:41 +0200 From: Conny Larsson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mext , Hesham Soliman Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2009 10:49:42.0665 (UTC) FILETIME=[3565DF90:01C9C401] X-Brightmail-Tracker: AAAAAA== Subject: [MEXT] Proposal for new Flow Idenfication option format X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 11:31:38 -0000 Hi Hesham, As there seems to be multiple proposals for the flow descriptor format I believe there is a need for a revised format of the Flow Identification option defined in draft-ietf-mext-flow-binding-01.txt. My proposal would be as follows: Flow Identification option: =========================== This option includes information about the type of flow identification format that follows. Exactly one option MUST be present in the message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Len | Format | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD Option Len Length of option in octets. Format 01 Format type 1 02 Format type 2 Flow Descriptor: ================ This option identifies a specific flow. There MAY exist multiple Flow Descriptor options in one Flow Identification option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Len | Flow Description | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD Option Len Length of the Flow Description in octets Flow Description Defined in a separate document per format type Regards Conny From tsirtsis@googlemail.com Thu Apr 23 06:19:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6DC93A6F4D for ; Thu, 23 Apr 2009 06:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 h1Z-2vDdGHkj for ; Thu, 23 Apr 2009 06:19:26 -0700 (PDT) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by core3.amsl.com (Postfix) with ESMTP id CE4073A6A47 for ; Thu, 23 Apr 2009 06:19:25 -0700 (PDT) Received: by gxk10 with SMTP id 10so1109222gxk.13 for ; Thu, 23 Apr 2009 06:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=AoSSe0idy8XL4SSa3sIXrFXjjnjDuvxI2++E3nDr5u8=; b=AHsG1yNbomw0Xvfhql4Qmp6X45cEcDhIzU2Qgyg4nwthYIrVtW4lFhGiRSL6U3XvGM tb/X24MF5Sl2li0by7hp9e3SsmbgKC2sY2V1V0ZmQlNsYOavgKvagUQJ/s2XYLHjnIY1 ZLNeXLTNNZzb0FBpYFEbds+ya3xr5LMKF2SNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eVN3LJQ82xav3gjImev4h5oinUUctU/QX09JD8orMhYCQ5+D3TUTcx5ZM8Ju2Wd9wh ezhBj1dladT0SZMV9CFNUKbrRfZrAxx8z4UJX1RTSP9t26g18v7AlpzmCJs6U0rUex2f oFGKfwO0Pbzxa6VicjjDIUzxc+vGbtAU+ntbI= MIME-Version: 1.0 Received: by 10.90.120.17 with SMTP id s17mr491156agc.33.1240492843295; Thu, 23 Apr 2009 06:20:43 -0700 (PDT) In-Reply-To: <49F047C5.5000202@ericsson.com> References: <49F047C5.5000202@ericsson.com> Date: Thu, 23 Apr 2009 14:20:43 +0100 Message-ID: From: George Tsirtsis To: Conny Larsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hesham Soliman , mext Subject: Re: [MEXT] Proposal for new Flow Idenfication option format X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 13:19:26 -0000 Hi Conny, We have been in intense editing of the Flow Binding draft for the last couple of weeks and we are going to publish a new version early next week. In this version we have already created a sub-option for the flow description so that different types can be defined. Sorry for the delay, please bear with us. Thanks George On Thu, Apr 23, 2009 at 11:49 AM, Conny Larsson wrote: > Hi Hesham, > > As there seems to be multiple proposals for the flow descriptor format I > believe there is a need for a revised format of the Flow Identification > option defined in draft-ietf-mext-flow-binding-01.txt. > > My proposal would be as follows: > > Flow Identification option: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > This option includes information about the type of flow identification > format that follows. Exactly one option MUST be present in the message. > > 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option Type =C2=A0 | =C2=A0Option Len =C2=A0 | =C2=A0 Format =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Option Type > =C2=A0TBD > > Option Len > =C2=A0Length of option in octets. > > Format > =C2=A001 =C2=A0 Format type 1 > =C2=A002 =C2=A0 Format type 2 > > > > Flow Descriptor: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This option identifies a specific flow. There MAY exist multiple > Flow Descriptor options in one Flow Identification option > > 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option Type =C2=A0 | =C2=A0Option Len =C2=A0 | =C2=A0 Flow Description = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 + > . =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 . > . =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Option Type > =C2=A0TBD > > Option Len > =C2=A0Length of the Flow Description in octets > > Flow Description > =C2=A0Defined in a separate document per format type > > > Regards > Conny > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From behcetsarikaya@yahoo.com Thu Apr 23 08:43:57 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B6528C687 for ; Thu, 23 Apr 2009 08:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=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 umkkqWfg+mij for ; Thu, 23 Apr 2009 08:43:55 -0700 (PDT) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id 18B9028C680 for ; Thu, 23 Apr 2009 08:43:55 -0700 (PDT) Received: (qmail 51132 invoked by uid 60001); 23 Apr 2009 15:45:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240501512; bh=eAx757Or6+EQum4y6M6F5xXWnypVDedOhmPsGEAMctA=; 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=YDgqaqAn8hCV0w5psxUlYkJ2/g89I2IQM6+I39reX6m1N40totks/USFV+eEnCOlnI9kctqh3+QTOHu9htWkyvR43KGYyJ/1jICdGo1mYsRUkNfeMt8E54z97aZlIGafJLZJ1QgplOFdP6OI0V+mTMlQwts69iAIAGQ9RgmBKTg= 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=xdswGPvsAgUmL1dn3cNzyUAY7rkmrN238x3B2W3dga5EruVXyRZa8isF8hEkF3Tv3hyJ7L5TClOOCsu3ovq9W0D0kVwZ1UMvkUCft+UHw/L5iLT5BYQyXQBVfu/KBS0PVnI1SNhf5iLU/kfIiyISPqepTY6nEx81zw9mrT4EOtU=; Message-ID: <923378.50587.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: cLxEfGYVM1nT1EpEAROByewkAyIP04I2R_LWIVsNo4LDbG_fuoX5tBvhvBE9vH89SZzGddWTQfbaWGjmM.N96GV7Rl7ec0SygynaXCp6vHhFspDAjppDlRUeXKI4DlxLa0WG2RsuQMy3XTBtjy5mZVMthpdHBGOHHm2vfNczqEDuKcXU4ActA0hjSX6xDQx7wVDUiKYQkm1jXfCZb37_GrJGCcRRh0uWOgHMMKLdNxKVXo8aWabJdgrRFVYu2oV2xpyF_YRA0igaelC0ohIOCbc1nGn740hW1JJgZbrbeELQnaqJ9milMo1xZedZkK_NoynA Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Thu, 23 Apr 2009 08:45:12 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: Date: Thu, 23 Apr 2009 08:45:12 -0700 (PDT) From: Behcet Sarikaya To: Hesham Soliman , marcelo bagnulo braun In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1499292816-1240501512=:50587" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:43:57 -0000 --0-1499292816-1240501512=:50587 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hesham, I don't think the text imposes on which interface you connect to th= e home link, so MN is able to use any interface.=0A=0AWhat the text says, t= he interface used to connect to the home interface is considered as the mai= n interface as far as this document is concerned. =0A=0AMaybe we can clarif= y the main and auxiliary with "as far as this document is concerned".=0A=0A= Regards,=0A=0ABehcet=0A=0A=0A=0A=0A________________________________=0AFrom:= Hesham Soliman =0ATo: marcelo bagnulo braun ; Behcet Sarikaya =0ACc: mext =0ASent: Thursday, April 23, 2009 5:17:59 AM=0ASubject: Re: [MEXT] [Fw= d: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A=0ASuch restriction = makes no sense for the document. The MN has to be able to=0Ause any interfa= ce. =0A=0AHesham=0A=0A> Behcet Sarikaya escribi=F3:=0A>> Hi Marcelo,=0A>>= =A0 How about this little paragraph?=0A>>=A0 =0A>> In this document it is a= ssumed that a multi-homed MN connects to the=0A>> home link using only one = interface. Therefore this interface=0A>> is considered as the main interfac= e as identified by the home address=0A>> assigned by the home agent.=A0 The= other or auxiliary interfaces may=0A>> later on become active and connect = to some other networks and get=0A>> their care-of addresses and then the pr= ocedures defined in this=0A>> document allow such care-of addresses to be r= egistered with the home=0A>> agent apart from the registration of the care-= of addresses assigned to=0A>> the main interface which is already defined i= n RFC 3775.=0A>> Regards,=0A>>=A0 =0A>> Behcet=0A>> -----------------------= -------------------------------------------------=0A>> *From:* marcelo bagn= ulo braun =0A>> *To:* Behcet Sarikaya =0A>> *Cc:* Ryuji Wakikawa ; mext =0A>> *Sent:* Wednesday, April 22, 2009 4:59:50 PM=0A>> *Subject:* Re: [M= EXT] [Fwd: I-D=0A>> Action:draft-ietf-monami6-multiplecoa-13.txt]=0A>> =0A>= > Hi Bechet,=0A>> =0A>> could you send exactly what text do you think needs= to be changed in=0A>> the MCOA draft, so the WG can evaluate and figure ou= t if the changes=0A>> are needed? (i.e. please send OLD text NEW text)=0A>>= =0A>> Please note that at this point in the life of the document, we only= =0A>> take changes that fix errors in the document, rather than=A0 getting= =0A>> more features in.=0A>> =0A>> Regards, marcelo=0A>> =0A>> =0A>> =0A>> = Behcet Sarikaya escribi=F3:=0A>>> Hi Ryuji,=0A>>>=A0 I checked your draft. = Again, I could not understand how you are=0A>> sending a registration BU at= the home link as only an O-flag is=0A>> defined in your draft which is use= d for something else.=0A>>>=A0 As I mentioned to you, we discussed this rel= ated to=0A>> draft-premec-homelink and it seems like HA will reject such a = BU=0A>> unless something is done, I thought you were familiar with the=0A>>= discussions as it relates to your draft too. I am surprised.=0A>>>=A0 Rega= rds,=0A>>>=A0 Behcet=0A>>> =0A>>> -----------------------------------------= -------------------------------=0A>>> *From:* Ryuji Wakikawa > >=0A>>> *To:* Behcet Sari= kaya >=0A>>> *Cc:* George Tsir= tsis > >; mext = > >=0A>>> *Sent:* Wednesday, April = 22, 2009 4:18:28 PM=0A>>> *Subject:* Re: [MEXT] [Fwd: I-D=0A>> Action:draft= -ietf-monami6-multiplecoa-13.txt]=0A>>> =0A>>> Hi Behcet,=0A>>> =0A>>> On 2= 009/04/22, at 11:31, Behcet Sarikaya wrote:=0A>>> =0A>>>> =0A>>>> =0A>>>> F= rom: George Tsirtsis > > >>=0A>>>> To: Behcet Sarikaya =0A>> >>=0A>>>> Cc: = mext =0A>> >>=0A>>>> Sent: Wednesday, April 22, 2009 10:10:08 AM=0A>>= >> Subject: Re: [MEXT] [Fwd: I-D=0A>> Action:draft-ietf-monami6-multiplecoa= -13.txt]=0A>>>> =0A>>>> I do not think that adding home link registration t= o RFC3775bis is=0A>> feasible.=0A>>>> This requires logic in the MN and HA = that is not directly compatible=0A>>>> to RFC3775. The aim of RFC3775bis is= to make minimal changes for=0A>>>> clarification reasons and to correct er= rors. Home Link Registration as=0A>>>> defined in MCoA is neither.=0A>>>> [= behcet] Why not? If it is needed in so many instances, that=0A>> qualifies = it to become a base protocol feature, at least to me.=0A>>> =0A>>> We canno= t add a new feature to 3775. That is the ground rule of=0A>> -bis. The chai= rs can clarify this.=0A>>> =0A>>> regards,=0A>>> ryuji=0A>>> =0A>>> =0A>>> = =0A>>>> =0A>>>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya=0A>>>> =0A>> >>=0A>> wrote:=0A>>>>>= Hi George,=0A>>>>>=A0 It seems in my previous reply I replied to this mail= of yours=0A>> which was=0A>>>>> unrelated to the other mail you sent to wh= ich I was really replying,=0A>>>>> apologies.=0A>>>>>=A0 Now regarding home= link registration, what is the mechanism=0A>> MCoA draft=0A>>>>> uses? Ryu= ji mentioned some H bit but I read the draft and=0A>> couldn't confirm=0A>>= >>> it.=0A>>>>> =0A>>>>>=A0 My suggestion was building on this, i.e. I sugg= ested that=0A>> whatever you=0A>>>>> came up with can be moved to 3775bis s= o that other people would=0A>> not have to=0A>>>>> make normative reference= s to your draft.=0A>>>>> =0A>>>>> That's all.=0A>>>>> =0A>>>>> Regards,=0A>= >>>> =0A>>>>> Behcet=0A>>>>> =0A>>>>> ________________________________=0A>>= >>> From: George Tsirtsis > > >>=0A>>>>> To: Vijay Devarapalli > > >>=0A>>>>> Cc: Behcet Sarikaya > > >>; mext= > >>=0A>>>>> Sent: Tuesday, April 21, 2009 2:14:55 PM=0A>>>>> Su= bject: Re: [MEXT] [Fwd: I-D=0A>> Action:draft-ietf-monami6-multiplecoa-13.t= xt]=0A>>>>> =0A>>>>> ...also wrt the home link registration, I do not think= what you=0A>>>>> suggest is necessary.=0A>>>>> =0A>>>>> As far as I see th= e other documents are informational, and they=0A>> do not=0A>>>>> yet have = a formal standing in the WG. If and when they do, as=0A>>>>> Informational = documents,=A0 they should not require normative=0A>> changes to=0A>>>>> any= thing. They should make sure what they describe (mostly=0A>>>>> implementat= ion options in this case) are compatible not only with=0A>>>>> RFC3775 but = also with extensions to it, including Flow Bindings. .=0A>>>>> =0A>>>>> =0A= >>>>> Regards=0A>>>>> George=0A>>>>> =0A>>>>> On Tue, Apr 21, 2009 at 7:58 = PM, Vijay Devarapalli=0A>> = =0A>> >>=0A>>>>> wrot= e:=0A>>>>>> Behcet,=0A>>>>>> =0A>>>>>> Behcet Sarikaya wrote:=0A>>>>>>> =0A= >>>>>>> *[behcet] Yes but each interface will appear to HA as a=0A>> differ= ent device=0A>>>>>>> and HA needs to assign a different HoA. Then MCoA prob= lem=0A>> disappears.*=0A>>>>>>> *So George is saying that this is avoided b= y some virtual=0A>> interfaces so=0A>>>>>>> that HA does not see each inter= face separately. *=0A>>>>>>> *Is this explained anywhere in the draft?*=0A>= >>>>>> *If yes then I am OK.*=0A>>>>>> =0A>>>>>> The home agent does not ca= re about the multiple interfaces on=0A>> the mobile=0A>>>>>> node. It only = sees the mobile node as one entity and allocates=0A>> a home=0A>>>>>> addre= ss to it. The multiple care-of addresses that the mobile=0A>> node has=0A>>= >>>> will=0A>>>>>> be used by the home agent as tunnel end points. That is = all..=0A>> So there is=0A>>>>>> no=0A>>>>>> issue.=0A>>>>>> =0A>>>>>> Vijay= =0A>>>>>> =0A>>>>>>>>=A0 Also I have a question to Ryuji: does this draft s= end a=0A>>>>>>> non-deregistration BU at the home link? If yes, is he famil= iar=0A>> with the=0A>>>>>>> discussion going on on this subject? This is an= other point of=0A>> confusion=0A>>>>>>> for=0A>>>>>>> me.=0A>>>>>>> =0A>>>>= >>> This has been discussed for a long time in MEXT.=0A>>>>>>> who is famil= iar with which discussions? I don't know your=0A>> concern here.=0A>>>>>>>= =A0 *[behcet] So your answer is yes the draft sends a=0A>> non-deregistrati= on BU=0A>>>>>>> (kind of bulk registration) at the home link.*=0A>>>>>>> *T= he discussion I mentioned was related to=0A>>>>>>> draft-premec-mext-extend= ed-home-link. This draft also sends=0A>>>>>>> non-deregistration BU at the = home link. So does a few more=0A>> drafts like=0A>>>>>>> **draft-devarapall= i-mext-mipv6-home-link.*=0A>>>>>>> =0A>>>>>>> **=0A>>>>>>> *[behcet] You me= ntioned some bit is set but I could not=0A>> understand which.=0A>>>>>>> On= e idea is since so many drafts need this, why not factor=0A>> this out and= =0A>>>>>>> define whatever the mechanism to enable sending=0A>> non-deregis= tration BU in=0A>>>>>>> 3775bis. What do you think about that?*=0A>>>>>>> = =0A>>>>>>> **=0A>>>>>>> =0A>>>>>>>>=A0 Sorry if I am too=A0 much confused= =0A>>>>>>>> Please don't get me wrong, I am not trying to slow down the=0A>= > progress=0A>>>>>>> of=0A>>>>>>> this document..=0A>>>>>>> =0A>>>>>>> sure= , but please explain your issue more precisely.=0A>>>>>>> =0A>>>>>>> thanks= !=0A>>>>>>> ryuji=0A>>>>>>> =0A>>>>>>>> =0A>>>>>>>> Regards,=0A>>>>>>>> =0A= >>>>>>>> Behcet=0A>>>>>>>> From: marcelo bagnulo braun > > >=0A>>>>>>> =0A>> >>>=0A= >>>>>>>> To: mext =0A>> > > > >>>; Julien Laganie= r=0A>>>>>>> > =0A>> > >=0A>>>>>>> > =0A>> > >>>; Jari Arkko=0A>>>>>>> =0A>> >=0A>> =0A>> >>>=0A>>>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM=0A>>>>>>>> Subjec= t: [MEXT] [Fwd: I-D=0A>>>>>>> Action:draft-ietf-monami6-multiplecoa-13.txt]= =0A>>>>>>>> =0A>>>>>>>> We have this new version of the MCOA document that= =0A>> addresses the=0A>>>>>>> comments received, including IESG review comm= ents.=0A>>>>>>>> To the best of my knowledge, the IESG is ok with the doc= =0A>> and ready for=0A>>>>>>> publication..=0A>>>>>>>> I am planning to ask= our AD to move forward in a week or=0A>> so, so, if=0A>>>>>>> you=0A>>>>>>= > have comments on the document please provide them before the=0A>> 1st of = may.=0A>>>>>>>> =0A>>>>>>>> Regards, marcelo=0A>>>>>>>> (mcoa doc shepherd)= =0A>>>>>>>> =0A>>>>>>>> -------- Mensaje original --------=0A>>>>>>>> Asunt= o:=A0 =A0 [MEXT] I-D=0A>> Action:draft-ietf-monami6-multiplecoa-13.txt=0A>>= >>>>>> Fecha:=A0 =A0 Mon, 20 Apr 2009 08:30:01 -0700 (PDT)=0A>>>>>>>> De:= =A0 =A0 Internet-Drafts@ietf.org=0A>> > > > > >>=0A>>>>>>>= > Para:=A0 =A0 i-d-announce@ietf.org=0A>> > > > > >>=0A>>>>>>>> CC:=A0 =A0 mext= @ietf.org =0A>> > > >>=0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> =0A>>>>>= >>> A New Internet-Draft is available from the on-line=0A>> Internet-Drafts= =0A>>>>>>> directories.=0A>>>>>>>> This draft is a work item of the Mobilit= y EXTensions for=0A>> IPv6 Working=0A>>>>>>> Group of the IETF.=0A>>>>>>>> = =0A>>>>>>>> =0A>>>>>>>>=A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : Multiple Care-of = Addresses Registration=0A>>>>>>>>=A0 =A0 Author(s)=A0 =A0 =A0 : R. Wakikawa= , et al.=0A>>>>>>>>=A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-monami6-mul= tiplecoa-13..txt=0A>>>>>>>>=A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 : 44=0A>>>>>>>>= =A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2009-04-20=0A>>>>>>>> =0A>>>>>>>> Acc= ording to the current Mobile IPv6 specification, a=0A>> mobile node may=0A>= >>>>>>> have several care-of addresses, but only one, called the=0A>> prima= ry=0A>>>>>>>> care-of address, that can be registered with its home agent= =0A>> and the=0A>>>>>>>> correspondent nodes.=A0 However, for matters of co= st,=0A>> bandwidth, delay,=0A>>>>>>>> etc, it is useful for the mobile node= to get Internet=0A>> access through=0A>>>>>>>> multiple accesses simultane= ously, in which case the mobile=0A>> node would=0A>>>>>>>> be configured wi= th multiple active IPv6 care-of addresses.=0A>> This=0A>>>>>>>> document pr= oposes extensions to the Mobile IPv6 protocol to=0A>> register=0A>>>>>>>> a= nd use multiple care-of addresses.=A0 The extensions=0A>> proposed in this= =0A>>>>>>>> document can be used by Mobile Routers using the NEMO (Network= =0A>>>>>>>> Mobility) Basic Support protocol as well.=0A>>>>>>>> =0A>>>>>>>= > A URL for this Internet-Draft is:=0A>>>>>>>> =0A>>>>>>> =0A>> http://www.= ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt=0A>>>>>>>> = =0A>>>>>>>> Internet-Drafts are also available by anonymous FTP at:=0A>>>>>= >>> ftp://ftp.ietf.org/internet-drafts/=0A>>>>>>>> =0A>>>>>>>> Below is the= data which will enable a MIME compliant mail=0A>> reader=0A>>>>>>>> implem= entation to automatically retrieve the ASCII version=0A>> of the=0A>>>>>>>>= Internet-Draft.=0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> =0A>>>>>>>> ___________= ____________________________________=0A>>>>>>>> MEXT mailing list=0A>>>>>>>= > MEXT@ietf.org > > =0A>> >>=0A>>>>>>>> https://www.ietf.org/mailma= n/listinfo/mext=0A>>>>>>> =0A>>>>>>> =0A>>>>>>> =0A>>>>>>> =0A>> ----------= --------------------------------------------------------------=0A>>>>>>> = =0A>>>>>>> _______________________________________________=0A>>>>>>> MEXT m= ailing list=0A>>>>>>> MEXT@ietf.org > >=0A>>>>>>> https://www.ietf.org/mailman/l= istinfo/mext=0A>>>>>> =0A>>>>>> ___________________________________________= ____=0A>>>>>> MEXT mailing list=0A>>>>>> MEXT@ietf.org > >=0A>>>>>> https://www.= ietf.org/mailman/listinfo/mext=0A>>>>>> =0A>>>>> =0A>>>>> =0A>>>> =0A>>>> _= ______________________________________________=0A>>>> MEXT mailing list=0A>= >>> MEXT@ietf.org > >=0A>>>> https://www.ietf.org/mailman/listinfo/mext=0A>>> = =0A>>> =0A>>> -------------------------------------------------------------= -----------=0A>>> =0A>>> _______________________________________________=0A= >>> MEXT mailing list=0A>>> MEXT@ietf.org =0A>>> http= s://www.ietf.org/mailman/listinfo/mext=0A>>> =0A>> =0A>> =0A> =0A> ________= _______________________________________=0A> MEXT mailing list=0A> MEXT@ietf= .org=0A> https://www.ietf.org/mailman/listinfo/mext=0A=0A=0A --0-1499292816-1240501512=:50587 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hesham, I don't think the text imposes on which interf= ace you connect to the home link, so MN is able to use any interface.
= =0A
 
=0A
What the text says, the interface used to conne= ct to the home interface is considered as the main interface as far as this= document is concerned.
=0A
 
=0A
Maybe we can clar= ify the main and auxiliary with "as far as this document is concerned".=0A
 
=0A
Regards,
=0A
 
=0A
Beh= cet
=0A

=0A
=0A
=0AFrom: Hesham Soliman &= lt;hesham@elevatemobile.com>
To:= marcelo bagnulo braun <marcelo@it.uc3m.es>; Behcet Sarika= ya <sarikaya@ieee.org>
Cc: mext <mext@ietf.org>
Sent: Thursday, April 23, 2009 5:17:59 AM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-ie= tf-monami6-multiplecoa-13.txt]

Such restriction makes no sens= e for the document. The MN has to be able to
use any interface.

= Hesham

> Behcet Sarikaya escribi=F3:
>> Hi Marcelo,
&= gt;>  How about this little paragraph?
>> 
>&g= t; In this document it is assumed that a multi-homed MN connects to the
= >> home link using only one interface. Therefore this interface
&g= t;> is considered as the main interface as identified by the home address
>= > assigned by the home agent.  The other or auxiliary interfaces ma= y
>> later on become active and connect to some other networks and= get
>> their care-of addresses and then the procedures defined in= this
>> document allow such care-of addresses to be registered wi= th the home
>> agent apart from the registration of the care-of ad= dresses assigned to
>> the main interface which is already defined= in RFC 3775.
>> Regards,
>> 
>> Behcet>> -----------------------------------------------------------------= -------
>> *From:* marcelo bagnulo braun <marcelo@it.uc3m.es>
>> *To:* Behcet Sarikaya <sarikaya@ieee.org>
>>= *Cc:* Ryuji Wakikawa <ryuji.wakikawa@gmail.com>; me= xt <me= xt@ietf.org>
>> *Sent:* Wednesday, April 22, 2009 4:59:50 P= M
>> *Subject:* Re: [MEXT] [Fwd: I-D
>> Action:draft-ietf= -monami6-multiplecoa-13.txt]
>>
>> Hi Bechet,
>>= ;
>> could you send exactly what text do you think needs to be ch= anged in
>> the MCOA draft, so the WG can evaluate and figure out = if the changes
>> are needed? (i.e. please send OLD text NEW text)=
>>
>> Please note that at this point in the life of the= document, we only
>> take changes that fix errors in the document= , rather than  getting
>> more features in.
>>
>> Regards, marcelo
>>
>>
>>
&g= t;> Behcet Sarikaya escribi=F3:
>>> Hi Ryuji,
>>>= ;  I checked your draft. Again, I could not understand how you are
= >> sending a registration BU at the home link as only an O-flag is>> defined in your draft which is used for something else.
>&g= t;>  As I mentioned to you, we discussed this related to
>>= ; draft-premec-homelink and it seems like HA will reject such a BU
>&= gt; unless something is done, I thought you were familiar with the
>&= gt; discussions as it relates to your draft too. I am surprised.
>>= ;>  Regards,
>>>  Behcet
>>>
>&= gt;> -------------------------------------------------------------------= -----
>>> *From:* Ryuji Wakikawa <ryuji.wakikawa@gmail.com>> <mailto:ryuji.wakikawa@gmail.com>>>>> *To:* Behcet Sarikaya <sarikaya@ieee.org <mailto:sar= ikaya@ieee.org>>
>>> *Cc:* George Tsirtsis <tsirtsis@googlemail.com
>> <mailto:tsirtsis= @googlemail.com>>; mext <mext@ietf.org
>> <mailto:mext@ietf.org>>
>>>= *Sent:* Wednesday, April 22, 2009 4:18:28 PM
>>> *Subject:* Re= : [MEXT] [Fwd: I-D
>> Action:draft-ietf-monami6-multiplecoa-13.txt= ]
>>>
>>> Hi Behcet,
>>>
>>&= gt; On 2009/04/22, at 11:31, Behcet Sarikaya wrote:
>>>
>= ;>>>
>>>>
>>>> From: George Tsirts= is <tsirtsis@googlemail.com
>> <mailto:tsirtsis@googlemail.com> <mailto:tsirtsis@googlem= ail.com
>> <mailto:tsirtsis@googlemail.com>= >>
>>>> To: Behcet Sarikaya <sarikaya@ieee.org &= lt;mailto:sarikaya@ieee.org>
>> <mailto:sarikaya@ieee.org<= /A> <mailto:sarikaya@ieee.org>>>
>>>> Cc: mex= t <mex= t@ietf.org <mailto:mext@ietf.org>
>> <mailto:mext@ietf.org <= mailto:mext@ietf.org>>>
>>= >> Sent: Wednesday, April 22, 2009 10:10:08 AM
>>>> Su= bject: Re: [MEXT] [Fwd: I-D
>> Action:draft-ietf-monami6-multiplec= oa-13.txt]
>>>>
>>>> I do not think that add= ing home link registration to RFC3775bis is
>> feasible.
>&g= t;>> This requires logic in the MN and HA that is not directly compat= ible
>>>> to RFC3775. The aim of RFC3775bis is to make minim= al changes for
>>>> clarification reasons and to correct err= ors. Home Link Registration as
>>>> defined in MCoA is neith= er.
>>>> [behcet] Why not? If it is needed in so many instan= ces, that
>> qualifies it to become a base protocol feature, at le= ast to me.
>>>
>>> We cannot add a new feature to = 3775. That is the ground rule of
>> -bis. The chairs can clarify this.
>>>
>>> regards,
>>> ry= uji
>>>
>>>
>>>
>>>> =
>>>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya
&g= t;>>> <behcetsarikaya@yahoo.com <mailto:behcetsarikaya@yahoo.com>
>> <mailto:behcetsarikaya@yahoo.com <mailto:behcetsarikaya@y= ahoo.com>>>
>> wrote:
>>>>> Hi Geor= ge,
>>>>>  It seems in my previous reply I replied t= o this mail of yours
>> which was
>>>>> unrelate= d to the other mail you sent to which I was really replying,
>>>>>= ; apologies.
>>>>>  Now regarding home link registra= tion, what is the mechanism
>> MCoA draft
>>>>> = uses? Ryuji mentioned some H bit but I read the draft and
>> could= n't confirm
>>>>> it.
>>>>>
>>= ;>>>  My suggestion was building on this, i.e. I suggested th= at
>> whatever you
>>>>> came up with can be mov= ed to 3775bis so that other people would
>> not have to
>>= ;>>> make normative references to your draft.
>>>>&= gt;
>>>>> That's all.
>>>>>
>&g= t;>>> Regards,
>>>>>
>>>>> Be= hcet
>>>>>
>>>>> _____________________= ___________
>>>>> From: George Tsirtsis <tsirtsis@googlemail.com
>> <mailto:tsir= tsis@googlemail.com> <mailto:tsirtsis@googlemail.com
>> <mailto:tsirtsis@googlemail.com>>>= ;
>>>>> To: Vijay Devarapalli <vijay@wichorus.com=
>> <mailto:vijay@wichorus.com> <mailto:vijay@wicho= rus.com
>> <mailto:vijay@wichorus.com>>>>>>>> Cc: Behcet Sarikaya <sarikaya@ieee.org
>= > <mailto:sarikaya@ieee.org> <mailto:sarikaya@ieee.org>> <mailto:sarikaya@ieee.org>>>; mext <mext@ietf.org>> <mailto:mext@ietf.org> <mailto:mext@ietf.org <mailto:mext@ietf.org>>>
>>= >>> Sent: Tuesday, April 21, 2009 2:14:55 PM
>>>>&g= t; Subject: Re: [MEXT] [Fwd: I-D
>> Action:draft-ietf-monami6-mult= iplecoa-13.txt]
>>>>>
>>>>> ...also wr= t the home link registration, I do not think what you
>>>>&g= t; suggest is necessary.
>>>>>
>>>>> A= s far as I see the other documents are informational, and they
>> = do not
>>>>> yet have a formal standing in the WG. If and= when they do, as
>>>>> Informational documents,  th= ey should not require normative
>> changes to
>>>>&= gt; anything. They should make sure what they describe (mostly
>>&= gt;>> implementation options in this case) are compatible not only wi= th
>>>>> RFC3775 but also with extensions to it, including Flow Bindings. .
>>>>>
>>>>>= ;
>>>>> Regards
>>>>> George
>&g= t;>>>
>>>>> On Tue, Apr 21, 2009 at 7:58 PM, Vi= jay Devarapalli
>> <vijay@wichorus.com <mailto:vijay@= wichorus.com>
>> <mailto:vijay@wichorus.com <mai= lto:vijay@wichorus.com>>>
>>>>> wrote:
&= gt;>>>>> Behcet,
>>>>>>
>>>= ;>>> Behcet Sarikaya wrote:
>>>>>>>
&g= t;>>>>>> *[behcet] Yes but each interface will appear to = HA as a
>> different device
>>>>>>> and HA need= s to assign a different HoA. Then MCoA problem
>> disappears.*
= >>>>>>> *So George is saying that this is avoided by s= ome virtual
>> interfaces so
>>>>>>> that = HA does not see each interface separately. *
>>>>>>>= ; *Is this explained anywhere in the draft?*
>>>>>>>= ; *If yes then I am OK.*
>>>>>>
>>>>&g= t;> The home agent does not care about the multiple interfaces on
>= ;> the mobile
>>>>>> node. It only sees the mobile = node as one entity and allocates
>> a home
>>>>>= > address to it. The multiple care-of addresses that the mobile
>&= gt; node has
>>>>>> will
>>>>>> b= e used by the home agent as tunnel end points. That is all..
>> So there is
>>>>>> no
>>&g= t;>>> issue.
>>>>>>
>>>>>&= gt; Vijay
>>>>>>
>>>>>>>>&= nbsp; Also I have a question to Ryuji: does this draft send a
>>&g= t;>>>> non-deregistration BU at the home link? If yes, is he fa= miliar
>> with the
>>>>>>> discussion goin= g on on this subject? This is another point of
>> confusion
>= ;>>>>>> for
>>>>>>> me.
>&g= t;>>>>>
>>>>>>> This has been discu= ssed for a long time in MEXT.
>>>>>>> who is famili= ar with which discussions? I don't know your
>> concern here.
&= gt;>>>>>>  *[behcet] So your answer is yes the draft= sends a
>> non-deregistration BU
>>>>>>> (kind of bulk registration) at the home= link.*
>>>>>>> *The discussion I mentioned was rel= ated to
>>>>>>> draft-premec-mext-extended-home-lin= k. This draft also sends
>>>>>>> non-deregistration= BU at the home link. So does a few more
>> drafts like
>>= ;>>>>> **draft-devarapalli-mext-mipv6-home-link.*
>>= ;>>>>>
>>>>>>> **
>>>&g= t;>>> *[behcet] You mentioned some bit is set but I could not
&= gt;> understand which.
>>>>>>> One idea is since= so many drafts need this, why not factor
>> this out and
>&= gt;>>>>> define whatever the mechanism to enable sending
= >> non-deregistration BU in
>>>>>>> 3775bis. = What do you think about that?*
>>>>>>>
>>>>>>> **
>>>>>>>
&g= t;>>>>>>>  Sorry if I am too  much confused<= BR>>>>>>>>> Please don't get me wrong, I am not try= ing to slow down the
>> progress
>>>>>>> o= f
>>>>>>> this document..
>>>>>&g= t;>
>>>>>>> sure, but please explain your issue= more precisely.
>>>>>>>
>>>>>&g= t;> thanks!
>>>>>>> ryuji
>>>>>= ;>>
>>>>>>>>
>>>>>>= >> Regards,
>>>>>>>>
>>>>&= gt;>>> Behcet
>>>>>>>> From: marcelo ba= gnulo braun <marcelo@it.uc3m.es
>> <mailto:m= arcelo@it.uc3m.es> <mailto:marcelo@it.uc3m.es
>> &l= t;mailto:marcelo@it.uc3m.es>>
>>>>>>> &l= t;mailto:marcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>
= >> <mailto:marcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es<= /A>>>>>
>>>>>>>> To: mext <mext@ietf.org <mailto:mext@ietf.o= rg>
>> <mailto:mext@ietf.org <mailto:mext@ietf.org>> <= ;mailto:m= ext@ietf.org
>> <mailto:mext@ietf.org> <mailto:mext@ietf.org>> <mailto:mext@ietf.org>>>>; Julien Laganier
>>&= gt;>>>> <julien.laganier.= ietf@googlemail.com
>> <mailto:julien.laganier.iet= f@googlemail.com>
>> <mailto:julien.laganier.ietf@googlemail.com
>> <mailto:julien.laganier.ietf@googlemail.com>&= gt;
>>>>>>> <mailto:julien.laganier..ietf@googlemail.com
>> <mailto:julien.laganier..ietf@googlemail.com= >
>> <mailto:julien.laganier..i= etf@googlemail.com
>> <mailto:julien.laganier..ietf@googlemail.com>>>>; Jari Arkk= o
>>>>>>> <jari.arkko@piuha.net <mai= lto:jari.arkko@piuha.net>
>> <mailto:jari.arkk= o@piuha.net <mailto:jari.arkko@piuha.net>>
>&g= t; <mailto:jari.arkko@piuha.net <mailto:jari.arkko@piuha.net>
&g= t;> <mailto:jari.arkko@piuha..net <mailto:jari.ark= ko@piuha.net>>>>
>>>>>>>> Sent: = Tuesday, April 21, 2009 11:03:05 AM
>>>>>>>> Sub= ject: [MEXT] [Fwd: I-D
>>>>>>> Action:draft-ietf-mo= nami6-multiplecoa-13.txt]
>>>>>>>>
>>&= gt;>>>>> We have this new version of the MCOA document that<= BR>>> addresses the
>>>>>>> comments received= , including IESG review comments.
>>>>>>>> To th= e best of my knowledge, the IESG is ok with the doc
>> and ready f= or
>>>>>>> publication..
>>>>>>>> I am planning to ask our= AD to move forward in a week or
>> so, so, if
>>>>= >>> you
>>>>>>> have comments on the docum= ent please provide them before the
>> 1st of may.
>>>&= gt;>>>>
>>>>>>>> Regards, marcelo>>>>>>>> (mcoa doc shepherd)
>>>>&= gt;>>>
>>>>>>>> -------- Mensaje origi= nal --------
>>>>>>>> Asunto:    [MEXT= ] I-D
>> Action:draft-ietf-monami6-multiplecoa-13.txt
>>&= gt;>>>>> Fecha:    Mon, 20 Apr 2009 08:30:01 -0700= (PDT)
>>>>>>>> De:    In= ternet-Drafts@ietf.org
>> <mailto:Internet-Drafts@ietf.org> <mailto:Interne= t-Drafts@ietf.org
>> <mailto:Internet-Drafts@i= etf.org>> <mailto:Internet-Drafts@ietf.org>> <mailto:Internet-Drafts@ietf.org> <mail= to:Internet-Drafts@ietf.org
>> <mailto:Internet-Drafts@ietf.org>>>
>>>>>>&= gt;> Para:    i-d-announce@ietf.org
>> <mailto:i-d-= announce@ietf.org> <mailto:i-d-announce@ietf.org
&g= t;> <mailto:i-d-announce@ietf.org>> <mailto:i-d-announce@ietf.org
>> <mailto:i-d-announce@ietf= .org> <mailto:i-d-announce@ietf.org
>> <ma= ilto:i-d-announce@ietf.org>>= >
>>>>>>>> CC:    mext@ietf.org <mail= to:mext@i= etf.org>
>> <mailto:mext@ietf..org <mailto:mext@ietf.org>&= gt; <mailto:mext@ietf.org
>> <mailto:mext@ietf.org> <mailto:mext@ietf.org= <mailto:mext@ietf.org>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> =
>>>>>>>> A New Internet-Draft is available from= the on-line
>> Internet-Drafts
>>>>>>> di= rectories.
>>>>>>>> This draft is a work item of= the Mobility EXTensions for
>> IPv6 Working
>>>>&g= t;>> Group of the IETF.
>>>>>>>>
>&= gt;>>>>>>
>>>>>>>>  &nbs= p; Title          : Multiple Care-of Addresses Reg= istration
>>>>>>>>    Author(s)  =     : R. Wakikawa, et al.
>>>>>>>>&nbs= p;   Filename        : draft-ietf-monami6-multiple= coa-13..txt
>>>>>>>>    Pages  &n= bsp;       : 44
>>>>>>>>    Date    &nbs= p;       : 2009-04-20
>>>>>>>> >>>>>>>> According to the current Mobile IPv6 spe= cification, a
>> mobile node may
>>>>>>>&g= t; have several care-of addresses, but only one, called the
>> pri= mary
>>>>>>>> care-of address, that can be regis= tered with its home agent
>> and the
>>>>>>&g= t;> correspondent nodes.  However, for matters of cost,
>>= bandwidth, delay,
>>>>>>>> etc, it is useful fo= r the mobile node to get Internet
>> access through
>>>= ;>>>>> multiple accesses simultaneously, in which case the m= obile
>> node would
>>>>>>>> be configu= red with multiple active IPv6 care-of addresses.
>> This
>>>>>>>> document proposes extensions to t= he Mobile IPv6 protocol to
>> register
>>>>>>= >> and use multiple care-of addresses.  The extensions
>&g= t; proposed in this
>>>>>>>> document can be use= d by Mobile Routers using the NEMO (Network
>>>>>>>= > Mobility) Basic Support protocol as well.
>>>>>>&= gt;>
>>>>>>>> A URL for this Internet-Draft = is:
>>>>>>>>
>>>>>>> >> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplec= oa-13.txt
>>>>>>>>
>>>>>>&= gt;> Internet-Drafts are also available by anonymous FTP at:
>>= >>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>= ;>>>>
>>>>>>>> Below is the data wh= ich will enable a MIME compliant mail
>> reader
>>>>= ;>>>> implementation to automatically retrieve the ASCII versio= n
>> of the
>>>>>>>> Internet-Draft.>>>>>>>>
>>>>>>>>
= >>>>>>>>
>>>>>>>> _____= __________________________________________
>>>>>>>&= gt; MEXT mailing list
>>>>>>>> MEXT@ietf.org <mail= to:MEXT@i= etf.org> <mailto:MEXT@ietf.org
>> <mailto:MEXT@ietf.o= rg>> <mailto:MEXT@ietf.org <mailto:MEXT@ietf.org>
>> <= mailto:ME= XT@ietf.org <mailto:MEXT@ietf.org>>>
>>>>>>= >> https://www.ietf.org/mailman/listinfo/mext
>>>>>= >>
>>>>>>>
>>>>>>> =
>>>>>>>
>> -----------------------------= -------------------------------------------
>>>>>>>=
>>>>>>> _______________________________________________
>>>>>>= ;> MEXT mailing list
>>>>>>> MEXT@ietf.org <mailto= :MEXT@iet= f.org> <mailto:MEXT@ietf.org
>> <mailto:MEXT@ietf.org>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext>>>>>>
>>>>>> ___________________= ____________________________
>>>>>> MEXT mailing list<= BR>>>>>>> MEXT@ietf.org <mailto:MEXT@ietf.org> <mailto:MEXT@ietf.org
>> <mailto:MEXT@ietf.org>>
>>>>>> https://w= ww.ietf.org/mailman/listinfo/mext
>>>>>>
>&= gt;>>>
>>>>>
>>>>
>>&= gt;> _______________________________________________
>>>>= MEXT mailing list
>>>> MEXT@ietf.org <mailto:MEXT@ietf.org> <= ;mailto:M= EXT@ietf.org
>> <mailto:MEXT@ietf..org>>
>>&g= t;> https://www.ietf.org/mailman/listinfo/mext
>>>
>&= gt;>
>>> --------------------------------------------------= ----------------------
>>>
>>> ___________________= ____________________________
>>> MEXT mailing list
>>&= gt; MEXT@= ietf.org <mailto:MEXT@ietf.org>
>>> https://www.ietf.org/mailm= an/listinfo/mext
>>>
>>
>>
> > _______________________________________________
> MEXT mailing = list
> MEXT@ietf.org
> https://www.ietf.or= g/mailman/listinfo/mext



=0A=0A --0-1499292816-1240501512=:50587-- From behcetsarikaya@yahoo.com Thu Apr 23 08:46:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92CAD28C51B for ; Thu, 23 Apr 2009 08:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 Ta9teJ8qR3MR for ; Thu, 23 Apr 2009 08:46:38 -0700 (PDT) Received: from n61a.bullet.mail.sp1.yahoo.com (n61a.bullet.mail.sp1.yahoo.com [98.136.45.8]) by core3.amsl.com (Postfix) with SMTP id 3576D28C138 for ; Thu, 23 Apr 2009 08:46:36 -0700 (PDT) Received: from [216.252.122.217] by n61.bullet.mail.sp1.yahoo.com with NNFMP; 23 Apr 2009 15:47:54 -0000 Received: from [67.195.9.83] by t2.bullet.sp1.yahoo.com with NNFMP; 23 Apr 2009 15:47:54 -0000 Received: from [67.195.9.110] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 23 Apr 2009 15:47:54 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 23 Apr 2009 15:45:40 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 762048.45095.bm@omp114.mail.gq1.yahoo.com Received: (qmail 17738 invoked by uid 60001); 23 Apr 2009 15:47:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240501673; bh=Z3Ig3xbJ/hs8A7L/R+GOP70LI4R/bgfNtO44GUXWjto=; 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=pKbLaso/9lYOeEWL8IosC6WkMnuMnmklRnGctuqRD0Wl3neToDwSVHpGI+0iq/J/cL8/LcXPSWlB2HN8zZR5IvTmUHXpOa/jFbs/ie0F6qP6a2dvQLfbdRldmPdUtMnzb3EOvLe+jJAmA+rz0K4SzmMCpOQ9I5oEnBVMuxhAtiM= 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=BYfOofD4ndvMuy5rndjEh/2/OpS3/MgkUZMrDww4+75L/HkiMHAqCqL01y+xrasCalqPGzbmbG5Tk7cRJ92pwf3+5FwMUOIQzJiz9oy4Ty9U8PvXxf8E040vBwA0tJn2EZMAitBbH/FcKIJ8Qc7F/TbUT68iPfWKIxjr47+n6XY=; Message-ID: <818951.16650.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: JqD8c9cVM1nSt6QiRJajsn.KMoRkt2207y9.YcATj0BWhD2j_IRgndxhqMXUDKnH5vmWJZhU2HmDqYtNeRianhHzm9.cL2ef64AhKgbwLC_YW7rHsl7MyIx9Gs8RSNGopxvVmYYPMLV6rOOZkDHKVn4mehA4Kc1pEC7gknEOf6Gk4DNjR8lFW6eJ0A1ngRVhvmuk1fefLiMKr7nJKQMHQfJs.Xira2SramulLINAwzjsmR.sBU3dhz9zmz1yTxOK00A6wYOYgs31jeEpG2AtLD5Cifpu2jF7AGXgsj2sMdT4Xg8QW7h33dp80j2gsb1ELVyF Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Thu, 23 Apr 2009 08:47:53 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <473113.45048.qm@web111406.mail.gq1.yahoo.com> Date: Thu, 23 Apr 2009 08:47:53 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis , Vijay Devarapalli In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-551930818-1240501673=:16650" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:46:40 -0000 --0-551930818-1240501673=:16650 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi George,=0A=A0 The problem was exactly many interfaces connecting to the = home link.=0AIf that happens you agreed that a different prefix has to be a= ssigned to each prefix and this requires many changes in MCoA draft.=0A=0AY= ou want to go ahead with this or with the proposed text?=0A=0ARegards,=0A= =0ABehcet=0A=0A=0A=0A=0A________________________________=0AFrom: George Tsi= rtsis =0ATo: Vijay Devarapalli =0ACc: Behcet Sarikaya ; marcelo bagnulo braun ; mext =0ASent: Thursday, April 23, 2009 3:41:27= AM=0ASubject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-1= 3.txt]=0A=0AI also disagree... there is not such thing as a 'main' interfac= e and=0Athere is no restriction on how many interfaces are connected to the= =0Ahome link, or whether aninterface connected on the home link then goes= =0Aahead is moved from the home link to a foreign link.=0A=0AGeorge=0A=0AOn= Thu, Apr 23, 2009 at 12:43 AM, Vijay Devarapalli wrot= e:=0A> Hi Bechet,=0A>=0A> On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote:=0A>= =0A>> Hi Marcelo,=0A>> =A0 How about this little paragraph?=0A>>=0A>> In th= is document it is assumed that a multi-homed MN connects to the home link= =0A>> using only one interface. Therefore this interface is considered as t= he main=0A>> interface as identified by the home address assigned by the ho= me agent.=0A>=0A> I disagree with this. The mobile node can connect to the = home link through=0A> any one of its interfaces.=0A>=0A>> The=0A>> other or= auxiliary interfaces may later on become active and connect to some=0A>> o= ther networks and get their care-of addresses and then the procedures defin= ed=0A>> in this document allow such care-of addresses to be registered with= the home=0A>> agent apart from the registration of the care-of addresses a= ssigned to the=0A>> main interface which is already defined in RFC 3775.=0A= >=0A> There is no need for the home agent to identify one of the interfaces= as a=0A> "main" interface.=0A>=0A> Vijay=0A>=0A>> Regards,=0A>>=0A>> Behce= t=0A>>=0A>> From: marcelo bagnulo braun =0A>> To: Behce= t Sarikaya =0A>> Cc: Ryuji Wakikawa ; mext =0A>> Sent: Wednesday, April 22, 2009 4:59:50 P= M=0A>> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-= 13.txt]=0A>>=0A>> Hi Bechet,=0A>>=0A>> could you send exactly what text do = you think needs to be changed in the MCOA=0A>> draft, so the WG can evaluat= e and figure out if the changes are needed? (i.e.=0A>> please send OLD text= NEW text)=0A>>=0A>> Please note that at this point in the life of the docu= ment, we only take=0A>> changes that fix errors in the document, rather tha= n =A0getting more features=0A>> in.=0A>>=0A>> Regards, marcelo=0A>>=0A>>=0A= >>=0A>> Behcet Sarikaya escribi=F3:=0A>>> Hi Ryuji,=0A>>> =A0I checked your= draft. Again, I could not understand how you are sending a=0A>>> registrat= ion BU at the home link as only an O-flag is defined in your draft=0A>>> wh= ich is used for something else.=0A>>> =A0As I mentioned to you, we discusse= d this related to draft-premec-homelink=0A>>> and it seems like HA will rej= ect such a BU unless something is done, I=0A>>> thought you were familiar w= ith the discussions as it relates to your draft=0A>>> too. I am surprised.= =0A>>> =A0Regards,=0A>>> =A0Behcet=0A>>>=0A>>> ----------------------------= --------------------------------------------=0A>>> *From:* Ryuji Wakikawa <= ryuji.wakikawa@gmail.com>=0A>>> *To:* Behcet Sarikaya = =0A>>> *Cc:* George Tsirtsis ; mext =0A>>> *Sent:* Wednesday, April 22, 2009 4:18:28 PM=0A>>> *Subject:* Re: [= MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A>>>=0A>>> H= i Behcet,=0A>>>=0A>>> On 2009/04/22, at 11:31, Behcet Sarikaya wrote:=0A>>>= =0A>>>>=0A>>>>=0A>>>> From: George Tsirtsis >>>= >=0A>>>> To: Behcet Sarikaya >=0A>>>> Cc: mext >=0A>>>> Sent: Wednesday, April 22, 2009 10:10:08 AM=0A>>>> Sub= ject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A= >>>>=0A>>>> I do not think that adding home link registration to RFC3775bis= is feasible.=0A>>>> This requires logic in the MN and HA that is not direc= tly compatible=0A>>>> to RFC3775. The aim of RFC3775bis is to make minimal = changes for=0A>>>> clarification reasons and to correct errors. Home Link R= egistration as=0A>>>> defined in MCoA is neither.=0A>>>> [behcet] Why not? = If it is needed in so many instances, that qualifies it to=0A>>>> become a = base protocol feature, at least to me.=0A>>>=0A>>> We cannot add a new feat= ure to 3775. That is the ground rule of -bis. The=0A>>> chairs can clarify = this.=0A>>>=0A>>> regards,=0A>>> ryuji=0A>>>=0A>>>=0A>>>=0A>>>>=0A>>>> On W= ed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya=0A>>>> > wrote:=0A>>>>> Hi George,=0A>>>>> =A0= It seems in my previous reply I replied to this mail of yours which was=0A>= >>>> unrelated to the other mail you sent to which I was really replying,= =0A>>>>> apologies.=0A>>>>> =A0Now regarding home link registration, what i= s the mechanism MCoA draft=0A>>>>> uses? Ryuji mentioned some H bit but I r= ead the draft and couldn't confirm=0A>>>>> it.=0A>>>>>=0A>>>>> =A0My sugges= tion was building on this, i.e. I suggested that whatever you=0A>>>>> came = up with can be moved to 3775bis so that other people would not have to=0A>>= >>> make normative references to your draft.=0A>>>>>=0A>>>>> That's all.=0A= >>>>>=0A>>>>> Regards,=0A>>>>>=0A>>>>> Behcet=0A>>>>>=0A>>>>> _____________= ___________________=0A>>>>> From: George Tsirtsis >>>> >=0A>>>>> To: Vijay Devarapalli >=0A>>>>> Cc: Behcet Sarikaya = >; mext=0A>>>>> >=0A>>>>> Sent: Tuesday, April 21, 2009 2:14:55 PM= =0A>>>>> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multipleco= a-13.txt]=0A>>>>>=0A>>>>> ...also wrt the home link registration, I do not = think what you=0A>>>>> suggest is necessary.=0A>>>>>=0A>>>>> As far as I se= e the other documents are informational, and they do not=0A>>>>> yet have a= formal standing in the WG. If and when they do, as=0A>>>>> Informational d= ocuments, =A0they should not require normative changes to=0A>>>>> anything.= They should make sure what they describe (mostly=0A>>>>> implementation op= tions in this case) are compatible not only with=0A>>>>> RFC3775 but also w= ith extensions to it, including Flow Bindings. .=0A>>>>>=0A>>>>>=0A>>>>> Re= gards=0A>>>>> George=0A>>>>>=0A>>>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay= Devarapalli >>>> >=0A>>>= >> wrote:=0A>>>>>> Behcet,=0A>>>>>>=0A>>>>>> Behcet Sarikaya wrote:=0A>>>>>= >>=0A>>>>>>> *[behcet] Yes but each interface will appear to HA as a differ= ent device=0A>>>>>>> and HA needs to assign a different HoA. Then MCoA prob= lem disappears.*=0A>>>>>>> *So George is saying that this is avoided by som= e virtual interfaces so=0A>>>>>>> that HA does not see each interface separ= ately. *=0A>>>>>>> *Is this explained anywhere in the draft?*=0A>>>>>>> *If= yes then I am OK.*=0A>>>>>>=0A>>>>>> The home agent does not care about th= e multiple interfaces on the mobile=0A>>>>>> node. It only sees the mobile = node as one entity and allocates a home=0A>>>>>> address to it. The multipl= e care-of addresses that the mobile node has=0A>>>>>> will=0A>>>>>> be used= by the home agent as tunnel end points. That is all.. So there is=0A>>>>>>= no=0A>>>>>> issue.=0A>>>>>>=0A>>>>>> Vijay=0A>>>>>>=0A>>>>>>>> =A0Also I h= ave a question to Ryuji: does this draft send a=0A>>>>>>> non-deregistratio= n BU at the home link? If yes, is he familiar with the=0A>>>>>>> discussion= going on on this subject? This is another point of confusion=0A>>>>>>> for= =0A>>>>>>> me.=0A>>>>>>>=0A>>>>>>> This has been discussed for a long time = in MEXT.=0A>>>>>>> who is familiar with which discussions? I don't know you= r concern here.=0A>>>>>>> =A0*[behcet] So your answer is yes the draft send= s a non-deregistration BU=0A>>>>>>> (kind of bulk registration) at the home= link.*=0A>>>>>>> *The discussion I mentioned was related to=0A>>>>>>> draf= t-premec-mext-extended-home-link. This draft also sends=0A>>>>>>> non-dereg= istration BU at the home link. So does a few more drafts like=0A>>>>>>> **d= raft-devarapalli-mext-mipv6-home-link.*=0A>>>>>>>=0A>>>>>>> **=0A>>>>>>> *[= behcet] You mentioned some bit is set but I could not understand which.=0A>= >>>>>> One idea is since so many drafts need this, why not factor this out = and=0A>>>>>>> define whatever the mechanism to enable sending non-deregistr= ation BU in=0A>>>>>>> 3775bis. What do you think about that?*=0A>>>>>>>=0A>= >>>>>> **=0A>>>>>>>=0A>>>>>>>> =A0Sorry if I am too =A0much confused=0A>>>>= >>>> Please don't get me wrong, I am not trying to slow down the progress= =0A>>>>>>> of=0A>>>>>>> this document..=0A>>>>>>>=0A>>>>>>> sure, but pleas= e explain your issue more precisely.=0A>>>>>>>=0A>>>>>>> thanks!=0A>>>>>>> = ryuji=0A>>>>>>>=0A>>>>>>>>=0A>>>>>>>> Regards,=0A>>>>>>>>=0A>>>>>>>> Behcet= =0A>>>>>>>> From: marcelo bagnulo braun >>>>>>> =0A>>>>>>> >>=0A>>>>>>>> To: mext <= mailto:mext@ietf.org=0A>>>>>>>> >>; Julien Laganier= =0A>>>>>>> >>>>>> =0A>>>>>>> >>>>>> >>; Jari Ark= ko=0A>>>>>>> =0A>>>>>>> = >>>>>> >>>=0A>>>>>>>> Sent: Tuesday, April 21, 2009 11:03:= 05 AM=0A>>>>>>>> Subject: [MEXT] [Fwd: I-D=0A>>>>>>> Action:draft-ietf-mona= mi6-multiplecoa-13.txt]=0A>>>>>>>>=0A>>>>>>>> We have this new version of t= he MCOA document that addresses the=0A>>>>>>> comments received, including = IESG review comments.=0A>>>>>>>> To the best of my knowledge, the IESG is o= k with the doc and ready for=0A>>>>>>> publication..=0A>>>>>>>> I am planni= ng to ask our AD to move forward in a week or so, so, if=0A>>>>>>> you=0A>>= >>>>> have comments on the document please provide them before the 1st of m= ay.=0A>>>>>>>>=0A>>>>>>>> Regards, marcelo=0A>>>>>>>> (mcoa doc shepherd)= =0A>>>>>>>>=0A>>>>>>>> -------- Mensaje original --------=0A>>>>>>>> Asunto= : =A0 =A0[MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt=0A>>>>>>>>= Fecha: =A0 =A0Mon, 20 Apr 2009 08:30:01 -0700 (PDT)=0A>>>>>>>> De: =A0 =A0= Internet-Drafts@ietf.org =0A>>>>>>>> >=0A>>>>>>>> P= ara: =A0 =A0i-d-announce@ietf.org =0A>>>>>>>>= >=0A>>>>>>>> C= C: =A0 =A0mext@ietf.org >=0A>= >>>>>>> >=0A>>>>>>>>=0A>>>>>>>>= =0A>>>>>>>>=0A>>>>>>>> A New Internet-Draft is available from the on-line I= nternet-Drafts=0A>>>>>>> directories.=0A>>>>>>>> This draft is a work item = of the Mobility EXTensions for IPv6 Working=0A>>>>>>> Group of the IETF.=0A= >>>>>>>>=0A>>>>>>>>=0A>>>>>>>> =A0 =A0Title =A0 =A0 =A0 =A0 =A0: Multiple C= are-of Addresses Registration=0A>>>>>>>> =A0 =A0Author(s) =A0 =A0 =A0: R. W= akikawa, et al.=0A>>>>>>>> =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mona= mi6-multiplecoa-13..txt=0A>>>>>>>> =A0 =A0Pages =A0 =A0 =A0 =A0 =A0: 44=0A>= >>>>>>> =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-04-20=0A>>>>>>>>=0A>>>>>>= >> According to the current Mobile IPv6 specification, a mobile node may=0A= >>>>>>>> have several care-of addresses, but only one, called the primary= =0A>>>>>>>> care-of address, that can be registered with its home agent and= the=0A>>>>>>>> correspondent nodes. =A0However, for matters of cost, bandw= idth, delay,=0A>>>>>>>> etc, it is useful for the mobile node to get Intern= et access through=0A>>>>>>>> multiple accesses simultaneously, in which cas= e the mobile node would=0A>>>>>>>> be configured with multiple active IPv6 = care-of addresses. =A0This=0A>>>>>>>> document proposes extensions to the M= obile IPv6 protocol to register=0A>>>>>>>> and use multiple care-of address= es. =A0The extensions proposed in this=0A>>>>>>>> document can be used by M= obile Routers using the NEMO (Network=0A>>>>>>>> Mobility) Basic Support pr= otocol as well.=0A>>>>>>>>=0A>>>>>>>> A URL for this Internet-Draft is:=0A>= >>>>>>>=0A>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-mu= ltiplecoa-13.txt=0A>>>>>>>>=0A>>>>>>>> Internet-Drafts are also available b= y anonymous FTP at:=0A>>>>>>>> ftp://ftp.ietf.org/internet-drafts/=0A>>>>>>= >>=0A>>>>>>>> Below is the data which will enable a MIME compliant mail rea= der=0A>>>>>>>> implementation to automatically retrieve the ASCII version o= f the=0A>>>>>>>> Internet-Draft.=0A>>>>>>>>=0A>>>>>>>>=0A>>>>>>>>=0A>>>>>>>= > _______________________________________________=0A>>>>>>>> MEXT mailing l= ist=0A>>>>>>>> MEXT@ietf.org >>>>>>> >=0A>>>>>>>> https://www.ietf.org/mailman= /listinfo/mext=0A>>>>>>>=0A>>>>>>>=0A>>>>>>>=0A>>>>>>> --------------------= ----------------------------------------------------=0A>>>>>>>=0A>>>>>>> __= _____________________________________________=0A>>>>>>> MEXT mailing list= =0A>>>>>>> MEXT@ietf.org =0A>>>>>>> https://www.ietf.= org/mailman/listinfo/mext=0A>>>>>>=0A>>>>>> _______________________________= ________________=0A>>>>>> MEXT mailing list=0A>>>>>> MEXT@ietf.org =0A>>>>>> https://www.ietf.org/mailman/listinfo/mext=0A>>>>>>= =0A>>>>>=0A>>>>>=0A>>>>=0A>>>> ____________________________________________= ___=0A>>>> MEXT mailing list=0A>>>> MEXT@ietf.org >=0A>>>> https://www.ietf.org/mailman/listinfo/mext=0A= >>>=0A>>>=0A>>> -----------------------------------------------------------= -------------=0A>>>=0A>>> _______________________________________________= =0A>>> MEXT mailing list=0A>>> MEXT@ietf.org=0A>>> https://www.ietf.org/mai= lman/listinfo/mext=0A>>>=0A>>=0A>>=0A>>=0A>>=0A>> _________________________= ______________________=0A>> MEXT mailing list=0A>> MEXT@ietf.org=0A>> https= ://www.ietf.org/mailman/listinfo/mext=0A>=0A> _____________________________= __________________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.= ietf.org/mailman/listinfo/mext=0A>=0A=0A=0A=0A --0-551930818-1240501673=:16650 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi George,
=0A
  The problem was exactly= many interfaces connecting to the home link.
=0A
If that happens = you agreed that a different prefix has to be assigned to each prefix and th= is requires many changes in MCoA draft.
=0A
 
=0A
Yo= u want to go ahead with this or with the proposed text?
=0A
 =
=0A
Regards,
=0A
 
=0A
Behcet
=0A=

=0A
=0A
=0AFrom: George Tsirtsis <tsirtsis@goo= glemail.com>
To: Vija= y Devarapalli <vijay@wichorus.com>
Cc: Behcet Sarikaya <sarikaya@ieee.org>; marcelo bag= nulo braun <marcelo@it.uc3m.es>; mext <mext@ietf.org>
Sent: Thursday, April 23, 2009 3:= 41:27 AM
Subject: Re: [M= EXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]

= I also disagree... there is not such thing as a 'main' interface and
the= re is no restriction on how many interfaces are connected to the
home li= nk, or whether aninterface connected on the home link then goes
ahead is= moved from the home link to a foreign link.

George

On Thu, A= pr 23, 2009 at 12:43 AM, Vijay Devarapalli <v= ijay@wichorus.com> wrote:
> Hi Bechet,
>
> On 4/22= /09 4:07 PM, "Behcet Sarikaya" wrote:
>
>> Hi Marcelo,
&g= t;>   How about this little paragraph?
>>
>> In t= his document it is assumed that a multi-homed MN connects to the home link<= BR>>> using only one interface. Therefore this interface is considere= d as the main
>> interface as identified by the home address assig= ned by the home agent.
>
> I disagree with this. The mobile nod= e can connect to the home link through
> any one of its interfaces.>
>> The
>> other or auxiliary interfaces may later = on become active and connect to some
>> other networks and get the= ir care-of addresses and then the procedures defined
>> in this do= cument allow such care-of addresses to be registered with the home
>> agent apart from the registration of the care-of addresse= s assigned to the
>> main interface which is already defined in RF= C 3775.
>
> There is no need for the home agent to identify one= of the interfaces as a
> "main" interface.
>
> Vijay
= >
>> Regards,
>>
>> Behcet
>>
>= ;> From: marcelo bagnulo braun <marcelo@it.uc3m.es>
>&g= t; To: Behcet Sarikaya <sarikaya@ieee.org>
>> Cc: Ryuji W= akikawa <ryuji.wakikawa@gmail.com>; mext <mext@ietf.org>
>> Sent: Wednesday, April 22, 2009 4:59:50 PM
>> Su= bject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
>= >
>> Hi Bechet,
>>
>> could you send exactly = what text do you think needs to be changed in the MCOA
>> draft, s= o the WG can evaluate and figure out if the changes are needed? (i.e.
&g= t;> please send OLD text NEW text)
>>
>> Please note t= hat at this point in the life of the document, we only take
>> cha= nges that fix errors in the document, rather than  getting more featur= es
>> in.
>>
>> Regards, marcelo
>>
= >>
>>
>> Behcet Sarikaya escribi=F3:
>>>= ; Hi Ryuji,
>>>  I checked your draft. Again, I could not = understand how you are sending a
>>> registration BU at the hom= e link as only an O-flag is defined in your draft
>>> which is = used for something else.
>>>  As I mentioned to you, we discussed this related to draft-premec-homelink
>>> and it = seems like HA will reject such a BU unless something is done, I
>>= > thought you were familiar with the discussions as it relates to your d= raft
>>> too. I am surprised.
>>>  Regards,>>>  Behcet
>>>
>>> ----------------= --------------------------------------------------------
>>> *F= rom:* Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
&= gt;>> *To:* Behcet Sarikaya <sarikaya@ieee.org>
>>&= gt; *Cc:* George Tsirtsis <tsirtsis@googlemail.com>; m= ext <mext@ietf.org>
>>> *Se= nt:* Wednesday, April 22, 2009 4:18:28 PM
>>> *Subject:* Re: [M= EXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>= ;
>>> Hi Behcet,
>>>
>>> On 2009/04/22,= at 11:31, Behcet Sarikaya wrote:
>>>
>>>>
&g= t;>>>
>>>> From: George Tsirtsis <tsi= rtsis@googlemail.com
>>>> <mailto:tsirtsis= @googlemail.com>>
>>>> To: Behcet Sarikaya <sari= kaya@ieee.org <mailto:sarikaya@ieee.org>>
>>>= > Cc: mext <mext= @ietf.org <mailto:mext@ietf.org>>
>>>> Sent: Wednesd= ay, April 22, 2009 10:10:08 AM
>>>> Subject: Re: [MEXT] [Fwd= : I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>
= >>>> I do not think that adding home link registration to RFC37= 75bis is feasible.
>>>> This requires logic in the MN and HA= that is not directly compatible
>>>> to RFC3775. The aim of= RFC3775bis is to make minimal changes for
>>>> clarificatio= n reasons and to correct errors. Home Link Registration as
>>>&= gt; defined in MCoA is neither.
>>>> [behcet] Why not? If it= is needed in so many instances, that qualifies it to
>>>> b= ecome a base protocol feature, at least to me.
>>>
>>> We cannot add a new feature to 3775. T= hat is the ground rule of -bis. The
>>> chairs can clarify this= ..
>>>
>>> regards,
>>> ryuji
>>= ;>
>>>
>>>
>>>>
>>>&g= t; On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya
>>>> <= ;behcetsarikaya@yahoo.com <mailto:behcetsa= rikaya@yahoo.com>> wrote:
>>>>> Hi George,
&= gt;>>>>  It seems in my previous reply I replied to this m= ail of yours which was
>>>>> unrelated to the other mail = you sent to which I was really replying,
>>>>> apologies.=
>>>>>  Now regarding home link registration, what i= s the mechanism MCoA draft
>>>>> uses? Ryuji mentioned som= e H bit but I read the draft and couldn't confirm
>>>>> i= t.
>>>>>
>>>>>  My suggestion was = building on this, i.e. I suggested that whatever you
>>>>>= ; came up with can be moved to 3775bis so that other people would not have = to
>>>>> make normative references to your draft.
>= >>>>
>>>>> That's all.
>>>>>= ;
>>>>> Regards,
>>>>>
>>>&= gt;> Behcet
>>>>>
>>>>> ____________= ____________________
>>>>> From: George Tsirtsis <tsirtsis@googlemail.com
>>>>> <mailto:tsirtsis@googlemail.com>= >
>>>>> To: Vijay Devarapalli <vijay@wichorus.com<= /A> <mailto:vijay@wichorus.com>>
>>>>> Cc: = Behcet Sarikaya <sarikaya@ieee.org <mailto:sarikaya@ieee.org>= ;>; mext
>>>>> <mext@ietf.org <mailto:mext@ietf.org>>= ;
>>>>> Sent: Tuesday, April 21, 2009 2:14:55 PM
>&= gt;>>> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>>
&= gt;>>>> ...also wrt the home link registration, I do not think = what you
>>>>> suggest is necessary.
>>>>&= gt;
>>>>> As far as I see the other documents are informa= tional, and they do not
>>>>> yet have a formal standing = in the WG. If and when they do, as
>>>>> Informational do= cuments,  they should not require normative changes to
>>>= >> anything. They should make sure what they describe (mostly
>= >>>> implementation options in this case) are compatible not on= ly with
>>>>> RFC3775 but also with extensions to it, inc= luding Flow Bindings. .
>>>>>
>>>>>
= >>>>> Regards
>>>>> George
>>>= >>
>>>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli <vijay@wichorus.com
>>>>> <= mailto:vijay@wichorus.com>>
>>>>> wrote:
&g= t;>>>>> Behcet,
>>>>>>
>>>&= gt;>> Behcet Sarikaya wrote:
>>>>>>>
>&= gt;>>>>> *[behcet] Yes but each interface will appear to HA = as a different device
>>>>>>> and HA needs to assig= n a different HoA. Then MCoA problem disappears.*
>>>>>&g= t;> *So George is saying that this is avoided by some virtual interfaces= so
>>>>>>> that HA does not see each interface sep= arately. *
>>>>>>> *Is this explained anywhere in t= he draft?*
>>>>>>> *If yes then I am OK.*
>>>>>>
>>>>>> The home agen= t does not care about the multiple interfaces on the mobile
>>>= >>> node. It only sees the mobile node as one entity and allocates= a home
>>>>>> address to it. The multiple care-of add= resses that the mobile node has
>>>>>> will
>>= ;>>>> be used by the home agent as tunnel end points. That is a= ll.. So there is
>>>>>> no
>>>>>>= issue.
>>>>>>
>>>>>> Vijay
&g= t;>>>>>
>>>>>>>>  Also I hav= e a question to Ryuji: does this draft send a
>>>>>>&g= t; non-deregistration BU at the home link? If yes, is he familiar with the<= BR>>>>>>>> discussion going on on this subject? This i= s another point of confusion
>>>>>>> for
>>>>>>> me.
>>>>>>>>>>>>>> This has been discussed for a long time in ME= XT.
>>>>>>> who is familiar with which discussions?= I don't know your concern here.
>>>>>>>  *[be= hcet] So your answer is yes the draft sends a non-deregistration BU
>= >>>>>> (kind of bulk registration) at the home link.*
= >>>>>>> *The discussion I mentioned was related to
= >>>>>>> draft-premec-mext-extended-home-link. This dra= ft also sends
>>>>>>> non-deregistration BU at the = home link. So does a few more drafts like
>>>>>>> *= *draft-devarapalli-mext-mipv6-home-link.*
>>>>>>>>>>>>>> **
>>>>>>> *[behcet]= You mentioned some bit is set but I could not understand which.
>>>>>>> One idea is since so many drafts ne= ed this, why not factor this out and
>>>>>>> define= whatever the mechanism to enable sending non-deregistration BU in
>&= gt;>>>>> 3775bis. What do you think about that?*
>>= >>>>>
>>>>>>> **
>>>>= >>>
>>>>>>>>  Sorry if I am too &n= bsp;much confused
>>>>>>>> Please don't get me w= rong, I am not trying to slow down the progress
>>>>>>= > of
>>>>>>> this document..
>>>>= >>>
>>>>>>> sure, but please explain your = issue more precisely.
>>>>>>>
>>>>&g= t;>> thanks!
>>>>>>> ryuji
>>>>>>>
>>>>>>>><= BR>>>>>>>>> Regards,
>>>>>>>= ;>
>>>>>>>> Behcet
>>>>>>= ;>> From: marcelo bagnulo braun <marcelo@it.uc3m.es
>&g= t;>>>>>> <mailto:marcelo@it.uc3m.es>
>&g= t;>>>>> <mailto:marcelo@it.uc3m.es <mailto:marce= lo@it.uc3m.es>>>
>>>>>>>> To: mext = <mext@= ietf.org <mailto:mext@ietf.org> <mailto:mext@ietf.org
>>>>>>>> <mailto:mext@ietf.org>>>; Juli= en Laganier
>>>>>>> <julien.laganier.ietf@googlemail.com
>>>>>>= > <mailto:julien.laganier.ietf@goo= glemail.com>
>>>>>>> <mailto:julien.laganier..ietf@googlemail.com
>&g= t;>>>>> <mailto:julien.laganier..i= etf@googlemail.com>>>; Jari Arkko
>>>>>>&= gt; <jari.arkko@piuha.net <mailto:jari.arkko@piuha.net<= /A>>
>>>>>>> <mailto:jari.arkko@piuha.ne= t <mailto:jari.arkko@piuha..net
>>>>>&g= t;> <mailto:jari.arkko@piuha.net> >>>
>>= ;>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM
>= >>>>>>> Subject: [MEXT] [Fwd: I-D
>>>>&= gt;>> Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>>>&= gt;>
>>>>>>>> We have this new version of the= MCOA document that addresses the
>>>>>>> comments = received, including IESG review comments.
>>>>>>>&g= t; To the best of my knowledge, the IESG is ok with the doc and ready for>>>>>>> publication..
>>>>>>>= ;> I am planning to ask our AD to move forward in a week or so, so, if>>>>>>> you
>>>>>>> have com= ments on the document please provide them before the 1st of may.
>>= ;>>>>>>
>>>>>>>> Regards, marc= elo
>>>>>>>> (mcoa doc shepherd)
>>>= >>>>>
>>>>>>>> -------- Mensaje o= riginal --------
>>>>>>>> Asunto:    [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt
>>&= gt;>>>>> Fecha:    Mon, 20 Apr 2009 08:30:01 -0700= (PDT)
>>>>>>>> De:    In= ternet-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org= >
>>>>>>>> <mailto:Intern= et-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org= >>
>>>>>>>> Para:    i-d-= announce@ietf.org <mailto:i-d-announce@ietf.org>
= >>>>>>>> <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>>
>>>>&g= t;>>> CC:    mext@ietf.org <mailto:mext@ietf..org <mailto:= mext@ietf= ..org> >
>>>>>>>> <mailto:mext@ietf.org &= lt;mailto:mext@ietf.org>>
>>>= >>>>>
>>>>>>>>
>>>>= ;>>>>
>>>>>>>> A New Internet-Draft = is available from the on-line Internet-Drafts
>>>>>>&g= t; directories.
>>>>>>>> This draft is a work it= em of the Mobility EXTensions for IPv6 Working
>>>>>>&= gt; Group of the IETF.
>>>>>>>>
>>>&= gt;>>>>
>>>>>>>>    Title =          : Multiple Care-of Addresses Registration=
>>>>>>>>    Author(s)     &= nbsp;: R. Wakikawa, et al.
>>>>>>>>    = ;Filename        : draft-ietf-monami6-multiplecoa-13..t= xt
>>>>>>>>    Pages          : 44
>>>>>>>>  =  Date            : 2009-04-20
>&g= t;>>>>>>
>>>>>>>> According to= the current Mobile IPv6 specification, a mobile node may
>>>&g= t;>>>> have several care-of addresses, but only one, called the= primary
>>>>>>>> care-of address, that can be r= egistered with its home agent and the
>>>>>>>> c= orrespondent nodes.  However, for matters of cost, bandwidth, delay,>>>>>>>> etc, it is useful for the mobile node to= get Internet access through
>>>>>>>> multiple a= ccesses simultaneously, in which case the mobile node would
>>>= >>>>> be configured with multiple active IPv6 care-of addres= ses.  This
>>>>>>>> document proposes extensions to the Mobile IPv6 protocol to register
>>>= ;>>>>> and use multiple care-of addresses.  The extensi= ons proposed in this
>>>>>>>> document can be us= ed by Mobile Routers using the NEMO (Network
>>>>>>>= ;> Mobility) Basic Support protocol as well.
>>>>>>= >>
>>>>>>>> A URL for this Internet-Draft = is:
>>>>>>>>
>>>>>>> htt= p://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.txt
&= gt;>>>>>>>
>>>>>>>> Interne= t-Drafts are also available by anonymous FTP at:
>>>>>>= ;>> f= tp://ftp.ietf.org/internet-drafts/
>>>>>>>><= BR>>>>>>>>> Below is the data which will enable a MIME compliant mail reader
>>>>>>>> implement= ation to automatically retrieve the ASCII version of the
>>>>= ;>>>> Internet-Draft.
>>>>>>>>
&g= t;>>>>>>>
>>>>>>>>
>&= gt;>>>>>> _______________________________________________=
>>>>>>>> MEXT mailing list
>>>>&= gt;>>> MEXT@ietf.org <mailto:MEXT@ietf.org> <mailto:MEXT@ietf.org
>= ;>>>>>>> <mailto:MEXT@ietf.org>>
>>>&g= t;>>>> https://www.ietf.org/mailman/listinfo/mext
>>= >>>>>
>>>>>>>
>>>>>= ;>>
>>>>>>> ---------------------------------= ---------------------------------------
>>>>>>>
= >>>>>>> ______________________________________________= _
>>>>>>> MEXT mailing list
>>>>>= >> = MEXT@ietf.org <mailto:MEXT@ietf.org>
>>>>>>> <= A href=3D"https://www.ietf.org/mailman/listinfo/mext" target=3D_blank>https= ://www.ietf.org/mailman/listinfo/mext
>>>>>>
&g= t;>>>>> _______________________________________________
&= gt;>>>>> MEXT mailing list
>>>>>> MEXT@ietf.o= rg <mailto:MEXT@ietf.org>
>>>>>> https://www.ietf.org= /mailman/listinfo/mext
>>>>>>
>>>>&= gt;
>>>>>
>>>>
>>>> _______= ________________________________________
>>>> MEXT mailing l= ist
>>>> MEXT@ietf.org <mailto:MEXT@ietf.org <mailto:MEXT@ietf..org= > >
>>>> https://www.ietf.org/mailman/listinfo/mext
>>= >
>>>
>>> --------------------------------------= ----------------------------------
>>>
>>> ________= _______________________________________
>>> MEXT mailing list>>> MEXT@ietf.org
>>> https://www.ietf.org/mailman/listinfo/m= ext
>>>
>>
>>
>>
>>
= >> _______________________________________________
>> MEXT m= ailing list
>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listi= nfo/mext
>
> ______________________________________________= _
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listin= fo/mext
>

=0A=0A --0-551930818-1240501673=:16650-- From behcetsarikaya@yahoo.com Thu Apr 23 08:52:54 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E94528C6B5 for ; Thu, 23 Apr 2009 08:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.485 X-Spam-Level: X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 lciHnTzrP-me for ; Thu, 23 Apr 2009 08:52:52 -0700 (PDT) Received: from n64a.bullet.mail.sp1.yahoo.com (n64a.bullet.mail.sp1.yahoo.com [98.136.45.11]) by core3.amsl.com (Postfix) with SMTP id 2F54728C6C1 for ; Thu, 23 Apr 2009 08:52:52 -0700 (PDT) Received: from [216.252.122.216] by n64.bullet.mail.sp1.yahoo.com with NNFMP; 23 Apr 2009 15:53:40 -0000 Received: from [67.195.9.82] by t1.bullet.sp1.yahoo.com with NNFMP; 23 Apr 2009 15:53:39 -0000 Received: from [67.195.9.106] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 23 Apr 2009 15:53:39 -0000 Received: from [127.0.0.1] by omp110.mail.gq1.yahoo.com with NNFMP; 23 Apr 2009 15:52:03 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 339022.7586.bm@omp110.mail.gq1.yahoo.com Received: (qmail 68588 invoked by uid 60001); 23 Apr 2009 15:53:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240502019; bh=PYcbkuArIRIAEi1ZMSbPceA1w27x348tE97SFohciDc=; 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=STQwMqiovW9joppY2P+IYDxP4Ouh28wvwytCCsGBmGTZbXXOBdHhU9A5colbvl7FDr84bAc5d1bjFvsGnAMKW2OR3VBc25cG7Msx/5wv4cp6zTG4lKYiWKP7LuPbR5CMTp1gW1npBpLJUskXZtMQIxTsgsIaZmJjjkV6fhStHfs= 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=u6Z+/hV8rqfCq8s7haTBTrL/1apVtzrORg6p71X9yuTwMvMFLLDZ7+ABjUlfIi8r68xA2m7u8sQarHVj7yUtbJiSwjGn6zDD6S4f4cSzFa2JVqTabdNwiHWpxdwQsEN3GihJJiXj/Beq1ruagTPHlszvCAf0/exlxj3LG9Z77lw=; Message-ID: <471395.65157.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: QsMbh0MVM1lLvgMgKWu3MxQhXa7.LwUbGfyC6cHHSKSgYdw1UAYLJK4stHTiGP2JzdkQ9_q_r4wSg0.C3JKBxBrcYmokJMMG_lB6hac.VdOTuchOHmkz45opuZGJLKqv_qV_oPFmW6_DRFGiYchWskmKZRYq5NH_lJa1qB5Mgc8izdGIjURYsSyb7omNVpTpPEtz81JPhgxQOYbwf5.nryS8AXac_1irgGK92s4eQDhZILXrF79gdEKL4t5hTkWlUAKuZe0DeaxbzObk3jzPl7etVXIxIxEq3XPl3avR.NCZT19lTPYRehhRh2f6..kp0dKP Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Thu, 23 Apr 2009 08:53:39 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: Date: Thu, 23 Apr 2009 08:53:39 -0700 (PDT) From: Behcet Sarikaya To: Vijay Devarapalli , marcelo bagnulo braun In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-768744141-1240502019=:65157" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:52:54 -0000 --0-768744141-1240502019=:65157 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Vijay,=0A=A0 I understand your concerns.=0A=0AHere is slightly revised v= ersion removing main and auxiliary:=0A=0AIn this document it is assumed tha= t a multi-homed MN connects to the home link using only one interface. This= interface is=A0identified by the home address assigned by the home agent.= =A0 The other=A0 interfaces may later on=A0become active and connect to som= e other=A0networks and get their care-of addresses and=A0then=A0the procedu= res defined in this document allow such care-of addresses to be registered = with the home agent=A0apart from the registration of the care-of addresses = assigned to the=A0 interface=A0MN originally used to connect to the home li= nk=A0which is already defined in RFC 3775.=0A=0ARegards,=0A=0ABehcet=0A=0A= =0A=0A________________________________=0AFrom: Vijay Devarapalli =0ATo: Behcet Sarikaya ; marcelo bagnulo braun= =0ACc: mext =0ASent: Wednesday, April 2= 2, 2009 6:43:13 PM=0ASubject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami= 6-multiplecoa-13.txt]=0A=0AHi Bechet,=0A=0AOn 4/22/09 4:07 PM, "Behcet Sari= kaya" wrote:=0A=0A> Hi Marcelo,=0A>=A0 How about this little paragraph?=0A>= =A0 =0A> In this document it is assumed that a multi-homed MN connects to t= he home link=0A> using only one interface. Therefore this interface is cons= idered as the main=0A> interface as identified by the home address assigned= by the home agent.=0A=0AI disagree with this. The mobile node can connect = to the home link through=0Aany one of its interfaces.=0A=0A> The =0A> other= or auxiliary interfaces may later on become active and connect to some=0A>= other networks and get their care-of addresses and then the procedures def= ined=0A> in this document allow such care-of addresses to be registered wit= h the home=0A> agent apart from the registration of the care-of addresses a= ssigned to the=0A> main interface which is already defined in RFC 3775.=0A= =0AThere is no need for the home agent to identify one of the interfaces as= a=0A"main" interface.=0A=0AVijay=0A=0A> Regards,=0A>=A0 =0A> Behcet=0A> = =0A> From: marcelo bagnulo braun =0A> To: Behcet Sarika= ya =0A> Cc: Ryuji Wakikawa ; m= ext =0A> Sent: Wednesday, April 22, 2009 4:59:50 PM=0A> Subj= ect: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A>= =0A> Hi Bechet,=0A> =0A> could you send exactly what text do you think nee= ds to be changed in the MCOA=0A> draft, so the WG can evaluate and figure o= ut if the changes are needed? (i.e.=0A> please send OLD text NEW text)=0A> = =0A> Please note that at this point in the life of the document, we only ta= ke=0A> changes that fix errors in the document, rather than=A0 getting more= features=0A> in.=0A> =0A> Regards, marcelo=0A> =0A> =0A> =0A> Behcet Sarik= aya escribi=F3:=0A>> Hi Ryuji,=0A>>=A0 I checked your draft. Again, I could= not understand how you are sending a=0A>> registration BU at the home link= as only an O-flag is defined in your draft=0A>> which is used for somethin= g else.=0A>>=A0 As I mentioned to you, we discussed this related to draft-p= remec-homelink=0A>> and it seems like HA will reject such a BU unless somet= hing is done, I=0A>> thought you were familiar with the discussions as it r= elates to your draft=0A>> too. I am surprised.=0A>>=A0 Regards,=0A>>=A0 Beh= cet=0A>> =0A>> ------------------------------------------------------------= ------------=0A>> *From:* Ryuji Wakikawa =0A>> *T= o:* Behcet Sarikaya =0A>> *Cc:* George Tsirtsis ; mext =0A>> *Sent:* Wednesday, April 22, 2= 009 4:18:28 PM=0A>> *Subject:* Re: [MEXT] [Fwd: I-D Action:draft-ietf-monam= i6-multiplecoa-13.txt]=0A>> =0A>> Hi Behcet,=0A>> =0A>> On 2009/04/22, at 1= 1:31, Behcet Sarikaya wrote:=0A>> =0A>>> =0A>>> =0A>>> From: George Tsirtsi= s >> >=0A>>> To= : Behcet Sarikaya >=0A>>> Cc: = mext >=0A>>> Sent: Wednesday, April 22= , 2009 10:10:08 AM=0A>>> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-mo= nami6-multiplecoa-13.txt]=0A>>> =0A>>> I do not think that adding home link= registration to RFC3775bis is feasible.=0A>>> This requires logic in the M= N and HA that is not directly compatible=0A>>> to RFC3775. The aim of RFC37= 75bis is to make minimal changes for=0A>>> clarification reasons and to cor= rect errors. Home Link Registration as=0A>>> defined in MCoA is neither.=0A= >>> [behcet] Why not? If it is needed in so many instances, that qualifies = it to=0A>>> become a base protocol feature, at least to me.=0A>> =0A>> We c= annot add a new feature to 3775. That is the ground rule of -bis. The=0A>> = chairs can clarify this.=0A>> =0A>> regards,=0A>> ryuji=0A>> =0A>> =0A>> = =0A>>> =0A>>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya=0A>>> > wrote:=0A>>>> Hi Geo= rge,=0A>>>>=A0 It seems in my previous reply I replied to this mail of your= s which was=0A>>>> unrelated to the other mail you sent to which I was real= ly replying,=0A>>>> apologies.=0A>>>>=A0 Now regarding home link registrati= on, what is the mechanism MCoA draft=0A>>>> uses? Ryuji mentioned some H bi= t but I read the draft and couldn't confirm=0A>>>> it.=0A>>>> =0A>>>>=A0 My= suggestion was building on this, i.e. I suggested that whatever you=0A>>>>= came up with can be moved to 3775bis so that other people would not have t= o=0A>>>> make normative references to your draft.=0A>>>> =0A>>>> That's all= ..=0A>>>> =0A>>>> Regards,=0A>>>> =0A>>>> Behcet=0A>>>> =0A>>>> ____________= ____________________=0A>>>> From: George Tsirtsis >>> >=0A>>>> To: Vijay Devarapalli >=0A>>>> Cc: Behcet Sarikaya >; mext=0A>>>> >=0A>>>> Sent: Tuesday, April 21, 2009 2:14:55 PM=0A>>>>= Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt= ]=0A>>>> =0A>>>> ...also wrt the home link registration, I do not think wha= t you=0A>>>> suggest is necessary.=0A>>>> =0A>>>> As far as I see the other= documents are informational, and they do not=0A>>>> yet have a formal stan= ding in the WG. If and when they do, as=0A>>>> Informational documents,=A0 = they should not require normative changes to=0A>>>> anything. They should m= ake sure what they describe (mostly=0A>>>> implementation options in this c= ase) are compatible not only with=0A>>>> RFC3775 but also with extensions t= o it, including Flow Bindings. .=0A>>>> =0A>>>> =0A>>>> Regards=0A>>>> Geor= ge=0A>>>> =0A>>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli >>> >=0A>>>> wrote:=0A>>>>> Beh= cet,=0A>>>>> =0A>>>>> Behcet Sarikaya wrote:=0A>>>>>> =0A>>>>>> *[behcet] Y= es but each interface will appear to HA as a different device=0A>>>>>> and = HA needs to assign a different HoA. Then MCoA problem disappears.*=0A>>>>>>= *So George is saying that this is avoided by some virtual interfaces so=0A= >>>>>> that HA does not see each interface separately. *=0A>>>>>> *Is this = explained anywhere in the draft?*=0A>>>>>> *If yes then I am OK.*=0A>>>>> = =0A>>>>> The home agent does not care about the multiple interfaces on the = mobile=0A>>>>> node. It only sees the mobile node as one entity and allocat= es a home=0A>>>>> address to it. The multiple care-of addresses that the mo= bile node has=0A>>>>> will=0A>>>>> be used by the home agent as tunnel end = points. That is all.. So there is=0A>>>>> no=0A>>>>> issue.=0A>>>>> =0A>>>>= > Vijay=0A>>>>> =0A>>>>>>>=A0 Also I have a question to Ryuji: does this dr= aft send a=0A>>>>>> non-deregistration BU at the home link? If yes, is he f= amiliar with the=0A>>>>>> discussion going on on this subject? This is anot= her point of confusion=0A>>>>>> for=0A>>>>>> me.=0A>>>>>> =0A>>>>>> This ha= s been discussed for a long time in MEXT.=0A>>>>>> who is familiar with whi= ch discussions? I don't know your concern here.=0A>>>>>>=A0 *[behcet] So yo= ur answer is yes the draft sends a non-deregistration BU=0A>>>>>> (kind of = bulk registration) at the home link.*=0A>>>>>> *The discussion I mentioned = was related to=0A>>>>>> draft-premec-mext-extended-home-link. This draft al= so sends=0A>>>>>> non-deregistration BU at the home link. So does a few mor= e drafts like=0A>>>>>> **draft-devarapalli-mext-mipv6-home-link.*=0A>>>>>> = =0A>>>>>> **=0A>>>>>> *[behcet] You mentioned some bit is set but I could n= ot understand which.=0A>>>>>> One idea is since so many drafts need this, w= hy not factor this out and=0A>>>>>> define whatever the mechanism to enable= sending non-deregistration BU in=0A>>>>>> 3775bis. What do you think about= that?*=0A>>>>>> =0A>>>>>> **=0A>>>>>> =0A>>>>>>>=A0 Sorry if I am too=A0 m= uch confused=0A>>>>>>> Please don't get me wrong, I am not trying to slow d= own the progress=0A>>>>>> of=0A>>>>>> this document..=0A>>>>>> =0A>>>>>> su= re, but please explain your issue more precisely.=0A>>>>>> =0A>>>>>> thanks= !=0A>>>>>> ryuji=0A>>>>>> =0A>>>>>>> =0A>>>>>>> Regards,=0A>>>>>>> =0A>>>>>= >> Behcet=0A>>>>>>> From: marcelo bagnulo braun >>>>= >> =0A>>>>>> >>=0A>>>>>>> To: mext >>>>>> >>; Julien Lagani= er=0A>>>>>> >>>>> =0A>>>>>> >>>>> >>; Jari Arkko= =0A>>>>>> =0A>>>>>> >>>>> >>>=0A>>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM= =0A>>>>>>> Subject: [MEXT] [Fwd: I-D=0A>>>>>> Action:draft-ietf-monami6-mul= tiplecoa-13.txt]=0A>>>>>>> =0A>>>>>>> We have this new version of the MCOA = document that addresses the=0A>>>>>> comments received, including IESG revi= ew comments.=0A>>>>>>> To the best of my knowledge, the IESG is ok with the= doc and ready for=0A>>>>>> publication..=0A>>>>>>> I am planning to ask ou= r AD to move forward in a week or so, so, if=0A>>>>>> you=0A>>>>>> have com= ments on the document please provide them before the 1st of may.=0A>>>>>>> = =0A>>>>>>> Regards, marcelo=0A>>>>>>> (mcoa doc shepherd)=0A>>>>>>> =0A>>>>= >>> -------- Mensaje original --------=0A>>>>>>> Asunto:=A0 =A0 [MEXT] I-D = Action:draft-ietf-monami6-multiplecoa-13.txt=0A>>>>>>> Fecha:=A0 =A0 Mon, 2= 0 Apr 2009 08:30:01 -0700 (PDT)=0A>>>>>>> De:=A0 =A0 Internet-Drafts@ietf.o= rg =0A>>>>>>> >=0A>>>>>>> Para:=A0 =A0 i-d-announce= @ietf.org =0A>>>>>>> >=0A>>>>>>> CC:=A0 =A0 mext@ietf.org >=0A>>>>>>> >=0A>>>>>>> =0A>>>>>>> =0A>>>>>>> =0A>>>>>>> A New= Internet-Draft is available from the on-line Internet-Drafts=0A>>>>>> dire= ctories.=0A>>>>>>> This draft is a work item of the Mobility EXTensions for= IPv6 Working=0A>>>>>> Group of the IETF.=0A>>>>>>> =0A>>>>>>> =0A>>>>>>>= =A0 =A0 Title=A0 =A0 =A0 =A0 =A0 : Multiple Care-of Addresses Registration= =0A>>>>>>>=A0 =A0 Author(s)=A0 =A0 =A0 : R. Wakikawa, et al.=0A>>>>>>>=A0 = =A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-monami6-multiplecoa-13..txt=0A>>>>= >>>=A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 : 44=0A>>>>>>>=A0 =A0 Date=A0 =A0 =A0 = =A0 =A0 =A0 : 2009-04-20=0A>>>>>>> =0A>>>>>>> According to the current Mobi= le IPv6 specification, a mobile node may=0A>>>>>>> have several care-of add= resses, but only one, called the primary=0A>>>>>>> care-of address, that ca= n be registered with its home agent and the=0A>>>>>>> correspondent nodes.= =A0 However, for matters of cost, bandwidth, delay,=0A>>>>>>> etc, it is us= eful for the mobile node to get Internet access through=0A>>>>>>> multiple = accesses simultaneously, in which case the mobile node would=0A>>>>>>> be c= onfigured with multiple active IPv6 care-of addresses.=A0 This=0A>>>>>>> do= cument proposes extensions to the Mobile IPv6 protocol to register=0A>>>>>>= > and use multiple care-of addresses.=A0 The extensions proposed in this=0A= >>>>>>> document can be used by Mobile Routers using the NEMO (Network=0A>>= >>>>> Mobility) Basic Support protocol as well.=0A>>>>>>> =0A>>>>>>> A URL = for this Internet-Draft is:=0A>>>>>>> =0A>>>>>> http://www.ietf.org/interne= t-drafts/draft-ietf-monami6-multiplecoa-13.txt=0A>>>>>>> =0A>>>>>>> Interne= t-Drafts are also available by anonymous FTP at:=0A>>>>>>> ftp://ftp.ietf.o= rg/internet-drafts/=0A>>>>>>> =0A>>>>>>> Below is the data which will enabl= e a MIME compliant mail reader=0A>>>>>>> implementation to automatically re= trieve the ASCII version of the=0A>>>>>>> Internet-Draft.=0A>>>>>>> =0A>>>>= >>> =0A>>>>>>> =0A>>>>>>> _______________________________________________= =0A>>>>>>> MEXT mailing list=0A>>>>>>> MEXT@ietf.org = >>>>>> >=0A>>>>>>> https://= www.ietf.org/mailman/listinfo/mext=0A>>>>>> =0A>>>>>> =0A>>>>>> =0A>>>>>> -= -----------------------------------------------------------------------=0A>= >>>>> =0A>>>>>> _______________________________________________=0A>>>>>> ME= XT mailing list=0A>>>>>> MEXT@ietf.org =0A>>>>>> http= s://www.ietf.org/mailman/listinfo/mext=0A>>>>> =0A>>>>> ___________________= ____________________________=0A>>>>> MEXT mailing list=0A>>>>> MEXT@ietf.or= g =0A>>>>> https://www.ietf.org/mailman/listinfo/mext= =0A>>>>> =0A>>>> =0A>>>> =0A>>> =0A>>> ____________________________________= ___________=0A>>> MEXT mailing list=0A>>> MEXT@ietf.org >=0A>>> https://www.ietf.org/mailman/listinfo/me= xt=0A>> =0A>> =0A>> -------------------------------------------------------= -----------------=0A>> =0A>> ______________________________________________= _=0A>> MEXT mailing list=0A>> MEXT@ietf.org=0A>> https://www.ietf.org/mailm= an/listinfo/mext=0A>>=A0 =0A> =0A> =0A>=A0 =0A> =0A> ______________________= _________________________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https= ://www.ietf.org/mailman/listinfo/mext=0A=0A=0A --0-768744141-1240502019=:65157 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Vijay,
=0A
  I understand your concer= ns.
=0A
 
=0A
Here is slightly revised version remov= ing main and auxiliary:
=0A
 
=0A
=0A
In this do= cument it is assumed that a multi-homed MN connects to the home link using = only one interface. This interface is identified by the home address a= ssigned by the home agent.  The other  interfaces may later on&nb= sp;become active and connect to some other networks and get their care= -of addresses and then the procedures defined in this document al= low such care-of addresses to be registered with the home agent apart = from the registration of the care-of addresses assigned to the  interf= ace MN originally used to connect to the home link which is alrea= dy defined in RFC 3775.

Regards,
=0A
 
=0A<= DIV>Behcet
=0A

=0A
=0A
=0AFrom: Vijay Devarap= alli <vijay@wichorus.com>
To:= Behcet Sarikaya <sarikaya@ieee.org>; marcelo bagnulo brau= n <marcelo@it.uc3m.es>
Cc: mext <mext@ietf.org>
Sent: Wednesday, April 22, 2009 6:43:13 PM
Subject: Re: [MEXT] [Fwd: I-D Action:draft-i= etf-monami6-multiplecoa-13.txt]

Hi Bechet,

On 4/22/09 = 4:07 PM, "Behcet Sarikaya" wrote:

> Hi Marcelo,
>  How= about this little paragraph?
> 
> In this document it is= assumed that a multi-homed MN connects to the home link
> using only= one interface. Therefore this interface is considered as the main
> = interface as identified by the home address assigned by the home agent.
=
I disagree with this. The mobile node can connect to the home link throughany one of its interfaces.

> The
> other or auxiliary in= terfaces may later on become active and connect to some
> other netwo= rks and get their care-of addresses and then the procedures defined
>= in this document allow such care-of addresses to be registered with the ho= me
> agent apart from the registration of the care-of addresses assig= ned to the
> main interface which is already defined in RFC 3775.
=
There is no need for the home agent to identify one of the interfaces a= s a
"main" interface.

Vijay

> Regards,
>  > Behcet
>
> From: marcelo bagnulo braun <marcelo@it.= uc3m.es>
> To: Behcet Sarikaya <sarikaya@ieee.org>
> Cc:= Ryuji Wakikawa <ryuji.wakikawa@gmail.com>; mext <= ;mext@iet= f.org>
> Sent: Wednesday, April 22, 2009 4:59:50 PM
> Su= bject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]>
> Hi Bechet,
>
> could you send exactly what tex= t do you think needs to be changed in the MCOA
> draft, so the WG can= evaluate and figure out if the changes are needed? (i.e.
> please se= nd OLD text NEW text)
>
> Please note that at this point in th= e life of the document, we only take
> changes that fix errors in the= document, rather than  getting more features
> in.
>
= > Regards, marcelo
>
>
>
> Behcet Sarikaya escribi=F3:
>> Hi Ryuji,
>>  I checked your draft. = Again, I could not understand how you are sending a
>> registratio= n BU at the home link as only an O-flag is defined in your draft
>>= ; which is used for something else.
>>  As I mentioned to you= , we discussed this related to draft-premec-homelink
>> and it see= ms like HA will reject such a BU unless something is done, I
>> th= ought you were familiar with the discussions as it relates to your draft>> too. I am surprised.
>>  Regards,
>> = Behcet
>>
>> ------------------------------------------= ------------------------------
>> *From:* Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
>> *To:* Behcet Sarikaya = <sarikaya@ieee.org>
>>= *Cc:* George Tsirtsis <tsirtsis@googlemail.com>; mext= <mext= @ietf.org>
>> *Sent:* Wednesday, April 22, 2009 4:18:28 PM<= BR>>> *Subject:* Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multi= plecoa-13.txt]
>>
>> Hi Behcet,
>>
>>= On 2009/04/22, at 11:31, Behcet Sarikaya wrote:
>>
>>&g= t;
>>>
>>> From: George Tsirtsis <t= sirtsis@googlemail.com
>>> <mailto:tsirtsis@g= ooglemail.com>>
>>> To: Behcet Sarikaya <sar= ikaya@ieee.org <mailto:sarikaya@ieee.org>>
>>>= Cc: mext <mext@ietf.org <mailto:mext@ietf.org>>
>>> Sent: W= ednesday, April 22, 2009 10:10:08 AM
>>> Subject: Re: [MEXT] [F= wd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>
&= gt;>> I do not think that adding home link registration to RFC3775bis= is feasible.
>>> This requires logic in the MN and HA that is = not directly compatible
>>> to RFC3775. The aim of RFC3775bis i= s to make minimal changes for
>>> clarification reasons and to = correct errors. Home Link Registration as
>>> defined in MCoA i= s neither.
>>> [behcet] Why not? If it is needed in so many inst= ances, that qualifies it to
>>> become a base protocol feature,= at least to me.
>>
>> We cannot add a new feature to 37= 75. That is the ground rule of -bis. The
>> chairs can clarify thi= s.
>>
>> regards,
>> ryuji
>>
>= >
>>
>>>
>>> On Wed, Apr 22, 2009 at= 4:06 PM, Behcet Sarikaya
>>> <behcetsarikaya@y= ahoo.com <mailto:behcetsarikaya@yahoo.com>> w= rote:
>>>> Hi George,
>>>>  It seems in = my previous reply I replied to this mail of yours which was
>>>= > unrelated to the other mail you sent to which I was really replying,
>>>> apologies.
>>>>  Now reg= arding home link registration, what is the mechanism MCoA draft
>>= >> uses? Ryuji mentioned some H bit but I read the draft and couldn't= confirm
>>>> it.
>>>>
>>>>&n= bsp; My suggestion was building on this, i.e. I suggested that whatever you=
>>>> came up with can be moved to 3775bis so that other peo= ple would not have to
>>>> make normative references to your= draft.
>>>>
>>>> That's all.
>>>= ;>
>>>> Regards,
>>>>
>>>>= ; Behcet
>>>>
>>>> _________________________= _______
>>>> From: George Tsirtsis <tsirtsis@g= ooglemail.com
>>>> <mailto:tsirtsis@googlemail.com>>
>>>> To: Vijay = Devarapalli <vijay@wichorus.com <mailto:vijay@wichorus.com&= gt;>
>>>> Cc: Behcet Sarikaya <sarikaya@ieee.org &l= t;mailto:sarikaya@ieee.org>>; mext
>>>> <mext@ietf.org <mailto:mext@ietf.org>>
>>>> Sent: Tuesday, April 21, = 2009 2:14:55 PM
>>>> Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>
>= >>> ...also wrt the home link registration, I do not think what yo= u
>>>> suggest is necessary.
>>>>
>>= ;>> As far as I see the other documents are informational, and they d= o not
>>>> yet have a formal standing in the WG. If and when= they do, as
>>>> Informational documents,  they should= not require normative changes to
>>>> anything. They should= make sure what they describe (mostly
>>>> implementation op= tions in this case) are compatible not only with
>>>> RFC377= 5 but also with extensions to it, including Flow Bindings. .
>>>= ;>
>>>>
>>>> Regards
>>>>= George
>>>>
>>>> On Tue, Apr 21, 2009 at 7:= 58 PM, Vijay Devarapalli <vijay@wichorus.com
>>&g= t;> <mailto:vijay@wichorus.com>>
>>>> wrote= :
>>>>> Behcet,
>>>>>
>>>&= gt;> Behcet Sarikaya wrote:
>>>>>>
>>>= >>> *[behcet] Yes but each interface will appear to HA as a differ= ent device
>>>>>> and HA needs to assign a different H= oA. Then MCoA problem disappears.*
>>>>>> *So George i= s saying that this is avoided by some virtual interfaces so
>>>= >>> that HA does not see each interface separately. *
>>&= gt;>>> *Is this explained anywhere in the draft?*
>>>&= gt;>> *If yes then I am OK.*
>>>>>
>>>= >> The home agent does not care about the multiple interfaces on the mobile
>>>>> node. It only sees the mobile node as one e= ntity and allocates a home
>>>>> address to it. The multi= ple care-of addresses that the mobile node has
>>>>> will=
>>>>> be used by the home agent as tunnel end points. Th= at is all.. So there is
>>>>> no
>>>>> = issue.
>>>>>
>>>>> Vijay
>>&g= t;>>
>>>>>>>  Also I have a question to= Ryuji: does this draft send a
>>>>>> non-deregistrati= on BU at the home link? If yes, is he familiar with the
>>>>= >> discussion going on on this subject? This is another point of conf= usion
>>>>>> for
>>>>>> me.
&g= t;>>>>>
>>>>>> This has been discussed= for a long time in MEXT.
>>>>>> who is familiar with which discussions? I don't know your concern here.
>&g= t;>>>>  *[behcet] So your answer is yes the draft sends a = non-deregistration BU
>>>>>> (kind of bulk registratio= n) at the home link.*
>>>>>> *The discussion I mention= ed was related to
>>>>>> draft-premec-mext-extended-ho= me-link. This draft also sends
>>>>>> non-deregistrati= on BU at the home link. So does a few more drafts like
>>>>&= gt;> **draft-devarapalli-mext-mipv6-home-link.*
>>>>>&= gt;
>>>>>> **
>>>>>> *[behcet] Y= ou mentioned some bit is set but I could not understand which.
>>&= gt;>>> One idea is since so many drafts need this, why not factor = this out and
>>>>>> define whatever the mechanism to e= nable sending non-deregistration BU in
>>>>>> 3775bis. What do you think about that?*
>>>>>>
&g= t;>>>>> **
>>>>>>
>>>>&= gt;>>  Sorry if I am too  much confused
>>>>= >>> Please don't get me wrong, I am not trying to slow down the pr= ogress
>>>>>> of
>>>>>> this docu= ment..
>>>>>>
>>>>>> sure, but p= lease explain your issue more precisely.
>>>>>>
&g= t;>>>>> thanks!
>>>>>> ryuji
>>= ;>>>>
>>>>>>>
>>>>>= >> Regards,
>>>>>>>
>>>>>&= gt;> Behcet
>>>>>>> From: marcelo bagnulo braun = <marcelo@it.uc3m.es
>>>>>>> <mailto:marcelo@it.uc3m.es>
>>>>>> <mai= lto:marcelo@it.uc3m.es <mailto:marcelo@it.uc3m.es>>><= BR>>>>>>>> To: mext <mext@ietf.org <mailto:mext@ietf.org&g= t; <mailto:mext@ietf.org
>>>>>>> <mailto:mext@ietf.org>>>; Julien Laganier
>>>>>> <julien.laganier.iet= f@googlemail.com
>>>>>> <mailto:julien.laganier.ietf@googlemail.com>
>>= >>>> <mailto:julien.lag= anier..ietf@googlemail.com
>>>>>> <mailto:julien.laganier..ietf@googlemail.com>= ;>>; Jari Arkko
>>>>>> <jari.arkko@piuha= ..net <mailto:jari.arkko@piuha.net>
>>>>&g= t;> <mailto:jari.arkko@piuha.net <mailto:jari.arkko@piuh= a..net
>>>>>> <mailto:jari.arkko@piuha.net= > >>>
>>>>>>> Sent: Tuesday, April = 21, 2009 11:03:05 AM
>>>>>>> Subject: [MEXT] [Fwd: = I-D
>>>>>> Action:draft-ietf-monami6-multiplecoa-13.tx= t]
>>>>>>>
>>>>>>> We have= this new version of the MCOA document that addresses the
>>>&g= t;>> comments received, including IESG review comments.
>>&g= t;>>>> To the best of my knowledge, the IESG is ok with the doc= and ready for
>>>>>> publication..
>>>>>>> I am planning to ask our AD = to move forward in a week or so, so, if
>>>>>> you
= >>>>>> have comments on the document please provide them = before the 1st of may.
>>>>>>>
>>>>= >>> Regards, marcelo
>>>>>>> (mcoa doc she= pherd)
>>>>>>>
>>>>>>> ---= ----- Mensaje original --------
>>>>>>> Asunto:&nbs= p;   [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt
>&g= t;>>>>> Fecha:    Mon, 20 Apr 2009 08:30:01 -0700 = (PDT)
>>>>>>> De:    Interne= t-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org&g= t;
>>>>>>> <mailto:Internet-Drafts@= ietf.org <mailto:Internet-Drafts@ietf.org>>>>>>>>> Para:    i-d-announce@ietf.= org <mailto:i-d-announce@ietf.org>
>>>>= >>> <mailto:i-d-announce@ietf.org <mailto:= i-d-announce@ietf.org>>
>>>>>>> CC: =   mext@ietf.o= rg <mailto:mext@ietf..org <mailto:mext@ietf.org> >
>>>&= gt;>>> <mailto:mext@ietf.org <mailto:mext@ietf.org>>
>>= >>>>>
>>>>>>>
>>>>&= gt;>>
>>>>>>> A New Internet-Draft is availa= ble from the on-line Internet-Drafts
>>>>>> directorie= s.
>>>>>>> This draft is a work item of the Mobilit= y EXTensions for IPv6 Working
>>>>>> Group of the IETF= ..
>>>>>>>
>>>>>>>
>>>>>>>    Title      &n= bsp;   : Multiple Care-of Addresses Registration
>>>>&g= t;>>    Author(s)      : R. Wakikawa, et al.=
>>>>>>>    Filename      =   : draft-ietf-monami6-multiplecoa-13..txt
>>>>>>= >    Pages          : 44
>>&= gt;>>>>    Date          &nb= sp; : 2009-04-20
>>>>>>>
>>>>>&g= t;> According to the current Mobile IPv6 specification, a mobile node ma= y
>>>>>>> have several care-of addresses, but only = one, called the primary
>>>>>>> care-of address, th= at can be registered with its home agent and the
>>>>>>= ;> correspondent nodes.  However, for matters of cost, bandwidth, delay,
>>>>>>> etc, it is useful for th= e mobile node to get Internet access through
>>>>>>>= ; multiple accesses simultaneously, in which case the mobile node would
= >>>>>>> be configured with multiple active IPv6 care-o= f addresses.  This
>>>>>>> document proposes e= xtensions to the Mobile IPv6 protocol to register
>>>>>&g= t;> and use multiple care-of addresses.  The extensions proposed in= this
>>>>>>> document can be used by Mobile Router= s using the NEMO (Network
>>>>>>> Mobility) Basic S= upport protocol as well.
>>>>>>>
>>>&g= t;>>> A URL for this Internet-Draft is:
>>>>>>= ;>
>>>>>> http://www.ietf.org/internet-drafts/draf= t-ietf-monami6-multiplecoa-13.txt
>>>>>>>
>>>>>>> Internet-Drafts are also available by ano= nymous 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.
>>>>>= >>
>>>>>>>
>>>>>>> =
>>>>>>> __________________________________________= _____
>>>>>>> MEXT mailing list
>>>>= >>> MEXT@ietf.org <mailto:MEXT@ietf.org> <mailto:MEXT@ietf.o= rg
>>>>>>> <mailto:MEXT@ietf.org>>
>&= gt;>>>>> https://www.ietf.org/mailman/listinfo/mext
>&= gt;>>>>
>>>>>>
>>>>>&g= t;
>>>>>> -------------------------------------------= -----------------------------
>>>>>>
>>>&= gt;>> _______________________________________________
>>>= >>> MEXT mailing list
>>>>>> MEXT@ietf.org <mai= lto:MEXT@= ietf.org>
>>>>>> https:= //www.ietf.org/mailman/listinfo/mext
>>>>>
>&g= t;>>> _______________________________________________
>>&= gt;>> MEXT mailing list
>>>>> MEXT@ietf.org <mailto:<= A href=3D"mailto:MEXT@ietf.org" ymailto=3D"mailto:MEXT@ietf.org">MEXT@ietf.= org>
>>>>> https://www.ietf.org/mailman/listinfo/mext<= /A>
>>>>>
>>>>
>>>>
&= gt;>>
>>> ______________________________________________= _
>>> MEXT mailing list
>>> MEXT@ietf.org <mailto:MEXT@ietf.or= g <mailto:MEXT@ietf..org> >
>>> https://www.ietf.org/mailman/l= istinfo/mext
>>
>>
>> --------------------= ----------------------------------------------------
>>
>&g= t; _______________________________________________
>> MEXT mailing= list
>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listinfo/me= xt
>> 
>
>
> 
>
>= _______________________________________________
> MEXT mailing list<= BR>> M= EXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext


=0A=0A --0-768744141-1240502019=:65157-- From behcetsarikaya@yahoo.com Thu Apr 23 08:55:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9D6A28C6EE for ; Thu, 23 Apr 2009 08:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.420, 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 Iudi+b6LLUW3 for ; Thu, 23 Apr 2009 08:55:00 -0700 (PDT) Received: from n9.bullet.re3.yahoo.com (n9.bullet.re3.yahoo.com [68.142.237.94]) by core3.amsl.com (Postfix) with SMTP id 8195A28C6D5 for ; Thu, 23 Apr 2009 08:55:00 -0700 (PDT) Received: from [68.142.237.87] by n9.bullet.re3.yahoo.com with NNFMP; 23 Apr 2009 15:55:53 -0000 Received: from [67.195.9.83] by t3.bullet.re3.yahoo.com with NNFMP; 23 Apr 2009 15:55:53 -0000 Received: from [67.195.9.106] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 23 Apr 2009 15:55:53 -0000 Received: from [127.0.0.1] by omp110.mail.gq1.yahoo.com with NNFMP; 23 Apr 2009 15:54:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 800497.47643.bm@omp110.mail.gq1.yahoo.com Received: (qmail 69603 invoked by uid 60001); 23 Apr 2009 15:55:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240502153; bh=bqLmzVR/bJHsHPtBZ6HiiXVaHNwZvp1zBqQOXqvHReA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=VH8xBwbaIXYY7yp2Cnu+QpgoZCT+CEhdM9h1A/NEbsjOwBHYKJa/GMRHh787lG/VzO79dOMvzreFCjsXcf5+CklkwnyUldEMlCCNNUcnhECONCTNjUCCCc+uyRnmAaFCjpce14j9GwfJhMb6Fgo6wU9KcqHOOPHUBB8NY05OpYY= 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; b=xmkD1g+reEo1JyB7Mcx4EiFEftKxHqS7FF7jy6zs22sT/5kJZ8Z8LK05OhR2A3GkKeVFhKg3xNPDv8yTop1oBFMke9KoMhAH6MWKHvqjIm7FJQRDyWvCIyU2+VnzpJii/bwP98FAyxXDZj0c6LqD4o5FF+no+ZFVhCZqrs/7fPg=; Message-ID: <58068.68556.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: JDx2L8AVM1loFwdeNHMeQbvoe87TotyHjNY4IEzUr2kzOEpMg.V1XE_Se0FfZnRhdu6364man1yzil0KsLgqQYq2hBA6_mmp9_i6Jx6hjxA2wiCN8Pf6nDU8jJKoz2vIycZNHi5zkzCkasxyXcI7tlMu9atUX8tDbPtdetSsnh2R2qxqjM8iXyShf8MKSFwaD6esekWGg0EG9tMYVvCNS3Ca8bny1Se95zoeVvqEWB5NJSoKlSPy6h.JucU6hh1Dg09bNYvBa7L8XVVIWKLVi5u_jbKwzAQZkiuOwrsbNEJpr8LEmcqu40hlFAgm9fZmYLlRxnLc2IM- Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Thu, 23 Apr 2009 08:55:52 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <49F047C5.5000202@ericsson.com> Date: Thu, 23 Apr 2009 08:55:52 -0700 (PDT) From: Behcet Sarikaya To: Conny Larsson , mext , Hesham Soliman In-Reply-To: <49F047C5.5000202@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-28828257-1240502152=:68556" Subject: Re: [MEXT] Proposal for new Flow Idenfication option format X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:55:01 -0000 --0-28828257-1240502152=:68556 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Conny,=0A=A0 All is well but there is no document for Format Type 1 (or = 2) depending on how you number them.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A= =0A________________________________=0AFrom: Conny Larsson =0ATo: mext ; Hesham Soliman =0ASent: Thursday, April 23, 2009 5:49:41 AM=0ASubject: [MEXT] Propos= al for new Flow Idenfication option format=0A=0AHi Hesham,=0A=0AAs there se= ems to be multiple proposals for the flow descriptor format I believe there= is a need for a revised format of the Flow Identification option defined i= n draft-ietf-mext-flow-binding-01.txt.=0A=0AMy proposal would be as follows= :=0A=0AFlow Identification option:=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AThis option includes inform= ation about the type of flow identification=0Aformat that follows. Exactly = one option MUST be present in the message.=0A=0A0=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 3=0A0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | Option Type=A0 |=A0 Option Len=A0 |=A0 Format=A0 =A0 =A0 |=A0 =A0 =A0 =A0= =A0 =A0 =A0 |=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+=0A=0AOption Type=0A=A0 TBD=0A=0AOption Len=0A=A0 Length of option i= n octets.=0A=0AFormat=0A=A0 01=A0 Format type 1=0A=A0 02=A0 Format type 2= =0A=0A=0A=0AFlow Descriptor:=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=0AThis option identifies a specific flow. There MAY exist multiple= =0AFlow Descriptor options in one Flow Identification option=0A=0A0=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 1=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 3=0A0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1= 2 3 4 5 6 7 8 9 0 1=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+=0A| Option Type=A0 |=A0 Option Len=A0 |=A0 Flow Description= =A0 =A0 =A0 =A0 =A0 =A0 |=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +=0A.=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 .=0A.=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 .=0A+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+=0A=0AOption Type=0A=A0 TBD=0A=0AOption Len=0A=A0 Length of the Flow Des= cription in octets=0A=0AFlow Description=0A=A0 Defined in a separate docume= nt per format type=0A=0A=0ARegards=0AConny=0A=0A___________________________= ____________________=0AMEXT mailing list=0AMEXT@ietf.org=0Ahttps://www.ietf= ..org/mailman/listinfo/mext=0A=0A=0A=0A --0-28828257-1240502152=:68556 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Conny,
=0A
  All is well but there is= no document for Format Type 1 (or 2) depending on how you number them.=0A
 
=0A
Regards,
=0A
 
=0A
Beh= cet
=0A

=0A
=0A
=0AFrom: Conny Larsson &l= t;conny.larsson@ericsson.com>
To= : mext <mext@ietf.org>; Hesham Soliman <Hesham@elevatem= obile.com>
Sent: Thur= sday, April 23, 2009 5:49:41 AM
Sub= ject: [MEXT] Proposal for new Flow Idenfication option format
Hi Hesham,

As there seems to be multiple proposals for t= he flow descriptor format I believe there is a need for a revised format of= the Flow Identification option defined in draft-ietf-mext-flow-binding-01.= txt.

My proposal would be as follows:

Flow Identification opt= ion:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
This option includes information about the type of flow = identification
format that follows. Exactly one option MUST be present i= n the message.

0                  1            &nb= sp;     2                =   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Option Type  |  Option Len  |  Format    &nbs= p; |              |
+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Type
&nbs= p; TBD

Option Len
  Length of option in octets.

Forma= t
  01  Format type 1
  02  Format type 2

=

Flow Descriptor:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
This option identifies a specific flow. There MAY exist multiple
= Flow Descriptor options in one Flow Identification option

0  &n= bsp;               1     =             2              &nb= sp;   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Option Type  |  Option Len  |  Flow Description&nbs= p;           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +                    &nbs= p;         +
.          &nb= sp;                     &= nbsp;                    =         .
.           = ;                     &nb= sp;                     &= nbsp;       .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Option Type
  TBD

Option Len
  Length of the Flo= w Description in octets

Flow Description
  Defined in a sepa= rate document per format type


Regards
Conny

__________= _____________________________________
MEXT mailing list
MEXT@ietf.org
<= A href=3D"https://www.ietf.org/mailman/listinfo/mext" target=3D_blank>https= ://www.ietf.org/mailman/listinfo/mext

=0A=0A= =0A=0A --0-28828257-1240502152=:68556-- From vijay@wichorus.com Thu Apr 23 10:27:41 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C92E3A72CC for ; Thu, 23 Apr 2009 10:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 sX7QD7ePdCCU for ; Thu, 23 Apr 2009 10:27:39 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 5EAE83A6DBC for ; Thu, 23 Apr 2009 10:27:39 -0700 (PDT) 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, 23 Apr 2009 13:28:54 -0400 Message-ID: In-Reply-To: <471395.65157.qm@web111404.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] Thread-Index: AcnEK6zGiE/dLqYhS56s+8FK1QVpwAADKTgA References: <471395.65157.qm@web111404.mail.gq1.yahoo.com> From: "Vijay Devarapalli" To: "Behcet Sarikaya" , "marcelo bagnulo braun" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 17:27:41 -0000 I kind of understand what you are saying now. You are concerned about = the mobile node attaching to the home link via multiple interfaces = (since it has multiple interfaces) and the result of assigning the home = address to those interfaces. As far as RFC 3775 and the MCoA draft is concerned, the home address is = assigned to first interface with which the mobile node attaches to the = home link. This may require the mobile node to "move" the home address = from a MIPv6 virtual interface to the physical interface with which it = attaches to the home link. This is implementation specific.=20 If the mobile node attaches to the home link via a second interface, I = think the mobile node should get a new home address for that interface. = Not the same home address.=20 Does the above make sense? Vijay=20 > -----Original Message----- > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 > Sent: Thursday, April 23, 2009 8:54 AM > To: Vijay Devarapalli; marcelo bagnulo braun > Cc: mext > Subject: Re: [MEXT] [Fwd: I-D=20 > Action:draft-ietf-monami6-multiplecoa-13.txt] >=20 > Hi Vijay, > I understand your concerns. > =20 > Here is slightly revised version removing main and auxiliary: > =20 > In this document it is assumed that a multi-homed MN connects=20 > to the home link using only one interface. This interface is=20 > identified by the home address assigned by the home agent. =20 > The other interfaces may later on become active and connect=20 > to some other networks and get their care-of addresses and=20 > then the procedures defined in this document allow such=20 > care-of addresses to be registered with the home agent apart=20 > from the registration of the care-of addresses assigned to=20 > the interface MN originally used to connect to the home link=20 > which is already defined in RFC 3775. >=20 >=20 > Regards, > =20 > Behcet >=20 > ________________________________ >=20 > From: Vijay Devarapalli > To: Behcet Sarikaya ; marcelo bagnulo=20 > braun > Cc: mext > Sent: Wednesday, April 22, 2009 6:43:13 PM > Subject: Re: [MEXT] [Fwd: I-D=20 > Action:draft-ietf-monami6-multiplecoa-13.txt] >=20 > Hi Bechet, >=20 > On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote: >=20 > > Hi Marcelo, > > How about this little paragraph? > > =20 > > In this document it is assumed that a multi-homed MN=20 > connects to the home link > > using only one interface. Therefore this interface is=20 > considered as the main > > interface as identified by the home address assigned by the=20 > home agent. >=20 > I disagree with this. The mobile node can connect to the home=20 > link through > any one of its interfaces. >=20 > > The=20 > > other or auxiliary interfaces may later on become active=20 > and connect to some > > other networks and get their care-of addresses and then the=20 > procedures defined > > in this document allow such care-of addresses to be=20 > registered with the home > > agent apart from the registration of the care-of addresses=20 > assigned to the > > main interface which is already defined in RFC 3775. >=20 > There is no need for the home agent to identify one of the=20 > interfaces as a > "main" interface. >=20 > Vijay >=20 > > Regards, > > =20 > > Behcet > >=20 > > From: marcelo bagnulo braun > > To: Behcet Sarikaya > > Cc: Ryuji Wakikawa ; mext > > Sent: Wednesday, April 22, 2009 4:59:50 PM > > Subject: Re: [MEXT] [Fwd: I-D=20 > Action:draft-ietf-monami6-multiplecoa-13.txt] > >=20 > > Hi Bechet, > >=20 > > could you send exactly what text do you think needs to be=20 > changed in the MCOA > > draft, so the WG can evaluate and figure out if the changes=20 > are needed? (i.e. > > please send OLD text NEW text) > >=20 > > Please note that at this point in the life of the document,=20 > we only take > > changes that fix errors in the document, rather than =20 > getting more features > > in. > >=20 > > Regards, marcelo > >=20 > >=20 > >=20 > > Behcet Sarikaya escribi=F3: > >> Hi Ryuji, > >> I checked your draft. Again, I could not understand how=20 > you are sending a > >> registration BU at the home link as only an O-flag is=20 > defined in your draft > >> which is used for something else. > >> As I mentioned to you, we discussed this related to=20 > draft-premec-homelink > >> and it seems like HA will reject such a BU unless=20 > something is done, I > >> thought you were familiar with the discussions as it=20 > relates to your draft > >> too. I am surprised. > >> Regards, > >> Behcet > >>=20 > >>=20 > -------------------------------------------------------------- > ---------- > >> *From:* Ryuji Wakikawa > >> *To:* Behcet Sarikaya > >> *Cc:* George Tsirtsis ; mext=20 > > >> *Sent:* Wednesday, April 22, 2009 4:18:28 PM > >> *Subject:* Re: [MEXT] [Fwd: I-D=20 > Action:draft-ietf-monami6-multiplecoa-13.txt] > >>=20 > >> Hi Behcet, > >>=20 > >> On 2009/04/22, at 11:31, Behcet Sarikaya wrote: > >>=20 > >>>=20 > >>>=20 > >>> From: George Tsirtsis >>> > > >>> To: Behcet Sarikaya > > >>> Cc: mext > > >>> Sent: Wednesday, April 22, 2009 10:10:08 AM > >>> Subject: Re: [MEXT] [Fwd: I-D=20 > Action:draft-ietf-monami6-multiplecoa-13.txt] > >>>=20 > >>> I do not think that adding home link registration to=20 > RFC3775bis is feasible. > >>> This requires logic in the MN and HA that is not directly=20 > compatible > >>> to RFC3775. The aim of RFC3775bis is to make minimal changes for > >>> clarification reasons and to correct errors. Home Link=20 > Registration as > >>> defined in MCoA is neither. > >>> [behcet] Why not? If it is needed in so many instances,=20 > that qualifies it to > >>> become a base protocol feature, at least to me. > >>=20 > >> We cannot add a new feature to 3775. That is the ground=20 > rule of -bis. The > >> chairs can clarify this. > >>=20 > >> regards, > >> ryuji > >>=20 > >>=20 > >>=20 > >>>=20 > >>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya > >>> > wrote: > >>>> Hi George, > >>>> It seems in my previous reply I replied to this mail of=20 > yours which was > >>>> unrelated to the other mail you sent to which I was=20 > really replying, > >>>> apologies. > >>>> Now regarding home link registration, what is the=20 > mechanism MCoA draft > >>>> uses? Ryuji mentioned some H bit but I read the draft=20 > and couldn't confirm > >>>> it. > >>>>=20 > >>>> My suggestion was building on this, i.e. I suggested=20 > that whatever you > >>>> came up with can be moved to 3775bis so that other=20 > people would not have to > >>>> make normative references to your draft. > >>>>=20 > >>>> That's all. > >>>>=20 > >>>> Regards, > >>>>=20 > >>>> Behcet > >>>>=20 > >>>> ________________________________ > >>>> From: George Tsirtsis >>>> > > >>>> To: Vijay Devarapalli > > >>>> Cc: Behcet Sarikaya >; mext > >>>> > > >>>> Sent: Tuesday, April 21, 2009 2:14:55 PM > >>>> Subject: Re: [MEXT] [Fwd: I-D=20 > Action:draft-ietf-monami6-multiplecoa-13.txt] > >>>>=20 > >>>> ...also wrt the home link registration, I do not think what you > >>>> suggest is necessary. > >>>>=20 > >>>> As far as I see the other documents are informational,=20 > and they do not > >>>> yet have a formal standing in the WG. If and when they do, as > >>>> Informational documents, they should not require=20 > normative changes to > >>>> anything. They should make sure what they describe (mostly > >>>> implementation options in this case) are compatible not only with > >>>> RFC3775 but also with extensions to it, including Flow=20 > Bindings. . > >>>>=20 > >>>>=20 > >>>> Regards > >>>> George > >>>>=20 > >>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli=20 > >>>> > > >>>> wrote: > >>>>> Behcet, > >>>>>=20 > >>>>> Behcet Sarikaya wrote: > >>>>>>=20 > >>>>>> *[behcet] Yes but each interface will appear to HA as=20 > a different device > >>>>>> and HA needs to assign a different HoA. Then MCoA=20 > problem disappears.* > >>>>>> *So George is saying that this is avoided by some=20 > virtual interfaces so > >>>>>> that HA does not see each interface separately. * > >>>>>> *Is this explained anywhere in the draft?* > >>>>>> *If yes then I am OK.* > >>>>>=20 > >>>>> The home agent does not care about the multiple=20 > interfaces on the mobile > >>>>> node. It only sees the mobile node as one entity and=20 > allocates a home > >>>>> address to it. The multiple care-of addresses that the=20 > mobile node has > >>>>> will > >>>>> be used by the home agent as tunnel end points. That is=20 > all.. So there is > >>>>> no > >>>>> issue. > >>>>>=20 > >>>>> Vijay > >>>>>=20 > >>>>>>> Also I have a question to Ryuji: does this draft send a > >>>>>> non-deregistration BU at the home link? If yes, is he=20 > familiar with the > >>>>>> discussion going on on this subject? This is another=20 > point of confusion > >>>>>> for > >>>>>> me. > >>>>>>=20 > >>>>>> This has been discussed for a long time in MEXT. > >>>>>> who is familiar with which discussions? I don't know=20 > your concern here. > >>>>>> *[behcet] So your answer is yes the draft sends a=20 > non-deregistration BU > >>>>>> (kind of bulk registration) at the home link.* > >>>>>> *The discussion I mentioned was related to > >>>>>> draft-premec-mext-extended-home-link. This draft also sends > >>>>>> non-deregistration BU at the home link. So does a few=20 > more drafts like > >>>>>> **draft-devarapalli-mext-mipv6-home-link.* > >>>>>>=20 > >>>>>> ** > >>>>>> *[behcet] You mentioned some bit is set but I could=20 > not understand which. > >>>>>> One idea is since so many drafts need this, why not=20 > factor this out and > >>>>>> define whatever the mechanism to enable sending=20 > non-deregistration BU in > >>>>>> 3775bis. What do you think about that?* > >>>>>>=20 > >>>>>> ** > >>>>>>=20 > >>>>>>> Sorry if I am too much confused > >>>>>>> Please don't get me wrong, I am not trying to slow=20 > down the progress > >>>>>> of > >>>>>> this document.. > >>>>>>=20 > >>>>>> sure, but please explain your issue more precisely. > >>>>>>=20 > >>>>>> thanks! > >>>>>> ryuji > >>>>>>=20 > >>>>>>>=20 > >>>>>>> Regards, > >>>>>>>=20 > >>>>>>> Behcet > >>>>>>> From: marcelo bagnulo braun >>>>>>> > >>>>>> >> > >>>>>>> To: mext =20 > >>>>>>> >>; Julien Laganier > >>>>>> >>>>>> > >>>>>> >>>>>> >>; Jari Arkko > >>>>>> =20 > > >>>>>> =20 > >>>>>> >>> > >>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM > >>>>>>> Subject: [MEXT] [Fwd: I-D > >>>>>> Action:draft-ietf-monami6-multiplecoa-13.txt] > >>>>>>>=20 > >>>>>>> We have this new version of the MCOA document that=20 > addresses the > >>>>>> comments received, including IESG review comments. > >>>>>>> To the best of my knowledge, the IESG is ok with the=20 > doc and ready for > >>>>>> publication.. > >>>>>>> I am planning to ask our AD to move forward in a week=20 > or so, so, if > >>>>>> you > >>>>>> have comments on the document please provide them=20 > before the 1st of may. > >>>>>>>=20 > >>>>>>> Regards, marcelo > >>>>>>> (mcoa doc shepherd) > >>>>>>>=20 > >>>>>>> -------- Mensaje original -------- > >>>>>>> Asunto: [MEXT] I-D=20 > Action:draft-ietf-monami6-multiplecoa-13.txt > >>>>>>> Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) > >>>>>>> De: Internet-Drafts@ietf.org=20 > > >>>>>>> > > >>>>>>> Para: i-d-announce@ietf.org > >>>>>>> > > >>>>>>> CC: mext@ietf.org > > >>>>>>> > > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>=20 > >>>>>>> A New Internet-Draft is available from the on-line=20 > Internet-Drafts > >>>>>> directories. > >>>>>>> This draft is a work item of the Mobility EXTensions=20 > for IPv6 Working > >>>>>> Group of the IETF.. > >>>>>>>=20 > >>>>>>>=20 > >>>>>>> Title : Multiple Care-of Addresses Registration > >>>>>>> Author(s) : R. Wakikawa, et al. > >>>>>>> Filename : draft-ietf-monami6-multiplecoa-13..txt > >>>>>>> Pages : 44 > >>>>>>> Date : 2009-04-20 > >>>>>>>=20 > >>>>>>> According to the current Mobile IPv6 specification, a=20 > mobile node may > >>>>>>> have several care-of addresses, but only one, called=20 > the primary > >>>>>>> care-of address, that can be registered with its home=20 > agent and the > >>>>>>> correspondent nodes. However, for matters of cost,=20 > bandwidth, delay, > >>>>>>> etc, it is useful for the mobile node to get Internet=20 > access through > >>>>>>> multiple accesses simultaneously, in which case the=20 > mobile node would > >>>>>>> be configured with multiple active IPv6 care-of=20 > addresses. This > >>>>>>> document proposes extensions to the Mobile IPv6=20 > protocol to register > >>>>>>> and use multiple care-of addresses. The extensions=20 > proposed in this > >>>>>>> document can be used by Mobile Routers using the NEMO (Network > >>>>>>> Mobility) Basic Support protocol as well. > >>>>>>>=20 > >>>>>>> A URL for this Internet-Draft is: > >>>>>>>=20 > >>>>>>=20 > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multipl ecoa-13.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=20 > mail reader > >>>>>>> implementation to automatically retrieve the ASCII=20 > version of the > >>>>>>> Internet-Draft. > >>>>>>>=20 > >>>>>>>=20 > >>>>>>>=20 > >>>>>>> _______________________________________________ > >>>>>>> MEXT mailing list > >>>>>>> MEXT@ietf.org >>>>>>> > > >>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > -------------------------------------------------------------- > ---------- > >>>>>>=20 > >>>>>> _______________________________________________ > >>>>>> MEXT mailing list > >>>>>> MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>=20 > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>=20 > >>>>=20 > >>>>=20 > >>>=20 > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/mext > >>=20 > >>=20 > >>=20 > -------------------------------------------------------------- > ---------- > >>=20 > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> =20 > >=20 > >=20 > > =20 > >=20 > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext >=20 >=20 >=20 >=20 From tsirtsis@googlemail.com Thu Apr 23 10:58:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADF293A731D for ; Thu, 23 Apr 2009 10:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 xIiK18+WMroi for ; Thu, 23 Apr 2009 10:58:36 -0700 (PDT) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by core3.amsl.com (Postfix) with ESMTP id 0A6C33A6DD0 for ; Thu, 23 Apr 2009 10:58:13 -0700 (PDT) Received: by gxk10 with SMTP id 10so1411141gxk.13 for ; Thu, 23 Apr 2009 10:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=5dZ13eRxdpQaQo8YtD52xp1lVwqpf1SuEth58k3nT5g=; b=kaE+eopVzyRII12gW/gPQfM1EutUSJhm2E+ZMUGZQgcTo/CUEUYIjG8XX7O+loCcb6 MxE9WVkytEM+lg5eUz4w7cTFMR0YUpeCQzmWPMMN0gaRYrcFY8YzLAk5p3YsbgnXBiaf KBYfOS4JHVHe4DBV/t/UGViHvaR4xdz040kLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DsyeB6a7sJCaF8GgD36XS0qV5ICOv02NIcurGlcpXDfR0c02oOJf+RdE+Mg2ty5z5T 4EWwaIJ/2al9uefS68nZM22gIYyXvBUUEqnY7fZU9WxURuyiBNYmfPNut/V1VR5zEbSh hJICIgdR0j0h+FL5uTPduVvCYQT1kSuEQkxKg= MIME-Version: 1.0 Received: by 10.90.93.8 with SMTP id q8mr1493162agb.72.1240509571674; Thu, 23 Apr 2009 10:59:31 -0700 (PDT) In-Reply-To: References: <471395.65157.qm@web111404.mail.gq1.yahoo.com> Date: Thu, 23 Apr 2009 18:59:31 +0100 Message-ID: From: George Tsirtsis To: Vijay Devarapalli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 17:58:37 -0000 On Thu, Apr 23, 2009 at 6:28 PM, Vijay Devarapalli wro= te: > I kind of understand what you are saying now. You are concerned about the= mobile node attaching to the home link via multiple interfaces (since it h= as multiple interfaces) and the result of assigning the home address to tho= se interfaces. > > As far as RFC 3775 and the MCoA draft is concerned, the home address is a= ssigned to first interface with which the mobile node attaches to the home = link. This may require the mobile node to "move" the home address from a MI= Pv6 virtual interface to the physical interface with which it attaches to t= he home link. This is implementation specific. > > If the mobile node attaches to the home link via a second interface, I th= ink the mobile node should get a new home address for that interface. Not t= he same home address. > GT> The MN would not be able to get the same home address even if it tried. At the time a node attaches an interface on a link, the Access Routers do not have any clue to what node this interface belongs or whether this node has other interfaces on or off link. All interfaces are assumed to have different IP addresses at that level. It is only after that, the MN communicates with the HA function in the local AR ( assuming that is where its HA is) establishes ONE of its addresses as home address. GT> Again I do not think there is anything to define here. > Does the above make sense? > > Vijay > >> -----Original Message----- >> From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] >> Sent: Thursday, April 23, 2009 8:54 AM >> To: Vijay Devarapalli; marcelo bagnulo braun >> Cc: mext >> Subject: Re: [MEXT] [Fwd: I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt] >> >> Hi Vijay, >> =C2=A0 I understand your concerns. >> >> Here is slightly revised version removing main and auxiliary: >> >> In this document it is assumed that a multi-homed MN connects >> to the home link using only one interface. This interface is >> identified by the home address assigned by the home agent. >> The other =C2=A0interfaces may later on become active and connect >> to some other networks and get their care-of addresses and >> then the procedures defined in this document allow such >> care-of addresses to be registered with the home agent apart >> from the registration of the care-of addresses assigned to >> the =C2=A0interface MN originally used to connect to the home link >> which is already defined in RFC 3775. >> >> >> Regards, >> >> Behcet >> >> ________________________________ >> >> From: Vijay Devarapalli >> To: Behcet Sarikaya ; marcelo bagnulo >> braun >> Cc: mext >> Sent: Wednesday, April 22, 2009 6:43:13 PM >> Subject: Re: [MEXT] [Fwd: I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt] >> >> Hi Bechet, >> >> On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote: >> >> > Hi Marcelo, >> > =C2=A0How about this little paragraph? >> > >> > In this document it is assumed that a multi-homed MN >> connects to the home link >> > using only one interface. Therefore this interface is >> considered as the main >> > interface as identified by the home address assigned by the >> home agent. >> >> I disagree with this. The mobile node can connect to the home >> link through >> any one of its interfaces. >> >> > The >> > other or auxiliary interfaces may later on become active >> and connect to some >> > other networks and get their care-of addresses and then the >> procedures defined >> > in this document allow such care-of addresses to be >> registered with the home >> > agent apart from the registration of the care-of addresses >> assigned to the >> > main interface which is already defined in RFC 3775. >> >> There is no need for the home agent to identify one of the >> interfaces as a >> "main" interface. >> >> Vijay >> >> > Regards, >> > >> > Behcet >> > >> > From: marcelo bagnulo braun >> > To: Behcet Sarikaya >> > Cc: Ryuji Wakikawa ; mext >> > Sent: Wednesday, April 22, 2009 4:59:50 PM >> > Subject: Re: [MEXT] [Fwd: I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt] >> > >> > Hi Bechet, >> > >> > could you send exactly what text do you think needs to be >> changed in the MCOA >> > draft, so the WG can evaluate and figure out if the changes >> are needed? (i.e. >> > please send OLD text NEW text) >> > >> > Please note that at this point in the life of the document, >> we only take >> > changes that fix errors in the document, rather than >> getting more features >> > in. >> > >> > Regards, marcelo >> > >> > >> > >> > Behcet Sarikaya escribi=C3=B3: >> >> Hi Ryuji, >> >> =C2=A0I checked your draft. Again, I could not understand how >> you are sending a >> >> registration BU at the home link as only an O-flag is >> defined in your draft >> >> which is used for something else. >> >> =C2=A0As I mentioned to you, we discussed this related to >> draft-premec-homelink >> >> and it seems like HA will reject such a BU unless >> something is done, I >> >> thought you were familiar with the discussions as it >> relates to your draft >> >> too. I am surprised. >> >> =C2=A0Regards, >> >> =C2=A0Behcet >> >> >> >> >> -------------------------------------------------------------- >> ---------- >> >> *From:* Ryuji Wakikawa >> >> *To:* Behcet Sarikaya >> >> *Cc:* George Tsirtsis ; mext >> >> >> *Sent:* Wednesday, April 22, 2009 4:18:28 PM >> >> *Subject:* Re: [MEXT] [Fwd: I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt] >> >> >> >> Hi Behcet, >> >> >> >> On 2009/04/22, at 11:31, Behcet Sarikaya wrote: >> >> >> >>> >> >>> >> >>> From: George Tsirtsis > >>> > >> >>> To: Behcet Sarikaya > >> >>> Cc: mext > >> >>> Sent: Wednesday, April 22, 2009 10:10:08 AM >> >>> Subject: Re: [MEXT] [Fwd: I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt] >> >>> >> >>> I do not think that adding home link registration to >> RFC3775bis is feasible. >> >>> This requires logic in the MN and HA that is not directly >> compatible >> >>> to RFC3775. The aim of RFC3775bis is to make minimal changes for >> >>> clarification reasons and to correct errors. Home Link >> Registration as >> >>> defined in MCoA is neither. >> >>> [behcet] Why not? If it is needed in so many instances, >> that qualifies it to >> >>> become a base protocol feature, at least to me. >> >> >> >> We cannot add a new feature to 3775. That is the ground >> rule of -bis. The >> >> chairs can clarify this. >> >> >> >> regards, >> >> ryuji >> >> >> >> >> >> >> >>> >> >>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya >> >>> > > wrote: >> >>>> Hi George, >> >>>> =C2=A0It seems in my previous reply I replied to this mail of >> yours which was >> >>>> unrelated to the other mail you sent to which I was >> really replying, >> >>>> apologies. >> >>>> =C2=A0Now regarding home link registration, what is the >> mechanism MCoA draft >> >>>> uses? Ryuji mentioned some H bit but I read the draft >> and couldn't confirm >> >>>> it. >> >>>> >> >>>> =C2=A0My suggestion was building on this, i.e. I suggested >> that whatever you >> >>>> came up with can be moved to 3775bis so that other >> people would not have to >> >>>> make normative references to your draft. >> >>>> >> >>>> That's all. >> >>>> >> >>>> Regards, >> >>>> >> >>>> Behcet >> >>>> >> >>>> ________________________________ >> >>>> From: George Tsirtsis > >>>> > >> >>>> To: Vijay Devarapalli > > >> >>>> Cc: Behcet Sarikaya > >; mext >> >>>> > >> >>>> Sent: Tuesday, April 21, 2009 2:14:55 PM >> >>>> Subject: Re: [MEXT] [Fwd: I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt] >> >>>> >> >>>> ...also wrt the home link registration, I do not think what you >> >>>> suggest is necessary. >> >>>> >> >>>> As far as I see the other documents are informational, >> and they do not >> >>>> yet have a formal standing in the WG. If and when they do, as >> >>>> Informational documents, =C2=A0they should not require >> normative changes to >> >>>> anything. They should make sure what they describe (mostly >> >>>> implementation options in this case) are compatible not only with >> >>>> RFC3775 but also with extensions to it, including Flow >> Bindings. . >> >>>> >> >>>> >> >>>> Regards >> >>>> George >> >>>> >> >>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli >> > >>>> > >> >>>> wrote: >> >>>>> Behcet, >> >>>>> >> >>>>> Behcet Sarikaya wrote: >> >>>>>> >> >>>>>> *[behcet] Yes but each interface will appear to HA as >> a different device >> >>>>>> and HA needs to assign a different HoA. Then MCoA >> problem disappears.* >> >>>>>> *So George is saying that this is avoided by some >> virtual interfaces so >> >>>>>> that HA does not see each interface separately. * >> >>>>>> *Is this explained anywhere in the draft?* >> >>>>>> *If yes then I am OK.* >> >>>>> >> >>>>> The home agent does not care about the multiple >> interfaces on the mobile >> >>>>> node. It only sees the mobile node as one entity and >> allocates a home >> >>>>> address to it. The multiple care-of addresses that the >> mobile node has >> >>>>> will >> >>>>> be used by the home agent as tunnel end points. That is >> all.. So there is >> >>>>> no >> >>>>> issue. >> >>>>> >> >>>>> Vijay >> >>>>> >> >>>>>>> =C2=A0Also I have a question to Ryuji: does this draft send a >> >>>>>> non-deregistration BU at the home link? If yes, is he >> familiar with the >> >>>>>> discussion going on on this subject? This is another >> point of confusion >> >>>>>> for >> >>>>>> me. >> >>>>>> >> >>>>>> This has been discussed for a long time in MEXT. >> >>>>>> who is familiar with which discussions? I don't know >> your concern here. >> >>>>>> =C2=A0*[behcet] So your answer is yes the draft sends a >> non-deregistration BU >> >>>>>> (kind of bulk registration) at the home link.* >> >>>>>> *The discussion I mentioned was related to >> >>>>>> draft-premec-mext-extended-home-link. This draft also sends >> >>>>>> non-deregistration BU at the home link. So does a few >> more drafts like >> >>>>>> **draft-devarapalli-mext-mipv6-home-link.* >> >>>>>> >> >>>>>> ** >> >>>>>> *[behcet] You mentioned some bit is set but I could >> not understand which. >> >>>>>> One idea is since so many drafts need this, why not >> factor this out and >> >>>>>> define whatever the mechanism to enable sending >> non-deregistration BU in >> >>>>>> 3775bis. What do you think about that?* >> >>>>>> >> >>>>>> ** >> >>>>>> >> >>>>>>> =C2=A0Sorry if I am too =C2=A0much confused >> >>>>>>> Please don't get me wrong, I am not trying to slow >> down the progress >> >>>>>> of >> >>>>>> this document.. >> >>>>>> >> >>>>>> sure, but please explain your issue more precisely. >> >>>>>> >> >>>>>> thanks! >> >>>>>> ryuji >> >>>>>> >> >>>>>>> >> >>>>>>> Regards, >> >>>>>>> >> >>>>>>> Behcet >> >>>>>>> From: marcelo bagnulo braun > >>>>>>> >> >>>>>> >> >> >>>>>>> To: mext >> > >>>>>>> >>; Julien Laganier >> >>>>>> > >>>>>> >> >>>>>> > >>>>>> >>; Jari Arkko >> >>>>>> >> >> >>>>>> > >> >>>>>> >>> >> >>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM >> >>>>>>> Subject: [MEXT] [Fwd: I-D >> >>>>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >> >>>>>>> >> >>>>>>> We have this new version of the MCOA document that >> addresses the >> >>>>>> comments received, including IESG review comments. >> >>>>>>> To the best of my knowledge, the IESG is ok with the >> doc and ready for >> >>>>>> publication.. >> >>>>>>> I am planning to ask our AD to move forward in a week >> or so, so, if >> >>>>>> you >> >>>>>> have comments on the document please provide them >> before the 1st of may. >> >>>>>>> >> >>>>>>> Regards, marcelo >> >>>>>>> (mcoa doc shepherd) >> >>>>>>> >> >>>>>>> -------- Mensaje original -------- >> >>>>>>> Asunto: =C2=A0 =C2=A0[MEXT] I-D >> Action:draft-ietf-monami6-multiplecoa-13.txt >> >>>>>>> Fecha: =C2=A0 =C2=A0Mon, 20 Apr 2009 08:30:01 -0700 (PDT) >> >>>>>>> De: =C2=A0 =C2=A0Internet-Drafts@ietf.org >> >> >>>>>>> > > >> >>>>>>> Para: =C2=A0 =C2=A0i-d-announce@ietf.org >> >>>>>>> > >> >>>>>>> CC: =C2=A0 =C2=A0mext@ietf.org > > >> >>>>>>> > >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> A New Internet-Draft is available from the on-line >> Internet-Drafts >> >>>>>> directories. >> >>>>>>> This draft is a work item of the Mobility EXTensions >> for IPv6 Working >> >>>>>> Group of the IETF.. >> >>>>>>> >> >>>>>>> >> >>>>>>> =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Multiple = Care-of Addresses Registration >> >>>>>>> =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0: R. Wakikawa, et al. >> >>>>>>> =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-mo= nami6-multiplecoa-13..txt >> >>>>>>> =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 44 >> >>>>>>> =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 200= 9-04-20 >> >>>>>>> >> >>>>>>> According to the current Mobile IPv6 specification, a >> mobile node may >> >>>>>>> have several care-of addresses, but only one, called >> the primary >> >>>>>>> care-of address, that can be registered with its home >> agent and the >> >>>>>>> correspondent nodes. =C2=A0However, for matters of cost, >> bandwidth, delay, >> >>>>>>> etc, it is useful for the mobile node to get Internet >> access through >> >>>>>>> multiple accesses simultaneously, in which case the >> mobile node would >> >>>>>>> be configured with multiple active IPv6 care-of >> addresses. =C2=A0This >> >>>>>>> document proposes extensions to the Mobile IPv6 >> protocol to register >> >>>>>>> and use multiple care-of addresses. =C2=A0The extensions >> proposed in this >> >>>>>>> document can be used by Mobile Routers using the NEMO (Network >> >>>>>>> Mobility) Basic Support protocol as well. >> >>>>>>> >> >>>>>>> A URL for this Internet-Draft is: >> >>>>>>> >> >>>>>> >> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multipl > ecoa-13.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. >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> MEXT mailing list >> >>>>>>> MEXT@ietf.org > >>>>>>> > >> >>>>>>> https://www.ietf.org/mailman/listinfo/mext >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> -------------------------------------------------------------- >> ---------- >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> MEXT mailing list >> >>>>>> MEXT@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/mext >> >>>>> >> >>>>> _______________________________________________ >> >>>>> MEXT mailing list >> >>>>> MEXT@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/mext >> >>>>> >> >>>> >> >>>> >> >>> >> >>> _______________________________________________ >> >>> MEXT mailing list >> >>> MEXT@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/mext >> >> >> >> >> >> >> -------------------------------------------------------------- >> ---------- >> >> >> >> _______________________________________________ >> >> MEXT mailing list >> >> MEXT@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mext >> >> >> > >> > >> > >> > >> > _______________________________________________ >> > MEXT mailing list >> > MEXT@ietf.org >> > https://www.ietf.org/mailman/listinfo/mext >> >> >> >> > From hesham@elevatemobile.com Thu Apr 23 11:06:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE2C3A68FB for ; Thu, 23 Apr 2009 11:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 R-HpGEv2i+bm for ; Thu, 23 Apr 2009 11:06:15 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 69BF03A6837 for ; Thu, 23 Apr 2009 11:06:14 -0700 (PDT) Received: from [60.224.64.196] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1Lx3Kc-00042S-Tk for ; Fri, 24 Apr 2009 04:07:31 +1000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Fri, 24 Apr 2009 04:07:28 +1000 From: Hesham Soliman To: mext Message-ID: Thread-Topic: [MEXT] Proposal for new Flow Idenfication option format Thread-Index: AcnELD+EeyCob6yVw0qyw5PdGk9VDQAEh09K In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [MEXT] FW: Proposal for new Flow Idenfication option format X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 18:06:16 -0000 Sorry forgot to cc the list ------ Forwarded Message > From: Hesham Soliman > Date: Fri, 24 Apr 2009 01:57:48 +1000 > To: Conny Larsson > Conversation: [MEXT] Proposal for new Flow Idenfication option format > Subject: Re: [MEXT] Proposal for new Flow Idenfication option format > > Hi Conny, > > The new option will support the different formats as we discussed, don't worry > :). The draft will be out soon. > > Hesham > > > On 23/04/09 8:49 PM, "Conny Larsson" wrote: > >> Hi Hesham, >> >> As there seems to be multiple proposals for the flow descriptor format I >> believe there is a need for a revised format of the Flow Identification >> option defined in draft-ietf-mext-flow-binding-01.txt. >> >> My proposal would be as follows: >> >> Flow Identification option: >> =========================== >> This option includes information about the type of flow identification >> format that follows. Exactly one option MUST be present in the message. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Option Type | Option Len | Format | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Option Type >> TBD >> >> Option Len >> Length of option in octets. >> >> Format >> 01 Format type 1 >> 02 Format type 2 >> >> >> >> Flow Descriptor: >> ================ >> This option identifies a specific flow. There MAY exist multiple >> Flow Descriptor options in one Flow Identification option >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Option Type | Option Len | Flow Description | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + >> . . >> . . >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Option Type >> TBD >> >> Option Len >> Length of the Flow Description in octets >> >> Flow Description >> Defined in a separate document per format type >> >> >> Regards >> Conny >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext ------ End of Forwarded Message From w52006@huawei.com Thu Apr 23 20:53:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66B573A6AAD for ; Thu, 23 Apr 2009 20:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.752, 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 PNOJNtBZVaHR for ; Thu, 23 Apr 2009 20:53:36 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C122A3A6ACF for ; Thu, 23 Apr 2009 20:53:35 -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 <0KIL005AR6UPOU@szxga04-in.huawei.com> for mext@ietf.org; Fri, 24 Apr 2009 11:54:25 +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 <0KIL00D156UPZB@szxga04-in.huawei.com> for mext@ietf.org; Fri, 24 Apr 2009 11:54:25 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIL00CDY6UOMS@szxml06-in.huawei.com> for mext@ietf.org; Fri, 24 Apr 2009 11:54:25 +0800 (CST) Date: Fri, 24 Apr 2009 11:54:25 +0800 From: Yungui Wang In-reply-to: To: 'Vijay Devarapalli' , 'Behcet Sarikaya' , 'marcelo bagnulo braun' Message-id: <006c01c9c490$5c1f7530$150ca40a@china.huawei.com> Organization: huawei 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=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcnEK6zGiE/dLqYhS56s+8FK1QVpwAADKTgAABWs4zA= Cc: 'mext' Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 03:53:38 -0000 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Vijay Devarapalli > Sent: Friday, April 24, 2009 1:29 AM > To: Behcet Sarikaya; marcelo bagnulo braun > Cc: mext > Subject: Re: [MEXT] [Fwd: I-D=20 > Action:draft-ietf-monami6-multiplecoa-13.txt] >=20 > I kind of understand what you are saying now. You are=20 > concerned about the mobile node attaching to the home link=20 > via multiple interfaces (since it has multiple interfaces)=20 > and the result of assigning the home address to those interfaces. >=20 > As far as RFC 3775 and the MCoA draft is concerned, the home=20 > address is assigned to first interface with which the mobile=20 > node attaches to the home link. This may require the mobile=20 > node to "move" the home address from a MIPv6 virtual=20 > interface to the physical interface with which it attaches to=20 > the home link. This is implementation specific.=20 >=20 > If the mobile node attaches to the home link via a second=20 > interface, I think the mobile node should get a new home=20 > address for that interface. Not the same home address.=20 >=20 [Yungui] In this case, in my mind, the question is, could we treat this new HoA as a (home) CoA binding to the primary HoA? If so, the service continuity could be guaranteed because this=20 interface is using the primary HoA. Otherwise, it seems the HA=20 has to initiate flow handover to another interface. Therefore, I think, Behcet's statement makes sense. B.R. Yungui > Does the above make sense? >=20 > Vijay=20 >=20 > > -----Original Message----- > > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 > > Sent: Thursday, April 23, 2009 8:54 AM > > To: Vijay Devarapalli; marcelo bagnulo braun > > Cc: mext > > Subject: Re: [MEXT] [Fwd: I-D=20 > > Action:draft-ietf-monami6-multiplecoa-13.txt] > >=20 > > Hi Vijay, > > I understand your concerns. > > =20 > > Here is slightly revised version removing main and auxiliary: > > =20 > > In this document it is assumed that a multi-homed MN connects=20 > > to the home link using only one interface. This interface is=20 > > identified by the home address assigned by the home agent. =20 > > The other interfaces may later on become active and connect=20 > > to some other networks and get their care-of addresses and=20 > > then the procedures defined in this document allow such=20 > > care-of addresses to be registered with the home agent apart=20 > > from the registration of the care-of addresses assigned to=20 > > the interface MN originally used to connect to the home link=20 > > which is already defined in RFC 3775. > >=20 > >=20 > > Regards, > > =20 > > Behcet > >=20 > > ________________________________ > >=20 > > From: Vijay Devarapalli > > To: Behcet Sarikaya ; marcelo bagnulo=20 > > braun > > Cc: mext > > Sent: Wednesday, April 22, 2009 6:43:13 PM > > Subject: Re: [MEXT] [Fwd: I-D=20 > > Action:draft-ietf-monami6-multiplecoa-13.txt] > >=20 > > Hi Bechet, > >=20 > > On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote: > >=20 > > > Hi Marcelo, > > > How about this little paragraph? > > > =20 > > > In this document it is assumed that a multi-homed MN=20 > > connects to the home link > > > using only one interface. Therefore this interface is=20 > > considered as the main > > > interface as identified by the home address assigned by the=20 > > home agent. > >=20 > > I disagree with this. The mobile node can connect to the home=20 > > link through > > any one of its interfaces. > >=20 > > > The=20 > > > other or auxiliary interfaces may later on become active=20 > > and connect to some > > > other networks and get their care-of addresses and then the=20 > > procedures defined > > > in this document allow such care-of addresses to be=20 > > registered with the home > > > agent apart from the registration of the care-of addresses=20 > > assigned to the > > > main interface which is already defined in RFC 3775. > >=20 > > There is no need for the home agent to identify one of the=20 > > interfaces as a > > "main" interface. > >=20 > > Vijay > >=20 > > > Regards, > > > =20 > > > Behcet > > >=20 > > > From: marcelo bagnulo braun > > > To: Behcet Sarikaya > > > Cc: Ryuji Wakikawa ; mext=20 > > > > Sent: Wednesday, April 22, 2009 4:59:50 PM > > > Subject: Re: [MEXT] [Fwd: I-D=20 > > Action:draft-ietf-monami6-multiplecoa-13.txt] > > >=20 > > > Hi Bechet, > > >=20 > > > could you send exactly what text do you think needs to be=20 > > changed in the MCOA > > > draft, so the WG can evaluate and figure out if the changes=20 > > are needed? (i.e. > > > please send OLD text NEW text) > > >=20 > > > Please note that at this point in the life of the document,=20 > > we only take > > > changes that fix errors in the document, rather than =20 > > getting more features > > > in. > > >=20 > > > Regards, marcelo > > >=20 > > >=20 > > >=20 > > > Behcet Sarikaya escribi=F3: > > >> Hi Ryuji, > > >> I checked your draft. Again, I could not understand how=20 > > you are sending a > > >> registration BU at the home link as only an O-flag is=20 > > defined in your draft > > >> which is used for something else. > > >> As I mentioned to you, we discussed this related to=20 > > draft-premec-homelink > > >> and it seems like HA will reject such a BU unless=20 > > something is done, I > > >> thought you were familiar with the discussions as it=20 > > relates to your draft > > >> too. I am surprised. > > >> Regards, > > >> Behcet > > >>=20 > > >>=20 > > -------------------------------------------------------------- > > ---------- > > >> *From:* Ryuji Wakikawa > > >> *To:* Behcet Sarikaya > > >> *Cc:* George Tsirtsis ; mext=20 > > > > >> *Sent:* Wednesday, April 22, 2009 4:18:28 PM > > >> *Subject:* Re: [MEXT] [Fwd: I-D=20 > > Action:draft-ietf-monami6-multiplecoa-13.txt] > > >>=20 > > >> Hi Behcet, > > >>=20 > > >> On 2009/04/22, at 11:31, Behcet Sarikaya wrote: > > >>=20 > > >>>=20 > > >>>=20 > > >>> From: George Tsirtsis > >>> > > > >>> To: Behcet Sarikaya > > > >>> Cc: mext > > > >>> Sent: Wednesday, April 22, 2009 10:10:08 AM > > >>> Subject: Re: [MEXT] [Fwd: I-D=20 > > Action:draft-ietf-monami6-multiplecoa-13.txt] > > >>>=20 > > >>> I do not think that adding home link registration to=20 > > RFC3775bis is feasible. > > >>> This requires logic in the MN and HA that is not directly=20 > > compatible > > >>> to RFC3775. The aim of RFC3775bis is to make minimal changes for > > >>> clarification reasons and to correct errors. Home Link=20 > > Registration as > > >>> defined in MCoA is neither. > > >>> [behcet] Why not? If it is needed in so many instances,=20 > > that qualifies it to > > >>> become a base protocol feature, at least to me. > > >>=20 > > >> We cannot add a new feature to 3775. That is the ground=20 > > rule of -bis. The > > >> chairs can clarify this. > > >>=20 > > >> regards, > > >> ryuji > > >>=20 > > >>=20 > > >>=20 > > >>>=20 > > >>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya > > >>> > > wrote: > > >>>> Hi George, > > >>>> It seems in my previous reply I replied to this mail of=20 > > yours which was > > >>>> unrelated to the other mail you sent to which I was=20 > > really replying, > > >>>> apologies. > > >>>> Now regarding home link registration, what is the=20 > > mechanism MCoA draft > > >>>> uses? Ryuji mentioned some H bit but I read the draft=20 > > and couldn't confirm > > >>>> it. > > >>>>=20 > > >>>> My suggestion was building on this, i.e. I suggested=20 > > that whatever you > > >>>> came up with can be moved to 3775bis so that other=20 > > people would not have to > > >>>> make normative references to your draft. > > >>>>=20 > > >>>> That's all. > > >>>>=20 > > >>>> Regards, > > >>>>=20 > > >>>> Behcet > > >>>>=20 > > >>>> ________________________________ > > >>>> From: George Tsirtsis > >>>> > > > >>>> To: Vijay Devarapalli > > > > >>>> Cc: Behcet Sarikaya > >; mext > > >>>> > > > >>>> Sent: Tuesday, April 21, 2009 2:14:55 PM > > >>>> Subject: Re: [MEXT] [Fwd: I-D=20 > > Action:draft-ietf-monami6-multiplecoa-13.txt] > > >>>>=20 > > >>>> ...also wrt the home link registration, I do not think what you > > >>>> suggest is necessary. > > >>>>=20 > > >>>> As far as I see the other documents are informational,=20 > > and they do not > > >>>> yet have a formal standing in the WG. If and when they do, as > > >>>> Informational documents, they should not require=20 > > normative changes to > > >>>> anything. They should make sure what they describe (mostly > > >>>> implementation options in this case) are compatible=20 > not only with > > >>>> RFC3775 but also with extensions to it, including Flow=20 > > Bindings. . > > >>>>=20 > > >>>>=20 > > >>>> Regards > > >>>> George > > >>>>=20 > > >>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli=20 > > > >>>> > > > >>>> wrote: > > >>>>> Behcet, > > >>>>>=20 > > >>>>> Behcet Sarikaya wrote: > > >>>>>>=20 > > >>>>>> *[behcet] Yes but each interface will appear to HA as=20 > > a different device > > >>>>>> and HA needs to assign a different HoA. Then MCoA=20 > > problem disappears.* > > >>>>>> *So George is saying that this is avoided by some=20 > > virtual interfaces so > > >>>>>> that HA does not see each interface separately. * > > >>>>>> *Is this explained anywhere in the draft?* > > >>>>>> *If yes then I am OK.* > > >>>>>=20 > > >>>>> The home agent does not care about the multiple=20 > > interfaces on the mobile > > >>>>> node. It only sees the mobile node as one entity and=20 > > allocates a home > > >>>>> address to it. The multiple care-of addresses that the=20 > > mobile node has > > >>>>> will > > >>>>> be used by the home agent as tunnel end points. That is=20 > > all.. So there is > > >>>>> no > > >>>>> issue. > > >>>>>=20 > > >>>>> Vijay > > >>>>>=20 > > >>>>>>> Also I have a question to Ryuji: does this draft send a > > >>>>>> non-deregistration BU at the home link? If yes, is he=20 > > familiar with the > > >>>>>> discussion going on on this subject? This is another=20 > > point of confusion > > >>>>>> for > > >>>>>> me. > > >>>>>>=20 > > >>>>>> This has been discussed for a long time in MEXT. > > >>>>>> who is familiar with which discussions? I don't know=20 > > your concern here. > > >>>>>> *[behcet] So your answer is yes the draft sends a=20 > > non-deregistration BU > > >>>>>> (kind of bulk registration) at the home link.* > > >>>>>> *The discussion I mentioned was related to > > >>>>>> draft-premec-mext-extended-home-link. This draft also sends > > >>>>>> non-deregistration BU at the home link. So does a few=20 > > more drafts like > > >>>>>> **draft-devarapalli-mext-mipv6-home-link.* > > >>>>>>=20 > > >>>>>> ** > > >>>>>> *[behcet] You mentioned some bit is set but I could=20 > > not understand which. > > >>>>>> One idea is since so many drafts need this, why not=20 > > factor this out and > > >>>>>> define whatever the mechanism to enable sending=20 > > non-deregistration BU in > > >>>>>> 3775bis. What do you think about that?* > > >>>>>>=20 > > >>>>>> ** > > >>>>>>=20 > > >>>>>>> Sorry if I am too much confused > > >>>>>>> Please don't get me wrong, I am not trying to slow=20 > > down the progress > > >>>>>> of > > >>>>>> this document.. > > >>>>>>=20 > > >>>>>> sure, but please explain your issue more precisely. > > >>>>>>=20 > > >>>>>> thanks! > > >>>>>> ryuji > > >>>>>>=20 > > >>>>>>>=20 > > >>>>>>> Regards, > > >>>>>>>=20 > > >>>>>>> Behcet > > >>>>>>> From: marcelo bagnulo braun > >>>>>>> > > >>>>>> >> > > >>>>>>> To: mext =20 > > > >>>>>>> >>; Julien Laganier > > >>>>>> > >>>>>> > > >>>>>> > >>>>>> >>; Jari Arkko > > >>>>>> =20 > > > > >>>>>> > =20 > > >>>>>> >>> > > >>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM > > >>>>>>> Subject: [MEXT] [Fwd: I-D > > >>>>>> Action:draft-ietf-monami6-multiplecoa-13.txt] > > >>>>>>>=20 > > >>>>>>> We have this new version of the MCOA document that=20 > > addresses the > > >>>>>> comments received, including IESG review comments. > > >>>>>>> To the best of my knowledge, the IESG is ok with the=20 > > doc and ready for > > >>>>>> publication.. > > >>>>>>> I am planning to ask our AD to move forward in a week=20 > > or so, so, if > > >>>>>> you > > >>>>>> have comments on the document please provide them=20 > > before the 1st of may. > > >>>>>>>=20 > > >>>>>>> Regards, marcelo > > >>>>>>> (mcoa doc shepherd) > > >>>>>>>=20 > > >>>>>>> -------- Mensaje original -------- > > >>>>>>> Asunto: [MEXT] I-D=20 > > Action:draft-ietf-monami6-multiplecoa-13.txt > > >>>>>>> Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) > > >>>>>>> De: Internet-Drafts@ietf.org=20 > > > > >>>>>>> > > > > >>>>>>> Para: i-d-announce@ietf.org=20 > > > >>>>>>> > > > >>>>>>> CC: mext@ietf.org > > > > >>>>>>> > > > >>>>>>>=20 > > >>>>>>>=20 > > >>>>>>>=20 > > >>>>>>> A New Internet-Draft is available from the on-line=20 > > Internet-Drafts > > >>>>>> directories. > > >>>>>>> This draft is a work item of the Mobility EXTensions=20 > > for IPv6 Working > > >>>>>> Group of the IETF.. > > >>>>>>>=20 > > >>>>>>>=20 > > >>>>>>> Title : Multiple Care-of Addresses Registration > > >>>>>>> Author(s) : R. Wakikawa, et al. > > >>>>>>> Filename : draft-ietf-monami6-multiplecoa-13..txt > > >>>>>>> Pages : 44 > > >>>>>>> Date : 2009-04-20 > > >>>>>>>=20 > > >>>>>>> According to the current Mobile IPv6 specification, a=20 > > mobile node may > > >>>>>>> have several care-of addresses, but only one, called=20 > > the primary > > >>>>>>> care-of address, that can be registered with its home=20 > > agent and the > > >>>>>>> correspondent nodes. However, for matters of cost,=20 > > bandwidth, delay, > > >>>>>>> etc, it is useful for the mobile node to get Internet=20 > > access through > > >>>>>>> multiple accesses simultaneously, in which case the=20 > > mobile node would > > >>>>>>> be configured with multiple active IPv6 care-of=20 > > addresses. This > > >>>>>>> document proposes extensions to the Mobile IPv6=20 > > protocol to register > > >>>>>>> and use multiple care-of addresses. The extensions=20 > > proposed in this > > >>>>>>> document can be used by Mobile Routers using the=20 > NEMO (Network > > >>>>>>> Mobility) Basic Support protocol as well. > > >>>>>>>=20 > > >>>>>>> A URL for this Internet-Draft is: > > >>>>>>>=20 > > >>>>>>=20 > > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multipl > ecoa-13.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=20 > > mail reader > > >>>>>>> implementation to automatically retrieve the ASCII=20 > > version of the > > >>>>>>> Internet-Draft. > > >>>>>>>=20 > > >>>>>>>=20 > > >>>>>>>=20 > > >>>>>>> _______________________________________________ > > >>>>>>> MEXT mailing list > > >>>>>>> MEXT@ietf.org > >>>>>>> > > > >>>>>>> https://www.ietf.org/mailman/listinfo/mext > > >>>>>>=20 > > >>>>>>=20 > > >>>>>>=20 > > >>>>>>=20 > > -------------------------------------------------------------- > > ---------- > > >>>>>>=20 > > >>>>>> _______________________________________________ > > >>>>>> MEXT mailing list > > >>>>>> MEXT@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/mext > > >>>>>=20 > > >>>>> _______________________________________________ > > >>>>> MEXT mailing list > > >>>>> MEXT@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/mext > > >>>>>=20 > > >>>>=20 > > >>>>=20 > > >>>=20 > > >>> _______________________________________________ > > >>> MEXT mailing list > > >>> MEXT@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/mext > > >>=20 > > >>=20 > > >>=20 > > -------------------------------------------------------------- > > ---------- > > >>=20 > > >> _______________________________________________ > > >> MEXT mailing list > > >> MEXT@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mext > > >> =20 > > >=20 > > >=20 > > > =20 > > >=20 > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > >=20 > >=20 > >=20 > >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From vijay@wichorus.com Thu Apr 23 22:32:13 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2E53A736A for ; Thu, 23 Apr 2009 22:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] 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 n0FuC+rwWRP2 for ; Thu, 23 Apr 2009 22:32:11 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 27C9E3A736C for ; Thu, 23 Apr 2009 22:31:18 -0700 (PDT) Received: from 67.161.28.136 ([67.161.28.136]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Fri, 24 Apr 2009 05:32:27 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 23 Apr 2009 22:32:18 -0700 From: Vijay Devarapalli To: , 'Behcet Sarikaya' , 'marcelo bagnulo braun' Message-ID: Thread-Topic: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] Thread-Index: AcnEK6zGiE/dLqYhS56s+8FK1QVpwAADKTgAABWs4zAAA8DH8w== In-Reply-To: <006c01c9c490$5c1f7530$150ca40a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: 'mext' Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 05:32:13 -0000 Hello, On 4/23/09 8:54 PM, "Yungui Wang" wrote: >> I kind of understand what you are saying now. You are >> concerned about the mobile node attaching to the home link >> via multiple interfaces (since it has multiple interfaces) >> and the result of assigning the home address to those interfaces. >>=20 >> As far as RFC 3775 and the MCoA draft is concerned, the home >> address is assigned to first interface with which the mobile >> node attaches to the home link. This may require the mobile >> node to "move" the home address from a MIPv6 virtual >> interface to the physical interface with which it attaches to >> the home link. This is implementation specific. >>=20 >> If the mobile node attaches to the home link via a second >> interface, I think the mobile node should get a new home >> address for that interface. Not the same home address. >>=20 > [Yungui] In this case, in my mind, the question is, could we treat > this new HoA as a (home) CoA binding to the primary HoA? > If so, the service continuity could be guaranteed because this > interface is using the primary HoA. That would be out of scope. As far as the current MCoA draft is concerned, there is no tunneling from the home link. Vijay > Otherwise, it seems the HA > has to initiate flow handover to another interface. > Therefore, I think, Behcet's statement makes sense. >=20 > B.R. > Yungui >=20 >> Does the above make sense? >>=20 >> Vijay=20 >>=20 >>> -----Original Message----- >>> From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] >>> Sent: Thursday, April 23, 2009 8:54 AM >>> To: Vijay Devarapalli; marcelo bagnulo braun >>> Cc: mext >>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>=20 >>> Hi Vijay, >>> I understand your concerns. >>> =20 >>> Here is slightly revised version removing main and auxiliary: >>> =20 >>> In this document it is assumed that a multi-homed MN connects >>> to the home link using only one interface. This interface is >>> identified by the home address assigned by the home agent. >>> The other interfaces may later on become active and connect >>> to some other networks and get their care-of addresses and >>> then the procedures defined in this document allow such >>> care-of addresses to be registered with the home agent apart >>> from the registration of the care-of addresses assigned to >>> the interface MN originally used to connect to the home link >>> which is already defined in RFC 3775. >>>=20 >>>=20 >>> Regards, >>> =20 >>> Behcet >>>=20 >>> ________________________________ >>>=20 >>> From: Vijay Devarapalli >>> To: Behcet Sarikaya ; marcelo bagnulo >>> braun >>> Cc: mext >>> Sent: Wednesday, April 22, 2009 6:43:13 PM >>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>=20 >>> Hi Bechet, >>>=20 >>> On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote: >>>=20 >>>> Hi Marcelo, >>>> How about this little paragraph? >>>> =20 >>>> In this document it is assumed that a multi-homed MN >>> connects to the home link >>>> using only one interface. Therefore this interface is >>> considered as the main >>>> interface as identified by the home address assigned by the >>> home agent. >>>=20 >>> I disagree with this. The mobile node can connect to the home >>> link through >>> any one of its interfaces. >>>=20 >>>> The=20 >>>> other or auxiliary interfaces may later on become active >>> and connect to some >>>> other networks and get their care-of addresses and then the >>> procedures defined >>>> in this document allow such care-of addresses to be >>> registered with the home >>>> agent apart from the registration of the care-of addresses >>> assigned to the >>>> main interface which is already defined in RFC 3775. >>>=20 >>> There is no need for the home agent to identify one of the >>> interfaces as a >>> "main" interface. >>>=20 >>> Vijay >>>=20 >>>> Regards, >>>> =20 >>>> Behcet >>>>=20 >>>> From: marcelo bagnulo braun >>>> To: Behcet Sarikaya >>>> Cc: Ryuji Wakikawa ; mext >> >>>> Sent: Wednesday, April 22, 2009 4:59:50 PM >>>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>=20 >>>> Hi Bechet, >>>>=20 >>>> could you send exactly what text do you think needs to be >>> changed in the MCOA >>>> draft, so the WG can evaluate and figure out if the changes >>> are needed? (i.e. >>>> please send OLD text NEW text) >>>>=20 >>>> Please note that at this point in the life of the document, >>> we only take >>>> changes that fix errors in the document, rather than >>> getting more features >>>> in. >>>>=20 >>>> Regards, marcelo >>>>=20 >>>>=20 >>>>=20 >>>> Behcet Sarikaya escribi=F3: >>>>> Hi Ryuji, >>>>> I checked your draft. Again, I could not understand how >>> you are sending a >>>>> registration BU at the home link as only an O-flag is >>> defined in your draft >>>>> which is used for something else. >>>>> As I mentioned to you, we discussed this related to >>> draft-premec-homelink >>>>> and it seems like HA will reject such a BU unless >>> something is done, I >>>>> thought you were familiar with the discussions as it >>> relates to your draft >>>>> too. I am surprised. >>>>> Regards, >>>>> Behcet >>>>>=20 >>>>>=20 >>> -------------------------------------------------------------- >>> ---------- >>>>> *From:* Ryuji Wakikawa >>>>> *To:* Behcet Sarikaya >>>>> *Cc:* George Tsirtsis ; mext >>> >>>>> *Sent:* Wednesday, April 22, 2009 4:18:28 PM >>>>> *Subject:* Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>=20 >>>>> Hi Behcet, >>>>>=20 >>>>> On 2009/04/22, at 11:31, Behcet Sarikaya wrote: >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From: George Tsirtsis >>>>> > >>>>>> To: Behcet Sarikaya > > >>>>>> Cc: mext > >>>>>> Sent: Wednesday, April 22, 2009 10:10:08 AM >>>>>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>=20 >>>>>> I do not think that adding home link registration to >>> RFC3775bis is feasible. >>>>>> This requires logic in the MN and HA that is not directly >>> compatible >>>>>> to RFC3775. The aim of RFC3775bis is to make minimal changes for >>>>>> clarification reasons and to correct errors. Home Link >>> Registration as >>>>>> defined in MCoA is neither. >>>>>> [behcet] Why not? If it is needed in so many instances, >>> that qualifies it to >>>>>> become a base protocol feature, at least to me. >>>>>=20 >>>>> We cannot add a new feature to 3775. That is the ground >>> rule of -bis. The >>>>> chairs can clarify this. >>>>>=20 >>>>> regards, >>>>> ryuji >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya >>>>>> >> > wrote: >>>>>>> Hi George, >>>>>>> It seems in my previous reply I replied to this mail of >>> yours which was >>>>>>> unrelated to the other mail you sent to which I was >>> really replying, >>>>>>> apologies. >>>>>>> Now regarding home link registration, what is the >>> mechanism MCoA draft >>>>>>> uses? Ryuji mentioned some H bit but I read the draft >>> and couldn't confirm >>>>>>> it. >>>>>>>=20 >>>>>>> My suggestion was building on this, i.e. I suggested >>> that whatever you >>>>>>> came up with can be moved to 3775bis so that other >>> people would not have to >>>>>>> make normative references to your draft. >>>>>>>=20 >>>>>>> That's all. >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Behcet >>>>>>>=20 >>>>>>> ________________________________ >>>>>>> From: George Tsirtsis >>>>>> > >>>>>>> To: Vijay Devarapalli >> > >>>>>>> Cc: Behcet Sarikaya >> >; mext >>>>>>> > >>>>>>> Sent: Tuesday, April 21, 2009 2:14:55 PM >>>>>>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>>=20 >>>>>>> ...also wrt the home link registration, I do not think what you >>>>>>> suggest is necessary. >>>>>>>=20 >>>>>>> As far as I see the other documents are informational, >>> and they do not >>>>>>> yet have a formal standing in the WG. If and when they do, as >>>>>>> Informational documents, they should not require >>> normative changes to >>>>>>> anything. They should make sure what they describe (mostly >>>>>>> implementation options in this case) are compatible >> not only with >>>>>>> RFC3775 but also with extensions to it, including Flow >>> Bindings. . >>>>>>>=20 >>>>>>>=20 >>>>>>> Regards >>>>>>> George >>>>>>>=20 >>>>>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli >>> >>>>>> > >>>>>>> wrote: >>>>>>>> Behcet, >>>>>>>>=20 >>>>>>>> Behcet Sarikaya wrote: >>>>>>>>>=20 >>>>>>>>> *[behcet] Yes but each interface will appear to HA as >>> a different device >>>>>>>>> and HA needs to assign a different HoA. Then MCoA >>> problem disappears.* >>>>>>>>> *So George is saying that this is avoided by some >>> virtual interfaces so >>>>>>>>> that HA does not see each interface separately. * >>>>>>>>> *Is this explained anywhere in the draft?* >>>>>>>>> *If yes then I am OK.* >>>>>>>>=20 >>>>>>>> The home agent does not care about the multiple >>> interfaces on the mobile >>>>>>>> node. It only sees the mobile node as one entity and >>> allocates a home >>>>>>>> address to it. The multiple care-of addresses that the >>> mobile node has >>>>>>>> will >>>>>>>> be used by the home agent as tunnel end points. That is >>> all.. So there is >>>>>>>> no >>>>>>>> issue. >>>>>>>>=20 >>>>>>>> Vijay >>>>>>>>=20 >>>>>>>>>> Also I have a question to Ryuji: does this draft send a >>>>>>>>> non-deregistration BU at the home link? If yes, is he >>> familiar with the >>>>>>>>> discussion going on on this subject? This is another >>> point of confusion >>>>>>>>> for >>>>>>>>> me. >>>>>>>>>=20 >>>>>>>>> This has been discussed for a long time in MEXT. >>>>>>>>> who is familiar with which discussions? I don't know >>> your concern here. >>>>>>>>> *[behcet] So your answer is yes the draft sends a >>> non-deregistration BU >>>>>>>>> (kind of bulk registration) at the home link.* >>>>>>>>> *The discussion I mentioned was related to >>>>>>>>> draft-premec-mext-extended-home-link. This draft also sends >>>>>>>>> non-deregistration BU at the home link. So does a few >>> more drafts like >>>>>>>>> **draft-devarapalli-mext-mipv6-home-link.* >>>>>>>>>=20 >>>>>>>>> ** >>>>>>>>> *[behcet] You mentioned some bit is set but I could >>> not understand which. >>>>>>>>> One idea is since so many drafts need this, why not >>> factor this out and >>>>>>>>> define whatever the mechanism to enable sending >>> non-deregistration BU in >>>>>>>>> 3775bis. What do you think about that?* >>>>>>>>>=20 >>>>>>>>> ** >>>>>>>>>=20 >>>>>>>>>> Sorry if I am too much confused >>>>>>>>>> Please don't get me wrong, I am not trying to slow >>> down the progress >>>>>>>>> of >>>>>>>>> this document.. >>>>>>>>>=20 >>>>>>>>> sure, but please explain your issue more precisely. >>>>>>>>>=20 >>>>>>>>> thanks! >>>>>>>>> ryuji >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Behcet >>>>>>>>>> From: marcelo bagnulo braun >>>>>>>>> >>>>>>>>> >> >>>>>>>>>> To: mext >>> >>>>>>>>> >>; Julien Laganier >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>; Jari Arkko >>>>>>>>> >>> >>>>>>>>> >> >>>>>>>>> >>> >>>>>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM >>>>>>>>>> Subject: [MEXT] [Fwd: I-D >>>>>>>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>>>>>=20 >>>>>>>>>> We have this new version of the MCOA document that >>> addresses the >>>>>>>>> comments received, including IESG review comments. >>>>>>>>>> To the best of my knowledge, the IESG is ok with the >>> doc and ready for >>>>>>>>> publication.. >>>>>>>>>> I am planning to ask our AD to move forward in a week >>> or so, so, if >>>>>>>>> you >>>>>>>>> have comments on the document please provide them >>> before the 1st of may. >>>>>>>>>>=20 >>>>>>>>>> Regards, marcelo >>>>>>>>>> (mcoa doc shepherd) >>>>>>>>>>=20 >>>>>>>>>> -------- Mensaje original -------- >>>>>>>>>> Asunto: [MEXT] I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt >>>>>>>>>> Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) >>>>>>>>>> De: Internet-Drafts@ietf.org >>> >>>>>>>>>> >> > >>>>>>>>>> Para: i-d-announce@ietf.org >> >>>>>>>>>> > > >>>>>>>>>> CC: mext@ietf.org >> > >>>>>>>>>> > >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> A New Internet-Draft is available from the on-line >>> Internet-Drafts >>>>>>>>> directories. >>>>>>>>>> This draft is a work item of the Mobility EXTensions >>> for IPv6 Working >>>>>>>>> Group of the IETF.. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Title : Multiple Care-of Addresses Registration >>>>>>>>>> Author(s) : R. Wakikawa, et al. >>>>>>>>>> Filename : draft-ietf-monami6-multiplecoa-13..txt >>>>>>>>>> Pages : 44 >>>>>>>>>> Date : 2009-04-20 >>>>>>>>>>=20 >>>>>>>>>> According to the current Mobile IPv6 specification, a >>> mobile node may >>>>>>>>>> have several care-of addresses, but only one, called >>> the primary >>>>>>>>>> care-of address, that can be registered with its home >>> agent and the >>>>>>>>>> correspondent nodes. However, for matters of cost, >>> bandwidth, delay, >>>>>>>>>> etc, it is useful for the mobile node to get Internet >>> access through >>>>>>>>>> multiple accesses simultaneously, in which case the >>> mobile node would >>>>>>>>>> be configured with multiple active IPv6 care-of >>> addresses. This >>>>>>>>>> document proposes extensions to the Mobile IPv6 >>> protocol to register >>>>>>>>>> and use multiple care-of addresses. The extensions >>> proposed in this >>>>>>>>>> document can be used by Mobile Routers using the >> NEMO (Network >>>>>>>>>> Mobility) Basic Support protocol as well. >>>>>>>>>>=20 >>>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>>>=20 >>>>>>>>>=20 >>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multipl >> ecoa-13.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 >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>> -------------------------------------------------------------- >>> ---------- >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>>>=20 >>>>>=20 >>> -------------------------------------------------------------- >>> ---------- >>>>>=20 >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> =20 >>>>=20 >>>>=20 >>>> =20 >>>>=20 >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>>=20 >>>=20 >>>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >>=20 >=20 From behcetsarikaya@yahoo.com Fri Apr 24 15:33:23 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824D63A681C for ; Fri, 24 Apr 2009 15:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_00=-2.599, HTML_IMAGE_ONLY_20=1.546, 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 7kjml0BwYshk for ; Fri, 24 Apr 2009 15:33:22 -0700 (PDT) Received: from n9.bullet.re3.yahoo.com (n9.bullet.re3.yahoo.com [68.142.237.94]) by core3.amsl.com (Postfix) with SMTP id 733C13A67EB for ; Fri, 24 Apr 2009 15:33:22 -0700 (PDT) Received: from [68.142.237.88] by n9.bullet.re3.yahoo.com with NNFMP; 24 Apr 2009 22:34:40 -0000 Received: from [67.195.9.82] by t4.bullet.re3.yahoo.com with NNFMP; 24 Apr 2009 22:34:40 -0000 Received: from [67.195.9.103] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 24 Apr 2009 22:34:40 -0000 Received: from [127.0.0.1] by omp107.mail.gq1.yahoo.com with NNFMP; 24 Apr 2009 22:34:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 334637.57401.bm@omp107.mail.gq1.yahoo.com Received: (qmail 91905 invoked by uid 60001); 24 Apr 2009 22:34:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240612480; bh=FMHTFky9K9WP55677+5z4WHzVqUiStWlN5nmEAc6aag=; 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=A0aFwI36yaJzzy61dJFzzl0nSspQxr0IvsUCi68b+pRxC1kgCbr8kLlvglan+bEINp5vTwUD/SbFSfba1bWxpKndcfENXtE7ZNovf35eY5I+ZQYGN/+PJcCzdQ/XkGkxGiI9qXEBWBO2bB2lHsJOgl7wnhu5cNWDblQmTebzSNQ= 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=lrisYQOPiIuJqhd6gpIrREF4/JKagQ3mq0ZwLmB1PljdwfCOwEfyflTDEGSThI8cZZEbUr6605INrgZX/g8Ng0RDyew42UrjbE2SYjPhGcIqwKyin5DJegeE8MXWVx89SqfZr+9urWpJowsEKuPOFYFZDqHvnaQ7d2dzJvYv+qI=; Message-ID: <469998.91465.qm@web111410.mail.gq1.yahoo.com> X-YMail-OSG: hLd9VLUVM1nvuFwzyZ5BRSprjO18ok6xzrr5dattXbPsUTTbbfOZckFkII_xHCBJjNH2zspujeFpqWTiWgAZcRmIjdniHaX47bYuHSu55YOh2bhpijzcfZP7M1HjNrjZ6JIde_JYZEn2vUm6bKpHmcnKxcfqRgl.ZcOQpr7eTM.RypperLJ7dxIq4YQsTDrfEfIWHUf5CLWB27V6uzD3xtO8qvr2.IZ7DqPsCe.Wq83GlQNCvxB9OWidpnPbjBDXS8QmFpk9xxr2qFruObToZscEjlPP9cB6ycR2lJpA0jBz541H3gv6OTTNOry4W_BHfqwowg-- Received: from [206.16.17.212] by web111410.mail.gq1.yahoo.com via HTTP; Fri, 24 Apr 2009 15:34:40 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: <471395.65157.qm@web111404.mail.gq1.yahoo.com> Date: Fri, 24 Apr 2009 15:34:40 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis , Vijay Devarapalli In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-57373454-1240612480=:91465" Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 22:33:23 -0000 --0-57373454-1240612480=:91465 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0AGT> The MN would not be able to get the same home address even if it= =0Atried. At the time a node attaches an interface on a link, the Access=0A= Routers do not have any clue to what node this interface belongs or=0Awheth= er this node has other interfaces on or off link. All interfaces=0Aare assu= med to have different IP addresses at that level. It is only=0Aafter that, = the MN communicates with the HA function in the local AR (=0Aassuming that = is where its HA is) establishes ONE of its addresses as=0Ahome address.=0A= =0A[behcet] Yes I agree but which ONE? I think that's where we need clarifi= cation. As Vijay says MN may connect the home link over multiple interfaces= , etc.=0AThe text I proposed has the purpose of clarifying these. It is pro= bably suggesting some restrictions and maybe that's why you are not happy = =0AWe are saying that you should not be at the home link and roaming at the= same time. I think this is a fair=A0assumption to make.=0A=A0=0AWhat do yo= u think?=0A=0ARegards,=0A=A0=0ABehcet=0A=A0=0AI removed the rest as it was = getting so big.=0A=0A=0A --0-57373454-1240612480=:91465 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=0A


GT> The MN wou= ld not be able to get the same home address even if it
tried. At the tim= e a node attaches an interface on a link, the Access
Routers do not have= any clue to what node this interface belongs or
whether this node has o= ther interfaces on or off link. All interfaces
are assumed to have diffe= rent IP addresses at that level. It is only
after that, the MN communica= tes with the HA function in the local AR (
assuming that is where its HA= is) establishes ONE of its addresses as
home address.
=0A

= [behcet] Yes I agree but which ONE? I think t= hat's where we need clarification. As Vijay says MN may connect the home li= nk over multiple interfaces, etc.
=0A
The text I proposed has the purpose of clarifying these. = It is probably suggesting some restrictions and maybe that's why you are no= t happy =
=0A
<= STRONG>We are saying that you should not be at the home link and roaming at= the same time. I think this is a fair assumption to make.
=0A
 =0A
What do you think?=0A

Regards,=0A
 
=0A
= Behcet
=0A
 
=0A
I removed the rest as it was getting so big.

=0A=0A=0A=0A --0-57373454-1240612480=:91465-- From w52006@huawei.com Fri Apr 24 17:49:16 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6083A6920 for ; Fri, 24 Apr 2009 17:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 0Ml6NusE571J for ; Fri, 24 Apr 2009 17:49:13 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BCDB63A6867 for ; Fri, 24 Apr 2009 17:49:12 -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 <0KIM00A87SZWJB@szxga03-in.huawei.com> for mext@ietf.org; Sat, 25 Apr 2009 08:50:21 +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 <0KIM008Z3SZWJM@szxga03-in.huawei.com> for mext@ietf.org; Sat, 25 Apr 2009 08:50:20 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIM0047BSZWQQ@szxml06-in.huawei.com> for mext@ietf.org; Sat, 25 Apr 2009 08:50:20 +0800 (CST) Date: Sat, 25 Apr 2009 08:50:19 +0800 From: Yungui Wang In-reply-to: To: 'Vijay Devarapalli' , 'Behcet Sarikaya' , 'marcelo bagnulo braun' Message-id: <005c01c9c53f$ceef2380$150ca40a@china.huawei.com> Organization: huawei 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_sQ9icvjKUghxD/GyBNteog)" Thread-index: AcnEK6zGiE/dLqYhS56s+8FK1QVpwAADKTgAABWs4zAAA8DH8wAm45/Q Cc: 'mext' Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 00:49:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_sQ9icvjKUghxD/GyBNteog) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hello _____ =20 From: Vijay Devarapalli [mailto:vijay@wichorus.com]=20 Sent: Friday, April 24, 2009 1:32 PM To: w52006@huawei.com; Behcet Sarikaya; marcelo bagnulo braun Cc: mext Subject: Re: [MEXT] [Fwd: I-D = Action:draft-ietf-monami6-multiplecoa-13.txt] Hello, On 4/23/09 8:54 PM, "Yungui Wang" wrote: >> I kind of understand what you are saying now. You are >> concerned about the mobile node attaching to the home link >> via multiple interfaces (since it has multiple interfaces) >> and the result of assigning the home address to those interfaces. >> >> As far as RFC 3775 and the MCoA draft is concerned, the home >> address is assigned to first interface with which the mobile >> node attaches to the home link. This may require the mobile >> node to "move" the home address from a MIPv6 virtual >> interface to the physical interface with which it attaches to >> the home link. This is implementation specific. >> >> If the mobile node attaches to the home link via a second >> interface, I think the mobile node should get a new home >> address for that interface. Not the same home address. >> > [Yungui] In this case, in my mind, the question is, could we treat > this new HoA as a (home) CoA binding to the primary HoA? > If so, the service continuity could be guaranteed because this > interface is using the primary HoA. That would be out of scope. As far as the current MCoA draft is = concerned, there is no tunneling from the home link. =20 As MCoA I-D described, when MN is located in foreign link=20 and home link in parallel, its interface returning home may=20 register a home binding with its (HoA, CoA). Here CoA is=20 set to HoA. Due to there are two HoA in above situation,=20 maybe it needs to be clarified something, such as=20 'what's the just HoA set to CoA in home binding for the=20 second interface'; or=20 'the second interface returning home is not supported'; or 'the second interface returning home is implicitly de-registered=20 from MCoA registration'; etc. If it is out of scope, obviously some ambiguous operation is left. =20 In addition, tunneling may be not necessary for the second=20 interface at home link. It need also register its Link-layer=20 Address Option for packet forwarding. The I-D can give a=20 note that HA shall use link-layer address to forward downlink packet once it is presented. =20 B.R. Yungui =20 =20 Vijay > Otherwise, it seems the HA > has to initiate flow handover to another interface. > Therefore, I think, Behcet's statement makes sense. > > B.R. > Yungui > >> Does the above make sense? >> >> Vijay >> >>> -----Original Message----- >>> From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] >>> Sent: Thursday, April 23, 2009 8:54 AM >>> To: Vijay Devarapalli; marcelo bagnulo braun >>> Cc: mext >>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>> >>> Hi Vijay, >>> I understand your concerns. >>>=20 >>> Here is slightly revised version removing main and auxiliary: >>>=20 >>> In this document it is assumed that a multi-homed MN connects >>> to the home link using only one interface. This interface is >>> identified by the home address assigned by the home agent. >>> The other interfaces may later on become active and connect >>> to some other networks and get their care-of addresses and >>> then the procedures defined in this document allow such >>> care-of addresses to be registered with the home agent apart >>> from the registration of the care-of addresses assigned to >>> the interface MN originally used to connect to the home link >>> which is already defined in RFC 3775. >>> >>> >>> Regards, >>>=20 >>> Behcet >>> >>> ________________________________ >>> >>> From: Vijay Devarapalli >>> To: Behcet Sarikaya ; marcelo bagnulo >>> braun >>> Cc: mext >>> Sent: Wednesday, April 22, 2009 6:43:13 PM >>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>> >>> Hi Bechet, >>> >>> On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote: >>> >>>> Hi Marcelo, >>>> How about this little paragraph? >>>>=20 >>>> In this document it is assumed that a multi-homed MN >>> connects to the home link >>>> using only one interface. Therefore this interface is >>> considered as the main >>>> interface as identified by the home address assigned by the >>> home agent. >>> >>> I disagree with this. The mobile node can connect to the home >>> link through >>> any one of its interfaces. >>> >>>> The >>>> other or auxiliary interfaces may later on become active >>> and connect to some >>>> other networks and get their care-of addresses and then the >>> procedures defined >>>> in this document allow such care-of addresses to be >>> registered with the home >>>> agent apart from the registration of the care-of addresses >>> assigned to the >>>> main interface which is already defined in RFC 3775. >>> >>> There is no need for the home agent to identify one of the >>> interfaces as a >>> "main" interface. >>> >>> Vijay >>> >>>> Regards, >>>>=20 >>>> Behcet >>>> >>>> From: marcelo bagnulo braun >>>> To: Behcet Sarikaya >>>> Cc: Ryuji Wakikawa ; mext >> >>>> Sent: Wednesday, April 22, 2009 4:59:50 PM >>>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>> >>>> Hi Bechet, >>>> >>>> could you send exactly what text do you think needs to be >>> changed in the MCOA >>>> draft, so the WG can evaluate and figure out if the changes >>> are needed? (i.e. >>>> please send OLD text NEW text) >>>> >>>> Please note that at this point in the life of the document, >>> we only take >>>> changes that fix errors in the document, rather than >>> getting more features >>>> in. >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> Behcet Sarikaya escribi=F3: >>>>> Hi Ryuji, >>>>> I checked your draft. Again, I could not understand how >>> you are sending a >>>>> registration BU at the home link as only an O-flag is >>> defined in your draft >>>>> which is used for something else. >>>>> As I mentioned to you, we discussed this related to >>> draft-premec-homelink >>>>> and it seems like HA will reject such a BU unless >>> something is done, I >>>>> thought you were familiar with the discussions as it >>> relates to your draft >>>>> too. I am surprised. >>>>> Regards, >>>>> Behcet >>>>> >>>>> >>> -------------------------------------------------------------- >>> ---------- >>>>> *From:* Ryuji Wakikawa >>>>> *To:* Behcet Sarikaya >>>>> *Cc:* George Tsirtsis ; mext >>> >>>>> *Sent:* Wednesday, April 22, 2009 4:18:28 PM >>>>> *Subject:* Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>> >>>>> Hi Behcet, >>>>> >>>>> On 2009/04/22, at 11:31, Behcet Sarikaya wrote: >>>>> >>>>>> >>>>>> >>>>>> From: George Tsirtsis >>>>> > >>>>>> To: Behcet Sarikaya > > >>>>>> Cc: mext > >>>>>> Sent: Wednesday, April 22, 2009 10:10:08 AM >>>>>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>> >>>>>> I do not think that adding home link registration to >>> RFC3775bis is feasible. >>>>>> This requires logic in the MN and HA that is not directly >>> compatible >>>>>> to RFC3775. The aim of RFC3775bis is to make minimal changes for >>>>>> clarification reasons and to correct errors. Home Link >>> Registration as >>>>>> defined in MCoA is neither. >>>>>> [behcet] Why not? If it is needed in so many instances, >>> that qualifies it to >>>>>> become a base protocol feature, at least to me. >>>>> >>>>> We cannot add a new feature to 3775. That is the ground >>> rule of -bis. The >>>>> chairs can clarify this. >>>>> >>>>> regards, >>>>> ryuji >>>>> >>>>> >>>>> >>>>>> >>>>>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya >>>>>> >> > wrote: >>>>>>> Hi George, >>>>>>> It seems in my previous reply I replied to this mail of >>> yours which was >>>>>>> unrelated to the other mail you sent to which I was >>> really replying, >>>>>>> apologies. >>>>>>> Now regarding home link registration, what is the >>> mechanism MCoA draft >>>>>>> uses? Ryuji mentioned some H bit but I read the draft >>> and couldn't confirm >>>>>>> it. >>>>>>> >>>>>>> My suggestion was building on this, i.e. I suggested >>> that whatever you >>>>>>> came up with can be moved to 3775bis so that other >>> people would not have to >>>>>>> make normative references to your draft. >>>>>>> >>>>>>> That's all. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>>> >>>>>>> ________________________________ >>>>>>> From: George Tsirtsis >>>>>> > >>>>>>> To: Vijay Devarapalli >> > >>>>>>> Cc: Behcet Sarikaya >> >; mext >>>>>>> > >>>>>>> Sent: Tuesday, April 21, 2009 2:14:55 PM >>>>>>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>> >>>>>>> ...also wrt the home link registration, I do not think what you >>>>>>> suggest is necessary. >>>>>>> >>>>>>> As far as I see the other documents are informational, >>> and they do not >>>>>>> yet have a formal standing in the WG. If and when they do, as >>>>>>> Informational documents, they should not require >>> normative changes to >>>>>>> anything. They should make sure what they describe (mostly >>>>>>> implementation options in this case) are compatible >> not only with >>>>>>> RFC3775 but also with extensions to it, including Flow >>> Bindings. . >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> George >>>>>>> >>>>>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli >>> >>>>>> > >>>>>>> wrote: >>>>>>>> Behcet, >>>>>>>> >>>>>>>> Behcet Sarikaya wrote: >>>>>>>>> >>>>>>>>> *[behcet] Yes but each interface will appear to HA as >>> a different device >>>>>>>>> and HA needs to assign a different HoA. Then MCoA >>> problem disappears.* >>>>>>>>> *So George is saying that this is avoided by some >>> virtual interfaces so >>>>>>>>> that HA does not see each interface separately. * >>>>>>>>> *Is this explained anywhere in the draft?* >>>>>>>>> *If yes then I am OK.* >>>>>>>> >>>>>>>> The home agent does not care about the multiple >>> interfaces on the mobile >>>>>>>> node. It only sees the mobile node as one entity and >>> allocates a home >>>>>>>> address to it. The multiple care-of addresses that the >>> mobile node has >>>>>>>> will >>>>>>>> be used by the home agent as tunnel end points. That is >>> all.. So there is >>>>>>>> no >>>>>>>> issue. >>>>>>>> >>>>>>>> Vijay >>>>>>>> >>>>>>>>>> Also I have a question to Ryuji: does this draft send a >>>>>>>>> non-deregistration BU at the home link? If yes, is he >>> familiar with the >>>>>>>>> discussion going on on this subject? This is another >>> point of confusion >>>>>>>>> for >>>>>>>>> me. >>>>>>>>> >>>>>>>>> This has been discussed for a long time in MEXT. >>>>>>>>> who is familiar with which discussions? I don't know >>> your concern here. >>>>>>>>> *[behcet] So your answer is yes the draft sends a >>> non-deregistration BU >>>>>>>>> (kind of bulk registration) at the home link.* >>>>>>>>> *The discussion I mentioned was related to >>>>>>>>> draft-premec-mext-extended-home-link. This draft also sends >>>>>>>>> non-deregistration BU at the home link. So does a few >>> more drafts like >>>>>>>>> **draft-devarapalli-mext-mipv6-home-link.* >>>>>>>>> >>>>>>>>> ** >>>>>>>>> *[behcet] You mentioned some bit is set but I could >>> not understand which. >>>>>>>>> One idea is since so many drafts need this, why not >>> factor this out and >>>>>>>>> define whatever the mechanism to enable sending >>> non-deregistration BU in >>>>>>>>> 3775bis. What do you think about that?* >>>>>>>>> >>>>>>>>> ** >>>>>>>>> >>>>>>>>>> Sorry if I am too much confused >>>>>>>>>> Please don't get me wrong, I am not trying to slow >>> down the progress >>>>>>>>> of >>>>>>>>> this document.. >>>>>>>>> >>>>>>>>> sure, but please explain your issue more precisely. >>>>>>>>> >>>>>>>>> thanks! >>>>>>>>> ryuji >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Behcet >>>>>>>>>> From: marcelo bagnulo braun >>>>>>>>> >>>>>>>>> >>> >>>>>>>>>> To: mext >>> >>>>>>>>> >>; Julien Laganier >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>; Jari Arkko >>>>>>>>> >>> >>>>>>>>> >> > >>>>>>>>> >>> >>>>>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM >>>>>>>>>> Subject: [MEXT] [Fwd: I-D >>>>>>>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>>>>> >>>>>>>>>> We have this new version of the MCOA document that >>> addresses the >>>>>>>>> comments received, including IESG review comments. >>>>>>>>>> To the best of my knowledge, the IESG is ok with the >>> doc and ready for >>>>>>>>> publication.. >>>>>>>>>> I am planning to ask our AD to move forward in a week >>> or so, so, if >>>>>>>>> you >>>>>>>>> have comments on the document please provide them >>> before the 1st of may. >>>>>>>>>> >>>>>>>>>> Regards, marcelo >>>>>>>>>> (mcoa doc shepherd) >>>>>>>>>> >>>>>>>>>> -------- Mensaje original -------- >>>>>>>>>> Asunto: [MEXT] I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt >>>>>>>>>> Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) >>>>>>>>>> De: Internet-Drafts@ietf.org >>> >>>>>>>>>> >> > >>>>>>>>>> Para: i-d-announce@ietf.org >> >>>>>>>>>> > > >>>>>>>>>> CC: mext@ietf.org >> > >>>>>>>>>> >> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A New Internet-Draft is available from the on-line >>> Internet-Drafts >>>>>>>>> directories. >>>>>>>>>> This draft is a work item of the Mobility EXTensions >>> for IPv6 Working >>>>>>>>> Group of the IETF.. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Title : Multiple Care-of Addresses Registration >>>>>>>>>> Author(s) : R. Wakikawa, et al. >>>>>>>>>> Filename : draft-ietf-monami6-multiplecoa-13..txt >>>>>>>>>> Pages : 44 >>>>>>>>>> Date : 2009-04-20 >>>>>>>>>> >>>>>>>>>> According to the current Mobile IPv6 specification, a >>> mobile node may >>>>>>>>>> have several care-of addresses, but only one, called >>> the primary >>>>>>>>>> care-of address, that can be registered with its home >>> agent and the >>>>>>>>>> correspondent nodes. However, for matters of cost, >>> bandwidth, delay, >>>>>>>>>> etc, it is useful for the mobile node to get Internet >>> access through >>>>>>>>>> multiple accesses simultaneously, in which case the >>> mobile node would >>>>>>>>>> be configured with multiple active IPv6 care-of >>> addresses. This >>>>>>>>>> document proposes extensions to the Mobile IPv6 >>> protocol to register >>>>>>>>>> and use multiple care-of addresses. The extensions >>> proposed in this >>>>>>>>>> document can be used by Mobile Routers using the >> NEMO (Network >>>>>>>>>> Mobility) Basic Support protocol as well. >>>>>>>>>> >>>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>>> >>>>>>>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multipl >> ecoa-13.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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>> -------------------------------------------------------------- >>> ---------- >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>>>> >>> -------------------------------------------------------------- >>> ---------- >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>> >>>> >>>>=20 >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > --Boundary_(ID_sQ9icvjKUghxD/GyBNteog) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Re: [MEXT] [Fwd: I-D = Action:draft-ietf-monami6-multiplecoa-13.txt]
Hello

From: Vijay Devarapalli=20 [mailto:vijay@wichorus.com]
Sent: Friday, April 24, 2009 = 1:32=20 PM
To: w52006@huawei.com; Behcet Sarikaya; marcelo bagnulo=20 braun
Cc: mext
Subject: Re: [MEXT] [Fwd: I-D=20 Action:draft-ietf-monami6-multiplecoa-13.txt]

Hello,

On 4/23/09 8:54 PM, "Yungui Wang"=20 wrote:

>> I kind of understand what you are saying now. = You=20 are
>> concerned about the mobile node attaching to the home=20 link
>> via multiple interfaces (since it has multiple=20 interfaces)
>> and the result of assigning the home address = to those=20 interfaces.
>>
>> As far as RFC 3775 and the MCoA = draft is=20 concerned, the home
>> address is assigned to first interface = with=20 which the mobile
>> node attaches to the home link. This may = require=20 the mobile
>> node to "move" the home address from a MIPv6=20 virtual
>> interface to the physical interface with which it = attaches=20 to
>> the home link. This is implementation=20 specific.
>>
>> If the mobile node attaches to the = home link=20 via a second
>> interface, I think the mobile node should get = a new=20 home
>> address for that interface. Not the same home=20 address.
>>
> [Yungui] In this case, in my mind, the = question=20 is, could we treat
> this new HoA as a (home) CoA binding to the = primary=20 HoA?
> If so, the service continuity could be guaranteed because = this
> interface is using the primary HoA.

That would be = out of=20 scope. As far as the current MCoA draft is concerned,
there is no = tunneling=20 from the home link.

 
As=20 MCoA I-D described, when MN is located=20 in foreign link=20
and=20 home link in parallel, its interface returning=20 home may
register a = home binding=20 with its (HoA, CoA). Here CoA=20 is 
set to HoA. Due to there are=20 two HoA in above situation,=20
maybe=20 it needs to be clarified something, such as=20
'what's the just HoA = set to=20 CoA in home binding for = the=20
second interface'; or=20
'the second interface = returning=20 home is not supported'; or
'the second interface returning home is implicitly = de-registered=20
from=20 MCoA registration'; etc.
If it is=20 out of scope, obviously some ambiguous operation is = left.
 
In=20 addition, tunneling may be not necessary for the second =
interface=20 at home link. It need also register its = Link-layer=20
Address=20 Option for packet = forwarding.=20 The I-D can give a 
note that HA shall use = link-layer address=20 to forward downlink
packet=20 once it is presented.
 
B.R.
Yungui
 
 
Vijay

> = Otherwise, it=20 seems the HA
> has to initiate flow handover to another=20 interface.
> Therefore, I think, Behcet's statement makes=20 sense.
>
> B.R.
> Yungui
>
>> Does = the above=20 make sense?
>>
>> Vijay
>>
>>>=20 -----Original Message-----
>>> From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com<= /A>]
>>>=20 Sent: Thursday, April 23, 2009 8:54 AM
>>> To: Vijay = Devarapalli;=20 marcelo bagnulo braun
>>> Cc: mext
>>> = Subject: Re:=20 [MEXT] [Fwd: I-D
>>>=20 = Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>
>>= >=20 Hi Vijay,
>>>   I understand your=20 concerns.
>>> 
>>> Here is slightly = revised=20 version removing main and = auxiliary:
>>> 
>>> In=20 this document it is assumed that a multi-homed MN = connects
>>> to=20 the home link using only one interface. This interface = is
>>>=20 identified by the home address assigned by the home = agent.
>>> The=20 other  interfaces may later on become active and = connect
>>>=20 to some other networks and get their care-of addresses = and
>>>=20 then the procedures defined in this document allow = such
>>>=20 care-of addresses to be registered with the home agent = apart
>>>=20 from the registration of the care-of addresses assigned = to
>>>=20 the  interface MN originally used to connect to the home=20 link
>>> which is already defined in RFC=20 3775.
>>>
>>>
>>>=20 Regards,
>>> 
>>>=20 Behcet
>>>
>>>=20 ________________________________
>>>
>>> From: = Vijay=20 Devarapalli <vijay@wichorus.com>
>>> To: Behcet = Sarikaya=20 <sarikaya@ieee.org>; marcelo bagnulo
>>> braun=20 <marcelo@it.uc3m.es>
>>> Cc: mext=20 <mext@ietf.org>
>>> Sent: Wednesday, April 22, 2009 = 6:43:13=20 PM
>>> Subject: Re: [MEXT] [Fwd: I-D
>>>=20 = Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>
>>= >=20 Hi Bechet,
>>>
>>> On 4/22/09 4:07 PM, "Behcet = Sarikaya" wrote:
>>>
>>>> Hi=20 Marcelo,
>>>>  How about this little=20 paragraph?
>>>> 
>>>> In this = document it=20 is assumed that a multi-homed MN
>>> connects to the home=20 link
>>>> using only one interface. Therefore this = interface=20 is
>>> considered as the main
>>>> = interface as=20 identified by the home address assigned by the
>>> home=20 agent.
>>>
>>> I disagree with this. The = mobile node=20 can connect to the home
>>> link through
>>> = any one=20 of its interfaces.
>>>
>>>> = The
>>>>=20 other or auxiliary interfaces may later on become = active
>>> and=20 connect to some
>>>> other networks and get their = care-of=20 addresses and then the
>>> procedures = defined
>>>>=20 in this document allow such care-of addresses to be
>>> = registered=20 with the home
>>>> agent apart from the registration of = the=20 care-of addresses
>>> assigned to the
>>>> = main=20 interface which is already defined in RFC=20 3775.
>>>
>>> There is no need for the home = agent to=20 identify one of the
>>> interfaces as a
>>> = "main"=20 interface.
>>>
>>>=20 Vijay
>>>
>>>>=20 Regards,
>>>> 
>>>>=20 Behcet
>>>>
>>>> From: marcelo bagnulo = braun=20 <marcelo@it.uc3m.es>
>>>> To: Behcet Sarikaya=20 <sarikaya@ieee.org>
>>>> Cc: Ryuji Wakikawa=20 <ryuji.wakikawa@gmail.com>; mext
>>=20 <mext@ietf.org>
>>>> Sent: Wednesday, April 22, = 2009=20 4:59:50 PM
>>>> Subject: Re: [MEXT] [Fwd: = I-D
>>>=20 = Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>
>= >>>=20 Hi Bechet,
>>>>
>>>> could you send = exactly what=20 text do you think needs to be
>>> changed in the=20 MCOA
>>>> draft, so the WG can evaluate and figure out = if the=20 changes
>>> are needed? (i.e.
>>>> please = send OLD=20 text NEW text)
>>>>
>>>> Please note = that at=20 this point in the life of the document,
>>> we only=20 take
>>>> changes that fix errors in the document, = rather=20 than
>>> getting more features
>>>>=20 in.
>>>>
>>>> Regards,=20 = marcelo
>>>>
>>>>
>>>>
&g= t;>>>=20 Behcet Sarikaya escribi=F3:
>>>>> Hi=20 Ryuji,
>>>>>  I checked your draft. Again, I = could not=20 understand how
>>> you are sending = a
>>>>>=20 registration BU at the home link as only an O-flag is
>>> = defined=20 in your draft
>>>>> which is used for something=20 else.
>>>>>  As I mentioned to you, we = discussed this=20 related to
>>> = draft-premec-homelink
>>>>> and=20 it seems like HA will reject such a BU unless
>>> = something is=20 done, I
>>>>> thought you were familiar with the = discussions=20 as it
>>> relates to your draft
>>>>> = too. I am=20 surprised.
>>>>> =20 Regards,
>>>>> =20 Behcet
>>>>>
>>>>>
>>> = = --------------------------------------------------------------
>>= ;>=20 ----------
>>>>> *From:* Ryuji Wakikawa=20 <ryuji.wakikawa@gmail.com>
>>>>> *To:* Behcet = Sarikaya=20 <sarikaya@ieee.org>
>>>>> *Cc:* George = Tsirtsis=20 <tsirtsis@googlemail.com>; mext
>>>=20 <mext@ietf.org>
>>>>> *Sent:* Wednesday, April = 22,=20 2009 4:18:28 PM
>>>>> *Subject:* Re: [MEXT] [Fwd:=20 I-D
>>>=20 = Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>>
= >>>>>=20 Hi Behcet,
>>>>>
>>>>> On = 2009/04/22, at=20 11:31, Behcet Sarikaya=20 = wrote:
>>>>>
>>>>>>
>>>= ;>>>
>>>>>>=20 From: George Tsirtsis = <tsirtsis@googlemail.com
>>>>>>=20 <mailto:tsirtsis@googlemail.com>>
>>>>>>=20 To: Behcet Sarikaya <sarikaya@ieee.org
>> <mailto:sarikaya@ieee.org>>>>>>>>=20 Cc: mext <mext@ietf.org <mailto:mext@ietf.org>>
>>= ;>>>>=20 Sent: Wednesday, April 22, 2009 10:10:08 = AM
>>>>>>=20 Subject: Re: [MEXT] [Fwd: I-D
>>>=20 = Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>>>=
>>>>>>=20 I do not think that adding home link registration to
>>>=20 RFC3775bis is feasible.
>>>>>> This requires = logic in the=20 MN and HA that is not directly
>>>=20 compatible
>>>>>> to RFC3775. The aim of = RFC3775bis is to=20 make minimal changes for
>>>>>> clarification = reasons and=20 to correct errors. Home Link
>>> Registration=20 as
>>>>>> defined in MCoA is=20 neither.
>>>>>> [behcet] Why not? If it is needed = in so=20 many instances,
>>> that qualifies it=20 to
>>>>>> become a base protocol feature, at = least to=20 me.
>>>>>
>>>>> We cannot add a = new=20 feature to 3775. That is the ground
>>> rule of -bis.=20 The
>>>>> chairs can clarify=20 this.
>>>>>
>>>>>=20 regards,
>>>>>=20 = ryuji
>>>>>
>>>>>
>>>>= >
>>>>>>
>>>>>>=20 On Wed, Apr 22, 2009 at 4:06 PM, Behcet = Sarikaya
>>>>>>=20 <behcetsarikaya@yahoo.com
>>> <mailto:behcetsarikaya@yahoo.com<= /A>>>=20 wrote:
>>>>>>> Hi=20 George,
>>>>>>>  It seems in my previous = reply I=20 replied to this mail of
>>> yours which=20 was
>>>>>>> unrelated to the other mail you = sent to=20 which I was
>>> really = replying,
>>>>>>>=20 apologies.
>>>>>>>  Now regarding home = link=20 registration, what is the
>>> mechanism MCoA=20 draft
>>>>>>> uses? Ryuji mentioned some H bit = but I=20 read the draft
>>> and couldn't=20 confirm
>>>>>>>=20 = it.
>>>>>>>
>>>>>>> = My=20 suggestion was building on this, i.e. I suggested
>>> that = whatever you
>>>>>>> came up with can be moved = to=20 3775bis so that other
>>> people would not have=20 to
>>>>>>> make normative references to your=20 draft.
>>>>>>>
>>>>>>> = That's=20 all.
>>>>>>>
>>>>>>>=20 = Regards,
>>>>>>>
>>>>>>> = Behcet
>>>>>>>
>>>>>>> = ________________________________
>>>>>>> From: = George=20 Tsirtsis <tsirtsis@googlemail.com
>>>>>>> = <mailto:tsirtsis@googlemail.com>>
>>>>>>>=20 To: Vijay Devarapalli <vijay@wichorus.com
>>> <mailto:vijay@wichorus.com>><= BR>>>>>>>>=20 Cc: Behcet Sarikaya <sarikaya@ieee.org
>>> <mailto:sarikaya@ieee.org>>;=20 mext
>>>>>>> <mext@ietf.org <mailto:mext@ietf.org>>
>>= ;>>>>>=20 Sent: Tuesday, April 21, 2009 2:14:55 = PM
>>>>>>>=20 Subject: Re: [MEXT] [Fwd: I-D
>>>=20 = Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>>>= >
>>>>>>>=20 ...also wrt the home link registration, I do not think what=20 you
>>>>>>> suggest is=20 = necessary.
>>>>>>>
>>>>>>>= ; As=20 far as I see the other documents are informational,
>>> = and they=20 do not
>>>>>>> yet have a formal standing in = the WG.=20 If and when they do, as
>>>>>>> Informational=20 documents,  they should not require
>>> normative = changes=20 to
>>>>>>> anything. They should make sure = what they=20 describe (mostly
>>>>>>> implementation = options in=20 this case) are compatible
>> not only=20 with
>>>>>>> RFC3775 but also with extensions = to it,=20 including Flow
>>> Bindings.=20 = .
>>>>>>>
>>>>>>>
>= >>>>>>=20 Regards
>>>>>>>=20 George
>>>>>>>
>>>>>>> = On Tue,=20 Apr 21, 2009 at 7:58 PM, Vijay Devarapalli
>>>=20 <vijay@wichorus.com
>>>>>>> <mailto:vijay@wichorus.com>><= BR>>>>>>>>=20 wrote:
>>>>>>>>=20 = Behcet,
>>>>>>>>
>>>>>>&g= t;>=20 Behcet Sarikaya=20 = wrote:
>>>>>>>>>
>>>>>>= ;>>>=20 *[behcet] Yes but each interface will appear to HA as
>>> = a=20 different device
>>>>>>>>> and HA needs = to=20 assign a different HoA. Then MCoA
>>> problem=20 disappears.*
>>>>>>>>> *So George is = saying that=20 this is avoided by some
>>> virtual interfaces=20 so
>>>>>>>>> that HA does not see each = interface=20 separately. *
>>>>>>>>> *Is this = explained=20 anywhere in the draft?*
>>>>>>>>> *If = yes then I=20 am=20 = OK.*
>>>>>>>>
>>>>>>>&= gt;=20 The home agent does not care about the multiple
>>> = interfaces on=20 the mobile
>>>>>>>> node. It only sees the = mobile=20 node as one entity and
>>> allocates a=20 home
>>>>>>>> address to it. The multiple = care-of=20 addresses that the
>>> mobile node=20 has
>>>>>>>>=20 will
>>>>>>>> be used by the home agent as = tunnel=20 end points. That is
>>> all.. So there=20 is
>>>>>>>> = no
>>>>>>>>=20 = issue.
>>>>>>>>
>>>>>>>= ;>=20 = Vijay
>>>>>>>>
>>>>>>>= >>> =20 Also I have a question to Ryuji: does this draft send=20 a
>>>>>>>>> non-deregistration BU at the = home=20 link? If yes, is he
>>> familiar with=20 the
>>>>>>>>> discussion going on on = this=20 subject? This is another
>>> point of=20 confusion
>>>>>>>>>=20 for
>>>>>>>>>=20 = me.
>>>>>>>>>
>>>>>>&g= t;>>=20 This has been discussed for a long time in=20 MEXT.
>>>>>>>>> who is familiar with = which=20 discussions? I don't know
>>> your concern=20 here.
>>>>>>>>>  *[behcet] So your = answer=20 is yes the draft sends a
>>> non-deregistration=20 BU
>>>>>>>>> (kind of bulk registration) = at the=20 home link.*
>>>>>>>>> *The discussion I=20 mentioned was related to
>>>>>>>>>=20 draft-premec-mext-extended-home-link. This draft also=20 sends
>>>>>>>>> non-deregistration BU at = the=20 home link. So does a few
>>> more drafts=20 like
>>>>>>>>>=20 = **draft-devarapalli-mext-mipv6-home-link.*
>>>>>>>= ;>>
>>>>>>>>>=20 **
>>>>>>>>> *[behcet] You mentioned = some bit is=20 set but I could
>>> not understand=20 which.
>>>>>>>>> One idea is since so = many=20 drafts need this, why not
>>> factor this out=20 and
>>>>>>>>> define whatever the = mechanism to=20 enable sending
>>> non-deregistration BU=20 in
>>>>>>>>> 3775bis. What do you think = about=20 = that?*
>>>>>>>>>
>>>>>>= ;>>>=20 = **
>>>>>>>>>
>>>>>>>= ;>>> =20 Sorry if I am too  much=20 confused
>>>>>>>>>> Please don't get = me=20 wrong, I am not trying to slow
>>> down the=20 progress
>>>>>>>>>=20 of
>>>>>>>>> this=20 = document..
>>>>>>>>>
>>>>>= ;>>>>=20 sure, but please explain your issue more=20 = precisely.
>>>>>>>>>
>>>>>= ;>>>>=20 thanks!
>>>>>>>>>=20 = ryuji
>>>>>>>>>
>>>>>>= >>>>
>>>>>>>>>>=20 = Regards,
>>>>>>>>>>
>>>>&= gt;>>>>>=20 Behcet
>>>>>>>>>> From: marcelo = bagnulo braun=20 <marcelo@it.uc3m.es
>>>>>>>>>> = <mailto:marcelo@it.uc3m.es>
&= gt;>>>>>>>>=20 <mailto:marcelo@it.uc3m.es=20 >>>
>>>>>>>>>> To: mext=20 <mext@ietf.org <mailto:mext@ietf.org>
>>>= ;=20 <mailto:mext@ietf.org
>>>>>>>>>> = <mailto:mext@ietf.org>>>; = Julien=20 Laganier
>>>>>>>>>=20 = <julien.laganier.ietf@googlemail.com
>>>>>>>&g= t;>=20 <mailto:julien.laganie= r.ietf@googlemail.com>
>>>>>>>>>=20 = <mailto:julien.laganier..ietf@googlemail.com
>>>>>&g= t;>>>=20 <mailto:julien.lagani= er..ietf@googlemail.com>>>;=20 Jari Arkko
>>>>>>>>> = <jari.arkko@piuha..net=20 <mailto:jari.arkko@piuha.net><= BR>>>>=20 <mailto:jari.arkko@piuha.net><= BR>>>>>>>>>>=20 <mailto:jari.arkko@piuha.net
>>> <mailto:jari.arkko@piuha..net=20 >
>>>>>>>>>=20 <mailto:jari.arkko@piuha.net> = >>>
>>>>>>>>>> Sent: = Tuesday, April=20 21, 2009 11:03:05 AM
>>>>>>>>>> = Subject:=20 [MEXT] [Fwd: I-D
>>>>>>>>>=20 = Action:draft-ietf-monami6-multiplecoa-13.txt]
>>>>>>= >>>>
>>>>>>>>>>=20 We have this new version of the MCOA document that
>>> = addresses=20 the
>>>>>>>>> comments received, = including IESG=20 review comments.
>>>>>>>>>> To the = best of my=20 knowledge, the IESG is ok with the
>>> doc and ready=20 for
>>>>>>>>>=20 publication..
>>>>>>>>>> I am = planning to ask=20 our AD to move forward in a week
>>> or so, so,=20 if
>>>>>>>>>=20 you
>>>>>>>>> have comments on the = document=20 please provide them
>>> before the 1st of=20 = may.
>>>>>>>>>>
>>>>>&= gt;>>>>=20 Regards, marcelo
>>>>>>>>>> (mcoa doc = = shepherd)
>>>>>>>>>>
>>>>= >>>>>>=20 -------- Mensaje original = --------
>>>>>>>>>>=20 Asunto:    [MEXT] I-D
>>>=20 = Action:draft-ietf-monami6-multiplecoa-13.txt
>>>>>>&= gt;>>>=20 Fecha:    Mon, 20 Apr 2009 08:30:01 -0700=20 (PDT)
>>>>>>>>>> = De:   =20 Internet-Drafts@ietf.org
>>> <mailto:Internet-Drafts@ietf.org<= /A>>
>>>>>>>>>>=20 <mailto:Internet-Drafts@ietf.org
>>> <mailto:Internet-Drafts@ietf.org<= /A>>>
>>>>>>>>>>=20 Para:    i-d-announce@ietf.org
>> <mailto:i-d-announce@ietf.org>= ;
>>>>>>>>>>=20 <mailto:i-d-announce@ietf.org
>> <mailto:i-d-announce@ietf.org>= ;>
>>>>>>>>>>=20 CC:    mext@ietf.org = <mailto:mext@ietf..org
>>>=20 <mailto:mext@ietf.org>=20 >
>>>>>>>>>> <mailto:mext@ietf.org=20 >>
>>>>>>>>>>
>>>>= ;>>>>>>
>>>>>>>>>>
= >>>>>>>>>>=20 A New Internet-Draft is available from the on-line
>>>=20 Internet-Drafts
>>>>>>>>>=20 directories.
>>>>>>>>>> This draft is = a work=20 item of the Mobility EXTensions
>>> for IPv6=20 Working
>>>>>>>>> Group of the=20 = IETF..
>>>>>>>>>>
>>>>>= ;>>>>>
>>>>>>>>>> &n= bsp; =20 Title          : Multiple = Care-of=20 Addresses=20 = Registration
>>>>>>>>>>   = ;=20 Author(s)      : R. Wakikawa, et=20 al.
>>>>>>>>>>   =20 Filename        :=20 = draft-ietf-monami6-multiplecoa-13..txt
>>>>>>>>= ;>>   =20 Pages          :=20 44
>>>>>>>>>>   =20 Date            = :=20 = 2009-04-20
>>>>>>>>>>
>>>>= ;>>>>>>=20 According to the current Mobile IPv6 specification, a
>>> = mobile=20 node may
>>>>>>>>>> have several = care-of=20 addresses, but only one, called
>>> the=20 primary
>>>>>>>>>> care-of address, = that can=20 be registered with its home
>>> agent and=20 the
>>>>>>>>>> correspondent = nodes. =20 However, for matters of cost,
>>> bandwidth,=20 delay,
>>>>>>>>>> etc, it is useful = for the=20 mobile node to get Internet
>>> access=20 through
>>>>>>>>>> multiple accesses=20 simultaneously, in which case the
>>> mobile node=20 would
>>>>>>>>>> be configured with = multiple=20 active IPv6 care-of
>>> addresses. =20 This
>>>>>>>>>> document proposes = extensions=20 to the Mobile IPv6
>>> protocol to=20 register
>>>>>>>>>> and use multiple = care-of=20 addresses.  The extensions
>>> proposed in=20 this
>>>>>>>>>> document can be used = by=20 Mobile Routers using the
>> NEMO=20 (Network
>>>>>>>>>> Mobility) Basic = Support=20 protocol as=20 = well.
>>>>>>>>>>
>>>>>= >>>>>=20 A URL for this Internet-Draft=20 = is:
>>>>>>>>>>
>>>>>&g= t;>>>
>>>=20 h= ttp://www.ietf.org/internet-drafts/draft-ietf-monami6-multipl
>= >=20 = ecoa-13.txt
>>>>>>>>>>
>>>&g= t;>>>>>>=20 Internet-Drafts are also available by anonymous FTP=20 at:
>>>>>>>>>> ftp://ftp.ietf.org/internet-= drafts/
>>>>>>>>>>
>>>&g= t;>>>>>>=20 Below is the data which will enable a MIME compliant
>>> = mail=20 reader
>>>>>>>>>> implementation to=20 automatically retrieve the ASCII
>>> version of=20 the
>>>>>>>>>>=20 = Internet-Draft.
>>>>>>>>>>
>>&g= t;>>>>>>>
>>>>>>>>>>= ;
>>>>>>>>>>=20 = _______________________________________________
>>>>>&g= t;>>>>=20 MEXT mailing list
>>>>>>>>>> = MEXT@ietf.org=20 <mailto:MEXT@ietf.org>=20 <mailto:MEXT@ietf.org
>>>>>>>>>> = <mailto:MEXT@ietf.org>>
>>= ;>>>>>>>>=20 https://www.ietf.org/= mailman/listinfo/mext
>>>>>>>>>
>= >>>>>>>>
>>>>>>>>><= BR>>>>>>>>>>
>>>=20 = --------------------------------------------------------------
>>= ;>=20 = ----------
>>>>>>>>>
>>>>>= ;>>>>=20 = _______________________________________________
>>>>>&g= t;>>>=20 MEXT mailing list
>>>>>>>>> = MEXT@ietf.org <mailto:MEXT@ietf.org>
>>>= ;>>>>>>=20 https://www.ietf.org/= mailman/listinfo/mext
>>>>>>>>
>>= >>>>>>=20 = _______________________________________________
>>>>>&g= t;>>=20 MEXT mailing list
>>>>>>>> MEXT@ietf.org = <mailto:MEXT@ietf.org>
>>>= ;>>>>>=20 https://www.ietf.org/= mailman/listinfo/mext
>>>>>>>>
>>= >>>>>
>>>>>>>
>>>>&= gt;>
>>>>>>=20 = _______________________________________________
>>>>>&g= t;=20 MEXT mailing list
>>>>>> MEXT@ietf.org <mailto:MEXT@ietf.org=20 > >
>>>>>> https://www.ietf.org/= mailman/listinfo/mext
>>>>>
>>>>>=
>>>>>
>>>=20 = --------------------------------------------------------------
>>= ;>=20 ----------
>>>>>
>>>>>=20 = _______________________________________________
>>>>> = MEXT=20 mailing list
>>>>> = MEXT@ietf.org
>>>>> https://www.ietf.org/= mailman/listinfo/mext
>>>>> 
>>>&g= t;
>>>>
>>>> 
>>>>
&= gt;>>>=20 _______________________________________________
>>>> = MEXT=20 mailing list
>>>> MEXT@ietf.org
>>>> https://www.ietf.org/= mailman/listinfo/mext
>>>
>>>
>>>=
>>>
>>=20 _______________________________________________
>> MEXT = mailing=20 list
>> MEXT@ietf.org
>> https://www.ietf.org/= mailman/listinfo/mext
>>
>

<= /FONT> --Boundary_(ID_sQ9icvjKUghxD/GyBNteog)-- From ryuji.wakikawa@gmail.com Sat Apr 25 01:39:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7A03A6BE2 for ; Sat, 25 Apr 2009 01:39:45 -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 xQna1ifu8f8v for ; Sat, 25 Apr 2009 01:39:42 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 1136F3A6BD6 for ; Sat, 25 Apr 2009 01:39:41 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so1613983qwe.31 for ; Sat, 25 Apr 2009 01:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=sFLm3he/rkEXN+6kbPk7iS/qaICtwTv4JFkNlVg3eDw=; b=ExKumlov10JLUMsoClmm6RMRabpQ4o49RdluEwbn8WTaGtEmFBKLopacigFRNwLOSr WHOoJM4dxqTEPt+R0qX1ojxlJpr1iA2c3I0p2PdkUoXrGLOAL9OAWOTNXuTLeql9OPiy vZnXPMvo0AepKX6J9E4Sq3CfZ8OMauuWpi26w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=Ud9aYAmD/+aA56bk9fTMYedhonF944XyRnzanUjcs+j9aU8ZxuqkJe2Nod9MstVYky KuzPcRvXWipx/viyYa6MfUqy1vEph8/a9xb79S25QpSOeNP/vlPlsE5CI8DPFMS2TyNN m7JQNUgJvnsUwsUi7lAeOLNyhy6Z1+sQ9xpnY= Received: by 10.220.45.211 with SMTP id g19mr6358446vcf.86.1240648860727; Sat, 25 Apr 2009 01:41:00 -0700 (PDT) Received: from ?172.16.0.175? ([12.235.127.2]) by mx.google.com with ESMTPS id 34sm6767152yxl.35.2009.04.25.01.40.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Apr 2009 01:41:00 -0700 (PDT) From: Ryuji Wakikawa To: George Tsirtsis In-Reply-To: References: <471395.65157.qm@web111404.mail.gq1.yahoo.com> Message-Id: <0F161E47-AB81-4785-A076-5D475892CBDD@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 25 Apr 2009 01:32:14 -0700 X-Mailer: Apple Mail (2.930.3) Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 08:39:45 -0000 Hi Behcet, Vijay and George, On 2009/04/23, at 13:59, George Tsirtsis wrote: > On Thu, Apr 23, 2009 at 6:28 PM, Vijay Devarapalli =20 > wrote: >> I kind of understand what you are saying now. You are concerned =20 >> about the mobile node attaching to the home link via multiple =20 >> interfaces (since it has multiple interfaces) and the result of =20 >> assigning the home address to those interfaces. >> >> As far as RFC 3775 and the MCoA draft is concerned, the home =20 >> address is assigned to first interface with which the mobile node =20 >> attaches to the home link. This may require the mobile node to =20 >> "move" the home address from a MIPv6 virtual interface to the =20 >> physical interface with which it attaches to the home link. This is =20= >> implementation specific. >> >> If the mobile node attaches to the home link via a second =20 >> interface, I think the mobile node should get a new home address =20 >> for that interface. Not the same home address. >> > > GT> The MN would not be able to get the same home address even if it > tried. At the time a node attaches an interface on a link, the Access > Routers do not have any clue to what node this interface belongs or > whether this node has other interfaces on or off link. All interfaces > are assumed to have different IP addresses at that level. It is only > after that, the MN communicates with the HA function in the local AR ( > assuming that is where its HA is) establishes ONE of its addresses as > home address. > =46rom IPv6 point of view, a node cannot assign the same address to =20 multiple interfaces on the same link. Thus, as Vijay and George mentioned, we don't have the configuration =20 which you concerned in MCoA. > > GT> Again I do not think there is anything to define here. I don't think this clarification is necessary. regards, ryuji > > >> Does the above make sense? >> >> Vijay >> >>> -----Original Message----- >>> From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] >>> Sent: Thursday, April 23, 2009 8:54 AM >>> To: Vijay Devarapalli; marcelo bagnulo braun >>> Cc: mext >>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>> >>> Hi Vijay, >>> I understand your concerns. >>> >>> Here is slightly revised version removing main and auxiliary: >>> >>> In this document it is assumed that a multi-homed MN connects >>> to the home link using only one interface. This interface is >>> identified by the home address assigned by the home agent. >>> The other interfaces may later on become active and connect >>> to some other networks and get their care-of addresses and >>> then the procedures defined in this document allow such >>> care-of addresses to be registered with the home agent apart >>> from the registration of the care-of addresses assigned to >>> the interface MN originally used to connect to the home link >>> which is already defined in RFC 3775. >>> >>> >>> Regards, >>> >>> Behcet >>> >>> ________________________________ >>> >>> From: Vijay Devarapalli >>> To: Behcet Sarikaya ; marcelo bagnulo >>> braun >>> Cc: mext >>> Sent: Wednesday, April 22, 2009 6:43:13 PM >>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>> >>> Hi Bechet, >>> >>> On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote: >>> >>>> Hi Marcelo, >>>> How about this little paragraph? >>>> >>>> In this document it is assumed that a multi-homed MN >>> connects to the home link >>>> using only one interface. Therefore this interface is >>> considered as the main >>>> interface as identified by the home address assigned by the >>> home agent. >>> >>> I disagree with this. The mobile node can connect to the home >>> link through >>> any one of its interfaces. >>> >>>> The >>>> other or auxiliary interfaces may later on become active >>> and connect to some >>>> other networks and get their care-of addresses and then the >>> procedures defined >>>> in this document allow such care-of addresses to be >>> registered with the home >>>> agent apart from the registration of the care-of addresses >>> assigned to the >>>> main interface which is already defined in RFC 3775. >>> >>> There is no need for the home agent to identify one of the >>> interfaces as a >>> "main" interface. >>> >>> Vijay >>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> From: marcelo bagnulo braun >>>> To: Behcet Sarikaya >>>> Cc: Ryuji Wakikawa ; mext >>>> Sent: Wednesday, April 22, 2009 4:59:50 PM >>>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>> >>>> Hi Bechet, >>>> >>>> could you send exactly what text do you think needs to be >>> changed in the MCOA >>>> draft, so the WG can evaluate and figure out if the changes >>> are needed? (i.e. >>>> please send OLD text NEW text) >>>> >>>> Please note that at this point in the life of the document, >>> we only take >>>> changes that fix errors in the document, rather than >>> getting more features >>>> in. >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> Behcet Sarikaya escribi=C3=B3: >>>>> Hi Ryuji, >>>>> I checked your draft. Again, I could not understand how >>> you are sending a >>>>> registration BU at the home link as only an O-flag is >>> defined in your draft >>>>> which is used for something else. >>>>> As I mentioned to you, we discussed this related to >>> draft-premec-homelink >>>>> and it seems like HA will reject such a BU unless >>> something is done, I >>>>> thought you were familiar with the discussions as it >>> relates to your draft >>>>> too. I am surprised. >>>>> Regards, >>>>> Behcet >>>>> >>>>> >>> -------------------------------------------------------------- >>> ---------- >>>>> *From:* Ryuji Wakikawa >>>>> *To:* Behcet Sarikaya >>>>> *Cc:* George Tsirtsis ; mext >>> >>>>> *Sent:* Wednesday, April 22, 2009 4:18:28 PM >>>>> *Subject:* Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>> >>>>> Hi Behcet, >>>>> >>>>> On 2009/04/22, at 11:31, Behcet Sarikaya wrote: >>>>> >>>>>> >>>>>> >>>>>> From: George Tsirtsis >>>>> > >>>>>> To: Behcet Sarikaya >>>>> > >>>>>> Cc: mext > >>>>>> Sent: Wednesday, April 22, 2009 10:10:08 AM >>>>>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>> >>>>>> I do not think that adding home link registration to >>> RFC3775bis is feasible. >>>>>> This requires logic in the MN and HA that is not directly >>> compatible >>>>>> to RFC3775. The aim of RFC3775bis is to make minimal changes for >>>>>> clarification reasons and to correct errors. Home Link >>> Registration as >>>>>> defined in MCoA is neither. >>>>>> [behcet] Why not? If it is needed in so many instances, >>> that qualifies it to >>>>>> become a base protocol feature, at least to me. >>>>> >>>>> We cannot add a new feature to 3775. That is the ground >>> rule of -bis. The >>>>> chairs can clarify this. >>>>> >>>>> regards, >>>>> ryuji >>>>> >>>>> >>>>> >>>>>> >>>>>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya >>>>>> >> > wrote: >>>>>>> Hi George, >>>>>>> It seems in my previous reply I replied to this mail of >>> yours which was >>>>>>> unrelated to the other mail you sent to which I was >>> really replying, >>>>>>> apologies. >>>>>>> Now regarding home link registration, what is the >>> mechanism MCoA draft >>>>>>> uses? Ryuji mentioned some H bit but I read the draft >>> and couldn't confirm >>>>>>> it. >>>>>>> >>>>>>> My suggestion was building on this, i.e. I suggested >>> that whatever you >>>>>>> came up with can be moved to 3775bis so that other >>> people would not have to >>>>>>> make normative references to your draft. >>>>>>> >>>>>>> That's all. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>>> >>>>>>> ________________________________ >>>>>>> From: George Tsirtsis >>>>>> > >>>>>>> To: Vijay Devarapalli >> > >>>>>>> Cc: Behcet Sarikaya >> >; mext >>>>>>> > >>>>>>> Sent: Tuesday, April 21, 2009 2:14:55 PM >>>>>>> Subject: Re: [MEXT] [Fwd: I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>> >>>>>>> ...also wrt the home link registration, I do not think what you >>>>>>> suggest is necessary. >>>>>>> >>>>>>> As far as I see the other documents are informational, >>> and they do not >>>>>>> yet have a formal standing in the WG. If and when they do, as >>>>>>> Informational documents, they should not require >>> normative changes to >>>>>>> anything. They should make sure what they describe (mostly >>>>>>> implementation options in this case) are compatible not only =20 >>>>>>> with >>>>>>> RFC3775 but also with extensions to it, including Flow >>> Bindings. . >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> George >>>>>>> >>>>>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli >>> >>>>>> > >>>>>>> wrote: >>>>>>>> Behcet, >>>>>>>> >>>>>>>> Behcet Sarikaya wrote: >>>>>>>>> >>>>>>>>> *[behcet] Yes but each interface will appear to HA as >>> a different device >>>>>>>>> and HA needs to assign a different HoA. Then MCoA >>> problem disappears.* >>>>>>>>> *So George is saying that this is avoided by some >>> virtual interfaces so >>>>>>>>> that HA does not see each interface separately. * >>>>>>>>> *Is this explained anywhere in the draft?* >>>>>>>>> *If yes then I am OK.* >>>>>>>> >>>>>>>> The home agent does not care about the multiple >>> interfaces on the mobile >>>>>>>> node. It only sees the mobile node as one entity and >>> allocates a home >>>>>>>> address to it. The multiple care-of addresses that the >>> mobile node has >>>>>>>> will >>>>>>>> be used by the home agent as tunnel end points. That is >>> all.. So there is >>>>>>>> no >>>>>>>> issue. >>>>>>>> >>>>>>>> Vijay >>>>>>>> >>>>>>>>>> Also I have a question to Ryuji: does this draft send a >>>>>>>>> non-deregistration BU at the home link? If yes, is he >>> familiar with the >>>>>>>>> discussion going on on this subject? This is another >>> point of confusion >>>>>>>>> for >>>>>>>>> me. >>>>>>>>> >>>>>>>>> This has been discussed for a long time in MEXT. >>>>>>>>> who is familiar with which discussions? I don't know >>> your concern here. >>>>>>>>> *[behcet] So your answer is yes the draft sends a >>> non-deregistration BU >>>>>>>>> (kind of bulk registration) at the home link.* >>>>>>>>> *The discussion I mentioned was related to >>>>>>>>> draft-premec-mext-extended-home-link. This draft also sends >>>>>>>>> non-deregistration BU at the home link. So does a few >>> more drafts like >>>>>>>>> **draft-devarapalli-mext-mipv6-home-link.* >>>>>>>>> >>>>>>>>> ** >>>>>>>>> *[behcet] You mentioned some bit is set but I could >>> not understand which. >>>>>>>>> One idea is since so many drafts need this, why not >>> factor this out and >>>>>>>>> define whatever the mechanism to enable sending >>> non-deregistration BU in >>>>>>>>> 3775bis. What do you think about that?* >>>>>>>>> >>>>>>>>> ** >>>>>>>>> >>>>>>>>>> Sorry if I am too much confused >>>>>>>>>> Please don't get me wrong, I am not trying to slow >>> down the progress >>>>>>>>> of >>>>>>>>> this document.. >>>>>>>>> >>>>>>>>> sure, but please explain your issue more precisely. >>>>>>>>> >>>>>>>>> thanks! >>>>>>>>> ryuji >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Behcet >>>>>>>>>> From: marcelo bagnulo braun >>>>>>>>> >>>>>>>>> >> >>>>>>>>>> To: mext >>> >>>>>>>>> >>; Julien Laganier >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>; Jari Arkko >>>>>>>>> >>> >>>>>>>>> >> >>>>>>>>> >>> >>>>>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM >>>>>>>>>> Subject: [MEXT] [Fwd: I-D >>>>>>>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>>>>> >>>>>>>>>> We have this new version of the MCOA document that >>> addresses the >>>>>>>>> comments received, including IESG review comments. >>>>>>>>>> To the best of my knowledge, the IESG is ok with the >>> doc and ready for >>>>>>>>> publication.. >>>>>>>>>> I am planning to ask our AD to move forward in a week >>> or so, so, if >>>>>>>>> you >>>>>>>>> have comments on the document please provide them >>> before the 1st of may. >>>>>>>>>> >>>>>>>>>> Regards, marcelo >>>>>>>>>> (mcoa doc shepherd) >>>>>>>>>> >>>>>>>>>> -------- Mensaje original -------- >>>>>>>>>> Asunto: [MEXT] I-D >>> Action:draft-ietf-monami6-multiplecoa-13.txt >>>>>>>>>> Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) >>>>>>>>>> De: Internet-Drafts@ietf.org >>> >>>>>>>>>> >> > >>>>>>>>>> Para: i-d-announce@ietf.org >>>>>>>>>> > >>>>>>>>>> CC: mext@ietf.org >> > >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A New Internet-Draft is available from the on-line >>> Internet-Drafts >>>>>>>>> directories. >>>>>>>>>> This draft is a work item of the Mobility EXTensions >>> for IPv6 Working >>>>>>>>> Group of the IETF.. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Title : Multiple Care-of Addresses Registration >>>>>>>>>> Author(s) : R. Wakikawa, et al. >>>>>>>>>> Filename : draft-ietf-monami6-multiplecoa-13..txt >>>>>>>>>> Pages : 44 >>>>>>>>>> Date : 2009-04-20 >>>>>>>>>> >>>>>>>>>> According to the current Mobile IPv6 specification, a >>> mobile node may >>>>>>>>>> have several care-of addresses, but only one, called >>> the primary >>>>>>>>>> care-of address, that can be registered with its home >>> agent and the >>>>>>>>>> correspondent nodes. However, for matters of cost, >>> bandwidth, delay, >>>>>>>>>> etc, it is useful for the mobile node to get Internet >>> access through >>>>>>>>>> multiple accesses simultaneously, in which case the >>> mobile node would >>>>>>>>>> be configured with multiple active IPv6 care-of >>> addresses. This >>>>>>>>>> document proposes extensions to the Mobile IPv6 >>> protocol to register >>>>>>>>>> and use multiple care-of addresses. The extensions >>> proposed in this >>>>>>>>>> document can be used by Mobile Routers using the NEMO =20 >>>>>>>>>> (Network >>>>>>>>>> Mobility) Basic Support protocol as well. >>>>>>>>>> >>>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>>> >>>>>>>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multipl >> ecoa-13.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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>> -------------------------------------------------------------- >>> ---------- >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> >>>>> >>> -------------------------------------------------------------- >>> ---------- >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> >>> >>> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Sat Apr 25 01:39:46 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C693A6BEE for ; Sat, 25 Apr 2009 01:39:46 -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 PbI0xk4zpioo for ; Sat, 25 Apr 2009 01:39:45 -0700 (PDT) Received: from mail-qy0-f132.google.com (mail-qy0-f132.google.com [209.85.221.132]) by core3.amsl.com (Postfix) with ESMTP id 220853A6BE1 for ; Sat, 25 Apr 2009 01:39:45 -0700 (PDT) Received: by qyk38 with SMTP id 38so730989qyk.29 for ; Sat, 25 Apr 2009 01:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=rRG6FLD9NwLMSx9rDnbGS/v5jtedCkZcc2pWFivWsxk=; b=gxFbud6Iq+aInDQP9/vxi4plcS3VFXTiw9GdhyOT9POzzvYnkqMkXigYNBcBJl46eQ boi14O1Rt+5q7bYNcuHwmOxyDEcBsLk5DDWEst5rQMQmFRfz42+oEnL8hD5xKUzaUm6d wQTbvJT69ejue6MkNyJdD/kn4a2GZxTT7cmBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=KZa7dvQfppRpncqOnZTfJHUMV+EPn63M/+m2JsYD+9o8MRnbUVmrcSPUJQYMkdsSlp Ur1pi+JWkbsDklpZkf8gSCDtsI3gR/JoICYajKTul+LhLuCjhjGd2fDWfGDIeCpcFXdF lEcgzIqKFDFzL6BB3Y/rQzgZRlOhYttxSvPoY= Received: by 10.220.74.4 with SMTP id s4mr6562413vcj.18.1240648863968; Sat, 25 Apr 2009 01:41:03 -0700 (PDT) Received: from ?172.16.0.175? ([12.235.127.2]) by mx.google.com with ESMTPS id 34sm6767152yxl.35.2009.04.25.01.41.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Apr 2009 01:41:03 -0700 (PDT) From: Ryuji Wakikawa To: Behcet Sarikaya In-Reply-To: <954696.84777.qm@web111411.mail.gq1.yahoo.com> References: <49EDEE39.50000@it.uc3m.es> <307819.85927.qm@web111409.mail.gq1.yahoo.com> <729718.46356.qm@web111410.mail.gq1.yahoo.com> <49EE173F.2090800@wichorus.com> <61210.92209.qm@web111410.mail.gq1.yahoo.com> <375902.20727.qm@web111403.mail.gq1.yahoo.com> <8CF30647-6A19-4391-BE7E-CFE87EFD8EAD@gmail.com> <222821.303.qm@web111407.mail.gq1.yahoo.com> <954696.84777.qm@web111411.mail.gq1.yahoo.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 25 Apr 2009 01:32:33 -0700 X-Mailer: Apple Mail (2.930.3) Cc: mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 08:39:46 -0000 Hi Behcet, On 2009/04/22, at 18:54, Behcet Sarikaya wrote: > Hi Ryuji, > So you are going to define a C-Flag? MCoA does not have such flag. What are you referring to? regards, ryuji > I am OK with it. But I don't understand why the only right place is > your draft. My idea is that the right place for such a thing is > 3775bis as this would avoid people with drafts not related to MCoA > having to refer to MCoA draft. > > Regards, > > Behcet > > From: Ryuji Wakikawa > To: Behcet Sarikaya > Cc: mext > Sent: Wednesday, April 22, 2009 5:02:09 PM > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > Hi Behcet, > > On 2009/04/22, at 17:45, Behcet Sarikaya wrote: > > > Hi Ryuji, > > I checked your draft. Again, I could not understand how you are > sending a registration BU at the home link as only an O-flag is > defined in your draft which is used for something else. > > Please see section 5.6.3 > > > As I mentioned to you, we discussed this related to draft-premec- > homelink and it seems like HA will reject such a BU unless something > is done, I thought you were familiar with the discussions as it > relates to your draft too. I am surprised. > > yes, I follow that discussion. > RFC3775-bis should not include any additional features like sending > BU from the home link. > We should define this in MCoA. Only if needed, draft-homelink can > refer to MCoA for this feature. > > regards, > ryuji > > > > > > > > > > Regards, > > > > Behcet > > > > From: Ryuji Wakikawa > > To: Behcet Sarikaya > > Cc: George Tsirtsis ; mext > > Sent: Wednesday, April 22, 2009 4:18:28 PM > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > Hi Behcet, > > > > On 2009/04/22, at 11:31, Behcet Sarikaya wrote: > > > > > > > > > > > From: George Tsirtsis > > > To: Behcet Sarikaya > > > Cc: mext > > > Sent: Wednesday, April 22, 2009 10:10:08 AM > > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > > > I do not think that adding home link registration to RFC3775bis > is feasible. > > > This requires logic in the MN and HA that is not directly > compatible > > > to RFC3775. The aim of RFC3775bis is to make minimal changes for > > > clarification reasons and to correct errors. Home Link > Registration as > > > defined in MCoA is neither. > > > [behcet] Why not? If it is needed in so many instances, that > qualifies it to become a base protocol feature, at least to me. > > > > We cannot add a new feature to 3775. That is the ground rule of - > bis. The chairs can clarify this. > > > > regards, > > ryuji > > > > > > > > > > > > On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya > > > wrote: > > > > Hi George, > > > > It seems in my previous reply I replied to this mail of yours > which was > > > > unrelated to the other mail you sent to which I was really > replying, > > > > apologies. > > > > Now regarding home link registration, what is the mechanism > MCoA draft > > > > uses? Ryuji mentioned some H bit but I read the draft and > couldn't confirm > > > > it. > > > > > > > > My suggestion was building on this, i.e. I suggested that > whatever you > > > > came up with can be moved to 3775bis so that other people > would not have to > > > > make normative references to your draft. > > > > > > > > That's all. > > > > > > > > Regards, > > > > > > > > Behcet > > > > > > > > ________________________________ > > > > From: George Tsirtsis > > > > To: Vijay Devarapalli > > > > Cc: Behcet Sarikaya ; mext > > > > Sent: Tuesday, April 21, 2009 2:14:55 PM > > > > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6- > multiplecoa-13.txt] > > > > > > > > ...also wrt the home link registration, I do not think what you > > > > suggest is necessary. > > > > > > > > As far as I see the other documents are informational, and > they do not > > > > yet have a formal standing in the WG. If and when they do, as > > > > Informational documents, they should not require normative > changes to > > > > anything. They should make sure what they describe (mostly > > > > implementation options in this case) are compatible not only > with > > > > RFC3775 but also with extensions to it, including Flow > Bindings. . > > > > > > > > > > > > Regards > > > > George > > > > > > > > On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli > > > > > wrote: > > > >> Behcet, > > > >> > > > >> Behcet Sarikaya wrote: > > > >>> > > > >>> *[behcet] Yes but each interface will appear to HA as a > different device > > > >>> and HA needs to assign a different HoA. Then MCoA problem > disappears.* > > > >>> *So George is saying that this is avoided by some virtual > interfaces so > > > >>> that HA does not see each interface separately. * > > > >>> *Is this explained anywhere in the draft?* > > > >>> *If yes then I am OK.* > > > >> > > > >> The home agent does not care about the multiple interfaces on > the mobile > > > >> node. It only sees the mobile node as one entity and > allocates a home > > > >> address to it. The multiple care-of addresses that the mobile > node has > > > >> will > > > >> be used by the home agent as tunnel end points. That is all. > So there is > > > >> no > > > >> issue. > > > >> > > > >> Vijay > > > >> > > > >>> > Also I have a question to Ryuji: does this draft send a > > > >>> non-deregistration BU at the home link? If yes, is he > familiar with the > > > >>> discussion going on on this subject? This is another point > of confusion > > > >>> for > > > >>> me. > > > >>> > > > >>> This has been discussed for a long time in MEXT. > > > >>> who is familiar with which discussions? I don't know your > concern here. > > > >>> *[behcet] So your answer is yes the draft sends a non- > deregistration BU > > > >>> (kind of bulk registration) at the home link.* > > > >>> *The discussion I mentioned was related to > > > >>> draft-premec-mext-extended-home-link. This draft also sends > > > >>> non-deregistration BU at the home link. So does a few more > drafts like > > > >>> **draft-devarapalli-mext-mipv6-home-link.* > > > >>> > > > >>> ** > > > >>> *[behcet] You mentioned some bit is set but I could not > understand which. > > > >>> One idea is since so many drafts need this, why not factor > this out and > > > >>> define whatever the mechanism to enable sending non- > deregistration BU in > > > >>> 3775bis. What do you think about that?* > > > >>> > > > >>> ** > > > >>> > > > >>> > Sorry if I am too much confused > > > >>> > Please don't get me wrong, I am not trying to slow down > the progress > > > >>> of > > > >>> this document.. > > > >>> > > > >>> sure, but please explain your issue more precisely. > > > >>> > > > >>> thanks! > > > >>> ryuji > > > >>> > > > >>> > > > > >>> > Regards, > > > >>> > > > > >>> > Behcet > > > >>> > From: marcelo bagnulo braun > > >>> > > > > >>> > To: mext >; Julien > Laganier > > > >>> > > >>> >; Jari Arkko > > > >>> > > > > >>> > Sent: Tuesday, April 21, 2009 11:03:05 AM > > > >>> > Subject: [MEXT] [Fwd: I-D > > > >>> Action:draft-ietf-monami6-multiplecoa-13.txt] > > > >>> > > > > >>> > We have this new version of the MCOA document that > addresses the > > > >>> comments received, including IESG review comments.. > > > >>> > To the best of my knowledge, the IESG is ok with the doc > and ready for > > > >>> publication.. > > > >>> > I am planning to ask our AD to move forward in a week or > so, so, if > > > >>> you > > > >>> have comments on the document please provide them before the > 1st of may. > > > >>> > > > > >>> > Regards, marcelo > > > >>> > (mcoa doc shepherd) > > > >>> > > > > >>> > -------- Mensaje original -------- > > > >>> > Asunto: [MEXT] I-D Action:draft-ietf-monami6- > multiplecoa-13.txt > > > >>> > Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) > > > >>> > De: Internet-Drafts@ietf.org > > > > >>> > Para: i-d-announce@ietf.org > > > > >>> > CC: mext@ietf.org > > > >>> > > > > >>> > > > > >>> > > > > >>> > A New Internet-Draft is available from the on-line > Internet-Drafts > > > >>> directories. > > > >>> > This draft is a work item of the Mobility EXTensions for > IPv6 Working > > > >>> Group of the IETF. > > > >>> > > > > >>> > > > > >>> > Title : Multiple Care-of Addresses Registration > > > >>> > Author(s) : R. Wakikawa, et al. > > > >>> > Filename : draft-ietf-monami6-multiplecoa-13..txt > > > >>> > Pages : 44 > > > >>> > Date : 2009-04-20 > > > >>> > > > > >>> > According to the current Mobile IPv6 specification, a > mobile node may > > > >>> > have several care-of addresses, but only one, called the > primary > > > >>> > care-of address, that can be registered with its home > agent and the > > > >>> > correspondent nodes. However, for matters of cost, > bandwidth, delay, > > > >>> > etc, it is useful for the mobile node to get Internet > access through > > > >>> > multiple accesses simultaneously, in which case the > mobile node would > > > >>> > be configured with multiple active IPv6 care-of > addresses.. This > > > >>> > document proposes extensions to the Mobile IPv6 protocol > to register > > > >>> > and use multiple care-of addresses. The extensions > proposed in this > > > >>> > document can be used by Mobile Routers using the NEMO > (Network > > > >>> > Mobility) Basic Support protocol as well. > > > >>> > > > > >>> > A URL for this Internet-Draft is: > > > >>> > > > > >>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.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. > > > >>> > > > > >>> > > > > >>> > > > > >>> > _______________________________________________ > > > >>> > MEXT mailing list > > > >>> > MEXT@ietf.org > > > >>> > https://www.ietf.org/mailman/listinfo/mext > > > >>> > > > >>> > > > >>> > > > >>> > ------------------------------------------------------------------------ > > > >>> > > > >>> _______________________________________________ > > > >>> MEXT mailing list > > > >>> MEXT@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/mext > > > >> > > > >> _______________________________________________ > > > >> MEXT mailing list > > > >> MEXT@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/mext > > > >> > > > > > > > > > > > > > > _______________________________________________ > > > MEXT mailing list > > > MEXT@ietf.org > > > https://www.ietf.org/mailman/listinfo/mext > > > > > > > > > From tsirtsis@googlemail.com Sat Apr 25 03:37:32 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A58D3A6A33 for ; Sat, 25 Apr 2009 03:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 4Y6X1cXUIzE0 for ; Sat, 25 Apr 2009 03:37:30 -0700 (PDT) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by core3.amsl.com (Postfix) with ESMTP id 13BE73A682B for ; Sat, 25 Apr 2009 03:37:29 -0700 (PDT) Received: by gxk10 with SMTP id 10so3168046gxk.13 for ; Sat, 25 Apr 2009 03:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=RxLFDi7ezrn+sIO2TX8tf8iFNRPWpQ2zIkNNdPsuBkY=; b=i/O1S5o2mbs0VD3Vw2pTwwcHmD1MRIGuMh5HZzpxDpBXlW7lXYJcOhLP+Mo+R+GUWw ojNWiAxqbLh+vTkalC2vs0ejeDCqtDRGTYge9iPuKU5Y4TOrnvgqUXIuozMFH8Pjq6Pf H/v6u6jb905PcVlMdLwlVZ6W3JFL6gMG/rL84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=PlTIqfRm5pE+88xB5gww6VGFkRLfjBh/bNkBWlSI0PZWX+I4P3aBchOVXV91BgiXRE Om7f10kL+YAo7FliH3q2XVhMWPg3QDJTb38lucacxMN5ZdbfsSCsRYrMK6LleeunSRS1 DiHCFL0lxzezKtrpF9bySKJToxajVp7J+Q4dk= MIME-Version: 1.0 Received: by 10.90.33.15 with SMTP id g15mr1160032agg.48.1240655929055; Sat, 25 Apr 2009 03:38:49 -0700 (PDT) Date: Sat, 25 Apr 2009 11:38:49 +0100 Message-ID: From: George Tsirtsis To: w52006@huawei.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2009 10:37:32 -0000 Behcet/Yungui, As you can see there is significant push-back in what you are proposing for this draft and I believe for good reasons. Maybe then, all this time and energy can be directed to something a bit more constructive. What you are talking about is not about protocol definition but about implementation, deployment choices etc. Since Marcelo, on behalf of the WG, is eager to get significant reviews on a number of upcoming documents why don't you take a look at draft-ietf-monami6-mipv6-analysis-05 which is about to enter WGLC, and which IMO is a much more appropriate document for this discussion. There are many possible configurations, that we should not attempt to capture in the MCoA spec (we never do that!)....but one could try to capture such examples in an info document like the analysis draft. A node with multiple interfaces attached to the same or different links, prior to initiation of MIPv6 session, is simply a node with multiple interfaces, each of which has its own IP address. The node has to make an explicit decision to turn one of these address, or maybe a different one (in case of a remote HA), into a MIPv6 home address, The node can even turn multiple of its addresses into HoAs...resulting in multiple independent MIPv6 session, possibly with different HAs. Or the MN may keep one HoA and turn all the others into CoAs....or any combination of the above.... and i am not even discussing NEMO, DSMIP etc...As I said there are many possible configurations ...which if we really want to discuss they should go in documents like that analysis doc. George On Sat, Apr 25, 2009 at 1:50 AM, Yungui Wang wrote: > Hello > > ________________________________ > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Friday, April 24, 2009 1:32 PM > To: w52006@huawei.com; Behcet Sarikaya; marcelo bagnulo braun > Cc: mext > Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.tx= t] > > Hello, > > On 4/23/09 8:54 PM, "Yungui Wang" wrote: > >>> I kind of understand what you are saying now. You are >>> concerned about the mobile node attaching to the home link >>> via multiple interfaces (since it has multiple interfaces) >>> and the result of assigning the home address to those interfaces. >>> >>> As far as RFC 3775 and the MCoA draft is concerned, the home >>> address is assigned to first interface with which the mobile >>> node attaches to the home link. This may require the mobile >>> node to "move" the home address from a MIPv6 virtual >>> interface to the physical interface with which it attaches to >>> the home link. This is implementation specific. >>> >>> If the mobile node attaches to the home link via a second >>> interface, I think the mobile node should get a new home >>> address for that interface. Not the same home address. >>> >> [Yungui] In this case, in my mind, the question is, could we treat >> this new HoA as a (home) CoA binding to the primary HoA? >> If so, the service continuity could be guaranteed because this >> interface is using the primary HoA. > > That would be out of scope. As far as the current MCoA draft is concerned= , > there is no tunneling from the home link. > > > As MCoA=C2=A0I-D described,=C2=A0when MN is=C2=A0located in foreign link > and home link=C2=A0in parallel,=C2=A0its interface=C2=A0returning home=C2= =A0may > register=C2=A0a home binding with its (HoA, CoA). Here CoA is > set=C2=A0to HoA. Due to there are two HoA in=C2=A0above situation, > maybe it needs to be clarified something, such as > 'what's the just HoA set to CoA in home binding for the > second interface'; or > 'the second interface returning home is not supported'; or > 'the second interface returning home is > implicitly de-registered > > from MCoA registration'; etc. > If it is out of scope, obviously some ambiguous operation is left. > > In addition, tunneling may be not necessary for the second > interface at home link. It=C2=A0need also register its Link-layer > Address Option for=C2=A0packet forwarding. The=C2=A0I-D can=C2=A0give a > note=C2=A0that HA shall use link-layer address to forward downlink > packet once it is presented. > > B.R. > Yungui > > > Vijay > >> Otherwise, it seems the HA >> has to initiate flow handover to another interface. >> Therefore, I think, Behcet's statement makes sense. >> >> B.R. >> Yungui >> >>> Does the above make sense? >>> >>> Vijay >>> >>>> -----Original Message----- >>>> From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] >>>> Sent: Thursday, April 23, 2009 8:54 AM >>>> To: Vijay Devarapalli; marcelo bagnulo braun >>>> Cc: mext >>>> Subject: Re: [MEXT] [Fwd: I-D >>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>> >>>> Hi Vijay, >>>>=C2=A0=C2=A0 I understand your concerns. >>>> >>>> Here is slightly revised version removing main and auxiliary: >>>> >>>> In this document it is assumed that a multi-homed MN connects >>>> to the home link using only one interface. This interface is >>>> identified by the home address assigned by the home agent. >>>> The other=C2=A0 interfaces may later on become active and connect >>>> to some other networks and get their care-of addresses and >>>> then the procedures defined in this document allow such >>>> care-of addresses to be registered with the home agent apart >>>> from the registration of the care-of addresses assigned to >>>> the=C2=A0 interface MN originally used to connect to the home link >>>> which is already defined in RFC 3775. >>>> >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> ________________________________ >>>> >>>> From: Vijay Devarapalli >>>> To: Behcet Sarikaya ; marcelo bagnulo >>>> braun >>>> Cc: mext >>>> Sent: Wednesday, April 22, 2009 6:43:13 PM >>>> Subject: Re: [MEXT] [Fwd: I-D >>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>> >>>> Hi Bechet, >>>> >>>> On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote: >>>> >>>>> Hi Marcelo, >>>>>=C2=A0 How about this little paragraph? >>>>> >>>>> In this document it is assumed that a multi-homed MN >>>> connects to the home link >>>>> using only one interface. Therefore this interface is >>>> considered as the main >>>>> interface as identified by the home address assigned by the >>>> home agent. >>>> >>>> I disagree with this. The mobile node can connect to the home >>>> link through >>>> any one of its interfaces. >>>> >>>>> The >>>>> other or auxiliary interfaces may later on become active >>>> and connect to some >>>>> other networks and get their care-of addresses and then the >>>> procedures defined >>>>> in this document allow such care-of addresses to be >>>> registered with the home >>>>> agent apart from the registration of the care-of addresses >>>> assigned to the >>>>> main interface which is already defined in RFC 3775. >>>> >>>> There is no need for the home agent to identify one of the >>>> interfaces as a >>>> "main" interface. >>>> >>>> Vijay >>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>> From: marcelo bagnulo braun >>>>> To: Behcet Sarikaya >>>>> Cc: Ryuji Wakikawa ; mext >>> >>>>> Sent: Wednesday, April 22, 2009 4:59:50 PM >>>>> Subject: Re: [MEXT] [Fwd: I-D >>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>> >>>>> Hi Bechet, >>>>> >>>>> could you send exactly what text do you think needs to be >>>> changed in the MCOA >>>>> draft, so the WG can evaluate and figure out if the changes >>>> are needed? (i.e. >>>>> please send OLD text NEW text) >>>>> >>>>> Please note that at this point in the life of the document, >>>> we only take >>>>> changes that fix errors in the document, rather than >>>> getting more features >>>>> in. >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> >>>>> Behcet Sarikaya escribi=C3=B3: >>>>>> Hi Ryuji, >>>>>>=C2=A0 I checked your draft. Again, I could not understand how >>>> you are sending a >>>>>> registration BU at the home link as only an O-flag is >>>> defined in your draft >>>>>> which is used for something else. >>>>>>=C2=A0 As I mentioned to you, we discussed this related to >>>> draft-premec-homelink >>>>>> and it seems like HA will reject such a BU unless >>>> something is done, I >>>>>> thought you were familiar with the discussions as it >>>> relates to your draft >>>>>> too. I am surprised. >>>>>>=C2=A0 Regards, >>>>>>=C2=A0 Behcet >>>>>> >>>>>> >>>> -------------------------------------------------------------- >>>> ---------- >>>>>> *From:* Ryuji Wakikawa >>>>>> *To:* Behcet Sarikaya >>>>>> *Cc:* George Tsirtsis ; mext >>>> >>>>>> *Sent:* Wednesday, April 22, 2009 4:18:28 PM >>>>>> *Subject:* Re: [MEXT] [Fwd: I-D >>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>> >>>>>> Hi Behcet, >>>>>> >>>>>> On 2009/04/22, at 11:31, Behcet Sarikaya wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> From: George Tsirtsis >>>>>> > >>>>>>> To: Behcet Sarikaya >> > >>>>>>> Cc: mext > >>>>>>> Sent: Wednesday, April 22, 2009 10:10:08 AM >>>>>>> Subject: Re: [MEXT] [Fwd: I-D >>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>> >>>>>>> I do not think that adding home link registration to >>>> RFC3775bis is feasible. >>>>>>> This requires logic in the MN and HA that is not directly >>>> compatible >>>>>>> to RFC3775. The aim of RFC3775bis is to make minimal changes for >>>>>>> clarification reasons and to correct errors. Home Link >>>> Registration as >>>>>>> defined in MCoA is neither. >>>>>>> [behcet] Why not? If it is needed in so many instances, >>>> that qualifies it to >>>>>>> become a base protocol feature, at least to me. >>>>>> >>>>>> We cannot add a new feature to 3775. That is the ground >>>> rule of -bis. The >>>>>> chairs can clarify this. >>>>>> >>>>>> regards, >>>>>> ryuji >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya >>>>>>> >>> > wrote: >>>>>>>> Hi George, >>>>>>>>=C2=A0 It seems in my previous reply I replied to this mail of >>>> yours which was >>>>>>>> unrelated to the other mail you sent to which I was >>>> really replying, >>>>>>>> apologies. >>>>>>>>=C2=A0 Now regarding home link registration, what is the >>>> mechanism MCoA draft >>>>>>>> uses? Ryuji mentioned some H bit but I read the draft >>>> and couldn't confirm >>>>>>>> it. >>>>>>>> >>>>>>>>=C2=A0 My suggestion was building on this, i.e. I suggested >>>> that whatever you >>>>>>>> came up with can be moved to 3775bis so that other >>>> people would not have to >>>>>>>> make normative references to your draft. >>>>>>>> >>>>>>>> That's all. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Behcet >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> From: George Tsirtsis >>>>>>> > >>>>>>>> To: Vijay Devarapalli >>> > >>>>>>>> Cc: Behcet Sarikaya >>> >; mext >>>>>>>> > >>>>>>>> Sent: Tuesday, April 21, 2009 2:14:55 PM >>>>>>>> Subject: Re: [MEXT] [Fwd: I-D >>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>>> >>>>>>>> ...also wrt the home link registration, I do not think what you >>>>>>>> suggest is necessary. >>>>>>>> >>>>>>>> As far as I see the other documents are informational, >>>> and they do not >>>>>>>> yet have a formal standing in the WG. If and when they do, as >>>>>>>> Informational documents,=C2=A0 they should not require >>>> normative changes to >>>>>>>> anything. They should make sure what they describe (mostly >>>>>>>> implementation options in this case) are compatible >>> not only with >>>>>>>> RFC3775 but also with extensions to it, including Flow >>>> Bindings. . >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> George >>>>>>>> >>>>>>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli >>>> >>>>>>> > >>>>>>>> wrote: >>>>>>>>> Behcet, >>>>>>>>> >>>>>>>>> Behcet Sarikaya wrote: >>>>>>>>>> >>>>>>>>>> *[behcet] Yes but each interface will appear to HA as >>>> a different device >>>>>>>>>> and HA needs to assign a different HoA. Then MCoA >>>> problem disappears.* >>>>>>>>>> *So George is saying that this is avoided by some >>>> virtual interfaces so >>>>>>>>>> that HA does not see each interface separately. * >>>>>>>>>> *Is this explained anywhere in the draft?* >>>>>>>>>> *If yes then I am OK.* >>>>>>>>> >>>>>>>>> The home agent does not care about the multiple >>>> interfaces on the mobile >>>>>>>>> node. It only sees the mobile node as one entity and >>>> allocates a home >>>>>>>>> address to it. The multiple care-of addresses that the >>>> mobile node has >>>>>>>>> will >>>>>>>>> be used by the home agent as tunnel end points. That is >>>> all.. So there is >>>>>>>>> no >>>>>>>>> issue. >>>>>>>>> >>>>>>>>> Vijay >>>>>>>>> >>>>>>>>>>>=C2=A0 Also I have a question to Ryuji: does this draft send a >>>>>>>>>> non-deregistration BU at the home link? If yes, is he >>>> familiar with the >>>>>>>>>> discussion going on on this subject? This is another >>>> point of confusion >>>>>>>>>> for >>>>>>>>>> me. >>>>>>>>>> >>>>>>>>>> This has been discussed for a long time in MEXT. >>>>>>>>>> who is familiar with which discussions? I don't know >>>> your concern here. >>>>>>>>>>=C2=A0 *[behcet] So your answer is yes the draft sends a >>>> non-deregistration BU >>>>>>>>>> (kind of bulk registration) at the home link.* >>>>>>>>>> *The discussion I mentioned was related to >>>>>>>>>> draft-premec-mext-extended-home-link. This draft also sends >>>>>>>>>> non-deregistration BU at the home link. So does a few >>>> more drafts like >>>>>>>>>> **draft-devarapalli-mext-mipv6-home-link.* >>>>>>>>>> >>>>>>>>>> ** >>>>>>>>>> *[behcet] You mentioned some bit is set but I could >>>> not understand which. >>>>>>>>>> One idea is since so many drafts need this, why not >>>> factor this out and >>>>>>>>>> define whatever the mechanism to enable sending >>>> non-deregistration BU in >>>>>>>>>> 3775bis. What do you think about that?* >>>>>>>>>> >>>>>>>>>> ** >>>>>>>>>> >>>>>>>>>>>=C2=A0 Sorry if I am too=C2=A0 much confused >>>>>>>>>>> Please don't get me wrong, I am not trying to slow >>>> down the progress >>>>>>>>>> of >>>>>>>>>> this document.. >>>>>>>>>> >>>>>>>>>> sure, but please explain your issue more precisely. >>>>>>>>>> >>>>>>>>>> thanks! >>>>>>>>>> ryuji >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Behcet >>>>>>>>>>> From: marcelo bagnulo braun >>>>>>>>>> >>>>>>>>>> < > mailto:marcelo@it.uc3m.es >>> >>>>>>>>>>> To: mext >>>> >>>>>>>>>> >>; Julien Laganier >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>> >>; Jari Arkko >>>>>>>>>> >>>> >>>>>>>>>> >>> < > mailto:jari.arkko@piuha..net > >>>>>>>>>> >>> >>>>>>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM >>>>>>>>>>> Subject: [MEXT] [Fwd: I-D >>>>>>>>>> Action:draft-ietf-monami6-multiplecoa-13.txt] >>>>>>>>>>> >>>>>>>>>>> We have this new version of the MCOA document that >>>> addresses the >>>>>>>>>> comments received, including IESG review comments. >>>>>>>>>>> To the best of my knowledge, the IESG is ok with the >>>> doc and ready for >>>>>>>>>> publication.. >>>>>>>>>>> I am planning to ask our AD to move forward in a week >>>> or so, so, if >>>>>>>>>> you >>>>>>>>>> have comments on the document please provide them >>>> before the 1st of may. >>>>>>>>>>> >>>>>>>>>>> Regards, marcelo >>>>>>>>>>> (mcoa doc shepherd) >>>>>>>>>>> >>>>>>>>>>> -------- Mensaje original -------- >>>>>>>>>>> Asunto:=C2=A0=C2=A0=C2=A0 [MEXT] I-D >>>> Action:draft-ietf-monami6-multiplecoa-13.txt >>>>>>>>>>> Fecha:=C2=A0=C2=A0=C2=A0 Mon, 20 Apr 2009 08:30:01 -0700 (PDT) >>>>>>>>>>> De:=C2=A0=C2=A0=C2=A0 Internet-Drafts@ietf.org >>>> >>>>>>>>>>> >>> > >>>>>>>>>>> Para:=C2=A0=C2=A0=C2=A0 i-d-announce@ietf.org >>> >>>>>>>>>>> >> > >>>>>>>>>>> CC:=C2=A0=C2=A0=C2=A0 mext@ietf.org >>> > >>>>>>>>>>> < > mailto:mext@ietf.org >> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts >>>>>>>>>> directories. >>>>>>>>>>> This draft is a work item of the Mobility EXTensions >>>> for IPv6 Working >>>>>>>>>> Group of the IETF.. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 : Multiple Care-of Addresses Registration >>>>>>>>>>>=C2=A0=C2=A0=C2=A0 Author(s)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : R. = Wakikawa, et al. >>>>>>>>>>>=C2=A0=C2=A0=C2=A0 Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 : draft-ietf-monami6-multiplecoa-13..txt >>>>>>>>>>>=C2=A0=C2=A0=C2=A0 Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 : 44 >>>>>>>>>>>=C2=A0=C2=A0=C2=A0 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 : 2009-04-20 >>>>>>>>>>> >>>>>>>>>>> According to the current Mobile IPv6 specification, a >>>> mobile node may >>>>>>>>>>> have several care-of addresses, but only one, called >>>> the primary >>>>>>>>>>> care-of address, that can be registered with its home >>>> agent and the >>>>>>>>>>> correspondent nodes.=C2=A0 However, for matters of cost, >>>> bandwidth, delay, >>>>>>>>>>> etc, it is useful for the mobile node to get Internet >>>> access through >>>>>>>>>>> multiple accesses simultaneously, in which case the >>>> mobile node would >>>>>>>>>>> be configured with multiple active IPv6 care-of >>>> addresses.=C2=A0 This >>>>>>>>>>> document proposes extensions to the Mobile IPv6 >>>> protocol to register >>>>>>>>>>> and use multiple care-of addresses.=C2=A0 The extensions >>>> proposed in this >>>>>>>>>>> document can be used by Mobile Routers using the >>> NEMO (Network >>>>>>>>>>> Mobility) Basic Support protocol as well. >>>>>>>>>>> >>>>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>>>> >>>>>>>>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multipl >>> ecoa-13.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. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MEXT mailing list >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>> > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>> -------------------------------------------------------------- >>>> ---------- >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> MEXT mailing list >>>>>>>>>> MEXT@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> MEXT mailing list >>>>>>>>> MEXT@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org < > mailto:MEXT@ietf.org > > >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> >>>>>> >>>> -------------------------------------------------------------- >>>> ---------- >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From w52006@huawei.com Sun Apr 26 19:03:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69BD23A6A7E for ; Sun, 26 Apr 2009 19:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.102 X-Spam-Level: * X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[AWL=-2.298, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_81=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 TtuQ7zKvGxDW for ; Sun, 26 Apr 2009 19:03:04 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id B5F8E3A67B5 for ; Sun, 26 Apr 2009 19:03:03 -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 <0KIQ00JOGLR9F4@szxga02-in.huawei.com> for mext@ietf.org; Mon, 27 Apr 2009 10:04:21 +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 <0KIQ003G5LR9XU@szxga02-in.huawei.com> for mext@ietf.org; Mon, 27 Apr 2009 10:04:21 +0800 (CST) Received: from w52006a ([10.164.12.21]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIQ007H8LR8DI@szxml06-in.huawei.com> for mext@ietf.org; Mon, 27 Apr 2009 10:04:21 +0800 (CST) Date: Mon, 27 Apr 2009 10:04:18 +0800 From: Yungui Wang In-reply-to: To: 'George Tsirtsis' Message-id: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> Organization: huawei 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=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcnFkt/0kEn6WsW+SMuUmL90IEW/ZgBPMHEw Cc: 'mext' Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 02:03:06 -0000 Hello=20 > -----Original Message----- > From: George Tsirtsis [mailto:tsirtsis@googlemail.com]=20 > Sent: Saturday, April 25, 2009 6:39 PM > To: w52006@huawei.com > Cc: Vijay Devarapalli; Behcet Sarikaya; marcelo bagnulo braun; mext > Subject: a suggestion ...Re: [MEXT] [Fwd: I-D=20 > Action:draft-ietf-monami6-multiplecoa-13.txt] >=20 > Behcet/Yungui, >=20 > As you can see there is significant push-back in what you are > proposing for this draft and I believe for good reasons. > Maybe then, all this time and energy can be directed to something a > bit more constructive. I wouldn't want to delay this document. Please move forward if = necessary. However, home binding is a little controversial new feature which was=20 recently added from -11. Well, I am only interesting with its operation. = Maybe it is more appropriate to clarify it offline. You are appreciated = to=20 do that. :) >=20 > What you are talking about is not about protocol definition but about > implementation, deployment choices etc. > Since Marcelo, on behalf of the WG, is eager to get significant > reviews on a number of upcoming documents why don't you take a look at > draft-ietf-monami6-mipv6-analysis-05 which is about to enter WGLC, and > which IMO is a much more appropriate document for this discussion. > There are many possible configurations, that we should not attempt to > capture in the MCoA spec (we never do that!)....but one could try to > capture such examples in an info document like the analysis draft. >=20 See blow. > A node with multiple interfaces attached to the same or different > links, prior to initiation of MIPv6 session, is simply a node with > multiple interfaces, each of which has its own IP address. The node > has to make an explicit decision to turn one of these address, or > maybe a different one (in case of a remote HA), into a MIPv6 home > address, Agree. > The node can even turn multiple of its addresses into HoAs...resulting > in multiple independent MIPv6 session, possibly with different HAs. Or > the MN may keep one HoA and turn all the others into CoAs....or any > combination of the above....=20 Actually, I were commenting home binding operation of MCoA in case of=20 multiple interfaces of MN returning home. I am not conerned of you = stated=20 how to configure address(es) on the MN, but how the HA to process the=20 multiple home binding registration at home link under different = situation. Thanks. Yungui > and i am not even discussing NEMO, DSMIP > etc...As I said there are many possible configurations ...which if we > really want to discuss they should go in documents like that analysis > doc. >=20 > George >=20 > On Sat, Apr 25, 2009 at 1:50 AM, Yungui Wang=20 > wrote: > > Hello > > > > ________________________________ > > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > > Sent: Friday, April 24, 2009 1:32 PM > > To: w52006@huawei.com; Behcet Sarikaya; marcelo bagnulo braun > > Cc: mext > > Subject: Re: [MEXT] [Fwd: I-D=20 > Action:draft-ietf-monami6-multiplecoa-13.txt] > > > > Hello, > > > > On 4/23/09 8:54 PM, "Yungui Wang" wrote: > > > >>> I kind of understand what you are saying now. You are > >>> concerned about the mobile node attaching to the home link > >>> via multiple interfaces (since it has multiple interfaces) > >>> and the result of assigning the home address to those interfaces. > >>> > >>> As far as RFC 3775 and the MCoA draft is concerned, the home > >>> address is assigned to first interface with which the mobile > >>> node attaches to the home link. This may require the mobile > >>> node to "move" the home address from a MIPv6 virtual > >>> interface to the physical interface with which it attaches to > >>> the home link. This is implementation specific. > >>> > >>> If the mobile node attaches to the home link via a second > >>> interface, I think the mobile node should get a new home > >>> address for that interface. Not the same home address. > >>> > >> [Yungui] In this case, in my mind, the question is, could we treat > >> this new HoA as a (home) CoA binding to the primary HoA? > >> If so, the service continuity could be guaranteed because this > >> interface is using the primary HoA. > > > > That would be out of scope. As far as the current MCoA=20 > draft is concerned, > > there is no tunneling from the home link. > > > > > > As MCoA?I-D described,?when MN is?located in foreign link > > and home link?in parallel,?its interface?returning home?may > > register?a home binding with its (HoA, CoA). Here CoA is > > set?to HoA. Due to there are two HoA in?above situation, > > maybe it needs to be clarified something, such as > > 'what's the just HoA set to CoA in home binding for the > > second interface'; or > > 'the second interface returning home is not supported'; or > > 'the second interface returning home is > > implicitly de-registered > > > > from MCoA registration'; etc. > > If it is out of scope, obviously some ambiguous operation is left. > > > > In addition, tunneling may be not necessary for the second > > interface at home link. It?need also register its Link-layer > > Address Option for?packet forwarding. The?I-D can?give a > > note?that HA shall use link-layer address to forward downlink > > packet once it is presented. > > > > B.R. > > Yungui > > > > > > Vijay > > > >> Otherwise, it seems the HA > >> has to initiate flow handover to another interface. > >> Therefore, I think, Behcet's statement makes sense. > >> > >> B.R. > >> Yungui > >> > >>> Does the above make sense? > >>> > >>> Vijay > >>> > >>>> -----Original Message----- > >>>> From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > >>>> Sent: Thursday, April 23, 2009 8:54 AM > >>>> To: Vijay Devarapalli; marcelo bagnulo braun > >>>> Cc: mext > >>>> Subject: Re: [MEXT] [Fwd: I-D > >>>> Action:draft-ietf-monami6-multiplecoa-13.txt] > >>>> > >>>> Hi Vijay, > >>>>?? I understand your concerns. > >>>> > >>>> Here is slightly revised version removing main and auxiliary: > >>>> > >>>> In this document it is assumed that a multi-homed MN connects > >>>> to the home link using only one interface. This interface is > >>>> identified by the home address assigned by the home agent. > >>>> The other? interfaces may later on become active and connect > >>>> to some other networks and get their care-of addresses and > >>>> then the procedures defined in this document allow such > >>>> care-of addresses to be registered with the home agent apart > >>>> from the registration of the care-of addresses assigned to > >>>> the? interface MN originally used to connect to the home link > >>>> which is already defined in RFC 3775. > >>>> > >>>> > >>>> Regards, > >>>> > >>>> Behcet > >>>> > >>>> ________________________________ > >>>> > >>>> From: Vijay Devarapalli > >>>> To: Behcet Sarikaya ; marcelo bagnulo > >>>> braun > >>>> Cc: mext > >>>> Sent: Wednesday, April 22, 2009 6:43:13 PM > >>>> Subject: Re: [MEXT] [Fwd: I-D > >>>> Action:draft-ietf-monami6-multiplecoa-13.txt] > >>>> > >>>> Hi Bechet, > >>>> > >>>> On 4/22/09 4:07 PM, "Behcet Sarikaya" wrote: > >>>> > >>>>> Hi Marcelo, > >>>>>? How about this little paragraph? > >>>>> > >>>>> In this document it is assumed that a multi-homed MN > >>>> connects to the home link > >>>>> using only one interface. Therefore this interface is > >>>> considered as the main > >>>>> interface as identified by the home address assigned by the > >>>> home agent. > >>>> > >>>> I disagree with this. The mobile node can connect to the home > >>>> link through > >>>> any one of its interfaces. > >>>> > >>>>> The > >>>>> other or auxiliary interfaces may later on become active > >>>> and connect to some > >>>>> other networks and get their care-of addresses and then the > >>>> procedures defined > >>>>> in this document allow such care-of addresses to be > >>>> registered with the home > >>>>> agent apart from the registration of the care-of addresses > >>>> assigned to the > >>>>> main interface which is already defined in RFC 3775. > >>>> > >>>> There is no need for the home agent to identify one of the > >>>> interfaces as a > >>>> "main" interface. > >>>> > >>>> Vijay > >>>> > >>>>> Regards, > >>>>> > >>>>> Behcet > >>>>> > >>>>> From: marcelo bagnulo braun > >>>>> To: Behcet Sarikaya > >>>>> Cc: Ryuji Wakikawa ; mext > >>> > >>>>> Sent: Wednesday, April 22, 2009 4:59:50 PM > >>>>> Subject: Re: [MEXT] [Fwd: I-D > >>>> Action:draft-ietf-monami6-multiplecoa-13.txt] > >>>>> > >>>>> Hi Bechet, > >>>>> > >>>>> could you send exactly what text do you think needs to be > >>>> changed in the MCOA > >>>>> draft, so the WG can evaluate and figure out if the changes > >>>> are needed? (i.e. > >>>>> please send OLD text NEW text) > >>>>> > >>>>> Please note that at this point in the life of the document, > >>>> we only take > >>>>> changes that fix errors in the document, rather than > >>>> getting more features > >>>>> in. > >>>>> > >>>>> Regards, marcelo > >>>>> > >>>>> > >>>>> > >>>>> Behcet Sarikaya escribi=F3: > >>>>>> Hi Ryuji, > >>>>>>? I checked your draft. Again, I could not understand how > >>>> you are sending a > >>>>>> registration BU at the home link as only an O-flag is > >>>> defined in your draft > >>>>>> which is used for something else. > >>>>>>? As I mentioned to you, we discussed this related to > >>>> draft-premec-homelink > >>>>>> and it seems like HA will reject such a BU unless > >>>> something is done, I > >>>>>> thought you were familiar with the discussions as it > >>>> relates to your draft > >>>>>> too. I am surprised. > >>>>>>? Regards, > >>>>>>? Behcet > >>>>>> > >>>>>> > >>>> -------------------------------------------------------------- > >>>> ---------- > >>>>>> *From:* Ryuji Wakikawa > >>>>>> *To:* Behcet Sarikaya > >>>>>> *Cc:* George Tsirtsis ; mext > >>>> > >>>>>> *Sent:* Wednesday, April 22, 2009 4:18:28 PM > >>>>>> *Subject:* Re: [MEXT] [Fwd: I-D > >>>> Action:draft-ietf-monami6-multiplecoa-13.txt] > >>>>>> > >>>>>> Hi Behcet, > >>>>>> > >>>>>> On 2009/04/22, at 11:31, Behcet Sarikaya wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> From: George Tsirtsis >>>>>>> > > >>>>>>> To: Behcet Sarikaya >>> > > >>>>>>> Cc: mext > > >>>>>>> Sent: Wednesday, April 22, 2009 10:10:08 AM > >>>>>>> Subject: Re: [MEXT] [Fwd: I-D > >>>> Action:draft-ietf-monami6-multiplecoa-13.txt] > >>>>>>> > >>>>>>> I do not think that adding home link registration to > >>>> RFC3775bis is feasible. > >>>>>>> This requires logic in the MN and HA that is not directly > >>>> compatible > >>>>>>> to RFC3775. The aim of RFC3775bis is to make minimal=20 > changes for > >>>>>>> clarification reasons and to correct errors. Home Link > >>>> Registration as > >>>>>>> defined in MCoA is neither. > >>>>>>> [behcet] Why not? If it is needed in so many instances, > >>>> that qualifies it to > >>>>>>> become a base protocol feature, at least to me. > >>>>>> > >>>>>> We cannot add a new feature to 3775. That is the ground > >>>> rule of -bis. The > >>>>>> chairs can clarify this. > >>>>>> > >>>>>> regards, > >>>>>> ryuji > >>>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> On Wed, Apr 22, 2009 at 4:06 PM, Behcet Sarikaya > >>>>>>> >>>> > wrote: > >>>>>>>> Hi George, > >>>>>>>>? It seems in my previous reply I replied to this mail of > >>>> yours which was > >>>>>>>> unrelated to the other mail you sent to which I was > >>>> really replying, > >>>>>>>> apologies. > >>>>>>>>? Now regarding home link registration, what is the > >>>> mechanism MCoA draft > >>>>>>>> uses? Ryuji mentioned some H bit but I read the draft > >>>> and couldn't confirm > >>>>>>>> it. > >>>>>>>> > >>>>>>>>? My suggestion was building on this, i.e. I suggested > >>>> that whatever you > >>>>>>>> came up with can be moved to 3775bis so that other > >>>> people would not have to > >>>>>>>> make normative references to your draft. > >>>>>>>> > >>>>>>>> That's all. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Behcet > >>>>>>>> > >>>>>>>> ________________________________ > >>>>>>>> From: George Tsirtsis >>>>>>>> > > >>>>>>>> To: Vijay Devarapalli >>>> > > >>>>>>>> Cc: Behcet Sarikaya >>>> >; mext > >>>>>>>> > > >>>>>>>> Sent: Tuesday, April 21, 2009 2:14:55 PM > >>>>>>>> Subject: Re: [MEXT] [Fwd: I-D > >>>> Action:draft-ietf-monami6-multiplecoa-13.txt] > >>>>>>>> > >>>>>>>> ...also wrt the home link registration, I do not=20 > think what you > >>>>>>>> suggest is necessary. > >>>>>>>> > >>>>>>>> As far as I see the other documents are informational, > >>>> and they do not > >>>>>>>> yet have a formal standing in the WG. If and when they do, as > >>>>>>>> Informational documents,? they should not require > >>>> normative changes to > >>>>>>>> anything. They should make sure what they describe (mostly > >>>>>>>> implementation options in this case) are compatible > >>> not only with > >>>>>>>> RFC3775 but also with extensions to it, including Flow > >>>> Bindings. . > >>>>>>>> > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> George > >>>>>>>> > >>>>>>>> On Tue, Apr 21, 2009 at 7:58 PM, Vijay Devarapalli > >>>> >>>>>>>> > > >>>>>>>> wrote: > >>>>>>>>> Behcet, > >>>>>>>>> > >>>>>>>>> Behcet Sarikaya wrote: > >>>>>>>>>> > >>>>>>>>>> *[behcet] Yes but each interface will appear to HA as > >>>> a different device > >>>>>>>>>> and HA needs to assign a different HoA. Then MCoA > >>>> problem disappears.* > >>>>>>>>>> *So George is saying that this is avoided by some > >>>> virtual interfaces so > >>>>>>>>>> that HA does not see each interface separately. * > >>>>>>>>>> *Is this explained anywhere in the draft?* > >>>>>>>>>> *If yes then I am OK.* > >>>>>>>>> > >>>>>>>>> The home agent does not care about the multiple > >>>> interfaces on the mobile > >>>>>>>>> node. It only sees the mobile node as one entity and > >>>> allocates a home > >>>>>>>>> address to it. The multiple care-of addresses that the > >>>> mobile node has > >>>>>>>>> will > >>>>>>>>> be used by the home agent as tunnel end points. That is > >>>> all.. So there is > >>>>>>>>> no > >>>>>>>>> issue. > >>>>>>>>> > >>>>>>>>> Vijay > >>>>>>>>> > >>>>>>>>>>>? Also I have a question to Ryuji: does this draft send a > >>>>>>>>>> non-deregistration BU at the home link? If yes, is he > >>>> familiar with the > >>>>>>>>>> discussion going on on this subject? This is another > >>>> point of confusion > >>>>>>>>>> for > >>>>>>>>>> me. > >>>>>>>>>> > >>>>>>>>>> This has been discussed for a long time in MEXT. > >>>>>>>>>> who is familiar with which discussions? I don't know > >>>> your concern here. > >>>>>>>>>>? *[behcet] So your answer is yes the draft sends a > >>>> non-deregistration BU > >>>>>>>>>> (kind of bulk registration) at the home link.* > >>>>>>>>>> *The discussion I mentioned was related to > >>>>>>>>>> draft-premec-mext-extended-home-link. This draft also sends > >>>>>>>>>> non-deregistration BU at the home link. So does a few > >>>> more drafts like > >>>>>>>>>> **draft-devarapalli-mext-mipv6-home-link.* > >>>>>>>>>> > >>>>>>>>>> ** > >>>>>>>>>> *[behcet] You mentioned some bit is set but I could > >>>> not understand which. > >>>>>>>>>> One idea is since so many drafts need this, why not > >>>> factor this out and > >>>>>>>>>> define whatever the mechanism to enable sending > >>>> non-deregistration BU in > >>>>>>>>>> 3775bis. What do you think about that?* > >>>>>>>>>> > >>>>>>>>>> ** > >>>>>>>>>> > >>>>>>>>>>>? Sorry if I am too? much confused > >>>>>>>>>>> Please don't get me wrong, I am not trying to slow > >>>> down the progress > >>>>>>>>>> of > >>>>>>>>>> this document.. > >>>>>>>>>> > >>>>>>>>>> sure, but please explain your issue more precisely. > >>>>>>>>>> > >>>>>>>>>> thanks! > >>>>>>>>>> ryuji > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> > >>>>>>>>>>> Behcet > >>>>>>>>>>> From: marcelo bagnulo braun >>>>>>>>>>> > >>>>>>>>>> < > > mailto:marcelo@it.uc3m.es >>> > >>>>>>>>>>> To: mext > >>>> >>>>>>>>>>> >>; Julien Laganier > >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> >>; Jari Arkko > >>>>>>>>>> > >>>> > >>>>>>>>>> >>>> < > > mailto:jari.arkko@piuha..net > > >>>>>>>>>> >>> > >>>>>>>>>>> Sent: Tuesday, April 21, 2009 11:03:05 AM > >>>>>>>>>>> Subject: [MEXT] [Fwd: I-D > >>>>>>>>>> Action:draft-ietf-monami6-multiplecoa-13.txt] > >>>>>>>>>>> > >>>>>>>>>>> We have this new version of the MCOA document that > >>>> addresses the > >>>>>>>>>> comments received, including IESG review comments. > >>>>>>>>>>> To the best of my knowledge, the IESG is ok with the > >>>> doc and ready for > >>>>>>>>>> publication.. > >>>>>>>>>>> I am planning to ask our AD to move forward in a week > >>>> or so, so, if > >>>>>>>>>> you > >>>>>>>>>> have comments on the document please provide them > >>>> before the 1st of may. > >>>>>>>>>>> > >>>>>>>>>>> Regards, marcelo > >>>>>>>>>>> (mcoa doc shepherd) > >>>>>>>>>>> > >>>>>>>>>>> -------- Mensaje original -------- > >>>>>>>>>>> Asunto:??? [MEXT] I-D > >>>> Action:draft-ietf-monami6-multiplecoa-13.txt > >>>>>>>>>>> Fecha:??? Mon, 20 Apr 2009 08:30:01 -0700 (PDT) > >>>>>>>>>>> De:??? Internet-Drafts@ietf.org > >>>> > >>>>>>>>>>> >>>> > > >>>>>>>>>>> Para:??? i-d-announce@ietf.org > >>> > >>>>>>>>>>> >>> > > >>>>>>>>>>> CC:??? mext@ietf.org >>>> > > >>>>>>>>>>> < > > mailto:mext@ietf.org >> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> A New Internet-Draft is available from the on-line > >>>> Internet-Drafts > >>>>>>>>>> directories. > >>>>>>>>>>> This draft is a work item of the Mobility EXTensions > >>>> for IPv6 Working > >>>>>>>>>> Group of the IETF.. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>??? Title????????? : Multiple Care-of Addresses=20 > Registration > >>>>>>>>>>>??? Author(s)????? : R. Wakikawa, et al. > >>>>>>>>>>>??? Filename??????? :=20 > draft-ietf-monami6-multiplecoa-13..txt > >>>>>>>>>>>??? Pages????????? : 44 > >>>>>>>>>>>??? Date??????????? : 2009-04-20 > >>>>>>>>>>> > >>>>>>>>>>> According to the current Mobile IPv6 specification, a > >>>> mobile node may > >>>>>>>>>>> have several care-of addresses, but only one, called > >>>> the primary > >>>>>>>>>>> care-of address, that can be registered with its home > >>>> agent and the > >>>>>>>>>>> correspondent nodes.? However, for matters of cost, > >>>> bandwidth, delay, > >>>>>>>>>>> etc, it is useful for the mobile node to get Internet > >>>> access through > >>>>>>>>>>> multiple accesses simultaneously, in which case the > >>>> mobile node would > >>>>>>>>>>> be configured with multiple active IPv6 care-of > >>>> addresses.? This > >>>>>>>>>>> document proposes extensions to the Mobile IPv6 > >>>> protocol to register > >>>>>>>>>>> and use multiple care-of addresses.? The extensions > >>>> proposed in this > >>>>>>>>>>> document can be used by Mobile Routers using the > >>> NEMO (Network > >>>>>>>>>>> Mobility) Basic Support protocol as well. > >>>>>>>>>>> > >>>>>>>>>>> A URL for this Internet-Draft is: > >>>>>>>>>>> > >>>>>>>>>> > >>>> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multipl > >>> ecoa-13.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. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> MEXT mailing list > >>>>>>>>>>> MEXT@ietf.org >>>>>>>>>>> > > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>> -------------------------------------------------------------- > >>>> ---------- > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> MEXT mailing list > >>>>>>>>>> MEXT@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> MEXT mailing list > >>>>>>>>> MEXT@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> MEXT mailing list > >>>>>>> MEXT@ietf.org < > > mailto:MEXT@ietf.org > > > >>>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>> > >>>>>> > >>>>>> > >>>> -------------------------------------------------------------- > >>>> ---------- > >>>>>> > >>>>>> _______________________________________________ > >>>>>> MEXT mailing list > >>>>>> MEXT@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >>> > >> > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > > > >=20 From sgundave@cisco.com Sun Apr 26 20:42:38 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55F13A69AA for ; Sun, 26 Apr 2009 20:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 w-DL3qYv+dsC for ; Sun, 26 Apr 2009 20:42:37 -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 A4F273A69A7 for ; Sun, 26 Apr 2009 20:42:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,251,1238976000"; d="scan'208";a="177103627" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 27 Apr 2009 03:43:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3R3hwOD006495; Sun, 26 Apr 2009 20:43:58 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3R3hwYU018503; Mon, 27 Apr 2009 03:43:58 GMT Date: Sun, 26 Apr 2009 20:43:58 -0700 (PDT) From: Sri Gundavelli To: Yungui Wang In-Reply-To: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> Message-ID: References: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2443; t=1240803838; x=1241667838; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20a=20suggestion=20...Re=3A=20[F wd=3A=20I-D=20Action=3Adraft-ietf-monami6-multiplecoa-13.txt ] |Sender:=20; bh=pGyn48GE/tX3mrCBvp+sfez4+M1Ft2YCtmawJePgrpg=; b=t2SamHDnJ9wNRBl3rTus3u5wSQOl5y4L4A0KGR3BtZCM9PQqf65C2s4k6D d6Ya5B97xOEMuY3hUwU6eJk5e1Wnh1yRNCYzYPZERrKmZ6UwcvF48RJcePtd qVGsksa5Xp; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'mext' Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 03:42:38 -0000 On Mon, 27 Apr 2009, Yungui Wang wrote: > > I wouldn't want to delay this document. Please move forward if necessary. > > However, home binding is a little controversial new feature which was > recently added from -11. Well, I am only interesting with its operation. > Maybe it is more appropriate to clarify it offline. You are appreciated to > do that. :) > > I agree with this assessment. I dont want to delay this doc either, you can go ahead. But, I just dont know how to implement the mobile node's home link attachment with non-NDP mode. The mobile node can use its home address, but cannot participate in NDP. It can use HoA on the home link, and can only send and receive packets with its home agent. This requires special semantics, or even driver layer interface, not a socket layer interface. Atleast in Cisco IOS, where there is some programming constructs, I do not know how to configure the HoA on the home link, disable NDP, still use HoA for sending packets with the link-layer header and for receiving packets to HoA, while its not defending that address. Or, I dont know how to make the mobile node's IPv6 interface to believe that the prefix is an off-link prefix, while the RA's carry the prefixes as onlink prefixes, for it to send all packets to destinations through the router. And for the home agent to disable the REDIRECT semantic on the home interface for supporting this through router indirection. This requires some changes as how IPv6 is confiugred on interfaces and how ND is enabled or how applications see it. Its possible with hacks. I assume some one implemented this on Linux, using standard socket layer interface per 4584 or 3542. Also, we are generally so worried about the integrity of the host, the programming layers, specially the interface integrity and the any changes to it, but for supporting this mode, we are going out of our way and the implications are hardly ever analyzed, like the home interface designation, multiple hoa generation, or the implementation complexity. But I guess, its CMIP with a free check to rewrite the host stack. Page 22, last paragraph: "If the home agent, according to its local policy, needs to deliver packets to the mobile node over the home link, an issue arises with respect to how the home agent discovers the mobile node's link local address. " Is it link local or link-layer ? Regards Sri From tsirtsis@googlemail.com Mon Apr 27 03:29:21 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4413A6B96 for ; Mon, 27 Apr 2009 03:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 EmWBLc6AAzuR for ; Mon, 27 Apr 2009 03:29:20 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 10D8A3A69FA for ; Mon, 27 Apr 2009 03:29:19 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so2589493ywj.49 for ; Mon, 27 Apr 2009 03:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=rmj1g5cm7CYGD0l4xgwkh97vcudeq6vXdC3yXNfTNEM=; b=l6VfRg0Guim5FbIKXph9AuzZmJj2bLiQNJy+fZHtZFUcfZMX+GOijRb8AJ/aqDiOHs bpcQS4HCdAvAubSshtZacNx4tkfCpcxLhd7qYSSHtk2IlpAz1NpKBnWHPesHJ3NX11Bo gZM9pLB7OFNQ4RzuSIxDLX4ezcJx6I/5aq4bc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JC6D3gbSl7SZD10ANsvpX+yKxfl+9ZxODyPU7Hd6xXiIdhuUBcVdjstjb+kQtVCHJT Jh9lH6oFDxZsjcJdjlmUoz3pLXfFI9i5B1vS9mddAkNG7burfWMdz34CO/FHkSv+NZTz 0CVJTd64CY9FcjaouWDykHEYQPD+j48+wdO5g= MIME-Version: 1.0 Received: by 10.90.93.13 with SMTP id q13mr6341803agb.19.1240828240248; Mon, 27 Apr 2009 03:30:40 -0700 (PDT) In-Reply-To: References: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> Date: Mon, 27 Apr 2009 11:30:40 +0100 Message-ID: From: George Tsirtsis To: Sri Gundavelli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mext Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 10:29:21 -0000 Hi Sri, I think the authors appreciate that the non-NDP home link operation is not straightforward, but as you say this is client MIP and changing the end node is part of the game. Also, the home link operation was the subject of lengthy discussion a few months back though and the draft captures the result of this discussion, so, I am not sure it is fair to say that the implications were not discussed.. Regards George On Mon, Apr 27, 2009 at 4:43 AM, Sri Gundavelli wrote: > > > On Mon, 27 Apr 2009, Yungui Wang wrote: > >> >> I wouldn't want to delay this document. Please move forward if necessary. >> >> However, home binding is a little controversial new feature which was >> recently added from -11. Well, I am only interesting with its operation. >> Maybe it is more appropriate to clarify it offline. You are appreciated to >> do that. :) >> >> > > I agree with this assessment. I dont want to delay this doc either, you > can go ahead. But, I just dont know how to implement the mobile node's > home link attachment with non-NDP mode. The mobile node can use its home > address, but cannot participate in NDP. It can use HoA on the home link, > and can only send and receive packets with its home agent. This requires > special semantics, or even driver layer interface, not a socket layer > interface. > > Atleast in Cisco IOS, where there is some programming constructs, I do > not know how to configure the HoA on the home link, disable NDP, still use > HoA for sending packets with the link-layer header and for receiving > packets to HoA, while its not defending that address. Or, I dont know how > to make the mobile node's IPv6 interface to believe that the prefix is an > off-link prefix, while the RA's carry the prefixes as onlink prefixes, for > it to send all packets to destinations through the router. And for the > home agent to disable the REDIRECT semantic on the home interface for > supporting this through router indirection. This requires some changes as > how IPv6 is confiugred on interfaces and how ND is enabled or how > applications see it. Its possible with hacks. I assume some one > implemented this on Linux, using standard socket layer interface > per 4584 or 3542. > > Also, we are generally so worried about the integrity of the host, the > programming layers, specially the interface integrity and the any changes > to it, but for supporting this mode, we are going out of our way and the > implications are hardly ever analyzed, like the home interface > designation, multiple hoa generation, or the implementation complexity. > But I guess, its CMIP with a free check to rewrite the host stack. > > > Page 22, last paragraph: > "If the home agent, according to its local policy, needs to deliver > packets to the mobile node over the home link, an issue arises > with respect to how the home agent discovers the mobile node's > link local address. " > > Is it link local or link-layer ? > > > Regards > Sri > > > > > From behcetsarikaya@yahoo.com Mon Apr 27 07:58:52 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86FD33A6F69 for ; Mon, 27 Apr 2009 07:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 SoRo86dS10Js for ; Mon, 27 Apr 2009 07:58:51 -0700 (PDT) Received: from n9.bullet.re3.yahoo.com (n9.bullet.re3.yahoo.com [68.142.237.94]) by core3.amsl.com (Postfix) with SMTP id 530413A68AF for ; Mon, 27 Apr 2009 07:58:51 -0700 (PDT) Received: from [68.142.230.28] by n9.bullet.re3.yahoo.com with NNFMP; 27 Apr 2009 15:00:12 -0000 Received: from [67.195.9.83] by t1.bullet.re2.yahoo.com with NNFMP; 27 Apr 2009 15:00:11 -0000 Received: from [67.195.9.110] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 27 Apr 2009 15:00:11 -0000 Received: from [127.0.0.1] by omp114.mail.gq1.yahoo.com with NNFMP; 27 Apr 2009 14:57:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 113903.53442.bm@omp114.mail.gq1.yahoo.com Received: (qmail 11379 invoked by uid 60001); 27 Apr 2009 15:00:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1240844411; bh=1A7HTbXdKmWG9X4l/DAoyseJcmgL2xJgzO/VnQoOURg=; 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=Aik7VKqBVSkLW5vkDBKdXxMvfkHbF7bEr/VS2KfN+8jELxsCHastl0+gR3LZiF29hYq7ljdNVcjFcl71acZQCwj0WDMwG+XO+WV5F8YlGObRetlzU2V/YLG2+/ZX1B+VjqnYkT1sxGJ3RptSrEMKUWxJLpCBKr048LWT4LBUVnY= 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=zQ7sk+VTLm7fdloVjvtQR7TVxg4v+m8JZ9ZROvRYq59r11rgeKddiXTPXVY7vjtssgZLn7eYXrYib7yItzUjq32f6tALYchSdLgL0YK+efWeKwyP6eLLXCe2y2bGGG5XUO6EVqemWsRcAVhxfbx9LJiBqiUjk58ViBl8vdiRIDQ=; Message-ID: <212164.10269.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: xky464MVM1m91fMFLnYUpttRGOUak7WL0JuVuZ5vRmwTJP3FuDJorRCk2Qg7rjxJvLxiJkGyg4oZT1p_xD9BpcJ27.ui.NY5xXcVy_2pzu7mGgtl7dMsOougatR3yaaCfEHxiCndWrkRKvl5R3Rvt.7SRLEnA6ri7tshk_z.IEKDa8SRgB3.a47m9Et2.jB7l.jRm4qxYmeDM3Ow7Y4G3DFu_ridfwOdtyoadoRwUakqn2Jxm1sQx0kXh4dLqNh5qTHiGTRfzvY91ejjTn8gfznJgj05yhbxgdi63gR8yti8RF0SGjU76WtZKhoQEpHAn12bcHq0 Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Mon, 27 Apr 2009 08:00:10 PDT X-Mailer: YahooMailRC/1277.35 YahooMailWebService/0.7.289.1 References: Date: Mon, 27 Apr 2009 08:00:10 -0700 (PDT) From: Behcet Sarikaya To: George Tsirtsis In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-495113741-1240844410=:10269" Cc: mext Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 14:58:52 -0000 --0-495113741-1240844410=:10269 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi George,=0A=A0 Your points well taken.=0AThat said, is this doc draft-iet= f-monami6-mipv6-analysis-05 in the charter? =0AMy suggestion was to include= the crust of the analysis and basic assumptions into your doc in a single = paragraph and you could replace that with the reference to this analysis dr= aft.=0A=A0 It seems like you guys are pretty reluctant for any progressive = suggestions.=0A=A0 Lastly, I looked at the draft again, as Vijay said this = draft does not talk about any packet forwarding to any of CoAs for which th= e BIDs were given. I don't think this draft is a prerequisite for any flow = binding work. =0A=A0 I would have proposed=A0spending the=A0time and energy= =A0that went=A0=A0to this draft (13 possibly more revisions) on better caus= es.=0A=0ARegards,=0A=0ABehcet=A0 =0A=A0 =0A=0A=0A=0A=0A____________________= ____________=0AFrom: George Tsirtsis =0ATo: w52006= @huawei.com=0ACc: Vijay Devarapalli ; Behcet Sarikaya <= sarikaya@ieee.org>; marcelo bagnulo braun ; mext =0ASent: Saturday, April 25, 2009 5:38:49 AM=0ASubject: a suggesti= on ...Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt]=0A= =0ABehcet/Yungui,=0A=0AAs you can see there is significant push-back in wha= t you are=0Aproposing for this draft and I believe for good reasons.=0AMayb= e then, all this time and energy can be directed to something a=0Abit more = constructive.=0A=0AWhat you are talking about is not about protocol definit= ion but about=0Aimplementation, deployment choices etc.=0ASince Marcelo, on= behalf of the WG, is eager to get significant=0Areviews on a number of upc= oming documents why don't you take a look at=0Adraft-ietf-monami6-mipv6-ana= lysis-05 which is about to enter WGLC, and=0Awhich IMO is a much more appro= priate document for this discussion.=0AThere are many possible configuratio= ns, that we should not attempt to=0Acapture in the MCoA spec (we never do t= hat!)....but one could try to=0Acapture such examples in an info document l= ike the analysis draft.=0A=0AA node with multiple interfaces attached to th= e same or different=0Alinks, prior to initiation of MIPv6 session, is simpl= y a node with=0Amultiple interfaces, each of which has its own IP address. = The node=0Ahas to make an explicit decision to turn one of these address, o= r=0Amaybe a different one (in case of a remote HA), into a MIPv6 home=0Aadd= ress,=0AThe node can even turn multiple of its addresses into HoAs...result= ing=0Ain multiple independent MIPv6 session, possibly with different HAs. O= r=0Athe MN may keep one HoA and turn all the others into CoAs....or any=0Ac= ombination of the above.... and i am not even discussing NEMO, DSMIP=0Aetc.= ...As I said there are many possible configurations ...which if we=0Areally = want to discuss they should go in documents like that analysis=0Adoc.=0A=0A= George=0A=0A=0A --0-495113741-1240844410=:10269 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi George,
=0A
  Your points well taken.=
=0A
That said, is this doc draft-ietf-monami6-mipv6-analysis-05 i= n the charter?
=0A
My suggestion was to include the crust of the = analysis and basic assumptions into your doc in a single paragraph and you = could replace that with the reference to this analysis draft.
=0A
=   It seems like you guys are pretty reluctant for any progressive sugg= estions.
=0A
  Lastly, I looked at the draft again, as Vijay = said this draft does not talk about any packet forwarding to any of CoAs fo= r which the BIDs were given. I don't think this draft is a prerequisite for= any flow binding work.
=0A
  I would have proposed spe= nding the time and energy that went  to this draft (13 = possibly more revisions) on better causes.
=0A
 
=0ARegards,
=0A
 
=0A
Behcet 
=0A
 = ;
=0A

=0A
=0A
=0AFrom: George Tsirtsis &= lt;tsirtsis@googlemail.com>
To:<= /SPAN> w52006@huawei.com
Cc: Vijay Devarapalli <vijay@wichorus.com>; Behcet Sarikaya <= sarikaya@ieee.org>; marcelo bagnulo braun <marcelo@it.uc3m.es>; me= xt <mext@ietf.org>
Sent: Saturday, April 25, 2009 5:38:49 AM
Subject: a suggestion ...Re: [MEXT] [Fwd: I-D Action:dra= ft-ietf-monami6-multiplecoa-13.txt]

Behcet/Yungui,

As = you can see there is significant push-back in what you are
proposing for= this draft and I believe for good reasons.
Maybe then, all this time an= d energy can be directed to something a
bit more constructive.

Wh= at you are talking about is not about protocol definition but about
implementation, deployment choices etc.
Since Marcelo, on beha= lf of the WG, is eager to get significant
reviews on a number of upcomin= g documents why don't you take a look at
draft-ietf-monami6-mipv6-analys= is-05 which is about to enter WGLC, and
which IMO is a much more appropr= iate document for this discussion.
There are many possible configuration= s, that we should not attempt to
capture in the MCoA spec (we never do t= hat!)....but one could try to
capture such examples in an info document = like the analysis draft.

A node with multiple interfaces attached to= the same or different
links, prior to initiation of MIPv6 session, is s= imply a node with
multiple interfaces, each of which has its own IP addr= ess. The node
has to make an explicit decision to turn one of these addr= ess, or
maybe a different one (in case of a remote HA), into a MIPv6 hom= e
address,
The node can even turn multiple of its addresses into HoAs...resulting
in multiple independent MIPv6 session, possibly w= ith different HAs. Or
the MN may keep one HoA and turn all the others in= to CoAs....or any
combination of the above.... and i am not even discuss= ing NEMO, DSMIP
etc...As I said there are many possible configurations .= ...which if we
really want to discuss they should go in documents like th= at analysis
doc.

George


=0A=0A = --0-495113741-1240844410=:10269-- From tsirtsis@googlemail.com Mon Apr 27 08:01:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A86183A6FA1 for ; Mon, 27 Apr 2009 08:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 VCfjic92XFrv for ; Mon, 27 Apr 2009 08:01:41 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 29F3828C158 for ; Mon, 27 Apr 2009 08:01:40 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so3127906yxb.49 for ; Mon, 27 Apr 2009 08:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=H96iXSmy4O0niksS0TbQTYEZ3xcIJmg7TJVozgSH2R4=; b=Hdfwg+i5DAqkKFfwvhsRgfhbpN4f4PKHbIQ2wnOCpGE2jOMR2nrHZf55DIxOzNfWGh 5uy31forvMYRUGzem8dVWqPbsJkDOaLOrOMkisBDR5c6EktHhbQ07+U/BsIloCa4JwAi tqfZdaW16iygac1Oy9BF7l/0dvpqxkymZr14A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qfhPbH853zcqbG44ogRi8nc+bQUt73Cp288CmFSZjJlB/iXpNF5OcEiZEZGGYCYKfj 9/ATxYJ2UxK8HRaB4ozHaCb4h8+XtM/pamVAUT2kb0Ix1/uy1ms05aMRKHjGRPd4YY1l kTvSHYYIpHJSzIJDGXy8MroNpE30BA+zvwcHY= MIME-Version: 1.0 Received: by 10.90.89.8 with SMTP id m8mr7154608agb.23.1240844580683; Mon, 27 Apr 2009 08:03:00 -0700 (PDT) In-Reply-To: <212164.10269.qm@web111401.mail.gq1.yahoo.com> References: <212164.10269.qm@web111401.mail.gq1.yahoo.com> Date: Mon, 27 Apr 2009 16:03:00 +0100 Message-ID: From: George Tsirtsis To: Behcet Sarikaya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 15:01:42 -0000 On Mon, Apr 27, 2009 at 4:00 PM, Behcet Sarikaya wrote: > Hi George, > =C2=A0 Your points well taken. > That said, is this doc draft-ietf-monami6-mipv6-analysis-05 in the charte= r? GT> This is one of the documents Marcelo identified as being ready for WGLC, and as such reviews would be much appreciated. George > My suggestion was to include the crust of the analysis and basic assumpti= ons > into your doc in a single paragraph and you could replace that with the > reference to this analysis draft. > =C2=A0 It seems like you guys are pretty reluctant for any progressive > suggestions. > =C2=A0 Lastly, I looked at the draft again, as Vijay said this draft does= not > talk about any packet forwarding to any of CoAs for which the BIDs were > given. I don't think this draft is a prerequisite for any flow binding wo= rk. > =C2=A0 I would have proposed=C2=A0spending the=C2=A0time and energy=C2=A0= that went=C2=A0=C2=A0to this > draft (13 possibly more revisions) on better causes. > > Regards, > > Behcet > > > ________________________________ > From: George Tsirtsis > To: w52006@huawei.com > Cc: Vijay Devarapalli ; Behcet Sarikaya > ; marcelo bagnulo braun ; mext > > Sent: Saturday, April 25, 2009 5:38:49 AM > Subject: a suggestion ...Re: [MEXT] [Fwd: I-D > Action:draft-ietf-monami6-multiplecoa-13.txt] > > Behcet/Yungui, > > As you can see there is significant push-back in what you are > proposing for this draft and I believe for good reasons. > Maybe then, all this time and energy can be directed to something a > bit more constructive. > > What you are talking about is not about protocol definition but about > implementation, deployment choices etc. > Since Marcelo, on behalf of the WG, is eager to get significant > reviews on a number of upcoming documents why don't you take a look at > draft-ietf-monami6-mipv6-analysis-05 which is about to enter WGLC, and > which IMO is a much more appropriate document for this discussion. > There are many possible configurations, that we should not attempt to > capture in the MCoA spec (we never do that!)....but one could try to > capture such examples in an info document like the analysis draft. > > A node with multiple interfaces attached to the same or different > links, prior to initiation of MIPv6 session, is simply a node with > multiple interfaces, each of which has its own IP address. The node > has to make an explicit decision to turn one of these address, or > maybe a different one (in case of a remote HA), into a MIPv6 home > address, > The node can even turn multiple of its addresses into HoAs...resulting > in multiple independent MIPv6 session, possibly with different HAs. Or > the MN may keep one HoA and turn all the others into CoAs....or any > combination of the above.... and i am not even discussing NEMO, DSMIP > etc...As I said there are many possible configurations ....which if we > really want to discuss they should go in documents like that analysis > doc. > > George > > > From vijay@wichorus.com Mon Apr 27 14:07:20 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5853A6E0A for ; Mon, 27 Apr 2009 14:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.517, 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 qCshvwnDhfTe for ; Mon, 27 Apr 2009 14:07:14 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id CF7853A6DE4 for ; Mon, 27 Apr 2009 14:06:39 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA07.westchester.pa.mail.comcast.net with comcast id kaoh1b0040Fqzac57l81P1; Mon, 27 Apr 2009 21:08:01 +0000 Received: from [10.166.254.170] ([38.104.122.206]) by OMTA08.westchester.pa.mail.comcast.net with comcast id kl7j1b0064THdvq3Ul7saN; Mon, 27 Apr 2009 21:07:59 +0000 Message-ID: <49F61E9A.1000200@wichorus.com> Date: Mon, 27 Apr 2009 14:07:38 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Sri Gundavelli References: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'mext' Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:07:21 -0000 Hi Sri, The "Home Binding" operation is not straight forward to implement on an ethernet-like link. I agree. However, it is not so hard when the mobile node has a tunnel (GTP, PMI, IPsec, etc..) as the link layer to the home agent. Note that the mobile node node is not required to support this. It can always have all the flows over the interface with which it is attached to the home link. For the scenario, where the mobile node wants to receive packets both over the home link and the visited link, the solution in the draft is the best we could come up with. Vijay Sri Gundavelli wrote: > > > On Mon, 27 Apr 2009, Yungui Wang wrote: > >> >> I wouldn't want to delay this document. Please move forward if necessary. >> >> However, home binding is a little controversial new feature which was >> recently added from -11. Well, I am only interesting with its operation. >> Maybe it is more appropriate to clarify it offline. You are >> appreciated to >> do that. :) >> >> > > I agree with this assessment. I dont want to delay this doc either, you > can go ahead. But, I just dont know how to implement the mobile node's > home link attachment with non-NDP mode. The mobile node can use its home > address, but cannot participate in NDP. It can use HoA on the home link, > and can only send and receive packets with its home agent. This requires > special semantics, or even driver layer interface, not a socket layer > interface. > > Atleast in Cisco IOS, where there is some programming constructs, I do > not know how to configure the HoA on the home link, disable NDP, still use > HoA for sending packets with the link-layer header and for receiving > packets to HoA, while its not defending that address. Or, I dont know how > to make the mobile node's IPv6 interface to believe that the prefix is an > off-link prefix, while the RA's carry the prefixes as onlink prefixes, for > it to send all packets to destinations through the router. And for the > home agent to disable the REDIRECT semantic on the home interface for > supporting this through router indirection. This requires some changes as > how IPv6 is confiugred on interfaces and how ND is enabled or how > applications see it. Its possible with hacks. I assume some one > implemented this on Linux, using standard socket layer interface > per 4584 or 3542. > > Also, we are generally so worried about the integrity of the host, the > programming layers, specially the interface integrity and the any changes > to it, but for supporting this mode, we are going out of our way and the > implications are hardly ever analyzed, like the home interface > designation, multiple hoa generation, or the implementation complexity. > But I guess, its CMIP with a free check to rewrite the host stack. > > > Page 22, last paragraph: > "If the home agent, according to its local policy, needs to deliver > packets to the mobile node over the home link, an issue arises > with respect to how the home agent discovers the mobile node's > link local address. " > > Is it link local or link-layer ? > > > Regards > Sri > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From sgundave@cisco.com Mon Apr 27 14:39:00 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F2A3A6AE2 for ; Mon, 27 Apr 2009 14:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 vl13a536Ichz for ; Mon, 27 Apr 2009 14:38:59 -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 A0B1C3A6A5B for ; Mon, 27 Apr 2009 14:38:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,256,1238976000"; d="scan'208";a="293913779" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2009 21:40:20 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3RLeKan023596; Mon, 27 Apr 2009 14:40:20 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3RLeKLH022845; Mon, 27 Apr 2009 21:40:20 GMT Date: Mon, 27 Apr 2009 14:40:20 -0700 (PDT) From: Sri Gundavelli To: George Tsirtsis In-Reply-To: Message-ID: References: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3883; t=1240868420; x=1241732420; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20a=20suggestion=20...Re=3A=20[F wd=3A=20I-D=20Action=3Adraft-ietf-monami6-multiplecoa-13.txt ] |Sender:=20; bh=9swazY18SpM1LD20sSUUwx9cGJ5H1vQqpovqs3kfCMU=; b=WUI/No54cdm7EJ0gab9GTg0sxOZJTmQkxXYpDB/9WK99MuMV8LR+ahwz14 XKAQLlVbNvBKW9UcS6MJayxPq8l44qHJE4pGC+MgsWQRL4762a7/TgWeiLKc P6gP2VevPLL57QxBZb5qdnzxvC8NGMHAacCusUixD+wnxW/3iz/ag=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: mext Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:39:00 -0000 Hi George, On Mon, 27 Apr 2009, George Tsirtsis wrote: > Hi Sri, > > I think the authors appreciate that the non-NDP home link operation is > not straightforward, but as you say this is client MIP and changing > the end node is part of the game. > Its not complex alone, it makes some fundamental assumptions on the IPv6 link model. I assumed you will argue, its does not require a endhost stack re-write, but you are a saying, its client MIP and so its a right to rewrite :) Not sure, about that. > Also, the home link operation was the subject of lengthy discussion a > few months back though and the draft captures the result of this > discussion, so, I am not sure it is fair to say that the implications > were not discussed.. > This was not a day-1 feature, it was added fairly recently, given the long history of MCOA draft. Even if there were lots of discussions, given the complexity and the fact that there are still lots of questions, I'm not sure why this cant be split to a different doc and taken on a slower path. As I said, I'm not arguing to block this, but I dont think any one can be compliant to this. Sri > Regards > George > > On Mon, Apr 27, 2009 at 4:43 AM, Sri Gundavelli wrote: >> >> >> On Mon, 27 Apr 2009, Yungui Wang wrote: >> >>> >>> I wouldn't want to delay this document. Please move forward if necessary. >>> >>> However, home binding is a little controversial new feature which was >>> recently added from -11. Well, I am only interesting with its operation. >>> Maybe it is more appropriate to clarify it offline. You are appreciated to >>> do that. :) >>> >>> >> >> I agree with this assessment. I dont want to delay this doc either, you >> can go ahead. But, I just dont know how to implement the mobile node's >> home link attachment with non-NDP mode. The mobile node can use its home >> address, but cannot participate in NDP. It can use HoA on the home link, >> and can only send and receive packets with its home agent. This requires >> special semantics, or even driver layer interface, not a socket layer >> interface. >> >> Atleast in Cisco IOS, where there is some programming constructs, I do >> not know how to configure the HoA on the home link, disable NDP, still use >> HoA for sending packets with the link-layer header and for receiving >> packets to HoA, while its not defending that address. Or, I dont know how >> to make the mobile node's IPv6 interface to believe that the prefix is an >> off-link prefix, while the RA's carry the prefixes as onlink prefixes, for >> it to send all packets to destinations through the router. And for the >> home agent to disable the REDIRECT semantic on the home interface for >> supporting this through router indirection. This requires some changes as >> how IPv6 is confiugred on interfaces and how ND is enabled or how >> applications see it. Its possible with hacks. I assume some one >> implemented this on Linux, using standard socket layer interface >> per 4584 or 3542. >> >> Also, we are generally so worried about the integrity of the host, the >> programming layers, specially the interface integrity and the any changes >> to it, but for supporting this mode, we are going out of our way and the >> implications are hardly ever analyzed, like the home interface >> designation, multiple hoa generation, or the implementation complexity. >> But I guess, its CMIP with a free check to rewrite the host stack. >> >> >> Page 22, last paragraph: >> "If the home agent, according to its local policy, needs to deliver >> packets to the mobile node over the home link, an issue arises >> with respect to how the home agent discovers the mobile node's >> link local address. " >> >> Is it link local or link-layer ? >> >> >> Regards >> Sri >> >> >> >> >> > From sgundave@cisco.com Mon Apr 27 14:39:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887C028C1AA for ; Mon, 27 Apr 2009 14:39:09 -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 O2yXTHrSxd6o for ; Mon, 27 Apr 2009 14:39:08 -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 8D76A28C17D for ; Mon, 27 Apr 2009 14:39:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,256,1238976000"; d="scan'208";a="293913878" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2009 21:40:29 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3RLeTGT023702; Mon, 27 Apr 2009 14:40:29 -0700 Received: from sgundave-sb100.cisco.com (sgundave-sb100.cisco.com [128.107.163.1]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n3RLeT6Z024280; Mon, 27 Apr 2009 21:40:29 GMT Date: Mon, 27 Apr 2009 14:40:29 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: <49F61E9A.1000200@wichorus.com> Message-ID: References: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> <49F61E9A.1000200@wichorus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5043; t=1240868429; x=1241732429; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20a=20suggestion=20...Re=3A=20[F wd=3A=20I-D=09Action=3Adraft-ietf-monami6-multiplecoa-13.txt ] |Sender:=20; bh=Tc51RnFZqf0hjDBPrVpwsO8ycsdLn+VCYoS1S8IylAY=; b=iqlXOyd+3aDkWsCl4XTT2hllXcA/JqlwVr/eu3q0lL8+hL9DqYAvQGspri IZQ/a4GgJE62d9vpX7IFcUtjA6tRC+dyywVYWov+mh3eokOLqrcH9VBiDITZ k7qD88lm12; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'mext' Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:39:09 -0000 Hi Vijay, Implementation complexity is one thing. But, the spec largely ignores the link model or the assumptions that all the ND specs make. On a given IPv6 link, there is only one node that can use an IPv6 address. The node or a proxy on its behalf. But, this draft introduces a new model, the proxy defends the node's address, it can receive packets, while the node can still send and receive the packets. What is this link model ? Where is it specified ? What are the implementations to the IPv6 stack on the host. The draft very simple terms states this requirement. I dont know how this can be achieved, IPv6 interface configuration or the ND mgmt is not a module owned by the mobile ip stack. There is some level of modularity on any platform. Like we dont make all the IPsec handling as a MIP decision. If the given feature requires the fundamental assumption change there is an issue. If one has to implement this on a open source platform such as Linux, with a kernel stack tighly controlled, how does one implement this ? As I said, I cant implement this on IOS and so we will always non-compliant to this spec. Generally, you insist on feature control, I say the same thing, why dont we do this later when we need it ? There are so many issues as the WG pointed out, in the current form no one can implement this any ways, even if you rush and publish the doc. But, its your call, as it cleared all reviews and surprisingly this was not caught in IESG reviews. Sri On Mon, 27 Apr 2009, Vijay Devarapalli wrote: > Hi Sri, > > The "Home Binding" operation is not straight forward to implement on an > ethernet-like link. I agree. However, it is not so hard when the mobile node > has a tunnel (GTP, PMI, IPsec, etc..) as the link layer to the home agent. > > Note that the mobile node node is not required to support this. It can always > have all the flows over the interface with which it is attached to the home > link. > > For the scenario, where the mobile node wants to receive packets both over > the home link and the visited link, the solution in the draft is the best we > could come up with. > > Vijay > > Sri Gundavelli wrote: >> >> >> On Mon, 27 Apr 2009, Yungui Wang wrote: >> >> > >> > I wouldn't want to delay this document. Please move forward if >> > necessary. >> > >> > However, home binding is a little controversial new feature which was >> > recently added from -11. Well, I am only interesting with its operation. >> > Maybe it is more appropriate to clarify it offline. You are appreciated >> > to >> > do that. :) >> > >> > >> >> I agree with this assessment. I dont want to delay this doc either, you >> can go ahead. But, I just dont know how to implement the mobile node's >> home link attachment with non-NDP mode. The mobile node can use its home >> address, but cannot participate in NDP. It can use HoA on the home link, >> and can only send and receive packets with its home agent. This requires >> special semantics, or even driver layer interface, not a socket layer >> interface. >> >> Atleast in Cisco IOS, where there is some programming constructs, I do >> not know how to configure the HoA on the home link, disable NDP, still use >> HoA for sending packets with the link-layer header and for receiving >> packets to HoA, while its not defending that address. Or, I dont know how >> to make the mobile node's IPv6 interface to believe that the prefix is an >> off-link prefix, while the RA's carry the prefixes as onlink prefixes, for >> it to send all packets to destinations through the router. And for the >> home agent to disable the REDIRECT semantic on the home interface for >> supporting this through router indirection. This requires some changes as >> how IPv6 is confiugred on interfaces and how ND is enabled or how >> applications see it. Its possible with hacks. I assume some one >> implemented this on Linux, using standard socket layer interface >> per 4584 or 3542. >> >> Also, we are generally so worried about the integrity of the host, the >> programming layers, specially the interface integrity and the any changes >> to it, but for supporting this mode, we are going out of our way and the >> implications are hardly ever analyzed, like the home interface >> designation, multiple hoa generation, or the implementation complexity. >> But I guess, its CMIP with a free check to rewrite the host stack. >> >> >> Page 22, last paragraph: >> "If the home agent, according to its local policy, needs to deliver >> packets to the mobile node over the home link, an issue arises >> with respect to how the home agent discovers the mobile node's >> link local address. " >> >> Is it link local or link-layer ? >> >> >> Regards >> Sri >> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > From vijay@wichorus.com Mon Apr 27 15:01:40 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F8033A6C85 for ; Mon, 27 Apr 2009 15:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 k5k4aOKZ37ne for ; Mon, 27 Apr 2009 15:01:38 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id E1ED73A6FC4 for ; Mon, 27 Apr 2009 15:01:06 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id kblm1b0010cQ2SLA9m2UtS; Mon, 27 Apr 2009 22:02:28 +0000 Received: from [10.166.254.170] ([38.104.122.206]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id km2B1b00T4THdvq8Wm2J8b; Mon, 27 Apr 2009 22:02:26 +0000 Message-ID: <49F62B5F.2010909@wichorus.com> Date: Mon, 27 Apr 2009 15:02:07 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Sri Gundavelli References: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> <49F61E9A.1000200@wichorus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'mext' Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 22:01:40 -0000 Sri Gundavelli wrote: > Hi Vijay, > > Implementation complexity is one thing. But, the spec > largely ignores the link model or the assumptions that > all the ND specs make. > > On a given IPv6 link, there is only one node that can > use an IPv6 address. The node or a proxy on its behalf. > But, this draft introduces a new model, the proxy > defends the node's address, it can receive packets, > while the node can still send and receive the packets. > What is this link model ? Where is it specified ? What > are the implementations to the IPv6 stack on the host. I guess you missed parts of my earlier email on this. I expect this "home binding" feature to be mostly used when there is a tunnel (GTP, etc..) emulating the home link. The mobile node is unlikely to receive any neighbor solicitations for the home address. The home agent would continue proxying for the home address. > The draft very simple terms states this requirement. > I dont know how this can be achieved, IPv6 interface > configuration or the ND mgmt is not a module owned by the > mobile ip stack. There is some level of modularity on any > platform. Like we dont make all the IPsec handling as a MIP > decision. If the given feature requires the fundamental > assumption change there is an issue. If one has to implement > this on a open source platform such as Linux, with a kernel > stack tighly controlled, how does one implement this ? As I > said, I cant implement this on IOS and so we will always > non-compliant to this spec. Not implementing the "home binding" feature would not make you non-compliant to the spec. Vijay > > Generally, you insist on feature control, I say the same > thing, why dont we do this later when we need it ? There > are so many issues as the WG pointed out, in the current > form no one can implement this any ways, even if you rush > and publish the doc. But, its your call, as it cleared all > reviews and surprisingly this was not caught in IESG reviews. > > > Sri > > > On Mon, 27 Apr 2009, Vijay Devarapalli wrote: > >> Hi Sri, >> >> The "Home Binding" operation is not straight forward to implement on >> an ethernet-like link. I agree. However, it is not so hard when the >> mobile node has a tunnel (GTP, PMI, IPsec, etc..) as the link layer >> to the home agent. >> >> Note that the mobile node node is not required to support this. It can >> always have all the flows over the interface with which it is attached >> to the home link. >> >> For the scenario, where the mobile node wants to receive packets both >> over the home link and the visited link, the solution in the draft is >> the best we could come up with. >> >> Vijay >> >> Sri Gundavelli wrote: >>> >>> >>> On Mon, 27 Apr 2009, Yungui Wang wrote: >>> >>> > > I wouldn't want to delay this document. Please move forward if >>> > necessary. >>> > > However, home binding is a little controversial new feature >>> which was >>> > recently added from -11. Well, I am only interesting with its >>> operation. >>> > Maybe it is more appropriate to clarify it offline. You are >>> appreciated > to >>> > do that. :) >>> > > >>> >>> I agree with this assessment. I dont want to delay this doc either, you >>> can go ahead. But, I just dont know how to implement the mobile node's >>> home link attachment with non-NDP mode. The mobile node can use its >>> home >>> address, but cannot participate in NDP. It can use HoA on the home >>> link, >>> and can only send and receive packets with its home agent. This >>> requires >>> special semantics, or even driver layer interface, not a socket layer >>> interface. >>> >>> Atleast in Cisco IOS, where there is some programming constructs, I do >>> not know how to configure the HoA on the home link, disable NDP, >>> still use >>> HoA for sending packets with the link-layer header and for receiving >>> packets to HoA, while its not defending that address. Or, I dont >>> know how >>> to make the mobile node's IPv6 interface to believe that the prefix >>> is an >>> off-link prefix, while the RA's carry the prefixes as onlink >>> prefixes, for >>> it to send all packets to destinations through the router. And for the >>> home agent to disable the REDIRECT semantic on the home interface for >>> supporting this through router indirection. This requires some >>> changes as >>> how IPv6 is confiugred on interfaces and how ND is enabled or how >>> applications see it. Its possible with hacks. I assume some one >>> implemented this on Linux, using standard socket layer interface >>> per 4584 or 3542. >>> >>> Also, we are generally so worried about the integrity of the host, the >>> programming layers, specially the interface integrity and the any >>> changes >>> to it, but for supporting this mode, we are going out of our way and >>> the >>> implications are hardly ever analyzed, like the home interface >>> designation, multiple hoa generation, or the implementation complexity. >>> But I guess, its CMIP with a free check to rewrite the host stack. >>> >>> >>> Page 22, last paragraph: >>> "If the home agent, according to its local policy, needs to deliver >>> packets to the mobile node over the home link, an issue arises >>> with respect to how the home agent discovers the mobile node's >>> link local address. " >>> >>> Is it link local or link-layer ? >>> >>> >>> Regards >>> Sri >>> >>> >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> From sgundave@cisco.com Mon Apr 27 15:09:00 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7308A3A6BAC for ; Mon, 27 Apr 2009 15:09:00 -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 jdtuWhAEbwys for ; Mon, 27 Apr 2009 15:08:59 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7D65B3A6A8B for ; Mon, 27 Apr 2009 15:08:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,256,1238976000"; d="scan'208";a="159467816" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 27 Apr 2009 22:10:17 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3RMAHjb023665; Mon, 27 Apr 2009 15:10:17 -0700 Received: from sgundave-sb100.cisco.com (sgundave-sb100.cisco.com [128.107.163.1]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3RMAHOn023939; Mon, 27 Apr 2009 22:10:17 GMT Date: Mon, 27 Apr 2009 15:10:16 -0700 (PDT) From: Sri Gundavelli To: Vijay Devarapalli In-Reply-To: <49F62B5F.2010909@wichorus.com> Message-ID: References: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> <49F61E9A.1000200@wichorus.com> <49F62B5F.2010909@wichorus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2020; t=1240870217; x=1241734217; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20a=20suggestion=20...Re=3A=20[F wd=3A=20I-D=09Action=3Adraft-ietf-monami6-multiplecoa-13.txt ] |Sender:=20; bh=TysKNciRQ04hStejHiY68NRvbK/+qfW/XwMQmzyPlGA=; b=gkwfPB3gPI4vNg7T8zY8puv8QaQjvGo8GirFhWRj/r0hk+Mm6EYdsZgDSv dN/BGnbdjiZ1nRLX2Rtj3k+PCs5v6huEowaKazzlnvRJJ0FVX00KYq/JlXSa SfFhs9FDhj; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'mext' Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 22:09:00 -0000 Hi Vijay, On Mon, 27 Apr 2009, Vijay Devarapalli wrote: >> Implementation complexity is one thing. But, the spec >> largely ignores the link model or the assumptions that >> all the ND specs make. >> >> On a given IPv6 link, there is only one node that can >> use an IPv6 address. The node or a proxy on its behalf. >> But, this draft introduces a new model, the proxy >> defends the node's address, it can receive packets, >> while the node can still send and receive the packets. >> What is this link model ? Where is it specified ? What >> are the implementations to the IPv6 stack on the host. > > I guess you missed parts of my earlier email on this. I expect this "home > binding" feature to be mostly used when there is a tunnel (GTP, etc..) > emulating the home link. The mobile node is unlikely to receive any neighbor > solicitations for the home address. The home agent would continue proxying > for the home address. > But, its still an IETF document. I'm not sure we can ignore the above considerations. If the home attachment solution is a generic requirement, I assume the solution needs to work for a generic mobile client. >> The draft very simple terms states this requirement. >> I dont know how this can be achieved, IPv6 interface >> configuration or the ND mgmt is not a module owned by the >> mobile ip stack. There is some level of modularity on any >> platform. Like we dont make all the IPsec handling as a MIP >> decision. If the given feature requires the fundamental >> assumption change there is an issue. If one has to implement >> this on a open source platform such as Linux, with a kernel >> stack tighly controlled, how does one implement this ? As I >> said, I cant implement this on IOS and so we will always >> non-compliant to this spec. > > Not implementing the "home binding" feature would not make you non-compliant > to the spec. Why is that ? You mean, it will be partially compliant ? Sri From vijay@wichorus.com Mon Apr 27 17:46:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7FD3A69E2 for ; Mon, 27 Apr 2009 17:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] 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 4UczCyvaI-h3 for ; Mon, 27 Apr 2009 17:46:36 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 6AAC13A6F71 for ; Mon, 27 Apr 2009 17:45:36 -0700 (PDT) Received: from 38.104.122.206 ([38.104.122.206]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Tue, 28 Apr 2009 00:46:57 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 27 Apr 2009 17:46:56 -0700 From: Vijay Devarapalli To: , George Tsirtsis Message-ID: Thread-Topic: a suggestion ...Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] Thread-Index: AcnFkt/0kEn6WsW+SMuUmL90IEW/ZgBPMHEwADLMrg0= In-Reply-To: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: mext Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 00:46:37 -0000 Hello Yungui, On 4/26/09 7:04 PM, "Yungui Wang" wrote: > However, home binding is a little controversial new feature which was > recently added from -11. This is not correct. Simultaneous attachment to the home and visited link was added to the specification in version 07. It was submitted in April 2008. See section 5.6.3 of http://tools.ietf.org/id/draft-ietf-monami6-multiplecoa-07.txt Vijay From ryuji.wakikawa@gmail.com Mon Apr 27 18:29:22 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456E53A7028 for ; Mon, 27 Apr 2009 18:29:22 -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 e6OQzDgY8rMn for ; Mon, 27 Apr 2009 18:29:21 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 2DA7C3A6BCE for ; Mon, 27 Apr 2009 18:29:21 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so295643ywj.49 for ; Mon, 27 Apr 2009 18:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=HVmvEElT9kbeJhA18imrIBdy7r3kAelGs2PncUhsvoo=; b=QkrUKTs803+lnp5xbuXHbuJDU9ZEi9SicFjb3T1LAEOaFgWYvEd7VoW8Flc4h9Tsiw mO8aS6RNYOuZk3g9XQVFf1KKl+ozawYv5WBxe5VNJFGtiRvea1jYoLl9zsSf7dTCE2+e uASOVs/zV6+jKwXLI+kl2xTRJFJ6a6xY3FwVM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=fCx8V0tvnioLGfJqnNBp3kWeMleMbIEYie5NCKwI6yaMyJz8bVy/8mCkOUMq5sA8KX Pn1A4PEpQLl8cpJ2Q9PM+SqhwjaqdB/RCHsx228hCTBrTJR10n2iAjVri3rnU9Bt7XIe TTBRSh3VF2uXpoyThQRPZfjnposJaCYJQP3Mg= Received: by 10.90.25.11 with SMTP id 11mr2669095agy.81.1240882241684; Mon, 27 Apr 2009 18:30:41 -0700 (PDT) Received: from ?192.168.110.115? ([206.132.173.18]) by mx.google.com with ESMTPS id 20sm1213630agb.65.2009.04.27.18.30.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Apr 2009 18:30:41 -0700 (PDT) From: Ryuji Wakikawa To: Sri Gundavelli In-Reply-To: References: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 18:30:37 -0700 X-Mailer: Apple Mail (2.930.3) Cc: 'mext' Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 01:29:22 -0000 Hi Sri, On 2009/04/26, at 20:43, Sri Gundavelli wrote: > > > On Mon, 27 Apr 2009, Yungui Wang wrote: > >> >> I wouldn't want to delay this document. Please move forward if >> necessary. >> >> However, home binding is a little controversial new feature which was >> recently added from -11. Well, I am only interesting with its >> operation. >> Maybe it is more appropriate to clarify it offline. You are >> appreciated to >> do that. :) >> >> > > I agree with this assessment. I dont want to delay this doc either, > you > can go ahead. But, I just dont know how to implement the mobile node's > home link attachment with non-NDP mode. The mobile node can use its > home > address, but cannot participate in NDP. It can use HoA on the home > link, > and can only send and receive packets with its home agent. This > requires > special semantics, or even driver layer interface, not a socket layer > interface. In MCoA document, we have following texts in the home binding no NDP operation. This operation is similar to Mobile IPv6 [RFC-3775] when a mobile node sends a deregistration binding update to the home agent's link- layer address in the operation for returning home. We follow the RFC3775 which MN does not react to NS for HoA. We don't introduce any new semantics here. Cisco has already had some codes for returning home, don't you? > > Atleast in Cisco IOS, where there is some programming constructs, I do > not know how to configure the HoA on the home link, disable NDP, > still use > HoA for sending packets with the link-layer header and for receiving > packets to HoA, while its not defending that address. Or, I dont > know how > to make the mobile node's IPv6 interface to believe that the prefix > is an > off-link prefix, while the RA's carry the prefixes as onlink > prefixes, for > it to send all packets to destinations through the router. And for the > home agent to disable the REDIRECT semantic on the home interface for > supporting this through router indirection. This requires some > changes as > how IPv6 is confiugred on interfaces and how ND is enabled or how > applications see it. Its possible with hacks. I assume some one > implemented this on Linux, using standard socket layer interface > per 4584 or 3542. Yes, we need some hack to work HoA without NDP. However, this is what I have implemented for Mobile IPv6's returning home. > Also, we are generally so worried about the integrity of the host, the > programming layers, specially the interface integrity and the any > changes > to it, but for supporting this mode, we are going out of our way and > the > implications are hardly ever analyzed, like the home interface > designation, multiple hoa generation, or the implementation > complexity. > But I guess, its CMIP with a free check to rewrite the host stack. > HA can tell the MN how to behave on the home link. If there is no routers on the home link other than HA, there is no reason to use this mode. > > Page 22, last paragraph: > "If the home agent, according to its local policy, needs to deliver > packets to the mobile node over the home link, an issue arises > with respect to how the home agent discovers the mobile node's > link local address. " > > Is it link local or link-layer ? Yes, this is typo. Thanks! regards, ryuji > > > > Regards > Sri > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Mon Apr 27 18:36:37 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89EF53A7034 for ; Mon, 27 Apr 2009 18:36:37 -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 uwytwvlS98+B for ; Mon, 27 Apr 2009 18:36:36 -0700 (PDT) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by core3.amsl.com (Postfix) with ESMTP id 256323A7035 for ; Mon, 27 Apr 2009 18:35:44 -0700 (PDT) Received: by gxk10 with SMTP id 10so590030gxk.13 for ; Mon, 27 Apr 2009 18:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=yHP2+6inK4a9wBBapFqEQxQpP7irQv3I5vuADvric4A=; b=nfOQyBr8N53QxCTVelq4xfEc3qa+7/vJYQSG3nf2Zqd9WJU120Q7qf991RnlFmdJbE jDwyq1DuV9gIDyl5wo/VlR2eemHID936fIxZrcpC3qZ4BY2NfjyeVq/HCFX4RHVDsbZJ LGPiTGI0uZZJW02BKfV88rtCBeFaNcPSViSR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=fOnOMaY+TsRzpXXjR01nmbOCdLPaU7olBnw/E++9eHfvvll2Vs1VKpbOF2RUUZXVt/ DrVkZNjXUTPU4NpWYcLawGNO6ykN0JT86oS77buJNbDITalwtYd8/3Hj6jsoiW1KmFsu vP0BsT9780OMJzhisyxzB4ZubXXO0YLflrsdo= Received: by 10.90.115.13 with SMTP id n13mr7820658agc.16.1240882625020; Mon, 27 Apr 2009 18:37:05 -0700 (PDT) Received: from ?192.168.110.115? ([206.132.173.18]) by mx.google.com with ESMTPS id 20sm10904674agb.25.2009.04.27.18.37.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Apr 2009 18:37:04 -0700 (PDT) From: Ryuji Wakikawa To: Sri Gundavelli In-Reply-To: References: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> Message-Id: <131022C3-524E-47CA-898A-ABEE9791C5EA@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 18:37:01 -0700 X-Mailer: Apple Mail (2.930.3) Cc: mext Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 01:36:37 -0000 Hi Sri, On 2009/04/27, at 14:40, Sri Gundavelli wrote: > Hi George, > > > On Mon, 27 Apr 2009, George Tsirtsis wrote: > >> Hi Sri, >> >> I think the authors appreciate that the non-NDP home link operation >> is >> not straightforward, but as you say this is client MIP and changing >> the end node is part of the game. >> > > Its not complex alone, it makes some fundamental assumptions on > the IPv6 link model. I assumed you will argue, its does not require > a endhost stack re-write, but you are a saying, its client MIP and so > its a right to rewrite :) Not sure, about that. > >> Also, the home link operation was the subject of lengthy discussion a >> few months back though and the draft captures the result of this >> discussion, so, I am not sure it is fair to say that the implications >> were not discussed.. >> > > This was not a day-1 feature, it was added fairly recently, > given the long history of MCOA draft. Even if there were > lots of discussions, given the complexity and the fact > that there are still lots of questions, I'm not sure why > this cant be split to a different doc and taken on a slower > path. As I said, I'm not arguing to block this, but I dont > think any one can be compliant to this. It's not recently added feature. Common, We added this feature more than 1 years ago. http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-05#section-5.6.3 We did a lot of discussion whether we exclude or include this feature (simultaneous home and foreign links) in MCoA. We had consensus to keep it at the MEXT WG. regards, ryuji > > > Sri > > >> Regards >> George >> >> On Mon, Apr 27, 2009 at 4:43 AM, Sri Gundavelli >> wrote: >>> >>> >>> On Mon, 27 Apr 2009, Yungui Wang wrote: >>> >>>> >>>> I wouldn't want to delay this document. Please move forward if >>>> necessary. >>>> >>>> However, home binding is a little controversial new feature which >>>> was >>>> recently added from -11. Well, I am only interesting with its >>>> operation. >>>> Maybe it is more appropriate to clarify it offline. You are >>>> appreciated to >>>> do that. :) >>>> >>>> >>> >>> I agree with this assessment. I dont want to delay this doc >>> either, you >>> can go ahead. But, I just dont know how to implement the mobile >>> node's >>> home link attachment with non-NDP mode. The mobile node can use >>> its home >>> address, but cannot participate in NDP. It can use HoA on the home >>> link, >>> and can only send and receive packets with its home agent. This >>> requires >>> special semantics, or even driver layer interface, not a socket >>> layer >>> interface. >>> >>> Atleast in Cisco IOS, where there is some programming constructs, >>> I do >>> not know how to configure the HoA on the home link, disable NDP, >>> still use >>> HoA for sending packets with the link-layer header and for receiving >>> packets to HoA, while its not defending that address. Or, I dont >>> know how >>> to make the mobile node's IPv6 interface to believe that the >>> prefix is an >>> off-link prefix, while the RA's carry the prefixes as onlink >>> prefixes, for >>> it to send all packets to destinations through the router. And for >>> the >>> home agent to disable the REDIRECT semantic on the home interface >>> for >>> supporting this through router indirection. This requires some >>> changes as >>> how IPv6 is confiugred on interfaces and how ND is enabled or how >>> applications see it. Its possible with hacks. I assume some one >>> implemented this on Linux, using standard socket layer interface >>> per 4584 or 3542. >>> >>> Also, we are generally so worried about the integrity of the host, >>> the >>> programming layers, specially the interface integrity and the any >>> changes >>> to it, but for supporting this mode, we are going out of our way >>> and the >>> implications are hardly ever analyzed, like the home interface >>> designation, multiple hoa generation, or the implementation >>> complexity. >>> But I guess, its CMIP with a free check to rewrite the host stack. >>> >>> >>> Page 22, last paragraph: >>> "If the home agent, according to its local policy, needs to deliver >>> packets to the mobile node over the home link, an issue arises >>> with respect to how the home agent discovers the mobile node's >>> link local address. " >>> >>> Is it link local or link-layer ? >>> >>> >>> Regards >>> Sri >>> >>> >>> >>> >>> >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From sgundave@cisco.com Mon Apr 27 19:31:42 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CC23A69E5 for ; Mon, 27 Apr 2009 19:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 tgw6I02ngzx2 for ; Mon, 27 Apr 2009 19:31:40 -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 D708F3A7033 for ; Mon, 27 Apr 2009 19:31:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,258,1238976000"; d="scan'208";a="177675881" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 Apr 2009 02:33:01 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3S2X18S006622; Mon, 27 Apr 2009 19:33:01 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3S2X1LM003779; Tue, 28 Apr 2009 02:33:01 GMT Date: Mon, 27 Apr 2009 19:33:00 -0700 (PDT) From: Sri Gundavelli To: Ryuji Wakikawa In-Reply-To: Message-ID: References: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4275; t=1240885981; x=1241749981; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20a=20suggestion=20...Re=3A=20[F wd=3A=20I-D=20Action=3Adraft-ietf-monami6-multiplecoa-13.txt ] |Sender:=20; bh=jSYWjpWe0quX0PvFPXCFDiF17PdNaFb2lckrf+ZPaQo=; b=IAOl7LB0YgYdemv8Sry/jwBiSJhJ5hlYEwlkcoOOFpSLpcxmHpRQrxZ6nY Igff83ZryW0pLIIVaOcmfK+df9qk8GI5kjfHry1A1esFhZXQJRujk2KWNNYv EnbaubPh8i; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'mext' Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 02:31:42 -0000 Hi Ryuji, Please see inline. On Mon, 27 Apr 2009, Ryuji Wakikawa wrote: > Hi Sri, > > > On 2009/04/26, at 20:43, Sri Gundavelli wrote: > >> >> >> On Mon, 27 Apr 2009, Yungui Wang wrote: >> >> > >> > I wouldn't want to delay this document. Please move forward if necessary. >> > >> > However, home binding is a little controversial new feature which was >> > recently added from -11. Well, I am only interesting with its operation. >> > Maybe it is more appropriate to clarify it offline. You are appreciated >> > to >> > do that. :) >> > >> > >> >> I agree with this assessment. I dont want to delay this doc either, you >> can go ahead. But, I just dont know how to implement the mobile node's >> home link attachment with non-NDP mode. The mobile node can use its home >> address, but cannot participate in NDP. It can use HoA on the home link, >> and can only send and receive packets with its home agent. This requires >> special semantics, or even driver layer interface, not a socket layer >> interface. > > In MCoA document, we have following texts in the home binding no NDP > operation. > > This > operation is similar to Mobile IPv6 [RFC-3775] when a mobile node > sends a deregistration binding update to the home agent's link- > layer address in the operation for returning home. > > We follow the RFC3775 which MN does not react to NS for HoA. > > We don't introduce any new semantics here. > Cisco has already had some codes for returning home, don't you? > > There are special ND considerations for the MN on returning home as how it takes over the home address from the HA. Those are general Proxy-ND considerations on unsolicited NA usage. This requires lot more hacks on complete ND disabling on the MN, and redirect disable on the HA, You cant equate these changes to MN returning home. >> >> Atleast in Cisco IOS, where there is some programming constructs, I do >> not know how to configure the HoA on the home link, disable NDP, still use >> HoA for sending packets with the link-layer header and for receiving >> packets to HoA, while its not defending that address. Or, I dont know how >> to make the mobile node's IPv6 interface to believe that the prefix is an >> off-link prefix, while the RA's carry the prefixes as onlink prefixes, for >> it to send all packets to destinations through the router. And for the >> home agent to disable the REDIRECT semantic on the home interface for >> supporting this through router indirection. This requires some changes as >> how IPv6 is confiugred on interfaces and how ND is enabled or how >> applications see it. Its possible with hacks. I assume some one >> implemented this on Linux, using standard socket layer interface >> per 4584 or 3542. > > Yes, we need some hack to work HoA without NDP. > However, this is what I have implemented for Mobile IPv6's returning home. > Ok. But, I hope you implemented this for MCOA with home/roam simultanous support. >> Also, we are generally so worried about the integrity of the host, the >> programming layers, specially the interface integrity and the any changes >> to it, but for supporting this mode, we are going out of our way and the >> implications are hardly ever analyzed, like the home interface >> designation, multiple hoa generation, or the implementation complexity. >> But I guess, its CMIP with a free check to rewrite the host stack. >> > > HA can tell the MN how to behave on the home link. > If there is no routers on the home link other than HA, there is no reason to > use this mode. > This configuration is another challenge. >> >> Page 22, last paragraph: >> "If the home agent, according to its local policy, needs to deliver >> packets to the mobile node over the home link, an issue arises >> with respect to how the home agent discovers the mobile node's >> link local address. " >> >> Is it link local or link-layer ? > > Yes, this is typo. > Thanks! > > regards, > ryuji > > >> >> >> >> Regards >> Sri >> >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > From sgundave@cisco.com Mon Apr 27 19:33:27 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6693A6C18 for ; Mon, 27 Apr 2009 19:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 3H34eIWLkUXy for ; Mon, 27 Apr 2009 19:33: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 80B1E3A69E5 for ; Mon, 27 Apr 2009 19:33:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,258,1238976000"; d="scan'208";a="294043392" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 28 Apr 2009 02:34:35 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3S2YZ2L029111; Mon, 27 Apr 2009 19:34:35 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3S2YWDZ029835; Tue, 28 Apr 2009 02:34:32 GMT Date: Mon, 27 Apr 2009 19:34:32 -0700 (PDT) From: Sri Gundavelli To: Ryuji Wakikawa In-Reply-To: <131022C3-524E-47CA-898A-ABEE9791C5EA@gmail.com> Message-ID: References: <003101c9c6dc$799bfae0$150ca40a@china.huawei.com> <131022C3-524E-47CA-898A-ABEE9791C5EA@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=472; t=1240886075; x=1241750075; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[MEXT]=20a=20suggestion=20...Re=3A=20[F wd=3A=20I-D=20Action=3Adraft-ietf-monami6-multiplecoa-13.txt ] |Sender:=20; bh=0s2twJGWXuqgetgs4VBOh2/wn/LF9E4ueKN7QU/koa8=; b=mV81hyVVvZrgVVQ5dZcq7qAsrV17yq5AGX/hDKfafJOWSSqz1/1MB6yygV m9rOPFZhAGUMFudCzsCntC/BV9a3TLMNSi7lL86Yjh3YOw8Pu42ZaQSfhhrx I6k8yRifw7; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mext Subject: Re: [MEXT] a suggestion ...Re: [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 02:33:27 -0000 Hi Ryuji, On Mon, 27 Apr 2009, Ryuji Wakikawa wrote: > It's not recently added feature. > Common, We added this feature more than 1 years ago. > http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-05#section-5.6.3 > > We did a lot of discussion whether we exclude or include this feature > (simultaneous home and foreign links) in MCoA. > We had consensus to keep it at the MEXT WG. > Ok, fine. I will let this go as we talked. Regards Sri From wwwrun@core3.amsl.com Tue Apr 28 07:55:52 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 30C3528C1D8; Tue, 28 Apr 2009 07:55:51 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090428145552.30C3528C1D8@core3.amsl.com> Date: Tue, 28 Apr 2009 07:55:52 -0700 (PDT) Cc: mext mailing list , Internet Architecture Board , mext chair , RFC Editor Subject: [MEXT] Protocol Action: 'Mobile IPv6 Support for Dual Stack Hosts and Routers' to Proposed Standard X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:55:52 -0000 The IESG has approved the following document: - 'Mobile IPv6 Support for Dual Stack Hosts and Routers ' as a Proposed Standard This document is the product of the Mobility EXTensions for IPv6 Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-v4traversal-10.txt Technical Summary The current Mobile IPv6 and NEMO specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. Working Group Summary This document is a product of the Mobility EXTensions for IPv6 (MEXT) working group. Document Quality Pasi Eronen reviewed the specification and his comments regarding interaction of DSMIPv6 with the IPsec architecture were resolved. Personnel The Document Shepherd for this document is Julien Laganier (MEXT WG co-chair). The Responsible Area Director is Jari Arkko (Internet Area Director). RFC Editor Note Please add the following paragraph to the end of Section 5.4.4: This specification does not support mobile nodes returning home while using IPv4. That is, the IPv4 support is only defined for mobile nodes that are in a visited network. From jouni.nospam@gmail.com Wed Apr 29 05:38:26 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1773A68D7 for ; Wed, 29 Apr 2009 05:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 bgQxwWdXtlm5 for ; Wed, 29 Apr 2009 05:38:26 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by core3.amsl.com (Postfix) with ESMTP id 8545C3A6866 for ; Wed, 29 Apr 2009 05:38:25 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so549551fkq.5 for ; Wed, 29 Apr 2009 05:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=gvgvr3REbt8K+HB2uXHtiEPm1kQs+5hvrYwaeRZ2Jn8=; b=Tfj1QgFU1NbZ0hYeN+YdifsxGbAJgcAfAlVZBKpMifY8D1mpJXHjZ+h/zhWvyXVy5u yrcbtbVA81RaHBlyyttSGReVsKWB9uLjJlesLuhwE6+G4k+PqcTjlFIz6DTfVFhmlVMk rV1RLB9FPfJlhil7lmLxMsUUTfurTlrCLXFF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=KLkaQXZ2Y/sTugYrt000FH0lwkaskHBAD63fnXeC5Y22my7lwnTbILnrVR2poxRfph nNQLbRnRkuk4zmf0Ew7N7illgvdZHgNp1aB0Tka//jno+U1nAO+r6YAqjnxYcWupf0tQ USdPfR67DTZftE7O9K62bMzrwlC2k4wUMfvYc= Received: by 10.204.113.203 with SMTP id b11mr273267bkq.116.1241008786406; Wed, 29 Apr 2009 05:39:46 -0700 (PDT) Received: from ?10.183.180.184? ([192.100.124.156]) by mx.google.com with ESMTPS id c28sm1314872fka.22.2009.04.29.05.39.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Apr 2009 05:39:46 -0700 (PDT) Message-Id: <6E127A8D-AB12-48F7-ADB1-8F53C7D80870@gmail.com> From: jouni korhonen To: marcelo bagnulo braun In-Reply-To: <49EDEE39.50000@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 15:39:44 +0300 References: <49EDEE39.50000@it.uc3m.es> X-Mailer: Apple Mail (2.930.3) Cc: Jari Arkko , Julien Laganier , mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 12:38:27 -0000 Hi, I had a quick re-read of this I-D based on the recent interest on it ;) And found several placed to comment. Mainly editorials but some other stuff as well. o Section 5.7 second bullet: "o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the mobile node needs to stop using bulk registrations with the node that sent the Binding Acknowledgement. It should assume that none of the attempted registrations were successful." Why "should"? I think "It MUST assume" works better here as the CN MUST reject the BU anyway according to Section 6.2. third bullet. o Section 5.7 second & third bullets Where "MCOA BULK REGISTRATION NOT SUPPORT" and its value is actually defined? It is not listed in IANA considerations nor in Section 4.4. o Section 5.7 third bullet: s/corruption. ./corruption. o Section 5.7 fourth bullet s/replced/replaced o Section 5.7 fifth bullet: s/care-off/care-of o Section 5.7 fifth bullet: "... indicated. If the mobile node is trying to deregister a BID, it NEED NOT do anything further." There is no such requirement language term as "NEED NOT" in rfc2119. o Section 5.9 "..If old bindings still exists at.." s/exists/exist o Section 6.2 sixth bullet, first sub-bullet "..is 20, the care-of address is copied the IPv6 address from the.." should probably say "..is 20, the care-of address is the IPv6 address copied from the.." o Section 8.1 first paragraph "..even if some of the care-of addresses are IPv4 address." s/are/is Cheers, Jouni On Apr 21, 2009, at 7:03 PM, marcelo bagnulo braun wrote: > We have this new version of the MCOA document that addresses the > comments received, including IESG review comments. > To the best of my knowledge, the IESG is ok with the doc and ready > for publication. > I am planning to ask our AD to move forward in a week or so, so, if > you have comments on the document please provide them before the 1st > of may. > > Regards, marcelo > (mcoa doc shepherd) > > -------- Mensaje original -------- > Asunto: [MEXT] I-D Action:draft-ietf-monami6-multiplecoa-13.txt > Fecha: Mon, 20 Apr 2009 08:30:01 -0700 (PDT) > De: Internet-Drafts@ietf.org > Para: i-d-announce@ietf.org > CC: mext@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobility EXTensions for IPv6 > Working Group of the IETF. > > > Title : Multiple Care-of Addresses Registration > Author(s) : R. Wakikawa, et al. > Filename : draft-ietf-monami6-multiplecoa-13.txt > Pages : 44 > Date : 2009-04-20 > > According to the current Mobile IPv6 specification, a mobile node may > have several care-of addresses, but only one, called the primary > care-of address, that can be registered with its home agent and the > correspondent nodes. However, for matters of cost, bandwidth, delay, > etc, it is useful for the mobile node to get Internet access through > multiple accesses simultaneously, in which case the mobile node would > be configured with multiple active IPv6 care-of addresses. This > document proposes extensions to the Mobile IPv6 protocol to register > and use multiple care-of addresses. The extensions proposed in this > document can be used by Mobile Routers using the NEMO (Network > Mobility) Basic Support protocol as well. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.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. > > > Content-Type: text/plain > Content-ID: <2009-04-20082837.I-D@ietf.org> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From tsirtsis@googlemail.com Wed Apr 29 06:38:09 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B773A7145 for ; Wed, 29 Apr 2009 06:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 BH68dHYNVDzb for ; Wed, 29 Apr 2009 06:38:08 -0700 (PDT) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by core3.amsl.com (Postfix) with ESMTP id D102C3A7144 for ; Wed, 29 Apr 2009 06:38:07 -0700 (PDT) Received: by gxk10 with SMTP id 10so2457828gxk.13 for ; Wed, 29 Apr 2009 06:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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=LSTW631xoWrgLktfOAeQGSuu1rv0pvBp2TqnNI/PFjI=; b=pJ81MugQrdb6IQnk1MdNB4xSAXog7VYl98d2q7C7zXb2Mt776OF9oOi/8gZkObvSpZ RnwVwqn7/92u77lZfmQt4Rcn6se3/fn9f34y6s24EGtOxx2iA9LUTzOUHhAYgDqLKuzJ hcQN5zUgx8hsgGZDmLJcnabcUsyADaO0DndFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AnHv8XOqPpArPtinOxjVHrTGwF4WeK3drooyYoaDmr5chw0x7W5stLzVGtAWZUDnry /kmtI5qRr5bjiTYwMi3TlZa0gzVipvAWPrAxLaQFNL8O78b7P/WENef115xcAignpn7a uFyt1ugzz2xoM4OzCztesi1I52LoL4ZPSISUs= MIME-Version: 1.0 Received: by 10.90.99.6 with SMTP id w6mr257610agb.90.1241012369689; Wed, 29 Apr 2009 06:39:29 -0700 (PDT) In-Reply-To: <6E127A8D-AB12-48F7-ADB1-8F53C7D80870@gmail.com> References: <49EDEE39.50000@it.uc3m.es> <6E127A8D-AB12-48F7-ADB1-8F53C7D80870@gmail.com> Date: Wed, 29 Apr 2009 14:39:29 +0100 Message-ID: From: George Tsirtsis To: jouni korhonen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Julien Laganier , Jari Arkko , mext Subject: Re: [MEXT] [Fwd: I-D Action:draft-ietf-monami6-multiplecoa-13.txt] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 13:38:09 -0000 Hi Jouni, We will provide these comments to the RFC Editor to clean them up, so no problem. Below I only comment on a few of them that need clarification. Thanks George On Wed, Apr 29, 2009 at 1:39 PM, jouni korhonen wr= ote: > Hi, > > I had a quick re-read of this I-D based on the recent interest on it ;) = =C2=A0And > found several placed to comment. Mainly editorials but some other stuff a= s > well. > > o Section 5.7 second bullet: > > =C2=A0"o =C2=A0If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT= ], the > =C2=A0 =C2=A0 =C2=A0mobile node needs to stop using bulk registrations wi= th the node > =C2=A0 =C2=A0 =C2=A0that sent the Binding Acknowledgement. =C2=A0It shoul= d assume that none > =C2=A0 =C2=A0 =C2=A0of the attempted registrations were successful." > > =C2=A0Why "should"? I think "It MUST assume" works better here as the CN = MUST > reject the BU anyway according to Section 6.2. third bullet. GT> I am not sure MUST in necessary. SHOULD means that you better have a good reason to do otherwise (e.g., in this case say the MN rebooted and forgot that bulk reg is not supported). In any case what is the HA going to do if the MN sends bulk registration for 2nd time? it will simply have to reject it again....so MUST/SHOULD make no difference in practice. As you say we already indicate that when talking to a CN bulk registration MUST NOT be used. > o Section 5.7 second & third bullets > =C2=A0Where "MCOA BULK REGISTRATION NOT SUPPORT" and its value is actuall= y > defined? It is not listed in IANA considerations nor in Section 4.4. GT> It should be "MCOA BULK REGISTRATION PROHIBITED" which is included. > o Section 5.7 third bullet: > =C2=A0s/corruption. ./corruption. > > o Section 5.7 fourth bullet > > =C2=A0s/replced/replaced > > o Section 5.7 fifth bullet: > > =C2=A0s/care-off/care-of > > o Section 5.7 fifth bullet: > > =C2=A0"... > =C2=A0 indicated. =C2=A0If the mobile node is trying to deregister a BID,= it > =C2=A0 NEED NOT do anything further." > > =C2=A0There is no such requirement language term as "NEED NOT" in rfc2119= . > GT> You are right :-) it should simply be lower case "need not" > o Section 5.9 > > =C2=A0"..If old bindings still exists at.." > > =C2=A0s/exists/exist > > o Section 6.2 sixth bullet, first sub-bullet > > =C2=A0"..is 20, the care-of address is copied the IPv6 address from the..= " > > =C2=A0should probably say > > =C2=A0"..is 20, the care-of address is the IPv6 address copied from the..= " > > o Section 8.1 first paragraph > > =C2=A0"..even if some of the care-of addresses are IPv4 address." > > =C2=A0s/are/is > > > Cheers, > =C2=A0 =C2=A0 =C2=A0 =C2=A0Jouni > > > > On Apr 21, 2009, at 7:03 PM, marcelo bagnulo braun wrote: > >> We have this new version of the MCOA document that addresses the comment= s >> received, including IESG review comments. >> To the best of my knowledge, the IESG is ok with the doc and ready for >> publication. >> I am planning to ask our AD to move forward in a week or so, so, if you >> have comments on the document please provide them before the 1st of may. >> >> Regards, marcelo >> (mcoa doc shepherd) >> >> -------- Mensaje original -------- >> Asunto: =C2=A0 =C2=A0 =C2=A0 =C2=A0 [MEXT] I-D Action:draft-ietf-monami6= -multiplecoa-13.txt >> Fecha: =C2=A0Mon, 20 Apr 2009 08:30:01 -0700 (PDT) >> De: =C2=A0 =C2=A0 Internet-Drafts@ietf.org >> Para: =C2=A0 i-d-announce@ietf.org >> CC: =C2=A0 =C2=A0 mext@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobility EXTensions for IPv6 Working >> Group of the IETF. >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Mu= ltiple Care-of Addresses Registration >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : R. Wakikawa,= et al. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-i= etf-monami6-multiplecoa-13.txt >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 44 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 2009-04-20 >> >> According to the current Mobile IPv6 specification, a mobile node may >> have several care-of addresses, but only one, called the primary >> care-of address, that can be registered with its home agent and the >> correspondent nodes. =C2=A0However, for matters of cost, bandwidth, dela= y, >> etc, it is useful for the mobile node to get Internet access through >> multiple accesses simultaneously, in which case the mobile node would >> be configured with multiple active IPv6 care-of addresses. =C2=A0This >> document proposes extensions to the Mobile IPv6 protocol to register >> and use multiple care-of addresses. =C2=A0The extensions proposed in thi= s >> document can be used by Mobile Routers using the NEMO (Network >> Mobility) Basic Support protocol as well. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-13.tx= t >> >> 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. >> >> >> Content-Type: text/plain >> Content-ID: <2009-04-20082837.I-D@ietf.org> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From arno@natisbad.org Thu Apr 30 09:36:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045CD3A722A for ; Thu, 30 Apr 2009 09:36:45 -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=[BAYES_00=-2.599, 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 yTnJGaHSc6vn for ; Thu, 30 Apr 2009 09:36:44 -0700 (PDT) Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 40BD83A6B72 for ; Thu, 30 Apr 2009 09:35:40 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LzZFp-0002em-IK; Thu, 30 Apr 2009 18:36:57 +0200 X-Hashcash: 1:20:090430:mext@ietf.org::1zgSQSwXoZLuR5n7:00001st+ From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG ML References: <20090430161918.5119D3A71F2@core3.amsl.com> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:090430:idsubmission@ietf.org::5Sc3ylgZmGiAkwAJ:00000000000000000000000000000000000000001Pvr X-Hashcash: 1:20:090430:arnaud.ebalard@eads.net::VGgWN2xg5PA07tfx:000000000000000000000000000000000000005plo Date: Thu, 30 Apr 2009 18:37:45 +0200 In-Reply-To: <20090430161918.5119D3A71F2@core3.amsl.com> (IETF I-D Submission Tool's message of "Thu, 30 Apr 2009 09:19:18 -0700 (PDT)") Message-ID: <87eivaksh2.fsf@small.ssi.corp> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [MEXT] [draft] MIPv6 Home Link Detection Mechanism Security considerations X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:36:45 -0000 Hello, I have just submitted a draft describing possible attacks (implemented for demonstration against an existing implementation) associated w/ the Home Link Detection mechanism and the Home Return procedure. If some among you find some interest in the topic, I'd be interested by some feedback (questions, comments). Link to the document: http://www.ietf.org/internet-drafts/draft-ebalard-mext-hld-security-00.txt Cheers, a+ IETF I-D Submission Tool writes: > A new version of I-D, draft-ebalard-mext-hld-security-00.txt has been > successfuly submitted by Arnaud Ebalard and posted to the IETF > repository. > > Filename: draft-ebalard-mext-hld-security > Revision: 00 > Title: Mobile IPv6 Home Link Detection Mechanism Security considerations > Creation_date: 2009-04-30 > WG ID: Independent Submission > Number_of_pages: 32 > > Abstract: > > MIPv6 defines the concept of Home Network for a MN, in opposition to > the foreign network where this entity may find itself. A ``Home Link > Detection'' mechanism is also specified to allow the MN to detect > when it is at home. > > MIPv6 specification mandates the use of IPsec for protecting main > signaling traffic and also defines how IPsec can be used to protect > data traffic between the MN and its HA. Even if optional, it is > expected that many deployments of MIPv6 will use it by default for MN > which may roam outside a trusted infrastructure (e.g. outside a > mobile operator network). > > When a MN detects it is at home, it is expected to stop IPsec > protection for data traffic exchanged with its Home Agent. That > event is the result of the Home Return procedure, triggered by the > Home Link Detection mechanism. > > This document discusses the possible threats and security impacts > associated with the use of this insecure NDP-based mechanism as a > trigger to drop IPsec protection of data traffic for the MN. It also > provides some results on the implementation of the attacks against an > existing MIPv6 module. Possible solutions are suggested. From Vrparente@aol.com Thu Apr 30 14:59:18 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782153A6E34 for ; Thu, 30 Apr 2009 14:59:18 -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 V5uAXKRkBqKS for ; Thu, 30 Apr 2009 14:59:17 -0700 (PDT) Received: from imo-d22.mx.aol.com (imo-d22.mx.aol.com [205.188.144.208]) by core3.amsl.com (Postfix) with ESMTP id 5FC8A3A6A24 for ; Thu, 30 Apr 2009 14:59:16 -0700 (PDT) Received: from imo-ma02.mx.aol.com (imo-ma02.mx.aol.com [64.12.78.137]) by imo-d22.mx.aol.com (v107.10) with ESMTP id RELAYIN2-349fa1f6f1e5; Thu, 30 Apr 2009 18:00:15 -0400 Received: from Vrparente@aol.com by imo-ma02.mx.aol.com (mail_out_v40_r1.5.) id l.c87.4d32d441 (34945) for ; Thu, 30 Apr 2009 18:00:04 -0400 (EDT) Received: from Study ([216.246.69.52]) by cia-da05.mx.aol.com (v123.4) with ESMTP id MAILCIADA056-888149fa1f62241; Thu, 30 Apr 2009 18:00:04 -0400 From: "Victor Blake" To: References: In-Reply-To: Date: Thu, 30 Apr 2009 17:59:38 -0400 Message-ID: <003801c9c9de$f6323ce0$e296b6a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnJxoBMXZl12mlFSPWzABQ4vwIhSwAF3OaQ Content-Language: en-us X-AOL-IP: 64.12.78.137 Subject: Re: [MEXT] MEXT Digest, Vol 22, Issue 23 draftebalard-mext-hld-security-00.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:59:18 -0000 Arnaud, Your assumption in 4.1 is that the HA relies exclusively on the BU message from the MN. In fact an HA can rely not only on the BU message itself, but also the source of the update (BU). That is that the HA, may (not necessarily but could) know about the Layer 2 source address of MN to validate the update is coming from the MN it says it is coming from based on the L3 address. In short, the L2 and L3 address can be correlated. I believe that there could be other stateful methods as well uses other link attachment mechanisms such as MIH, DNA, or FMIP in which the sequence in the state machine would not be valid if such an attack occurred within the appropriate preceeding and post registration events. If we try to address the argument beyond just that particular message to other DoS, I think it is true that there could be cause for concern. However, regardless of IPsec, Layer 2 DoS attacks would in any event still be possible. Right ? -Victor Blake -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of mext-request@ietf.org Sent: Thursday, April 30, 2009 3:00 PM To: mext@ietf.org Subject: MEXT Digest, Vol 22, Issue 23 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/mext Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send MEXT mailing list submissions to mext@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/mext or, via email, send a message with subject or body 'help' to mext-request@ietf.org You can reach the person managing the list at mext-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of MEXT digest..." Today's Topics: 1. [draft] MIPv6 Home Link Detection Mechanism Security considerations (Arnaud Ebalard) ---------------------------------------------------------------------- Message: 1 Date: Thu, 30 Apr 2009 18:37:45 +0200 From: arno@natisbad.org (Arnaud Ebalard) Subject: [MEXT] [draft] MIPv6 Home Link Detection Mechanism Security considerations To: IETF MEXT WG ML Message-ID: <87eivaksh2.fsf@small.ssi.corp> Content-Type: text/plain; charset=us-ascii Hello, I have just submitted a draft describing possible attacks (implemented for demonstration against an existing implementation) associated w/ the Home Link Detection mechanism and the Home Return procedure. If some among you find some interest in the topic, I'd be interested by some feedback (questions, comments). Link to the document: http://www.ietf.org/internet-drafts/draft-ebalard-mext-hld-security-00.txt Cheers, a+ IETF I-D Submission Tool writes: > A new version of I-D, draft-ebalard-mext-hld-security-00.txt has been > successfuly submitted by Arnaud Ebalard and posted to the IETF > repository. > > Filename: draft-ebalard-mext-hld-security > Revision: 00 > Title: Mobile IPv6 Home Link Detection Mechanism Security considerations > Creation_date: 2009-04-30 > WG ID: Independent Submission > Number_of_pages: 32 > > Abstract: > > MIPv6 defines the concept of Home Network for a MN, in opposition to > the foreign network where this entity may find itself. A ``Home Link > Detection'' mechanism is also specified to allow the MN to detect > when it is at home. > > MIPv6 specification mandates the use of IPsec for protecting main > signaling traffic and also defines how IPsec can be used to protect > data traffic between the MN and its HA. Even if optional, it is > expected that many deployments of MIPv6 will use it by default for MN > which may roam outside a trusted infrastructure (e.g. outside a > mobile operator network). > > When a MN detects it is at home, it is expected to stop IPsec > protection for data traffic exchanged with its Home Agent. That > event is the result of the Home Return procedure, triggered by the > Home Link Detection mechanism. > > This document discusses the possible threats and security impacts > associated with the use of this insecure NDP-based mechanism as a > trigger to drop IPsec protection of data traffic for the MN. It also > provides some results on the implementation of the attacks against an > existing MIPv6 module. Possible solutions are suggested. ------------------------------ _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext End of MEXT Digest, Vol 22, Issue 23 ************************************ From root@core3.amsl.com Thu Apr 30 15:45:01 2009 Return-Path: X-Original-To: mext@ietf.org Delivered-To: mext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6387828C137; Thu, 30 Apr 2009 15:45: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: <20090430224501.6387828C137@core3.amsl.com> Date: Thu, 30 Apr 2009 15:45:01 -0700 (PDT) Cc: mext@ietf.org Subject: [MEXT] I-D ACTION:draft-ietf-mext-flow-binding-02.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 22:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Flow Bindings in Mobile IPv6 and Nemo Basic Support Author(s) : G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, K. Kuladinithi Filename : draft-ietf-mext-flow-binding-02.txt Pages : 33 Date : 2009-4-30 This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct their peers to direct downlink flows to specific addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-02.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-mext-flow-binding-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-4-30153512.I-D@ietf.org> --NextPart--