From mohamed.boucadair@orange.com Mon Dec 3 01:07:59 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D162621F889B; Mon, 3 Dec 2012 01:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6kpXn1BbbKY; Mon, 3 Dec 2012 01:07:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D4B7821F8892; Mon, 3 Dec 2012 01:07:58 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 97F6918C0A4; Mon, 3 Dec 2012 10:07:56 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5B0BE27C076; Mon, 3 Dec 2012 10:07:56 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 3 Dec 2012 10:07:56 +0100 From: To: "fmc@ietf.org" , "int-area@ietf.org" Date: Mon, 3 Dec 2012 10:07:55 +0100 Thread-Topic: draft-boucadair-intarea-host-identifier-scenarios Thread-Index: Ac3RJ5IJWlBw2c21SWyfVVEqMDvBzQADOsDg Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> 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: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" Subject: [Int-area] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 09:08:00 -0000 Dear all, We submitted an updated version of this draft to list use cases which encou= nter the issue of host identification. The following use cases are discusse= d in the draft: (1) Carrier Grade NAT (CGN) (2) A+P (e.g., MAP ) (3) Application Proxies (4) Provider Wi-Fi (5) Policy and Charging Architectures (6) Cellular Networks (7) Femtocells (8) Overlay Networks (e.g., CDNs) The document does not include any solution-specific discussion. Its main go= al is to identify the use cases and describe them.=20 If you think your use case is not included in this version, please share it= with us.=20 Comments are welcome.=20 Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : lundi 3 d=E9cembre 2012 08:26 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-intarea-host-identifier-scenarios-02.tx= t A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Host Identification: Use Cases Author(s) : Mohamed Boucadair David Binet Sophie Durel Tirumaleswar Reddy Brandon Williams Filename : draft-boucadair-intarea-host-identifier-scenarios-02.txt Pages : 14 Date : 2012-12-02 Abstract: This document describes a set of scenarios in which host identification is required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-intarea-host-identifier-sc= enarios There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenario= s-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-intarea-host-identifier-= scenarios-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From wesley.george@twcable.com Tue Dec 4 12:11:49 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B87621F85E8; Tue, 4 Dec 2012 12:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkviYq7UfAw2; Tue, 4 Dec 2012 12:11:48 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB5F21F8C70; Tue, 4 Dec 2012 12:11:47 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,217,1355115600"; d="scan'208";a="482631668" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 04 Dec 2012 15:08:44 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 4 Dec 2012 15:08:53 -0500 From: "George, Wes" To: "mohamed.boucadair@orange.com" , "fmc@ietf.org" , "int-area@ietf.org" Date: Tue, 4 Dec 2012 15:09:11 -0500 Thread-Topic: draft-boucadair-intarea-host-identifier-scenarios Thread-Index: Ac3RJ5IJWlBw2c21SWyfVVEqMDvBzQADOsDgAEjqz2A= Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.com> References: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" Subject: Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 20:11:49 -0000 I've read this draft, and I think the use case list is reasonably complete. However, it's really unclear to me what the value of this draft might be in= its current form, and what its intended audience might be. Cataloging use = cases is not all that helpful by itself without an end goal in mind, and th= at end goal is not clear from the draft. The scope is deliberately very nar= row and references other drafts that discuss some of the surrounding issues= with address sharing and unique identifiers, and so there is very little t= ext in each section beyond a basic description. Even when you think of this= in terms of follow-on drafts such as a gap analysis or problem statement o= r solution drafts, one wonders how useful it is to spread this across multi= ple drafts. So why not simply incorporate this list into one of the referen= ced general drafts on host identification, such as nat-reveal-analysis and = then broaden that draft so that it considers and addresses the other use ca= ses as appropriate? Otherwise, I think that the draft needs to be much clearer about the unique= issues and considerations for each use case, especially those that are som= ehow distinct from those covered in nat-reveal-analysis so that it can serv= e as a better input to any potential solutions addressing this problem. I also believe that if this draft is to remain a standalone document, the a= uthors need to make at least some attempt at discussing security and privac= y considerations here, even if it is mainly to refer the reader to more in-= depth discussions of the matter in other drafts. Again, here is an area whe= re being clear about the specific considerations for each use case is impor= tant, identifying whether the other drafts discuss things so that they are = applicable to all of the use cases, or if the use cases are unique in any n= umber of ways that will mean that they have unique privacy and security con= siderations. Thanks, Wes George > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of mohamed.boucadair@orange.com > Sent: Monday, December 03, 2012 4:08 AM > To: fmc@ietf.org; int-area@ietf.org > Cc: draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org > Subject: [Int-area] draft-boucadair-intarea-host-identifier-scenarios > > Dear all, > > We submitted an updated version of this draft to list use cases which > encounter the issue of host identification. The following use cases are > discussed in the draft: > > (1) Carrier Grade NAT (CGN) > (2) A+P (e.g., MAP ) > (3) Application Proxies > (4) Provider Wi-Fi > (5) Policy and Charging Architectures > (6) Cellular Networks > (7) Femtocells > (8) Overlay Networks (e.g., CDNs) > > The document does not include any solution-specific discussion. Its main > goal is to identify the use cases and describe them. > > If you think your use case is not included in this version, please share > it with us. > > Comments are welcome. > > Cheers, > Med > > > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] De la part de internet-drafts@ietf.org Envoy=E9 : lundi > 3 d=E9cembre 2012 08:26 =C0 : i-d-announce@ietf.org Objet : I-D Action: > draft-boucadair-intarea-host-identifier-scenarios-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Host Identification: Use Cases > Author(s) : Mohamed Boucadair > David Binet > Sophie Durel > Tirumaleswar Reddy > Brandon Williams > Filename : draft-boucadair-intarea-host-identifier- > scenarios-02.txt > Pages : 14 > Date : 2012-12-02 > > Abstract: > This document describes a set of scenarios in which host > identification is required. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-intarea-host- > identifier-scenarios > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- > scenarios-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-intarea-host- > identifier-scenarios-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From mohamed.boucadair@orange.com Tue Dec 4 23:10:04 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF2321F8C71; Tue, 4 Dec 2012 23:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd84GWu9NIA5; Tue, 4 Dec 2012 23:10:03 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B15F721F8C60; Tue, 4 Dec 2012 23:10:02 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id BAB6C18CB61; Wed, 5 Dec 2012 08:10:00 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9A22D35C065; Wed, 5 Dec 2012 08:10:00 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 5 Dec 2012 08:10:00 +0100 From: To: "George, Wes" , "fmc@ietf.org" , "int-area@ietf.org" Date: Wed, 5 Dec 2012 08:09:59 +0100 Thread-Topic: draft-boucadair-intarea-host-identifier-scenarios Thread-Index: Ac3RJ5IJWlBw2c21SWyfVVEqMDvBzQADOsDgAEjqz2AAFxx6kA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2E2C2@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.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: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.5.61518 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" Subject: Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 07:10:05 -0000 Dear Wes, Thank you for your comments.=20 Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : George, Wes [mailto:wesley.george@twcable.com]=20 >Envoy=E9 : mardi 4 d=E9cembre 2012 21:09 >=C0 : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-area@ietf.org >Cc : draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org >Objet : RE: draft-boucadair-intarea-host-identifier-scenarios > >I've read this draft, and I think the use case list is=20 >reasonably complete. > >However, it's really unclear to me what the value of this=20 >draft might be in its current form, and what its intended=20 >audience might be. Cataloging use cases is not all that=20 >helpful by itself without an end goal in mind, and that end=20 >goal is not clear from the draft. Med: The goal of this draft is what is described in Section 2: "The goal is to identify scenarios the authors are aware of and which share the same issue of host identification. This document does not include any solution-specific discussion. This document can be used as a tool to design solution(s) mitigating the encountered issues. Having a generic solution which would solve the issues encountered in these use cases is preferred over designing a solution for each use case. Describing the use case allows to identify what is common between the use cases and then would help during the solution design phase." Next updates of this draft will: * include a discussion section to assess whether the issue is valid for IPv= 4-only or it applies also for IPv6 * include a discussion text to clarify whether each use case is valid withi= n one single administrative domain or not * include a discussion text to identify use cases which share the same requ= irements (this will help in designing the solution)=20 * add additional use cases if any At given point in time we need to draw conclusions about the following: (1) are these use cases valid ones? (2) if this is a real technical problem, what the IETF can do to solve the = issue? (3) if there is interest in this area, how to organize the work for the sol= ution space. The scope is deliberately=20 >very narrow and references other drafts that discuss some of=20 >the surrounding issues with address sharing and unique=20 >identifiers, and so there is very little text in each section=20 >beyond a basic description. Even when you think of this in=20 >terms of follow-on drafts such as a gap analysis or problem=20 >statement or solution drafts, one wonders how useful it is to=20 >spread this across multiple drafts. So why not simply=20 >incorporate this list into one of the referenced general=20 >drafts on host identification, such as nat-reveal-analysis and=20 >then broaden that draft so that it considers and addresses the=20 >other use cases as appropriate? Med: As I mentioned above, we don't want to include any solution-specific d= iscussion to this draft. The text is shortened in purpose. > >Otherwise, I think that the draft needs to be much clearer=20 >about the unique issues and considerations for each use case,=20 >especially those that are somehow distinct from those covered=20 >in nat-reveal-analysis so that it can serve as a better input=20 >to any potential solutions addressing this problem. Med: Fully agreed. This will be added to the next rev of the draft. > >I also believe that if this draft is to remain a standalone=20 >document, the authors need to make at least some attempt at=20 >discussing security and privacy considerations here, even if=20 >it is mainly to refer the reader to more in-depth discussions=20 >of the matter in other drafts. Med: Agree. A pointer to http://tools.ietf.org/html/draft-ietf-intarea-nat-= reveal-analysis-04#section-3 will be added to the next rev of the draft. Th= e text will also include some discussion for use cases which are restricted= to one single administrative domain. Again, here is an area where=20 >being clear about the specific considerations for each use=20 >case is important, identifying whether the other drafts=20 >discuss things so that they are applicable to all of the use=20 >cases, or if the use cases are unique in any number of ways=20 >that will mean that they have unique privacy and security=20 >considerations. > >Thanks, > >Wes George > >> -----Original Message----- >> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On >> Behalf Of mohamed.boucadair@orange.com >> Sent: Monday, December 03, 2012 4:08 AM >> To: fmc@ietf.org; int-area@ietf.org >> Cc: draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org >> Subject: [Int-area] draft-boucadair-intarea-host-identifier-scenarios >> >> Dear all, >> >> We submitted an updated version of this draft to list use cases which >> encounter the issue of host identification. The following=20 >use cases are >> discussed in the draft: >> >> (1) Carrier Grade NAT (CGN) >> (2) A+P (e.g., MAP ) >> (3) Application Proxies >> (4) Provider Wi-Fi >> (5) Policy and Charging Architectures >> (6) Cellular Networks >> (7) Femtocells >> (8) Overlay Networks (e.g., CDNs) >> >> The document does not include any solution-specific=20 >discussion. Its main >> goal is to identify the use cases and describe them. >> >> If you think your use case is not included in this version,=20 >please share >> it with us. >> >> Comments are welcome. >> >> Cheers, >> Med >> >> >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org [mailto:i-d-announce- >> bounces@ietf.org] De la part de internet-drafts@ietf.org=20 >Envoy=E9 : lundi >> 3 d=E9cembre 2012 08:26 =C0 : i-d-announce@ietf.org Objet : I-D Action: >> draft-boucadair-intarea-host-identifier-scenarios-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Host Identification: Use Cases >> Author(s) : Mohamed Boucadair >> David Binet >> Sophie Durel >> Tirumaleswar Reddy >> Brandon Williams >> Filename : draft-boucadair-intarea-host-identifier- >> scenarios-02.txt >> Pages : 14 >> Date : 2012-12-02 >> >> Abstract: >> This document describes a set of scenarios in which host >> identification is required. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-boucadair-intarea-host- >> identifier-scenarios >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- >> scenarios-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-intarea-host- >> identifier-scenarios-02 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > >This E-mail and any of its attachments may contain Time Warner=20 >Cable proprietary information, which is privileged,=20 >confidential, or subject to copyright belonging to Time Warner=20 >Cable. This E-mail is intended solely for the use of the=20 >individual or entity to which it is addressed. If you are not=20 >the intended recipient of this E-mail, you are hereby notified=20 >that any dissemination, distribution, copying, or action taken=20 >in relation to the contents of and attachments to this E-mail=20 >is strictly prohibited and may be unlawful. If you have=20 >received this E-mail in error, please notify the sender=20 >immediately and permanently delete the original and any copy=20 >of this E-mail and any printout. >= From brian.e.carpenter@gmail.com Wed Dec 5 07:42:34 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497C021F8CC4 for ; Wed, 5 Dec 2012 07:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UakMDYa7qEJ9 for ; Wed, 5 Dec 2012 07:42:33 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 90E3F21F8CBF for ; Wed, 5 Dec 2012 07:42:33 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hm9so1795281wib.13 for ; Wed, 05 Dec 2012 07:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=5CRrJ3VJBH0eeibG1inpMlcLMt/NU4/HuCmU2Gw1D/E=; b=v97U62UiZBTdreT8jVT5Tggy9pCQlq1KeIP7EmTaFflwwxZk0CyAZhyYvWo7x+WzW0 piZF/aZfrZoL2UEDvm0xrwMYwH9GG1wbDyr81rQGTQ0TBFQ9MEMY3HsHl5RVL+L1Qk+o 7r6wDusVbeY1nc89dtThOssh7S4oXtrBeS3ylvRbpGhQfxhrH60V57b0WwstKg9Ccn+X 2/UBMdh4kolejpcV2e0S+fDwSH3BJ9Jx044f/fs8PLenCw4zDGtiYz2UnfaCZTvQdfmJ pjdjNq/4ILj6vhxB6WpOqUicZLZ1XlJrzwfH3m/8R59V3rSVJpuQGOkjZALIt8utX/aY 10Dw== Received: by 10.180.87.39 with SMTP id u7mr3954618wiz.6.1354722152680; Wed, 05 Dec 2012 07:42:32 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-76.as13285.net. [2.102.216.76]) by mx.google.com with ESMTPS id eu8sm19510225wib.1.2012.12.05.07.42.30 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 07:42:31 -0800 (PST) Message-ID: <50BF6B6F.8080006@gmail.com> Date: Wed, 05 Dec 2012 15:42:39 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: int-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Int-area] [Fwd: I-D Action: draft-carpenter-flow-label-balancing-02.txt] X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 15:42:34 -0000 Hi, This version has been updated following the review by Julia Renouard. Brian -------- Original Message -------- Subject: I-D Action: draft-carpenter-flow-label-balancing-02.txt Date: Wed, 05 Dec 2012 07:36:10 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using the IPv6 Flow Label for Server Load Balancing Author(s) : Brian Carpenter Sheng Jiang Willy Tarreau Filename : draft-carpenter-flow-label-balancing-02.txt Pages : 13 Date : 2012-12-05 Abstract: This document describes how the IPv6 flow label as currently specified can be used to enhance layer 3/4 load distribution and balancing for large server farms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-flow-label-balancing There's also a htmlized version available at: http://tools.ietf.org/html/draft-carpenter-flow-label-balancing-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-carpenter-flow-label-balancing-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Tina.Tsou.Zouting@huawei.com Thu Dec 6 23:16:38 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5D821F84F9; Thu, 6 Dec 2012 23:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL3jfqLRh+Fn; Thu, 6 Dec 2012 23:16:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9824D21F8A90; Thu, 6 Dec 2012 23:16:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMG39661; Fri, 07 Dec 2012 07:16:34 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 07:15:31 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 15:16:03 +0800 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.39]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 6 Dec 2012 23:16:01 -0800 From: Tina TSOU To: "mohamed.boucadair@orange.com" Thread-Topic: [Int-area] draft-boucadair-intarea-host-identifier-scenarios Thread-Index: AQHN1Eq1hdFbUszkvEqG84In7vT9DA== Date: Fri, 7 Dec 2012 07:16:00 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.com>, <94C682931C08B048B7A8645303FDC9F36E99E2E2C2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2E2C2@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FDFF3C8247664F0986FC2E9CE214D2C7huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" , "int-area@ietf.org" , "fmc@ietf.org" Subject: Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 07:16:38 -0000 --_000_FDFF3C8247664F0986FC2E9CE214D2C7huaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Med et al, In general, I like the current version. Some comments are below. 1. From my understanding, this document provides the use cases for the= issues and analysis in =93draft-ietf-intarea-nat-reveal-analysis=94. Is it= correct? If it is , I suggest this document be referenced in =93nat-reveal= -analysis=94. 2. Regarding this document, in the section of CGN use case, the statel= ess NAT44 case should be included. 3. For A+P section, the MAP/Lw4over6 cases may be considered. 4. In figure 6, the UE may have an interface with AF to initiate the s= ession request, e.g., SIP. Thank you, Tina On Dec 4, 2012, at 11:10 PM, "mohamed.boucadair@orange.com" > wrote: Dear Wes, Thank you for your comments. Please see inline. Cheers, Med -----Message d'origine----- De : George, Wes [mailto:wesley.george@twcable.com] Envoy=E9 : mardi 4 d=E9cembre 2012 21:09 =C0 : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-ar= ea@ietf.org Cc : draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Objet : RE: draft-boucadair-intarea-host-identifier-scenarios I've read this draft, and I think the use case list is reasonably complete. However, it's really unclear to me what the value of this draft might be in its current form, and what its intended audience might be. Cataloging use cases is not all that helpful by itself without an end goal in mind, and that end goal is not clear from the draft. Med: The goal of this draft is what is described in Section 2: "The goal is to identify scenarios the authors are aware of and which share the same issue of host identification. This document does not include any solution-specific discussion. This document can be used as a tool to design solution(s) mitigating the encountered issues. Having a generic solution which would solve the issues encountered in these use cases is preferred over designing a solution for each use case. Describing the use case allows to identify what is common between the use cases and then would help during the solution design phase." Next updates of this draft will: * include a discussion section to assess whether the issue is valid for IPv= 4-only or it applies also for IPv6 * include a discussion text to clarify whether each use case is valid withi= n one single administrative domain or not * include a discussion text to identify use cases which share the same requ= irements (this will help in designing the solution) * add additional use cases if any At given point in time we need to draw conclusions about the following: (1) are these use cases valid ones? (2) if this is a real technical problem, what the IETF can do to solve the = issue? (3) if there is interest in this area, how to organize the work for the sol= ution space. The scope is deliberately very narrow and references other drafts that discuss some of the surrounding issues with address sharing and unique identifiers, and so there is very little text in each section beyond a basic description. Even when you think of this in terms of follow-on drafts such as a gap analysis or problem statement or solution drafts, one wonders how useful it is to spread this across multiple drafts. So why not simply incorporate this list into one of the referenced general drafts on host identification, such as nat-reveal-analysis and then broaden that draft so that it considers and addresses the other use cases as appropriate? Med: As I mentioned above, we don't want to include any solution-specific d= iscussion to this draft. The text is shortened in purpose. Otherwise, I think that the draft needs to be much clearer about the unique issues and considerations for each use case, especially those that are somehow distinct from those covered in nat-reveal-analysis so that it can serve as a better input to any potential solutions addressing this problem. Med: Fully agreed. This will be added to the next rev of the draft. I also believe that if this draft is to remain a standalone document, the authors need to make at least some attempt at discussing security and privacy considerations here, even if it is mainly to refer the reader to more in-depth discussions of the matter in other drafts. Med: Agree. A pointer to http://tools.ietf.org/html/draft-ietf-intarea-nat-= reveal-analysis-04#section-3 will be added to the next rev of the draft. Th= e text will also include some discussion for use cases which are restricted= to one single administrative domain. Again, here is an area where being clear about the specific considerations for each use case is important, identifying whether the other drafts discuss things so that they are applicable to all of the use cases, or if the use cases are unique in any number of ways that will mean that they have unique privacy and security considerations. Thanks, Wes George -----Original Message----- From: int-area-bounces@ietf.org [mailto:i= nt-area-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Monday, December 03, 2012 4:08 AM To: fmc@ietf.org; int-area@ietf.org Cc: draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: [Int-area] draft-boucadair-intarea-host-identifier-scenarios Dear all, We submitted an updated version of this draft to list use cases which encounter the issue of host identification. The following use cases are discussed in the draft: (1) Carrier Grade NAT (CGN) (2) A+P (e.g., MAP ) (3) Application Proxies (4) Provider Wi-Fi (5) Policy and Charging Architectures (6) Cellular Networks (7) Femtocells (8) Overlay Networks (e.g., CDNs) The document does not include any solution-specific discussion. Its main goal is to identify the use cases and describe them. If you think your use case is not included in this version, please share it with us. Comments are welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [m= ailto:i-d-announce- bounces@ietf.org] De la part de internet-drafts@ie= tf.org Envoy=E9 : lundi 3 d=E9cembre 2012 08:26 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-intarea-host-identifier-scenarios-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Host Identification: Use Cases Author(s) : Mohamed Boucadair David Binet Sophie Durel Tirumaleswar Reddy Brandon Williams Filename : draft-boucadair-intarea-host-identifier- scenarios-02.txt Pages : 14 Date : 2012-12-02 Abstract: This document describes a set of scenarios in which host identification is required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-intarea-host- identifier-scenarios There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- scenarios-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-intarea-host- identifier-scenarios-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area --_000_FDFF3C8247664F0986FC2E9CE214D2C7huaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear Med et al,

