From nobody Tue Jun 5 07:05:11 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14B913107D for ; Tue, 5 Jun 2018 07:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrZ9MwXpGtSJ for ; Tue, 5 Jun 2018 07:05:03 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D38131074 for ; Tue, 5 Jun 2018 07:05:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F3E664A05B7 for ; Tue, 5 Jun 2018 07:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1528207503; bh=woFIkXPmDmyyj/PoWAEkkM1co0FkytUu0PKcytjHi3A=; h=To:From:Subject:Date:From; b=bLPMIA4efueMucjGr5MbCFFUWA2sUsvisC/M4cbM5phkGFIJyOK3P8JC26B68nOzk GR2yH2UiH1MZz/BsVOFYUTU+ZK2ncRfKZPx23dCfwBgeDS6ONAJSX0pPI6tmxHA3GE X75pDM76TXD8f0VM9jFJ7Z8ih1g8Kmup9E6DZbhs= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 91F704A047D for ; Tue, 5 Jun 2018 07:05:02 -0700 (PDT) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Tue, 5 Jun 2018 10:05:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:05:09 -0000 My impression of the conversation in London was that the working group was leaning towards keeping both of the proof of transit algorithms. One because it is very efficient and confirms that each SF has been visited, and the other because although it is more complex, it verifies order of visiting, which is important in a significant subset of cases. Do folks on the list agree with that direction? Yours, Joel From nobody Tue Jun 5 10:44:35 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EE1126DBF for ; Tue, 5 Jun 2018 10:44:33 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tCxv1vHC56G for ; Tue, 5 Jun 2018 10:44:32 -0700 (PDT) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6E81310EC for ; Tue, 5 Jun 2018 10:44:31 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id w55HiT8V019102; Tue, 5 Jun 2018 18:44:29 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9CEE9220DC; Tue, 5 Jun 2018 18:44:29 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 87AF7220DE; Tue, 5 Jun 2018 18:44:29 +0100 (BST) Received: from 950129200 (243.125.113.87.dyn.plus.net [87.113.125.243]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w55HiSTS029716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2018 18:44:29 +0100 Reply-To: From: "Adrian Farrel" To: "'Joel M. Halpern'" , References: In-Reply-To: Date: Tue, 5 Jun 2018 18:44:26 +0100 Message-ID: <01c501d3fcf4$d9534850$8bf9d8f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIz/mzJNy5wQFUQmdWlzEHt1Nq4daOR7DBA Content-Language: en-gb X-Originating-IP: 87.113.125.243 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23890.001 X-TM-AS-Result: No--12.374-10.0-31-10 X-imss-scan-details: No--12.374-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23890.001 X-TMASE-Result: 10--12.373900-10.000000 X-TMASE-MatchedRID: nVQUmLJJeyZf8szgSbttglz+axQLnAVBFJFr2qlKix9JdkX1f2fQXYJg uobn5aAOTWLw2jvbfpw1hgVNDSx/9+yt+a9Mtf+ei+2bC1UYsSQjkrgJ37Rqjxa6DRt6Sf/f/sv dVly7w9nJ//Qj80fwjpYlxuk1ogQATpxma7wJmYoc8J6ZrWP/q30tCKdnhB58vqq8s2MNhPDPPe N6HN6d7Ku6xVHLhqfxIAcCikR3vq+oEX8mi8PlVY8lxVV6l4kdWW7rJZuTut6y3OvOntNcM9xrx VPNApzE X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 17:44:34 -0000 Yes, Joel, That sounds right as these are different levels of function. So long as we add the ability to request/control which level of function is applied to a trace, and so long as we protect that against downgrade attack. A > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 05 June 2018 15:05 > To: sfc@ietf.org > Subject: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms > > My impression of the conversation in London was that the working group > was leaning towards keeping both of the proof of transit algorithms. > One because it is very efficient and confirms that each SF has been visited, > and the other because although it is more complex, it verifies order of > visiting, which is important in a significant subset of cases. > > Do folks on the list agree with that direction? > > Yours, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jun 6 11:23:35 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727D41277D2 for ; Wed, 6 Jun 2018 11:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20stQTVE6PqV for ; Wed, 6 Jun 2018 11:23:28 -0700 (PDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F8712777C for ; Wed, 6 Jun 2018 11:23:28 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2018 11:23:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,484,1520924400"; d="scan'208";a="64864095" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga002.jf.intel.com with ESMTP; 06 Jun 2018 11:23:27 -0700 Received: from orsmsx158.amr.corp.intel.com (10.22.240.20) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 6 Jun 2018 11:23:27 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.118]) by ORSMSX158.amr.corp.intel.com ([169.254.10.35]) with mapi id 14.03.0319.002; Wed, 6 Jun 2018 11:23:27 -0700 From: "Elzur, Uri" To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms Thread-Index: AQHT/NZDFq0iFLOY8UKPAC0XMljkLKRThemQ Date: Wed, 6 Jun 2018 18:23:27 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B899585D56E1361@ORSMSX114.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 18:23:33 -0000 few questions: 1) assume this is not positioned as MANDATORY but rather OPTIONAL, status o= f the I-D is EXPERIMENTAL 2) two mechanisms (consulting the minutes) is low computation and NOT in -o= rder or high computational and in-order? 3) for NSH - will this be packaged in a TLV?=20 Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, June 5, 2018 7:05 AM To: sfc@ietf.org Subject: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms My impression of the conversation in London was that the working group was = leaning towards keeping both of the proof of transit algorithms. One because it is very efficient and confirms that each SF has been visited= , and the other because although it is more complex, it verifies order of v= isiting, which is important in a significant subset of cases. Do folks on the list agree with that direction? Yours, Joel _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jun 6 11:37:05 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBCB128CF3 for ; Wed, 6 Jun 2018 11:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dkfT9HC3Tc0 for ; Wed, 6 Jun 2018 11:36:58 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70964129619 for ; Wed, 6 Jun 2018 11:36:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 48A5F78017C; Wed, 6 Jun 2018 11:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1528310218; bh=gHifjdPFaVu2OBmxh2zxvAzvpBueQeZxovKG6SMnoYM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BweSbg1DIyk8MwfwM+QMIRk3s4gEi7o/ITsTavG+qeEB7eO4gzUdxs80wXvNecRlm 1gbgkPHjGw9EL75AEtdyvjmcDthCBSf5dm1BvrpgvUdTPoTO8SbCal2wFUzvYI7S1K VzDyktjSxT1fFE92KrXiUCvI886ckvOpbIFwha3U= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9AEFC78016F; Wed, 6 Jun 2018 11:36:57 -0700 (PDT) To: "Elzur, Uri" , "sfc@ietf.org" References: <7E05C330D7FD6D4FAD0728C46B899585D56E1361@ORSMSX114.amr.corp.intel.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 6 Jun 2018 14:36:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7E05C330D7FD6D4FAD0728C46B899585D56E1361@ORSMSX114.amr.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 18:37:02 -0000 Not quite Uri. Making something PS does not make it mandatory. Customers decide which RFCs to ask for in products. Vendors decide which RFCs to implement. What Proposed Standard means is that if you want to implement this beahviro in the agreed fashion, this is how to do it. Experimental means that the IETF is not confident that the defined thing is useful / the right way to meet the need / harmless / ... There are clearly additional aspects such as encoding still to be specified before we consider declaring this work complete. The PoT work seems to lend itself to a TLV. There may be some desire to align with whatever we conclude on the IOAM format. Yours, Joel On 6/6/18 2:23 PM, Elzur, Uri wrote: > few questions: > > 1) assume this is not positioned as MANDATORY but rather OPTIONAL, status of the I-D is EXPERIMENTAL > 2) two mechanisms (consulting the minutes) is low computation and NOT in -order or high computational and in-order? > 3) for NSH - will this be packaged in a TLV? > > Thx > > Uri ("Oo-Ree") > C: 949-378-7568 > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, June 5, 2018 7:05 AM > To: sfc@ietf.org > Subject: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms > > My impression of the conversation in London was that the working group was leaning towards keeping both of the proof of transit algorithms. > One because it is very efficient and confirms that each SF has been visited, and the other because although it is more complex, it verifies order of visiting, which is important in a significant subset of cases. > > Do folks on the list agree with that direction? > > Yours, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Jun 6 11:46:39 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFEB128CF3 for ; Wed, 6 Jun 2018 11:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqYbjObJd708 for ; Wed, 6 Jun 2018 11:46:30 -0700 (PDT) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F9C129619 for ; Wed, 6 Jun 2018 11:46:29 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2018 11:46:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,484,1520924400"; d="scan'208";a="230474760" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by orsmga005.jf.intel.com with ESMTP; 06 Jun 2018 11:46:28 -0700 Received: from orsmsx154.amr.corp.intel.com (10.22.226.12) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 6 Jun 2018 11:46:27 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.118]) by ORSMSX154.amr.corp.intel.com ([10.22.226.12]) with mapi id 14.03.0319.002; Wed, 6 Jun 2018 11:46:27 -0700 From: "Elzur, Uri" To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms Thread-Index: AQHT/NZDFq0iFLOY8UKPAC0XMljkLKRThemQgACAdAD//40swA== Date: Wed, 6 Jun 2018 18:46:26 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B899585D56E1402@ORSMSX114.amr.corp.intel.com> References: <7E05C330D7FD6D4FAD0728C46B899585D56E1361@ORSMSX114.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 18:46:35 -0000 SGkgSm9lbA0KDQpUYW5rcyBJIHRoaW5rIHdlIGFyZSBhbGlnbmVkLCBzb3JyeSBpZiBteSB3b3Jk aW5nIGNob2ljZSB3YXMgY29uZnVzaW5nDQoNClRoeA0KDQpVcmkgKOKAnE9vLVJlZeKAnSkNCkM6 IDk0OS0zNzgtNzU2OA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2Vs IE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSANClNlbnQ6IFdlZG5lc2Rh eSwgSnVuZSA2LCAyMDE4IDExOjM3IEFNDQpUbzogRWx6dXIsIFVyaSA8dXJpLmVsenVyQGludGVs LmNvbT47IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LWlldGYtc2ZjLXBy b29mLW9mLXRyYW5zaXQgLSBtZWNoYW5pc21zDQoNCk5vdCBxdWl0ZSBVcmkuICBNYWtpbmcgc29t ZXRoaW5nIFBTIGRvZXMgbm90IG1ha2UgaXQgbWFuZGF0b3J5LiANCkN1c3RvbWVycyBkZWNpZGUg d2hpY2ggUkZDcyB0byBhc2sgZm9yIGluIHByb2R1Y3RzLiAgVmVuZG9ycyBkZWNpZGUgd2hpY2gg UkZDcyB0byBpbXBsZW1lbnQuICBXaGF0IFByb3Bvc2VkIFN0YW5kYXJkIG1lYW5zIGlzIHRoYXQg aWYgeW91IHdhbnQgdG8gaW1wbGVtZW50IHRoaXMgYmVhaHZpcm8gaW4gdGhlIGFncmVlZCBmYXNo aW9uLCB0aGlzIGlzIGhvdyB0byBkbyBpdC4NCg0KRXhwZXJpbWVudGFsIG1lYW5zIHRoYXQgdGhl IElFVEYgaXMgbm90IGNvbmZpZGVudCB0aGF0IHRoZSBkZWZpbmVkIHRoaW5nIGlzIHVzZWZ1bCAv IHRoZSByaWdodCB3YXkgdG8gbWVldCB0aGUgbmVlZCAvIGhhcm1sZXNzIC8gLi4uDQoNClRoZXJl IGFyZSBjbGVhcmx5IGFkZGl0aW9uYWwgYXNwZWN0cyBzdWNoIGFzIGVuY29kaW5nIHN0aWxsIHRv IGJlIHNwZWNpZmllZCBiZWZvcmUgd2UgY29uc2lkZXIgZGVjbGFyaW5nIHRoaXMgd29yayBjb21w bGV0ZS4NCg0KVGhlIFBvVCB3b3JrIHNlZW1zIHRvIGxlbmQgaXRzZWxmIHRvIGEgVExWLiAgVGhl cmUgbWF5IGJlIHNvbWUgZGVzaXJlIHRvIGFsaWduIHdpdGggd2hhdGV2ZXIgd2UgY29uY2x1ZGUg b24gdGhlIElPQU0gZm9ybWF0Lg0KDQpZb3VycywNCkpvZWwNCg0KT24gNi82LzE4IDI6MjMgUE0s IEVsenVyLCBVcmkgd3JvdGU6DQo+IGZldyBxdWVzdGlvbnM6DQo+IA0KPiAxKSBhc3N1bWUgdGhp cyBpcyBub3QgcG9zaXRpb25lZCBhcyBNQU5EQVRPUlkgYnV0IHJhdGhlciBPUFRJT05BTCwgDQo+ IHN0YXR1cyBvZiB0aGUgSS1EIGlzIEVYUEVSSU1FTlRBTA0KPiAyKSB0d28gbWVjaGFuaXNtcyAo Y29uc3VsdGluZyB0aGUgbWludXRlcykgaXMgbG93IGNvbXB1dGF0aW9uIGFuZCBOT1QgaW4gLW9y ZGVyIG9yIGhpZ2ggY29tcHV0YXRpb25hbCBhbmQgaW4tb3JkZXI/DQo+IDMpIGZvciBOU0ggLSB3 aWxsIHRoaXMgYmUgcGFja2FnZWQgaW4gYSBUTFY/DQo+IA0KPiBUaHgNCj4gDQo+IFVyaSAoIk9v LVJlZSIpDQo+IEM6IDk0OS0zNzgtNzU2OA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSm9lbCBNLiBIYWxwZXJuDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgNSwgMjAxOCA3OjA1 IEFNDQo+IFRvOiBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogW3NmY10gZHJhZnQtaWV0Zi1zZmMt cHJvb2Ytb2YtdHJhbnNpdCAtIG1lY2hhbmlzbXMNCj4gDQo+IE15IGltcHJlc3Npb24gb2YgdGhl IGNvbnZlcnNhdGlvbiBpbiBMb25kb24gd2FzIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgd2FzIGxl YW5pbmcgdG93YXJkcyBrZWVwaW5nIGJvdGggb2YgdGhlIHByb29mIG9mIHRyYW5zaXQgYWxnb3Jp dGhtcy4NCj4gT25lIGJlY2F1c2UgaXQgaXMgdmVyeSBlZmZpY2llbnQgYW5kIGNvbmZpcm1zIHRo YXQgZWFjaCBTRiBoYXMgYmVlbiB2aXNpdGVkLCBhbmQgdGhlIG90aGVyIGJlY2F1c2UgYWx0aG91 Z2ggaXQgaXMgbW9yZSBjb21wbGV4LCBpdCB2ZXJpZmllcyBvcmRlciBvZiB2aXNpdGluZywgd2hp Y2ggaXMgaW1wb3J0YW50IGluIGEgc2lnbmlmaWNhbnQgc3Vic2V0IG9mIGNhc2VzLg0KPiANCj4g RG8gZm9sa3Mgb24gdGhlIGxpc3QgYWdyZWUgd2l0aCB0aGF0IGRpcmVjdGlvbj8NCj4gDQo+IFlv dXJzLA0KPiBKb2VsDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiANCg== From nobody Fri Jun 8 09:00:45 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DD8130F18; Fri, 8 Jun 2018 09:00:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vijay Gurbani To: Cc: draft-ietf-sfc-hierarchical.all@ietf.org, ietf@ietf.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152847362891.15388.2522619650189897667@ietfa.amsl.com> Date: Fri, 08 Jun 2018 09:00:28 -0700 Archived-At: Subject: [sfc] Genart last call review of draft-ietf-sfc-hierarchical-08 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 16:00:30 -0000 Reviewer: Vijay Gurbani Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sfc-hierarchical-08 Reviewer: Vijay Gurbani Review Date: 2018-06-08 IETF LC End Date: 2018-05-21 IESG Telechat date: 2018-06-21 Summary: This draft is ready for publication as an Informational. Major issues: None. Minor issues: None. Nits/editorial comments: None. From nobody Sat Jun 9 09:23:40 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FBA130ED4 for ; Sat, 9 Jun 2018 09:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2iodxijCJNo for ; Sat, 9 Jun 2018 09:23:37 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F19130EBE for ; Sat, 9 Jun 2018 09:23:36 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id n3-v6so24485314lfe.12 for ; Sat, 09 Jun 2018 09:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M3q47SlmdJZmiVenmYfjiKwXTjoUgF3rMHDa6j01I34=; b=vTZpe+lyvlNJtRp4DD9IZZuBlA8r1UpSTIjW3VkgH3yNDCdPykjVEqdSB6KJWtSWUB Sgzoho8TfzpoBpTLe6NrnnVMuUndBzCKJ6T0Iu+21bPWpgzH7ZGtuQ33DqZoj2JM59X2 lHEbqwQaZtOe8Pq/IrRv+2JAElSKB3GvOHi2LU/N1b9GbSbQszw6B2pRD1cqvYoldpNs jbA7O1b/S0uMGoCU1i2AcqRvt/6F+I3WDBZCt5tI8J0tlPTF9f8ODqmDeg3mD0N1T/T3 IQQVgip37diQRhkTwmrbjbShY3hea1GYLQG6fsFPczBaUlt01cqD/Ns9dVv/pq1rNuh4 gQ3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M3q47SlmdJZmiVenmYfjiKwXTjoUgF3rMHDa6j01I34=; b=NUlbXfDuNOZtQMROmTMq6JKBAP68Y0zwNuiiXaSsw891gPtvYQ61CNvynuBn816I6T vO7ujI/0TgPNsxuxmplTCmVpyX+OWtmCTDYk7cRIc2WxNmLWJ3AbfjJe+uMNW1zyX8fE jjhVLfODV+IFDieaQBWpZakwGrQYEQtrU8hvsirQqsgPlEmN83q2KZ5Km1JZ8RzY1aiK BXpWjoLbWLYGP4+LGxwnK0FQYotJrAV+s2XZgdlWLEvtSYuFlH32JJLB923KSukL7fTW GDkbwvlSMvKTk9pgEVbAcPK7lueGxjj4l+XHXcyhWsSa3w0aQ07vwTBUxzj8lQd++PrR o8SA== X-Gm-Message-State: APt69E0FInvLTZddg5el1CYtfJ0B3pDNVhZVx+lJu9UeNXvvr1zJwo1/ 8bvMMxFsdf0C0rGHLqJFTcqZJkMxzkaoMdZz8RQ= X-Google-Smtp-Source: ADUXVKKlhErirKSKuM4ah5cS7EHMv2ctfjWHAfj6Jym3w8aoZbapJBpKbS2a/i04+n/9DdkHOpssZXW4XYRbvI/zkec= X-Received: by 2002:a2e:878f:: with SMTP id n15-v6mr7247764lji.69.1528561414785; Sat, 09 Jun 2018 09:23:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Sat, 9 Jun 2018 09:23:33 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Sat, 9 Jun 2018 09:23:33 -0700 Message-ID: To: "Joel M. Halpern" Cc: "sfc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000025500d056e37f07c" Archived-At: Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 16:23:39 -0000 --00000000000025500d056e37f07c Content-Type: text/plain; charset="UTF-8" Hi Joel, et. al, I think that, as with any solution proposal, we need to check it against the use case(s) and the requirements that characterize these cases. I don't see these being discussed in the draft. As you've pointed, the draft addresses two cases: - verification that pre-defined set of nodes was visited; - verification that pre-defined ordered set of nodes was traversed in the expected order. What are the use cases for each solution and are both required or only the latter, as the stronger and complete, has a practical use? What being verified - traversing SF or SFF? The list will grow as we look into the use cases. And one more, the proposed solution is only one of many algorithms. I believe it will be future proof to allow for other algos to be used. Regards, Greg On Tue, Jun 5, 2018 at 7:05 AM, Joel M. Halpern wrote: > My impression of the conversation in London was that the working group was > leaning towards keeping both of the proof of transit algorithms. > One because it is very efficient and confirms that each SF has been > visited, > and the other because although it is more complex, it verifies order of > visiting, which is important in a significant subset of cases. > > Do folks on the list agree with that direction? > > Yours, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --00000000000025500d056e37f07c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joel, et. al,
I think that, as with any solution pr= oposal, we need to check it against the use case(s) and the requirements th= at characterize these cases. I don't see these being discussed=C2=A0in = the draft. As you've pointed, the draft addresses two cases:
=
  • verification that pre-defined set of nodes was visited;
  • ver= ification that pre-defined ordered set of nodes was traversed in the expect= ed order.
What are the use cases for each solution and are both re= quired or only the latter, as the stronger and complete, has a practical us= e?
What being verified - traversing SF or SFF?

The list will grow as we look into the use cases.

And one more, the proposed solution is only one of many algorithms. = I believe it will be future proof to allow for other algos=C2=A0to be used.=

Regards,
Greg

On Tue, Jun 5, 2018 at 7:05 AM,= Joel M. Halpern <jmh@joelhalpern.com> wrote:
My impression of the conversation in London was that = the working group was leaning towards keeping both of the proof of transit = algorithms.
One because it is very efficient and confirms that each SF has been visited= ,
and the other because although it is more complex, it verifies order of vis= iting, which is important in a significant subset of cases.

Do folks on the list agree with that direction?

Yours,
Joel

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

--00000000000025500d056e37f07c-- From nobody Wed Jun 13 02:12:58 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D7D13107F; Wed, 13 Jun 2018 02:12:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152888116400.15234.7012151415483731970@ietfa.amsl.com> Date: Wed, 13 Jun 2018 02:12:44 -0700 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-hierarchical-09.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 09:12:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Hierarchical Service Function Chaining (hSFC) Authors : David Dolson Shunsuke Homma Diego R. Lopez Mohamed Boucadair Filename : draft-ietf-sfc-hierarchical-09.txt Pages : 26 Date : 2018-06-13 Abstract: Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration. The goals of hSFC are to make a large-scale network easier to reason about, simpler to control and to support independent functional groups within large network operators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-09 https://datatracker.ietf.org/doc/html/draft-ietf-sfc-hierarchical-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-hierarchical-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 13 02:15:42 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27830130EDF; Wed, 13 Jun 2018 02:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSj6bpXzVQgH; Wed, 13 Jun 2018 02:15:29 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D154130E18; Wed, 13 Jun 2018 02:15:29 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 9EAF0C0EFA; Wed, 13 Jun 2018 11:15:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 7E1C718006C; Wed, 13 Jun 2018 11:15:27 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0389.001; Wed, 13 Jun 2018 11:15:26 +0200 From: To: Ines Robles , "rtg-dir@ietf.org" CC: "draft-ietf-sfc-hierarchical.all@ietf.org" , "ietf@ietf.org" , "sfc@ietf.org" Thread-Topic: Rtgdir last call review of draft-ietf-sfc-hierarchical-08 Thread-Index: AQHT8VGLlh+NMdzUK0Sk0czeyKklNKReCxTw Date: Wed, 13 Jun 2018 09:15:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF35797@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152694106121.7908.13286903159935171274@ietfa.amsl.com> In-Reply-To: <152694106121.7908.13286903159935171274@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Rtgdir last call review of draft-ietf-sfc-hierarchical-08 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 09:15:33 -0000 SGkgSW5lcywgDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldyAoQXBvbG9naWVzIGZvciB0aGUg ZGVsYXkgdG8gcmVwbHkgdG8gdGhpcyByZXZpZXcpLiANCg0KQWxsIHlvdXIgY29tbWVudHMgd2Vy ZSB0YWtlbiBpbnRvIGFjY291bnQuIFBsZWFzZSB0aGUgbmV3IHZlcnNpb24gYXQ6IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLWhpZXJhcmNoaWNhbC8gDQoN CkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBJ bmVzIFJvYmxlcyBbbWFpbHRvOm1hcmlhaW5lc3JvYmxlc0Bnb29nbGVtYWlsLmNvbV0NCj4gRW52 b3nDqcKgOiBtYXJkaSAyMiBtYWkgMjAxOCAwMDoxOA0KPiDDgMKgOiBydGctZGlyQGlldGYub3Jn DQo+IENjwqA6IGRyYWZ0LWlldGYtc2ZjLWhpZXJhcmNoaWNhbC5hbGxAaWV0Zi5vcmc7IGlldGZA aWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSdGdkaXIgbGFzdCBjYWxsIHJldmll dyBvZiBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWwtMDgNCj4gDQo+IFJldmlld2VyOiBJbmVz IFJvYmxlcw0KPiBSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQo+IA0KPiBIZWxsbywNCj4gDQo+ IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2Vy IGZvciB0aGlzIGRyYWZ0Lg0KPiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZp ZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cw0KPiBhcyB0aGV5IHBhc3Mg dGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24g c3BlY2lhbA0KPiByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZw0KPiBBRHMuDQo+IEZvciBtb3JlIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo+IOKAi2h0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4gDQo+IEFs dGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJv dXRpbmcgQURzLCBpdA0KPiB3b3VsZA0KPiBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRl ciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdCBDYWxsDQo+IGNvbW1lbnRzDQo+ ICB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRp c2N1c3Npb24gb3IgYnkNCj4gdXBkYXRpbmcNCj4gIHRoZSBkcmFmdC4NCj4gDQo+IERvY3VtZW50 OiBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWwtMDgNCj4gUmV2aWV3ZXI6IEluZXMgUm9ibGVz DQo+IFJldmlldyBEYXRlOiAwNS0yMS0yMDE4DQo+IEludGVuZGVkIHN0YXR1czogSW5mb3JtYXRp b25hbA0KPiANCj4gU3VtbWFyeToNCj4gDQo+IEkgYmVsaWV2ZSB0aGUgZHJhZnQgaXMgdGVjaG5p Y2FsbHkgZ29vZC4gVGhpcyBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0ZW4gYW5kDQo+IGNsZWFyIHRv IHVuZGVyc3RhbmQuIFRoZSBmaWd1cmVzIGFyZSBjbGVhciBhbmQgaGVscGZ1bC4gVGhlIGRyYWZ0 IHByZXNlbnRzDQo+IHNvbWUNCj4gbWlub3IgaXNzdWVzIHRoYXQgSSB0aGluayBzaG91bGQgYmUg cmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KPiANCj4gQ29tbWVudHM6DQo+IA0KPiBNYWpv ciBJc3N1ZXM6IE5vIG1ham9yIGlzc3VlcyBmb3VuZC4NCj4gDQo+IE1pbm9yIElzc3VlczoNCj4g DQo+IC0gSXQgd291bGQgYmUgbmljZSB0byBhZGQgYSB0ZXJtaW5vbG9neSBzZWN0aW9uIHRoYXQg cmVmZXJlbmNlcyBzZWN0aW9uIDEuNA0KPiBvZg0KPiByZmM3NjY1LCBzZWN0aW9uIDEuMyBvZiBy ZmM4MzAwIChzaW5jZSB5b3UgYXJlIHVzaW5nIE5TSC1hd2FyZSBkZWZpbmVkIHRoZXJlKQ0KPiBh bmQgYWRkIGRlZmluaXRpb25zIHN1Y2ggYXMgSUJOLiAtIFF1ZXN0aW9uOiBhYm91dCB0aGlzIHNl bnRlbmNlIGluIHBhZy4gMzoNCj4gIi4uLlRoZSAiZG9tYWlucyIgZGlzY3Vzc2VkIGluIHRoaXMg ZG9jdW1lbnQgYXJlIGFzc3VtZWQgdG8gYmUgdW5kZXIgdGhlDQo+ICAgIGNvbnRyb2wgb2YgYSBz aW5nbGUgb3JnYW5pemF0aW9uLi4uIi4gSXMgaXQgdGhlIHNhbWUgaWYgd2Ugc2F5ICIuLi5UaGUN Cj4gICAgIlNGQy1FbmFibGVkIERvbWFpbnMiIGRpc2N1c3NlZCBpbiB0aGlzIGRvY3VtZW50IGFy ZSBhc3N1bWVkIHRvIGJlIHVuZGVyDQo+IHRoZQ0KPiAgICBjb250cm9sIG9mIGEgc2luZ2xlIG9y Z2FuaXphdGlvbiAuLi4iPw0KPiBOaXRzOg0KPiAtLSBJdCB3b3VsZCBiZSBuaWNlIHRvIGV4cGFu ZCBOU0ggaW4gdGhlIEludHJvZHVjdGlvbiBzZWN0aW9uLg0KPiAtLSBJbiBGaWd1cmUgMSwgaXQg d291bGQgYmUgbmljZSB0byBhZGQgYSBudW1iZXIgdG8gdGhlIENsYXNzaWZpZXJzLA0KPiBlLmcu Q0YjMSwNCj4gdGhlbiB3aGVuIHlvdSBtZW50aW9uIHRoYXQgaW4gdGhlIHRleHQgeW91IGNhbiBy ZWZlcmVuY2UgaXQsIGUuZy4gIk9uZSBwYXRoDQo+IGlzDQo+IHNob3duIGZyb20gZWRnZSBjbGFz c2lmaWVyIChDRiMxKSB0byBTRkYxIHRvIFN1Yi1kb21haW4jMS4uLiIgLS0gSW4gRmlndXJlIDYs DQo+IGl0IHdvdWxkIGJlIG5pY2UgdG8gYWRkIGluIHRoZSBsZWdlbmQgc2VjdGlvbiB0aGUgbWVh bmluZyBmb3IgRFBJLg0KPiANCj4gVGhhbmtzLA0KPiANCj4gSW5lcy4NCg0K From nobody Wed Jun 13 02:20:33 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB97130E0A; Wed, 13 Jun 2018 02:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E1bXcuMq-Ap; Wed, 13 Jun 2018 02:20:14 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33EC130EB2; Wed, 13 Jun 2018 02:20:14 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 2D3EEC078D; Wed, 13 Jun 2018 11:20:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 01E08120083; Wed, 13 Jun 2018 11:20:13 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0389.001; Wed, 13 Jun 2018 11:20:12 +0200 From: To: Sean Turner , "secdir@ietf.org" CC: "draft-ietf-sfc-hierarchical.all@ietf.org" , "ietf@ietf.org" , "sfc@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-sfc-hierarchical-08 Thread-Index: AQHT91gIey1rcuKs3U+uFAmpphPKT6Rd/37g Date: Wed, 13 Jun 2018 09:20:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF357C6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152760355124.12572.4328281075629737814@ietfa.amsl.com> In-Reply-To: <152760355124.12572.4328281075629737814@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Secdir last call review of draft-ietf-sfc-hierarchical-08 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 09:20:20 -0000 SGkgU2VhbiwgDQoNClRoYW5rIHlvdS4NCg0KRmlndXJlIDQgaXMgcHJvdmlkZWQgYXMgKiogYW4g ZXhhbXBsZSAqKiB0byBpbGx1c3RyYXRlIGhvdyB0aGUgZmxvdyBJRCBjYW4gYmUgcGxhY2VkIG9u IHRoZSBOU0guIFRoaXMgaXMgbm90IG5vcm1hdGl2ZS4gICANCg0KQ2hlZXJzLA0KTWVkDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IFNlYW4gVHVybmVyIFttYWlsdG86 c2VhbkBzbjNyZC5jb21dDQo+IEVudm95w6nCoDogbWFyZGkgMjkgbWFpIDIwMTggMTY6MTkNCj4g w4DCoDogc2VjZGlyQGlldGYub3JnDQo+IENjwqA6IGRyYWZ0LWlldGYtc2ZjLWhpZXJhcmNoaWNh bC5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiBPYmpldMKgOiBT ZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWwtMDgN Cj4gDQo+IFJldmlld2VyOiBTZWFuIFR1cm5lcg0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KPiAN Cj4gSGkhIEnigJltIG5vIGV4cGVydCBvbiBTRkMgc28gSSBzcGVudCBzb21lIHRpbWUgcmV2aWV3 aW5nIFJGQzc2NjUgYW5kIFNpbW9uDQo+IEpvc2Vmc3NvbuKAmXMgc2VjZGlyIHJldmlldyBbMF0g YXMgd2VsbCBhcyBSRkMgODMwMCBhbmQgODM5My4gIEl0IGxvb2tzIGxpa2UNCj4gYWxsDQo+IHRo ZSB0aGluZ3MgSSB3YXMgZ29pbmcgdG8gcGljayBvbiBhcmUgYWRkcmVzc2VkIGJ5IHRoZSByZWZl cmVuY2VzLg0KPiANCj4gSeKAmWxsIGxldCBzb21lYm9keSBlbHNlIG9uIHRoZSBJRVNHIGRlYmF0 ZSB3aGV0aGVyIEZpZ3VyZSA0IGlzIHRyeWluZyB0byBiZSBhDQo+IGxpdHRsZSBkaWZmZXJlbnQg dGhhbiB0aGUgcmVzdCBvZiB0aGlzIGFyY2hpdGVjdHVyYWwgZG9jdW1lbnQgYnkgc3BlY2lmeSBz b21lDQo+IHByb3RvY29scyBiaXRzOyBpbmZvcm1hdGlvbmFsIHN0aWxsPw0KPiANCj4gWzBdDQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3Jldmlldy1pZXRmLXNmYy1hcmNoaXRl Y3R1cmUtMDgtc2VjZGlyLWxjLQ0KPiBqb3NlZnNzb24tMjAxNS0wNS0yOC8NCg0K From nobody Mon Jun 18 05:50:37 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC74130E9A; Mon, 18 Jun 2018 05:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP4_UNJD5Qpu; Mon, 18 Jun 2018 05:50:25 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EC5126DBF; Mon, 18 Jun 2018 05:50:25 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B33349963E735; Mon, 18 Jun 2018 13:50:20 +0100 (IST) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 18 Jun 2018 13:50:22 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.141]) by SJCEML701-CHM.china.huawei.com ([169.254.3.24]) with mapi id 14.03.0382.000; Mon, 18 Jun 2018 05:50:16 -0700 From: James N Guichard To: "bruno.decraene@orange.com" , "spring@ietf.org" CC: "sfc@ietf.org" Thread-Topic: IETF 102 - SPRING meeting Thread-Index: AdQG7OtmRpyx634bT6eW+ZbHbzvq7wAFaLyQ Date: Mon, 18 Jun 2018 12:50:15 +0000 Message-ID: References: <28026_1529317804_5B2789AC_28026_51_1_53C29892C857584299CBF5D05346208A47AA2D9D@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <28026_1529317804_5B2789AC_28026_51_1_53C29892C857584299CBF5D05346208A47AA2D9D@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.213] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA313516139sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] IETF 102 - SPRING meeting X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 12:50:30 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA313516139sjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bruno, I would like to get a 15 minute slot (10 to present, 5 Q&A) to present http= s://datatracker.ietf.org/doc/draft-guichard-sfc-nsh-sr/ .. speaker will be = myself. Thanks! Jim From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Monday, June 18, 2018 6:30 AM To: spring@ietf.org Subject: [spring] IETF 102 - SPRING meeting Hi all, During IETF 102, the SPRING WG is currently scheduled to meet Monday 13:30-= 15:30. We have a two hours session. https://datatracker.ietf.org/meeting/102/agenda.html It is time start building the SPRING WG agenda for Montreal. Please send your request for a presentation slot, indicating draft name, sp= eaker, and desired duration (covering presentation and discussion), before = Monday 2018-07-02 09:00 CET. Before is better. If it is not the first presentation of a non-WG draft, please give a reason= why it is required to have a new presentation slot. A checklist is available on the wiki: https://trac.ietf.org/trac/spring/wik= i/Checklist%20for%20presenting%20at%20a%20SPRING%20meeting As we are meeting on Monday, please send your slides on time, before Sunday= 18:00 local time. Earlier is better. Thanks, --Bruno, Rob ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA313516139sjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bruno,

 

I would like to get a = 15 minute slot (10 to present, 5 Q&A) to present htt= ps://datatracker.ietf.org/doc/draft-guichard-sfc-nsh-sr/ .. speaker wil= l be myself.

 

Thanks!

 

Jim<= /p>

 

From: spring [mailto:spring-bounces@ietf.org]= On Behalf Of bruno.decraene@orange.com
Sent: Monday, June 18, 2018 6:30 AM
To: spring@ietf.org
Subject: [spring] IETF 102 - SPRING meeting

 

Hi all,
 
During IETF 102, the SPRING WG is currently scheduled to meet Monday =
13:30-15:30. We have a two hours session.

https://datatracker.ietf.org/meeting/102/agenda.html

 

It is time start building the SPRING WG agenda fo= r Montreal.

Please send your request for a presentation slot,= indicating draft name, speaker, and desired duration (covering presentatio= n and discussion), before Monday 2018-07-02  09:00 CET. Before is bett= er.

If it is not the first presentation of a non-WG d= raft, please give a reason why it is required to have a new presentation sl= ot.

A checklist is available on the wiki: https://trac.ietf.org/trac/spring/wiki/Checklist%20for%20presenting%20at%20= a%20SPRING%20meeting

 

As we are meeting on Monday, please send your sli= des on time, before Sunday 18:00 local time. Earlier is better.<= /p> 

 

Thanks,

--Bruno, Rob

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA313516139sjceml521mbxchi_-- From nobody Tue Jun 19 01:12:29 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7E212D7F8; Tue, 19 Jun 2018 01:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33EryTbzks4l; Tue, 19 Jun 2018 01:12:24 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A603130DEB; Tue, 19 Jun 2018 01:12:24 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id e16-v6so18323033wmd.0; Tue, 19 Jun 2018 01:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NT/A/dbD7FTv1s9bbZBHz0CmpK8626acqruO+9ZGnHo=; b=JfzKNeKDwcFE0OH60/U1PFXStASUQ8uOKer+eKV6/sdAxzEg05+0HL3Jq3CXnVkjzh Qg62BJUoffXt26h6x/wy7hQ51oesJhF5d8ysU/fnbgvrxbyA8kUVIMdBFiXJ/kAqgtky 63MuO4XfLCRON+zXZOtsIwYf3fknVBPXj2aAUjRDvZCE9cn2PLmHud3ff83VavvyeKj7 XYPEuNjqBpuFm9qOJXmDszZzWxnSH+lK7pbWEa5/p6QVs/7GS8bwI00NdniU79+AJhVG kNFYwglgiC2p76PDnsBjemktyom2HQZIfy+BMZQZSc3mlPx70UPuWDAh7a47CkpqlocS kQ+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NT/A/dbD7FTv1s9bbZBHz0CmpK8626acqruO+9ZGnHo=; b=lYWahfq0k4WudznYvAoS/sg4F7YCI/bbEmSuChLHY4W+phR70qOAcfR0FFRXVeCe7M EWk/h8SrUaiJO8Awofw/D0zBmxVsuKqMXFwOV1apMcFUYIyef+OFVisgEPBr147DAiTf BBiijB5egTDY9x5IocLEc9XBAyTIfvxc/K9i6K1kiNZsG9dXqGemCLWqSmwAoOJPpbEg MvCnWOd8q+mxH6McrKspkdLmMcyvBJ6HKvb99TiQP+Az85wXHaPrToF2FS8rt8q9WxB7 wWdoCc7WyVAuCZaHTD1ovcCa9aMPX5M7UWlyxU5wAj9N5LvkyBnpSZTEHR9Q1F0Bu+9x OlUw== X-Gm-Message-State: APt69E0RSzTsZ9ZN3lp8+MWfgox9tp8GHsIoEch9uQTHuBCQioUu43aa e/EEp15MtaZ82DldO2iEGh0mGFOzUwWfTs/2SPWk8Q== X-Google-Smtp-Source: ADUXVKLx3rSxhGxRYo+aFuLqIzjB1Cnb5ktXqEqFBUEgo7DyiqqyVggQzt7vQhk/g8q+ROEJp4uT+pnXoEzbqiJEgXc= X-Received: by 2002:a50:ef17:: with SMTP id m23-v6mr14090393eds.10.1529395942592; Tue, 19 Jun 2018 01:12:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:a9c2:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 01:12:22 -0700 (PDT) From: Tal Mizrahi Date: Tue, 19 Jun 2018 11:12:22 +0300 Message-ID: To: sfc@ietf.org, sfc-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000e11286056efa3df0" Archived-At: Subject: [sfc] IETF 102 SFC - Call for Agenda Items X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 08:12:27 -0000 --000000000000e11286056efa3df0 Content-Type: text/plain; charset="UTF-8" Hi, We are starting to work on the agenda for the SFC session in IETF 102. If you have a draft that you would like to discuss, please send a request to sfc-chairs@ietf.org including the name of the draft, the presenter's name, and how much time you need. Also please make note of the draft cutoff date, which is the 2nd of July. If you are planning to update your draft(s) before IETF 102, we encourage you to do so as soon as possible, to allow people to review the drafts before the meeting. Please note that a preliminary version of the agenda for IETF 102 is available: https://datatracker.ietf.org/meeting/102/agenda.html Cheers, Tal. --000000000000e11286056efa3df0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

=
We are starting to work on the agenda for the SFC se= ssion in IETF 102.

If you = have a draft that you would like to discuss, please send a request to= =C2=A0sfc-chairs@ietf.org=C2=A0includi= ng the name of the draft, the presenter's name, and how much time you n= eed.

Also please make note= of the draft cutoff date, which is the 2nd of July. If you are planning to= update your draft(s) before IETF 102, we encourage you to do so as soon as= possible, to allow people to review the drafts before the meeting.

Please note that a preliminary ve= rsion of the agenda for IETF 102 is available:

Cheers,
Tal.

--000000000000e11286056efa3df0-- From nobody Tue Jun 19 02:06:24 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 880D51310B9; Tue, 19 Jun 2018 02:06:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152939918251.13026.5239534408020819983@ietfa.amsl.com> Date: Tue, 19 Jun 2018 02:06:22 -0700 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-broadband-allocation-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 09:06:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : NSH Context Header Allocation for Broadband Authors : Jeffrey Napper Surendra Kumar Praveen Muley Wim Hendericks Mohamed Boucadair Filename : draft-ietf-sfc-nsh-broadband-allocation-01.txt Pages : 9 Date : 2018-06-19 Abstract: This document provides a recommended allocation of Network Service Header (NSH) context headers within the broadband service provider network context. Both fixed and mobile deployments are considered. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-broadband-allocation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sfc-nsh-broadband-allocation-01 https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-broadband-allocation-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-broadband-allocation-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 19 02:13:02 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D18130DEB for ; Tue, 19 Jun 2018 02:13:01 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQBHJIkMSoJ0 for ; Tue, 19 Jun 2018 02:12:59 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF916130DD0 for ; Tue, 19 Jun 2018 02:12:58 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4DA10160D7F for ; Tue, 19 Jun 2018 11:12:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 36BB318006A for ; Tue, 19 Jun 2018 11:12:57 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0399.000; Tue, 19 Jun 2018 11:12:57 +0200 From: To: "sfc@ietf.org" Thread-Topic: I-D Action: draft-guichard-sfc-nsh-sr-02.txt Thread-Index: AQHUB0sfYU7NdAhIZUWXvNIwTrTsHKRnTMHA Date: Tue, 19 Jun 2018 09:12:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF4855B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152935719932.3264.11190167702442846801@ietfa.amsl.com> In-Reply-To: <152935719932.3264.11190167702442846801@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sfc] TR: I-D Action: draft-guichard-sfc-nsh-sr-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 09:13:01 -0000 FYI. Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: lundi 18 juin 2018 23:27 > =C0=A0: i-d-announce@ietf.org > Objet=A0: I-D Action: draft-guichard-sfc-nsh-sr-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : NSH and Segment Routing Integration for Service > Function Chaining (SFC) > Authors : James N Guichard > Haoyu Song > Jeff Tantsura > Joel Halpern > Wim Henderickx > Mohamed Boucadair > Filename : draft-guichard-sfc-nsh-sr-02.txt > Pages : 15 > Date : 2018-06-18 >=20 > Abstract: > This document describes two application scenarios where Network > Service Header (NSH) and Segment Routing (SR) techniques can be > deployed together to support Service Function Chaining (SFC) in an > efficient manner while maintaining separation of the service and > transport planes as originally intended by the SFC architecture. >=20 > In the first scenario, an NSH-based SFC is created using SR as the > transport between SFFs. SR in this case is just one of many > encapsulations that could be used to maintain the transport- > independent nature of NSH-based service chains. >=20 > In the second scenario, SR is used to represent each service hop of > the NSH-based SFC as a segment within the segment-list. SR and NSH > in this case are integrated. >=20 > In both scenarios SR is responsible for steering packets between SFFs > along a given SFP while NSH is responsible for maintaining the > integrity of the service plane, the SFC instance context, and any > associated metadata. >=20 > These application scenarios demonstrate that NSH and SR can work > jointly and complement each other leaving the network operator with > the flexibility to use whichever transport technology makes sense in > specific areas of their network infrastructure, and still maintain an > end-to-end service plane using NSH. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-guichard-sfc-nsh-sr/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-guichard-sfc-nsh-sr-02 > https://datatracker.ietf.org/doc/html/draft-guichard-sfc-nsh-sr-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-guichard-sfc-nsh-sr-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 nobody Tue Jun 19 08:14:27 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9F5130E9F; Tue, 19 Jun 2018 08:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24TWvntg7bUf; Tue, 19 Jun 2018 08:14:24 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8CC9126DBF; Tue, 19 Jun 2018 08:14:23 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id h6-v6so77163otj.0; Tue, 19 Jun 2018 08:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eBX8tSERPhSnK4wlvKNqiPo5/w9o6yx4gli0USe3Ung=; b=MQG/5rD364m1+EuOSQs0qpImjpq5Uej6pKgh4aiWUX1yuqcMnfnjHejp6Hvs4BDKHZ Xsk/b/XZFULV2NXYGUiRuLMWBPvYbuvdDzvrWL28cOeE95sOigXoxReuZkjkTII8+74P ZrksAh64EdoXXI9GeQzv32KnOsqLlwsqPLuzn3S/PzhbJ8201yYGZHq6wzdlqqpX9pHS 3+vUl+WtFuXF8JG7/1gji0ieoteIB+Kv0Yglr2fbPSEBgzUkBj+4lQ37a6LwoZBKb1mZ J0aWteN0041fbuFZVZ/EzEKSXAQ12S0QPsuKOME6j9EkrMUViT73ldWejwOCiIjvCuJP hsRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eBX8tSERPhSnK4wlvKNqiPo5/w9o6yx4gli0USe3Ung=; b=sKNPGqJVn4k3hk9AK92MGJnZMRczGARQJUqA0bc0MhWI2ooPbB1y6dHrz3VuaiX0Ra 5UI/paT1W/TNWT0QuIYISnaq9LolbJd1Q0MW/yZBwMTRltDm34Tb5O1C0/cAeKdpi2tK HhMawauoEGPM//YzJl6fHEvpSOose6Ew8X9PkaaqCz4WUxArGvp3EbBHzsijktt20KNZ SuqxCKUegLCDy9qF6cnG7ddFUZZc6kiztfzQP7ioIpFn+WbTV6FTTCu0UpTcYzsx2Zcs QzePUEXf8mccKdJhSpB3fV5RW/llSVSc4XlRRCguu0umNN2lX85j6AaSiGcu2ILm5kv2 zijw== X-Gm-Message-State: APt69E2BZvb4g10aq02bNDJBK/Ey9N4weEl3Y0spYQTxVh2847uyuCg4 recl1yF9oq/7lWQ65ug7+XsNiIGdXus75g1Wq5Irpg== X-Google-Smtp-Source: ADUXVKJ+qCybUPL8oIU+jnQlq050nnOIByKMHse+QUYNeuLE0d9x2OHnbmkNsSd7YKX8vsQ9GBXfhbrZFVkwhw14UtE= X-Received: by 2002:a9d:27a6:: with SMTP id c35-v6mr11379305otb.56.1529421263099; Tue, 19 Jun 2018 08:14:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c3:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 08:14:02 -0700 (PDT) From: "Andrew G. Malis" Date: Tue, 19 Jun 2018 11:14:02 -0400 Message-ID: To: mpls@ietf.org, sfc@ietf.org Content-Type: multipart/alternative; boundary="000000000000195bc5056f0023cd" Archived-At: Subject: [sfc] Request for comments on draft-malis-mpls-sfc-encapsulation-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:14:26 -0000 --000000000000195bc5056f0023cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99ve just uploaded https://tools.ietf.org/html/draft-malis-mpls-sfc= - encapsulation-00 . It=E2=80=99s a short draft that discusses how to carry S= FC packets that include the NSH over MPLS from one SFF to the next, so that SFFs that support the NSH can be connected via MPLS. It also includes the ability for MPLS nodes to support more than one SFF. Comments are appreciated! Thanks, Andy --000000000000195bc5056f0023cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99ve just uploaded=C2=A0https://tools.ietf.o= rg/html/draft-malis-mpls-sfc-encapsulation-00=C2=A0. It=E2=80= =99s a short draft that discusses how to carry SFC packets that include the= NSH over MPLS from one SFF to the next, so that SFFs that support the NSH = can be connected via MPLS. It also includes the ability for MPLS nodes to s= upport more than one SFF. Comments are appreciated!

