From jouni.nospam@gmail.com Tue Nov 1 06:30:05 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E756E1F0C59 for ; Tue, 1 Nov 2011 06:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi1bpTOXeUjo for ; Tue, 1 Nov 2011 06:30:05 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE0771F0C3F for ; Tue, 1 Nov 2011 06:30:04 -0700 (PDT) Received: by eyg24 with SMTP id 24so6716017eyg.31 for ; Tue, 01 Nov 2011 06:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+Xb+ACNjSSOKQyXyFmavUyb/N3V6184kVxmQ/+jVFoY=; b=N/FoCZVJVFnQNKO7tLE5KOjHYhXlyTgwYOjOBLGqRydRHa/i4+Wn3FV1ThZGWVAEJN P/1SRnGR5+Hcfx+3puBwD7gKHM1YkaKpejWZbRiTvugBt70xAE59Xqb2OMvCcNk8C3P0 mwALTKLRCGhMR1yftuJXfscf93kUnF+Lbi9PI= Received: by 10.213.35.70 with SMTP id o6mr1199321ebd.102.1320154202513; Tue, 01 Nov 2011 06:30:02 -0700 (PDT) Received: from dhcp-27-53.ripemtg.ripe.net (dhcp-27-53.ripemtg.ripe.net. [193.0.27.53]) by mx.google.com with ESMTPS id d6sm31810920eec.10.2011.11.01.06.29.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Nov 2011 06:30:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <1320004272.3313.118.camel@acorde.it.uc3m.es> Date: Tue, 1 Nov 2011 15:29:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <40378106-C231-4FE2-8CC3-5798F5A96841@gmail.com> References: <1320004272.3313.118.camel@acorde.it.uc3m.es> To: cjbc@it.uc3m.es X-Mailer: Apple Mail (2.1084) Cc: netext@ietf.org Subject: Re: [netext] Review of draft-ietf-netext-access-network-option-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 13:30:06 -0000 Carlos, Thanks for the review. See some responses inline. On Oct 30, 2011, at 9:51 PM, Carlos Jes=FAs Bernardos Cano wrote: > Hi all, >=20 > I've read draft-ietf-netext-access-network-option-00 and I have some > comments: >=20 > - I think the document is OK in general. > - The normative text of Section 3 needs to be revised. For example, > there are lots of normative words in lowercase. Ok. > - Can a PBU carry more than one ANI option? It is not clearly = mentioned, > though Figure 1 may indicate it is possible (as there is both BSSID = and > Geo-Loc shown as part of the identification of the access network. There can be one ANI option.. as you can access only one operator = network at once. The option structure is still in flux so it is likely to change a bit in = the future. For example there might be cases where multiple network = identifiers are useful (e.g. SSID accompanied with geo-location etc). > - Figure 3 is not referred in the document. > - I think there should be text dealing with the case in which an LMA = not > supporting/understanding the ANI option receives a PBU carrying one. Ok. You mean a simple capability confirmation like echoing the ANI = option back in the PBA? Or something else? > - It seems that included Nw-ID types are 802.11 related. Is there no > other case (e.g., 3GPP related) worth including? This is the initial set. If you have additional Nw-IDs to propose with a = good use case, go ahead :) > - Does the ANI option introduce privacy issues? In case an attacker = was > able to overhear PBUs, it could be able to know where a particular MN = is > geographically located. Not sure this is a realistic concern in a real > deployment, but authors might want to mention that IPsec encryption > could be used to mitigate this problem. I think we do not need to go beyond existing RFC5213 security.. Even = MN-ID option introduces a privacy issue more or less. - Jouni >=20 > Thanks, >=20 > Carlos >=20 > --=20 > Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From cjbc@it.uc3m.es Tue Nov 1 16:45:43 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2D51F0C7D for ; Tue, 1 Nov 2011 16:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPlFI-Y+wmx7 for ; Tue, 1 Nov 2011 16:45:43 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id D20BF1F0C55 for ; Tue, 1 Nov 2011 16:45:42 -0700 (PDT) X-uc3m-safe: yes Received: from [192.168.1.3] (82.158.121.177.dyn.user.ono.com [82.158.121.177]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id EAD21BFA89B; Wed, 2 Nov 2011 00:45:40 +0100 (CET) Message-ID: <1320191140.19191.19.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: jouni korhonen Date: Wed, 02 Nov 2011 00:45:40 +0100 In-Reply-To: <40378106-C231-4FE2-8CC3-5798F5A96841@gmail.com> References: <1320004272.3313.118.camel@acorde.it.uc3m.es> <40378106-C231-4FE2-8CC3-5798F5A96841@gmail.com> Organization: Universidad Carlos III de Madrid Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Paz+pTeZklJ6FFGpa4hv" X-Mailer: Evolution 3.0.3-2 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18486.002 Cc: netext@ietf.org Subject: Re: [netext] Review of draft-ietf-netext-access-network-option-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 23:45:44 -0000 --=-Paz+pTeZklJ6FFGpa4hv Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Jouni, Thanks for your comments. Some additional ones from my side below. On Tue, 2011-11-01 at 15:29 +0200, jouni korhonen wrote: > Carlos, >=20 > Thanks for the review. See some responses inline. >=20 > On Oct 30, 2011, at 9:51 PM, Carlos Jes=FAs Bernardos Cano wrote: >=20 > > Hi all, > >=20 > > I've read draft-ietf-netext-access-network-option-00 and I have some > > comments: > >=20 > > - I think the document is OK in general. > > - The normative text of Section 3 needs to be revised. For example, > > there are lots of normative words in lowercase. >=20 > Ok. >=20 > > - Can a PBU carry more than one ANI option? It is not clearly mentioned= , > > though Figure 1 may indicate it is possible (as there is both BSSID and > > Geo-Loc shown as part of the identification of the access network. >=20 > There can be one ANI option.. as you can access only one operator network= at once. >=20 > The option structure is still in flux so it is likely to change a bit in = the future. For example there might be cases where multiple network identif= iers are useful (e.g. SSID accompanied with geo-location etc). This is exactly what I was referring to. In the current draft, it seems that multiple network identifiers can be conveyed, but this seems not possible to be done with a single ANI option (as currently defined). >=20 > > - Figure 3 is not referred in the document. > > - I think there should be text dealing with the case in which an LMA no= t > > supporting/understanding the ANI option receives a PBU carrying one. >=20 > Ok. You mean a simple capability confirmation like echoing the ANI option= back in the PBA? Or something else? Well, just some text explaining what an LMA will do in that case. Maybe just ignore the ANI option, but this needs to be mentioned in the draft, IMHO. >=20 > > - It seems that included Nw-ID types are 802.11 related. Is there no > > other case (e.g., 3GPP related) worth including? >=20 > This is the initial set. If you have additional Nw-IDs to propose with a = good use case, go ahead :) OK, I'll try that exercise :) >=20 > > - Does the ANI option introduce privacy issues? In case an attacker was > > able to overhear PBUs, it could be able to know where a particular MN i= s > > geographically located. Not sure this is a realistic concern in a real > > deployment, but authors might want to mention that IPsec encryption > > could be used to mitigate this problem. >=20 > I think we do not need to go beyond existing RFC5213 security.. Even MN-I= D option introduces a privacy issue more or less. Well, I'm not an expert but I think this deserves at least a second look. Jong-Hyouk also expressed some concerns about this. At least, I think this should be mentioned on the Security Considerations section, IMHO. Thanks, Carlos >=20 > - Jouni >=20 >=20 >=20 > >=20 > > Thanks, > >=20 > > Carlos > >=20 > > --=20 > > Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-Paz+pTeZklJ6FFGpa4hv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk6whKQACgkQNdy6TdFwT2cgngCfXQfXtJU4lfxH828QyPRf+2Tt 218AnjGUnVd3rLvix1FngGwQaqdLv3V1 =/E5a -----END PGP SIGNATURE----- --=-Paz+pTeZklJ6FFGpa4hv-- From jouni.nospam@gmail.com Wed Nov 2 02:46:36 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F7A1F0CA2 for ; Wed, 2 Nov 2011 02:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We4fgbupgCRb for ; Wed, 2 Nov 2011 02:46:35 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E68C11E80D9 for ; Wed, 2 Nov 2011 02:46:27 -0700 (PDT) Received: by eyg24 with SMTP id 24so7523645eyg.31 for ; Wed, 02 Nov 2011 02:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=qK79M7K8J9i63o3sspLyOTigJXIdnVzhNqt8WoOfvlI=; b=o0zZh5Ni6NEal7aNWYnvSLuZtS5tQEQ3tHjla7vldaKUdZYm3afDse93EB23GxC8vJ 1UkGhNCtsKfPdN7S3ByIizIHv2SC19uF+NHjB1xDZHLD2mgIL+xieK9BP/ItPSxvH59b DiXo66MF9PKk3u8mmVudPvvdJx0Iyj/F+eTEY= Received: by 10.213.2.75 with SMTP id 11mr1629031ebi.25.1320227186501; Wed, 02 Nov 2011 02:46:26 -0700 (PDT) Received: from dhcp-27-53.ripemtg.ripe.net (dhcp-27-53.ripemtg.ripe.net. [193.0.27.53]) by mx.google.com with ESMTPS id q28sm4965129eea.6.2011.11.02.02.46.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Nov 2011 02:46:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <4EB10549.805@gmail.com> Date: Wed, 2 Nov 2011 11:46:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8FED80E1-F25F-4079-812C-1921FD3F4746@gmail.com> References: <1320004272.3313.118.camel@acorde.it.uc3m.es> <40378106-C231-4FE2-8CC3-5798F5A96841@gmail.com> <1320191140.19191.19.camel@acorde.it.uc3m.es> <4EB10549.805@gmail.com> To: Jong-Hyouk Lee X-Mailer: Apple Mail (2.1084) Cc: netext@ietf.org Subject: Re: [netext] Review of draft-ietf-netext-access-network-option-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 09:46:36 -0000 Hi, On Nov 2, 2011, at 10:54 AM, Jong-Hyouk Lee wrote: > Dear all. >=20 > Regarding location privacy, I agree with Carlos. As I mentioned it = before and Carlos also noticed, it should be mentioned at least at the = security consideration section at the document. Ok. Thou shalt be done. - JOuni >=20 > Thanks. >=20 > On Wed 02 Nov 2011 12:45:40 AM CET, Carlos Jes=FAs Bernardos Cano = wrote: >>=20 >> Hi Jouni, >>=20 >> Thanks for your comments. Some additional ones from my side below. >>=20 >> On Tue, 2011-11-01 at 15:29 +0200, jouni korhonen wrote: >>>=20 >>> Carlos, >>>=20 >>> Thanks for the review. See some responses inline. >>>=20 >>> On Oct 30, 2011, at 9:51 PM, Carlos Jes=FAs Bernardos Cano wrote: >>>=20 >>>>=20 >>>> Hi all, >>>>=20 >>>> I've read draft-ietf-netext-access-network-option-00 and I have = some >>>> comments: >>>>=20 >>>> - I think the document is OK in general. >>>> - The normative text of Section 3 needs to be revised. For example, >>>> there are lots of normative words in lowercase. >>>=20 >>>=20 >>> Ok. >>>=20 >>>>=20 >>>> - Can a PBU carry more than one ANI option? It is not clearly = mentioned, >>>> though Figure 1 may indicate it is possible (as there is both BSSID = and >>>> Geo-Loc shown as part of the identification of the access network. >>>=20 >>>=20 >>> There can be one ANI option.. as you can access only one operator = network at once. >>>=20 >>> The option structure is still in flux so it is likely to change a = bit in the future. For example there might be cases where multiple = network identifiers are useful (e.g. SSID accompanied with geo-location = etc). >>=20 >>=20 >> This is exactly what I was referring to. In the current draft, it = seems >> that multiple network identifiers can be conveyed, but this seems not >> possible to be done with a single ANI option (as currently defined). >>=20 >>>=20 >>>=20 >>>>=20 >>>> - Figure 3 is not referred in the document. >>>> - I think there should be text dealing with the case in which an = LMA not >>>> supporting/understanding the ANI option receives a PBU carrying = one. >>>=20 >>>=20 >>> Ok. You mean a simple capability confirmation like echoing the ANI = option back in the PBA? Or something else? >>=20 >>=20 >> Well, just some text explaining what an LMA will do in that case. = Maybe >> just ignore the ANI option, but this needs to be mentioned in the = draft, >> IMHO. >>=20 >>>=20 >>>=20 >>>>=20 >>>> - It seems that included Nw-ID types are 802.11 related. Is there = no >>>> other case (e.g., 3GPP related) worth including? >>>=20 >>>=20 >>> This is the initial set. If you have additional Nw-IDs to propose = with a good use case, go ahead :) >>=20 >>=20 >> OK, I'll try that exercise :) >>=20 >>>=20 >>>=20 >>>>=20 >>>> - Does the ANI option introduce privacy issues? In case an attacker = was >>>> able to overhear PBUs, it could be able to know where a particular = MN is >>>> geographically located. Not sure this is a realistic concern in a = real >>>> deployment, but authors might want to mention that IPsec encryption >>>> could be used to mitigate this problem. >>>=20 >>>=20 >>> I think we do not need to go beyond existing RFC5213 security.. Even = MN-ID option introduces a privacy issue more or less. >>=20 >>=20 >> Well, I'm not an expert but I think this deserves at least a second >> look. Jong-Hyouk also expressed some concerns about this. At least, I >> think this should be mentioned on the Security Considerations = section, >> IMHO. >>=20 >> Thanks, >>=20 >> Carlos >>=20 >>>=20 >>>=20 >>> - Jouni >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Carlos >>>>=20 >>>> --=20 >>>> Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ >>>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> --=20 >> IMARA Team, INRIA, France >> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >>=20 >> #email: hurryon (at) gmail.com || jong-hyouk.lee (at) inria.fr >> #webpage: http://sites.google.com/site/hurryon/ From telemaco.melia@alcatel-lucent.com Wed Nov 2 08:19:54 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6600B21F8ED5 for ; Wed, 2 Nov 2011 08:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2faSYC9Jz6sg for ; Wed, 2 Nov 2011 08:19:54 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id ABB5A21F8E9D for ; Wed, 2 Nov 2011 08:19:53 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pA2FJoRA022177 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 2 Nov 2011 16:19:51 +0100 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.111]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 2 Nov 2011 16:19:36 +0100 From: "MELIA, TELEMACO (TELEMACO)" To: "netext@ietf.org" Date: Wed, 2 Nov 2011 16:19:33 +0100 Thread-Topic: Additional review of ID draft-ietf-netext-access-network-option-00 Thread-Index: AcyZctLn9/RO8RuPR5exeaKicfkAEA== Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EEC2A0F0D@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3D6C64F2D792B540BAAEBCEF6509363B0EEC2A0F0DFRMRSSXCHMBSE_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [netext] Additional review of ID draft-ietf-netext-access-network-option-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 15:19:54 -0000 --_000_3D6C64F2D792B540BAAEBCEF6509363B0EEC2A0F0DFRMRSSXCHMBSE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, As requested here follows my review. The document is generally well written and understandable. Introduction: I know that we are not supposed to say how a LMA uses the inf= o contained in an ANI but more context (references) would not harm. Why tal= king about 802.11 only? Section 3: If how the MAG discovers ANI from attached MNs is out of scope t= hen you should state DHCP method as an example. There are other ways of doi= ng this, or you list all of them. Section 4: why not defining a generic ANI option not specific to WIFI? Else= we should clearly make the IF WIFI specific. Had a couple of issues more that Carlos already mentioned. Thanks telemaco --_000_3D6C64F2D792B540BAAEBCEF6509363B0EEC2A0F0DFRMRSSXCHMBSE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
As requested here follows my review.
 
The document is generally well written and understandable.
 
Introduction: I know that we are not supposed to say how a LMA uses th= e info contained in an ANI but more context (references) would not harm. Wh= y talking about 802.11 only?
 
Section 3: If how the MAG discovers ANI from attached MNs is out of sc= ope then you should state DHCP method as an example. There are other ways o= f doing this, or you list all of them.
 
Section 4: why not defining a generic ANI option not specific to WIFI?= Else we should clearly make the IF WIFI specific.
 
Had a couple of issues more that Carlos already mentioned.
 
