From Andreas.Ripke@neclab.eu Mon Feb 3 01:01:50 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B351A0192 for ; Mon, 3 Feb 2014 01:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL3mRbSj7K8u for ; Mon, 3 Feb 2014 01:01:48 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 44C921A0170 for ; Mon, 3 Feb 2014 01:01:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 41D9B106B03 for ; Mon, 3 Feb 2014 10:01:43 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29+Zu+y8GjTu for ; Mon, 3 Feb 2014 10:01:43 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 21A6A106AFD for ; Mon, 3 Feb 2014 10:01:38 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.144]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 3 Feb 2014 10:01:17 +0100 From: Andreas Ripke To: "pcp@ietf.org" Thread-Topic: question on PCP proxy Thread-Index: Ac8gvFDLhr31xMV/QN2urUMIZaUWWA== Date: Mon, 3 Feb 2014 09:01:15 +0000 Message-ID: <2D2FFE4726FAF74285C45D69FDC30E79631C65CF@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.215] Content-Type: multipart/alternative; boundary="_000_2D2FFE4726FAF74285C45D69FDC30E79631C65CFDAPHNISofficehd_" MIME-Version: 1.0 Subject: [pcp] question on PCP proxy X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 09:01:50 -0000 --_000_2D2FFE4726FAF74285C45D69FDC30E79631C65CFDAPHNISofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am writing to inquire about the status of draft-ietf-pcp-proxy that recen= tly expired. What are the pending issues with this draft and is there any intention to r= evive it? Thanks. Best, Andreas NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End= Road, London, HA4 6QE, GB | Registered in England 2832014 --_000_2D2FFE4726FAF74285C45D69FDC30E79631C65CFDAPHNISofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am writing to inquire about the status of draft-ie= tf-pcp-proxy that recently expired.

What are the pending issues with this draft and is t= here any intention to revive it?

 

Thanks.

 

Best,

 

Andreas

 

 

NEC Europe Ltd | Registered Office: Athene, Odyssey = Business Park, West End  Road, London, HA4 6QE, GB | Registered in Eng= land 2832014

 

--_000_2D2FFE4726FAF74285C45D69FDC30E79631C65CFDAPHNISofficehd_-- From tireddy@cisco.com Mon Feb 3 06:07:25 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D4D1A00C7 for ; Mon, 3 Feb 2014 06:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.436 X-Spam-Level: X-Spam-Status: No, score=-9.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBoqeAhql4-O for ; Mon, 3 Feb 2014 06:07:20 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 285A81A01CF for ; Mon, 3 Feb 2014 06:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4923; q=dns/txt; s=iport; t=1391436291; x=1392645891; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=8pq/V6YQ9DUxr1STJAdmYRErqkfkJno6C3j3yOOjX8o=; b=B0ZLpFDmyXLSPPYuhLYLNggG36IS8WaSk/SR0MQeMs6gbVF6E/V8NEiV yiGkc8ep4Gb1qIxjcyKCRAQex1shmOBUCHgK6N575zJq1VREKtC64d9MM /32Z0ZjX5P1tSwcQeqagLH1ZMtyNxx/L0b16mKwjZ3RTUAnW1fzpx4joW 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAIqh71KtJXHA/2dsb2JhbABPCoMMOEsMvgiBCBZ0giUBAQEEeRIBCBEEAQELGT0dCQEEAQ0FCAGHfA3MQxeOLSsxgyuBFASJEZBLkG+Bb4E+gWgCHgIEHBE X-IronPort-AV: E=Sophos;i="4.95,772,1384300800"; d="scan'208";a="17525685" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-4.cisco.com with ESMTP; 03 Feb 2014 14:04:50 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s13E4ook016409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Feb 2014 14:04:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 08:04:50 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Anca Zamfir (ancaz)" , "Reinaldo Penno (repenno)" , "Dan Wing (dwing)" , "Prashanth Patil (praspati)" Thread-Topic: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Thread-Index: Ac8g6OM9iZ7sffF+Q5SWt1ojcC5EYg== Date: Mon, 3 Feb 2014 14:04:50 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242A5956@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.51.29] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:07:25 -0000 Hi Anca, Thanks for the review. Please see inline [TR] From: Anca Zamfir (ancaz)=20 Sent: Wednesday, January 29, 2014 4:56 PM To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing (dwing= ); Prashanth Patil (praspati) Cc: pcp@ietf.org Subject: [pcp] Comments on PCP Extension for Third Party Authorization (htt= p://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Hi Tiru et al, A few comments and questions on this draft.=A0 Section 4: . Figure 1: could you identify the entities you mention in the text below i= t? Like PCP Client (Alice box), Oauth 2.0 server (does it have to be the We= bRTC or could it be separate?) [TR] Yes, updated. . I don't understand the paragraph after bullet 4 and how is relevant to th= is section/ draft? What do you mean by "This technique"? [TR] Replaced "This technique" with " The technique proposed in the specifi= cation".=20 The paragraph explains how this technique can be used with PCP-aware NAT to= permit MAP request after the client has got the token.=20 Section 5: . Figure 3: Show a bidirectional Request/ Response on (1). Show a (5) arrow= with PCP Response so the loop is closed. [TR] Fixed. . Same question as above. Does the Auth Server has to be the WebRTC Server = (or app server in general)? Or is this figure just a possible scenario ? [TR] Yes, The authorization server in this specific example has to be the= WebRTC server because only it will be aware of call termination details to= revoke the token. . Create section 5.1 for the option detail and say something like "This spe= cification defines the new PCP ACCESS_TOKEN Option." [TR] ok. . Option Length: Is this like any PCP option (i.e. length of Option Data, m= ust be multiple of 4, etc). Maybe just refer to RFC6887 Section 7.3 [TR] Yes and its variable length. . "Reserved1": set to 0 by sender and ignored by the receiver? [TR] Added =20 Lifetime: Why does the PCP Client need to tell the PCP Server about the lif= etime? Is this the expires_in value that the PCP Client got from the Auth S= erver? Can this be "extended" later in a PCP Request by the PCP Client/ Ali= ce or Mallory? And what would happen? I thought the PCP Server =A0must ensu= re that the token has not expired by interacting with the authorization ser= ver (e.g. on arrow (4) in your Figure 3, the Auth server would also include= the lifetime). I don't understand why it's needed in the PCP Option. [TR] The PCP servers uses the lifetime field to do local validation before = interacting with the Authorization Server for further checks. Yes, this is = the expires_in value that the PCP Client got from the Authorization server.= Performing local validation is just a minor benefit and anyways the PCP S= erver will ensure that the token has not expired by interacting with the au= thorization server. . Timestamp : This assumes some sort of synchronization, right? Then I don'= t understand how the Timestamp on its own can prevent replay attacks. Maybe= you can elaborate on this a bit? [TR] Sure.=20 Using the formula "Lifetime + Delta > abs(RDnew - TSnew)" defined in sectio= n 7 of the draft, PCP server can find out if the Timestamp field in the ACC= ESS_TOKEN option is too old when compared to the receipt of the PCP request= . . May appear in: response...I don't see any explanation on when PCP Server = would include it in response and what is the PCP Client supposed to do/ che= ck. Maybe you can say a few words about this in Sections 5.2 and 5.3=A0 [TR] If the token is valid then the PCP server generates a success PCP resp= onse (it's the same as in RFC 6887, no changes) . Probably out of scope but what happens on mapping refresh, PCP server res= tart, etc? Will PCP Client get new token, reuse the old one, etc? Maybe giv= e some hints on good practices? [TR] It's covered in Section 7 "Security Considerations" A PCP server will delete explicit dynamic mappings after the lifetime of th= e cryptographic token expires. The PCP client must obtain a new cryptograph= ic token from the authorization server before the current token becomes inv= alid or expires. The PCP client must propagate the new cryptographic token = to the PCP server to refresh lifetime of mappings before the current token = becomes invalid or expires Section 6: . PCP Proxy question: What are the possible actions here wrt to the TOKEN o= ption? Just forward or drop (e.g. if unknown and configured to drop unknown= s)?=A0 [TR] PCP Proxy will replay the ACCESS_TOKEN option because it's a mandator= y-to-process option. For more information on the PCP proxy behavior w.r.t m= andatory-to-process option please refer to section 7 in http://tools.ietf.o= rg/html/draft-ietf-pcp-proxy-04#section-7=20 Cheers, -Tiru. thanks, -anca From simon.perreault@viagenie.ca Mon Feb 3 07:44:32 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE911A0155 for ; Mon, 3 Feb 2014 07:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGm_mi4jKEPx for ; Mon, 3 Feb 2014 07:44:29 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB371A0199 for ; Mon, 3 Feb 2014 07:44:29 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id F370B40379 for ; Mon, 3 Feb 2014 10:44:28 -0500 (EST) Message-ID: <52EFB95C.9080605@viagenie.ca> Date: Mon, 03 Feb 2014 10:44:28 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@ietf.org References: <2D2FFE4726FAF74285C45D69FDC30E79631C65CF@DAPHNIS.office.hd> In-Reply-To: <2D2FFE4726FAF74285C45D69FDC30E79631C65CF@DAPHNIS.office.hd> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [pcp] question on PCP proxy X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:44:32 -0000 Le 2014-02-03 04:01, Andreas Ripke a écrit : > I am writing to inquire about the status of draft-ietf-pcp-proxy that > recently expired. > > What are the pending issues with this draft and is there any intention > to revive it? A new revision should be posted very very very very soon... :) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From rjsparks@nostrum.com Mon Feb 3 15:06:30 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0261A027B; Mon, 3 Feb 2014 15:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBEVV-F5TbfS; Mon, 3 Feb 2014 15:06:29 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6253F1A0267; Mon, 3 Feb 2014 15:06:29 -0800 (PST) Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s13N6Tco047547 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 3 Feb 2014 17:06:29 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <52F020FE.6090904@nostrum.com> Date: Mon, 03 Feb 2014 17:06:38 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: General Area Review Team , pcp@ietf.org, draft-ietf-pcp-nat64-prefix64@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism) Subject: [pcp] Gen-art LC review: draft-ietf-pcp-nat64-prefix64-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 23:06:30 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pcp-nat64-prefix64-04 Reviewer: Robert Sparks Review Date: 3-Jan-2014 IETF LC End Date: 4-Jan-2014 IESG Telechat date: Unknown Summary: Ready with Nits Nits/editorial comments: There are several references to expired drafts (some very expired). If those are not going to progress, the details you wanted to call out would be better moved here. It's not clear which of the results in nat64-experiments you are pointing to for support for this document. Is the reference necessary? If so, can it be made more specific. In section 4.1, you restate the allowed values for length from RFC6052. Consider making the statement even clearer that these values are a consequence of RFC6052 and aren't being defined by this document. Something like "The allowed values are specified in RFC6052 (currently 4,5,6,7,8,12). (I almost didn't include this since that set's not likely to change, but somebody might copy the style...) RjS From internet-drafts@ietf.org Mon Feb 3 22:38:45 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575931A037B; Mon, 3 Feb 2014 22:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yQZGrJQjRwx; Mon, 3 Feb 2014 22:38:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EE81A0371; Mon, 3 Feb 2014 22:38:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140204063844.24004.20992.idtracker@ietfa.amsl.com> Date: Mon, 03 Feb 2014 22:38:44 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-description-option-04.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 06:38:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : PCP Description Option Authors : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-description-option-04.txt Pages : 6 Date : 2014-02-03 Abstract: This document extends Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does so by defining a new DESCRIPTION option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-description-option/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-description-option-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-description-option-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 3 22:58:03 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611411A038C; Mon, 3 Feb 2014 22:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgESn-rudVYZ; Mon, 3 Feb 2014 22:58:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA261A0385; Mon, 3 Feb 2014 22:58:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140204065801.26408.27074.idtracker@ietfa.amsl.com> Date: Mon, 03 Feb 2014 22:58:01 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-nat64-prefix64-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 06:58:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : Learning NAT64 PREFIX64s using Port Control Protocol (PCP) Author : Mohamed Boucadair Filename : draft-ietf-pcp-nat64-prefix64-05.txt Pages : 17 Date : 2014-02-03 Abstract: This document defines a new Port Control Protocol (PCP) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This option is needed for successful communications when IPv4 addresses are used in referrals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-nat64-prefix64-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Feb 4 08:58:04 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C481A0135; Tue, 4 Feb 2014 08:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV8sxLSyfhi5; Tue, 4 Feb 2014 08:58:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8121A019F; Tue, 4 Feb 2014 08:58:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140204165802.24244.94984.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2014 08:58:02 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-proxy-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:58:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : Port Control Protocol (PCP) Proxy Function Authors : Simon Perreault Mohamed Boucadair Reinaldo Penno Dan Wing Stuart Cheshire Filename : draft-ietf-pcp-proxy-05.txt Pages : 12 Date : 2014-01-29 Abstract: This document specifies a new PCP functional element denoted as a PCP Proxy. The PCP Proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that can not be configured with the address of a PCP server located more than one hop away. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-proxy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-proxy-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-proxy-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Tue Feb 4 09:05:29 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BAF1A020A for ; Tue, 4 Feb 2014 09:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blTkC64vwKQN for ; Tue, 4 Feb 2014 09:05:27 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 347181A011D for ; Tue, 4 Feb 2014 09:05:27 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AB4734037A for ; Tue, 4 Feb 2014 12:05:26 -0500 (EST) Message-ID: <52F11DD6.2090004@viagenie.ca> Date: Tue, 04 Feb 2014 12:05:26 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@ietf.org References: <20140204165802.24244.94984.idtracker@ietfa.amsl.com> In-Reply-To: <20140204165802.24244.94984.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [pcp] I-D Action: draft-ietf-pcp-proxy-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 17:05:29 -0000 All, This new revision is a merge between -04 and draft-cheshire-recursive-pcp. The general aim was to define the proxy as a back-to-back server and client, while ensuring that unknown opcodes were propagated upstream. Discuss! :) Simon Le 2014-02-04 11:58, internet-drafts@ietf.org a écrit : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Port Control Protocol Working Group of the IETF. > > Title : Port Control Protocol (PCP) Proxy Function > Authors : Simon Perreault > Mohamed Boucadair > Reinaldo Penno > Dan Wing > Stuart Cheshire > Filename : draft-ietf-pcp-proxy-05.txt > Pages : 12 > Date : 2014-01-29 > > Abstract: > This document specifies a new PCP functional element denoted as a PCP > Proxy. The PCP Proxy relays PCP requests received from PCP clients > to upstream PCP server(s). A typical deployment usage of this > function is to help establish successful PCP communications for PCP > clients that can not be configured with the address of a PCP server > located more than one hop away. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pcp-proxy/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pcp-proxy-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-proxy-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tireddy@cisco.com Wed Feb 5 05:49:07 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD2A1A0149 for ; Wed, 5 Feb 2014 05:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70JdrWdFaRjR for ; Wed, 5 Feb 2014 05:49:06 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1852E1A012D for ; Wed, 5 Feb 2014 05:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2726; q=dns/txt; s=iport; t=1391608145; x=1392817745; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=iiAn5gkL0sxwX5VoMsrxmp7NL9swzmgaeTDwwyBChXE=; b=QizhqQ+arfWZJf50d9iI28DPQtcdy6NBtzq5FI2UyVKO8+27NpkrlO4Y r0XSTNa3rUGNb4LxrzfWdwXJOOEAPZ9o9PN12q/7BdtVUMZO0tGM1KcLV zMylHCboldQBNF8WBTL6AwkwAwZZuTqkf9c9QlmiVK86+WYcQJ7CVcK2T Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFABFB8lKtJV2c/2dsb2JhbABZgww4UQaDAbtCGHcWdIIlAQEBBCMRQw4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBBMIAYd8CAWteqE0F4EpjRs4BoJpNYEUBJldkG+DLYIq X-IronPort-AV: E=Sophos;i="4.95,786,1384300800"; d="scan'208";a="301981051" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 05 Feb 2014 13:49:05 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s15Dn5XP012655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Feb 2014 13:49:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 07:49:04 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "pcp@ietf.org" Thread-Topic: New Version Notification for draft-wing-pcp-third-party-authz-02.txt Thread-Index: AQHPInihkrAT5A4qwUqSM0P2ssdBwpqmrOrw Date: Wed, 5 Feb 2014 13:49:04 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242A8343@xmb-rcd-x10.cisco.com> References: <20140205134608.386.45135.idtracker@ietfa.amsl.com> In-Reply-To: <20140205134608.386.45135.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.61.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [pcp] FW: New Version Notification for draft-wing-pcp-third-party-authz-02.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 13:49:08 -0000 UmV2aXNlZCBkcmFmdC13aW5nLXBjcC10aGlyZC1wYXJ0eS1hdXRoei0wMiBoYXMgYmVlbiBwdWJs aXNoZWQuIFRoZSB1cGRhdGUgaW5jb3Jwb3JhdGVzIHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9t IHRoZSBXRy4gRnVydGhlciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoN ClRoYW5rcyBhbmQgUmVnYXJkcywNCi1BdXRob3JzLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXSANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNzoxNiBQ TQ0KVG86IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRp cmVkZHkpOyBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KTsgRGFuIFdpbmcgKGR3aW5nKTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBEYW4g V2luZyAoZHdpbmcpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykNClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFydHktYXV0aHotMDIu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdpbmctcGNwLXRoaXJkLXBhcnR5 LWF1dGh6LTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFs ZXN3YXIgUmVkZHkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJ ZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFydHktYXV0aHoNClJldmlzaW9uOgkwMg0KVGl0bGU6CQlQ Q1AgRXh0ZW5zaW9uIGZvciBUaGlyZCBQYXJ0eSBBdXRob3JpemF0aW9uDQpEb2N1bWVudCBkYXRl OgkyMDE0LTAyLTA1DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxNQ0K VVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXdpbmctcGNwLXRoaXJkLXBhcnR5LWF1dGh6LTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdpbmctcGNwLXRoaXJkLXBhcnR5LWF1 dGh6Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdp bmctcGNwLXRoaXJkLXBhcnR5LWF1dGh6LTAyDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFydHktYXV0aHotMDIN Cg0KQWJzdHJhY3Q6DQogICBJdCBpcyBvZnRlbiBkZXNpcmFibGUgZm9yIGFuIGFwcGxpY2F0aW9u IHNlcnZlciB0byBwZXJtaXQgYSBmbG93DQogICBhY3Jvc3MgYSBmaXJld2FsbCwgYXMgaGFwcGVu cyB0b2RheSB3aGVuIGEgZmlyZXdhbGwgaW5jbHVkZXMgYW4NCiAgIEFwcGxpY2F0aW9uIExheWVy IEdhdGV3YXkgKEFMRykgZnVuY3Rpb24uICBIb3dldmVyLCBhbiBBTEcgaGFzDQogICBzZXZlcmFs IHdlYWtuZXNzZXMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgY3J5cHRvZ3JhcGhp YyB0ZWNobmlxdWUgZm9yIGFuIGFwcGxpY2F0aW9uDQogICBzZXJ2ZXIgdG8gcGVybWl0IGEgZmxv dyBhY3Jvc3MgYSBmaXJld2FsbC4gIFRoaXMgdGVjaG5pcXVlIHVzZXMgT0F1dGgNCiAgIGFuZCBh IG5ldyBQQ1Agb3B0aW9uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From tireddy@cisco.com Wed Feb 5 10:33:43 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EA91A0138 for ; Wed, 5 Feb 2014 10:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izhb5lIG4IpU for ; Wed, 5 Feb 2014 10:33:41 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id F1C8B1A0132 for ; Wed, 5 Feb 2014 10:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7124; q=dns/txt; s=iport; t=1391625220; x=1392834820; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=5BeROcLn1/28sy0RopCHhzIk3xTsNVHdegU4NKsikqw=; b=E4mvYXeHUJ2A3ETGXB4DmEN8Loy8TFg6SQe4md1Egg85wqWIiIfS+8mw kHBe660T47lq/kF3j9sjWCNGzohxofrLItIgAZzOTzDyY5ZtbX7QOovem ELmS9odZJXXTh5KxMH2YD+UTUekAzbqGm0IO3DZ1v2QwP9gvjZoY+YWxT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMFAJqD8lKtJXG8/2dsb2JhbABPCoMMOFe+TIEQFnSCJQEBAQSBCwEIEQQBAQsdORQJCQEEARIIE4dqDc50F44UBQUKHINcgRQEiRGQTJBvgy2BaUE X-IronPort-AV: E=Sophos;i="4.95,788,1384300800"; d="scan'208";a="18215611" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-1.cisco.com with ESMTP; 05 Feb 2014 18:33:39 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s15IXd8U015728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 18:33:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 12:33:39 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Ben McCann , "pcp@ietf.org" Thread-Topic: [pcp] Draft-wing-pcp-flowdata-000 Comments Thread-Index: Ac8ioMUrjNvuc54eQby5psLfys81zA== Date: Wed, 5 Feb 2014 18:33:38 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242A86F8@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.34.133] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Draft-wing-pcp-flowdata-000 Comments X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 18:33:43 -0000 Hi Ben, Thanks for the detailed review. Please see inline [TR] From: Ben McCann [mailto:B.McCann@F5.com]=20 Sent: Wednesday, January 29, 2014 2:25 AM To: pcp@ietf.org Subject: [pcp] Draft-wing-pcp-flowdata-000 Comments Hi Dan, Reinaldo, and Tiru, I have a few comments and questions on your PCP flowdata draft. Overall, it= looks good. To summarize, this PCP enhancement enables an application attached to an ac= cess network to signal its resource (bandwidth, etc) requirements to the ne= twork via a PCP server. The PCP server reserves none, some, or all of the r= equested resources and returns a response describing that reservation. . Section 1: Recursively forwarding PCP FlowData requests hop-by-hop throug= h the access network is an elegant solution for reserving resources from th= e application to the boundary between the access network and the Internet. = That said, =A0does this introduce scaling problems ? o Are there administrative scaling challenges for large access networks wit= h many switches and routers? Do most of them have to be configured with PCP= servers for the reservation system to be effective? [TR] Not all switches and routers in large access network need to be PCP-aw= are. PCP server in the access network can convey the information to the SDN= controller (Policy Decision Point) which in turn installs flow in network = devices. For more information refer to draft http://tools.ietf.org/html/dra= ft-penno-pcp-asdn-00=20 o Can upstream PCP servers handle all of the individual reservation request= s arriving from multiple downstream PCP servers? Is some kind of reservatio= n aggregation mechanism required to scale to 1000's or 10000s of reservatio= ns? . Section 3.2 & Figure 3: Does the FlowData option in a MAP request define = the aggregate resource requirements for all matching inbound flows going to= the application sending that MAP request or is the reservation per flow? B= oth options have issues: o If the reservation is for all flows, then the resource manager can easily= reserve resources (bandwidth, etc) in aggregate for that application. That= simplifies resource allocation but it is extremely inefficient because res= ources are pre-allocated for flows that may never arrive. o If the reservation is per flow, then how does the resource manager know h= ow many resources to reserve? If the MAP request FlowData option only descr= ibes the resource requirements for one flow, then how does the resource res= ervation system know how many flows to expect? IMHO, both of these options are broken. Instead, the FlowData option should= : o Describe the resource requirements per flow. The CGNAT/Firewall/Etc must = reserve resources incrementally as clients connect to the mapped server. Th= is provides some level of fairness across multiple servers using the MAP re= quest. o Define the maximum number of flows that are expected. The PCP server may = return a smaller number in the MAP reply if this is excessive. The CGNAT ma= y reject inbound connections that exceed this upper bound to ensure it has = resources for other mapped servers. o Define the behavior of the connection when resources (as defined in the M= AP request) are unavailable. Should the CGNAT fall back to "best effort", d= rop the SYN packet and let the client retry, send back something in ICMP, o= r should it reject the connection request with a RST? (Examples are admitte= dly TCP-centric). In summary, FlowData should describe resources per flow, how many flows are= expected, and how to handle new inbound flows when resources are unavailab= le. Note that the CGNAT/Firewall handles resource reservation errors autonomous= ly because, IMHO, sending PCP packets back to the client when resources are= low introduces unacceptable DoS attack vectors. [TR] Good point. The reason for supporting FLOWDATA with MAP is to use it i= n SIP/WebRTC calls where an endpoint with multiple interfaces (3G, Wifi etc= ) can use MAP with FLOWDATA on each available interface to find if any of t= he networks can meet the requested flow characteristics, so that the appli= cation can prioritize the host candidates accordingly based on FLOWDATA res= ponse. In this case it would be only be one flow per MAP request. The scen= ario you have mentioned would be typically used by servers and would use MA= P for multiple flows. we will define the behavior of FLOWDATA option with = MAP opcode in the next revision.=20 . Section 6: Why do we need a separate authorization mechanism for FlowData= ? The client's identify is verified during PCP Authentication so why doesn'= t the PCP server consult a policy server at that time to determine the clie= nt's resource reservation privileges? We don't need a separate crypto-token= for FlowData because the whole PCP request is signed by the PCP Authentica= tion Tag. We should also avoid authorizing individual FlowData requests to = an external server because it won't scale. [TR] PCP third party authorization is required only for some applications. = For example in a scenario where access network has business agreement with = Netflix, Hulu Plus etc. HTTP Adaptive Streaming client will send PCP reques= t with access token option so that the access network can prioritize the on= e-way streaming content. Usage of PCP third party authorization in Mobile n= etworks is explained http://tools.ietf.org/search/draft-penno-pcp-mobile-qo= s-00, where PCP requests with third party authorization will be mapped to Q= CI values 1 to 4 and Bandwidth Minimum value in FLOWDATA option will be map= ped to Guaranteed bit rate (GBR). PCP requests without third party authoriz= ation will also be honored but mapped only to QCI values 6 to 8 (Non- GBR).= =20 . (Other) Should the FlowData option define enforcement policies for non-co= nformant flows that exceed their bandwidth reservation? For example, best e= ffort, some flavor of random early discard, rate shaping, etc, etc.? The al= ternative is that the reservation enforcement policy is statically defined = per hop and that it is unaware of the best protocol-dependent method to enf= orce bandwidth reservations. [TR] Yes, FlowData option should enforce policies for flows which lie or mi= sbehave. In section 3.3 this problem is discussed A PCP server that processes the FLOWDATA option is likely to create state for that flow (e.g., for bandwidth counting so that the bandwidth is returned to the bandwidth pool when the flow lifetime expires). Because Memory and other resources limit how much state can be created, the PCP server MUST implement a policy limit so that all state is not consumed by one host. It MAY also implement other limits, such as rate limits. The PCP server can implement its own policy to remove flows from its memory, such as FIFO. If a host has exceeded its quota, the existing error USER_EX_QUOTA SHOULD be returned. =20 Cheers, -Tiru. Ben McCann, F5 Networks From repenno@cisco.com Thu Feb 6 11:54:26 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58031A044C for ; Thu, 6 Feb 2014 11:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLmUOqaxchH3 for ; Thu, 6 Feb 2014 11:54:25 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id A27791A03ED for ; Thu, 6 Feb 2014 11:54:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1002; q=dns/txt; s=iport; t=1391716464; x=1392926064; h=from:to:subject:date:message-id:mime-version; bh=xpjEzAteabTnCEVL+zMNYR8q47N+v9gg4mB8RB+c6rA=; b=ivzgvFoYZvNopMEkKgv5G+HRDnGeK1p6I8RJYYJW57JN6591ognoQOgH TvAvV5M/EigRuxw3UpZFZlL+FeF842M8o2aMjdBc8uxSoGvsP9n7qijRP tX3dvqgcvRnCYguK+vujlKUbUakaRXUGng0L2Vs0pzwHfAMSzASoRCP/W I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFALfn81KtJXHB/2dsb2JhbABZgkhEgQ++aYEXFnSCLB1uAQsBAnInBIgYnQGwDheOJoUTBJgrkiGDLYIq X-IronPort-AV: E=Sophos;i="4.95,795,1384300800"; d="scan'208,217";a="18545719" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-2.cisco.com with ESMTP; 06 Feb 2014 19:54:24 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s16JsO42016252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 6 Feb 2014 19:54:24 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 13:54:24 -0600 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: PCP WG Call for Presentation - IETF London Thread-Index: AQHPI3U71M6Y0T32I0K+YWkcpYErOQ== Date: Thu, 6 Feb 2014 19:54:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.112.52] Content-Type: multipart/alternative; boundary="_000_CF19286E8AFCrepennociscocom_" MIME-Version: 1.0 Subject: [pcp] PCP WG Call for Presentation - IETF London X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 19:54:26 -0000 --_000_CF19286E8AFCrepennociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you would like to present, please send title, time needed, presenter and= pointer to draft (if exists). Thanks, Chairs --_000_CF19286E8AFCrepennociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
If you would like to present, please send title, time needed, presente= r and pointer to draft (if exists).

Thanks,