In general, I like the current version. Some comments = are below.

1.      From my understanding, this document provide= s the use cases for the issues and analysis in =93draft-ietf-intarea-nat-re= veal-analysis=94. Is it correct? If it is , I suggest this document be referenced in =93nat-= reveal-analysis=94.

2.      Regarding this document, in the section of C= GN use case, the stateless NAT44 case should be included.=

3.      For A+P section, the MAP/Lw4over6 cases = may be considered.

4.      In figure 6, the UE may have an interface wi= th AF to initiate the session request, e.g., SIP.


Thank you,
Tina

On Dec 4, 2012, at 11:10 PM, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> wrote:

Dear Wes,

Thank you for your comments.

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : George, Wes [mailto:wesley.george@twca= ble.com]
Envoy=E9 : mardi 4 d=E9cembre 2012 21:09
=C0 : BOUCADAIR Mohamed OLNC/OLN; fmc@ietf.org; int-area@ietf.org
Cc : draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org=
Objet : RE: draft-boucadair-intarea-host-id= entifier-scenarios

I've read this draft, and I think the use c= ase list is
reasonably complete.

However, it's really unclear to me what the= value of this
draft might be in its current form, and wha= t its intended
audience might be. Cataloging use cases is = not all that
helpful by itself without an end goal in mi= nd, and that end
goal is not clear from the draft.