Thanks
telemaco
 
 
 
 
 
 --_000_3D6C64F2D792B540BAAEBCEF6509363B0EEC2A0F0DFRMRSSXCHMBSE_-- From Basavaraj.Patil@nokia.com Mon Nov 7 12:17:58 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5550511E80C1 for ; Mon, 7 Nov 2011 12:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.12 X-Spam-Level: X-Spam-Status: No, score=-103.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkhlk+-G8G+8 for ; Mon, 7 Nov 2011 12:17:57 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id A379311E80C0 for ; Mon, 7 Nov 2011 12:17:57 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA7KHsng004524; Mon, 7 Nov 2011 22:17:55 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 22:17:54 +0200 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0339.002; Mon, 7 Nov 2011 21:17:53 +0100 From: To: Thread-Topic: Review of I-D: draft-ietf-netext-pd-pmip-01 Thread-Index: AQHMnYpTGqYa7OGEukONGJ+vApALIQ== Date: Mon, 7 Nov 2011 20:17:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.33] Content-Type: text/plain; charset="us-ascii" Content-ID: <541C80BA34419143AEBCE7BEBA0D6FA3@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2011 20:17:54.0086 (UTC) FILETIME=[54CFE460:01CC9D8A] X-Nokia-AV: Clean Cc: draft-ietf-netext-pd-pmip@tools.ietf.org Subject: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 20:17:58 -0000 A few quick comments: 1. Abstract should have no references. And the description can be improved. It really is hard to understand what this I-D is trying to accomplish.=20 2. The introduction section can be improved. Maybe you should include a problem statement section to indicate what is lacking in PMIP6 as per RFC5213. 3. In Sec 3.1 it states: " o The MR (as a RR) MUST either obtain the Home Network Prefix (HNP) before initiating the DHCPv6-PD procedure or in case of stateful address configuration simultaneously while configuring the Mobile Node Home Address (MN-HoA). " So does this imply that the MR (PMIP6 MN) obtains an HNP as per RFC5213 for its own use prior to the MR requesting via DHCPv6 another set of prefixes to be used for delegating to downstream nodes?=20 4. If the prefixes (delegated) are provided by a DHCP server (and not the LMA), how does the LMA get informed about these? In the PBU? How do you ensure that "All the mobile network prefixes managed in the DR MUST be reachable via local mobility anchor (LMA)" when they are not assigned by the LMA? 5. Sec 3.1 also states: "The delegating router (DR) can be located either at LMA or some other device in the PMIPv6 domain" What is this some other device? 6. In Sec 3.2 the I-D states that the profile needs to indicate whether an MN can be assigned prefixes for delegation. Does the profile indicate whether the host is a mobile router? Is this needed? Any MN should be able to act as an MR. 7. In Fig 1, you have a DR shown there. How does the DR indicate the assigned prefixes to the LMA? - Step 5 seems disconnected from the rest of the process. Maybe it is better to split that aspect and show it in another figure. 8. Does the lifetime of the delegated prefix (assigned by a DR) the same as the lifetime assigned by the LMA? Why not have Sec 3.3.3 to describe how a prefix is revoked or deleted? Text is currently in 3.3.2. 9. In sec 3.4.2: "Other considerations from Section 6.10.5 or [RFC5213]" Sec 6.10.5 of this I-D? There is none. 10. Sec 3.5.2 states: "In order to receive those packets, the LMA MUST advertise a connected route into the routing infrastructure for the MR's MNP(s)." - Is it enough from a specification standpoint to state that the routes need to be injected into the routing infra? Handwaving???? 11. Are there any new threats or security issues that arise from assigning prefixes to be delegated downstream in the case of PMIP6? Security section seems pretty light. -Raj From hurryon@gmail.com Wed Nov 2 01:54:38 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F8311E80F4 for ; Wed, 2 Nov 2011 01:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHr4oajjf5bW for ; Wed, 2 Nov 2011 01:54:37 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5626211E80D3 for ; Wed, 2 Nov 2011 01:54:37 -0700 (PDT) Received: by bkat8 with SMTP id t8so3600304bka.31 for ; Wed, 02 Nov 2011 01:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cMH69lTY357lGLu2NkHtNPA+jnlyEUgTR00btpVPVc4=; b=oj90+r4Wqd5L2cChrDO/jx5bIUW0AuqsaeL+fQ+L6T5rkr759NWJYEDMBPxJ6daSAt uDRnXl49wk61FMMUl7ogilw6e2IgHWbqqQ4TCdlzePeW/XRIkGTroyTGbAJlxAOVvDVR F5JaqhBU/sIhy3GJkvdAVqXaANiuVZYrzXwfQ= Received: by 10.204.15.211 with SMTP id l19mr2717579bka.75.1320224076326; Wed, 02 Nov 2011 01:54:36 -0700 (PDT) Received: from [128.93.62.121] (dhcp-rocq-121.inria.fr. [128.93.62.121]) by mx.google.com with ESMTPS id e14sm1590781bka.0.2011.11.02.01.54.34 (version=SSLv3 cipher=OTHER); Wed, 02 Nov 2011 01:54:34 -0700 (PDT) Message-ID: <4EB10549.805@gmail.com> Date: Wed, 02 Nov 2011 09:54:33 +0100 From: Jong-Hyouk Lee Organization: INRIA, France User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111008 Thunderbird/8.0 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1320004272.3313.118.camel@acorde.it.uc3m.es> <40378106-C231-4FE2-8CC3-5798F5A96841@gmail.com> <1320191140.19191.19.camel@acorde.it.uc3m.es> In-Reply-To: <1320191140.19191.19.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 07 Nov 2011 12:50:16 -0800 Cc: netext@ietf.org Subject: Re: [netext] Review of draft-ietf-netext-access-network-option-00 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 08:54:38 -0000 Dear all. Regarding location privacy, I agree with Carlos. As I mentioned it before and Carlos also noticed, it should be mentioned at least at the security consideration section at the document. Thanks. On Wed 02 Nov 2011 12:45:40 AM CET, Carlos Jesús Bernardos Cano wrote: > > Hi Jouni, > > Thanks for your comments. Some additional ones from my side below. > > On Tue, 2011-11-01 at 15:29 +0200, jouni korhonen wrote: >> >> Carlos, >> >> Thanks for the review. See some responses inline. >> >> On Oct 30, 2011, at 9:51 PM, Carlos Jesús Bernardos Cano wrote: >> >>> >>> Hi all, >>> >>> I've read draft-ietf-netext-access-network-option-00 and I have some >>> comments: >>> >>> - I think the document is OK in general. >>> - The normative text of Section 3 needs to be revised. For example, >>> there are lots of normative words in lowercase. >> >> >> Ok. >> >>> >>> - Can a PBU carry more than one ANI option? It is not clearly mentioned, >>> though Figure 1 may indicate it is possible (as there is both BSSID and >>> Geo-Loc shown as part of the identification of the access network. >> >> >> There can be one ANI option.. as you can access only one operator >> network at once. >> >> The option structure is still in flux so it is likely to change a bit >> in the future. For example there might be cases where multiple >> network identifiers are useful (e.g. SSID accompanied with >> geo-location etc). > > > This is exactly what I was referring to. In the current draft, it seems > that multiple network identifiers can be conveyed, but this seems not > possible to be done with a single ANI option (as currently defined). > >> >> >>> >>> - Figure 3 is not referred in the document. >>> - I think there should be text dealing with the case in which an LMA not >>> supporting/understanding the ANI option receives a PBU carrying one. >> >> >> Ok. You mean a simple capability confirmation like echoing the ANI >> option back in the PBA? Or something else? > > > Well, just some text explaining what an LMA will do in that case. Maybe > just ignore the ANI option, but this needs to be mentioned in the draft, > IMHO. > >> >> >>> >>> - It seems that included Nw-ID types are 802.11 related. Is there no >>> other case (e.g., 3GPP related) worth including? >> >> >> This is the initial set. If you have additional Nw-IDs to propose >> with a good use case, go ahead :) > > > OK, I'll try that exercise :) > >> >> >>> >>> - Does the ANI option introduce privacy issues? In case an attacker was >>> able to overhear PBUs, it could be able to know where a particular MN is >>> geographically located. Not sure this is a realistic concern in a real >>> deployment, but authors might want to mention that IPsec encryption >>> could be used to mitigate this problem. >> >> >> I think we do not need to go beyond existing RFC5213 security.. Even >> MN-ID option introduces a privacy issue more or less. > > > Well, I'm not an expert but I think this deserves at least a second > look. Jong-Hyouk also expressed some concerns about this. At least, I > think this should be mentioned on the Security Considerations section, > IMHO. > > Thanks, > > Carlos > >> >> >> - Jouni >> >> >> >>> >>> >>> Thanks, >>> >>> Carlos >>> >>> -- >>> Carlos Jesús Bernardos Cano http://www.netcom.it.uc3m.es/ >>> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> >> > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > -- > IMARA Team, INRIA, France > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > > #email: hurryon (at) gmail.com || jong-hyouk.lee (at) inria.fr > #webpage: http://sites.google.com/site/hurryon/ From Basavaraj.Patil@nokia.com Wed Nov 9 10:21:48 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00E021F8593 for ; Wed, 9 Nov 2011 10:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.652 X-Spam-Level: X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yju7C3nmRETI for ; Wed, 9 Nov 2011 10:21:48 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 089AC21F84D3 for ; Wed, 9 Nov 2011 10:21:47 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA9ILk2r018949 for ; Wed, 9 Nov 2011 20:21:46 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 20:21:41 +0200 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0339.002; Wed, 9 Nov 2011 19:21:40 +0100 From: To: Thread-Topic: Volunteers to take minutes, jabber scribe Thread-Index: AQHMnwxsXJnzf6EMm0+gTSNXup4yAg== Date: Wed, 9 Nov 2011 18:21:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <6DA928C751141E4F9D28AA5CE8C57E0C@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 18:21:41.0269 (UTC) FILETIME=[6D83F450:01CC9F0C] X-Nokia-AV: Clean Subject: [netext] Volunteers to take minutes, jabber scribe X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 18:21:48 -0000 Seeking volunteers to take minutes of the Netext WG meeting at IETF82. You can use: http://tools.ietf.org/wg/netext/minutes -Chairs From zhou.xingyue@zte.com.cn Thu Nov 10 04:36:21 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1C21F8B1F; Thu, 10 Nov 2011 04:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8mDU-k-xY+r; Thu, 10 Nov 2011 04:36:20 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0725321F8B1D; Thu, 10 Nov 2011 04:36:19 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 566903502467742; Thu, 10 Nov 2011 20:25:44 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 20387.7534587262; Thu, 10 Nov 2011 20:31:21 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAACVFWf016539; Thu, 10 Nov 2011 20:31:15 +0800 (GMT-8) (envelope-from zhou.xingyue@zte.com.cn) In-Reply-To: To: MIME-Version: 1.0 X-KeepSent: 69C8640F:9EAA66B4-48257944:003FA1B5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.xingyue@zte.com.cn Date: Thu, 10 Nov 2011 20:30:57 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-10 20:31:18, Serialize complete at 2011-11-10 20:31:18 Content-Type: multipart/alternative; boundary="=_alternative 0044C66D48257944_=" X-MAIL: mse02.zte.com.cn pAACVFWf016539 Cc: netext@ietf.org, draft-ietf-netext-pd-pmip@tools.ietf.org, netext-bounces@ietf.org Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 12:36:21 -0000 This is a multipart message in MIME format. --=_alternative 0044C66D48257944_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUmFqLA0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIGJlbG93IGlubGlu ZS4NCg0KbmV0ZXh0LWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDExLTExLTA4IMnPzucgMDQ6MTc6 NTI6DQoNCj4gDQo+IEEgZmV3IHF1aWNrIGNvbW1lbnRzOg0KPiANCj4gMS4gQWJzdHJhY3Qgc2hv dWxkIGhhdmUgbm8gcmVmZXJlbmNlcy4gQW5kIHRoZSBkZXNjcmlwdGlvbiBjYW4gYmUNCj4gICAg aW1wcm92ZWQuIEl0IHJlYWxseSBpcyBoYXJkIHRvIHVuZGVyc3RhbmQgd2hhdCB0aGlzIEktRCBp cyB0cnlpbmcNCj4gICAgdG8gYWNjb21wbGlzaC4gDQo+IA0KPiAyLiBUaGUgaW50cm9kdWN0aW9u IHNlY3Rpb24gY2FuIGJlIGltcHJvdmVkLiBNYXliZSB5b3Ugc2hvdWxkIGluY2x1ZGUNCj4gICAg YSBwcm9ibGVtIHN0YXRlbWVudCBzZWN0aW9uIHRvIGluZGljYXRlIHdoYXQgaXMgbGFja2luZyBp biBQTUlQNiBhcw0KPiAgICBwZXIgUkZDNTIxMy4NCltKb3ldUmV3b3JkaW5nIHdpbGwgYmUgZG9u ZSBmb3IgMSYyIGluIG5leHQgdmVyc2lvbi4NCj4gDQo+IDMuIEluIFNlYyAzLjEgaXQgc3RhdGVz Og0KPiAiDQo+ICAgIG8gIFRoZSBNUiAoYXMgYSBSUikgTVVTVCBlaXRoZXIgb2J0YWluIHRoZSBI b21lIE5ldHdvcmsgUHJlZml4IChITlApDQo+ICAgICAgIGJlZm9yZSBpbml0aWF0aW5nIHRoZSBE SENQdjYtUEQgcHJvY2VkdXJlIG9yIGluIGNhc2Ugb2Ygc3RhdGVmdWwNCj4gICAgICAgYWRkcmVz cyBjb25maWd1cmF0aW9uIHNpbXVsdGFuZW91c2x5IHdoaWxlIGNvbmZpZ3VyaW5nIHRoZSBNb2Jp bGUNCj4gICAgICAgTm9kZSBIb21lIEFkZHJlc3MgKE1OLUhvQSkuDQo+ICINCj4gDQo+ICAgIFNv IGRvZXMgdGhpcyBpbXBseSB0aGF0IHRoZSBNUiAoUE1JUDYgTU4pIG9idGFpbnMgYW4gSE5QIGFz IHBlcg0KPiAgICBSRkM1MjEzIGZvciBpdHMgb3duIHVzZSBwcmlvciB0byB0aGUgTVIgcmVxdWVz dGluZyB2aWEgREhDUHY2DQo+ICAgIGFub3RoZXIgc2V0IG9mIHByZWZpeGVzIHRvIGJlIHVzZWQg Zm9yIGRlbGVnYXRpbmcgdG8gZG93bnN0cmVhbQ0KPiAgICBub2Rlcz8gDQpbSm95XVllcy4NCj4g DQo+IDQuIElmIHRoZSBwcmVmaXhlcyAoZGVsZWdhdGVkKSBhcmUgcHJvdmlkZWQgYnkgYSBESENQ IHNlcnZlciAoYW5kIG5vdA0KPiAgICB0aGUgTE1BKSwgaG93IGRvZXMgdGhlIExNQSBnZXQgaW5m b3JtZWQgYWJvdXQgdGhlc2U/IEluIHRoZSBQQlU/DQo+ICAgIEhvdyBkbyB5b3UgZW5zdXJlIHRo YXQNCj4gICAgIkFsbCB0aGUgbW9iaWxlIG5ldHdvcmsgcHJlZml4ZXMgbWFuYWdlZCBpbiB0aGUg RFIgTVVTVCBiZQ0KPiAgICByZWFjaGFibGUgdmlhIGxvY2FsIG1vYmlsaXR5IGFuY2hvciAoTE1B KSIgd2hlbiB0aGV5IGFyZSBub3QNCj4gICAgYXNzaWduZWQgYnkgdGhlIExNQT8NCltKb3ldSGVy ZSBpdCBhc3N1bWVzIHRoYXQgdGhlIExNQSBjYW4gaW50ZXJhY3Qgd2l0aCB0aGUgREhDUHY2IFNl cnZlciANCndpdGhpbiBzb21lIG90aGVyIG1lY2hhbmlzbXMgZS5nLiBSYWRpdXMuDQo+IA0KPiA1 LiBTZWMgMy4xIGFsc28gc3RhdGVzOg0KPiAgICAiVGhlIGRlbGVnYXRpbmcgcm91dGVyIChEUikg Y2FuIGJlIGxvY2F0ZWQgZWl0aGVyIGF0IExNQSBvciBzb21lDQo+ICAgICAgIG90aGVyIGRldmlj ZSBpbiB0aGUgUE1JUHY2IGRvbWFpbiINCj4gDQo+ICAgICBXaGF0IGlzIHRoaXMgc29tZSBvdGhl ciBkZXZpY2U/DQpbSm95XUhlcmUgd2UganVzdCBzdHVkeSB0aGVzZSB0d28ga2luZHMgb2YgZGVw bG95bWVudHMgd2hpY2ggYXJlIGNvbW1vbiBpbiANCmN1cnJlbnQgbmV0d29yay4NCj4gDQo+IDYu ICBJbiBTZWMgMy4yIHRoZSBJLUQgc3RhdGVzIHRoYXQgdGhlIHByb2ZpbGUgbmVlZHMgdG8gaW5k aWNhdGUNCj4gICAgIHdoZXRoZXIgYW4gTU4gY2FuIGJlIGFzc2lnbmVkIHByZWZpeGVzIGZvciBk ZWxlZ2F0aW9uLiBEb2VzIHRoZQ0KPiAgICAgcHJvZmlsZSBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBo b3N0IGlzIGEgbW9iaWxlIHJvdXRlcj8gSXMgdGhpcw0KPiAgICAgbmVlZGVkPyBBbnkgTU4gc2hv dWxkIGJlIGFibGUgdG8gYWN0IGFzIGFuIE1SLg0KW0pveV1NTiBpcyBhYmxlIHRvIGFjdCBhcyBh biBNUiBkb2VzIG5vdCBtZWFuIGl0IGNhbiBvYnRhaW4gbW9iaWxlIG5ldHdvcmsgDQpwcmVmaXgu IFVzdWFsbHkgd2hldGhlciB0aGUgbW9iaWxlIG5ldHdvcmsgcHJlZml4IGlzIGFsbG93ZWQgZGVw ZW5kcyBvbiANCnRoZSBwcm9maWxlLg0KPiANCj4gNy4gSW4gRmlnIDEsIHlvdSBoYXZlIGEgRFIg c2hvd24gdGhlcmUuIEhvdyBkb2VzIHRoZSBEUiBpbmRpY2F0ZSB0aGUNCj4gICAgYXNzaWduZWQg cHJlZml4ZXMgdG8gdGhlIExNQT8NCj4gICAgLSBTdGVwIDUgc2VlbXMgZGlzY29ubmVjdGVkIGZy b20gdGhlIHJlc3Qgb2YgdGhlIHByb2Nlc3MuIE1heWJlIGl0DQo+ICAgIGlzIGJldHRlciB0byBz cGxpdCB0aGF0IGFzcGVjdCBhbmQgc2hvdyBpdCBpbiBhbm90aGVyIGZpZ3VyZS4NCltKb3ldQXMg SSBzYXkgaW4gUTQuIEkgYW0gbm90IHN1cmUgd2hhdCB5b3UgbWVudGlvbiBvZiB0aGUgc3RlcCA1 LiBJdCBpcyANCmp1c3QgcmVsYXllZCBieSB0aGUgTUFHLg0KPiANCj4gOC4gRG9lcyB0aGUgbGlm ZXRpbWUgb2YgdGhlIGRlbGVnYXRlZCBwcmVmaXggKGFzc2lnbmVkIGJ5IGEgRFIpIHRoZQ0KPiAg ICBzYW1lIGFzIHRoZSBsaWZldGltZSBhc3NpZ25lZCBieSB0aGUgTE1BPw0KW0pveV1ZZXMuDQo+ ICAgIFdoeSBub3QgaGF2ZSBTZWMgMy4zLjMgdG8gZGVzY3JpYmUgaG93IGEgcHJlZml4IGlzIHJl dm9rZWQgb3INCj4gICAgZGVsZXRlZD8gVGV4dCBpcyBjdXJyZW50bHkgaW4gMy4zLjIuDQpbSm95 XVRoaXMgaXMgYSBnb29kIHByb3Bvc2FsLg0KPiANCj4gOS4gSW4gc2VjIDMuNC4yOg0KPiAgICAi T3RoZXIgY29uc2lkZXJhdGlvbnMgZnJvbSBTZWN0aW9uIDYuMTAuNSBvciBbUkZDNTIxM10iDQo+ IA0KPiAgICBTZWMgNi4xMC41IG9mIHRoaXMgSS1EPyBUaGVyZSBpcyBub25lLg0KW0pveV1JdCBk b2VzIGV4aXN0ICI2LjEwLjUuICBGb3J3YXJkaW5nIFJ1bGVzIg0KPiANCj4gMTAuIFNlYyAzLjUu MiBzdGF0ZXM6DQo+ICAgICAiSW4gb3JkZXIgdG8gcmVjZWl2ZQ0KPiAgICAgICB0aG9zZSBwYWNr ZXRzLCB0aGUgTE1BIE1VU1QgYWR2ZXJ0aXNlIGEgY29ubmVjdGVkIHJvdXRlIGludG8gdGhlDQo+ ICAgICAgIHJvdXRpbmcgaW5mcmFzdHJ1Y3R1cmUgZm9yIHRoZSBNUidzIE1OUChzKS4iDQo+IA0K PiAgICAgLSBJcyBpdCBlbm91Z2ggZnJvbSBhIHNwZWNpZmljYXRpb24gc3RhbmRwb2ludCB0byBz dGF0ZSB0aGF0IHRoZQ0KPiAgICAgICByb3V0ZXMgbmVlZCB0byBiZSBpbmplY3RlZCBpbnRvIHRo ZSByb3V0aW5nIGluZnJhPw0KPiAgICAgICBIYW5kd2F2aW5nPz8/Pw0KW0pveV1Gcm9tIHRoZSBy b3V0aW5nIHBlcnNwZWN0aXZlLCBJIGFtIG5vdCBzdXJlIHdoYXQgZWxzZSBuZWVkcyB0byBiZSAN CnNwZWNpZmllZC4gQ2FuIHlvdSBnaXZlIGFub3RoZXIgcHJvcG9zYWw/DQo+IA0KPiAxMS4gQXJl IHRoZXJlIGFueSBuZXcgdGhyZWF0cyBvciBzZWN1cml0eSBpc3N1ZXMgdGhhdCBhcmlzZSBmcm9t DQo+ICAgICBhc3NpZ25pbmcgcHJlZml4ZXMgdG8gYmUgZGVsZWdhdGVkIGRvd25zdHJlYW0gaW4g dGhlIGNhc2Ugb2YNCj4gICAgIFBNSVA2PyBTZWN1cml0eSBzZWN0aW9uIHNlZW1zIHByZXR0eSBs aWdodC4NCltKb3ldV2Ugd2lsbCBzZWFyY2ggZm9yIHBvc3NpYmxlIHRleHQgZm9yIHRoaXMgaW4g dGhlIGZ1dHVyZSBkaXNjdXNzaW9uLg0KDQpKb3kNCj4gDQo+IA0KPiAtUmFqDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRleHQgbWFp bGluZyBsaXN0DQo+IG5ldGV4dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGV4dA0KPiANCg0K --=_alternative 0044C66D48257944_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJhaiw8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4g UGxlYXNlIHNlZQ0KYmVsb3cgaW5saW5lLjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPm5ldGV4dC1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMS0xMS0wOCDJz87nIDA0OjE3OjUy Ojxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBBIGZldyBxdWljayBjb21tZW50czo8YnI+DQom Z3Q7IDxicj4NCiZndDsgMS4gQWJzdHJhY3Qgc2hvdWxkIGhhdmUgbm8gcmVmZXJlbmNlcy4gQW5k IHRoZSBkZXNjcmlwdGlvbiBjYW4gYmU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtpbXByb3ZlZC4g SXQgcmVhbGx5IGlzIGhhcmQgdG8gdW5kZXJzdGFuZCB3aGF0IHRoaXMgSS1EDQppcyB0cnlpbmc8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt0byBhY2NvbXBsaXNoLiA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgMi4gVGhlIGludHJvZHVjdGlvbiBzZWN0aW9uIGNhbiBiZSBpbXByb3ZlZC4gTWF5YmUgeW91 IHNob3VsZCBpbmNsdWRlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7YSBwcm9ibGVtIHN0YXRlbWVu dCBzZWN0aW9uIHRvIGluZGljYXRlIHdoYXQgaXMgbGFja2luZw0KaW4gUE1JUDYgYXM8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDtwZXIgUkZDNTIxMy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPltKb3ldUmV3b3JkaW5nIHdpbGwgYmUgZG9uZSBmb3IgMSZhbXA7MiBpbiBuZXh0IHZl cnNpb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDMuIEluIFNlYyAzLjEgaXQgc3RhdGVzOjxicj4N CiZndDsgJnF1b3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7byAmbmJzcDtUaGUgTVIgKGFzIGEg UlIpIE1VU1QgZWl0aGVyIG9idGFpbiB0aGUgSG9tZQ0KTmV0d29yayBQcmVmaXggKEhOUCk8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJlZm9yZSBpbml0aWF0aW5nIHRoZSBESENQdjYt UEQgcHJvY2VkdXJlIG9yDQppbiBjYXNlIG9mIHN0YXRlZnVsPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBhZGRyZXNzIGNvbmZpZ3VyYXRpb24gc2ltdWx0YW5lb3VzbHkgd2hpbGUgY29u ZmlndXJpbmcNCnRoZSBNb2JpbGU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE5vZGUg SG9tZSBBZGRyZXNzIChNTi1Ib0EpLjxicj4NCiZndDsgJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDtTbyBkb2VzIHRoaXMgaW1wbHkgdGhhdCB0aGUgTVIgKFBNSVA2IE1O KSBvYnRhaW5zIGFuDQpITlAgYXMgcGVyPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7UkZDNTIxMyBm b3IgaXRzIG93biB1c2UgcHJpb3IgdG8gdGhlIE1SIHJlcXVlc3RpbmcgdmlhDQpESENQdjY8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDthbm90aGVyIHNldCBvZiBwcmVmaXhlcyB0byBiZSB1c2VkIGZv ciBkZWxlZ2F0aW5nIHRvDQpkb3duc3RyZWFtPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7bm9kZXM/ IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+W0pveV1ZZXMuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDQuIElmIHRoZSBwcmVmaXhlcyAoZGVsZWdhdGVkKSBhcmUgcHJvdmlkZWQgYnkg YSBESENQIHNlcnZlciAoYW5kDQpub3Q8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDt0aGUgTE1BKSwg aG93IGRvZXMgdGhlIExNQSBnZXQgaW5mb3JtZWQgYWJvdXQgdGhlc2U/DQpJbiB0aGUgUEJVPzxi cj4NCiZndDsgJm5ic3A7ICZuYnNwO0hvdyBkbyB5b3UgZW5zdXJlIHRoYXQ8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsmcXVvdDtBbGwgdGhlIG1vYmlsZSBuZXR3b3JrIHByZWZpeGVzIG1hbmFnZWQg aW4gdGhlDQpEUiBNVVNUIGJlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7cmVhY2hhYmxlIHZpYSBs b2NhbCBtb2JpbGl0eSBhbmNob3IgKExNQSkmcXVvdDsgd2hlbg0KdGhleSBhcmUgbm90PGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7YXNzaWduZWQgYnkgdGhlIExNQT88L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPltKb3ldSGVyZSBpdCBhc3N1bWVzIHRoYXQgdGhlIExNQSBjYW4gaW50 ZXJhY3Qgd2l0aA0KdGhlIERIQ1B2NiBTZXJ2ZXIgd2l0aGluIHNvbWUgb3RoZXIgbWVjaGFuaXNt cyBlLmcuIFJhZGl1cy48YnI+DQomZ3Q7IDxicj4NCiZndDsgNS4gU2VjIDMuMSBhbHNvIHN0YXRl czo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsmcXVvdDtUaGUgZGVsZWdhdGluZyByb3V0ZXIgKERS KSBjYW4gYmUgbG9jYXRlZCBlaXRoZXINCmF0IExNQSBvciBzb21lPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBvdGhlciBkZXZpY2UgaW4gdGhlIFBNSVB2NiBkb21haW4mcXVvdDs8YnI+ DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBXaGF0IGlzIHRoaXMgc29tZSBvdGhlciBk ZXZpY2U/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bSm95XUhlcmUgd2UganVz dCBzdHVkeSB0aGVzZSB0d28ga2luZHMgb2YgZGVwbG95bWVudHMNCndoaWNoIGFyZSBjb21tb24g aW4gY3VycmVudCBuZXR3b3JrLjxicj4NCiZndDsgPGJyPg0KJmd0OyA2LiAmbmJzcDtJbiBTZWMg My4yIHRoZSBJLUQgc3RhdGVzIHRoYXQgdGhlIHByb2ZpbGUgbmVlZHMgdG8gaW5kaWNhdGU8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgd2hldGhlciBhbiBNTiBjYW4gYmUgYXNzaWduZWQgcHJlZml4 ZXMgZm9yIGRlbGVnYXRpb24uDQpEb2VzIHRoZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBwcm9m aWxlIGluZGljYXRlIHdoZXRoZXIgdGhlIGhvc3QgaXMgYSBtb2JpbGUgcm91dGVyPw0KSXMgdGhp czxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBuZWVkZWQ/IEFueSBNTiBzaG91bGQgYmUgYWJsZSB0 byBhY3QgYXMgYW4gTVIuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bSm95XU1O IGlzIGFibGUgdG8gYWN0IGFzIGFuIE1SIGRvZXMgbm90IG1lYW4gaXQgY2FuDQpvYnRhaW4gbW9i aWxlIG5ldHdvcmsgcHJlZml4LiBVc3VhbGx5IHdoZXRoZXIgdGhlIG1vYmlsZSBuZXR3b3JrIHBy ZWZpeA0KaXMgYWxsb3dlZCBkZXBlbmRzIG9uIHRoZSBwcm9maWxlLjxicj4NCiZndDsgPGJyPg0K Jmd0OyA3LiBJbiBGaWcgMSwgeW91IGhhdmUgYSBEUiBzaG93biB0aGVyZS4gSG93IGRvZXMgdGhl IERSIGluZGljYXRlIHRoZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2Fzc2lnbmVkIHByZWZpeGVz IHRvIHRoZSBMTUE/PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7LSBTdGVwIDUgc2VlbXMgZGlzY29u bmVjdGVkIGZyb20gdGhlIHJlc3Qgb2YgdGhlIHByb2Nlc3MuDQpNYXliZSBpdDxicj4NCiZndDsg Jm5ic3A7ICZuYnNwO2lzIGJldHRlciB0byBzcGxpdCB0aGF0IGFzcGVjdCBhbmQgc2hvdyBpdCBp biBhbm90aGVyDQpmaWd1cmUuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bSm95 XUFzIEkgc2F5IGluIFE0LiBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lbnRpb24NCm9mIHRoZSBz dGVwIDUuIEl0IGlzIGp1c3QgcmVsYXllZCBieSB0aGUgTUFHLjxicj4NCiZndDsgPGJyPg0KJmd0 OyA4LiBEb2VzIHRoZSBsaWZldGltZSBvZiB0aGUgZGVsZWdhdGVkIHByZWZpeCAoYXNzaWduZWQg YnkgYSBEUikgdGhlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7c2FtZSBhcyB0aGUgbGlmZXRpbWUg YXNzaWduZWQgYnkgdGhlIExNQT88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPltK b3ldWWVzLjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1doeSBub3QgaGF2ZSBTZWMgMy4zLjMgdG8g ZGVzY3JpYmUgaG93IGEgcHJlZml4IGlzIHJldm9rZWQNCm9yPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7ZGVsZXRlZD8gVGV4dCBpcyBjdXJyZW50bHkgaW4gMy4zLjIuPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5bSm95XVRoaXMgaXMgYSBnb29kIHByb3Bvc2FsLjxicj4NCiZndDsg PGJyPg0KJmd0OyA5LiBJbiBzZWMgMy40LjI6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7JnF1b3Q7 T3RoZXIgY29uc2lkZXJhdGlvbnMgZnJvbSBTZWN0aW9uIDYuMTAuNSBvciBbUkZDNTIxM10mcXVv dDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1NlYyA2LjEwLjUgb2YgdGhpcyBJ LUQ/IFRoZXJlIGlzIG5vbmUuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bSm95 XUl0IGRvZXMgZXhpc3QgJnF1b3Q7PGk+Ni4xMC41LiAmbmJzcDtGb3J3YXJkaW5nDQpSdWxlczwv aT4mcXVvdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgMTAuIFNlYyAzLjUuMiBzdGF0ZXM6PGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7ICZxdW90O0luIG9yZGVyIHRvIHJlY2VpdmU8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHRob3NlIHBhY2tldHMsIHRoZSBMTUEgTVVTVCBhZHZlcnRpc2Ug YSBjb25uZWN0ZWQNCnJvdXRlIGludG8gdGhlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyByb3V0aW5nIGluZnJhc3RydWN0dXJlIGZvciB0aGUgTVIncyBNTlAocykuJnF1b3Q7PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgLSBJcyBpdCBlbm91Z2ggZnJvbSBhIHNwZWNp ZmljYXRpb24gc3RhbmRwb2ludCB0byBzdGF0ZQ0KdGhhdCB0aGU8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHJvdXRlcyBuZWVkIHRvIGJlIGluamVjdGVkIGludG8gdGhlIHJvdXRpbmcg aW5mcmE/PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBIYW5kd2F2aW5nPz8/PzwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+W0pveV1Gcm9tIHRoZSByb3V0aW5nIHBlcnNw ZWN0aXZlLCBJIGFtIG5vdCBzdXJlIHdoYXQNCmVsc2UgbmVlZHMgdG8gYmUgc3BlY2lmaWVkLiBD YW4geW91IGdpdmUgYW5vdGhlciBwcm9wb3NhbD88YnI+DQomZ3Q7IDxicj4NCiZndDsgMTEuIEFy ZSB0aGVyZSBhbnkgbmV3IHRocmVhdHMgb3Igc2VjdXJpdHkgaXNzdWVzIHRoYXQgYXJpc2UgZnJv bTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBhc3NpZ25pbmcgcHJlZml4ZXMgdG8gYmUgZGVsZWdh dGVkIGRvd25zdHJlYW0gaW4gdGhlDQpjYXNlIG9mPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFBN SVA2PyBTZWN1cml0eSBzZWN0aW9uIHNlZW1zIHByZXR0eSBsaWdodC48L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPltKb3ldV2Ugd2lsbCBzZWFyY2ggZm9yIHBvc3NpYmxlIHRleHQg Zm9yIHRoaXMgaW4NCnRoZSBmdXR1cmUgZGlzY3Vzc2lvbi48L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPkpveTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC1S YWo8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7IG5ldGV4dCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IG5l dGV4dEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRleHQ8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0K --=_alternative 0044C66D48257944_=-- From jouni.nospam@gmail.com Thu Nov 10 12:21:32 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D9521F8485; Thu, 10 Nov 2011 12:21:32 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo21GelTRet9; Thu, 10 Nov 2011 12:21:32 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AAA8221F8482; Thu, 10 Nov 2011 12:21:31 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so3311442bkb.31 for ; Thu, 10 Nov 2011 12:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=yTcqpc2i7dQJRrWWuWrMs5/U0DPytHhcVFSAhPHMoLE=; b=kQ0OSJjS/XRDh8G8uiSp48yYyzVS4fjlPdxNrsK0qFNopULzWxUV4aqtysauqi1wfh 9791N9SglAxs0tG32amE1Aut4/Ij3kUwtv4kZTHXXHuYYQwhpSSPu1hkezMLrYQOYIxe DVWy8tjTmlTox9FGbpQk5UMiUuqJwIFc3o7dA= Received: by 10.204.152.25 with SMTP id e25mr6167604bkw.51.1320956490735; Thu, 10 Nov 2011 12:21:30 -0800 (PST) Received: from [62.237.209.70] ([62.237.209.70]) by mx.google.com with ESMTPS id r12sm8549570bkw.5.2011.11.10.12.21.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Nov 2011 12:21:28 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 10 Nov 2011 22:21:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23E4A915-9B63-4EA8-814A-C442EE007A1B@gmail.com> References: To: zhou.xingyue@zte.com.cn, " Patil" X-Mailer: Apple Mail (2.1084) Cc: netext@ietf.org, draft-ietf-netext-pd-pmip@tools.ietf.org, netext-bounces@ietf.org Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 20:21:32 -0000 Raj, On Nov 10, 2011, at 2:30 PM, zhou.xingyue@zte.com.cn wrote: > > 4. If the prefixes (delegated) are provided by a DHCP server (and = not > > the LMA), how does the LMA get informed about these? In the PBU? > > How do you ensure that > > "All the mobile network prefixes managed in the DR MUST be > > reachable via local mobility anchor (LMA)" when they are not > > assigned by the LMA?=20 > [Joy]Here it assumes that the LMA can interact with the DHCPv6 Server = within some other mechanisms e.g. Radius. The situation is the same as with PMIP6 and DHCPv6 in general. The = DHCPv6 server and the LMA has to be in sync. There is no need for an = interface as everything can be managed with configuration. But that does = not preclude having an interface between the LMA and the DHCPv6 server. - Jouni From Basavaraj.Patil@nokia.com Thu Nov 10 12:30:18 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D402921F8B03; Thu, 10 Nov 2011 12:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hD1xbHdy1ApU; Thu, 10 Nov 2011 12:30:18 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 41C9321F8ACE; Thu, 10 Nov 2011 12:30:18 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAAKUFQY028208; Thu, 10 Nov 2011 22:30:15 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 22:30:01 +0200 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0339.002; Thu, 10 Nov 2011 21:30:00 +0100 From: To: , Thread-Topic: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 Thread-Index: AQHMnYpTGqYa7OGEukONGJ+vApALIZWl/ViAgACDXYD//53lgA== Date: Thu, 10 Nov 2011 20:29:59 +0000 Message-ID: In-Reply-To: <23E4A915-9B63-4EA8-814A-C442EE007A1B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.138] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Nov 2011 20:30:01.0350 (UTC) FILETIME=[8588D260:01CC9FE7] X-Nokia-AV: Clean Cc: netext@ietf.org, draft-ietf-netext-pd-pmip@tools.ietf.org, netext-bounces@ietf.org Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 20:30:18 -0000 Inline: On 11/10/11 2:21 PM, "ext jouni korhonen" wrote: >Raj, > >On Nov 10, 2011, at 2:30 PM, zhou.xingyue@zte.com.cn wrote: > >> > 4. If the prefixes (delegated) are provided by a DHCP server (and not >> > the LMA), how does the LMA get informed about these? In the PBU? >> > How do you ensure that >> > "All the mobile network prefixes managed in the DR MUST be >> > reachable via local mobility anchor (LMA)" when they are not >> > assigned by the LMA? >> [Joy]Here it assumes that the LMA can interact with the DHCPv6 Server >>within some other mechanisms e.g. Radius. > >The situation is the same as with PMIP6 and DHCPv6 in general. The DHCPv6 >server and the LMA has to be in sync. There is no need for an interface >as everything can be managed with configuration. But that does not >preclude having an interface between the LMA and the DHCPv6 server. How do you keep the DHCPv6 server and the LMA in sync? Is it considered out-of-scope and the actual method about how they are synced not specified? If the DHCPv6 server and LMA are co-located, it could be easier. If they are not, then it may be an issue. The argument that you can use a Radius type interface between DHCPv6 server and the LMA is not good enough. Is there such a specification? The Netext WG has only specified the RADIUS interactions between a AAA server and the MAG/LMA entities. -Raj > >- Jouni > > > From sgundave@cisco.com Thu Nov 10 12:36:13 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02C221F8B78; Thu, 10 Nov 2011 12:36:13 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSzjecmTaIm0; Thu, 10 Nov 2011 12:36:13 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CCAF521F8B76; Thu, 10 Nov 2011 12:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1964; q=dns/txt; s=iport; t=1320957372; x=1322166972; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=93qmzh/7d51E+hbuO/XFHPEXL2mP2TcVouIJy73FKjg=; b=U82EfzkUuaHvmN3eKG5k9ziwaTYuJ7o4fRVcx7Qd7JkGvp8P/7B+GUDZ NVXf3bG0PCy20VcBM18tsRVAGBLwrQQ/BQv5ZU/QuqWkpUbH4XmqiOZ6X Si9Fex5WZLRIx1wxXwFyZ4+ahcSlRUSEekbSFbuM78IkMlfQ2XxGMlUCP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFU1vE6rRDoI/2dsb2JhbABEqiyBBYFyAQEBAwEBAQEPAScCATELEgEIGE8GMAIEAQ0FIodgCJkeAZ5YBIl+BIgPjBmFQYUGh04 X-IronPort-AV: E=Sophos;i="4.69,490,1315180800"; d="scan'208";a="13524901" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 10 Nov 2011 20:36:12 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAAKaCoS020116; Thu, 10 Nov 2011 20:36:12 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 12:36:12 -0800 Received: from 10.21.148.189 ([10.21.148.189]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 Nov 2011 20:36:12 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Thu, 10 Nov 2011 12:36:10 -0700 From: Sri Gundavelli To: , , Message-ID: Thread-Topic: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 Thread-Index: AQHMnYpTGqYa7OGEukONGJ+vApALIZWl/ViAgACDXYD//53lgIAAdxN5 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Nov 2011 20:36:12.0576 (UTC) FILETIME=[62CD6A00:01CC9FE8] Cc: netext@ietf.org, draft-ietf-netext-pd-pmip@tools.ietf.org, netext-bounces@ietf.org Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 20:36:13 -0000 I agree. I think we should simply assume the DHCPv6 server and the LMA are collocated. For the split case, we loosely specify the assumptions and the interface should be out of scope. Sri On 11/10/11 1:29 PM, "Basavaraj.Patil@nokia.com" wrote: > > Inline: > > On 11/10/11 2:21 PM, "ext jouni korhonen" wrote: > >> Raj, >> >> On Nov 10, 2011, at 2:30 PM, zhou.xingyue@zte.com.cn wrote: >> >>>> 4. If the prefixes (delegated) are provided by a DHCP server (and not >>>> the LMA), how does the LMA get informed about these? In the PBU? >>>> How do you ensure that >>>> "All the mobile network prefixes managed in the DR MUST be >>>> reachable via local mobility anchor (LMA)" when they are not >>>> assigned by the LMA? >>> [Joy]Here it assumes that the LMA can interact with the DHCPv6 Server >>> within some other mechanisms e.g. Radius. >> >> The situation is the same as with PMIP6 and DHCPv6 in general. The DHCPv6 >> server and the LMA has to be in sync. There is no need for an interface >> as everything can be managed with configuration. But that does not >> preclude having an interface between the LMA and the DHCPv6 server. > > How do you keep the DHCPv6 server and the LMA in sync? Is it considered > out-of-scope and the actual method about how they are synced not > specified? If the DHCPv6 server and LMA are co-located, it could be > easier. If they are not, then it may be an issue. The argument that you > can use a Radius type interface between DHCPv6 server and the LMA is not > good enough. Is there such a specification? The Netext WG has only > specified the RADIUS interactions between a AAA server and the MAG/LMA > entities. > > -Raj > >> >> - Jouni >> >> >> > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Thu Nov 10 12:45:01 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9F121F8AB9; Thu, 10 Nov 2011 12:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.544 X-Spam-Level: X-Spam-Status: No, score=-100.544 tagged_above=-999 required=5 tests=[AWL=-2.148, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZ9DJ4BMs8YK; Thu, 10 Nov 2011 12:45:00 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id EA7B521F88B7; Thu, 10 Nov 2011 12:44:43 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAAKif9k009422; Thu, 10 Nov 2011 22:44:42 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 22:44:41 +0200 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0339.002; Thu, 10 Nov 2011 21:44:40 +0100 From: To: Thread-Topic: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 Thread-Index: AQHMnYpTGqYa7OGEukONGJ+vApALIZWl/ViAgACJ9AA= Date: Thu, 10 Nov 2011 20:44:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.59.138] Content-Type: text/plain; charset="gb2312" Content-ID: <5E6BAC17A4D8B542AD256E7EAA104019@mgd.nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 10 Nov 2011 20:44:41.0546 (UTC) FILETIME=[922C12A0:01CC9FE9] X-Nokia-AV: Clean Cc: netext@ietf.org, draft-ietf-netext-pd-pmip@tools.ietf.org, netext-bounces@ietf.org Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 20:45:01 -0000 DQpJbmxpbmU6DQoNCk9uIE5vdiAxMCwgMjAxMSwgYXQgNjozMCBBTSwgZXh0IHpob3UueGluZ3l1 ZUB6dGUuY29tLmNuIHdyb3RlOg0KDQo+IA0KPiBIaSBSYWosIA0KPiBUaGFua3MgZm9yIHlvdXIg Y29tbWVudHMuIFBsZWFzZSBzZWUgYmVsb3cgaW5saW5lLiANCj4gDQo+IG5ldGV4dC1ib3VuY2Vz QGlldGYub3JnINC009ogMjAxMS0xMS0wOCDJz87nIDA0OjE3OjUyOg0KPiANCj4gPiANCj4gPiBB IGZldyBxdWljayBjb21tZW50czoNCj4gPiANCj4gPiAxLiBBYnN0cmFjdCBzaG91bGQgaGF2ZSBu byByZWZlcmVuY2VzLiBBbmQgdGhlIGRlc2NyaXB0aW9uIGNhbiBiZQ0KPiA+ICAgIGltcHJvdmVk LiBJdCByZWFsbHkgaXMgaGFyZCB0byB1bmRlcnN0YW5kIHdoYXQgdGhpcyBJLUQgaXMgdHJ5aW5n DQo+ID4gICAgdG8gYWNjb21wbGlzaC4gDQo+ID4gDQo+ID4gMi4gVGhlIGludHJvZHVjdGlvbiBz ZWN0aW9uIGNhbiBiZSBpbXByb3ZlZC4gTWF5YmUgeW91IHNob3VsZCBpbmNsdWRlDQo+ID4gICAg YSBwcm9ibGVtIHN0YXRlbWVudCBzZWN0aW9uIHRvIGluZGljYXRlIHdoYXQgaXMgbGFja2luZyBp biBQTUlQNiBhcw0KPiA+ICAgIHBlciBSRkM1MjEzLiANCj4gW0pveV1SZXdvcmRpbmcgd2lsbCBi ZSBkb25lIGZvciAxJjIgaW4gbmV4dCB2ZXJzaW9uLg0KDQpHb29kLg0KDQo+ID4gDQo+ID4gMy4g SW4gU2VjIDMuMSBpdCBzdGF0ZXM6DQo+ID4gIg0KPiA+ICAgIG8gIFRoZSBNUiAoYXMgYSBSUikg TVVTVCBlaXRoZXIgb2J0YWluIHRoZSBIb21lIE5ldHdvcmsgUHJlZml4IChITlApDQo+ID4gICAg ICAgYmVmb3JlIGluaXRpYXRpbmcgdGhlIERIQ1B2Ni1QRCBwcm9jZWR1cmUgb3IgaW4gY2FzZSBv ZiBzdGF0ZWZ1bA0KPiA+ICAgICAgIGFkZHJlc3MgY29uZmlndXJhdGlvbiBzaW11bHRhbmVvdXNs eSB3aGlsZSBjb25maWd1cmluZyB0aGUgTW9iaWxlDQo+ID4gICAgICAgTm9kZSBIb21lIEFkZHJl c3MgKE1OLUhvQSkuDQo+ID4gIg0KPiA+IA0KPiA+ICAgIFNvIGRvZXMgdGhpcyBpbXBseSB0aGF0 IHRoZSBNUiAoUE1JUDYgTU4pIG9idGFpbnMgYW4gSE5QIGFzIHBlcg0KPiA+ICAgIFJGQzUyMTMg Zm9yIGl0cyBvd24gdXNlIHByaW9yIHRvIHRoZSBNUiByZXF1ZXN0aW5nIHZpYSBESENQdjYNCj4g PiAgICBhbm90aGVyIHNldCBvZiBwcmVmaXhlcyB0byBiZSB1c2VkIGZvciBkZWxlZ2F0aW5nIHRv IGRvd25zdHJlYW0NCj4gPiAgICBub2Rlcz8gDQo+IFtKb3ldWWVzLg0KDQpTb21lIHRleHQgY2xh cmlmeWluZyB0aGlzIHdvdWxkIGJlIHVzZWZ1bCBpbiB0aGUgZG9jdW1lbnQuDQoNCj4gPiANCj4g PiA0LiBJZiB0aGUgcHJlZml4ZXMgKGRlbGVnYXRlZCkgYXJlIHByb3ZpZGVkIGJ5IGEgREhDUCBz ZXJ2ZXIgKGFuZCBub3QNCj4gPiAgICB0aGUgTE1BKSwgaG93IGRvZXMgdGhlIExNQSBnZXQgaW5m b3JtZWQgYWJvdXQgdGhlc2U/IEluIHRoZSBQQlU/DQo+ID4gICAgSG93IGRvIHlvdSBlbnN1cmUg dGhhdA0KPiA+ICAgICJBbGwgdGhlIG1vYmlsZSBuZXR3b3JrIHByZWZpeGVzIG1hbmFnZWQgaW4g dGhlIERSIE1VU1QgYmUNCj4gPiAgICByZWFjaGFibGUgdmlhIGxvY2FsIG1vYmlsaXR5IGFuY2hv ciAoTE1BKSIgd2hlbiB0aGV5IGFyZSBub3QNCj4gPiAgICBhc3NpZ25lZCBieSB0aGUgTE1BPyAN Cj4gW0pveV1IZXJlIGl0IGFzc3VtZXMgdGhhdCB0aGUgTE1BIGNhbiBpbnRlcmFjdCB3aXRoIHRo ZSBESENQdjYgU2VydmVyIHdpdGhpbiBzb21lIG90aGVyIG1lY2hhbmlzbXMgZS5nLiBSYWRpdXMu DQoNClRoaXMgaXMgYW4gYXNzdW1wdGlvbi4gU2VlIG15IHJlc3BvbnNlIHRvIEpvdW5pLg0KDQo+ ID4gDQo+ID4gNS4gU2VjIDMuMSBhbHNvIHN0YXRlczoNCj4gPiAgICAiVGhlIGRlbGVnYXRpbmcg cm91dGVyIChEUikgY2FuIGJlIGxvY2F0ZWQgZWl0aGVyIGF0IExNQSBvciBzb21lDQo+ID4gICAg ICAgb3RoZXIgZGV2aWNlIGluIHRoZSBQTUlQdjYgZG9tYWluIg0KPiA+IA0KPiA+ICAgICBXaGF0 IGlzIHRoaXMgc29tZSBvdGhlciBkZXZpY2U/IA0KPiBbSm95XUhlcmUgd2UganVzdCBzdHVkeSB0 aGVzZSB0d28ga2luZHMgb2YgZGVwbG95bWVudHMgd2hpY2ggYXJlIGNvbW1vbiBpbiBjdXJyZW50 IG5ldHdvcmsuDQoNCllvdSBtZWFuIHRoZSBzb21lIG90aGVyIGRldmljZSBpcyB0aGUgTE1BPyBX aGF0IGlzIHRoaXMgInNvbWUgb3RoZXIgZGV2aWNlIiB0aGF0IHlvdSByZWZlciB0byBpbiB0aGUg dGV4dC4NCkFuZCB3aGF0IGFyZSB0aGVzZSB0d28ga2luZHMgb2YgZGVwbG95bWVudHMuIFlvdXIg cmVzcG9uc2UgZGlkIG5vdCBwcm92aWRlIGFuIGFuc3dlciBoZXJlLg0KDQo+ID4gDQo+ID4gNi4g IEluIFNlYyAzLjIgdGhlIEktRCBzdGF0ZXMgdGhhdCB0aGUgcHJvZmlsZSBuZWVkcyB0byBpbmRp Y2F0ZQ0KPiA+ICAgICB3aGV0aGVyIGFuIE1OIGNhbiBiZSBhc3NpZ25lZCBwcmVmaXhlcyBmb3Ig ZGVsZWdhdGlvbi4gRG9lcyB0aGUNCj4gPiAgICAgcHJvZmlsZSBpbmRpY2F0ZSB3aGV0aGVyIHRo ZSBob3N0IGlzIGEgbW9iaWxlIHJvdXRlcj8gSXMgdGhpcw0KPiA+ICAgICBuZWVkZWQ/IEFueSBN TiBzaG91bGQgYmUgYWJsZSB0byBhY3QgYXMgYW4gTVIuIA0KPiBbSm95XU1OIGlzIGFibGUgdG8g YWN0IGFzIGFuIE1SIGRvZXMgbm90IG1lYW4gaXQgY2FuIG9idGFpbiBtb2JpbGUgbmV0d29yayBw cmVmaXguIFVzdWFsbHkgd2hldGhlciB0aGUgbW9iaWxlIG5ldHdvcmsgcHJlZml4IGlzIGFsbG93 ZWQgZGVwZW5kcyBvbiB0aGUgcHJvZmlsZS4NCg0KQWdyZWUuIEJ1dCBhbiBNTiBjYW4gYWxzbyBi ZWhhdmUgYXMgYSBNUi4gV2hldGhlciBpdCBjYW4gYmUgYWxsb2NhdGVkIHByZWZpeGVzIGZvciBk ZWxlZ2F0aW9uIGRlcGVuZHMgb24gdGhlIHByb2ZpbGUuIFNvIG15IHBvaW50IGlzIHRoYXQgdGhl IHRleHQgc2hvdWxkIG5vdCBkaWZmZXJlbnRpYXRlIGJldHdlZW4gYW4gTU4gYW5kIE1SLg0KDQo+ ID4gDQo+ID4gNy4gSW4gRmlnIDEsIHlvdSBoYXZlIGEgRFIgc2hvd24gdGhlcmUuIEhvdyBkb2Vz IHRoZSBEUiBpbmRpY2F0ZSB0aGUNCj4gPiAgICBhc3NpZ25lZCBwcmVmaXhlcyB0byB0aGUgTE1B Pw0KPiA+ICAgIC0gU3RlcCA1IHNlZW1zIGRpc2Nvbm5lY3RlZCBmcm9tIHRoZSByZXN0IG9mIHRo ZSBwcm9jZXNzLiBNYXliZSBpdA0KPiA+ICAgIGlzIGJldHRlciB0byBzcGxpdCB0aGF0IGFzcGVj dCBhbmQgc2hvdyBpdCBpbiBhbm90aGVyIGZpZ3VyZS4gDQo+IFtKb3ldQXMgSSBzYXkgaW4gUTQu IEkgYW0gbm90IHN1cmUgd2hhdCB5b3UgbWVudGlvbiBvZiB0aGUgc3RlcCA1LiBJdCBpcyBqdXN0 IHJlbGF5ZWQgYnkgdGhlIE1BRy4NCg0KTGV0cyBkaXNjdXNzIGF0IHRoZSBXRyBtZWV0aW5nIG5l eHQgd2Vlay4NCg0KPiA+IA0KPiA+IDguIERvZXMgdGhlIGxpZmV0aW1lIG9mIHRoZSBkZWxlZ2F0 ZWQgcHJlZml4IChhc3NpZ25lZCBieSBhIERSKSB0aGUNCj4gPiAgICBzYW1lIGFzIHRoZSBsaWZl dGltZSBhc3NpZ25lZCBieSB0aGUgTE1BPyANCj4gW0pveV1ZZXMuDQoNCkhvdyBkbyB5b3UgZW5z dXJlIGl0IGlmIHRoZSBkZWxlZ2F0ZWQgcHJlZml4ZXMgYXJlIGFzc2lnbmVkIGJ5IHRoZSBESENQ djYgc2VydmVyIGFuZCB0aGUgTE1BIGNob29zZXMgdG8gYXNzaWduIGEgZGlmZmVyZW50IGxpZmV0 aW1lIGluIHRoZSBQQkEuDQoNCj4gPiAgICBXaHkgbm90IGhhdmUgU2VjIDMuMy4zIHRvIGRlc2Ny aWJlIGhvdyBhIHByZWZpeCBpcyByZXZva2VkIG9yDQo+ID4gICAgZGVsZXRlZD8gVGV4dCBpcyBj dXJyZW50bHkgaW4gMy4zLjIuIA0KPiBbSm95XVRoaXMgaXMgYSBnb29kIHByb3Bvc2FsLg0KPiA+ IA0KPiA+IDkuIEluIHNlYyAzLjQuMjoNCj4gPiAgICAiT3RoZXIgY29uc2lkZXJhdGlvbnMgZnJv bSBTZWN0aW9uIDYuMTAuNSBvciBbUkZDNTIxM10iDQo+ID4gDQo+ID4gICAgU2VjIDYuMTAuNSBv ZiB0aGlzIEktRD8gVGhlcmUgaXMgbm9uZS4gDQo+IFtKb3ldSXQgZG9lcyBleGlzdCAiNi4xMC41 LiAgRm9yd2FyZGluZyBSdWxlcyINCg0KQ2hhbmdlIHRoZSBPciB0byBPZiBpbiB0aGUgc2VudGVu Y2UuIFRoYXQgaXMgdGhlIHByb2JsZW0uIA0KDQo+ID4gDQo+ID4gMTAuIFNlYyAzLjUuMiBzdGF0 ZXM6DQo+ID4gICAgICJJbiBvcmRlciB0byByZWNlaXZlDQo+ID4gICAgICAgdGhvc2UgcGFja2V0 cywgdGhlIExNQSBNVVNUIGFkdmVydGlzZSBhIGNvbm5lY3RlZCByb3V0ZSBpbnRvIHRoZQ0KPiA+ ICAgICAgIHJvdXRpbmcgaW5mcmFzdHJ1Y3R1cmUgZm9yIHRoZSBNUidzIE1OUChzKS4iDQo+ID4g DQo+ID4gICAgIC0gSXMgaXQgZW5vdWdoIGZyb20gYSBzcGVjaWZpY2F0aW9uIHN0YW5kcG9pbnQg dG8gc3RhdGUgdGhhdCB0aGUNCj4gPiAgICAgICByb3V0ZXMgbmVlZCB0byBiZSBpbmplY3RlZCBp bnRvIHRoZSByb3V0aW5nIGluZnJhPw0KPiA+ICAgICAgIEhhbmR3YXZpbmc/Pz8/IA0KPiBbSm95 XUZyb20gdGhlIHJvdXRpbmcgcGVyc3BlY3RpdmUsIEkgYW0gbm90IHN1cmUgd2hhdCBlbHNlIG5l ZWRzIHRvIGJlIHNwZWNpZmllZC4gQ2FuIHlvdSBnaXZlIGFub3RoZXIgcHJvcG9zYWw/DQoNCk15 IHBvaW50IGhlcmUgaXMgdGhhdCBpcyBpdCBwb3NzaWJsZSB0byBpbXBsZW1lbnQgdGhpcyBleHRl bnNpb24gYW5kIGRlcGxveSB0aGUgcHJvdG9jb2wgYmFzZWQgb24ganVzdCB0aGlzIGV4cGxhbmF0 aW9uIGFib3V0IHdoYXQgbmVlZHMgdG8gYmUgZG9uZSBieSB0aGUgTE1BIHcuci50IHRoZSByb3V0 aW5nIGluZnJhPw0KDQo+ID4gDQo+ID4gMTEuIEFyZSB0aGVyZSBhbnkgbmV3IHRocmVhdHMgb3Ig c2VjdXJpdHkgaXNzdWVzIHRoYXQgYXJpc2UgZnJvbQ0KPiA+ICAgICBhc3NpZ25pbmcgcHJlZml4 ZXMgdG8gYmUgZGVsZWdhdGVkIGRvd25zdHJlYW0gaW4gdGhlIGNhc2Ugb2YNCj4gPiAgICAgUE1J UDY/IFNlY3VyaXR5IHNlY3Rpb24gc2VlbXMgcHJldHR5IGxpZ2h0LiANCj4gW0pveV1XZSB3aWxs IHNlYXJjaCBmb3IgcG9zc2libGUgdGV4dCBmb3IgdGhpcyBpbiB0aGUgZnV0dXJlIGRpc2N1c3Np b24uIA0KDQpHb29kLg0KDQpUaHguDQotUmFqDQoNCj4gDQo+IEpveQ0KPiA+IA0KPiA+IA0KPiA+ IC1SYWoNCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IG5ldGV4dCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRleHRAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGV4dA0KPiA+IA0KDQo= From sarikaya2012@gmail.com Thu Nov 10 14:46:30 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4658F21F8880 for ; Thu, 10 Nov 2011 14:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icXzBpVPRJ+S for ; Thu, 10 Nov 2011 14:46:29 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D06321F861E for ; Thu, 10 Nov 2011 14:46:29 -0800 (PST) Received: by ywt34 with SMTP id 34so1550817ywt.31 for ; Thu, 10 Nov 2011 14:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fep87PkYoD/gTvuT3U/x1A1haS5puQ5oQ5unDVGUIMA=; b=l4fSuBt4noG8Ea+LutjTWGwZdPNpFEtpOQUXgnpv/AWUlL1Tc6A1SsHGgcKCvBW91m a0GUgGzLyukE6g1nl2LnwoVeQh6n3uKuuL8hH2WgMERgIYsBsGxShwJaeZNxoJjr4+YW mJpxpnxreUeUeuNZLTM4p7dNmWqL+yZ+tvyZQ= MIME-Version: 1.0 Received: by 10.146.159.5 with SMTP id h5mr4085032yae.1.1320965188926; Thu, 10 Nov 2011 14:46:28 -0800 (PST) Received: by 10.236.95.9 with HTTP; Thu, 10 Nov 2011 14:46:28 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Nov 2011 16:46:28 -0600 Message-ID: From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com Content-Type: multipart/alternative; boundary=000e0cd29e52d8bbc704b1692c5b Cc: netext@ietf.org, draft-ietf-netext-pd-pmip@tools.ietf.org Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 22:46:30 -0000 --000e0cd29e52d8bbc704b1692c5b Content-Type: text/plain; charset=ISO-8859-1 Hi Basavaraj, I have a question: Can we at Netext work on specs that require modifying MN? Reading the charter: The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). It seems to me the answer is no? Regards, Behcet On Mon, Nov 7, 2011 at 2:17 PM, wrote: > > A few quick comments: > > 1. Abstract should have no references. And the description can be > improved. It really is hard to understand what this I-D is trying > to accomplish. > > 2. The introduction section can be improved. Maybe you should include > a problem statement section to indicate what is lacking in PMIP6 as > per RFC5213. > > 3. In Sec 3.1 it states: > " > o The MR (as a RR) MUST either obtain the Home Network Prefix (HNP) > before initiating the DHCPv6-PD procedure or in case of stateful > address configuration simultaneously while configuring the Mobile > Node Home Address (MN-HoA). > " > > So does this imply that the MR (PMIP6 MN) obtains an HNP as per > RFC5213 for its own use prior to the MR requesting via DHCPv6 > another set of prefixes to be used for delegating to downstream > nodes? > > 4. If the prefixes (delegated) are provided by a DHCP server (and not > the LMA), how does the LMA get informed about these? In the PBU? > How do you ensure that > "All the mobile network prefixes managed in the DR MUST be > reachable via local mobility anchor (LMA)" when they are not > assigned by the LMA? > > 5. Sec 3.1 also states: > "The delegating router (DR) can be located either at LMA or some > other device in the PMIPv6 domain" > > What is this some other device? > > 6. In Sec 3.2 the I-D states that the profile needs to indicate > whether an MN can be assigned prefixes for delegation. Does the > profile indicate whether the host is a mobile router? Is this > needed? Any MN should be able to act as an MR. > > 7. In Fig 1, you have a DR shown there. How does the DR indicate the > assigned prefixes to the LMA? > - Step 5 seems disconnected from the rest of the process. Maybe it > is better to split that aspect and show it in another figure. > > 8. Does the lifetime of the delegated prefix (assigned by a DR) the > same as the lifetime assigned by the LMA? > Why not have Sec 3.3.3 to describe how a prefix is revoked or > deleted? Text is currently in 3.3.2. > > 9. In sec 3.4.2: > "Other considerations from Section 6.10.5 or [RFC5213]" > > Sec 6.10.5 of this I-D? There is none. > > 10. Sec 3.5.2 states: > "In order to receive > those packets, the LMA MUST advertise a connected route into the > routing infrastructure for the MR's MNP(s)." > > - Is it enough from a specification standpoint to state that the > routes need to be injected into the routing infra? > Handwaving???? > > 11. Are there any new threats or security issues that arise from > assigning prefixes to be delegated downstream in the case of > PMIP6? Security section seems pretty light. > > > -Raj > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > --000e0cd29e52d8bbc704b1692c5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Basavaraj,