Than= ks,
Andy

--000000000000195bc5056f0023cd-- From nobody Tue Jun 19 14:43:44 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D11E127148; Tue, 19 Jun 2018 14:43:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-sfc-hierarchical@ietf.org, Behcet Sarikaya , sfc-chairs@ietf.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152944462163.32387.10898454540152524931.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2018 14:43:41 -0700 Archived-At: Subject: [sfc] Alvaro Retana's Abstain on draft-ietf-sfc-hierarchical-09: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 21:43:42 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-sfc-hierarchical-09: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The hSFC concept is indeed interesting -- thanks for doing the work! Reading through the document, I found myself thinking about its usefulness. The Introduction says that it "focuses on the difficult problem of implementing SFC across a large, geographically dispersed network, potentially comprised of millions of hosts and thousands of network forwarding elements, and which may involve multiple operational teams (with varying functional responsibilities)." However, the content doesn't deal directly with the implementation/operational issues -- and offers instead a list of options around the IBN, with no clear or explicit recommendation. Even though it is not explicitly mentioned anywhere, I think that is the intent of the document. The options themselves include speculation about how things could work; including, for example, state synchronization between IBNs (§4.1.1) without specific proposals...or, my favorite, the nesting of NSH headers (§4.1.4). I note that even though the NSH spec (rfc8300) offers a Next Protocol value of "NSH", and the architecture (rfc7665) is such that "the SFC encapsulation remain transport independent...[and]...any network transport protocol may be used", it may not be possible to add/remove NSH Headers within specific transport encapsulations...but that is not discussed. Again, I think that was the intent. The design of the document (present options, but don't dig deep into any of them) is ok. It would be nicer if the WG would move this work forward by exploring the options, specifying them and having detailed operational considerations related to "the difficult problem of implementing SFC" and how hSFC may help. But I didn't find related work in the datatracker. In the end, I believe that this document is valuable as a discussion piece which may lead to future work...but, in my opinion, it doesn't need to be published as an RFC to serve that purpose...and it could in fact benefit from further analysis and evaluation before eventual publication reflecting *the* hSFC architecture. Given that we're at the IESG Evaluation point in the process, I won't stand in the way of publication and have chosen to ABSTAIN instead. From nobody Tue Jun 19 20:24:38 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9432130EA1; Tue, 19 Jun 2018 20:24:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-sfc-hierarchical@ietf.org, Behcet Sarikaya , sfc-chairs@ietf.org, sarikaya@ieee.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152946506975.32330.12254535644684416668.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2018 20:24:29 -0700 Archived-At: Subject: [sfc] Ben Campbell's No Objection on draft-ietf-sfc-hierarchical-09: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 03:24:30 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sfc-hierarchical-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §10: "This document describes systems that may be managed by distinct teams of a single administrative entity." I had to re-read this a few times to realize you meant distinct teams that are all part of the same entity, not distinct teams each made up of one entity. From nobody Tue Jun 19 23:05:18 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E7A130EB9; Tue, 19 Jun 2018 23:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbuDQP0hC0Ku; Tue, 19 Jun 2018 23:04:50 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEF8131045; Tue, 19 Jun 2018 23:04:50 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 19B4B61140; Wed, 20 Jun 2018 08:04:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id EA57C180076; Wed, 20 Jun 2018 08:04:47 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0399.000; Wed, 20 Jun 2018 08:04:47 +0200 From: To: Alvaro Retana , The IESG CC: "draft-ietf-sfc-hierarchical@ietf.org" , Behcet Sarikaya , "sfc-chairs@ietf.org" , "sfc@ietf.org" Thread-Topic: Alvaro Retana's Abstain on draft-ietf-sfc-hierarchical-09: (with COMMENT) Thread-Index: AQHUCBaY4XoeDufItEWTNiHSiKc1+aRoogYw Date: Wed, 20 Jun 2018 06:04:47 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF49018@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152944462163.32387.10898454540152524931.idtracker@ietfa.amsl.com> In-Reply-To: <152944462163.32387.10898454540152524931.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Alvaro Retana's Abstain on draft-ietf-sfc-hierarchical-09: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 06:04:53 -0000 SGkgQWx2YXJvLCANCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiANCg0KUGxlYXNlIHNlZSBp bmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQgDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+IERlwqA6IEFsdmFybyBSZXRhbmEgW21haWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tXQ0K PiBFbnZvecOpwqA6IG1hcmRpIDE5IGp1aW4gMjAxOCAyMzo0NA0KPiDDgMKgOiBUaGUgSUVTRw0K PiBDY8KgOiBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWxAaWV0Zi5vcmc7IEJlaGNldCBTYXJp a2F5YTsgc2ZjLQ0KPiBjaGFpcnNAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiBPYmpldMKgOiBB bHZhcm8gUmV0YW5hJ3MgQWJzdGFpbiBvbiBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWwtMDk6 ICh3aXRoDQo+IENPTU1FTlQpDQo+IA0KPiBBbHZhcm8gUmV0YW5hIGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGlj YWwtMDk6IEFic3RhaW4NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1 YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiBlbWFpbCBhZGRyZXNzZXMgaW5j bHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPiBp bnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIg dG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5o dG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVO VCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJh bGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWwvDQo+IA0KPiANCj4gDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGhlIGhT RkMgY29uY2VwdCBpcyBpbmRlZWQgaW50ZXJlc3RpbmcgLS0gdGhhbmtzIGZvciBkb2luZyB0aGUg d29yayENCj4gDQo+IFJlYWRpbmcgdGhyb3VnaCB0aGUgZG9jdW1lbnQsIEkgZm91bmQgbXlzZWxm IHRoaW5raW5nIGFib3V0IGl0cyB1c2VmdWxuZXNzLg0KPiBUaGUgSW50cm9kdWN0aW9uIHNheXMg dGhhdCBpdCAiZm9jdXNlcyBvbiB0aGUgZGlmZmljdWx0IHByb2JsZW0gb2YNCj4gaW1wbGVtZW50 aW5nDQo+IFNGQyBhY3Jvc3MgYSBsYXJnZSwgZ2VvZ3JhcGhpY2FsbHkgZGlzcGVyc2VkIG5ldHdv cmssIHBvdGVudGlhbGx5IGNvbXByaXNlZA0KPiBvZg0KPiBtaWxsaW9ucyBvZiBob3N0cyBhbmQg dGhvdXNhbmRzIG9mIG5ldHdvcmsgZm9yd2FyZGluZyBlbGVtZW50cywgYW5kIHdoaWNoIG1heQ0K PiBpbnZvbHZlIG11bHRpcGxlIG9wZXJhdGlvbmFsIHRlYW1zICh3aXRoIHZhcnlpbmcgZnVuY3Rp b25hbA0KPiByZXNwb25zaWJpbGl0aWVzKS4iDQo+ICBIb3dldmVyLCB0aGUgY29udGVudCBkb2Vz bid0IGRlYWwgZGlyZWN0bHkgd2l0aCB0aGUNCj4gaW1wbGVtZW50YXRpb24vb3BlcmF0aW9uYWwN Cj4gaXNzdWVzIC0tIGFuZCBvZmZlcnMgaW5zdGVhZCBhIGxpc3Qgb2Ygb3B0aW9ucyBhcm91bmQg dGhlIElCTiwgd2l0aCBubyBjbGVhcg0KPiBvcg0KPiBleHBsaWNpdCByZWNvbW1lbmRhdGlvbi4g IEV2ZW4gdGhvdWdoIGl0IGlzIG5vdCBleHBsaWNpdGx5IG1lbnRpb25lZA0KPiBhbnl3aGVyZSwN Cj4gSSB0aGluayB0aGF0IGlzIHRoZSBpbnRlbnQgb2YgdGhlIGRvY3VtZW50Lg0KDQpbTWVkXSBU aGUgbWFuZGF0ZSB3ZSBoYWQgZm9yIHRoaXMgZG9jdW1lbnQgaXMgdG8gZGlzY3VzcyBvcHRpb25z IHdpdGhvdXQgbWFraW5nIGFueSByZWNvbW1lbmRhdGlvbi4gVGhpcyBpcyB3aHkgdGhlIGRvY3Vt ZW50IGlzIGFuIEluZm9ybWF0aW9uYWwgb25lIGFuZCBubyBub3JtYXRpdmUgbGFuZ3VhZ2UgaXMg dXNlZC4gDQoNCj4gDQo+IFRoZSBvcHRpb25zIHRoZW1zZWx2ZXMgaW5jbHVkZSBzcGVjdWxhdGlv biBhYm91dCBob3cgdGhpbmdzIGNvdWxkIHdvcms7DQo+IGluY2x1ZGluZywgZm9yIGV4YW1wbGUs IHN0YXRlIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIElCTnMgKMKnNC4xLjEpDQoNCltNZWRdIFRo aXMgaXMgbm90IGEgc3BlY3VsYXRpb24gYnV0IGEgdmFsaWQgc3RhdGVtZW50Og0KDQoiIElmIHRo ZSBwYWNrZXQgaXMgcmV0dXJuZWQgdG8gYSBkaWZmZXJlbnQgZWdyZXNzIElCTiwNCiAgIHN0YXRl IG11c3QgYmUgc3luY2hyb25pemVkIGJldHdlZW4gdGhlIElCTnMuIg0KDQpUaGUgc3RhdGUgdG8g Z2x1ZSBiZXR3ZWVuIGxheWVycyBpcyBjcmVhdGVkIGF0IHRoZSBpbmdyZXNzIElCTi4gSWYgYSBk aXN0aW5jdCBJQk4gaXMgdXNlZCB3aGVuIGV4aXN0aW5nIHRoZSBzdWItZG9tYWluLCB0aGVuIHRo ZSByZXF1aXJlZCBzdGF0ZSBtdXN0IGJlIGluc3RhbnRpYXRlZCBpbiB0aGF0IElCTi4gIA0KDQog d2l0aG91dA0KPiBzcGVjaWZpYyBwcm9wb3NhbHMuLi4NCg0KW01lZF0gVGhlIHB1cnBvc2Ugb2Yg dGhlIGFib3ZlIHN0YXRlbWVudCBpcyB0byBjYWxsIG91dCBhIGRlcGxveW1lbnQgaXNzdWUgdW5k ZXIgc3VjaCBtb2RlLCBub3QgdG8gc3BlY2lmaWMgaG93IHRvIHNvbHZlICh0aGlzIGlzIGRlcGxv eW1lbnQtc3BlY2lmaWMpLiBBbiBvcGVyYXRvciB3aGljaCBmb2xsb3dzIHRoZSBvcHRpb24gwqc0 LjEuMSBjYW4gZm9yY2UgdGhhdCB0aGUgc2FtZSBJQk4gaXMgdXNlZCBhcyBpbmdyZXNzL2VncmVz cy4gIA0KDQpvciwgbXkgZmF2b3JpdGUsIHRoZSBuZXN0aW5nIG9mIE5TSCBoZWFkZXJzICjCpzQu MS40KS4gIEkNCj4gbm90ZSB0aGF0IGV2ZW4gdGhvdWdoIHRoZSBOU0ggc3BlYyAocmZjODMwMCkg b2ZmZXJzIGEgTmV4dCBQcm90b2NvbCB2YWx1ZSBvZg0KPiAiTlNIIiwgYW5kIHRoZSBhcmNoaXRl Y3R1cmUgKHJmYzc2NjUpIGlzIHN1Y2ggdGhhdCAidGhlIFNGQyBlbmNhcHN1bGF0aW9uDQo+IHJl bWFpbiB0cmFuc3BvcnQgaW5kZXBlbmRlbnQuLi5bYW5kXS4uLmFueSBuZXR3b3JrIHRyYW5zcG9y dCBwcm90b2NvbCBtYXkgYmUNCj4gdXNlZCIsIGl0IG1heSBub3QgYmUgcG9zc2libGUgdG8gYWRk L3JlbW92ZSBOU0ggSGVhZGVycyB3aXRoaW4gc3BlY2lmaWMNCj4gdHJhbnNwb3J0IGVuY2Fwc3Vs YXRpb25zLi4uDQoNCltNZWRdIE5vdCBzdXJlIHRvIHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbnQg YnkgImFkZC9yZW1vdmUgTlNIIEhlYWRlcnMgd2l0aGluIHNwZWNpZmljIHRyYW5zcG9ydCBlbmNh cHN1bGF0aW9ucyIuIA0KDQpidXQgdGhhdCBpcyBub3QgZGlzY3Vzc2VkLiAgQWdhaW4sIEkgdGhp bmsgdGhhdA0KPiB3YXMNCj4gdGhlIGludGVudC4NCj4gDQo+IFRoZSBkZXNpZ24gb2YgdGhlIGRv Y3VtZW50IChwcmVzZW50IG9wdGlvbnMsIGJ1dCBkb24ndCBkaWcgZGVlcCBpbnRvIGFueSBvZg0K PiB0aGVtKSBpcyBvay4gIEl0IHdvdWxkIGJlIG5pY2VyIGlmIHRoZSBXRyB3b3VsZCBtb3ZlIHRo aXMgd29yayBmb3J3YXJkIGJ5DQo+IGV4cGxvcmluZyB0aGUgb3B0aW9ucywgc3BlY2lmeWluZyB0 aGVtIGFuZCBoYXZpbmcgZGV0YWlsZWQgb3BlcmF0aW9uYWwNCj4gY29uc2lkZXJhdGlvbnMgcmVs YXRlZCB0byAidGhlIGRpZmZpY3VsdCBwcm9ibGVtIG9mIGltcGxlbWVudGluZyBTRkMiIGFuZCBo b3cNCj4gaFNGQyBtYXkgaGVscC4NCg0KW01lZF0gVGhlIGRvY3VtZW50IGFscmVhZHkgaW5jbHVk ZXMgZXhhbXBsZXMgb2YgaG93IGhTRkMgaGVscHMgKGUuZy4sIHJlZHVjZSB0aGUgbnVtYmVyIG9m IHNlcnZpY2UgcGF0aHMgYXMgZGlzY3Vzc2VkIGluIHRoZSBhcHBlbmRpeCkuIA0KDQogIEJ1dCBJ IGRpZG4ndCBmaW5kIHJlbGF0ZWQgd29yayBpbiB0aGUgZGF0YXRyYWNrZXIuDQo+IA0KPiBJbiB0 aGUgZW5kLCBJIGJlbGlldmUgdGhhdCB0aGlzIGRvY3VtZW50IGlzIHZhbHVhYmxlIGFzIGEgZGlz Y3Vzc2lvbiBwaWVjZQ0KPiB3aGljaCBtYXkgbGVhZCB0byBmdXR1cmUgd29yay4uLmJ1dCwgaW4g bXkgb3BpbmlvbiwgaXQgZG9lc24ndCBuZWVkIHRvIGJlDQo+IHB1Ymxpc2hlZCBhcyBhbiBSRkMg dG8gc2VydmUgdGhhdCBwdXJwb3NlLi4uYW5kIGl0IGNvdWxkIGluIGZhY3QgYmVuZWZpdCBmcm9t DQo+IGZ1cnRoZXIgYW5hbHlzaXMgYW5kIGV2YWx1YXRpb24gYmVmb3JlIGV2ZW50dWFsIHB1Ymxp Y2F0aW9uIHJlZmxlY3RpbmcgKnRoZSoNCj4gaFNGQyBhcmNoaXRlY3R1cmUuDQoNCltNZWRdIFRo ZSBkb2N1bWVudCBkZWZpbmVzIGFuIGhTRkMgYXJjaGl0ZWN0dXJlIHRoYXQgaXMgY29tbW9uIHRv IGFsbCBvcHRpb25zOiANCi0gSGllcmFyY2h5IGxheWVycw0KLSBHbHVlIGJldHdlZW4gbGF5ZXJz OiBJQk4NCg0KQXMgSSBtZW50aW9uZWQgYWJvdmUsIHRoZSBpbnRlbnQgaXMgbm90IHRvIG1hbmRh dGUgT05FIG9wdGlvbiBmb3IgYWNoaWV2aW5nIHRoYXQgYXJjaGl0ZWN0dXJlLCBidXQgdG8gaWRl bnRpZnkgYW5kIGRpc2N1c3Mgb3B0aW9ucyBmb3IgYWNoaWV2aW5nIGl0LiANCg0KPiANCj4gR2l2 ZW4gdGhhdCB3ZSdyZSBhdCB0aGUgSUVTRyBFdmFsdWF0aW9uIHBvaW50IGluIHRoZSBwcm9jZXNz LCBJIHdvbid0IHN0YW5kDQo+IGluDQo+IHRoZSB3YXkgb2YgcHVibGljYXRpb24gYW5kIGhhdmUg Y2hvc2VuIHRvIEFCU1RBSU4gaW5zdGVhZC4NCj4gDQoNCg== From nobody Tue Jun 19 23:10:30 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699A7131045; Tue, 19 Jun 2018 23:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKn5AnloXzwp; Tue, 19 Jun 2018 23:09:49 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79DA12F1AB; Tue, 19 Jun 2018 23:09:48 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 566FDC08BE; Wed, 20 Jun 2018 08:09:47 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 2022620070; Wed, 20 Jun 2018 08:09:47 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0399.000; Wed, 20 Jun 2018 08:09:46 +0200 From: To: Ben Campbell , The IESG CC: "draft-ietf-sfc-hierarchical@ietf.org" , Behcet Sarikaya , "sfc-chairs@ietf.org" , "sarikaya@ieee.org" , "sfc@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-sfc-hierarchical-09: (with COMMENT) Thread-Index: AQHUCEY1U9rD5TW6oUWKX3u4bMRFKaRoqLcA Date: Wed, 20 Jun 2018 06:09:46 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF49035@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152946506975.32330.12254535644684416668.idtracker@ietfa.amsl.com> In-Reply-To: <152946506975.32330.12254535644684416668.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Ben Campbell's No Objection on draft-ietf-sfc-hierarchical-09: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 06:09:51 -0000 SGkgQmVuLCANCg0KVGhhbmsgeW91IGZvciB0aGUgY29tbWVudC4gDQoNClBsZWFzZSBzZWUgaW5s aW5lIC4NCg0KQ2hlZXJzLA0KTWVkIA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZcKgOiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5Abm9zdHJ1bS5jb21dDQo+IEVudm95w6nC oDogbWVyY3JlZGkgMjAganVpbiAyMDE4IDA1OjI0DQo+IMOAwqA6IFRoZSBJRVNHDQo+IENjwqA6 IGRyYWZ0LWlldGYtc2ZjLWhpZXJhcmNoaWNhbEBpZXRmLm9yZzsgQmVoY2V0IFNhcmlrYXlhOyBz ZmMtDQo+IGNoYWlyc0BpZXRmLm9yZzsgc2FyaWtheWFAaWVlZS5vcmc7IHNmY0BpZXRmLm9yZw0K PiBPYmpldMKgOiBCZW4gQ2FtcGJlbGwncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1zZmMt aGllcmFyY2hpY2FsLTA5OiAod2l0aA0KPiBDT01NRU5UKQ0KPiANCj4gQmVuIENhbXBiZWxsIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRm LXNmYy1oaWVyYXJjaGljYWwtMDk6IE5vIE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5n LCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+ IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBm cmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiAN Cj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVu dC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVT RyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQs IGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLWhpZXJhcmNo aWNhbC8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IA0KPiDCpzEwOiAiVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgc3lzdGVtcyB0aGF0 IG1heSBiZSBtYW5hZ2VkIGJ5IGRpc3RpbmN0IHRlYW1zDQo+IG9mDQo+IGEgc2luZ2xlIGFkbWlu aXN0cmF0aXZlIGVudGl0eS4iDQo+IA0KPiBJIGhhZCB0byByZS1yZWFkIHRoaXMgYSBmZXcgdGlt ZXMgdG8gcmVhbGl6ZSB5b3UgbWVhbnQgZGlzdGluY3QgdGVhbXMgdGhhdA0KPiBhcmUNCj4gYWxs IHBhcnQgb2YgdGhlIHNhbWUgZW50aXR5LCBub3QgZGlzdGluY3QgdGVhbXMgZWFjaCBtYWRlIHVw IG9mIG9uZSBlbnRpdHkuDQo+IA0KDQpbTWVkXSBXZSBjYW4gY2hhbmdlIHRoaXMgc2VudGVuY2Ug dG86IA0KDQoiVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgc3lzdGVtcyB0aGF0IG1heSBiZSBtYW5h Z2VkIGJ5IGRpc3RpbmN0IHRlYW1zLCB3aGljaCBhbGwgYmVsb25nIHRvIHRoZSBzYW1lIGFkbWlu aXN0cmF0aXZlIGVudGl0eS4iIA0K From nobody Wed Jun 20 05:24:27 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC09513111C; Wed, 20 Jun 2018 05:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU5G2mT6rZGy; Wed, 20 Jun 2018 05:24:05 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC741310EE; Wed, 20 Jun 2018 05:24:05 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id r24-v6so3257933ioh.9; Wed, 20 Jun 2018 05:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z0Ope9eQylytFzmavzHldRxWRdArNnc+kZDIvNwBWrQ=; b=iGU7yJf3W2QowJ2uVB+GmmBGLcYPfd5U/djnW8Q+9cIMeM296f764RmX/fVdTE+mBt RBN6Zy9s0yKOlryE89y8J7W/war577gV/EFcYCniKOsqkiRF7L1JnxX2a0/LLAvlAGvD 6ZnN/Yrtl+Axk92NUhJ8g6f4sBqfJm9UlzYFVXwHkjbqrlYP3WUsK3uL2dabLu9p2Tci ClWasuOpWAKua74Rrfj4WE4iYtFWIh4DumQyfXebSewbPG0gBqWvoCQKoqHPidEUrVVU jJvNqvQbgbYWlCxLArM5Zrl1aIOLkP/21n/mY+Pvd8RkwFhY3hDVXxbePWxkANkWxsq6 nzUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z0Ope9eQylytFzmavzHldRxWRdArNnc+kZDIvNwBWrQ=; b=MBoFDn8un5OkD8VKVzIWWFzuSVULagC5CS1dBTf5nhV/Wx7FM5aPB1pMlZRqOZgGyp J+zqp7GXyq5GLJ3P2yWWLOdBSSM6otPuxm5Xe12IoZVJh36JNGDORkJdgG7mpHDcsP0q P800n+TTabx8Gcg7r/m5jlFMotC16aSTN6UenROznnLF70IlgizLpx3DCZlvNF6tgYGU U4IR9e+iMQb7LHualWsp0dqK0YLvP/RQ/vYGPwNTQCLWzGADMG1iCxI7cQaykW9j9sYC zUhc35DuNO66u196ixuukLC8waEOkh/jku38EpzzYCWwARHphZ+4arPq7iL38CxcYWp3 oHvg== X-Gm-Message-State: APt69E3yq4aPxvRy4EfgOvcnJSdteiG/pfRdwK73q91WqCsoFmdlFVvK hDgNam3p4rBcH1ejvUkafer4wpn5kcP52cjQQAw= X-Google-Smtp-Source: ADUXVKJ0cszYkM+7YUidFNodpB8pB4ImF+iKQcCb3LMmIc2/OocBNJQG9x/a5loXIFO8jfBasH1AqI6ugoNBkjN59FE= X-Received: by 2002:a6b:c741:: with SMTP id x62-v6mr15319598iof.99.1529497444203; Wed, 20 Jun 2018 05:24:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:f505:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 05:24:03 -0700 (PDT) In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF35797@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152694106121.7908.13286903159935171274@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF35797@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Ines Robles Date: Wed, 20 Jun 2018 15:24:03 +0300 Message-ID: To: mohamed.boucadair@orange.com Cc: "rtg-dir@ietf.org" , "draft-ietf-sfc-hierarchical.all@ietf.org" , "ietf@ietf.org" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d8c0fc056f11dfcf" Archived-At: Subject: Re: [sfc] Rtgdir last call review of draft-ietf-sfc-hierarchical-08 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 12:24:14 -0000 --000000000000d8c0fc056f11dfcf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, Thank you for your update. Best, Ines. 2018-06-13 12:15 GMT+03:00 : > Hi Ines, > > Thank you for the review (Apologies for the delay to reply to this > review). > > All your comments were taken into account. Please the new version at: > https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ > > Cheers, > Med > > > -----Message d'origine----- > > De : Ines Robles [mailto:mariainesrobles@googlemail.com] > > Envoy=C3=A9 : mardi 22 mai 2018 00:18 > > =C3=80 : rtg-dir@ietf.org > > Cc : draft-ietf-sfc-hierarchical.all@ietf.org; ietf@ietf.org; > sfc@ietf.org > > Objet : Rtgdir last call review of draft-ietf-sfc-hierarchical-08 > > > > Reviewer: Ines Robles > > Review result: Has Issues > > > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this draft= . > > The Routing Directorate seeks to review all routing or routing-related > drafts > > as they pass through IETF last call and IESG review, and sometimes on > special > > request. The purpose of the review is to provide assistance to the > Routing > > ADs. > > For more information about the Routing Directorate, please see > > =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > Although these comments are primarily for the use of the Routing ADs, i= t > > would > > be helpful if you could consider them along with any other IETF Last Ca= ll > > comments > > that you receive, and strive to resolve them through discussion or by > > updating > > the draft. > > > > Document: draft-ietf-sfc-hierarchical-08 > > Reviewer: Ines Robles > > Review Date: 05-21-2018 > > Intended status: Informational > > > > Summary: > > > > I believe the draft is technically good. This document is well written > and > > clear to understand. The figures are clear and helpful. The draft > presents > > some > > minor issues that I think should be resolved before publication. > > > > Comments: > > > > Major Issues: No major issues found. > > > > Minor Issues: > > > > - It would be nice to add a terminology section that references section > 1.4 > > of > > rfc7665, section 1.3 of rfc8300 (since you are using NSH-aware defined > there) > > and add definitions such as IBN. - Question: about this sentence in pag= . > 3: > > "...The "domains" discussed in this document are assumed to be under th= e > > control of a single organization...". Is it the same if we say "...T= he > > "SFC-Enabled Domains" discussed in this document are assumed to be > under > > the > > control of a single organization ..."? > > Nits: > > -- It would be nice to expand NSH in the Introduction section. > > -- In Figure 1, it would be nice to add a number to the Classifiers, > > e.g.CF#1, > > then when you mention that in the text you can reference it, e.g. "One > path > > is > > shown from edge classifier (CF#1) to SFF1 to Sub-domain#1..." -- In > Figure 6, > > it would be nice to add in the legend section the meaning for DPI. > > > > Thanks, > > > > Ines. > > --000000000000d8c0fc056f11dfcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Med,

Thank you for your update.

Best,

Ines.

2018-06-13 12:15 GMT+03= :00 <mohamed.boucadair@orange.com>:
Hi Ines,

Thank you for the review (Apologies for the delay to reply to this review).=

All your comments were taken into account. Please the new version at: https://datatracker.ietf.org/doc/draft-= ietf-sfc-hierarchical/

Cheers,
Med

> -----Message d'origine-----
> De=C2=A0: Ines Robles [mailto:mariainesrobles@googlemail.com]
> Envoy=C3=A9=C2=A0: mardi 22 mai 2018 00:18
> =C3=80=C2=A0: rtg-dir@ietf.org=
> Cc=C2=A0: = draft-ietf-sfc-hierarchical.all@ietf.org; ietf@ietf.org; sfc@ietf.org
> Objet=C2=A0: Rtgdir last call review of draft-ietf-sfc-hierarchical-08=
>
> Reviewer: Ines Robles
> Review result: Has Issues
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draf= t.
> The Routing Directorate seeks to review all routing or routing-related= drafts
> as they pass through IETF last call and IESG review, and sometimes on = special
> request. The purpose of the review is to provide assistance to the Rou= ting
> ADs.
> For more information about the Routing Directorate, please see
> =E2=80=8Bhttp://trac.tools.ietf.org/ar= ea/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, = it
> would
> be helpful if you could consider them along with any other IETF Last C= all
> comments
>=C2=A0 that you receive, and strive to resolve them through discussion = or by
> updating
>=C2=A0 the draft.
>
> Document: draft-ietf-sfc-hierarchical-08
> Reviewer: Ines Robles
> Review Date: 05-21-2018
> Intended status: Informational
>
> Summary:
>
> I believe the draft is technically good. This document is well written= and
> clear to understand. The figures are clear and helpful. The draft pres= ents
> some
> minor issues that I think should be resolved before publication.
>
> Comments:
>
> Major Issues: No major issues found.
>
> Minor Issues:
>
> - It would be nice to add a terminology section that references sectio= n 1.4
> of
> rfc7665, section 1.3 of rfc8300 (since you are using NSH-aware defined= there)
> and add definitions such as IBN. - Question: about this sentence in pa= g. 3:
> "...The "domains" discussed in this document are assume= d to be under the
>=C2=A0 =C2=A0 control of a single organization...". Is it the same= if we say "...The
>=C2=A0 =C2=A0 "SFC-Enabled Domains" discussed in this documen= t are assumed to be under
> the
>=C2=A0 =C2=A0 control of a single organization ..."?
> Nits:
> -- It would be nice to expand NSH in the Introduction section.
> -- In Figure 1, it would be nice to add a number to the Classifiers, > e.g.C= F#1,
> then when you mention that in the text you can reference it, e.g. &quo= t;One path
> is
> shown from edge classifier (CF#1) to SFF1 to Sub-domain#1..." -- = In Figure 6,
> it would be nice to add in the legend section the meaning for DPI.
>
> Thanks,
>
> Ines.


--000000000000d8c0fc056f11dfcf-- From nobody Wed Jun 20 18:45:18 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A052130FA8; Wed, 20 Jun 2018 18:45:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-sfc-hierarchical@ietf.org, Behcet Sarikaya , sfc-chairs@ietf.org, sarikaya@ieee.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152954550322.28624.14636040697546417914.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2018 18:45:03 -0700 Archived-At: Subject: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 01:45:04 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sfc-hierarchical-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This does seem like an interesting and potentially useful idea -- thanks for doing the work! However, I am not sure that the document as-is is suitable for publication. In Section 4.1.5 we hear that preserving metadata and applying metadata to injected packets is not special and is "usual" functionality, but section 4.1.2 calls out that the 4.1.2 approach requires the SFs in the path to be capable of forwarding metadata and attaching metadata to injected packets as if it is a nontrivial requirement. This apparent internal inconsistency needs to be resolved before publication. Why does Section 4.1 offer five different choices with no guidance on how to make a cost/benefit analysis amongst them? Is the full spread of five choices really necessary? Complexity breeds implementation bugs which breed security issues, so I feel that this breadth of choice needs to be justified. This also ties into some confusion I have as to the goal of this document (which currently targets Informational status), akin to what is stated in Alvaro's ballot position: is it just providing information on how to assemble existing pieces in a novel way, or presenting a new protocol specification that is not yet fit for Proposed Standard status, or is it listing out potential solutions to a problem so that they can be implemented and experience gained as to which are useful in practice and which are not? Accordingly, I would be interested to hear about what deployment experience exists already and whether this abstraction proves to be as useful as the use cases seem to promise; if there is little implementation experience, perhaps Experimental status is more appropriate. I further am uncertain as to whether the approach described in Section 4.1.3 even merits consideration at all; the technique it describes seems to have a very leaky abstraction barrier (e.g., w.r.t TTL modifications). This seems especially poignant given the already large size of candidate approaches. The approach described in Section 4.1.5 also seems to be incompletely specified, in that the hSFC Flow ID semantics are not covered at all. On my initial reading I assumed that this field's encoding and semantics were intended to be left as entirely local matters to the lower domain, avoiding a need to specify them in this document. However, I'm not sure that it's actually true, since we generally want multiple vendors to be able to interoperate, and this scheme does not appear to require that the node applying the hSFC Flow ID (and saving state) is the same node that removes it (and restores state). That is, these two nodes could potentially be implemented by different vendors. Even once the above issues are resolved, I will only be able to move to an Abstain position, since this document proposes additional usage of (meta)data in the NSH headers that is not subject to mandatory integrity protection, as was discussed at length for RFC 8300 and is mandated to be available by RFC 7665. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 4 To achieve the benefits of hierarchy, the IBN should be applying more granular traffic classification rules at the lower level than the traffic passed to it. This means that the number of SFPs within the lower level is greater than the number of SFPs arriving to the IBN. "more granular" and "less granular" are unfortunately ambiguous in practical usage; I suggest "fine-grained" as an alternative for this usage. Section 4.1.5 Figure 4's caption should indicate where the base NSH fixed-length context header is originally defined. Section 4.4 presents another operational choice that contributes to exponential complexity growth, and further highlights unique properties of the Section 4.1.3 approach that may render it unsuitable for inclusion. Section 7.2 Other fundamental functions required as IBN (e.g., maintaining metadata of upper level or decrementing Service Index) are same as normal usage. nit: "the same as in normal usage" Also, I think the two occurrences of "to permit specific metadata types" should be "to *only* permit specific metadata types". Section 10.1 Security considerations related to the control plane should be discussed in the corresponding control specification documents (e.g., [I-D.ietf-bess-nsh-bgp-control-plane], [I-D.wu-pce-traffic-steering-sfc], or [I-D.maglione-sfc-nsh-radius]). I'm going to call this a nit, but "should be discussed" sounds as if this document is trying to direct the behavior of the other listed documents; maybe "are discussed" is better. Section A.1 could perhaps note the potential drawback that the classification functionality is now distributed across the domains instead of being totally centralized at the initial entry, which requires greater coordination between the different classifers. (This is, of course, not necessarily a drawback for all deployments, but could be for some.) From nobody Wed Jun 20 20:19:53 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7726130F88; Wed, 20 Jun 2018 20:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ARrIc8ZBHhL; Wed, 20 Jun 2018 20:19:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53BC130EE1; Wed, 20 Jun 2018 20:19:49 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5L3JjTT087391 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Jun 2018 22:19:45 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0E7079CA-C70C-44F0-80C0-88541D9A8346"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 20 Jun 2018 22:19:44 -0500 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF49035@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Cc: The IESG , "draft-ietf-sfc-hierarchical@ietf.org" , "sarikaya@ieee.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" To: mohamed.boucadair@orange.com References: <152946506975.32330.12254535644684416668.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF49035@OPEXCLILMA3.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [sfc] Ben Campbell's No Objection on draft-ietf-sfc-hierarchical-09: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 03:19:52 -0000 --Apple-Mail=_0E7079CA-C70C-44F0-80C0-88541D9A8346 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That change works for me. Thanks! Ben. > On Jun 20, 2018, at 1:09 AM, mohamed.boucadair@orange.com wrote: >=20 > Hi Ben, >=20 > Thank you for the comment. >=20 > Please see inline . >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Ben Campbell [mailto:ben@nostrum.com] >> Envoy=C3=A9 : mercredi 20 juin 2018 05:24 >> =C3=80 : The IESG >> Cc : draft-ietf-sfc-hierarchical@ietf.org; Behcet Sarikaya; sfc- >> chairs@ietf.org; sarikaya@ieee.org; sfc@ietf.org >> Objet : Ben Campbell's No Objection on = draft-ietf-sfc-hierarchical-09: (with >> COMMENT) >>=20 >> Ben Campbell has entered the following ballot position for >> draft-ietf-sfc-hierarchical-09: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> =C2=A710: "This document describes systems that may be managed by = distinct teams >> of >> a single administrative entity." >>=20 >> I had to re-read this a few times to realize you meant distinct teams = that >> are >> all part of the same entity, not distinct teams each made up of one = entity. >>=20 >=20 > [Med] We can change this sentence to: >=20 > "This document describes systems that may be managed by distinct = teams, which all belong to the same administrative entity." --Apple-Mail=_0E7079CA-C70C-44F0-80C0-88541D9A8346 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlsrGVAACgkQgFZKbJXz 1A3DcA/+M/wJSA7tMP5tKtCkWYYDnYBVG66AeqHTLCg1J02gZJkj5Li/I+5JHtdb 9TVNDaxJ7A4wS666rt3Eymk9frhLeq1BDohy2Wonif/XCyWWcBZB+scfwyIa8Uj4 vEs/vlcPCkNQFTTjFDyw7s1E5Ciw8i47YD8tQ0ErClhOHhz5g6vzTsTUSrTN3tuk P8Wlt1NAyiKMDwaX+ohLv/VfulXRzQJB4oV9mwnzy++KgbWmyOhLAti4jx/PP3vs rBwy810c7pJR92OPBW3fzkrVrhlIkFQxEkD9Gvw+Md2yols9CQ5SqNHkUwGRUa6r 2Y8Y37+dFwePsa+Fv7boiy0ijWslI9/Q9IwtOhUGt0eZeGu4J7iQivujNXPzIemK N5EXVlKHncGISIUrp1CPMm7MgdQYXgZOHajzCMdKvKcEAYtolnH/L/8iCtWCeh4s 8nH0RiU8WGI55GHO6lv3G+OIw0gcF3f3VfOUnBIo5Vj3KjgIZAvF/wKCROreivgD bWZyazH+iALfbGfLBzKIBkG+pIKfjJY3jL4khPJ5FSWQp4p0MTS/cNlC7gNdjOWS YItg0eQBg1WsWtluueayAPP52+FSdRHI3ofhtFTntDLqepf7AnOhVeat3+Twvvlg O+LtikFSw1VrcSL/sNet05IDP+1tJaJ2dJqN9X4SRi6Fvt7ILpA= =9Tg1 -----END PGP SIGNATURE----- --Apple-Mail=_0E7079CA-C70C-44F0-80C0-88541D9A8346-- From nobody Wed Jun 20 21:03:11 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80ABC130E12; Wed, 20 Jun 2018 21:03:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-sfc-hierarchical@ietf.org, Behcet Sarikaya , sfc-chairs@ietf.org, sarikaya@ieee.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152955378352.28604.10339840308129450256.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2018 21:03:03 -0700 Archived-At: Subject: [sfc] Suresh Krishnan's No Objection on draft-ietf-sfc-hierarchical-09: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 04:03:04 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-sfc-hierarchical-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am balloting No Objection but I share Alvaro's concern that the document needs to do further work on analyzing (and potentially narrowing down) the options in order to be useful. From nobody Wed Jun 20 23:42:19 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611E6130EB9; Wed, 20 Jun 2018 23:42:17 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWUHqjqFAdRO; Wed, 20 Jun 2018 23:42:14 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D35128BAC; Wed, 20 Jun 2018 23:42:14 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id A41D840B5D; Thu, 21 Jun 2018 08:42:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 66D0D1C033D; Thu, 21 Jun 2018 08:42:12 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0399.000; Thu, 21 Jun 2018 08:42:12 +0200 From: To: Benjamin Kaduk , The IESG CC: "draft-ietf-sfc-hierarchical@ietf.org" , Behcet Sarikaya , "sfc-chairs@ietf.org" , "sarikaya@ieee.org" , "sfc@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with DISCUSS and COMMENT) Thread-Index: AQHUCQF6jdJj0lKai0+fk8WiazOQBaRqLC2Q Date: Thu, 21 Jun 2018 06:42:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF49B65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152954550322.28624.14636040697546417914.idtracker@ietfa.amsl.com> In-Reply-To: <152954550322.28624.14636040697546417914.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 06:42:18 -0000 SGkgQmVuamFtaW4sIA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQoNClBsZWFzZSBzZWUg aW5saW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+IERlwqA6IEJlbmphbWluIEthZHVrIFttYWlsdG86a2FkdWtAbWl0LmVkdV0NCj4gRW52b3nD qcKgOiBqZXVkaSAyMSBqdWluIDIwMTggMDM6NDUNCj4gw4DCoDogVGhlIElFU0cNCj4gQ2PCoDog ZHJhZnQtaWV0Zi1zZmMtaGllcmFyY2hpY2FsQGlldGYub3JnOyBCZWhjZXQgU2FyaWtheWE7IHNm Yy0NCj4gY2hhaXJzQGlldGYub3JnOyBzYXJpa2F5YUBpZWVlLm9yZzsgc2ZjQGlldGYub3JnDQo+ IE9iamV0wqA6IEJlbmphbWluIEthZHVrJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNmYy1oaWVy YXJjaGljYWwtMDk6ICh3aXRoDQo+IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBCZW5qYW1p biBLYWR1ayBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4g ZHJhZnQtaWV0Zi1zZmMtaGllcmFyY2hpY2FsLTA5OiBEaXNjdXNzDQo+IA0KPiBXaGVuIHJlc3Bv bmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBh bGwNCj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChG ZWVsIGZyZWUgdG8gY3V0IHRoaXMNCj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4p DQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3Rh dGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1 bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVy ZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zZmMtaGll cmFyY2hpY2FsLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gDQo+IFRoaXMgZG9lcyBzZWVtIGxpa2UgYW4gaW50ZXJlc3RpbmcgYW5k IHBvdGVudGlhbGx5IHVzZWZ1bCBpZGVhIC0tIHRoYW5rcw0KPiBmb3IgZG9pbmcgdGhlIHdvcmsh IA0KDQpbTWVkXSBUaGFuayB5b3UuIA0KDQogSG93ZXZlciwgSSBhbSBub3Qgc3VyZSB0aGF0IHRo ZSBkb2N1bWVudCBhcy1pcyBpcw0KPiBzdWl0YWJsZSBmb3IgcHVibGljYXRpb24uDQo+IA0KPiBJ biBTZWN0aW9uIDQuMS41IHdlIGhlYXIgdGhhdCBwcmVzZXJ2aW5nIG1ldGFkYXRhIGFuZCBhcHBs eWluZyBtZXRhZGF0YSB0bw0KPiBpbmplY3RlZCBwYWNrZXRzIGlzIG5vdCBzcGVjaWFsIGFuZCBp cyAidXN1YWwiIGZ1bmN0aW9uYWxpdHksIGJ1dA0KPiBzZWN0aW9uIDQuMS4yIGNhbGxzIG91dCB0 aGF0IHRoZSA0LjEuMiBhcHByb2FjaCByZXF1aXJlcyB0aGUgU0ZzIGluIHRoZQ0KPiBwYXRoIHRv IGJlIGNhcGFibGUgb2YgZm9yd2FyZGluZyBtZXRhZGF0YSBhbmQgYXR0YWNoaW5nIG1ldGFkYXRh IHRvDQo+IGluamVjdGVkIHBhY2tldHMgYXMgaWYgaXQgaXMgYSBub250cml2aWFsIHJlcXVpcmVt ZW50LiAgVGhpcyBhcHBhcmVudA0KPiBpbnRlcm5hbCBpbmNvbnNpc3RlbmN5IG5lZWRzIHRvIGJl IHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCg0KW01lZF0gSSBndWVzcyB5b3UgYXJlIHJl ZmVycmluZyB0bzogDQoNCig0LjEuMikNCg0KIlRoaXMgYXBwcm9hY2ggcmVxdWlyZXMgdGhlIFNG cyBpbiB0aGUgcGF0aCB0byBiZSBjYXBhYmxlIG9mDQogICBmb3J3YXJkaW5nIHRoZSBtZXRhZGF0 YSBhbmQgYXBwcm9wcmlhdGVseSBhdHRhY2hpbmcgbWV0YWRhdGEgdG8gYW55DQogICBwYWNrZXRz IGluamVjdGVkIGZvciBhIGZsb3cuIg0KDQpBbmQNCg0KKDQuMS41KQ0KDQoiTm8gc3BlY2lhbCBm dW5jdGlvbmFsaXR5IGlzIHJlcXVpcmVkIHRvIGJlIHN1cHBvcnRlZCBieSBhbiBTRkMtDQogICAg ICBhd2FyZSBTRiwgb3RoZXIgdGhhbiB0aGUgdXN1YWwgYWJpbGl0eSB0byBwcmVzZXJ2ZSBtZXRh ZGF0YSBhbmQgdG8NCiAgICAgIGFwcGx5IG1ldGFkYXRhIHRvIGluamVjdGVkIHBhY2tldHMuIg0K DQoNCiJ1c3VhbCIgaXMgdXNlZCBpbiB0aGUgc2Vuc2UgdGhhdCBtYW5pcHVsYXRpbmcgbWV0YWRh dGEgKHVwZGF0ZSBjb250ZXh0IGhlYWRlciBhbmQgc2VydmljZSBwb2xpY3kgc2VsZWN0aW9uKSBp cyBwYXJ0IG9mIHRoZSByb2xlcyBvZiBhbiBTRkMtYXdhcmUgU0YuIFBsZWFzZSByZWZlciB0byAi IEZpZ3VyZSA4OiBOU0ggQWN0aW9uIGFuZCBSb2xlIE1hcHBpbmciIGluIFJGQzgzMDAuIA0KDQpJ IHN1Z2dlc3QgdG8gdXBkYXRlIDQuMS41IGFzIGZvbGxvd3M6IA0KDQoiTm8gbmV3IFNGQy1yZWxh dGVkIGZ1bmN0aW9uYWxpdHkgaXMgcmVxdWlyZWQgdG8gYmUgc3VwcG9ydGVkIGJ5IGFuIFNGQy0N CiAgICAgIGF3YXJlIFNGLCBvdGhlciB0aGFuIHRoZSBhYmlsaXR5IHRvIHByZXNlcnZlIG1ldGFk YXRhIGFuZCB0bw0KICAgICAgYXBwbHkgbWV0YWRhdGEgdG8gaW5qZWN0ZWQgcGFja2V0cy4iDQoN Cj4gDQo+IFdoeSBkb2VzIFNlY3Rpb24gNC4xIG9mZmVyIGZpdmUgZGlmZmVyZW50IGNob2ljZXMg d2l0aCBubyBndWlkYW5jZSBvbiBob3cNCj4gdG8gbWFrZSBhIGNvc3QvYmVuZWZpdCBhbmFseXNp cyBhbW9uZ3N0IHRoZW0/DQoNCltNZWRdIFRoZSByYXRpb25hbGUgb2YgdGhlIGRvY3VtZW50IGlz IHRvIGRlc2NyaWJlIG9wdGlvbnMgYW5kIGxlYXZlIGl0IHRvIHRoZSB0YXN0ZSBvZiB0aG9zZSB3 aG8gKHdpbGwpIGRlcGxveSB0byBkZWNpZGUgd2hpY2ggb25lcyBhbW9uZyB0aG9zZSBpcyBtb3Jl IGFwcHJvcHJpYXRlIGZvciB0aGVpciBkZXBsb3ltZW50IGNvbnRleHQuIEtleSBhZHZhbnRhZ2Vz IGFuZCBpc3N1ZXMgYXJlIGNhbGxlZCBvdXQuIA0KDQpXZSBjYW5ub3Qgc3BlY3VsYXRlIGFib3V0 IGNvc3QgYW5hbHlzaXMuIFJlYWxseS4gDQoNCiAgSXMgdGhlIGZ1bGwgc3ByZWFkIG9mIGZpdmUN Cj4gY2hvaWNlcyByZWFsbHkgbmVjZXNzYXJ5PyAgQ29tcGxleGl0eSBicmVlZHMgaW1wbGVtZW50 YXRpb24gYnVncyB3aGljaA0KPiBicmVlZCBzZWN1cml0eSBpc3N1ZXMsIHNvIEkgZmVlbCB0aGF0 IHRoaXMgYnJlYWR0aCBvZiBjaG9pY2UgbmVlZHMgdG8gYmUNCj4ganVzdGlmaWVkLg0KDQpbTWVk XSBJIHdvdWxkIGFncmVlIHdpdGggeW91IGlmIHdlIGFyZSByZWNvbW1lbmRpbmcgYWxsIChvciBt b3N0KSBvZiB0aGVtLiAgDQoNCiAgVGhpcyBhbHNvIHRpZXMgaW50byBzb21lIGNvbmZ1c2lvbiBJ IGhhdmUgYXMgdG8gdGhlIGdvYWwgb2YNCj4gdGhpcyBkb2N1bWVudCAod2hpY2ggY3VycmVudGx5 IHRhcmdldHMgSW5mb3JtYXRpb25hbCBzdGF0dXMpLCANCg0KW01lZF0gVGhlIG1haW4gY29udHJp YnV0aW9ucyBvZiB0aGUgZG9jdW1lbnQgYXJlIGFzIGZvbGxvd3M6IA0KLSBEZWZpbmUgYW4gYXJj aGl0ZWN0dXJlIGZvciBoU0ZDIChoaWVyYXJjaHkgbGV2ZWwsIGludHJvZHVjZSBJQk4sIGRlZmlu ZSBJQk4gcm9sZSkuIFRoaXMgcHJvcG9zZWQgaHNGQyBhcmNoaXRlY3R1cmUgaXMgZ2VuZXJpYyBl bm91Z2guDQotIElkZW50aWZ5IGFuZCBkZXNjcmliZSBvcHRpb25zIHRvIGdsdWUgbGV2ZWxzDQoN ClRoZSBkb2N1bWVudCBpcyBpbmZvcm1hdGlvbmFsLiBBcyBzdWNoLCBpdCBkb2VzIG5vdCBtYWtl IHVzZSBvZiBub3JtYXRpdmUgbGFuZ3VhZ2Ugb3IgcGljayBhIGZhdm9yaXRlIG9wdGlvbi4gDQoN CmFraW4gdG8gd2hhdA0KPiBpcyBzdGF0ZWQgaW4gQWx2YXJvJ3MgYmFsbG90IHBvc2l0aW9uOiBp cyBpdCBqdXN0IHByb3ZpZGluZyBpbmZvcm1hdGlvbiBvbg0KPiBob3cgdG8gYXNzZW1ibGUgZXhp c3RpbmcgcGllY2VzIGluIGEgbm92ZWwgd2F5LCBvciBwcmVzZW50aW5nIGEgbmV3DQo+IHByb3Rv Y29sIHNwZWNpZmljYXRpb24gdGhhdCBpcyBub3QgeWV0IGZpdCBmb3IgUHJvcG9zZWQgU3RhbmRh cmQgc3RhdHVzLCBvcg0KPiBpcyBpdCBsaXN0aW5nIG91dCBwb3RlbnRpYWwgc29sdXRpb25zIHRv IGEgcHJvYmxlbSBzbyB0aGF0IHRoZXkgY2FuIGJlDQo+IGltcGxlbWVudGVkIGFuZCBleHBlcmll bmNlIGdhaW5lZCBhcyB0byB3aGljaCBhcmUgdXNlZnVsIGluIHByYWN0aWNlIGFuZA0KPiB3aGlj aCBhcmUgbm90Pw0KDQpbTWVkXSBBcyBtZW50aW9uZWQgYWJvdmUsIHRoZSBkb2N1bWVudCBkb2Vz IG5vdCBkZWNsYXJlIGEgZmF2b3JpdGUgb3B0aW9uIHRvIGJlIGRlcGxveWVkIChJIGhhdmUgb25l IHRob3VnaCksIGJ1dCBkb2N1bWVudHMgY2FuZGlkYXRlcyB0aGF0IGNhbiBiZSBjb25zaWRlcmVk IHdoZW4gZGVwbG95aW5nIGhTRkMuIFNvbWUgb2YgdGhlIG9wdGlvbnMgYXJlIGltcGxlbWVudGF0 aW9uLXNwZWNpZmljICg0LjEuMSksIHNvbWUgb2YgdGhlbSBhcmUgZGVwbG95bWVudC1zcGVjaWZp YyAoNC4xLjMpLCBzb21lIHJlcXVpcmUgbW9yZSBzdGFuZGFyZGl6YXRpb24gZWZmb3J0LiAgIA0K DQogIEFjY29yZGluZ2x5LCBJIHdvdWxkIGJlIGludGVyZXN0ZWQgdG8gaGVhciBhYm91dCB3aGF0 DQo+IGRlcGxveW1lbnQgZXhwZXJpZW5jZSBleGlzdHMgYWxyZWFkeSBhbmQgd2hldGhlciB0aGlz IGFic3RyYWN0aW9uIHByb3ZlcyB0bw0KPiBiZSBhcyB1c2VmdWwgYXMgdGhlIHVzZSBjYXNlcyBz ZWVtIHRvIHByb21pc2U7IGlmIHRoZXJlIGlzIGxpdHRsZQ0KPiBpbXBsZW1lbnRhdGlvbiBleHBl cmllbmNlLCBwZXJoYXBzIEV4cGVyaW1lbnRhbCBzdGF0dXMgaXMgbW9yZSBhcHByb3ByaWF0ZS4N Cj4gDQo+IEkgZnVydGhlciBhbSB1bmNlcnRhaW4gYXMgdG8gd2hldGhlciB0aGUgYXBwcm9hY2gg ZGVzY3JpYmVkIGluIFNlY3Rpb24NCj4gNC4xLjMgZXZlbiBtZXJpdHMgY29uc2lkZXJhdGlvbiBh dCBhbGw7IHRoZSB0ZWNobmlxdWUgaXQgZGVzY3JpYmVzIHNlZW1zIHRvDQo+IGhhdmUgYSB2ZXJ5 IGxlYWt5IGFic3RyYWN0aW9uIGJhcnJpZXIgKGUuZy4sIHcuci50IFRUTCBtb2RpZmljYXRpb25z KS4NCg0KW01lZF0gR2xhZCB0byBzZWUgdGhhdCB0aGUgZGVzY3JpcHRpb24gb2YgdGhhdCBzZWN0 aW9uIGlzIGNsZWFyIGVub3VnaCBhYm91dCB0aGUgY29tcGxpY2F0aW9ucyB0aGF0IGFyZSBpbmhl cmVudCB3aXRoIHRoaXMgb3B0aW9uLiBPdXIgdGFyZ2V0IHJlYWRlciBpcyBsaWtlbHkgdG8gaGF2 ZSB0aGUgc2FtZSByZWFjdGlvbiBhcyB5b3UuIA0KDQpUaGUgcXVlc3Rpb24gaXMgd2hldGhlciBp dCBpcyBoYXJtZnVsIHRvIGhhdmUgdGhlIG9wdGlvbiBkZXNjcmliZWQuIA0KDQo+IFRoaXMgc2Vl bXMgZXNwZWNpYWxseSBwb2lnbmFudCBnaXZlbiB0aGUgYWxyZWFkeSBsYXJnZSBzaXplIG9mIGNh bmRpZGF0ZQ0KPiBhcHByb2FjaGVzLg0KDQpbTWVkXSA1IGlzIG5vdCBhICJsYXJnZSBzaXplIiBv ZiBjYW5kaWRhdGVzLCBJTU8uIElmIHRoaXMgaXMgYW4gaXNzdWUsIHdlIGNhbiBjb25zaWRlciBt b3Zpbmcgc29tZSBvZiB0aGUgb3B0aW9ucyBpbnRvIGFuIGFwcGVuZGl4Lg0KDQo+IA0KPiBUaGUg YXBwcm9hY2ggZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4xLjUgYWxzbyBzZWVtcyB0byBiZSBpbmNv bXBsZXRlbHkNCj4gc3BlY2lmaWVkLCBpbiB0aGF0IHRoZSBoU0ZDIEZsb3cgSUQgc2VtYW50aWNz IGFyZSBub3QgY292ZXJlZCBhdCBhbGwuICBPbg0KPiBteSBpbml0aWFsIHJlYWRpbmcgSSBhc3N1 bWVkIHRoYXQgdGhpcyBmaWVsZCdzIGVuY29kaW5nIGFuZCBzZW1hbnRpY3Mgd2VyZQ0KPiBpbnRl bmRlZCB0byBiZSBsZWZ0IGFzIGVudGlyZWx5IGxvY2FsIG1hdHRlcnMgdG8gdGhlIGxvd2VyIGRv bWFpbiwgYXZvaWRpbmcNCj4gYSBuZWVkIHRvIHNwZWNpZnkgdGhlbSBpbiB0aGlzIGRvY3VtZW50 Lg0KDQpbTWVkXSBUaGUgc2VtYW50aWMgaXMgbG9jYWwgdG8gYSBkb21haW4uIA0KDQogIEhvd2V2 ZXIsIEknbSBub3Qgc3VyZSB0aGF0IGl0J3MNCj4gYWN0dWFsbHkgdHJ1ZSwgc2luY2Ugd2UgZ2Vu ZXJhbGx5IHdhbnQgbXVsdGlwbGUgdmVuZG9ycyB0byBiZSBhYmxlIHRvDQo+IGludGVyb3BlcmF0 ZSwNCg0KW01lZF0gSW50ZXJtZWRpYXRlIFNGQyBlbGVtZW50cyBkbyBub3QgbmVlZCB0byB1bmRl cnN0YW5kIHRoZSBzZW1hbnRpYyBvZiBmbG93SUQuIFRoZXkgd2lsbCBoYW5kbGUgdGhlIGZsb3dJ RCBhcyBhbiBvcGFxdWUgdmFsdWUuICAgDQoNCiBhbmQgdGhpcyBzY2hlbWUgZG9lcyBub3QgYXBw ZWFyIHRvIHJlcXVpcmUgdGhhdCB0aGUgbm9kZQ0KPiBhcHBseWluZyB0aGUgaFNGQyBGbG93IElE IChhbmQgc2F2aW5nIHN0YXRlKSBpcyB0aGUgc2FtZSBub2RlIHRoYXQgcmVtb3Zlcw0KPiBpdCAo YW5kIHJlc3RvcmVzIHN0YXRlKS4gIFRoYXQgaXMsIHRoZXNlIHR3byBub2RlcyBjb3VsZCBwb3Rl bnRpYWxseSBiZQ0KPiBpbXBsZW1lbnRlZCBieSBkaWZmZXJlbnQgdmVuZG9ycy4NCj4gDQoNCltN ZWRdIFN0YXRlIHN5bmMvcmVwbGljYXRpb24gaXMgaW5kaWNhdGVkIGluIHRoZSB0ZXh0OiANCg0K ICAgRGlzYWR2YW50YWdlcyBpbmNsdWRlIHRob3NlIG9mIG90aGVyIHN0YXRlZnVsIGFwcHJvYWNo ZXMsIGluY2x1ZGluZw0KICAgc3RhdGUgdGltZW91dCBhbmQgcmVwbGljYXRpb24gbWVudGlvbmVk IGluIFNlY3Rpb24gNC4xLjEuDQoNCj4gRXZlbiBvbmNlIHRoZSBhYm92ZSBpc3N1ZXMgYXJlIHJl c29sdmVkLCBJIHdpbGwgb25seSBiZSBhYmxlIHRvIG1vdmUgdG8gYW4NCj4gQWJzdGFpbiBwb3Np dGlvbiwgc2luY2UgdGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhZGRpdGlvbmFsIHVzYWdlIG9mDQo+ IChtZXRhKWRhdGEgaW4gdGhlIE5TSCBoZWFkZXJzIHRoYXQgaXMgbm90IHN1YmplY3QgdG8gbWFu ZGF0b3J5IGludGVncml0eQ0KPiBwcm90ZWN0aW9uLCBhcyB3YXMgZGlzY3Vzc2VkIGF0IGxlbmd0 aCBmb3IgUkZDIDgzMDAgYW5kIGlzIG1hbmRhdGVkIHRvIGJlDQo+IGF2YWlsYWJsZSBieSBSRkMg NzY2NS4NCj4gDQoNCltNZWRdIFRoZSBkb2N1bWVudCBkb2VzIG5vdCBzcGVjaWZ5IGFueSBtZXRh ZGF0YS4gSXQgZG9lcyBvbmx5IGRlZmluZSBhbiBhcmNoaXRlY3R1cmUgZm9yIGhTRkMgYW5kIGV4 cGxvcmVzIGRlcGxveW1lbnQgb3B0aW9ucy4NCiANCg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBD T01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBTZWN0aW9uIDQNCj4gDQo+ICAgIFRvIGFj aGlldmUgdGhlIGJlbmVmaXRzIG9mIGhpZXJhcmNoeSwgdGhlIElCTiBzaG91bGQgYmUgYXBwbHlp bmcgbW9yZQ0KPiAgICBncmFudWxhciB0cmFmZmljIGNsYXNzaWZpY2F0aW9uIHJ1bGVzIGF0IHRo ZSBsb3dlciBsZXZlbCB0aGFuIHRoZQ0KPiAgICB0cmFmZmljIHBhc3NlZCB0byBpdC4gIFRoaXMg bWVhbnMgdGhhdCB0aGUgbnVtYmVyIG9mIFNGUHMgd2l0aGluIHRoZQ0KPiAgICBsb3dlciBsZXZl bCBpcyBncmVhdGVyIHRoYW4gdGhlIG51bWJlciBvZiBTRlBzIGFycml2aW5nIHRvIHRoZSBJQk4u DQo+IA0KPiAibW9yZSBncmFudWxhciIgYW5kICJsZXNzIGdyYW51bGFyIiBhcmUgdW5mb3J0dW5h dGVseSBhbWJpZ3VvdXMgaW4NCj4gcHJhY3RpY2FsIHVzYWdlOyBJIHN1Z2dlc3QgImZpbmUtZ3Jh aW5lZCIgYXMgYW4gYWx0ZXJuYXRpdmUgZm9yIHRoaXMgdXNhZ2UuDQoNCltNZWRdIEZpeGVkLiBU aGFuayB5b3UuIA0KDQo+IA0KPiBTZWN0aW9uIDQuMS41DQo+IA0KPiBGaWd1cmUgNCdzIGNhcHRp b24gc2hvdWxkIGluZGljYXRlIHdoZXJlIHRoZSBiYXNlIE5TSCBmaXhlZC1sZW5ndGggY29udGV4 dA0KPiBoZWFkZXIgaXMgb3JpZ2luYWxseSBkZWZpbmVkLg0KDQpbTWVkXSBJIGFkZGVkICJbUkZD ODMwMF0sIFNlY3Rpb24gMi40Ig0KDQo+IA0KPiBTZWN0aW9uIDQuNCBwcmVzZW50cyBhbm90aGVy IG9wZXJhdGlvbmFsIGNob2ljZSB0aGF0IGNvbnRyaWJ1dGVzIHRvDQo+IGV4cG9uZW50aWFsIGNv bXBsZXhpdHkgZ3Jvd3RoLCBhbmQgZnVydGhlciBoaWdobGlnaHRzIHVuaXF1ZSBwcm9wZXJ0aWVz IG9mDQo+IHRoZSBTZWN0aW9uIDQuMS4zIGFwcHJvYWNoIHRoYXQgbWF5IHJlbmRlciBpdCB1bnN1 aXRhYmxlIGZvciBpbmNsdXNpb24uDQo+IA0KDQpbTWVkXSBXaGF0IGFib3V0IG1vdmluZyBTZWN0 aW9uIDQuMS4zIGludG8gYW4gYXBwZW5kaXg/DQoNCj4gU2VjdGlvbiA3LjINCj4gDQo+ICAgIE90 aGVyIGZ1bmRhbWVudGFsIGZ1bmN0aW9ucyByZXF1aXJlZCBhcyBJQk4gKGUuZy4sIG1haW50YWlu aW5nDQo+ICAgIG1ldGFkYXRhIG9mIHVwcGVyIGxldmVsIG9yIGRlY3JlbWVudGluZyBTZXJ2aWNl IEluZGV4KSBhcmUgc2FtZSBhcw0KPiAgICBub3JtYWwgdXNhZ2UuDQo+IA0KPiBuaXQ6ICJ0aGUg c2FtZSBhcyBpbiBub3JtYWwgdXNhZ2UiDQoNCltNZWRdIEZpeGVkLiANCg0KPiANCj4gQWxzbywg SSB0aGluayB0aGUgdHdvIG9jY3VycmVuY2VzIG9mICJ0byBwZXJtaXQgc3BlY2lmaWMgbWV0YWRh dGEgdHlwZXMiDQo+IHNob3VsZCBiZSAidG8gKm9ubHkqIHBlcm1pdCBzcGVjaWZpYyBtZXRhZGF0 YSB0eXBlcyIuDQo+IA0KDQpbTWVkXSBBZ3JlZS4gDQoNCj4gDQo+IFNlY3Rpb24gMTAuMQ0KPiAN Cj4gICAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0byB0aGUgY29udHJvbCBwbGFu ZSBzaG91bGQgYmUNCj4gICAgZGlzY3Vzc2VkIGluIHRoZSBjb3JyZXNwb25kaW5nIGNvbnRyb2wg c3BlY2lmaWNhdGlvbiBkb2N1bWVudHMgKGUuZy4sDQo+ICAgIFtJLUQuaWV0Zi1iZXNzLW5zaC1i Z3AtY29udHJvbC1wbGFuZV0sDQo+ICAgIFtJLUQud3UtcGNlLXRyYWZmaWMtc3RlZXJpbmctc2Zj XSwgb3IgW0ktRC5tYWdsaW9uZS1zZmMtbnNoLXJhZGl1c10pLg0KPiANCj4gSSdtIGdvaW5nIHRv IGNhbGwgdGhpcyBhIG5pdCwgYnV0ICJzaG91bGQgYmUgZGlzY3Vzc2VkIiBzb3VuZHMgYXMgaWYg dGhpcw0KPiBkb2N1bWVudCBpcyB0cnlpbmcgdG8gZGlyZWN0IHRoZSBiZWhhdmlvciBvZiB0aGUg b3RoZXIgbGlzdGVkIGRvY3VtZW50czsNCj4gbWF5YmUgImFyZSBkaXNjdXNzZWQiIGlzIGJldHRl ci4NCg0KW01lZF0gV29ya3MgZm9yIG1lLiANCg0KPiANCj4gU2VjdGlvbiBBLjEgY291bGQgcGVy aGFwcyBub3RlIHRoZSBwb3RlbnRpYWwgZHJhd2JhY2sgdGhhdCB0aGUNCj4gY2xhc3NpZmljYXRp b24gZnVuY3Rpb25hbGl0eSBpcyBub3cgZGlzdHJpYnV0ZWQgYWNyb3NzIHRoZSBkb21haW5zIGlu c3RlYWQNCj4gb2YgYmVpbmcgdG90YWxseSBjZW50cmFsaXplZCBhdCB0aGUgaW5pdGlhbCBlbnRy eSwgd2hpY2ggcmVxdWlyZXMgZ3JlYXRlcg0KPiBjb29yZGluYXRpb24gYmV0d2VlbiB0aGUgZGlm ZmVyZW50IGNsYXNzaWZlcnMuDQoNCltNZWRdIFRoZSB0ZXh0IGluIFNlY3Rpb24gNCBpcyBjbGVh ciB0aGF0IHRoZSBoU0ZDIHJlcXVpcmVzIElCTiB0byBiZWhhdmUgYXMgYSBjbGFzc2lmaWVyOiAN Cg0KICAgVG8gYWNoaWV2ZSB0aGUgYmVuZWZpdHMgb2YgaGllcmFyY2h5LCB0aGUgSUJOIHNob3Vs ZCBiZSBhcHBseWluZyBtb3JlDQogICBncmFudWxhciB0cmFmZmljIGNsYXNzaWZpY2F0aW9uIHJ1 bGVzIGF0IHRoZSBsb3dlciBsZXZlbCB0aGFuIHRoZQ0KICAgdHJhZmZpYyBwYXNzZWQgdG8gaXQu DQoNCldlIGNhbiBhZGQgdGV4dCB0byBBLjEgYnV0IElNSE8gdGhpcyBpcyByZWR1bmRhbnQuIA0K DQogIChUaGlzIGlzLCBvZiBjb3Vyc2UsDQo+IG5vdCBuZWNlc3NhcmlseSBhIGRyYXdiYWNrIGZv ciBhbGwgZGVwbG95bWVudHMsIGJ1dCBjb3VsZCBiZSBmb3Igc29tZS4pDQo+IA0KDQo= From nobody Wed Jun 20 23:43:13 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2FF13104C; Wed, 20 Jun 2018 23:43:00 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnkoqNGEPewQ; Wed, 20 Jun 2018 23:42:55 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0090130EB9; Wed, 20 Jun 2018 23:42:54 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 14C11615CA; Thu, 21 Jun 2018 08:42:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id E5983C050E; Thu, 21 Jun 2018 08:42:52 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0399.000; Thu, 21 Jun 2018 08:42:52 +0200 From: To: Ben Campbell CC: The IESG , "draft-ietf-sfc-hierarchical@ietf.org" , "sarikaya@ieee.org" , "sfc-chairs@ietf.org" , "sfc@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-sfc-hierarchical-09: (with COMMENT) Thread-Index: AQHUCQ64fjJlrV5F+Eaw82CKdl9Xm6RqQ+Og Date: Thu, 21 Jun 2018 06:42:52 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF49B7A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152946506975.32330.12254535644684416668.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF49035@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Ben Campbell's No Objection on draft-ietf-sfc-hierarchical-09: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 06:43:01 -0000 SGkgQmVuLA0KDQpJIGltcGxlbWVudGVkIHRoZSBjaGFuZ2UgaW4gbXkgbG9jYWwgY29weS4gDQoN ClRoYW5rIHlvdS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiBEZcKgOiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5Abm9zdHJ1bS5jb21dDQo+IEVu dm95w6nCoDogamV1ZGkgMjEganVpbiAyMDE4IDA1OjIwDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hh bWVkIElNVC9PTE4NCj4gQ2PCoDogVGhlIElFU0c7IGRyYWZ0LWlldGYtc2ZjLWhpZXJhcmNoaWNh bEBpZXRmLm9yZzsgc2FyaWtheWFAaWVlZS5vcmc7IHNmYy0NCj4gY2hhaXJzQGlldGYub3JnOyBz ZmNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IEJlbiBDYW1wYmVsbCdzIE5vIE9iamVjdGlvbiBv biBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWwtMDk6DQo+ICh3aXRoIENPTU1FTlQpDQo+IA0K PiBUaGF0IGNoYW5nZSB3b3JrcyBmb3IgbWUuDQo+IA0KPiBUaGFua3MhDQo+IA0KPiBCZW4uDQo+ IA0KPiA+IE9uIEp1biAyMCwgMjAxOCwgYXQgMTowOSBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSB3cm90ZToNCj4gPg0KPiA+IEhpIEJlbiwNCj4gPg0KPiA+IFRoYW5rIHlvdSBmb3Ig dGhlIGNvbW1lbnQuDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZSAuDQo+ID4NCj4gPiBDaGVl cnMsDQo+ID4gTWVkDQo+ID4NCj4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+ IERlIDogQmVuIENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0uY29tXQ0KPiA+PiBFbnZvecOp IDogbWVyY3JlZGkgMjAganVpbiAyMDE4IDA1OjI0DQo+ID4+IMOAIDogVGhlIElFU0cNCj4gPj4g Q2MgOiBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWxAaWV0Zi5vcmc7IEJlaGNldCBTYXJpa2F5 YTsgc2ZjLQ0KPiA+PiBjaGFpcnNAaWV0Zi5vcmc7IHNhcmlrYXlhQGllZWUub3JnOyBzZmNAaWV0 Zi5vcmcNCj4gPj4gT2JqZXQgOiBCZW4gQ2FtcGJlbGwncyBObyBPYmplY3Rpb24gb24gZHJhZnQt aWV0Zi1zZmMtaGllcmFyY2hpY2FsLTA5Og0KPiAod2l0aA0KPiA+PiBDT01NRU5UKQ0KPiA+Pg0K PiA+PiBCZW4gQ2FtcGJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRp b24gZm9yDQo+ID4+IGRyYWZ0LWlldGYtc2ZjLWhpZXJhcmNoaWNhbC0wOTogTm8gT2JqZWN0aW9u DQo+ID4+DQo+ID4+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGlu ZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiA+PiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQg aW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPiA+PiBpbnRy b2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPj4NCj4gPj4NCj4gPj4gUGxlYXNlIHJl ZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVy aWEuaHRtbA0KPiA+PiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5k IENPTU1FTlQgcG9zaXRpb25zLg0KPiA+Pg0KPiA+Pg0KPiA+PiBUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ID4+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLWhpZXJhcmNoaWNh bC8NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiBDT01NRU5UOg0K PiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+DQo+ID4+IMKnMTA6ICJUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBzeXN0ZW1zIHRoYXQgbWF5IGJlIG1hbmFnZWQgYnkgZGlzdGluY3QNCj4gdGVhbXMNCj4g Pj4gb2YNCj4gPj4gYSBzaW5nbGUgYWRtaW5pc3RyYXRpdmUgZW50aXR5LiINCj4gPj4NCj4gPj4g SSBoYWQgdG8gcmUtcmVhZCB0aGlzIGEgZmV3IHRpbWVzIHRvIHJlYWxpemUgeW91IG1lYW50IGRp c3RpbmN0IHRlYW1zIHRoYXQNCj4gPj4gYXJlDQo+ID4+IGFsbCBwYXJ0IG9mIHRoZSBzYW1lIGVu dGl0eSwgbm90IGRpc3RpbmN0IHRlYW1zIGVhY2ggbWFkZSB1cCBvZiBvbmUNCj4gZW50aXR5Lg0K PiA+Pg0KPiA+DQo+ID4gW01lZF0gV2UgY2FuIGNoYW5nZSB0aGlzIHNlbnRlbmNlIHRvOg0KPiA+ DQo+ID4gIlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHN5c3RlbXMgdGhhdCBtYXkgYmUgbWFuYWdl ZCBieSBkaXN0aW5jdCB0ZWFtcywNCj4gd2hpY2ggYWxsIGJlbG9uZyB0byB0aGUgc2FtZSBhZG1p bmlzdHJhdGl2ZSBlbnRpdHkuIg0KDQo= From nobody Thu Jun 21 06:47:42 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1A2130DDD; Thu, 21 Jun 2018 06:47:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-sfc-hierarchical@ietf.org, Behcet Sarikaya , sfc-chairs@ietf.org, sarikaya@ieee.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152958885618.31481.15323878563432622242.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2018 06:47:36 -0700 Archived-At: Subject: [sfc] Alissa Cooper's Abstain on draft-ietf-sfc-hierarchical-09: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 13:47:37 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sfc-hierarchical-09: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Benjamin's DISCUSS. In particular, each of the options presented in Section 4.1 seem to have challenges that could render them unworkable, and no insights from deployment experience are provided to explain why they are in fact workable in practice. I think it would be preferable to do the further analysis suggested by Alvaro before publishing an informational document about hSFC. With that said, given that this is an informational document I wouldn't stand in the way of it being published. From nobody Thu Jun 21 06:50:29 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C77130E3B; Thu, 21 Jun 2018 06:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=HWdgDrRJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YiR4ylD2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6czGtpwNu9n; Thu, 21 Jun 2018 06:50:25 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE33130DDD; Thu, 21 Jun 2018 06:50:25 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DDFF820E46; Thu, 21 Jun 2018 09:50:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 21 Jun 2018 09:50:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=hu/MDZrSJgwqLGVSMbdPp0B7IKn77 H+bys1M3Ae5xoo=; b=HWdgDrRJuTmfZWHIyZ23twAdbhbpKD+urYLU9RsufQ32S Ov1r2DQPEU0gpbZiuHquxIjtCbs9GfVrCZWBkYiBQvPPZ7mesED52crBPtIp8V45 eQ1dDK0APlcJoeMmpTWLxsxC9crWkJVaNcMfNKDQHQHs6ngDhTuXAAIVXDTUm1II 3dJIDSHkTvJ+UPensWkbV3NHpFZ3MMnbtg8FeK6SAFopy22EcNkbTyQM0vWXqBSQ X/w/S9IHAddrTwwqTTfArc/g6a7aqWZe3O3mAw79rFd/oRKFYLyDgzY01VzyyHO3 imT2idHCw5vO1FxJHPZID2szpERSG8/4e2pZQTA1Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=hu/MDZ rSJgwqLGVSMbdPp0B7IKn77H+bys1M3Ae5xoo=; b=YiR4ylD26D5Dmz9LK6iKd1 2VWmDrBNLHl/e2/g9UTA56/j/89IsFEdgdsc/kaHd4vpgOeQ7npJjwvK75W6AvvG tfISjcFI+EBEeG2+iW7u4nRw48PkJPwuckpy4D9SISQN0cqgvxtTXsuTewic5lvf izVeZCE1A0ndmQOksZ2aQZyTtdOW9flq1zrMRgSFKqN5HF7TbyowF+APoFAWXLBc xLi8Imxc/5roQ0VkubYrle6Zh+9nV4/ylHVH1KwRJ56awUbeW6a25gXKBYjQneQf n07vIy3eOz+SJho4wU8pL7Mq0X/9IizqRKjYjDEBwhF5V3CgiD+/0uUUjQLuuRAw == X-ME-Proxy: X-ME-Sender: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.75]) by mail.messagingengine.com (Postfix) with ESMTPA id 6A43EE43A3; Thu, 21 Jun 2018 09:50:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <152847362891.15388.2522619650189897667@ietfa.amsl.com> Date: Thu, 21 Jun 2018 09:50:23 -0400 Cc: General Area Review Team , draft-ietf-sfc-hierarchical.all@ietf.org, sfc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <152847362891.15388.2522619650189897667@ietfa.amsl.com> To: Vijay Gurbani X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sfc] [Gen-art] Genart last call review of draft-ietf-sfc-hierarchical-08 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 13:50:27 -0000 Vijay, thanks for your review. I have entered an Abstain ballot position = due to concerns about Section 4.1. Alissa > On Jun 8, 2018, at 12:00 PM, Vijay Gurbani = wrote: >=20 > Reviewer: Vijay Gurbani > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-sfc-hierarchical-08 > Reviewer: Vijay Gurbani > Review Date: 2018-06-08 > IETF LC End Date: 2018-05-21 > IESG Telechat date: 2018-06-21 >=20 > Summary: This draft is ready for publication as an Informational. >=20 > Major issues: None. >=20 > Minor issues: None. >=20 > Nits/editorial comments: None. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Jun 21 10:16:34 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D633D126F72; Thu, 21 Jun 2018 10:16:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152960139183.31792.18268525749166860549@ietfa.amsl.com> Date: Thu, 21 Jun 2018 10:16:31 -0700 Archived-At: Subject: [sfc] I-D Action: draft-sarikaya-sfc-hostid-serviceheader-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 17:16:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Service Function Chaining: Subscriber and Service Identification Use Cases and Variable-Length NSH Context Headers Authors : Behcet Sarikaya Mohamed Boucadair Dirk von Hugo Filename : draft-sarikaya-sfc-hostid-serviceheader-07.txt Pages : 15 Date : 2018-06-21 Abstract: This document discusses how to inform Service Functions about service- and subscriber-related information for the sake of policy enforcement and appropriate SFC-inferred forwarding. Once the information is consumed by SFC-aware elements of an SFC-enabled domain, it is stripped from packets when they leave the SFC-enabled domain. Thus privacy-sensitive information is not leaked outside the domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-sarikaya-sfc-hostid-serviceheader/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-sarikaya-sfc-hostid-serviceheader-07 https://datatracker.ietf.org/doc/html/draft-sarikaya-sfc-hostid-serviceheader-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-sarikaya-sfc-hostid-serviceheader-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 22 01:30:40 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D77130DC6; Fri, 22 Jun 2018 01:30:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152965623854.3636.5439223383734305780@ietfa.amsl.com> Date: Fri, 22 Jun 2018 01:30:38 -0700 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-hierarchical-10.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 08:30:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Hierarchical Service Function Chaining (hSFC) Authors : David Dolson Shunsuke Homma Diego R. Lopez Mohamed Boucadair Filename : draft-ietf-sfc-hierarchical-10.txt Pages : 27 Date : 2018-06-22 Abstract: Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration. The goals of hSFC are to make a large-scale network easier to reason about, simpler to control and to support independent functional groups within large network operators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-10 https://datatracker.ietf.org/doc/html/draft-ietf-sfc-hierarchical-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-hierarchical-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 22 03:50:13 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F51130E25; Fri, 22 Jun 2018 03:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8edi8GB-XUUK; Fri, 22 Jun 2018 03:50:09 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625C9130E24; Fri, 22 Jun 2018 03:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1529664608; x=1561200608; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7SVBuQ/OKWaKVEOuqs1AWFBXtBVpmtqUBgp820AFoCw=; b=vwdN9iZDcKuQx4kJDn+knRP8HJ1Mt06rOwYk63xSvI3SNTxCzTawxI+3 mkOdEG9Anipjg5mAWBkA5hVwu9wZmXxsH6UH4f94uo3QJ02Uvv8Ludaot qM1meF5y/NvzcsdxRebX95zMkvPtj7lmWo55D+YFAi0Q8+q1iWvi6QCm7 2zX/kmpjfeafSI+pp4f13wsjLx8LgO8DssO51bXRvix1GGq41GrJE3GLL NooBu5SXLDFxwZSD4zcL6O8ICpR3SufJ99yYLRpXjiwAG7S0wFZsknKBT rnxr87wzY4YDw3iStB6sNIcYvw6WF3G+OK5tmwM9dOYHjRoflaTFXjhoW w==; Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2018 12:50:06 +0200 X-IronPort-AV: E=Sophos;i="5.48,405,1517871600"; d="scan'208";a="70789814" Received: from he106139.emea1.cds.t-internal.com ([10.169.119.72]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 22 Jun 2018 12:50:05 +0200 Received: from HE106139.EMEA1.cds.t-internal.com (10.169.119.72) by HE106139.emea1.cds.t-internal.com (10.169.119.72) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 22 Jun 2018 12:50:05 +0200 Received: from HE106139.EMEA1.cds.t-internal.com ([fe80::65f0:6cb5:eda4:e658]) by HE106139.emea1.cds.t-internal.com ([fe80::65f0:6cb5:eda4:e658%26]) with mapi id 15.00.1367.000; Fri, 22 Jun 2018 12:50:05 +0200 From: To: , , , Thread-Topic: [sfc] The SFC WG has placed draft-sarikaya-sfc-hostid-serviceheader in state "Call For Adoption By WG Issued" Thread-Index: AQHTpM1F1S3+8VvqBEyZ/67kFfG1bKPD1e6AgAEHnpCAATuZAICmybnw Date: Fri, 22 Jun 2018 10:50:05 +0000 Message-ID: References: <151852796414.13036.17297455691813895066.idtracker@ietfa.amsl.com> <1520374321.3784.15.camel@it.uc3m.es> <918ad5eb76c64629a7b949b3116a7375@HE105831.emea1.cds.t-internal.com> <1520498706.4362.16.camel@it.uc3m.es> In-Reply-To: <1520498706.4362.16.camel@it.uc3m.es> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.17.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-sarikaya-sfc-hostid-serviceheader in state "Call For Adoption By WG Issued" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 10:50:13 -0000 SGkgQ2FybG9zLA0KaW4gdGhlIHJlY2VudGx5IHB1Ymxpc2hlZCB1cGRhdGVkIHZlcnNpb24gd2Ug aGF2ZSB0YWtlbiBjYXJlIG9mIHRoZSByZW1hcmtzIC0gc2ltaWxhciB0byB3aGF0IHdlIHByb3Bv c2VkIGJlbG93LiBXZSByZXBsYWNlZCB0aGUgZXhwaXJlZCAnY29udHJvbC1wbGFuZScgZHJhZnQg YnkgdGhlIGN1cnJlbnRseSBJRVNHIHJldmlld2VkICdoaWVyYXJjaGljYWwnIG9uZSwgd2hpY2gg YWxzbyBtZW50aW9ucyBjb250cm9sIHBsYW5lIHByb3RvY29sIGV4cGVjdGF0aW9ucy4NClRoYW5r cyBhZ2FpbiBmb3IgeW91ciByZXZpZXchDQpCZXN0IFJlZ2FyZHMNCkRpcmsNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENhcmxvcyBKZXPDunMgQmVybmFyZG9zIENhbm8gW21h aWx0bzpjamJjQGl0LnVjM20uZXNdIA0KU2VudDogRG9ubmVyc3RhZywgOC4gTcOkcnogMjAxOCAw OTo0NQ0KVG86IHZvbiBIdWdvLCBEaXJrIDxEaXJrLnZvbi1IdWdvQHRlbGVrb20uZGU+OyBzZmMt Y2hhaXJzQGlldGYub3JnOyBkcmFmdC1zYXJpa2F5YS1zZmMtaG9zdGlkLXNlcnZpY2VoZWFkZXJA aWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIFRoZSBTRkMgV0cgaGFz IHBsYWNlZCBkcmFmdC1zYXJpa2F5YS1zZmMtaG9zdGlkLXNlcnZpY2VoZWFkZXIgaW4gc3RhdGUg IkNhbGwgRm9yIEFkb3B0aW9uIEJ5IFdHIElzc3VlZCINCg0KSGkgRGlyaywNCg0KVGhhbmtzIGEg bG90LiBJJ20gZmluZSB3aXRoIHlvdXIgcHJvcG9zZWQgY2hhbmdlcy4NCg0KQ2FybG9zDQoNCk9u IFdlZCwgMjAxOC0wMy0wNyBhdCAxMzoxOSArMDAwMCwgRGlyay52b24tSHVnb0B0ZWxla29tLmRl IHdyb3RlOg0KPiBIaSBDYXJsb3MsDQo+IHRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCj4gV2Ug d2lsbCBhZGRyZXNzIHRoZW0gaW4gdGhlIG5leHQgdmVyc2lvbi4NCj4gU2VlIGlubGluZSBiZWxv dyEgDQo+IEJlc3QgUmVnYXJkcw0KPiBEaXJrDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBDYXJsb3MgSmVzw7pzIEJlcm5hcmRvcyBDYW5vIFttYWlsdG86Y2piY0Bp dC51YzNtLmVzXQ0KPiBTZW50OiBEaWVuc3RhZywgNi4gTcOkcnogMjAxOCAyMzoxMg0KPiBUbzog c2ZjLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtc2FyaWtheWEtc2ZjLWhvc3RpZC1zZXJ2aWNlaGVh ZGVyQGlldGYNCj4gLm9yZzsgc2ZjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2ZjXSBUaGUg U0ZDIFdHIGhhcyBwbGFjZWQgZHJhZnQtc2FyaWtheWEtc2ZjLWhvc3RpZC0gDQo+IHNlcnZpY2Vo ZWFkZXIgaW4gc3RhdGUgIkNhbGwgRm9yIEFkb3B0aW9uIEJ5IFdHIElzc3VlZCINCj4gDQo+IEhp LA0KPiANCj4gKEkgaG9wZSBpdCBpcyBzdGlsbCBub3QgdG9vIGxhdGUpLg0KPiANCj4gSSd2ZSBy ZWFkIHRoZSBkcmFmdCBhbmQgc3VwcG9ydCBhZG9wdGlvbi4gSSB0aGluayBpdCBpcyBhIHVzZWZ1 bCANCj4gZG9jdW1lbnQuIFNvbWUgaW5pdGlhbCBjb21tZW50cyBiZWxvdzoNCj4gDQo+IC0gSXQg aXMgbm90IGNsZWFyIGhvdyB0aGUgU3Vic2NyaWJlciBJZC4gd291bGQgaGVscCBpbiB0aGUgdXNl IGNhc2UgDQo+ICJFeHRyZW1lIExvdyBMYXRlbmN5IFNlcnZpY2UgVXNlIENhc2VzIi4gU2VjdGlv biA1IGdvZXMgaW50byBpdCwgYnV0IA0KPiBwcm9iYWJseSBpdCB3b3VsZCBiZSBnb29kIHRvIGFs cmVhZHkgaW50cm9kdWNlIGEgYml0IGl0IHdoZW4gDQo+IGRlc2NyaWJpbmcgdGhlIHVzZSBjYXNl IGluIHNlY3Rpb24gMy40Lg0KPiANCj4gREg+IGdvb2QgcG9pbnQsIGhvdyBhYm91dCB0byBhZGQg YWZ0ZXI6IA0KPiAiVGhpcyBjYW4gYmUgZ3JhbnRlZCBieSBmb3J3YXJkaW5nIGFsbA0KPiAgICBw YWNrZXRzIHZpYSB0aGUgc2hvcnRlc3QgcGF0aHMgb25seSBhbmQvb3IgdmlhIHRoZSBzZXJ2aWNl IA0KPiBmdW5jdGlvbnMNCj4gICAgZ3JhbnRpbmcgbG93ZXN0IHByb2Nlc3NpbmcgZGVsYXkuIg0K PiB0aGUgc2VudGVuY2UNCj4gIlRob3NlIHBhdGhzIGFuZCBzZXJ2aWNlIGZ1bmN0aW9ucyBjYW4g YmUgY2hvc2VuIGluIHRoZSBTRkMgbW9kZWwgaW4gDQo+IHRlcm1zIG9mIHBvbGljeSBlbmZvcmNl bWVudCBiYXNlZCBvbiBzdWNoIGlkZW50aWZpZXJzLiINCj4gDQo+IC0gSWYgSSdtIG5vdCBtaXN0 YWtlbiAgZHJhZnQtaWV0Zi1zZmMtY29udHJvbC1wbGFuZS0wOCB3YXMgYWJhbmRvbmVkLCANCj4g c28gSSdtIG5vdCBzdXJlIGlmIHRoaXMgZG9jdW1lbnQgc2hvdWxkIHJlZmVyZW5jZSBpdC4NCj4g DQo+IERIPiB0aGUgZHJhZnQgZXhwaXJlZCBsYXN0IHllYXIuIFdlIHdpbGwgZGlzY3VzcyBob3cg dG8gcmVmbGVjdCB0aGlzDQo+IGluIHRoZSB0ZXh0DQo+IA0KPiBOaXRzOg0KPiAtICJhbmQgKiBb UkZDODMwMF0iDQo+IC0gInN5c3RpbWF0aWNsYWx5Ig0KPiANCj4gREg+IFRoYW5rcyAtIGFncmVl ZCEgOy0pDQo+IA0KPiBUaGFua3MsDQo+IA0KPiBDYXJsb3MNCj4gDQo+IE9uIFR1ZSwgMjAxOC0w Mi0xMyBhdCAwNToxOSAtMDgwMCwgSUVURiBTZWNyZXRhcmlhdCB3cm90ZToNCj4gPiBUaGUgU0ZD IFdHIGhhcyBwbGFjZWQgZHJhZnQtc2FyaWtheWEtc2ZjLWhvc3RpZC1zZXJ2aWNlaGVhZGVyIGlu IA0KPiA+IHN0YXRlIENhbGwgRm9yIEFkb3B0aW9uIEJ5IFdHIElzc3VlZCAoZW50ZXJlZCBieSBK b2VsIEhhbHBlcm4pDQo+ID4gDQo+ID4gVGhlIGRvY3VtZW50IGlzIGF2YWlsYWJsZSBhdA0KPiA+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNhcmlrYXlhLXNmYy1ob3N0 aWQtc2VydmljZWgNCj4gPiBlYQ0KPiA+IGRlci8NCj4gPiANCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNmYyBtYWlsaW5nIGxpc3QNCj4g PiBzZmNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0K From nobody Fri Jun 22 11:21:00 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F752130EC0; Fri, 22 Jun 2018 11:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_l1qlRcYi3O; Fri, 22 Jun 2018 11:20:51 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8614130EAF; Fri, 22 Jun 2018 11:20:50 -0700 (PDT) X-AuditID: 12074423-789ff70000002a63-9f-5b2d3e0108e7 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id A6.DC.10851.10E3D2B5; Fri, 22 Jun 2018 14:20:49 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w5MIKlgw030044; Fri, 22 Jun 2018 14:20:48 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5MIKhif030048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jun 2018 14:20:45 -0400 Date: Fri, 22 Jun 2018 13:20:43 -0500 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: The IESG , "draft-ietf-sfc-hierarchical@ietf.org" , Behcet Sarikaya , "sfc-chairs@ietf.org" , "sfc@ietf.org" Message-ID: <20180622182042.GJ64617@kduck.kaduk.org> References: <152954550322.28624.14636040697546417914.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF49B65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF49B65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUixCmqrMtopxtt8OiVscW0r58ZLWb8mchs cfjtU3aL2b2nWSz2bJvGbvHkwVZ2BzaPpxMOMnksWfKTyaPl2Um2AOYoLpuU1JzMstQifbsE roybZ+ewFmyJr2hZdZSpgXGCdxcjJ4eEgInE99W3GbsYuTiEBBYzSSzb844dwtnIKHFr3y8W COcqk8TlR8sYQVpYBFQlvn3byQZiswmoSDR0X2YGsUUEFCT2tfWDNTALNDBJLLizhR0kISyQ KvH0+jOwZl6gfZO+/WGCmLqMUaLzwAaohKDEyZlPWEBsZgEdiZ1b7wBt4ACypSWW/+OACMtL NG+dDbaMUyBJomvNJbAjRAWUJfb2HWKfwCg4C8mkWUgmzUKYNAvJpAWMLKsYZVNyq3RzEzNz ilOTdYuTE/PyUot0zfRyM0v0UlNKNzGCooHdRXkH48s+70OMAhyMSjy8Gl91ooVYE8uKK3MP MUpyMCmJ8t6sAArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4XV7CpTjTUmsrEotyodJSXOwKInz 5ixijBYSSE8sSc1OTS1ILYLJynBwKEnwBtvqRgsJFqWmp1akZeaUIKSZODhBhvMADS8AqeEt LkjMLc5Mh8ifYlSUEuc9bgOUEABJZJTmwfWCkpVE9v6aV4ziQK8I864EqeIBJjq47ldAg5mA Blc3a4EMLklESEk1MNq+Fft54j5LykfpZdONHJLf7bg1acGMGe4L7lbemXxy6/+H2UlCPfFx K903/jKapCggV/cxmM/hHd8iw6QDB1vPO1tc+H9ycdNTb0WXUI7pFX2szc7xPOdarO8LVNR/ 0WG4c/Rt8pdvVcwbm67+uOI9oeTtBrf2rat2Xyi6+OBXOs++7/vc/f2VWIozEg21mIuKEwFf +EZFMQMAAA== Archived-At: Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 18:20:54 -0000 Hi Med, I see that you already uploaded a -10 that moves the intended status to Experimental, with a nice clear introduction that lays out the scope and goals of the proposed experiment(s). That's a big improvement, so I will clear my DISCUSS. More inline... On Thu, Jun 21, 2018 at 06:42:11AM +0000, mohamed.boucadair@orange.com wrote: > Hi Benjamin, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoyé : jeudi 21 juin 2018 03:45 > > À : The IESG > > Cc : draft-ietf-sfc-hierarchical@ietf.org; Behcet Sarikaya; sfc- > > chairs@ietf.org; sarikaya@ieee.org; sfc@ietf.org > > Objet : Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with > > DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-sfc-hierarchical-09: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This does seem like an interesting and potentially useful idea -- thanks > > for doing the work! > > [Med] Thank you. > > However, I am not sure that the document as-is is > > suitable for publication. > > > > In Section 4.1.5 we hear that preserving metadata and applying metadata to > > injected packets is not special and is "usual" functionality, but > > section 4.1.2 calls out that the 4.1.2 approach requires the SFs in the > > path to be capable of forwarding metadata and attaching metadata to > > injected packets as if it is a nontrivial requirement. This apparent > > internal inconsistency needs to be resolved before publication. > > [Med] I guess you are referring to: > > (4.1.2) > > "This approach requires the SFs in the path to be capable of > forwarding the metadata and appropriately attaching metadata to any > packets injected for a flow." > > And > > (4.1.5) > > "No special functionality is required to be supported by an SFC- > aware SF, other than the usual ability to preserve metadata and to > apply metadata to injected packets." Yes, that's the spot(s). > > "usual" is used in the sense that manipulating metadata (update context header and service policy selection) is part of the roles of an SFC-aware SF. Please refer to " Figure 8: NSH Action and Role Mapping" in RFC8300. > > I suggest to update 4.1.5 as follows: > > "No new SFC-related functionality is required to be supported by an SFC- > aware SF, other than the ability to preserve metadata and to > apply metadata to injected packets." "No new [...], other than " still can be read to say that the functionality Y is in fact new. I think it would be more clear to say something like "only the existing ability to preserve and apply metadata is needed" or "The SFC-related functionality required by this approach in an SFC-aware SF is to be able to preserve and apply metadata, which is a requirement that was already present in RFC 8300". But your explanation/pointer to 8300 suffices to clear my discuss point, so please treat this as a non-blocking comment. > > > > Why does Section 4.1 offer five different choices with no guidance on how > > to make a cost/benefit analysis amongst them? > > [Med] The rationale of the document is to describe options and leave it to the taste of those who (will) deploy to decide which ones among those is more appropriate for their deployment context. Key advantages and issues are called out. > > We cannot speculate about cost analysis. Really. > > Is the full spread of five > > choices really necessary? Complexity breeds implementation bugs which > > breed security issues, so I feel that this breadth of choice needs to be > > justified. > > [Med] I would agree with you if we are recommending all (or most) of them. > > This also ties into some confusion I have as to the goal of > > this document (which currently targets Informational status), > > [Med] The main contributions of the document are as follows: > - Define an architecture for hSFC (hierarchy level, introduce IBN, define IBN role). This proposed hsFC architecture is generic enough. > - Identify and describe options to glue levels > > The document is informational. As such, it does not make use of normative language or pick a favorite option. > > akin to what > > is stated in Alvaro's ballot position: is it just providing information on > > how to assemble existing pieces in a novel way, or presenting a new > > protocol specification that is not yet fit for Proposed Standard status, or > > is it listing out potential solutions to a problem so that they can be > > implemented and experience gained as to which are useful in practice and > > which are not? > > [Med] As mentioned above, the document does not declare a favorite option to be deployed (I have one though), but documents candidates that can be considered when deploying hSFC. Some of the options are implementation-specific (4.1.1), some of them are deployment-specific (4.1.3), some require more standardization effort. The desire to get more deployment experience does seem to fit pretty well with the Experimental status. > Accordingly, I would be interested to hear about what > > deployment experience exists already and whether this abstraction proves to > > be as useful as the use cases seem to promise; if there is little > > implementation experience, perhaps Experimental status is more appropriate. > > > > I further am uncertain as to whether the approach described in Section > > 4.1.3 even merits consideration at all; the technique it describes seems to > > have a very leaky abstraction barrier (e.g., w.r.t TTL modifications). > > [Med] Glad to see that the description of that section is clear enough about the complications that are inherent with this option. Our target reader is likely to have the same reaction as you. > > The question is whether it is harmful to have the option described. For an experiment, it seems okay to leave it in. > > This seems especially poignant given the already large size of candidate > > approaches. > > [Med] 5 is not a "large size" of candidates, IMO. If this is an issue, we can consider moving some of the options into an appendix. I don't think 5 is a large size for an experiment, only for a final protocol. (Sometimes we still end up with that many, but I remember at least one case where I complained about it in my ballot position.) > > > > The approach described in Section 4.1.5 also seems to be incompletely > > specified, in that the hSFC Flow ID semantics are not covered at all. On > > my initial reading I assumed that this field's encoding and semantics were > > intended to be left as entirely local matters to the lower domain, avoiding > > a need to specify them in this document. > > [Med] The semantic is local to a domain. Agreed, it will not escape a single domain. > However, I'm not sure that it's > > actually true, since we generally want multiple vendors to be able to > > interoperate, > > [Med] Intermediate SFC elements do not need to understand the semantic of flowID. They will handle the flowID as an opaque value. Agreed. I think it might help to call out (as is done in Section 4.1.1) that if the egress IBN differs from the ingress IBN, there is a need for state synchronization between those nodes. > and this scheme does not appear to require that the node > > applying the hSFC Flow ID (and saving state) is the same node that removes > > it (and restores state). That is, these two nodes could potentially be > > implemented by different vendors. > > > > [Med] State sync/replication is indicated in the text: > > Disadvantages include those of other stateful approaches, including > state timeout and replication mentioned in Section 4.1.1. I had read the Section 4.1.1 text as only applying to that particular approach, implying that state synchronization would not necessarily be needed for the other approaches. > > Even once the above issues are resolved, I will only be able to move to an > > Abstain position, since this document proposes additional usage of > > (meta)data in the NSH headers that is not subject to mandatory integrity > > protection, as was discussed at length for RFC 8300 and is mandated to be > > available by RFC 7665. > > > > [Med] The document does not specify any metadata. It does only define an architecture for hSFC and explores deployment options. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 4 > > > > To achieve the benefits of hierarchy, the IBN should be applying more > > granular traffic classification rules at the lower level than the > > traffic passed to it. This means that the number of SFPs within the > > lower level is greater than the number of SFPs arriving to the IBN. > > > > "more granular" and "less granular" are unfortunately ambiguous in > > practical usage; I suggest "fine-grained" as an alternative for this usage. > > [Med] Fixed. Thank you. > > > > > Section 4.1.5 > > > > Figure 4's caption should indicate where the base NSH fixed-length context > > header is originally defined. > > [Med] I added "[RFC8300], Section 2.4" > > > > > Section 4.4 presents another operational choice that contributes to > > exponential complexity growth, and further highlights unique properties of > > the Section 4.1.3 approach that may render it unsuitable for inclusion. > > > > [Med] What about moving Section 4.1.3 into an appendix? I'd say leave it where it is, if we are going with Experimental status. > > Section 7.2 > > > > Other fundamental functions required as IBN (e.g., maintaining > > metadata of upper level or decrementing Service Index) are same as > > normal usage. > > > > nit: "the same as in normal usage" > > [Med] Fixed. > > > > > Also, I think the two occurrences of "to permit specific metadata types" > > should be "to *only* permit specific metadata types". > > > > [Med] Agree. > > > > > Section 10.1 > > > > Security considerations related to the control plane should be > > discussed in the corresponding control specification documents (e.g., > > [I-D.ietf-bess-nsh-bgp-control-plane], > > [I-D.wu-pce-traffic-steering-sfc], or [I-D.maglione-sfc-nsh-radius]). > > > > I'm going to call this a nit, but "should be discussed" sounds as if this > > document is trying to direct the behavior of the other listed documents; > > maybe "are discussed" is better. > > [Med] Works for me. > > > > > Section A.1 could perhaps note the potential drawback that the > > classification functionality is now distributed across the domains instead > > of being totally centralized at the initial entry, which requires greater > > coordination between the different classifers. > > [Med] The text in Section 4 is clear that the hSFC requires IBN to behave as a classifier: > > To achieve the benefits of hierarchy, the IBN should be applying more > granular traffic classification rules at the lower level than the > traffic passed to it. > > We can add text to A.1 but IMHO this is redundant. I'm happy to defer to you here. -Benjamin From nobody Fri Jun 22 11:23:43 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA58130EC2; Fri, 22 Jun 2018 11:23:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-sfc-hierarchical@ietf.org, Behcet Sarikaya , sfc-chairs@ietf.org, sarikaya@ieee.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152969181163.3611.2830752447026021853.idtracker@ietfa.amsl.com> Date: Fri, 22 Jun 2018 11:23:31 -0700 Archived-At: Subject: [sfc] Benjamin Kaduk's Abstain on draft-ietf-sfc-hierarchical-10: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 18:23:32 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sfc-hierarchical-10: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the quick updates to the document. As previously indicated, I am Abstaining, since this document includes a proposal for adding a new category of NSH metadata contents, and as discussed during RFC 8300's evaluation there is not a mandatory integrity protection option for such metadata. From nobody Sun Jun 24 08:29:59 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD30130E07; Sun, 24 Jun 2018 08:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhfbwVPDkzNM; Sun, 24 Jun 2018 08:29:49 -0700 (PDT) Received: from mail3.bemta25.messagelabs.com (mail3.bemta25.messagelabs.com [195.245.230.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF098129C6B; Sun, 24 Jun 2018 08:29:48 -0700 (PDT) Received: from [46.226.52.197] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.eu-west-1.aws.symcld.net id A6/A0-26453-BE8BF2B5; Sun, 24 Jun 2018 15:29:47 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0zTUBiGPe3WFWSmjNsnXiIzRjF2MKMGfhi Nl4hRDP6R6GKkg8qWjELWTqr+wSheAG8RBCaIkIGCopGgDMUgJGqciagYQWQgOhVmCBqjxhAv 7Tpv/dE853vf833vOTkkrvMSsSQrCqydY2x6IlS1ZEarSPvdCabEN33zkx688xBJA/WN6iTfy 2ualXhKu9OrSXG5vmFp2Da1lTPnihlqS0nbuCavfqN46uM+ogBVbChCoaSKqsOh/qcfkxc6qg yDb61+XFm8RnDR50VFKIQkqOXQctFLyBxJxcPNyvsBxqlVUHC+N+CJoLbAoNeHFE86TB4pkJi UeDF8Htgql1XUPHhfWYjJrKUyoKX5IC6zjkqDjjtH1TKHUJvh6sj7gAdR0fDVcwlTRsXAgK8m wEBR4OrowRWOgrHXP9SK3wzDb2qRUo+DiqEqjcKz4ElNMZLPBdR1DKqfuwhFoOFDWVmwUSpU/ HBr5MxAzYXW0e2KfxjBkevlQf8iOPmpMzggF17dbQwOMEHn7eEgz4amoyMqhTtx+PBgjsIzYf +5akJp2k+Ar+uZ+gSinf8cTmEO6k+0IGfgksLhfqVP5ZQy4dK9X7mRoFjioLR4RKPwAiisqtb 8Wz+HNE1omdluzbYIOYzVRhsTE2mjcTFtTE6mlxiYPbTZwDrofJYXaKOByecN/O6cTFuWgWOF FiQ9rynS50a3HmV2o+kkpo/SPhcXmXTTzLlZuy0Mb9lhd9hYvhvNJEk9aOvaEky6cDubzYo7r Tbpjf6WgQzTR2rbZVnL5zE5vDVbkTwomeyeKC3ByYeBv6/3dAmuU3G5HBsbo3XLGyh5g8XB/W n3+9U/QbNiI7RICqgLy2PtOVbhf92PYkikj9AOyl3CrJzwZ6pfCoRJgfoGaDmQwPyVYgtQYVp pcWr0/qXNy0WHqavPNbrmoGl71t0LtV+eTh0Uxo83ujd56Mn1zuaklLJj5dZxx4F7qy6Prni8 q+hnaM9G9k58/4GzT0O/N6YOjkWFTE7Nfxt2uDej/MWGiayza8WhKfFz14XXnF99RvC0Rab3n LQ1JB8a46rF4b0hUbAi0VnVoFfxFsa4ELfzzC+wFRrv8AMAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-285.messagelabs.com!1529854183!3006668!1 X-Originating-IP: [52.27.180.120] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 3357 invoked from network); 24 Jun 2018 15:29:45 -0000 Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR04-VI1-obe.outbound.protection.outlook.com) (52.27.180.120) by server-4.tower-285.messagelabs.com with AES256-SHA256 encrypted SMTP; 24 Jun 2018 15:29:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l8m6izkkxnZIJ7gh5nJCWdmM9IEE4m9P9ZhJgUDaceE=; b=SewmFn5CuhUaSVVfb+exJ9p0YOTUa56S/XGRBgIf6gX0GBFSvXiYDOfP8tF/xmrQJ6/He4zfzYIpz8cpAigs1h04nLGLQfy3G2XXZpciw/ufFEGlvTO3lUgvjkYDZMg2yYWvHVwvXUSzZttOcK0wJFVQ8fylxmxCYCsVhNj0KbU= Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB2055.eurprd03.prod.outlook.com (10.167.227.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.20; Sun, 24 Jun 2018 15:29:40 +0000 Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::6c62:c2c0:1d05:4e77]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::6c62:c2c0:1d05:4e77%2]) with mapi id 15.20.0884.021; Sun, 24 Jun 2018 15:29:40 +0000 From: Alexander Vainshtein To: "Andrew G. Malis" CC: "mpls@ietf.org" , "sfc@ietf.org" Thread-Topic: [mpls] Request for comments on draft-malis-mpls-sfc-encapsulation-00.txt Thread-Index: AQHUB+BOthO5ZT0Lf0CBs3Vus0p91aRvjlqA Date: Sun, 24 Jun 2018 15:29:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR0301MB2055; 7:oaAEToGH88E8YgQSZWWKHXi2RIBXjs18X4L6XBqQKdnhbccC089FQ90QfTkB2Hl7ZCg+LYbwDqMR5Bn2RaQ6OUrkmYadonHCre04taYV+aVBtEp6cI0SCLIoSwwrIJFcnmSKPIf0LCZ+OzeAzlOHRvG7scLRM+hzW7uop7NJv7fMJEVxVnqz43lcY1qa2Iv3AXImWOB9VfctZnqgaOq2LfacK/Z2llAbsPMlwPzYbfZeAaWxpgafJfE4ba94O7G4 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 97d55054-9a09-4117-e38b-08d5d9e74d97 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB2055; x-ms-traffictypediagnostic: DB5PR0301MB2055: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155)(279101305709854); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DB5PR0301MB2055; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB2055; x-forefront-prvs: 0713BC207F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(366004)(39850400004)(39380400002)(252514010)(54094003)(199004)(189003)(51874003)(1411001)(54896002)(9686003)(3846002)(6116002)(102836004)(26005)(66066001)(790700001)(5660300001)(11346002)(74316002)(99286004)(7736002)(33656002)(76176011)(5250100002)(81156014)(81166006)(606006)(486006)(106356001)(8936002)(55016002)(476003)(54906003)(6916009)(2900100001)(236005)(446003)(7696005)(6306002)(14454004)(68736007)(316002)(8676002)(72206003)(6506007)(4326008)(25786009)(53546011)(105586002)(86362001)(6436002)(6246003)(39060400002)(3280700002)(97736004)(186003)(3660700001)(966005)(2906002)(478600001)(59450400001)(53936002)(229853002)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB2055; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: q40jvcVjsB1HR+sRcL/nEcPopKFV+FwmScPVRyL0N4IdrYsEqWb+ZCXOYmDz5+Ep7cQfBTAXdMGcrFqFUHToPRJXArvGQx6hnXDFuUVbTT/jvcZAtqDlWs7i1muORSZRvtV8roqZYVcwxhePEOrHVd8u/v2BdBrCh3yRR1JogmrdV2V6laUlONsT87J26WdABMoAcqv3x3MVeMbFIvdOOJiUjlbHtmikoOQnhGgM78zvkFb4vNtny/biWcBfHYLBCbBwHD3bV+HodH/5Z4tT5nj5lgqYGiJMWEOH8Fgezpq5RTu59QfvQJHx8oJ7p2hlv4tQuZyYCeONxUTgT+naxbC67o8TxWk5ZcI4lZakQMY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB1909733B4E15C94FED93B9D89D4B0DB5PR0301MB1909_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97d55054-9a09-4117-e38b-08d5d9e74d97 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2018 15:29:40.3859 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB2055 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] [mpls] Request for comments on draft-malis-mpls-sfc-encapsulation-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 15:29:52 -0000 --_000_DB5PR0301MB1909733B4E15C94FED93B9D89D4B0DB5PR0301MB1909_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSBhbmQgYWxsLApJ4oCZdmUgcmVhZCB0aGUgZHJhZnQgYW5kIEkgaGF2ZSBhIHF1ZXN0aW9u IHJlZ2FyZGluZyBwb3NpdGlvbiBvZiB0aGUgU0ZGIGxhYmVsIGluIHRoZSBsYWJlbCBzdGFjay4K VGhlIGRyYWZ0IHN0YXRlcyB0aGUgU0ZGIGxhYmVsIGlzIGxvY2F0ZWQgYXQgdGhlIGJvdHRvbSBv ZiB0aGUgc3RhY2sgYW5kIGltbWVkaWF0ZWx5IGZvbGxvd2VkIGJ5IHRoZSBOU0ggaGVhZGVyLgoK SSB3b25kZXIgaWYgaXQgaXMgcG9zc2libGUgdG8gaGF2ZSBzb21lIHNwZWNpYWwgcHVycG9zZSBs YWJlbHMgdG8gZm9sbG93IHRoZSBTRkYgbGFiZWwuIFRoZSByZWxldmFudCBleGFtcGxlIGNvdWxk IGJlIEdBTCAoUkZDIDU1ODYpIGZvbGxvd2VkIGJ5IHRoZSBHQUNIIGZvciBPQU0gcHVycG9zZXMu ClJGQyA3NzA4IGhhcyBhbGxvd2VkIHRoaXMgZm9yIFBXIGxhYmVscyB3aGljaCBvcmlnaW5hbGx5 IGFsc28gaGF2ZSBiZWVuIGRlZmluZWQgYXMgQm9TIG9ubHkKClJlZ2FyZHMsIGFuZCBsb3RzIG9m IHRoYW5rcyBpbiBhZHZhbmNlLApTYXNoYQoKT2ZmaWNlOiArOTcyLTM5MjY2MzAyCkNlbGw6ICAg ICAgKzk3Mi01NDkyNjYzMDIKRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20KCkZyb206IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBBbmRyZXcgRy4gTWFsaXMKU2VudDogVHVlc2RheSwgSnVuZSAxOSwgMjAxOCA2OjE0IFBNClRv OiBtcGxzQGlldGYub3JnOyBzZmNAaWV0Zi5vcmcKU3ViamVjdDogW21wbHNdIFJlcXVlc3QgZm9y IGNvbW1lbnRzIG9uIGRyYWZ0LW1hbGlzLW1wbHMtc2ZjLWVuY2Fwc3VsYXRpb24tMDAudHh0CgpJ 4oCZdmUganVzdCB1cGxvYWRlZCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFs aXMtbXBscy1zZmMtZW5jYXBzdWxhdGlvbi0wMCAuIEl04oCZcyBhIHNob3J0IGRyYWZ0IHRoYXQg ZGlzY3Vzc2VzIGhvdyB0byBjYXJyeSBTRkMgcGFja2V0cyB0aGF0IGluY2x1ZGUgdGhlIE5TSCBv dmVyIE1QTFMgZnJvbSBvbmUgU0ZGIHRvIHRoZSBuZXh0LCBzbyB0aGF0IFNGRnMgdGhhdCBzdXBw b3J0IHRoZSBOU0ggY2FuIGJlIGNvbm5lY3RlZCB2aWEgTVBMUy4gSXQgYWxzbyBpbmNsdWRlcyB0 aGUgYWJpbGl0eSBmb3IgTVBMUyBub2RlcyB0byBzdXBwb3J0IG1vcmUgdGhhbiBvbmUgU0ZGLiBD b21tZW50cyBhcmUgYXBwcmVjaWF0ZWQhCgpUaGFua3MsCkFuZHkKCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25s eSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgCkNPTkZJREVOVElBTCBhbmQgd2hp Y2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIAp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWls LCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgCmFuZCBhbGwgY29w aWVzIHRoZXJlb2YuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo= --_000_DB5PR0301MB1909733B4E15C94FED93B9D89D4B0DB5PR0301MB1909_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEt LQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bAoJe21hcmdpbjowY207CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTIuMHB0 OwoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Ymx1ZTsKCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQK CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpwdXJwbGU7Cgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMAoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsKCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOwoJbWFy Z2luLXJpZ2h0OjBjbTsKCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOwoJbWFyZ2luLWxlZnQ6 MGNtOwoJZm9udC1zaXplOjEyLjBwdDsKCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30Kc3Bhbi5FbWFpbFN0eWxlMTgKCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsK CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOwoJY29sb3I6IzFGNDk3RDt9Ci5Nc29D aHBEZWZhdWx0Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7Cglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9CkBwYWdlIFdvcmRTZWN0aW9uMQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0OwoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9CmRpdi5Xb3JkU2VjdGlv bjEKCXtwYWdlOldvcmRTZWN0aW9uMTt9Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+CjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPgo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+CjwvaGVhZD4KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPgo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5keSBhbmQgYWxsLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPknigJl2ZSByZWFkIHRoZSBkcmFmdCBhbmQgSSBoYXZlIGEgcXVlc3Rp b24gcmVnYXJkaW5nIHBvc2l0aW9uIG9mIHRoZSBTRkYgbGFiZWwgaW4gdGhlIGxhYmVsIHN0YWNr Lgo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZHJhZnQgc3RhdGVzIHRoZSBTRkYgbGFiZWwgaXMgbG9j YXRlZCBhdCB0aGUgYm90dG9tIG9mIHRoZSBzdGFjayBhbmQgaW1tZWRpYXRlbHkgZm9sbG93ZWQg YnkgdGhlIE5TSCBoZWFkZXIuPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SSB3b25kZXIgaWYgaXQgaXMgcG9zc2libGUgdG8gaGF2ZSBzb21lIHNwZWNpYWwgcHVycG9z ZSBsYWJlbHMgdG8gZm9sbG93IHRoZSBTRkYgbGFiZWwuIFRoZSByZWxldmFudCBleGFtcGxlIGNv dWxkIGJlIEdBTCAoUkZDIDU1ODYpIGZvbGxvd2VkIGJ5IHRoZSBHQUNIIGZvcgogT0FNIHB1cnBv c2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJGQyA3NzA4IGhhcyBhbGxvd2VkIHRoaXMgZm9yIFBXIGxh YmVscyB3aGljaCBvcmlnaW5hbGx5IGFsc28gaGF2ZSBiZWVuIGRlZmluZWQgYXMgQm9TIG9ubHk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLCBhbmQgbG90 cyBvZiB0aGFua3MgaW4gYWR2YW5jZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TYXNoYTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9mZmljZTogJiM0Mzs5NzItMzkyNjYzMDI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5DZWxsOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Ozk3Mi01NDkyNjYzMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FbWFpbDombmJzcDsmbmJzcDsgQWxleGFu ZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG1wbHMgW21haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmddCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5kcmV3IEcuIE1hbGlzPGJyPgo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgSnVuZSAxOSwgMjAxOCA2OjE0IFBNPGJyPgo8Yj5Ubzo8L2I+IG1w bHNAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzxicj4KPGI+U3ViamVjdDo8L2I+IFttcGxzXSBSZXF1 ZXN0IGZvciBjb21tZW50cyBvbiBkcmFmdC1tYWxpcy1tcGxzLXNmYy1lbmNhcHN1bGF0aW9uLTAw LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJl2ZSBqdXN0IHVwbG9h ZGVkJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hbGlz LW1wbHMtc2ZjLWVuY2Fwc3VsYXRpb24tMDAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFsaXMt bXBscy1zZmMtZW5jYXBzdWxhdGlvbi0wMDwvc3Bhbj48L2E+Jm5ic3A7LiBJdOKAmXMgYSBzaG9y dCBkcmFmdAogdGhhdCBkaXNjdXNzZXMgaG93IHRvIGNhcnJ5IFNGQyBwYWNrZXRzIHRoYXQgaW5j bHVkZSB0aGUgTlNIIG92ZXIgTVBMUyBmcm9tIG9uZSBTRkYgdG8gdGhlIG5leHQsIHNvIHRoYXQg U0ZGcyB0aGF0IHN1cHBvcnQgdGhlIE5TSCBjYW4gYmUgY29ubmVjdGVkIHZpYSBNUExTLiBJdCBh bHNvIGluY2x1ZGVzIHRoZSBhYmlsaXR5IGZvciBNUExTIG5vZGVzIHRvIHN1cHBvcnQgbW9yZSB0 aGFuIG9uZSBTRkYuIENvbW1lbnRzIGFyZSBhcHByZWNpYXRlZCE8bzpwPjwvbzpwPjwvcD4KPGRp dj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8ZGl2 Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2 Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPC9kaXY+CjwvZGl2Pgo8 L2Rpdj4KPGJyIGNsZWFyPSJib3RoIj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPgo8QlI+ClRoaXMg ZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29u dGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgPEJSPgpDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1h eSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyA8QlI+CnRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWws IHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCA8QlI+CmFuZCBhbGwg Y29waWVzIHRoZXJlb2YuPEJSPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+CjwvYm9keT4KPC9odG1s PgoK --_000_DB5PR0301MB1909733B4E15C94FED93B9D89D4B0DB5PR0301MB1909_-- From nobody Sun Jun 24 09:29:53 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC39130E12; Sun, 24 Jun 2018 09:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra_IWVGju3Ry; Sun, 24 Jun 2018 09:29:48 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC998130DDA; Sun, 24 Jun 2018 09:29:48 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id l22-v6so10318365oib.4; Sun, 24 Jun 2018 09:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xZ8AneNcJVbWE0HVhEPLV+pVuIz9gbvlZoFT9iDi+NY=; b=L8gjAGTTACNUs2HRktHxozTt184pja/ADOOsupKNil/0DT4VtOIuzmNqTiIqySh8wj 8stBcGth2UWwExT0JXiZ/Zfd1YsUGSnM6R0155q78CVbisDL+fv6V/Fn5zhys8K0j1dq ISRj3KmC8SrY6TvsnzcyeNR++m1UGnXJ51CMzqn13unFRwxX8MUeAZHPe4mMSzI4jaSj cmHKRbCQ+ayBrbjqhHCnEjWaj0Jsg+aGB5zETtAf3jAweVN7vWUDx25uGMLm8EJ1WGTt k9IovbS5nAQb1UXd+hyMMrwxIG/+uqKVvbmJiUUWfv1GYPeQCBDPEXZS2INEWHgG1drc YLgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xZ8AneNcJVbWE0HVhEPLV+pVuIz9gbvlZoFT9iDi+NY=; b=KysNsvk9GEb6RwFn7i4Uht9vNFCzLWGx5DQpxN31Wpj+YFFSbajvcoQAV8b7Cfw1u2 XVZiZejui3iuVczeKeR75m/XOJM5E2Li0AIrTTHLmKkcSWt8dtBPSCMdq68fL8YnTXVS md4qXIXJ0sN2eetyN6qv4s39yCtH7sYGDbUnuoV6N7qxq0UyWQ+9DWRIhcmtqn8bFm0f 26v/u9wOiSzTaWDHGzQWDVQ8uIs9urxrvbBI7TQcsfFwgbK1Z08+FOjMdurcPPq2i+56 otHSk5kagOTwdx4YGPY11wmQlmQb9QrHXxzgoqmhXaxF6zPBjHvjCXTbUU62GCusjxJ2 dE2g== X-Gm-Message-State: APt69E2vc2OcDYqSMxnW3wsjv3egFrdzVZf0Z5vMjezdGnHzL9kyAmkh 4oF2iDMcP8EWYLBTWf4/ytIuKAL3bXsvjmlFY1w= X-Google-Smtp-Source: ADUXVKJF//atuEC8Wr+ul+XLUqEnRLHW03CcY5s27zTkUnOvRAjxbVp47nBXNfUPiSxGy1UumQLW2ujpo2ZYT2D4C3A= X-Received: by 2002:aca:e6c2:: with SMTP id d185-v6mr4771503oih.154.1529857788046; Sun, 24 Jun 2018 09:29:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c3:0:0:0:0:0 with HTTP; Sun, 24 Jun 2018 09:29:27 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Sun, 24 Jun 2018 12:29:27 -0400 Message-ID: To: Alexander Vainshtein Cc: "mpls@ietf.org" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000372a0056f65c62d" Archived-At: Subject: Re: [sfc] [mpls] Request for comments on draft-malis-mpls-sfc-encapsulation-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 16:29:51 -0000 --0000000000000372a0056f65c62d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sasha, Yes, thanks for asking, we can add that to the next revision. The intent is that the NSH label operates similar to a PW or VPN label, so whatever applies to them should apply to the NSH label as well. And thanks for reading the draft! Cheers, Andy On Sun, Jun 24, 2018 at 11:29 AM, Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Andy and all, > > I=E2=80=99ve read the draft and I have a question regarding position of t= he SFF > label in the label stack. > > The draft states the SFF label is located at the bottom of the stack and > immediately followed by the NSH header. > > > > I wonder if it is possible to have some special purpose labels to follow > the SFF label. The relevant example could be GAL (RFC 5586) followed by t= he > GACH for OAM purposes. > > RFC 7708 has allowed this for PW labels which originally also have been > defined as BoS only > > > > Regards, and lots of thanks in advance, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Andrew G. Mali= s > *Sent:* Tuesday, June 19, 2018 6:14 PM > *To:* mpls@ietf.org; sfc@ietf.org > *Subject:* [mpls] Request for comments on draft-malis-mpls-sfc- > encapsulation-00.txt > > > > I=E2=80=99ve just uploaded https://tools.ietf.org/html/draft-malis-mpls-s= fc- > encapsulation-00 . It=E2=80=99s a short draft that discusses how to carry= SFC > packets that include the NSH over MPLS from one SFF to the next, so that > SFFs that support the NSH can be connected via MPLS. It also includes the > ability for MPLS nodes to support more than one SFF. Comments are > appreciated! > > > > Thanks, > > Andy > > > > ____________________________________________________________ > _______________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > ____________________________________________________________ > _______________ > --0000000000000372a0056f65c62d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sasha,

