From internet-drafts@ietf.org Wed Jun 1 04:29:58 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8468FE07EB; Wed, 1 Jun 2011 04:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 f8ZEgZ6VZAin; Wed, 1 Jun 2011 04:29:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0AEE074A; Wed, 1 Jun 2011 04:29:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-tsvwg-natsupp-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110601112958.2666.82286.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2011 04:29:58 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 11:29:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Network Addr= ess Translation Support Author(s) : Randall R. Stewart Michael Tuexen Irene Ruengeler Filename : draft-ietf-tsvwg-natsupp-01.txt Pages : 11 Date : 2011-06-01 Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific chunks and procedures to help NAT's provide similar features of NAPT in the single point and multi-point traversal scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-natsupp-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-natsupp-01.txt From fernando.gont.netbook.win@gmail.com Thu Jun 2 22:39:43 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AA9E06A1 for ; Thu, 2 Jun 2011 22:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643] 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 MG4i0OIekcIJ for ; Thu, 2 Jun 2011 22:39:41 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5E2E0682 for ; Thu, 2 Jun 2011 22:39:41 -0700 (PDT) Received: by gxk19 with SMTP id 19so813532gxk.31 for ; Thu, 02 Jun 2011 22:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=+zzR2oakYdDm79Q4O9ocjsUenvNocGroJs1Z86AQ1fs=; b=jVwewNXsHH2KNwJDl35QzPAJN7nrMLdBbUx/GqIf89jIADnaxY8pItHbEId0aojyr4 QFH/7n766QZ0d1ucARH/za1WGdNjQ92D/vDAigtUTeX6aQzKAUT4Hg0j6NNkfrGVzVlM h9Kc/ridiWh5te4QZBEoo3gozs790D1wavQwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:content-type:content-transfer-encoding; b=dr6XRWaamkdKTchA1NXFFas1d3sk4NFxIndB3EGXx10Pbcw85GrzvPm4uzTQ2HOkyN gJWoXBeKpyYxAlXaC0nKoB+hTtRjhlAboSJKfojL2ovxvjC+9CzvxjjE9QmtBQVurC/b HB1zsVrO0jv87/e4brPw8nxDJ+aecF4xtb1h8= Received: by 10.150.173.9 with SMTP id v9mr1470436ybe.168.1307079580418; Thu, 02 Jun 2011 22:39:40 -0700 (PDT) Received: from [192.168.1.35] ([190.48.217.138]) by mx.google.com with ESMTPS id u32sm929446ann.30.2011.06.02.22.39.09 (version=SSLv3 cipher=OTHER); Thu, 02 Jun 2011 22:39:39 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE86FFA.1010606@gont.com.ar> Date: Fri, 03 Jun 2011 02:24:10 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: tsvwg Subject: draft-gont-tsvwg-source-quench: IANA Considerations section X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Carlos Pignataro X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 05:39:43 -0000 Folks, Carlos Pignataro has suggested that the IANA Considerations section of the document should request IANA to mark the corresponding ICMP type as "Deprecated". This seems to make sense, and thus I'm planning to incorporate the following text in the IANA considerations section: IANA is requested to mark ICMP type 4 (Source Quench) as "Deprecated" in de ICMP Parameters registry [ICMPPARREG] with a reference to this document. Please yell if you disagree with this. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@isi.edu Sun Jun 5 16:49:15 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B2311E807A for ; Sun, 5 Jun 2011 16:49:15 -0700 (PDT) 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 JVX9q8S41isf for ; Sun, 5 Jun 2011 16:49:14 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfa.amsl.com (Postfix) with ESMTP id 923BD11E8075 for ; Sun, 5 Jun 2011 16:49:14 -0700 (PDT) Received: from [172.20.0.222] (pc2.kyotoint1-unet.ocn.ne.jp [211.123.99.34]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p55Nmcc5018035 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 5 Jun 2011 16:48:49 -0700 (PDT) Message-ID: <4DEC15D6.2050801@isi.edu> Date: Sun, 05 Jun 2011 16:48:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Fernando Gont Subject: Re: draft-gont-tsvwg-source-quench: IANA Considerations section References: <4DE86FFA.1010606@gont.com.ar> In-Reply-To: <4DE86FFA.1010606@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p55Nmcc5018035 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Carlos Pignataro , tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 23:49:15 -0000 Hi, all, I agree with the IANA recommendation below. I don't agree with "yell if you disagree" - I prefer "yell either way". Silence should never be taken as acceptance, pro or con. Joe On 6/2/2011 10:24 PM, Fernando Gont wrote: > Folks, > > Carlos Pignataro has suggested that the IANA Considerations section of > the document should request IANA to mark the corresponding ICMP type as > "Deprecated". > > This seems to make sense, and thus I'm planning to incorporate the > following text in the IANA considerations section: > > IANA is requested to mark ICMP type 4 (Source Quench) as > "Deprecated" in de ICMP Parameters registry [ICMPPARREG] > with a reference to this document. > > Please yell if you disagree with this. > > Thanks! > > Best regards, From nekiz@udel.edu Tue Jun 7 08:08:15 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55281F0C36 for ; Tue, 7 Jun 2011 08:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 LXFZwznW5jbS for ; Tue, 7 Jun 2011 08:08:15 -0700 (PDT) Received: from md10.nss.udel.edu (md10.nss.udel.edu [128.175.1.40]) by ietfa.amsl.com (Postfix) with ESMTP id 069DB1F0C34 for ; Tue, 7 Jun 2011 08:08:14 -0700 (PDT) Received: from roaming-192-232.nss.udel.edu (EHLO _128.175.192.232_) ([128.175.192.232]) by md10.nss.udel.edu (MOS 4.2.3-GA FastPath queued) with ESMTP id BUY33291; Tue, 07 Jun 2011 11:08:13 -0400 (EDT) Message-ID: <4DEE3EDF.8090302@udel.edu> Date: Tue, 07 Jun 2011 11:08:15 -0400 From: Nasif Ekiz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: tsvwg@ietf.org Subject: TCP Traffic Traces Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A020302.4DEE3EDD.0007, actions=MAILHURDLE TAG X-Mailman-Approved-At: Tue, 07 Jun 2011 09:16:58 -0700 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 15:09:28 -0000 Hi all, I am doing research on TCP data reneging behavior and need TCP traces from different domains such as enterprise and wireless. Can you give me pointers for recent TCP traces (anonymized traces are OK)? Thank you. Nasif Ekiz Research Assistant at Protocol Engineering Lab, University of Delaware http://www.cis.udel.edu/~nekiz/ From internet-drafts@ietf.org Thu Jun 9 17:36:12 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DA811E8102; Thu, 9 Jun 2011 17:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 0r3qGYeq7xQk; Thu, 9 Jun 2011 17:36:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE7511E80A3; Thu, 9 Jun 2011 17:36:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-tsvwg-source-quench-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110610003611.5031.5280.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2011 17:36:11 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 00:36:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Deprecation of ICMP Source Quench messages Author(s) : Fernando Gont Filename : draft-ietf-tsvwg-source-quench-01.txt Pages : 8 Date : 2011-06-09 This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. Additionally, it requests that the status of RFC 1016 be changed to "Historic". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-source-quench-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-source-quench-01.txt From guyingjie@huawei.com Sun Jun 12 23:55:36 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBE221F8498; Sun, 12 Jun 2011 23:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.737 X-Spam-Level: X-Spam-Status: No, score=-100.737 tagged_above=-999 required=5 tests=[AWL=-1.861, BAYES_50=0.001, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, HTML_MESSAGE=0.001, MANGLED_GRNTEE=2.3, MIME_CHARSET_FARAWAY=2.45, 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 79j4s0stvGhs; Sun, 12 Jun 2011 23:55:33 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B5FEB21F8495; Sun, 12 Jun 2011 23:55:31 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMP006YOV7LOB@szxga04-in.huawei.com>; Mon, 13 Jun 2011 14:54:58 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMP00DWQV7LSV@szxga04-in.huawei.com>; Mon, 13 Jun 2011 14:54:57 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 13 Jun 2011 14:54:54 +0800 Received: from g00107907 (10.138.41.104) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 13 Jun 2011 14:54:53 +0800 Date: Mon, 13 Jun 2011 14:56:41 +0800 From: "Yingjie Gu(yingjie)" Subject: Looking forward to your comments: Virtual machine/host migraiton in Data Center. X-Originating-IP: [10.138.41.104] To: tsvwg@ietf.org, dispatch@ietf.org Message-id: <003e01cc2997$0cb96960$262c3c20$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_syjEGnl9pB2WJrEh/zMbQg)" Content-language: zh-cn Thread-index: AcwplwweZ120wpp3QcmuTCIlEcs5Ng== Cc: "'Romascanu, Dan \(Dan\)'" , 'Ning Zong' , wangdanhua@huawei.com, 'Fan Yongbing' , rbonica@juniper.net X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 06:55:36 -0000 --Boundary_(ID_syjEGnl9pB2WJrEh/zMbQg) Content-type: multipart/related; boundary="Boundary_(ID_/1PbB/2x1jdhEcFsLazVqQ)" --Boundary_(ID_/1PbB/2x1jdhEcFsLazVqQ) Content-type: multipart/alternative; boundary="Boundary_(ID_Q7wk6KaGRFUGzdMb7/+t7w)" --Boundary_(ID_Q7wk6KaGRFUGzdMb7/+t7w) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi all, We have sent a draft regarding virtual machine/host migration in Data = Center to OPSAWG. I guess people in TSV Area may also be interested in this problem. Please review the attached draft for detail.=20 Virtualization enables Data Center to improve their resource utility to = 70% or higher. Virtual machine migration enables even better resource = utility and better flexibility. A physical server is virtualized into several virtual machines/hosts and the virtual machines can be migrate to any location within the pre-designated area in the Data Center, or to a different Data Center site, based on physical server status, network conditions, application requirements or subscribers=A1=AF requirements. = For example, a part of network is experiencing badly packet loss. In order = to guarantee high priority services, the virtual machine hosting high = priority services are migrated to a place with better network performance. Two parts of information need to be considered when migrate a virtual machine: 1) software resource, such as OS and memory, on server side, = and 2) policies and dynamic information on network side. This draft is focus on = 2). Since the most important feature of Virtual machine migration is that = the running service should not be significantly interrupted, it=A1=AFs quite challenging on how to migrate the policies and dynamic information on network side, within or between Data Center sites.=20 =20 Anyone who has any questions or comments, please post to the this = thread. The authors looks forward to your feedback.=20 =20 Best Regards Yingjie Gu =20 _____ =20 Gu Yingjie =BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies = Co., Ltd. Company_logo Phone:=20 Fax:=20 Mobile:=20 Email:=20 =B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF=BB=AA=CE= =AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129 Huawei Technologies Co., Ltd. Bantian, Longgang District,Shenzhen 518129, P.R.China http://www.huawei.com=20 _____ =20 =B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB= =BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8= =C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA =D7=E9=A1=A3=BD=FB =D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3= =C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6= =B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3= =CA =BC=FE=D6=D0 =B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC= =FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA= =B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1 This e-mail and its attachments contain confidential information from HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, total or partial=20 disclosure, reproduction, or dissemination) by persons other than the intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by=20 phone or email immediately and delete it! --Boundary_(ID_Q7wk6KaGRFUGzdMb7/+t7w) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi= all,

We= have sent a draft regarding virtual machine/host migration in Data = Center to OPSAWG. I guess people in TSV Area may also be interested in = this problem. Please review the attached draft for detail. =

Vi= rtualization enables Data Center to improve their resource utility to = 70% or higher. Virtual machine migration enables even better resource = utility and better flexibility. A physical server is virtualized into = several virtual machines/hosts and the virtual machines can be migrate = to any location within the pre-designated area in the Data Center, or to = a different Data Center site, based on physical server status, network = conditions, application requirements or subscribers=A1=AF requirements. = For example, a part of network is experiencing badly packet loss. In = order to guarantee high priority services, the virtual machine hosting = high priority services are migrated to a place with better network = performance.

Tw= o parts of information need to be considered when migrate a virtual = machine: 1) software resource, such as OS and memory, on server side, = and 2) policies and dynamic information on network side. This draft is = focus on 2). Since the most important feature of Virtual machine = migration is that the running service should not be significantly = interrupted, it=A1=AFs quite challenging on how to migrate the policies = and dynamic information on network side, within or between Data Center = sites.

 

An= yone who has any questions or comments, please post to the this thread. = The authors looks forward to your feedback.

 

Be= st Regards

Yi= ngjie Gu

 

Gu Yingjie
=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE = Huawei Technologies Co., Ltd.
3D"Company_logo"

Phone:
Fax:
Mobile:
Email:
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC=EF=BB=AA= =CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei = Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, = P.R.China
http://www.huawei.com =

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB= =CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8= =F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA= =D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA= =CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB= =B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9= =A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA= =D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2= =D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC= =FE=A3=A1
Thi= s e-mail and its attachments contain confidential information from = HUAWEI, which
is intended only for the person or entity whose = address is listed above. Any use of the
information contained herein = in any way (including, but not limited to, total or partial =
disclosure, reproduction, or dissemination) by persons other than = the intended
recipient(s) is prohibited. If you receive this e-mail = in error, please notify the sender by
phone or email immediately and = delete it!

