Re: [MEXT] hello, everyone,i have the question,thanks

From julienl@qualcomm.com Tue Dec 1 08:31:45 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C861E3A6886 for ; Tue, 1 Dec 2009 08:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=-1.418, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scr39fWn-1Uf for ; Tue, 1 Dec 2009 08:31:44 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5F07428C10D for ; Tue, 1 Dec 2009 08:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259685093; x=1291221093; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Dave=20Craig=20|CC:=20"mext @ietf.org"=20,=0D=0A=20=20=20=20=20=20=20 =20"draft-ietf-mext-binary-ts@tools.ietf.org"=0D=0A=09|Date:=20Tue,=201 =20Dec=202009=2008:31:29=20-0800|Subject:=20RE:=20[MEXT] =20[WGLC]=20draft-ietf-mext-binary-ts-01|Thread-Topic:=20 [MEXT]=20[WGLC]=20draft-ietf-mext-binary-ts-01 |Thread-Index:=20AcpyKwdwl+ln5FpgQ9CByr+InIZQZQAdo15w |Message-ID:=20|References:=20=0D=0A=09=20<40b8fe770911301648m51b82a37o179596ab20856 5bc@mail.gmail.com>=0D=0A=09=20=0D=0A=20<4 0b8fe770911301807p6bcd2ca1o250547109f7d7a2c@mail.gmail.co m>|In-Reply-To:=20<40b8fe770911301807p6bcd2ca1o250547109f 7d7a2c@mail.gmail.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5818"=3B=20a=3D"28804894"; bh=AMkaEU8hXcFV2/hTbHm/ge/QusDGqCdp4vnbItC5a5o=; b=yeF+Nw8D1za+5KSfwK5oxcesGREMx4/eotOYxu7UHh4Tf01NYo3mI/Nb OUe3HMxi/C0lBULMMW8r89/0W1MKTIO97mroXDpvPsGavnoQkGlL3N76y X/QKKf5QiWf/0fTYS4mBICE5K1Y9hX7TR1qDQoqQSegK1aiKtP0k1nRCk k=; X-IronPort-AV: E=McAfee;i="5400,1158,5818"; a="28804894" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 01 Dec 2009 08:31:33 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB1GVWKa020670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2009 08:31:33 -0800 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB1GVWcC021361 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Dec 2009 08:31:32 -0800 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 1 Dec 2009 08:31:31 -0800 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Tue, 1 Dec 2009 08:31:31 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Tue, 1 Dec 2009 08:31:31 -0800 From: "Laganier, Julien" To: Dave Craig Date: Tue, 1 Dec 2009 08:31:29 -0800 Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 Thread-Index: AcpyKwdwl+ln5FpgQ9CByr+InIZQZQAdo15w Message-ID: References: <40b8fe770911301648m51b82a37o179596ab208565bc@mail.gmail.com> <40b8fe770911301807p6bcd2ca1o250547109f7d7a2c@mail.gmail.com> In-Reply-To: <40b8fe770911301807p6bcd2ca1o250547109f7d7a2c@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mext-binary-ts@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:31:45 -0000 Dave Craig wrote: > Laganier, Julien wrote: > > Dave Craig wrote: > >> > >> [...] > >> > >> 3.1. page 6, How about adding the following to the end of the SPI > >> field descriptions (EF), "A present SPI field does not match traffic > >> without an IPsec header." =A0Also applies to 3.2. page 10. > > > > Would it be simpler to say "this field MUST NOT be present if the > > protocol is neither IPsec AH nor ESP"? >=20 > Both solutions would work, but is there a reason to add more > verification logic and possible causes for failure messages in the > protocol? Let me illustrate in terms of dealing with ports in RFC 4306, which I was t= rying to mimic with our traffic selector format: RFC 4306 specify that the = start and end port MUST be respectively set to 0 and 65535 for protocols fo= r which port is undefined. So the port fields are there but they MUST be ex= plicitly marked as 'irrelevant' with these special values. Since we have th= e ability to omit the values that seemed a straightforward way to signal th= at these fields are 'irrelevant'. On the other hand your proposal implies that the presence of SPI field matc= hes against the protocol field that has to be IPsec AH or ESP, so this seem= s redundant. It also introduces some ambiguities: what do I do if I match p= acket that has no SPI but has port numbers, and the traffic selector has bo= th ports and SPIs. Does it match or not? =20 > >> 3.1. page 7, How about adding the following to the end of the port > >> field description (GHIJ), "A present port field does not match > >> traffic with IP protocols that do not define a transport port." =A0 > >> Also add a reference to the port number definitions, so it is not ambi= guous > >> which port you're talking about. > >> http://www.iana.org/assignments/port-numbers. > > > > I am not sure we want to cite the port-numbers registry. This seems > > to imply that only the ports as registered in the registry are legal in > > terms of this specification, and I'm not sure we want that... > > > > As to restricting the port field to protocols defining a transport > > port, I'm wondering whether we want to have a provision similar to that > > of RFC 4306 (IKEv2) w.r.t. ICMP: > > > > =A0 For the ICMP protocol, the two one-octet fields Type and Code are > > treated as a single 16-bit integer (with Type in the most significant > > eight bits and Code in the least significant eight bits) port number= =20 > > for the purposes of filtering based on this field. >=20 > Which fields would you use for a GRE packet when the filter only > specifies ports? Suggest paring down the problem to match only > specified protocol where you know the mapping, then. IPv6 NH also > matches ICMPv6 type+code. IPv4 protocol also matches ICMP type + > code. As above for handling SPIs in protocols which don't have them, I would sugg= est to say "this field MUST NOT be present if the protocol does not have pr= otocol numbers, or is neither ICMP nor ICMPv6". --julien From dave.craig4@gmail.com Tue Dec 1 11:13:17 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C223A6926 for ; Tue, 1 Dec 2009 11:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RYprl6sRvS4 for ; Tue, 1 Dec 2009 11:13:15 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 198A53A6784 for ; Tue, 1 Dec 2009 11:13:15 -0800 (PST) Received: by pzk6 with SMTP id 6so3765826pzk.29 for ; Tue, 01 Dec 2009 11:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FBj1DX/oThML3lLLwsBgcBS07SS+6LebGRJJf5ukAEE=; b=otD5oxvlZ4YjRxJaMrC1rZ+BD9JQrGxhzvGkjZbFI03rvztMaiVHGS3XX5Mjkv4Fud /hZus1R55Pzix6B4tgJEdnqAF29lzNJnqbPRA9hkgrv2vF+CkrawdP1stRudkXzYhZ6u RcDb5fAMfKAvYOV1R0KC87OzBE7TgLzkLtZsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YUWm1cEafu7a7wHuggEsGQrhwX+pnnvfs6RyH/gc56ebBKnT2RRTNB661mtDwmqaqI 8CIEVr34tx6PbZcq/mvDw/Ra74XMFBpU9gJPwL6VNVba2EgbJIQPjOz85yhhBn687H7h QOo2vQltBE8u0goyAN2KYVui3SxTUHYyFqV5o= MIME-Version: 1.0 Received: by 10.115.61.16 with SMTP id o16mr11825073wak.15.1259694782772; Tue, 01 Dec 2009 11:13:02 -0800 (PST) In-Reply-To: References: <40b8fe770911301648m51b82a37o179596ab208565bc@mail.gmail.com> <40b8fe770911301807p6bcd2ca1o250547109f7d7a2c@mail.gmail.com> Date: Tue, 1 Dec 2009 11:13:02 -0800 Message-ID: <40b8fe770912011113n78ccedbcq53e1a621767bcdd0@mail.gmail.com> From: Dave Craig To: "Laganier, Julien" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-mext-binary-ts@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:13:17 -0000 On Tue, Dec 1, 2009 at 8:31 AM, Laganier, Julien wro= te: > Dave Craig wrote: >> Laganier, Julien wrote: >> > Dave Craig wrote: >> >> >> >> [...] >> >> >> >> 3.1. page 6, How about adding the following to the end of the SPI >> >> field descriptions (EF), "A present SPI field does not match traffic >> >> without an IPsec header." =A0Also applies to 3.2. page 10. >> > >> > Would it be simpler to say "this field MUST NOT be present if the >> > protocol is neither IPsec AH nor ESP"? >> >> Both solutions would work, but is there a reason to add more >> verification logic and possible causes for failure messages in the >> protocol? > > Let me illustrate in terms of dealing with ports in RFC 4306, which I was= trying to mimic with our traffic selector format: RFC 4306 specify that th= e start and end port MUST be respectively set to 0 and 65535 for protocols = for which port is undefined. So the port fields are there but they MUST be = explicitly marked as 'irrelevant' with these special values. Since we have = the ability to omit the values that seemed a straightforward way to signal = that these fields are 'irrelevant'. > > On the other hand your proposal implies that the presence of SPI field ma= tches against the protocol field that has to be IPsec AH or ESP, so this se= ems redundant. It also introduces some ambiguities: what do I do if I match= packet that has no SPI but has port numbers, and the traffic selector has = both ports and SPIs. Does it match or not? > >> >> 3.1. page 7, How about adding the following to the end of the port >> >> field description (GHIJ), "A present port field does not match >> >> traffic with IP protocols that do not define a transport port." >> >> Also add a reference to the port number definitions, so it is not amb= iguous >> >> which port you're talking about. >> >> http://www.iana.org/assignments/port-numbers. >> > >> > I am not sure we want to cite the port-numbers registry. This seems >> > to imply that only the ports as registered in the registry are legal i= n >> > terms of this specification, and I'm not sure we want that... >> > >> > As to restricting the port field to protocols defining a transport >> > port, I'm wondering whether we want to have a provision similar to tha= t >> > of RFC 4306 (IKEv2) w.r.t. ICMP: >> > >> > =A0 For the ICMP protocol, the two one-octet fields Type and Code are >> > =A0 treated as a single 16-bit integer (with Type in the most signific= ant >> > =A0 eight bits and Code in the least significant eight bits) port numb= er >> > =A0 for the purposes of filtering based on this field. >> >> Which fields would you use for a GRE packet when the filter only >> specifies ports? =A0Suggest paring down the problem to match only >> specified protocol where you know the mapping, then. =A0IPv6 NH also >> matches ICMPv6 type+code. =A0IPv4 protocol also matches ICMP type + >> code. > > As above for handling SPIs in protocols which don't have them, I would su= ggest to say "this field MUST NOT be present if the protocol does not have = protocol numbers, or is neither ICMP nor ICMPv6". > > --julien > > I see the advantage of being more pedantic in message handling. The only downside is that the spec will need a lot more text explaining all of the possible error scenarios. It is not just a matter of having SPIs present without specifying IPsec protocol. Each field needs an enumeration of the protocols that it is valid for. Implementers also will need to add more verification logic to provide this validation. I would still like to advocate leaving the mappings implicit like firewalls often do today. When I specify only a port number in the filter, the implementation makes a best effort mapping to what that means for each protocol or does not match the packet when it does not make sense to do the mapping. Thanks, Dave From julienl@qualcomm.com Tue Dec 1 11:28:48 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C743A6969 for ; Tue, 1 Dec 2009 11:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.672 X-Spam-Level: X-Spam-Status: No, score=-103.672 tagged_above=-999 required=5 tests=[AWL=-1.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qvn3+4hcquGz for ; Tue, 1 Dec 2009 11:28:47 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 169AB3A6967 for ; Tue, 1 Dec 2009 11:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259695720; x=1291231720; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Dave=20Craig=20|CC:=20"mext @ietf.org"=20,=0D=0A=20=20=20=20=20=20=20 =20"draft-ietf-mext-binary-ts@tools.ietf.org"=0D=0A=09|Date:=20Tue,=201 =20Dec=202009=2011:28:36=20-0800|Subject:=20RE:=20[MEXT] =20[WGLC]=20draft-ietf-mext-binary-ts-01|Thread-Topic:=20 [MEXT]=20[WGLC]=20draft-ietf-mext-binary-ts-01 |Thread-Index:=20Acpyulr+5SGyWnnDTTaCjmFNeDRdKgAACl3g |Message-ID:=20|References:=20=0D=0A=09=20<40b8fe770911301648m51b82a37o179596ab20856 5bc@mail.gmail.com>=0D=0A=09=20=0D=0A=09 =20<40b8fe770911301807p6bcd2ca1o250547109f7d7a2c@mail.gma il.com>=0D=0A=09=20=0D=0A=20<40b8fe7709120 11113n78ccedbcq53e1a621767bcdd0@mail.gmail.com> |In-Reply-To:=20<40b8fe770912011113n78ccedbcq53e1a621767b cdd0@mail.gmail.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5819"=3B=20a=3D"28819456"; bh=Pz/ksorITq+ouOUcNiDfHjJ69ZSIJCoip/T4wl210O8=; b=r072fZZS9q6Kw+zpnqxgRc+hxTHUEhwx3n+6MhdT8R2JF2enNRJlhlbT j7cMyy9ogsDTTP94w+7U/x5oVLLYmtCLmdhchEpjZbuVtPY6Jmzma9Suh 5HkWlWg8YQjp2Rhl/zUsTUk6nS19c8hueoteJkVjFfpx40yUgKblU/m2s k=; X-IronPort-AV: E=McAfee;i="5400,1158,5819"; a="28819456" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 01 Dec 2009 11:28:39 -0800 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB1JSdLi015520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2009 11:28:39 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB1JSdFV004226 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Dec 2009 11:28:39 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 1 Dec 2009 11:28:38 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Tue, 1 Dec 2009 11:28:38 -0800 From: "Laganier, Julien" To: Dave Craig Date: Tue, 1 Dec 2009 11:28:36 -0800 Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 Thread-Index: Acpyulr+5SGyWnnDTTaCjmFNeDRdKgAACl3g Message-ID: References: <40b8fe770911301648m51b82a37o179596ab208565bc@mail.gmail.com> <40b8fe770911301807p6bcd2ca1o250547109f7d7a2c@mail.gmail.com> <40b8fe770912011113n78ccedbcq53e1a621767bcdd0@mail.gmail.com> In-Reply-To: <40b8fe770912011113n78ccedbcq53e1a621767bcdd0@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mext-binary-ts@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:28:48 -0000 Dave Craig wrote:=20 > On Tue, Dec 1, 2009 at 8:31 AM, Laganier, Julien > > [...] > > > > As above for handling SPIs in protocols which don't have them, I > > would suggest to say "this field MUST NOT be present if the protocol > > does not have protocol numbers, or is neither ICMP nor ICMPv6". > > > > --julien >=20 > I see the advantage of being more pedantic in message handling. The > only downside is that the spec will need a lot more text explaining > all of the possible error scenarios. It is not just a matter of > having SPIs present without specifying IPsec protocol. Each field > needs an enumeration of the protocols that it is valid for. > Implementers also will need to add more verification logic to provide > this validation. >=20 > I would still like to advocate leaving the mappings implicit like > firewalls often do today. When I specify only a port number in the > filter, the implementation makes a best effort mapping to what that > means for each protocol or does not match the packet when it does not > make sense to do the mapping. Ok, I understand your point. I don't have a strong opinion on the matter, s= o if nobody else has one, I'd suggest that we move forward with your origin= al proposal (i.e., "A present port field does not match traffic with IP pro= tocols that do not define a transport port " and "A present SPI field does = not match traffic without an IPsec header".) --julien From behcetsarikaya@yahoo.com Tue Dec 1 15:25:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89893A6957 for ; Tue, 1 Dec 2009 15:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.143 X-Spam-Level: X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc+MttLnVUyK for ; Tue, 1 Dec 2009 15:25:50 -0800 (PST) Received: from web111404.mail.gq1.yahoo.com (web111404.mail.gq1.yahoo.com [67.195.15.150]) by core3.amsl.com (Postfix) with SMTP id 1E1853A6934 for ; Tue, 1 Dec 2009 15:25:50 -0800 (PST) Received: (qmail 79897 invoked by uid 60001); 1 Dec 2009 23:25:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259709942; bh=AyJcz1+F58lgzJm7H9ije/yHAkxuLQDqPyKHL525WYY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aAd6JcVLzwAbtL7J/WNi3EfI/L6l/tzAbxU77QwAAi+5bw+uJhJ7KTwMUcaM9C2pblFsQLwTMpgyEjRdxs8RjZ6ue3T8X2y4k3JiB1SxU90BPu/Er9uBmQgLAnFPa7x4DAV+4ELhx6FKhp7jVVzZr5B0P97DyzBHkxU6JSck3J8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5UMGYzB9pOvgDiwr3HtYwlI/ozQOlqThuMRZoWlEWQ38frUbTqMDnranPEWfmJtSqJkeqpw1TEH2H2UVkULjWO4eivR8yF90+tI8CfVxakoICte80RHqBGvG9fuPrQnsF6r0ChSSYa4jtu5Tjus0XFk/2NgeOvD6Af6t6wU4AgU=; Message-ID: <342737.79841.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: N1OvyXYVM1n52O1infXciZzUbfu2GTRO3IKZJCmczYM9XiG9VDOWZOUKil0dWsMvY83Rosl6bFnfVO7l.svHr2mB_LzO2LwypiBgxXtCaMqTbiX4wIrt7Rz9WJHDCzE6AG_Gmo16GtAo4IaAfQ54bFifo.OSIkfJpZHMsYIlQU0z6HC5VB_jXFcg2Jrkn7B9wka7XNKY2SkYYHoA7lXJzE8b29LdKO6A.cKoHLN1h0RXv4FRCIIND7.vuozbiDrrxN164zrvJQIE3VmGB_zzOet3A1M9vuQQgPO4Hcj6_vr.umq8VplswBMDA5TvuN7ZifPDGVre Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Tue, 01 Dec 2009 15:25:42 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: <4AEFEBDE.6040903@ericsson.com> Date: Tue, 1 Dec 2009 15:25:42 -0800 (PST) From: Behcet Sarikaya To: George Tsirtsis In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-mext-flow-binding@tools.ietf.org, IETF MEXT WG ML Subject: Re: [MEXT] Flow Bindings WGLC output: pre-04 version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 23:25:50 -0000 Hi George,=0A=A0 I have a question on the draft. I was reading it and could= not figure out an answer for that, maybe you can help me?=0A=0AAs for send= ing BU with flow identification mobility options, in case MN has more than = one interface which is active, from which interface MN should send the BU? = I think that there is no problem in setting the source and destination addr= esses=0Athe rules are pretty clear there but the interface selection does n= ot seem to be clarified in the text?=0A=0ACan you shed some light into this= ?=0A=0AThanks in advance.=0A=0ABehcet=0A=0A=0A From Basavaraj.Patil@nokia.com Wed Dec 2 12:53:48 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C30F63A690D for ; Wed, 2 Dec 2009 12:53:48 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5CtIOhBMBk8 for ; Wed, 2 Dec 2009 12:53:48 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0CA2F3A68FF for ; Wed, 2 Dec 2009 12:53:47 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nB2KrYK1032529 for ; Wed, 2 Dec 2009 14:53:39 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 22:53:38 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 22:53:32 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 2 Dec 2009 21:53:31 +0100 From: To: Date: Wed, 2 Dec 2009 21:53:24 +0100 Thread-Topic: Review of I-D: draft-ietf-mext-binary-ts-01 Thread-Index: AcpzkX0du69e8VapuUid8S99FtOGTg== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Dec 2009 20:53:32.0192 (UTC) FILETIME=[81FF3A00:01CA7391] X-Nokia-AV: Clean Subject: [MEXT] Review of I-D: draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 20:53:48 -0000 Below are my review comments for the I-D: draft-ietf-mext-binary-ts-01 1. s/If more than one contiguous source addresses need to be mached/If more than one contiguous source address needs to be matched 2. s/SPI values need to be mached/SPI values need to be matched 3. W.r.t the ports, does it make sense to have a wildcard flag which implies that no part matching needs to be done by the HA? The same might apply for the destination address field as well. 4. s/mached/matched in multiple places in the I-D 5. s/concenrs/concerns One other suggestion: - The I-D is proposing traffic selectors which are specified in binary format. In the future we could have other formats as well for TS. Hence the title of the I-D should be "Binary format Traffic Selectors for Flow Bindings" Summary: -------- I think the I-D does not have any major issues and ready to be progressed. -Basavaraj From julienl@qualcomm.com Wed Dec 2 14:00:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70CF33A6838 for ; Wed, 2 Dec 2009 14:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.685 X-Spam-Level: X-Spam-Status: No, score=-103.685 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIru-qSjdNvE for ; Wed, 2 Dec 2009 14:00:49 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 7C1A83A6836 for ; Wed, 2 Dec 2009 14:00:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259791242; x=1291327242; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"Basavaraj.Patil@nokia.com"=20,=0D=0A=20=20=20=20=20=20=20=20"mext@ietf.org"=0D =0A=09|Date:=20Wed,=202=20Dec=202009=2014: 00:35=20-0800|Subject:=20RE:=20Review=20of=20I-D:=20draft -ietf-mext-binary-ts-01|Thread-Topic:=20Review=20of=20I-D :=20draft-ietf-mext-binary-ts-01|Thread-Index:=20AcpzkX0d u69e8VapuUid8S99FtOGTgACOHpQ|Message-ID:=20|References:=20 |In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5820"=3B=20a=3D"28921828"; bh=OLlKmb21+yYhayhCCKmiRnAXGEGkmh51oCGOAk8SC/0=; b=S7dxHB4ZCc+ZiqlZdfS8nnbrgnSiCP7+ybPwnCny4VxI8xxrCWweykXo i2lWyRLnsFhvEeqiiaUn1aHEC9VlFr+QAyKCiyjD6VSFgcPqXng79qBaz EvBfuIA3DwXVKQr8axWW2C20fxh0c1OiIZzAf/PuEaH9iOP6kH0p1BsU8 o=; X-IronPort-AV: E=McAfee;i="5400,1158,5820"; a="28921828" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 02 Dec 2009 14:00:38 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB2M0c5O010626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2009 14:00:38 -0800 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB2M0bXY013318 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Dec 2009 14:00:38 -0800 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Dec 2009 14:00:37 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 2 Dec 2009 14:00:37 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 2 Dec 2009 14:00:37 -0800 From: "Laganier, Julien" To: "Basavaraj.Patil@nokia.com" , "mext@ietf.org" Date: Wed, 2 Dec 2009 14:00:35 -0800 Thread-Topic: Review of I-D: draft-ietf-mext-binary-ts-01 Thread-Index: AcpzkX0du69e8VapuUid8S99FtOGTgACOHpQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] Review of I-D: draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 22:00:50 -0000 Basavaraj.Patil@nokia.com wrote:=20 >=20 > Below are my review comments for the I-D: draft-ietf-mext-binary-ts-01 >=20 > [...] >=20 > 3. W.r.t the ports, does it make sense to have a wildcard flag which > implies that no part matching needs to be done by the HA? > The same might apply for the destination address field as well. I understand that if neither the start nor the end port fields are included= , the traffic selector matches any port number. Same with goes with address= es (or SPIs, etc.). > One other suggestion: >=20 > - The I-D is proposing traffic selectors which are specified in binary > format. In the future we could have other formats as well for > TS. Hence the title of the I-D should be "Binary format Traffic > Selectors for Flow Bindings" Everything in Mobile IPv6 is binary formatted so far, so I don't think we n= eed to outline that in the name of the mechanism. We could entitle it "Simp= le Traffic Selector Format for Flow Bindings", however =3D) =20 > Summary: > -------- >=20 > I think the I-D does not have any major issues and ready to be > progressed. Good. Thanks for the review Raj! --julien From behcetsarikaya@yahoo.com Wed Dec 2 15:09:01 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D323A69B0 for ; Wed, 2 Dec 2009 15:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV1geamddyoF for ; Wed, 2 Dec 2009 15:09:00 -0800 (PST) Received: from web111409.mail.gq1.yahoo.com (web111409.mail.gq1.yahoo.com [67.195.15.180]) by core3.amsl.com (Postfix) with SMTP id 5817A3A69AC for ; Wed, 2 Dec 2009 15:09:00 -0800 (PST) Received: (qmail 85119 invoked by uid 60001); 2 Dec 2009 23:08:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259795332; bh=SIFB6x9PR69lk2M8AatN5H+fg9Dkt3OlnqIvftJGaxQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Jpqf8osk39CtZ82G3m/GJMy6oQEt5fCQJhAOtfjLAx45mE/Xrt3MB+7cQHps0IMT8liN2DIfxlnbaRLc53kGjiONcXM4BDp6RCacIEPZUzBhRv+3aAhY7sKn4GZ89V9LCll0gaWDN8v0lDlNhglIPShfQ34KeCwwaFQoTp3Dk8M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ABBF8L8PJKZHTgfcUHFX1BLAZdE1McQcVVxOUMDJqWGlKxOmjtNcpQ0uP01HyavnbHDb++ZqcJKnSVnRBROuDhxlwgguvjwidWdczu4i4GqArOuC/3p8ygGdKGuq8hKXwi8IUWNy65vEFj55Lh5TWmtQhM2TZ3sFy1m5SGapkiM=; Message-ID: <694378.85035.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: YndhiO4VM1kaTWn8XRLssjKXdyRyfA0O84NjJhw5pIw8NQRfy2Naww_p_P0zf4ErlxLe.7rJEBTjsaUrwLcpl0990tVWJ5zjbodYTd1UTTn4I03cBltNM7_djEHkFWOlnIASQNgyo897MzuEpxrQvvO5mtOqzy_uVmdrP_nA8sa1470DqBWRbeI_vMQYwBSd0fhm1DW75GB3sGJLaTTPUyMKBq..2oOFMyFu61aJjrt1yaVT3g9XI2O6tXupfQz6v6SlBzBubvV.oEG_iyCKZtuhjjF31jq3ZVD0v_Wl08Mb5bAIiwxqxQibsfpVQSU89RP657Y53p2f5Gs8iOLybdqVhuOOjBNO3BVv78Fn Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Wed, 02 Dec 2009 15:08:52 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 References: Date: Wed, 2 Dec 2009 15:08:52 -0800 (PST) From: Behcet Sarikaya To: "Laganier, Julien" , "Basavaraj.Patil@nokia.com" , "mext@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] Review of I-D: draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 23:09:01 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: "Laganier, Julien" =0A> To: "Basavaraj.Patil@nokia.com" ; "mext@ietf.org" =0A> Sent: Wed, December 2, 2009 4:00= :35 PM=0A> Subject: Re: [MEXT] Review of I-D: draft-ietf-mext-binary-ts-01= =0A> =0A> Basavaraj.Patil@nokia.com wrote: =0A> > =0A> > Below are my revie= w comments for the I-D: draft-ietf-mext-binary-ts-01=0A> > =0A> > [...]=0A>= > =0A> > 3. W.r.t the ports, does it make sense to have a wildcard flag wh= ich=0A> >=A0 =A0 implies that no part matching needs to be done by the HA?= =0A> >=A0 =A0 The same might apply for the destination address field as wel= l.=0A> =0A> I understand that if neither the start nor the end port fields = are included, the =0A> traffic selector matches any port number. Same with = goes with addresses (or =0A> SPIs, etc.).=0A> =0A> > One other suggestion:= =0A> > =0A> > - The I-D is proposing traffic selectors which are specified = in binary=0A> >=A0 format. In the future we could have other formats as wel= l for=0A> >=A0 TS. Hence the title of the I-D should be "Binary format Traf= fic=0A> >=A0 Selectors for Flow Bindings"=0A> =0A> Everything in Mobile IPv= 6 is binary formatted so far, so I don't think we need =0A> to outline that= in the name of the mechanism. We could entitle it "Simple =0A> Traffic Sel= ector Format for Flow Bindings", however =3D)=0A> =0AI agree that binary is= too generic.=0A=0AMy suggestion is=0ATraffic Selectors for Flow Bindings B= ased on IP and Transport Header Fields=0A=0AWhat do you think?=0A=0A--behce= t=0A=0A=0A From yuri.ismailov@ericsson.com Thu Dec 3 00:55:31 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03DE3A69EE for ; Thu, 3 Dec 2009 00:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtDGdbkh-4Zr for ; Thu, 3 Dec 2009 00:55:31 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 9393A3A69E3 for ; Thu, 3 Dec 2009 00:55:29 -0800 (PST) X-AuditID: c1b4fb3e-b7b36ae000005786-a8-4b177c1e28cc Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id F6.DC.22406.E1C771B4; Thu, 3 Dec 2009 09:51:42 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 09:51:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Dec 2009 09:51:34 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 Thread-Index: Acpyulr+5SGyWnnDTTaCjmFNeDRdKgAACl3gAE5ufSA= References: <40b8fe770911301648m51b82a37o179596ab208565bc@mail.gmail.com><40b8fe770911301807p6bcd2ca1o250547109f7d7a2c@mail.gmail.com><40b8fe770912011113n78ccedbcq53e1a621767bcdd0@mail.gmail.com> From: "Yuri Ismailov" To: "Laganier, Julien" , "Dave Craig" X-OriginalArrivalTime: 03 Dec 2009 08:51:35.0289 (UTC) FILETIME=[D1861E90:01CA73F5] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-mext-binary-ts@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 08:55:32 -0000 Hello, I think this sounds reasonable, at least unambiguous. I have another ambiguity concern regarding IPv6 traffic selector. The last two fields specify "next header" range. However, an IPv6 packet may contain optional headers following right after the IPv6 header. It means that the value of NH is not necessarily transport protocol value. Then the question is will the port numbers be ignored in such case? As I understand it yes, according to the previous discussion. This will lead to the result the the packet will not match the traffic selector Is that correct? Regards Yuri -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Laganier, Julien Sent: Tuesday, December 01, 2009 8:29 PM To: Dave Craig Cc: draft-ietf-mext-binary-ts@tools.ietf.org; mext@ietf.org Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 Dave Craig wrote:=20 > On Tue, Dec 1, 2009 at 8:31 AM, Laganier, Julien=20 > > > [...] > > > > As above for handling SPIs in protocols which don't have them, I=20 > > would suggest to say "this field MUST NOT be present if the protocol > > does not have protocol numbers, or is neither ICMP nor ICMPv6". > > > > --julien >=20 > I see the advantage of being more pedantic in message handling. The=20 > only downside is that the spec will need a lot more text explaining=20 > all of the possible error scenarios. It is not just a matter of=20 > having SPIs present without specifying IPsec protocol. Each field=20 > needs an enumeration of the protocols that it is valid for. > Implementers also will need to add more verification logic to provide=20 > this validation. >=20 > I would still like to advocate leaving the mappings implicit like=20 > firewalls often do today. When I specify only a port number in the=20 > filter, the implementation makes a best effort mapping to what that=20 > means for each protocol or does not match the packet when it does not=20 > make sense to do the mapping. Ok, I understand your point. I don't have a strong opinion on the matter, so if nobody else has one, I'd suggest that we move forward with your original proposal (i.e., "A present port field does not match traffic with IP protocols that do not define a transport port " and "A present SPI field does not match traffic without an IPsec header".) --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From yuri.ismailov@ericsson.com Thu Dec 3 01:07:56 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F833A68AD for ; Thu, 3 Dec 2009 01:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2UyPbbxT3oV for ; Thu, 3 Dec 2009 01:07:55 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D700E3A683D for ; Thu, 3 Dec 2009 01:07:54 -0800 (PST) X-AuditID: c1b4fb3e-b7b36ae000005786-16-4b177f243f48 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 89.0E.22406.42F771B4; Thu, 3 Dec 2009 10:04:36 +0100 (CET) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 10:04:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Dec 2009 10:04:35 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] Review of I-D: draft-ietf-mext-binary-ts-01 Thread-Index: AcpzkX0du69e8VapuUid8S99FtOGTgACOHpQABc//YA= References: From: "Yuri Ismailov" To: "Laganier, Julien" , , X-OriginalArrivalTime: 03 Dec 2009 09:04:36.0341 (UTC) FILETIME=[A3113250:01CA73F7] X-Brightmail-Tracker: AAAAAA== Subject: Re: [MEXT] Review of I-D: draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 09:07:56 -0000 Hi, Quick comment about draft title. The word "simple" does not have any strict technical definition and does not give any estimate about boundaries of simplicity. I suggest not using "simple" in the draft name. /yuri =20 -----Original Message----- From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Laganier, Julien Sent: Wednesday, December 02, 2009 11:01 PM To: Basavaraj.Patil@nokia.com; mext@ietf.org Subject: Re: [MEXT] Review of I-D: draft-ietf-mext-binary-ts-01 Basavaraj.Patil@nokia.com wrote:=20 >=20 > Below are my review comments for the I-D: draft-ietf-mext-binary-ts-01 >=20 > [...] >=20 > 3. W.r.t the ports, does it make sense to have a wildcard flag which > implies that no part matching needs to be done by the HA? > The same might apply for the destination address field as well. I understand that if neither the start nor the end port fields are included, the traffic selector matches any port number. Same with goes with addresses (or SPIs, etc.). > One other suggestion: >=20 > - The I-D is proposing traffic selectors which are specified in binary > format. In the future we could have other formats as well for > TS. Hence the title of the I-D should be "Binary format Traffic > Selectors for Flow Bindings" Everything in Mobile IPv6 is binary formatted so far, so I don't think we need to outline that in the name of the mechanism. We could entitle it "Simple Traffic Selector Format for Flow Bindings", however =3D) =20 > Summary: > -------- >=20 > I think the I-D does not have any major issues and ready to be=20 > progressed. Good. Thanks for the review Raj! --julien _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From tsirtsis@googlemail.com Fri Dec 4 01:28:31 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330DA3A683D for ; Fri, 4 Dec 2009 01:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBJs2-5HTb0D for ; Fri, 4 Dec 2009 01:28:30 -0800 (PST) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 3907D3A67F5 for ; Fri, 4 Dec 2009 01:28:30 -0800 (PST) Received: by fxm10 with SMTP id 10so2499711fxm.14 for ; Fri, 04 Dec 2009 01:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sQ4KCiHeCQNhRv9HFreO+iWt9j7WlRDwhVmWxEfupTY=; b=CMR5QLfT154MC2hP35uh0o4AE8CRYmQjsIeos7rUbVvyYHB/arSRAMDxUugvCijiP9 4c0jPlQY6JAsJ1a3nYhGpdNHcSjIbZs2F5U9XSEIkf1Y+CyeVOmqz9FKc+N9RXvcHpHE NnaOTQcsYtttKn4MO5Brz2ZzjKn5SiJNV7AwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uNa3KX9PQEweopaJUHoLNckaT4WrxxT2xlG1AtQLNxtzanIC87NDKR//0d+BBVrsP9 xaRQggVEUPWzE9d7BphqCNGJZHvx1LVPGIzwDOzrKM5Tx/7ZPSqHzgKgiAaoTtoXk8f6 we3hwJOPiHZWbBR4Apk5l4p2gqnlzxUB9taSs= MIME-Version: 1.0 Received: by 10.239.170.34 with SMTP id q34mr321566hbe.3.1259918891839; Fri, 04 Dec 2009 01:28:11 -0800 (PST) In-Reply-To: <342737.79841.qm@web111404.mail.gq1.yahoo.com> References: <4AEFEBDE.6040903@ericsson.com> <342737.79841.qm@web111404.mail.gq1.yahoo.com> Date: Fri, 4 Dec 2009 09:28:11 +0000 Message-ID: From: George Tsirtsis To: Behcet Sarikaya Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-mext-flow-binding@tools.ietf.org, IETF MEXT WG ML Subject: Re: [MEXT] Flow Bindings WGLC output: pre-04 version X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 09:28:31 -0000 I think this question has more to do with RFC3775 and RFC5648 than this dra= ft. The source address of the BU is always sent out on the interface addressed with said source address to ensure that source address filtering does not cause the BU to be dropped. Nothing in this draft changes this normal behaviour. George On Tue, Dec 1, 2009 at 11:25 PM, Behcet Sarikaya wrote: > Hi George, > =C2=A0 I have a question on the draft. I was reading it and could not fig= ure out an answer for that, maybe you can help me? > > As for sending BU with flow identification mobility options, in case MN h= as more than one interface which is active, from which interface MN should = send the BU? I think that there is no problem in setting the source and des= tination addresses > the rules are pretty clear there but the interface selection does not see= m to be clarified in the text? > > Can you shed some light into this? > > Thanks in advance. > > Behcet > > > > From tsirtsis@googlemail.com Fri Dec 4 01:46:19 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133463A68AD for ; Fri, 4 Dec 2009 01:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN+qJgOxG+qq for ; Fri, 4 Dec 2009 01:46:18 -0800 (PST) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id C0FC63A67F5 for ; Fri, 4 Dec 2009 01:46:17 -0800 (PST) Received: by fxm10 with SMTP id 10so2513141fxm.14 for ; Fri, 04 Dec 2009 01:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=SiffvAGB1yDQcbW98TBqL8JO02jnfb0Zm6d2d/dSHzA=; b=rsQJYkY4FxDegp8hoFAJInmSKL9WSWvMIphVMuYGG4Cy/T68CtfK8Vr5cpttkbLXTw sa41O/8PqLPnUCBvQLaALe/XlvMRtOr1Zgg6nTH6XN6aWxUEStpDiY0mdcE10EGqO5Te IiY3RwtldNYC898X0IhD3GfG0Iq348T9RUrFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=bDwd/LudssHJAYTl6iADwjI0WufZiFmbk/fWZC+0dH827B8MAthaetKj/hfgmBNeik 2Wca/yiQDEBXYxJ2Dpc77pfpxkJOj+aogMNwA/LSxEQGQxzm4QwqoGKmcPAMno/63+gr rw29sMuDVdMjIc2oryHRKumSNxiYqGpyIy604= MIME-Version: 1.0 Received: by 10.239.143.219 with SMTP id l27mr269669hba.162.1259919964613; Fri, 04 Dec 2009 01:46:04 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Dec 2009 11:46:04 +0200 Message-ID: From: George Tsirtsis To: "Laganier, Julien" , "mext@ietf.org" , "draft-ietf-mext-binary-ts@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 09:46:19 -0000 Folks, thanks for the reviews and discussion on this draft. I was out of the office this week and I am traveling on business during the next but I will try to catch up as soon as I can. Thanks George On 11/18/09, Laganier, Julien wrote: > Folks, > > As stated during the meeting, we're starting a two weeks WGLC on our > "Traffic Selectors for Flow Bindings" document, available at the following > URL: > > > > Please review the specification, post your comments to the mailing list, and > state whether or not you think the document is ready to be forwarded to IESG > before 2009-12-02 6:00PM PST. > > Thank you for your support. > > --julien & marcelo, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From guoyuehua.bupt@gmail.com Wed Dec 9 03:23:50 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D966A3A69BA; Wed, 9 Dec 2009 03:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_81=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHuymUnqFM3h; Wed, 9 Dec 2009 03:23:50 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 218073A690B; Wed, 9 Dec 2009 03:23:50 -0800 (PST) Received: by pzk6 with SMTP id 6so5419378pzk.29 for ; Wed, 09 Dec 2009 03:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=XwJcbbKFwl9JvaVTp/6WSPUn8JC/K6TxwYjeKFvTR1M=; b=kj1pJOH9SJlyDAYzTzXx/a7dtI3QQP76E9hN6f7M09EQzlySy3JHWxSd/dH/HSy/PN VG8HpuWS6br58ls/3DV6v2aaGJrujDB7QeXg0ut4k0bdMJZmAkVhPW431rRIundqBZIu BCJayKOsCV3Ga5B41YigPtmob5RUFuoWn9X3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=D4cLKXpFbPaFPFTYGljXYMC2tTncIJfytxiHH7vLL5tl2K5oMHowZ5vsbgtd8lwoe7 lyMeoKNpJJ1fhLjhTuSUWtOZrk+9pNONogAU6NP7LMEGgdM0MeN6sBpXpHBMg1+eNkAS lyCw4Ie2lbgoW+YOqkR5pHafmYQ0aWpjysWkc= MIME-Version: 1.0 Received: by 10.142.74.20 with SMTP id w20mr1089405wfa.193.1260357816885; Wed, 09 Dec 2009 03:23:36 -0800 (PST) Date: Wed, 9 Dec 2009 19:23:36 +0800 Message-ID: From: =?UTF-8?B?6YOt6LeD5Y2O?= To: mext@ietf.org, mext-bounces@ietf.org Content-Type: multipart/alternative; boundary=001636e90cfdf72384047a49eb5f X-Mailman-Approved-At: Wed, 09 Dec 2009 08:00:48 -0800 Subject: [MEXT] hello, everyone,i have the question,thanks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 11:24:57 -0000 --001636e90cfdf72384047a49eb5f Content-Type: text/plain; charset=ISO-8859-1 Now i want to build an Dsmip experimental scenario in my lab. In the home link,there is the ha which has the ipv4 address and ipv6 address. In the foreign link,there is the AR,it is the dhcp server and i have installed the dhcp3-server package. I have configured the node and the server assigned the address from 192.168.5.* when the mn move from the home to the foreign, My understanding is that this moving node should get the ipv4 address automatically. But when i use the wireshark for capturing the packets in mn, I found that mn node always send the ARP packets, The contents of this package is to ask whether there are nodes which has the 192.168.5.11 address in the current network, and can not obtain the ipv4 address???? Has anyone known how to solve this problem? thans a lot --001636e90cfdf72384047a49eb5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Now i want to= build an Dsmip experimental scenario in my lab.=A0 In the home