Yes, thanks for asking, we can a= dd that to the next revision. The intent is that the NSH label operates sim= ilar to a PW or VPN label, so whatever applies to them should apply to the = NSH label as well.

And thanks for reading the draf= t!

Cheers,
Andy


On Sun, Jun 24,= 2018 at 11:29 AM, Alexander Vainshtein <Alexander.Vainshte= in@ecitele.com> wrote:

Andy and all,

I=E2=80=99ve read the draft and I hav= e a question regarding position of the SFF label in the label stack.

The draft states the SFF label is loc= ated at the bottom of the stack and immediately followed by the NSH header.=

=C2=A0

I wonder if it is possible to have so= me special purpose labels to follow the SFF label. The relevant example cou= ld be GAL (RFC 5586) followed by the GACH for OAM purposes.

RFC 7708 has allowed this for PW labe= ls which originally also have been defined as BoS only=

=C2=A0

Regards, and lots of thanks in advanc= e,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 += 972-549266302

Email:=C2=A0=C2=A0 Alexander.Vainshtein@ec= itele.com

=C2=A0

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Tuesday, June 19, 2018 6:14 PM
To: mpls@ietf.org= ; sfc@ietf.org Subject: [mpls] Request for comments on draft-malis-mpls-sfc-en= capsulation-00.txt