= --Boundary_(ID_Q7wk6KaGRFUGzdMb7/+t7w)-- --Boundary_(ID_/1PbB/2x1jdhEcFsLazVqQ) Content-id: Content-type: image/jpeg; name=image001.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_/1PbB/2x1jdhEcFsLazVqQ)-- --Boundary_(ID_syjEGnl9pB2WJrEh/zMbQg) Content-type: text/plain; name=draft-gu-opsa-policy-migration-00.TXT Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-gu-opsa-policy-migration-00.TXT Network Working Group Y. Gu Internet-Draft Huawei Intended status: Standards Track Y. Fan Expires: December 10, 2011 China Telecom June 8, 2011 Policies and dynamic information migration in DC draft-gu-opsa-policy-migration-00 Abstract Virtualization and Virtual Machine (VM) migration provide Data Center with feasibility and improves the utilization of limited physical resource, e.g. switches/routers, servers and links. Meanwhile, a variety of policies (e.g. ACL, firewalls, load balancers, IPS and QoS) are deployed in Data Center to improve system security and gurantee SLA. Those polices are executed by rules configured or generated on network devices. E.g. packet filtering policies are executed by Access Control List on switches or firewalls. Another example is Load balancer (LB) who extablishes TCP/HTTP connections with external clients and balances connections among server farm. During this process, TCP connection tables are dynamically generated on LB. When VM migrates, the network devices that processing and forward VM's packets may change. In order to keep VM's running serives and guanrantee security on new place, VM-relevant policies, including static policies as well as the dynamically generated information, need to migrate with VM. This draft describes some examples of the policies that need to migrate with VM, the problems that need to consider when migrate polices in Data Center. The goal is to justify that it is necessary for IETF to make new effort on management of virtualized Data Center. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Gu & Fan Expires December 10, 2011 [Page 1] Internet-Draft policy and dynamic information migration June 2011 This Internet-Draft will expire on December 10, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gu & Fan Expires December 10, 2011 [Page 2] Internet-Draft policy and dynamic information migration June 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 5 3. Policies Classification . . . . . . . . . . . . . . . . . . . 6 3.1. Static Policies . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Dynamic Information . . . . . . . . . . . . . . . . . . . 9 3.2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Policy migration within a single site . . . . . . . . . . 22 4.2. Polices migration in asymmetric architecture . . . . . . . 23 4.3. Policies migration between DC sites . . . . . . . . . . . 24 5. General Considerations . . . . . . . . . . . . . . . . . . . . 25 5.1. Time-sensitive . . . . . . . . . . . . . . . . . . . . . . 26 5.2. Notification . . . . . . . . . . . . . . . . . . . . . . . 27 5.3. Functionality . . . . . . . . . . . . . . . . . . . . . . 27 5.4. Resource Capability . . . . . . . . . . . . . . . . . . . 29 5.5. Migration Feedback . . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 29 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Gu & Fan Expires December 10, 2011 [Page 3] Internet-Draft policy and dynamic information migration June 2011 1. Introduction Data centers can host tens or even thousands of different applications. Some are simple applications such as web servers providing static content, while some may be very complex, e.g. e-commerce, that requiring all around privacy protection and data security. Clients of Data Center, unlike server hosting clients, raise more strict QoS and Security requirements. To satisfy different level of security requirements and to manage and improve the performance of these applications, data centers typically deploy a large variety of policies on network devices, e.g. interface security functions on switches and routers, and middleboxes, including firewalls, load balancers, SSL offloaders, web caches and intrusion prevention boxes. To satisfy QoS requirements, Data Center also implement QoS mechanism as ISP network. IEEE 802.1 DCB working group defines a series of standards to guarantee quality of service. 802.1Qau - Congestion Notification 802.1Qaz - Enhanced Transmission Selection 802.1Qbb - Priority-based Flow Control Without regard to mobile network, the existing DC network management has a pre-assumption that end hosts will not move. If an end host moves, because the physical link has to break down and the service also has to break down, the network can treat it as two separated parts: one host leave the network and another host join the network. Server Virtualization and Virtual Machine Migration changes the situation and disable the preassumption. With server virtualization, providers can reduce networking cost. To support the same volume of services, fewer network devices, servers and links are required than before. Multiple Virtual Machines (VMs) are established within a single physical server and the VMs are allowed to relocate to a different servers within the same subnet of Data Center, or even among different sites of a Data Center. This is so called VM Migration. VM Migration brings flexibility to Data Center, meanwhile it makes network management more complex and challenging. Unlike servers power off and power on again, in which case, servers know and can bear services disruption, VM Migration requires that VM's IP Address shouldn't change and running service mustn't be disrupted. Meawhile, security level should be guaranteed. In order to satisfy the above requirements, the VM relevant polices need to Gu & Fan Expires December 10, 2011 [Page 4] Internet-Draft policy and dynamic information migration June 2011 migrate with VM. IEEE 802.1Qbg has developed VSI Discovery and Configuration Protocol (VDP) to enable ajacent bridge to discover VM and configure corresponding static polices. The author has presented the problem to IEEE 802.1 DCB task group. DCB has recognized this problem and make extension to VDP to notify VM status, which will be introduced in Section 5.2. IEEE 802.1 DCB would like to know furture progress of this problem in IETF and ask the author to let know the furthur progress. In the following sections, detail examples and senarios are given to explain why and which polices need to migrate with VM. 2. Terminologies and concepts The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Source Network Device, Source switch, or Source device: the network device/switch/device from where the VM migrates. I.E. VM is originally located under the source network device/switch/device. Destination Network Device, Destination switch, or Destination device: the network device/switch/device to where the VM migrates. I.E. VM is relocated to the destination network device/switch/device. TCP connection table: A table containing TCP connection-specific information. VM: Virtual Machine; A completely isolated operation system which is installed by software on a normal operation system. An normal operation system can be virtualized into several VM. ACL: Access Control List; A list of rules that specifies which packets can be permited, which should be denied. QoS: Quality of Service; FW: Firewall; a policy based security function, typically used for restricting access to/from specific devices and applications. LB: Load Balancer; A methodology to distribute workload across multiple computers or a computer cluster, network links, central processing units, disk drives, or other resources, to achieve optimal Gu & Fan Expires December 10, 2011 [Page 5] Internet-Draft policy and dynamic information migration June 2011 resource utilization, maximize throughput, minimize response time, and avoid overload. NAT: Network Address Translation. Refer to RFC3303. 3. Policies Classification In this section, we use the following figure as an example network architecture. Some redundant links are omitted for simplicity. the new VM1 under Server4 represents the VM1 after migration. VM1 and new VM1 don't exist at the same time. In the real world, the networking of DC could be different. ------------------------------------------------- | Gateway | ------------------------------------------------- / \ / \ / \ / \ ----- -------- -------- -------- -------- ------ |FW-A|--| AGG1 |----| AGG2 | | AGG3 |----| AGG4 |---|FW-B| ----- -------- -------- -------- -------- ------ | | | | | | | | | \ / | | \ / | | \ / | | \ / | | \/ | | \/ | | /\ | | /\ | | / \ | | / \ | | / \ | | / \ | | | | | | | | | ---------- ---------- ---------- ---------- |Switch1 | |Switch2 | |Switch3 | |Switch4 | ---------- ---------- ---------- ---------- | \ / | | \ / | | \/ | | \/ | | /\ | | /\ | | / \ | | / \ | ---------- ---------- ---------- ---------- |Server1 | |Server2 | |Server3 | |Server4 | ---------- ---------- ---------- ---------- | | | | VM1 VM2 VM3 new VM1 Figure 1: Basic networking for discussion in this draft. One key feature of VM migration is that VM's IP Address shouldn't change, otherwise the running service could be disrupted. In order to achieve this, additional mechanism need to be developed. However, these mechanism are out of the scope of this draft. In policy Gu & Fan Expires December 10, 2011 [Page 6] Internet-Draft policy and dynamic information migration June 2011 migration problem statement, we assume that there already exist an effective mechanism to guarantee VM's IP Address unchanged. Two kinds of polices are introduced in this draft, i.e. static polices and dynamic polices (or dynamic information). 3.1. Static Policies Administrators of DC establish VM profile, which may include static policies for the VM, e.g. VLAN Name, bandwidth indication, and Qos parameters, etc. And they are suppposed to be consistent during the lifetime of the VM. No matter where VM migrates, the static policies need to move with VM for the sake of security, privacy and QoS. Static polices can be described by natural languages or mathematics fomula. They are implementated by specific configurations on different network elements, e.g. a ACL item on physical ports of switches enables a packet filtering policies. In this draft, we discuss the migration of policies, but the policies migration also implies the migration of configurations on network devices, because configurations are embodiment of policies. Policies that need to migrate with VM are those can influence VM's running services or are related to security and billing&accounting. Different network devices will contain different kind of policies. For example, it can be static Access Control Lists on Access switches, QoS on switches and routers, security rules on Firewalls, and load balancing mechanism on Load Balancer, etc. 3.1.1. Use Cases It's hard to enumerate all the VM-related static polices. In this section, we just give two examples of static policies to show the necessity of static polices migration. 3.1.1.1. Access Control List shows the influence of lack of ACLs on destination switch. There is an Default ACL on source switch (Switch1) deny all packets from IP subnet 10.138.3.0 to Internet. And another ACL 101 allows IP Address 10.138.3.1, VM1's IP Address, to send packets to Internet. VM1 has a running service on it. During service provisioning, VM1 is migrated to Server4 under Switch4, Where there is default ACL to deny all packets. Since ACL 101 on Switch1 is not migrated to Switch4, VM1's IP Address falls into a default ACL which deny all unmatching packets. As a result, packets belonging to the running services are dropped, hence the running service is disrupted. Gu & Fan Expires December 10, 2011 [Page 7] Internet-Draft policy and dynamic information migration June 2011 ------------------------------------------------- | Gateway | ------------------------------------------------- //\ \ / \ / * \ / \ ------ -------- -------- -------- -------- ------ |FW-A|----| AGG1 |----| AGG2 | | AGG3 |----| AGG4 |---|FW-B| ------ -------- -------- -------- -------- ------ |* | | | | | | | |* \ / | | \ / | |* \ / | | \ / | |* \/ | | \/ | ACL 101: |* /\ | | /\ | permit VM1 |* / \ | | / \ |Default ACL: Default ACL:|* / \ | | / \ |deny all deny all |* | | | | | | |Packets dropped ---------- ---------- ---------- ---------- |Switch1 | |Switch2 | |Switch3 | |Switch4 | ---------- ---------- ---------- ---------- |* \ / | | \ / |/\ \/ |* \/ | | \/ |* /\ |* /\ | | /\ |* |* / \ | | / \ |* ---------- ---------- ---------- ---------- |Server1 | |Server2 | |Server3 | |Server4 | ---------- ---------- ---------- ---------- |* | | |* |* | | |* VM1 VM2 VM3 new VM1 Figure 2: VM migration without ACL migration 3.1.1.2. VLAN VMs with similar properties could be grouped into a VLAN, e.g. end hosts providing Web service are grouped into Web-VLAN. Each VLAN has a unique VLAN ID. Only when a VM is configured into a specific VLAN, can it receives broadcast packets from other VMs in the same VLAN. In , VM1 belongs to VLAN1. Assuming VLAN1 is not configured on the port on AGG4 that attaching Switch4, and VM1 migrates to new VM1, Broadcast pakcets from another VM belonging to VLAN1 are forwarded to AGG4, however they can not be forwarded to Switch4, since broadcast packets are sending only to VLAN1-enabled port. The *** line represents VLAN1 broadcast, which can not access Server4. New VM1 can not receive VLAN1 broadcast. Gu & Fan Expires December 10, 2011 [Page 8] Internet-Draft policy and dynamic information migration June 2011 ----------------------------------- | Gateway | ----------------------------------- | | ------------------------------------------ | Core Switch | ------------------------------------------ /* \ / *\ /* \ / \/\ ------ ------- ------- -------- ------- ------ |FW-A|----|AGG1 |----| AGG2| | AGG3 |--| AGG4|---|Fw-B| ------ ------- ------- -------- ------- ------ |* *| | | | | | | \/ No VLAN1 |* *\ / | | \ / | /\ |* *\ / | | \ / | |* *\/ | | \/ | |* /*\ | | /\ | |* / * \ | | / \ | |* / * \ | | / \ | |* | * | | | | | | --------- --------- --------- ---------- |Switch1| |Switch2| |Switch3| |Switch4 | --------- --------- --------- ---------- VLAN1 |* \ / * |VLAN1 | \ / | |* \/ * | | \/ | |* /\ * | | /\ | |* / \ \/ | | / \ | --------- --------- --------- ---------- |Server1| |Server2| |Server3| |Server4 | --------- --------- --------- ---------- |* | | | |\/ | | | VM1 VM2 VM3 new VM1 Figure 3: VM migration without VLAN migration 3.2. Dynamic Information Except for the static policies, some dynamic information could also be generated by network devices to assist packet processing. TCP connection table on proxy is an obvious example. Proxy intervenes the direct connection between external client and internal server, which can protect internal server from attacking. Proxy establishes TCP connection with external client for internal server, a TCP connection Table being generated on proxy. Then proxy establishes TCP connection with internal server for external client, another TCP connection table being generated. These TCP Connection table can not Gu & Fan Expires December 10, 2011 [Page 9] Internet-Draft policy and dynamic information migration June 2011 be configured by network manager, but is generated by network devices, e.g. Firewalls and proxies, according to real connections. Another example is cumulative data, e.g. how many packets/TCP connecition requests an end host has sent. This information can only be generated by network devices according to real traffic. Configurations could be generated dynamically by network devices themselves according to the dynamic informaiton, e.g. Dynamic ACLs. In following section, we enumerate several kinds of dynamic information. A dynamic information could be generated on different network devices, meanwhile a specific network devices could hold more than one kind of dynamic information. In following section, we introduce possible dynamic informaiton on specific network devices. 3.2.1. Use Cases 3.2.1.1. Switches We use switch to represent Top of Racks, Bridges and switches. These devices have slightly different definition and functions, and may be used or combinedly used in differenct scenarios. 3.2.1.1.1. Dynamic ACL In , assuming a default ACL is configured on Switch1 that all traffic is denied unless the end host is authorized and authenticated. VM1 has been authenticated on source device and a dynamic ACL has been generated which allows VM1's traffic to pass through. A 'Deny all' default ACL is configured on Switch4 too. VM1 migrates to destination device which attaches to Swtich4. Because Switch4 regards new VM1 as an unathenticated end host, according to default ACL, all data packets from VM1 will be dropped. In order to continue service, VM1 has to authenticate again. In this case, running service is disrupted. If authentication and dynamic ACL, generated on Switch1, can be migrated to Switch4, data packets from VM1 are permitted, hence, without regard to influence caused by features, running service can continue. Gu & Fan Expires December 10, 2011 [Page 10] Internet-Draft policy and dynamic information migration June 2011 ------------------------------------------------- | Gateway | ------------------------------------------------- //\ \ / \ / * \ / \ ------ ------- ------- ------- ------ ------ |FW-A|-----| AGG1 |---| AGG2 | | AGG3|----| AGG4|---|FW-B| ------ ------- ------- ------- ------ ------ |* | | | | | | | |* \ / | | \ / | |* \ / | | \ / | |* \/ | | \/ | |* /\ | | /\ | |* / \ | | / \ | |* / \ | | / \ | |* | | | | | | | Default ACL: --------- --------- --------- --------- Default ACL: deny all |Switch1| |Switch2| |Switch3| |Switch4| deny all --------- --------- --------- --------- |* \ / | | \ / /\| \/ VM1's pakcets Dynamic ACL: |* \/ | | \/ *| /\ are dropped. Permit VM! |* /\ | | /\ *| |* / \ | | / \ *| --------- --------- --------- --------- |Server1| |Server2| |Server3| |Server4| --------- --------- --------- --------- |* | | *| |* | | *| VM1 VM2 VM3 new VM1 Figure 4: VM migration without dynamic ACL migration 3.2.1.1.2. DHCP snooping Assuming Switch1 is DHCP Snooping Enabled and a DHCP Snooping mapping item is created for VM1: (IP-VM1: MAC-VM1). This mapping is created dynamically by listening to DHCP Response message. If VM1 migrate to destination device, since the IP Address of VM1 doesn't change, there is no DHCP Request sent by VM1 before lease time expires. So on Switch4, no mapping information can be generated by listening to DHCP response, and all traffic from VM1 will be dropped. If DHCP snooping table on Switch1 can be migrated to Switch4, Switch4 learns from the migrated DHCP snooping talbe that packet with IP-VM1 and MAC-VM1 can be regularly forwarded. Gu & Fan Expires December 10, 2011 [Page 11] Internet-Draft policy and dynamic information migration June 2011 ------------------------------------------------- | Gateway | ------------------------------------------------- //\ \ / \ / * \ / \ ------ ------- ------ -------- ------- ------ |FW-A|---|AGG1 |----| AGG2| | AGG3 |---|AGG4 |---|FW-B| ------ -------- ------ -------- ------- ------ |* | | | | | | | DHCP |* \ / | | \ / | Response |* \ / | | \ / | \ |* \/ | | \/ | \ |* /\ | | /\ | \ |* / \ | | / \ |DHCP snooping enabled \ |* / \ | | / \ |No DHCP request DHCP >|* | | | | | | |from new VM1 snooping --------- --------- --------- ---------- enabled |Switch1| |Switch2| |Switch3| |Switch4 | --------- --------- --------- ---------- ---------- |* \ / | | \ / /\| \/ VM1's packets |Snooping| |* \/ | | \/ *| /\ are dropped |Table | |* /\ | | /\ *| ---------- |* / \ | | / \ *| -------- --------- --------- ---------- |Server1| |Server2| |Server3| |Server4 | -------- --------- --------- ---------- |* | | *| |* | | *| VM1 VM2 VM3 new VM1 Figure 5: VM migration without DHCP snooping table migration 3.2.1.1.3. IGMP snooping IGMP snooping is similar to DHCP Snooping. Multicast membership is created on ports by listening to IGMP JOIN or membership report messages. When a switch receives a multicast packet, it forwards the packet to the port which has joined the multicast group. In , assuming VM1 sends an IGMP JOIN Group1 message to Multicast server, port1 and port-uplink on Switch1 check the JOIN message and tag on port1 and port-uplink that they should forward Multicast packets from Group1. If VM1 migrates to destination, since migration is transparent to VM, VM1 will not send IGMP membership report until next IGMP General Query is received. If port2 on Swtich4 didn't join Group1, multicast packet from Group1 won't be forward to port2, then VM1 won't be able to receive Multicast packets. Gu & Fan Expires December 10, 2011 [Page 12] Internet-Draft policy and dynamic information migration June 2011 ------------------------------------------------- | Gateway | ------------------------------------------------- /* \ / *\ /* \ / *\ ------ -------- -------- -------- -------- ------ |FW-A|-----| AGG1 |----| AGG2 | | AGG3 |---| AGG4 |--- |FW-B| ------ -------- -------- -------- -------- ------ |* | | | | | | *| IGMP |* \ / | | \ / *| JOIN Snooping|* \ / | | \ / *| \ |* \/ | | \/ *| \ |* /\ | | /\ *| \ |* / \ | | / \ *|IGMP enabled \ |* / \ | | / \ *|No IGMP JOIN >|* | | | | | | \/|from new VM1 IGMP ---------- ---------- ---------- ---------- \/ enabled |Switch1 | |Switch2 | |Switch3 | |Switch4 | /\ ---------- ---------- ---------- ---------- |* \ / | | \ / | ---------- |* \/ | | \/ | |Group1: | |* /\ | | /\ | |Port1 | |* / \ | | / \ | ---------- ---------- --------- --------- ---------- |Server1 | |Server2| |Server3| |Server4 | ---------- --------- --------- ---------- |* | | | |\/ | | | VM1 VM2 VM3 new VM1 Figure 6: VM migration without IGMP snooping table migration 3.2.1.1.4. Cumulative Data To ensure VMs consume no more than assigned bandwidth and to enable QoS control, billing and accounting, bridges need to cumulate packets number and calculate packet rate. Lack of these cumulative data and statistic data on destination bridge decrease the accuracy. 3.2.1.2. Firewall Fireall (FW) is a filtering device that separates LAN segments, giving each segment a different security level and establishing a security perimeter that controls the traffic flow between segments. There are different types of firewalls based on their packet- processing capabilities and their awareness of application-level information: Gu & Fan Expires December 10, 2011 [Page 13] Internet-Draft policy and dynamic information migration June 2011 Packet-filetering firewalls Proxy firewalls Stateful firewalls Hybrid firewalls 3.2.1.2.1. Dynamic ACL Packet filtering Firewall filters packet according to ACL. Dynamic ACL could be generated to protect internal network/servers from attacks, similar to dynamic ACL on Switches. 3.2.1.2.2. TCP Connection Table Proxy Firewall proxies TCP connections between internal servers and external clients. It establishes TCP connection with external client and then it establishes TCP connection with internal server. TCP connection tables are cached on Proxy Firewall to indicate how to transform following packets belonging to this TCP connection. External Client Firewall Internal server |----- TCP SYN ----->| |<-----SYN/ACK ------| |-------ACK ----->| |--------TCP SYN ------>| |<-------SYN/ACK -------| |--------ACK ------>| |-------DATA ------>|--------DATA ------>| |<------DATA -------|<-------DATA -------| Figure 7: Proxy Firewall Gu & Fan Expires December 10, 2011 [Page 14] Internet-Draft policy and dynamic information migration June 2011 ------------------------------------------------- | Gateway | ------------------------------------------------- ---------------- /* \ / *\ |TCP Conn Table| /* \ / *\ No corresponding ---------------- /* \ / *\ TCP Conn Table ------ **** -------- -------- -------- -------- ****>------ |FW-A|-----| AGG1 |----| AGG2 | | AGG3 |----| AGG4 |----- |FW-B| ------ **** -------- -------- -------- -------- \/ ------ |* | | | | | | | /\ |* \ / | | \ / | |* \ / | | \ / | |* \/ | | \/ | |* /\ | | /\ | |* / \ | | / \ | |* / \ | | / \ | |* | | | | | | | ---------- ---------- ---------- ---------- |Switch1 | |Switch2 | |Switch3 | |Switch4 | ---------- ---------- ---------- ---------- |* \ / | | \ / | |* \/ | | \/ | |* /\ | | /\ | |* / \ | | / \ | ---------- ---------- ---------- ---------- |Server1 | |Server2 | |Server3 | |Server4 | ---------- ---------- ---------- ---------- |* | | | |\/ | | | VM1 VM2 VM3 new VM1 Figure 8: VM migration without TCP connection table migration A typical TCP Connection Table includes the following data: tcpConnState: The state of this TCP connection. tcpConnLocalAddress: The local IP address for this TCP connection. tcpConnLocalPort: The local port number for this TCP connection. tcpConnRemAddress: The remote IP address for this TCP connection. tcpConnRemPort: The remote port number for this TCP connection. A TCP Connectin Table could also includes the following information: Gu & Fan Expires December 10, 2011 [Page 15] Internet-Draft policy and dynamic information migration June 2011 Sequence Number: the sequence number in the packet header the sender is going to send. Acknowledgement Number: the sequence number in the packet header the receiver is hoping to receive. Idle time: the time that the tcp connection table hasn't been updated. Assuming TCP Connection Table item is generated for VM1 on Fw-A, the information is as follows: tcpConnState == Established tcpConnLocalAddress == 10.138.3.1 tcpConnLocalPort == 1234 tcpConnRemAddress: == 192.167.22.3 tcpConnRemPort == 4321 VM1 migrates to Server4 under Switch4, without TCP Connection Table items migration. The packets belonging to this TCP Connection will continue coming, which will pass FW-B, instead of FW-A. Because there is no TCP Connection Table for VM1 on FW-B, the following packets belonging to the TCP Connection will be dropped, hence the running service is broken down. 3.2.1.2.3. Cumulative Data One example for cumulative data is unfinished TCP Connection established by a specific VM. In order to avoid TCP SYN flood, Firewall may control the unfinished TCP Connection established by a single end host by setting a threshold. For example, the NM set the threshold to 50, and VM1 has established 30 unfinished TCP connections. If the cumulated TCP connection number isn't migrated to destination devices, the destination device will allow VM1 to establish up to 50 unfinished TCP connections. For the single destination device, the unfinished TCP connections established by VM1 is under control, but for the whole DC, VM1 has established 80 unfinished TCP connections. So VM1 has consume more resoureces than allowed. 3.2.1.2.4. NAT Address Mapping Data center may implement network address translation. Sometimes NAT function is enabled on Firewall. Private IP Add. is assigned to Gu & Fan Expires December 10, 2011 [Page 16] Internet-Draft policy and dynamic information migration June 2011 internal VM. When VM communicate with external client, NAT function assigns a public IP Add. to the communicating internal VM. A mapping between private IP Add. and public IP Add. is recorded on NAT function. Assuming a mapping from Pri-IP-VM1 to Pub-IP-VM1 is generated on FW-A. When VM1 migrates to Server4 without the address mapping, following packets from external client can not be translated to correct Pri-IP-VM1, and vice versa. ------------------------------------------------- | Gateway | ------------------------------------------------- //\ \ / \* Dst: Pub-IP-VM1 Src: Pub-IP-VM1 /* \ / \* No Address mapping ----------------- /* \ / \* from Pub-IP-VM1 |Address Mapping| /* \ / \* to Private-IP-VM1 ----------------- /* \ / \*Packets are dropped ------- ****>-------- -------- ------- ------- ****>------ |NAT-A|------| AGG1 |---| AGG2 | |AGG3 |----| AGG4 |-----|NAT-B| ------- <****-------- -------- ------- -------\/ ------- |* | | | | | | | /\ |* \ / | | \ / | |* \ / | | \ / | |* \/ | | \/ | |* /\ | | /\ | |* / \ | | / \ | |* / \ | | / \ | |* | | | | | | | --------- --------- --------- ---------- |Switch1| |Switch2| |Switch3| |Switch4 | --------- --------- --------- ---------- |* \ / | | \ / | Src: |* \/ | | \/ | Pri-IP-VM1 |* /\ | | /\ | |* / \ | | / \ | --------- --------- --------- ---------- |Server1| |Server2| |Server3| |Server4 | --------- --------- --------- ---------- |* | | | |\/ | | | VM1 VM2 VM3 new VM1 Figure 9: VM migration without NAT Address Mapping migration Gu & Fan Expires December 10, 2011 [Page 17] Internet-Draft policy and dynamic information migration June 2011 3.2.1.3. Load Balancer When a cluster of servers are organized to provide same services, Load Balancer (LB) is used to balance service load between servers. All external requests are sent to LB, before they are redirected to a specific server. First, external clients extablish TCP connection with LB. Then LB decides which specific server should take care of the requests. Two ways to redirect the requests, i.e. transparent LB and proxy LB. The following dynamic information applies for both ways. 3.2.1.3.1. Connection Table Layer 4 LB identifies and makes load-balancing decesion by Layer 4 Protocol, e.g. TCP. Layer 4 LB generates TCP connection table which is similar to TCP connection table on Firewall. External Client Load Balancer Internal server | ------- TCP SYN ------->|-------TCP SYN ----->| |<--------SYN/ACK --------|<------SYN/ACK ------| |---------ACK ------->|-------ACK ----->| |---------HTTP REQ ------->|-------HTTP REQ----->| |<--------HTTP ACK --------|<------HTTP ACK------| |---------DATA ------->|-------DATA ----->| |<--------DATA --------|<------DATA ------| Figure 10: Layer 4 Load Balancing Layer 5 LB identifies and makes load-balancing decesion by Layer 5 protocol, e.g. HTTP, SMTP and FTP, that is found in packet payload. The Layer 5 information could be HTTP URL, HTTP cookie, or HTTP header field user agent. Layer 5 LB generates connection table for HTTP, SMTP, and FTP, etc. External Client Load Balancer Internal server | ------- TCP SYN ----->| |<--------SYN/ACK ------| |---------ACK ----->| |---------HTTP Req ----->| |-------TCP SYN ----->| |<------SYN/ACK ------| |-------ACK ----->| |-------HTTP Req----->| |---------HTTP ACK ----->|-------HTTP ACK----->| |---------DATA ----->|-------DATA ----->| |<--------DATA ------|<------DATA ------| Figure 11: Layer 5 Load Balancing shows the result of lack of Connection table on destination Gu & Fan Expires December 10, 2011 [Page 18] Internet-Draft policy and dynamic information migration June 2011 LB. ------------------------------------------------- | Gateway | ------------------------------------------------- ------------- /* \ / *\ No VM1's Conn Table |Conn Table | /* \ / *\Packets could be dropped ------------- /* \ / *\or mis-redirected ------ <**** ------- -------- ------- ------- ****>------- |LB-A|------| AGG1 |---| AGG2 | | AGG3|---|AGG4 |----- |LB-B| ------ ****> ------- -------- ------- ------- <**** ------ |* | | | | | | |* |* \ / | | \ / |* |* \ / | | \ / |* |* \/ | | \/ |* |* /\ | | /\ |* |* / \ | | / \ |* |* / \ | | / \ |* |* | | | | | | |* ---------- ---------- --------- --------- |Switch1 | |Switch2 | |Switch3| |Switch4| ---------- ---------- --------- --------- |* \ / | | \ / |* |* \/ | | \/ |* |* /\ | | /\ |* |* / \ | | / \ |* ---------- ---------- ---------- ---------- |Server1 | |Server2 | |Server3 | |Server4 | ---------- ---------- ---------- ---------- |* | |* | |\/ | |\/ | VM1 VM2 VM3 new VM1 Figure 12: VM migration without Connection table migration 3.2.1.3.2. Sticky Table Session persistence refers to the capability of the Load alancer to logically group multiple connections from the same client transaction to the service. Session persistence is also known as stickiness or sticky connections because the goal is to stick two or more connections together as part of a single session. This grouping is done to ensure the connections are handled and forwarded to the groups of servers that are aware of and expect to see the remaining connections. This ensures that the client has a successful interaction with the application. LB usually keeps a sticky table for session persistence, which is Gu & Fan Expires December 10, 2011 [Page 19] Internet-Draft policy and dynamic information migration June 2011 used to match incoming requests to existing connections so that they can be grouped together. A sticky table could include the following information. Sticky groups Group name (sticky group identifier) Type (sticky group type, according to stick methods) Sticky server farm Backup server farm Aggregate state (to indicate whether the state of the backup server is tied to the virtual server state) Sticky enabled on backup server farm (to indicate whether the backup server farm is sticky) Replicate (to indicate whether to replicate sticky entries on the standby device) Timeout (a mechanism to age out sticky table entries) Timeout active connections (to specify whether to time out sticky table entries if active connections exists after the sticky timer expires) Sticky methods Sticky connections Real servers In , two connections, represented by * line and $ line, are redirected to VM1, and a sticky table is generated on LB-A. VM1 migrates to new VM1, without Sticky table migrates with VM1. A new connection, represented by & line, arriving at LB-B, which can not know that this connection should be redirected to new VM1, because of lack of sticky table. As a result, LB-B redirect the new connection to other VM than new VM1. This mis-redirection could cause key information lost. For example, in e-business, refer to Gu & Fan Expires December 10, 2011 [Page 20] Internet-Draft policy and dynamic information migration June 2011 External Client-X * $ & * $ & * $ & -------------------------------------------- | Gateway | -------------------------------------------- /*$ \ /\*$& /*$ \ / \*$& No Sticky table for client-X ------------- /*$ \ / \*$& Connections from client-X |Sticky Table| /*$ \ / \*$& may be redirected to ------------- /*$ \ / \*$& different servers ----- <*$*$*------- ------ ------- -------- *$&*> ------ |LB-A|------| AGG1 |----| AGG2| | AGG3|----| AGG4 |----- |LB-B| ----- *$*$> ------- ------ ------- --------<*$&* ------ |*$ | | | | | | |*$& |*$ \ / | | \ / |*$& |*$ \ / | | \ / |*$& |*$ \/ | | \/ |*$& |*$ /\ | | /\ |*$& |*$ / \ | | / \ |*$& |*$ / \ | | / \ |*$& |*$ | | | | | | |*$& --------- -------- --------- ---------- |Switch1| |Switch2| |Switch3| |Switch4 | --------- -------- --------- ---------- |*$ \ / | | \ / |*$& |*$ \/ | | \/ |*$& |*$ /\ | | / \ |*$& |*$ / \ | | / \ |*$& ---------- ---------- --------- ---------- |Server1 | |Server2 | |Server3| |Server4 | ---------- ---------- --------- ---------- |$% | |& |*$ |\/ | |\/ |\/ VM1 VM2 VM3 new VM1 ****** $$$$$$ Threee connectons from the same external clients. &&&&&& Figure 13: VM migration without Sticky table migration While server or server farm move to a new location under a new LB, in order to keep the existing connections and sessions, as well as session persistence, both connection table and sticky table need to move with servers. Gu & Fan Expires December 10, 2011 [Page 21] Internet-Draft policy and dynamic information migration June 2011 4. Scenarios In previous section, we introduce two classes of policies, i.e. static policies and dynamic information. The introduction is based on a simplized networking architecture and intentionally omit other factors. The polices in the example network implies <1:1> partner, that is polices need to move from one device to another. However, in real world, network architectures are much complicate than the simplized example networking. We introduce several scenarios in this section. Different architecture raise different requirements and migration partner style. 4.1. Policy migration within a single site A DC site means a geographic location, which could include one subnet, or several subnets. A VM migrates to a new location which is in the same subnet as original location. In this case, there might not be policies on Middleboxes that need to be migrated, since new VM1 is under the same Middleboxes as VM1. But dynamic information on switches need to migrate as well. Gu & Fan Expires December 10, 2011 [Page 22] Internet-Draft policy and dynamic information migration June 2011 ------------------------------------------------- | Gateway | ------------------------------------------------- / \ / \ / \ / \ ------ -------- -------- -------- -------- ------ |FW-A|---| AGG1 |----| AGG2 | | AGG3 |----| AGG4 |----- |FW-B| ------ -------- -------- -------- -------- ------ | | | | | | | | | \ / | | \ / | | \ / | | \ / | | \/ | | \/ | | /\ | | /\ | | / \ | | / \ | | / \ | | / \ | | | | | | | | | ---------- ---------- ---------- ---------- |Switch1 | |Switch2 | |Switch3 | |Switch4 | ---------- ---------- ---------- ---------- | \ / | | \ / | | \/ | | \/ | | /\ | | /\ | | / \ | | / \ | ---------- ---------- ---------- ---------- |Server1 | |Server2 | |Server3 | |Server4 | ---------- ---------- ---------- ---------- | | VM1 new VM1 Figure 14: Policy migration within a single DataCenter site 4.2. Polices migration in asymmetric architecture The network architecture could be asymmetric. Refer to Fig16. In this case, there is possible to encounter <1:n> or partnership. The former partnership implies policies on one orginal device might need to migrate to n destination devices. The latter partnership implies policies on multiple original devices might need to migrate to one destination devices. For example, when VM1 migrate from Server 4 to Server1, the dynamic information on both Switch4 and ToR need to migrate to Switch1, which is 2:1 partnership。 Gu & Fan Expires December 10, 2011 [Page 23] Internet-Draft policy and dynamic information migration June 2011 ------------------------------------------------- | Gateway | ------------------------------------------------- / \ / \ / \ / \ ------ ------- ------- -------- -------- ------ |FW-A|---| AGG1|----| AGG2 | | AGG3 |----| AGG4 |---|FW-B| ------ ------- ------- -------- -------- ------ | | | | | \ / | | \ / | | \/ | | \ / | | /\ | | \/ | ---------- ---------- | /\ | |Switch3 | |Switch4 | | / \ | ---------- ---------- | / \ | | \ / | | | | | | \/ | --------- ---------- | /\ | |Switch1| |Switch2 | ---------- ---------- --------- ---------- | ToR | | ToR | | \ / | ---------- ---------- | \/ | | \/ | | /\ | | /\ | | / \ | | / \ | ---------- --------- ---------- ---------- |Server1 | |Server2| |Server3 | |Server4 | ---------- --------- ---------- ---------- | | new VM1 VM1 Figure 15: Polices migration in asymmetric architecture 4.3. Policies migration between DC sites Currently, most VM hot migration is limited in the same data center site. But in the furture there might be requirements for VM migration between data center sites, as shown in . A use case for this scenario is resource coordination between data center sites. A DC provier has two data center sites in different countries, and both of them serve external clients with similar applications. Some of the applications are high priority applications, others are normal priority ones. At first, requests from external clients are redirected to the data center site which are physically close to the external clients. However, at some time, one data center is approaching its capability limits, which could be servers capability limits (i.e. few server capability are available for new requests) or network capability limits (i.e. network can not support so much packet processing requirement, and packet loss happens) and performance is degraded. In order to guarantee high priority Gu & Fan Expires December 10, 2011 [Page 24] Internet-Draft policy and dynamic information migration June 2011 applications, and try best to make fewest damage to normal priority applications, some VMs, who provide normal priority applications, can be migrated to the other data center sites. In this case, policies on switches, middleboxes and gateways need to migrate to new devices on the other data center site. Policies migration between data centers also need to consider the asymmetric structure. ------------------ --------------------- | Gateway | | Gateway2 | ------------------ --------------------- / \ / \ / \ / \ ------ -------- -------- -------- -------- ------ |FW-A|---| AGG1 |----| AGG2 | | AGG3 |----| AGG4 |-----|FW-B| ------ -------- -------- -------- -------- ------ | | | | | | | | | \ / | | \ / | | \ / | | \ / | | \/ | | \/ | | /\ | | /\ | | / \ | | / \ | | / \ | | / \ | | | | | | | | | ---------- ---------- ---------- ---------- |Switch1 | |Switch2 | |Switch3 | |Switch4 | ---------- ---------- ---------- ---------- | \ / | | \ / | | \/ | | \/ | | /\ | | /\ | | / \ | | / \ | ---------- ---------- ---------- ---------- |Server1 | |Server2 | |Server3 | |Server4 | ---------- ---------- ---------- ---------- | | VM1 new VM1 Figure 16: Polices migration between DC sites 5. General Considerations In this section, we enumerate some general considerations on Policy migration. Only with deep consideration on these factors can we achieve a successful VM migration and policy migration. Gu & Fan Expires December 10, 2011 [Page 25] Internet-Draft policy and dynamic information migration June 2011 5.1. Time-sensitive VM migration needs a period to finish memory and register copy. Fig.3 shows the VMware VMotion process. There are three points we should pay attention to. Pre-copy period: VM begins to prepare for migration. In this period, VM pre-copy memory state to the new VM on destination device. The original VM is still power on and service is still running, which means the memory and register could keep changing. The new VM is power-on. VM not running period: The end phase of memory copy. In this period, original VM stop running service, the memory will not change. Original VM finish copying the rest changed memory and register to new VM. New VM is still power-on. VM power-off point: After original VM receives the OK message from new VM, it turns off the power, and meanwhile the new memory starts to run. We can see that it's unrealistic to make a 'zero delay' VM migration, because there is at least about 1 second period (VM not running period) when neither VM is running. Assuming there is a 3rd-party device can GET and SET dynamic information.(This is only an possible way to migrate polices. Polices could also be migrated distributedly. The author has no preferrence to any approaches in this draft.) The 3rd-party device GET dynamic information at Time A, and finish SET at Time B. At Time A, the Sequence Number of VM1's TCP Connection is 99. After 3rd- party device GET dynamic information, VM1's TCP connection keeps transferring packets and Sequence Number increase to 110, until VM not running period begins. During VM not running period, no TCP packet is acknowledged by VM1, so the Sequence Number is 110. At Time B, the destination Firewall is SET by Sequence Number 99. When new VM1 starts, the packets belonging to VM1's TCP connection comes to Firewall-B with Sequence Number 111. Since the receiving Sequence Number doesn't equal to the Acknowleadge Sequence Number of Firewall-B, this packet will be dropped and the running service is broken down. Another example: After Time A, VM1 may establish new TCP connections, which are not migrated to new Firewall, then following packets belonging to new TCP connections will be dropped and running services are disrupted. Gu & Fan Expires December 10, 2011 [Page 26] Internet-Draft policy and dynamic information migration June 2011 ------------------------------------------------------- ^ || | Power-on destination VM ^ | || | | | ||--->| --------------------------- VMotion VM || | Pre-copy memory state abortable running ||--->| |-------->Time A on source|| | | /\ | ||--->| |Dynamic Information | ||--->| |keep changing V || | | \/ ---------------------------------------------------|----------- ^ |---->| Checkpoint-save src VM and | | |---->| transfer state | | | |-----------------------------------| VM not |---->| transfer remaining changed memory |-------->Time B running | | and checkpoint-restore dst VM V | | |-------------------------------------- ~1sec |<----| send restore OK V | | ------------------------------------------------------ | || Power-off source VM | || VM running on destination Figure 17: VMware VMotion process 5.2. Notification As Section 5.1shows, policy migration is very sensitive to migration time. Either later or earlier may cause service disruption. The best migration time is after the original VM stops running and before the destination VM begins running. Only Hypervisor knows the acurate VM status. So we need a notification from server side, Hypervisor in specific, to tell network side when to migrate polices. In fact, the author has presented the problem to IEEE 802.1 DCB task group, which defines VSI Discovery and Configuration protocols (VDP). DCB has recognized this problem and make effort within its scope. DCB has extended VDP, in 802.1 Qbg, to enable notification from Hypervisor to adjacent bridge. DCB expects corresponding IETF WG to make furthur effort to distribute the notification to devices from Layer 3 to Layer 7. And IEEE 802.1 DCB working group would like to see further progress at IETF on this problem. 5.3. Functionality Data center architecture could be heterogeneous, both in physical structure and functionality. Section 4.2 and shows the asymmetric physical structure. The following figure shows the case Gu & Fan Expires December 10, 2011 [Page 27] Internet-Draft policy and dynamic information migration June 2011 where functionality on devices is heterogenous. While VM migrates from one location to a heterogeneous location, it's necessary to negotiate and make sure that essential functions are supported at destination location. Otherwise, VM migration maybe fail. Even VM successfully migrates, there might be security risk and/or service failure. VM Managers who want to migrate VM between heterogeneous architecutre must be aware of the risk. shows two examples of functionality heterogeneous. FW-A is the source Firewall with packet filtering function, and a dynamic ACL is generated on FW-A for VM1. FW-B is the destination Firewall without packet filtering funtion. In this case, dynamic ACL on FW-A can not be implemented on FW-B. The similar case happens on Switch1 and Switch4. Switch1 has DHCP snooping function enabled, while Switch has not. DHCP snooping table from Switch1 can not be implemented on Switch4. ------------------------------------------------- | Gateway | ------------------------------------------------- / \ / \ / \ / \ ------ -------- -------- ------ ------- ------ |FW-A|----| AGG1 |----| AGG2 | | AGG3|----| AGG4|---|FW-B| ------ -------- -------- ------ ------- ------ with | | | | | | | | without Packet | \ / | | \ / | Packet filtering filtering | \ / | | \ / | | \/ | | \/ | | /\ | | /\ | | / \ | | / \ | | / \ | | / \ | | | | | | | | | ---------- ---------- --------- --------- with |Switch1 | |Switch2 | |Switch3| |Switch4| withou DHCP ---------- ---------- --------- --------- DHCP Snooping | \ / | | \ / | Snooping | \/ | | \/ | | /\ | | /\ | | / \ | | / \ | ---------- ---------- ---------- ---------- |Server1 | |Server2 | |Server3 | |Server4 | ---------- ---------- ---------- ---------- | | VM1 new VM1 Figure 18: Heterogeneous functions on devices Gu & Fan Expires December 10, 2011 [Page 28] Internet-Draft policy and dynamic information migration June 2011 5.4. Resource Capability Even if destination devices can support specific function that is required by dynamic information migration, there might be not enough resources to implement migrated polices. For example, there are 5 connection state items related to VM1 on source LB. However, the destination LB has only 4 table items available. That means the destination LB doesn't have enough resource to support this VM migration, and policies migration on network devices may fail. 5.5. Migration Feedback Sometimes, VM manager has ensure, by some way, that proper functionality and plenty of resources are available on destionation devices, by which we mean all the devices that need to handle VM's packets, but dynamic information migration still fails. In this case, VM manager or Hypervisor needs to know the results of policy migration. The feedback from network can help VM Manager to decide whether to rollback the migration or continue migration with risk. 6. Security Considerations The policies and dynamic information described above are all about security. Besides, we need to be careful to avoid poisoned polices from untrusted source. That means no mather how the polices are migrated, be it distributed or centralized way, authentication and verification are required. A reliable notifation from server side to network side is also necessary, so that the destination and original devices can be sure that a real VM migration happens. 7. Acknowledgments I would like to thank the following people for contributing to this draft: Ning Zong, David harrington, Linda dunbar, Susan Hares, Serge manning, Barry Leiba, Jiang xingfeng, Song Wei, Robert Sultan, and many others. 8. References 8.1. Normative Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. Gu & Fan Expires December 10, 2011 [Page 29] Internet-Draft policy and dynamic information migration June 2011 [RFC3303] , P., "Middlebox communication architecture and framework", August 2002. 8.2. Informative Reference [Data_Center_Fundamentals] , Cisco Press., "Data Center Fundamentals", 2003. Authors' Addresses Gu Yingjie Huawei No. 101 Software Avenue Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-56624760 Fax: +86-25-56624702 Email: guyingjie@huawei.com Fan Yongbing China Telecom No. 109 Zhongshan Road West Guangzhou, Guangdong Province P.R.China Phone: 86-20-38639121 Fax: 86-20-38639487 Email: fanyb@gsta.com Gu & Fan Expires December 10, 2011 [Page 30] --Boundary_(ID_syjEGnl9pB2WJrEh/zMbQg)-- From gorry@erg.abdn.ac.uk Mon Jun 20 01:32:23 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8833C11E8086 for ; Mon, 20 Jun 2011 01:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 4Bg-hn-cPxFe for ; Mon, 20 Jun 2011 01:32:23 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 90CBD11E8080 for ; Mon, 20 Jun 2011 01:32:21 -0700 (PDT) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p5K8WDHk019495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Jun 2011 09:32:14 +0100 (BST) Message-ID: <4DFF058D.1010309@erg.abdn.ac.uk> Date: Mon, 20 Jun 2011 09:32:13 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsvwg WG Subject: Call for WG Adoption of draft-polk-tsvwg-intserv-multiple-tspec-06 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: "James M. Polk" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 08:32:23 -0000 The authors of "IntServ Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1" (draft-polk-tsvwg-intserv-multiple-tspec) requests that this is adopted as WG item. This draft defines extensions to Integrated Services (IntServ) allowing multiple traffic specifications and multiple flow specifications to be conveyed in the same Resource Reservation Protocol (RSVPv1) reservation message exchange. This ability helps optimize an agreeable bandwidth through a network between endpoints in a single round trip There was hum indicating general WG support for this at the last IETF in Prague. I applied to the AD to amend our Charter to allow this work, which was approved. So we are now ready to make a formal decision and this email is to allow people to confirm that there is sufficient energy to complete this work in TSVWG. * PLEASE send an email to this list if you think adopting this document in TSVWG is a good or bad idea. * Please also indicate if you are willing to REVIEW such a document during its development - our AD has indicated that we expect to have at least 4 people who commit to review this within the WG, perform a detailed review in WGLC and provide appropriate comments if called upon during the IESG review. If you can promise to do this please say! Please provide any comments at the latest by Wednesday 29th June 2011. Best regards Gorry Fairhurst (TSVWG Co-Chair) From bdavie@cisco.com Mon Jun 20 05:24:40 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4029E8021 for ; Mon, 20 Jun 2011 05:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 rQ6Au6pB2Q6W for ; Mon, 20 Jun 2011 05:24:39 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 00F5B9E8020 for ; Mon, 20 Jun 2011 05:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bdavie@cisco.com; l=1596; q=dns/txt; s=iport; t=1308572679; x=1309782279; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aHOwrkzxhvLHBH7Kc8hHjjRp+ESfyGsfAy3N9wpg52g=; b=PxMKt06H0hfKwp6ISoKzoSTrZQtF7aNFVo2cQO6esSon9X60bttTpacm 82CxrLWir1NlegYfoqC2N03xE25IP9ZHS31d3h8SM4jxbxwMUzlNkYkCk glrYv5NPqFLM8f8IVEVxK+kIMfb8ymuPPLJntVTNb2Ca4tJRbwn/w493J s=; X-IronPort-AV: E=Sophos;i="4.65,394,1304294400"; d="scan'208";a="36053075" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 20 Jun 2011 12:24:35 +0000 Received: from [10.32.241.77] ([10.32.241.77]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5KCOVIQ024846; Mon, 20 Jun 2011 12:24:32 GMT Subject: Re: Call for WG Adoption of draft-polk-tsvwg-intserv-multiple-tspec-06 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bruce Davie In-Reply-To: <4DFF058D.1010309@erg.abdn.ac.uk> Date: Mon, 20 Jun 2011 08:24:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8A85F10E-9A41-4901-A0F1-9F654B20C213@cisco.com> References: <4DFF058D.1010309@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1084) Cc: "James M. Polk" , tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:24:40 -0000 On Jun 20, 2011, at 4:32 AM, Gorry Fairhurst wrote: > The authors of "IntServ Extension to Allow Signaling of Multiple = Traffic Specifications and Multiple Flow Specifications in RSVPv1" = (draft-polk-tsvwg-intserv-multiple-tspec) requests that this is adopted = as WG item. >=20 > This draft defines extensions to Integrated Services (IntServ) > allowing multiple traffic specifications and multiple flow > specifications to be conveyed in the same Resource Reservation > Protocol (RSVPv1) reservation message exchange. This ability helps > optimize an agreeable bandwidth through a network between endpoints > in a single round trip >=20 > There was hum indicating general WG support for this at the last IETF = in Prague. I applied to the AD to amend our Charter to allow this work, = which was approved. So we are now ready to make a formal decision and = this email is to allow people to confirm that there is sufficient energy = to complete this work in TSVWG. >=20 >=20 > * PLEASE send an email to this list if you think adopting this = document in TSVWG is a good or bad idea. Good idea (I'm sure my view will come as a shock) >=20 > * Please also indicate if you are willing to REVIEW such a document = during its development - our AD has indicated that we expect to have at = least 4 people who commit to review this within the WG, perform a = detailed review in WGLC and provide appropriate comments if called upon = during the IESG review. If you can promise to do this please say! >=20 I will provide (another) review. Bruce From lberger@labn.net Mon Jun 20 06:07:16 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD8511E817C for ; Mon, 20 Jun 2011 06:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.132 X-Spam-Level: X-Spam-Status: No, score=-102.132 tagged_above=-999 required=5 tests=[AWL=0.467, 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 EY9n5484Y-jl for ; Mon, 20 Jun 2011 06:07:15 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 748DF11E8171 for ; Mon, 20 Jun 2011 06:07:15 -0700 (PDT) Received: (qmail 5304 invoked by uid 0); 20 Jun 2011 13:07:15 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 20 Jun 2011 13:07:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=KAbCTCfZCNq8rfn/LvGcz5UYupNjC7puavGXxu1uu/66GagGcnbrhVBFU8xeM2KwzLxUzSM2dlIAQrvXatDdqnFyxZe+RLenoMldp0mVA+BoHG54lvAIEgI2ILSH20gH; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1QYeCB-0001zO-0o; Mon, 20 Jun 2011 07:07:15 -0600 Message-ID: <4DFF4608.4010900@labn.net> Date: Mon, 20 Jun 2011 09:07:20 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk Subject: Re: Call for WG Adoption of draft-polk-tsvwg-intserv-multiple-tspec-06 References: <4DFF058D.1010309@erg.abdn.ac.uk> In-Reply-To: <4DFF058D.1010309@erg.abdn.ac.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "James M. Polk" , tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:07:16 -0000 Gorry, See below. On 6/20/2011 4:32 AM, Gorry Fairhurst wrote: > The authors of "IntServ Extension to Allow Signaling of Multiple Traffic > Specifications and Multiple Flow Specifications in RSVPv1" > (draft-polk-tsvwg-intserv-multiple-tspec) requests that this is adopted > as WG item. > > This draft defines extensions to Integrated Services (IntServ) > allowing multiple traffic specifications and multiple flow > specifications to be conveyed in the same Resource Reservation > Protocol (RSVPv1) reservation message exchange. This ability helps > optimize an agreeable bandwidth through a network between endpoints > in a single round trip > > There was hum indicating general WG support for this at the last IETF in > Prague. I applied to the AD to amend our Charter to allow this work, > which was approved. So we are now ready to make a formal decision and > this email is to allow people to confirm that there is sufficient energy > to complete this work in TSVWG. > > > * PLEASE send an email to this list if you think adopting this document > in TSVWG is a good or bad idea. a good idea. > > * Please also indicate if you are willing to REVIEW such a document > during its development - our AD has indicated that we expect to have at > least 4 people who commit to review this within the WG, perform a > detailed review in WGLC and provide appropriate comments if called upon > during the IESG review. If you can promise to do this please say! I'm willing. (I have already provided some comments off line that I look forward to discussing on-list, assuming the draft becomes a WG document.) Lou > > > Please provide any comments at the latest by Wednesday 29th June 2011. > > > Best regards > > Gorry Fairhurst > (TSVWG Co-Chair) > > > > > > From flefauch@cisco.com Mon Jun 20 06:54:32 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FE111E8150 for ; Mon, 20 Jun 2011 06:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.371 X-Spam-Level: X-Spam-Status: No, score=-9.371 tagged_above=-999 required=5 tests=[AWL=1.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 l6afkaq0KWI8 for ; Mon, 20 Jun 2011 06:54:31 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id DF01D11E808A for ; Mon, 20 Jun 2011 06:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=4628; q=dns/txt; s=iport; t=1308578071; x=1309787671; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=wBaUS4wnlxEg1ItNqnpqM4C0kZwB2/FwcuYo6oGOt6A=; b=UnNO4mU1sHwZVyB4qZj6cjUWRnwgcRId36Z7HxSJNPsVd7yN06MwgXPj dRE2l59J9D2fU08STSeLzBDnEolhKy4/ETd9Mhvmoj5/yTJjvg3xZDJH/ Cstw8MyijCxfyrKfZDChgshb6yK5ObsZ6a5Clf4yc8i0RSX1Fg1NuFqJF A=; X-IronPort-AV: E=Sophos;i="4.65,394,1304294400"; d="scan'208,217";a="36072402" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 20 Jun 2011 13:54:30 +0000 Received: from ams-flefauch-8718.cisco.com (ams-flefauch-8718.cisco.com [10.55.161.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5KDsT41007616; Mon, 20 Jun 2011 13:54:29 GMT Subject: Re: Call for WG Adoption of draft-polk-tsvwg-intserv-multiple-tspec-06 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-622--441491285 From: Francois Le Faucheur In-Reply-To: <4DFF058D.1010309@erg.abdn.ac.uk> Date: Mon, 20 Jun 2011 15:56:30 +0200 Message-Id: <6A077FD4-9847-4663-AA9B-CDC66E68CBEE@cisco.com> References: <4DFF058D.1010309@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1084) Cc: "James M. Polk" , tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:54:32 -0000 --Apple-Mail-622--441491285 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Gorry, It is a good idea. As you know I already provided comments on this doc, but I will review = it again during its development. In fact, it is on my ToDo list before = Quebec City meeting. Thanks Francois On 20 Jun 2011, at 10:32, Gorry Fairhurst wrote: > The authors of "IntServ Extension to Allow Signaling of Multiple = Traffic Specifications and Multiple Flow Specifications in RSVPv1" = (draft-polk-tsvwg-intserv-multiple-tspec) requests that this is adopted = as WG item. >=20 > This draft defines extensions to Integrated Services (IntServ) > allowing multiple traffic specifications and multiple flow > specifications to be conveyed in the same Resource Reservation > Protocol (RSVPv1) reservation message exchange. This ability helps > optimize an agreeable bandwidth through a network between endpoints > in a single round trip >=20 > There was hum indicating general WG support for this at the last IETF = in Prague. I applied to the AD to amend our Charter to allow this work, = which was approved. So we are now ready to make a formal decision and = this email is to allow people to confirm that there is sufficient energy = to complete this work in TSVWG. >=20 >=20 > * PLEASE send an email to this list if you think adopting this = document in TSVWG is a good or bad idea. >=20 > * Please also indicate if you are willing to REVIEW such a document = during its development - our AD has indicated that we expect to have at = least 4 people who commit to review this within the WG, perform a = detailed review in WGLC and provide appropriate comments if called upon = during the IESG review. If you can promise to do this please say! >=20 >=20 > Please provide any comments at the latest by Wednesday 29th June 2011. >=20 >=20 > Best regards >=20 > Gorry Fairhurst > (TSVWG Co-Chair) >=20 >=20 --Apple-Mail-622--441491285 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Gorry,