I have a question:

Can we at Netext work on spe= cs that require modifying MN?

Reading the charter:
The work =
in this charter is entirely internal to the network and does
  not affect host IP stack operation in any way (except perhaps through
  impacting packet forwarding capacity visible to the hosts).

It s= eems to me the answer is no?

Regards,

Behcet
On Mon, Nov 7, 2011 at 2:17 PM, <Basavaraj.Patil@nokia.com> wrote:

A few quick comments:

1. Abstract should have no references. And the description can be
=A0 improved. It really is hard to understand what this I-D is trying
=A0 to accomplish.

2. The introduction section can be improved. Maybe you should include
=A0 a problem statement section to indicate what is lacking in PMIP6 as =A0 per RFC5213.

3. In Sec 3.1 it states:
"
=A0 o =A0The MR (as a RR) MUST either obtain the Home Network Prefix (HNP)=
=A0 =A0 =A0before initiating the DHCPv6-PD procedure or in case of statefu= l
=A0 =A0 =A0address configuration simultaneously while configuring the Mobi= le
=A0 =A0 =A0Node Home Address (MN-HoA).
"

=A0 So does this imply that the MR (PMIP6 MN) obtains an HNP as per
=A0 RFC5213 for its own use prior to the MR requesting via DHCPv6
=A0 another set of prefixes to be used for delegating to downstream
=A0 nodes?