=C2=A0

I=E2=80=99ve just uploaded=C2=A0https://tools.ietf.org/html/draft-mal= is-mpls-sfc-encapsulation-00=C2=A0. It=E2=80=99s a short dr= aft that discusses how to carry SFC packets that include the NSH over MPLS fro= m one SFF to the next, so that SFFs that support the NSH can be connected v= ia MPLS. It also includes the ability for MPLS nodes to support more than o= ne SFF. Comments are appreciated!

=C2=A0

Thanks,

Andy

=C2=A0


_________________________________________________________________= __________

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
_________________________________________________________________= __________

--0000000000000372a0056f65c62d-- From nobody Sun Jun 24 15:11:06 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FECD130E5C for ; Sun, 24 Jun 2018 15:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC-cuoqoMmBL for ; Sun, 24 Jun 2018 15:11:01 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E4C130DFA for ; Sun, 24 Jun 2018 15:11:01 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id l14-v6so6583168wrq.13 for ; Sun, 24 Jun 2018 15:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=Awx+8I5FajlFvI2LYhJAEoFez4CspwmfodRWvT1frfE=; b=UWV5A1+MBNixJ5m7UoO7ftxPLpgzvkEJBwjg77XpM3DNXAgfeHPEnLy4xdDABkYSV3 wOXzDCYDGLoq4QQuuTRbugN2vejFLDjxLGDzP1NHPUi//d0ljOUIxt/Q7499AKeCp9S+ Gsal3B6NOEcopt/6ozh6117wlmlKUWjPP16UQUOpwfHLQZefOuuz01ahoaBTxQ1lr9Bl EsebcI2QYMWywlM/GC39GGzVsX5EtosPYxFwc1YvrtjtmqWGq3LLSdfEYUGBFCg73lj7 SemL5qqyaDG864EQjR+VvulngxC4XcnpuOGcJDxLnn683OeZbveHnniS2AKeUr+DsLlG cUvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=Awx+8I5FajlFvI2LYhJAEoFez4CspwmfodRWvT1frfE=; b=X0CUN1u9Ho082gTSYp+1ViRV7CYS71t9r4CobEpokXox+6ezZPQfI5kraWeA/6rP9v U5Qlwiyengrol+K6T/uJQbIkDygWwNY2wd8/yfCZIhxWnuOP0wRfEBaXIpvbw9Sw39f7 5/JIQ3uksSpye5zE87pF1+HmSbWEYyoqDwbPwm6Piai3klIxnCIOiYYnWTR0c0MTCNih d2IY8hPf/K76V5C7wt7uGZQ2sStSTjwV3BDLY+ZOWRcArLYQUkt3+6sSqxWBK0Vfqc/K 8XwiGmSJ1lsfvKlSGqGVftNmF+lib8oRoOFBWmI2HuKhEWWlPe1Vy6wPslh6tri6a7q3 cbsA== X-Gm-Message-State: APt69E26IBgJLGRFHQU7Md8bvuzs6kWsznZbhueMR4yeDn8BpjKKh967 IbswdMbfyGdjN1Y5D4GJebifew== X-Google-Smtp-Source: AAOMgpcPisF8LkrYQR+niYVwcAuBYKaWomF/s2v8Jcwq3AiBSLroEcZKuNbauk+6gtupck/MkP4t2g== X-Received: by 2002:a5d:4392:: with SMTP id i18-v6mr8543019wrq.156.1529878259627; Sun, 24 Jun 2018 15:10:59 -0700 (PDT) Received: from cjbc_dell.lan (2.154.161.159.dyn.user.ono.com. [2.154.161.159]) by smtp.gmail.com with ESMTPSA id q1-v6sm15547996wrm.96.2018.06.24.15.10.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 24 Jun 2018 15:10:59 -0700 (PDT) Message-ID: <7297c6c7eb848456217a70f09b0028ec7156ab27.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano Reply-To: cjbc@it.uc3m.es To: Dirk.von-Hugo@telekom.de, sfc-chairs@ietf.org, draft-sarikaya-sfc-hostid-serviceheader@ietf.org, sfc@ietf.org Date: Mon, 25 Jun 2018 00:10:58 +0200 In-Reply-To: References: <151852796414.13036.17297455691813895066.idtracker@ietfa.amsl.com> <1520374321.3784.15.camel@it.uc3m.es> <918ad5eb76c64629a7b949b3116a7375@HE105831.emea1.cds.t-internal.com> <1520498706.4362.16.camel@it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-sarikaya-sfc-hostid-serviceheader in state "Call For Adoption By WG Issued" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 22:11:05 -0000 Thanks Dirk! On Fri, 2018-06-22 at 10:50 +0000, Dirk.von-Hugo@telekom.de wrote: > Hi Carlos, > in the recently published updated version we have taken care of the > remarks - similar to what we proposed below. We replaced the expired > 'control-plane' draft by the currently IESG reviewed 'hierarchical' > one, which also mentions control plane protocol expectations. > Thanks again for your review! > Best Regards > Dirk > > -----Original Message----- > From: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es] > Sent: Donnerstag, 8. März 2018 09:45 > To: von Hugo, Dirk ; sfc-chairs@ietf.org; d > raft-sarikaya-sfc-hostid-serviceheader@ietf.org; sfc@ietf.org > Subject: Re: [sfc] The SFC WG has placed draft-sarikaya-sfc-hostid- > serviceheader in state "Call For Adoption By WG Issued" > > Hi Dirk, > > Thanks a lot. I'm fine with your proposed changes. > > Carlos > > On Wed, 2018-03-07 at 13:19 +0000, Dirk.von-Hugo@telekom.de wrote: > > Hi Carlos, > > thanks for your comments. > > We will address them in the next version. > > See inline below! > > Best Regards > > Dirk > > > > -----Original Message----- > > From: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es] > > Sent: Dienstag, 6. März 2018 23:12 > > To: sfc-chairs@ietf.org; draft-sarikaya-sfc-hostid-serviceheader@ie > > tf > > .org; sfc@ietf.org > > Subject: Re: [sfc] The SFC WG has placed draft-sarikaya-sfc > > -hostid- > > serviceheader in state "Call For Adoption By WG Issued" > > > > Hi, > > > > (I hope it is still not too late). > > > > I've read the draft and support adoption. I think it is a useful > > document. Some initial comments below: > > > > - It is not clear how the Subscriber Id. would help in the use > > case > > "Extreme Low Latency Service Use Cases". Section 5 goes into it, > > but > > probably it would be good to already introduce a bit it when > > describing the use case in section 3.4. > > > > DH> good point, how about to add after: > > "This can be granted by forwarding all > > packets via the shortest paths only and/or via the service > > functions > > granting lowest processing delay." > > the sentence > > "Those paths and service functions can be chosen in the SFC model > > in > > terms of policy enforcement based on such identifiers." > > > > - If I'm not mistaken draft-ietf-sfc-control-plane-08 was > > abandoned, > > so I'm not sure if this document should reference it. > > > > DH> the draft expired last year. We will discuss how to reflect > > this > > in the text > > > > Nits: > > - "and * [RFC8300]" > > - "systimaticlaly" > > > > DH> Thanks - agreed! ;-) > > > > Thanks, > > > > Carlos > > > > On Tue, 2018-02-13 at 05:19 -0800, IETF Secretariat wrote: > > > The SFC WG has placed draft-sarikaya-sfc-hostid-serviceheader in > > > state Call For Adoption By WG Issued (entered by Joel Halpern) > > > > > > The document is available at > > > https://datatracker.ietf.org/doc/draft-sarikaya-sfc-hostid-servic > > > eh > > > ea > > > der/ > > > > > > _______________________________________________ > > > sfc mailing list > > > sfc@ietf.org > > > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jun 25 07:06:34 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC79124C04; Mon, 25 Jun 2018 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMoaznmUIsl3; Mon, 25 Jun 2018 07:06:28 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C8D130DF1; Mon, 25 Jun 2018 07:06:28 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 090EEC047E; Mon, 25 Jun 2018 16:06:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id C1A6440058; Mon, 25 Jun 2018 16:06:26 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0399.000; Mon, 25 Jun 2018 16:06:26 +0200 From: To: Benjamin Kaduk CC: The IESG , "draft-ietf-sfc-hierarchical@ietf.org" , Behcet Sarikaya , "sfc-chairs@ietf.org" , "sfc@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with DISCUSS and COMMENT) Thread-Index: AQHUClXBB89+3jWS4ECsf8GN2V37E6RxBJ2g Date: Mon, 25 Jun 2018 14:06:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF4B5E3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152954550322.28624.14636040697546417914.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF49B65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20180622182042.GJ64617@kduck.kaduk.org> In-Reply-To: <20180622182042.GJ64617@kduck.kaduk.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 14:06:33 -0000 Hi Benjamin,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: vendredi 22 juin 2018 20:21 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: The IESG; draft-ietf-sfc-hierarchical@ietf.org; Behcet Sarikaya; s= fc- > chairs@ietf.org; sfc@ietf.org > Objet=A0: Re: Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09:= (with > DISCUSS and COMMENT) >=20 > Hi Med, >=20 > I see that you already uploaded a -10 that moves the intended status to > Experimental, with a nice clear introduction that lays out the scope and > goals of the proposed experiment(s). That's a big improvement, so I will > clear my DISCUSS. [Med] Thank you.=20 More inline... >=20 > On Thu, Jun 21, 2018 at 06:42:11AM +0000, mohamed.boucadair@orange.com wr= ote: > > Hi Benjamin, > > > > Thank you for the review. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > Envoy=E9=A0: jeudi 21 juin 2018 03:45 > > > =C0=A0: The IESG > > > Cc=A0: draft-ietf-sfc-hierarchical@ietf.org; Behcet Sarikaya; sfc- > > > chairs@ietf.org; sarikaya@ieee.org; sfc@ietf.org > > > Objet=A0: Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09:= (with > > > DISCUSS and COMMENT) > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-sfc-hierarchical-09: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut th= is > > > introductory paragraph, however.) > > > > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.= html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ > > > > > > > > > > > > ---------------------------------------------------------------------= - > > > DISCUSS: > > > ---------------------------------------------------------------------= - > > > > > > This does seem like an interesting and potentially useful idea -- tha= nks > > > for doing the work! > > > > [Med] Thank you. > > > > However, I am not sure that the document as-is is > > > suitable for publication. > > > > > > In Section 4.1.5 we hear that preserving metadata and applying metada= ta > to > > > injected packets is not special and is "usual" functionality, but > > > section 4.1.2 calls out that the 4.1.2 approach requires the SFs in t= he > > > path to be capable of forwarding metadata and attaching metadata to > > > injected packets as if it is a nontrivial requirement. This apparent > > > internal inconsistency needs to be resolved before publication. > > > > [Med] I guess you are referring to: > > > > (4.1.2) > > > > "This approach requires the SFs in the path to be capable of > > forwarding the metadata and appropriately attaching metadata to any > > packets injected for a flow." > > > > And > > > > (4.1.5) > > > > "No special functionality is required to be supported by an SFC- > > aware SF, other than the usual ability to preserve metadata and t= o > > apply metadata to injected packets." >=20 > Yes, that's the spot(s). >=20 > > > > "usual" is used in the sense that manipulating metadata (update context > header and service policy selection) is part of the roles of an SFC-aware= SF. > Please refer to " Figure 8: NSH Action and Role Mapping" in RFC8300. > > > > I suggest to update 4.1.5 as follows: > > > > "No new SFC-related functionality is required to be supported by an SFC= - > > aware SF, other than the ability to preserve metadata and to > > apply metadata to injected packets." >=20 > "No new [...], other than " still can be read to say that the > functionality Y is in fact new. I think it would be more clear to say > something like "only the existing ability to preserve and apply metadata = is > needed" or "The SFC-related functionality required by this approach in an > SFC-aware SF is to be able to preserve and apply metadata, which is a > requirement that was already present in RFC 8300". But your > explanation/pointer to 8300 suffices to clear my discuss point, so please > treat this as a non-blocking comment. >=20 [Med] The second proposal works for me.=20 > > > > > > Why does Section 4.1 offer five different choices with no guidance on= how > > > to make a cost/benefit analysis amongst them? > > > > [Med] The rationale of the document is to describe options and leave it= to > the taste of those who (will) deploy to decide which ones among those is = more > appropriate for their deployment context. Key advantages and issues are > called out. > > > > We cannot speculate about cost analysis. Really. > > > > Is the full spread of five > > > choices really necessary? Complexity breeds implementation bugs whic= h > > > breed security issues, so I feel that this breadth of choice needs to= be > > > justified. > > > > [Med] I would agree with you if we are recommending all (or most) of th= em. > > > > This also ties into some confusion I have as to the goal of > > > this document (which currently targets Informational status), > > > > [Med] The main contributions of the document are as follows: > > - Define an architecture for hSFC (hierarchy level, introduce IBN, defi= ne > IBN role). This proposed hsFC architecture is generic enough. > > - Identify and describe options to glue levels > > > > The document is informational. As such, it does not make use of normati= ve > language or pick a favorite option. > > > > akin to what > > > is stated in Alvaro's ballot position: is it just providing informati= on > on > > > how to assemble existing pieces in a novel way, or presenting a new > > > protocol specification that is not yet fit for Proposed Standard stat= us, > or > > > is it listing out potential solutions to a problem so that they can b= e > > > implemented and experience gained as to which are useful in practice = and > > > which are not? > > > > [Med] As mentioned above, the document does not declare a favorite opti= on > to be deployed (I have one though), but documents candidates that can be > considered when deploying hSFC. Some of the options are implementation- > specific (4.1.1), some of them are deployment-specific (4.1.3), some requ= ire > more standardization effort. >=20 > The desire to get more deployment experience does seem to fit pretty well > with the Experimental status. [Med] Yes.=20 >=20 > > Accordingly, I would be interested to hear about what > > > deployment experience exists already and whether this abstraction pro= ves > to > > > be as useful as the use cases seem to promise; if there is little > > > implementation experience, perhaps Experimental status is more > appropriate. > > > > > > I further am uncertain as to whether the approach described in Sectio= n > > > 4.1.3 even merits consideration at all; the technique it describes se= ems > to > > > have a very leaky abstraction barrier (e.g., w.r.t TTL modifications)= . > > > > [Med] Glad to see that the description of that section is clear enough > about the complications that are inherent with this option. Our target re= ader > is likely to have the same reaction as you. > > > > The question is whether it is harmful to have the option described. >=20 > For an experiment, it seems okay to leave it in. [Med] OK.=20 >=20 > > > This seems especially poignant given the already large size of candid= ate > > > approaches. > > > > [Med] 5 is not a "large size" of candidates, IMO. If this is an issue, = we > can consider moving some of the options into an appendix. >=20 > I don't think 5 is a large size for an experiment, only for a final > protocol.=20 [Med] In full agreement.=20 (Sometimes we still end up with that many, but I remember at > least one case where I complained about it in my ballot position.) >=20 > > > > > > The approach described in Section 4.1.5 also seems to be incompletely > > > specified, in that the hSFC Flow ID semantics are not covered at all.= On > > > my initial reading I assumed that this field's encoding and semantics > were > > > intended to be left as entirely local matters to the lower domain, > avoiding > > > a need to specify them in this document. > > > > [Med] The semantic is local to a domain. >=20 > Agreed, it will not escape a single domain. >=20 > > However, I'm not sure that it's > > > actually true, since we generally want multiple vendors to be able to > > > interoperate, > > > > [Med] Intermediate SFC elements do not need to understand the semantic = of > flowID. They will handle the flowID as an opaque value. >=20 > Agreed. I think it might help to call out (as is done in Section 4.1.1) > that if the egress IBN differs from the ingress IBN, there is a need for > state synchronization between those nodes. [Med] This is the intent of "state replication mentioned in Section 4.1.1".= =20 I changed the text to "state synchronization mentioned in Section 4.1.1". >=20 > > and this scheme does not appear to require that the node > > > applying the hSFC Flow ID (and saving state) is the same node that > removes > > > it (and restores state). That is, these two nodes could potentially = be > > > implemented by different vendors. > > > > > > > [Med] State sync/replication is indicated in the text: > > > > Disadvantages include those of other stateful approaches, including > > state timeout and replication mentioned in Section 4.1.1. >=20 > I had read the Section 4.1.1 text as only applying to that particular > approach, implying that state synchronization would not necessarily be > needed for the other approaches. >=20 > > > Even once the above issues are resolved, I will only be able to move = to > an > > > Abstain position, since this document proposes additional usage of > > > (meta)data in the NSH headers that is not subject to mandatory integr= ity > > > protection, as was discussed at length for RFC 8300 and is mandated t= o be > > > available by RFC 7665. > > > > > > > [Med] The document does not specify any metadata. It does only define a= n > architecture for hSFC and explores deployment options. > > > > > > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > Section 4 > > > > > > To achieve the benefits of hierarchy, the IBN should be applying m= ore > > > granular traffic classification rules at the lower level than the > > > traffic passed to it. This means that the number of SFPs within t= he > > > lower level is greater than the number of SFPs arriving to the IBN= . > > > > > > "more granular" and "less granular" are unfortunately ambiguous in > > > practical usage; I suggest "fine-grained" as an alternative for this > usage. > > > > [Med] Fixed. Thank you. > > > > > > > > Section 4.1.5 > > > > > > Figure 4's caption should indicate where the base NSH fixed-length > context > > > header is originally defined. > > > > [Med] I added "[RFC8300], Section 2.4" > > > > > > > > Section 4.4 presents another operational choice that contributes to > > > exponential complexity growth, and further highlights unique properti= es > of > > > the Section 4.1.3 approach that may render it unsuitable for inclusio= n. > > > > > > > [Med] What about moving Section 4.1.3 into an appendix? >=20 > I'd say leave it where it is, if we are going with Experimental status. >=20 > > > Section 7.2 > > > > > > Other fundamental functions required as IBN (e.g., maintaining > > > metadata of upper level or decrementing Service Index) are same as > > > normal usage. > > > > > > nit: "the same as in normal usage" > > > > [Med] Fixed. > > > > > > > > Also, I think the two occurrences of "to permit specific metadata typ= es" > > > should be "to *only* permit specific metadata types". > > > > > > > [Med] Agree. > > > > > > > > Section 10.1 > > > > > > Security considerations related to the control plane should be > > > discussed in the corresponding control specification documents (e.= g., > > > [I-D.ietf-bess-nsh-bgp-control-plane], > > > [I-D.wu-pce-traffic-steering-sfc], or [I-D.maglione-sfc-nsh-radius= ]). > > > > > > I'm going to call this a nit, but "should be discussed" sounds as if = this > > > document is trying to direct the behavior of the other listed documen= ts; > > > maybe "are discussed" is better. > > > > [Med] Works for me. > > > > > > > > Section A.1 could perhaps note the potential drawback that the > > > classification functionality is now distributed across the domains > instead > > > of being totally centralized at the initial entry, which requires gre= ater > > > coordination between the different classifers. > > > > [Med] The text in Section 4 is clear that the hSFC requires IBN to beha= ve > as a classifier: > > > > To achieve the benefits of hierarchy, the IBN should be applying mor= e > > granular traffic classification rules at the lower level than the > > traffic passed to it. > > > > We can add text to A.1 but IMHO this is redundant. >=20 > I'm happy to defer to you here. [Med] OK, thanks. I'm planning to leave the text as it is.=20 >=20 > -Benjamin From nobody Mon Jun 25 09:55:59 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE37E130EC1; Mon, 25 Jun 2018 09:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRamWcNu9_Zz; Mon, 25 Jun 2018 09:55:55 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B17130EB5; Mon, 25 Jun 2018 09:55:55 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id v16-v6so312870wmv.5; Mon, 25 Jun 2018 09:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=GXDmj0vK2OvGo0YUnNpVwQSmHaeN+FQLmDs7C0uzRFg=; b=uh2MAqlnhP9fzAD0u8n35tWB1FyIqZJKDEHYIXTlAHs2VjSzUc4TZ6HIS7X1d2HC3i SfkGanbw5IUhNTHk1UE5uaquAQvAb+APzKbDrDG4jqqpiVhH16aKFmCG1EzQ7g8n2WA+ j1P6G4SfADhiXu61XATR0/mqXlVepamlMZLw3y7sOgZ2Nfpww1f7gjbMqRxxxNt1n5qR jFLHpZbyknz8FUnNtm4s5qpc5PWqeghrfKWHZoKEdzh8vquX6ac5vn6PKLfJk2LkDDyT 00EXq3cuEqEGTvIUoH6L4ZrLYB22r+mZlBODFDvrAsvpUWkCmxfp3V5zpma2qS4MpxbO LHmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=GXDmj0vK2OvGo0YUnNpVwQSmHaeN+FQLmDs7C0uzRFg=; b=BIfjhOcyB4PDbNa7pzmNGrSRElm+uUE+J8KWTMR4xbZNDGoKqAMysTWeN6bBuoQQxh t5tnpxMwtx5vjv488MO++uvdpccIT9d2DnZfaPRdR9z/IXlLwD1Nfdqp/N4GT+0t2kqT E06mWHhU+f80sXDD+2JBE+xs8bRrdJSzZOstSd4PK6NxXF8Qv+HsOKKr5yg8wZmdz8ef GarJr5pFD4FCdJLkPLe93Rv8+UI4Toi6mHQbD+wp0NpnbjOC08NTV45YgvTqybISvfO6 pK5oC2p+qZgZQqixxUCANGXBwr6l8O+U8XoQybSsWwDETEJ+QAfIFz92ZzvPQiUVjq4d pYgQ== X-Gm-Message-State: APt69E39g5Nmjyo6JB5ryB7pgzOSNG35/Nsh5N7QbFDwXcYzJMAHMAFW DZNA56qJYAS/kWu0faeZxjIwmOMW X-Google-Smtp-Source: AAOMgpcqDEpO56OfCaPZScKAu2vQnmrSPsJ0g3DV2tyUDj/Q7Q6ZMQ8hmBQO6xjIWT+Jc3QU0QgGng== X-Received: by 2002:a1c:9947:: with SMTP id b68-v6mr1577328wme.159.1529945753337; Mon, 25 Jun 2018 09:55:53 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id c10-v6sm14665127wrs.6.2018.06.25.09.55.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 09:55:52 -0700 (PDT) To: "Andrew G. Malis" , Alexander Vainshtein Cc: "mpls@ietf.org" , "sfc@ietf.org" References: From: Stewart Bryant Message-ID: Date: Mon, 25 Jun 2018 17:55:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D59F40794D2FD90531129C67" Content-Language: en-GB Archived-At: Subject: Re: [sfc] [mpls] Request for comments on draft-malis-mpls-sfc-encapsulation-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 16:55:58 -0000 This is a multi-part message in MIME format. --------------D59F40794D2FD90531129C67 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Andy, NSH has an OAM mechanism which you would use for OAM at that level. The only time you would want to use a GAL is OAM to the SFF itself. If we think that it is useful to apply OAM between an SFF pair we could use a GAL. If we think that it is useful to do ECMP, we might also put an EL/ELI at BoS. We could also do it with a FAT label. I am not sure what is better. Best regards Stewart On 24/06/2018 17:29, Andrew G. Malis wrote: > Sasha, > > Yes, thanks for asking, we can add that to the next revision. The > intent is that the NSH label operates similar to a PW or VPN label, so > whatever applies to them should apply to the NSH label as well. > > And thanks for reading the draft! > > Cheers, > Andy > > > On Sun, Jun 24, 2018 at 11:29 AM, Alexander Vainshtein > > wrote: > > Andy and all, > > I’ve read the draft and I have a question regarding position of > the SFF label in the label stack. > > The draft states the SFF label is located at the bottom of the > stack and immediately followed by the NSH header. > > I wonder if it is possible to have some special purpose labels to > follow the SFF label. The relevant example could be GAL (RFC 5586) > followed by the GACH for OAM purposes. > > RFC 7708 has allowed this for PW labels which originally also have > been defined as BoS only > > Regards, and lots of thanks in advance, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:*mpls [mailto:mpls-bounces@ietf.org > ] *On Behalf Of *Andrew G. Malis > *Sent:* Tuesday, June 19, 2018 6:14 PM > *To:* mpls@ietf.org ; sfc@ietf.org > > *Subject:* [mpls] Request for comments on > draft-malis-mpls-sfc-encapsulation-00.txt > > I’ve just uploaded > https://tools.ietf.org/html/draft-malis-mpls-sfc-encapsulation-00 >  . > It’s a short draft that discusses how to carry SFC packets that > include the NSH over MPLS from one SFF to the next, so that SFFs > that support the NSH can be connected via MPLS. It also includes > the ability for MPLS nodes to support more than one SFF. Comments > are appreciated! > > Thanks, > > Andy > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and > contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this > transmission in error, please inform us by e-mail, phone or fax, > and then delete the original > and all copies thereof. > ___________________________________________________________________________ > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --------------D59F40794D2FD90531129C67 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Andy,