It is a good idea.
As you know I = already provided comments on this doc, but I will review it again during = its development. In fact, it is on my ToDo list before Quebec City = meeting.

Thanks

Francois=

On 20 Jun 2011, at 10:32, Gorry Fairhurst = wrote:

The authors of "IntServ Extension to Allow Signaling = of Multiple Traffic Specifications and Multiple Flow Specifications in = RSVPv1" (draft-polk-tsvwg-intserv-multiple-tspec) requests that this is = adopted as WG item.

  This draft defines extensions to = Integrated Services (IntServ)
  allowing  multiple = traffic specifications and multiple flow
  specifications = to be conveyed in the same Resource Reservation
  Protocol = (RSVPv1) reservation message exchange. This ability helps
=   optimize an agreeable bandwidth through a network between = endpoints
  in a single round trip

There was hum = indicating general WG support for this at the last IETF in Prague. I = applied to the AD to amend our Charter to allow this work, which was = approved. So we are now ready to make a formal decision and this email = is to allow people to confirm that there is sufficient energy to = complete this work in TSVWG.


* PLEASE send an email to this = list if you think adopting this document in TSVWG is a good or bad = idea.

* Please also indicate if you are willing to REVIEW such a = document during its development - our AD has indicated that we expect to = have at least 4 people who commit to review this within the WG, perform = a detailed review in WGLC and provide appropriate comments if called = upon during the IESG review. If you can promise to do this please = say!