Chairs
--_000_CF19286E8AFCrepennociscocom_-- From dthaler@microsoft.com Fri Feb 7 18:35:09 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B2E1AD947 for ; Fri, 7 Feb 2014 18:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7BAHy4HdQjc for ; Fri, 7 Feb 2014 18:35:07 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8371A046C for ; Fri, 7 Feb 2014 18:35:07 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.0.873.15; Sat, 8 Feb 2014 02:35:05 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0873.009; Sat, 8 Feb 2014 02:35:05 +0000 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21 Thread-Index: Ac8kdjJMiw3eyGvqT6mQAxskuNkKaQ== Date: Sat, 8 Feb 2014 02:35:05 +0000 Message-ID: <8242767cd57c4b6c94759273739404b7@BY2PR03MB412.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-forefront-prvs: 01165471DB x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(24454002)(13464003)(164054003)(377424004)(189002)(199002)(51704005)(479174003)(377454003)(83072002)(90146001)(56816005)(77982001)(85852003)(59766001)(76576001)(74876001)(76786001)(87266001)(19580405001)(94946001)(83322001)(19580395003)(86612001)(86362001)(94316002)(80976001)(93516002)(95416001)(54316002)(56776001)(47446002)(2656002)(85306002)(87936001)(76176001)(74502001)(74662001)(31966008)(76796001)(93136001)(33646001)(51856001)(81816001)(81686001)(15975445006)(46102001)(92566001)(65816001)(53806001)(76482001)(80022001)(74316001)(4396001)(54356001)(50986001)(47976001)(47736001)(49866001)(81342001)(79102001)(81542001)(74706001)(74366001)(69226001)(63696002)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:2CE8FDDD.DF227C2.B5D6B3B7.50E9D9DC.20348; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 02:35:09 -0000 This email initiates a two-week Working Group Last Call on draft-ietf-pcp-server-selection-02 to conclude on Friday, February 21st. Please send comments to the list. As a reminder, when responding to a WGLC, what we chairs are looking for is= a statement=20 about document quality (not really about whether the mechanism should move forward). That is, state whether you think the document is ready as is, or if not, what issues you see. Thanks, -Dave > -----Original Message----- > From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Prashanth Patil > (praspati) > Sent: Monday, January 6, 2014 8:52 AM > To: pcp@ietf.org > Subject: Re: [pcp] I-D Action: draft-ietf-pcp-server-selection-02.txt >=20 > Folks, > Revised PCP server selection draft has been published. The update > addresses comments received from Dave Thaler and the ones at IETF 88. >=20 > -Prashanth >=20 >=20 > On 1/6/14 10:19 PM, "internet-drafts@ietf.org" > wrote: >=20 > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Port Control Protocol Working Group > >of the IETF. > > > > Title : PCP Server Selection > > Authors : Mohamed Boucadair > > Reinaldo Penno > > Dan Wing > > Prashanth Patil > > Tirumaleswar Reddy > > Filename : draft-ietf-pcp-server-selection-02.txt > > Pages : 11 > > Date : 2014-01-06 > > > >Abstract: > > Multiple IP addresses may be configured on a PCP client in some > > deployment contexts such as multi-homing. This document specifies > > the behavior to be followed by the PCP client to contact its PCP > > server(s) when one or several PCP server IP addresses are configured. > > > > This document updates RFC6887. > > > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-pcp-server-selection/ > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-pcp-server-selection-02 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-02 > > > > > >Please note that it may take a couple of minutes from the time of > >submission until the htmlized version and diff are available at > >tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >pcp mailing list > >pcp@ietf.org > >https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From internet-drafts@ietf.org Sat Feb 8 01:36:11 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3751ADF43; Sat, 8 Feb 2014 01:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jopyOqb30bs2; Sat, 8 Feb 2014 01:36:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A731ADF44; Sat, 8 Feb 2014 01:36:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140208093609.19040.45724.idtracker@ietfa.amsl.com> Date: Sat, 08 Feb 2014 01:36:09 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-authentication-03.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 09:36:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : Port Control Protocol (PCP) Authentication Mechanism Authors : Margaret Wasserman Sam Hartman Dacheng Zhang Filename : draft-ietf-pcp-authentication-03.txt Pages : 23 Date : 2014-02-08 Abstract: An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address and port mapping information on Network Address Translators (NATs) or firewalls, to facilitate communications with remote hosts. However, the un-controlled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases the client may need to prove that it is authorized to modify, create or delete PCP mappings. This document proposes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-authentication/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-authentication-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-authentication-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hassnaa.moustafa@intel.com Tue Feb 11 13:16:02 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B04F1A075E for ; Tue, 11 Feb 2014 13:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqHnPXaX2VO6 for ; Tue, 11 Feb 2014 13:15:58 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9162D1A0764 for ; Tue, 11 Feb 2014 13:15:58 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 11 Feb 2014 13:15:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.95,827,1384329600"; d="scan'208";a="473616687" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by fmsmga001.fm.intel.com with ESMTP; 11 Feb 2014 13:15:57 -0800 Received: from orsmsx155.amr.corp.intel.com (10.22.240.21) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Feb 2014 13:15:57 -0800 Received: from orsmsx102.amr.corp.intel.com ([169.254.1.111]) by ORSMSX155.amr.corp.intel.com ([169.254.7.248]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 13:15:57 -0800 From: "Moustafa, Hassnaa" To: "pcp@ietf.org" Thread-Topic: Comments For WGLC (draft-ietf-pcp-server-selection-02.txt) Thread-Index: Ac8nbnAMPmCLz4feSSugkAOF9m9TDg== Date: Tue, 11 Feb 2014 21:15:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] Comments For WGLC (draft-ietf-pcp-server-selection-02.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 21:16:02 -0000 Hi, There are few editorial comments on draft (draft-ietf-pcp-server-selection-= 02) as follows: 1. The term IP address family used in the draft needs more text clarificati= on (to say for example IPv4 or IPv6 or maybe other points that the authors = have in mind). 2. The IP addresses used in the diagram (in the example of Section 5) is no= t very consistent with the IP addresses mentioned in the text that explains= the diagram. Regards, Hassnaa -----Original Message----- From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Dave Thaler Sent: Friday, February 07, 2014 6:35 PM To: pcp@ietf.org Subject: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by= FEB 21 This email initiates a two-week Working Group Last Call on draft-ietf-pcp-server-selection-02 to conclude on Friday, February 21st. Please send comments to the list. As a reminder, when responding to a WGLC, what we chairs are looking for is= a statement about document quality (not really about whether the mechanism= should move forward). That is, state whether you think the document is re= ady as is, or if not, what issues you see. Thanks, -Dave > -----Original Message----- > From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Prashanth Patil > (praspati) > Sent: Monday, January 6, 2014 8:52 AM > To: pcp@ietf.org > Subject: Re: [pcp] I-D Action: draft-ietf-pcp-server-selection-02.txt >=20 > Folks, > Revised PCP server selection draft has been published. The update=20 > addresses comments received from Dave Thaler and the ones at IETF 88. >=20 > -Prashanth >=20 >=20 > On 1/6/14 10:19 PM, "internet-drafts@ietf.org"=20 > > wrote: >=20 > > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > >directories. > > This draft is a work item of the Port Control Protocol Working Group=20 > >of the IETF. > > > > Title : PCP Server Selection > > Authors : Mohamed Boucadair > > Reinaldo Penno > > Dan Wing > > Prashanth Patil > > Tirumaleswar Reddy > > Filename : draft-ietf-pcp-server-selection-02.txt > > Pages : 11 > > Date : 2014-01-06 > > > >Abstract: > > Multiple IP addresses may be configured on a PCP client in some > > deployment contexts such as multi-homing. This document specifies > > the behavior to be followed by the PCP client to contact its PCP > > server(s) when one or several PCP server IP addresses are configured. > > > > This document updates RFC6887. > > > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-pcp-server-selection/ > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-pcp-server-selection-02 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-02 > > > > > >Please note that it may take a couple of minutes from the time of=20 > >submission until the htmlized version and diff are available at=20 > >tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >pcp mailing list > >pcp@ietf.org > >https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Wed Feb 12 14:20:26 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2BA1A0002 for ; Wed, 12 Feb 2014 14:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e0aRXkTOZJ4 for ; Wed, 12 Feb 2014 14:20:22 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECA71A001B for ; Wed, 12 Feb 2014 14:20:21 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 22B0C403CB for ; Wed, 12 Feb 2014 17:20:20 -0500 (EST) Message-ID: <52FBF3A3.2070009@viagenie.ca> Date: Wed, 12 Feb 2014 17:20:19 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "pcp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 22:20:26 -0000 All, Here's my review... Summary: This draft contains major issues that need to be resolved before being sent to IESG. > 3. IP Address Selection > > These steps specify the behavior to be followed by the PCP client to > contact a PCP server when the PCP client has multiple IP addresses > for a single PCP server. How does the client know that those addresses belong to a single PCP server? Does this work when there are multiple addresses that belong to multiple PCP servers, or does it need to be a single server? Are we assuming that there is always a single PCP server per interface, and therefore all addresses can only belong to a single server by definition? > 1. If the PCP client can use both address families when > communicating to a particular PCP server, the PCP client SHOULD > select the source address of the PCP request to be of the same IP > address family as its requested PCP mapping (i.e., the address > family of the Requested External IP Address). This is wrong. You can't pick a source address based on the requested external address family. You can only pick the address family. For example, you can decide that you're going to use IPv6 to request an IPv6 external address, but that does not help decide which source IPv6 address you're going to use. And this is even more fundamentally wrong. The address family of the PCP request depends on your internal address family, not the suggested external address family. If your server is listening on IPvX, you send your PCP request over IPvX. Otherwise you have to play games with THIRD_PARTY. The external address family has nothing to do with it. In fact, the source address you're going to select has to be one your server is listening on. Otherwise you'll have to play games with THIRD_PARTY. Often servers just listen on the wildcard address, so that does not help you pick one particular address, but if that's not the case then you don't have a choice. Finally, "Requested External IP Address" is not a PCP term. I think you mean "Suggested External IP Address". > 2. Whenever communicating with a PCP server, the rules of Section 6 > of [RFC6724] SHOULD be followed by using the source address > selected in the previous step as input to the destination address > selection algorithm. Step 1 did not yield a particular source address. It yielded an address family. You still need to pick a particular source address. > 3. The PCP client initializes its Maximum Retransmission Count (MRC) > to 4. > > 4. The PCP client sends its PCP message to the PCP server's IP > address following the retransmission procedure specified in > Section 8.1.1 of [RFC6887]. If no response is received after MRC > attempts, the PCP client re-tries the procedure excluding the > destination addresses which did not respond. The PCP client > SHOULD ignore any response received from an IP address after > exhausting MRC attempts for that particular IP address. If, when > sending PCP requests, the PCP client receives a hard ICMP error > [RFC1122] it SHOULD immediately try the next IP address from the > list of PCP server' IP addresses. > > 5. If the PCP client has exhausted all IP addresses configured for a > given PCP server, the procedure is repeated every fifteen minutes > until the PCP request is successfully answered. > > 6. Once the PCP client has successfully received a response from a > PCP server's IP address, it sends subsequent PCP requests to the > same server's IP address until that IP address becomes non- > responsive, which causes the PCP client to follow the steps above > to contact its PCP server. Do we reset the destination address set then? That is, are addresses that failed previously now potentially good again? > 4. Multiple Interfaces > > When an end host has multiple interfaces concurrently active (e.g., > IEEE 802.11 and 3G), a PCP client would discover different PCP > servers over different interfaces. A host may have multiple network > interfaces (e.g, 3G, IEEE 802.11, etc.); each configured differently. > Each PCP server learned MUST be associated with the interface via > which it was learned. Particularly, the PCP client relies on the > source IP address of an outgoing PCP request to select which PCP > server(s) to use. That last sentence would be wrong following my feedback to section 3. > 5. Example: Multiple PCP servers on a Single Interface > > Figure 1 depicts an example that is used to illustrate the server > selection procedure specified in Section 3. > > ISP Network > | | > ......................................................... > | | Subscriber Network > +-------+------+ +----+---------+ > | PCP-Server-A | | PCP-Server-B | > | | | | > +-------+------+ +----+---------+ > 192.0.2.1 | | 198.51.100.1 > 2001:db8:2222::1 | | 2001:db8:3333::1 > | | > | | > -------+--------------+----------- > | > | 203.0.113.0 > | 2001:db8:1111::1 > +---+---+ > | Host | > +-------+ > > Figure 1 The PCP servers in this figure look like routers. To make things clearer: - Remove the connection from each PCP server to the ISP network. - Draw the "PCP-controlled device". That one would look like a router and would be sitting on the border between the subscriber network and the ISP network. Connect it to both PCP servers and the host. No need for addresses. Is there only one PCP-controlled device, or does each server control its own device? > The PCP client sends two PCP requests at the same time, Really? The algorithm from section 3 does not seem to allow parallel requests. I'm lost. > the first to > 192.0.2.1 (corresponding to PCP-Server-A) and the second to > 198.51.100.1 (corresponding to PCP-Server-B). The path to > 198.51.100.1 is working so a PCP response is received. Because the > path to 192.0.2.1 is broken, no PCP response is received. The PCP > client retries 4 times to elicit a response from 192.0.2.1 and > finally gives up on that address and sends a PCP message to > 2001::db8:1111:1. That path is working, and a response is received. > Thereafter, the PCP client should continue using that responsive IP > address for PCP-Server-A (2001:db8:1111::1). In this particular > case, it will have to use THIRD_PARTY option for IPv4 mappings. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Wed Feb 12 17:02:17 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45421A0081 for ; Wed, 12 Feb 2014 17:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.76 X-Spam-Level: X-Spam-Status: No, score=-8.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2zPeCypzHuD for ; Wed, 12 Feb 2014 17:02:15 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D38AB1A0079 for ; Wed, 12 Feb 2014 17:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1510; q=dns/txt; s=iport; t=1392253335; x=1393462935; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=mOB3UyA+vM9XHwapYGPrnxE8rnjQ5WpWlcW/0d93TN0=; b=Do537mson3lwl6KRZvcPGpS93pFXpjMZG4D+Rucjj5vT0FYIDXdSu+8a xDFis6c5bKxJuh7ZgGK1dWv2glUOon18HJzpfQEy+g7hGQnA+yO2gsDo3 f91i6mvPFGO9/m1ax0frXuur7Fkk5pzGmHk43oP9wkA8VKXEC6oF6hexs A=; X-IronPort-AV: E=Sophos;i="4.95,835,1384300800"; d="scan'208";a="105604150" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 13 Feb 2014 01:02:15 +0000 Received: from [10.85.165.242] ([10.85.165.242]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1D12189013574; Thu, 13 Feb 2014 01:02:07 GMT Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> Date: Wed, 12 Feb 2014 17:02:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140212033032.D4F0A7FC395@rfc-editor.org> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> To: "Zhangzhan (Channy)" X-Mailer: Apple Mail (2.1510) Cc: Stuart Cheshire , Brian Haberman , PCP Working Group Subject: Re: [pcp] =?gb2312?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtU?= =?gb2312?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 01:02:17 -0000 On Feb 12, 2014, at 4:49 PM, "Zhangzhan (Channy)" = wrote: > "Indeed, it has been discussed." >=20 > What's the final conclusion to the discussion?=20 >=20 > How PCP applies in the Dual-Egress NAT scene? >=20 > Could you please share it?=20 I removed the RFC Editor from the thread. PCP client needs to communicate to both of the NATs independently. = Which the same host (the PCP client) needs to know how to do anyway to = send its TCP SYN to one ISP or the other ISP -- to send its TCP SYNs to = different networks, the host must have routing entries. The PCP client = can use those same routing entries to know there are two routers on the = network, and send PCP messages to those two routers separately. -d >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Ted Lemon [mailto:ted.lemon@nominum.com]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 0:13 > =CA=D5=BC=FE=C8=CB: Dan Wing > =B3=AD=CB=CD: RFC Errata System; Zhangzhan (Channy); Stuart Cheshire; = mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler; PCP Working Group > =D6=F7=CC=E2: Re: [Technical Errata Reported] RFC6887 (3887) >=20 > On Feb 12, 2014, at 10:15 AM, Dan Wing wrote: >> It seems appropriate to discuss this question on the PCP mailing = list, pcp@ietf.org. >=20 > Indeed, it has been discussed. This isn't really an appropriate = topic for an erratum. >=20 From dwing@cisco.com Wed Feb 12 18:22:49 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7940E1A00C9 for ; Wed, 12 Feb 2014 18:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.76 X-Spam-Level: X-Spam-Status: No, score=-8.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9c9JlZKKvv2 for ; Wed, 12 Feb 2014 18:22:46 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id AC35C1A00CB for ; Wed, 12 Feb 2014 18:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3319; q=dns/txt; s=iport; t=1392258166; x=1393467766; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=27za/TbmOeOOom/RY+ZTVfQHInP490UBe+KfpG27TN0=; b=m5TuU02ryvuMugvAVo6SDfLjEAX5gbTeq1USnvVfD3ECfwndvYuMw9cG 6rKZZAaxvOgDPLJ35JUP1TyeFgVIjxCBKjEqCgEMw2XLubWYJVQA4ugT+ NVDvozgiWzI+7SAzRW8NjC9pZfz3T/5nLNxI6x0TkWDkqKaX63H1EOe81 k=; X-IronPort-AV: E=Sophos;i="4.95,836,1384300800"; d="scan'208";a="102328145" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 13 Feb 2014 02:22:45 +0000 Received: from [10.85.165.242] ([10.85.165.242]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1D2MgXP025702; Thu, 13 Feb 2014 02:22:43 GMT Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> Date: Wed, 12 Feb 2014 18:22:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com> References: <20140212033032.D4F0A7FC395@rfc-editor.org> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> To: Zhangzhan (Channy) X-Mailer: Apple Mail (2.1510) Cc: Stuart Cheshire , Brian Haberman , PCP Working Group Subject: Re: [pcp] =?gb2312?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtU?= =?gb2312?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 02:22:49 -0000 On Feb 12, 2014, at 5:29 PM, Zhangzhan (Channy) = wrote: > Maybe you misunderstand me. > There is only one router for NAT and PCP. > If the NAT gateway device (such as CGN) is PCP Server and has two or = more out interfaces to internet were doing different nat conversion in = the ISP.=20 > Maybe using NAT address pool A, B, C... And the routing entries to = internet on NAT gateway is equivalent default route. In this case, the = out interface is uncertain, fully in accordance with the equivalent = route selection. > If no PCP, service traffic can be selected out interface according to = the destination address and do different NAT conversion. > But the PCP message is in before the normal service traffic. And PCP = MAP mode message does not include the destination address, the NAT = gateway device how to choose the out interfaces and the different NAT = address pools?=20 > Based on the current PCP protocol, I think that can't be solved. Or = what I understand something wrong? With such a network topology, you are correct that the current MAP = opcode doesn't work. We need something different. Would = http://tools.ietf.org/html/draft-penno-pcp-zones be a viable solution? -d >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 9:02 > =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy) > =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; = mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler > =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: [Technical = Errata Reported] RFC6887 (3887) >=20 >=20 > On Feb 12, 2014, at 4:49 PM, "Zhangzhan (Channy)" = wrote: >=20 >> "Indeed, it has been discussed." >>=20 >> What's the final conclusion to the discussion?=20 >>=20 >> How PCP applies in the Dual-Egress NAT scene? >>=20 >> Could you please share it?=20 >=20 > I removed the RFC Editor from the thread. >=20 > PCP client needs to communicate to both of the NATs independently. = Which the same host (the PCP client) needs to know how to do anyway to = send its TCP SYN to one ISP or the other ISP -- to send its TCP SYNs to = different networks, the host must have routing entries. The PCP client = can use those same routing entries to know there are two routers on the = network, and send PCP messages to those two routers separately. >=20 > -d >=20 >=20 >>=20 >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: Ted Lemon [mailto:ted.lemon@nominum.com]=20 >> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 0:13 >> =CA=D5=BC=FE=C8=CB: Dan Wing >> =B3=AD=CB=CD: RFC Errata System; Zhangzhan (Channy); Stuart Cheshire; = mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler; PCP Working Group >> =D6=F7=CC=E2: Re: [Technical Errata Reported] RFC6887 (3887) >>=20 >> On Feb 12, 2014, at 10:15 AM, Dan Wing wrote: >>> It seems appropriate to discuss this question on the PCP mailing = list, pcp@ietf.org. >>=20 >> Indeed, it has been discussed. This isn't really an appropriate = topic for an erratum. >>=20 >=20 From dthaler@microsoft.com Wed Feb 12 18:35:59 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAE31A00B6 for ; Wed, 12 Feb 2014 18:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.652 X-Spam-Level: X-Spam-Status: No, score=-96.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKvNjDzqrB1s for ; Wed, 12 Feb 2014 18:35:57 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id D8DE11A00AB for ; Wed, 12 Feb 2014 18:35:56 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 02:35:47 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 02:35:47 +0000 From: Dave Thaler To: Dan Wing , Zhangzhan Thread-Topic: =?gb2312?B?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtUZWNobmljYWwg?= =?gb2312?Q?Errata_Reported]_RFC6887_(3887)?= Thread-Index: AQHPJ6LKN4bC5yHBw0Cuo55Yoa2Q+pqxu0+AgAAQJoCAAJAjAIAAA4gAgAAHuwCAAA7RAIAAAsuw Date: Thu, 13 Feb 2014 02:35:46 +0000 Message-ID: References: <20140212033032.D4F0A7FC395@rfc-editor.org> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com> In-Reply-To: <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(24454002)(189002)(199002)(377454003)(13464003)(51444003)(81816001)(76482001)(81686001)(33646001)(4396001)(53806001)(51856001)(46102001)(47976001)(49866001)(47736001)(74876001)(50986001)(95666001)(93136001)(94316002)(90146001)(56816005)(74706001)(86362001)(54356001)(19580395003)(2656002)(94946001)(87936001)(76786001)(83322001)(76576001)(95416001)(76796001)(86612001)(83072002)(77982001)(80976001)(224303002)(59766001)(19580405001)(85852003)(74366001)(79102001)(85306002)(66066001)(92566001)(65816001)(80022001)(87266001)(74316001)(56776001)(31966008)(74662001)(93516002)(47446002)(74502001)(81342001)(54316002)(69226001)(63696002)(81542001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:FC7CF1C5.2CF2CDA6.9F3DD7B.CED0D151.20300; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Stuart Cheshire , Brian Haberman , PCP Working Group Subject: Re: [pcp] =?gb2312?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtU?= =?gb2312?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 02:35:59 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYW4gV2luZyBbbWFpbHRvOmR3 aW5nQGNpc2NvLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAxNCA2OjIz IFBNDQo+IFRvOiBaaGFuZ3poYW4NCj4gQ2M6IFRlZCBMZW1vbjsgUENQIFdvcmtpbmcgR3JvdXA7 IFN0dWFydCBDaGVzaGlyZTsNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBCb3VjYWRh aXI7IFJlaW5hbGRvIFBlbm5vOw0KPiBwc2Vsa2lya0Bpc2Mub3JnOyBCcmlhbiBIYWJlcm1hbjsg RGF2ZSBUaGFsZXINCj4gU3ViamVjdDogUmU6IFdoYXQncyB0aGUgZmluYWwgY29uY2x1c2lvbj+0 8Li0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0NCj4gUkZDNjg4NyAoMzg4NykNCj4gDQo+ IA0KPiBPbiBGZWIgMTIsIDIwMTQsIGF0IDU6MjkgUE0sIFpoYW5nemhhbiAoQ2hhbm55KQ0KPiA8 Y2hhbm55LnpoYW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gPiBNYXliZSB5b3UgbWlzdW5k ZXJzdGFuZCBtZS4NCj4gPiBUaGVyZSBpcyBvbmx5IG9uZSByb3V0ZXIgZm9yIE5BVCBhbmQgUENQ Lg0KPiA+IElmIHRoZSBOQVQgZ2F0ZXdheSBkZXZpY2UgKHN1Y2ggYXMgQ0dOKSBpcyBQQ1AgU2Vy dmVyIGFuZCBoYXMgdHdvIG9yIG1vcmUNCj4gb3V0IGludGVyZmFjZXMgdG8gaW50ZXJuZXQgd2Vy ZSBkb2luZyBkaWZmZXJlbnQgbmF0IGNvbnZlcnNpb24gaW4gdGhlIElTUC4NCj4gPiBNYXliZSB1 c2luZyBOQVQgYWRkcmVzcyBwb29sIEEsIEIsIEMuLi4gQW5kIHRoZSByb3V0aW5nIGVudHJpZXMg dG8gaW50ZXJuZXQNCj4gb24gTkFUIGdhdGV3YXkgaXMgZXF1aXZhbGVudCBkZWZhdWx0IHJvdXRl LiBJbiB0aGlzIGNhc2UsIHRoZSBvdXQgaW50ZXJmYWNlIGlzDQo+IHVuY2VydGFpbiwgZnVsbHkg aW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBlcXVpdmFsZW50IHJvdXRlIHNlbGVjdGlvbi4NCj4gPiBJ ZiBubyBQQ1AsIHNlcnZpY2UgdHJhZmZpYyBjYW4gYmUgc2VsZWN0ZWQgb3V0IGludGVyZmFjZSBh Y2NvcmRpbmcgdG8gdGhlDQo+IGRlc3RpbmF0aW9uIGFkZHJlc3MgYW5kIGRvIGRpZmZlcmVudCBO QVQgY29udmVyc2lvbi4NCj4gPiBCdXQgdGhlIFBDUCBtZXNzYWdlIGlzIGluIGJlZm9yZSB0aGUg bm9ybWFsIHNlcnZpY2UgdHJhZmZpYy4gQW5kIFBDUCBNQVANCj4gbW9kZSBtZXNzYWdlIGRvZXMg bm90IGluY2x1ZGUgdGhlIGRlc3RpbmF0aW9uIGFkZHJlc3MsIHRoZSBOQVQgZ2F0ZXdheQ0KPiBk ZXZpY2UgaG93IHRvIGNob29zZSB0aGUgb3V0IGludGVyZmFjZXMgYW5kIHRoZSBkaWZmZXJlbnQg TkFUIGFkZHJlc3MNCj4gcG9vbHM/DQo+ID4gQmFzZWQgb24gdGhlIGN1cnJlbnQgUENQIHByb3Rv Y29sLCBJIHRoaW5rIHRoYXQgY2FuJ3QgYmUgc29sdmVkLiBPciB3aGF0IEkNCj4gdW5kZXJzdGFu ZCBzb21ldGhpbmcgd3Jvbmc/DQo+IA0KPiBXaXRoIHN1Y2ggYSBuZXR3b3JrIHRvcG9sb2d5LCB5 b3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgY3VycmVudCBNQVAgb3Bjb2RlDQo+IGRvZXNuJ3Qgd29y ay4NCg0KSSdtIG5vdCBzdXJlIGl0J3MgZmFpciB0byBzYXkgaXQgImRvZXNuJ3Qgd29yayIuICBJ dCBqdXN0IG1lYW5zIHRoYXQgdGhlIE5BVCBwaWNrcw0Kb25lIHVzaW5nIGFueSBpbXBsZW1lbnRh dGlvbi1zcGVjaWZpYyBtZWNoYW5pc20uICBJbiB0aGUgc3RhdGVkIGV4YW1wbGUgYWJvdmUsDQpi b3RoIHBvc3NpYmxlIGFuc3dlcnMgZ28gdG8gdGhlIEludGVybmV0LCBzbyB3aGF0IHdvdWxkbid0 ICJ3b3JrIj8NCg0KT24gdGhlIHRvcGljIG9mIHRoZSBlcnJhdGEsIEkgYWdyZWUgd2l0aCBUZWQg aXQgaXMgbm90IGFuIGVycmF0YS4gIEl0J3Mgc2ltcGx5IGFuDQppbXBsZW1lbnRhdGlvbiBkZXRh aWwgdGhhdCB0aGUgUkZDIGRvZXNuJ3Qgc3BlY2lmeSwgc28gaXQncyB1cCB0byB0aGUgcmVhZGVy Lg0KDQotRGF2ZQ0K From dwing@cisco.com Wed Feb 12 18:54:38 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848A91A004A for ; Wed, 12 Feb 2014 18:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gheydz1eKNm5 for ; Wed, 12 Feb 2014 18:54:36 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBFF1A0028 for ; Wed, 12 Feb 2014 18:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2431; q=dns/txt; s=iport; t=1392260075; x=1393469675; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=m4MqACOAFLlJFbjBeEv9okgGH8L9MA6FGEfkvtZbL+U=; b=Z7LUQznL4jMB7XooD+mVPDX75QbHxbAK1O+Mv2ZkGoIP0tT2FOPwc/zp qb27HAvMiy2RE2eumzbIep/+mgegyzvA7GXquVs2Z8GAA+B4sA2qEE7Tc abzOiHGZre2/H95OZtUekweQQApJmZGQTKo38Y2WDY7PmcU/2XEn9a7Uo U=; X-IronPort-AV: E=Sophos;i="4.95,836,1384300800"; d="scan'208";a="20040490" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP; 13 Feb 2014 02:54:33 +0000 Received: from [10.85.165.242] ([10.85.165.242]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1D2sURp008344; Thu, 13 Feb 2014 02:54:31 GMT Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Wed, 12 Feb 2014 18:54:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <38C9F787-C766-47FF-835F-E224BFD47483@cisco.com> References: <20140212033032.D4F0A7FC395@rfc-editor.org> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com> To: Dave Thaler X-Mailer: Apple Mail (2.1510) Cc: Stuart Cheshire , Brian Haberman , Zhangzhan , PCP Working Group Subject: Re: [pcp] =?gb2312?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtU?= =?gb2312?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 02:54:38 -0000 On Feb 12, 2014, at 6:35 PM, Dave Thaler wrote: >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Wednesday, February 12, 2014 6:23 PM >> To: Zhangzhan >> Cc: Ted Lemon; PCP Working Group; Stuart Cheshire; >> mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; >> pselkirk@isc.org; Brian Haberman; Dave Thaler >> Subject: Re: What's the final conclusion?=B4=F0=B8=B4: [Technical = Errata Reported] >> RFC6887 (3887) >>=20 >>=20 >> On Feb 12, 2014, at 5:29 PM, Zhangzhan (Channy) >> wrote: >>=20 >>> Maybe you misunderstand me. >>> There is only one router for NAT and PCP. >>> If the NAT gateway device (such as CGN) is PCP Server and has two or = more >> out interfaces to internet were doing different nat conversion in the = ISP. >>> Maybe using NAT address pool A, B, C... And the routing entries to = internet >> on NAT gateway is equivalent default route. In this case, the out = interface is >> uncertain, fully in accordance with the equivalent route selection. >>> If no PCP, service traffic can be selected out interface according = to the >> destination address and do different NAT conversion. >>> But the PCP message is in before the normal service traffic. And PCP = MAP >> mode message does not include the destination address, the NAT = gateway >> device how to choose the out interfaces and the different NAT address >> pools? >>> Based on the current PCP protocol, I think that can't be solved. Or = what I >> understand something wrong? >>=20 >> With such a network topology, you are correct that the current MAP = opcode >> doesn't work. >=20 > I'm not sure it's fair to say it "doesn't work". It just means that = the NAT picks > one using any implementation-specific mechanism. In the stated = example above, > both possible answers go to the Internet, so what wouldn't "work"? Good point. Same with a TCP SYN -- it gets assigned to one CGN, or the = other -- it wouldn't be assigned to both. I had figured that both don't = really, really, go to the Internet, like what NTT does with their IPv6 = default route in Japan (which doesn't go to the Internet). -d >=20 > On the topic of the errata, I agree with Ted it is not an errata. = It's simply an > implementation detail that the RFC doesn't specify, so it's up to the = reader. >=20 > -Dave From dthaler@microsoft.com Wed Feb 12 19:03:12 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0235D1A00D3 for ; Wed, 12 Feb 2014 19:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.952 X-Spam-Level: X-Spam-Status: No, score=-95.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3zU2GmLQy1y for ; Wed, 12 Feb 2014 19:03:09 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) by ietfa.amsl.com (Postfix) with ESMTP id 48A081A0028 for ; Wed, 12 Feb 2014 19:03:09 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB409.namprd03.prod.outlook.com (10.141.141.11) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 03:03:06 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 03:03:06 +0000 From: Dave Thaler To: Dan Wing Thread-Topic: =?gb2312?B?TXVsdGktaG9tZWQgTkFUICh3YXM6IFdoYXQncyB0aGUgZmluYWwgY29uY2x1?= =?gb2312?B?c2lvbj+08Li0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNjg4?= =?gb2312?Q?7_(3887))?= Thread-Index: Ac8oZzWfW4x5PAEUTrq8YeFFYwPPGQ== Date: Thu, 13 Feb 2014 03:03:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(51444003)(377454003)(51704005)(24454002)(13464003)(85306002)(74876001)(19580395003)(19580405001)(83322001)(65816001)(80022001)(81816001)(90146001)(81686001)(66066001)(92566001)(56816005)(63696002)(76176001)(53806001)(85852003)(87936001)(87266001)(83072002)(76482001)(95416001)(33646001)(86612001)(56776001)(54316002)(2656002)(224303002)(80976001)(95666001)(79102001)(74316001)(59766001)(77982001)(74706001)(54356001)(74502001)(93516002)(47736001)(93136001)(51856001)(74662001)(94946001)(74366001)(86362001)(50986001)(47976001)(47446002)(69226001)(49866001)(94316002)(31966008)(46102001)(76576001)(76786001)(76796001)(81342001)(81542001)(4396001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB409; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:FC30F1E5.ACF2D5A6.CF17D7B.CED05D51.203FC; MLV:sfv; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Stuart Cheshire , Brian Haberman , Zhangzhan , PCP Working Group Subject: [pcp] =?gb2312?b?TXVsdGktaG9tZWQgTkFUICh3YXM6IFdoYXQncyB0aGUgZmlu?= =?gb2312?b?YWwgY29uY2x1c2lvbj+08Li0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRl?= =?gb2312?b?ZF0gUkZDNjg4NyAoMzg4Nykp?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 03:03:12 -0000 VXBkYXRpbmcgc3ViamVjdCBsaW5lLg0KDQpNb3JlIGJlbG93Lg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IERhbiBXaW5nIFttYWlsdG86ZHdpbmdAY2lzY28uY29tXQ0K PiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0IDY6NTUgUE0NCj4gVG86IERhdmUg VGhhbGVyDQo+IENjOiBaaGFuZ3poYW47IFRlZCBMZW1vbjsgUENQIFdvcmtpbmcgR3JvdXA7IFN0 dWFydCBDaGVzaGlyZTsNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBCb3VjYWRhaXI7 IFJlaW5hbGRvIFBlbm5vOw0KPiBwc2Vsa2lya0Bpc2Mub3JnOyBCcmlhbiBIYWJlcm1hbg0KPiBT dWJqZWN0OiBSZTogV2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtUZWNobmljYWwg RXJyYXRhIFJlcG9ydGVkXQ0KPiBSRkM2ODg3ICgzODg3KQ0KPiANCj4gDQo+IE9uIEZlYiAxMiwg MjAxNCwgYXQgNjozNSBQTSwgRGF2ZSBUaGFsZXIgPGR0aGFsZXJAbWljcm9zb2Z0LmNvbT4gd3Jv dGU6DQo+IA0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBEYW4g V2luZyBbbWFpbHRvOmR3aW5nQGNpc2NvLmNvbV0NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBGZWJy dWFyeSAxMiwgMjAxNCA2OjIzIFBNDQo+ID4+IFRvOiBaaGFuZ3poYW4NCj4gPj4gQ2M6IFRlZCBM ZW1vbjsgUENQIFdvcmtpbmcgR3JvdXA7IFN0dWFydCBDaGVzaGlyZTsNCj4gPj4gbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSBCb3VjYWRhaXI7IFJlaW5hbGRvIFBlbm5vOw0KPiA+PiBwc2Vs a2lya0Bpc2Mub3JnOyBCcmlhbiBIYWJlcm1hbjsgRGF2ZSBUaGFsZXINCj4gPj4gU3ViamVjdDog UmU6IFdoYXQncyB0aGUgZmluYWwgY29uY2x1c2lvbj+08Li0OiBbVGVjaG5pY2FsIEVycmF0YQ0K PiA+PiBSZXBvcnRlZF0NCj4gPj4gUkZDNjg4NyAoMzg4NykNCj4gPj4NCj4gPj4NCj4gPj4gT24g RmViIDEyLCAyMDE0LCBhdCA1OjI5IFBNLCBaaGFuZ3poYW4gKENoYW5ueSkNCj4gPj4gPGNoYW5u eS56aGFuZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gPj4NCj4gPj4+IE1heWJlIHlvdSBtaXN1bmRl cnN0YW5kIG1lLg0KPiA+Pj4gVGhlcmUgaXMgb25seSBvbmUgcm91dGVyIGZvciBOQVQgYW5kIFBD UC4NCj4gPj4+IElmIHRoZSBOQVQgZ2F0ZXdheSBkZXZpY2UgKHN1Y2ggYXMgQ0dOKSBpcyBQQ1Ag U2VydmVyIGFuZCBoYXMgdHdvIG9yDQo+ID4+PiBtb3JlDQo+ID4+IG91dCBpbnRlcmZhY2VzIHRv IGludGVybmV0IHdlcmUgZG9pbmcgZGlmZmVyZW50IG5hdCBjb252ZXJzaW9uIGluIHRoZSBJU1Au DQo+ID4+PiBNYXliZSB1c2luZyBOQVQgYWRkcmVzcyBwb29sIEEsIEIsIEMuLi4gQW5kIHRoZSBy b3V0aW5nIGVudHJpZXMgdG8NCj4gPj4+IGludGVybmV0DQo+ID4+IG9uIE5BVCBnYXRld2F5IGlz IGVxdWl2YWxlbnQgZGVmYXVsdCByb3V0ZS4gSW4gdGhpcyBjYXNlLCB0aGUgb3V0DQo+ID4+IGlu dGVyZmFjZSBpcyB1bmNlcnRhaW4sIGZ1bGx5IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgZXF1aXZh bGVudCByb3V0ZQ0KPiBzZWxlY3Rpb24uDQo+ID4+PiBJZiBubyBQQ1AsIHNlcnZpY2UgdHJhZmZp YyBjYW4gYmUgc2VsZWN0ZWQgb3V0IGludGVyZmFjZSBhY2NvcmRpbmcNCj4gPj4+IHRvIHRoZQ0K PiA+PiBkZXN0aW5hdGlvbiBhZGRyZXNzIGFuZCBkbyBkaWZmZXJlbnQgTkFUIGNvbnZlcnNpb24u DQo+ID4+PiBCdXQgdGhlIFBDUCBtZXNzYWdlIGlzIGluIGJlZm9yZSB0aGUgbm9ybWFsIHNlcnZp Y2UgdHJhZmZpYy4gQW5kIFBDUA0KPiA+Pj4gTUFQDQo+ID4+IG1vZGUgbWVzc2FnZSBkb2VzIG5v dCBpbmNsdWRlIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzLCB0aGUgTkFUDQo+ID4+IGdhdGV3YXkg ZGV2aWNlIGhvdyB0byBjaG9vc2UgdGhlIG91dCBpbnRlcmZhY2VzIGFuZCB0aGUgZGlmZmVyZW50 IE5BVA0KPiA+PiBhZGRyZXNzIHBvb2xzPw0KPiA+Pj4gQmFzZWQgb24gdGhlIGN1cnJlbnQgUENQ IHByb3RvY29sLCBJIHRoaW5rIHRoYXQgY2FuJ3QgYmUgc29sdmVkLiBPcg0KPiA+Pj4gd2hhdCBJ DQo+ID4+IHVuZGVyc3RhbmQgc29tZXRoaW5nIHdyb25nPw0KPiA+Pg0KPiA+PiBXaXRoIHN1Y2gg YSBuZXR3b3JrIHRvcG9sb2d5LCB5b3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgY3VycmVudCBNQVAN Cj4gPj4gb3Bjb2RlIGRvZXNuJ3Qgd29yay4NCj4gPg0KPiA+IEknbSBub3Qgc3VyZSBpdCdzIGZh aXIgdG8gc2F5IGl0ICJkb2Vzbid0IHdvcmsiLiAgSXQganVzdCBtZWFucyB0aGF0DQo+ID4gdGhl IE5BVCBwaWNrcyBvbmUgdXNpbmcgYW55IGltcGxlbWVudGF0aW9uLXNwZWNpZmljIG1lY2hhbmlz bS4gIEluIHRoZQ0KPiA+IHN0YXRlZCBleGFtcGxlIGFib3ZlLCBib3RoIHBvc3NpYmxlIGFuc3dl cnMgZ28gdG8gdGhlIEludGVybmV0LCBzbyB3aGF0DQo+IHdvdWxkbid0ICJ3b3JrIj8NCj4gDQo+ IEdvb2QgcG9pbnQuICBTYW1lIHdpdGggYSBUQ1AgU1lOIC0tIGl0IGdldHMgYXNzaWduZWQgdG8g b25lIENHTiwgb3IgdGhlIG90aGVyDQo+IC0tIGl0IHdvdWxkbid0IGJlIGFzc2lnbmVkIHRvIGJv dGguICBJIGhhZCBmaWd1cmVkIHRoYXQgYm90aCBkb24ndCByZWFsbHksIHJlYWxseSwNCj4gZ28g dG8gdGhlIEludGVybmV0LCBsaWtlIHdoYXQgTlRUIGRvZXMgd2l0aCB0aGVpciBJUHY2IGRlZmF1 bHQgcm91dGUgaW4gSmFwYW4NCj4gKHdoaWNoIGRvZXNuJ3QgZ28gdG8gdGhlIEludGVybmV0KS4N Cg0KWWVzIHRoYXQncyBhbiBhbHRlcm5hdGUgZXhhbXBsZSB0aGF0J3MgZ29vZCB0byBkaXNjdXNz IChoZW5jZSB0aGUgY2hhbmdlIGluIA0Kc3ViamVjdCBsaW5lKSwgd2hpY2ggZHJhZnQtcGVubm8t cGNwLXpvbmVzIGRvZXMuICBJbiBhIG11bHRpLWhvbWVkIE5BVCBjYXNlLA0KSSdkIGV4cGVjdCB0 aGUgaW1wbGVtZW50YXRpb24gdG8gcHJlZmVyIHRoZSBvbmUgdGhhdCBhY3R1YWxseSBnb2VzIHRv IHRoZSBJbnRlcm5ldC4NClRoYXQgaXMsIHNpbmNlIE1BUCB0cmllcyB0byBvcGVuIGEgcG9ydCBm b3IgImFueW9uZSIsIHRoZW4gd2hlbiBtdWx0aXBsZSBjaG9pY2VzDQpleGlzdCB0aGF0IHN1cHBv cnQgZGlmZmVyZW50IHNldHMgb2YgcmVtb3RlIHBlZXJzLCBvbmUgc2hvdWxkIGJ5IGRlZmF1bHQg cHJlZmVyDQp0aGUgb25lIHdpdGggdGhlIGxhcmdlciBzZXQsIGFzIGJlaW5nIGNsb3NlciB0byB0 aGUgZGVzaXJlIG9mICJhbnlvbmUiLg0KDQpBbmQgb2YgY291cnNlIHRoZXJlIGNvdWxkIGJlIGlt cGxlbWVudGF0aW9uLXNwZWNpZmljIGNvbmZpZ3VyYXRpb24gdG8gb3ZlcnJpZGUNCnRoZSBkZWZh dWx0LCBvciBwcm90b2NvbCBzdXBwb3J0IGEgbGEgZHJhZnQtcGVubm8tcGNwLXpvbmVzIHRvIHNw ZWNpZnkgbm9uLWRlZmF1bHQNCmJlaGF2aW9yLg0KDQotRGF2ZQ0KDQo+IA0KPiAtZA0KPiANCj4g DQo+ID4NCj4gPiBPbiB0aGUgdG9waWMgb2YgdGhlIGVycmF0YSwgSSBhZ3JlZSB3aXRoIFRlZCBp dCBpcyBub3QgYW4gZXJyYXRhLg0KPiA+IEl0J3Mgc2ltcGx5IGFuIGltcGxlbWVudGF0aW9uIGRl dGFpbCB0aGF0IHRoZSBSRkMgZG9lc24ndCBzcGVjaWZ5LCBzbyBpdCdzIHVwDQo+IHRvIHRoZSBy ZWFkZXIuDQo+ID4NCj4gPiAtRGF2ZQ0KDQo= From dthaler@microsoft.com Wed Feb 12 19:55:09 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0A71A00DD for ; Wed, 12 Feb 2014 19:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.313 X-Spam-Level: X-Spam-Status: No, score=-96.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pImbNwsk_jHf for ; Wed, 12 Feb 2014 19:55:06 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 285131A00D8 for ; Wed, 12 Feb 2014 19:55:06 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 03:55:03 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 03:55:03 +0000 From: Dave Thaler To: "Zhangzhan (Channy)" , Dan Wing Thread-Topic: =?gb2312?B?TXVsdGktaG9tZWQgTkFUICh3YXM6IFdoYXQncyB0aGUgZmluYWwgY29uY2x1?= =?gb2312?B?c2lvbj+08Li0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNjg4?= =?gb2312?Q?7_(3887))?= Thread-Index: Ac8oZzWfW4x5PAEUTrq8YeFFYwPPGQABkIyAAABsuMA= Date: Thu, 13 Feb 2014 03:55:03 +0000 Message-ID: <3881c4e57bf54bea836ca214c98c528f@BY2PR03MB412.namprd03.prod.outlook.com> References: <1DA8CEC3F3E989439069663C05A865D334F97B5A@nkgeml508-mbx.china.huawei.com> In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97B5A@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(13464003)(24454002)(51444003)(199002)(189002)(377454003)(94946001)(51856001)(74662001)(74366001)(93516002)(74502001)(47736001)(93136001)(81542001)(4396001)(69226001)(47446002)(31966008)(49866001)(94316002)(50986001)(47976001)(86362001)(81342001)(76796001)(76576001)(46102001)(76786001)(53806001)(63696002)(56816005)(92566001)(85852003)(87936001)(83322001)(19580405001)(19580395003)(81816001)(65816001)(80022001)(85306002)(74876001)(81686001)(66066001)(90146001)(2656002)(80976001)(224303002)(77982001)(59766001)(54356001)(74706001)(95666001)(74316001)(79102001)(76482001)(33646001)(95416001)(87266001)(83072002)(54316002)(56776001)(86612001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:FC20F0E5.ACF2DBA2.3CF171BB.8ED8DD51.20513; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Stuart Cheshire , Brian Haberman , PCP Working Group Subject: Re: [pcp] =?gb2312?b?TXVsdGktaG9tZWQgTkFUICh3YXM6IFdoYXQncyB0aGUgZmlu?= =?gb2312?b?YWwgY29uY2x1c2lvbj+08Li0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRl?= =?gb2312?b?ZF0gUkZDNjg4NyAoMzg4Nykp?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 03:55:09 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBaaGFuZ3poYW4gKENoYW5ueSkg W21haWx0bzpjaGFubnkuemhhbmdAaHVhd2VpLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBGZWJy dWFyeSAxMiwgMjAxNCA3OjQ0IFBNDQo+IFRvOiBEYXZlIFRoYWxlcjsgRGFuIFdpbmcNCj4gQ2M6 IFRlZCBMZW1vbjsgUENQIFdvcmtpbmcgR3JvdXA7IFN0dWFydCBDaGVzaGlyZTsNCj4gbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBCb3VjYWRhaXI7IFJlaW5hbGRvIFBlbm5vOw0KPiBwc2Vs a2lya0Bpc2Mub3JnOyBCcmlhbiBIYWJlcm1hbg0KPiBTdWJqZWN0OiC08Li0OiBNdWx0aS1ob21l ZCBOQVQgKHdhczogV2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6DQo+IFtUZWNobmlj YWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KSkNCj4gDQo+IFRvIERhdmU6DQo+IA0K PiBCYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nIGZvciB5b3VyIG1lYW5pbmc6DQo+IEl0J3MgbW9y ZSBhcHByb3ByaWF0ZSB0byBzZWxlY3QgYW4gb3B0aW1hbCBvbmUgaW5zdGVhZCBvZiBkZWZhdWx0 IGJlaGF2aW9yIGluDQo+IHRoaXMgc2NlbmUuDQo+IA0KPiBCdXQgaW4gc3VjaCBhIG5ldHdvcmsg dG9wb2xvZ3k6DQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAsLS0tLS0uDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAsJyAgICAgICBgLg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC4oIElTUDEgKQ0KPiAgICAgICAgICAgICAgICwtLS0tLS0tLiAg ICAgICAgICAgICAgICAgICAgIC4tJyAgYC4gICAgICAgLCcNCj4gICAgICAgICAgICAsLScgIElT UDAgICBgLS4gICAgICAgICAgICAgICAgLicgICAgICAgYC0tLS0tJw0KPiAgICAgICAgIEhvc3Qg ICAgICAgICAgICAgIFwgQ0dOICAgICAgICAuLScgICAgICAgICAgLC0tLS0tLS0uDQo+ICAgICAr LS0tLSstLS0tLSsgICAgICAgKy0tLSstLS0tLS0rICAuJyAgICAgICAgICAgLCcgICAgICAgICBg Lg0KPiAgICAgfFBDUCBDbGllbnR8LS0tLS0tLXxQQ1AgU2VydmVyfC4nLS0tLS0tLS0tLS0tKCBJ U1AyKQ0KPiAgICAgKy0tLS0rLS0tLS0rICAgICAgICstLS0rLS0tLS0tKyBgLS4gICAgICAgICAg IGAuICAgICAgICAgLCcNCj4gICAgICAgICAgIFwgICAgICAgICAgICAgICAvICAgICAgICAgICAg YC4gICAgICAgICAgIGAtLS0tLS0tJw0KPiAgICAgICAgICAgIGAtLiAgICAgICAgICwtJyAgICAg ICAgICAgICAgIGAtLiAgICAgICwtLS0tLS4NCj4gICAgICAgICAgICAgICBgLS0tLS0tLScgICAg ICAgICAgICAgICAgICAgICBgLiAgIC8gICAgICAgXA0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgYC0oIElTUDMgKQ0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXCAgICAgICAvDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYC0tLS0tJw0KPiANCj4gSWYgdXNl cnMgaW4gSVNQMSB3YW50IHRvIHZpc2l0IHRoZSBob3N0IGluIElTUDAsIHN1cHBvc2UgdGhlIGds b2JhbCBuYXQgYWRkcmVzcw0KPiBvZiBob3N0IGlzIElQIHBvb2wgMS4NCj4gTm9ybWFsbHksIGlm IG5vIFBDUCwgaWYgdXNlcnMgaW4gSVNQMiB3YW50IHRvIHZpc2l0IHRoZSBob3N0LCB0aGUgZ2xv YmFsIG5hdA0KPiBhZGRyZXNzIG9mIGhvc3QgaXMgSVAgcG9vbCAyLg0KPiBJUCBwb29sIDEgYW5k IElQIHBvb2wgMiBhcmUgY2VydGFpbmx5IGRpZmZlcmVudCBhZGRyZXNzIHNlZ21lbnRzLCBhbmQN Cj4gYmVsb25naW5nIHRvIGRpZmZlcmVudCBJU1AuDQo+IA0KPiBOb3cgUENQIGlzIHVzZWQgdG8g bWFwcGluZyB0aGUgZ2xvYmFsIG5hdCBhZGRyZXNzLCBzdXBwb3NlIENHTiBzZWxlY3QgSVANCj4g cG9vbCAxIGFzIHRoZSBvcHRpbWFsIG9uZS4gSWYgdXNlcnMgaW4gSVNQMiB3YW50IHRvIHZpc2l0 IHRoZSBob3N0LCBtdXN0IHZpc2l0IHRoZQ0KPiBJUCBwb29sIDEgdGhyb3VnaCBJU1AxJ3MgbmV0 d29yay4gQnV0IHVzdWFsbHkgdGhpcyBpcyBub3QgYWNjZXB0YWJsZSB0byBJUFMyLg0KDQpZZXMg dGhhdCBkaWFncmFtIGlzIGEgZGlmZmVyZW50IHNjZW5hcmlvIHRoYW4gdGhlIG9uZSB5b3Ugb3Jp Z2luYWxseSBtZW50aW9uZWQsDQp3aGVyZSBhbGwgY29ubmVjdCB0byB0aGUgSW50ZXJuZXQuICAo VGhlcmUgaXMgbm8gSW50ZXJuZXQgaW4geW91ciBwaWN0dXJlIGhlcmUuKQ0KDQpUaGlzIGlzIHRo ZSBzY2VuYXJpbyBEYW4gd2FzIHJlZmVycmluZyB0by4NCg0KLURhdmUNCiANCj4gLS0tLS3Tyrz+ 1K28/i0tLS0tDQo+ILeivP7IyzogRGF2ZSBUaGFsZXIgW21haWx0bzpkdGhhbGVyQG1pY3Jvc29m dC5jb21dDQo+ILeiy83KsbzkOiAyMDE0xOoy1MIxM8jVIDExOjAzDQo+IMrVvP7IyzogRGFuIFdp bmcNCj4gs63LzTogWmhhbmd6aGFuIChDaGFubnkpOyBUZWQgTGVtb247IFBDUCBXb3JraW5nIEdy b3VwOyBTdHVhcnQNCj4gQ2hlc2hpcmU7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gQm91 Y2FkYWlyOyBSZWluYWxkbyBQZW5ubzsNCj4gcHNlbGtpcmtAaXNjLm9yZzsgQnJpYW4gSGFiZXJt YW4NCj4g1vfM4jogTXVsdGktaG9tZWQgTkFUICh3YXM6IFdoYXQncyB0aGUgZmluYWwgY29uY2x1 c2lvbj+08Li0OiBbVGVjaG5pY2FsDQo+IEVycmF0YSBSZXBvcnRlZF0gUkZDNjg4NyAoMzg4Nykp DQo+IA0KPiBVcGRhdGluZyBzdWJqZWN0IGxpbmUuDQo+IA0KPiBNb3JlIGJlbG93Lg0KPiANCj4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERhbiBXaW5nIFttYWlsdG86 ZHdpbmdAY2lzY28uY29tXQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQg Njo1NSBQTQ0KPiA+IFRvOiBEYXZlIFRoYWxlcg0KPiA+IENjOiBaaGFuZ3poYW47IFRlZCBMZW1v bjsgUENQIFdvcmtpbmcgR3JvdXA7IFN0dWFydCBDaGVzaGlyZTsNCj4gPiBtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tIEJvdWNhZGFpcjsgUmVpbmFsZG8gUGVubm87DQo+ID4gcHNlbGtpcmtA aXNjLm9yZzsgQnJpYW4gSGFiZXJtYW4NCj4gPiBTdWJqZWN0OiBSZTogV2hhdCdzIHRoZSBmaW5h bCBjb25jbHVzaW9uP7TwuLQ6IFtUZWNobmljYWwgRXJyYXRhDQo+ID4gUmVwb3J0ZWRdDQo+ID4g UkZDNjg4NyAoMzg4NykNCj4gPg0KPiA+DQo+ID4gT24gRmViIDEyLCAyMDE0LCBhdCA2OjM1IFBN LCBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gPg0KPiA+ID4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPj4gRnJvbTogRGFuIFdpbmcgW21haWx0 bzpkd2luZ0BjaXNjby5jb21dDQo+ID4gPj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwg MjAxNCA2OjIzIFBNDQo+ID4gPj4gVG86IFpoYW5nemhhbg0KPiA+ID4+IENjOiBUZWQgTGVtb247 IFBDUCBXb3JraW5nIEdyb3VwOyBTdHVhcnQgQ2hlc2hpcmU7DQo+ID4gPj4gbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbSBCb3VjYWRhaXI7IFJlaW5hbGRvIFBlbm5vOw0KPiA+ID4+IHBzZWxr aXJrQGlzYy5vcmc7IEJyaWFuIEhhYmVybWFuOyBEYXZlIFRoYWxlcg0KPiA+ID4+IFN1YmplY3Q6 IFJlOiBXaGF0J3MgdGhlIGZpbmFsIGNvbmNsdXNpb24/tPC4tDogW1RlY2huaWNhbCBFcnJhdGEN Cj4gPiA+PiBSZXBvcnRlZF0NCj4gPiA+PiBSRkM2ODg3ICgzODg3KQ0KPiA+ID4+DQo+ID4gPj4N Cj4gPiA+PiBPbiBGZWIgMTIsIDIwMTQsIGF0IDU6MjkgUE0sIFpoYW5nemhhbiAoQ2hhbm55KQ0K PiA+ID4+IDxjaGFubnkuemhhbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gPj4NCj4gPiA+Pj4g TWF5YmUgeW91IG1pc3VuZGVyc3RhbmQgbWUuDQo+ID4gPj4+IFRoZXJlIGlzIG9ubHkgb25lIHJv dXRlciBmb3IgTkFUIGFuZCBQQ1AuDQo+ID4gPj4+IElmIHRoZSBOQVQgZ2F0ZXdheSBkZXZpY2Ug KHN1Y2ggYXMgQ0dOKSBpcyBQQ1AgU2VydmVyIGFuZCBoYXMgdHdvDQo+ID4gPj4+IG9yIG1vcmUN Cj4gPiA+PiBvdXQgaW50ZXJmYWNlcyB0byBpbnRlcm5ldCB3ZXJlIGRvaW5nIGRpZmZlcmVudCBu YXQgY29udmVyc2lvbiBpbiB0aGUNCj4gSVNQLg0KPiA+ID4+PiBNYXliZSB1c2luZyBOQVQgYWRk cmVzcyBwb29sIEEsIEIsIEMuLi4gQW5kIHRoZSByb3V0aW5nIGVudHJpZXMgdG8NCj4gPiA+Pj4g aW50ZXJuZXQNCj4gPiA+PiBvbiBOQVQgZ2F0ZXdheSBpcyBlcXVpdmFsZW50IGRlZmF1bHQgcm91 dGUuIEluIHRoaXMgY2FzZSwgdGhlIG91dA0KPiA+ID4+IGludGVyZmFjZSBpcyB1bmNlcnRhaW4s IGZ1bGx5IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgZXF1aXZhbGVudA0KPiA+ID4+IHJvdXRlDQo+ ID4gc2VsZWN0aW9uLg0KPiA+ID4+PiBJZiBubyBQQ1AsIHNlcnZpY2UgdHJhZmZpYyBjYW4gYmUg c2VsZWN0ZWQgb3V0IGludGVyZmFjZSBhY2NvcmRpbmcNCj4gPiA+Pj4gdG8gdGhlDQo+ID4gPj4g ZGVzdGluYXRpb24gYWRkcmVzcyBhbmQgZG8gZGlmZmVyZW50IE5BVCBjb252ZXJzaW9uLg0KPiA+ ID4+PiBCdXQgdGhlIFBDUCBtZXNzYWdlIGlzIGluIGJlZm9yZSB0aGUgbm9ybWFsIHNlcnZpY2Ug dHJhZmZpYy4gQW5kDQo+ID4gPj4+IFBDUCBNQVANCj4gPiA+PiBtb2RlIG1lc3NhZ2UgZG9lcyBu b3QgaW5jbHVkZSB0aGUgZGVzdGluYXRpb24gYWRkcmVzcywgdGhlIE5BVA0KPiA+ID4+IGdhdGV3 YXkgZGV2aWNlIGhvdyB0byBjaG9vc2UgdGhlIG91dCBpbnRlcmZhY2VzIGFuZCB0aGUgZGlmZmVy ZW50DQo+ID4gPj4gTkFUIGFkZHJlc3MgcG9vbHM/DQo+ID4gPj4+IEJhc2VkIG9uIHRoZSBjdXJy ZW50IFBDUCBwcm90b2NvbCwgSSB0aGluayB0aGF0IGNhbid0IGJlIHNvbHZlZC4NCj4gPiA+Pj4g T3Igd2hhdCBJDQo+ID4gPj4gdW5kZXJzdGFuZCBzb21ldGhpbmcgd3Jvbmc/DQo+ID4gPj4NCj4g PiA+PiBXaXRoIHN1Y2ggYSBuZXR3b3JrIHRvcG9sb2d5LCB5b3UgYXJlIGNvcnJlY3QgdGhhdCB0 aGUgY3VycmVudCBNQVANCj4gPiA+PiBvcGNvZGUgZG9lc24ndCB3b3JrLg0KPiA+ID4NCj4gPiA+ IEknbSBub3Qgc3VyZSBpdCdzIGZhaXIgdG8gc2F5IGl0ICJkb2Vzbid0IHdvcmsiLiAgSXQganVz dCBtZWFucyB0aGF0DQo+ID4gPiB0aGUgTkFUIHBpY2tzIG9uZSB1c2luZyBhbnkgaW1wbGVtZW50 YXRpb24tc3BlY2lmaWMgbWVjaGFuaXNtLiAgSW4NCj4gPiA+IHRoZSBzdGF0ZWQgZXhhbXBsZSBh Ym92ZSwgYm90aCBwb3NzaWJsZSBhbnN3ZXJzIGdvIHRvIHRoZSBJbnRlcm5ldCwNCj4gPiA+IHNv IHdoYXQNCj4gPiB3b3VsZG4ndCAid29yayI/DQo+ID4NCj4gPiBHb29kIHBvaW50LiAgU2FtZSB3 aXRoIGEgVENQIFNZTiAtLSBpdCBnZXRzIGFzc2lnbmVkIHRvIG9uZSBDR04sIG9yDQo+ID4gdGhl IG90aGVyDQo+ID4gLS0gaXQgd291bGRuJ3QgYmUgYXNzaWduZWQgdG8gYm90aC4gIEkgaGFkIGZp Z3VyZWQgdGhhdCBib3RoIGRvbid0DQo+ID4gcmVhbGx5LCByZWFsbHksIGdvIHRvIHRoZSBJbnRl cm5ldCwgbGlrZSB3aGF0IE5UVCBkb2VzIHdpdGggdGhlaXIgSVB2Ng0KPiA+IGRlZmF1bHQgcm91 dGUgaW4gSmFwYW4gKHdoaWNoIGRvZXNuJ3QgZ28gdG8gdGhlIEludGVybmV0KS4NCj4gDQo+IFll cyB0aGF0J3MgYW4gYWx0ZXJuYXRlIGV4YW1wbGUgdGhhdCdzIGdvb2QgdG8gZGlzY3VzcyAoaGVu Y2UgdGhlIGNoYW5nZSBpbg0KPiBzdWJqZWN0IGxpbmUpLCB3aGljaCBkcmFmdC1wZW5uby1wY3At em9uZXMgZG9lcy4gIEluIGEgbXVsdGktaG9tZWQgTkFUDQo+IGNhc2UsIEknZCBleHBlY3QgdGhl IGltcGxlbWVudGF0aW9uIHRvIHByZWZlciB0aGUgb25lIHRoYXQgYWN0dWFsbHkgZ29lcyB0bw0K PiB0aGUgSW50ZXJuZXQuDQo+IFRoYXQgaXMsIHNpbmNlIE1BUCB0cmllcyB0byBvcGVuIGEgcG9y dCBmb3IgImFueW9uZSIsIHRoZW4gd2hlbiBtdWx0aXBsZQ0KPiBjaG9pY2VzIGV4aXN0IHRoYXQg c3VwcG9ydCBkaWZmZXJlbnQgc2V0cyBvZiByZW1vdGUgcGVlcnMsIG9uZSBzaG91bGQgYnkNCj4g ZGVmYXVsdCBwcmVmZXIgdGhlIG9uZSB3aXRoIHRoZSBsYXJnZXIgc2V0LCBhcyBiZWluZyBjbG9z ZXIgdG8gdGhlIGRlc2lyZSBvZg0KPiAiYW55b25lIi4NCj4gDQo+IEFuZCBvZiBjb3Vyc2UgdGhl cmUgY291bGQgYmUgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgY29uZmlndXJhdGlvbiB0bw0KPiBv dmVycmlkZSB0aGUgZGVmYXVsdCwgb3IgcHJvdG9jb2wgc3VwcG9ydCBhIGxhIGRyYWZ0LXBlbm5v LXBjcC16b25lcyB0bw0KPiBzcGVjaWZ5IG5vbi1kZWZhdWx0IGJlaGF2aW9yLg0KPiANCj4gLURh dmUNCj4gDQo+ID4NCj4gPiAtZA0KPiA+DQo+ID4NCj4gPiA+DQo+ID4gPiBPbiB0aGUgdG9waWMg b2YgdGhlIGVycmF0YSwgSSBhZ3JlZSB3aXRoIFRlZCBpdCBpcyBub3QgYW4gZXJyYXRhLg0KPiA+ ID4gSXQncyBzaW1wbHkgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsIHRoYXQgdGhlIFJGQyBkb2Vz bid0IHNwZWNpZnksDQo+ID4gPiBzbyBpdCdzIHVwDQo+ID4gdG8gdGhlIHJlYWRlci4NCj4gPiA+ DQo+ID4gPiAtRGF2ZQ0KDQo= From dwing@cisco.com Wed Feb 12 22:22:20 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB72F1A0111 for ; Wed, 12 Feb 2014 22:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.76 X-Spam-Level: X-Spam-Status: No, score=-8.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eej9_pc0NasU for ; Wed, 12 Feb 2014 22:22:18 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 390281A00F5 for ; Wed, 12 Feb 2014 22:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4869; q=dns/txt; s=iport; t=1392272537; x=1393482137; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lX6iNO4R4Aw/kGvZgZgmQmwbS7HH48A0X50EoPw75Bw=; b=PJ1fjJjDBS9Ix0JXS13PcY/tWJjn5ZaVIutmwzMaGad3+WhFagkPyyew zmNYFR5wKr5tbZuGDLl4C0SLNi17uPez0TIYrCTGdcL2OzERjltpKmiB1 8TUNXQ/aLj9NyxWJX5qnQHQSJZXSutOV+HQGjAdjcfwKVu+VrCCX7Yrol w=; X-IronPort-AV: E=Sophos;i="4.95,837,1384300800"; d="scan'208";a="303830458" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 13 Feb 2014 06:22:17 +0000 Received: from [10.85.165.74] ([10.85.165.74]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1D6MEFf009564; Thu, 13 Feb 2014 06:22:15 GMT Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97B71@nkgeml508-mbx.china.huawei.com> Date: Wed, 12 Feb 2014 22:22:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <06F690E9-CCC1-4CC1-A7B5-07E0042EFE0A@cisco.com> References: <20140212033032.D4F0A7FC395@rfc-editor.org> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B71@nkgeml508-mbx.china.huawei.com> To: "Zhangzhan (Channy)" X-Mailer: Apple Mail (2.1510) Cc: Stuart Cheshire , Brian Haberman , PCP Working Group Subject: Re: [pcp] =?gb2312?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtU?= =?gb2312?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 06:22:21 -0000 On Feb 12, 2014, at 10:14 PM, "Zhangzhan (Channy)" = wrote: > This draft is proposed in 2011, but has expired, no refresh or = replacement? That's right. > The PEER mode include remote address maybe can be selected correct = zone. >=20 > The MAP mode only through the filter option to identify, if contains = more than one filter in one PCP message, and these filters maybe belong = to different zones.=20 > And an address pool may contain a number of different segments address = blocks, the filter maybe not be able to identify zones. >=20 > The ZONEID option should be a good solution, but the client to get the = zones information is a very difficult thing, because zones in CGN is = hidden for a client and no business relations. Zones maybe be changed, = how to keep the synchronization is a problem. That problem needs to be solved anyway, no matter if it's called ZONEID = or called something else. -d >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 10:23 > =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy) > =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; = mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler > =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: [Technical = Errata Reported] RFC6887 (3887) >=20 >=20 > On Feb 12, 2014, at 5:29 PM, Zhangzhan (Channy) = wrote: >=20 >> Maybe you misunderstand me. >> There is only one router for NAT and PCP. >> If the NAT gateway device (such as CGN) is PCP Server and has two or = more out interfaces to internet were doing different nat conversion in = the ISP.=20 >> Maybe using NAT address pool A, B, C... And the routing entries to = internet on NAT gateway is equivalent default route. In this case, the = out interface is uncertain, fully in accordance with the equivalent = route selection. >> If no PCP, service traffic can be selected out interface according to = the destination address and do different NAT conversion. >> But the PCP message is in before the normal service traffic. And PCP = MAP mode message does not include the destination address, the NAT = gateway device how to choose the out interfaces and the different NAT = address pools?=20 >> Based on the current PCP protocol, I think that can't be solved. Or = what I understand something wrong? >=20 > With such a network topology, you are correct that the current MAP = opcode doesn't work. We need something different. Would = http://tools.ietf.org/html/draft-penno-pcp-zones be a viable solution? >=20 > -d >=20 >=20 >>=20 >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20 >> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 9:02 >> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy) >> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; = mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler >> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: = [Technical Errata Reported] RFC6887 (3887) >>=20 >>=20 >> On Feb 12, 2014, at 4:49 PM, "Zhangzhan (Channy)" = wrote: >>=20 >>> "Indeed, it has been discussed." >>>=20 >>> What's the final conclusion to the discussion?=20 >>>=20 >>> How PCP applies in the Dual-Egress NAT scene? >>>=20 >>> Could you please share it?=20 >>=20 >> I removed the RFC Editor from the thread. >>=20 >> PCP client needs to communicate to both of the NATs independently. = Which the same host (the PCP client) needs to know how to do anyway to = send its TCP SYN to one ISP or the other ISP -- to send its TCP SYNs to = different networks, the host must have routing entries. The PCP client = can use those same routing entries to know there are two routers on the = network, and send PCP messages to those two routers separately. >>=20 >> -d >>=20 >>=20 >>>=20 >>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>> =B7=A2=BC=FE=C8=CB: Ted Lemon [mailto:ted.lemon@nominum.com]=20 >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 0:13 >>> =CA=D5=BC=FE=C8=CB: Dan Wing >>> =B3=AD=CB=CD: RFC Errata System; Zhangzhan (Channy); Stuart = Cheshire; mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler; PCP Working Group >>> =D6=F7=CC=E2: Re: [Technical Errata Reported] RFC6887 (3887) >>>=20 >>> On Feb 12, 2014, at 10:15 AM, Dan Wing wrote: >>>> It seems appropriate to discuss this question on the PCP mailing = list, pcp@ietf.org. >>>=20 >>> Indeed, it has been discussed. This isn't really an appropriate = topic for an erratum. >>>=20 >>=20 >=20 From Ted.Lemon@nominum.com Thu Feb 13 05:59:38 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6346C1A0105 for ; Thu, 13 Feb 2014 05:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.502 X-Spam-Level: *** X-Spam-Status: No, score=3.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBi8WgicjJwE for ; Thu, 13 Feb 2014 05:59:36 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id D78011A0008 for ; Thu, 13 Feb 2014 05:59:36 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0C7201B82A4 for ; Thu, 13 Feb 2014 05:59:36 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id EE17B190052; Thu, 13 Feb 2014 05:59:35 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 05:59:35 -0800 Content-Type: text/plain; charset="gb18030" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <06F690E9-CCC1-4CC1-A7B5-07E0042EFE0A@cisco.com> Date: Thu, 13 Feb 2014 08:59:30 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140212033032.D4F0A7FC395@rfc-editor.org> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B71@nkgeml508-mbx.china.huawei.com> <06F690E9-CCC1-4CC1-A7B5-07E0042EFE0A@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: Stuart Cheshire , Brian Haberman , "Zhangzhan \(Channy\)" , PCP Working Group Subject: Re: [pcp] =?gb18030?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6?= =?gb18030?q?_=5BTechnical_Errata_Reported=5D_RFC6887_=283887=29?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 13:59:38 -0000 On Feb 13, 2014, at 1:22 AM, Dan Wing wrote: >> This draft is proposed in 2011, but has expired, no refresh or = replacement? > That's right. Yes, this is why it's so important to discuss it in the working = group=A1=AAso that progress can resume! :) From repenno@cisco.com Thu Feb 13 06:08:09 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCA71A0186 for ; Thu, 13 Feb 2014 06:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.549 X-Spam-Level: X-Spam-Status: No, score=-11.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7fmf_geNOt4 for ; Thu, 13 Feb 2014 06:08:08 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A18BA1A0292 for ; Thu, 13 Feb 2014 06:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1114; q=dns/txt; s=iport; t=1392300472; x=1393510072; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tNnjuomByn+BgMK1mXfEK6udP6p1wlPDnJLoCJsQQqA=; b=d0yTVPm+iYkq+eRO6Z9oRyzipYdZm11rXSEk0axjYocfykdrvAugeHuF 3DTDwgel+1NA1WrNe/04V1GCNRVQgiqtHurl5jNJ0Fu+IY3mH3KPNLeC/ Z3RctWpJqmAMMBhynZvs8gcjdezUWOLPk+3HaWadokkMLRoLkdkhFJdVq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAGDQ/FKtJV2c/2dsb2JhbABZgwaBD4MAvEwYfhZ0giUBAQEENEUQAgEIEQQBAQEEBiICAjAaAwgCBAENBQiHfYl/m3MOoiUXgSCNKDEHgmY+gRQBA6pPgy2CKg X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208";a="303790397" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 13 Feb 2014 14:07:51 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1DE7pxt028103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 14:07:51 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 08:07:50 -0600 From: "Reinaldo Penno (repenno)" To: Ted Lemon , "Dan Wing (dwing)" Thread-Topic: =?big5?B?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7WqzmA6IFtUZWNobmljYWwgRXJy?= =?big5?Q?ata_Reported]_RFC6887_(3887)?= Thread-Index: AQHPJ6LPzMjxlXlS/USHNBsyymSwU5qxNTOAgAAQJoCAARNEUIAAaxgAgAAHuwCAAA7RAIAAQNAAgAACHQCAAH/CAP//nVfc Date: Thu, 13 Feb 2014 14:07:50 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B7A5F2E@xmb-rcd-x04.cisco.com> References: <20140212033032.D4F0A7FC395@rfc-editor.org> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B71@nkgeml508-mbx.china.huawei.com> <06F690E9-CCC1-4CC1-A7B5-07E0042EFE0A@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.113.31] Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Stuart Cheshire , Brian Haberman , "Zhangzhan \(Channy\)" , PCP Working Group Subject: Re: [pcp] =?big5?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7WqzmA6IFtU?= =?big5?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:08:10 -0000 SSBiZWxpZXZlIGF0IHRoYXQgdGltZSB3ZSBoYWQgYmlnZ2VyIGZpc2ggdG8gZnJ5IHN1Y2ggYXMg Y29tcGxldGluZyB0aGUgbWFpbiBzcGVjLiBJZiB0aGVyZSBpcyBlbm91Z2ggaW50ZXJlc3QgdGhp cyB3b3JrIGNvdWxkIGJlIHJlc3VtZWQuIAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpGcm9tOiBUZWQgTGVtb24gW3RlZC5sZW1vbkBub21pbnVtLmNvbV0KU2VudDog VGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE0IDU6NTkgQU0KVG86IERhbiBXaW5nIChkd2luZykK Q2M6IFpoYW5nemhhbiAoQ2hhbm55KTsgUENQIFdvcmtpbmcgR3JvdXA7IFN0dWFydCBDaGVzaGly ZTsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBCb3VjYWRhaXI7IFJlaW5hbGRvIFBlbm5v IChyZXBlbm5vKTsgcHNlbGtpcmtAaXNjLm9yZzsgQnJpYW4gSGFiZXJtYW47IERhdmUgVGhhbGVy ClN1YmplY3Q6IFJlOiBXaGF0J3MgdGhlIGZpbmFsIGNvbmNsdXNpb24/tarOYDogW1RlY2huaWNh bCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzY4ODcgKDM4ODcpCgpPbiBGZWIgMTMsIDIwMTQsIGF0IDE6 MjIgQU0sIERhbiBXaW5nIDxkd2luZ0BjaXNjby5jb20+IHdyb3RlOgo+PiBUaGlzIGRyYWZ0IGlz IHByb3Bvc2VkIGluIDIwMTEsIGJ1dCBoYXMgZXhwaXJlZCwgbm8gcmVmcmVzaCBvciByZXBsYWNl bWVudD8KPiBUaGF0J3MgcmlnaHQuCgpZZXMsIHRoaXMgaXMgd2h5IGl0J3Mgc28gaW1wb3J0YW50 IHRvIGRpc2N1c3MgaXQgaW4gdGhlIHdvcmtpbmcgZ3JvdXChWHNvIHRoYXQgcHJvZ3Jlc3MgY2Fu IHJlc3VtZSEgICA6KQoK From repenno@cisco.com Thu Feb 13 09:14:19 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3F21A0370 for ; Thu, 13 Feb 2014 09:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.549 X-Spam-Level: X-Spam-Status: No, score=-11.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8O1uGM8h9o9D for ; Thu, 13 Feb 2014 09:14:17 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 87DD41A036B for ; Thu, 13 Feb 2014 09:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1610; q=dns/txt; s=iport; t=1392311656; x=1393521256; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=AmVDLSMO3XTuzSqnin/+ETEj2AR5zeWuSs7f/DH8SnI=; b=KdmaxewIlyvHIf2lfuq95UiYd4GUuUuh2aGwbN/r+32GJZf75s0VEMHN adlK1DqnpzgHooCjPBZQEPm4jPROljLc2uDInRz33K2Q2w0pVVoxC4Hmt U27T6pG2akyR3tADWq60P3s76+aK4Q44LoaffjHIxZm6pwEZfCHAbSNZK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFACv9/FKtJXG8/2dsb2JhbABZgwaBD4MAvEwYgQAWdIIlAQEBBDRFEgEIEQQBAQEEKAQwGgMIAgQOBRmHbIlmm3MOoiEXgSCNJjMHgmaBUgEDmCySI4Mtgio X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="scan'208";a="303864357" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 13 Feb 2014 17:14:16 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1DHEGxY032614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 17:14:16 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 11:14:16 -0600 From: "Reinaldo Penno (repenno)" To: "Zhangzhan (Channy)" Thread-Topic: =?big5?B?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7WqzmA6IFtUZWNobmljYWwgRXJy?= =?big5?Q?ata_Reported]_RFC6887_(3887)?= Thread-Index: AQHPJ6LPzMjxlXlS/USHNBsyymSwU5qxNTOAgAAQJoCAARNEUIAAaxgAgAAHuwCAAA7RAIAAQNAAgAACHQCAAH/CAP//nVfcgAAS9QA= Date: Thu, 13 Feb 2014 17:14:15 +0000 Message-ID: In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B7A5F2E@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.102.89] Content-Type: text/plain; charset="big5" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: PCP Working Group Subject: Re: [pcp] =?big5?b?V2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7WqzmA6IFtU?= =?big5?b?ZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3KQ==?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:14:19 -0000 Wmhhbmd6aGFuLA0KDQpXb3VsZCB5b3UgY2FyZSB0byBwcmVzZW50IHlvdXIgdXNlLWNhc2UgYW5k IHByb2JsZW0gc3RhdGVtZW50IGF0IHRoZSBuZXh0DQpJRVRGPyANCg0KQXMgSSBzYWlkLCBJIHBy ZXNlbnRlZCB0aGlzIHByb3Bvc2FsIGJlZm9yZSBidXQgbWF5YmUgaXQgd2FzIHRvbyBlYXJseSBv bg0KV0cgbGlmZSBmb3Igb3RoZXJzIHRvIGRlZGljYXRlZCB0aW1lLg0KDQpUaGFua3MsDQoNClJl aW5hbGRvDQoNCk9uIDIvMTMvMTQsIDY6MDcgQU0sICJSZWluYWxkbyBQZW5ubyAocmVwZW5ubyki IDxyZXBlbm5vQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5JIGJlbGlldmUgYXQgdGhhdCB0aW1lIHdl IGhhZCBiaWdnZXIgZmlzaCB0byBmcnkgc3VjaCBhcyBjb21wbGV0aW5nIHRoZQ0KPm1haW4gc3Bl Yy4gSWYgdGhlcmUgaXMgZW5vdWdoIGludGVyZXN0IHRoaXMgd29yayBjb3VsZCBiZSByZXN1bWVk Lg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Gcm9tOiBU ZWQgTGVtb24gW3RlZC5sZW1vbkBub21pbnVtLmNvbV0NCj5TZW50OiBUaHVyc2RheSwgRmVicnVh cnkgMTMsIDIwMTQgNTo1OSBBTQ0KPlRvOiBEYW4gV2luZyAoZHdpbmcpDQo+Q2M6IFpoYW5nemhh biAoQ2hhbm55KTsgUENQIFdvcmtpbmcgR3JvdXA7IFN0dWFydCBDaGVzaGlyZTsNCj5tb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tIEJvdWNhZGFpcjsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8p Ow0KPnBzZWxraXJrQGlzYy5vcmc7IEJyaWFuIEhhYmVybWFuOyBEYXZlIFRoYWxlcg0KPlN1Ympl Y3Q6IFJlOiBXaGF0J3MgdGhlIGZpbmFsIGNvbmNsdXNpb24/tarOYDogW1RlY2huaWNhbCBFcnJh dGEgUmVwb3J0ZWRdDQo+UkZDNjg4NyAoMzg4NykNCj4NCj5PbiBGZWIgMTMsIDIwMTQsIGF0IDE6 MjIgQU0sIERhbiBXaW5nIDxkd2luZ0BjaXNjby5jb20+IHdyb3RlOg0KPj4+IFRoaXMgZHJhZnQg aXMgcHJvcG9zZWQgaW4gMjAxMSwgYnV0IGhhcyBleHBpcmVkLCBubyByZWZyZXNoIG9yDQo+Pj5y ZXBsYWNlbWVudD8NCj4+IFRoYXQncyByaWdodC4NCj4NCj5ZZXMsIHRoaXMgaXMgd2h5IGl0J3Mg c28gaW1wb3J0YW50IHRvIGRpc2N1c3MgaXQgaW4gdGhlIHdvcmtpbmcgZ3JvdXChWHNvDQo+dGhh dCBwcm9ncmVzcyBjYW4gcmVzdW1lISAgIDopDQo+DQoNCg== From nobody Thu Feb 13 09:45:33 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FE81A036E for ; Thu, 13 Feb 2014 09:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.76 X-Spam-Level: X-Spam-Status: No, score=-8.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 093mnyWz2sui for ; Thu, 13 Feb 2014 09:45:27 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3681A02B9 for ; Thu, 13 Feb 2014 09:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8061; q=dns/txt; s=iport; t=1392313526; x=1393523126; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1zIYyGF9+vaZtBV3gyG1I3I8OpJxiUjQmnvzJ8ui/E0=; b=OTQ9MiC+kgVfhfkbQfJxCbdlqt4C72p3645cqG7LzsZrMXsu3zdEECmP Am/p+TRJHw07W4Vf+aM5QkjvG1zNqIUL7UF5GwBwmmWUpEQZzLVIl1SMe uQ8BZDm7SD3s1nwio1ey/7YRg4fwfd8jI9M4g0mkL0lXFcBpNwLRVmiSG s=; X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="scan'208";a="102390557" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 13 Feb 2014 17:45:26 +0000 Received: from [10.85.165.74] ([10.85.165.74]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1DHjBhN025817; Thu, 13 Feb 2014 17:45:14 GMT Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97B88@nkgeml508-mbx.china.huawei.com> Date: Thu, 13 Feb 2014 09:45:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <80955F6E-204D-4B6B-BE45-9C1A0F0DD072@cisco.com> References: <20140212033032.D4F0A7FC395@rfc-editor.org> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B71@nkgeml508-mbx.china.huawei.com> <06F690E9-CCC1-4CC1-A7B5-07E0042EFE0A@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B88@nkgeml508-mbx.china.huawei.com> To: Zhangzhan (Channy) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/sqUU-WEm2Jbf_lJmJrEdfsXykME Cc: Stuart Cheshire , Brian Haberman , PCP Working Group Subject: Re: [pcp] =?gb2312?b?VGhpcyBzb2x1dGlvbiBpcyBmZWFzaWJsZT+08Li0OiBXaGF0?= =?gb2312?b?J3MgdGhlIGZpbmFsIGNvbmNsdXNpb24/tPC4tDogW1RlY2huaWNhbCBFcnJh?= =?gb2312?b?dGEgUmVwb3J0ZWRdIFJGQzY4ODcgKDM4ODcp?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:45:31 -0000 On Feb 12, 2014, at 11:06 PM, Zhangzhan (Channy) = wrote: > This solution is feasible? >=20 > We define a new result code, such as MULTIPLE_ZONES, and define a new = Opcode, such as GET_ZONE. > If the PCP server have more than one ZONE, reply a MULTIPLE_ZONES = result code message when receiving any PCP requests. > The client receives the result code, must send a GET_ZONE Opcode = request message. > The PCP server must replay a message which contains the list of all = ZONE ID information. > Then the client get the ZONE ID information, sends request messages = (PEER or MAP) which include ZONEID option. If there are N zones, client = must send N request messages. > Finally The PCP server can be selected the different address pools = according to the ZONEID information and create multiple different = mapping tables. > If the zone information is changed in PCP server, mapping tables must = be deleted and create new mapping table when receiving renewing messages = from clients. Seems like a good first cut, but I don't like breaking backwards = compatibility with existing PCP clients. Backwards compatibility is = broken in that second step (the step starting with "If the PCP server = have more than one ZONE ..."). Better would be if the PCP client tries = to do zone discovery when it sends its first MAP (such as an PCP = option), as that doesn't change state machine much. Here is what I am = thinking (view with fixed-width font): PCP Client PCP Server=09 ---------- ---------- | | |---MAP w/LEARN_ZONES option------->| | | | (one mapping is created) | | |<--mapped to zone=3D1, total zones=3D3-| | | |--GET_ZONE 1 details-------------->| |<--zone 1 details------------------| | | |--GET_ZONE 2 details-------------->| |<--zone 2 details------------------| | | |--GET_ZONE 3 details-------------->| |<--zone 3 details------------------| | | |--MAP, ZONE=3D2--------------------->| |<-ok-------------------------------| | | |--MAP, ZONE=3D3--------------------->| |<-ok-------------------------------| | | -d >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 14:22 > =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy) > =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; = mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler > =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: [Technical = Errata Reported] RFC6887 (3887) >=20 >=20 > On Feb 12, 2014, at 10:14 PM, "Zhangzhan (Channy)" = wrote: >=20 >> This draft is proposed in 2011, but has expired, no refresh or = replacement? >=20 > That's right. >=20 >> The PEER mode include remote address maybe can be selected correct = zone. >>=20 >> The MAP mode only through the filter option to identify, if contains = more than one filter in one PCP message, and these filters maybe belong = to different zones.=20 >> And an address pool may contain a number of different segments = address blocks, the filter maybe not be able to identify zones. >>=20 >> The ZONEID option should be a good solution, but the client to get = the zones information is a very difficult thing, because zones in CGN is = hidden for a client and no business relations. Zones maybe be changed, = how to keep the synchronization is a problem. >=20 > That problem needs to be solved anyway, no matter if it's called = ZONEID or called something else. >=20 > -d >=20 >=20 >>=20 >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20 >> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 10:23 >> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy) >> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; = mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler >> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: = [Technical Errata Reported] RFC6887 (3887) >>=20 >>=20 >> On Feb 12, 2014, at 5:29 PM, Zhangzhan (Channy) = wrote: >>=20 >>> Maybe you misunderstand me. >>> There is only one router for NAT and PCP. >>> If the NAT gateway device (such as CGN) is PCP Server and has two or = more out interfaces to internet were doing different nat conversion in = the ISP.=20 >>> Maybe using NAT address pool A, B, C... And the routing entries to = internet on NAT gateway is equivalent default route. In this case, the = out interface is uncertain, fully in accordance with the equivalent = route selection. >>> If no PCP, service traffic can be selected out interface according = to the destination address and do different NAT conversion. >>> But the PCP message is in before the normal service traffic. And PCP = MAP mode message does not include the destination address, the NAT = gateway device how to choose the out interfaces and the different NAT = address pools?=20 >>> Based on the current PCP protocol, I think that can't be solved. Or = what I understand something wrong? >>=20 >> With such a network topology, you are correct that the current MAP = opcode doesn't work. We need something different. Would = http://tools.ietf.org/html/draft-penno-pcp-zones be a viable solution? >>=20 >> -d >>=20 >>=20 >>>=20 >>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20 >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 9:02 >>> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy) >>> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; = mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler >>> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: = [Technical Errata Reported] RFC6887 (3887) >>>=20 >>>=20 >>> On Feb 12, 2014, at 4:49 PM, "Zhangzhan (Channy)" = wrote: >>>=20 >>>> "Indeed, it has been discussed." >>>>=20 >>>> What's the final conclusion to the discussion?=20 >>>>=20 >>>> How PCP applies in the Dual-Egress NAT scene? >>>>=20 >>>> Could you please share it?=20 >>>=20 >>> I removed the RFC Editor from the thread. >>>=20 >>> PCP client needs to communicate to both of the NATs independently. = Which the same host (the PCP client) needs to know how to do anyway to = send its TCP SYN to one ISP or the other ISP -- to send its TCP SYNs to = different networks, the host must have routing entries. The PCP client = can use those same routing entries to know there are two routers on the = network, and send PCP messages to those two routers separately. >>>=20 >>> -d >>>=20 >>>=20 >>>>=20 >>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>>> =B7=A2=BC=FE=C8=CB: Ted Lemon [mailto:ted.lemon@nominum.com]=20 >>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 0:13 >>>> =CA=D5=BC=FE=C8=CB: Dan Wing >>>> =B3=AD=CB=CD: RFC Errata System; Zhangzhan (Channy); Stuart = Cheshire; mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler; PCP Working Group >>>> =D6=F7=CC=E2: Re: [Technical Errata Reported] RFC6887 (3887) >>>>=20 >>>> On Feb 12, 2014, at 10:15 AM, Dan Wing wrote: >>>>> It seems appropriate to discuss this question on the PCP mailing = list, pcp@ietf.org. >>>>=20 >>>> Indeed, it has been discussed. This isn't really an appropriate = topic for an erratum. >>>>=20 >>>=20 >>=20 >=20 From nobody Thu Feb 13 19:24:23 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5166A1A00B8 for ; Thu, 13 Feb 2014 19:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.76 X-Spam-Level: X-Spam-Status: No, score=-8.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCtMJTDND8I0 for ; Thu, 13 Feb 2014 19:24:13 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 39BEA1A003B for ; Thu, 13 Feb 2014 19:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14739; q=dns/txt; s=iport; t=1392348252; x=1393557852; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=i/vqcI4a+4HfR+O4WzyffTuJcnbHnwzhhax/UuFB7x8=; b=Rr2GwHYXF/j9s4AN5yAfBiqBdddry7EzfCE9cPgpi9xrIo4yKn4rR1YK AaQxaiiG0aXA2WwJQ3EFRCwvZwKAsYnNEviVqzURkJO/BRIoY1U5EnZFj b/xGd82DXqFcObjRcGn56upTT3vHm4xzbqlKzwE1hI59qpEySvOUlRkqN Y=; X-IronPort-AV: E=Sophos;i="4.95,842,1384300800"; d="scan'208";a="102424989" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 14 Feb 2014 03:24:12 +0000 Received: from sjc-vpn5-1629.cisco.com (sjc-vpn5-1629.cisco.com [10.21.94.93]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1E3O7Mu016498; Fri, 14 Feb 2014 03:24:08 GMT Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97BCE@nkgeml508-mbx.china.huawei.com> Date: Thu, 13 Feb 2014 19:24:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140212033032.D4F0A7FC395@rfc-editor.org> <1DA8CEC3F3E989439069663C05A865D334F97AE6@nkgeml508-mbx.china.huawei.com> <1DA8CEC3F3E989439069663C05A865D334F97B15@nkgeml508-mbx.china.huawei.com> <315A4314-038C-4304-BB90-8DC75FFFF9B3@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B71@nkgeml508-mbx.china.huawei.com> <06F690E9-CCC1-4CC1-A7B5-07E0042EFE0A@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97B88@nkgeml508-mbx.china.huawei.com> <80955F6E-204D-4B6B-BE45-9C1A0F0DD072@cisco.com> <1DA8CEC3F3E989439069663C05A865D334F97BCE@nkgeml508-mbx.china.huawei.com> To: "Zhangzhan (Channy)" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/at-KfWE0uqKjf31jZDK3sooaKV8 Cc: Stuart Cheshire , Brian Haberman , PCP Working Group Subject: Re: [pcp] =?gb2312?b?VGhpcyBzb2x1dGlvbiBpcyBmZWFzaWJsZT+08Li0OiBXaGF0?= =?gb2312?b?J3MgdGhlIGZpbmFsIGNvbmNsdXNpb24/tPC4tDogW1RlY2huaWNhbCBFcnJh?= =?gb2312?b?dGEgUmVwb3J0ZWRdIFJGQzY4ODcgKDM4ODcp?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 03:24:20 -0000 On Feb 13, 2014, at 5:56 PM, "Zhangzhan (Channy)" = wrote: > PCP Client PCP Server=09 > ---------- ---------- > | | > |---MAP w/LEARN_ZONES option------->| > | | > | (one mapping is created) > | | > |<--mapped to zone=3D1, total zones=3D3-| > | | > |--GET_ZONE 1 details-------------->| > |<--zone 1 details------------------| > | | > |--GET_ZONE 2 details-------------->| > |<--zone 2 details------------------| > | | > |--GET_ZONE 3 details-------------->| > |<--zone 3 details------------------| > | | > |--MAP, ZONE=3D2--------------------->| > |<-ok-------------------------------| > | | > |--MAP, ZONE=3D3--------------------->| > |<-ok-------------------------------| > | | >=20 > I think this solution has one problem. > Based on RFC6887, we add a new LEARN_ZONES option, and client send = this option message firstly to get zone number of PCP server.=20 > It seems that pcp client know the server has more than one ZONEs in = advance. No, it doesn't. LEARN_ZONE would be in the optional-to-process range, = so the PCP client can safely send that option with any MAP request. If = the PCP server understands LEARN_ZONE, it includes LEARN_ZONE = information in the response. I show that the LEARN_ZONE information = would merely indicate the number of zones supported. If the PCP server = does not understand LEARN_ZONE, the PCP server omits the LEARN_ZONE = option from the response, but otherwise creates the requested MAP = normally (that is, the PCP server behaves as if the optional-to-process = LEARN_ZONE was not in the request at all). This gives good backwards and forwards compatibility. > But in actual network pcp client how to get this information?=20 > I think that supplementing on the basis of the existing is a better = way for protocol compatibility. >=20 > Refer to your idea chart, my idea chart is as follows: >=20 > PCP Client PCP Server=09 > ---------- ---------- > | | > |---MAP/PEER request--------------->| > | | > | (have more than one ZONEs) > | | > |<-----MULTIPLE_ZONES resultcode----| > | | > |--GET_ZONE Opcode----------------->| > |<--------------all zones detail----| > | | > |--MAP/PEER zone 1----------------->| > | | > | (mapping to zone 1) > | | > |<--ok------------------------------| > | | > |--MAP/PEER zone 2----------------->| > | | > | (mapping to zone 2) > | | > |<--ok------------------------------| > | | > |--MAP/PEER zone 3----------------->| > | | > | (mapping to zone 3) > | | > |<--ok------------------------------| > | | >=20 >=20 > Based on your idea, my idea to make the following change: >=20 > PCP Client PCP Server=09 > ---------- ---------- > | | > |---MAP/PEER request--------------->| > | | > | (have more than one ZONEs) > | | > |<----MULTIPLE_ZONES resultcode > ZONES_NUM option(zones=3D3)-----| So, that is an error message. Existing PCP clients will be unable to = create any sort of mapping. That seems undesirable, as it forces PCP = clients to understand how to handle zones, or else they cannot function. = If that is the desire, it is better to create an entirely new opcode = instead of overloading MAP as I proposed. I don't think such a failure = is desirable. Why force zone-unaware PCP clients to fail? -d > | | > |--GET_ZONE 1 details-------------->| > |<--zone 1 details------------------| > | | > |--GET_ZONE 2 details-------------->| > |<--zone 2 details------------------| > | | > |--GET_ZONE 3 details-------------->| > |<--zone 3 details------------------| > | | > |--MAP/PEER zone 1----------------->| > | | > | (mapping to zone 1) > | | > |<--ok------------------------------| > | | > |--MAP/PEER zone 2----------------->| > | | > | (mapping to zone 2) > | | > |<--ok------------------------------| > | | > |--MAP/PEER zone 3----------------->| > | | > | (mapping to zone 3) > | | > |<--ok------------------------------| > | | >=20 > The coupling degree of this idea is smaller, or not? >=20 >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C214=C8=D5 1:45 > =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy) > =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; = mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler > =D6=F7=CC=E2: Re: This solution is feasible?=B4=F0=B8=B4: What's the = final conclusion?=B4=F0=B8=B4: [Technical Errata Reported] RFC6887 = (3887) >=20 >=20 > On Feb 12, 2014, at 11:06 PM, Zhangzhan (Channy) = wrote: >=20 >> This solution is feasible? >>=20 >> We define a new result code, such as MULTIPLE_ZONES, and define a new = Opcode, such as GET_ZONE. >> If the PCP server have more than one ZONE, reply a MULTIPLE_ZONES = result code message when receiving any PCP requests. >> The client receives the result code, must send a GET_ZONE Opcode = request message. >> The PCP server must replay a message which contains the list of all = ZONE ID information. >> Then the client get the ZONE ID information, sends request messages = (PEER or MAP) which include ZONEID option. If there are N zones, client = must send N request messages. >> Finally The PCP server can be selected the different address pools = according to the ZONEID information and create multiple different = mapping tables. >> If the zone information is changed in PCP server, mapping tables must = be deleted and create new mapping table when receiving renewing messages = from clients. >=20 > Seems like a good first cut, but I don't like breaking backwards = compatibility with existing PCP clients. Backwards compatibility is = broken in that second step (the step starting with "If the PCP server = have more than one ZONE ..."). Better would be if the PCP client tries = to do zone discovery when it sends its first MAP (such as an PCP = option), as that doesn't change state machine much. Here is what I am = thinking (view with fixed-width font): >=20 > PCP Client PCP Server=09 > ---------- ---------- > | | > |---MAP w/LEARN_ZONES option------->| > | | > | (one mapping is created) > | | > |<--mapped to zone=3D1, total zones=3D3-| > | | > |--GET_ZONE 1 details-------------->| > |<--zone 1 details------------------| > | | > |--GET_ZONE 2 details-------------->| > |<--zone 2 details------------------| > | | > |--GET_ZONE 3 details-------------->| > |<--zone 3 details------------------| > | | > |--MAP, ZONE=3D2--------------------->| > |<-ok-------------------------------| > | | > |--MAP, ZONE=3D3--------------------->| > |<-ok-------------------------------| > | | >=20 >=20 > -d >=20 >=20 >>=20 >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20 >> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 14:22 >> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy) >> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; = mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler >> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: = [Technical Errata Reported] RFC6887 (3887) >>=20 >>=20 >> On Feb 12, 2014, at 10:14 PM, "Zhangzhan (Channy)" = wrote: >>=20 >>> This draft is proposed in 2011, but has expired, no refresh or = replacement? >>=20 >> That's right. >>=20 >>> The PEER mode include remote address maybe can be selected correct = zone. >>>=20 >>> The MAP mode only through the filter option to identify, if contains = more than one filter in one PCP message, and these filters maybe belong = to different zones.=20 >>> And an address pool may contain a number of different segments = address blocks, the filter maybe not be able to identify zones. >>>=20 >>> The ZONEID option should be a good solution, but the client to get = the zones information is a very difficult thing, because zones in CGN is = hidden for a client and no business relations. Zones maybe be changed, = how to keep the synchronization is a problem. >>=20 >> That problem needs to be solved anyway, no matter if it's called = ZONEID or called something else. >>=20 >> -d >>=20 >>=20 >>>=20 >>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20 >>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 10:23 >>> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy) >>> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; = mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler >>> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: = [Technical Errata Reported] RFC6887 (3887) >>>=20 >>>=20 >>> On Feb 12, 2014, at 5:29 PM, Zhangzhan (Channy) = wrote: >>>=20 >>>> Maybe you misunderstand me. >>>> There is only one router for NAT and PCP. >>>> If the NAT gateway device (such as CGN) is PCP Server and has two = or more out interfaces to internet were doing different nat conversion = in the ISP.=20 >>>> Maybe using NAT address pool A, B, C... And the routing entries to = internet on NAT gateway is equivalent default route. In this case, the = out interface is uncertain, fully in accordance with the equivalent = route selection. >>>> If no PCP, service traffic can be selected out interface according = to the destination address and do different NAT conversion. >>>> But the PCP message is in before the normal service traffic. And = PCP MAP mode message does not include the destination address, the NAT = gateway device how to choose the out interfaces and the different NAT = address pools?=20 >>>> Based on the current PCP protocol, I think that can't be solved. Or = what I understand something wrong? >>>=20 >>> With such a network topology, you are correct that the current MAP = opcode doesn't work. We need something different. Would = http://tools.ietf.org/html/draft-penno-pcp-zones be a viable solution? >>>=20 >>> -d >>>=20 >>>=20 >>>>=20 >>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>>> =B7=A2=BC=FE=C8=CB: Dan Wing [mailto:dwing@cisco.com]=20 >>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 9:02 >>>> =CA=D5=BC=FE=C8=CB: Zhangzhan (Channy) >>>> =B3=AD=CB=CD: Ted Lemon; PCP Working Group; Stuart Cheshire; = mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler >>>> =D6=F7=CC=E2: Re: What's the final conclusion?=B4=F0=B8=B4: = [Technical Errata Reported] RFC6887 (3887) >>>>=20 >>>>=20 >>>> On Feb 12, 2014, at 4:49 PM, "Zhangzhan (Channy)" = wrote: >>>>=20 >>>>> "Indeed, it has been discussed." >>>>>=20 >>>>> What's the final conclusion to the discussion?=20 >>>>>=20 >>>>> How PCP applies in the Dual-Egress NAT scene? >>>>>=20 >>>>> Could you please share it?=20 >>>>=20 >>>> I removed the RFC Editor from the thread. >>>>=20 >>>> PCP client needs to communicate to both of the NATs independently. = Which the same host (the PCP client) needs to know how to do anyway to = send its TCP SYN to one ISP or the other ISP -- to send its TCP SYNs to = different networks, the host must have routing entries. The PCP client = can use those same routing entries to know there are two routers on the = network, and send PCP messages to those two routers separately. >>>>=20 >>>> -d >>>>=20 >>>>=20 >>>>>=20 >>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>>>> =B7=A2=BC=FE=C8=CB: Ted Lemon [mailto:ted.lemon@nominum.com]=20 >>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA2=D4=C213=C8=D5 0:13 >>>>> =CA=D5=BC=FE=C8=CB: Dan Wing >>>>> =B3=AD=CB=CD: RFC Errata System; Zhangzhan (Channy); Stuart = Cheshire; mohamed.boucadair@orange.com Boucadair; Reinaldo Penno; = pselkirk@isc.org; Brian Haberman; Dave Thaler; PCP Working Group >>>>> =D6=F7=CC=E2: Re: [Technical Errata Reported] RFC6887 (3887) >>>>>=20 >>>>> On Feb 12, 2014, at 10:15 AM, Dan Wing wrote: >>>>>> It seems appropriate to discuss this question on the PCP mailing = list, pcp@ietf.org. >>>>>=20 >>>>> Indeed, it has been discussed. This isn't really an appropriate = topic for an erratum. >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Thu Feb 13 19:24:43 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0311A00D1 for ; Thu, 13 Feb 2014 19:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.76 X-Spam-Level: X-Spam-Status: No, score=-3.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya1rjYT1v2Oj for ; Thu, 13 Feb 2014 19:24:23 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id E6EDE1A003B for ; Thu, 13 Feb 2014 19:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2440; q=dns/txt; s=iport; t=1392348262; x=1393557862; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vLNbhaOyXsDWnV4VgxiSoavxq+zYKshMzc6Lq7IrKS4=; b=lllgtFv8Rg2Vn6u/sEvQgRrpYzV9a6m1iscRmkUh/VGHC3HdJ2HdKhMx NkcEWpjvdTcVbp16nAIW/PXS9B00SRb3qEeYKb3/43aoquOZ9WVqw7hdq iRVygoBGdbKdeMQBaIVP/N6lgliU0IMATx4Kt6XCRwMdgCpZX8JsSa2Lp w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAOiL/VKtJV2d/2dsb2JhbABZgwaBD4MCvFcYgQEWdIIlAQEBBDRFEgEGAhEEAQEBBCMFBDAUBgMIAgQOBRkCh2qKZZt5CKFyF4EljTkbB4JrgU0BA5gskiOBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,842,1384300800"; d="scan'208";a="20367430" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 14 Feb 2014 03:24:21 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1E3OLW3015066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 03:24:21 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 21:24:20 -0600 From: "Reinaldo Penno (repenno)" To: "Zhangzhan (Channy)" Thread-Topic: =?gb2312?B?tPC4tDogV2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7TwuLQ6IFtUZWNo?= =?gb2312?Q?nical_Errata_Reported]_RFC6887_(3887)?= Thread-Index: AQHPJ6LPzMjxlXlS/USHNBsyymSwU5qxNTOAgAAQJoCAARNEUIAAaxgAgAAHuwCAAA7RAIAAQNAAgAACHQCAAH/CAP//nVfcgAAS9QCAARv7AP//jnkA Date: Fri, 14 Feb 2014 03:24:20 +0000 Message-ID: In-Reply-To: <1DA8CEC3F3E989439069663C05A865D334F97BE1@nkgeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.155.66.4] Content-Type: text/plain; charset="gb2312" Content-ID: <0542A4F6508457439A4A6086705467E3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/xu04IDEY2Ol56Pv6PqR-M_sXrn0 Cc: PCP Working Group Subject: Re: [pcp] =?gb2312?b?tPC4tDogV2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9uP7Tw?= =?gb2312?b?uLQ6IFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM2ODg3ICgzODg3?= =?gb2312?b?KQ==?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 03:24:25 -0000 SnVzdCBwdXQgYSBwb3dlcnBvaW50IHByZXNlbnRhdGlvbiB0b2dldGhlciBkZXNjcmliaW5nIHlv dXIgaXNzdWUsDQpwcm9wb3NlZCBzb2x1dGlvbiwgd2hhdG5vdC4NCg0KQW5kIHRlbGwgdXMgaG93 IG11Y2ggdGltZSB5b3UgbmVlZC4NCg0KT24gMi8xMy8xNCwgNjoxMCBQTSwgIlpoYW5nemhhbiAo Q2hhbm55KSIgPGNoYW5ueS56aGFuZ0BodWF3ZWkuY29tPiB3cm90ZToNCg0KPkl0J3MgbXkgcGxl YXN1cmUuDQo+DQo+Q291bGQgeW91IHRlbGwgbWUgaG93IHRvIHByZXNlbnQ/IEFueSBlbnRyYW5j ZSBvciBndWlkZT8NCj4NCj4NCj4tLS0tLdPKvP7Urbz+LS0tLS0NCj63orz+yMs6IFJlaW5hbGRv IFBlbm5vIChyZXBlbm5vKSBbbWFpbHRvOnJlcGVubm9AY2lzY28uY29tXQ0KPreiy83KsbzkOiAy MDE0xOoy1MIxNMjVIDE6MTQNCj7K1bz+yMs6IFpoYW5nemhhbiAoQ2hhbm55KQ0KPrOty806IFBD UCBXb3JraW5nIEdyb3VwDQo+1vfM4jogUmU6IFdoYXQncyB0aGUgZmluYWwgY29uY2x1c2lvbj+0 8Li0OiBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0NCj5SRkM2ODg3ICgzODg3KQ0KPg0KPlpo YW5nemhhbiwNCj4NCj5Xb3VsZCB5b3UgY2FyZSB0byBwcmVzZW50IHlvdXIgdXNlLWNhc2UgYW5k IHByb2JsZW0gc3RhdGVtZW50IGF0IHRoZSBuZXh0DQo+SUVURj8gDQo+DQo+QXMgSSBzYWlkLCBJ IHByZXNlbnRlZCB0aGlzIHByb3Bvc2FsIGJlZm9yZSBidXQgbWF5YmUgaXQgd2FzIHRvbyBlYXJs eSBvbg0KPldHIGxpZmUgZm9yIG90aGVycyB0byBkZWRpY2F0ZWQgdGltZS4NCj4NCj5UaGFua3Ms DQo+DQo+UmVpbmFsZG8NCj4NCj5PbiAyLzEzLzE0LCA2OjA3IEFNLCAiUmVpbmFsZG8gUGVubm8g KHJlcGVubm8pIiA8cmVwZW5ub0BjaXNjby5jb20+IHdyb3RlOg0KPg0KPj5JIGJlbGlldmUgYXQg dGhhdCB0aW1lIHdlIGhhZCBiaWdnZXIgZmlzaCB0byBmcnkgc3VjaCBhcyBjb21wbGV0aW5nIHRo ZQ0KPj5tYWluIHNwZWMuIElmIHRoZXJlIGlzIGVub3VnaCBpbnRlcmVzdCB0aGlzIHdvcmsgY291 bGQgYmUgcmVzdW1lZC4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+RnJvbTogVGVkIExlbW9uIFt0ZWQubGVtb25Abm9taW51bS5jb21dDQo+PlNlbnQ6 IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCA1OjU5IEFNDQo+PlRvOiBEYW4gV2luZyAoZHdp bmcpDQo+PkNjOiBaaGFuZ3poYW4gKENoYW5ueSk7IFBDUCBXb3JraW5nIEdyb3VwOyBTdHVhcnQg Q2hlc2hpcmU7DQo+Pm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gQm91Y2FkYWlyOyBSZWlu YWxkbyBQZW5ubyAocmVwZW5ubyk7DQo+PnBzZWxraXJrQGlzYy5vcmc7IEJyaWFuIEhhYmVybWFu OyBEYXZlIFRoYWxlcg0KPj5TdWJqZWN0OiBSZTogV2hhdCdzIHRoZSBmaW5hbCBjb25jbHVzaW9u P7TwuLQ6IFtUZWNobmljYWwgRXJyYXRhDQo+PlJlcG9ydGVkXQ0KPj5SRkM2ODg3ICgzODg3KQ0K Pj4NCj4+T24gRmViIDEzLCAyMDE0LCBhdCAxOjIyIEFNLCBEYW4gV2luZyA8ZHdpbmdAY2lzY28u Y29tPiB3cm90ZToNCj4+Pj4gVGhpcyBkcmFmdCBpcyBwcm9wb3NlZCBpbiAyMDExLCBidXQgaGFz IGV4cGlyZWQsIG5vIHJlZnJlc2ggb3INCj4+Pj5yZXBsYWNlbWVudD8NCj4+PiBUaGF0J3Mgcmln aHQuDQo+Pg0KPj5ZZXMsIHRoaXMgaXMgd2h5IGl0J3Mgc28gaW1wb3J0YW50IHRvIGRpc2N1c3Mg aXQgaW4gdGhlIHdvcmtpbmcgZ3JvdXChqnNvDQo+PnRoYXQgcHJvZ3Jlc3MgY2FuIHJlc3VtZSEg ICA6KQ0KPj4NCj4NCg0K From nobody Fri Feb 14 01:07:45 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60331A01B3 for ; Fri, 14 Feb 2014 01:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FH6-DVnxDui for ; Fri, 14 Feb 2014 01:07:38 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E47D11A01F4 for ; Fri, 14 Feb 2014 01:07:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4D905106CCB for ; Fri, 14 Feb 2014 10:07:17 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUE6KIMjhNMs for ; Fri, 14 Feb 2014 10:07:17 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 281A7106CCA for ; Fri, 14 Feb 2014 10:07:12 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 14 Feb 2014 10:07:12 +0100 From: Andreas Ripke To: "pcp@ietf.org" Thread-Topic: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt Thread-Index: AQHPKNN183BuJolhBUq4sUpr4CoLq5q0dB4Q Date: Fri, 14 Feb 2014 09:07:11 +0000 Message-ID: <2D2FFE4726FAF74285C45D69FDC30E79631D6915@PALLENE.office.hd> References: <20140213155106.26257.47053.idtracker@ietfa.amsl.com> In-Reply-To: <20140213155106.26257.47053.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.215] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/fUbdxFos3cUYYUO6AGrV9a195VM Subject: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 09:07:42 -0000 SGksDQoNClRoZSBiZWxvdyBkcmFmdCBkZXNjcmliZXMgYSBzY2VuYXJpbyBpbiB0aGF0DQogICgx KSB0aGUgc3Vic2NyaWJlcnMgYmVoaW5kIGEgQ0dOIGNhbiBmcmVlbHkgY2hvb3NlIHRoZWlyIGlu dGVybmFsIElQIGFkZHJlc3Nlcw0KICAgICAgICh3aGljaCBwb3RlbnRpYWxseSBsZWFkcyB0byBv dmVybGFwcGluZyBJUCBhZGRyZXNzIHNwYWNlcykNCiAgKDIpIGEgY2VudHJhbCBQQ1AgY2xpZW50 IGlzIHVzZWQgZm9yIHBvcnQgbWFwcGluZyByZXF1ZXN0cy4NClRoZSBDR04sIGFjdGluZyBhcyBQ Q1Agc2VydmVyLCBjYW5ub3QgaWRlbnRpZnkgdGhlIHN1YnNjcmliZXIganVzdCBieSB0aGUgaW50 ZXJuYWwgSVAgYWRkcmVzcyBwcm92aWRlZCB3aXRoIHRoZSBUSElSRF9QQVJUWSBvcHRpb24uDQpU aGVyZWZvcmUsIGFuIGFkZGl0aW9uYWwgaWRlbnRpZmllciAodGhlIHN1YnNjcmliZXLigJlzIHR1 bm5lbCBJRCkgdG8gdGhlIFBDUCBtYXBwaW5nIHJlcXVlc3QgaXMgbmVlZGVkLg0KDQpJZiB5b3Ug aGF2ZSBhbnkgY29tbWVudHMgb24gdGhpcyBkcmFmdCBwbGVhc2UgbGV0IHVzIGtub3cuIFRoYW5r cy4NCg0KQmVzdCwNCg0KQW5kcmVhcw0KDQoNCk5FQyBFdXJvcGUgTHRkIHwgUmVnaXN0ZXJlZCBP ZmZpY2U6IEF0aGVuZSwgT2R5c3NleSBCdXNpbmVzcyBQYXJrLCBXZXN0IEVuZCAgUm9hZCwgTG9u ZG9uLCBIQTQgNlFFLCBHQiB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0DQoNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFRodXJzZGF5LCBG ZWJydWFyeSAxMywgMjAxNCA0OjUxIFBNDQo+IFRvOiBBbmRyZWFzIFJpcGtlOyBSYWZhZWwgTG9w ZXogZGEgU2lsdmE7IFJhZmFlbCBMb3BleiBkYSBTaWx2YTsgVGhvbWFzIERpZXR6Ow0KPiBKdWVy Z2VuIFF1aXR0ZWs7IEp1ZXJnZW4gUXVpdHRlazsgVGhvbWFzIERpZXR6OyBBbmRyZWFzIFJpcGtl DQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmlwa2UtcGNw LXR1bm5lbC1pZC1vcHRpb24tMDAudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LXJpcGtlLXBjcC10dW5uZWwtaWQtb3B0aW9uLTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFuZHJlYXMgUmlwa2UgYW5kIHBvc3RlZCB0byB0aGUgSUVU Rg0KPiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LXJpcGtlLXBjcC10dW5uZWwtaWQt b3B0aW9uDQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJCVBDUCBUdW5uZWwtSUQgT3B0aW9uDQo+ IERvY3VtZW50IGRhdGU6CTIwMTQtMDItMTMNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCj4gUGFnZXM6CQk4DQo+IFVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1yaXBrZS1wY3AtdHVubmVsLWlkLQ0KPiBvcHRpb24tMDAudHh0 DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1yaXBrZS1wY3AtdHVubmVsLWlkLW9wdGlvbi8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpcGtlLXBjcC10dW5uZWwtaWQtb3B0aW9uLTAwDQo+ IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbmV3IFBv cnQgQ29udHJvbCBQcm90b2NvbCAoUENQKSBvcHRpb24NCj4gICAgY2FsbGVkIFRVTk5FTF9JRC4g IEl0IHNlcnZlcyBmb3IgaWRlbnRpZnlpbmcgYSBUaGlyZCBQYXJ0eSBpbg0KPiAgICBhZGRpdGlv biB0byB0aGUgbWVhbnMgdGhhdCBQQ1AncyBUSElSRF9QQVJUWSBvcHRpb24gYWxyZWFkeSBwcm92 aWRlcw0KPiAgICBmb3IgdGhhdCBwdXJwb3NlLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Feb 14 07:08:44 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6CA1A02BB for ; Fri, 14 Feb 2014 07:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYhb3sDhYCs8 for ; Fri, 14 Feb 2014 07:08:36 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6781A02A2 for ; Fri, 14 Feb 2014 07:08:32 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 97E2640222 for ; Fri, 14 Feb 2014 10:08:30 -0500 (EST) Message-ID: <52FE316E.7000708@viagenie.ca> Date: Fri, 14 Feb 2014 10:08:30 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: pcp@ietf.org References: <20140213155106.26257.47053.idtracker@ietfa.amsl.com> <2D2FFE4726FAF74285C45D69FDC30E79631D6915@PALLENE.office.hd> In-Reply-To: <2D2FFE4726FAF74285C45D69FDC30E79631D6915@PALLENE.office.hd> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/aBb01pjI2PQRjHV7O8DHBORBj-8 Subject: Re: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:08:41 -0000 Le 2014-02-14 04:07, Andreas Ripke a écrit : > The below draft describes a scenario in that > (1) the subscribers behind a CGN can freely choose their internal IP addresses > (which potentially leads to overlapping IP address spaces) > (2) a central PCP client is used for port mapping requests. > The CGN, acting as PCP server, cannot identify the subscriber just by the internal IP address provided with the THIRD_PARTY option. > Therefore, an additional identifier (the subscriber’s tunnel ID) to the PCP mapping request is needed. Eerily similar to draft-ietf-pcp-dslite... Why not send the PCP request inside the tunnel? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Feb 14 08:09:34 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2611A0242 for ; Fri, 14 Feb 2014 08:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQL96DdF6RRx for ; Fri, 14 Feb 2014 08:09:28 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1AD1A02FB for ; Fri, 14 Feb 2014 08:09:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5204C106CD5; Fri, 14 Feb 2014 17:09:21 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZHrxDnrvoKj; Fri, 14 Feb 2014 17:09:21 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 37EC3106CDD; Fri, 14 Feb 2014 17:09:11 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 14 Feb 2014 17:09:11 +0100 From: Andreas Ripke To: Simon Perreault , "pcp@ietf.org" Thread-Topic: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt Thread-Index: AQHPKNN183BuJolhBUq4sUpr4CoLq5q0dB4QgABWtACAAB34wA== Date: Fri, 14 Feb 2014 16:09:11 +0000 Message-ID: <2D2FFE4726FAF74285C45D69FDC30E79631D69FE@PALLENE.office.hd> References: <20140213155106.26257.47053.idtracker@ietfa.amsl.com> <2D2FFE4726FAF74285C45D69FDC30E79631D6915@PALLENE.office.hd> <52FE316E.7000708@viagenie.ca> In-Reply-To: <52FE316E.7000708@viagenie.ca> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.215] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/0k1rYqZR0AJFBjAqrMvO15d35Cs Cc: Rolf Winter , Thomas Dietz Subject: Re: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:09:31 -0000 SGkgU2ltb24sDQoNClRoZSB1c2UtY2FzZSBpbiBkcmFmdC1pZXRmLXBjcC1kc2xpdGUgaXMgYSBk aWZmZXJlbnQgb25lLg0KVGhlcmUsIHRoZSBQQ1AgcHJveHkgb3IgY2xpZW50IGlzIGxvY2F0ZWQg aW4gdGhlIGN1c3RvbWVyJ3MgcmVhbG0uDQpXaGF0IHdlIGRlc2NyaWJlIGlzIGEgc2NlbmFyaW8g d2l0aCBvbmUgY2VudHJhbCBQQ1AgY2xpZW50IGxvY2F0ZWQgb24gYSB3ZWIgcG9ydGFsIHNlcnZp bmcgYWxsIGN1c3RvbWVycy4NClRoZXJlZm9yZSwgYW4gYWRkaXRpb25hbCBpZGVudGlmaWVyIGlz IG5lZWRlZCBieSB0aGUgUENQIHNlcnZlciB0byBhc3NvY2lhdGUgdGhlIGNvbm5lY3Rpb24gdG8g YmUgbWFwcGVkIHdpdGggdGhlIGN1c3RvbWVyJ3MgdHVubmVsLg0KDQpCZXN0LA0KDQpBbmRyZWFz DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcGNwIFttYWlsdG86cGNw LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaW1vbiBQZXJyZWF1bHQNCj4gU2VudDog RnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCA0OjA5IFBNDQo+IFRvOiBwY3BAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtwY3BdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXJpcGtlLXBjcC10dW5uZWwtaWQtDQo+IG9wdGlvbi0wMC50eHQNCj4gDQo+IExlIDIwMTQtMDIt MTQgMDQ6MDcsIEFuZHJlYXMgUmlwa2UgYSDDqWNyaXQgOg0KPiA+IFRoZSBiZWxvdyBkcmFmdCBk ZXNjcmliZXMgYSBzY2VuYXJpbyBpbiB0aGF0DQo+ID4gICAoMSkgdGhlIHN1YnNjcmliZXJzIGJl aGluZCBhIENHTiBjYW4gZnJlZWx5IGNob29zZSB0aGVpciBpbnRlcm5hbCBJUA0KPiBhZGRyZXNz ZXMNCj4gPiAgICAgICAgKHdoaWNoIHBvdGVudGlhbGx5IGxlYWRzIHRvIG92ZXJsYXBwaW5nIElQ IGFkZHJlc3Mgc3BhY2VzKQ0KPiA+ICAgKDIpIGEgY2VudHJhbCBQQ1AgY2xpZW50IGlzIHVzZWQg Zm9yIHBvcnQgbWFwcGluZyByZXF1ZXN0cy4NCj4gPiBUaGUgQ0dOLCBhY3RpbmcgYXMgUENQIHNl cnZlciwgY2Fubm90IGlkZW50aWZ5IHRoZSBzdWJzY3JpYmVyIGp1c3QgYnkgdGhlDQo+IGludGVy bmFsIElQIGFkZHJlc3MgcHJvdmlkZWQgd2l0aCB0aGUgVEhJUkRfUEFSVFkgb3B0aW9uLg0KPiA+ IFRoZXJlZm9yZSwgYW4gYWRkaXRpb25hbCBpZGVudGlmaWVyICh0aGUgc3Vic2NyaWJlcuKAmXMg dHVubmVsIElEKSB0byB0aGUgUENQDQo+IG1hcHBpbmcgcmVxdWVzdCBpcyBuZWVkZWQuDQo+IA0K PiBFZXJpbHkgc2ltaWxhciB0byBkcmFmdC1pZXRmLXBjcC1kc2xpdGUuLi4NCj4gDQo+IFdoeSBu b3Qgc2VuZCB0aGUgUENQIHJlcXVlc3QgaW5zaWRlIHRoZSB0dW5uZWw/DQo+IA0KPiBTaW1vbg0K PiAtLQ0KPiBEVE4gbWFkZSBlYXN5LCBsZWFuLCBhbmQgc21hcnQgLS0+IGh0dHA6Ly9wb3N0ZWxs YXRpb24udmlhZ2VuaWUuY2ENCj4gTkFUNjQvRE5TNjQgb3Blbi1zb3VyY2UgICAgICAgIC0tPiBo dHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYQ0KPiBTVFVOL1RVUk4gc2VydmVyICAgICAgICAgICAg ICAgLS0+IGh0dHA6Ly9udW1iLnZpYWdlbmllLmNhDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwY3AgbWFpbGluZyBsaXN0DQo+IHBjcEBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjcA0K From nobody Fri Feb 14 10:51:04 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F0B1A0341; Fri, 14 Feb 2014 10:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0KecmQjCD5m; Fri, 14 Feb 2014 10:50:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 352511A02D0; Fri, 14 Feb 2014 10:50:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214185059.6512.98492.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 10:50:59 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/FZ89i_tPInKxTPO2Z0lnfWXQbpI Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-anycast-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:51:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : PCP Anycast Address Authors : Sebastian Kiesel Reinaldo Penno Stuart Cheshire Filename : draft-ietf-pcp-anycast-01.txt Pages : 16 Date : 2014-02-14 Abstract: The Port Control Protocol (PCP) Anycast Address enables PCP clients to transmit signaling messages to their closest on-path NAT, Firewall, or other middlebox, without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP Anycast Address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-anycast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-anycast-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-anycast-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 11:04:39 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D571A0045 for ; Fri, 14 Feb 2014 11:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKduFi1uzvhv for ; Fri, 14 Feb 2014 11:04:33 -0800 (PST) Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) by ietfa.amsl.com (Postfix) with ESMTP id E80C41A02A3 for ; Fri, 14 Feb 2014 11:04:32 -0800 (PST) Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.80) (envelope-from ) id 1WEO3p-00017R-Hn for pcp@ietf.org; Fri, 14 Feb 2014 20:04:29 +0100 Date: Fri, 14 Feb 2014 20:04:29 +0100 From: Sebastian Kiesel To: pcp@ietf.org Message-ID: <20140214190429.GA3221@gw01.ehlo.wurstkaes.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/ldcMMPZOBi-jNeqyzyn-vplx95A Subject: [pcp] FWD: I-D Action: draft-ietf-pcp-anycast-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:04:36 -0000 Dear all, this version of the draft has a dramatically shortened deployment considerations section. All discussion of possible mechanisms to deal with multiple PCP servers and asymetric routing removed, keeping just a statement that this is beyond the scope of this document. Your reviews/comments/suggestions are appreciated. Thanks Sebastian ----- Forwarded message from internet-drafts@ietf.org ----- Date: Fri, 14 Feb 2014 10:50:59 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-anycast-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : PCP Anycast Address Authors : Sebastian Kiesel Reinaldo Penno Stuart Cheshire Filename : draft-ietf-pcp-anycast-01.txt Pages : 16 Date : 2014-02-14 Abstract: The Port Control Protocol (PCP) Anycast Address enables PCP clients to transmit signaling messages to their closest on-path NAT, Firewall, or other middlebox, without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP Anycast Address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-anycast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-anycast-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-anycast-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp ----- End forwarded message ----- From nobody Sat Feb 15 10:47:21 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBD11A027A for ; Sat, 15 Feb 2014 10:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6RLcFCh_eyG for ; Sat, 15 Feb 2014 10:47:17 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 03F941A026D for ; Sat, 15 Feb 2014 10:47:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8AA22106CC6; Sat, 15 Feb 2014 19:47:14 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOFgzUo-QBT2; Sat, 15 Feb 2014 19:47:14 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 6BEA51068B5; Sat, 15 Feb 2014 19:46:59 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Sat, 15 Feb 2014 19:46:38 +0100 From: Juergen Quittek To: Andreas Ripke , Simon Perreault , "pcp@ietf.org" Thread-Topic: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt Thread-Index: AQHPKNN1JE4TS3eChESgjCh6CKOftJq0Zd+AgABk8wCAABD1gIABzLKg Date: Sat, 15 Feb 2014 18:46:37 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E877A5A617@PALLENE.office.hd> References: <20140213155106.26257.47053.idtracker@ietfa.amsl.com> <2D2FFE4726FAF74285C45D69FDC30E79631D6915@PALLENE.office.hd> <52FE316E.7000708@viagenie.ca> <2D2FFE4726FAF74285C45D69FDC30E79631D69FE@PALLENE.office.hd> In-Reply-To: <2D2FFE4726FAF74285C45D69FDC30E79631D69FE@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/4ae_8i65n6bSeKtb_r5GZPmuAME Cc: "ralds@tid.es" , Rolf Winter , Thomas Dietz Subject: Re: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 18:47:20 -0000 RGVhciBhbGwsDQoNClllcywgdGhhdCBpcyB0aGUgZGlmZmVyZW5jZS4NCg0KSW4gdGhlIHBjcC1k c2xpdGUgc2NlbmFyaW8sIHRoZSBQQ1AgcHJveHkgc2VuZHMgUENQIHJlcXVlc3RzIHdpdGhpbiB0 aGUgRFNsaXRlIHR1bm5lbC4gVGhlIHJlY2VpdmluZyBQQ1AgU2VydmVyL05BVCBjYW4gbWFwIHRo ZSByZXF1ZXN0IHRvIGEgRFNsaXRlIHR1bm5lbCwgYmVjYXVzZSBpdCBjYW4gb2JzZXJ2ZSBmcm9t IHdoaWNoIHR1bm5lbCB0aGUgcmVxdWVzdCBjb21lcy4gDQoNCkluIHRoZSBzY2VuYXJpbyBvZiBw Y3AtdHVubmVsLWlkLCB0aGUgcmVxdWVzdCBjb21lcyBmcm9tIG91dHNpZGUgdGhlIHR1bm5lbCwg ZnJvbSBhIHBvcnRhbCBvZiB0aGUgTkFUIG9wZXJhdG9yIHdoZXJlIGNsaWVudHMgY2FuIGNvbmZp Z3VyZSB0aGVpciBzZXJ2aWNlcy4gSGVyZSwgdGhlIFBDUCBjbGllbnQgaGFzIHRvIHVzZSB0aGUg VEhJUkRfUEFSVFkgb3B0aW9uIHRvIGlkZW50aWZ5IHRoZSBJbnRlcm5hbCBIb3N0LiBJZiB0aGUg SW50ZXJuYWwgSG9zdCBpcyB1c2luZyBwcml2YXRlIGFkZHJlc3NlcywgaXQgbmVlZHMgZnVydGhl ciBpZGVudGlmaWNhdGlvbi4gVGhpcyBpcyB3aGF0IHRoZSBUVU5ORUxfSUQgb3B0aW9uIGlzIHBy b3Bvc2VkIHRvIGJlIHVzZWQgZm9yLg0KDQpDaGVlcnMsDQogICAgSnVlcmdlbg0KIA0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmRyZWFzIFJpcGtlDQo+IFNlbnQ6IEZy ZWl0YWcsIDE0LiBGZWJydWFyIDIwMTQgMTc6MDkNCj4gVG86IFNpbW9uIFBlcnJlYXVsdDsgcGNw QGlldGYub3JnDQo+IENjOiBKdWVyZ2VuIFF1aXR0ZWs7IFRob21hcyBEaWV0ejsgUm9sZiBXaW50 ZXINCj4gU3ViamVjdDogUkU6IFtwY3BdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXJpcGtlLXBjcC10dW5uZWwtDQo+IGlkLW9wdGlvbi0wMC50eHQNCj4gDQo+IEhpIFNp bW9uLA0KPiANCj4gVGhlIHVzZS1jYXNlIGluIGRyYWZ0LWlldGYtcGNwLWRzbGl0ZSBpcyBhIGRp ZmZlcmVudCBvbmUuDQo+IFRoZXJlLCB0aGUgUENQIHByb3h5IG9yIGNsaWVudCBpcyBsb2NhdGVk IGluIHRoZSBjdXN0b21lcidzIHJlYWxtLg0KPiBXaGF0IHdlIGRlc2NyaWJlIGlzIGEgc2NlbmFy aW8gd2l0aCBvbmUgY2VudHJhbCBQQ1AgY2xpZW50IGxvY2F0ZWQgb24gYSB3ZWINCj4gcG9ydGFs IHNlcnZpbmcgYWxsIGN1c3RvbWVycy4NCj4gVGhlcmVmb3JlLCBhbiBhZGRpdGlvbmFsIGlkZW50 aWZpZXIgaXMgbmVlZGVkIGJ5IHRoZSBQQ1Agc2VydmVyIHRvIGFzc29jaWF0ZQ0KPiB0aGUgY29u bmVjdGlvbiB0byBiZSBtYXBwZWQgd2l0aCB0aGUgY3VzdG9tZXIncyB0dW5uZWwuDQo+IA0KPiBC ZXN0LA0KPiANCj4gQW5kcmVhcw0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+IEZyb206IHBjcCBbbWFpbHRvOnBjcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg U2ltb24gUGVycmVhdWx0DQo+ID4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCA0OjA5 IFBNDQo+ID4gVG86IHBjcEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbcGNwXSBGVzogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+IGRyYWZ0LXJpcGtlLXBjcC10dW5uZWwtaWQt IG9wdGlvbi0wMC50eHQNCj4gPg0KPiA+IExlIDIwMTQtMDItMTQgMDQ6MDcsIEFuZHJlYXMgUmlw a2UgYSDDqWNyaXQgOg0KPiA+ID4gVGhlIGJlbG93IGRyYWZ0IGRlc2NyaWJlcyBhIHNjZW5hcmlv IGluIHRoYXQNCj4gPiA+ICAgKDEpIHRoZSBzdWJzY3JpYmVycyBiZWhpbmQgYSBDR04gY2FuIGZy ZWVseSBjaG9vc2UgdGhlaXIgaW50ZXJuYWwNCj4gPiA+IElQDQo+ID4gYWRkcmVzc2VzDQo+ID4g PiAgICAgICAgKHdoaWNoIHBvdGVudGlhbGx5IGxlYWRzIHRvIG92ZXJsYXBwaW5nIElQIGFkZHJl c3Mgc3BhY2VzKQ0KPiA+ID4gICAoMikgYSBjZW50cmFsIFBDUCBjbGllbnQgaXMgdXNlZCBmb3Ig cG9ydCBtYXBwaW5nIHJlcXVlc3RzLg0KPiA+ID4gVGhlIENHTiwgYWN0aW5nIGFzIFBDUCBzZXJ2 ZXIsIGNhbm5vdCBpZGVudGlmeSB0aGUgc3Vic2NyaWJlciBqdXN0DQo+ID4gPiBieSB0aGUNCj4g PiBpbnRlcm5hbCBJUCBhZGRyZXNzIHByb3ZpZGVkIHdpdGggdGhlIFRISVJEX1BBUlRZIG9wdGlv bi4NCj4gPiA+IFRoZXJlZm9yZSwgYW4gYWRkaXRpb25hbCBpZGVudGlmaWVyICh0aGUgc3Vic2Ny aWJlcuKAmXMgdHVubmVsIElEKSB0bw0KPiA+ID4gdGhlIFBDUA0KPiA+IG1hcHBpbmcgcmVxdWVz dCBpcyBuZWVkZWQuDQo+ID4NCj4gPiBFZXJpbHkgc2ltaWxhciB0byBkcmFmdC1pZXRmLXBjcC1k c2xpdGUuLi4NCj4gPg0KPiA+IFdoeSBub3Qgc2VuZCB0aGUgUENQIHJlcXVlc3QgaW5zaWRlIHRo ZSB0dW5uZWw/DQo+ID4NCj4gPiBTaW1vbg0KPiA+IC0tDQo+ID4gRFROIG1hZGUgZWFzeSwgbGVh biwgYW5kIHNtYXJ0IC0tPiBodHRwOi8vcG9zdGVsbGF0aW9uLnZpYWdlbmllLmNhDQo+ID4gTkFU NjQvRE5TNjQgb3Blbi1zb3VyY2UgICAgICAgIC0tPiBodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5j YQ0KPiA+IFNUVU4vVFVSTiBzZXJ2ZXIgICAgICAgICAgICAgICAtLT4gaHR0cDovL251bWIudmlh Z2VuaWUuY2ENCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gcGNwIG1haWxpbmcgbGlzdA0KPiA+IHBjcEBpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNwDQo= From nobody Mon Feb 17 15:48:13 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE1B1A05B8 for ; Mon, 17 Feb 2014 15:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8_bD1DQiXk7 for ; Mon, 17 Feb 2014 15:48:05 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id E00C61A043D for ; Mon, 17 Feb 2014 15:48:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1209; q=dns/txt; s=iport; t=1392680880; x=1393890480; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=KXG305Kj5jQaOxAp8NVuOrtOSaKTaFxOc13vquhBMQI=; b=MHXSJsq4xW/Bv3+DlJVJeyFwsZ+LvQI1eb2xW6U5dqjOue6YSk4dz97+ rESXtOgLVu3yd9ciodHrh9UaiVTAngNje0Q3to8SsNWVkr8geGX+SckNp lG9VSqYtSgUcB4e8ZlmC3qKt9RGAvplEyBWR4F0Me+mYMj5k8QyByy4/n Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAMyeAlOtJXG9/2dsb2JhbABZgwY4V8BgFnSCJQEBAQQBAQFrHQEIOzILGwEGBQQTiAUNmUGwfReOLYUTBIkQjxyBMpBxgW+BPoIq X-IronPort-AV: E=Sophos;i="4.95,863,1384300800"; d="scan'208";a="21133020" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-5.cisco.com with ESMTP; 17 Feb 2014 23:47:59 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1HNlxKY026106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Feb 2014 23:47:59 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 17:47:58 -0600 From: "Charles Eckel (eckelcu)" To: "pcp@ietf.org" Thread-Topic: [Aeon] Time slots for AEON session at IETF 89 - Please indicate available via link below by Wed. Feb 19 Thread-Index: AQHPLDqvmtNJ9L8wukKWAsGpI1Inkg== Date: Mon, 17 Feb 2014 23:47:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.79.36] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7793D31DFAA7E244914273E19A1A0DC2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/KsT9k5MKEyOt2k4BSOifnlwcpek Subject: [pcp] FW: [Aeon] Time slots for AEON session at IETF 89 - Please indicate available via link below by Wed. Feb 19 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 23:48:07 -0000 FYI, if you had interested in the concepts introduced in "PCP Flowdata Option=B2, draft-wing-pcp-flowdata-00 (http://tools.ietf.org/html/draft-wing-pcp-flowdata-00), which was presented in this WG at a pervious IETF, you may also be interested in subscribing to the AEON list and attending the AEON meeting announced in the forwarded e-mail. Cheers, Charles On 2/17/14, 10:12 AM, "Charles Eckel (eckelcu)" wrote: >AEON list members and other interested parties, > >We plan to reserve an IESG breakout room to have an AEON meeting at IETF >89 in London. >Please indicate which of the potential time slots work for you no later >than Wednesday, Feb 19. >All time slots are 1 hour in duration. >The actual location and time will be announced on the AEON list. > > >Preliminary agenda is as follows: >1) problem statement draft >2) draft charter > >The agenda will be finalized via a separate thread on the AEON list as >well. >Here is the link to the poll: >http://www.doodle.com/fb8k5hyqap4iqyye > > >Cheers, >Charles > >_______________________________________________ >Aeon mailing list >Aeon@ietf.org >https://www.ietf.org/mailman/listinfo/aeon From nobody Tue Feb 18 00:54:12 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347FB1A009E for ; Tue, 18 Feb 2014 00:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jW7mhTj49qyk for ; Tue, 18 Feb 2014 00:54:07 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A19B31A012B for ; Tue, 18 Feb 2014 00:54:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7A001106D29 for ; Tue, 18 Feb 2014 09:54:04 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLNDk11ak9OL for ; Tue, 18 Feb 2014 09:54:04 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 5D326106D28 for ; Tue, 18 Feb 2014 09:53:59 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 18 Feb 2014 09:54:00 +0100 From: Andreas Ripke To: "pcp@ietf.org" Thread-Topic: PCP WG Call for Presentation - IETF London Thread-Index: AQHPI3U71M6Y0T32I0K+YWkcpYErOZq0x1VggAX+hWA= Date: Tue, 18 Feb 2014 08:53:58 +0000 Message-ID: <2D2FFE4726FAF74285C45D69FDC30E79631D6D8C@PALLENE.office.hd> References: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.215] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/Yj1_aGS3FWBkkf8ffjGhoAzwqC0 Subject: [pcp] FW: PCP WG Call for Presentation - IETF London X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 08:54:10 -0000 > Hi, >=20 > We would like to have a slot for presenting draft-ripke-pcp-tunnel-id-opt= ion- > 00.txt > (http://tools.ietf.org/html/draft-ripke-pcp-tunnel-id-option-00). > Most likely Rolf Winter will be presenting. > Duration: 10mins. >=20 > Thanks. >=20 > Best, >=20 > Andreas >=20 >=20 > NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West > End =A0Road, London, HA4 6QE, GB | Registered in England 2832014 >=20 >=20 >=20 > From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Reinaldo Penno > (repenno) > Sent: Thursday, February 06, 2014 8:54 PM > To: pcp@ietf.org > Subject: [pcp] PCP WG Call for Presentation - IETF London >=20 > If you would like to present, please send title, time needed, presenter a= nd > pointer to draft (if exists). >=20 > Thanks, >=20 > Chairs From nobody Tue Feb 18 06:20:54 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B231A04D5 for ; Tue, 18 Feb 2014 06:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZourSUJQi2s for ; Tue, 18 Feb 2014 06:20:48 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id DE2FF1A01CB for ; Tue, 18 Feb 2014 06:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9621; q=dns/txt; s=iport; t=1392733245; x=1393942845; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xQ23iiDG0ciKiivaJwjPsjs5lf10KKzGEII43Aj22wY=; b=XccMWrqe56SwBLWQtrRSesavU73VivkImACpBPm/vNRWrLaXh97NvTPJ tlTmo6lC7m6KWqH6nkr4Lu+lsQiaKo/UzjQMlBdpw2nboyik9D55bTAnR gEJjSWcYabFe7ouo2XxaiuLz3gPkpOF3Fw+kuRnSue+Y6Ymjeg6dP/Hdc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFACtrA1OtJXG9/2dsb2JhbABZgwY4V79QgRUWdIIlAQEBAwEBAQEkEzQbAgEINhAnCyUCBAESh30IDcttF44eaoQ4BJgsgTKQcYMtgio X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208";a="21264576" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-6.cisco.com with ESMTP; 18 Feb 2014 14:20:44 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1IEKixM031528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 14:20:44 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.116]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 08:20:44 -0600 From: "Prashanth Patil (praspati)" To: Simon Perreault , "pcp@ietf.org" Thread-Topic: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21 Thread-Index: AQHPLLSbX79HGCj/7kO9PWHLSSzZLw== Date: Tue, 18 Feb 2014 14:20:44 +0000 Message-ID: References: <52FBF3A3.2070009@viagenie.ca> In-Reply-To: <52FBF3A3.2070009@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.47.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <0E9E905B52A17646BAD60F88F764B48E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/xgC_5hCWMIZdFAeSDPI5Y7MILeQ Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 14:20:52 -0000 Hi, On 2/13/14 3:50 AM, "Simon Perreault" wrote: >All, > >Here's my review... > >Summary: This draft contains major issues that need to be resolved >before being sent to IESG. > >> 3. IP Address Selection >>=20 >> These steps specify the behavior to be followed by the PCP client to >> contact a PCP server when the PCP client has multiple IP addresses >> for a single PCP server. > >How does the client know that those addresses belong to a single PCP >server? A PCP client, via DHCP for example, can learn a list of IP addresses for the same PCP server and a list of unique PCP servers. https://tools.ietf.org/html/draft-ietf-pcp-dhcp-09#page-5 > >Does this work when there are multiple addresses that belong to multiple >PCP servers, or does it need to be a single server? It works in both cases. The draft first describes how a PCP client goes about contacting a PCP server that has multiple addresses. The same steps are to be followed for each unique PCP server learnt (each of which may again have multiple addresses). >From the draft: "If several PCP servers are configured, each with multiple IP addresses, the PCP client contacts all PCP servers in parallel following the steps described above." > >Are we assuming that there is always a single PCP server per interface, >and therefore all addresses can only belong to a single server by >definition? No, we're not making that assumption. > >> 1. If the PCP client can use both address families when >> communicating to a particular PCP server, the PCP client SHOULD >> select the source address of the PCP request to be of the same IP >> address family as its requested PCP mapping (i.e., the address >> family of the Requested External IP Address). > >This is wrong. You can't pick a source address based on the requested >external address family. You can only pick the address family. For >example, you can decide that you're going to use IPv6 to request an IPv6 >external address, but that does not help decide which source IPv6 >address you're going to use. Agreed. What is currently described addresses PEER and MAP+FILTER cases where source and destination IP addresses are known. In case of MAP, what you say is right. For MAP, based on the address family the client intends to listen on, the client makes an appropriate request to each distinct server. We'll have to fix this. > >And this is even more fundamentally wrong. The address family of the PCP >request depends on your internal address family, not the suggested >external address family. If your server is listening on IPvX, you send >your PCP request over IPvX. Otherwise you have to play games with >THIRD_PARTY. The external address family has nothing to do with it. > >In fact, the source address you're going to select has to be one your >server is listening on. Otherwise you'll have to play games with >THIRD_PARTY. Often servers just listen on the wildcard address, so that >does not help you pick one particular address, but if that's not the >case then you don't have a choice. > >Finally, "Requested External IP Address" is not a PCP term. I think you >mean "Suggested External IP Address". Ok. > >> 2. Whenever communicating with a PCP server, the rules of Section 6 >> of [RFC6724] SHOULD be followed by using the source address >> selected in the previous step as input to the destination address >> selection algorithm. > >Step 1 did not yield a particular source address. It yielded an address >family. You still need to pick a particular source address. > >> 3. The PCP client initializes its Maximum Retransmission Count (MRC) >> to 4. >>=20 >> 4. The PCP client sends its PCP message to the PCP server's IP >> address following the retransmission procedure specified in >> Section 8.1.1 of [RFC6887]. If no response is received after MRC >> attempts, the PCP client re-tries the procedure excluding the >> destination addresses which did not respond. The PCP client >> SHOULD ignore any response received from an IP address after >> exhausting MRC attempts for that particular IP address. If, when >> sending PCP requests, the PCP client receives a hard ICMP error >> [RFC1122] it SHOULD immediately try the next IP address from the >> list of PCP server' IP addresses. >>=20 >> 5. If the PCP client has exhausted all IP addresses configured for a >> given PCP server, the procedure is repeated every fifteen minutes >> until the PCP request is successfully answered. >>=20 >> 6. Once the PCP client has successfully received a response from a >> PCP server's IP address, it sends subsequent PCP requests to the >> same server's IP address until that IP address becomes non- >> responsive, which causes the PCP client to follow the steps above >> to contact its PCP server. > >Do we reset the destination address set then? That is, are addresses >that failed previously now potentially good again? Yes, the client has to attempt contacting the servers again. > >> 4. Multiple Interfaces >>=20 >> When an end host has multiple interfaces concurrently active (e.g., >> IEEE 802.11 and 3G), a PCP client would discover different PCP >> servers over different interfaces. A host may have multiple network >> interfaces (e.g, 3G, IEEE 802.11, etc.); each configured differently. >> Each PCP server learned MUST be associated with the interface via >> which it was learned. Particularly, the PCP client relies on the >> source IP address of an outgoing PCP request to select which PCP >> server(s) to use. > >That last sentence would be wrong following my feedback to section 3. > >> 5. Example: Multiple PCP servers on a Single Interface >>=20 >> Figure 1 depicts an example that is used to illustrate the server >> selection procedure specified in Section 3. >>=20 >> ISP Network >> | | >> ......................................................... >> | | Subscriber Network >> +-------+------+ +----+---------+ >> | PCP-Server-A | | PCP-Server-B | >> | | | | >> +-------+------+ +----+---------+ >> 192.0.2.1 | | 198.51.100.1 >> 2001:db8:2222::1 | | 2001:db8:3333::1 >> | | >> | | >> -------+--------------+----------- >> | >> | 203.0.113.0 >> | 2001:db8:1111::1 >> +---+---+ >> | Host | >> +-------+ >>=20 >> Figure 1 > >The PCP servers in this figure look like routers. To make things clearer: > >- Remove the connection from each PCP server to the ISP network. > >- Draw the "PCP-controlled device". That one would look like a router >and would be sitting on the border between the subscriber network and >the ISP network. Connect it to both PCP servers and the host. No need >for addresses. > >Is there only one PCP-controlled device, or does each server control its >own device? Each server controls its own device. With this clarification, do you still think the figure needs to be updated? The text below the figure illustrates how the client goes about contacting the two distinct servers. > >> The PCP client sends two PCP requests at the same time, > >Really? The algorithm from section 3 does not seem to allow parallel >requests. I'm lost. It does, as described in an earlier comment and the last paragraph of http://tools.ietf.org/html/draft-ietf-pcp-server-selection-02#section-3. There are two potential scenarios. A single server having multiple addresses AND multiple PCP servers itself. The draft tries to address both scenarios. If this is unclear, we'll have to see how to re-organize to make it more obvious. -Prashanth > >> the first to >> 192.0.2.1 (corresponding to PCP-Server-A) and the second to >> 198.51.100.1 (corresponding to PCP-Server-B). The path to >> 198.51.100.1 is working so a PCP response is received. Because the >> path to 192.0.2.1 is broken, no PCP response is received. The PCP >> client retries 4 times to elicit a response from 192.0.2.1 and >> finally gives up on that address and sends a PCP message to >> 2001::db8:1111:1. That path is working, and a response is received. >> Thereafter, the PCP client should continue using that responsive IP >> address for PCP-Server-A (2001:db8:1111::1). In this particular >> case, it will have to use THIRD_PARTY option for IPv4 mappings. > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From nobody Tue Feb 18 06:28:17 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B3D1A01D4 for ; Tue, 18 Feb 2014 06:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zrw55XJGAuOe for ; Tue, 18 Feb 2014 06:28:12 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id BD93A1A060E for ; Tue, 18 Feb 2014 06:28:11 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A46C94040D; Tue, 18 Feb 2014 09:28:08 -0500 (EST) Message-ID: <53036DF8.9050003@viagenie.ca> Date: Tue, 18 Feb 2014 09:28:08 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "pcp@ietf.org" References: <52FBF3A3.2070009@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/PwzDTo65MM-c-0TMCqXixjeHeME Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 14:28:17 -0000 Le 2014-02-18 09:20, Prashanth Patil (praspati) a écrit : >> How does the client know that those addresses belong to a single PCP >> server? > > A PCP client, via DHCP for example, can learn a list of IP addresses for > the same PCP server and a list of unique PCP servers. > https://tools.ietf.org/html/draft-ietf-pcp-dhcp-09#page-5 > > >> >> Does this work when there are multiple addresses that belong to multiple >> PCP servers, or does it need to be a single server? > > It works in both cases. > > The draft first describes how a PCP client goes about contacting a PCP > server that has multiple addresses. The same steps are to be followed for > each unique PCP server learnt (each of which may again have multiple > addresses). > > From the draft: > "If several PCP servers are configured, each with multiple IP addresses, > the PCP client contacts all PCP servers in parallel following the steps > described above." Good. That makes sense. >>> 6. Once the PCP client has successfully received a response from a >>> PCP server's IP address, it sends subsequent PCP requests to the >>> same server's IP address until that IP address becomes non- >>> responsive, which causes the PCP client to follow the steps above >>> to contact its PCP server. >> >> Do we reset the destination address set then? That is, are addresses >> that failed previously now potentially good again? > > Yes, the client has to attempt contacting the servers again. Ok. It would be nice to mention it explicitly. >>> 5. Example: Multiple PCP servers on a Single Interface >>> >>> Figure 1 depicts an example that is used to illustrate the server >>> selection procedure specified in Section 3. >>> >>> ISP Network >>> | | >>> ......................................................... >>> | | Subscriber Network >>> +-------+------+ +----+---------+ >>> | PCP-Server-A | | PCP-Server-B | >>> | | | | >>> +-------+------+ +----+---------+ >>> 192.0.2.1 | | 198.51.100.1 >>> 2001:db8:2222::1 | | 2001:db8:3333::1 >>> | | >>> | | >>> -------+--------------+----------- >>> | >>> | 203.0.113.0 >>> | 2001:db8:1111::1 >>> +---+---+ >>> | Host | >>> +-------+ >>> >>> Figure 1 >> >> The PCP servers in this figure look like routers. To make things clearer: >> >> - Remove the connection from each PCP server to the ISP network. >> >> - Draw the "PCP-controlled device". That one would look like a router >> and would be sitting on the border between the subscriber network and >> the ISP network. Connect it to both PCP servers and the host. No need >> for addresses. >> >> Is there only one PCP-controlled device, or does each server control its >> own device? > > Each server controls its own device. With this clarification, do you still > think the figure needs to be updated? Yes. >>> The PCP client sends two PCP requests at the same time, >> >> Really? The algorithm from section 3 does not seem to allow parallel >> requests. I'm lost. > > It does, as described in an earlier comment and the last paragraph of > http://tools.ietf.org/html/draft-ietf-pcp-server-selection-02#section-3. > There are two potential scenarios. A single server having multiple > addresses AND multiple PCP servers itself. The draft tries to address both > scenarios. If this is unclear, we'll have to see how to re-organize to > make it more obvious. I think that would be necessary. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Feb 18 08:40:20 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032E51A04D4 for ; Tue, 18 Feb 2014 08:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3xou1j29dhU for ; Tue, 18 Feb 2014 08:40:17 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9D41A0504 for ; Tue, 18 Feb 2014 08:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=732; q=dns/txt; s=iport; t=1392741614; x=1393951214; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=mlKSC3AKUVD5YaXsnakN1ORsJm9foCEJYG7eELS1HT0=; b=CSQT08umTX9oAaD/XXiwTcz/ybAyY6XksncXGI1CVMZbT5XhCs4B/8Wv 4bITTxSQqjBfaDCEmWnOGiRHXMMUA+dGVkDs0Gr80DJyYF9x6K06Tmww7 1AkDx6iuMNmw4RK4B+wHtEagXrsmg/8sHOCT3Xhcreq1/ONcUY4CwpIO9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAHiMA1OtJXG8/2dsb2JhbABZgwY4V8BqFnSCLIELAYEAJwSIGA2ac7EdF5NABIkQjxyBMpBxgy2CKg X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208";a="304855417" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 18 Feb 2014 16:40:14 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1IGeEOG016970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Feb 2014 16:40:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 10:40:14 -0600 From: "Reinaldo Penno (repenno)" To: PCP Working Group Thread-Topic: PCP Presentation Slots so far Thread-Index: AQHPLMgYyqPqIEtprkClBlORpGNshw== Date: Tue, 18 Feb 2014 16:40:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.89.179] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/1MtBDQBj6URcU6qPAomONH11piA Subject: [pcp] PCP Presentation Slots so far X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:40:19 -0000 PCP Proxy =AD 20 minutes - Simon http://tools.ietf.org/html/draft-ietf-pcp-proxy-05 PCP Authentication =AD 20 minutes =AD Dacheng http://tools.ietf.org/html/draft-ietf-pcp-authentication-03 PCP Anycast =AD 10 minutes - Sebastian http://tools.ietf.org/html/draft-ietf-pcp-anycast-01 PCP Extension for Third Party Authorization =AD 10min -Tiru http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-02 PCP Tunnel ID Option =AD 10min =AD Rolf Winter http://tools.ietf.org/html/draft-ripke-pcp-tunnel-id-option-00. PCP Support for Multi-Homing/Egress NATs - 15mins - Zhangzhan (Channy) No draft, but refer to: http://tools.ietf.org/id/draft-penno-pcp-zones-01.txt Also presentation sent to list on Feb 13th From nobody Fri Feb 21 09:10:38 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF461A0483; Fri, 21 Feb 2014 09:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXdb24WG5p1H; Fri, 21 Feb 2014 09:10:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A85C1A02D0; Fri, 21 Feb 2014 09:10:34 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140221171034.15533.45654.idtracker@ietfa.amsl.com> Date: Fri, 21 Feb 2014 09:10:34 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/5LtSrLkwqd_3s2eeZbQPXtZ6-yo Cc: pcp@ietf.org Subject: [pcp] I-D ACTION:draft-ietf-pcp-description-option-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:10:36 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : PCP Description Option Author(s) : M. Boucadair, et al Filename : draft-ietf-pcp-description-option Pages : 6 Date : 2014-02-21 This document extends Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does so by defining a new DESCRIPTION option. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-description-option-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcp-description-option"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-21091034.I-D@ietf.org> --NextPart-- From nobody Fri Feb 21 09:13:08 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51681A047E; Fri, 21 Feb 2014 09:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqJA0nx2X8GX; Fri, 21 Feb 2014 09:13:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3E11A01BF; Fri, 21 Feb 2014 09:13:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140221171303.15533.4406.idtracker@ietfa.amsl.com> Date: Fri, 21 Feb 2014 09:13:03 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/bTN4MP_iduOUpJky_DcXklHjt_o Cc: pcp@ietf.org Subject: [pcp] I-D ACTION:draft-ietf-pcp-nat64-prefix64-06.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:13:05 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : Learning NAT64 PREFIX64s using Port Control Protocol (PCP) Author(s) : M. Boucadair Filename : draft-ietf-pcp-nat64-prefix64 Pages : 17 Date : 2014-02-21 This document defines a new Port Control Protocol (PCP) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This option is needed for successful communications when IPv4 addresses are used in referrals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-nat64-prefix64-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcp-nat64-prefix64"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-02-21091303.I-D@ietf.org> --NextPart-- From nobody Mon Feb 24 13:56:12 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8191A02BF for ; Mon, 24 Feb 2014 13:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ2GghL8Yos7 for ; Mon, 24 Feb 2014 13:56:07 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id EEEC31A030A for ; Mon, 24 Feb 2014 13:56:06 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB596.namprd03.prod.outlook.com (10.255.93.36) with Microsoft SMTP Server (TLS) id 15.0.883.10; Mon, 24 Feb 2014 21:56:04 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Mon, 24 Feb 2014 21:56:04 +0000 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21 Thread-Index: Ac8kdjJMiw3eyGvqT6mQAxskuNkKaQNM833A Date: Mon, 24 Feb 2014 21:56:03 +0000 Message-ID: <22358639d9584ae591dd272472d24993@BY2PR03MB412.namprd03.prod.outlook.com> References: <8242767cd57c4b6c94759273739404b7@BY2PR03MB412.namprd03.prod.outlook.com> In-Reply-To: <8242767cd57c4b6c94759273739404b7@BY2PR03MB412.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::2] x-forefront-prvs: 0132C558ED x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(51704005)(164054003)(479174003)(24454002)(377454003)(243025003)(13464003)(377424004)(74366001)(74316001)(93136001)(76786001)(76796001)(76576001)(74876001)(74706001)(95666003)(15202345003)(81542001)(81342001)(86362001)(94946001)(94316002)(93516002)(92566001)(80022001)(95416001)(86612001)(69226001)(33646001)(85306002)(15975445006)(87936001)(224313003)(224303002)(2656002)(87266001)(80976001)(19580405001)(19580395003)(83322001)(85852003)(81816001)(90146001)(56816005)(81686001)(79102001)(83072002)(47446002)(63696002)(4396001)(54356001)(76482001)(77982001)(59766001)(53806001)(54316002)(56776001)(51856001)(65816001)(46102001)(74502001)(50986001)(47976001)(49866001)(31966008)(74662001)(47736001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB596; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::2; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/1a6m0EO3Lu6C6fJ1fq3-3GsP-UI Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 21:56:10 -0000 My comments are in the marked up copy at http://research.microsoft.com/~dthaler/draft-ietf-pcp-server-selection-02.p= df Much of it is editorial-only. A summary of the top technical feedback is b= elow. 1) Relationship to RFC 6724 is confusing. For a given server should be I) Construct set of *Candidate* Source Addresses based on app input an= d constraints in the PCP base spec (e.g., for a PEER it should just = contain the app session's source address). II) Sort list of destination addresses per RFC 6724 section 6 2) Should provide more guidance about when to use one vs multiple servers. I believe the best answer is that by default, the client needs to use = all PCP servers that configure firewalls (i.e. external IP =3D=3D internal IP = in mapping). When NATs are involved, then it is implementation specific... if the a= pp can deal with multiple IPs then it can use multiple servers that return di= fferent external IPs. -Dave > -----Original Message----- > From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Dave Thaler > Sent: Friday, February 7, 2014 6:35 PM > To: pcp@ietf.org > Subject: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due > by FEB 21 >=20 > This email initiates a two-week Working Group Last Call on > draft-ietf-pcp-server-selection-02 to conclude on Friday, February 21st. > Please send comments to the list. >=20 > As a reminder, when responding to a WGLC, what we chairs are looking for = is > a statement about document quality (not really about whether the > mechanism should move forward). That is, state whether you think the > document is ready as is, or if not, what issues you see. >=20 > Thanks, > -Dave >=20 > > -----Original Message----- > > From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Prashanth Patil > > (praspati) > > Sent: Monday, January 6, 2014 8:52 AM > > To: pcp@ietf.org > > Subject: Re: [pcp] I-D Action: draft-ietf-pcp-server-selection-02.txt > > > > Folks, > > Revised PCP server selection draft has been published. The update > > addresses comments received from Dave Thaler and the ones at IETF 88. > > > > -Prashanth > > > > > > On 1/6/14 10:19 PM, "internet-drafts@ietf.org" > > > > wrote: > > > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > > >directories. > > > This draft is a work item of the Port Control Protocol Working Group > > >of the IETF. > > > > > > Title : PCP Server Selection > > > Authors : Mohamed Boucadair > > > Reinaldo Penno > > > Dan Wing > > > Prashanth Patil > > > Tirumaleswar Reddy > > > Filename : draft-ietf-pcp-server-selection-02.txt > > > Pages : 11 > > > Date : 2014-01-06 > > > > > >Abstract: > > > Multiple IP addresses may be configured on a PCP client in some > > > deployment contexts such as multi-homing. This document specifies > > > the behavior to be followed by the PCP client to contact its PCP > > > server(s) when one or several PCP server IP addresses are configure= d. > > > > > > This document updates RFC6887. > > > > > > > > > > > >The IETF datatracker status page for this draft is: > > >https://datatracker.ietf.org/doc/draft-ietf-pcp-server-selection/ > > > > > >There's also a htmlized version available at: > > >http://tools.ietf.org/html/draft-ietf-pcp-server-selection-02 > > > > > >A diff from the previous version is available at: > > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-02 > > > > > > > > >Please note that it may take a couple of minutes from the time of > > >submission until the htmlized version and diff are available at > > >tools.ietf.org. > > > > > >Internet-Drafts are also available by anonymous FTP at: > > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >_______________________________________________ > > >pcp mailing list > > >pcp@ietf.org > > >https://www.ietf.org/mailman/listinfo/pcp > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From nobody Mon Feb 24 14:13:12 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427811A02C7 for ; Mon, 24 Feb 2014 14:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buIkDwWJoCzy for ; Mon, 24 Feb 2014 14:13:09 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 452FF1A028B for ; Mon, 24 Feb 2014 14:13:09 -0800 (PST) Received: from localhost ([127.0.0.1]:57271 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WI3lk-00082S-Au; Mon, 24 Feb 2014 23:13:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-pcp-server-selection@tools.ietf.org, hassnaa.moustafa@intel.com X-Trac-Project: pcp Date: Mon, 24 Feb 2014 22:13:00 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/66 Message-ID: <064.7b3a3e19faa89c6a5e8c0ab56fb13946@tools.ietf.org> X-Trac-Ticket-ID: 66 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-server-selection@tools.ietf.org, hassnaa.moustafa@intel.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: dwing@cisco.com, mohamed.boucadair@orange.com, praspati@cisco.com, repenno@cisco.com, tireddy@cisco.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/XYk5txXyVsgowNtH8q_IYCAYmjI Cc: pcp@ietf.org Subject: [pcp] #66: server-selection comments from Hassnaa Moustafa X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 22:13:11 -0000 #66: server-selection comments from Hassnaa Moustafa There are few editorial comments on draft (draft-ietf-pcp-server- selection-02) as follows: 1. The term IP address family used in the draft needs more text clarification (to say for example IPv4 or IPv6 or maybe other points that the authors have in mind). 2. The IP addresses used in the diagram (in the example of Section 5) is not very consistent with the IP addresses mentioned in the text that explains the diagram. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-pcp-server- hassnaa.moustafa@intel.com | selection@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: server-selection | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: pcp From nobody Mon Feb 24 14:17:35 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D2B1A02E1 for ; Mon, 24 Feb 2014 14:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o--ZpS4Oyhbt for ; Mon, 24 Feb 2014 14:17:32 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B95951A02D8 for ; Mon, 24 Feb 2014 14:17:31 -0800 (PST) Received: from localhost ([127.0.0.1]:57568 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WI3q2-0002oE-5J; Mon, 24 Feb 2014 23:17:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-pcp-server-selection@tools.ietf.org, simon.perreault@viagenie.ca X-Trac-Project: pcp Date: Mon, 24 Feb 2014 22:17:26 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/67 Message-ID: <065.afb63ecc150bcf708a7b04d61f012f95@tools.ietf.org> X-Trac-Ticket-ID: 67 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-server-selection@tools.ietf.org, simon.perreault@viagenie.ca, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: dwing@cisco.com, mohamed.boucadair@orange.com, praspati@cisco.com, repenno@cisco.com, tireddy@cisco.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/5Cq6uMMMtiXgBV0DVG0Bl4_NfyE Cc: pcp@ietf.org Subject: [pcp] #67: Server selection feedback from Simon Perreault X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 22:17:34 -0000 #67: Server selection feedback from Simon Perreault > 3. IP Address Selection > > These steps specify the behavior to be followed by the PCP client to > contact a PCP server when the PCP client has multiple IP addresses > for a single PCP server. How does the client know that those addresses belong to a single PCP server? Does this work when there are multiple addresses that belong to multiple PCP servers, or does it need to be a single server? Are we assuming that there is always a single PCP server per interface, and therefore all addresses can only belong to a single server by definition? > 1. If the PCP client can use both address families when > communicating to a particular PCP server, the PCP client SHOULD > select the source address of the PCP request to be of the same IP > address family as its requested PCP mapping (i.e., the address > family of the Requested External IP Address). This is wrong. You can't pick a source address based on the requested external address family. You can only pick the address family. For example, you can decide that you're going to use IPv6 to request an IPv6 external address, but that does not help decide which source IPv6 address you're going to use. And this is even more fundamentally wrong. The address family of the PCP request depends on your internal address family, not the suggested external address family. If your server is listening on IPvX, you send your PCP request over IPvX. Otherwise you have to play games with THIRD_PARTY. The external address family has nothing to do with it. In fact, the source address you're going to select has to be one your server is listening on. Otherwise you'll have to play games with THIRD_PARTY. Often servers just listen on the wildcard address, so that does not help you pick one particular address, but if that's not the case then you don't have a choice. Finally, "Requested External IP Address" is not a PCP term. I think you mean "Suggested External IP Address". > 2. Whenever communicating with a PCP server, the rules of Section 6 > of [RFC6724] SHOULD be followed by using the source address > selected in the previous step as input to the destination address > selection algorithm. Step 1 did not yield a particular source address. It yielded an address family. You still need to pick a particular source address. > 3. The PCP client initializes its Maximum Retransmission Count (MRC) > to 4. > > 4. The PCP client sends its PCP message to the PCP server's IP > address following the retransmission procedure specified in > Section 8.1.1 of [RFC6887]. If no response is received after MRC > attempts, the PCP client re-tries the procedure excluding the > destination addresses which did not respond. The PCP client > SHOULD ignore any response received from an IP address after > exhausting MRC attempts for that particular IP address. If, when > sending PCP requests, the PCP client receives a hard ICMP error > [RFC1122] it SHOULD immediately try the next IP address from the > list of PCP server' IP addresses. > > 5. If the PCP client has exhausted all IP addresses configured for a > given PCP server, the procedure is repeated every fifteen minutes > until the PCP request is successfully answered. > > 6. Once the PCP client has successfully received a response from a > PCP server's IP address, it sends subsequent PCP requests to the > same server's IP address until that IP address becomes non- > responsive, which causes the PCP client to follow the steps above > to contact its PCP server. Do we reset the destination address set then? That is, are addresses that failed previously now potentially good again? > 4. Multiple Interfaces > > When an end host has multiple interfaces concurrently active (e.g., > IEEE 802.11 and 3G), a PCP client would discover different PCP > servers over different interfaces. A host may have multiple network > interfaces (e.g, 3G, IEEE 802.11, etc.); each configured differently. > Each PCP server learned MUST be associated with the interface via > which it was learned. Particularly, the PCP client relies on the > source IP address of an outgoing PCP request to select which PCP > server(s) to use. That last sentence would be wrong following my feedback to section 3. {{{ > 5. Example: Multiple PCP servers on a Single Interface > > Figure 1 depicts an example that is used to illustrate the server > selection procedure specified in Section 3. > > ISP Network > | | > ......................................................... > | | Subscriber Network > +-------+------+ +----+---------+ > | PCP-Server-A | | PCP-Server-B | > | | | | > +-------+------+ +----+---------+ > 192.0.2.1 | | 198.51.100.1 > 2001:db8:2222::1 | | 2001:db8:3333::1 > | | > | | > -------+--------------+----------- > | > | 203.0.113.0 > | 2001:db8:1111::1 > +---+---+ > | Host | > +-------+ > > Figure 1 }}} The PCP servers in this figure look like routers. To make things clearer: - Remove the connection from each PCP server to the ISP network. - Draw the "PCP-controlled device". That one would look like a router and would be sitting on the border between the subscriber network and the ISP network. Connect it to both PCP servers and the host. No need for addresses. Is there only one PCP-controlled device, or does each server control its own device? > The PCP client sends two PCP requests at the same time, Really? The algorithm from section 3 does not seem to allow parallel requests. I'm lost. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-pcp-server- simon.perreault@viagenie.ca | selection@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: server-selection | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: pcp From nobody Mon Feb 24 14:19:58 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0A41A02E1 for ; Mon, 24 Feb 2014 14:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW6pC7jmD7Tp for ; Mon, 24 Feb 2014 14:19:56 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F23211A02D8 for ; Mon, 24 Feb 2014 14:19:55 -0800 (PST) Received: from localhost ([127.0.0.1]:57743 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WI3sN-0004gY-Tr; Mon, 24 Feb 2014 23:19:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-pcp-server-selection@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Mon, 24 Feb 2014 22:19:51 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/68 Message-ID: <059.8c54e37692f360ec6114d97c4ee4c134@tools.ietf.org> X-Trac-Ticket-ID: 68 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-server-selection@tools.ietf.org, dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: dwing@cisco.com, mohamed.boucadair@orange.com, praspati@cisco.com, repenno@cisco.com, tireddy@cisco.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/WlXAfcg3MtxF6zt-pMSD7VhNj2Q Cc: pcp@ietf.org Subject: [pcp] #68: Server selection feedback from Dave Thaler X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 22:19:57 -0000 #68: Server selection feedback from Dave Thaler My comments are in the marked up copy at http://research.microsoft.com/~dthaler/draft-ietf-pcp-server- selection-02.pdf Much of it is editorial-only. A summary of the top technical feedback is below. 1) Relationship to RFC 6724 is confusing. For a given server should be I) Construct set of *Candidate* Source Addresses based on app input and constraints in the PCP base spec (e.g., for a PEER it should just contain the app session's source address). II) Sort list of destination addresses per RFC 6724 section 6 2) Should provide more guidance about when to use one vs multiple servers. I believe the best answer is that by default, the client needs to use all PCP servers that configure firewalls (i.e. external IP == internal IP in mapping). When NATs are involved, then it is implementation specific... if the app can deal with multiple IPs then it can use multiple servers that return different external IPs. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-pcp-server- dthaler@microsoft.com | selection@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: server- | Version: 1.0 selection | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: pcp From nobody Mon Feb 24 17:51:37 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120EC1A0235 for ; Mon, 24 Feb 2014 17:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.703 X-Spam-Level: X-Spam-Status: No, score=-100.703 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gaDUFvNMr3N for ; Mon, 24 Feb 2014 17:51:32 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 014891A0393 for ; Mon, 24 Feb 2014 17:51:31 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB596.namprd03.prod.outlook.com (10.255.93.36) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 01:51:23 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 01:51:23 +0000 From: Dave Thaler To: Simon Perreault , "pcp@ietf.org" Thread-Topic: Comments on draft-ietf-pcp-port-set-04.txt Thread-Index: Ac8xy+Mq/8nkmFJKT/e9FgA8BKMzaA== Date: Tue, 25 Feb 2014 01:51:12 +0000 Message-ID: <8c6c79ff7a7a4886bca7e9b5e2ed4bce@BY2PR03MB412.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::2] x-forefront-prvs: 01334458E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(51704005)(24454002)(377424004)(74366001)(74316001)(93136001)(76786001)(76796001)(76576001)(76176001)(74876001)(74706001)(86362001)(81542001)(81342001)(93516002)(94946001)(94316002)(92566001)(80022001)(95416001)(86612001)(69226001)(33646001)(85306002)(87936001)(2656002)(87266001)(81816001)(80976001)(83322001)(85852003)(56816005)(90146001)(81686001)(79102001)(83072002)(47446002)(63696002)(4396001)(54356001)(76482001)(77982001)(59766001)(53806001)(54316002)(56776001)(51856001)(65816001)(46102001)(74502001)(50986001)(47976001)(49866001)(31966008)(74662001)(47736001)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB596; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::2; FPR:EE21D0D5.9AC253D5.F0D2317B.5EE4D141.20692; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/Wuqf3VelAAe59MtjyH4rIsQrkRA Subject: [pcp] Comments on draft-ietf-pcp-port-set-04.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 01:51:35 -0000 Reviewing -04 and comparing it with the thread below... see inline. Simon Perreault wrote: > Thanks a lot for the review! I'll be sure to incorporate your comments in= to a > new revision shortly after the gates reopen. >=20 > Le 2013-10-30 18:33, Dave Thaler a =E9crit : > > 1) The claim that a port set makes code simpler needs an explanation to > justify it. > > E.g., if an app really needs 16 ports, and it fails to get 16 back in > > its first request, it still has to handle that and say make multiple se= parate > requests. >=20 > Two observations: >=20 > - Wouldn't that behaviour be a tiny bit evil? It reminds me of applicatio= ns that > create multiple flows in an attempt to trick an SFQ-based QoS into alloca= ting > them more bandwidth. >=20 > - Often, apps that ask for N ports don't really need N ports. Ideally the= y > would like to get N ports, but they can live with port fallback in that case. >=20 > > So if it already has to have > > code to deal with multiple separate requests, why is it simpler to add > > port set functionality to and implement both? This seems counter-intui= tive > to a reader. >=20 > That would only apply to apps that absolutely need N ports to function, a= nd > don't need them to be contiguous. Those apps need to fall back on single- > port requests as you describe. But I would argue that these apps are real= ly > quite rare. >=20 > We can add text describing these concerns in the next revision. Sure, but the claim in section 2 is that the client side logic *is* simpler= . Not "often" simpler, or "may be simpler". You can=92t assert this when=20 sections 6.4 and 6.3 both leave some major questions up to the=20 implementation. So it might be more complicated not simpler. Suggest=20 just deleting the "Client-side simplicity" bullet. The text added in section 6.4 looks fine to me, except for one editorial suggestion on this text: > Suppose a PCP client asks for 16 ports and receives 8. What should > it do? Should it consider this a final answer? Should it try a > second request, asking for 8 more ports? Should it fall back to 8 > individual MAP requests? This document does not try to answer those > questions , but describes issues to be considered when doing so. Suggest changing last sentence to "This document leaves the answers to be implementation-specific, but describes issues to be considered when answering them." That is, it answers them by saying it's implementation-specific. > > 2) Text on overlapping ranges needs more detail. Is it legal for a > > client to send requests for overlapping ranges in parallel or not? I > > ask because this was an attack vector for IP reassembly so can imagine > > we need the precision here to avoid similar attacks. This might have a= n > impact on the Security Considerations section. >=20 > Hmmm... interesting. I see now that those requests would not be > idempotent, contrary to single-port MAP requests. The first one to be > processed by the server would "win". Responses to each request would > depend on which one has won. >=20 > I don't see an attack here, but the lack of idempotence bugs me. I don't = quite > know what action to take here except describe the situation in the next > revision. Yes, Section 6.3 now looks fine to me, except for a typo: > which port set mapping requests would be arbitrated, Alternatively, Change first comma to period. > > 3) The unstated assumption in section 5.3 seems to be that the client > > can reuse the same mapping nonce in all independent requests that it > wants to refresh as a block, is that right? >=20 > Right. >=20 > > Let's say internal port 100 and 110 both have the same mapping nonce, > > and internal port 105 has a different mapping nonce (e.g., from a diffe= rent > PCP client on the same host). > > If the first PCP client sends a refresh for port 100, Port Set Size =3D > > 11, what would the effect be at the PCP server? >=20 > Assuming the request nonce matches the nonce of the mapping at port 100, > then: >=20 > - The mapping at port 100 would be refreshed. >=20 > - The mapping at port 110 would not be refreshed, but its remaining lifet= ime > would be returned by the server, as described in draft-cheshire-pcp-unsup= p- > family. The response's nonce would be copied from the request's nonce. >=20 > If you agree that this is how it should be, I'll add this to the example = section. > However, that would depend on keeping the normative reference to > unsupp-family (see point 5 below). We agreed to not have a normative reference to unsupp-family, but I don't want this to get lost. Was any change to the port-set document made? Should there be an example in the unsupp-family draft, or what? > > 4) Section 4.1 says if the response does not include a PORT_SET, in a > > response it assumes the server doesn't support it, and sends individual > MAP requests for the rest of the ports it needs. > > But section 4.2 says if the server does support PORT_SET but can only > > return 1 in its first response, It must omit the PORT_SET option. I th= ink > that's wrong since it will confuse the client as noted above. > > If it's included with a Port Set Size of 1, the client knows it can > > keep trying using PORT_SET for subsequent blocks, which might get more > than 1 port in each response. >=20 > Agreed. I'll modify the draft accordingly unless others disagree. I expected the draft to be modified accordingly as I didn't see any disagre= ement on the list or in the meeting notes (let me know if I missed something). However a different change was made to the draft which I think isn't as goo= d. Specifically, per the "Agreed" above, I expected it to say the server will return a port set option with size of 1, and the client then knows the serv= er supports port-sets and can choose to ask for another port-set if it wants. And if the response has no port-set option, then it knows the server doesn'= t support it and can send other requests accordingly. Instead, -04 changed to keep the statement: > If the PCP server ends up mapping only a single port, for any reason, > the PORT_SET option MUST NOT be present in the response. And instead added this text: > If no PORT_SET option is present in the response, the PCP client > cannot conclude that the PCP server does not support the PORT_SET > option. It may just be that the PCP server does support PORT_SET but > decided to allocate only a single port, for reasons that are its own. > If the client wishes to obtain more ports, it MAY send additional MAP > requests (see Section 6.4), I didn't see it explained why this is better than what I thought we agreed to on the list. =20 > > 5) If we want this to go to RFC soon, we need to remove normative > > references to non-RFCs (and this is easy, I suggested text), but I > > think we should also remove informative references to individual > > drafts (i.e., drafts that aren't currently WG drafts in any WG), and in= stead > only reference in the reverse direction; those other drafts should refere= nce > this one instead of the other way around. >=20 > AFAIK, informative references don't prevent publishing as an RFC. So I'll > focus on normative references. >=20 > I'll remove the reference to draft-boucadair-pcp-failure unless others > disagree. >=20 > About draft-cheshire-pcp-unsupp-family: we could remove the reference > and let the document stand on its own. The new example showing the effect > of nonce checking multiple mappings with differing nonces would be added > to draft-cheshire. >=20 > As an aside: the example in section "5.2 Stateless Mapping Discovery" is = not > specific to draft-tsou-stateless-nat44. It is intended to illustrate how > discovery is done generically without the client knowing the kind of stat= eless > NAT it is speaking to. In fact, if the NAT in that example had been one > implementing draft-tsou, the numbers would have been different. > Therefore I suggest keeping the example. I'm fine with that part, thanks. -Dave From nobody Mon Feb 24 18:00:23 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE3C1A02F2 for ; Mon, 24 Feb 2014 18:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8ESo5kl0e-M for ; Mon, 24 Feb 2014 18:00:19 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id D36731A0236 for ; Mon, 24 Feb 2014 18:00:18 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB595.namprd03.prod.outlook.com (10.255.93.35) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 02:00:16 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 02:00:13 +0000 From: Dave Thaler To: "draft-ietf-pcp-port-set@tools.ietf.org" Thread-Topic: IETF 88 notes for draft-ietf-pcp-port-set-04 Thread-Index: Ac8xzUhiSfXY0tZASTK1+6aFvdMunQ== Date: Tue, 25 Feb 2014 02:00:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::2] x-forefront-prvs: 01334458E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(54316002)(76482001)(15975445006)(81686001)(56776001)(85306002)(81816001)(74706001)(74876001)(76796001)(81542001)(80976001)(95416001)(80022001)(54356001)(86362001)(46102001)(53806001)(51856001)(83072002)(85852003)(92566001)(94946001)(56816005)(19580395003)(83322001)(90146001)(74366001)(94316002)(74316001)(76786001)(79102001)(65816001)(2656002)(74662001)(93516002)(87936001)(77982001)(59766001)(4396001)(81342001)(31966008)(76176001)(33646001)(86612001)(93136001)(47976001)(50986001)(49866001)(47736001)(15202345003)(76576001)(69226001)(63696002)(74502001)(87266001)(47446002)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB595; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::2; FPR:7E3AD1D4.8C2065CF.49F2517D.84E91959.201DE; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/4ieTgKUjtpGcv50cBS37L9_5kyI Cc: "pcp@ietf.org" Subject: [pcp] IETF 88 notes for draft-ietf-pcp-port-set-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 02:00:21 -0000 >From the IETF 88 meeting notes (http://www.ietf.org/proceedings/88/minutes/= minutes-88-pcp) [...] > Dave Thaler suggested that if port-set capability is added (or removed), > the PCP server can reset its Epoch to zero, which causes PCP client to=20 > re-try using PORT_SET. New text is needed in the document for those thing= s. > [See also discussion in the Jabber log.] I don't see this in draft -04. [...] > Simon: Possible to get multiple responses to a single request. > Dan: Add to Security Considerations. > Dan: If I'm missing one response out of the set, have to re-send request. > Dave: Need to know nonce, so this can still be an on-path attack. I don't see this in draft -04. [...] > Dan: Server can be upgraded/changed to support/not support PORT_SET. > Is there any harm to always request PORT_SET? > Dave: If I get an indication that the server doesn't currently support > PORT_SET, I'll send multiple requests in parallel. This is related to the issue in the other thread (the follow-up to -03). The text to address that should just keep the above in mind. -Dave From nobody Mon Feb 24 18:34:52 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E45E1A039B for ; Mon, 24 Feb 2014 18:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWuc4RO6BTRF for ; Mon, 24 Feb 2014 18:34:46 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) by ietfa.amsl.com (Postfix) with ESMTP id 864D41A0389 for ; Mon, 24 Feb 2014 18:34:46 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB597.namprd03.prod.outlook.com (10.255.93.37) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 02:34:43 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 02:34:44 +0000 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: 1 week last call on draft-ietf-pcp-dhcp-09 Thread-Index: Ac8x0W0A6P90LzsJSXOKAFBdPQrjcw== Date: Tue, 25 Feb 2014 02:34:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 01334458E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(92566001)(87936001)(95416001)(86612001)(83322001)(19580395003)(56816005)(80976001)(83072002)(85852003)(94946001)(90146001)(93516002)(93136001)(65816001)(94316002)(49866001)(47736001)(47976001)(50986001)(54316002)(56776001)(76482001)(31966008)(81686001)(81816001)(2656002)(74662001)(87266001)(74502001)(47446002)(54356001)(51856001)(53806001)(4396001)(46102001)(85306002)(15975445006)(63696002)(77982001)(59766001)(74876001)(79102001)(74706001)(76176001)(76576001)(76786001)(19300405004)(76796001)(69226001)(81542001)(81342001)(80022001)(86362001)(33646001)(74316001)(16236675002)(74366001)(15202345003)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB597; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:B6CB7EB2.9D1087EB.715D7FEB.84E9DEB9.201B1; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_a97532a3e6964630ab6cb9e92091e5a8BY2PR03MB412namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/7ywJ79LJmHUr1c-0lk2U3mKzfPo Subject: [pcp] 1 week last call on draft-ietf-pcp-dhcp-09 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 02:34:51 -0000 --_000_a97532a3e6964630ab6cb9e92091e5a8BY2PR03MB412namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As we reported in the IETF 88 meeting, the DHCP document previously went through 2 WGLCs, with -08 being the version that was updated to reflect WG consensus and AD feedback. The document shepherd (me) reviewed -08 and agreed that all technical issues had been addressed and found only editorial issues, which resulted in -09 posted shortly before the PCP meeting at IETF 88. Per the meeting notes there were no objections to starting a short WGLC to let anyone else review -09 before submitting to the IESG. Hence this email is a notice that we intend to submit draft-ietf-pcp-dhcp-0= 9 to the IESG for publication as a Proposed Standard in approximately 1 week from today (i.e., before the PCP meeting on the Wednesday of IETF) unless we hear any objections by end of day Monday March 3rd. -Dave --_000_a97532a3e6964630ab6cb9e92091e5a8BY2PR03MB412namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As we reported in the IETF 88 meeting, the DHCP docu= ment previously

went through 2 WGLCs, with -08 being the version tha= t was updated to

reflect WG consensus and AD feedback.  The docu= ment shepherd (me)

reviewed -08 and agreed that all technical issues ha= d been addressed and

found only editorial issues, which resulted in -09 p= osted shortly before

the PCP meeting at IETF 88.  Per the meeting no= tes there were no

objections to starting a short WGLC to let anyone el= se review -09 before

submitting to the IESG.

 

Hence this email is a notice that we intend to submi= t draft-ietf-pcp-dhcp-09

to the IESG for publication as a Proposed Standard i= n approximately

1 week from today (i.e., before the PCP meeting on t= he Wednesday

of IETF) unless we hear any objections by end of day= Monday March 3rd.

 

-Dave

--_000_a97532a3e6964630ab6cb9e92091e5a8BY2PR03MB412namprd03pro_-- From nobody Mon Feb 24 18:42:28 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D281A022A for ; Mon, 24 Feb 2014 18:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1Ou7dTfj1p0 for ; Mon, 24 Feb 2014 18:42:24 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 633451A0221 for ; Mon, 24 Feb 2014 18:42:24 -0800 (PST) Received: from localhost ([127.0.0.1]:40928 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WI7yF-0006XK-HQ; Tue, 25 Feb 2014 03:42:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-pcp-port-set@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 25 Feb 2014 02:42:11 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/69 Message-ID: <059.3374a8816348b43c84919b7b9ca03a7f@tools.ietf.org> X-Trac-Ticket-ID: 69 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-port-set@tools.ietf.org, dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cathy.zhou@huawei.com, mohamed.boucadair@orange.com, simon.perreault@viagenie.ca, ssenthil@cisco.com, sunqiong@ctbri.com.cn, tina.tsou.zouting@huawei.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/alRIpjZmxj-rV28GdECorg_6gWc Cc: pcp@ietf.org Subject: [pcp] #69: Dave Thaler comments on draft-ietf-pcp-port-set-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 02:42:27 -0000 #69: Dave Thaler comments on draft-ietf-pcp-port-set-04 > Le 2013-10-30 18:33, Dave Thaler a écrit : > > 1) The claim that a port set makes code simpler needs an explanation > > to > justify it. > > E.g., if an app really needs 16 ports, and it fails to get 16 back > > in its first request, it still has to handle that and say make > > multiple separate > requests. > > Two observations: > > - Wouldn't that behaviour be a tiny bit evil? It reminds me of > applications that create multiple flows in an attempt to trick an > SFQ-based QoS into allocating them more bandwidth. > > - Often, apps that ask for N ports don't really need N ports. Ideally > they would like to get N ports, but they can live with need for single- port fallback in that case. > > > So if it already has to have > > code to deal with multiple separate requests, why is it simpler to > > add port set functionality to and implement both? This seems > > counter-intuitive > to a reader. > > That would only apply to apps that absolutely need N ports to > function, and don't need them to be contiguous. Those apps need to > fall back on single- port requests as you describe. But I would argue > that these apps are really quite rare. > > We can add text describing these concerns in the next revision. Sure, but the claim in section 2 is that the client side logic *is* simpler. Not "often" simpler, or "may be simpler". You can’t assert this when sections 6.4 and 6.3 both leave some major questions up to the implementation. So it might be more complicated not simpler. Suggest just deleting the "Client-side simplicity" bullet. The text added in section 6.4 looks fine to me, except for one editorial suggestion on this text: > Suppose a PCP client asks for 16 ports and receives 8. What should > it do? Should it consider this a final answer? Should it try a > second request, asking for 8 more ports? Should it fall back to 8 > individual MAP requests? This document does not try to answer those > questions , but describes issues to be considered when doing so. Suggest changing last sentence to "This document leaves the answers to be implementation-specific, but describes issues to be considered when answering them." That is, it answers them by saying it's implementation-specific. [...] Section 6.3 now looks fine to me, except for a typo: > which port set mapping requests would be arbitrated, Alternatively, Change first comma to period. > > 4) Section 4.1 says if the response does not include a PORT_SET, in > > a response it assumes the server doesn't support it, and sends > > individual > MAP requests for the rest of the ports it needs. > > But section 4.2 says if the server does support PORT_SET but can > > only return 1 in its first response, It must omit the PORT_SET > > option. I think > that's wrong since it will confuse the client as noted above. > > If it's included with a Port Set Size of 1, the client knows it can > > keep trying using PORT_SET for subsequent blocks, which might get > > more > than 1 port in each response. > > Agreed. I'll modify the draft accordingly unless others disagree. I expected the draft to be modified accordingly as I didn't see any disagreement on the list or in the meeting notes (let me know if I missed something). However a different change was made to the draft which I think isn't as good. Specifically, per the "Agreed" above, I expected it to say the server will return a port set option with size of 1, and the client then knows the server supports port-sets and can choose to ask for another port-set if it wants. And if the response has no port-set option, then it knows the server doesn't support it and can send other requests accordingly. Instead, -04 changed to keep the statement: > If the PCP server ends up mapping only a single port, for any reason, > the PORT_SET option MUST NOT be present in the response. And instead added this text: > If no PORT_SET option is present in the response, the PCP client > cannot conclude that the PCP server does not support the PORT_SET > option. It may just be that the PCP server does support PORT_SET but > decided to allocate only a single port, for reasons that are its own. > If the client wishes to obtain more ports, it MAY send additional MAP > requests (see Section 6.4), I didn't see it explained why this is better than what I thought we agreed to on the list. Also related to the above is the following from IETF 88 meeting minutes: > Dan: Server can be upgraded/changed to support/not support PORT_SET. > Is there any harm to always request PORT_SET? > Dave: If I get an indication that the server doesn't currently support > PORT_SET, I'll send multiple requests in parallel. Just keep the above in mind when addressing the earlier issue. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-pcp-port- dthaler@microsoft.com | set@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: port-set | Version: 1.0 Severity: Active WG | Keywords: Document | -------------------------+------------------------------------------------- Ticket URL: pcp From nobody Mon Feb 24 18:43:17 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4941A0221 for ; Mon, 24 Feb 2014 18:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEH5YnX0M1og for ; Mon, 24 Feb 2014 18:43:14 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 789B31A022A for ; Mon, 24 Feb 2014 18:43:14 -0800 (PST) Received: from localhost ([127.0.0.1]:40948 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WI7z8-0001mu-4S; Tue, 25 Feb 2014 03:43:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-pcp-port-set@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 25 Feb 2014 02:43:06 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/70 Message-ID: <059.9c890c190a530694044ddc4e563b8d72@tools.ietf.org> X-Trac-Ticket-ID: 70 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-port-set@tools.ietf.org, dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cathy.zhou@huawei.com, mohamed.boucadair@orange.com, simon.perreault@viagenie.ca, ssenthil@cisco.com, sunqiong@ctbri.com.cn, tina.tsou.zouting@huawei.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/wDpKTZH7dyNR6nfgyfdomxuuWBY Cc: pcp@ietf.org Subject: [pcp] #70: IETF 88 meeting feedback on draft-ietf-pcp-port-set-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 02:43:16 -0000 #70: IETF 88 meeting feedback on draft-ietf-pcp-port-set-04 From the IETF 88 meeting notes (http://www.ietf.org/proceedings/88/minutes/minutes-88-pcp) [...] > Dave Thaler suggested that if port-set capability is added (or > removed), the PCP server can reset its Epoch to zero, which causes PCP > client to re-try using PORT_SET. New text is needed in the document for those things. > [See also discussion in the Jabber log.] I don't see this in draft -04. [...] > Simon: Possible to get multiple responses to a single request. > Dan: Add to Security Considerations. > Dan: If I'm missing one response out of the set, have to re-send request. > Dave: Need to know nonce, so this can still be an on-path attack. I don't see this in draft -04. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-pcp-port- dthaler@microsoft.com | set@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: port-set | Version: 1.0 Severity: Active WG | Keywords: Document | -------------------------+------------------------------------------------- Ticket URL: pcp From nobody Mon Feb 24 18:50:22 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED071A025D for ; Mon, 24 Feb 2014 18:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6upE3lS4F4Nm for ; Mon, 24 Feb 2014 18:50:18 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F21161A024C for ; Mon, 24 Feb 2014 18:50:17 -0800 (PST) Received: from localhost ([127.0.0.1]:41228 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WI862-0002Yf-C2; Tue, 25 Feb 2014 03:50:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: dwing@cisco.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 25 Feb 2014 02:50:14 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/26#comment:2 Message-ID: <106.547968bb11cef77fd6e80e0207e20c7f@tools.ietf.org> References: <091.f83f0cafe2719b6da7df8493705ab75f@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <091.f83f0cafe2719b6da7df8493705ab75f@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dwing@cisco.com, dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/Yjd-B2MFbycCFqdxwYFHXIe4Ais Cc: pcp@ietf.org Subject: Re: [pcp] #26: Firewall detection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 02:50:19 -0000 #26: Firewall detection Changes (by dthaler@microsoft.com): * component: PCP server discovery => Extensions -- -------------------------------------------------+------------------------- Reporter: mohamed.boucadair@orange- | Owner: ftgroup.com; dwing@cisco.com | Status: new Type: enhancement | Milestone: Priority: major | Version: Component: Extensions | Resolution: Severity: Active WG Document | Keywords: | -------------------------------------------------+------------------------- Ticket URL: pcp From nobody Mon Feb 24 18:53:17 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79241A025E for ; Mon, 24 Feb 2014 18:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jH14nG4ChOvj for ; Mon, 24 Feb 2014 18:53:14 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3456D1A025D for ; Mon, 24 Feb 2014 18:53:14 -0800 (PST) Received: from localhost ([127.0.0.1]:41891 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WI88l-0003DZ-2X; Tue, 25 Feb 2014 03:53:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com, cheshire@apple.com X-Trac-Project: pcp Date: Tue, 25 Feb 2014 02:53:02 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/49#comment:7 Message-ID: <074.0665c2dd32c6f8eb09aeda462f9408fe@tools.ietf.org> References: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com, cheshire@apple.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: cheshire@apple.com, dwing@cisco.com, mohamed.boucadair@orange.com, pselkirk@isc.org, repenno@cisco.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/5lasA8cX0IznNgNHBxKprTmQmiE Cc: pcp@ietf.org Subject: Re: [pcp] #49: Multihoming confusion X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 02:53:16 -0000 #49: Multihoming confusion Changes (by dthaler@microsoft.com): * component: base => server-selection -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-pcp-base@tools.ietf.org dthaler@microsoft.com | Status: reopened Type: defect | Milestone: Priority: major | Version: Component: server- | Resolution: selection | Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: pcp From nobody Mon Feb 24 18:53:37 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647401A024C for ; Mon, 24 Feb 2014 18:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS_UTJUdjWI2 for ; Mon, 24 Feb 2014 18:53:35 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 198281A03BE for ; Mon, 24 Feb 2014 18:53:35 -0800 (PST) Received: from localhost ([127.0.0.1]:41919 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WI89C-0003Pe-5i; Tue, 25 Feb 2014 03:53:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: dwing@cisco.com, dthaler@microsoft.com, tena@huawei.com X-Trac-Project: pcp Date: Tue, 25 Feb 2014 02:53:30 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/13#comment:5 Message-ID: <068.e1892b18ac74380890c8391664064e3b@tools.ietf.org> References: <053.a0bcfe3bfc790d5de6e2861c6c3677b6@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <053.a0bcfe3bfc790d5de6e2861c6c3677b6@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dwing@cisco.com, dthaler@microsoft.com, tena@huawei.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/n1SfR18PxeM1G1zB4tp1kAaCH68 Cc: pcp@ietf.org Subject: Re: [pcp] #13: DS-lite interaction X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 02:53:36 -0000 #13: DS-lite interaction Changes (by dthaler@microsoft.com): * component: base => dslite -- --------------------------------+------------------ Reporter: dwing@cisco.com | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: dslite | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------ Ticket URL: pcp From nobody Mon Feb 24 18:59:21 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69C21A03D6 for ; Mon, 24 Feb 2014 18:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-RXoe2AuQJv for ; Mon, 24 Feb 2014 18:59:16 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5091A03E9 for ; Mon, 24 Feb 2014 18:59:12 -0800 (PST) Received: from localhost ([127.0.0.1]:42456 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WI8Ee-0002Dy-4C; Tue, 25 Feb 2014 03:59:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: dwing@cisco.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 25 Feb 2014 02:59:07 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/34#comment:4 Message-ID: <089.dbc3f8a58b54e680653d724bd0c3c76d@tools.ietf.org> References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dwing@cisco.com, dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/S2CeUCO0ZG1WZmdbnnuvmY6NX4E Cc: pcp@ietf.org Subject: Re: [pcp] #34: notify NAT WAN address changed X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 02:59:18 -0000 #34: notify NAT WAN address changed Changes (by dthaler@microsoft.com): * status: new => closed * resolution: => fixed Comment: This was addressed in RFC 6887. Section 14.2 begins: > 14.2. PCP Mapping Update > > This rapid recovery mechanism is used when the PCP server remembers > its state and determines its existing mappings are invalid (e.g., IP > renumbering changes the external IP address of a PCP-controlled NAT). -- --------------------------------------------------+--------------------- Reporter: mohamed.boucadair@orange-ftgroup.com | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: Extensions | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------------------------+--------------------- Ticket URL: pcp From nobody Mon Feb 24 19:01:09 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235F31A03CC for ; Mon, 24 Feb 2014 19:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75MMxD6MgMxz for ; Mon, 24 Feb 2014 19:01:05 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 86F6E1A02E3 for ; Mon, 24 Feb 2014 19:01:05 -0800 (PST) Received: from localhost ([127.0.0.1]:42535 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WI8GV-0002kD-9n; Tue, 25 Feb 2014 04:01:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 25 Feb 2014 03:01:03 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/36#comment:1 Message-ID: <068.3e310a7a0983b1338abd375c9e6f856c@tools.ietf.org> References: <053.58320c0d7e5437ce095c55c69e6bd448@tools.ietf.org> X-Trac-Ticket-ID: 36 In-Reply-To: <053.58320c0d7e5437ce095c55c69e6bd448@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/gSxYdy4kpccEGUYU3WUy7WUefZc Cc: pcp@ietf.org Subject: Re: [pcp] #36: error on renewal for interworking function X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 03:01:07 -0000 #36: error on renewal for interworking function Changes (by dthaler@microsoft.com): * status: new => closed * resolution: => fixed * component: UPnP interop => upnp-igd-interworking Comment: This was addressed in RFC 6970 section 5.9. -- -----------------------------------+--------------------- Reporter: dwing@cisco.com | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: upnp-igd-interworking | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------------+--------------------- Ticket URL: pcp From nobody Mon Feb 24 19:03:16 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CC01A03E2 for ; Mon, 24 Feb 2014 19:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F90GC9PfPr1E for ; Mon, 24 Feb 2014 19:03:13 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 17C851A03CC for ; Mon, 24 Feb 2014 19:03:13 -0800 (PST) Received: from localhost ([127.0.0.1]:42595 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WI8IX-00034f-CP; Tue, 25 Feb 2014 04:03:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 25 Feb 2014 03:03:09 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/30#comment:3 Message-ID: <089.ca62926dc2989897b7ec47723d728cf0@tools.ietf.org> References: <074.7aee1ae9c8079cffdef45063f8ecdbfb@tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <074.7aee1ae9c8079cffdef45063f8ecdbfb@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/SD6Pzdm10pAloZoHeuJAUdqKHZk Cc: pcp@ietf.org Subject: Re: [pcp] #30: GetExternalIP capability? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 03:03:14 -0000 #30: GetExternalIP capability? Changes (by dthaler@microsoft.com): * status: new => closed * resolution: => fixed * component: UPnP interop => upnp-igd-interworking * severity: Active WG Document => Submitted WG Document Comment: GetExternalIPAddress() support was addressed in RFC 6970 section 4.2. -- --------------------------------------------------+--------------------- Reporter: mohamed.boucadair@orange-ftgroup.com | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: upnp-igd-interworking | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | --------------------------------------------------+--------------------- Ticket URL: pcp From nobody Mon Feb 24 19:07:48 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB8F1A03E0 for ; Mon, 24 Feb 2014 19:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmvpaOtbqB71 for ; Mon, 24 Feb 2014 19:07:43 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CDA4A1A03CC for ; Mon, 24 Feb 2014 19:07:42 -0800 (PST) Received: from localhost ([127.0.0.1]:42737 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WI8M6-0004QT-0h; Tue, 25 Feb 2014 04:06:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: tena@huawei.com, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 25 Feb 2014 03:06:48 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/16#comment:4 Message-ID: <074.f1740c3eea6f2d6c12bb754369f307d5@tools.ietf.org> References: <059.b8e7df1bdcf8430f3c4de0aadc733008@tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <059.b8e7df1bdcf8430f3c4de0aadc733008@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tena@huawei.com, cheshire@apple.com, dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/EkE1aJcx2_OcmFbI_u6eCEvJPvQ Cc: pcp@ietf.org Subject: Re: [pcp] #16: PCP lifetime expiration with active traffic X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 03:07:46 -0000 #16: PCP lifetime expiration with active traffic Changes (by dthaler@microsoft.com): * status: new => closed * resolution: => fixed Comment: WG consensus is what was put in RFC 6887 section 15: > In particular, it is implementation-dependent if outgoing traffic > extends the lifetime of such mappings beyond the PCP-assigned > lifetime. PCP clients MUST NOT depend on this behavior to keep > mappings active, and MUST explicitly renew their mappings as required > by the Lifetime field in PCP response messages. -- -----------------------------------+--------------------- Reporter: dthaler@microsoft.com | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+--------------------- Ticket URL: pcp From nobody Tue Feb 25 03:52:46 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4A81A06B8 for ; Tue, 25 Feb 2014 03:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiKF7Omg-H-0 for ; Tue, 25 Feb 2014 03:52:42 -0800 (PST) Received: from mail.bodgit-n-scarper.com (simulant.bodgit-n-scarper.com [IPv6:2600:3c03::f03c:91ff:fe96:1bcb]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5E21A06B6 for ; Tue, 25 Feb 2014 03:52:42 -0800 (PST) Received: by mail.bodgit-n-scarper.com (Postfix, from userid 2000) id 552C37F15; Tue, 25 Feb 2014 06:53:13 -0500 (EST) Date: Tue, 25 Feb 2014 06:53:13 -0500 From: Matt Dainty To: pcp@ietf.org Message-ID: <20140225115313.GS2245@simulant.bodgit-n-scarper.com> References: <20140221171034.15533.45654.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140221171034.15533.45654.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.2.2i X-Operating-System: Linux 2.6.18-348.3.1.el5xen on x86_64 SMP (simulant.bodgit-n-scarper.com) Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/VOMqSQ0i9j_ErclRFpxDU4lyj98 Subject: Re: [pcp] I-D ACTION:draft-ietf-pcp-description-option-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 11:52:44 -0000 Section 3 of this draft seems to hint at different forms of option processing compared to what is defined in RFC 6887. If the PCP client includes the DESCRIPTION option and marks it as mandatory the PCP server should return UNSUPP_OPTION if it does not support it, rather than ignore it. In fact, if it truly doesn't understand this option, that's what it will do anyway; you would have to teach the server about this option to then make it ignore it. RFC 6887 defines the method of marking options as optional so clients should use that if they don't want the option to potentially trigger an error response from the server. If the PCP client includes malformed UTF-8 content then the PCP server should return MALFORMED_OPTION as per the standard option processing rather than just ignore the option/request. Matt * Internet-Drafts@ietf.org [2014-02-21 12:10:39]: > A new Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Port Control Protocol Working Group of the IETF. > > Title : PCP Description Option > Author(s) : M. Boucadair, et al > Filename : draft-ietf-pcp-description-option > Pages : 6 > Date : 2014-02-21 > > This document extends Port Control Protocol (PCP) with the ability to > associate a description with a PCP-instantiated mapping. It does so > by defining a new DESCRIPTION option. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pcp-description-option-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From nobody Tue Feb 25 04:33:22 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68EC1A06D0 for ; Tue, 25 Feb 2014 04:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6Bov2Ypb2GH for ; Tue, 25 Feb 2014 04:33:18 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0F01A06C2 for ; Tue, 25 Feb 2014 04:33:18 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 36FFD18C338; Tue, 25 Feb 2014 13:33:17 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1D4D427C0CE; Tue, 25 Feb 2014 13:33:17 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 25 Feb 2014 13:33:17 +0100 From: To: Matt Dainty , "pcp@ietf.org" Date: Tue, 25 Feb 2014 13:33:12 +0100 Thread-Topic: [pcp] I-D ACTION:draft-ietf-pcp-description-option-05.txt Thread-Index: Ac8yIBr+P+7Pj9xvQze4K/GIWOilTgAAyRHA Message-ID: <94C682931C08B048B7A8645303FDC9F36F4E4D7909@PUEXCB1B.nanterre.francetelecom.fr> References: <20140221171034.15533.45654.idtracker@ietfa.amsl.com> <20140225115313.GS2245@simulant.bodgit-n-scarper.com> In-Reply-To: <20140225115313.GS2245@simulant.bodgit-n-scarper.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/YEwtllicI2fxeL1hMY7-dFsj1XA Subject: Re: [pcp] I-D ACTION:draft-ietf-pcp-description-option-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 12:33:20 -0000 Dear Matt, This option is defined in the optional to process range (see IANA section).= =20 The draft follows the behavior in RFC6887, particularly this part: If the overall option structure of a request is valid, then how each individual option is handled is determined by the most significant bit in the option code. If the most significant bit is set, handling this option is optional, and a PCP server MAY process or ignore this option, entirely at its discretion. If the most significant bit is clear, handling this option is mandatory, and a PCP server MUST return the error MALFORMED_OPTION if the option contents are malformed, or UNSUPP_OPTION if the option is unrecognized, unimplemented, or disabled, or if the client is not authorized to use the option. In error responses, all options are returned. In success responses, all processed options are included and unprocessed options are not included. Cheers, Med >-----Message d'origine----- >De=A0: pcp [mailto:pcp-bounces@ietf.org] De la part de Matt Dainty >Envoy=E9=A0: mardi 25 f=E9vrier 2014 12:53 >=C0=A0: pcp@ietf.org >Objet=A0: Re: [pcp] I-D ACTION:draft-ietf-pcp-description-option-05.txt > >Section 3 of this draft seems to hint at different forms of option >processing compared to what is defined in RFC 6887. > >If the PCP client includes the DESCRIPTION option and marks it as >mandatory the PCP server should return UNSUPP_OPTION if it does not >support it, rather than ignore it. In fact, if it truly doesn't >understand this option, that's what it will do anyway; you would have >to teach the server about this option to then make it ignore it. RFC >6887 defines the method of marking options as optional so clients >should use that if they don't want the option to potentially trigger an >error response from the server. > >If the PCP client includes malformed UTF-8 content then the PCP server >should return MALFORMED_OPTION as per the standard option processing >rather than just ignore the option/request. > >Matt > >* Internet-Drafts@ietf.org [2014-02-21 >12:10:39]: >> A new Internet-Draft is available from the on-line Internet-Drafts >directories. >> This draft is a work item of the Port Control Protocol Working Group of >the IETF. >> >> Title : PCP Description Option >> Author(s) : M. Boucadair, et al >> Filename : draft-ietf-pcp-description-option >> Pages : 6 >> Date : 2014-02-21 >> >> This document extends Port Control Protocol (PCP) with the ability to >> associate a description with a PCP-instantiated mapping. It does so >> by defining a new DESCRIPTION option. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-pcp-description-option- >05.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > > >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From nobody Tue Feb 25 06:50:52 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697DD1A0476 for ; Tue, 25 Feb 2014 06:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F491DorC53C3 for ; Tue, 25 Feb 2014 06:50:47 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 66FC91A00B2 for ; Tue, 25 Feb 2014 06:50:47 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6BE23403F7 for ; Tue, 25 Feb 2014 09:50:46 -0500 (EST) Message-ID: <530CADC6.104@viagenie.ca> Date: Tue, 25 Feb 2014 09:50:46 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: pcp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/j53WtT2ArHRHUHF4bKi36DdqQKg Subject: Re: [pcp] IETF 88 notes for draft-ietf-pcp-port-set-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 14:50:49 -0000 You're right. I wonder how I missed those. I'll bake a new revision. Simon Le 2014-02-24 21:00, Dave Thaler a écrit : >>From the IETF 88 meeting notes (http://www.ietf.org/proceedings/88/minutes/minutes-88-pcp) > > [...] >> Dave Thaler suggested that if port-set capability is added (or removed), >> the PCP server can reset its Epoch to zero, which causes PCP client to >> re-try using PORT_SET. New text is needed in the document for those things. >> [See also discussion in the Jabber log.] > > I don't see this in draft -04. > > [...] >> Simon: Possible to get multiple responses to a single request. >> Dan: Add to Security Considerations. >> Dan: If I'm missing one response out of the set, have to re-send request. >> Dave: Need to know nonce, so this can still be an on-path attack. > > I don't see this in draft -04. > > [...] >> Dan: Server can be upgraded/changed to support/not support PORT_SET. >> Is there any harm to always request PORT_SET? >> Dave: If I get an indication that the server doesn't currently support >> PORT_SET, I'll send multiple requests in parallel. > > This is related to the issue in the other thread (the follow-up to -03). > The text to address that should just keep the above in mind. > > -Dave > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Feb 25 19:08:42 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38651A0845 for ; Tue, 25 Feb 2014 19:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrTsRUa6rKR5 for ; Tue, 25 Feb 2014 19:08:39 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 115491A03B1 for ; Tue, 25 Feb 2014 19:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4991; q=dns/txt; s=iport; t=1393384117; x=1394593717; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=BEJpyMCcWlVz8QJMTrTB5gxXnCdJeFj7genoKMCVdRs=; b=RikVVvM7ywSwXRtK1BUH38Ufis3SatiRJXfb/H1eSASCfnmfintxhikj quqTMLKlAwxH3je95ZjJIRI38M//d7m02WsBF6NifywnbHJj2ImyMS+k2 pvMz5okfHkigL5I71kafcoTkJg1c1sOyFnT8xRZH7cxkxqF+b5cCj6o/L 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAB9aDVOtJXHA/2dsb2JhbABYgwY7V8EDgRcWdIIlAQEBBCdeBgEIEQQBAQsdORQJCQEEARIIh30NyFAXjW0yCzODHoEUBIkRkFeQdoMtgio X-IronPort-AV: E=Sophos;i="4.97,544,1389744000"; d="scan'208";a="306526055" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 26 Feb 2014 03:08:36 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q38asO019697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 03:08:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 21:08:36 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , "Prashanth Patil (praspati)" , "pcp@ietf.org" Thread-Topic: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21 Thread-Index: Ac8yoAclbfYgfWYkTaiF3WBTb2QENQ== Date: Wed, 26 Feb 2014 03:08:36 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242C5B0B@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.77.126] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/5Kmnm8abn8ZUvtX0rgYYNDlUdyc Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 03:08:41 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Tuesday, February 18, 2014 7:58 PM > To: Prashanth Patil (praspati); pcp@ietf.org > Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments = due > by FEB 21 >=20 > Le 2014-02-18 09:20, Prashanth Patil (praspati) a =E9crit : > >> How does the client know that those addresses belong to a single PCP > >> server? > > > > A PCP client, via DHCP for example, can learn a list of IP addresses > > for the same PCP server and a list of unique PCP servers. > > https://tools.ietf.org/html/draft-ietf-pcp-dhcp-09#page-5 > > > > > >> > >> Does this work when there are multiple addresses that belong to > >> multiple PCP servers, or does it need to be a single server? > > > > It works in both cases. > > > > The draft first describes how a PCP client goes about contacting a PCP > > server that has multiple addresses. The same steps are to be followed > > for each unique PCP server learnt (each of which may again have > > multiple addresses). > > > > From the draft: > > "If several PCP servers are configured, each with multiple IP > > addresses, the PCP client contacts all PCP servers in parallel > > following the steps described above." >=20 > Good. That makes sense. >=20 > >>> 6. Once the PCP client has successfully received a response from = a > >>> PCP server's IP address, it sends subsequent PCP requests to t= he > >>> same server's IP address until that IP address becomes non- > >>> responsive, which causes the PCP client to follow the steps ab= ove > >>> to contact its PCP server. > >> > >> Do we reset the destination address set then? That is, are addresses > >> that failed previously now potentially good again? > > > > Yes, the client has to attempt contacting the servers again. >=20 > Ok. It would be nice to mention it explicitly. >=20 > >>> 5. Example: Multiple PCP servers on a Single Interface > >>> > >>> Figure 1 depicts an example that is used to illustrate the server > >>> selection procedure specified in Section 3. > >>> > >>> ISP Network > >>> | | > >>> ......................................................... > >>> | | Subscriber Netwo= rk > >>> +-------+------+ +----+---------+ > >>> | PCP-Server-A | | PCP-Server-B | > >>> | | | | > >>> +-------+------+ +----+---------+ > >>> 192.0.2.1 | | 198.51.100.1 > >>> 2001:db8:2222::1 | | 2001:db8:3333::1 > >>> | | > >>> | | > >>> -------+--------------+----------- > >>> | > >>> | 203.0.113.0 > >>> | 2001:db8:1111::1 > >>> +---+---+ > >>> | Host | > >>> +-------+ > >>> > >>> Figure 1 > >> > >> The PCP servers in this figure look like routers. To make things clear= er: > >> > >> - Remove the connection from each PCP server to the ISP network. > >> > >> - Draw the "PCP-controlled device". That one would look like a router > >> and would be sitting on the border between the subscriber network and > >> the ISP network. Connect it to both PCP servers and the host. No need > >> for addresses. > >> > >> Is there only one PCP-controlled device, or does each server control > >> its own device? > > > > Each server controls its own device. With this clarification, do you > > still think the figure needs to be updated? >=20 > Yes. Can you please provide more details why this figure needs to be updated ? -Tiru >=20 > >>> The PCP client sends two PCP requests at the same time, > >> > >> Really? The algorithm from section 3 does not seem to allow parallel > >> requests. I'm lost. > > > > It does, as described in an earlier comment and the last paragraph of > > http://tools.ietf.org/html/draft-ietf-pcp-server-selection-02#section-3= . > > There are two potential scenarios. A single server having multiple > > addresses AND multiple PCP servers itself. The draft tries to address > > both scenarios. If this is unclear, we'll have to see how to > > re-organize to make it more obvious. >=20 > I think that would be necessary. >=20 > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 From nobody Wed Feb 26 01:11:35 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AC41A002F for ; Wed, 26 Feb 2014 01:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU01jPKL1JtN for ; Wed, 26 Feb 2014 01:11:22 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1861A016A for ; Wed, 26 Feb 2014 01:11:22 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 7840D324063; Wed, 26 Feb 2014 10:11:20 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4D71927C0B6; Wed, 26 Feb 2014 10:11:20 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 26 Feb 2014 10:11:20 +0100 From: To: pcp issue tracker , "dwing@cisco.com" , "dthaler@microsoft.com" Date: Wed, 26 Feb 2014 10:11:18 +0100 Thread-Topic: [pcp] #34: notify NAT WAN address changed Thread-Index: Ac8x1ZsNomlq7CMaTFqv1wt/Mk7JagA+28DA Message-ID: <94C682931C08B048B7A8645303FDC9F36F4F905D0F@PUEXCB1B.nanterre.francetelecom.fr> References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> <089.dbc3f8a58b54e680653d724bd0c3c76d@tools.ietf.org> In-Reply-To: <089.dbc3f8a58b54e680653d724bd0c3c76d@tools.ietf.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.25.93015 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/X0zcgewJdMV12XtQtuEzPjt6Q1g Cc: "pcp@ietf.org" Subject: Re: [pcp] #34: notify NAT WAN address changed X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 09:11:29 -0000 Hi Dave, all, I agree most of the issues captured in this ticket are solved, but still th= ere is one remaining issue.=20 As a reminder, the ticket refers to this text: =3D=3D=3D=3D=3D=3D 2.5. Change of the CPE WAN IP Address The change of the IP address of the WAN interface of the CPE would have an impact on the accuracy of the mappings instantiated in the PCP Server: o For the DS-Lite case [I-D.ietf-softwire-dual-stack-lite]: if a new IPv6 address is used by the B4 element when encapsulating IPv4 packets in IPv6 ones, the mappings SHOULD be refreshed: If the PCP Client is embedded in the B4, the refresh operation is triggered by the change of the B4 IPv6 address. This would be more complicated when the PCP Client is located in a device behind the B4. [Ed. Note: how an IPv4 host behind a DS-Lite CPE is aware that a new IPv6 address is used by the B4?] o For the NAT64 case [I-D.ietf-behave-v6v4-xlate-stateful], any change of the assigned IPv6 prefix delegated to the CPE will be detected by the PCP Client (because this leads to the allocation of a new IPv6 address). The PCP Client has to undertake the operation described in Section 2.4. =3D=3D=3D=3D=3D=3D=3D=3D An issue is still unsolved in the DS-Lite case where the PCP client is not = co-located with B4. This issue is not solved in the base PCP spec, but is a= ddressed in this individual draft: http://tools.ietf.org/search/draft-vinap= amula-softwire-dslite-prefix-binding-01=20 The recommendation in http://tools.ietf.org/search/draft-vinapamula-softwir= e-dslite-prefix-binding-01 covers the PCP case, in particular these two rec= ommendations: 3. In the event a new IPv6 address is assigned to B4, the AFTR SHOULD migrate existing state to be bound to the new B4's IP address. This ensures the traffic destined to the previous IPv6 address will redirected to the new IPv6 address. The destination address for tunneling return traffic SHOULD be the last seen address from the CPE. The source address of the tunnel would remain same as AFTR. 4. In the event of change of the CPE WAN IPv6 prefix, unsolicited PCP ANNOUNCE messages SHOULD be sent by the B4 element to internal hosts to update their mappings. Cheers, Med >-----Message d'origine----- >De=A0: pcp [mailto:pcp-bounces@ietf.org] De la part de pcp issue tracker >Envoy=E9=A0: mardi 25 f=E9vrier 2014 03:59 >=C0=A0: dwing@cisco.com; dthaler@microsoft.com >Cc=A0: pcp@ietf.org >Objet=A0: Re: [pcp] #34: notify NAT WAN address changed > >#34: notify NAT WAN address changed > >Changes (by dthaler@microsoft.com): > > * status: new =3D> closed > * resolution: =3D> fixed > > >Comment: > > This was addressed in RFC 6887. Section 14.2 begins: > > 14.2. PCP Mapping Update > > > > This rapid recovery mechanism is used when the PCP server remembers > > its state and determines its existing mappings are invalid (e.g., IP > > renumbering changes the external IP address of a PCP-controlled NAT). > >-- >--------------------------------------------------+--------------------- > Reporter: mohamed.boucadair@orange-ftgroup.com | Owner: > Type: enhancement | Status: closed > Priority: minor | Milestone: >Component: Extensions | Version: > Severity: - | Resolution: fixed > Keywords: | >--------------------------------------------------+--------------------- > >Ticket URL: >pcp > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From nobody Wed Feb 26 05:20:23 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7491A02E4 for ; Wed, 26 Feb 2014 05:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTqE6hRhCfgR for ; Wed, 26 Feb 2014 05:20:13 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 200B41A007F for ; Wed, 26 Feb 2014 05:20:13 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C561246907; Wed, 26 Feb 2014 08:20:11 -0500 (EST) Message-ID: <530DEA0B.9010800@viagenie.ca> Date: Wed, 26 Feb 2014 08:20:11 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "Prashanth Patil (praspati)" , "pcp@ietf.org" References: <913383AAA69FF945B8F946018B75898A242C5B0B@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242C5B0B@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/zUGPNuoU4Yb9EiKS_XdmOOkZ5_E Subject: Re: [pcp] WGLC: draft-ietf-pcp-server-selection-02.txt comments due by FEB 21 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 13:20:20 -0000 Le 2014-02-25 22:08, Tirumaleswar Reddy (tireddy) a écrit : >>>>> 5. Example: Multiple PCP servers on a Single Interface >>>>> >>>>> Figure 1 depicts an example that is used to illustrate the server >>>>> selection procedure specified in Section 3. >>>>> >>>>> ISP Network >>>>> | | >>>>> ......................................................... >>>>> | | Subscriber Network >>>>> +-------+------+ +----+---------+ >>>>> | PCP-Server-A | | PCP-Server-B | >>>>> | | | | >>>>> +-------+------+ +----+---------+ >>>>> 192.0.2.1 | | 198.51.100.1 >>>>> 2001:db8:2222::1 | | 2001:db8:3333::1 >>>>> | | >>>>> | | >>>>> -------+--------------+----------- >>>>> | >>>>> | 203.0.113.0 >>>>> | 2001:db8:1111::1 >>>>> +---+---+ >>>>> | Host | >>>>> +-------+ >>>>> >>>>> Figure 1 > > Can you please provide more details why this figure needs to be updated ? Because: 1. The PCP servers look like routers. They should not be connected at the top. 2. The PCP-controlled device(s) is/are not shown. We don't know whether there are two PCP servers controlling a single device or two PCP servers each controlling its own device. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Feb 26 10:44:03 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0391A0802; Wed, 26 Feb 2014 10:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtF6ttXbERki; Wed, 26 Feb 2014 10:43:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 190A41A0732; Wed, 26 Feb 2014 10:43:47 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140226184347.14989.14128.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2014 10:43:47 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/voueZ1llu4KQCskkLXBFV36PQZU Cc: pcp mailing list , pcp chair , RFC Editor Subject: [pcp] Protocol Action: 'PCP Description Option' to Proposed Standard (draft-ietf-pcp-description-option-05.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 18:43:58 -0000 The IESG has approved the following document: - 'PCP Description Option' (draft-ietf-pcp-description-option-05.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcp-description-option/ Technical Summary This document extends Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does so by defining a new DESCRIPTION option. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Nothing controversial. Document Quality It is expected that any implementation of RFC 6970 (PCP/UPnP-IGD interop) would want this extension. One known implementation is reported in http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-2.1. Other than the document editor, the following people reviewed the document during WGLC and all concluded the document had no substantive issues: 1) Dave Thaler (document shepherd, WG co-chair) 2) Tiru Reddy 3) Simon Perreault 4) Paul Selkirk 5) Reinaldo Penno (WG co-chair, co-author) Personnel Document Shepherd: Dave Thaler Responsible Area Director: Ted Lemon RFC Editor Note: Please replace paragraphs 4 and 5 of section three with the following new text. OLD (in -05): Because of the UDP payload limit of 1100 octets [RFC6887], the configured maximum length MUST NOT exceed 1016 octets. The suggested maximum length is 128 octets. If a PCP client includes a DESCRIPTION option with a length exceeding the maximum length supported by the PCP server, only the portion of the Description field fitting that maximum length is stored by the PCP server and returned to the PCP client in the response. If the PCP server receives a DESCRIPTION option having a length which does not exceed the maximum value configured, the PCP server MUST record the complete sequence of the description text and MUST send back to the PCP client the same DESCRIPTION option as the one included in the request. NEW: A PCP server SHOULD be able to store at least 128 bytes for a description. When the PCP server receives a DESCRIPTION option, it first stores the value of the received Description field, truncating it if it cannot store the entire value. The server MUST then send the stored value back to the PCP client in the DESCRIPTION option in the response. From nobody Wed Feb 26 10:58:14 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03BB1A07D3; Wed, 26 Feb 2014 10:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEl6ybi1VR-4; Wed, 26 Feb 2014 10:58:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 925A01A074A; Wed, 26 Feb 2014 10:58:00 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140226185800.17844.42509.idtracker@ietfa.amsl.com> Date: Wed, 26 Feb 2014 10:58:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/_c13dhziqyBsESlIwubARuBYRkc Cc: pcp mailing list , pcp chair , RFC Editor Subject: [pcp] Protocol Action: 'Learning NAT64 PREFIX64s using Port Control Protocol (PCP)' to Proposed Standard (draft-ietf-pcp-nat64-prefix64-06.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 18:58:07 -0000 The IESG has approved the following document: - 'Learning NAT64 PREFIX64s using Port Control Protocol (PCP)' (draft-ietf-pcp-nat64-prefix64-06.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64/ Technical Summary This document defines a new PCP extension to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This extension is needed for successful communications when IPv4 addresses are used in referrals. Working Group Summary The WG easily got consensus. Document Quality It is unknown whether there are existing implementations. A large number of people (named in section 8 of the doc) reviewed it and contributed to it. The individuals who provided reviews during WGLC were: Dave Thaler Teemu Savolainen Senthil Sivakumar Simon Perreault Iljitsch van Beijnum Personnel Document Shepherd: Dave Thaler Responsible AD: Ted Lemon From nobody Thu Feb 27 12:18:24 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE871A0552 for ; Thu, 27 Feb 2014 12:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O08c4Gf-gcwH for ; Thu, 27 Feb 2014 12:18:19 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1991A0643 for ; Thu, 27 Feb 2014 12:18:18 -0800 (PST) Received: from mail100-am1-R.bigfish.com (10.3.201.228) by AM1EHSOBE023.bigfish.com (10.3.207.145) with Microsoft SMTP Server id 14.1.225.22; Thu, 27 Feb 2014 20:18:16 +0000 Received: from mail100-am1 (localhost [127.0.0.1]) by mail100-am1-R.bigfish.com (Postfix) with ESMTP id 6482136078D; Thu, 27 Feb 2014 20:18:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -73 X-BigFish: VPS-73(z551bizbb2dI98dI9371Ic89bh1432I15caKJzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hz97hdchz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail100-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=sureshk@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(51704005)(479174003)(189002)(24454002)(55784002)(199002)(76482001)(94946001)(31966008)(74662001)(74502001)(19580405001)(83072002)(2656002)(51856001)(94316002)(47446002)(54356001)(54316002)(86362001)(95416001)(79102001)(36756003)(92566001)(2201001)(92726001)(95666003)(83322001)(19580395003)(81686001)(83506001)(87266001)(80976001)(85852003)(59766001)(74706001)(53806001)(50986001)(47736001)(47976001)(49866001)(93136001)(81342001)(65816001)(66066001)(80022001)(69226001)(76796001)(1511001)(90146001)(56776001)(56816005)(87936001)(74366001)(46102001)(85306002)(81816001)(81542001)(4396001)(76786001)(76176001)(93516002)(74876001)(77982001)(63696002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB719; H:DM2PR05MB288.namprd05.prod.outlook.com; CLIP:66.129.239.14; FPR:FCFEFD0D.AFFA17E9.F5C170BC.4EEEF74B.20411; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail100-am1 (localhost.localdomain [127.0.0.1]) by mail100-am1 (MessageSwitch) id 1393532293283994_6427; Thu, 27 Feb 2014 20:18:13 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.229]) by mail100-am1.bigfish.com (Postfix) with ESMTP id 3ADF724009D; Thu, 27 Feb 2014 20:18:13 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 27 Feb 2014 20:18:11 +0000 Received: from DM2PR05MB719.namprd05.prod.outlook.com (10.141.177.151) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 27 Feb 2014 20:18:10 +0000 Received: from DM2PR05MB288.namprd05.prod.outlook.com (10.141.101.11) by DM2PR05MB719.namprd05.prod.outlook.com (10.141.177.151) with Microsoft SMTP Server (TLS) id 15.0.883.10; Thu, 27 Feb 2014 20:18:08 +0000 Received: from DM2PR05MB288.namprd05.prod.outlook.com ([10.141.101.11]) by DM2PR05MB288.namprd05.prod.outlook.com ([10.141.101.11]) with mapi id 15.00.0888.003; Thu, 27 Feb 2014 20:18:08 +0000 From: Suresh Kumar Vinapamula Venkata To: "mohamed.boucadair@orange.com" , pcp issue tracker , "dwing@cisco.com" , "dthaler@microsoft.com" Thread-Topic: [pcp] #34: notify NAT WAN address changed Thread-Index: AQHPMdWeDQOTA82BA0m4bjbUYzmRWprHQb4AgAHGg4A= Date: Thu, 27 Feb 2014 20:18:08 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4F905D0F@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [66.129.239.14] x-forefront-prvs: 013568035E Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9B0A26BCB4460D42A66AB8DD41A8046D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/clv5VfdgQCafAXZtrq5kk9Cm6bo Cc: "pcp@ietf.org" Subject: Re: [pcp] #34: notify NAT WAN address changed X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 20:18:22 -0000 Hi Dave,=20 Section 14.2 of RFC6887 addresses change in external IP address of PCP controlled NAT, and it doesn=B9t address change in CPE WAN IP address. This draft is addressing the change in CPE WAN IP address and suggests recommendations.=20 Thanks Suresh On 2/26/14 1:11 AM, "mohamed.boucadair@orange.com" wrote: >Hi Dave, all, > >I agree most of the issues captured in this ticket are solved, but still >there is one remaining issue. > >As a reminder, the ticket refers to this text: > >=3D=3D=3D=3D=3D=3D >2.5. Change of the CPE WAN IP Address > > The change of the IP address of the WAN interface of the CPE would > have an impact on the accuracy of the mappings instantiated in the > PCP Server: > > o For the DS-Lite case [I-D.ietf-softwire-dual-stack-lite]: if a new > IPv6 address is used by the B4 element when encapsulating IPv4 > packets in IPv6 ones, the mappings SHOULD be refreshed: If the PCP > Client is embedded in the B4, the refresh operation is triggered > by the change of the B4 IPv6 address. This would be more > complicated when the PCP Client is located in a device behind the > B4. > > [Ed. Note: how an IPv4 host behind a DS-Lite CPE is aware that > a new IPv6 address is used by the B4?] > > o For the NAT64 case [I-D.ietf-behave-v6v4-xlate-stateful], any > change of the assigned IPv6 prefix delegated to the CPE will be > detected by the PCP Client (because this leads to the allocation > of a new IPv6 address). The PCP Client has to undertake the > operation described in Section 2.4. >=3D=3D=3D=3D=3D=3D=3D=3D > >An issue is still unsolved in the DS-Lite case where the PCP client is >not co-located with B4. This issue is not solved in the base PCP spec, >but is addressed in this individual draft: >http://tools.ietf.org/search/draft-vinapamula-softwire-dslite-prefix-bindi >ng-01=20 > >The recommendation in >http://tools.ietf.org/search/draft-vinapamula-softwire-dslite-prefix-bindi >ng-01 covers the PCP case, in particular these two recommendations: > > 3. In the event a new IPv6 address is assigned to B4, the AFTR > SHOULD migrate existing state to be bound to the new B4's IP > address. This ensures the traffic destined to the previous IPv6 > address will redirected to the new IPv6 address. The destination > address for tunneling return traffic SHOULD be the last seen > address from the CPE. The source address of the tunnel would > remain same as AFTR. > > 4. In the event of change of the CPE WAN IPv6 prefix, unsolicited > PCP ANNOUNCE messages SHOULD be sent by the B4 element to > internal hosts to update their mappings. > >Cheers, >Med > >>-----Message d'origine----- >>De : pcp [mailto:pcp-bounces@ietf.org] De la part de pcp issue tracker >>Envoy=E9 : mardi 25 f=E9vrier 2014 03:59 >>=C0 : dwing@cisco.com; dthaler@microsoft.com >>Cc : pcp@ietf.org >>Objet : Re: [pcp] #34: notify NAT WAN address changed >> >>#34: notify NAT WAN address changed >> >>Changes (by dthaler@microsoft.com): >> >> * status: new =3D> closed >> * resolution: =3D> fixed >> >> >>Comment: >> >> This was addressed in RFC 6887. Section 14.2 begins: >> > 14.2. PCP Mapping Update >> > >> > This rapid recovery mechanism is used when the PCP server remembers >> > its state and determines its existing mappings are invalid (e.g., IP >> > renumbering changes the external IP address of a PCP-controlled >>NAT). >> >>-- >>--------------------------------------------------+--------------------- >> Reporter: mohamed.boucadair@orange-ftgroup.com | Owner: >> Type: enhancement | Status: closed >> Priority: minor | Milestone: >>Component: Extensions | Version: >> Severity: - | Resolution: fixed >> Keywords: | >>--------------------------------------------------+--------------------- >> >>Ticket URL: >>pcp >> >>_______________________________________________ >>pcp mailing list >>pcp@ietf.org >>https://www.ietf.org/mailman/listinfo/pcp > > From nobody Thu Feb 27 14:41:04 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C321A024A for ; Thu, 27 Feb 2014 14:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oC6jJv5Iacf for ; Thu, 27 Feb 2014 14:40:58 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ietfa.amsl.com (Postfix) with ESMTP id C04811A028E for ; Thu, 27 Feb 2014 14:40:57 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB597.namprd03.prod.outlook.com (10.255.93.37) with Microsoft SMTP Server (TLS) id 15.0.888.9; Thu, 27 Feb 2014 22:40:54 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Thu, 27 Feb 2014 22:40:54 +0000 From: Dave Thaler To: Suresh Kumar Vinapamula Venkata , "mohamed.boucadair@orange.com" , "pcp issue tracker" , "dwing@cisco.com" Thread-Topic: [pcp] #34: notify NAT WAN address changed Thread-Index: AQHPMdWQIS2flFFrkUulCiX4MJkHkprHQb8AgAJMpACAACd50A== Date: Thu, 27 Feb 2014 22:40:53 +0000 Message-ID: <2db04f60e1c749b7abcddec705c31e14@BY2PR03MB412.namprd03.prod.outlook.com> References: <94C682931C08B048B7A8645303FDC9F36F4F905D0F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.108.71.45] x-forefront-prvs: 013568035E x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(13464003)(479174003)(51704005)(189002)(199002)(377454003)(56776001)(93516002)(93136001)(54316002)(76482001)(74316001)(49866001)(90146001)(47736001)(94316002)(74706001)(74366001)(4396001)(33646001)(46102001)(92566001)(54356001)(86362001)(53806001)(56816005)(83072002)(50986001)(47976001)(66066001)(80022001)(85852003)(85306002)(65816001)(80976001)(83322001)(19580395003)(19580405001)(81686001)(94946001)(77982001)(59766001)(74662001)(47446002)(81542001)(74502001)(31966008)(63696002)(69226001)(79102001)(87936001)(81816001)(76796001)(76786001)(76576001)(95666003)(95416001)(86612001)(87266001)(74876001)(2656002)(81342001)(24736002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB597; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:199.108.71.45; FPR:FCFEFD1D.AFFA17E9.F4C170BC.4EE2774F.20464; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/412JW493YtpRQW_xrCbfewscD1o Cc: "pcp@ietf.org" Subject: Re: [pcp] #34: notify NAT WAN address changed X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 22:41:01 -0000 I don't follow. If the PCP server controls the NAT in the CPE,=20 then the CPE WAN IP address *is* the external IP address of=20 the PCP controlled NAT. -Dave > -----Original Message----- > From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] > Sent: Thursday, February 27, 2014 12:18 PM > To: mohamed.boucadair@orange.com; pcp issue tracker; dwing@cisco.com; > Dave Thaler > Cc: pcp@ietf.org > Subject: Re: [pcp] #34: notify NAT WAN address changed >=20 > Hi Dave, >=20 > Section 14.2 of RFC6887 addresses change in external IP address of PCP > controlled NAT, and it doesn=B9t address change in CPE WAN IP address. Th= is > draft is addressing the change in CPE WAN IP address and suggests > recommendations. >=20 > Thanks > Suresh >=20 > On 2/26/14 1:11 AM, "mohamed.boucadair@orange.com" > wrote: >=20 > >Hi Dave, all, > > > >I agree most of the issues captured in this ticket are solved, but > >still there is one remaining issue. > > > >As a reminder, the ticket refers to this text: > > > >=3D=3D=3D=3D=3D=3D > >2.5. Change of the CPE WAN IP Address > > > > The change of the IP address of the WAN interface of the CPE would > > have an impact on the accuracy of the mappings instantiated in the > > PCP Server: > > > > o For the DS-Lite case [I-D.ietf-softwire-dual-stack-lite]: if a new > > IPv6 address is used by the B4 element when encapsulating IPv4 > > packets in IPv6 ones, the mappings SHOULD be refreshed: If the PCP > > Client is embedded in the B4, the refresh operation is triggered > > by the change of the B4 IPv6 address. This would be more > > complicated when the PCP Client is located in a device behind the > > B4. > > > > [Ed. Note: how an IPv4 host behind a DS-Lite CPE is aware that > > a new IPv6 address is used by the B4?] > > > > o For the NAT64 case [I-D.ietf-behave-v6v4-xlate-stateful], any > > change of the assigned IPv6 prefix delegated to the CPE will be > > detected by the PCP Client (because this leads to the allocation > > of a new IPv6 address). The PCP Client has to undertake the > > operation described in Section 2.4. > >=3D=3D=3D=3D=3D=3D=3D=3D > > > >An issue is still unsolved in the DS-Lite case where the PCP client is > >not co-located with B4. This issue is not solved in the base PCP spec, > >but is addressed in this individual draft: > >http://tools.ietf.org/search/draft-vinapamula-softwire-dslite-prefix-bi > >ndi > >ng-01 > > > >The recommendation in > >http://tools.ietf.org/search/draft-vinapamula-softwire-dslite-prefix-bi > >ndi > >ng-01 covers the PCP case, in particular these two recommendations: > > > > 3. In the event a new IPv6 address is assigned to B4, the AFTR > > SHOULD migrate existing state to be bound to the new B4's IP > > address. This ensures the traffic destined to the previous IPv6 > > address will redirected to the new IPv6 address. The destination > > address for tunneling return traffic SHOULD be the last seen > > address from the CPE. The source address of the tunnel would > > remain same as AFTR. > > > > 4. In the event of change of the CPE WAN IPv6 prefix, unsolicited > > PCP ANNOUNCE messages SHOULD be sent by the B4 element to > > internal hosts to update their mappings. > > > >Cheers, > >Med > > > >>-----Message d'origine----- > >>De : pcp [mailto:pcp-bounces@ietf.org] De la part de pcp issue tracker > >>Envoy=E9 : mardi 25 f=E9vrier 2014 03:59 =C0 : dwing@cisco.com; > >>dthaler@microsoft.com Cc : pcp@ietf.org Objet : Re: [pcp] #34: notify > >>NAT WAN address changed > >> > >>#34: notify NAT WAN address changed > >> > >>Changes (by dthaler@microsoft.com): > >> > >> * status: new =3D> closed > >> * resolution: =3D> fixed > >> > >> > >>Comment: > >> > >> This was addressed in RFC 6887. Section 14.2 begins: > >> > 14.2. PCP Mapping Update > >> > > >> > This rapid recovery mechanism is used when the PCP server > remembers > >> > its state and determines its existing mappings are invalid (e.g., = IP > >> > renumbering changes the external IP address of a PCP-controlled > >>NAT). > >> > >>-- > >>--------------------------------------------------+------------------- > >>--------------------------------------------------+-- > >> Reporter: mohamed.boucadair@orange-ftgroup.com | Owner: > >> Type: enhancement | Status: close= d > >> Priority: minor | Milestone: > >>Component: Extensions | Version: > >> Severity: - | Resolution: fixed > >> Keywords: | > >>--------------------------------------------------+------------------- > >>--------------------------------------------------+-- > >> > >>Ticket URL: > >> > >>pcp > >> > >>_______________________________________________ > >>pcp mailing list > >>pcp@ietf.org > >>https://www.ietf.org/mailman/listinfo/pcp > > > > >=20 From nobody Thu Feb 27 14:43:00 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A031A015E for ; Thu, 27 Feb 2014 14:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQyaCvo9Q03k for ; Thu, 27 Feb 2014 14:42:54 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 248F21A0131 for ; Thu, 27 Feb 2014 14:42:53 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB595.namprd03.prod.outlook.com (10.255.93.35) with Microsoft SMTP Server (TLS) id 15.0.888.9; Thu, 27 Feb 2014 22:42:50 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0883.010; Thu, 27 Feb 2014 22:42:50 +0000 From: Dave Thaler To: "mohamed.boucadair@orange.com" , "pcp issue tracker" , "dwing@cisco.com" Thread-Topic: [pcp] #34: notify NAT WAN address changed Thread-Index: AQHPMdWQIS2flFFrkUulCiX4MJkHkprHQb8AgAJ0U7A= Date: Thu, 27 Feb 2014 22:42:49 +0000 Message-ID: References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> <089.dbc3f8a58b54e680653d724bd0c3c76d@tools.ietf.org> <94C682931C08B048B7A8645303FDC9F36F4F905D0F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F4F905D0F@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.108.71.45] x-forefront-prvs: 013568035E x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(51704005)(377454003)(13464003)(86362001)(94946001)(79102001)(94316002)(19580405001)(83322001)(63696002)(80976001)(76576001)(76786001)(76796001)(74706001)(95666003)(74876001)(87266001)(69226001)(90146001)(81542001)(19580395003)(33646001)(93136001)(86612001)(81686001)(59766001)(77982001)(95416001)(74366001)(74316001)(93516002)(81342001)(53806001)(56776001)(31966008)(81816001)(54316002)(76482001)(65816001)(50986001)(47976001)(66066001)(80022001)(92566001)(47446002)(4396001)(74502001)(74662001)(49866001)(47736001)(15975445006)(87936001)(54356001)(56816005)(85852003)(83072002)(85306002)(46102001)(2656002)(15202345003)(24736002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB595; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:199.108.71.45; FPR:FCFCFDDD.AFFA17E9.F0C170B8.46EEF74F.20436; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/7iPOyZHXQbX6UbI9yEqmqwS2XUA Cc: "pcp@ietf.org" Subject: Re: [pcp] #34: notify NAT WAN address changed X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 22:42:57 -0000 The DSlite case needs to be treated as a separate issue because it's a separate doc. I'll open a separate ticket to track that. -Dave > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, February 26, 2014 1:11 AM > To: pcp issue tracker; dwing@cisco.com; Dave Thaler > Cc: pcp@ietf.org; Suresh Kumar Vinapamula Venkata > Subject: RE: [pcp] #34: notify NAT WAN address changed >=20 > Hi Dave, all, >=20 > I agree most of the issues captured in this ticket are solved, but still = there is > one remaining issue. >=20 > As a reminder, the ticket refers to this text: >=20 > =3D=3D=3D=3D=3D=3D > 2.5. Change of the CPE WAN IP Address >=20 > The change of the IP address of the WAN interface of the CPE would > have an impact on the accuracy of the mappings instantiated in the > PCP Server: >=20 > o For the DS-Lite case [I-D.ietf-softwire-dual-stack-lite]: if a new > IPv6 address is used by the B4 element when encapsulating IPv4 > packets in IPv6 ones, the mappings SHOULD be refreshed: If the PCP > Client is embedded in the B4, the refresh operation is triggered > by the change of the B4 IPv6 address. This would be more > complicated when the PCP Client is located in a device behind the > B4. >=20 > [Ed. Note: how an IPv4 host behind a DS-Lite CPE is aware that > a new IPv6 address is used by the B4?] >=20 > o For the NAT64 case [I-D.ietf-behave-v6v4-xlate-stateful], any > change of the assigned IPv6 prefix delegated to the CPE will be > detected by the PCP Client (because this leads to the allocation > of a new IPv6 address). The PCP Client has to undertake the > operation described in Section 2.4. > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > An issue is still unsolved in the DS-Lite case where the PCP client is no= t co- > located with B4. This issue is not solved in the base PCP spec, but is > addressed in this individual draft: http://tools.ietf.org/search/draft- > vinapamula-softwire-dslite-prefix-binding-01 >=20 > The recommendation in http://tools.ietf.org/search/draft-vinapamula- > softwire-dslite-prefix-binding-01 covers the PCP case, in particular thes= e two > recommendations: >=20 > 3. In the event a new IPv6 address is assigned to B4, the AFTR > SHOULD migrate existing state to be bound to the new B4's IP > address. This ensures the traffic destined to the previous IPv6 > address will redirected to the new IPv6 address. The destination > address for tunneling return traffic SHOULD be the last seen > address from the CPE. The source address of the tunnel would > remain same as AFTR. >=20 > 4. In the event of change of the CPE WAN IPv6 prefix, unsolicited > PCP ANNOUNCE messages SHOULD be sent by the B4 element to > internal hosts to update their mappings. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: pcp [mailto:pcp-bounces@ietf.org] De la part de pcp issue tracker > >Envoy=E9=A0: mardi 25 f=E9vrier 2014 03:59 =C0=A0: dwing@cisco.com; > >dthaler@microsoft.com Cc=A0: pcp@ietf.org Objet=A0: Re: [pcp] #34: notif= y > >NAT WAN address changed > > > >#34: notify NAT WAN address changed > > > >Changes (by dthaler@microsoft.com): > > > > * status: new =3D> closed > > * resolution: =3D> fixed > > > > > >Comment: > > > > This was addressed in RFC 6887. Section 14.2 begins: > > > 14.2. PCP Mapping Update > > > > > > This rapid recovery mechanism is used when the PCP server remembers > > > its state and determines its existing mappings are invalid (e.g., I= P > > > renumbering changes the external IP address of a PCP-controlled NAT= ). > > > >-- > >--------------------------------------------------+-------------------- > >--------------------------------------------------+- > > Reporter: mohamed.boucadair@orange-ftgroup.com | Owner: > > Type: enhancement | Status: closed > > Priority: minor | Milestone: > >Component: Extensions | Version: > > Severity: - | Resolution: fixed > > Keywords: | > >--------------------------------------------------+-------------------- > >--------------------------------------------------+- > > > >Ticket URL: > > > >pcp > > > >_______________________________________________ > >pcp mailing list > >pcp@ietf.org > >https://www.ietf.org/mailman/listinfo/pcp From nobody Thu Feb 27 14:46:13 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6DB1A0131 for ; Thu, 27 Feb 2014 14:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThY28_pycIEy for ; Thu, 27 Feb 2014 14:46:08 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 830F11A00ED for ; Thu, 27 Feb 2014 14:46:08 -0800 (PST) Received: from localhost ([127.0.0.1]:39433 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WJ9iB-0003YH-Bw; Thu, 27 Feb 2014 23:45:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "pcp issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-pcp-dslite@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: pcp Date: Thu, 27 Feb 2014 22:45:51 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/pcp/trac/ticket/71 Message-ID: <066.da9f39acbb4f0e726165162172cd1c41@tools.ietf.org> X-Trac-Ticket-ID: 71 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-dslite@tools.ietf.org, mohamed.boucadair@orange.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: fdupont@isc.org, jacni@jacni.com, mrw@painless-security.com, tina.tsou.zouting@huawei.com, zhangdacheng@huawei.com Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/IHQU5qnoxYTpM0O-3Ld0LdM3PHU Cc: pcp@ietf.org Subject: [pcp] #71 (dslite): Handling change of B4's IPv6 address X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 22:46:11 -0000 #71: Handling change of B4's IPv6 address [DSlite portion of ticket #34 moved to this ticket] ====== 2.5. Change of the CPE WAN IP Address The change of the IP address of the WAN interface of the CPE would have an impact on the accuracy of the mappings instantiated in the PCP Server: o For the DS-Lite case [I-D.ietf-softwire-dual-stack-lite]: if a new IPv6 address is used by the B4 element when encapsulating IPv4 packets in IPv6 ones, the mappings SHOULD be refreshed: If the PCP Client is embedded in the B4, the refresh operation is triggered by the change of the B4 IPv6 address. This would be more complicated when the PCP Client is located in a device behind the B4. [Ed. Note: how an IPv4 host behind a DS-Lite CPE is aware that a new IPv6 address is used by the B4?] o For the NAT64 case [I-D.ietf-behave-v6v4-xlate-stateful], any change of the assigned IPv6 prefix delegated to the CPE will be detected by the PCP Client (because this leads to the allocation of a new IPv6 address). The PCP Client has to undertake the operation described in Section 2.4. ======== An issue is still unsolved in the DS-Lite case where the PCP client is not co-located with B4. This issue is not solved in the base PCP spec, but is addressed in this individual draft: http://tools.ietf.org/search/draft- vinapamula-softwire-dslite-prefix-binding-01 The recommendation in http://tools.ietf.org/search/draft-vinapamula- softwire-dslite-prefix-binding-01 covers the PCP case, in particular these two recommendations: 3. In the event a new IPv6 address is assigned to B4, the AFTR SHOULD migrate existing state to be bound to the new B4's IP address. This ensures the traffic destined to the previous IPv6 address will redirected to the new IPv6 address. The destination address for tunneling return traffic SHOULD be the last seen address from the CPE. The source address of the tunnel would remain same as AFTR. 4. In the event of change of the CPE WAN IPv6 prefix, unsolicited PCP ANNOUNCE messages SHOULD be sent by the B4 element to internal hosts to update their mappings. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-pcp- mohamed.boucadair@orange.com | dslite@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: dslite | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: pcp From nobody Thu Feb 27 16:33:04 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0861A069B for ; Thu, 27 Feb 2014 16:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJWvGutOw5cb for ; Thu, 27 Feb 2014 16:32:57 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id A3D921A068F for ; Thu, 27 Feb 2014 16:32:57 -0800 (PST) Received: from mail224-tx2-R.bigfish.com (10.9.14.225) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.22; Fri, 28 Feb 2014 00:32:55 +0000 Received: from mail224-tx2 (localhost [127.0.0.1]) by mail224-tx2-R.bigfish.com (Postfix) with ESMTP id C87ADA00173; Fri, 28 Feb 2014 00:32:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -74 X-BigFish: VPS-74(z551bizbb2dI98dI9371Ic89bh542I1432I15caKJzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hz97hz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h93fhe5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail224-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=sureshk@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(55784002)(377454003)(479174003)(51704005)(13464003)(189002)(199002)(24454002)(94316002)(74502001)(74662001)(63696002)(74366001)(47446002)(50986001)(76176001)(47736001)(49866001)(86362001)(93516002)(94946001)(81686001)(31966008)(4396001)(51856001)(95666003)(90146001)(85306002)(79102001)(80976001)(92566001)(56816005)(80022001)(76786001)(46102001)(66066001)(76796001)(47976001)(65816001)(83322001)(92726001)(1511001)(19580395003)(95416001)(74706001)(19580405001)(83072002)(53806001)(87266001)(59766001)(77982001)(87936001)(81816001)(2656002)(76482001)(69226001)(93136001)(83506001)(54356001)(36756003)(85852003)(74876001)(54316002)(81342001)(56776001)(81542001)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB706; H:CO1PR05MB284.namprd05.prod.outlook.com; CLIP:66.129.239.14; FPR:FCFEFD1D.AFFA17E9.F4C170BC.4EE2774F.204A3; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail224-tx2 (localhost.localdomain [127.0.0.1]) by mail224-tx2 (MessageSwitch) id 139354757453359_19425; Fri, 28 Feb 2014 00:32:54 +0000 (UTC) Received: from TX2EHSMHS010.bigfish.com (unknown [10.9.14.247]) by mail224-tx2.bigfish.com (Postfix) with ESMTP id F2FBFA0060; Fri, 28 Feb 2014 00:32:53 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS010.bigfish.com (10.9.99.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 28 Feb 2014 00:32:53 +0000 Received: from BLUPR05MB706.namprd05.prod.outlook.com (10.141.207.13) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 28 Feb 2014 00:32:52 +0000 Received: from CO1PR05MB284.namprd05.prod.outlook.com (10.141.70.144) by BLUPR05MB706.namprd05.prod.outlook.com (10.141.207.13) with Microsoft SMTP Server (TLS) id 15.0.888.9; Fri, 28 Feb 2014 00:32:51 +0000 Received: from CO1PR05MB284.namprd05.prod.outlook.com ([10.141.70.144]) by CO1PR05MB284.namprd05.prod.outlook.com ([10.141.70.144]) with mapi id 15.00.0883.010; Fri, 28 Feb 2014 00:32:50 +0000 From: Suresh Kumar Vinapamula Venkata To: Dave Thaler , "mohamed.boucadair@orange.com" , pcp issue tracker , "dwing@cisco.com" Thread-Topic: [pcp] #34: notify NAT WAN address changed Thread-Index: AQHPMdWeDQOTA82BA0m4bjbUYzmRWprHQb4AgAHGg4CAAK4EgP//mSYA Date: Fri, 28 Feb 2014 00:32:50 +0000 Message-ID: In-Reply-To: <2db04f60e1c749b7abcddec705c31e14@BY2PR03MB412.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [66.129.239.14] x-forefront-prvs: 0136C1DDA4 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/Fd5fkP6VA90P50KSsPWfgOnKFQU Cc: "pcp@ietf.org" Subject: Re: [pcp] #34: notify NAT WAN address changed X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 00:33:02 -0000 SGkgRGF2ZSwgDQoNCkkgd2FzIHRhbGtpbmcgaW4gdGhlIGNvbnRleHQgb2YgRFMtTGl0ZSwgd2hh dCBJIG1lYW50IGJ5IENQRSBXQU4gSVAgaXMgdGhlDQpCNCBhZGRyZXNzIG9mIHRoZSBDUEUuIENo YW5nZSBvZiB0aGF0IGFkZHJlc3MgY291bGQgcmVzdWx0IGluIGluYWNjdXJhY3kNCm9mIHRoYXQg ZXhpc3RpbmcgbWFwcGluZ3Mgb2YgYm90aCBQQ1AgYW5kIG5vbiBQQ1AuIFRoaXMgZHJhZnQgaXMN CmFkZHJlc3NpbmcgdGhvc2UgaXNzdWVzLiBNYXkgYmUgIklQIiBhZGRyZXNzLCBtaWdodCBoYXZl IGNvbmZ1c2VkIHlvdS4NCg0KLVN1cmVzaA0KDQpPbiAyLzI3LzE0IDI6NDAgUE0sICJEYXZlIFRo YWxlciIgPGR0aGFsZXJAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQoNCj5JIGRvbid0IGZvbGxvdy4g IElmIHRoZSBQQ1Agc2VydmVyIGNvbnRyb2xzIHRoZSBOQVQgaW4gdGhlIENQRSwNCj50aGVuIHRo ZSBDUEUgV0FOIElQIGFkZHJlc3MgKmlzKiB0aGUgZXh0ZXJuYWwgSVAgYWRkcmVzcyBvZg0KPnRo ZSBQQ1AgY29udHJvbGxlZCBOQVQuDQo+DQo+LURhdmUNCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiBGcm9tOiBTdXJlc2ggS3VtYXIgVmluYXBhbXVsYSBWZW5rYXRhIFttYWls dG86c3VyZXNoa0BqdW5pcGVyLm5ldF0NCj4+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNywg MjAxNCAxMjoxOCBQTQ0KPj4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHBjcCBp c3N1ZSB0cmFja2VyOyBkd2luZ0BjaXNjby5jb207DQo+PiBEYXZlIFRoYWxlcg0KPj4gQ2M6IHBj cEBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtwY3BdICMzNDogbm90aWZ5IE5BVCBXQU4gYWRk cmVzcyBjaGFuZ2VkDQo+PiANCj4+IEhpIERhdmUsDQo+PiANCj4+IFNlY3Rpb24gMTQuMiBvZiBS RkM2ODg3IGFkZHJlc3NlcyBjaGFuZ2UgaW4gZXh0ZXJuYWwgSVAgYWRkcmVzcyBvZiBQQ1ANCj4+ IGNvbnRyb2xsZWQgTkFULCBhbmQgaXQgZG9lc27CuXQgYWRkcmVzcyBjaGFuZ2UgaW4gQ1BFIFdB TiBJUCBhZGRyZXNzLg0KPj5UaGlzDQo+PiBkcmFmdCBpcyBhZGRyZXNzaW5nIHRoZSBjaGFuZ2Ug aW4gQ1BFIFdBTiBJUCBhZGRyZXNzIGFuZCBzdWdnZXN0cw0KPj4gcmVjb21tZW5kYXRpb25zLg0K Pj4gDQo+PiBUaGFua3MNCj4+IFN1cmVzaA0KPj4gDQo+PiBPbiAyLzI2LzE0IDE6MTEgQU0sICJt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIg0KPj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+IHdyb3RlOg0KPj4gDQo+PiA+SGkgRGF2ZSwgYWxsLA0KPj4gPg0KPj4gPkkgYWdyZWUg bW9zdCBvZiB0aGUgaXNzdWVzIGNhcHR1cmVkIGluIHRoaXMgdGlja2V0IGFyZSBzb2x2ZWQsIGJ1 dA0KPj4gPnN0aWxsIHRoZXJlIGlzIG9uZSByZW1haW5pbmcgaXNzdWUuDQo+PiA+DQo+PiA+QXMg YSByZW1pbmRlciwgdGhlIHRpY2tldCByZWZlcnMgdG8gdGhpcyB0ZXh0Og0KPj4gPg0KPj4gPj09 PT09PQ0KPj4gPjIuNS4gQ2hhbmdlIG9mIHRoZSBDUEUgV0FOIElQIEFkZHJlc3MNCj4+ID4NCj4+ ID4gICBUaGUgY2hhbmdlIG9mIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBXQU4gaW50ZXJmYWNlIG9m IHRoZSBDUEUgd291bGQNCj4+ID4gICBoYXZlIGFuIGltcGFjdCBvbiB0aGUgYWNjdXJhY3kgb2Yg dGhlIG1hcHBpbmdzIGluc3RhbnRpYXRlZCBpbiB0aGUNCj4+ID4gICBQQ1AgU2VydmVyOg0KPj4g Pg0KPj4gPiAgIG8gIEZvciB0aGUgRFMtTGl0ZSBjYXNlIFtJLUQuaWV0Zi1zb2Z0d2lyZS1kdWFs LXN0YWNrLWxpdGVdOiBpZiBhDQo+Pm5ldw0KPj4gPiAgICAgIElQdjYgYWRkcmVzcyBpcyB1c2Vk IGJ5IHRoZSBCNCBlbGVtZW50IHdoZW4gZW5jYXBzdWxhdGluZyBJUHY0DQo+PiA+ICAgICAgcGFj a2V0cyBpbiBJUHY2IG9uZXMsIHRoZSBtYXBwaW5ncyBTSE9VTEQgYmUgcmVmcmVzaGVkOiBJZiB0 aGUNCj4+UENQDQo+PiA+ICAgICAgQ2xpZW50IGlzIGVtYmVkZGVkIGluIHRoZSBCNCwgdGhlIHJl ZnJlc2ggb3BlcmF0aW9uIGlzIHRyaWdnZXJlZA0KPj4gPiAgICAgIGJ5IHRoZSBjaGFuZ2Ugb2Yg dGhlIEI0IElQdjYgYWRkcmVzcy4gIFRoaXMgd291bGQgYmUgbW9yZQ0KPj4gPiAgICAgIGNvbXBs aWNhdGVkIHdoZW4gdGhlIFBDUCBDbGllbnQgaXMgbG9jYXRlZCBpbiBhIGRldmljZSBiZWhpbmQg dGhlDQo+PiA+ICAgICAgQjQuDQo+PiA+DQo+PiA+ICAgICAgICAgW0VkLiAgTm90ZTogaG93IGFu IElQdjQgaG9zdCBiZWhpbmQgYSBEUy1MaXRlIENQRSBpcyBhd2FyZQ0KPj50aGF0DQo+PiA+ICAg ICAgICAgYSBuZXcgSVB2NiBhZGRyZXNzIGlzIHVzZWQgYnkgdGhlIEI0P10NCj4+ID4NCj4+ID4g ICBvICBGb3IgdGhlIE5BVDY0IGNhc2UgW0ktRC5pZXRmLWJlaGF2ZS12NnY0LXhsYXRlLXN0YXRl ZnVsXSwgYW55DQo+PiA+ICAgICAgY2hhbmdlIG9mIHRoZSBhc3NpZ25lZCBJUHY2IHByZWZpeCBk ZWxlZ2F0ZWQgdG8gdGhlIENQRSB3aWxsIGJlDQo+PiA+ICAgICAgZGV0ZWN0ZWQgYnkgdGhlIFBD UCBDbGllbnQgKGJlY2F1c2UgdGhpcyBsZWFkcyB0byB0aGUgYWxsb2NhdGlvbg0KPj4gPiAgICAg IG9mIGEgbmV3IElQdjYgYWRkcmVzcykuICBUaGUgUENQIENsaWVudCBoYXMgdG8gdW5kZXJ0YWtl IHRoZQ0KPj4gPiAgICAgIG9wZXJhdGlvbiBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjQuDQo+PiA+ PT09PT09PT0NCj4+ID4NCj4+ID5BbiBpc3N1ZSBpcyBzdGlsbCB1bnNvbHZlZCBpbiB0aGUgRFMt TGl0ZSBjYXNlIHdoZXJlIHRoZSBQQ1AgY2xpZW50IGlzDQo+PiA+bm90IGNvLWxvY2F0ZWQgd2l0 aCBCNC4gVGhpcyBpc3N1ZSBpcyBub3Qgc29sdmVkIGluIHRoZSBiYXNlIFBDUCBzcGVjLA0KPj4g PmJ1dCBpcyBhZGRyZXNzZWQgaW4gdGhpcyBpbmRpdmlkdWFsIGRyYWZ0Og0KPj4gPmh0dHA6Ly90 b29scy5pZXRmLm9yZy9zZWFyY2gvZHJhZnQtdmluYXBhbXVsYS1zb2Z0d2lyZS1kc2xpdGUtcHJl Zml4LWJpDQo+PiA+bmRpDQo+PiA+bmctMDENCj4+ID4NCj4+ID5UaGUgcmVjb21tZW5kYXRpb24g aW4NCj4+ID5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvc2VhcmNoL2RyYWZ0LXZpbmFwYW11bGEtc29m dHdpcmUtZHNsaXRlLXByZWZpeC1iaQ0KPj4gPm5kaQ0KPj4gPm5nLTAxIGNvdmVycyB0aGUgUENQ IGNhc2UsIGluIHBhcnRpY3VsYXIgdGhlc2UgdHdvIHJlY29tbWVuZGF0aW9uczoNCj4+ID4NCj4+ ID4gICAzLiAgSW4gdGhlIGV2ZW50IGEgbmV3IElQdjYgYWRkcmVzcyBpcyBhc3NpZ25lZCB0byBC NCwgdGhlIEFGVFINCj4+ID4gICAgICAgU0hPVUxEIG1pZ3JhdGUgZXhpc3Rpbmcgc3RhdGUgdG8g YmUgYm91bmQgdG8gdGhlIG5ldyBCNCdzIElQDQo+PiA+ICAgICAgIGFkZHJlc3MuICBUaGlzIGVu c3VyZXMgdGhlIHRyYWZmaWMgZGVzdGluZWQgdG8gdGhlIHByZXZpb3VzIElQdjYNCj4+ID4gICAg ICAgYWRkcmVzcyB3aWxsIHJlZGlyZWN0ZWQgdG8gdGhlIG5ldyBJUHY2IGFkZHJlc3MuICBUaGUN Cj4+ZGVzdGluYXRpb24NCj4+ID4gICAgICAgYWRkcmVzcyBmb3IgdHVubmVsaW5nIHJldHVybiB0 cmFmZmljIFNIT1VMRCBiZSB0aGUgbGFzdCBzZWVuDQo+PiA+ICAgICAgIGFkZHJlc3MgZnJvbSB0 aGUgQ1BFLiAgVGhlIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSB0dW5uZWwgd291bGQNCj4+ID4gICAg ICAgcmVtYWluIHNhbWUgYXMgQUZUUi4NCj4+ID4NCj4+ID4gICA0LiAgSW4gdGhlIGV2ZW50IG9m IGNoYW5nZSBvZiB0aGUgQ1BFIFdBTiBJUHY2IHByZWZpeCwgdW5zb2xpY2l0ZWQNCj4+ID4gICAg ICAgUENQIEFOTk9VTkNFIG1lc3NhZ2VzIFNIT1VMRCBiZSBzZW50IGJ5IHRoZSBCNCBlbGVtZW50 IHRvDQo+PiA+ICAgICAgIGludGVybmFsIGhvc3RzIHRvIHVwZGF0ZSB0aGVpciBtYXBwaW5ncy4N Cj4+ID4NCj4+ID5DaGVlcnMsDQo+PiA+TWVkDQo+PiA+DQo+PiA+Pi0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KPj4gPj5EZSA6IHBjcCBbbWFpbHRvOnBjcC1ib3VuY2VzQGlldGYub3JnXSBE ZSBsYSBwYXJ0IGRlIHBjcCBpc3N1ZSB0cmFja2VyDQo+PiA+PkVudm95w6kgOiBtYXJkaSAyNSBm w6l2cmllciAyMDE0IDAzOjU5IMOAIDogZHdpbmdAY2lzY28uY29tOw0KPj4gPj5kdGhhbGVyQG1p Y3Jvc29mdC5jb20gQ2MgOiBwY3BAaWV0Zi5vcmcgT2JqZXQgOiBSZTogW3BjcF0gIzM0OiBub3Rp ZnkNCj4+ID4+TkFUIFdBTiBhZGRyZXNzIGNoYW5nZWQNCj4+ID4+DQo+PiA+PiMzNDogbm90aWZ5 IE5BVCBXQU4gYWRkcmVzcyBjaGFuZ2VkDQo+PiA+Pg0KPj4gPj5DaGFuZ2VzIChieSBkdGhhbGVy QG1pY3Jvc29mdC5jb20pOg0KPj4gPj4NCj4+ID4+ICogc3RhdHVzOiAgbmV3ID0+IGNsb3NlZA0K Pj4gPj4gKiByZXNvbHV0aW9uOiAgID0+IGZpeGVkDQo+PiA+Pg0KPj4gPj4NCj4+ID4+Q29tbWVu dDoNCj4+ID4+DQo+PiA+PiBUaGlzIHdhcyBhZGRyZXNzZWQgaW4gUkZDIDY4ODcuICBTZWN0aW9u IDE0LjIgYmVnaW5zOg0KPj4gPj4gPiAxNC4yLiAgUENQIE1hcHBpbmcgVXBkYXRlDQo+PiA+PiA+ DQo+PiA+PiA+ICAgVGhpcyByYXBpZCByZWNvdmVyeSBtZWNoYW5pc20gaXMgdXNlZCB3aGVuIHRo ZSBQQ1Agc2VydmVyDQo+PiByZW1lbWJlcnMNCj4+ID4+ID4gICBpdHMgc3RhdGUgYW5kIGRldGVy bWluZXMgaXRzIGV4aXN0aW5nIG1hcHBpbmdzIGFyZSBpbnZhbGlkDQo+PihlLmcuLCBJUA0KPj4g Pj4gPiAgIHJlbnVtYmVyaW5nIGNoYW5nZXMgdGhlIGV4dGVybmFsIElQIGFkZHJlc3Mgb2YgYSBQ Q1AtY29udHJvbGxlZA0KPj4gPj5OQVQpLg0KPj4gPj4NCj4+ID4+LS0NCj4+ID4+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPj4gPj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLQ0KPj4gPj4gUmVwb3J0ZXI6ICBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UtZnRncm91 cC5jb20gIHwgICAgICAgT3duZXI6DQo+PiA+PiAgICAgVHlwZTogIGVuaGFuY2VtZW50ICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFN0YXR1czoNCj4+Y2xvc2VkDQo+PiA+PiBQcmlv cml0eTogIG1pbm9yICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIE1pbGVzdG9u ZToNCj4+ID4+Q29tcG9uZW50OiAgRXh0ZW5zaW9ucyAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICBWZXJzaW9uOg0KPj4gPj4gU2V2ZXJpdHk6ICAtICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgIFJlc29sdXRpb246DQo+PmZpeGVkDQo+PiA+PiBLZXl3b3Jkczog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4gPj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tDQo+PiA+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tDQo+PiA+Pg0KPj4gPj5UaWNrZXQgVVJMOg0KPj4gPj48aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvd2cvcGNwL3RyYWMvdGlja2V0LzM0I2NvbW1lbnQ6ND4NCj4+ID4+cGNwIDxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvcGNwLz4NCj4+ID4+DQo+PiA+Pl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PnBjcCBtYWlsaW5nIGxpc3QNCj4+ID4+ cGNwQGlldGYub3JnDQo+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGNwDQo+PiA+DQo+PiA+DQo+PiANCj4NCj4NCj4NCg0K From nobody Thu Feb 27 20:37:14 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84961A06FA for ; Thu, 27 Feb 2014 20:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QicJfoHWxkZ for ; Thu, 27 Feb 2014 20:37:08 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 18CD21A06DF for ; Thu, 27 Feb 2014 20:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1396; q=dns/txt; s=iport; t=1393562227; x=1394771827; h=from:to:subject:date:message-id:mime-version; bh=+5Lk0wsZ8y1zI1b/xpacX5yO6MMqBhGx/ZjO7MMwjM0=; b=B+QjLTCtXKEv73Urs+/KHiAbflqozyTcyXUFoUH++epseRpWPXnZ7+Z/ M0ss9EZw537QUpeL12cfDKJkkfVJNmXSIPFtEQgWwNvNA4XJDmgf3bNnH DA17CUdvYdu5agytkXgLo6C+yvyhRSHnbmQugmn4LHdv3VKHHL6k2/z1S I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4IAEwREFOtJXG//2dsb2JhbABagkJEO1eEIbQniVwWdIIcDgKBCwELAXQnBByHcA2bMLAAF5MTBJg4kiqDLYIq X-IronPort-AV: E=Sophos;i="4.97,559,1389744000"; d="scan'208,217";a="307139376" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 28 Feb 2014 04:37:06 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1S4b6Os023766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 28 Feb 2014 04:37:06 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.98]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 27 Feb 2014 22:37:06 -0600 From: "Reinaldo Penno (repenno)" To: PCP Working Group Thread-Topic: PCP Interop Report - Apple Airport Extreme Thread-Index: AQHPND67RvotjnUmr0m5xviztcGU1w== Date: Fri, 28 Feb 2014 04:37:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.77.147] Content-Type: multipart/alternative; boundary="_000_CF35521C9CA1repennociscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/gdssOqPCTk5MU81wG8gpGDXPOYo Subject: [pcp] PCP Interop Report - Apple Airport Extreme X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 04:37:10 -0000 --_000_CF35521C9CA1repennociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If there is time and interest at next meeting I can go through the slides. For reference, slides are here: http://www.ietf.org/proceedings/89/slides/slides-89-pcp-1.pdf New versions will be committed to Github Regards, Reinaldo --_000_CF35521C9CA1repennociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
If there is time and interest at next meeting I can go through the sli= des.

For reference, slides are here:


New versions will be committed to Github

Regards,

Reinaldo
--_000_CF35521C9CA1repennociscocom_--