NSH has an OAM mechanism which you would use for OAM at that level.

The only time you would want to use a GAL is OAM to the SFF itself.

If we think that it is useful to apply OAM between an SFF pair we could use a GAL.

If we think that it is useful to do ECMP, we might also put an EL/ELI at BoS. We could also do it with a FAT label. I am not sure what is better.

Best regards

Stewart




On 24/06/2018 17:29, Andrew G. Malis wrote:
Sasha,

Yes, thanks for asking, we can add that to the next revision. The intent is that the NSH label operates similar to a PW or VPN label, so whatever applies to them should apply to the NSH label as well.

And thanks for reading the draft!

Cheers,
Andy


On Sun, Jun 24, 2018 at 11:29 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

Andy and all,

I’ve read the draft and I have a question regarding position of the SFF label in the label stack.

The draft states the SFF label is located at the bottom of the stack and immediately followed by the NSH header.

 

I wonder if it is possible to have some special purpose labels to follow the SFF label. The relevant example could be GAL (RFC 5586) followed by the GACH for OAM purposes.

RFC 7708 has allowed this for PW labels which originally also have been defined as BoS only

 

Regards, and lots of thanks in advance,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Tuesday, June 19, 2018 6:14 PM
To: mpls@ietf.org; sfc@ietf.org
Subject: [mpls] Request for comments on draft-malis-mpls-sfc-encapsulation-00.txt

 