Med: The goal of this draft is what is described in Section 2:=

"The goal is to
  identify scenarios the authors are aware of and which sha= re the same
  issue of host identification.

  This document does not include any solution-specific disc= ussion.
  This document can be used as a tool to design solution(s)= mitigating
  the encountered issues.  Having a generic solution w= hich would solve
  the issues encountered in these use cases is preferred ov= er designing
  a solution for each use case.  Describing the use ca= se allows to
  identify what is common between the use cases and then wo= uld help
  during the solution design phase."

Next updates of this draft will:
* include a discussion section to assess whether the issue is valid f= or IPv4-only or it applies also for IPv6
* include a discussion text to clarify whether each use case is valid= within one single administrative domain or not
* include a discussion text to identify use cases which share the sam= e requirements (this will help in designing the solution)
* add additional use cases if any

At given point in time we need to draw conclusions about the followin= g:
(1) are these use cases valid ones?
(2) if this is a real technical problem, what the IETF can do to solv= e the issue?
(3) if there is interest in this area, how to organize the work for t= he solution space.

The scope is deliberately
very narrow and references other drafts tha= t discuss some of
the surrounding issues with address sharing= and unique
identifiers, and so there is very little te= xt in each section
beyond a basic description. Even when you t= hink of this in
terms of follow-on drafts such as a gap ana= lysis or problem
statement or solution drafts, one wonders h= ow useful it is to
spread this across multiple drafts. So why = not simply
incorporate this list into one of the refer= enced general
drafts on host identification, such as nat-= reveal-analysis and
then broaden that draft so that it consider= s and addresses the
other use cases as appropriate?

Med: As I mentioned above, we don't want to include any solution-spec= ific discussion to this draft. The text is shortened in purpose.


Otherwise, I think that the draft needs to = be much clearer
about the unique issues and considerations = for each use case,
especially those that are somehow distinct = from those covered
in nat-reveal-analysis so that it can serve= as a better input
to any potential solutions addressing this = problem.

Med: Fully agreed. This will be added to the next rev of the draft.


I also believe that if this draft is to rem= ain a standalone
document, the authors need to make at least= some attempt at
discussing security and privacy considerati= ons here, even if
it is mainly to refer the reader to more in= -depth discussions
of the matter in other drafts.

Med: Agree. A pointer to http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-04#sectio= n-3 will be added to the next rev of the draft. The text will also incl= ude some discussion for use cases which are restricted to one single admini= strative domain.


Again, here is an area where
being clear about the specific consideratio= ns for each use
case is important, identifying whether the = other drafts
discuss things so that they are applicable = to all of the use
cases, or if the use cases are unique in an= y number of ways
that will mean that they have unique privac= y and security
considerations.

Thanks,

Wes George

-----Original Message-----
From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On=
Behalf Of mohamed.boucadair@orange.com
Sent: Monday, December 03, 2012 4:08 AM
To: fmc@iet= f.org; int-area@ietf.org
Cc: draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org=
Subject: [Int-area] draft-boucadair-intarea= -host-identifier-scenarios

Dear all,

We submitted an updated version of this dra= ft to list use cases which
encounter the issue of host identification.= The following
use cases are
discussed in the draft:

  (1)  Carrier Grade NAT (CG= N)
  (2)  A+P (e.g., MAP )<= /span>
  (3)  Application Proxies
  (4)  Provider Wi-Fi=
  (5)  Policy and Charging A= rchitectures
  (6)  Cellular Networks
  (7)  Femtocells
  (8)  Overlay Networks (e.g= ., CDNs)

The document does not include any solution-= specific
discussion. Its main
goal is to identify the use cases and descr= ibe them.

If you think your use case is not included = in this version,
please share
it with us.

Comments are welcome.

Cheers,
Med


-----Message d'origine-----
De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-
bounces= @ietf.org] De la part de internet-drafts@ietf.org
Envoy=E9 : lundi
3 d=E9cembre 2012 08:26 =C0 : i-d-announce@ietf.org Objet : I-D Action:
draft-boucadair-intarea-host-identifier-sce= narios-02.txt


A New Internet-Draft is available from the = on-line Internet-Drafts
directories.


     Title  &= nbsp;        : Host Identification:= Use Cases
     Author(s) &nb= sp;     : Mohamed Boucadair
       &= nbsp;           &nbs= p;     David Binet
       &= nbsp;           &nbs= p;     Sophie Durel
       &= nbsp;           &nbs= p;     Tirumaleswar Reddy
       &= nbsp;           &nbs= p;     Brandon Williams
     Filename &nbs= p;      : draft-boucadair-intarea-host-identi= fier-
scenarios-02.txt
     Pages  &= nbsp;        : 14
     Date  &n= bsp;         : 2012-12-02

Abstract:
  This document describes a set o= f scenarios in which host
  identification is required.


The IETF datatracker status page for this d= raft is:
https://datatracker.ietf.org/doc/draft-bouc= adair-intarea-host-
identifier-scenarios

There's also a htmlized version available a= t:
http://tools.ietf.org/html/draft-bouca= dair-intarea-host-identifier-
scenarios-02

A diff from the previous version is availab= le at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-= boucadair-intarea-host-
identifier-scenarios-02


Internet-Drafts are also available by anony= mous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___________________________________________= ____
I-D-Announce mailing list
I-= D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce<= /span>
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___________________________________________= ____
Int-area mailing list
Int-ar= ea@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

This E-mail and any of its attachments may = contain Time Warner
Cable proprietary information, which is pri= vileged,
confidential, or subject to copyright belon= ging to Time Warner
Cable. This E-mail is intended solely for t= he use of the
individual or entity to which it is address= ed. If you are not
the intended recipient of this E-mail, you = are hereby notified
that any dissemination, distribution, copyi= ng, or action taken
in relation to the contents of and attachme= nts to this E-mail
is strictly prohibited and may be unlawful.= If you have
received this E-mail in error, please notif= y the sender
immediately and permanently delete the orig= inal and any copy
of this E-mail and any printout.

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://ww= w.ietf.org/mailman/listinfo/int-area
--_000_FDFF3C8247664F0986FC2E9CE214D2C7huaweicom_-- From mohamed.boucadair@orange.com Tue Dec 11 01:32:03 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F094C21F87A2; Tue, 11 Dec 2012 01:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Guh9eKEQgyCc; Tue, 11 Dec 2012 01:32:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8419F21F878B; Tue, 11 Dec 2012 01:32:01 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3AD193245C4; Tue, 11 Dec 2012 10:32:00 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1560627C06E; Tue, 11 Dec 2012 10:32:00 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 11 Dec 2012 10:31:59 +0100 From: To: Tina TSOU Date: Tue, 11 Dec 2012 10:31:58 +0100 Thread-Topic: [Int-area] draft-boucadair-intarea-host-identifier-scenarios Thread-Index: AQHN1Eq1hdFbUszkvEqG84In7vT9DJgRmtZAgADO0+aAAMn8oA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E9B6B6D91@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E99E2D9FA@PUEXCB1B.nanterre.francetelecom.fr> <2671C6CDFBB59E47B64C10B3E0BD59230338CCCBC2@PRVPEXVS15.corp.twcable.com>, <94C682931C08B048B7A8645303FDC9F36E99E2E2C2@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36E9B6B67B2@PUEXCB1B.nanterre.francetelecom.fr> <38E21423-7972-4EFE-A233-B2CB37448B7B@huawei.com> In-Reply-To: <38E21423-7972-4EFE-A233-B2CB37448B7B@huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E9B6B6D91PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.11.90324 Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" , "int-area@ietf.org" , "fmc@ietf.org" Subject: Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 09:32:03 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E9B6B6D91PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tina, Thank you for the clarification. I updated the draft with a pointer to SLNA= T44. I prefer to not modify fig.6 (keep it simple + we are not dealing with sign= alling flows issued from the UE). Thanks for the review. Cheers, Med ________________________________ De : Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] Envoy=E9 : lundi 10 d=E9cembre 2012 20:04 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : George, Wes; fmc@ietf.org; int-area@ietf.org; draft-boucadair-intarea-= host-identifier-scenarios@tools.ietf.org Objet : Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios Dear Med et al, In line... Thank you, Tina On Dec 9, 2012, at 10:57 PM, "mohamed.boucadair@orange.com" > wrote: Hi Tina, Many thanks for the comments. Please see inline. Cheers, Med ________________________________ De : Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] Envoy=E9 : vendredi 7 d=E9cembre 2012 08:16 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : George, Wes; fmc@ietf.org; int-area@ietf.org; draft-boucadair-intarea-host-identifier-scenarios@to= ols.ietf.org Objet : Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios Dear Med et al, In general, I like the current version. Some comments are below. 1. From my understanding, this document provides the use cases for the= issues and analysis in "draft-ietf-intarea-nat-reveal-analysis". Is it cor= rect? If it is , I suggest this document be referenced in "nat-reveal-analy= sis". [Med] nat-reveal-analysis draft inherits its scope from RFC6269. The use ca= ses draft adopts a more generic scope in which host identification issue is= encountered (this can be caused by address sharing, tunnelling, involvemen= t of multiple administrative entities, etc.). 2. Regarding this document, in the section of CGN use case, the statel= ess NAT44 case should be included. [Med] Do you mean 1:1 NAT? [Tina] I meant the case in this document: http://datatracker.ietf.org/doc/d= raft-tsou-stateless-nat44/, did not mean to just promote my own draft thoug= h. 3. For A+P section, the MAP/Lw4over6 cases may be considered. [Med] OK. I will add a pointer to MAP and Lw4over6 as examples. 4. In figure 6, the UE may have an interface with AF to initiate the s= ession request, e.g., SIP. [Med] What does that mean? The goal of fig.6 is to illustrate the case wher= e there is a host identification issue. [Tina] In section 7, it says "The main issue is: PCEF, PCRF and AF all rece= ive information bound to the same UE but without being able to correlate be= tween the piece of data visible for each entity." In PCRF architecture, the AF receives service request from the UE for servi= ce establishment, which is one of the ways for AF to receive UE information= , e.g., user ID. To make the architecture more generic, there should be an = interface between AF and UE. --_000_94C682931C08B048B7A8645303FDC9F36E9B6B6D91PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Tina,
 
Thank you for the clarification. I updated the d= raft=20 with a pointer to SLNAT44.
 
I prefer to not modify fig.6 (keep it simple + <= SPAN=20 class=3D177000707-11122012>we are not dealing with signalling flows issued = from=20 the UE).
 
Thanks for the review.
 
Cheers,
Med

De : Tina TSOU=20 [mailto:Tina.Tsou.Zouting@huawei.com]
Envoy=E9 : lundi 10= =20 d=E9cembre 2012 20:04
=C0 : BOUCADAIR Mohamed=20 OLNC/OLN
Cc : George, Wes; fmc@ietf.org; int-area@ietf.org= ;=20 draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org
Ob= jet :=20 Re: [Int-area]=20 draft-boucadair-intarea-host-identifier-scenarios

Dear Med et al,
In line...

Thank you,
Tina

On Dec 9, 2012, at 10:57 PM, "mohamed.boucadair@orange.com= "=20 <mohamed.boucadair@orange.com= >=20 wrote:

Hi Tina,
 
Many thanks for the comments.
 
Please see inline.
 
Cheers,
Med