4. If the prefixes (delegated) are provided by a DHCP server (and not
=A0 the LMA), how does the LMA get informed about these? In the PBU?
=A0 How do you ensure that
=A0 "All the mobile network prefixes managed in the DR MUST be
=A0 reachable via local mobility anchor (LMA)" when they are not
=A0 assigned by the LMA?

5. Sec 3.1 also states:
=A0 "The delegating router (DR) can be located either at LMA or some<= br> =A0 =A0 =A0other device in the PMIPv6 domain"

=A0 =A0What is this some other device?

6. =A0In Sec 3.2 the I-D states that the profile needs to indicate
=A0 =A0whether an MN can be assigned prefixes for delegation. Does the
=A0 =A0profile indicate whether the host is a mobile router? Is this
=A0 =A0needed? Any MN should be able to act as an MR.

7. In Fig 1, you have a DR shown there. How does the DR indicate the
=A0 assigned prefixes to the LMA?
=A0 - Step 5 seems disconnected from the rest of the process. Maybe it
=A0 is better to split that aspect and show it in another figure.

8. Does the lifetime of the delegated prefix (assigned by a DR) the
=A0 same as the lifetime assigned by the LMA?
=A0 Why not have Sec 3.3.3 to describe how a prefix is revoked or
=A0 deleted? Text is currently in 3.3.2.