I’ve just uploaded https://tools.ietf.org/html/draft-malis-mpls-sfc-encapsulation-00 . It’s a short draft that discusses how to carry SFC packets that include the NSH over MPLS from one SFF to the next, so that SFFs that support the NSH can be connected via MPLS. It also includes the ability for MPLS nodes to support more than one SFF. Comments are appreciated!

 

Thanks,

Andy

 


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________



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

--------------D59F40794D2FD90531129C67-- From nobody Mon Jun 25 10:34:40 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3158A130ECA; Mon, 25 Jun 2018 10:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB0BA2A1pYTm; Mon, 25 Jun 2018 10:34:29 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA25130E13; Mon, 25 Jun 2018 10:34:29 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5PHT7R9013351; Mon, 25 Jun 2018 10:34:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=PPS1017; bh=6gzSCkTzkgeh116INy8mHF3ScTGRwlkUoOKGP0DLhK0=; b=Hh0pwpu/GWxaBPmo8td0ToLLfBHWicGvJlVCbNh5dnsGPLjW0V7NVpfeRFPhslb6NoH1 kPkv4j38p71S+ONuHsYqSQkg+BlNNE/+iuLLT9n1JIlvn9gAgT5AjS8MYVGL/Z/2UWpt 0VEdFQBDvugD+H/bp5LeDCASJwoZ24qznhM2yD2kY3yI8xN5LZzmBQxaC/mQhef2TR7g viOszUdE4F1xcnEukqa1ZZC2a+yZ8sW7y7lFBnMageVrDFNpcla5edggTFIG/KxMCH6b x/w4scpTJ3Lby18X4oIOCt/WfMEk4qc/W2W+n4PWMURIEpTAt/E7/bWM1gdWEA/zhFBs ng== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0083.outbound.protection.outlook.com [207.46.163.83]) by mx0a-00273201.pphosted.com with ESMTP id 2jtxdv8nhp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 25 Jun 2018 10:34:23 -0700 Received: from [172.29.37.70] (66.129.241.13) by SN4PR0501MB3870.namprd05.prod.outlook.com (2603:10b6:803:4a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.15; Mon, 25 Jun 2018 17:34:20 +0000 To: Alexander Vainshtein , "Andrew G. Malis" Cc: "mpls@ietf.org" , "sfc@ietf.org" References: From: Eric C Rosen Message-ID: <758e3c48-dd77-dff8-f18e-cdd0e01a8bc8@juniper.net> Date: Mon, 25 Jun 2018 13:34:17 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BN4PR13CA0019.namprd13.prod.outlook.com (2603:10b6:403:3::29) To SN4PR0501MB3870.namprd05.prod.outlook.com (2603:10b6:803:4a::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 834de0b7-3c5b-4260-1386-08d5dac1e2cf X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989117)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:SN4PR0501MB3870; X-Microsoft-Exchange-Diagnostics: 1; SN4PR0501MB3870; 3:zEVlNN1fSdfJFWq3iI7tVlLsphM2ieEcQEPTBg9GKsGpZrqcGnVibpJFuSB4S52oz2k3QjKswkp2pLEb2lEJpYGo++sgdwt/y+4qVR7z66VTGrhqKdJhUB29TqZgbtRGw9dhMJRbgWdwRgf2xVjyln1WpkrI5KKTIrkAj6EHXS2nNPdFc37u9bd3fYJeD28FZqUb3RSQx+8mQFD/B+W43FHrt40xxFT7XT5VtVdpYDo4yTlv0QoMxYQqLEu2MOG6; 25:qTIah9CEwwuOkYlki7uoDSYCO/o4AiQiRIZXdgOkkPBOLCizsjR5L9LLCCm6AmB66mSftqGME2RW/uxgaNCkquk/OYxeOixJ2NZ8GPbbZRjW/YKupyC8Cx3HH35sjfl/nkVtnultPfqjsb2ZcdBk/XhNeiLU3N3+b66Gx09HbN2B5SkX4OQieJxxsDt6bW2l2FkweTM/3trHNcJ3068CZ9n/M2YwiAkrKq7/HyxJh44r18BD9j66z5GgA3ePdty2K5JtwBOzVttyKOhXQV43EeB1HWJV6Yl2TsTnvXB5d+dudg7Y5+q8l+nOWqjgua8lYIAPUsmVBazlkILwcv3tCA==; 31:ThQkcqRFmWXD9Z54pvLbBuziLhG1rapqz0jWRTdSUNKVt97aMYFHhbeoE5lNTSKR0fUmPF7wi0SoTUtkHZTN9EyTuV78kARklikvyUySohTpMb4ukecToqhVEYQ1rL4IdtiqJT7FvoP9X/4TRZOXEq2UKZIH0/omSALgj9IFFZL+kfHIgFcIYkgQXahR9r8Nsh3j6BAhcCgzFwlrMRLTLbpwJHSyAESN8B3YIrCjszA= X-MS-TrafficTypeDiagnostic: SN4PR0501MB3870: X-Microsoft-Exchange-Diagnostics: 1; SN4PR0501MB3870; 20:03flU9KzdVUAWgIE+J6PNxPohlpQvXb61z2n7G/ij6/1Gw2/yhIq8qDXgpa+vWAsSJdJGNiGgT1C/9vXH11cV8q2vFvZC9AAHMqvApGRdT/Csn8JKqL3fHidSbC6mfQySyu00a2t/6BhPMsg+oEXjorgdNmLHTtv4kWTU5CtnFirR2K6Bxlanc1fvYXuXSR199iWc61m8Ou2iZFMVdW3YFWjM2+Wf43QXbRwfw0fSqGmI3rBlLz6evQTn2uovJMJCt25i75LxPFlH0t9glHg4XdUsXnQa6g2MxC8ttg8FEsu/LRNYgdcfxMUMpeVPLXI9L173Ad/XLjUV3r8po+bD7sgLnOv46jJZycC2yD+Qx+sCrXwibu22EQ1fB3IENhaVjQ7BOnktyveCI30PI/jMvJbRGTP6Hj7KXQ1RBLLCTws+xSOmgKX9/b9yGDdiMz0YQFmA1jX0XmeW0Nygmrly1BwJsJcDsoKTu31QdhAiz6ChkFHnzREgAOxtv2hIUpKJ2mwNd59rl9W34M2Mw620eKaOCtl20P4EUQCqtnndyqasI4msHAFTfJWelX5xPqenRFs+ZI2p+xtlLwvtoiNcEbJ8uo/XSUBkDdYjwVaM8c=; 4:Z/E4+Pm2abdPZM4cPwDYHe0er6rw1Ex6QyjhklUChQEnFbVgzucQhu6qHKNBIzGX7RtY0ecN1lcrNzqD7qzcA0qoojTdXLLpgzZZOu8tEnUa21D7BuohVbcUn+SSRIU76nCSmp8H6aal2MHJsf8K+iH6kN6cw6dmxuyj+qjzFwYNJqjYsEOFMM32GDvpVIcKQN8RvlVQjj4KrlrToXEM1V475UYTusABu0V19xwLwmzhdBdnHcPFgPEmwbRT13FUJSoPkMb3JuWutmtq9TXiEA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:SN4PR0501MB3870; BCL:0; PCL:0; RULEID:; SRVR:SN4PR0501MB3870; X-Forefront-PRVS: 0714841678 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(366004)(376002)(136003)(39860400002)(396003)(346002)(54094003)(199004)(189003)(67846002)(65826007)(50466002)(68736007)(77096007)(229853002)(16576012)(11346002)(316002)(58126008)(2616005)(25786009)(476003)(3260700006)(53936002)(39060400002)(956004)(26005)(110136005)(54906003)(6486002)(6666003)(16526019)(6246003)(446003)(4326008)(486006)(36756003)(2486003)(2870700001)(52146003)(23676004)(106356001)(386003)(81166006)(97736004)(76176011)(52116002)(105586002)(8936002)(65806001)(7736002)(5660300001)(31686004)(81156014)(65956001)(8676002)(478600001)(66066001)(64126003)(3846002)(2906002)(6116002)(31696002)(47776003)(305945005)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN4PR0501MB3870; H:[172.29.37.70]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjRQUjA1MDFNQjM4NzA7MjM6MlBhR2dtRGY4M2V0dEFHSHZnc0tBVE1W?= =?utf-8?B?Q05lSU53bVVyMjJGVXRVS2RhWXl4T1IvTVZsQUxGMzQrNXM3bW00NlZnVlJi?= =?utf-8?B?eCsvbXlBZ0FRZHJ0MzdMSEdsQnBpOFk2aFZBd3dCUU5WTVk1c0ZYcGNhSSs2?= =?utf-8?B?bFRQZUtZdDI3R05LcnNaSnlVUWRib1A1d3c3VDhkTUVYUEY0b1pEWWZUNUNB?= =?utf-8?B?RUs1SmZXYzE2Uld3ZW0rUXpVZDR5OVhOTUoyT3l2VG44Zjh5akp1S1NxbDFj?= =?utf-8?B?NTlSenl3QnNXZDJKVC9aSVZwRmRwQ0s3L2NCR3lqa08wNExKOE5WZU82UDc1?= =?utf-8?B?MlI1ZzdrYWQzbTV0SFVpdlVMZHlpWVNXckVWNmJkcVpkYVpRbi9XTExBMjd1?= =?utf-8?B?b1hONUo4UUlLNWhEamNlMFNpcHVHSkNmU0ttL0lLRGJvQURzYUllZWEzZXNU?= =?utf-8?B?SHlYOG1OSnFYZWh0clIxYUNnUGJKR1VEald5d1lqTWlVWXYzL0ZSWjZ1MDJV?= =?utf-8?B?RFRQdnk1UG9TcUNlc3I2WFBFNmdXN1BKdW5BRmxYN1oybVRpZERoZHRIdkx1?= =?utf-8?B?STFnTFVOSWRVR0NDODc4dXk4b2xsSmxkMkZ5Qktqc0liRXd1OUMvZ2puek9x?= =?utf-8?B?UWY5NGIvRkpaYmFZWlhkbGVlL3BxRUNndU1GQXZxWU1zakN3WVVpTCtZcFlG?= =?utf-8?B?ZFViRHQ3M0lrSzJsUEp6bWo2QzFuNnRLOHgybVkvNmd4TlU0bFJkcXp4TURR?= =?utf-8?B?bnVYVjk3OUQwMWJneFF0N1BJWXFXeHV4SExpRk1pWU12Si82NDVCQ01OMVNq?= =?utf-8?B?ZlpHVFF2YXRmYkl4aWI4NitmdjgwZ0dIYksyK0paRnplL2ZrNVNxV0I1NzdD?= =?utf-8?B?bDV0eTF0cFhUSjdwemgwbVZnaWs2SUZDcTZMNWVLeHNDNXNRK0Y2WGEvM3Z4?= =?utf-8?B?bEtzMGFDUEwvdlhFZENjUUppOEpZbHRnV09NNHo5MXg1cVlZcHlSRFZDWlov?= =?utf-8?B?TzZ2UmxNelRrcUZ1K3RKblpsM3pUOWFDUTNzV2hoQXRCem5iZzlJYSt1OXhk?= =?utf-8?B?TWgvMkNhS2h5RHFhcllvaDdLMGpRVWRQbGgwVVJJVTA4ME5zcDlFemRaVEQ5?= =?utf-8?B?ajVHeS96OXNTNDhRZWMwMkpkUEJVOEVTaHQ2TzRvZmpldEp6cGhVTUhhT2tt?= =?utf-8?B?RmcvZkUxMks2bTIybUt1QWhNSGtPc2k2NWNyb1ZkT1NwWHJ4UXJMM2htc1dq?= =?utf-8?B?YWJ4ZDJ5VXQzN1VKSFhuQkI0dUdCWHNRWFRBTGZYSnhIdnhKd1Q5SjR6NFgv?= =?utf-8?B?RlVlVW1xWVg2SmdqZHJvdzJjWkYxeWdCelRuTS9ic1dja2lFREEwVmJqS3Jl?= =?utf-8?B?RGh6RWY3MDNubFNSeTYvMDBleGVoeWphcnJzL3lpRTNZUS9vMlRsYjJLZjVv?= =?utf-8?B?MExUbzA1blVQZU9Nb1d5b1AvaDBJQnRzdVVXRW1JaGpjTUxDV0pzaW8vYy95?= =?utf-8?B?MEVvNWFZb0hjUVFpNDJQNkx3Sm9DZ0xVTks2dEM5NHlxcU0xOHpaT0ZsMXQz?= =?utf-8?B?SEJmUWQvK2kyT2h2QjUrekhWTWoxUUFRcW5ESmxJUXBVdnNZODdBSG9iZWl1?= =?utf-8?B?QWJlaVRhQU1Ic3dDSFQ5blQra0Rzdkl5REZXS0dwS05jMlAzdGNxM1NvRUJC?= =?utf-8?B?UHliRkw2dDRVRE5ydGZYYzZvQkswQVlaS3dhWW5oTTMrZ2lIZjg5dG9tSDdC?= =?utf-8?B?Rzh1RTFVbWpRYjE3dE9FZDdmc0J5WGh0aUR6aCtuT2xmc3A5c3dXSVljbWtV?= =?utf-8?B?eVBsYTkxYTc1dG44c3EvQlBqQzc2LzJoclB4VFU5QS82eXp0ZEZBZlE4RDk1?= =?utf-8?B?b1JUV0ZRRzBYVkhNZXA2ZDl5T05lSVdhYVRZa2dRcjk2ZVdFdUtIYUMreTlO?= =?utf-8?B?dStuRnZURDA1NkhURHIveDk4cEREQ25vVzBCMlBvVHhGZkJVNHV4bkVmdlF0?= =?utf-8?B?bytGYlJJdWd2M3pndEFVelNYK1AySlMzVkdlcDF3PT0=?= X-Microsoft-Antispam-Message-Info: uGLOOYSU80FYx1dRqsHbqBFs8e5aFsW4nzMGX/ieXpEs/LpMchpcmXWGNeN+HMavAhjx//qBpr+PieuV89ClH7yd3/WzV8awjF8rTJQ+r9P9PbwwqTrQ04expRfksJi2YQDFxe0pFZnBpf939kRI2BgwG2EHNS2QAJacxqltECLG4PeRbUdun9zm6nvvVbOBs5DjeW/AyrnBrd2igPkeOom+R0InouwJf6CgjpAHH0FJqVPN3VD/2wTsDKzCnTcYoo6u2GQKWBqfSSHnr6meIRJpkA0Cc3HvdgIuMA1J/YiIyrBvIUG9eSb4omqR5rhejoOhx37b/4uEdwvmxJMGj+6wFPYH5LC6DhhNltISc58= X-Microsoft-Exchange-Diagnostics: 1; SN4PR0501MB3870; 6:JIZo1bTBgy+5vRsrDUU7xsJLlDklhBsEWi/pQ3OSuohZsRi/BZ9WaiIdaLeAV3Wkk3eYCbN4hX9+/NR7zLDzONuE/SjhxPh+xt5Ww7fPxNo5ZtBFXRnLJmdfB3ITnlJxIZ26h8nnS8qIqzqPCXpP6Y0R/uriMxJLJu3QAvdWKR6+s0bGP+wJXvPROVSrf2h2YH/aJg6ECBd0isyPbKRkNmAZkkOYBVYwog/HnjXIUskOMC6mdSbpCrwjGf8g7igz5X6MTGg+94z8n0sqjE8jpstpi8WsNurJ4kabOn1BxlZa6FsWiExL0qosYhElxUIWbHG8oDoX36F2X4wo0DPkFBTQ/6ZaD6tMPxeUS7t3LK5Vw7TuOHV3FKp85CGznt23s2DdIw6j4c+kNV5WZX3aSmzoOpOmYoME+c4DGmRl2POr5alZWzVktNCYOZCxGvh6IeYNHrkP0HWC/3RcKx+dtQ==; 5:vZpkVSCPj1MS+Bp+fcZQKWKY/7OSOAb8EJ98X9lrjplTSt319rvDW3fbZOmZZZDPLAEY+SHIOxFoHOGrVT9i+hGTjphzo78y8jJJ/O/VpriZBGEAKJOPRkuI0QH58LgcvhYQpuGcwEzdI2qkQWvHrwVPS15FkKMQtcAs6mv4rQ8=; 24:OrtnS0KyjmzANn8O+n0QOdmCKrnvoIj85AKkAy9AAShiDETOSefiQ42Gs20raCAhV02f35vPGuoNngnSAKf53sFYdqomrJivCj16ne/VqOo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN4PR0501MB3870; 7:8iTmFl/2P/wy6AwsWiUKaTMO0yhdPOxMmlLHTpkkaDnG3dZ/+jgi+XVmRbuxoIRjAFrLLeoaTtbcC5R2Q1JHZf01d3Nj9S2DWNcgmtZpUjXzvhnCMv1vo50kQjBZMAlu6XeZvSIpddvmUHEFzlKDTIPKyQuD9Mkb21m7HDnQV3K/FePGfPJNPjZdBVf0T3VdcKxs0CfEEb5KYNgA5CQC9jC1jgJ9rUf6GKQSr0QDUqN7pDrNuuH8kNjzV2+HEnkJ X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2018 17:34:20.4983 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 834de0b7-3c5b-4260-1386-08d5dac1e2cf X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0501MB3870 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-25_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806250203 Archived-At: Subject: Re: [sfc] [mpls] Request for comments on draft-malis-mpls-sfc-encapsulation-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 17:34:32 -0000 It's always a bit tricky to specify the precise rules for creating a label stack.  I think the rules for creating the label stack atop an NSH packet are probably something like the following.  Suppose one has an NSH packet, and one has chosen a target node on the network, where that target node is (or contains) the SFF that next needs to receive the NSH packet (the target SFF).  Then create the label stack as follows: - Push on zero or more labels that are to be interpreted by the target SFF.  (I guess the GAL label could be an example here.) - Push on the SFF label.  (A label that, at the target node, is associated with the target SFF.) - Push on zero or more additional labels such that (a) the resulting label stack will cause the packet to be transported to the target node, and (b) when the packet arrives at the target node, either:   * the SFF label will be at the top of the label stack, or   * the SFF label will rise to the top of the label stack before the packet is forwarded to another node and before the packet is dispatched to a higher layer. It's probably best to also state that PHP MUST NOT be applied to the SFF label.  (I realize that the control plane is out of scope here, but whatever the control plane is, it needs to set up the PHP appropriately.) It would be good to say what the SFF is supposed to do if it gets an MPLS packet rather than an NSH packet (i.e., if the SFF label is not BoS).  The SFF might or might not understand the label following the SFF label.  Also, if the following label is v4-explicit-null or v6-explicit-null, does that convey any semantics?  Frankly, I wonder if it's a bit dangerous to allow labels below the SFF label, as this will cause problems if the SFF label is programmed to cause a dispatch of the remaining packet to a procedure that does not understand MPLS at all and is expecting to see an NSH packet. It would be good to say where something like the entropy label would appear in the stack.  Before the SFF label?  Or after?  Or either? From nobody Mon Jun 25 11:58:35 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188DE130EF1; Mon, 25 Jun 2018 11:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zxz2OD-fP26N; Mon, 25 Jun 2018 11:58:13 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7612A130EF0; Mon, 25 Jun 2018 11:58:13 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id x6-v6so10404673wmc.3; Mon, 25 Jun 2018 11:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=jJegQwuv7g+WZWn3YQJbVKfLsPK9Db2mUtCoj7vuKDw=; b=bVoRII0UhFZNq1JTQy4YCFCKu43MaSj8fUYN11JSBrpD8mMSDVG6HJToVYaaaXIbBr eJRyVeOP6+xwIIfCRMzhvlWRw16PJpDeSVSZ5Hr+Wdt91IMWyXC8kSBgtPCzZzgGtD5Q spY1oSFqPML1JcsNKsKrQD4dYUbSuGQ9EoEJxdpVzqIUaBL+tESDhqBa7DJUWz/djAtD p6Fc0VX6b0p23xs0E3cwBMTWC3Vb8pzGi2g/1lcTV3SQ7InQv8g53QuvmH3mDlEgYFAt OdYFkItrQvQjYuG+mHQpzJ8Tm3QSbO+NyrJJL7GdsHmPv1kFByd3t9VmHBFeoZfvharv scTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=jJegQwuv7g+WZWn3YQJbVKfLsPK9Db2mUtCoj7vuKDw=; b=tJf9c67UhBH5h+6cIKtm7MRo1faDv7pN7xrvnjxLGun60m4b6Zzi4Yrg9DNHQs38Xf 50EzkF75AMGMHmkiH2ZFb6ADBmdKmb6w2zauQaWibsDthA7qDYUo/Gz/UAAj8vB7yj5N rP7KbiWSZVbBLWPn7t5yFiCegr26/ymm1DoJ6gs0qXe883S4EC8/AzkLm//PMNng/Dfy 2Dz0xpqZAOapVktQXNATaNzEr9BMegfvrOz1G0dIHCs1BjZzWvfS7oU5xFSwMEK7944a qB4aOiJRsPYyO3PIvRgaEErs7Hg8lo0K1uEGdN5Xm6qirx55YVAR9HLEODldPTZYlXSb ci7A== X-Gm-Message-State: APt69E3x8l9fL5LaPuqa3+NQ5OmXqRb2oz1VY3cQwigsqkCeyB521ANo rySUiWfPa+mSR5u4C0o1TbYwvrA+ X-Google-Smtp-Source: AAOMgpc1fI/a4LNRO0Pk1l1SHh/U41J5VugK+9PzHmockweb303BCBe2v0yHLY9XtKRSo9QQ47S3YQ== X-Received: by 2002:a1c:78b:: with SMTP id 133-v6mr2011766wmh.59.1529953091361; Mon, 25 Jun 2018 11:58:11 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id z14-v6sm7462204wma.11.2018.06.25.11.58.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 11:58:10 -0700 (PDT) To: Eric C Rosen , Alexander Vainshtein , "Andrew G. Malis" Cc: "mpls@ietf.org" , "sfc@ietf.org" References: <758e3c48-dd77-dff8-f18e-cdd0e01a8bc8@juniper.net> From: Stewart Bryant Message-ID: Date: Mon, 25 Jun 2018 19:58:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <758e3c48-dd77-dff8-f18e-cdd0e01a8bc8@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [sfc] [mpls] Request for comments on draft-malis-mpls-sfc-encapsulation-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 18:58:27 -0000 Hi Eric Your description is what I would expect to happen. The question is always  what should you leave unsaid as it is obvious to those skilled in the art, and creates maximum flexibility to allow innovation, and what should you say to resolve ambiguity and prevent an unnecessary infinity of functional combinations? On 25/06/2018 18:34, Eric C Rosen wrote: > It's always a bit tricky to specify the precise rules for creating a > label stack.  I think the rules for creating the label stack atop an > NSH packet are probably something like the following.  Suppose one has > an NSH packet, and one has chosen a target node on the network, where > that target node is (or contains) the SFF that next needs to receive > the NSH packet (the target SFF).  Then create the label stack as follows: > > - Push on zero or more labels that are to be interpreted by the target > SFF.  (I guess the GAL label could be an example here.) > > - Push on the SFF label.  (A label that, at the target node, is > associated with the target SFF.) > > - Push on zero or more additional labels such that (a) the resulting > label stack will cause the packet to be transported to the target > node, and (b) when the packet arrives at the target node, either: > >   * the SFF label will be at the top of the label stack, or > >   * the SFF label will rise to the top of the label stack before the > packet is forwarded to another node and before the packet is > dispatched to a higher layer. > > It's probably best to also state that PHP MUST NOT be applied to the > SFF label.  (I realize that the control plane is out of scope here, > but whatever the control plane is, it needs to set up the PHP > appropriately.) For that to happen you would need to pop two labels which can only happen by error, which is something we can mitigate against, but never completely avoid. > > It would be good to say what the SFF is supposed to do if it gets an > MPLS packet rather than an NSH packet (i.e., if the SFF label is not > BoS).  The SFF might or might not understand the label following the > SFF label. I imagine that would be a parameter of the SFF label. You would certainly need to know which type the packet was to get the MAC layer right. > Also, if the following label is v4-explicit-null or v6-explicit-null, > does that convey any semantics? Probably which ethernet type to use if going to the SF over a LAN. > Frankly, I wonder if it's a bit dangerous to allow labels below the > SFF label, as this will cause problems if the SFF label is programmed > to cause a dispatch of the remaining packet to a procedure that does > not understand MPLS at all and is expecting to see an NSH packet. It depends how the packet gets from the SFF to the SF. If it is pure internal processing on the SFF and no further checking that would be a problem, although you could prevent it with an SFF rule, but in any case where the packet was sent across a network the MAC type ought to be MPLS in which case the SFF would bin the packet as unknown/unexpected type. > > It would be good to say where something like the entropy label would > appear in the stack.  Before the SFF label?  Or after?  Or either? > Certainly before, but there is a case for both else we will end up also needing FAT labels. Thanks for your thoughts, we will reflect them in the next version. - Stewart > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Jun 25 13:22:08 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C80130E3E; Mon, 25 Jun 2018 13:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj1L_o2Iabmm; Mon, 25 Jun 2018 13:22:04 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A16130E3F; Mon, 25 Jun 2018 13:22:03 -0700 (PDT) X-AuditID: 12074422-df5ff70000000c70-7c-5b314eea743b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 7F.76.03184.AEE413B5; Mon, 25 Jun 2018 16:22:02 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w5PKM10Z027818; Mon, 25 Jun 2018 16:22:02 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5PKLvVh001334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jun 2018 16:21:59 -0400 Date: Mon, 25 Jun 2018 15:21:57 -0500 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: The IESG , "draft-ietf-sfc-hierarchical@ietf.org" , Behcet Sarikaya , "sfc-chairs@ietf.org" , "sfc@ietf.org" Message-ID: <20180625202157.GI99689@kduck.kaduk.org> References: <152954550322.28624.14636040697546417914.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF49B65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20180622182042.GJ64617@kduck.kaduk.org> <787AE7BB302AE849A7480A190F8B93302DF4B5E3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF4B5E3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUixG6novvKzzDa4N8xQ4tpXz8zWsz4M5HZ 4vDbp+wWs3tPs1js2TaN3eLJg63sDmweTyccZPJYsuQnk0fLs5NsAcxRXDYpqTmZZalF+nYJ XBkfbm5nKTgpVLHwegdzA+NBvi5GTg4JAROJN/93snQxcnEICSxmkmjrP8YI4WxklOiZ+pAN wrnKJLH+zUw2kBYWAVWJnbOeMYLYbAIqEg3dl5lBbBEBBYl9bf1go5gFGpgkFtzZwg6SEBZI lXh6HaKBF2hf84I17BBTVzJJHGh5yQyREJQ4OfMJC4jNLKAjsXPrHaBtHEC2tMTyfxwQYXmJ 5q2zwco5BZIkXux4DDZTVEBZYm/fIfYJjIKzkEyahWTSLIRJs5BMWsDIsopRNiW3Sjc3MTOn ODVZtzg5MS8vtUjXVC83s0QvNaV0EyM4GlyUdjBO/Od1iFGAg1GJh3fFS4NoIdbEsuLK3EOM khxMSqK8acyG0UJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeO32A5XzpiRWVqUW5cOkpDlYlMR5 cxcxRgsJpCeWpGanphakFsFkZTg4lCR4f/kCDRUsSk1PrUjLzClBSDNxcIIM5wEafhmkhre4 IDG3ODMdIn+KUVFKnPcCSEIAJJFRmgfXC0pWEtn7a14xigO9Isz7H6SKB5jo4LpfAQ1mAhpc 9hjk6uKSRISUVAOj2ye1NTbt9x+/M905k4HzjuWreTt2e8YEzj3YUG96rXvtVrlFxpe/cc8x zu16NWfimlAJ22PPZaz0Ls9ZePyvlcORnVO2qF77w+vTNW+75jzrM1veacbarnonUBP9dOvS roq//UlVSeHa+4sP7j8vpvbw+4eHO4ruB1iWB2/sPaltvHNd+rdjokosxRmJhlrMRcWJANTx hPYxAwAA Archived-At: Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 20:22:06 -0000 On Mon, Jun 25, 2018 at 02:06:26PM +0000, mohamed.boucadair@orange.com wrote: > Hi Benjamin, > > Please see inline. This all looks good; just one final note inline > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoyé : vendredi 22 juin 2018 20:21 > > À : BOUCADAIR Mohamed IMT/OLN > > Cc : The IESG; draft-ietf-sfc-hierarchical@ietf.org; Behcet Sarikaya; sfc- > > chairs@ietf.org; sfc@ietf.org > > Objet : Re: Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with > > DISCUSS and COMMENT) > > > > > > On Thu, Jun 21, 2018 at 06:42:11AM +0000, mohamed.boucadair@orange.com wrote: > > > > > > > -----Message d'origine----- > > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > Envoyé : jeudi 21 juin 2018 03:45 > > > > À : The IESG > > > > The approach described in Section 4.1.5 also seems to be incompletely > > > > specified, in that the hSFC Flow ID semantics are not covered at all. On > > > > my initial reading I assumed that this field's encoding and semantics > > were > > > > intended to be left as entirely local matters to the lower domain, > > avoiding > > > > a need to specify them in this document. > > > > > > [Med] The semantic is local to a domain. > > > > Agreed, it will not escape a single domain. > > > > > However, I'm not sure that it's > > > > actually true, since we generally want multiple vendors to be able to > > > > interoperate, > > > > > > [Med] Intermediate SFC elements do not need to understand the semantic of > > flowID. They will handle the flowID as an opaque value. > > > > Agreed. I think it might help to call out (as is done in Section 4.1.1) > > that if the egress IBN differs from the ingress IBN, there is a need for > > state synchronization between those nodes. > > [Med] This is the intent of "state replication mentioned in Section 4.1.1". > > I changed the text to "state synchronization mentioned in Section 4.1.1". Ah, looking at the -10 now I finally see what you are referring to. I think when I first read "state timeout and replication mentioned in Section 4.1.1" I did not make the connection that it was specifically the *state* replication as well. Probably that's just me reading to fast, but I think your change does increase clarity. Thanks again, Benjamin From nobody Mon Jun 25 22:25:44 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F6E130F55 for ; Mon, 25 Jun 2018 22:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNqD-n34ZUP8 for ; Mon, 25 Jun 2018 22:25:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8162130E80 for ; Mon, 25 Jun 2018 22:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9654; q=dns/txt; s=iport; t=1529990741; x=1531200341; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L7S0CDPbag+PFWsLB/fGzxvUQ4UOjXhcyA/5yb6tyaM=; b=hjv7ulc6FUlJTdl/gtkfK9BQZdmYizYGJJ//pwn8dKNyvJZ7/fAlAVau 8x0AaKBk+FJPtNPTA6ksnS2NdrpfRLHibVkpA5j4tQXFaJ9Zxuu5boFAV jfH1vhabg3k67TbV7l+NEwMcZlNWs83MV/VPdO9pSJWcJnp/CRJtrDJEX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVAQDYzDFb/40NJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTVwEBAQEhYn8oCoNvlEaKModfhQaBegsYAQqESQIXgnY?= =?us-ascii?q?hNRcBAgEBAQEBAQJtHAyFKQIEAQEhSwsQAgEIPwMCAgIfBgsUEQIEAQ0FG4M?= =?us-ascii?q?KAYEbTAMVD6xughyEW4I1DYEsgRUFiGyBVj+BNoJoglZCAQGBPYMkMYIkApk?= =?us-ascii?q?ELAkCiGCDJoMJDY08inKGVQIREwGBJB4BNoFScBU7KgGCPoFziSCFPm+OWIE?= =?us-ascii?q?aAQE?= X-IronPort-AV: E=Sophos;i="5.51,273,1526342400"; d="scan'208,217";a="197312914" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2018 05:25:39 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w5Q5PdrN004992 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jun 2018 05:25:39 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Jun 2018 01:25:38 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1320.000; Tue, 26 Jun 2018 01:25:38 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky , "Joel M. Halpern" CC: "sfc@ietf.org" Thread-Topic: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms Thread-Index: AQHT/NY/Z/77rh2SF0KJakcEBPxNeqRYZcyAgBn/z4A= Date: Tue, 26 Jun 2018 05:25:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.133] Content-Type: multipart/alternative; boundary="_000_E6D83E7510ED4CA1B28712F94D39D731ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 05:25:44 -0000 --_000_E6D83E7510ED4CA1B28712F94D39D731ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9lbCwNCg0KSSBhZ3JlZSB3aXRoIHRoZSBkaXJlY3Rpb24geW91IGRlc2NyaWJlIGJlbG93LCBh bmQgZm9yIGNvbXBsZXRlbmVzcyBJIGRvIG5vdCBzdXBwb3J0IGJ1aWxkaW5nIHVzZSBjYXNlIGRv Y3VtZW50cyBhbmQgcmVxdWlyZW1lbnQgZG9jdW1lbnRzLiBUaGUgcmVmZXJlbmNlIGZyb20gUkZD IDgzMDAgc3VmZmljZXMuDQoNClRoYW5rcywNCg0K4oCUIENhcmxvcyBQaWduYXRhcm8NCg0KT24g SnVuIDksIDIwMTgsIGF0IDEyOjIzIFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwu Y29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGkgSm9lbCwgZXQu IGFsLA0KSSB0aGluayB0aGF0LCBhcyB3aXRoIGFueSBzb2x1dGlvbiBwcm9wb3NhbCwgd2UgbmVl ZCB0byBjaGVjayBpdCBhZ2FpbnN0IHRoZSB1c2UgY2FzZShzKSBhbmQgdGhlIHJlcXVpcmVtZW50 cyB0aGF0IGNoYXJhY3Rlcml6ZSB0aGVzZSBjYXNlcy4gSSBkb24ndCBzZWUgdGhlc2UgYmVpbmcg ZGlzY3Vzc2VkIGluIHRoZSBkcmFmdC4gQXMgeW91J3ZlIHBvaW50ZWQsIHRoZSBkcmFmdCBhZGRy ZXNzZXMgdHdvIGNhc2VzOg0KDQogICogICB2ZXJpZmljYXRpb24gdGhhdCBwcmUtZGVmaW5lZCBz ZXQgb2Ygbm9kZXMgd2FzIHZpc2l0ZWQ7DQogICogICB2ZXJpZmljYXRpb24gdGhhdCBwcmUtZGVm aW5lZCBvcmRlcmVkIHNldCBvZiBub2RlcyB3YXMgdHJhdmVyc2VkIGluIHRoZSBleHBlY3RlZCBv cmRlci4NCg0KV2hhdCBhcmUgdGhlIHVzZSBjYXNlcyBmb3IgZWFjaCBzb2x1dGlvbiBhbmQgYXJl IGJvdGggcmVxdWlyZWQgb3Igb25seSB0aGUgbGF0dGVyLCBhcyB0aGUgc3Ryb25nZXIgYW5kIGNv bXBsZXRlLCBoYXMgYSBwcmFjdGljYWwgdXNlPw0KV2hhdCBiZWluZyB2ZXJpZmllZCAtIHRyYXZl cnNpbmcgU0Ygb3IgU0ZGPw0KDQpUaGUgbGlzdCB3aWxsIGdyb3cgYXMgd2UgbG9vayBpbnRvIHRo ZSB1c2UgY2FzZXMuDQoNCkFuZCBvbmUgbW9yZSwgdGhlIHByb3Bvc2VkIHNvbHV0aW9uIGlzIG9u bHkgb25lIG9mIG1hbnkgYWxnb3JpdGhtcy4gSSBiZWxpZXZlIGl0IHdpbGwgYmUgZnV0dXJlIHBy b29mIHRvIGFsbG93IGZvciBvdGhlciBhbGdvcyB0byBiZSB1c2VkLg0KDQpSZWdhcmRzLA0KR3Jl Zw0KDQpPbiBUdWUsIEp1biA1LCAyMDE4IGF0IDc6MDUgQU0sIEpvZWwgTS4gSGFscGVybiA8am1o QGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+IHdyb3RlOg0KTXkg aW1wcmVzc2lvbiBvZiB0aGUgY29udmVyc2F0aW9uIGluIExvbmRvbiB3YXMgdGhhdCB0aGUgd29y a2luZyBncm91cCB3YXMgbGVhbmluZyB0b3dhcmRzIGtlZXBpbmcgYm90aCBvZiB0aGUgcHJvb2Yg b2YgdHJhbnNpdCBhbGdvcml0aG1zLg0KT25lIGJlY2F1c2UgaXQgaXMgdmVyeSBlZmZpY2llbnQg YW5kIGNvbmZpcm1zIHRoYXQgZWFjaCBTRiBoYXMgYmVlbiB2aXNpdGVkLA0KYW5kIHRoZSBvdGhl ciBiZWNhdXNlIGFsdGhvdWdoIGl0IGlzIG1vcmUgY29tcGxleCwgaXQgdmVyaWZpZXMgb3JkZXIg b2YgdmlzaXRpbmcsIHdoaWNoIGlzIGltcG9ydGFudCBpbiBhIHNpZ25pZmljYW50IHN1YnNldCBv ZiBjYXNlcy4NCg0KRG8gZm9sa3Mgb24gdGhlIGxpc3QgYWdyZWUgd2l0aCB0aGF0IGRpcmVjdGlv bj8NCg0KWW91cnMsDQpKb2VsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGlu ZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== --_000_E6D83E7510ED4CA1B28712F94D39D731ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkpvZWwsDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFncmVlIHdpdGggdGhlIGRpcmVjdGlvbiB5 b3UgZGVzY3JpYmUgYmVsb3csIGFuZCBmb3IgY29tcGxldGVuZXNzIEkgZG8gbm90IHN1cHBvcnQg YnVpbGRpbmcgdXNlIGNhc2UgZG9jdW1lbnRzIGFuZCByZXF1aXJlbWVudCBkb2N1bWVudHMuIFRo ZSByZWZlcmVuY2UgZnJvbSBSRkMgODMwMCBzdWZmaWNlcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0id29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NClRoYW5rcyw8L2Rpdj4NCjxk aXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCuKAlCBDYXJsb3MgUGlnbmF0YXJv PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVuIDksIDIwMTgsIGF0IDEy OjIzIFBNLCBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWls LmNvbSIgY2xhc3M9IiI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+ DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPkhpIEpvZWwsIGV0LiBhbCwNCjxkaXYgY2xhc3M9IiI+ SSB0aGluayB0aGF0LCBhcyB3aXRoIGFueSBzb2x1dGlvbiBwcm9wb3NhbCwgd2UgbmVlZCB0byBj aGVjayBpdCBhZ2FpbnN0IHRoZSB1c2UgY2FzZShzKSBhbmQgdGhlIHJlcXVpcmVtZW50cyB0aGF0 IGNoYXJhY3Rlcml6ZSB0aGVzZSBjYXNlcy4gSSBkb24ndCBzZWUgdGhlc2UgYmVpbmcgZGlzY3Vz c2VkJm5ic3A7aW4gdGhlIGRyYWZ0LiBBcyB5b3UndmUgcG9pbnRlZCwgdGhlIGRyYWZ0IGFkZHJl c3NlcyB0d28gY2FzZXM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHVsIGNsYXNzPSIiPg0KPGxp IGNsYXNzPSIiPnZlcmlmaWNhdGlvbiB0aGF0IHByZS1kZWZpbmVkIHNldCBvZiBub2RlcyB3YXMg dmlzaXRlZDs8L2xpPjxsaSBjbGFzcz0iIj52ZXJpZmljYXRpb24gdGhhdCBwcmUtZGVmaW5lZCBv cmRlcmVkIHNldCBvZiBub2RlcyB3YXMgdHJhdmVyc2VkIGluIHRoZSBleHBlY3RlZCBvcmRlci48 L2xpPjwvdWw+DQpXaGF0IGFyZSB0aGUgdXNlIGNhc2VzIGZvciBlYWNoIHNvbHV0aW9uIGFuZCBh cmUgYm90aCByZXF1aXJlZCBvciBvbmx5IHRoZSBsYXR0ZXIsIGFzIHRoZSBzdHJvbmdlciBhbmQg Y29tcGxldGUsIGhhcyBhIHByYWN0aWNhbCB1c2U/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldoYXQg YmVpbmcgdmVyaWZpZWQgLSB0cmF2ZXJzaW5nIFNGIG9yIFNGRj88L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBsaXN0IHdpbGwgZ3Jv dyBhcyB3ZSBsb29rIGludG8gdGhlIHVzZSBjYXNlcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFuZCBvbmUgbW9yZSwgdGhlIHByb3Bv c2VkIHNvbHV0aW9uIGlzIG9ubHkgb25lIG9mIG1hbnkgYWxnb3JpdGhtcy4gSSBiZWxpZXZlIGl0 IHdpbGwgYmUgZnV0dXJlIHByb29mIHRvIGFsbG93IGZvciBvdGhlciBhbGdvcyZuYnNwO3RvIGJl IHVzZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5SZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5HcmVnPC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+T24gVHVlLCBKdW4gNSwgMjAxOCBhdCA3OjA1IEFNLCBKb2VsIE0uIEhhbHBlcm4g PHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+am1oQGpvZWxoYWxwZXJuLmNvbTwv YT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCk15IGltcHJlc3Npb24gb2YgdGhlIGNvbnZlcnNhdGlv biBpbiBMb25kb24gd2FzIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgd2FzIGxlYW5pbmcgdG93YXJk cyBrZWVwaW5nIGJvdGggb2YgdGhlIHByb29mIG9mIHRyYW5zaXQgYWxnb3JpdGhtcy48YnIgY2xh c3M9IiI+DQpPbmUgYmVjYXVzZSBpdCBpcyB2ZXJ5IGVmZmljaWVudCBhbmQgY29uZmlybXMgdGhh dCBlYWNoIFNGIGhhcyBiZWVuIHZpc2l0ZWQsPGJyIGNsYXNzPSIiPg0KYW5kIHRoZSBvdGhlciBi ZWNhdXNlIGFsdGhvdWdoIGl0IGlzIG1vcmUgY29tcGxleCwgaXQgdmVyaWZpZXMgb3JkZXIgb2Yg dmlzaXRpbmcsIHdoaWNoIGlzIGltcG9ydGFudCBpbiBhIHNpZ25pZmljYW50IHN1YnNldCBvZiBj YXNlcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpEbyBmb2xrcyBvbiB0aGUgbGlzdCBh Z3JlZSB3aXRoIHRoYXQgZGlyZWN0aW9uPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCllv dXJzLDxiciBjbGFzcz0iIj4NCkpvZWw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX188d2JyIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19f PGJyIGNsYXNzPSIiPg0Kc2ZjIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5zZmNAaWV0Zi5vcmc8 L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbDx3YnIgY2xhc3M9IiI+aXN0aW5mby9zZmM8L2E+ PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNs YXNzPSIiPg0Kc2ZjIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpz ZmNAaWV0Zi5vcmciIGNsYXNzPSIiPnNmY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyIgY2xhc3M9IiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_E6D83E7510ED4CA1B28712F94D39D731ciscocom_-- From nobody Mon Jun 25 23:10:49 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8154127AC2; Mon, 25 Jun 2018 23:10:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152999344664.2016.15009727348875033146@ietfa.amsl.com> Date: Mon, 25 Jun 2018 23:10:46 -0700 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-hierarchical-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 06:10:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Hierarchical Service Function Chaining (hSFC) Authors : David Dolson Shunsuke Homma Diego R. Lopez Mohamed Boucadair Filename : draft-ietf-sfc-hierarchical-11.txt Pages : 27 Date : 2018-06-25 Abstract: Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration. The goals of hSFC are to make a large-scale network easier to reason about, simpler to control and to support independent functional groups within large network operators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-11 https://datatracker.ietf.org/doc/html/draft-ietf-sfc-hierarchical-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-hierarchical-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 25 23:12:27 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB79130E87; Mon, 25 Jun 2018 23:12:17 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgziWH_KBzUg; Mon, 25 Jun 2018 23:12:15 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2263127AC2; Mon, 25 Jun 2018 23:12:14 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 6C8D560C72; Tue, 26 Jun 2018 08:12:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4F16440058; Tue, 26 Jun 2018 08:12:13 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0399.000; Tue, 26 Jun 2018 08:12:13 +0200 From: To: Benjamin Kaduk CC: The IESG , "draft-ietf-sfc-hierarchical@ietf.org" , Behcet Sarikaya , "sfc-chairs@ietf.org" , "sfc@ietf.org" Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with DISCUSS and COMMENT) Thread-Index: AQHUDMIukAU6KIG30ESWRByKjJsZSKRyD2Rw Date: Tue, 26 Jun 2018 06:12:11 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF4BBD4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152954550322.28624.14636040697546417914.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF49B65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20180622182042.GJ64617@kduck.kaduk.org> <787AE7BB302AE849A7480A190F8B93302DF4B5E3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20180625202157.GI99689@kduck.kaduk.org> In-Reply-To: <20180625202157.GI99689@kduck.kaduk.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 06:12:19 -0000 Hi Benjamin,=20 Deal!=20 I uploaded a new version with the changes discussed in this thread.=20 Thank you very much for engaging and reviewing.=20 Cheers, Med=20 > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > Envoy=E9=A0: lundi 25 juin 2018 22:22 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: The IESG; draft-ietf-sfc-hierarchical@ietf.org; Behcet Sarikaya; s= fc- > chairs@ietf.org; sfc@ietf.org > Objet=A0: Re: Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical-09:= (with > DISCUSS and COMMENT) >=20 > On Mon, Jun 25, 2018 at 02:06:26PM +0000, mohamed.boucadair@orange.com wr= ote: > > Hi Benjamin, > > > > Please see inline. >=20 > This all looks good; just one final note inline >=20 > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > Envoy=E9=A0: vendredi 22 juin 2018 20:21 > > > =C0=A0: BOUCADAIR Mohamed IMT/OLN > > > Cc=A0: The IESG; draft-ietf-sfc-hierarchical@ietf.org; Behcet Sarikay= a; > sfc- > > > chairs@ietf.org; sfc@ietf.org > > > Objet=A0: Re: Benjamin Kaduk's Discuss on draft-ietf-sfc-hierarchical= -09: > (with > > > DISCUSS and COMMENT) > > > > > > > > > On Thu, Jun 21, 2018 at 06:42:11AM +0000, mohamed.boucadair@orange.co= m > wrote: > > > > > > > > > -----Message d'origine----- > > > > > De=A0: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > > > Envoy=E9=A0: jeudi 21 juin 2018 03:45 > > > > > =C0=A0: The IESG > > > > > The approach described in Section 4.1.5 also seems to be incomple= tely > > > > > specified, in that the hSFC Flow ID semantics are not covered at = all. > On > > > > > my initial reading I assumed that this field's encoding and seman= tics > > > were > > > > > intended to be left as entirely local matters to the lower domain= , > > > avoiding > > > > > a need to specify them in this document. > > > > > > > > [Med] The semantic is local to a domain. > > > > > > Agreed, it will not escape a single domain. > > > > > > > However, I'm not sure that it's > > > > > actually true, since we generally want multiple vendors to be abl= e to > > > > > interoperate, > > > > > > > > [Med] Intermediate SFC elements do not need to understand the seman= tic > of > > > flowID. They will handle the flowID as an opaque value. > > > > > > Agreed. I think it might help to call out (as is done in Section 4.1= .1) > > > that if the egress IBN differs from the ingress IBN, there is a need = for > > > state synchronization between those nodes. > > > > [Med] This is the intent of "state replication mentioned in Section 4.1= .1". > > > > I changed the text to "state synchronization mentioned in Section 4.1.1= ". >=20 > Ah, looking at the -10 now I finally see what you are referring to. I > think when I first read "state timeout and replication mentioned in Secti= on > 4.1.1" I did not make the connection that it was specifically the *state* > replication as well. Probably that's just me reading to fast, but I thin= k > your change does increase clarity. >=20 > Thanks again, >=20 > Benjamin From nobody Tue Jun 26 06:33:28 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DB2131030; Tue, 26 Jun 2018 06:33:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-sfc-hierarchical@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, The IESG , Behcet Sarikaya , sarikaya@ieee.org, martin.vigoureux@nokia.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153001999948.1077.2796395207700015749.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2018 06:33:19 -0700 Archived-At: Subject: [sfc] Document Action: 'Hierarchical Service Function Chaining (hSFC)' to Informational RFC (draft-ietf-sfc-hierarchical-11.txt) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 13:33:20 -0000 The IESG has approved the following document: - 'Hierarchical Service Function Chaining (hSFC)' (draft-ietf-sfc-hierarchical-11.txt) as Informational RFC This document is the product of the Service Function Chaining Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ Technical Summary Instead of considering a single SFC control plane that can manage complete service paths from one end of the network to the other, the document adopts an approach that decomposes large networks into smaller domains operated by as many SFC sub-domains (under the same administrative entity). This approach is called: Hierarchical Service Function Chaining (hSFC) The goals of hSFC are to make a large-scale network easier to reason about, simpler to control and to support independent functional groups within large network operators. Working Group Summary Two WGLCs were made for this document. The second one was mainly to confirm that the comments raised during the first call are well addressed. There seems to be consensus in the working group that the document is ready for publication. Document Quality The Document intended status is Informational. There is no known implementation. Personnel Behcet Sarikaya is the Document Shepherd Martin Vigoureux is the Responsible AD From nobody Tue Jun 26 07:56:58 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF60130E93; Tue, 26 Jun 2018 07:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF-4oGWve6vU; Tue, 26 Jun 2018 07:56:55 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E8F124C04; Tue, 26 Jun 2018 07:56:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id AF0CB2E23E7; Tue, 26 Jun 2018 07:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1530025015; bh=TTS0f4OR7CnPTvqURGmP3sLeAKTTtFcuFqoLryKJyMM=; h=Subject:Cc:References:From:Date:In-Reply-To:From; b=joqVjPlmVh9X+/e5tPg6M/yghy/pB9fHlDbuR1tUTiL7ONWYuCR8VZOQShtY2ZDpo 2Kvfp1ElRIpSkivIgUAi0FNux0C6HYfXIuF0VOore9/w3pDwiuIqDXqHI9bW0HLQwy 6bjJJWPNfJ1Z2VJ2T942rgA6KpkKyzxVLB75CGUs= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 045B62E23E9; Tue, 26 Jun 2018 07:56:54 -0700 (PDT) Cc: draft-ietf-sfc-hierarchical@ietf.org, sfc@ietf.org, sarikaya@ieee.org References: <153001999948.1077.2796395207700015749.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <5a552604-d1c7-948d-ced2-b6b1bbba9e6d@joelhalpern.com> Date: Tue, 26 Jun 2018 10:56:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <153001999948.1077.2796395207700015749.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] Document Action: 'Hierarchical Service Function Chaining (hSFC)' to Informational RFC (draft-ietf-sfc-hierarchical-11.txt) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 14:56:58 -0000 Congratulations to the working group and those who worked on the document. My thanks to the authors and shepherd for seeing this through with very good responsiveness to the questions as they were raised. Yours, Joel On 6/26/18 9:33 AM, The IESG wrote: > The IESG has approved the following document: > - 'Hierarchical Service Function Chaining (hSFC)' > (draft-ietf-sfc-hierarchical-11.txt) as Informational RFC > > This document is the product of the Service Function Chaining Working Group. > > The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin > Vigoureux. > > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ > > > > > > Technical Summary > > Instead of considering a single SFC control plane that can manage > complete service paths from one end of the network > to the other, the document adopts an approach that decomposes > large networks into smaller domains operated > by as many SFC sub-domains (under the same administrative entity). > > This approach is called: Hierarchical Service Function Chaining (hSFC) > > The goals of hSFC are to make a large-scale network easier to reason > about, simpler to control and to support independent functional > groups within large network operators. > > Working Group Summary > > Two WGLCs were made for this document. The second one was mainly to confirm that the comments > raised during the first call are well addressed. > > There seems to be consensus in the working group that the document is ready for publication. > > Document Quality > > The Document intended status is Informational. > There is no known implementation. > > Personnel > > Behcet Sarikaya is the Document Shepherd > Martin Vigoureux is the Responsible AD > > From nobody Tue Jun 26 08:24:30 2018 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5869413104E; Tue, 26 Jun 2018 08:24:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153002666235.697.13095391407146000571@ietfa.amsl.com> Date: Tue, 26 Jun 2018 08:24:22 -0700 Archived-At: Subject: [sfc] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to RFC 8300 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 15:24:23 -0000 Dear Paul Quinn, Uri Elzur, Carlos Pignataro: An IPR disclosure that pertains to your RFC entitled "Network Service Header (NSH)" (RFC8300) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3217/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 8300" Thank you IETF Secretariat From nobody Thu Jun 28 13:29:52 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533D21310A0; Thu, 28 Jun 2018 13:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAYB6s6xLH3h; Thu, 28 Jun 2018 13:29:15 -0700 (PDT) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2BCB1292F1; Thu, 28 Jun 2018 13:29:14 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id o26-v6so5526188ljg.3; Thu, 28 Jun 2018 13:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=iCkBa8YwZjf2vStEN7ELJFWll+iZWIzs0fhxGnG08VQ=; b=l5fxlQXnDkmuCqYcoAr/H2utQOgylvwSY5tHF6isnKOJ8CnmUuaHuBvnfEO7Qlt0lx RNUgaCj0NVLl3NNkGEafULkWdeHWW8QSLX7IkwaQzDxEhPL6y21ZSq0WUxCtaJUUy/gp sRxIEzMu50xr2BgPrl4xY7pUuvbuDY3w6Jans5w9xPUnbMrzQr89zZ3JmcU7nBGXI3uk VB78VveIjWFM7z6eFZE3mCvbRDIqT/KtoNQI1AqLQBXTvv5zBZctRrK1FLHd35xgQaAb O0W3OQGZGwP9X3rWlO6+N4IumGf8Ak5SCh38LIgBDIhotgI7et9Pa+Z7oXfPIWgqKAHM 3ChA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=iCkBa8YwZjf2vStEN7ELJFWll+iZWIzs0fhxGnG08VQ=; b=UlQCUi8new6EsFYLUct40RxHHCEAUdzmTvEIh7D/Z4AE7CxMEzWsVDm/+Y0QgiD67S GGiGcYSyPRHEJsewVL6fK7sU6Y/W6kwKSPXb7wc8te3jq4WLdEQY083cJ8OcrTSuM/XL /cXcoPtcziq/DnldvwWRgbU9M1QvPeTEVut0DgHXPfalBA8K7lVnahXdflCWU47nIOut kWuoierEnBifXqoJHTKrhS+GNkv6uyAUsQaOu+P6XT3r4traEdok8gM8R3OTmLX2g7OP PbY2/wspiVE1Zua1cKpF5oQ6pK5c+2rsQNRc5dhnaXDPEDEyVa2Rpndn4M0BgfcMuRo/ i/2g== X-Gm-Message-State: APt69E0M56cyioA5KZyF90gGdRQyKQzXoVXm4i/1vTMLHtzDKwLSX6Nh StQTRh8RcRD6Y9/4RyRi6cTimf00UsFYFuy/U5Y= X-Google-Smtp-Source: AAOMgpfWqVssWS0bhDxI3DjXBuHCO2CjFCuK8NacaskK9KzxwaPhob/0AFptpGkat/hbm7t6d5D/NOTqkxxKSHcB4rg= X-Received: by 2002:a2e:87da:: with SMTP id v26-v6mr7741228ljj.69.1530217752708; Thu, 28 Jun 2018 13:29:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 13:29:12 -0700 (PDT) In-Reply-To: <153014505217.15447.15073934942116107591.idtracker@ietfa.amsl.com> References: <153014505217.15447.15073934942116107591.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Thu, 28 Jun 2018 13:29:12 -0700 Message-ID: To: RTGWG , Service Function Chaining IETF list , NVO3 , BIER WG , int-area@ietf.org, detnet@ietf.org Content-Type: multipart/alternative; boundary="00000000000094523b056fb995b7" Archived-At: Subject: [sfc] Fwd: New Version Notification for draft-mirsky-pim-bfd-p2mp-use-case-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 20:29:18 -0000 --00000000000094523b056fb995b7 Content-Type: text/plain; charset="UTF-8" Dear All, I hope that this new draft will be of interest to those working on overlay encapsulations. Appreciate your comments, questions, and suggestions. Regards, Greg ---------- Forwarded message ---------- From: Date: Wed, Jun 27, 2018 at 5:17 PM Subject: New Version Notification for draft-mirsky-pim-bfd-p2mp-use-case-02.txt To: Gregory Mirsky , Ji Xiaoli A new version of I-D, draft-mirsky-pim-bfd-p2mp-use-case-02.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-pim-bfd-p2mp-use-case Revision: 02 Title: Bidirectional Forwarding Detection (BFD) for Multi-point Networks and Protocol Independent Multicast - Sparse Mode (PIM-SM) Use Case Document date: 2018-06-27 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-mirsky-pim-bfd- p2mp-use-case-02.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-pim-bfd-p2mp- use-case/ Htmlized: https://tools.ietf.org/html/draft-mirsky-pim-bfd-p2mp-use- case-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-pim-bfd- p2mp-use-case Diff: https://www.ietf.org/rfcdiff?url2=draft-mirsky-pim-bfd- p2mp-use-case-02 Abstract: This document discusses the use of Bidirectional Forwarding Detection (BFD) for multi-point networks to provide nodes that participate in Protocol Independent Multicast - Sparse Mode (PIM-SM) with the sub- second convergence. Optional extension to PIM-SM Hello, as specified in RFC 7761, to bootstrap point-to-multipoint BFD session. also defined in this document. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --00000000000094523b056fb995b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
I hope that this new draft will be of intere= st to those working on overlay=C2=A0encapsulations. Appreciate your comment= s, questions, and suggestions.

Regards,
= Greg

---------- Forwarded message = ----------
From: &l= t;internet-drafts@ietf.org&= gt;
Date: Wed, Jun 27, 2018 at 5:17 PM
Subject: New Version No= tification for draft-mirsky-pim-bfd-p2mp-use-case-02.txt
To: Gregory Mir= sky <gregimirsky@gmail.com&= gt;, Ji Xiaoli <ji.xiaoli@zte.co= m.cn>



A new version of I-D, draft-mirsky-pim-bfd-p2mp-use-case-02.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-pim-bfd-p2mp-use= -case
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) for Multi-point Networks and Protocol Independent Multicast - Sparse= Mode (PIM-SM) Use Case
Document date:=C2=A0 2018-06-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mir= sky-pim-bfd-p2mp-use-case-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-pim-bfd-p2mp-use-case/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mirsky-pim-bfd-p2mp-use-case-0= 2
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-pim-bfd-p2mp-use-case
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-pi= m-bfd-p2mp-use-case-02