De : Tina TSOU=20 [mailto:Tina.Tsou.Zouting@huawei.com]
Envoy=E9 : vend= redi 7=20 d=E9cembre 2012 08:16
=C0 : BOUCADAIR Mohamed=20 OLNC/OLN
Cc : George, Wes; fmc@ietf.org; int-area@ietf.org; draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.or= g
Objet :=20 Re: [Int-area]=20 draft-boucadair-intarea-host-identifier-scenarios

Dear Med et al,

In=20 general, I like the current version. Some comments are=20 below.

1.     &= nbsp;From my understanding, this document provides the use ca= ses for=20 the issues and analysis in =93draft-ietf-intarea-nat-reveal-analysis= =94. Is it=20 correct? If it is , I suggest this document be referenced in=20 =93nat-reveal-analysis=94.
[Med] nat-reveal-a= nalysis=20 draft inherits its scope from RFC6269. The use cases=20 draft adopts a more generic scope in which host identification i= ssue=20 is encountered (this can be caused by address sharing,=20 tunnelling, involvement of multiple administrative entities= ,=20 etc.). 

2.     &= nbsp;Regarding this document, in the section of CGN use case,= the=20 stateless NAT44 case should be included.
[Med] Do you mean 1:1=20 NAT?

[Tina] I meant the case in th= is=20 document: http= ://datatracker.ietf.org/doc/draft-tsou-stateless-nat44/,=20 did not mean to just promote my own draft though.

3.     &= nbsp;For A+P section, the MAP/Lw4over6 cases may be=20 considered.
[Med] OK. I will add a pointer to MAP and L= w4over6=20 as examples.

4.     &= nbsp;In figure 6, the UE may have an interface with AF to ini= tiate=20 the session request, e.g., SIP.
<= FONT=20 color=3D#0000ff size=3D2 face=3D"Courier New">[Med] What does=20 that mean? The goal of fig.6 is to illustrat= e the=20 case where there is a host identification issue.=20

[Tina]=  In section 7, it says =93The main issue is: PCEF, PCRF= and AF=20 all receive information bound to the same UE but without being able to=20 correlate between the piece of data visible for each entity.=94 
In PCRF architecture, the AF receives service re= quest=20 from the UE for service establishment, which is one of the ways for AF to= =20 receive UE information, e.g., user ID. To make the architecture more gene= ric,=20 there should be an interface between AF and UE.=20
 