Please provide any comments at the latest by Wednesday = 29th June 2011.


Best regards

Gorry Fairhurst
(TSVWG = Co-Chair)



, tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 14:03:56 -0000 Hi Gorry, Its a good idea, and the list already has my detailed comments. cheers, -ken On Jun 20, 2011, at 4:32 AM, Gorry Fairhurst wrote: > The authors of "IntServ Extension to Allow Signaling of Multiple = Traffic Specifications and Multiple Flow Specifications in RSVPv1" = (draft-polk-tsvwg-intserv-multiple-tspec) requests that this is adopted = as WG item. >=20 > This draft defines extensions to Integrated Services (IntServ) > allowing multiple traffic specifications and multiple flow > specifications to be conveyed in the same Resource Reservation > Protocol (RSVPv1) reservation message exchange. This ability helps > optimize an agreeable bandwidth through a network between endpoints > in a single round trip >=20 > There was hum indicating general WG support for this at the last IETF = in Prague. I applied to the AD to amend our Charter to allow this work, = which was approved. So we are now ready to make a formal decision and = this email is to allow people to confirm that there is sufficient energy = to complete this work in TSVWG. >=20 >=20 > * PLEASE send an email to this list if you think adopting this = document in TSVWG is a good or bad idea. >=20 > * Please also indicate if you are willing to REVIEW such a document = during its development - our AD has indicated that we expect to have at = least 4 people who commit to review this within the WG, perform a = detailed review in WGLC and provide appropriate comments if called upon = during the IESG review. If you can promise to do this please say! >=20 >=20 > Please provide any comments at the latest by Wednesday 29th June 2011. >=20 >=20 > Best regards >=20 > Gorry Fairhurst > (TSVWG Co-Chair) >=20 >=20 From jgunn6@csc.com Mon Jun 20 08:23:48 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303A321F85FB; Mon, 20 Jun 2011 08:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 21gBSVc6rpdc; Mon, 20 Jun 2011 08:23:45 -0700 (PDT) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 86CD121F8652; Mon, 20 Jun 2011 08:23:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-12.tower-85.messagelabs.com!1308583423!8664102!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 17761 invoked from network); 20 Jun 2011 15:23:43 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-12.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Jun 2011 15:23:43 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id p5KFNfQ2016695; Mon, 20 Jun 2011 11:23:42 -0400 In-Reply-To: <4DFF058D.1010309@erg.abdn.ac.uk> References: <4DFF058D.1010309@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk MIME-Version: 1.0 Subject: Re: Call for WG Adoption of draft-polk-tsvwg-intserv-multiple-tspec-06 X-KeepSent: 98B4E914:45E5CB13-852578B5:00548E38; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Mon, 20 Jun 2011 11:23:40 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 06/20/2011 11:22:12 AM, Serialize complete at 06/20/2011 11:22:12 AM Content-Type: multipart/alternative; boundary="=_alternative 0054928D852578B5_=" Cc: "James M. Polk" , tsvwg WG , tsvwg-bounces@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:23:48 -0000 This is a multipart message in MIME format. --=_alternative 0054928D852578B5_= Content-Type: text/plain; charset="US-ASCII" Good idea. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: Gorry Fairhurst To: tsvwg WG Cc: "James M. Polk" Date: 06/20/2011 04:33 AM Subject: Call for WG Adoption of draft-polk-tsvwg-intserv-multiple-tspec-06 The authors of "IntServ Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1" (draft-polk-tsvwg-intserv-multiple-tspec) requests that this is adopted as WG item. This draft defines extensions to Integrated Services (IntServ) allowing multiple traffic specifications and multiple flow specifications to be conveyed in the same Resource Reservation Protocol (RSVPv1) reservation message exchange. This ability helps optimize an agreeable bandwidth through a network between endpoints in a single round trip There was hum indicating general WG support for this at the last IETF in Prague. I applied to the AD to amend our Charter to allow this work, which was approved. So we are now ready to make a formal decision and this email is to allow people to confirm that there is sufficient energy to complete this work in TSVWG. * PLEASE send an email to this list if you think adopting this document in TSVWG is a good or bad idea. * Please also indicate if you are willing to REVIEW such a document during its development - our AD has indicated that we expect to have at least 4 people who commit to review this within the WG, perform a detailed review in WGLC and provide appropriate comments if called upon during the IESG review. If you can promise to do this please say! Please provide any comments at the latest by Wednesday 29th June 2011. Best regards Gorry Fairhurst (TSVWG Co-Chair) --=_alternative 0054928D852578B5_= Content-Type: text/html; charset="US-ASCII"
Good idea.
Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.