Abstract:
=C2=A0 =C2=A0This document discusses the use of Bidirectional Forwarding De= tection
=C2=A0 =C2=A0(BFD) for multi-point networks to provide nodes that participa= te in
=C2=A0 =C2=A0Protocol Independent Multicast - Sparse Mode (PIM-SM) with the= sub-
=C2=A0 =C2=A0second convergence.=C2=A0 Optional extension to PIM-SM Hello, = as specified
=C2=A0 =C2=A0in RFC 7761, to bootstrap point-to-multipoint BFD session. als= o
=C2=A0 =C2=A0defined in this document.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--00000000000094523b056fb995b7-- From nobody Thu Jun 28 13:33:12 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8738D1310CF; Thu, 28 Jun 2018 13:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSSwwIogPRXA; Thu, 28 Jun 2018 13:32:31 -0700 (PDT) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A7F1310DD; Thu, 28 Jun 2018 13:32:30 -0700 (PDT) Received: by mail-lf0-x244.google.com with SMTP id y127-v6so5166755lfc.8; Thu, 28 Jun 2018 13:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=vTDr4yTl8FcYScjNNRqG6Z8UU/50iyGPUuldT7pnVlk=; b=qs3Ntq27C+sDRWnd32ExOz24Lu3BUAOuq8xtvIi/vIbtU84D9ALXv53lrJVkxa/jS5 QMrPqjucFlF9yIfZK4/rLL1ACuHAqO/QJsvXncZXmON/uBgsXo1XfaVDoT2BGo4TMlSV iQ53/uW/cm3c+CXeJ7+iPs3TeJpdsglKp+yY0lgBMFoKAIxmlP9BKgd8h6O5wTaccHG3 XAg6t4uxZE7Tfx2qwEWGbTEoYDBnvxoLrn3auNtPx8+mt+e0y/HqsTUjTjGV1v/OFrnH +1RlWHYgYNQ23Sfbb2WyNokvkkYs6Gq6Ki5j3rkVDfmB6AYvwZvCwlmaHtOAwQNW3/VL bqZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=vTDr4yTl8FcYScjNNRqG6Z8UU/50iyGPUuldT7pnVlk=; b=QYnvmlEyXJiWF788tkCEmyaD+2IMRAdEqcgQSN7tL17chu2sI39eZYHhXIqCpFTwbQ +Ls7sTGt1LAdjSCCAgvvRgUpEkUI96eb3hI+iT7bTKWIAMk2fIKuiEvVi5faPa3IFIod +pycm3ndD8fPIiYD2VjS/ZY1LHOlnl/sIGgN4MIPRC0t0v/ftdlYuFZ/i+N76KLRRphA 6+gIQ4mClmqHJI84WpEx0Kq485kUw3hUiYEDuCIkoiCk3r20lAHxbTqqwHsPXSjI8q+4 3tG5KIIBBcpdDiFyDLpH1Uhj2guINtd8K2jZPL+9zwq9VCW3Sftexu65+Xyf6uQe8Mm1 WnlA== X-Gm-Message-State: APt69E2sziZ7JiZOWMZ2aFPunPzmZ5QC3zU+c3ZbNseibogdkmnhMOUV 8vyxPbMHtKd724+jE2UDPd3cnBbcvreE4+Syg+0= X-Google-Smtp-Source: AAOMgpe9o4s3YDXds5mv3MNQAc0J1dq6It40pWK0nPljoCnagy/Xxuy1qNO2PpjWpeXiFZlFSoX0qUorrzeMUtFzK0w= X-Received: by 2002:a19:a111:: with SMTP id k17-v6mr8287813lfe.60.1530217948735; Thu, 28 Jun 2018 13:32:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 13:32:28 -0700 (PDT) In-Reply-To: References: <153014505217.15447.15073934942116107591.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Thu, 28 Jun 2018 13:32:28 -0700 Message-ID: To: RTGWG , Service Function Chaining IETF list , NVO3 , BIER WG , int-area@ietf.org, detnet@ietf.org Content-Type: multipart/alternative; boundary="000000000000437045056fb9a100" Archived-At: Subject: Re: [sfc] New Version Notification for draft-mirsky-pim-bfd-p2mp-use-case-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 20:32:47 -0000 --000000000000437045056fb9a100 Content-Type: text/plain; charset="UTF-8" My sincere apologies, wrong draft :( On Thu, Jun 28, 2018 at 1:29 PM, Greg Mirsky wrote: > Dear All, > I hope that this new draft will be of interest to those working on > overlay encapsulations. Appreciate your comments, questions, and > suggestions. > > Regards, > Greg > > ---------- Forwarded message ---------- > From: > Date: Wed, Jun 27, 2018 at 5:17 PM > Subject: New Version Notification for draft-mirsky-pim-bfd-p2mp-use- > case-02.txt > To: Gregory Mirsky , Ji Xiaoli < > ji.xiaoli@zte.com.cn> > > > > A new version of I-D, draft-mirsky-pim-bfd-p2mp-use-case-02.txt > has been successfully submitted by Greg Mirsky and posted to the > IETF repository. > > Name: draft-mirsky-pim-bfd-p2mp-use-case > Revision: 02 > Title: Bidirectional Forwarding Detection (BFD) for Multi-point > Networks and Protocol Independent Multicast - Sparse Mode (PIM-SM) Use Case > Document date: 2018-06-27 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet- > drafts/draft-mirsky-pim-bfd-p2mp-use-case-02.txt > Status: https://datatracker.ietf.org/ > doc/draft-mirsky-pim-bfd-p2mp-use-case/ > Htmlized: https://tools.ietf.org/html/d > raft-mirsky-pim-bfd-p2mp-use-case-02 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-mirsky-pim-bfd-p2mp-use-case > Diff: https://www.ietf.org/rfcdiff? > url2=draft-mirsky-pim-bfd-p2mp-use-case-02 > > Abstract: > This document discusses the use of Bidirectional Forwarding Detection > (BFD) for multi-point networks to provide nodes that participate in > Protocol Independent Multicast - Sparse Mode (PIM-SM) with the sub- > second convergence. Optional extension to PIM-SM Hello, as specified > in RFC 7761, to bootstrap point-to-multipoint BFD session. also > defined in this document. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > --000000000000437045056fb9a100 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My sincere apologies, wrong draft :(

On Thu, Jun 28, 2018 at 1:29 PM, = Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
I hope that this new dr= aft will be of interest to those working on overlay=C2=A0encapsulations. Ap= preciate your comments, questions, and suggestions.

Regards,
Greg

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date:= Wed, Jun 27, 2018 at 5:17 PM
Subject: New Version Notification for draf= t-mirsky-pim-bfd-p2mp-use-case-02.txt
To: Gregory Mirsky <gregimirsky@gmail.com<= /a>>, Ji Xiaoli <ji.xiaoli@zte.com.cn>



A new version of I-D, draft-mirsky-pim-bfd-p2mp-use-case-02.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-pim-bfd-p2mp-use-case
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) for Multi-point Networks and Protocol Independent Multicast - Sparse= Mode (PIM-SM) Use Case
Document date:=C2=A0 2018-06-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mir= sky-pim-bfd-p2mp-use-case-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-pim-bfd-p2mp-use-case/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mirsky-pim-bfd-p2mp-use-case-0= 2
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-pim-bfd-p2mp-use-case
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-pi= m-bfd-p2mp-use-case-02