--_000_94C682931C08B048B7A8645303FDC9F36E9B6B6D91PUEXCB1Bnante_-- From rafiee@hpi.uni-potsdam.de Fri Dec 14 09:18:45 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F9D21F8422; Fri, 14 Dec 2012 09:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[AWL=1.669, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsrX9TZcjf6f; Fri, 14 Dec 2012 09:18:43 -0800 (PST) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 7640A21F8907; Fri, 14 Dec 2012 09:18:43 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 3012216A00E; Fri, 14 Dec 2012 18:18:41 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Fri, 14 Dec 2012 18:18:39 +0100 From: "Rafiee, Hosnieh" To: "Int-area@ietf.org" Date: Fri, 14 Dec 2012 18:18:37 +0100 Thread-Topic: Call for the adoption of draft-rafiee-intarea-CGA-TSIG Thread-Index: Ac3aHtFFFtVD9r7kR+GWjIzerXvptw== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924EB86C58A8MXMA1Rhpiuni_" MIME-Version: 1.0 Cc: "DNSOP@ietf.org" , "dnsext@ietf.org" Subject: [Int-area] Call for the adoption of draft-rafiee-intarea-CGA-TSIG X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:18:45 -0000 --_000_EA738325B0580041A50A364F5F76B68924EB86C58A8MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I am presenting this document for adoption in either the intarea wg or the = dnsext wg or dnsop wg. I believe that I have considered all the comments th= at I received and incorporated what was applicable into this draft thus mak= ing it a much improved draft. I also read most of the RFCs dealing with SSH= and its use in DNS that Dave suggested. Even though you say that CGA is co= mplex, I proved in my draft, based on the experimental results, that it can= be generated less than 600 milliseconds. SSH also has its own complexity.= As you know, SSH uses different ports, and so, one needs to integrate SSH = with the current DNS implementations in order to have the authentication ac= cepted using port 22. It is for this reason that I do not believe that the = use of SSH is a good solution for the current problem, i.e., secure authent= ication in NDP and SEND enabled networks. My solution only involves the use of the same cached value available in the= node. I have implemented this solution and the implementation of CGA-TSIG = won the first place prize at the 5th IPv6 International Contest as a soluti= on for securing DNS against spoofing attacks. Here is a summary of what is being proffered: - Using the cached value, available in a node, for authentication purposes = for o A client to authenticate a resolver o A DNS server to authenticate another DNS server or a client who wants to = update its resource records on that server. - This approach is applicable in all networks using SEND to secure them - The implementation of this approach is now available for a Windows client= (that I will extend to Linux clients) and for PowerDNS as a server. For th= e client, it is easily installed. A user, with little computer experience, = can install it as he just needs to click on the "NEXT" button. But for Pow= erDNS, as the powerDNS has its own configuration, it is equally as easy. - Analysis of the data from our many experiments shows that the CGA genera= tion, using a sec value 1, which provides enough security for the network, = is less than 600 milliseconds. Finally, the purpose of this draft is to demonstrate how to minimize human = intervention, as much as possible, in performing the update process and res= olving a query . When, in a network ,a good node (a legitimate node) goes b= ad, because of a virus or an attacker takes control of one of the legitimat= e nodes in a network, CGA-TSIG will prevent spoofing attacks against this D= NS server. If there are any questions with regard to this draft, feel free to ask me = for clarification. Finally, do not forget to reply with +1 if you would like to support this s= olution. http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-01 Thank you, Hosnieh --_000_EA738325B0580041A50A364F5F76B68924EB86C58A8MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I am presenting this document for adopti= on in either the intarea wg or the dnsext wg or dnsop wg. I believe that I = have considered all the comments that I received and incorporated what was = applicable into this draft thus making it a much improved draft. I also rea= d most of the RFCs dealing with SSH and its use in DNS that Dave suggested.= Even though you say that CGA is complex, I proved in my draft, based on th= e experimental results, that it can be generated less than 600 milliseconds= .  SSH also has its own complexity. As you know, SSH uses different po= rts, and so, one needs to integrate SSH with the current DNS implementation= s in order to have the authentication accepted using port 22. It is for thi= s reason that I do not believe that the use of SSH is a good solution for t= he current problem, i.e., secure authentication in NDP and SEND enabled net= works.

My solution only involve= s the use of the same cached value available in the node. I have implemente= d this solution and the implementation of CGA-TSIG won the first place priz= e at the 5th IPv6 International Contest as a solution for securi= ng DNS against spoofing attacks.

Here is a summary of what is being proffered:

- Using the cached value, available in a node, for authentication= purposes for

o <= span style=3D'font-size:12.0pt;font-family:"Arial","sans-serif"'>A client t= o authenticate a resolver

A DNS server to authenticate another DNS server or a client who wants t= o update its resource records on that server.

- This approach is applicable in all networks using SEND to secure= them

- The implementation of this ap= proach is now available for a Windows client (that I will extend to Linux c= lients) and for PowerDNS as a server. For the client, it is easily installe= d. A user, with little computer experience, can install it as he just needs= to click on the  “NEXT” button. But for PowerDNS, as the = powerDNS has its own configuration, it is equally as easy.

-  Analysis of the data from our many experiment= s shows that the CGA generation, using a sec value 1, which provides enough= security for the network, is less than 600 milliseconds.

Finally, the purpose of this d= raft is to demonstrate how to minimize human intervention, as much as possi= ble, in performing the update process and resolving a query . When, in a ne= twork ,a good node (a legitimate node) goes bad, because of a virus or an a= ttacker takes control of one of the legitimate nodes in a network, CGA-TSIG= will prevent spoofing attacks against this DNS server.

If there are any  questions = with regard to this draft, feel free to ask me for clarification.

Finally, do not forget = to reply with +1 if you would like to support this solution.

http://tools.ietf.org/html/draf= t-rafiee-intarea-cga-tsig-01

Thank you,

Hosnieh

&n= bsp;

= --_000_EA738325B0580041A50A364F5F76B68924EB86C58A8MXMA1Rhpiuni_-- From suresh.krishnan@ericsson.com Tue Dec 18 04:48:26 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E7A21F845D for ; Tue, 18 Dec 2012 04:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZw-0ss9OVwO for ; Tue, 18 Dec 2012 04:48:26 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 43CDB21F889C for ; Tue, 18 Dec 2012 04:48:26 -0800 (PST) Received: from EUSAAHC007.ericsson.se ([147.117.188.93]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qBICxiaR010982; Tue, 18 Dec 2012 06:59:45 -0600 Received: from eusaamw0711.eamcs.ericsson.se (147.117.20.178) by EUSAAHC007.ericsson.se (147.117.188.93) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 18 Dec 2012 07:48:21 -0500 Received: from [164.48.125.54] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 18 Dec 2012 07:48:21 -0500 Message-ID: <50D0657B.8090302@ericsson.com> Date: Tue, 18 Dec 2012 07:45:47 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Internet Area X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Julien Laganier , Ralph Droms Subject: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 12:48:27 -0000 Hi all, This draft has been presented at intarea face to face meetings and has received a bit of discussion. It has been difficult to gauge whether the wg is interested in this work or not. This call is being initiated to determine whether there is WG consensus towards adoption of draft-carpenter-flow-label-balancing-02 as an intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2013-01-04. Regards Suresh & Julien From wesley.george@twcable.com Wed Dec 19 09:25:44 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1706221F87A6 for ; Wed, 19 Dec 2012 09:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sovO3hXrIdKU for ; Wed, 19 Dec 2012 09:25:43 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 05A3421F8488 for ; Wed, 19 Dec 2012 09:25:40 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,318,1355115600"; d="scan'208";a="803322" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 19 Dec 2012 12:25:30 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 19 Dec 2012 12:25:36 -0500 From: "George, Wes" To: Suresh Krishnan , "int-area@ietf.org" Date: Wed, 19 Dec 2012 12:25:44 -0500 Thread-Topic: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02 Thread-Index: Ac3dHf40hVUpz2MRQHGo81WmHgpsAQA79Cjw Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033A3B3F57@PRVPEXVS15.corp.twcable.com> References: <50D0657B.8090302@ericsson.com> In-Reply-To: <50D0657B.8090302@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:25:44 -0000 support Thanks, Wes George > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Suresh Krishnan > Sent: Tuesday, December 18, 2012 7:46 AM > To: Internet Area > Cc: Julien Laganier; Ralph Droms > Subject: [Int-area] Call for adoption of draft-carpenter-flow-label- > balancing-02 > > Hi all, > This draft has been presented at intarea face to face meetings and has > received a bit of discussion. It has been difficult to gauge whether the > wg is interested in this work or not. This call is being initiated to > determine whether there is WG consensus towards adoption of > draft-carpenter-flow-label-balancing-02 as an intarea WG draft. Please > state whether or not you're in favor of the adoption by replying to this > email. If you are not in favor, please also state your objections in > your response. This adoption call will complete on 2013-01-04. > > Regards > Suresh & Julien > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From brandon.williams@akamai.com Thu Dec 20 09:20:04 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E24021F8A58 for ; Thu, 20 Dec 2012 09:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3ARYF8lteFx for ; Thu, 20 Dec 2012 09:20:03 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 77A7921F8A57 for ; Thu, 20 Dec 2012 09:20:03 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6F808CF0E8 for ; Thu, 20 Dec 2012 17:20:02 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id 5D4D8CF0DC for ; Thu, 20 Dec 2012 17:20:02 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 47BD21FF9 for ; Thu, 20 Dec 2012 17:20:02 +0000 (GMT) Message-ID: <50D348C1.1080109@akamai.com> Date: Thu, 20 Dec 2012 12:20:01 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "int-area@ietf.org" References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> In-Reply-To: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:20:04 -0000 Dear all, A new version of this draft has been submitted that attempts to lay out a more clear argument for the use of both TCP and IP options, with references to other efforts in the same arena. Comments are welcome. Cheers, --Brandon -------- Original Message -------- Subject: New Version Notification for draft-williams-overlaypath-ip-tcp-rfc-03.txt Date: Thu, 20 Dec 2012 11:55:33 -0500 From: internet-drafts@ietf.org To: Williams, Brandon A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-03.txt has been successfully submitted by Brandon Williams and posted to the IETF repository. Filename: draft-williams-overlaypath-ip-tcp-rfc Revision: 03 Title: Overlay Path Option for IP and TCP Creation date: 2012-12-20 WG ID: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-williams-overlaypath-ip-tcp-rfc-03.txt Status: http://datatracker.ietf.org/doc/draft-williams-overlaypath-ip-tcp-rfc Htmlized: http://tools.ietf.org/html/draft-williams-overlaypath-ip-tcp-rfc-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-williams-overlaypath-ip-tcp-rfc-03 Abstract: Data transport through overlay networks often uses either connection termination or network address translation (NAT) in such a way that the public IP addresses of the true endpoint machines involved in the data transport are invisible to each other. This document describes IPv4, IPv6, and TCP options for communicating this information from the overlay network to the endpoint machines. The IETF Secretariat From wes@mti-systems.com Thu Dec 20 11:16:24 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1FF21F8A67 for ; Thu, 20 Dec 2012 11:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59DVazy6BqhX for ; Thu, 20 Dec 2012 11:16:24 -0800 (PST) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 151C121F8A64 for ; Thu, 20 Dec 2012 11:16:24 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qBKJGN32017578 for ; Thu, 20 Dec 2012 14:16:23 -0500 Received: (qmail 15342 invoked by uid 0); 20 Dec 2012 19:16:23 -0000 Received: from unknown (HELO ?192.168.1.145?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 20 Dec 2012 19:16:23 -0000 Message-ID: <50D363FC.9010906@mti-systems.com> Date: Thu, 20 Dec 2012 14:16:12 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brandon Williams References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> In-Reply-To: <50D348FE.3060807@akamai.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, "int-area@ietf.org" Subject: Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 19:16:24 -0000 On 12/20/2012 12:21 PM, Brandon Williams wrote: > Dear all, > > A new version of this draft has been submitted that attempts to lay out > a more clear argument for the use of both TCP and IP options, with > references to other efforts in the same arena. > > Comments are welcome. (note, I've cross-posted to INTAREA and TCPM, since similar announcements went to each list) Hi Brandon, *many* thanks for writing this; it does help me (at least) to understand what you're doing with this option. As I now understand it, instead of a tunneling approach that would normally be applied for building overlay networks, this approach pushes and pops IP addresses from the protocol options fields. Can you discuss why normal tunneling protocols aren't used to build the overlay? Since those are easily and widely available, I wonder why they aren't used and why something more elaborate, fragile, and not as compatible with the Internet architecture is really needed or felt to be a good idea? I understand that it basically *works* ... but just am not seeing how it makes sense? -- Wes Eddy MTI Systems From brandon.williams@akamai.com Thu Dec 20 12:49:30 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36ED421F8A8F; Thu, 20 Dec 2012 12:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnmY5Wh4K06o; Thu, 20 Dec 2012 12:49:29 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8A221F8A8B; Thu, 20 Dec 2012 12:49:29 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BFCDDCF6CC; Thu, 20 Dec 2012 20:49:28 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id A9F44CF67C; Thu, 20 Dec 2012 20:49:28 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 877F22011; Thu, 20 Dec 2012 20:49:28 +0000 (GMT) Message-ID: <50D379D7.609@akamai.com> Date: Thu, 20 Dec 2012 15:49:27 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Wesley Eddy References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> In-Reply-To: <50D363FC.9010906@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "int-area@ietf.org" , "Williams, Brandon" Subject: Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 20:49:30 -0000 Hi Wes, Thanks for your comments. It looks like I might have managed to make the use of the proposed option less clear, instead of more clear. Or maybe I'm misunderstanding the point that you're making. The mechanics of our system are tunnel-based, as with most overlay architectures that I've looked at. The tunneling starts at an overlay ingress machine close to one of the endpoints (i.e. the client or server) and ends at an overlay egress machine close to the other endpoint. Since the ingress and egress are on the public internet, the overlay does not extend all the way onto the endpoints' LANs. This means that standard internet routing cannot be used to drive the connections into the overlay. Instead, NAT is used on both sides of the overlay, which results in the server having no way to reliably identify the client. The proposed options are not intended to be used as part of the mechanics of the overlay. The overlay is fully functional without the options. Instead, the options are intended to provide the client's connection identifying information to the server for use in load-balancing, diagnostics, etc. Does this clarify things? further muddy the waters? or simply indicate that I missed your point? --Brandon PS: Thanks for cross-posting your comments. I should have done that to begin with. I primarily posted to TCPM for informational purposes, since the TCPM has not shown much interest in this or similar drafts in the past. The INTAREA list has been more actively engaged in discussion related to client identification. Still, if I was going to cross-post, I should have done it with a single thread. On 12/20/2012 02:16 PM, Wesley Eddy wrote: > On 12/20/2012 12:21 PM, Brandon Williams wrote: >> Dear all, >> >> A new version of this draft has been submitted that attempts to lay out >> a more clear argument for the use of both TCP and IP options, with >> references to other efforts in the same arena. >> >> Comments are welcome. > > (note, I've cross-posted to INTAREA and TCPM, since similar > announcements went to each list) > > Hi Brandon, *many* thanks for writing this; it does help me (at least) > to understand what you're doing with this option. > > As I now understand it, instead of a tunneling approach that would > normally be applied for building overlay networks, this approach > pushes and pops IP addresses from the protocol options fields. > > Can you discuss why normal tunneling protocols aren't used to build > the overlay? > > Since those are easily and widely available, I wonder why they aren't > used and why something more elaborate, fragile, and not as compatible > with the Internet architecture is really needed or felt to be a good > idea? I understand that it basically *works* ... but just am not > seeing how it makes sense? > -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From wes@mti-systems.com Thu Dec 20 13:05:15 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F62221F899B for ; Thu, 20 Dec 2012 13:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r04vgvcpvakU for ; Thu, 20 Dec 2012 13:05:12 -0800 (PST) Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8B77121F8AA4 for ; Thu, 20 Dec 2012 13:05:12 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qBKL58ZE014705 for ; Thu, 20 Dec 2012 16:05:08 -0500 Received: (qmail 24419 invoked by uid 0); 20 Dec 2012 21:05:08 -0000 Received: from unknown (HELO ?192.168.1.145?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 20 Dec 2012 21:05:08 -0000 Message-ID: <50D37D79.20109@mti-systems.com> Date: Thu, 20 Dec 2012 16:04:57 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brandon Williams References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> <50D379D7.609@akamai.com> In-Reply-To: <50D379D7.609@akamai.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "int-area@ietf.org" , "Williams, Brandon" Subject: Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 21:05:15 -0000 On 12/20/2012 3:49 PM, Brandon Williams wrote: > Hi Wes, > > Thanks for your comments. > > It looks like I might have managed to make the use of the proposed > option less clear, instead of more clear. Or maybe I'm misunderstanding > the point that you're making. > > The mechanics of our system are tunnel-based, as with most overlay > architectures that I've looked at. The tunneling starts at an overlay > ingress machine close to one of the endpoints (i.e. the client or > server) and ends at an overlay egress machine close to the other > endpoint. Since the ingress and egress are on the public internet, the > overlay does not extend all the way onto the endpoints' LANs. This means > that standard internet routing cannot be used to drive the connections > into the overlay. Instead, NAT is used on both sides of the overlay, > which results in the server having no way to reliably identify the client. > > The proposed options are not intended to be used as part of the > mechanics of the overlay. The overlay is fully functional without the > options. Instead, the options are intended to provide the client's > connection identifying information to the server for use in > load-balancing, diagnostics, etc. > Ah, so are there additional devices beyond what's shown in your Figure 1? I ask because if the overlay ingress and egress are simple tunnel endpoints, then the endpoint addresses would be totally visible to one another. Your figure 1 is: +------------------------------------+ | | | INTERNET | | | +-----------+ | +------------+ | | HOST_1 |-----| OVRLY_IN_1 |-----------+ | +-----------+ | +------------+ | | | | | +-----------+ | +------------+ +-----------+ | +--------+ | HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER | +-----------+ | +------------+ +-----------+ | +--------+ | | | +-----------+ | +------------+ | | | HOST_3 |-----| OVRLY_IN_3 |-----------+ | +-----------+ | +------------+ | | | +------------------------------------+ Figure 1 If there were tunnels between the OVRLY_IN and OVERLY_OUT boxes, then the inner IP headers would have the HOST_X and SERVER addresses, and the outer ones in the tunnel would have the overlay headers. Since the inner packets would be delivered ultimately after egressing the tunnels, the HOST_X addresses are totally visible to the server, and vice versa. Your document shows instead: --------------------------------------------------------------------- ip hdr contains: ip hdr contains: SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER dst = overlay1 dst = receiver --------------------------------------------------------------------- So, this is not really showing tunnels to me ... this is rewriting (NAT) of the destination address. Or am I misunderstanding? -- Wes Eddy MTI Systems From brandon.williams@akamai.com Thu Dec 20 14:04:50 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC7221F8967; Thu, 20 Dec 2012 14:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z23TcqwetRpV; Thu, 20 Dec 2012 14:04:50 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 06F6E21F8824; Thu, 20 Dec 2012 14:04:50 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 708B4CF73D; Thu, 20 Dec 2012 22:04:49 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id 5CE50CF6EB; Thu, 20 Dec 2012 22:04:49 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 4D290FE085; Thu, 20 Dec 2012 22:04:49 +0000 (GMT) Message-ID: <50D38B80.7080409@akamai.com> Date: Thu, 20 Dec 2012 17:04:48 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Wesley Eddy References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> <50D379D7.609@akamai.com> <50D37D79.20109@mti-systems.com> In-Reply-To: <50D37D79.20109@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 22:04:51 -0000 On 12/20/2012 04:04 PM, Wesley Eddy wrote: > On 12/20/2012 3:49 PM, Brandon Williams wrote: >> Hi Wes, >> >> Thanks for your comments. >> >> It looks like I might have managed to make the use of the proposed >> option less clear, instead of more clear. Or maybe I'm misunderstanding >> the point that you're making. >> >> The mechanics of our system are tunnel-based, as with most overlay >> architectures that I've looked at. The tunneling starts at an overlay >> ingress machine close to one of the endpoints (i.e. the client or >> server) and ends at an overlay egress machine close to the other >> endpoint. Since the ingress and egress are on the public internet, the >> overlay does not extend all the way onto the endpoints' LANs. This means >> that standard internet routing cannot be used to drive the connections >> into the overlay. Instead, NAT is used on both sides of the overlay, >> which results in the server having no way to reliably identify the client. >> >> The proposed options are not intended to be used as part of the >> mechanics of the overlay. The overlay is fully functional without the >> options. Instead, the options are intended to provide the client's >> connection identifying information to the server for use in >> load-balancing, diagnostics, etc. >> > > Ah, so are there additional devices beyond what's shown in your Figure > 1? I ask because if the overlay ingress and egress are simple tunnel > endpoints, then the endpoint addresses would be totally visible to one > another. Yes. There are additional devices between the HOST and OVRLY_IN, and also between OVRLY_OUT and SERVER, but those devices are just the internet's standard routing infrastructure. There are also potential intermediate devices between OVRLY_IN and OVRLY_OUT that can be used for optimized routing between the overlay's ingress and egress. > > Your figure 1 is: > > +------------------------------------+ > | | > | INTERNET | > | | > +-----------+ | +------------+ | > | HOST_1 |-----| OVRLY_IN_1 |-----------+ | > +-----------+ | +------------+ | | > | | | > +-----------+ | +------------+ +-----------+ | +--------+ > | HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER | > +-----------+ | +------------+ +-----------+ | +--------+ > | | | > +-----------+ | +------------+ | | > | HOST_3 |-----| OVRLY_IN_3 |-----------+ | > +-----------+ | +------------+ | > | | > +------------------------------------+ > > Figure 1 > > If there were tunnels between the OVRLY_IN and OVERLY_OUT boxes, > then the inner IP headers would have the HOST_X and SERVER > addresses, and the outer ones in the tunnel would have the > overlay headers. Since the inner packets would be delivered > ultimately after egressing the tunnels, the HOST_X addresses > are totally visible to the server, and vice versa. There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and the inner IP headers will typically use either the client-side addresses or the server-side addresses. However, neither OVRLY_IN nor OVRLY_OUT can be assumed to be reliably in-path between HOST and SERVER, which means that internet routing cannot be relied upon to cause packets to arrive at the overlay ingress. Instead, HOST_1 must directly address OVRLY_IN_1 in order to send its packets into the tunnel, and SERVER must directly address OVRLY_OUT in order to send the return traffic into the tunnel. > > Your document shows instead: > > --------------------------------------------------------------------- > > ip hdr contains: ip hdr contains: > SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER > dst = overlay1 dst = receiver > > --------------------------------------------------------------------- > > So, this is not really showing tunnels to me ... this is rewriting > (NAT) of the destination address. > As noted above, the use of tunnels and NAT in this case are not mutually exclusive. NAT is used to allow the overlay ingress to intercept packets, which are then tunneled to the overlay egress, where NAT is used to deliver the packets to the receiver and ensure that return traffic also uses the overlay. --Brandon PS: Sorry to double send this to you Wes. It was bounced by the ietf lists the first time. -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From leo.liubing@huawei.com Thu Dec 20 17:39:02 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAB521F895C for ; Thu, 20 Dec 2012 17:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA-25wRL0GYx for ; Thu, 20 Dec 2012 17:39:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7781E21F8953 for ; Thu, 20 Dec 2012 17:39:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR74135; Fri, 21 Dec 2012 01:38:59 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 01:38:42 +0000 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 01:38:57 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Fri, 21 Dec 2012 09:38:50 +0800 From: "Liubing (Leo)" To: Suresh Krishnan , Internet Area Thread-Topic: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02 Thread-Index: AQHN3R3+qSGmxN/ydUC0H5ymxS8MR5gievnA Date: Fri, 21 Dec 2012 01:38:48 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453CCFF776@szxeml509-mbx> References: <50D0657B.8090302@ericsson.com> In-Reply-To: <50D0657B.8090302@ericsson.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Julien Laganier , Ralph Droms Subject: Re: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 01:39:02 -0000 I'm in favor of it. It's a good use case of flow label for L3/4 load balanc= ing. Thanks B.R. Bing > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Suresh Krishnan > Sent: Tuesday, December 18, 2012 8:46 PM > To: Internet Area > Cc: Julien Laganier; Ralph Droms > Subject: [Int-area] Call for adoption of > draft-carpenter-flow-label-balancing-02 >=20 > Hi all, > This draft has been presented at intarea face to face meetings and has > received a bit of discussion. It has been difficult to gauge whether the > wg is interested in this work or not. This call is being initiated to > determine whether there is WG consensus towards adoption of > draft-carpenter-flow-label-balancing-02 as an intarea WG draft. Please > state whether or not you're in favor of the adoption by replying to this > email. If you are not in favor, please also state your objections in > your response. This adoption call will complete on 2013-01-04. >=20 > Regards > Suresh & Julien >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From joelja@bogus.com Thu Dec 20 18:38:36 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B072A21F888F for ; Thu, 20 Dec 2012 18:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJTTPuGOUI9g for ; Thu, 20 Dec 2012 18:38:35 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D2F8C21F884B for ; Thu, 20 Dec 2012 18:38:35 -0800 (PST) Received: from joels-MacBook-Air.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qBL2bbdn080645 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 21 Dec 2012 02:37:38 GMT (envelope-from joelja@bogus.com) Message-ID: <50D3CB6C.9040708@bogus.com> Date: Thu, 20 Dec 2012 18:37:32 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: "Liubing (Leo)" References: <50D0657B.8090302@ericsson.com> <8AE0F17B87264D4CAC7DE0AA6C406F453CCFF776@szxeml509-mbx> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453CCFF776@szxeml509-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 21 Dec 2012 02:37:38 +0000 (UTC) Cc: Julien Laganier , Internet Area , Ralph Droms Subject: Re: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 02:38:36 -0000 On 12/20/12 5:38 PM, Liubing (Leo) wrote: > I'm in favor of it. It's a good use case of flow label for L3/4 load balancing RFC 6437 did not go nearly far enough in my opinion make the flow label suitable for this application. The fact of the matter is if I attempted to use the flow label today as part of a load balancing scheme it would provide zero additional entropy, and what's more I still have to look at the upper layer header. Furthermore the document proposes the use of flow label across muliple flows as a common "session key" across multiple flows which I personally feel is inconsistent with the notion of a flow, is certainly embedding upper layer (notionally above the l4 header) session information in the layer-3 header and suffers from the exposures described in section 6 of 6437 and making no attempt to ameliorate them. > Thanks > > B.R. > Bing > >> -----Original Message----- >> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On >> Behalf Of Suresh Krishnan >> Sent: Tuesday, December 18, 2012 8:46 PM >> To: Internet Area >> Cc: Julien Laganier; Ralph Droms >> Subject: [Int-area] Call for adoption of >> draft-carpenter-flow-label-balancing-02 >> >> Hi all, >> This draft has been presented at intarea face to face meetings and has >> received a bit of discussion. It has been difficult to gauge whether the >> wg is interested in this work or not. This call is being initiated to >> determine whether there is WG consensus towards adoption of >> draft-carpenter-flow-label-balancing-02 as an intarea WG draft. Please >> state whether or not you're in favor of the adoption by replying to this >> email. If you are not in favor, please also state your objections in >> your response. This adoption call will complete on 2013-01-04. >> >> Regards >> Suresh & Julien >> >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From brian.e.carpenter@gmail.com Fri Dec 21 00:30:38 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B9421F8511 for ; Fri, 21 Dec 2012 00:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.603 X-Spam-Level: X-Spam-Status: No, score=-101.603 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBVJpCOdrE1G for ; Fri, 21 Dec 2012 00:30:37 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5643221F84D5 for ; Fri, 21 Dec 2012 00:30:37 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id r1so2117865wey.1 for ; Fri, 21 Dec 2012 00:30:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wPWn4Bz/80Kql9vGPURAZ+EZcBgLANaWKlMcpDR9Fyc=; b=tL9yOQ8BZjqSP7IPKBlfe4a5Dn9tzZddcdO2xuXrsuVt20W8auvg47wEJo3vvjtYGm UiIECzSyDlzV1zdIIRC34UpLb8pOkC16MSUw+FqZyt2uq6rCh2byz4bvrUhTpwyOT/+X BN9nJrpMO7jHpeN6jaGThy+Iq73kNFw9PD1V7eRl4wc20ik/RWY6nP40GitgRZrbAAFE XbGxUzllU9wPCyE5fyvGKM3Dr6LaApKzvpcI7XyXDZHKDrAcvQUMj1EdgGphUqADETTm 5Y9yHrj8tCA1tegHAFZH+cHMZwghz4lLnIjbgbnIX3aQrXLyh33AmUytSQPzVrUgAEeY +eoA== X-Received: by 10.180.100.163 with SMTP id ez3mr14076541wib.24.1356078636335; Fri, 21 Dec 2012 00:30:36 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-97.as13285.net. [2.102.219.97]) by mx.google.com with ESMTPS id bd7sm17136181wib.8.2012.12.21.00.30.34 (version=SSLv3 cipher=OTHER); Fri, 21 Dec 2012 00:30:35 -0800 (PST) Message-ID: <50D41E38.5060805@gmail.com> Date: Fri, 21 Dec 2012 08:30:48 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <50D0657B.8090302@ericsson.com> <8AE0F17B87264D4CAC7DE0AA6C406F453CCFF776@szxeml509-mbx> <50D3CB6C.9040708@bogus.com> In-Reply-To: <50D3CB6C.9040708@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Julien Laganier , Internet Area , Ralph Droms Subject: Re: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 08:30:38 -0000 Joel, On 21/12/2012 02:37, joel jaeggli wrote: > On 12/20/12 5:38 PM, Liubing (Leo) wrote: >> I'm in favor of it. It's a good use case of flow label for L3/4 load >> balancing > RFC 6437 did not go nearly far enough in my opinion make the flow label > suitable for this application. > > The fact of the matter is if I attempted to use the flow label today as > part of a load balancing scheme it would provide zero additional > entropy, and what's more I still have to look at the upper layer header. Have you read the latest version? That is discussed. The point is to provide a path to fixing that problem. > Furthermore the document proposes the use of flow label across muliple > flows as a common "session key" across multiple flows No, you definitely haven't read the latest version. It absolutely does not propose that. If you want to discuss that point, please comment on draft-tarreau-extend-flow-label-balancing, which is *not* proposed for adoption at this time. Brian which I personally > feel is inconsistent with the notion of a flow, is certainly embedding > upper layer (notionally above the l4 header) session information in the > layer-3 header and suffers from the exposures described in section 6 of > 6437 and making no attempt to ameliorate them. > >> Thanks >> >> B.R. >> Bing >> >>> -----Original Message----- >>> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On >>> Behalf Of Suresh Krishnan >>> Sent: Tuesday, December 18, 2012 8:46 PM >>> To: Internet Area >>> Cc: Julien Laganier; Ralph Droms >>> Subject: [Int-area] Call for adoption of >>> draft-carpenter-flow-label-balancing-02 >>> >>> Hi all, >>> This draft has been presented at intarea face to face meetings and >>> has >>> received a bit of discussion. It has been difficult to gauge whether the >>> wg is interested in this work or not. This call is being initiated to >>> determine whether there is WG consensus towards adoption of >>> draft-carpenter-flow-label-balancing-02 as an intarea WG draft. Please >>> state whether or not you're in favor of the adoption by replying to this >>> email. If you are not in favor, please also state your objections in >>> your response. This adoption call will complete on 2013-01-04. >>> >>> Regards >>> Suresh & Julien >>> >>> >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From michael.scharf@alcatel-lucent.com Fri Dec 21 05:35:05 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E45521F8976; Fri, 21 Dec 2012 05:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.866 X-Spam-Level: X-Spam-Status: No, score=-9.866 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pww66VX2WeBG; Fri, 21 Dec 2012 05:35:04 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 34DDB21F8964; Fri, 21 Dec 2012 05:35:04 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBLDYtYC023064 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 21 Dec 2012 14:34:59 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 21 Dec 2012 14:34:44 +0100 From: "Scharf, Michael (Michael)" To: Brandon Williams , Wesley Eddy Date: Fri, 21 Dec 2012 14:34:43 +0100 Thread-Topic: [tcpm] draft-williams-overlaypath-ip-tcp-rfc Thread-Index: Ac3e/hG6V/PaidZlTHmX2VSG2wj0OAAfDMSQ Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE17@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> <50D379D7.609@akamai.com> <50D37D79.20109@mti-systems.com> <50D38B80.7080409@akamai.com> In-Reply-To: <50D38B80.7080409@akamai.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 X-Mailman-Approved-At: Fri, 21 Dec 2012 08:12:42 -0800 Cc: "tcpm@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 13:35:05 -0000 Brandon,=20 > > If there were tunnels between the OVRLY_IN and OVERLY_OUT=20 > boxes, then=20 > > the inner IP headers would have the HOST_X and SERVER=20 > addresses, and=20 > > the outer ones in the tunnel would have the overlay headers. Since=20 > > the inner packets would be delivered ultimately after egressing the=20 > > tunnels, the HOST_X addresses are totally visible to the=20 > server, and=20 > > vice versa. >=20 > There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and=20 > the inner IP headers will typically use either the=20 > client-side addresses or the server-side addresses. However,=20 > neither OVRLY_IN nor OVRLY_OUT can be assumed to be reliably=20 > in-path between HOST and SERVER, which means that internet=20 > routing cannot be relied upon to cause packets to arrive at=20 > the overlay ingress. Instead, HOST_1 must directly address=20 > OVRLY_IN_1 in order to send its packets into the tunnel, and=20 > SERVER must directly address OVRLY_OUT in order to send the=20 > return traffic into the tunnel. Thanks for this explanation - this indeed helps to understand the architect= ure. But actually I still don't fully understand the motivation of bypassin= g Internet routing this way. As a non-expert on routing, it indeed looks to= me like reinventing source routing - but this is outside my core expertise= . Regarding TCPM's business: If I correctly understand the approach, OVRLY_IN= will "transparently" add and remove TCP options. This is kind of dangerous= from an end-to-end perspective... Sorry if that has been answered before, = but I really wonder what to do if OVRLY_IN can't add this option, either be= cause of lack of TCP option space, or because the path MTU is exceeded by t= he resulting IP packet. (In fact, I think that this problem does not apply = to TCP options only.) Unless I miss something, the latter case could become much more relevant so= on: TCPM currently works on the fast-open scheme that adds data to SYNs. Wi= th that, I think it is possible that all data packets from a sender to a re= ceiver are either full sized or large enough that the proposed option does = not fit in. Given that this option can include full-sized IPv6 addresses, t= his likelihood is much larger than for other existing TCP option, right? In some cases, I believe that the proposed TCP option cannot be added in th= e overlay without either IP fragmentation, which is unlikely to be a good i= dea with NATs, or TCP segment splitting, which probably can cause harm as w= ell. For instance, what would OVRLY_IN do if it receives an IP packet with = a TCP SYN segment that already sums up to 1500 byte? And, to make the scena= rio more nasty, if the same applies to the first data segments as well? Thanks Michael From brandon.williams@akamai.com Fri Dec 21 08:31:49 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C473E21F86C2; Fri, 21 Dec 2012 08:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWS3d0FS2Am0; Fri, 21 Dec 2012 08:31:48 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB4421F86F6; Fri, 21 Dec 2012 08:31:46 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 209CE27F30; Fri, 21 Dec 2012 16:31:46 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 0450027F67; Fri, 21 Dec 2012 16:31:46 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id E2E4C2011; Fri, 21 Dec 2012 16:31:45 +0000 (GMT) Message-ID: <50D48EF1.2030107@akamai.com> Date: Fri, 21 Dec 2012 11:31:45 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> <50D379D7.609@akamai.com> <50D37D79.20109@mti-systems.com> <50D38B80.7080409@akamai.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE17@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE17@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 16:31:49 -0000 Hi Michael, Thanks for your comments. Your are correct that the option could be problematic if added to a full-sized packet, or even a nearly full one. I can see that the document should have some discussion of this issue. In a case like ours, where the overlay network uses tunneling, transparently adding the option is not a critical problem to be solved. It is already the case that the overlay entry point must advertise a reduced MSS in order to accommodate the tunnel overhead. The amount of space consumed by the option will always be smaller than the tunnel overhead, and the option can be added at OVRLY_OUT, so the two are not additive. That said, I can see that an overlay network that does not use tunnels internally, or one that in fact does apply the option on OVRLY_IN, would have a bigger problem, though. The issue of the proposed fast-open scheme is one that we have not considered, but I don't think it adds any problems for the TCP option that aren't already a problem for tunneled connectivity in general. I will have to spend some time with that proposal and think about how they interrelate. --Brandon On 12/21/2012 08:34 AM, Scharf, Michael (Michael) wrote: > Brandon, > >>> If there were tunnels between the OVRLY_IN and OVERLY_OUT >> boxes, then >>> the inner IP headers would have the HOST_X and SERVER >> addresses, and >>> the outer ones in the tunnel would have the overlay headers. Since >>> the inner packets would be delivered ultimately after egressing the >>> tunnels, the HOST_X addresses are totally visible to the >> server, and >>> vice versa. >> >> There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and >> the inner IP headers will typically use either the >> client-side addresses or the server-side addresses. However, >> neither OVRLY_IN nor OVRLY_OUT can be assumed to be reliably >> in-path between HOST and SERVER, which means that internet >> routing cannot be relied upon to cause packets to arrive at >> the overlay ingress. Instead, HOST_1 must directly address >> OVRLY_IN_1 in order to send its packets into the tunnel, and >> SERVER must directly address OVRLY_OUT in order to send the >> return traffic into the tunnel. > > Thanks for this explanation - this indeed helps to understand the architecture. But actually I still don't fully understand the motivation of bypassing Internet routing this way. As a non-expert on routing, it indeed looks to me like reinventing source routing - but this is outside my core expertise. > > Regarding TCPM's business: If I correctly understand the approach, OVRLY_IN will "transparently" add and remove TCP options. This is kind of dangerous from an end-to-end perspective... Sorry if that has been answered before, but I really wonder what to do if OVRLY_IN can't add this option, either because of lack of TCP option space, or because the path MTU is exceeded by the resulting IP packet. (In fact, I think that this problem does not apply to TCP options only.) > > Unless I miss something, the latter case could become much more relevant soon: TCPM currently works on the fast-open scheme that adds data to SYNs. With that, I think it is possible that all data packets from a sender to a receiver are either full sized or large enough that the proposed option does not fit in. Given that this option can include full-sized IPv6 addresses, this likelihood is much larger than for other existing TCP option, right? > > In some cases, I believe that the proposed TCP option cannot be added in the overlay without either IP fragmentation, which is unlikely to be a good idea with NATs, or TCP segment splitting, which probably can cause harm as well. For instance, what would OVRLY_IN do if it receives an IP packet with a TCP SYN segment that already sums up to 1500 byte? And, to make the scenario more nasty, if the same applies to the first data segments as well? > > Thanks > > Michael > -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From michael.scharf@alcatel-lucent.com Fri Dec 21 11:14:33 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAD221F8648; Fri, 21 Dec 2012 11:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.92 X-Spam-Level: X-Spam-Status: No, score=-9.92 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UuRycucNMXe; Fri, 21 Dec 2012 11:14:32 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 588C821F85E2; Fri, 21 Dec 2012 11:14:31 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBLJE2lw001889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 21 Dec 2012 20:14:23 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 21 Dec 2012 20:14:12 +0100 From: "Scharf, Michael (Michael)" To: Brandon Williams Date: Fri, 21 Dec 2012 20:14:10 +0100 Thread-Topic: [tcpm] draft-williams-overlaypath-ip-tcp-rfc Thread-Index: Ac3fmK5XK1RjySyESDWH16Dubko7VAAExhEg Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE1E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> <50D379D7.609@akamai.com> <50D37D79.20109@mti-systems.com> <50D38B80.7080409@akamai.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE17@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50D48EF1.2030107@akamai.com> In-Reply-To: <50D48EF1.2030107@akamai.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 19:14:33 -0000 Brandon,=20 > Your are correct that the option could be problematic if=20 > added to a full-sized packet, or even a nearly full one. I=20 > can see that the document should have some discussion of this issue. Yes. > In a case like ours, where the overlay network uses=20 > tunneling, transparently adding the option is not a critical=20 > problem to be solved.=20 > It is already the case that the overlay entry point must=20 > advertise a reduced MSS in order to accommodate the tunnel=20 > overhead. The amount of space consumed by the option will=20 > always be smaller than the tunnel overhead, and the option=20 > can be added at OVRLY_OUT, so the two are not additive. That=20 > said, I can see that an overlay network that does not use=20 > tunnels internally, or one that in fact does apply the option=20 > on OVRLY_IN, would have a bigger problem, though. So, the new TCP option is basically required between OVRLY_OUT and the rece= iver/server, because the relevant information is already somehow transporte= d in the overlay, right? This raises another question (sorry if it is naive): Why can't the overlay = tunnel just be extended to the server? This somehow implies that OVRLY_OUT = would be kind of co-located with the server - obviously, there can be furth= er routers/overlay nodes in between. I am asking this because processing the information contained in the TCP op= tion will require anyway a modified TCP stack in the server, i. e., the ser= ver will not be fully backward compatible if it has to process the proposed= option. But if the TCP/IP stack has to be modified anyway, I could imagine= that one could just add to the server whatever encap/decap is required for= the overlay transport. Then, I have the impression that the proposed TCP o= ption would not be needed at all. I don't want to dig into the overlay design, because this is not really in = scope of TCPM. But if there is a system architecture that does not require = adding TCP options in middleboxes, thus affecting TCP end-to-end semantics,= it would really be important to understand why such an architecture cannot= be used. Thanks Michael =20 > The issue of the proposed fast-open scheme is one that we=20 > have not considered, but I don't think it adds any problems=20 > for the TCP option that aren't already a problem for tunneled=20 > connectivity in general. I will have to spend some time with=20 > that proposal and think about how they interrelate. >=20 > --Brandon >=20 > On 12/21/2012 08:34 AM, Scharf, Michael (Michael) wrote: > > Brandon, > > > >>> If there were tunnels between the OVRLY_IN and OVERLY_OUT > >> boxes, then > >>> the inner IP headers would have the HOST_X and SERVER > >> addresses, and > >>> the outer ones in the tunnel would have the overlay=20 > headers. Since=20 > >>> the inner packets would be delivered ultimately after=20 > egressing the=20 > >>> tunnels, the HOST_X addresses are totally visible to the > >> server, and > >>> vice versa. > >> > >> There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and the=20 > >> inner IP headers will typically use either the client-side=20 > addresses=20 > >> or the server-side addresses. However, neither OVRLY_IN=20 > nor OVRLY_OUT=20 > >> can be assumed to be reliably in-path between HOST and=20 > SERVER, which=20 > >> means that internet routing cannot be relied upon to cause=20 > packets to=20 > >> arrive at the overlay ingress. Instead, HOST_1 must=20 > directly address > >> OVRLY_IN_1 in order to send its packets into the tunnel,=20 > and SERVER=20 > >> must directly address OVRLY_OUT in order to send the=20 > return traffic=20 > >> into the tunnel. > > > > Thanks for this explanation - this indeed helps to=20 > understand the architecture. But actually I still don't fully=20 > understand the motivation of bypassing Internet routing this=20 > way. As a non-expert on routing, it indeed looks to me like=20 > reinventing source routing - but this is outside my core expertise. > > > > Regarding TCPM's business: If I correctly understand the approach,=20 > > OVRLY_IN will "transparently" add and remove TCP options.=20 > This is kind=20 > > of dangerous from an end-to-end perspective... Sorry if=20 > that has been=20 > > answered before, but I really wonder what to do if OVRLY_IN=20 > can't add=20 > > this option, either because of lack of TCP option space, or because=20 > > the path MTU is exceeded by the resulting IP packet. (In=20 > fact, I think=20 > > that this problem does not apply to TCP options only.) > > > > Unless I miss something, the latter case could become much=20 > more relevant soon: TCPM currently works on the fast-open=20 > scheme that adds data to SYNs. With that, I think it is=20 > possible that all data packets from a sender to a receiver=20 > are either full sized or large enough that the proposed=20 > option does not fit in. Given that this option can include=20 > full-sized IPv6 addresses, this likelihood is much larger=20 > than for other existing TCP option, right? > > > > In some cases, I believe that the proposed TCP option=20 > cannot be added in the overlay without either IP=20 > fragmentation, which is unlikely to be a good idea with NATs,=20 > or TCP segment splitting, which probably can cause harm as=20 > well. For instance, what would OVRLY_IN do if it receives an=20 > IP packet with a TCP SYN segment that already sums up to 1500=20 > byte? And, to make the scenario more nasty, if the same=20 > applies to the first data segments as well? > > > > Thanks > > > > Michael > > >=20 > -- > Brandon Williams; Principal Software Engineer Cloud=20 > Engineering; Akamai Technologies Inc. > = From brandon.williams@akamai.com Fri Dec 21 12:07:21 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC4621F84C2; Fri, 21 Dec 2012 12:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Dn9C9WjdsEf; Fri, 21 Dec 2012 12:07:20 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 86BED21F8455; Fri, 21 Dec 2012 12:07:20 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 88481CF8DE; Fri, 21 Dec 2012 20:07:19 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id 75688CF8D3; Fri, 21 Dec 2012 20:07:19 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 629D0FE07A; Fri, 21 Dec 2012 20:07:19 +0000 (GMT) Message-ID: <50D4C177.3010309@akamai.com> Date: Fri, 21 Dec 2012 15:07:19 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20121220165533.11066.52759.idtracker@ietfa.amsl.com> <50D348FE.3060807@akamai.com> <50D363FC.9010906@mti-systems.com> <50D379D7.609@akamai.com> <50D37D79.20109@mti-systems.com> <50D38B80.7080409@akamai.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE17@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50D48EF1.2030107@akamai.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE1E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE1E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "int-area@ietf.org" Subject: Re: [Int-area] [tcpm] draft-williams-overlaypath-ip-tcp-rfc X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 20:07:21 -0000 Michael, Extending the overlay all the way to the application server would mean that existing solutions for load balancing, SSL offload, intrusion detection, diagnostic logging, etc. would not work. In other words, there are many systems in a common enterprise environment that would benefit from more accurate host identification, and all would require changes in order for the mechanism to work. On the other hand, there is existing middleware that can already handle an arbitrary tcp option, using its value for the above listed purposes. So using a TCP option for this purpose is deployable today, but extending the overlay is not. At the same time, use of the option does not carry significant risk of breaking existing connectivity, even in cases where the option is not understood by the TCP stack. Testing has shown that only about 1.7% of the top 100,000 web servers fail to establish connections when the option is included (see draft-abdo-hostid-tcpopt-implementation). This is mostly likely a characteristic of the common TCP stacks in use today, and so probably extends to non-HTTP application servers, too. --Brandon On 12/21/2012 02:14 PM, Scharf, Michael (Michael) wrote: > Brandon, > >> Your are correct that the option could be problematic if >> added to a full-sized packet, or even a nearly full one. I >> can see that the document should have some discussion of this issue. > > Yes. > >> In a case like ours, where the overlay network uses >> tunneling, transparently adding the option is not a critical >> problem to be solved. >> It is already the case that the overlay entry point must >> advertise a reduced MSS in order to accommodate the tunnel >> overhead. The amount of space consumed by the option will >> always be smaller than the tunnel overhead, and the option >> can be added at OVRLY_OUT, so the two are not additive. That >> said, I can see that an overlay network that does not use >> tunnels internally, or one that in fact does apply the option >> on OVRLY_IN, would have a bigger problem, though. > > So, the new TCP option is basically required between OVRLY_OUT and the receiver/server, because the relevant information is already somehow transported in the overlay, right? > > This raises another question (sorry if it is naive): Why can't the overlay tunnel just be extended to the server? This somehow implies that OVRLY_OUT would be kind of co-located with the server - obviously, there can be further routers/overlay nodes in between. > > I am asking this because processing the information contained in the TCP option will require anyway a modified TCP stack in the server, i. e., the server will not be fully backward compatible if it has to process the proposed option. But if the TCP/IP stack has to be modified anyway, I could imagine that one could just add to the server whatever encap/decap is required for the overlay transport. Then, I have the impression that the proposed TCP option would not be needed at all. > > I don't want to dig into the overlay design, because this is not really in scope of TCPM. But if there is a system architecture that does not require adding TCP options in middleboxes, thus affecting TCP end-to-end semantics, it would really be important to understand why such an architecture cannot be used. > > Thanks > > Michael > > > >> The issue of the proposed fast-open scheme is one that we >> have not considered, but I don't think it adds any problems >> for the TCP option that aren't already a problem for tunneled >> connectivity in general. I will have to spend some time with >> that proposal and think about how they interrelate. >> >> --Brandon >> >> On 12/21/2012 08:34 AM, Scharf, Michael (Michael) wrote: >>> Brandon, >>> >>>>> If there were tunnels between the OVRLY_IN and OVERLY_OUT >>>> boxes, then >>>>> the inner IP headers would have the HOST_X and SERVER >>>> addresses, and >>>>> the outer ones in the tunnel would have the overlay >> headers. Since >>>>> the inner packets would be delivered ultimately after >> egressing the >>>>> tunnels, the HOST_X addresses are totally visible to the >>>> server, and >>>>> vice versa. >>>> >>>> There are indeed tunnels between OVRLY_IN and OVRLY_OUT, and the >>>> inner IP headers will typically use either the client-side >> addresses >>>> or the server-side addresses. However, neither OVRLY_IN >> nor OVRLY_OUT >>>> can be assumed to be reliably in-path between HOST and >> SERVER, which >>>> means that internet routing cannot be relied upon to cause >> packets to >>>> arrive at the overlay ingress. Instead, HOST_1 must >> directly address >>>> OVRLY_IN_1 in order to send its packets into the tunnel, >> and SERVER >>>> must directly address OVRLY_OUT in order to send the >> return traffic >>>> into the tunnel. >>> >>> Thanks for this explanation - this indeed helps to >> understand the architecture. But actually I still don't fully >> understand the motivation of bypassing Internet routing this >> way. As a non-expert on routing, it indeed looks to me like >> reinventing source routing - but this is outside my core expertise. >>> >>> Regarding TCPM's business: If I correctly understand the approach, >>> OVRLY_IN will "transparently" add and remove TCP options. >> This is kind >>> of dangerous from an end-to-end perspective... Sorry if >> that has been >>> answered before, but I really wonder what to do if OVRLY_IN >> can't add >>> this option, either because of lack of TCP option space, or because >>> the path MTU is exceeded by the resulting IP packet. (In >> fact, I think >>> that this problem does not apply to TCP options only.) >>> >>> Unless I miss something, the latter case could become much >> more relevant soon: TCPM currently works on the fast-open >> scheme that adds data to SYNs. With that, I think it is >> possible that all data packets from a sender to a receiver >> are either full sized or large enough that the proposed >> option does not fit in. Given that this option can include >> full-sized IPv6 addresses, this likelihood is much larger >> than for other existing TCP option, right? >>> >>> In some cases, I believe that the proposed TCP option >> cannot be added in the overlay without either IP >> fragmentation, which is unlikely to be a good idea with NATs, >> or TCP segment splitting, which probably can cause harm as >> well. For instance, what would OVRLY_IN do if it receives an >> IP packet with a TCP SYN segment that already sums up to 1500 >> byte? And, to make the scenario more nasty, if the same >> applies to the first data segments as well? >>> >>> Thanks >>> >>> Michael >>> >> >> -- >> Brandon Williams; Principal Software Engineer Cloud >> Engineering; Akamai Technologies Inc. -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From warren@kumari.net Mon Dec 31 09:51:27 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1603121F8905 for ; Mon, 31 Dec 2012 09:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp4qMK9y9iJs for ; Mon, 31 Dec 2012 09:51:26 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E55F21F88B1 for ; Mon, 31 Dec 2012 09:51:25 -0800 (PST) Received: from [192.168.1.136] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 64A361B40221; Mon, 31 Dec 2012 12:51:24 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453CCFF776@szxeml509-mbx> Date: Mon, 31 Dec 2012 12:51:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <87D38459-3B16-4AA9-A899-8B8B49642EB5@kumari.net> References: <50D0657B.8090302@ericsson.com> <8AE0F17B87264D4CAC7DE0AA6C406F453CCFF776@szxeml509-mbx> To: Internet Area X-Mailer: Apple Mail (2.1499) Cc: Ralph Droms Subject: Re: [Int-area] Call for adoption of draft-carpenter-flow-label-balancing-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 17:51:27 -0000 [ Replying midway through the thread as somehow my MUA et the original=85]= =20 On Dec 20, 2012, at 8:38 PM, Liubing (Leo) = wrote: > I'm in favor of it. It's a good use case of flow label for L3/4 load = balancing. >=20 > Thanks >=20 > B.R. > Bing >=20 >> -----Original Message----- >> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On >> Behalf Of Suresh Krishnan >> Sent: Tuesday, December 18, 2012 8:46 PM >> To: Internet Area >> Cc: Julien Laganier; Ralph Droms >> Subject: [Int-area] Call for adoption of >> draft-carpenter-flow-label-balancing-02 >>=20 >> Hi all, >> This draft has been presented at intarea face to face meetings and = has >> received a bit of discussion. It has been difficult to gauge whether = the >> wg is interested in this work or not. This call is being initiated to >> determine whether there is WG consensus towards adoption of >> draft-carpenter-flow-label-balancing-02 as an intarea WG draft. = Please >> state whether or not you're in favor of the adoption by replying to = this >> email. If you are not in favor, please also state your objections in >> your response. This adoption call will complete on 2013-01-04. Support. I was originally opposed to this draft (and /may/ have thrown a bit of a = hissy fit at Brian about it), but my major concerns have been addressed = in this version and I now support adoption=85 I have a few comments / notes that I promise to ship over to the authors = sometime=85 W >>=20 >> Regards >> Suresh & Julien >>=20 >>=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 -- "Have you got any previous convictions?" "Well, I dunno... I suppose I used to believe very firmly that a penny = saved is a penny earned--" -- Terry Pratchett