From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: tsvwg WG <tsvwg@ietf.org>
Cc: "James M. Polk" <jmpolk@cisco.com>
Date: 06/20/2011 04:33 AM
Subject: Call for WG Adoption of draft-polk-tsvwg-intserv-multiple-tspec-06




The authors of "IntServ Extension to Allow Signaling of Multiple Traffic
Specifications and Multiple Flow Specifications in RSVPv1"
(draft-polk-tsvwg-intserv-multiple-tspec) requests that this is adopted
as WG item.

   This draft defines extensions to Integrated Services (IntServ)
   allowing  multiple traffic specifications and multiple flow
   specifications to be conveyed in the same Resource Reservation
   Protocol (RSVPv1) reservation message exchange. This ability helps
   optimize an agreeable bandwidth through a network between endpoints
   in a single round trip

There was hum indicating general WG support for this at the last IETF in
Prague. I applied to the AD to amend our Charter to allow this work,
which was approved. So we are now ready to make a formal decision and
this email is to allow people to confirm that there is sufficient energy
to complete this work in TSVWG.


* PLEASE send an email to this list if you think adopting this document
in TSVWG is a good or bad idea.

* Please also indicate if you are willing to REVIEW such a document
during its development - our AD has indicated that we expect to have at
least 4 people who commit to review this within the WG, perform a
detailed review in WGLC and provide appropriate comments if called upon
during the IESG review. If you can promise to do this please say!


Please provide any comments at the latest by Wednesday 29th June 2011.


Best regards

Gorry Fairhurst
(TSVWG Co-Chair)