9. In sec 3.4.2:
=A0 "Other considerations from Section 6.10.5 or [RFC5213]"

=A0 Sec 6.10.5 of this I-D? There is none.

10. Sec 3.5.2 states:
=A0 =A0"In order to receive
=A0 =A0 =A0those packets, the LMA MUST advertise a connected route into th= e
=A0 =A0 =A0routing infrastructure for the MR's MNP(s)."

=A0 =A0- Is it enough from a specification standpoint to state that the =A0 =A0 =A0routes need to be injected into the routing infra?
=A0 =A0 =A0Handwaving????

11. Are there any new threats or security issues that arise from
=A0 =A0assigning prefixes to be delegated downstream in the case of
=A0 =A0PMIP6? Security section seems pretty light.


-Raj

_______________________________________________
netext mailing list
netext@ietf.org
= https://www.ietf.org/mailman/listinfo/netext

--000e0cd29e52d8bbc704b1692c5b-- From Basavaraj.Patil@nokia.com Sun Nov 13 17:38:30 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F7811E8083 for ; Sun, 13 Nov 2011 17:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wG2nXxBYBxy for ; Sun, 13 Nov 2011 17:38:29 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0916421F8783 for ; Sun, 13 Nov 2011 17:38:28 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAE1cN0S007779; Mon, 14 Nov 2011 03:38:24 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 03:38:08 +0200 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Mon, 14 Nov 2011 02:38:07 +0100 From: To: Thread-Topic: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 Thread-Index: AQHMnYpTGqYa7OGEukONGJ+vApALIZWmqVIAgAVtDwA= Date: Mon, 14 Nov 2011 01:38:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [130.129.17.117] Content-Type: multipart/alternative; boundary="_000_CAE691D0159C9basavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Nov 2011 01:38:08.0354 (UTC) FILETIME=[0FE30420:01CCA26E] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:38:30 -0000 --_000_CAE691D0159C9basavarajpatilnokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Behect, I believe you answered your own question in the email. So yes, you are corr= ect. The answer is No. -Basavaraj From: ext Behcet Sarikaya > Reply-To: Behcet Sarikaya > Date: Thu, 10 Nov 2011 16:46:28 -0600 To: Basavaraj Patil > Cc: Netext >, > Subject: Re: [netext] Review of I-D: draft-ietf-netext-pd-pmip-01 Hi Basavaraj, I have a question: Can we at Netext work on specs that require modifying MN? Reading the charter: The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). It seems to me the answer is no? Regards, Behcet On Mon, Nov 7, 2011 at 2:17 PM, > wrote: A few quick comments: 1. Abstract should have no references. And the description can be improved. It really is hard to understand what this I-D is trying to accomplish. 2. The introduction section can be improved. Maybe you should include a problem statement section to indicate what is lacking in PMIP6 as per RFC5213. 3. In Sec 3.1 it states: " o The MR (as a RR) MUST either obtain the Home Network Prefix (HNP) before initiating the DHCPv6-PD procedure or in case of stateful address configuration simultaneously while configuring the Mobile Node Home Address (MN-HoA). " So does this imply that the MR (PMIP6 MN) obtains an HNP as per RFC5213 for its own use prior to the MR requesting via DHCPv6 another set of prefixes to be used for delegating to downstream nodes? 4. If the prefixes (delegated) are provided by a DHCP server (and not the LMA), how does the LMA get informed about these? In the PBU? How do you ensure that "All the mobile network prefixes managed in the DR MUST be reachable via local mobility anchor (LMA)" when they are not assigned by the LMA? 5. Sec 3.1 also states: "The delegating router (DR) can be located either at LMA or some other device in the PMIPv6 domain" What is this some other device? 6. In Sec 3.2 the I-D states that the profile needs to indicate whether an MN can be assigned prefixes for delegation. Does the profile indicate whether the host is a mobile router? Is this needed? Any MN should be able to act as an MR. 7. In Fig 1, you have a DR shown there. How does the DR indicate the assigned prefixes to the LMA? - Step 5 seems disconnected from the rest of the process. Maybe it is better to split that aspect and show it in another figure. 8. Does the lifetime of the delegated prefix (assigned by a DR) the same as the lifetime assigned by the LMA? Why not have Sec 3.3.3 to describe how a prefix is revoked or deleted? Text is currently in 3.3.2. 9. In sec 3.4.2: "Other considerations from Section 6.10.5 or [RFC5213]" Sec 6.10.5 of this I-D? There is none. 10. Sec 3.5.2 states: "In order to receive those packets, the LMA MUST advertise a connected route into the routing infrastructure for the MR's MNP(s)." - Is it enough from a specification standpoint to state that the routes need to be injected into the routing infra? Handwaving???? 11. Are there any new threats or security issues that arise from assigning prefixes to be delegated downstream in the case of PMIP6? Security section seems pretty light. -Raj _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_CAE691D0159C9basavarajpatilnokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7C1EB09CE7340A49BEF1E47386B2ECBB@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