Abstract:
=C2=A0 =C2=A0This document discusses the use of Bidirectional Forwarding De= tection
=C2=A0 =C2=A0(BFD) for multi-point networks to provide nodes that participa= te in
=C2=A0 =C2=A0Protocol Independent Multicast - Sparse Mode (PIM-SM) with the= sub-
=C2=A0 =C2=A0second convergence.=C2=A0 Optional extension to PIM-SM Hello, = as specified
=C2=A0 =C2=A0in RFC 7761, to bootstrap point-to-multipoint BFD session. als= o
=C2=A0 =C2=A0defined in this document.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--000000000000437045056fb9a100-- From nobody Thu Jun 28 13:35:45 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C86D1310D7; Thu, 28 Jun 2018 13:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbu5eRc3jOE4; Thu, 28 Jun 2018 13:34:53 -0700 (PDT) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49301310E2; Thu, 28 Jun 2018 13:34:52 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id h2-v6so2300243ljb.10; Thu, 28 Jun 2018 13:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jzcbvJe72CNvFSO/oFXQPAoWSFYLo935tqUnkfLFXjE=; b=EUg8HsufciUYdJ/spyR8NqN9Z3UViNWQUT1Xi2XFW8EeJ7EkB8AAaUD0ZPOCy1aaus MXlaGG6gEoM6K8DqWqojQ3YVUNlG5P6zRnn3C1TIptWFCZ7warSgywIvvkEp/ifkfJGv mHpm1CItyrQqI1nTlLut7xD80yUvpzGVVltKXWran8IqR/SGxjCe8K79hi+kyJbVevkd MJPloJLkofPOQ5Sy6xV26yPc2cKXrJ5ajDX5pzvtjFT0OabpTTZJ4h1DNhUDXwQEo3kF J9piKL2RFSzRF/2dpsLdi9ER/jvOdqzpGNR3759y6ymXltq9M5o/zZaQeNfsw8JsTfoU 874Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jzcbvJe72CNvFSO/oFXQPAoWSFYLo935tqUnkfLFXjE=; b=ois11RUjzgAXSsIUoDlWiTpjKe4kkIHR7kWHWMchjKRj80oftAdudN33c4Gp8lQ9U2 H55CL7NB8tV1IS4B0TnHlsG4Q2lm2T6igLWPjAUD10ICPVExBNLS7bOqda8KZAO6O4k7 eX2sYt1L8yYR4dDFQsZs1aVJLlmHpUQn9pCusukVi80xIkJmcOLmg9SLne2g2sZ02WVF tdOyZQuP04F0rKffWW9KjoY7HiO12vtOLzkNFi9qCYbireoGYPJItHZtrkRCVFjBEAxe PHEj51MaLgLy7Gxwj57ZzfD0GrsMl4UYNQ93vo7MBnMKstns50wC3Uehne6J4KmZczPY igcQ== X-Gm-Message-State: APt69E2MTJN6X/YZMUAColRUByqtIHatsWWDMj+i0nKgk3n6YkRB9oQU Gjsc8gkuO188QxLvViUzrhVyEk6dE3rNDfh6VyrUww== X-Google-Smtp-Source: AAOMgpfoIjByF9offX+tnWgeHW8QtzrGw6smSQxijnT4oeiyIRIa/t7ASKv8oUHIteIOW3pjzB3F4S2XHthp+dJ5frg= X-Received: by 2002:a2e:2161:: with SMTP id h94-v6mr8653391ljh.58.1530218090558; Thu, 28 Jun 2018 13:34:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 13:34:49 -0700 (PDT) In-Reply-To: <153020466705.14520.2646847580748723541.idtracker@ietfa.amsl.com> References: <153020466705.14520.2646847580748723541.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Thu, 28 Jun 2018 13:34:49 -0700 Message-ID: To: rtg-bfd@ietf.org, Service Function Chaining IETF list , NVO3 , BIER WG , detnet@ietf.org, int-area@ietf.org Content-Type: multipart/alternative; boundary="000000000000b779cc056fb9a994" Archived-At: Subject: [sfc] Fwd: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 20:35:10 -0000 --000000000000b779cc056fb9a994 Content-Type: text/plain; charset="UTF-8" Dear All, I hope that this new draft (yes, that's what I wanted to send the first time) will be of interest to those working on overlay encapsulations. Appreciate your comments, questions, and suggestions. Regards, Greg ---------- Forwarded message ---------- From: Date: Thu, Jun 28, 2018 at 9:51 AM Subject: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt To: Gregory Mirsky A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-rtgwg-oam-identify Revision: 00 Title: Identification of Overlay Operations, Administration, and Maintenance (OAM) Document date: 2018-06-28 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-mirsky-rtgwg-oam- identify-00.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-rtgwg-oam- identify/ Htmlized: https://tools.ietf.org/html/draft-mirsky-rtgwg-oam- identify-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-rtgwg- oam-identify Abstract: This document analyzes how the presence of Operations, Administration, and Maintenance (OAM) control command and/or special data is identified in some overlay networks, and an impact on the choice of identification may have on OAM functionality. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000b779cc056fb9a994 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
I hope that this new dra= ft (yes, that's what I wanted to send the first time) will be of intere= st to those working on overlay=C2=A0encapsulations. Appreciate your comment= s, questions, and suggestions.

Re= gards,
Greg

---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
D= ate: Thu, Jun 28, 2018 at 9:51 AM
Subject: New Version Notification for = draft-mirsky-rtgwg-oam-identify-00.txt
To: Gregory Mirsky <gregimirsky@gmail.com>


A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-rtgwg-oam-i= dentify
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Identification of Overlay Operatio= ns, Administration, and Maintenance (OAM)
Document date:=C2=A0 2018-06-28
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky= -rtgwg-oam-identify-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-rtgwg-oam-ide= ntify/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-mirsky-rtgwg-oam-identify-00<= br> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-rtgwg-oam= -identify


Abstract:
=C2=A0 =C2=A0This document analyzes how the presence of Operations,
=C2=A0 =C2=A0Administration, and Maintenance (OAM) control command and/or s= pecial
=C2=A0 =C2=A0data is identified in some overlay networks, and an impact on = the
=C2=A0 =C2=A0choice of identification may have on OAM functionality.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--000000000000b779cc056fb9a994-- From nobody Thu Jun 28 14:32:30 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEB41310F2 for ; Thu, 28 Jun 2018 14:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFShsVp-PrUB for ; Thu, 28 Jun 2018 14:32:00 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32E81310DA for ; Thu, 28 Jun 2018 14:31:55 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id h5-v6so6119801qtm.13 for ; Thu, 28 Jun 2018 14:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tRy6VinVZKV5pKf/2VuvRQ8hu2UFQ/RR8hXmx0CqbwU=; b=OGaS4JtlfEiXThHJ3eXrqjv5YBmmdWgdLMaCBTrUu3EEqmGy8R/KPy+kvAdQhnRcHy 8tfAhHRFZ704I4eY7ZFpYP6orHqgSjGr59FWQLkXLIYhcQrjeTcaoEQX3qVkKA+k9uge u+ZGD+apAWX9J7PA1zdw+6snz+MJIUOkYw33jkMlc5SUR+/ItU1e2K2XWCdIv+3euzH6 yujjxtYvLd9WnSy41AggAuWDC7uQ/O8dPMdKMZdQSyU9cIZSfVX228asDslW/rLngxZi jTrLr4DUInx/Iw/YM9lehLj3hMGMi/eQPmVEhR+jeEOpkk3BVxBAAfc6aR/BfKk7xW9r q+sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tRy6VinVZKV5pKf/2VuvRQ8hu2UFQ/RR8hXmx0CqbwU=; b=slFsn+4k3dEFyYfEbku5hI/UJ47jhErkyxCyMG/6FT5LMVY+eLAGYfEGl3PC8nwt68 B/a2YPIgkFvCaApuet8ntVh9uXOD8oF2U1XQp6hcnRb0Sgz3wYEQuJvNSmURNZLZlo2g GrmsxhGKhMhvLejnFQDQHrrbZh2rNJ7a8Zc9yo+fXGTMObff77qttX/oCqhz7uojJSnS ek3jJoF6NMga5rQWTrkXJwcLu7y9v7WYXnSW+fzNljDqFpGQT0GCgMlM6dLFXT1wnRDp 6sWB0twe8S3vfmpFZ+DSEgW4Gc4MfUwoQHEebfuVVlnKFDyOAaqE09Ppy7htdODj6SgE CObw== X-Gm-Message-State: APt69E2UG4u+xfjAE/7A5f2jJKrnGqiwjExGW6C/Nr8TdBgXOf1BhQYT e9bs2eNz68mesBAAT5OT0l6qAjs3LRa+8JMuxD7cnQ== X-Google-Smtp-Source: AAOMgpeR+1CVMg7EMSfm7YC6AfDS00zsMWo43YvM4zGhdvq0E09juSWZbDHWbaSLHUwQR6VTyMyspRaZaP3dCaqDuLI= X-Received: by 2002:ac8:2393:: with SMTP id q19-v6mr11032977qtq.197.1530221514539; Thu, 28 Jun 2018 14:31:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 14:31:53 -0700 (PDT) In-Reply-To: References: <153020466705.14520.2646847580748723541.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Thu, 28 Jun 2018 14:31:53 -0700 Message-ID: To: Greg Mirsky Cc: rtg-bfd@ietf.org, Service Function Chaining IETF list , NVO3 , BIER WG , detnet@ietf.org, int-area Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sfc] [Int-area] Fwd: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 21:32:11 -0000 On Thu, Jun 28, 2018 at 1:34 PM, Greg Mirsky wrote: > Dear All, > I hope that this new draft (yes, that's what I wanted to send the first > time) will be of interest to those working on overlay encapsulations. > Appreciate your comments, questions, and suggestions. > Regarding OAM in GUE, the C bit can be set to indicate a control packet which could be OAM (draft-ietf-intarea-gue-05). I imagine that OAM could be implement in one or more ctypes. This is considered an alternative to GUE carrying a data protocol payload, it's not considered part of the GUE header and isn't limited by GUE header len. The statement in Geneve description "transit devices MUST NOT attempt to interpret or process it" is true for all UDP encapsulation protocols. The problem is that encapsulation is determined by destination port number. As described in RFC7605, UDP port numbers only have meaning at the endpoints, so transit devices may incorrectly interpret packets as being an encapsulation. Incorrectly reading a packet as encapsulation might be innocuous, but an intermediate node modifying such a packet that it incorrectly believes is an encapsulation would be systematic data corruption. Because of this, probably the only robust method for in-situ OAM is Hop-by-Hop options. Tom > Regards, > Greg > > ---------- Forwarded message ---------- > From: > Date: Thu, Jun 28, 2018 at 9:51 AM > Subject: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt > To: Gregory Mirsky > > > > A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt > has been successfully submitted by Greg Mirsky and posted to the > IETF repository. > > Name: draft-mirsky-rtgwg-oam-identify > Revision: 00 > Title: Identification of Overlay Operations, Administration, and > Maintenance (OAM) > Document date: 2018-06-28 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-mirsky-rtgwg-oam-identify-00.txt > Status: > https://datatracker.ietf.org/doc/draft-mirsky-rtgwg-oam-identify/ > Htmlized: > https://tools.ietf.org/html/draft-mirsky-rtgwg-oam-identify-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-mirsky-rtgwg-oam-identify > > > Abstract: > This document analyzes how the presence of Operations, > Administration, and Maintenance (OAM) control command and/or special > data is identified in some overlay networks, and an impact on the > choice of identification may have on OAM functionality. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From nobody Thu Jun 28 17:28:14 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1550130E3F; Thu, 28 Jun 2018 17:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ansu3Q5VYIAZ; Thu, 28 Jun 2018 17:28:04 -0700 (PDT) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED9B130E37; Thu, 28 Jun 2018 17:28:04 -0700 (PDT) Received: by mail-oi0-x244.google.com with SMTP id 18-v6so6916178oiq.6; Thu, 28 Jun 2018 17:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=i+tQK8bB1+2Qzp0hQrCSCnoDjC4ecws0XJoLt0Bc7uQ=; b=ucrtxM/PD8oB0RIG+6BBlZW2FqaoqTJR8Cbn1Q3cM6+aoNQbj8DAs5kNn4xex968hx IOqcTzcDRq1YyI4JBPTrY8H7wKQmMHy52nf+4rrQf676iNBnNGkPev4wldwAOkYx+Zfi mBEM0K0D6pMwcmPzlQehxSdYZJYyOSX2jxZ7YBxthj+GL6SIKqT5OyPNeLEoS3MIQCn8 wZBqTNGFZWic8ToKcH1E55HjWZEVTe7GUzmShJxlJOX2J2y6rWqm3kTXx9Oqol3fHuqP kNeoMWIaa2+19o57g1/SEzDHFACuWyuh72QoS2OkdqLVDQ82WFkoZfC3Y23WehxcdoIt nQxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=i+tQK8bB1+2Qzp0hQrCSCnoDjC4ecws0XJoLt0Bc7uQ=; b=NjAAowTNRw3GuCsPGQf7IB8Zn9E9MK74xsV36nSBBtX07rMD7PFs2mveuycu4zekdd PjGvdaP+szs1dZEWyvzhzUJpHjcSk21yl5w9la6QMMHRuC8DrKg22vRRHIRbOGJ/gctg Vz5lU3WkKw0l8d/XbeWyjmfLdinKyvD7gax8qPoQiGbhM0fDOYH0lSLa2wAwN8/IEBeZ vNjvpwWNCi7i9WwR5hhZDdeIjPsjeuJqEKU/g1j0D3M+NjiyvwqQXKQBzsdP8dkmMJTL KmCdJhLTAF1B1PzDgHNfNHpaMhFdg6qpsh1oXz9aJ+e/t1kertXaB6Br2WACozn8woTc 7JqA== X-Gm-Message-State: APt69E2RYEh3vin+4yAIr2QkAQublXD1ZBnD+bVubA9AzB49tsHSj7N2 L9mXnNveI7+WoAfqKcFfD/tAW+vKRQbszO0i3oA= X-Google-Smtp-Source: AAOMgpdY4XKbWSWTRdkcCgTYhyNvBJKtAETy22iRFryGOL1L4LmBrCwgIUeDSF1i3CZvvuU2v8wWqgZSdUpEtnf6B4U= X-Received: by 2002:aca:4c0e:: with SMTP id z14-v6mr4404963oia.230.1530232083998; Thu, 28 Jun 2018 17:28:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c3:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 17:27:43 -0700 (PDT) In-Reply-To: <153023172883.18521.11613663353592942727@ietfa.amsl.com> References: <153023172883.18521.11613663353592942727@ietfa.amsl.com> From: "Andrew G. Malis" Date: Thu, 28 Jun 2018 20:27:43 -0400 Message-ID: To: mpls@ietf.org, sfc@ietf.org Content-Type: multipart/alternative; boundary="000000000000ca6aea056fbceb8c" Archived-At: Subject: [sfc] Fwd: I-D Action: draft-malis-mpls-sfc-encapsulation-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 00:28:07 -0000 --000000000000ca6aea056fbceb8c Content-Type: text/plain; charset="UTF-8" This new version addresses comments received to date, moves ECMP considerations to its own section, adds a new OAM considerations section, and adds Wim as a co-author. We have asked to present it in both the MPLS and SFC sessions in Montreal, although we expect the primary discussion to occur in the MPLS session. Cheers, Andy ---------- Forwarded message ---------- From: Date: Thu, Jun 28, 2018 at 8:22 PM Subject: I-D Action: draft-malis-mpls-sfc-encapsulation-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS Encapsulation for SFC NSH Authors : Andrew G. Malis Stewart Bryant Joel M. Halpern Wim Henderickx Filename : draft-malis-mpls-sfc-encapsulation-01.txt Pages : 6 Date : 2018-06-28 Abstract: This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet payload. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and the selection between multiple SFFs in the destination MPLS node. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-malis-mpls-sfc-encapsulation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-malis-mpls-sfc-encapsulation-01 https://datatracker.ietf.org/doc/html/draft-malis-mpls-sfc-encapsulation-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-malis-mpls-sfc-encapsulation-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 --000000000000ca6aea056fbceb8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This new version addresses comments received to date, move= s ECMP considerations to its own section, adds a new OAM considerations sec= tion, and adds Wim as a co-author. We have asked to present it in both the = MPLS and SFC sessions in Montreal, although we expect the primary discussio= n to occur in the MPLS session.

Cheers,
Andy

---------- Forwarded message --------= --
From: <internet-drafts@ietf.org>
Date: Thu, Jun 28, 2018 at 8:22 PM
Subject: I-D Action: draft-mali= s-mpls-sfc-encapsulation-01.txt
To: i-d-announce@ietf.org



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


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= MPLS Encapsulation for SFC NSH
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Andr= ew G. Malis
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Stewart Bryant
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Joel M. Halpern
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Wim Henderickx
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-mal= is-mpls-sfc-encapsulation-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-06-28

Abstract:
=C2=A0 =C2=A0This document describes how to use a Service Function Forwarde= r (SFF)
=C2=A0 =C2=A0Label (similar to a pseudowire label or VPN label) to indicate= the
=C2=A0 =C2=A0presence of a Service Function Chaining (SFC) Network Service = Header
=C2=A0 =C2=A0(NSH) between an MPLS label stack and the packet payload.=C2= =A0 This
=C2=A0 =C2=A0allows SFC packets using the NSH to be forwarded between SFFs = over an
=C2=A0 =C2=A0MPLS network, and the selection between multiple SFFs in the =C2=A0 =C2=A0destination MPLS node.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-malis-mpls-sfc-encapsulation/

There are also htmlized versions available at:
https://tools.ietf.org/html/dr= aft-malis-mpls-sfc-encapsulation-01
https://datatracker.ietf.= org/doc/html/draft-malis-mpls-sfc-encapsulation-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdif= f?url2=3Ddraft-malis-mpls-sfc-encapsulation-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/m= ailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html<= /a>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--000000000000ca6aea056fbceb8c-- From nobody Fri Jun 29 10:07:26 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0761130DC7; Fri, 29 Jun 2018 10:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVRCf6Ul7_lc; Fri, 29 Jun 2018 10:06:51 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60AD5124C04; Fri, 29 Jun 2018 10:06:51 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id t21-v6so7860765lji.0; Fri, 29 Jun 2018 10:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Uax7kU/iTVcVDecltNGA8e5ufhBV6xYLSUs2756HY2Y=; b=mNQfSLkcaLsYyLtK9ZiSY4PbCUBUVDTXNazk8F4hZ21/RxJuoInynm68zH1wyQLbAr W3uBW1RVY/5XCT2Wv/zf9AT4vapWoogMHIegqZyJMJPW9KOL1qtjpWbLvafrqW++Hb5I F7Zn9s7XC5g3xXGpnbSAa3r9iRXQx+AO6GRbrFP5cXh9+0YdfL2qFAyvo1EFKF6bWBMT bXEAn+NrGqSG8NfWuqjp7ry3qxvA3qebdUfTlHTllKyWDEKytGkeIIeFAVyoctPpMA+O 2iBtyq+NeIwRA1K2/vCgL//rgTZwK+kGbMOxsB2kSVku8tKK6bGo3pTTMU6TTg2z8CxI +PMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Uax7kU/iTVcVDecltNGA8e5ufhBV6xYLSUs2756HY2Y=; b=nL466wdAIz5Rh6TZXYfPk/4JyVvODkG7nuFYpBLNOkOg+v7+G9V+vQ/aufRpJj5d/v 8xKzeV3/zH9qh1ACpaKmq1twthMxKgbg+RRbVGsGJ9a7L1Y0JIR8vP7yT0V6XX9OprQ0 0W8H6nOqqOS628BPMvBNKx4IWKB+MJHcR1QF6UJoCsYgFzvXAYAaadr5qBJtSalsAN5P /2lVPqvWsAolKKIuxf3wJizbEQxuNxk7jrtOYoV5E7agrzSuK6y7IZb4JyWJjJAWypWV ijl7gs+mNxICcRYrP0h7RRi3lM+hmYxrOalHLkcPxvnQMxIAXIhq33bYKgM7p9U5DbS1 0WTg== X-Gm-Message-State: APt69E0XORuZ5GVFj9jo1J2r1F4v5wof3C0WVTv9VjvQTESKlS7pK6/K c6iudAY33DGjY9l2IYLbR9wCNsAA8sp+PJvVoMU= X-Google-Smtp-Source: ADUXVKJQVnEEnI6Ka0RBCVAtsdEGnJFZs0jM/7nmqkx48EnnGxGXAwPWfCC6/YGDfPSsIYhwiWAhXXwKpz9/6ycoos8= X-Received: by 2002:a2e:c52:: with SMTP id o18-v6mr10571575ljd.72.1530292009554; Fri, 29 Jun 2018 10:06:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:6e08:0:0:0:0:0 with HTTP; Fri, 29 Jun 2018 10:06:48 -0700 (PDT) In-Reply-To: References: <153020466705.14520.2646847580748723541.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Fri, 29 Jun 2018 10:06:48 -0700 Message-ID: To: Tom Herbert Cc: rtg-bfd@ietf.org, Service Function Chaining IETF list , NVO3 , BIER WG , detnet@ietf.org, int-area Content-Type: multipart/alternative; boundary="000000000000a1d950056fcadfd6" Archived-At: Subject: Re: [sfc] [Int-area] Fwd: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 17:06:54 -0000 --000000000000a1d950056fcadfd6 Content-Type: text/plain; charset="UTF-8" Hi Tom, many thanks for taking interest in the topic and helping with details on GUE and OAM. I've reviewed the listed in the draft encapsulations and analyzed how active OAM may be identified in each of the cases. For active OAM to be more useful the test packets must be in-band with the data that is being monitored. For the GUE case, I believe, that means that an OAM test packet will have all the values that characterize the monitored flow that may affect routing the packet with exception of values of C-bit and Proto/ctype field. Regards, Greg On Thu, Jun 28, 2018 at 2:31 PM, Tom Herbert wrote: > On Thu, Jun 28, 2018 at 1:34 PM, Greg Mirsky > wrote: > > Dear All, > > I hope that this new draft (yes, that's what I wanted to send the first > > time) will be of interest to those working on overlay encapsulations. > > Appreciate your comments, questions, and suggestions. > > > > Regarding OAM in GUE, the C bit can be set to indicate a control > packet which could be OAM (draft-ietf-intarea-gue-05). I imagine that > OAM could be implement in one or more ctypes. This is considered an > alternative to GUE carrying a data protocol payload, it's not > considered part of the GUE header and isn't limited by GUE header len. > > The statement in Geneve description "transit devices MUST NOT attempt > to interpret or process it" is true for all UDP encapsulation > protocols. The problem is that encapsulation is determined by > destination port number. As described in RFC7605, UDP port numbers > only have meaning at the endpoints, so transit devices may incorrectly > interpret packets as being an encapsulation. Incorrectly reading a > packet as encapsulation might be innocuous, but an intermediate node > modifying such a packet that it incorrectly believes is an > encapsulation would be systematic data corruption. Because of this, > probably the only robust method for in-situ OAM is Hop-by-Hop options. > > Tom > > > > > > Regards, > > Greg > > > > ---------- Forwarded message ---------- > > From: > > Date: Thu, Jun 28, 2018 at 9:51 AM > > Subject: New Version Notification for draft-mirsky-rtgwg-oam- > identify-00.txt > > To: Gregory Mirsky > > > > > > > > A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt > > has been successfully submitted by Greg Mirsky and posted to the > > IETF repository. > > > > Name: draft-mirsky-rtgwg-oam-identify > > Revision: 00 > > Title: Identification of Overlay Operations, Administration, and > > Maintenance (OAM) > > Document date: 2018-06-28 > > Group: Individual Submission > > Pages: 9 > > URL: > > https://www.ietf.org/internet-drafts/draft-mirsky-rtgwg-oam- > identify-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-mirsky-rtgwg-oam-identify/ > > Htmlized: > > https://tools.ietf.org/html/draft-mirsky-rtgwg-oam-identify-00 > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-mirsky-rtgwg-oam-identify > > > > > > Abstract: > > This document analyzes how the presence of Operations, > > Administration, and Maintenance (OAM) control command and/or special > > data is identified in some overlay networks, and an impact on the > > choice of identification may have on OAM functionality. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > > --000000000000a1d950056fcadfd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,
many thanks for taking interest in the topic a= nd helping with details on GUE and OAM. I've reviewed the listed in the= draft encapsulations and analyzed how active OAM may be identified in each= of the cases. For active OAM to be more useful the test packets must be in= -band with the data that is being monitored. For the GUE case, I believe, t= hat means that an OAM test packet will have all the values that characteriz= e the monitored flow that may=C2=A0affect routing the packet with exception= of values of C-bit and Proto/ctype=C2=A0field.=C2=A0

<= div>Regards,
Greg

On Thu, Jun 28, 2018 at 2:31 PM, Tom Herbert <tom@= herbertland.com> wrote:
On Thu, Jun 28, 2018 at 1:34 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
> Dear All,
> I hope that this new draft (yes, that's what I wanted to send the = first
> time) will be of interest to those working on overlay encapsulations.<= br> > Appreciate your comments, questions, and suggestions.
>

Regarding OAM in GUE, the C bit can be set to indicate a control
packet which could be OAM (draft-ietf-intarea-gue-05). I imagine that
OAM could be implement in one or more ctypes. This is considered an
alternative to GUE carrying a data protocol payload, it's not
considered part of the GUE header and isn't limited by GUE header len.<= br>
The statement in Geneve description "transit devices MUST NOT attempt<= br> to interpret or process it" is true for all UDP encapsulation
protocols. The problem is that encapsulation is determined by
destination port number. As described in RFC7605, UDP port numbers
only have meaning at the endpoints, so transit devices may incorrectly
interpret packets as being an encapsulation. Incorrectly reading a
packet as encapsulation might be innocuous, but an intermediate node
modifying such a packet that it incorrectly believes is an
encapsulation would be systematic data corruption. Because of this,
probably the only robust method for in-situ OAM is Hop-by-Hop options.

Tom




> Regards,
> Greg
>
> ---------- Forwarded message ----------
> From: <internet-drafts@= ietf.org>
> Date: Thu, Jun 28, 2018 at 9:51 AM
> Subject: New Version Notification for draft-mirsky-rtgwg-oam-iden= tify-00.txt
> To: Gregory Mirsky <gregim= irsky@gmail.com>
>
>
>
> A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt
> has been successfully submitted by Greg Mirsky and posted to the
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-rtgwg-oam-<= wbr>identify
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Identification of Overlay Ope= rations, Administration, and
> Maintenance (OAM)
> Document date:=C2=A0 2018-06-28
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
> URL:
> https://www.ietf.org= /internet-drafts/draft-mirsky-rtgwg-oam-identify-00.txt
> Status:
> https://datatracker.ietf.org/<= wbr>doc/draft-mirsky-rtgwg-oam-identify/
> Htmlized:
> https://tools.ietf.org/html/= draft-mirsky-rtgwg-oam-identify-00
> Htmlized:
> https://datatracker.ietf.o= rg/doc/html/draft-mirsky-rtgwg-oam-identify
>
>
> Abstract:
>=C2=A0 =C2=A0 This document analyzes how the presence of Operations, >=C2=A0 =C2=A0 Administration, and Maintenance (OAM) control command and= /or special
>=C2=A0 =C2=A0 data is identified in some overlay networks, and an impac= t on the
>=C2=A0 =C2=A0 choice of identification may have on OAM functionality. >
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>
>
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-ar= ea
>

--000000000000a1d950056fcadfd6-- From nobody Sat Jun 30 23:56:50 2018 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18812130F17; Sat, 30 Jun 2018 23:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q98jKsYKYquE; Sat, 30 Jun 2018 23:56:45 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641E1130F01; Sat, 30 Jun 2018 23:56:45 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id r17-v6so9572112edo.13; Sat, 30 Jun 2018 23:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RNOp1K7XGzw8XOQdX+IG9cIl8fC0oZYwxyV8alLrBwg=; b=LckVqgLdo0eHgnfUA3Gd/NdqrvrrRHHABY25sMVFccaYULTAQpmhLfCB3ONsk83ezh JKeJF+eBXz2setiYSPxVzfrfYwWdKuRs+4s+3jgsVUO7R2uNBzi5AjOxD8D/fcBgoXR5 aGM08n1RWkO7e5VQT9D7aprGhgXzg4rc4hfDsT7b1ewbUXdkyK+JCUFCdZCuhn1OgRtk nlgMOpUeTVw47s2LB0xr3VFg2mG8qXWFgn43TgXuo3pMHsMjlWNAS0j54ax4zv7dHv5j SdD08ZSZa2PonW/jD5kvnyswvS8zLvulLYnRVePipDyhKc3830vhY9zz8w5fgIMcG7B+ cxGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RNOp1K7XGzw8XOQdX+IG9cIl8fC0oZYwxyV8alLrBwg=; b=razvMbnSP3By3jCWUAWyDvey4VOe89O0LfPPV8Fwy+oHSEFBNy8t0P9NREVu3Eh4iG Tnn+NVtmYekvvnb4zAEJ0rioMmeUKYdsNiU7r+9a62HGtkLk37y8YAZMFP+3bvtPmuf/ 155oCagMqoUHenwj7pQDP8Ym0GpQEYGez4cASgt+0QVEIaTXpKODxZEK2yFrVx6e4j55 Qoiia/3S1pN+hHZ6/Ejz4lTJnWxzXHByHJdn5VlzPw2TLhaLx/MOhZyETr5UTvITrqJi 4VKWXQAmNggm6TC0EhSOQRNHSB/n7IiArNpcItroy39knBJPR1+GzzLx9hSbX4gUAJ0/ 0G9Q== X-Gm-Message-State: APt69E13m8Eiv22SuzsrGh//GGsupNEpAVmlT85jtGODE2S5HzxxdmwN FpduyXf+UHEfvV89NzVpdOQiOsSPdsgGqjRiR/YH/A== X-Google-Smtp-Source: AAOMgpcAj6365Xkp2uoN76yxUGEdBo7+sIZxhxlXBGdXXu2+YUWFjD6LS1WcjeBDiPiL3wzqJWIzgijFF2pyOCEaaMQ= X-Received: by 2002:a50:b4a1:: with SMTP id w30-v6mr19124158edd.254.1530428203727; Sat, 30 Jun 2018 23:56:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a50:a9c2:0:0:0:0:0 with HTTP; Sat, 30 Jun 2018 23:56:43 -0700 (PDT) From: Tal Mizrahi Date: Sun, 1 Jul 2018 09:56:43 +0300 Message-ID: To: sfc@ietf.org, sfc-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000006ffdb5056fea950a" Archived-At: Subject: [sfc] IETF 102 SFC - Draft Agenda X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 06:56:49 -0000 --0000000000006ffdb5056fea950a Content-Type: text/plain; charset="UTF-8" Hi, A draft agenda of the SFC session has been uploaded: https://datatracker.ietf.org/meeting/102/materials/agenda-102-sfc-00 If you have any comments or requests, please let us know ( sfc-chairs@ietf.org). Cheers, Tal. --0000000000006ffdb5056fea950a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

A draft agenda of = the SFC session has been uploaded:

I= f you have any comments or requests, please let us know (sfc-chairs@ietf.org).

Che= ers,
Tal.
--0000000000006ffdb5056fea950a--