--=_alternative 0054928D852578B5_=-- From sob@harvard.edu Mon Jun 20 09:54:35 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD28B1F0C5B for ; Mon, 20 Jun 2011 09:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.752 X-Spam-Level: X-Spam-Status: No, score=-102.752 tagged_above=-999 required=5 tests=[AWL=-0.153, 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 5fJl3oVTkbdT for ; Mon, 20 Jun 2011 09:54:34 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietfa.amsl.com (Postfix) with ESMTP id D08151F0C59 for ; Mon, 20 Jun 2011 09:54:34 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 0E585C174BE; Mon, 20 Jun 2011 12:54:34 -0400 (EDT) To: gorry@erg.abdn.ac.uk Subject: Re: Call for WG Adoption of draft-polk-tsvwg-intserv-multiple-tspec-06 In-Reply-To: <4DFF058D.1010309@erg.abdn.ac.uk> Message-Id: <20110620165434.0E585C174BE@newdev.eecs.harvard.edu> Date: Mon, 20 Jun 2011 12:54:34 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 16:54:36 -0000 > * PLEASE send an email to this list if you think adopting this document > in TSVWG is a good or bad idea. I think it is a good (long delayed) idea > * Please also indicate if you are willing to REVIEW such a document > during its development I am Scott From gorry@erg.abdn.ac.uk Tue Jun 21 00:03:46 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B0A11E80C1 for ; Tue, 21 Jun 2011 00:03:46 -0700 (PDT) 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 c6lwR7Gql7QS for ; Tue, 21 Jun 2011 00:03:45 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 4F42C11E80FF for ; Tue, 21 Jun 2011 00:03:44 -0700 (PDT) Received: from Gorry.local (fgrpf.plus.com [212.159.18.54]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id p5L73b21010755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 21 Jun 2011 08:03:38 +0100 (BST) Message-ID: <4E004249.4080006@erg.abdn.ac.uk> Date: Tue, 21 Jun 2011 08:03:37 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tsvwg WG Subject: TSVWG Status June 2011 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 07:03:46 -0000 Here are the current notes from the TSVWG chairs. Several drafts require input or comments from the WG, please use the TSVWG list to discuss these drafts, best wishes, Gorry & James --- TSVWG Status June 2011 --- IDs in RFC Editor Queue: draft-ietf-tsvwg-emergency-rsvp-15 (MISREF) Norm. ref to router alert draft (in INT-area WG, now in AD Evaluation) draft-ietf-tsvwg-iana-ports New revision 25 Oct 2010. This will require a multi-working group LC. draft-ietf-tsvwg-iana-ports-08 was WGL'ed 30-10-2010 WGLC ended Friday, 26th November 2010 New version -09 02/12/2010. Discussion on list during Dec 2010. AD review received 21/12/2010. Proto Write-up sent 19/01/2011. Revised document text agreed, and document sent for publication. Post IESG status reviewed at IETF-80. RFC Editor Queue. Gorry is Shepherd. ------------------------------------------------------------------- IDs in IESG processing: draft-ietf-tsvwg-rsvp-security-groupkeying WGLC of previous version completed. SECDIR review comments received, and updated as version -05. Short WGLC to confirm new text ended August 11th 2010. New version (-09) 22-10-2010. Proto write-up sent 14/12/2010. Publication requested. AD review provided 19 Apr 2011. James is Shepherd. DUE: *** Revised ID required to address review comments. *** ------------------------------------------------------------------- WG Drafts with Chairs: draft-ietf-tsvwg-sctpsocket New Rev -25, 07/01/2011. WGLC complete. WG-29, April 23, 2011 James is Shepherd. DUE: Proto Write-up by Shepherd (James) draft-ietf-tsvwg-sctp-strrst Dependency on this for IPFIX document with RFC-Ed. Benoit Claise to review for IPFIX New revision (-08) 25 Oct 2010. Text on race-condition to be updated before WGLC. New text to address this in revision 04/01/2011. draft-stewart-tsvwg-reconfuse-sctp to assist in consensus WGLC in progress. James is Shepherd. DUE: WG Chairs to evaluate result of WGLC (17-Mar-2011) IETF-80: need to discus whether one in-band mechanism is viable. ------------------------------------------------------------------- WG Drafts: draft-ietf-tsvwg-source-quench (Replaced: draft-gont-tsvwg-source-quench-01.txt) IETF-79 suggested there was interest in this topic. Comments to list in 2010 from: Fred Baker, Antonio DeSimone, James Polk, Gorry Fairhurst, Andrew Yourtchenko, and others. WG agreed the draft should be a work item. More motivation needed to justify the SHOULD cases. New revision 10 Jun 2011 - new text on RTP; - needs clarification of cases where you do not need to follow the SHOULD. Please comment on list. DUE: *** Reviewers needed to volunteer for LC *** draft-ietf-tsvwg-byte-pkt-congest New editor added Jul 2010. New revision 25 Oct 2010. WG -01, June 10, 2011 Previous: Update needed before deciding if ready for WGLC. Gorry reviewed -02 WG-04 14 Mar 2011 DUE: Reviewers need to volunteer for LC Please comment on list. draft-ietf-tsvwg-natsupp-tsvwg (Replaced: draft-stewart-natsupp-tsvw) Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 uploaded as: draft-ietf-natsupp-tsvwg WG -01, June 1, 2011 DUE: Reviews need. draft-ietf-tsvwg-sctp-udp-encap (Replaced: draft-tuexen-sctp-udp-encap) Lars sent a note as AD agreeing to progress this work. Work to be coordinated with DCCP work on encaps. Adopted as a work item 21 Sept 2010 (Gorry). draft-tuexen-sctp-udp-encaps-06, January 10, 2011 DUE: New revision need. ------------------------------------------------------------------- WG action required: draft-polk-tsvwg-intserv-multiple-tspec WG interest in this topic recorded at IETF-78. Charter update would be needed to progress this work. 5 Reviews needed to determine energy/technical direction. Version -05 (presented in Beijing, IETF-79) Version -06 (presented in Prague, IETF-80) RSVP directorate was consulted. 2 reviews from RSVP-DIR received (Bruce Davie, ?). 2 additional reviews promised (Ken Carlberg, Francois LeF). Chairs asked AD for a Charter update (IESG agreed). Draft discussed at IETF-80, and request to update charter agreed. - AD advised 4 named reviewers will be required. DUE: *** Call to adopt by WG, respond by 29 Ju 2011 *** draft-ietf-6man-udpzero was: draft-fairhurst-tsvwg-6man-udpzero Draft was adopted by 6man, please discuss on the 6man list. A WGLC of this draft is expected in 6MAN WG. related draft: draft-ietf-6man-udpchecksums-00 Expected to start WGLC in Jul 2011. This draft will be LC'ed in TSVWG also. ------------------------------------------------------------------- The following have received recent discussion at TSVWG meetings or on the list. Inclusion in the list below does not indicate support for these specific drafts and other contributions are also warmly welcomed. draft-stewart-tsvwg-sctpecn-00 Partially replaces (draft-stewart-tsvwg-sctp-nonce) IETF-78 suggested there was interest in this topic. Please comment to list. Revised uploaded with new name. - The draft needs to be updated for multihoming (IETF-80) - new revision expected April 2011 (IETF-80) WG needs to assess if the new draft should be a work item. draft-briscoe-tsvwg-ecn-encap-guidelines -00 Presented in Prague, IETF-80. - comments at IETF-80 (see minutes) WG needs to assess if the new draft should be a work item. Please comment on list. DUE: Chairs to check liaison status with other SDOs. draft-touch-tsvwg-port-use-00 - Intended to be advice to protocol designers needing a port. 5 people have looked at this document, Prague IETF-80 WG needs to assess if the new draft should be a work item. Please comment on list. DUE: Chairs to discuss with TSV and APPs ADs. draft-nishida-tsvwg-sctp-failover -00 Presented in Prague, IETF-80. - understood not to conflict with draft-tuexen-tsvwg-sctp-multipath Please comment to list. draft-tuexen-tsvwg-sctp-multipath -00 Presented in Prague, IETF-80. - understood not to conflict with draft-nishida-tsvwg-sctp-failover -01, 2010-12-27 Please comment to list. WG chair note: Above two drafts should be read together. ------------------------------------------------------------------- draft-polk-tsvwg-rsvp-app-id-vv-profiles -01 Presented in Beijing, IETF-79. -02, 14-Mar-2011 Presented IET-80. WG needs to assess if the new draft should be a work item. Seek to coordinate with music. Please comment on list. draft-lefaucheur-tsvwg-rsvp-multiple-preemption RSVP directorate to be consulted. - Reviewers: Bruce Davie (awaiting other reviews) Please comment to list. draft-wing-tsvwg-happy-eyeballs-sctp Please comment to list. draft-tuexen-tsvwg-sctp-sack-immediately -05, 2011-01-02 Please comment to list. ------------------------------------------------------------------- Related non-WG items: draft-narayanan-tsvwg-rsvp-resource-sharing Authors to take this draft to CCAMP WG. draft-ietf-behave-sctpnat-03.txt BEHAVE WG item linked to SCTP encapsulation work. ------------------------------------------------------------------ Other news: RSVP Directorate (formed in May 2010) - directorate consulted on Charter to be updated. ------------------------------------------------------------------ From dave.mcdysan@verizon.com Tue Jun 21 07:03:30 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D5411E814F for ; Tue, 21 Jun 2011 07:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 1zt2uTuHkhxA for ; Tue, 21 Jun 2011 07:03:29 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA2211E80B8 for ; Tue, 21 Jun 2011 07:03:26 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p5LE3N7u016792 for ; Tue, 21 Jun 2011 10:03:23 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.65,401,1304294400"; d="scan'208";a="77096429" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 21 Jun 2011 14:03:23 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.164]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Tue, 21 Jun 2011 10:03:23 -0400 To: "gorry@erg.abdn.ac.uk" , tsvwg WG Date: Tue, 21 Jun 2011 10:03:21 -0400 Subject: Re: Call for WG Adoption of draft-polk-tsvwg-intserv-multiple-tspec-06 Thread-Topic: Call for WG Adoption of draft-polk-tsvwg-intserv-multiple-tspec-06 Thread-Index: AcwwG/ta7YuDJQFiQVWeeKz//yko8g== Message-ID: In-Reply-To: <4DFF058D.1010309@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 21 Jun 2011 09:54:10 -0700 Cc: "James M. Polk" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 14:03:30 -0000 On Monday6/20/11 4:32 AM, "Gorry Fairhurst" wrote: >The authors of "IntServ Extension to Allow Signaling of Multiple Traffic >Specifications and Multiple Flow Specifications in RSVPv1" >(draft-polk-tsvwg-intserv-multiple-tspec) requests that this is adopted >as WG item. > > This draft defines extensions to Integrated Services (IntServ) > allowing multiple traffic specifications and multiple flow > specifications to be conveyed in the same Resource Reservation > Protocol (RSVPv1) reservation message exchange. This ability helps > optimize an agreeable bandwidth through a network between endpoints > in a single round trip > >There was hum indicating general WG support for this at the last IETF in >Prague. I applied to the AD to amend our Charter to allow this work, >which was approved. So we are now ready to make a formal decision and >this email is to allow people to confirm that there is sufficient energy >to complete this work in TSVWG. I think this is a good idea. It is a potential solution to some requirements for composite links soon to be published by the rtgwg. These extensions could be used in RSVP-TE to meet these requirements. > > >* PLEASE send an email to this list if you think adopting this document >in TSVWG is a good or bad idea. > >* Please also indicate if you are willing to REVIEW such a document >during its development - our AD has indicated that we expect to have at >least 4 people who commit to review this within the WG, perform a >detailed review in WGLC and provide appropriate comments if called upon >during the IESG review. If you can promise to do this please say! I can be a reviewer. > > >Please provide any comments at the latest by Wednesday 29th June 2011. > > >Best regards > >Gorry Fairhurst >(TSVWG Co-Chair) > > From fernando.gont.netbook.win@gmail.com Tue Jun 21 21:35:59 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABE111E8074 for ; Tue, 21 Jun 2011 21:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.983 X-Spam-Level: X-Spam-Status: No, score=-2.983 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_00=-2.599, 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 kxrV5vZBRV88 for ; Tue, 21 Jun 2011 21:35:59 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB21611E8070 for ; Tue, 21 Jun 2011 21:35:58 -0700 (PDT) Received: by gya6 with SMTP id 6so258427gya.31 for ; Tue, 21 Jun 2011 21:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=c2KEU4wuMEk3PmKWJCTIdQZxbww8a7xKPy691tazUuI=; b=ZWSXVDA/RVPpnmTcJGLK9LCpqyuErZDwwqbAGC2EzLB+AwOeWt2hTIoiOwYNz7918b oSRbXIhT7U/XhHan4bzinvReJC32bMC5XxFm1z4NlIrgVOFI1fCVwI69/ezu49ZoHoN2 ItQD4Z3wjVt4PUlvo5Ygk5GtDpPP9HJ+YjXJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:content-type:content-transfer-encoding; b=xS923o4BecyFlAPvyXoIxFVz52krlZCM/dCaycYoy1PLKnMSIGoJPbLSBA5X2Y38Lv ZKa1wQzRKE19Xg7XwiccBYtv5AuD+8lmD9X31LD0p83IDBhaCg+O/bn5nnrC3MLCln+S ZlT8GjU8wZapOTZbH6YSufRITWPGpP/2Dnr14= Received: by 10.100.91.7 with SMTP id o7mr16361anb.143.1308717358263; Tue, 21 Jun 2011 21:35:58 -0700 (PDT) Received: from [192.168.123.103] ([190.48.241.129]) by mx.google.com with ESMTPS id v9sm195452anv.30.2011.06.21.21.35.54 (version=SSLv3 cipher=OTHER); Tue, 21 Jun 2011 21:35:57 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E0168C8.6020709@gont.com.ar> Date: Wed, 22 Jun 2011 01:00:08 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: tsvwg Subject: draft-ietf-tsvwg-source-quench: SHOULD NOT vs. MUST NOT X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Scott O. Bradner" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 04:35:59 -0000 Folks, During the Beijing IETF, and in a corridor meeting in Prague, Scott Bradner noted that the source quench I-D should deprecate ICMP SQ with a "MUST NOT" rather than a "SHOULD NOT". Since this is the only remaining "issue" with this I-D, and sending this note (CC'ing Scott), such that he has the opportunity to make his point, and have the wg decide whether to leave the I-D as is (i.e., deprecating ICMP SQ with "SHOULD NOT"s), or change the requirements language as suggested by Scott. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From sob@harvard.edu Wed Jun 22 03:44:21 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7E211E8076 for ; Wed, 22 Jun 2011 03:44:21 -0700 (PDT) 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 oYpFeY2HwM0G for ; Wed, 22 Jun 2011 03:44:21 -0700 (PDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by ietfa.amsl.com (Postfix) with ESMTP id 33A9911E80D7 for ; Wed, 22 Jun 2011 03:44:21 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by golem.sobco.com (Postfix) with ESMTP id 224C46E25BC7; Wed, 22 Jun 2011 06:44:18 -0400 (EDT) Subject: Re: draft-ietf-tsvwg-source-quench: SHOULD NOT vs. MUST NOT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Scott O. Bradner" In-Reply-To: <4E0168C8.6020709@gont.com.ar> Date: Wed, 22 Jun 2011 06:44:18 -0400 Content-Transfer-Encoding: 7bit Message-Id: <6E42136B-111D-45BA-BD01-3B2E7FE6CC77@harvard.edu> References: <4E0168C8.6020709@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 10:44:21 -0000 SHOULD-NOT is fine if you can imagine that someone would have a real reason to send a SQ - if so it should be explained, if not please use MUST-NOT from RFC 2119 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Scott On Jun 22, 2011, at 12:00 AM, Fernando Gont wrote: > Folks, > > During the Beijing IETF, and in a corridor meeting in Prague, Scott > Bradner noted that the source quench I-D should deprecate ICMP SQ with a > "MUST NOT" rather than a "SHOULD NOT". > > Since this is the only remaining "issue" with this I-D, and sending this > note (CC'ing Scott), such that he has the opportunity to make his point, > and have the wg decide whether to leave the I-D as is (i.e., deprecating > ICMP SQ with "SHOULD NOT"s), or change the requirements language as > suggested by Scott. > > Thanks! > > Best regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > From scott.brim@gmail.com Wed Jun 22 05:55:16 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B5D11E8131 for ; Wed, 22 Jun 2011 05:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 3aoSE2TqrDGG for ; Wed, 22 Jun 2011 05:55:15 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B07011E812D for ; Wed, 22 Jun 2011 05:55:15 -0700 (PDT) Received: by iwn39 with SMTP id 39so910545iwn.31 for ; Wed, 22 Jun 2011 05:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ePTzE/mnyIDv+QrGJuZ/RCwCOm6amw6cggawlacSBGY=; b=Pdx59PHWMGRzLmGubv0pZVdOmt05ur1ioe6dbh6c46Zu97W2nCgU+QM69Zonuhx66d 96FOLKFTAtKpHG9wkL/ogxZmdBCfbSmJJFNCP6fD/xrTmZGzWCoRyHmg2/OPhEKLzaoo 7IuAmwa+Ua0qDQuroc4Umew+0OcPLNvUClZfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Pskux9DClmTqraceu8/KLxeG834jHNAtplFVjFZQOfr3wg0z3AhutQkHXdTEw2SYye LDtRevb68DCoYKi5vhytJ7ygN+c7S+j+qdoYtNwzYaAFlu3DAPLe9sZRYjYUcesyX+Mm oNXhv6if8tlmEECLksLEBady/qCjuvqq+H674= Received: by 10.231.203.132 with SMTP id fi4mr620612ibb.69.1308747315144; Wed, 22 Jun 2011 05:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.15.198 with HTTP; Wed, 22 Jun 2011 05:54:55 -0700 (PDT) In-Reply-To: <6E42136B-111D-45BA-BD01-3B2E7FE6CC77@harvard.edu> References: <4E0168C8.6020709@gont.com.ar> <6E42136B-111D-45BA-BD01-3B2E7FE6CC77@harvard.edu> From: Scott Brim Date: Wed, 22 Jun 2011 08:54:55 -0400 Message-ID: Subject: Re: draft-ietf-tsvwg-source-quench: SHOULD NOT vs. MUST NOT To: "Scott O. Bradner" Content-Type: text/plain; charset=ISO-8859-1 Cc: Fernando Gont , tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 12:55:16 -0000 For example, if you're allowing for existing implementations. From sob@harvard.edu Wed Jun 22 06:20:47 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C2811E8160 for ; Wed, 22 Jun 2011 06:20:47 -0700 (PDT) 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 khex16FYsq-N for ; Wed, 22 Jun 2011 06:20:46 -0700 (PDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by ietfa.amsl.com (Postfix) with ESMTP id 88F7711E80D4 for ; Wed, 22 Jun 2011 06:20:46 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by golem.sobco.com (Postfix) with ESMTP id E51486E27307; Wed, 22 Jun 2011 09:20:04 -0400 (EDT) Subject: Re: draft-ietf-tsvwg-source-quench: SHOULD NOT vs. MUST NOT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Scott O. Bradner" In-Reply-To: Date: Wed, 22 Jun 2011 09:20:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50A7BE87-94A5-4165-B00E-E7E59C02DCC0@harvard.edu> References: <4E0168C8.6020709@gont.com.ar> <6E42136B-111D-45BA-BD01-3B2E7FE6CC77@harvard.edu> To: Scott Brim X-Mailer: Apple Mail (2.1084) Cc: Fernando Gont , tsvwg X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 13:20:47 -0000 if one wanted to be anal one could say that "new implementations MUST = NOT...." but I expect just saying MUST NOT wold be understood to apply to software = created after the RFC was published Scott On Jun 22, 2011, at 8:54 AM, Scott Brim wrote: > For example, if you're allowing for existing implementations. From internet-drafts@ietf.org Fri Jun 24 05:17:52 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0319E8048; Fri, 24 Jun 2011 05:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 Nc8a1JsDVagq; Fri, 24 Jun 2011 05:17:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620039E8005; Fri, 24 Jun 2011 05:17:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-tsvwg-rsvp-security-groupkeying-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110624121751.15864.20264.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2011 05:17:51 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 12:17:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Applicability of Keying Methods for RSVP Security Author(s) : Michael H. Behringer Francois Le Faucheur Brian Weis Filename : draft-ietf-tsvwg-rsvp-security-groupkeying-10.txt Pages : 19 Date : 2011-06-24 The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per neighbor or per interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. The document also discusses applicability of encrypting RSVP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-security-groupkey= ing-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-security-groupkeyi= ng-10.txt From mbehring@cisco.com Fri Jun 24 05:20:59 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA8311E80B5 for ; Fri, 24 Jun 2011 05:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.416 X-Spam-Level: X-Spam-Status: No, score=-10.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, 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 NBlDyXnQcGm4 for ; Fri, 24 Jun 2011 05:20:58 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BB92411E80A8 for ; Fri, 24 Jun 2011 05:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mbehring@cisco.com; l=8046; q=dns/txt; s=iport; t=1308918057; x=1310127657; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6xXrgXVeTO51uLoEORODfpH4YEFLkQeFEU9IjEAxbWw=; b=UJcVrqmLrCSMdtdhotHr6kqSJGrQyuPYSq6CqECmo3m38QpMZN1Da9I1 8Z+rRwQTdV79LJLOUJAMVC7ZyIe9ViZ2pckuBVrIsvs89XOtrXkojzkGq QerV3w+2QSrvBhwHgaeWOZt3MkshuDGf1Lw0d+1PNS+QIEAGnolnguW2H I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMmABE6Q/khL/2dsb2JhbABFBwanNXeIc6NRnheDIBmCdASRe4RoCYsj X-IronPort-AV: E=Sophos;i="4.65,419,1304294400"; d="scan'208";a="38861603" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 24 Jun 2011 12:20:53 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5OCKrer021035; Fri, 24 Jun 2011 12:20:53 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 14:20:53 +0200 Received: from [10.55.194.28] ([10.55.194.28]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 14:20:52 +0200 Message-ID: <4E048123.9040709@cisco.com> Date: Fri, 24 Jun 2011 14:20:51 +0200 From: Michael Behringer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: David Harrington Subject: Re: AD review: draft-ietf-tsvwg-rsvp-security-groupkeying-09 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jun 2011 12:20:52.0327 (UTC) FILETIME=[28BC0F70:01CC3269] Cc: draft-ietf-tsvwg-rsvp-security-groupkeying@tools.ietf.org, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 12:20:59 -0000 Thank you David for your AD review. In version 10 (just posted) we address your comments. The IDnits check shows no issues. We believe that the document is now ready for publication. Thanks for your help! Michael On 19/04/2011 23:21, David Harrington wrote: > Hi, > > I have performed an AD review of this document. > > Overall, I found the content of this document well written, but have a > few concerns. > I believe these should be fairly easy to resolve. > > -- Technical and Process concerns: > 1) section 2 last paragraph > "... the RSVP router that > receives the Path message will be able to authenticate it > successfully using the group key." > It is important to be consistent in specifying what is being > authenticated. Here "it" appears to refer to a message. Earlier text > in section 2 says "If a group key is used, the authentication > granularity becomes group membership of devices, not (individual) peer > authentication between devices", which seems to indicate a device (or > peer) is being authenticated (or a group of devices). > > 2) I am concerned with the number of "should" and "should not" > recommendations, using non-RFC2119 keywords in an Informational > document. This feels like you are trying to define a standard or BCP > without using the standards track process. I think the usage of > "should" should be eliminated from an Informational document. > > 3) Has the WG explicitly discussed acceptability of the IPR terms > related to this document? The RAND terms apply for compliance to the > standard, but this is not being submitted as a standards-track > document. As noted in 2), there are a number of shoulds in this > Informational document. The terms in the IPR declaration do not seem > to provide non-assert status for implementing an Informational > document. Has the WG discussed this? > > Comments (mainly suggestions for improving the text): > 1) The text is made much harder to read because there are a bunch of > unnecesary lead-in phrases. You do not need a lead-in phrase for most > sentences. > Sentences that start with "Note that" generally don't need the "Note > that". > Sentences that start with "This implies that" generally don't need the > "This implies that". > Sentences that start with "We observe that" generally don't need the > "We observe that". > Sentences that start with "As observed in the security considerations > section of RFCXXXX," generally don't need the introductory lead-in, > just a simple reference after the stated content. > > These superfluous phrases obscure the real content of the text. > > 2) [I-D.weis-gdoi-mac-tek] is referenced informationally. I generally > prefer to avoid referencing IDs; they are an unstable thing to > reference, and can delay document publication. > > 3) The next-to-last paragraph of section2 (starting with "This means > that") could benefit from rephrasing. The first sentence seems to > belong to the preceding paragraph (the challenge), while the rest of > this paragraph is about the impact of handshakes. I think the > paragraph could be more succinct: > OLD: > Section 4.3 of [RFC2747] states that "... the > receiver MAY initiate an integrity handshake with the sender." We > note that if this handshake is taking place, it can be used to > determine the identity of the next RSVP hop. In this case, > non-RSVP > hops can be traversed also using per interface or per neighbor > keys. > NEW: > Section 4.3 of [RFC2747] states that "... the > receiver MAY initiate an integrity handshake with the sender." > Non-RSVP hops can be traversed more easily using per interface or per > neighbor keys if an integrity handshake is used to determine the > identity of the next RSVP hop. > > (The ease is impacted; are the security properties impacted at all?) > > 4) section 3.1 defines "security domain". I think the definition is > not clear and unambiguous. I think if you are going to define a term, > it should not be buried in the fourth sentence of a paragraph. Put it > in a terminology section, and make sure it is clear and unambiguous. > If the term is already clearly defined in another document, please > reference the normative document. > > 5) please ask the RFC editor whether they would prefer that "per > interface" and "per neighbor" be hyphenated. > > 6) "per interface" should be "Per interface" when it starts a > sentence. > > 7) please run id-nits and correct the problems it finds. I ran it and > it complains about copyright year, lack of an RFC2119 reference, and > the IPR disclaimer. Some complaints are caused by crossing a year-end > during processing and are easy fixes. > > 8) I found section 3.1 a bit confusing on first read. The problem is > the repetition using different words: > "However, when the > interface is multipoint, all RSVP speakers on a given subnet have > to > share the same key in this model. This makes it unsuitable for > deployment scenarios where nodes from different security domains > are > present on a subnet" > and > "As mentioned above, per interface keys are only > applicable when all the nodes reachable on the specific interface > belong to the same security domain." > and > "Again, interface > level keys can be deployed safely only when all the reachable > neighbors on the interface belong to the same security domain." > > What happens if interpretatiosn of the wording differ because your > wording differs? State it once clearly, so you don't have to keep > repeating it in different language. > > 9) s/We observe that, alternatively, in some > environments, // > > 10) The sentence starting "Group keying may allow" might be better as > the start of the next paragraph. > > 11) section 5.2 > OLD: > In its Security Considerations section, > [RFC4875] points out that RSVP message integrity mechanisms for > hop- > by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE > signaling. > Suggested: > RSVP message integrity mechanisms for hop- > by-hop RSVP signaling apply to the hop-by-hop P2MP RSVP-TE > signaling > (see [RFC4875] Security Considerations). > > 12) s/In turn, we observe that the analyses in this document of keying > methods apply equally to P2MP RSVP-TE for the hop-by-hop signaling. > /analyses in this document apply to P2MP RSVP-TE hop-by-hop > signaling./ > > But after cutting away the excess words, does this sentence actually > say anything? > > Is it the analyses in this document that apply to P2MP signalling, or > is it the RSVP integrity mechanism that applies? > Or are you saying that the analysis of keying methods for RSVP apply > to the keying for P2MP signalling? > > 13) "We note that the observation in Section 3.1 of this > document about use of group keying for protection of non-hop-by-hop > messages apply to protection of non-hop-by-hop signaling for LSP > Hierarchy and P2MP RSVP- TE." > > What does this sentence actually say? Please be clear and unambiguous > in your wording. > > Let me see if I can understand what you are trying to say here. > a) section 3.1 discusses per-interface and per-neighbor keying, not > group keying. and doesn't even mention non-hop-by-hop messages. > b) If I assume you meant 3.2, not 3.1, then I find that 3.2 says "As > discussed in Section 2, group keying can be used in the presence of > non-RSVP hops." > So to understand 5.2, I should read 3.2, which says I should read > section 2. > > and the message is ... "group keying can simplify protection of > non-hop-by-hop signaling for LSP Hierarchy and P2MP RSVP- TE." > Is that what you are trying to say? > > 14) please expand all acronyms on first usage. > > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > > > From internet-drafts@ietf.org Fri Jun 24 09:33:36 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E53011E8120; Fri, 24 Jun 2011 09:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 s3TDvvmB49s8; Fri, 24 Jun 2011 09:33:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1170F11E80E8; Fri, 24 Jun 2011 09:33:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110624163336.5983.66201.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2011 09:33:36 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 16:33:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Sockets API Extensions for Stream Control Transmission P= rotocol (SCTP) Author(s) : Randall R. Stewart Michael Tuexen Kacheong Poon Peter Lei Vladislav Yasevich Filename : draft-ietf-tsvwg-sctpsocket-30.txt Pages : 112 Date : 2011-06-24 This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-30.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-30.txt From randall@lakerest.net Sat Jun 25 15:30:57 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A2211E80BA for ; Sat, 25 Jun 2011 15:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2NTtKn2LxOw for ; Sat, 25 Jun 2011 15:30:57 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by ietfa.amsl.com (Postfix) with ESMTP id 4962A228011 for ; Sat, 25 Jun 2011 15:30:55 -0700 (PDT) Received: from [10.1.1.122] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p5PMUfxw010536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 25 Jun 2011 18:30:41 -0400 (EDT) (envelope-from randall@lakerest.net) Subject: Re: Call for WG Adoption of draft-polk-tsvwg-intserv-multiple-tspec-06 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Randy Stewart In-Reply-To: <20110620165434.0E585C174BE@newdev.eecs.harvard.edu> Date: Sat, 25 Jun 2011 18:30:40 -0400 Content-Transfer-Encoding: 7bit Message-Id: <61C72BC0-FD52-4765-8E7B-3AF9AE225DE8@lakerest.net> References: <20110620165434.0E585C174BE@newdev.eecs.harvard.edu> To: "Scott O. Bradner" X-Mailer: Apple Mail (2.1084) Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 22:30:57 -0000 +1 (and yes I would be willing to review the document) R On Jun 20, 2011, at 12:54 PM, Scott O. Bradner wrote: >> * PLEASE send an email to this list if you think adopting this document >> in TSVWG is a good or bad idea. > > I think it is a good (long delayed) idea > >> * Please also indicate if you are willing to REVIEW such a document >> during its development > > I am > > Scott > ----- Randall Stewart randall@lakerest.net From internet-drafts@ietf.org Sun Jun 26 03:29:51 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58E221F852F; Sun, 26 Jun 2011 03:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.383 X-Spam-Level: X-Spam-Status: No, score=-102.383 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356, 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 dYxk9y7HuvoF; Sun, 26 Jun 2011 03:29:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5755521F852B; Sun, 26 Jun 2011 03:29:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-tsvwg-sctp-strrst-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110626102951.11992.17163.idtracker@ietfa.amsl.com> Date: Sun, 26 Jun 2011 03:29:51 -0700 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 10:29:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Stream Recon= figuration Author(s) : Randall R. Stewart Peter Lei Michael Tuexen Filename : draft-ietf-tsvwg-sctp-strrst-10.txt Pages : 31 Date : 2011-06-26 Many applications that use SCTP want the ability to "reset" a = stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification t= o the upper layer that this has been performed. The applications that want this feature want it so that they can "re-use" streams for dif= ferent purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transport sequence numbers, adding additional streams and resetting all stream sequence numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-10.txt From randall@lakerest.net Sun Jun 26 03:55:46 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3332121F84BA; Sun, 26 Jun 2011 03:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] 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 g5XEI-W8gbIF; Sun, 26 Jun 2011 03:55:45 -0700 (PDT) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by ietfa.amsl.com (Postfix) with ESMTP id 1570021F84B8; Sun, 26 Jun 2011 03:55:44 -0700 (PDT) Received: from [10.1.1.122] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id p5QAtgm9015276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 26 Jun 2011 06:55:43 -0400 (EDT) (envelope-from randall@lakerest.net) Subject: Re: I-D Action: draft-ietf-tsvwg-sctp-strrst-10.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Randy Stewart In-Reply-To: <20110626102951.11992.17163.idtracker@ietfa.amsl.com> Date: Sun, 26 Jun 2011 06:55:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110626102951.11992.17163.idtracker@ietfa.amsl.com> To: Internet-Drafts@ietf.org X-Mailer: Apple Mail (2.1084) Cc: tsvwg@ietf.org, i-d-announce@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 10:55:46 -0000 This submission has all the previous comments.. not to many I think.. It was about to expire so I thought it best to update (especially since my affiliation has changed ;-) Still unresolved is the out-of-band vs in-band idea... again I don't see how you do this totally inband.. R On Jun 26, 2011, at 6:29 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Transport Area Working = Group Working Group of the IETF. >=20 > Title : Stream Control Transmission Protocol (SCTP) = Stream Reconfiguration > Author(s) : Randall R. Stewart > Peter Lei > Michael Tuexen > Filename : draft-ietf-tsvwg-sctp-strrst-10.txt > Pages : 31 > Date : 2011-06-26 >=20 > Many applications that use SCTP want the ability to = "reset" a stream. > The intention of resetting a stream is to set the numbering sequence > of the stream back to 'zero' with a corresponding = notification to the > upper layer that this has been performed. The applications that = want > this feature want it so that they can "re-use" streams for = different > purposes but still utilize the stream sequence number so that the > application can track the message flows. Thus, without this = feature, > a new use of an old stream would result in message numbers greater > than expected unless there is a protocol mechanism to "reset = the > streams back to zero". This document also includes methods for > resetting the transport sequence numbers, adding additional streams > and resetting all stream sequence numbers. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-10.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-10.txt >=20 ----- Randall Stewart randall@lakerest.net From Michael.Tuexen@lurchi.franken.de Sun Jun 26 04:11:12 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E381F228017 for ; Sun, 26 Jun 2011 04:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_6CONS_WORD=0.356] 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 0nsZ99Yls73K for ; Sun, 26 Jun 2011 04:11:11 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id B259E228015 for ; Sun, 26 Jun 2011 04:11:10 -0700 (PDT) Received: from [192.168.1.195] (p508FA1B4.dip.t-dialin.net [80.143.161.180]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6B4901C0B461C; Sun, 26 Jun 2011 13:11:07 +0200 (CEST) Subject: Re: I-D Action: draft-ietf-tsvwg-sctp-strrst-10.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Sun, 26 Jun 2011 13:11:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110626102951.11992.17163.idtracker@ietfa.amsl.com> To: Randy Stewart X-Mailer: Apple Mail (2.1084) Cc: tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 11:11:12 -0000 On Jun 26, 2011, at 12:55 PM, Randy Stewart wrote: > This submission has all the previous comment .. not to many I think.. These issues are not yet resolved, but on my ToDo list: * Address Geavins comments. * Add incoming streams request parameters. These were the points brought up during LC, which I know hoe to address. And the out-of-band vs. in-band discussion, which is still open. Best regards Michael >=20 > It was about to expire so I thought it best to update (especially = since > my affiliation has changed ;-) >=20 > Still unresolved is the out-of-band vs in-band idea... again > I don't see how you do this totally inband.. >=20 > R > On Jun 26, 2011, at 6:29 AM, Internet-Drafts@ietf.org wrote: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Transport Area Working = Group Working Group of the IETF. >>=20 >> Title : Stream Control Transmission Protocol (SCTP) = Stream Reconfiguration >> Author(s) : Randall R. Stewart >> Peter Lei >> Michael Tuexen >> Filename : draft-ietf-tsvwg-sctp-strrst-10.txt >> Pages : 31 >> Date : 2011-06-26 >>=20 >> Many applications that use SCTP want the ability to = "reset" a stream. >> The intention of resetting a stream is to set the numbering sequence >> of the stream back to 'zero' with a corresponding = notification to the >> upper layer that this has been performed. The applications that = want >> this feature want it so that they can "re-use" streams for = different >> purposes but still utilize the stream sequence number so that the >> application can track the message flows. Thus, without this = feature, >> a new use of an old stream would result in message numbers greater >> than expected unless there is a protocol mechanism to "reset = the >> streams back to zero". This document also includes methods for >> resetting the transport sequence numbers, adding additional streams >> and resetting all stream sequence numbers. >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-10.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-10.txt >>=20 >=20 > ----- > Randall Stewart > randall@lakerest.net >=20 >=20 >=20 >=20 >=20 From jmpolk@cisco.com Mon Jun 27 12:59:54 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F8C21F8585 for ; Mon, 27 Jun 2011 12:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 RJDHtPsfanQK for ; Mon, 27 Jun 2011 12:59:53 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id ECE9021F856E for ; Mon, 27 Jun 2011 12:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2056; q=dns/txt; s=iport; t=1309204793; x=1310414393; h=message-id:date:to:from:subject:mime-version; bh=SFzTYbJ+iU8GhVZsyRFA+cIHdFTSJK4eQsRTZfqlnXQ=; b=TOdBwEt1KIWfheGLgPVPzZQzWQLJPJHoAEGs1xeGGbzh8WqTUAZ2kmot CIWBlK/GspEn7a/49qItd900UmsfuzX3sakFpSviPDNaEMCZMExmNlQqo gNdYeVC3xdjmS19lVQcHZtVscs/yXEzCexIwjLmIAa3kDAPOGThoCDXyE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAN3gCE6rRDoI/2dsb2JhbAA1Hacyd6l9gR6OXoF1hQ6IM4YwBIcsmxA X-IronPort-AV: E=Sophos;i="4.65,434,1304294400"; d="scan'208";a="348352747" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 27 Jun 2011 19:59:53 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5RJxrfN007686 for ; Mon, 27 Jun 2011 19:59:53 GMT Message-Id: <201106271959.p5RJxrfN007686@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Jun 2011 14:59:52 -0500 To: tsvwg From: "James M. Polk" Subject: Nomcom 2011-2012: Call for Volunteers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 19:59:54 -0000 TSVWG Here is a call to be on the NONCOM. I encourage each of you to consider this. Details about the process for volunteering for the Nomcom and the list of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ >From: NomCom Chair >To: IETF Announcement list >Subject: Nomcom 2011-2012: Second Call for Volunteers >Date: Fri, 24 Jun 2011 11:14:22 -0700 (PDT) > >The primary activity for this nomcom will begin during IETF-81 in >Quebec City and should be completed by January 2012. The nomcom will >be collecting requirements from the community, as well as talking to >candidates and to community members about candidates. There will be >regularly scheduled conference calls to ensure progress. Thus, being a >nomcom member does require some time commitment. > >Please volunteer by sending an email to me before >11:59 pm EDT July 10, 2011 as follows: > >To: suresh.krishnan@ericsson.com >Subject: Nomcom 2011-12 Volunteer > >Please include the following information in the body of the mail: > >Full Name: // As you enter in the IETF Registration Form, > // First/Given name followed by Last/Family Name > >Current Primary Affiliation: // typically what goes in the Company > // field in the IETF Registration Form > >Email Address(es): // all email addresses used to Register for the > // past 5 IETF meetings > // Please designate a Preferred email address for > // contact if there is more than one email address > >Telephone number: // With country code (for confirmation if selected) > >Please expect an email response from me within 3 business days stating >whether or not you are qualified. If you do not receive a response in >this timeframe, please re-send your email with the tag "RESEND:" added >to the subject line. James TSVWG Chair From dwing@cisco.com Tue Jun 28 12:09:36 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E1421F8599 for ; Tue, 28 Jun 2011 12:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.339 X-Spam-Level: X-Spam-Status: No, score=-110.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 IXpVXjTLVYIx for ; Tue, 28 Jun 2011 12:09:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 69DA621F859F for ; Tue, 28 Jun 2011 12:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2065; q=dns/txt; s=iport; t=1309288172; x=1310497772; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=5Mi1tar8ieR2kB8hAufJc58F7MGBqG54ihk4Fz8TaWc=; b=ajGGgBulo5sbQ9TuHJk78drurus0ufB1UBMOlcIks60LGewsYwX1xuxq 3gCZ6xR3wRi3uGlNIUClcr8d6ZcZvRv/8Q03ysaG4Tp8WmSfulsYpbz03 oFCryNM2dafKp99+WPTpDUTPlJ5R/ovTWHj7aP2TKkt07pLDitjRsOPcH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0BAM8lCk6rRDoG/2dsb2JhbABTmAxCgSaNTHerKp4dhjAEhzSbHQ X-IronPort-AV: E=Sophos;i="4.65,438,1304294400"; d="scan'208";a="471498090" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2011 19:09:30 +0000 Received: from dwingWS (sjc-vpn5-1143.cisco.com [10.21.92.119]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5SJ9Ua2012431; Tue, 28 Jun 2011 19:09:30 GMT From: "Dan Wing" To: References: <20110624163336.5983.66201.idtracker@ietfa.amsl.com> In-Reply-To: <20110624163336.5983.66201.idtracker@ietfa.amsl.com> Subject: RE: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt Date: Tue, 28 Jun 2011 12:09:29 -0700 Message-ID: <021801cc35c6$e7d933f0$b78b9bd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwyjLFmHYHmvwGLRFaeC9wZ0n7liwDOE4Cw Content-Language: en-us Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 19:09:37 -0000 I noticed draft-ietf-tsvwg-sctpsocket-30 doesn't mention the DISABLE_RESTART defined in draft-ietf-tsvwg-natsupp. Is draft-ietf-tsvwg-natsupp expected to Update draft-ietf-tsvwg-sctpsocket? If so, it doesn't do that at the moment. -d > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Friday, June 24, 2011 9:34 AM > To: i-d-announce@ietf.org > Cc: tsvwg@ietf.org > Subject: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Transport Area Working > Group Working Group of the IETF. > > Title : Sockets API Extensions for Stream Control > Transmission Protocol (SCTP) > Author(s) : Randall R. Stewart > Michael Tuexen > Kacheong Poon > Peter Lei > Vladislav Yasevich > Filename : draft-ietf-tsvwg-sctpsocket-30.txt > Pages : 112 > Date : 2011-06-24 > > This document describes a mapping of the Stream Control Transmission > Protocol (SCTP) into a sockets API. The benefits of this mapping > include compatibility for TCP applications, access to new SCTP > features and a consolidated error and event notification scheme. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-30.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-30.txt > _______________________________________________ > 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 Michael.Tuexen@lurchi.franken.de Tue Jun 28 13:21:41 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA4521F85DA for ; Tue, 28 Jun 2011 13:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 yQVRhu1gmyAw for ; Tue, 28 Jun 2011 13:21:40 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 0F70E21F85D8 for ; Tue, 28 Jun 2011 13:21:39 -0700 (PDT) Received: from [192.168.1.195] (p508FB7B8.dip.t-dialin.net [80.143.183.184]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 2B6671C0C0BD9; Tue, 28 Jun 2011 22:21:37 +0200 (CEST) Subject: Re: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <021801cc35c6$e7d933f0$b78b9bd0$@com> Date: Tue, 28 Jun 2011 22:21:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110624163336.5983.66201.idtracker@ietfa.amsl.com> <021801cc35c6$e7d933f0$b78b9bd0$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1084) Cc: tsvwg@ietf.org, draft-ietf-tsvwg-sctpsocket@tools.ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:21:41 -0000 On Jun 28, 2011, at 9:09 PM, Dan Wing wrote: > I noticed draft-ietf-tsvwg-sctpsocket-30 doesn't mention the = DISABLE_RESTART > defined in draft-ietf-tsvwg-natsupp. Is draft-ietf-tsvwg-natsupp = expected > to Update draft-ietf-tsvwg-sctpsocket? If so, it doesn't do that at = the > moment. Hi Dan, documents can have a socket API section, if the stuff described in the document needs some user interaction. We do this for example in the SCTP Stream Reset ID, the I-Bit extension and so on. These documents also do not update the socket API RFC (once it is an RFC). So the socket API ID can progress without being affected by the NAT documents. Best regards Michael >=20 > -d >=20 >=20 >=20 >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- >> bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: Friday, June 24, 2011 9:34 AM >> To: i-d-announce@ietf.org >> Cc: tsvwg@ietf.org >> Subject: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Transport Area Working >> Group Working Group of the IETF. >>=20 >> Title : Sockets API Extensions for Stream Control >> Transmission Protocol (SCTP) >> Author(s) : Randall R. Stewart >> Michael Tuexen >> Kacheong Poon >> Peter Lei >> Vladislav Yasevich >> Filename : draft-ietf-tsvwg-sctpsocket-30.txt >> Pages : 112 >> Date : 2011-06-24 >>=20 >> This document describes a mapping of the Stream Control = Transmission >> Protocol (SCTP) into a sockets API. The benefits of this mapping >> include compatibility for TCP applications, access to new SCTP >> features and a consolidated error and event notification scheme. >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-30.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-30.txt >> _______________________________________________ >> 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 >=20 >=20 From dwing@cisco.com Tue Jun 28 15:00:01 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FA121F8489 for ; Tue, 28 Jun 2011 15:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.232 X-Spam-Level: X-Spam-Status: No, score=-110.232 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 iBTUW1711K6R for ; Tue, 28 Jun 2011 14:59:59 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3000811E80C0 for ; Tue, 28 Jun 2011 14:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3088; q=dns/txt; s=iport; t=1309298398; x=1310507998; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=eEk8TQtiFCX4rC03KT2tkr4zDhQgnn/zu4lWDVLLtZo=; b=WnpZRKq8Cx3xoog7jnFuIENyeeaZmsQMNmxV+/ey+CczON4VTBp/SHZG CTWsJRB9vzJrY2J+Ra3xBfCQy+uQYui9oyHtIzBe0fgfUd0y0LwD49LF7 GmbzIT+s/RxpE+llwXPYtySv5yl5ElRgZe5xrrIg6w/PCALc6g7zYi/Kg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAIZOCk6rRDoJ/2dsb2JhbABSmA6BaI1Md4h3pBSeFIYwBIc0mx0 X-IronPort-AV: E=Sophos;i="4.65,439,1304294400"; d="scan'208";a="349262885" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 28 Jun 2011 21:59:58 +0000 Received: from dwingWS (sjc-vpn5-1143.cisco.com [10.21.92.119]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5SLxw7G005165; Tue, 28 Jun 2011 21:59:58 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'Michael_T=FCxen'?=" References: <20110624163336.5983.66201.idtracker@ietfa.amsl.com> <021801cc35c6$e7d933f0$b78b9bd0$@com> In-Reply-To: Subject: RE: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt Date: Tue, 28 Jun 2011 14:59:58 -0700 Message-ID: <02d401cc35de$b8d23ee0$2a76bca0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw10QEcilh11WXRRp+PEkje+G6A0gADMrfQ Content-Language: en-us Cc: tsvwg@ietf.org, draft-ietf-tsvwg-sctpsocket@tools.ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 22:00:01 -0000 > -----Original Message----- > From: Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] > Sent: Tuesday, June 28, 2011 1:22 PM > To: Dan Wing > Cc: draft-ietf-tsvwg-sctpsocket@tools.ietf.org; tsvwg@ietf.org > Subject: Re: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt >=20 > On Jun 28, 2011, at 9:09 PM, Dan Wing wrote: >=20 > > I noticed draft-ietf-tsvwg-sctpsocket-30 doesn't mention the > DISABLE_RESTART > > defined in draft-ietf-tsvwg-natsupp. Is draft-ietf-tsvwg-natsupp > expected > > to Update draft-ietf-tsvwg-sctpsocket? If so, it doesn't do that = at > the > > moment. > Hi Dan, >=20 > documents can have a socket API section, if the stuff described in the > document needs some user interaction. We do this for example in the > SCTP Stream Reset ID, the I-Bit extension and so on. > These documents also do not update the socket API RFC (once it is > an RFC). >=20 > So the socket API ID can progress without being affected by the > NAT documents. I see. Is DISABLE_RESTART necessary with NPTv6 (draft-mrw-nat66)? -d > Best regards > Michael > > > > -d > > > > > > > >> -----Original Message----- > >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > >> bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > >> Sent: Friday, June 24, 2011 9:34 AM > >> To: i-d-announce@ietf.org > >> Cc: tsvwg@ietf.org > >> Subject: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. This draft is a work item of the Transport Area = Working > >> Group Working Group of the IETF. > >> > >> Title : Sockets API Extensions for Stream Control > >> Transmission Protocol (SCTP) > >> Author(s) : Randall R. Stewart > >> Michael Tuexen > >> Kacheong Poon > >> Peter Lei > >> Vladislav Yasevich > >> Filename : draft-ietf-tsvwg-sctpsocket-30.txt > >> Pages : 112 > >> Date : 2011-06-24 > >> > >> This document describes a mapping of the Stream Control > Transmission > >> Protocol (SCTP) into a sockets API. The benefits of this mapping > >> include compatibility for TCP applications, access to new SCTP > >> features and a consolidated error and event notification scheme. > >> > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket- > 30.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> This Internet-Draft can be retrieved at: > >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket- > 30.txt > >> _______________________________________________ > >> 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 Michael.Tuexen@lurchi.franken.de Tue Jun 28 15:08:28 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF2611E8112 for ; Tue, 28 Jun 2011 15:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 Y-eV+1gK7Joj for ; Tue, 28 Jun 2011 15:08:28 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 5504C11E80C0 for ; Tue, 28 Jun 2011 15:08:27 -0700 (PDT) Received: from [192.168.1.195] (p508FB7B8.dip.t-dialin.net [80.143.183.184]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 8A7211C0C0BD9; Wed, 29 Jun 2011 00:08:25 +0200 (CEST) Subject: Re: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <02d401cc35de$b8d23ee0$2a76bca0$@com> Date: Wed, 29 Jun 2011 00:08:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87855BBA-94F2-470B-A8D0-F17624FCCA2A@lurchi.franken.de> References: <20110624163336.5983.66201.idtracker@ietfa.amsl.com> <021801cc35c6$e7d933f0$b78b9bd0$@com> <02d401cc35de$b8d23ee0$2a76bca0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: tsvwg@ietf.org, draft-ietf-tsvwg-sctpsocket@tools.ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 22:08:29 -0000 On Jun 28, 2011, at 11:59 PM, Dan Wing wrote: >> -----Original Message----- >> From: Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] >> Sent: Tuesday, June 28, 2011 1:22 PM >> To: Dan Wing >> Cc: draft-ietf-tsvwg-sctpsocket@tools.ietf.org; tsvwg@ietf.org >> Subject: Re: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt >>=20 >> On Jun 28, 2011, at 9:09 PM, Dan Wing wrote: >>=20 >>> I noticed draft-ietf-tsvwg-sctpsocket-30 doesn't mention the >> DISABLE_RESTART >>> defined in draft-ietf-tsvwg-natsupp. Is draft-ietf-tsvwg-natsupp >> expected >>> to Update draft-ietf-tsvwg-sctpsocket? If so, it doesn't do that = at >> the >>> moment. >> Hi Dan, >>=20 >> documents can have a socket API section, if the stuff described in = the >> document needs some user interaction. We do this for example in the >> SCTP Stream Reset ID, the I-Bit extension and so on. >> These documents also do not update the socket API RFC (once it is >> an RFC). >>=20 >> So the socket API ID can progress without being affected by the >> NAT documents. >=20 > I see. >=20 > Is DISABLE_RESTART necessary with NPTv6 (draft-mrw-nat66)? Not sure. Is it possible that multiple hosts behind the NAT will be exposed to the Internet using the same IP address? If this is possible, DISABLE_RESTART is required, if not, it is not required. Best regards Michael >=20 > -d >=20 >=20 >> Best regards >> Michael >>>=20 >>> -d >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- >>>> bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >>>> Sent: Friday, June 24, 2011 9:34 AM >>>> To: i-d-announce@ietf.org >>>> Cc: tsvwg@ietf.org >>>> Subject: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. This draft is a work item of the Transport Area = Working >>>> Group Working Group of the IETF. >>>>=20 >>>> Title : Sockets API Extensions for Stream Control >>>> Transmission Protocol (SCTP) >>>> Author(s) : Randall R. Stewart >>>> Michael Tuexen >>>> Kacheong Poon >>>> Peter Lei >>>> Vladislav Yasevich >>>> Filename : draft-ietf-tsvwg-sctpsocket-30.txt >>>> Pages : 112 >>>> Date : 2011-06-24 >>>>=20 >>>> This document describes a mapping of the Stream Control >> Transmission >>>> Protocol (SCTP) into a sockets API. The benefits of this mapping >>>> include compatibility for TCP applications, access to new SCTP >>>> features and a consolidated error and event notification scheme. >>>>=20 >>>>=20 >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket- >> 30.txt >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket- >> 30.txt >>>> _______________________________________________ >>>> 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 >>>=20 >>>=20 >=20 >=20 From dwing@cisco.com Tue Jun 28 15:37:17 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44F611E81EB for ; Tue, 28 Jun 2011 15:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.242 X-Spam-Level: X-Spam-Status: No, score=-110.242 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 cudenTEr1OiU for ; Tue, 28 Jun 2011 15:37:17 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C076011E81E7 for ; Tue, 28 Jun 2011 15:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3943; q=dns/txt; s=iport; t=1309300634; x=1310510234; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=aSGSr5T1GK4RXSPUwVV7ncZAIKg5ayP8Wczrdy9R83s=; b=bncYskvjsx0GE88SBXvxkvsNxm+4d0ed5K08giUS4ehhfULxUWIjJRLH RhIB93H52siAg+Em3vL6dpBpn6i16THsSPChRrbZgVkLP30MMbq+IWEv5 dUey6oUZuQKD1gWopRw4MlXce9HhqxBU/VzlVTeQQ2/CNfsk/Tk9U1A7s 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAL1WCk6rRDoH/2dsb2JhbABSmA6BaI1Md4h3o2OeDIYwBIc0mx0 X-IronPort-AV: E=Sophos;i="4.65,439,1304294400"; d="scan'208";a="349282688" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 28 Jun 2011 22:37:14 +0000 Received: from dwingWS (sjc-vpn5-1143.cisco.com [10.21.92.119]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5SMbEof019932; Tue, 28 Jun 2011 22:37:14 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'Michael_T=FCxen'?=" References: <20110624163336.5983.66201.idtracker@ietfa.amsl.com> <021801cc35c6$e7d933f0$b78b9bd0$@com> <02d401cc35de$b8d23ee0$2a76bca0$@com> <87855BBA-94F2-470B-A8D0-F17624FCCA2A@lurchi.franken.de> In-Reply-To: <87855BBA-94F2-470B-A8D0-F17624FCCA2A@lurchi.franken.de> Subject: RE: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt Date: Tue, 28 Jun 2011 15:37:13 -0700 Message-ID: <02ef01cc35e3$ed3e4070$c7bac150$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw13+oxsrkZWgD4T/e9eVIqRhMJLQAA+/tQ Content-Language: en-us Cc: tsvwg@ietf.org, draft-ietf-tsvwg-sctpsocket@tools.ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 22:37:17 -0000 > -----Original Message----- > From: Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] > Sent: Tuesday, June 28, 2011 3:08 PM > To: Dan Wing > Cc: draft-ietf-tsvwg-sctpsocket@tools.ietf.org; tsvwg@ietf.org > Subject: Re: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt >=20 > On Jun 28, 2011, at 11:59 PM, Dan Wing wrote: >=20 > >> -----Original Message----- > >> From: Michael T=FCxen [mailto:Michael.Tuexen@lurchi.franken.de] > >> Sent: Tuesday, June 28, 2011 1:22 PM > >> To: Dan Wing > >> Cc: draft-ietf-tsvwg-sctpsocket@tools.ietf.org; tsvwg@ietf.org > >> Subject: Re: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt > >> > >> On Jun 28, 2011, at 9:09 PM, Dan Wing wrote: > >> > >>> I noticed draft-ietf-tsvwg-sctpsocket-30 doesn't mention the > >> DISABLE_RESTART > >>> defined in draft-ietf-tsvwg-natsupp. Is draft-ietf-tsvwg-natsupp > >> expected > >>> to Update draft-ietf-tsvwg-sctpsocket? If so, it doesn't do that > at > >> the > >>> moment. > >> Hi Dan, > >> > >> documents can have a socket API section, if the stuff described in > the > >> document needs some user interaction. We do this for example in the > >> SCTP Stream Reset ID, the I-Bit extension and so on. > >> These documents also do not update the socket API RFC (once it is > >> an RFC). > >> > >> So the socket API ID can progress without being affected by the > >> NAT documents. > > > > I see. > > > > Is DISABLE_RESTART necessary with NPTv6 (draft-mrw-nat66)? > > Not sure. Is it possible that multiple hosts behind the NAT > will be exposed to the Internet using the same IP address? No, not with NPTv6. > If this is possible, DISABLE_RESTART is required, if not, > it is not required. Ok, great. Thanks. -d > Best regards > Michael > > > > -d > > > > > >> Best regards > >> Michael > >>> > >>> -d > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > >>>> bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > >>>> Sent: Friday, June 24, 2011 9:34 AM > >>>> To: i-d-announce@ietf.org > >>>> Cc: tsvwg@ietf.org > >>>> Subject: I-D Action: draft-ietf-tsvwg-sctpsocket-30.txt > >>>> > >>>> A New Internet-Draft is available from the on-line = Internet-Drafts > >>>> directories. This draft is a work item of the Transport Area > Working > >>>> Group Working Group of the IETF. > >>>> > >>>> Title : Sockets API Extensions for Stream Control > >>>> Transmission Protocol (SCTP) > >>>> Author(s) : Randall R. Stewart > >>>> Michael Tuexen > >>>> Kacheong Poon > >>>> Peter Lei > >>>> Vladislav Yasevich > >>>> Filename : draft-ietf-tsvwg-sctpsocket-30.txt > >>>> Pages : 112 > >>>> Date : 2011-06-24 > >>>> > >>>> This document describes a mapping of the Stream Control > >> Transmission > >>>> Protocol (SCTP) into a sockets API. The benefits of this = mapping > >>>> include compatibility for TCP applications, access to new SCTP > >>>> features and a consolidated error and event notification scheme. > >>>> > >>>> > >>>> A URL for this Internet-Draft is: > >>>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket- > >> 30.txt > >>>> > >>>> Internet-Drafts are also available by anonymous FTP at: > >>>> ftp://ftp.ietf.org/internet-drafts/ > >>>> > >>>> This Internet-Draft can be retrieved at: > >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket- > >> 30.txt > >>>> _______________________________________________ > >>>> 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 jmpolk@cisco.com Tue Jun 28 20:30:48 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA2C11E808C for ; Tue, 28 Jun 2011 20:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 m8Mf+XPibBwv for ; Tue, 28 Jun 2011 20:30:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id B250F11E8084 for ; Tue, 28 Jun 2011 20:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2190; q=dns/txt; s=iport; t=1309318247; x=1310527847; h=message-id:date:to:from:subject:cc:mime-version: content-transfer-encoding; bh=njrZ11BWEFkMDwIGtgR+JxszO8gk0Hqn+3ml6NQWUzY=; b=m6dRtObyaBKw0cKfuFJB/7mBWvTHp92mvcztkh7J8MpT5cUSoRrfa5fR 2fcItQDTpNtSs/zDPhTazgbwx+H4rDWxDOHieUhnW5l3+fe5FLMhEyqS4 tJaO0UbWahLCM2O3XMEwUJ7KYYCpDDj7pFDNuNAK3eXLZJ5GtAFFJ3LZj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOCbCk6rRDoI/2dsb2JhbABSp093qwCeB4YwBIc2myg X-IronPort-AV: E=Sophos;i="4.65,441,1304294400"; d="scan'208";a="349412937" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 29 Jun 2011 03:30:47 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5T3Uk4W015900; Wed, 29 Jun 2011 03:30:47 GMT Message-Id: <201106290330.p5T3Uk4W015900@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Jun 2011 22:30:45 -0500 To: tsvwg From: "James M. Polk" Subject: New 48 hour LC on draft-ietf-tsvwg-sctpsocket Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: gorry@erg.abdn.ac.uk X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 03:30:48 -0000 TSVWG Michael T=FCxen discovered a few bugs when=20 implementing this SCTP Socket API against -29 of=20 this draft. The chairs are issuing a VERY SHORT 48 hour WGLC (details= below). Here is the complete list (including the issues earlier reported): (NOTE: the "I" below is from Michael) (1) The list in section 8 for the socket options supported by= sctp_opt_info() is outdated. It should be updated to be consistent with the current= doc. I consider this purely editorial. (2) The description of SCTP_LOCAL_AUTH_CHUNKS is missing a statement= regarding the special assoc ids. It should be added. I consider this purely editorial. (3) It should be made clear in section 8.1.20 that the sctp_data_io_event is deprecated. I consider this purely editorial. (4) For all socket options supporting an association ID, only the special= value of SCTP_FUTURE_ASSOC might make sense with=20 getsockopt(). SCTP_ALL_ASSOC and SCTP_CURRENT_ASSOC do not make sense. This should be stated explicitly. I consider this purely editorial. (5) Change struct sctp_authinfo { uint16_t auth_keyid; } to struct sctp_authinfo { uint16_t auth_keynumber; } to make naming consistent in the document. I consider this purely editorial. (6) The SCTP_PEER_ADDR_PARAMS socket option supports SCTP_FUTURE_ASSOCS. This is not stated correctly in the ID. I consider this purely editorial. (7) The description of sctp_sendv() is missing the constant= SCTP_SENDV_NOINFO. This is an omission and should be added. I don't consider this to be a technically change. (8) A socket option for setting/getting the default SCTP_PRINFO. This was forgotten. I don't consider this to be a technically change. TSVWG now has 48 hours to let the chairs know if=20 they see any problems with the proposed status or=20 fixes stated to any open issue listed above. This=20 is a VERY short LC, ending Thursday at 11pm EDT (2300 East Coast US Time). If you have issues, make sure the chairs hear you in the next 48 hours. James & Gorry TSVWG chairs From ietfc@btconnect.com Wed Jun 29 08:11:52 2011 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FA99E8044 for ; Wed, 29 Jun 2011 08:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_6CONS_WORD=0.356] 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 owCkIjB7womc for ; Wed, 29 Jun 2011 08:11:45 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 274D49E800C for ; Wed, 29 Jun 2011 08:11:44 -0700 (PDT) Received: from host81-156-70-165.range81-156.btcentralplus.com (HELO pc6) ([81.156.70.165]) by c2bthomr13.btconnect.com with SMTP id DKN14219; Wed, 29 Jun 2011 16:11:32 +0100 (BST) Message-ID: <008e01cc3666$1b8d2220$4001a8c0@gateway.2wire.net> From: "t.petch" To: =?iso-8859-1?Q?Michael_T=FCxen?= , "Randy Stewart" References: <20110626102951.11992.17163.idtracker@ietfa.amsl.com> Subject: Re: I-D Action: draft-ietf-tsvwg-sctp-strrst-10.txt Date: Wed, 29 Jun 2011 16:08:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4E0B40A4.001D, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.29.144515:17:7.586, ip=81.156.70.165, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020C.4E0B40A5.0095,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: tsvwg list X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 15:11:52 -0000 There are still some quirks of spelling, some old, some new, and I think that the race condition is still not wholy covered in 5.2.3. I am thinking of a case where the Incoming SSN Reset Request Parameter specifies eg streams 2 and 3 while the Outgoing SSN Reset Request Parameter specifies eg streams 1 and 2. Tom Petch ----- Original Message ----- From: "Michael Tüxen" To: "Randy Stewart" Cc: "tsvwg list" Sent: Sunday, June 26, 2011 1:11 PM Subject: Re: I-D Action: draft-ietf-tsvwg-sctp-strrst-10.txt On Jun 26, 2011, at 12:55 PM, Randy Stewart wrote: > This submission has all the previous comment .. not to many I think.. These issues are not yet resolved, but on my ToDo list: * Address Geavins comments. * Add incoming streams request parameters. These were the points brought up during LC, which I know hoe to address. And the out-of-band vs. in-band discussion, which is still open. Best regards Michael > > It was about to expire so I thought it best to update (especially since > my affiliation has changed ;-) > > Still unresolved is the out-of-band vs in-band idea... again > I don't see how you do this totally inband.. > > R > On Jun 26, 2011, at 6:29 AM, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. >> >> Title : Stream Control Transmission Protocol (SCTP) Stream Reconfiguration >> Author(s) : Randall R. Stewart >> Peter Lei >> Michael Tuexen >> Filename : draft-ietf-tsvwg-sctp-strrst-10.txt >> Pages : 31 >> Date : 2011-06-26 >> >> Many applications that use SCTP want the ability to "reset" a stream. >> The intention of resetting a stream is to set the numbering sequence >> of the stream back to 'zero' with a corresponding notification to the >> upper layer that this has been performed. The applications that want >> this feature want it so that they can "re-use" streams for different >> purposes but still utilize the stream sequence number so that the >> application can track the message flows. Thus, without this feature, >> a new use of an old stream would result in message numbers greater >> than expected unless there is a protocol mechanism to "reset the >> streams back to zero". This document also includes methods for >> resetting the transport sequence numbers, adding additional streams >> and resetting all stream sequence numbers. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-10.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-10.txt >> > > ----- > Randall Stewart > randall@lakerest.net > > > > >