Behect,

I believe you answered your own question in the email. So yes, you are= correct. The answer is No.

-Basavaraj

From: ext Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: Behcet Sarikaya <sarikaya@ieee.org>
Date: Thu, 10 Nov 2011 16:46:28 -06= 00
To: Basavaraj Patil <basavaraj.patil@nokia.com>
Cc: Netext <netext@ietf.org>, <draft-ietf-netext-pd-pmip@tools.ietf.org&g= t;
Subject: Re: [netext] Review of I-D= : draft-ietf-netext-pd-pmip-01

Hi Basavaraj,

I have a question:

Can we at Netext work on specs that require modifying MN?

Reading the charter:
The work in this charter is entirely internal to the network and does
  not affect host IP stack operation in any way (except perhaps through
  impacting packet forwarding capacity visible to the hosts).

It seems to me the answer is no?

Regards,

Behcet
On Mon, Nov 7, 2011 at 2:17 PM, <Basavaraj.Patil@nokia.co= m> wrote:

A few quick comments:

1. Abstract should have no references. And the description can be
  improved. It really is hard to understand what this I-D is trying   to accomplish.

2. The introduction section can be improved. Maybe you should include
  a problem statement section to indicate what is lacking in PMIP6 as<= br>   per RFC5213.

3. In Sec 3.1 it states:
"
  o  The MR (as a RR) MUST either obtain the Home Network Prefix = (HNP)
     before initiating the DHCPv6-PD procedure or in case of= stateful
     address configuration simultaneously while configuring = the Mobile
     Node Home Address (MN-HoA).
"

  So does this imply that the MR (PMIP6 MN) obtains an HNP as per
  RFC5213 for its own use prior to the MR requesting via DHCPv6
  another set of prefixes to be used for delegating to downstream
  nodes?

4. If the prefixes (delegated) are provided by a DHCP server (and not
  the LMA), how does the LMA get informed about these? In the PBU?
  How do you ensure that
  "All the mobile network prefixes managed in the DR MUST be
  reachable via local mobility anchor (LMA)" when they are not   assigned by the LMA?

5. Sec 3.1 also states:
  "The delegating router (DR) can be located either at LMA or som= e
     other device in the PMIPv6 domain"

   What is this some other device?

6.  In Sec 3.2 the I-D states that the profile needs to indicate
   whether an MN can be assigned prefixes for delegation. Does th= e
   profile indicate whether the host is a mobile router? Is this<= br>    needed? Any MN should be able to act as an MR.

7. In Fig 1, you have a DR shown there. How does the DR indicate the
  assigned prefixes to the LMA?
  - Step 5 seems disconnected from the rest of the process. Maybe it   is better to split that aspect and show it in another figure.

8. Does the lifetime of the delegated prefix (assigned by a DR) the
  same as the lifetime assigned by the LMA?
  Why not have Sec 3.3.3 to describe how a prefix is revoked or
  deleted? Text is currently in 3.3.2.

9. In sec 3.4.2:
  "Other considerations from Section 6.10.5 or [RFC5213]"
  Sec 6.10.5 of this I-D? There is none.

10. Sec 3.5.2 states:
   "In order to receive
     those packets, the LMA MUST advertise a connected route= into the
     routing infrastructure for the MR's MNP(s)."

   - Is it enough from a specification standpoint to state that t= he
     routes need to be injected into the routing infra?
     Handwaving????

11. Are there any new threats or security issues that arise from
   assigning prefixes to be delegated downstream in the case of    PMIP6? Security section seems pretty light.


-Raj