lin= k,there is the ha which has the ipv4 address and ipv6 address. In the forei= gn

link,there is the AR,it is the dhcp server and i have installed the dhc= p3-server

package. I have configured the node and the server assigned the address= from 192.168.5.*
when the mn move from the=A0 home to the foreign, My = understanding is that this

moving node should get the ipv4 address = automatically. But when i use the

wireshark for capturing the packets in mn, I found that mn node always = send the

ARP packets, The contents of this package is to ask whethe= r there are nodes

which has the 192.168.5.11 address in the current= network, and can not obtain the

ipv4 address????
=A0=A0=A0 Has anyone known how to solve this proble= m? thans a lot

--001636e90cfdf72384047a49eb5f-- From sgundave@cisco.com Wed Dec 9 09:03:30 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F75F28C163; Wed, 9 Dec 2009 09:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.083 X-Spam-Level: X-Spam-Status: No, score=-4.083 tagged_above=-999 required=5 tests=[AWL=-2.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzZR0GrNqc52; Wed, 9 Dec 2009 09:03:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0B37C28C13F; Wed, 9 Dec 2009 09:03:26 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAJtmH0urRN+K/2dsb2JhbACEJpYPpgOGeQiQIYNVVwSBYg X-IronPort-AV: E=Sophos;i="4.47,369,1257120000"; d="scan'208,217";a="60249402" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 09 Dec 2009 17:03:15 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nB9H3Fg4006747; Wed, 9 Dec 2009 17:03:15 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 09:03:15 -0800 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Dec 2009 17:03:14 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 09 Dec 2009 09:03:46 -0800 From: Sri Gundavelli To: =?GB2312?B?ufnUvruq?= , , Message-ID: Thread-Topic: [MEXT] hello, everyone,i have the question,thanks Thread-Index: Acp48ZGtjntirNiRAUKEL7QfVgEpzA== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3343194230_81625107" X-OriginalArrivalTime: 09 Dec 2009 17:03:15.0023 (UTC) FILETIME=[7F36CDF0:01CA78F1] Subject: Re: [MEXT] hello, everyone,i have the question,thanks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 17:03:30 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3343194230_81625107 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable It appears to be performing the link-change detection after the interface flap. Per the DNAv4 procedures, most stacks like Windows wireless clients ARP for the default router on the link and if it won=A1=AFt get the response fr= om the default router, it will move the DHCP client state to INIT-REBOOT state and should obtain a new IPv4 address on that foreign link. Sri On 12/9/09 3:23 AM, "=B9=F9=D4=BE=BB=AA" wrote: > ackets in mn, I found that mn node always send the >=20 > ARP packets, The contents of this package is to ask whether there are nod= es >=20 > which has the 192.168.5.11 address in the current network, and can not ob= tain > the=20 >=20 > ipv4 address???? --B_3343194230_81625107 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable Re: [MEXT] hello, everyone,i have the question,thanks It appears to be performing the link-change detection after the interface = flap. Per the DNAv4 procedures, most stacks like Windows wireless clients AR= P for the default router on the link and if it won’t get the response = from the default router, it will move the DHCP client state to INIT-REBOOT s= tate and should obtain a new IPv4 address on that foreign link.

Sri

On 12/9/09 3:23 AM, "=B9=F9=D4=BE=BB=AA" <guoyuehua.bupt@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>ackets in mn, I found that mn node always send t= he

ARP packets, The contents of this package is to ask whether there are nodes=

which has the 192.168.5.11 address in the current network, and can not obta= in the

ipv4 address????

--B_3343194230_81625107-- From pstupar@qualcomm.com Thu Dec 10 08:42:06 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1235728C0D0 for ; Thu, 10 Dec 2009 08:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBF0otuZ3w7X for ; Thu, 10 Dec 2009 08:42:04 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C56693A6A9E for ; Thu, 10 Dec 2009 08:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=pstupar@qualcomm.com; q=dns/txt; s=qcdkim; t=1260463314; x=1291999314; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Stupar,=20Patrick"=20|To: =20"Laganier,=20Julien"=20,=20"mext @ietf.org"=20|CC:=20"draft-ietf-mext-binar y-ts@tools.ietf.org"=0D=0A=09|Date:=20Thu,=2010=20Dec=202009=2008:39:54 =20-0800|Subject:=20RE:=20[WGLC]=20draft-ietf-mext-binary -ts-01|Thread-Topic:=20[WGLC]=20draft-ietf-mext-binary-ts -01|Thread-Index:=20AcpoZ7tLGBWV4/j+TkKRHFf6ZYILLwRTjqmA |Message-ID:=20|References:=20|In-Reply-To:=20|Accept-Language:=20en- US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5827"=3B=20a=3D"29569502"; bh=UTLo+FR9pwwxIXMCYlDxSA4q5X9b1NjN2pV5eVHKl1c=; b=vye1DNUhAvYRXO38aCrhohYzr0nJdrJsa4opJut4UEngqSYe3hGSsbtQ 0Caqci9NUuyHejnxZDCTykEhYhjIEo/C9bTltGI4LvMj7oxCLh41KzyUO gmzKtvAWINlcpLqllHbzDwiVp3pvsFBLwICpzHmcgbNzdQKc32756Zm1B 8=; X-IronPort-AV: E=McAfee;i="5400,1158,5827"; a="29569502" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 10 Dec 2009 08:41:53 -0800 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nBAGfqxT026999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Dec 2009 08:41:53 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nBAGfqm8011327 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Dec 2009 08:41:52 -0800 (PST) Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 10 Dec 2009 08:41:52 -0800 Received: from NALASEXMB15.na.qualcomm.com ([10.47.5.229]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Thu, 10 Dec 2009 08:41:51 -0800 From: "Stupar, Patrick" To: "Laganier, Julien" , "mext@ietf.org" Date: Thu, 10 Dec 2009 08:39:54 -0800 Thread-Topic: [WGLC] draft-ietf-mext-binary-ts-01 Thread-Index: AcpoZ7tLGBWV4/j+TkKRHFf6ZYILLwRTjqmA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-mext-binary-ts@tools.ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 16:42:06 -0000 Hi all, I reviewed the draft (I hope I am not too late). Overall I think that the d= raft is in good shape and can be progressed. Here are my comments: The content of the draft needs to be aligned with the Traffic Selector sub-= option defined in draft-ietf-mext-flow-binding-04. This implies the followi= ng: -Section 3 title should not contain the word sub-options (this draft define= s a TS format not a sub-option) -Section 3 "The following values of the sub-option Type field, are reserved in this specification for binary traffic selectors" s/sub-option Type/ Traffic selector Format -Section 3.1 " If the Type field of the traffic selector sub-option indicates "IPv4 binary traffic selector",... " s/Type / TS Format The format of the IPv4 traffic selector needs to be updated accordingly wi= th draft-ietf-mext-flow-binding-04 -Section 3.2 " If the Type field of the traffic selector sub-option indicates "IPv6 binary traffic selector", then the traffic selector is formatted as follows:" s/Type / TS Format The format of the IPv6 traffic selector needs to be updated accordingly wi= th draft-ietf-mext-flow-binding-04 I also have a question for my understanding: in the definition of Start Des= tination address (C) for both IPv4 and IPv6 formats there is the following = sentence: " In other words this (i.e. the destination address) is one of the registered addresses of the mobile node." =09 My understanding was that this field should contain the mobile node Home Ad= dress. From 3775 my understanding is that the primary CoA is the registered= address. What am I missing? Regards, Patrick > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Laganier, Julien > Sent: Wednesday, November 18, 2009 4:57 PM > To: mext@ietf.org > Cc: draft-ietf-mext-binary-ts@tools.ietf.org > Subject: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 >=20 > Folks, >=20 > As stated during the meeting, we're starting a two weeks WGLC on our > "Traffic Selectors for Flow Bindings" document, available at the > following URL: >=20 > >=20 > Please review the specification, post your comments to the mailing > list, and state whether or not you think the document is ready to be > forwarded to IESG before 2009-12-02 6:00PM PST. >=20 > Thank you for your support. >=20 > --julien & marcelo, MEXT chairs > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From wudiyetc@gmail.com Fri Dec 11 01:35:51 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6393A6AA5 for ; Fri, 11 Dec 2009 01:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkw2XjM-fBeV for ; Fri, 11 Dec 2009 01:35:50 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 7CFAA3A6A96 for ; Fri, 11 Dec 2009 01:35:50 -0800 (PST) Received: by pzk6 with SMTP id 6so533205pzk.29 for ; Fri, 11 Dec 2009 01:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:x-mailer:mime-version:content-type; bh=nR2tktOTwT7TW/c/lhH0a+3kspZRWFaUT3UlVR238N0=; b=fzpFbAeqYLGCAIaNfVTP22tffjmiI7++/IXUhk+RaqDJ5kj/JWHqAW5RINoI7e/pPl aZuCV+R3vcTjRCnPuuM3SXictx6CeF+bU7wV7JLv+lIU4E1fFSqrx+1UDjUwdvC2CCfO tPpklYG3jfz2ux0chSg0Ni0ay4/55EOJO+JxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type; b=h/rBfQ99736ql9nnuy0RtoPiM2CY9tMsfvlbersR488f7tVIlmiFr55bV2/wSmQfww MOY6aSZ/jZvAsMW0osNgNWydpfz+dv93UCyo8Hpb1NASqVrDwCELKHJRA8oA99VmAJE1 qgF79qFaafUu0d82zAZWdzaiVImj85WEK4Lr8= Received: by 10.142.6.11 with SMTP id 11mr679849wff.79.1260524136266; Fri, 11 Dec 2009 01:35:36 -0800 (PST) Received: from bupt-feng ([125.33.184.163]) by mx.google.com with ESMTPS id 20sm1614018pzk.9.2009.12.11.01.35.29 (version=SSLv3 cipher=RC4-MD5); Fri, 11 Dec 2009 01:35:35 -0800 (PST) Date: Fri, 11 Dec 2009 17:35:29 +0800 From: "wudiyetc" To: "tsirtsis" , "tsirtsis" , "tsirtsis" , "tsirtsis" , "tsirtsis" , "tsirtsis" , "tsirtsis" Message-ID: <200912111735227185297@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon758534578508_=====" Cc: mext Subject: [MEXT] about draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 09:35:51 -0000 This is a multi-part message in MIME format. --=====003_Dragon758534578508_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit hello ,Tsirtsis I have reviewed the draft and have a question. What means about the "Start Source Address" and "End Source Address" ? I guess if the "Start Source Address" is 211.10.1.6, and the "End Source Address" is 211.10.1.10 then the packet with the source address 211.10.1.7 will matched. Is it wrong? Regards Wudi ye --=====003_Dragon758534578508_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit

hello ,Tsirtsis

I have reviewed the draft and have a question. What means about the "Start Source Address" and "End Source Address" ?

I guess if the "Start Source Address" is 211.10.1.6, and the "End Source Address" is 211.10.1.10

then the packet with the source address 211.10.1.7 will matched.

Is it wrong?

Regards

Wudi ye

--=====003_Dragon758534578508_=====-- From marcelo@it.uc3m.es Fri Dec 11 16:41:55 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2D13A69F0 for ; Fri, 11 Dec 2009 16:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.205 X-Spam-Level: X-Spam-Status: No, score=-5.205 tagged_above=-999 required=5 tests=[AWL=1.395, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3GxH3-tGuIX for ; Fri, 11 Dec 2009 16:41:54 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 26DC53A69A1 for ; Fri, 11 Dec 2009 16:41:53 -0800 (PST) Received: from r190-132-199-175.dialup.adsl.anteldata.net.uy (unknown [190.132.199.175]) by smtp02.uc3m.es (Postfix) with ESMTP id 1DFE06562DC for ; Sat, 12 Dec 2009 01:41:38 +0100 (CET) Message-ID: <4B22E6C0.30002@it.uc3m.es> Date: Sat, 12 Dec 2009 01:41:36 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17064.003 Subject: [MEXT] draft ietf76 minutes posted X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2009 00:41:55 -0000 Hi, you can find the draft minutes at: http://www.ietf.org/proceedings/09nov/minutes/mext.txt let us know if you want to change anything. Thanks Raj and Jouni for taking the minutes. Regards, marcelo From tsirtsis@googlemail.com Tue Dec 15 03:36:29 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997843A67FD for ; Tue, 15 Dec 2009 03:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl0q7MG0qW7R for ; Tue, 15 Dec 2009 03:36:28 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 6DD5D3A67A4 for ; Tue, 15 Dec 2009 03:36:28 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 16so322045fgg.13 for ; Tue, 15 Dec 2009 03:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=o58WVsPBLzOvlWS1HS7YzHd1LVpg+BShEzk4pgTu2Ss=; b=HT1gIJab1cvIosX7ujvCiy0LTi0pPV/nYlfQG5RWsRTgSQcALLteG90GowotRPAVLX 7NbBD174T0tYwZ8mSfTGsowYSEntPh6VWUFY6D14ojg41ZDtb6En9BDfWJmqrtxVs4h4 58RraP6nJDxQ8Le109jqSuDK6ejxkfh37ufeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XufOoLIg1FFn7rQCmSAo7RPlPg68ZIJPV4Xn3oYijvsItLfjJv6iVOne2aoDPK80zZ AdXztiIKErWX2cy5gMVPyXqT40xrHXnyeUXUqYY6xuM/wfsu2V+V2rDt1WfNz94eR2K0 foT+tDkiF5I4N9hHf7XeaGYM7C7ho2SE/i8iQ= MIME-Version: 1.0 Received: by 10.239.145.136 with SMTP id s8mr603396hba.46.1260876970697; Tue, 15 Dec 2009 03:36:10 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Dec 2009 11:36:10 +0000 Message-ID: From: George Tsirtsis To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] Review of I-D: draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 11:36:29 -0000 Hi Raj, I incorporated your comments, thanks Wildcards, as indicated by Julian, are indeed implemented by the absence of fields i.e., if no start/stop source address fields are indicated then "any" source address will match. IMO the title of the document does not need to be qualified with "Binary". "Simple" or otherwise since these are the first and only traffic selectors for now. The next type of TS that will be defined can qualify itself to differentiate with these. Regards George On Wed, Dec 2, 2009 at 3:53 PM, wrote: > > > Below are my review comments for the I-D: draft-ietf-mext-binary-ts-01 > > 1. s/If more than one contiguous source addresses need to be mached/If > =C2=A0 more than one contiguous source address needs to be matched > > 2. s/SPI values need to be mached/SPI values need to be matched > > 3. W.r.t the ports, does it make sense to have a wildcard flag which > =C2=A0 implies that no part matching needs to be done by the HA? > =C2=A0 The same might apply for the destination address field as well. > > 4. s/mached/matched in multiple places in the I-D > > 5. s/concenrs/concerns > > > One other suggestion: > > - The I-D is proposing traffic selectors which are specified in binary > =C2=A0format. In the future we could have other formats as well for > =C2=A0TS. Hence the title of the I-D should be "Binary format Traffic > =C2=A0Selectors for Flow Bindings" > > Summary: > -------- > > I think the I-D does not have any major issues and ready to be > progressed. > > -Basavaraj > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From tsirtsis@googlemail.com Tue Dec 15 03:36:47 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B5F3A6986 for ; Tue, 15 Dec 2009 03:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_FORM=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IQDmEES87Jp for ; Tue, 15 Dec 2009 03:36:45 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 5F5843A6767 for ; Tue, 15 Dec 2009 03:36:44 -0800 (PST) Received: by fxm7 with SMTP id 7so4056003fxm.29 for ; Tue, 15 Dec 2009 03:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3/EfjG8flm3GPdW9NGO8TI0GZGF/Qq3k4D2QJT/4jN8=; b=AJihYwIXJhnFIZRKeN2e3y+4cDkeaTjl4dECUvSrFQmLN9/0pK2rCgHWra5+Y7fK+E pUVDhdH/1O6/3k3deSVhBJ8SxQ6PptujRugtfQWk0FN/Op+ewrcDbVt+sLngf0Zwd6wQ BmPyO0sMYiQOedvd66H1dcHi7OzJplMzmWvA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y/7GwfKuruDYv11lDAUunJkeyNM+udTxw6Gxk1plvu0UwiVywzASM6/gntAJomCgYW vbG4zcaLO7CX9LHKT6M0WbBk+ucI4r3inUWvm/Oku+19QmfBLXJfyOrenYWEoCqpoJu2 WmJApZfq1NZgi2PQ2HcZm3v134vXXR3JiOrgY= MIME-Version: 1.0 Received: by 10.239.170.73 with SMTP id r9mr617803hbe.63.1260876987091; Tue, 15 Dec 2009 03:36:27 -0800 (PST) In-Reply-To: <4B136025.6070200@sg.panasonic.com> References: <4B136025.6070200@sg.panasonic.com> Date: Tue, 15 Dec 2009 11:36:26 +0000 Message-ID: From: George Tsirtsis To: Benjamin Lim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 11:36:47 -0000 Thanks Ben, All comments taken into account. George On Mon, Nov 30, 2009 at 6:03 AM, Benjamin Lim wrote: > Hi, > > I have reviewed the draft and have some questions/editorials stated below= . > > Regards, > Benjamin Lim > > ----------- >> Abstract >> >> This document defines binary formats for IPv4 and IPv6 traffic >> selectors to be used in conjuction with flow bindings for Mobile > [Ben] s/ conjuction/ conjunction > OK >> IPv6. > > ... > >> 2. =C2=A0Introduction >> >> This document defines binary formats for IPv4 and IPv6 Traffic >> Selector sub-options as defined in [I-D.ietf-mext-flow-binding]. >> >> The binary traffic selector sub-options defined here, allow efficient >> =C2=A0identification of flow(s) based on well known fields in IPv4 >> [RFC0791], IPv6 [RFC2460], and transport layer headers like TCP >> [RFC0793] and UDP [RFC0768]. > > [Ben] Propose to rephrase to "The binary traffic selector sub-options > defined here, allow for efficient..." > OK > ... > >> 3.1. =C2=A0IPv4 binary traffic selector > > ... > >> >> (B)End Source Address >> >> If more than one contiguous source addresses need to be mached > [Ben] s/ mached/ matched > OK >> then this field can be used to indicate the end value of a range >> starting from the value of the Start Source Address field. =C2=A0This >> field MUST NOT be included unless the Start Source Address field is >> included. =C2=A0When this field is included the receiver will match all = of >> the addresses between fields (A) and (B), inclusive of (A) and (B). > > [Ben] For clarification, if it is only to match one IP address of CN, > does it mean that "(A)Start Source Address" and "(B)End Source Address" > would be of the same IP address? The same question applies to those > fields that allow specifying ranges. > > ... GT> Yes, all of the "End" definitions start with "If more than one ..." >> >> (D)End Destination Address >> >> If more than one contiguous destination addresses need to be mached > [Ben] s/ mached/ matched > >> then this field can be used to indicate the end value of a >> range starting from the value of the Start Destination Address field. >> This field MUST NOT be included unless the Start Destination Address >> field is included. =C2=A0When this field is included the receiver will >> match all of the addresses between fields (C) and (D), inclusive of >> (C) and (D). > > ... > >> (F)End SPI - Security Parameter Index >> >> If more than one contiguous SPI values need to be mached then this > [Ben] s/ mached/ matched > >> field can be used to indicate the end value of a range starting from >> the value of the Start SPI field. =C2=A0This field MUST NOT be included >> unless the Start SPI field is included. =C2=A0When this field is include= d >> the receiver will match all of the SPI values between fields (E) and >> (F), inclusive of (E) and (F). > > ... > >> (H)End Source Port >> >> If more than one contiguous source port numbers need to be mached > [Ben] s/ mached/ matched > >> then this field can be used to indicate the end value of a range >> starting from the value of the Start Source Port field. =C2=A0This field >> MUST NOT be included unless the Start Source Port field is included. >> When this field is included the receiver will match all of the port >> numbers between fields (G) and (H), inclusive of (G) and (H). > > ... > >> (J)End Destination Port >> >> If more than one contiguous destination port numbers need to be >> mached then this field can be used to indicate the end value of a > [Ben] s/ mached/ matched > >> range starting from the value of the Start Destination Port field. >> This field MUST NOT be included unless the Start Destination Port >> field is included. =C2=A0When this field is included the receiver will >> match all of the port numbers between fields (I) and (K), > [Ben] s/ (K)/ (J) > >> inclusive of (I) and (J). >> >> (K)Start DS - Differential Services >> >> This field identifies the first differential services value, from the >> range of differential services values to be matched, on data packets >> as seen by the home agent. =C2=A0Note that this field is called Type of >> Service field in [RFC0791]. =C2=A0[RFC3260] then clarified that the fiel= d >> has been redefined as 6 bits DS field and 2 bits reserved, later >> claimed by Explicit Congestion Notification (ECN) [RFC3168]. =C2=A0For t= he >> purpose of this specification the DS field is 8bit long, were the 6 > [Ben] s/ 8bit/ 8 bits > >> most significant bits indicating the DS >> field to be matched and the 2 list significant bits MUST be set to 0 >> by the sender and ignored by the receiver. >> >> (L)End DS - Differential Services >> >> If more than one contiguous DS values need to be mached then this > [Ben] s/ mached/ matched > >> field can be used to indicate the end value of a range starting from >> the value of the Start DS field. =C2=A0This field MUST NOT be included >> unless the Start DS field is included. =C2=A0When this field is included >> the receiver will match all of the values between fields (K) and (L), >> inclusive of (K) and (L). > > [Ben] I assume that same note for (K) on how to format the bits in the > DS field applies to (L) also? I.e. For the purpose of this specification > the DS field is 8 bits long, were the 6 most significant bits indicating > the DS field to be matched and the 2 list significant bits MUST be set > to 0 by the sender and ignored by the receiver. > GT> Yes > ... > >> (N)End Protocol >> >> If more than one contiguous protocol values need to be mached then > [Ben] s/ mached/ matched > >> this field can be used to indicate the end value of a range starting >> from the value of the Start Protocol field. =C2=A0This field MUST NOT be >> included unless the Start Protocol field is included. When this field >> is included the receiver will match all of the values between fields >> (M) and (N), inclusive of (M) and (N). > > [Ben] For my understanding, can I ask what is the purpose of the > "Protocol field"? > GT> The Protocol field in the IPv4 header defines the next header e.g., UDP/TCP etc > ... > >> 3.2. =C2=A0IPv6 binary traffic selector > > ... > >> (B)End Source Address >> >> If more than one contiguous source addresses need to be mached > [Ben] s/ mached/ matched > >> then this field can be used to indicate the end value of a range >> starting from the value of the Start Source Address field. =C2=A0This >> field MUST NOT be included unless the Start Source Address field is >> included. =C2=A0When this field is included the receiver will match all = of >> the addresses between fields (A) and (B), inclusive of (A) and (B). > > ... > >> (D)End Destination Address >> >> If more than one contiguous destination addresses need to be mached > [Ben] s/ mached/ matched > >> then this field can be used to indicate the end value of a >> range starting from the value of the Start Destination Address field. >> This field MUST NOT be included unless the Start Destination Address >> field is included. =C2=A0When this field is included the receiver will >> match all of the addresses between fields (C) and (D), inclusive of >> (C) and (D). > > ... > >> (F)End SPI - Security Parameter Index >> >> If more than one contiguous SPI values need to be mached then this > [Ben] s/ mached/ matched > >> field can be used to indicate the end value of a range starting from >> the value of the Start SPI field. =C2=A0This field MUST NOT be included >> unless the Start SPI field is included. =C2=A0When this field is include= d >> the receiver will match all of the SPI values between fields (E) and >> (F), inclusive of (E) and (F). > > ... > >> (G)Start Flow Label >> >> This field identifies the first flow label value, from the range of >> flow label values to be matched, on data packets as seen by the home >> agent. =C2=A0According to [RFC2460] the flow label is 24-bit long. For t= he >> purpose of this specification the sender of this options MUST prefix >> flow label values with 8-bits of "0" before inserting it in this >> field. > [Ben] Reword the above sentence to "For the purpose of this > specification the sender of this option MUST prefix the flow label > values with 8-bits of "0" before inserting it into this field." > >> The receive SHOULD ignore the first 8-bits of > [Ben] s/ receive/ receiver > >> this field. >> >> (H)End Flow Label >> >> If more than one contiguous flow label values need to be mached > [Ben] s/ mached/ matched > >> then this field can be used to indicate the end value of a range >> starting from the value of the Start Flow Label field. =C2=A0This field >> MUST NOT be included unless the Start Flow Label field is included. >> When this field is included the receiver will match all of the flow >> label values between fields (G) and (H), inclusive of (G) and (H). > > ... > >> (J)End Source Port >> >> If more than one contiguous source port numbers need to be mached > [Ben] s/ mached/ matched > >> then this field can be used to indicate the end value of a range >> starting from the value of the Start Source Port field. =C2=A0This field >> MUST NOT be included unless the Start Source Port field is included. >> When this field is included the receiver will match all of the port >> numbers between fields (I) and (J), inclusive of (I) and (J). > > ... > >> (L)End Destination Port >> >> If more than one contiguous destination port numbers need to be >> mached then this field can be used to indicate the end value of a > [Ben] s/ mached/ matched > >> range starting from the value of the Start Destination Port field. >> This field MUST NOT be included unless the Start Destination Port >> field is included. =C2=A0When this field is included the receiver will >> match all of the port numbers between fields (K) and (L), inclusive >> of (K) and (L). >> >> (M)Start DS - Differential Services >> >> This field identifies the first differential services value, from the >> range of differential services values to be matched, on data packets >> as seen by the home agent. =C2=A0Note that this field is called Type of >> Service field in [RFC0791]. =C2=A0[RFC3260] then clarified that the fiel= d >> has been redefined as 6 bits DS field and 2 bits reserved, later >> claimed by Explicit Congestion Notification (ECN) [RFC3168]. =C2=A0For t= he >> purpose of this specification the DS field is 8bit long, were the 6 > [Ben] s/ 8bit/ 8 bits > >> most significant bits indicating the DS >> field to be matched and the 2 list significant bits MUST be set to 0 >> by the sender and ignored by the receiver. >> >> (N)End DS - Differential Services >> >> If more than one contiguous DS values need to be mached then this > [Ben] s/ mached/ matched > >> field can be used to indicate the end value of a range starting from >> the value of the Start DS field. =C2=A0This field MUST NOT be included >> unless the Start DS field is included. =C2=A0When this field is included >> the receiver will match all of the values between fields (M) and (N), >> inclusive of (M) and (N). > > [Ben] I assume that same note for (M) on how to format the bits in the > DS field applies to (N) also? I.e. For the purpose of this specification > the DS field is 8 bits long, were the 6 most significant bits indicating > the DS field to be matched and the 2 list significant bits MUST be set > to 0 by the sender and ignored by the receiver. > > ... > >> (P)End NH - Next Header >> >> If more than one contiguous next header values need to be mached > [Ben] s/ mached/ matched > >> then this field can be used to indicate the end value of a range >> starting from the value of the Start NH field. =C2=A0This field MUST NOT >> be included unless the Start next header field is included. When this >> field is included the receiver will match all of the values between >> fields (O) and (P), inclusive of (O) and (P). > > ... > >> 4. =C2=A0Security Considerations >> >> This draft defines the format of traffic selector sub-options defined >> =C2=A0in the flow bindings [I-D.ietf-mext-flow-binding]. =C2=A0The autho= rs have >> =C2=A0not identified any security concenrs pertaining to this draft beyo= nd > [Ben] s/ concenrs/ concerns > >> what is already identified in [I-D.ietf-mext-flow-binding]. > > ... > >> 6. =C2=A0Aknowledgements > [Ben] s/ Aknowledgements/ Acknowledgements > >> >> The authors would like to thank Patrick Stupar and Julien Laganier >> for their contributions to this document. > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From tsirtsis@googlemail.com Tue Dec 15 03:45:25 2009 Return-Path: X-Original-To: mext@core3.amsl.com Delivered-To: mext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B85F3A69E2 for ; Tue, 15 Dec 2009 03:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQkvUjOnPNOZ for ; Tue, 15 Dec 2009 03:45:24 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 6A1E73A69D0 for ; Tue, 15 Dec 2009 03:45:24 -0800 (PST) Received: by fxm7 with SMTP id 7so4063367fxm.29 for ; Tue, 15 Dec 2009 03:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vYUCtkXDzfX2raciEEI0e45beunDHG7JiWm7DJUkXGw=; b=ko7HLdccXUtn8QpWX6+yn3P/t/9ISlEUujS/8FEyK1mRUYikz4uGtg7kJw0IuhYbd4 lgSxyOJGJI0XNhtAhNS+DeLEnLeTwu/8bITovPUPu3TxE+EZ+3jgg+JGcbMEeOb1hflo irtrho+BkP1AMMwhv8vxosdln7PaFz7aynDNM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DtRgWYQ/2oBum1t45YI3zox+q8yGsUPltyghpxPcyxuXt0ENnjLB9M+I6RLY/cYAoM quNqJXUA16VfR57B2RzPwJcUTQ8Tw4zrXRrM8KwM65efBKLNc4F157TrxI+4rG/p37qJ hGnW7hOtVLXFVZp4rM/H/PLKMLKt7+AXwNroE= MIME-Version: 1.0 Received: by 10.239.188.201 with SMTP id q9mr600911hbh.189.1260877509590; Tue, 15 Dec 2009 03:45:09 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Dec 2009 11:45:09 +0000 Message-ID: From: George Tsirtsis To: "Laganier, Julien" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-mext-binary-ts@tools.ietf.org" , "mext@ietf.org" Subject: Re: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 11:45:25 -0000 Julien, thanks for the review...comments inline... On Mon, Nov 30, 2009 at 9:44 PM, Laganier, Julien wr= ote: > Folks - > > This is my hat-less draft review: > > I think the draft is ready provided that the minor points below are addre= ssed: > > 1- We should include the following alignments requirements for the sub-op= tions: > > * IPv4 TS: > - 4n aligned if A, B, C, D, E or F is set > - 2n aligned if G, H, I or J is set > - n aligned otherwise > > * IPv6 TS: > - 8n aligned if A, B, C, or D is set > - 4n aligned if E, F, G, or H is set > - 2n aligned if I, J, K, or L is set > - n aligned otherwise > GT> Thanks Julien, I added these. > 2- I feel that the text describing the Start/End field for ranges could b= e made simpler by formulating a la RFC 4306 (IKEv2), as per this template: > > * Start () - Value specifying the smallest > =C2=A0 =C2=A0 =C2=A0allowed by this Traffic Selector. If the End