_______________________________________________
netext mailing list
netext@ietf.org
= https://www.ietf.org/mailman/listinfo/netext

 --_000_CAE691D0159C9basavarajpatilnokiacom_-- From ietf@meetecho.com Tue Nov 15 06:38:15 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928F51F0C52 for ; Tue, 15 Nov 2011 06:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qACHjZhrcGAl for ; Tue, 15 Nov 2011 06:38:11 -0800 (PST) Received: from smtpw1.aruba.it (smtpipvs3.aruba.it [62.149.128.188]) by ietfa.amsl.com (Postfix) with SMTP id 2F1D01F0C45 for ; Tue, 15 Nov 2011 06:38:06 -0800 (PST) Received: (qmail 18233 invoked by uid 89); 15 Nov 2011 14:38:01 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw1.ad.aruba.it with SMTP; 15 Nov 2011 14:38:01 -0000 Date: Tue, 15 Nov 2011 15:38:01 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: netext@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 143.225.229.143 X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N Subject: [netext] Meetecho support for NETEXT WG meeting session X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 14:38:15 -0000 Hi all,=0A=0Aa virtual room has been reserved on the Meetecho system for = tomorrow's NETEXT WG meeting session.=0A=0AAccess to the on-line session = (including audio and video streams) will be available from 9:00am at:=0Ah= ttp://www.meetecho.com/ietf82/netext=0A=0AThe Meetecho session automatica= lly logs you into the standard IETF jabber room. So, from there, you can = have an integrated experience involving all media and allowing you to int= eract with the room.=0A=0AA tutorial of interactivity features of the too= l can be found at:=0Ahttp://www.meetecho.com/ietf82/tutorials=0A=0AFor fu= rther information you can contact us at ietf-support@meetecho.com.=0A=0AC= heers,=0Athe Meetecho team=C2=A0=0A=0A--=C2=A0=0AMeetecho s.r.l.=0AWeb Co= nferencing and Collaboration Tools=0Awww.meetecho.com=0A=C2=A0 From charliep@computer.org Tue Nov 15 18:23:50 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAB511E815F for ; Tue, 15 Nov 2011 18:23:50 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5BnugE3oX4c for ; Tue, 15 Nov 2011 18:23:50 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id E6B7811E80EE for ; Tue, 15 Nov 2011 18:23:49 -0800 (PST) Received: from [130.129.83.71] by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RQVAA-00081N-ON for netext@ietf.org; Tue, 15 Nov 2011 21:23:47 -0500 Message-ID: <4EC31EAE.2010007@computer.org> Date: Tue, 15 Nov 2011 18:23:42 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: netext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86931f720be776d14fbf0ef8fc3e1a57fe350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.83.71 Subject: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 02:23:50 -0000 Hello folks, At the meeting this morning, a question was raised about the proper behavior on a logical interface if more than one value of MTU were advertised on any of the links of the interface. This was discussed in the IPv6 working group. IIRC, the sense of the discussion was that this was simply an error. See section 6.2.7 of RFC 4861. In the case for logical interfaces, it seems to me that (a) a device can pick the MTU for whatever router advertisement it is using and (b) for the purposes of multicast across all links the source should pick the minimum of all advertised values. Regards, Charlie P. Regards, Charlie P. From Basavaraj.Patil@nokia.com Tue Nov 15 21:34:39 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448181F0C61 for ; Tue, 15 Nov 2011 21:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqHCDLf4pO1W for ; Tue, 15 Nov 2011 21:34:35 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id A46541F0CD8 for ; Tue, 15 Nov 2011 21:34:34 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAG5YTXL031786; Wed, 16 Nov 2011 07:34:29 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 07:34:29 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by 008-AM1MMR1-009.mgdnok.nokia.com (65.54.30.25) with Microsoft SMTP Server (TLS) id 14.1.355.3; Wed, 16 Nov 2011 06:34:28 +0100 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Wed, 16 Nov 2011 06:34:28 +0100 From: To: Thread-Topic: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements? Thread-Index: AQHMpAbNXcKzKnB2d0K7cZZ3yVH6bZWu6f6A Date: Wed, 16 Nov 2011 05:34:27 +0000 Message-ID: <3987B607-580F-470E-B2C3-9C880356489F@nokia.com> References: <4EC31EAE.2010007@computer.org> In-Reply-To: <4EC31EAE.2010007@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.17.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <6EB7952DFB617F45974C0CD3921953A7@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Nov 2011 05:34:29.0383 (UTC) FILETIME=[6943D170:01CCA421] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:34:39 -0000 Hi Charlie, Using the minimum MTU as the value for the logical IF is probably the right= thing to do. However you can also consider this as a sort of a DoS attack in the sense t= hat you are forcing the MN to use an MTU to a smaller value thereby causing= less efficient use of an air IF.=20 As an example a wifi network may advertise an MTU of 1280 and if the MN use= s this as the default even on the cellular IF, the cellular IF is being use= d sub optimally. -Basavaraj On Nov 16, 2011, at 10:23 AM, ext Charles E. Perkins wrote: >=20 > Hello folks, >=20 > At the meeting this morning, a question was raised > about the proper behavior on a logical interface if > more than one value of MTU were advertised on any of > the links of the interface. This was discussed in > the IPv6 working group. IIRC, the sense of the > discussion was that this was simply an error. > See section 6.2.7 of RFC 4861. >=20 > In the case for logical interfaces, it seems to > me that (a) a device can pick the MTU for whatever > router advertisement it is using and (b) for the > purposes of multicast across all links the source > should pick the minimum of all advertised values. >=20 > Regards, > Charlie P. >=20 >=20 > Regards, > Charlie P. > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From ietf@meetecho.com Wed Nov 16 04:35:48 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C5721F94D4 for ; Wed, 16 Nov 2011 04:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQqG0LaKY-vo for ; Wed, 16 Nov 2011 04:35:48 -0800 (PST) Received: from smtplq04.aruba.it (smtplq-out19.aruba.it [62.149.158.39]) by ietfa.amsl.com (Postfix) with SMTP id 6CF6D21F94D3 for ; Wed, 16 Nov 2011 04:35:47 -0800 (PST) Received: (qmail 6241 invoked by uid 89); 16 Nov 2011 12:35:42 -0000 Received: from unknown (HELO smtp7.aruba.it) (62.149.158.227) by smtplq04.aruba.it with SMTP; 16 Nov 2011 12:35:42 -0000 Received: (qmail 5126 invoked by uid 89); 16 Nov 2011 12:35:42 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp7.ad.aruba.it with SMTP; 16 Nov 2011 12:35:42 -0000 Message-ID: <4EC3AE16.9090204@meetecho.com> Date: Wed, 16 Nov 2011 13:35:34 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp7.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Subject: [netext] NETEXT session recording available X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 12:35:48 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of today's NETEXT session is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/82/remote-participation.html#Meetecho), or by directly accessing the following URL: http://www.meetecho.com/ietf82/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. Cheers, the Meetecho Team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From sgundave@cisco.com Wed Nov 16 19:39:54 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA5E1F0CAC for ; Wed, 16 Nov 2011 19:39:54 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcrhnTRMqEZ2 for ; Wed, 16 Nov 2011 19:39:53 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D1E551F0C98 for ; Wed, 16 Nov 2011 19:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3100; q=dns/txt; s=iport; t=1321501193; x=1322710793; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=0nvaR9h9Cmf8SKd9epeRiI+sBLwQFOX8glGrRNh0Qes=; b=LoloBj9hUzdDf0Qw7jiTkCDu8o8Z+q1UjBiCqkn6jGbndecLJBS6Z8Vx Dno12UaOg0KSIsvsD0Jvvep8jxEIDIiuMP9ttjr8hBIUNIlG/xiirQx+Z ffpROLDw+Km7pYbc/7J9FCE+logoyv2I/hxOlklHQNbrsH0LGrQI5k1AE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB9yxE6rRDoG/2dsb2JhbABCqgaBBYFyAQEBAwEBAQEPAScCATELEgEIGCMyMAIEAQ0FIodgCJR7AZ5gBIoXBIgUjCCFRIxZ X-IronPort-AV: E=Sophos;i="4.69,524,1315180800"; d="scan'208";a="14680502" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 17 Nov 2011 02:36:50 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAH2ao0X000405; Thu, 17 Nov 2011 02:36:50 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 18:36:50 -0800 Received: from 10.21.88.139 ([10.21.88.139]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Thu, 17 Nov 2011 02:36:49 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Wed, 16 Nov 2011 18:36:48 -0800 From: Sri Gundavelli To: , Message-ID: Thread-Topic: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements? Thread-Index: AQHMpAbNXcKzKnB2d0K7cZZ3yVH6bZWu6f6AgAFxdo8= In-Reply-To: <3987B607-580F-470E-B2C3-9C880356489F@nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Nov 2011 02:36:50.0012 (UTC) FILETIME=[C232A1C0:01CCA4D1] Cc: netext@ietf.org Subject: Re: [netext] draft-ietf-netext-logical-interface-support -- multiple incompatible MTU advertisements? X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 03:39:54 -0000 Hi Charlie/Raj: Agree. This is what we have for the MTU considerations. 5.2. MTU considerations The link MTU (maximum transmission unit) value configured on a logical interface should be the lowest of the MTU values supported across any of the physical interfaces that are part of that logical interface construct. The MTU value should be configured as part of the logical interface creation on the host. Furthermore, this value must be updated any time there is a change to the logical interface construct, such as when interfaces are added or deleted from the logical interface setup. Any time there is an inter-technology handover between two access technologies, the applications on the host bound to the IP address configuration on the logical interface will not detect the change and will continue to use the MTU value of the logical interface for the outbound packets, which is never greater than the MTU value on that supported access network. However, the access network may continue to deliver the packets conforming to the MTU value supported on that access technology and the logical interface should be able to receive those packets from the physical interface attached to that network. This approach of MTU configuration will ensure there is no IP packet fragmentation after inter-technology handovers. On 11/15/11 9:34 PM, "Basavaraj.Patil@nokia.com" wrote: > > Hi Charlie, > > Using the minimum MTU as the value for the logical IF is probably the right > thing to do. > However you can also consider this as a sort of a DoS attack in the sense that > you are forcing the MN to use an MTU to a smaller value thereby causing less > efficient use of an air IF. > As an example a wifi network may advertise an MTU of 1280 and if the MN uses > this as the default even on the cellular IF, the cellular IF is being used sub > optimally. > > -Basavaraj > > On Nov 16, 2011, at 10:23 AM, ext Charles E. Perkins wrote: > >> >> Hello folks, >> >> At the meeting this morning, a question was raised >> about the proper behavior on a logical interface if >> more than one value of MTU were advertised on any of >> the links of the interface. This was discussed in >> the IPv6 working group. IIRC, the sense of the >> discussion was that this was simply an error. >> See section 6.2.7 of RFC 4861. >> >> In the case for logical interfaces, it seems to >> me that (a) a device can pick the MTU for whatever >> router advertisement it is using and (b) for the >> purposes of multicast across all links the source >> should pick the minimum of all advertised values. >> >> Regards, >> Charlie P. >> >> >> Regards, >> Charlie P. >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From jari.arkko@piuha.net Tue Nov 22 05:53:00 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C2B21F8B58 for ; Tue, 22 Nov 2011 05:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25Dxw8OZ-+er for ; Tue, 22 Nov 2011 05:52:59 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 26C4F21F8BCB for ; Tue, 22 Nov 2011 05:52:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7AAF42CC43; Tue, 22 Nov 2011 15:52:57 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4ecnT+DhLTG; Tue, 22 Nov 2011 15:52:55 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1C8722CC31; Tue, 22 Nov 2011 15:52:54 +0200 (EET) Message-ID: <4ECBA935.6060309@piuha.net> Date: Tue, 22 Nov 2011 05:52:53 -0800 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: draft-ietf-netext-bulk-re-registration@tools.ietf.org, "netext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] AD review of draft-ietf-netext-bulk-re-registration X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 13:53:00 -0000 I have reviewed this draft. The draft is almost ready to move forward. Please make a quick revision based on the comments below: > For an hypothetical scenario, with 500,000 mobility sessions and with > binding lifetime of 30 minutes, it results in: 500,000 / 1,800 sec = > 277 transactions/sec > > For the above hypothetical scenario, based on the computation, it is > apparent that the base Proxy Mobile IPv6 re-registration process > where the mobile access gateway sends a unique binding refresh > message for each mobility session is inefficient or sub-optimal. > These re-registration messages consume significant amount of network > resources, both in terms of processing power and in terms of network > bandwidth at both the peers. Therefore it is the intent of this > specification to optimize the signaling procedures. These > optimizations allow the local mobility anchor and the mobile access > gateway to perform bulk binding update and revocation operations. > This seems a little bit overselling the idea. A 500,000 node gateway will also have some traffic, e.g., if one node out of 100 is doing a 50 packets per second (a voip call), then the entire box does 250,000 packets per second. The network traffic impact part of the signaling is not that big. Anyway, this is just a comment and not critical in anyway to progressing the draft. But I would add a sentence that the actual impacts depend on capacity required to deal with other issues, such as worst-case movement signalling or payload traffic load. > The mobile access gateway can also assign a local group identifier > for the mobility session and include that in the initial request. > This group identifier may be different from the group identifier that > the local mobility assigns. Subsequently, both the peers can perform > bulk operations on those groups. > The mobile > access gateway MAY also choose to request the group identifier > based on its own grouping consideration, by sending the Mobile > Node Group Identifier option with the proposed group identifier. > Upon receiving the Proxy Binding Acknowledgment message with > status code value set to (0) (Proxy Binding Update accepted), the > bulk binding update flag (B) in the reply is set to a value of (1) > and if there is a mobile node group identifier option present, the > message serves as a hint that the local mobility anchor has > enabled bulk binding update support for the mobility session and > that the mobile access gateway MAY use the group identifier when > requesting binding update or binding revocation operation with > group specific scope. The group identifier value in Binding > Update List entry MUST also be updated to include the assigned > group identifier. > > o For enabling the bulk binding update support for the mobility > session, the local mobility anchor MAY choose to associate the > mobility session to a specific group. The specific details on how > the local mobility anchor associates the given mobility session to > a specific bulk binding update group is outside the scope of this > document. The local mobility anchor MAY choose to assign a > default group identifier value of (255), indicating that all the > mobility sessions from that mobile access gateway are part of that > group. If there is a request from the mobile access gateway to > assign a specific group identifier, the local mobility anchor may > choose to honor that request. The assigned group identifier field > in the Binding Cache entry is updated with the identifier of the > group to which the mobility session is associated. The first quoted paragraph seems to claim that both sides can group devices per their own desires. This does not seem to be supported by the rest of the specification, as the LMA will override whatever suggestion was made by the MAG. This may be fine, but I would change the first paragraph as follows: OLD: The mobile access gateway can also assign a local group identifier for the mobility session and include that in the initial request. This group identifier may be different from the group identifier that the local mobility assigns. Subsequently, both the peers can perform bulk operations on those groups. NEW: The mobile access gateway can also suggest a local group identifier for the mobility session and include that in the initial request. This group identifier may be different from the group identifier that the local mobility anchor assigns. Subsequently, both the peers can perform bulk operations on the group identifier confirmed by the local mobility anchor. > the > bulk binding update flag (B) in the reply is set to a value of (1) > and if there is a mobile node group identifier option present, the > message serves as a hint that the local mobility anchor has > enabled bulk binding update support for the mobility session and > that the mobile access gateway MAY use the group identifier when > requesting binding update or binding revocation operation with > group specific scope. AFAICT, this is not a "hint" -- it is a fact. Whether you use it for something is up to you, but the LMA *has* enabled the support. Or am I missing something? Suggested edit: s/serves as hint/informs the receiver/ > o If the (B) flag in the received Proxy Binding Update message is > set to a value of (1) and if the Mobile Node Group Identifier > option is not present in the request, the message serves as a > request to the local mobility anchor to include the mobile node's > session to the bulk binding update group. > ... to *the* bulk binding update group. I think you mean "... to *a* bulk binding update group." In This case there is ID specified, so the LMA has to find a suitable group based on its own preferences. Similarly, in the next paragraph I would change: OLD: o If the (B) flag in the received Proxy Binding Update message is set to a value of (1) and if the Mobile Node Group Identifier option is present in the request, the message serves as a request to the local mobility anchor to include the mobile node's session to the bulk binding update group, with the proposed group identifier present in the Mobile Node Group Identifier option. NEW: o If the (B) flag in the received Proxy Binding Update message is set to a value of (1) and if the Mobile Node Group Identifier option is present in the request, the message serves as a request to the local mobility anchor to include the mobile node's session to a bulk binding update group, with the proposed group identifier present in the Mobile Node Group Identifier option. > Mobile Node Group Identifier A 32-bit field containing the mobile > node's group identifier. The group identifier value of (255) is > reserved for the group, all the mobility sessions for a given > mobile access gateway hosted on a given local mobility anchor, > this is a preassigned group. > Some strange wording. I would also suggest that the value 255 needs to be discussed in the IANA considerations. Also, the value zero seems to be used: > The value of the group > identifier in the Binding Cache entry must be set to the value of > (0). Please talk about this in the IANA considerations, too. Perhaps you could leave values 1-254 as Reserved for IETF, and then values 256-(2^32-1) as freely usable by implementations. Or something... the current situation is confusing because I don't know how to generate group IDs that do not collide with the ones needed for some special purpose. E.g, on some implementation I might want to use line card ID as the group ID. But then I have to worry about 0. Missing things: 1) You should specify what to do if the LMA returns a group identifier and sets the B bit without the MAG requesting it to do so. The right action is to ignore this, I think, but you should specify it. 2) You should specify what to do if client MIP operations set the B bit. Some kind of error should be returned, or the flag and option ignored, I think. 3) I think you should add "Updates: RFC 5213, 5846" to the header of the draft. You are changing the procedures for identifying nodes. Jari From sgundave@cisco.com Tue Nov 22 09:27:46 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830D711E8091 for ; Tue, 22 Nov 2011 09:27:46 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwO2bKWILrGR for ; Tue, 22 Nov 2011 09:27:45 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF9911E8090 for ; Tue, 22 Nov 2011 09:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=9971; q=dns/txt; s=iport; t=1321982865; x=1323192465; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=CC9DVzpA3v41wUd91Ye9DS6iDsaeBkR27dst9BpW1vc=; b=X7SekNX2XS14gfxV9QKDrcXJis/GFVT7AuzOz8fVp4auMKlp1SoPrCcM 7SFgFA+/hB3+4sZdWiSHI9g2BVjXBT/hsTsPjNudKnV0KvcvuAfNHG2T7 JPXZskpKHuA4lclzBX/gl3uqnkiqmh+ShyRgO/Yn6gvLhNu8NvRTRZU6p U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADDby06rRDoI/2dsb2JhbABDqlGBBYFyAQEBAwEBAQEPAScCATEQDQEIbTABAQQBEiKHYwiWKAGeWASKYgSIHIwnhUiMYQ X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; d="scan'208";a="15772213" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 22 Nov 2011 17:27:45 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAMHRiEY006424; Tue, 22 Nov 2011 17:27:45 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Nov 2011 09:27:45 -0800 Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Nov 2011 17:27:44 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Tue, 22 Nov 2011 09:27:39 -0800 From: Sri Gundavelli To: Jari Arkko , , "netext@ietf.org" Message-ID: Thread-Topic: [netext] AD review of draft-ietf-netext-bulk-re-registration Thread-Index: AcypPAhXa03fzzOc8EuYg1jo3HddEw== In-Reply-To: <4ECBA935.6060309@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Nov 2011 17:27:45.0085 (UTC) FILETIME=[0BF836D0:01CCA93C] Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 17:27:46 -0000 Hi Jari: Thanks for the review. Please see inline. On 11/22/11 5:52 AM, "Jari Arkko" wrote: > I have reviewed this draft. > > The draft is almost ready to move forward. Please make a quick revision based > on the comments below: > >> For an hypothetical scenario, with 500,000 mobility sessions and with >> binding lifetime of 30 minutes, it results in: 500,000 / 1,800 sec = >> 277 transactions/sec >> >> For the above hypothetical scenario, based on the computation, it is >> apparent that the base Proxy Mobile IPv6 re-registration process >> where the mobile access gateway sends a unique binding refresh >> message for each mobility session is inefficient or sub-optimal. >> These re-registration messages consume significant amount of network >> resources, both in terms of processing power and in terms of network >> bandwidth at both the peers. Therefore it is the intent of this >> specification to optimize the signaling procedures. These >> optimizations allow the local mobility anchor and the mobile access >> gateway to perform bulk binding update and revocation operations. >> > > This seems a little bit overselling the idea. A 500,000 node gateway will also > have some traffic, e.g., if one node out of 100 is doing a 50 packets per > second (a voip call), then the entire box does 250,000 packets per second. The > network traffic impact part of the signaling is not that big. > > Anyway, this is just a comment and not critical in anyway to progressing the > draft. But I would add a sentence that the actual impacts depend on capacity > required to deal with other issues, such as worst-case movement signalling or > payload traffic load. > I agree, :) it is not entirely accurate. Will fix it. >> The mobile access gateway can also assign a local group identifier >> for the mobility session and include that in the initial request. >> This group identifier may be different from the group identifier that >> the local mobility assigns. Subsequently, both the peers can perform >> bulk operations on those groups. >> The mobile >> access gateway MAY also choose to request the group identifier >> based on its own grouping consideration, by sending the Mobile >> Node Group Identifier option with the proposed group identifier. >> Upon receiving the Proxy Binding Acknowledgment message with >> status code value set to (0) (Proxy Binding Update accepted), the >> bulk binding update flag (B) in the reply is set to a value of (1) >> and if there is a mobile node group identifier option present, the >> message serves as a hint that the local mobility anchor has >> enabled bulk binding update support for the mobility session and >> that the mobile access gateway MAY use the group identifier when >> requesting binding update or binding revocation operation with >> group specific scope. The group identifier value in Binding >> Update List entry MUST also be updated to include the assigned >> group identifier. >> >> o For enabling the bulk binding update support for the mobility >> session, the local mobility anchor MAY choose to associate the >> mobility session to a specific group. The specific details on how >> the local mobility anchor associates the given mobility session to >> a specific bulk binding update group is outside the scope of this >> document. The local mobility anchor MAY choose to assign a >> default group identifier value of (255), indicating that all the >> mobility sessions from that mobile access gateway are part of that >> group. If there is a request from the mobile access gateway to >> assign a specific group identifier, the local mobility anchor may >> choose to honor that request. The assigned group identifier field >> in the Binding Cache entry is updated with the identifier of the >> group to which the mobility session is associated. > > The first quoted paragraph seems to claim that both sides can group devices > per their own desires. This does not seem to be supported by the rest of the > specification, as the LMA will override whatever suggestion was made by the > MAG. This may be fine, but I would change the first paragraph as follows: > We allowed both the nodes to perform group operations. A given session may be assigned a MAG-specific group identifier and also an LMA-specific group identifier. Probably it needs corrections in couple of places and in the illustration. > OLD: > The mobile access gateway can also assign a local group identifier > for the mobility session and include that in the initial request. > This group identifier may be different from the group identifier that > the local mobility assigns. Subsequently, both the peers can perform > bulk operations on those groups. > NEW: > The mobile access gateway can also suggest a local group identifier > for the mobility session and include that in the initial request. > This group identifier may be different from the group identifier that > the local mobility anchor assigns. Subsequently, both the peers can perform > bulk operations on the group identifier confirmed by the local mobility > anchor. > I think its a very small change needed to support two group identifiers for a given session, I can go over the spec and fix it. If you agree. >> the >> bulk binding update flag (B) in the reply is set to a value of (1) >> and if there is a mobile node group identifier option present, the >> message serves as a hint that the local mobility anchor has >> enabled bulk binding update support for the mobility session and >> that the mobile access gateway MAY use the group identifier when >> requesting binding update or binding revocation operation with >> group specific scope. > > AFAICT, this is not a "hint" -- it is a fact. Whether you use it for something > is up to you, but the LMA *has* enabled the support. Or am I missing > something? > Yes. It is a fact that the LMA can support bulk binding operations and that this session is part of that list. Will reword it. > Suggested edit: s/serves as hint/informs the receiver/ > OK. >> o If the (B) flag in the received Proxy Binding Update message is >> set to a value of (1) and if the Mobile Node Group Identifier >> option is not present in the request, the message serves as a >> request to the local mobility anchor to include the mobile node's >> session to the bulk binding update group. >> > > ... to *the* bulk binding update group. I think you mean "... to *a* bulk > binding update group." In This case there is ID specified, so the LMA has to > find a suitable group based on its own preferences. > I agree, this needs to be fixed. Between the Flag and the option, we need to tighten the text on the usage. > Similarly, in the next paragraph I would change: > > OLD: > o If the (B) flag in the received Proxy Binding Update message is > set to a value of (1) and if the Mobile Node Group Identifier > option is present in the request, the message serves as a request > to the local mobility anchor to include the mobile node's session > to the bulk binding update group, with the proposed group > identifier present in the Mobile Node Group Identifier option. > NEW: > o If the (B) flag in the received Proxy Binding Update message is > set to a value of (1) and if the Mobile Node Group Identifier > option is present in the request, the message serves as a request > to the local mobility anchor to include the mobile node's session > to a bulk binding update group, with the proposed group > identifier present in the Mobile Node Group Identifier option. > >> Mobile Node Group Identifier A 32-bit field containing the mobile >> node's group identifier. The group identifier value of (255) is >> reserved for the group, all the mobility sessions for a given >> mobile access gateway hosted on a given local mobility anchor, >> this is a preassigned group. >> > > Some strange wording. I would also suggest that the value 255 needs to be > discussed in the IANA considerations. Also, the value zero seems to be used: > Agree, its not clear. We will fix it. >> The value of the group >> identifier in the Binding Cache entry must be set to the value of >> (0). > > Please talk about this in the IANA considerations, too. Perhaps you could > leave values 1-254 as Reserved for IETF, and then values 256-(2^32-1) as > freely usable by implementations. Or something... the current situation is > confusing because I don't know how to generate group IDs that do not collide > with the ones needed for some special purpose. E.g, on some implementation I > might want to use line card ID as the group ID. But then I have to worry about > 0. > Sure. > Missing things: > > 1) You should specify what to do if the LMA returns a group identifier and > sets the B bit without the MAG requesting it to do so. The right action is to > ignore this, I think, but you should specify it. > Sure. > 2) You should specify what to do if client MIP operations set the B bit. Some > kind of error should be returned, or the flag and option ignored, I think. > We can add a condition that this is relevant only if the (P) flag is set. > 3) I think you should add "Updates: RFC 5213, 5846" to the header of the > draft. You are changing the procedures for identifying nodes. > If the new flag/option is not present, we will be updating 5213/5844. I'll check and see if we are updating the base procedures. Regards Sri > Jari > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From jari.arkko@piuha.net Tue Nov 22 11:00:24 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B1011E8083 for ; Tue, 22 Nov 2011 11:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWMJW-Y1b6yp for ; Tue, 22 Nov 2011 11:00:23 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7B54811E8082 for ; Tue, 22 Nov 2011 11:00:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CAB532CC31; Tue, 22 Nov 2011 21:00:22 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mrw+zMS0aps; Tue, 22 Nov 2011 21:00:22 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id BD0F02CC43; Tue, 22 Nov 2011 21:00:20 +0200 (EET) Message-ID: <4ECBF141.6010607@piuha.net> Date: Tue, 22 Nov 2011 11:00:17 -0800 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sri Gundavelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" , draft-ietf-netext-bulk-re-registration@tools.ietf.org Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 19:00:24 -0000 Sri, > > The first quoted paragraph seems to claim that both sides can group devices > per their own desires. This does not seem to be supported by the rest of the > specification, as the LMA will override whatever suggestion was made by the > MAG. This may be fine, but I would change the first paragraph as follows: > > We allowed both the nodes to perform group operations. A given session may > be assigned a MAG-specific group identifier and also an LMA-specific group > identifier. Probably it needs corrections in couple of places and in the > illustration. > > > You say you allowed, but I don't actually see the functionality. You can have the MAG set it, you can have LMA set it, but it is not possible for *both* to set it. If the LMA wants to dictate group IDs, then the IDs that the MAG used no longer can be used. Or am I missing something? Jari From sgundave@cisco.com Tue Nov 22 11:57:46 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497EC1F0C5A for ; Tue, 22 Nov 2011 11:57:46 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAn1XbK7LYvv for ; Tue, 22 Nov 2011 11:57:44 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA621F0C56 for ; Tue, 22 Nov 2011 11:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=2122; q=dns/txt; s=iport; t=1321991864; x=1323201464; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=0FIB71s5qdjlUZSso1c1Uz7KT7npMLfe3Vkr+wdFdzQ=; b=Nqoz5AieuHReKMpK6pJdWE118jDPdejHBt4Gguv2RUZKz4uqp+O1CsdK eilaG+tbhMg1yUqTJlTxvdVqurHH3PeTy6XYf3Y37d7mQRrp815h4p6IV zQqNOnxX+Hd7Xw/FkWaEjHyAogZaGC5FALQiUJftHJOWrIhb70MlbSlyo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFT+y06rRDoI/2dsb2JhbABEql2BBYFyAQEBAwESAScCASoSBQ0BCIEdAQEEDgUih2OWIgGeSYpiBIgcjCeFSIxh X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; d="scan'208";a="15800674" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 22 Nov 2011 19:57:44 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAMJviX9027881; Tue, 22 Nov 2011 19:57:44 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Nov 2011 11:57:44 -0800 Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 Nov 2011 19:57:43 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Tue, 22 Nov 2011 11:57:37 -0800 From: Sri Gundavelli To: Jari Arkko Message-ID: Thread-Topic: [netext] AD review of draft-ietf-netext-bulk-re-registration Thread-Index: AcypUPuRr9ApEup8X0qG3oZ/ElZ56Q== In-Reply-To: <4ECBF141.6010607@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Nov 2011 19:57:44.0388 (UTC) FILETIME=[FFF8E040:01CCA950] Cc: "netext@ietf.org" , draft-ietf-netext-bulk-re-registration@tools.ietf.org Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 19:57:46 -0000 Hi Jari: On 11/22/11 11:00 AM, "Jari Arkko" wrote: > Sri, > >> >> The first quoted paragraph seems to claim that both sides can group devices >> per their own desires. This does not seem to be supported by the rest of the >> specification, as the LMA will override whatever suggestion was made by the >> MAG. This may be fine, but I would change the first paragraph as follows: >> > >> We allowed both the nodes to perform group operations. A given session may >> be assigned a MAG-specific group identifier and also an LMA-specific group >> identifier. Probably it needs corrections in couple of places and in the >> illustration. >> >> >> > > You say you allowed, but I don't actually see the functionality. You can have > the MAG set it, you can have LMA set it, but it is not possible for *both* to > set it. If the LMA wants to dictate group IDs, then the IDs that the MAG used > no longer can be used. Or am I missing something? > My intention was to support the scenario to perform binding operations on nodes that are hosted on the same application blade/module of the MAG, or on the LMA. For example, when the MAG creates sessions for two mobile nodes (Ex: MN-1 and MN-2), both these nodes may be hosted on a given blade of the MAG, while those sessions on LMA may be hosted on two different blades. So, the group ID's for these nodes will be MN-1 (Mag-Id1, Lma-Id1), MN-2 (Mag-Id1, LMA-Id2). The binding operations can be now performed on Mag-Id1, Lma-Id1, or Lma-Id2. I agree, this part of the text is not clear and should be updated. But, the option can be carried on both the directions, the BCE/BUL entries needs to store both the id's, binding operation's scope is always a single Id present in the identifier, protocol negotiation related text is where there is some ambiguity. So, might need to update in just couple of places, that's all. But, I agree, the current text is bit unclear on this aspect. I can quickly address this comment and there is a long weekend not too far :) Regards Sri > Jari > From jari.arkko@piuha.net Tue Nov 22 16:42:05 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF0F11E8098 for ; Tue, 22 Nov 2011 16:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zmzd8vIlTv8w for ; Tue, 22 Nov 2011 16:42:05 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id F365811E80D6 for ; Tue, 22 Nov 2011 16:42:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DFC852CC4D; Wed, 23 Nov 2011 02:42:03 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-xTWGGtuFLl; Wed, 23 Nov 2011 02:42:03 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 7812F2CC31; Wed, 23 Nov 2011 02:41:54 +0200 (EET) Message-ID: <4ECC4150.1060706@piuha.net> Date: Tue, 22 Nov 2011 16:41:52 -0800 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sri Gundavelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" , draft-ietf-netext-bulk-re-registration@tools.ietf.org Subject: Re: [netext] AD review of draft-ietf-netext-bulk-re-registration X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 00:42:05 -0000 Ok. You have clearly understood the issue, and I'll wait until you've updated the draft. Thanks. jari From jari.arkko@piuha.net Fri Nov 25 10:24:51 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F6A21F8B3A for ; Fri, 25 Nov 2011 10:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dju6FXzyt1Nx for ; Fri, 25 Nov 2011 10:24:50 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 90CBB21F8507 for ; Fri, 25 Nov 2011 10:24:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 171142CC4D; Fri, 25 Nov 2011 20:24:42 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oy7YJZPxVh96; Fri, 25 Nov 2011 20:24:40 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 830652CC31; Fri, 25 Nov 2011 20:24:38 +0200 (EET) Message-ID: <4ECFDD66.2040801@piuha.net> Date: Fri, 25 Nov 2011 09:24:38 -0900 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: draft-ietf-netext-pmip-lr@tools.ietf.org, "netext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] AD review of draft-ietf-netext-pmip-lr X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 18:24:51 -0000 I have reviewed this draft. It is in good shape and almost ready to move forward. I did find a couple of issues, however, and the most serious one of these is the one about tear-down. Please fix this and submit a new draft so that I can initiate an IETF last call. > If a MAG is unable to deliver packets using the LREs, it is possible > that the MN is no longer attached to the MAG. Hence, the MAG SHOULD > fall back to using the BUL entry, and the LMA MUST forward the > received packets using its BCE. > This seems wrong. First of all, there are two MNs. Maybe you should say "... that one of the MNs is no longer ...". Secondly, since you had a MUST earlier for use of the LRE, shouldn't the SHOULD be a MUST too? > If one of the MNs, say MN1, detaches from the MAG and attaches to > another MAG (say nMAG) the localized routing state needs to be re- > established. When the LMA receives the PBU from nMAG for MN1, it > will see that localized routing is active for MN1. It will hence > initiate LR at nMAG and update the LR state of MAG. After the > handover completes, the localized routing will resemble Scenario A21. > I think you should explain how the state in the pMAG changes. I presume this is just standard RFC 5213 behaviour, but nevertheless it is important for the pMAG to know that it should no longer do RO. > When a supported > scenario, such as Scenario A12, morphs into Scenario A22 the node > that initiated the localized routing session SHOULD tear it down in > order to prevent lasting packet loss. Shouldn't this be a MUST? > The node > that initiated the localized routing session SHOULD tear it down in > order to prevent lasting packet loss. > In > deployments where Scenario A22 is possible, it is recommended that > localized routing not be initiated when packet-loss-sensitive > applications are in use. There are *no* situations where lasting packet loss is acceptable. So I think you have to handle this. I don't mean that you have to be able to use RO in A22, but you have to be able to tear RO down when the situation changes. I think this is doable, and a part of the tear-down in general happens. When the device that initiated RO realizes that one of the involved sessions is gone elsewhere, it MUST do a RLI with lifetime 0 to tear the session down in the other nodes. > PMIPv6 MNs can use an IPv4 HoA as described in [RFC5844 ]. In order > to support the setup and maintenance of localized routes for these > IPv4 HoAs in PMIPv6, MAGs must add the IPv4 HoAs into their LREs. > The MAGs MUST also support encapsulation of IPv4 packets as described > in [RFC5844 ]. The localized routing protocol messages MUST include a > IPv4 HoA option in their signaling messages in order to support IPv4 > addresses for localized routing. > > ... > > Note that this document supports LR only for IPv6 traffic, and LR is > not supported for IPv4 traffic. The last paragraph seems inconsistent with the first paragraph. Remove one of them? > All the Localized routing messages use a new mobility header type > (TBA1). > The Localized Routing Initiation, described inSection 9.1 and the > Localized Routing Acknowledgment, described inSection 9.2 require a > single Mobility Header Type (TBA1) from the Mobility Header Types > registry athttp://www.iana.org/assignments/mobility-parameters > This seems odd. Usually, a message and its acknowledgment have different message types. TBA1 and TBA2... I can see that you have the R flag, but this isn't the usual way to define new MH messages. > Mobility Options: MUST contain the MN-ID, followed by one or more > HNPs for each of the MNs. For instance, for Mobile Nodes MN1 and > MN2 with identifiers MN1-ID, MN2-ID and Home Network Prefixes > MN1-HNP and MN2-HNP, the following tuple in the following order > MUST be present: [MN1-ID, MN1-HNP], [MN2-ID, MN2-HNP]. The > MN-ID and HNP options are the same as in [RFC5213 ]. MAY contain > the remote MAG IPv6 address option, which is formatted identically > to the HNP option, except that it uses a different Type code and > the Prefix Length is always equal to 128 bits (seeSection 10.1 ). > I think you could explain this better. My understanding is that there is only one option for MN-ID, so by repeating that option you will signal two identities. "MUST contain two separate MN-iD options, followed by ..." And you should define which one is which. The first one is the one that is always in the MAG that sends/receives the message? > > 11. Security Considerations > > > > The protocol specified in this document uses the same security > association as defined in [RFC5213 ] for use between the LMA and the > MAG to protect the LRI and LRA messages. This document also assumes > the pre-existence of a MAG-MAG security association if LR needs to be > supported between them. No new security risks are identified as > compared to [RFC5213 ]. Support for integrity protection using IPsec > is required, but support for confidentiality is not necessary. > I think you should highlight one new risk, which is the risk of setting up a MAG-MAG tunnel. The document should also specify what packets are allowable to come from such tunnels (to prevent spoofing attempts). > > 12. IANA Considerations > > > What is the situation with the LRA Status field? Does it need its own registry, or are the values shared between PBA status values? Please specify. > == The document seems to lack the recommended RFC 2119 boilerplate, even if > it appears to use RFC 2119 keywords -- however, there's a paragraph with > a matching beginning. Boilerplate error? Please see if you can fix this idnits warning. Some wording difference between Section 3 and what 2119 uses, perhaps? Jari