From nobody Fri Feb 2 09:35:02 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 00CDB129C5D; Fri, 2 Feb 2018 09:34:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-farrel-sfc-convent@ietf.org, Tal Mizrahi , sfc-chairs@ietf.org, tal.mizrahi.phd@gmail.com, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.71.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151759289599.1342.15363054759260139160.idtracker@ietfa.amsl.com> Date: Fri, 02 Feb 2018 09:34:55 -0800 Archived-At: Subject: [sfc] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-farrel-?= =?utf-8?q?sfc-convent-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 17:34:56 -0000 Mirja Kühlewind has entered the following ballot position for draft-farrel-sfc-convent-05: 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-farrel-sfc-convent/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This spec enables an SC node to create new packets and therefore must provide congestion control consideration to avoid network overload from these packets, e.g. in the simplest case requiring a maximal sending rate/minimal time interval between to packets. I also requested an additional TSV-ART review for further feedback and recommendations for a potential solution. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think this document should update RFC8300 as it does not only register an new protocol but also changes some of the process for this specific case. From nobody Fri Feb 2 10:26:01 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 C29CD1252BA; Fri, 2 Feb 2018 10:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 T24dHMb-ydli; Fri, 2 Feb 2018 10:25:52 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951BD126BF6; Fri, 2 Feb 2018 10:25:51 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id w12IPn8s032620; Fri, 2 Feb 2018 18:25:49 GMT Received: from 950129200 ([193.57.120.177]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id w12IPlIR032603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Feb 2018 18:25:48 GMT Reply-To: From: "Adrian Farrel" To: "'Mirja Kuehlewind \(IETF\)'" Cc: , , , , References: <151759289599.1342.15363054759260139160.idtracker@ietfa.amsl.com> <1bce8bb3c4ac4dcd901f0da1c2950fcc@BLUPR05MB370.namprd05.prod.outlook.com> In-Reply-To: <1bce8bb3c4ac4dcd901f0da1c2950fcc@BLUPR05MB370.namprd05.prod.outlook.com> Date: Fri, 2 Feb 2018 18:25:47 -0000 Message-ID: <002e01d39c53$40045240$c00cf6c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNaOpuO90dzvAyd/+cEP7WPMdxW0wGNyEWaoHe/zCA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.2.0.1013-23638.001 X-TM-AS-Result: No--8.330-10.0-31-10 X-imss-scan-details: No--8.330-10.0-31-10 X-TMASE-MatchedRID: 8+bhjh9TQnGnykMun0J1wgPZZctd3P4BC/ExpXrHizxnnK6mXN72m2sk psLNM/2rbgtklEfqWvlRVLWpLTooRoe/o1zWuGFvHcQQBuf4ZFuiNCtus+nPOjVeBpP/c9O+Qlv dvkPwTXIuZRjmVNgAB8wwLFGcU8LI2X53LeVAc3H0hv/rD7WVZOTWKSbLQnNIVv+3DNSQobM5d9 n04fLNZqNseLbbxlNlOdSnoEAYEulzDgxKJu7runBRIrj8R47FYQXxsZnRwoJct5jgLX72gAtm3 +L0ARguKx7t9oB8L4k54gMEYqqxwYT+apTPNzhsBu2zRCSrLjZmfspe4MClvpS9f9yLlOOyArfw hXClRwksE0Xi959Y5pGTpe1iiCJqT6cNbCp0hFwLbigRnpKlKWxlRJiH4397W5Zjq0LB5+fEghg wQjUw9ipASw+3yT7iwy2qpPVqcbP50fenSUXXlQ== Archived-At: Subject: Re: [sfc] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-farr?= =?iso-8859-1?q?el-sfc-convent-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 18:25:55 -0000 Hi Mirja, Thanks for the review. >From the Discuss... > This spec enables an SC node to create new packets and therefore must provide > congestion control consideration to avoid network overload from these packets, > e.g. in the simplest case requiring a maximal sending rate/minimal time > interval between to packets. You say "consideration" and not "mechanism" and that sounds about right. I think we should require rate-limiting on transmission and also on receipt/forwarding. At 30,000 foot we should look at this like ICMP, so rate limits are reasonable. I am slightly worried that an application here might be OAM (although that is still open for debate in the WG) and so rate limiting might be counter-productive. Consider, if you will, BFD. There *is* rate limiting in BFD, but the rate may be pretty fast. Anyway, if we construct some text that advises implementations: - why to rate limit - how to rate limit - what rates may be appropriate would you review it for us? For the Comment... > I think this document should update RFC8300 as it does not only register an new > protocol but also changes some of the process for this specific case. I am not going to get between the IESG and its regular discussion of what an "update" is ;-) Once upon a time "B updates A" meant you cannot implement A without also implementing B. It was not my intention that anything in this spec changed the behaviour of an implementation of 8300. If we have inadvertently made that happen, could you point it out so we can fix it. Thanks, Adrian From nobody Fri Feb 2 12:15: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 1C9FD124BAC for ; Fri, 2 Feb 2018 12:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 f99fwExtfat8 for ; Fri, 2 Feb 2018 12:15:03 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FBBF1200C5 for ; Fri, 2 Feb 2018 12:15:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=PYCDEXssbiu7ShkTTVPzwrPI1lhbNkFWFBAziaMmFAEk2EK3mYVTZixMdTGVbKQniFZPupW+r6sNub7cwreidCny1ANVMc0G9qs7yqgfAw5pU8CD2nsJuY3h/6/LFLLECDIXRyrrN4c70wyWL5OTBBlmjCnCKg5ar+6xpivVcjc=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 11622 invoked from network); 2 Feb 2018 21:15:00 +0100 Received: from i577bce83.versanet.de (HELO ?192.168.178.33?) (87.123.206.131) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Feb 2018 21:15:00 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <002e01d39c53$40045240$c00cf6c0$@olddog.co.uk> Date: Fri, 2 Feb 2018 21:14:58 +0100 Cc: iesg@ietf.org, draft-farrel-sfc-convent@ietf.org, sfc-chairs@ietf.org, tal.mizrahi.phd@gmail.com, sfc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <361D51F5-EEEE-4735-A371-92252AE55FEA@kuehlewind.net> References: <151759289599.1342.15363054759260139160.idtracker@ietfa.amsl.com> <1bce8bb3c4ac4dcd901f0da1c2950fcc@BLUPR05MB370.namprd05.prod.outlook.com> <002e01d39c53$40045240$c00cf6c0$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180202201500.11613.99726@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [sfc] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-farrel?= =?utf-8?q?-sfc-convent-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 20:15:05 -0000 Hi Adrian, > Am 02.02.2018 um 19:25 schrieb Adrian Farrel : >=20 > Hi Mirja,=20 >=20 > Thanks for the review. >=20 > =46rom the Discuss... >=20 >> This spec enables an SC node to create new packets and therefore must = provide >> congestion control consideration to avoid network overload from these = packets, >> e.g. in the simplest case requiring a maximal sending rate/minimal = time >> interval between to packets. >=20 > You say "consideration" and not "mechanism" and that sounds about = right. >=20 > I think we should require rate-limiting on transmission and also on > receipt/forwarding. >=20 > At 30,000 foot we should look at this like ICMP, so rate limits are = reasonable. >=20 > I am slightly worried that an application here might be OAM (although = that is > still open for debate in the WG) and so rate limiting might be > counter-productive. >=20 > Consider, if you will, BFD. There *is* rate limiting in BFD, but the = rate may be > pretty fast. >=20 > Anyway, if we construct some text that advises implementations: > - why to rate limit > - how to rate limit > - what rates may be appropriate > would you review it for us? Yes to all of this. >=20 > For the Comment... >=20 >> I think this document should update RFC8300 as it does not only = register an > new >> protocol but also changes some of the process for this specific case. >=20 > I am not going to get between the IESG and its regular discussion of = what an > "update" is ;-) > Once upon a time "B updates A" meant you cannot implement A without = also > implementing B. > It was not my intention that anything in this spec changed the = behaviour of an > implementation of 8300. If we have inadvertently made that happen, = could you > point it out so we can fix it. Yes, this was more a comment for the AD. However, it is still not true = that =E2=80=9Eupdates=E2=80=9C means =E2=80=9Emust implement=E2=80=9C, = maybe =E2=80=9Emust read=E2=80=9C or =E2=80=9Emust have a look at to = figure out if it should be implemented as well=E2=80=9C. But I also have = to say it's on my todo for a while to write draft for clarification = here, so I take all the blame. However, this is also just a comment, so = one opinion that does not need to be addressed. Mirja >=20 > Thanks, > Adrian >=20 From nobody Fri Feb 2 12:32: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 84C7612D77C for ; Fri, 2 Feb 2018 12:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 CKg1eDjvGs86 for ; Fri, 2 Feb 2018 12:32:15 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F581200C5 for ; Fri, 2 Feb 2018 12:32:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=S1OmhvsTFzyd6CyZpN1g2Z3lK5L7Tgy/MQtRt4YP7FA2LHaIvLcEW2fdneBncA3aAhtK39+2hN1OYP7oAiRrBTU7J6/mVdrdM8Y0JJ23kFuWbeE9hh3uvjKpactpF+16RbUdyGFOeiMWDuoCgto0S2TMelUjSvSqEfZXVHfWDak=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 11992 invoked from network); 2 Feb 2018 21:25:32 +0100 Received: from i577bce83.versanet.de (HELO ?192.168.178.33?) (87.123.206.131) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 Feb 2018 21:25:30 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <361D51F5-EEEE-4735-A371-92252AE55FEA@kuehlewind.net> Date: Fri, 2 Feb 2018 21:25:28 +0100 Cc: draft-farrel-sfc-convent@ietf.org, tal.mizrahi.phd@gmail.com, sfc-chairs@ietf.org, iesg@ietf.org, sfc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3A4BF59C-0C23-46EA-AC59-E76765CB600F@kuehlewind.net> References: <151759289599.1342.15363054759260139160.idtracker@ietfa.amsl.com> <1bce8bb3c4ac4dcd901f0da1c2950fcc@BLUPR05MB370.namprd05.prod.outlook.com> <002e01d39c53$40045240$c00cf6c0$@olddog.co.uk> <361D51F5-EEEE-4735-A371-92252AE55FEA@kuehlewind.net> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180202202531.11982.81214@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [sfc] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-farrel?= =?utf-8?q?-sfc-convent-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 20:32:16 -0000 Forgot to mention that probably a pointer to RFC8085 might also be = helpful. These UDP usage guidelines are probably applicable here as well = and the RFC discusses different cases depending on the traffic model. I = guess 3.1.3 is most relevant but I actually don=E2=80=99t know what = traffic characteristics you are expecting; so maybe addition = discussion/consideration would be needed. Mirja > Am 02.02.2018 um 21:14 schrieb Mirja Kuehlewind (IETF) = : >=20 > Hi Adrian, >=20 >=20 >> Am 02.02.2018 um 19:25 schrieb Adrian Farrel : >>=20 >> Hi Mirja,=20 >>=20 >> Thanks for the review. >>=20 >> =46rom the Discuss... >>=20 >>> This spec enables an SC node to create new packets and therefore = must provide >>> congestion control consideration to avoid network overload from = these packets, >>> e.g. in the simplest case requiring a maximal sending rate/minimal = time >>> interval between to packets. >>=20 >> You say "consideration" and not "mechanism" and that sounds about = right. >>=20 >> I think we should require rate-limiting on transmission and also on >> receipt/forwarding. >>=20 >> At 30,000 foot we should look at this like ICMP, so rate limits are = reasonable. >>=20 >> I am slightly worried that an application here might be OAM (although = that is >> still open for debate in the WG) and so rate limiting might be >> counter-productive. >>=20 >> Consider, if you will, BFD. There *is* rate limiting in BFD, but the = rate may be >> pretty fast. >>=20 >> Anyway, if we construct some text that advises implementations: >> - why to rate limit >> - how to rate limit >> - what rates may be appropriate >> would you review it for us? >=20 > Yes to all of this. >=20 >>=20 >> For the Comment... >>=20 >>> I think this document should update RFC8300 as it does not only = register an >> new >>> protocol but also changes some of the process for this specific = case. >>=20 >> I am not going to get between the IESG and its regular discussion of = what an >> "update" is ;-) >> Once upon a time "B updates A" meant you cannot implement A without = also >> implementing B. >> It was not my intention that anything in this spec changed the = behaviour of an >> implementation of 8300. If we have inadvertently made that happen, = could you >> point it out so we can fix it. >=20 > Yes, this was more a comment for the AD. However, it is still not true = that =E2=80=9Eupdates=E2=80=9C means =E2=80=9Emust implement=E2=80=9C, = maybe =E2=80=9Emust read=E2=80=9C or =E2=80=9Emust have a look at to = figure out if it should be implemented as well=E2=80=9C. But I also have = to say it's on my todo for a while to write draft for clarification = here, so I take all the blame. However, this is also just a comment, so = one opinion that does not need to be addressed. >=20 > Mirja >=20 >=20 >=20 >>=20 >> Thanks, >> Adrian >>=20 >=20 From nobody Tue Feb 6 13:48:54 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 0A00012D886; Tue, 6 Feb 2018 13:48:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: sfc-chairs@ietf.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151795372699.9022.17721549288703171792.idtracker@ietfa.amsl.com> Date: Tue, 06 Feb 2018 13:48:46 -0800 Archived-At: Subject: [sfc] Alvaro Retana's No Objection on charter-ietf-sfc-01-03: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 21:48:47 -0000 Alvaro Retana has entered the following ballot position for charter-ietf-sfc-01-03: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sfc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would like to see milestones added before the final approval. From nobody Tue Feb 6 14:03: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 580EB12D882; Tue, 6 Feb 2018 14:03:12 -0800 (PST) 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, FREEMAIL_FROM=0.001, 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=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 y250u7e2jc1j; Tue, 6 Feb 2018 14:03:10 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 9C88B12D881; Tue, 6 Feb 2018 14:03:10 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id 143so6538903wma.5; Tue, 06 Feb 2018 14:03:10 -0800 (PST) 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; bh=OHJuhYnRBbzM8GdV4Q+aNzWPjs1yPq72BFxHc+C/4TM=; b=TgfsVYP6S3zFiT1ONypM1zWpO6QW6RxTJ25kFySeYSFzU88PvqbSX6Dtg04mlgJFpK 29ERYRYooAtHFoCIYkoc61poz7Wf/3unbvENjUjnv+TqrSxfdDiCWfVOLIvVNJmDzHi7 QN9+aBVJH0Y+s4CifmPZka+WkgOKScfrb6hl7Gy21YZXff9p4OESlr4FK9X+H0h+r4FP IGx9Hotsyi7l9eP95OSNoLzxttzbCEXvAOh1rHekFA5RX+6d+oalkCj9uckd2XIpNkpF fNJm/KgEaCo3hRvCqay5vTna1muX3kiqubxWN0f1oPKZucV7t2KjscWyXnaEkrBMvEKE xkRg== 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; bh=OHJuhYnRBbzM8GdV4Q+aNzWPjs1yPq72BFxHc+C/4TM=; b=GLKcT4nZ3ubgSrp5O/9wcoc9NMDyK3flma4LZU+w0StEPe/dedb0MWe2S7o6K96Oay D+deb3rV0Ne4GYOb/3Z8fWxXAZVGpnvxKtd88Ax8mGjlSeJ5CFSyjZKjJ6hj0bbp8LwS kOOjNct8N1r4FTvcDZPA/etWe1/2AbEs2c/xkIo00u4PgXIwtJR7NBnS76+UhyPOewcy j4Da7Zptr6klfqpEnuzwbToylT75M3yDf30G63bj7fRJA54dz+e8qla9EPX4j6Ke7MZE MzGkpofKqpcx58FZdJeQGEiaekQ6vonWLuKb5uyEz/88PF0r3UlMjkhTuaps7J80tH46 zKLg== X-Gm-Message-State: APf1xPAaN24Bc5BzVIVKxWFOUkXW2cXCor3XmwVzA2Iqn9GnNzxiQ3gb aXsvRjRp+aXNrV7c8eG/acU9vA== X-Google-Smtp-Source: AH8x226L/JxxnrpKPJLEnBxJK2q2XoULnIToBrHrwuc55aZOhbdhWTTXqMWdMx0fEJsNTNvTIgVI/w== X-Received: by 10.80.145.41 with SMTP id e38mr5548797eda.63.1517954588893; Tue, 06 Feb 2018 14:03:08 -0800 (PST) Received: from ?IPv6:2003:74:cf60:d651:1998:df11:51d2:9bbc? (p200300065124C4511998DF1151D29BBC.dip0.t-ipconnect.de. [2003:6:5124:c451:1998:df11:51d2:9bbc]) by smtp.googlemail.com with ESMTPSA id u17sm247900edm.6.2018.02.06.14.03.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 14:03:08 -0800 (PST) To: adrian@olddog.co.uk, "'Mirja Kuehlewind (IETF)'" Cc: draft-farrel-sfc-convent@ietf.org, tal.mizrahi.phd@gmail.com, sfc-chairs@ietf.org, iesg@ietf.org, sfc@ietf.org References: <151759289599.1342.15363054759260139160.idtracker@ietfa.amsl.com> <1bce8bb3c4ac4dcd901f0da1c2950fcc@BLUPR05MB370.namprd05.prod.outlook.com> <002e01d39c53$40045240$c00cf6c0$@olddog.co.uk> From: Martin Stiemerling Message-ID: <0beb0fae-60f0-1b41-1e8a-97e0113edc8f@gmail.com> Date: Tue, 6 Feb 2018 23:03:06 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <002e01d39c53$40045240$c00cf6c0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-farrel?= =?utf-8?q?-sfc-convent-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 22:03:12 -0000 Hi Adrian, Jumping in here, as the TSVART reviewer: The document is good modulo what Mirja mentioned about congestion control: Am 02.02.18 um 19:25 schrieb Adrian Farrel: [...] > > Consider, if you will, BFD. There *is* rate limiting in BFD, but the rate may be > pretty fast. > > Anyway, if we construct some text that advises implementations: > - why to rate limit > - how to rate limit > - what rates may be appropriate > would you review it for us? and it is probably explicitly noteworthy that one incoming packet can trigger one (or even multiple ?) new packet which may increase the number of packets related to the incoming flow by a factor of 2. BFD (RFC 5880) might be a good start (but only...) when it comes to text about congestion control, i.e., to make the implementers and operators aware of the issue. However, as you've written the reasons about why, how and what is much better. I can do the review and help with the text. Cheers from Southern Europe ;) Martin From nobody Tue Feb 6 19:18:47 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 9AA70124D37; Tue, 6 Feb 2018 19:18:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-farrel-sfc-convent@ietf.org, Tal Mizrahi , sfc-chairs@ietf.org, tal.mizrahi.phd@gmail.com, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151797352162.25862.18235247183979141834.idtracker@ietfa.amsl.com> Date: Tue, 06 Feb 2018 19:18:41 -0800 Archived-At: Subject: [sfc] Eric Rescorla's No Objection on draft-farrel-sfc-convent-05: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 03:18:42 -0000 Eric Rescorla has entered the following ballot position for draft-farrel-sfc-convent-05: 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-farrel-sfc-convent/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The need to protect the metadata is not modified by this document and forms part of the NSH definition found in [I-D.ietf-sfc-nsh]. Nit: I wouldn't limit this to encryption. If you care about integrity/data origin authentication, then encryption may not supply that, From nobody Wed Feb 7 06:18: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 B8B431200B9; Wed, 7 Feb 2018 06:18:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: sfc-chairs@ietf.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151801309373.4759.1227448902302427901.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 06:18:13 -0800 Archived-At: Subject: [sfc] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charter-?= =?utf-8?q?ietf-sfc-01-03=3A_=28with_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 14:18:14 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-sfc-01-03: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sfc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Maybe s/OAM frameworks/an OAM framework/ From nobody Wed Feb 7 10:07:26 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 3EA78126DFF; Wed, 7 Feb 2018 10:07:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: sfc-chairs@ietf.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151802684521.4889.14790524805570690778.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 10:07:25 -0800 Archived-At: Subject: [sfc] Spencer Dawkins' No Objection on charter-ietf-sfc-01-03: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 18:07:25 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-sfc-01-03: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sfc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- MD-1 is explained (as fixed-length), but MD-2 is not explained in this charter. I'm not sure who is responsible for the determining in this text: "What can be effectively provided, for which scenarios, and how those tools can be provided need to be determined and the tools standardized." Could you rephrase this as active voice? Thank you for including Transport Considerations at the charter level. Should it be obvious to me why the first deliverable is a base set of MD-2 type codes, with MD-1 type codes being pushed off to other drafts? Is there more to this than "we're just going to do variable length to get started"? Is "active, passive, and hybrid OAM" related to the work in IPPM? If so, probably worth adding them to the "will coordinate with" list. From nobody Wed Feb 7 10:19: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 187B412D84D; Wed, 7 Feb 2018 10:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cIYVAw68U-5c; Wed, 7 Feb 2018 10:18:57 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 2F8ED126DED; Wed, 7 Feb 2018 10:18:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 17E5436A9EC; Wed, 7 Feb 2018 10:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1518027537; bh=un8CvPXNsXqYwNe0HA9XZUXfV75sLjP/wSW71pDfu44=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JmGfQ3sRk7lQVFYwl0cyr0pLZrZ3slYa7iyDl6IuPijihgu5e7cLVXMbIvSEkkMFZ xLpJuGWrN/I5X84gNImsGwZLrUYCbNUr9bkmA+/2iKBJ7ssuGMjTBlRI7UQPMklkkc jnJjK5UI/dTn4WgddIfIe1o3+XFUOltdNtZ6Sbek= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6DFB136A96C; Wed, 7 Feb 2018 10:18:56 -0800 (PST) To: Spencer Dawkins , The IESG Cc: sfc-chairs@ietf.org, sfc@ietf.org References: <151802684521.4889.14790524805570690778.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <40cc656b-7a25-fd0d-8f29-4e7ebfee8575@joelhalpern.com> Date: Wed, 7 Feb 2018 13:18:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151802684521.4889.14790524805570690778.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] Spencer Dawkins' No Objection on charter-ietf-sfc-01-03: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 18:18:59 -0000 With regard to your question about MD-2 Types and MD-1 definitions, the difference is tha tthe base MD-2 types document is standards track. The MD-1 documents are informational. Thus, as chair I expect the WG to put more energy into the standards track document. Yours, Joel On 2/7/18 1:07 PM, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > charter-ietf-sfc-01-03: 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.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-sfc/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > MD-1 is explained (as fixed-length), but MD-2 is not explained in this charter. > > I'm not sure who is responsible for the determining in this text: > > "What can be effectively provided, for which scenarios, > and how those tools can be provided need to be determined and the tools > standardized." > > Could you rephrase this as active voice? > > Thank you for including Transport Considerations at the charter level. > > Should it be obvious to me why the first deliverable is a base set of MD-2 type > codes, with MD-1 type codes being pushed off to other drafts? Is there more to > this than "we're just going to do variable length to get started"? > > Is "active, passive, and hybrid OAM" related to the work in IPPM? If so, > probably worth adding them to the "will coordinate with" list. > > > From nobody Wed Feb 7 10: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 A859D1270B4; Wed, 7 Feb 2018 10:24:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-farrel-sfc-convent@ietf.org, Tal Mizrahi , sfc-chairs@ietf.org, tal.mizrahi.phd@gmail.com, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151802786968.4755.12217489948381879097.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 10:24:29 -0800 Archived-At: Subject: [sfc] Kathleen Moriarty's No Objection on draft-farrel-sfc-convent-05: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 18:24:30 -0000 Kathleen Moriarty has entered the following ballot position for draft-farrel-sfc-convent-05: 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-farrel-sfc-convent/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the security considerations, I think these look good for what this document should address adding the possible considerations for metadata only NSH. Integrity protection, authentication and other things lacking in SFC and NSH should be addressed in other documents (and it's sadly not, but this isn't the document for that). From nobody Wed Feb 7 19:13:49 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 1459E12AF6E; Wed, 7 Feb 2018 19:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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 hY4fE5Ob23C3; Wed, 7 Feb 2018 19:13:42 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 CF08D129C6B; Wed, 7 Feb 2018 19:13:41 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id x62so1643928ywg.11; Wed, 07 Feb 2018 19:13:41 -0800 (PST) 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=AQuKkxof3UjMCwq5ZqsoYGct6s9tVcVebIOY8aqouzk=; b=f+dzq+LbQSHEFVO0/UDZa7SLzHavDzh7eR1NIhNJk14I6Ml44FdiMcDXZ/NxtErup8 myOnzJliiNysNdeVmkJLaUP1RD4KncPnrXdeza060yc2n8KCiqc7zd/jBBCrsYPaRRuV cpTDETEJOCiFgWO4wrk608sSFNp2YP/STv4GQYGttpvPFA/xWr8HC2HjCdHr0nse/Oz5 GfNmTSOHUr0RcwcJf4+NlwWUF4GBVXqnvUyQ19TFYAuzAUBxlb97BPPbNmX2GKrYrSnj ZEvsR2/xNmnYam8zvQvGY1nAkGU+nmsc4pzGgqgCd/GnDt5EakjuE5e4BTxmtsrFkSXQ YPug== 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=AQuKkxof3UjMCwq5ZqsoYGct6s9tVcVebIOY8aqouzk=; b=JWVReN17tlULQIy5BfsBHYIMvaCBPTlvZiHxcfJ/ndqdwAJPNJuNd9rx2vdq1bHS2+ g49xV3nt0EAtNQwFIV2vCoKLgb9X0/Uoqx9cAcMhWVjE7bGR1Q26gj5o4r2AENL80O14 3HwoXqN5gnojWJVVrvgrAckIxntTZnNIsptWtN54GNlrplM+jC0aEfMEySXt/uPajmCa 3OUo7YpZnzUjg4vXBA1Lhv0dkGBe7SpY28mMt96P7uV7OouWQXetfj46Qpl+RFbV0UI7 78t9mM0B+VtlIi1fT1erzeOJux3qL1/iw9c/bJYKpYJiFViTwr+KGhFIM+dngxCMIceK MK9w== X-Gm-Message-State: APf1xPD6ONZwzMY108U1Ai4gj2nku7qAoo+d26soUOvCtDLF934Z6hy8 REKtJmhDYpPfKaRRWsnyKOoyUDjui4BvSx7pJjs= X-Google-Smtp-Source: AH8x2251/5+Ac60B/JgWsgU55NwFav89X9q+6yUPevvRGL05n1Saok4q1WzBsAccnek5Sp+TRimw6Qw4wH2iGQ+OP3M= X-Received: by 10.37.133.69 with SMTP id f5mr5750422ybn.54.1518059620702; Wed, 07 Feb 2018 19:13:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.21.201 with HTTP; Wed, 7 Feb 2018 19:13:40 -0800 (PST) In-Reply-To: <40cc656b-7a25-fd0d-8f29-4e7ebfee8575@joelhalpern.com> References: <151802684521.4889.14790524805570690778.idtracker@ietfa.amsl.com> <40cc656b-7a25-fd0d-8f29-4e7ebfee8575@joelhalpern.com> From: Spencer Dawkins at IETF Date: Wed, 7 Feb 2018 21:13:40 -0600 Message-ID: To: "Joel M. Halpern" Cc: The IESG , sfc-chairs@ietf.org, Service Function Chaining IETF list Content-Type: multipart/alternative; boundary="089e08250e88709f5b0564aacc03" Archived-At: Subject: Re: [sfc] Spencer Dawkins' No Objection on charter-ietf-sfc-01-03: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 03:13:44 -0000 --089e08250e88709f5b0564aacc03 Content-Type: text/plain; charset="UTF-8" Hi, Joel, On Wed, Feb 7, 2018 at 12:18 PM, Joel M. Halpern wrote: > With regard to your question about MD-2 Types and MD-1 definitions, the > difference is tha tthe base MD-2 types document is standards track. The > MD-1 documents are informational. Thus, as chair I expect the WG to put > more energy into the standards track document. > That all makes sense. What I was confused about was that all the MD-1 (fixed-length) definitions are informational - but maybe that's just the way things are? Spencer > > Yours, > Joel > > > On 2/7/18 1:07 PM, Spencer Dawkins wrote: > >> Spencer Dawkins has entered the following ballot position for >> charter-ietf-sfc-01-03: 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.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-sfc/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> MD-1 is explained (as fixed-length), but MD-2 is not explained in this >> charter. >> >> I'm not sure who is responsible for the determining in this text: >> >> "What can be effectively provided, for which scenarios, >> and how those tools can be provided need to be determined and the tools >> standardized." >> >> Could you rephrase this as active voice? >> >> Thank you for including Transport Considerations at the charter level. >> >> Should it be obvious to me why the first deliverable is a base set of >> MD-2 type >> codes, with MD-1 type codes being pushed off to other drafts? Is there >> more to >> this than "we're just going to do variable length to get started"? >> >> Is "active, passive, and hybrid OAM" related to the work in IPPM? If so, >> probably worth adding them to the "will coordinate with" list. >> >> >> >> --089e08250e88709f5b0564aacc03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Joel,

On Wed, Feb 7, 2018 at 12:18 PM, Joel M. Halpern <jmh@joelhalpe= rn.com> wrote:
With regard = to your question about MD-2 Types and MD-1 definitions, the difference is t= ha tthe base MD-2 types document is standards track.=C2=A0 The MD-1 documen= ts are informational.=C2=A0 Thus, as chair I expect the WG to put more ener= gy into the standards track document.

T= hat all makes sense. What I was confused about was that all the MD-1 (fixed= -length) definitions are informational - but maybe that's just the way = things are?

Spencer
=C2=A0

Yours,
Joel


On 2/7/18 1:07 PM, Spencer Dawkins wrote:
Spencer Dawkins has entered the following ballot position for
charter-ietf-sfc-01-03: 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.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf= -sfc/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

MD-1 is explained (as fixed-length), but MD-2 is not explained in this char= ter.

I'm not sure who is responsible for the determining in this text:

"What can be effectively provided, for which scenarios,
and how those tools can be provided need to be determined and the tools
standardized."

Could you rephrase this as active voice?

Thank you for including Transport Considerations at the charter level.

Should it be obvious to me why the first deliverable is a base set of MD-2 = type
codes, with MD-1 type codes being pushed off to other drafts? Is there more= to
this than "we're just going to do variable length to get started&q= uot;?

Is "active, passive, and hybrid OAM" related to the work in IPPM?= If so,
probably worth adding them to the "will coordinate with" list.



--089e08250e88709f5b0564aacc03-- From nobody Wed Feb 7 19:19: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 85A1B12AF6E; Wed, 7 Feb 2018 19:18:59 -0800 (PST) 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 (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 c6ovTS6IVvQb; Wed, 7 Feb 2018 19:18:57 -0800 (PST) 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 ADD6F127342; Wed, 7 Feb 2018 19:18:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 96B05A8024C; Wed, 7 Feb 2018 19:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1518059937; bh=yqoAAzyaQhGRv85GdRGFRuIYshNhUH1P4gRBjqrTds8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lvA0fosq8FFHgp350li5sLb55rtfsnQw455oRpkXXrGGzijAM5jV6UkdykBh0AK/P PV0sPIfL328Kwev0X1TBo+25/RsBB6onlYZoGEF7QB9kKW0W4RK6g7yYIzkW3yVwrA sCyL+xGnsg2t38VXx7dvwzPmQcd8ykKCFzY4x7HM= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (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 9D2E9240E56; Wed, 7 Feb 2018 19:18:56 -0800 (PST) To: Spencer Dawkins at IETF Cc: The IESG , sfc-chairs@ietf.org, Service Function Chaining IETF list References: <151802684521.4889.14790524805570690778.idtracker@ietfa.amsl.com> <40cc656b-7a25-fd0d-8f29-4e7ebfee8575@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <67d4741a-bb55-e7d1-5fb4-c28a35027c40@joelhalpern.com> Date: Wed, 7 Feb 2018 22:18:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Spencer Dawkins' No Objection on charter-ietf-sfc-01-03: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 03:19:00 -0000 The MD-1 usage is indeed somewhat unusual. Yes, all the layouts are informational. It is up to deployment and control to make sure that all participants know what layout (or in interesting cases layouts) is being used. There is no layout identification (other than that it is MD-1) in the packet format. Yours, Joel On 2/7/18 10:13 PM, Spencer Dawkins at IETF wrote: > Hi, Joel, > > On Wed, Feb 7, 2018 at 12:18 PM, Joel M. Halpern > wrote: > > With regard to your question about MD-2 Types and MD-1 definitions, > the difference is tha tthe base MD-2 types document is standards > track.  The MD-1 documents are informational.  Thus, as chair I > expect the WG to put more energy into the standards track document. > > > That all makes sense. What I was confused about was that all the MD-1 > (fixed-length) definitions are informational - but maybe that's just the > way things are? > > Spencer > > > Yours, > Joel > > > On 2/7/18 1:07 PM, Spencer Dawkins wrote: > > Spencer Dawkins has entered the following ballot position for > charter-ietf-sfc-01-03: 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.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-sfc/ > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > MD-1 is explained (as fixed-length), but MD-2 is not explained > in this charter. > > I'm not sure who is responsible for the determining in this text: > > "What can be effectively provided, for which scenarios, > and how those tools can be provided need to be determined and > the tools > standardized." > > Could you rephrase this as active voice? > > Thank you for including Transport Considerations at the charter > level. > > Should it be obvious to me why the first deliverable is a base > set of MD-2 type > codes, with MD-1 type codes being pushed off to other drafts? Is > there more to > this than "we're just going to do variable length to get started"? > > Is "active, passive, and hybrid OAM" related to the work in > IPPM? If so, > probably worth adding them to the "will coordinate with" list. > > > > From nobody Wed Feb 7 19:35:38 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 8D4C0126D45; Wed, 7 Feb 2018 19:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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 U6EyDsdCpSxr; Wed, 7 Feb 2018 19:35:33 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 729871200F1; Wed, 7 Feb 2018 19:35:33 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id u21so1684732ywc.2; Wed, 07 Feb 2018 19:35:33 -0800 (PST) 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=wurR6eBecktBgC3Ap74ADFsVvAPsMNCxmKqih+zhmkU=; b=SN8gZxdoW8gxmC4q1isxEyZgH4rtTaveIHkK/SmrP01lhPBlDOaCpi2kdyG12goqJQ fCO7k3AVlh1uNqfyoiAS3Qr616BlANVAiW/QxWJUygeDVRNhmT2wPT7XdbQXvKksw/dj 1KfK8iXM/LvPvFYl1NzU/4enEIytbVW/1Za8uTcbytgh/el5iO6MOvKkWkFJXBOvRwRn KLpYfXnrn60dv2PWTRpvet9R8kocVqjx13W/LzNX3zuX4PrxgU5xawWNaF+P4MqFB7d+ XdlA85eZjZliAZi7ZaIWgF8cTHB08chBXMprJQ8fJLzw0wnhwG2zQq8wZ5JPj91Ec+QG L60A== 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=wurR6eBecktBgC3Ap74ADFsVvAPsMNCxmKqih+zhmkU=; b=jeoQMUaDMWzQoXv0G9YRaXgKfhADdN2okN7+ANQRtpLptfcCDj4YcROhIY5pD/mw7/ eJqT8EskvAN/zd9isix6RPXQCknXh/gTnRoLc8haoiPvdyHb3BIBhqJkYKf64AMwLdR0 L7OBwn2AKGBhm1xM/AeJe/tr5b3GGgNrjsUrePW3FPrliM2+JK7t9AE318hNATIlg4Jn 7zWmkluoBpfeC7RqrKpNa9/9jtHFf573e//iH3y0TJuriPdcQgCSTAjSsxpWiXUNR8tm DAij0eG9Uma+grLnYlIdqiMhH3v/0q0nxChxdRvjX8W1atMkFBohyZ4d1Lo6Y+kHdkkm 1QLw== X-Gm-Message-State: APf1xPC2n6vg9YYymaMi9YSdm/xZQsTmEv4+nvZOtWBheePieLrYiSfd Wt8+/IxbLZMrVta8IA2pFI0K9IpYDiVEeEp+8Pc= X-Google-Smtp-Source: AH8x224tOcu5zw4Xpwkg2ogCSSTttfKzepPd9EyzI2V7lYUf9fmmWzJXLtJU2t/weUjPlrA+R+NZG9K+nZQc31wSCYs= X-Received: by 10.129.87.2 with SMTP id l2mr5484288ywb.454.1518060932256; Wed, 07 Feb 2018 19:35:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.21.201 with HTTP; Wed, 7 Feb 2018 19:35:31 -0800 (PST) In-Reply-To: <67d4741a-bb55-e7d1-5fb4-c28a35027c40@joelhalpern.com> References: <151802684521.4889.14790524805570690778.idtracker@ietfa.amsl.com> <40cc656b-7a25-fd0d-8f29-4e7ebfee8575@joelhalpern.com> <67d4741a-bb55-e7d1-5fb4-c28a35027c40@joelhalpern.com> From: Spencer Dawkins at IETF Date: Wed, 7 Feb 2018 21:35:31 -0600 Message-ID: To: "Joel M. Halpern" Cc: The IESG , sfc-chairs@ietf.org, Service Function Chaining IETF list Content-Type: multipart/alternative; boundary="001a113a3c4e9d5b5f0564ab1a84" Archived-At: Subject: Re: [sfc] Spencer Dawkins' No Objection on charter-ietf-sfc-01-03: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 03:35:36 -0000 --001a113a3c4e9d5b5f0564ab1a84 Content-Type: text/plain; charset="UTF-8" Hi, Joel, On Wed, Feb 7, 2018 at 9:18 PM, Joel M. Halpern wrote: > The MD-1 usage is indeed somewhat unusual. > Yes, all the layouts are informational. > > It is up to deployment and control to make sure that all participants know > what layout (or in interesting cases layouts) is being used. There is no > layout identification (other than that it is MD-1) in the packet format. > It sounds like https://thenewstack.io/not-expected-understand-explainer/ applies, but I'm OK with that :-) Thanks for your help in understanding what's going on here. Spencer > Yours, > Joel > > On 2/7/18 10:13 PM, Spencer Dawkins at IETF wrote: > >> Hi, Joel, >> >> >> On Wed, Feb 7, 2018 at 12:18 PM, Joel M. Halpern > > wrote: >> >> With regard to your question about MD-2 Types and MD-1 definitions, >> the difference is tha tthe base MD-2 types document is standards >> track. The MD-1 documents are informational. Thus, as chair I >> expect the WG to put more energy into the standards track document. >> >> >> That all makes sense. What I was confused about was that all the MD-1 >> (fixed-length) definitions are informational - but maybe that's just the >> way things are? >> >> Spencer >> >> >> Yours, >> Joel >> >> >> On 2/7/18 1:07 PM, Spencer Dawkins wrote: >> >> Spencer Dawkins has entered the following ballot position for >> charter-ietf-sfc-01-03: 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.) >> >> >> >> The document, along with other ballot positions, can be found >> here: >> https://datatracker.ietf.org/doc/charter-ietf-sfc/ >> >> >> >> >> ------------------------------------------------------------ >> ---------- >> COMMENT: >> ------------------------------------------------------------ >> ---------- >> >> MD-1 is explained (as fixed-length), but MD-2 is not explained >> in this charter. >> >> I'm not sure who is responsible for the determining in this text: >> >> "What can be effectively provided, for which scenarios, >> and how those tools can be provided need to be determined and >> the tools >> standardized." >> >> Could you rephrase this as active voice? >> >> Thank you for including Transport Considerations at the charter >> level. >> >> Should it be obvious to me why the first deliverable is a base >> set of MD-2 type >> codes, with MD-1 type codes being pushed off to other drafts? Is >> there more to >> this than "we're just going to do variable length to get started"? >> >> Is "active, passive, and hybrid OAM" related to the work in >> IPPM? If so, >> probably worth adding them to the "will coordinate with" list. >> >> >> >> >> --001a113a3c4e9d5b5f0564ab1a84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Joel,

On Wed, Feb 7, 2018 at 9:18 PM, Joel M. Halpern = <jmh@joelhalper= n.com> wrote:
The MD-1 usage is indeed somewhat unusual.
Yes, all the layouts are informational.

It is up to deployment and control to make sure that all participants know = what layout (or in interesting cases layouts) is being used.=C2=A0 There is= no layout identification (other than that it is MD-1) in the packet format= .

It sounds like=C2=A0https://thenewstack.io= /not-expected-understand-explainer/ applies, but I'm OK with that := -)

Thanks for your help in understanding what'= s going on here.

Spencer
=C2=A0
Yours,
Joel

On 2/7/18 10:13 PM, Spencer Dawkins at IETF wrote:
Hi, Joel,


On Wed, Feb 7, 2018 at 12:18 PM, Joel M. Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com= >> wrote:

=C2=A0 =C2=A0 With regard to your question about MD-2 Types and MD-1 defini= tions,
=C2=A0 =C2=A0 the difference is tha tthe base MD-2 types document is standa= rds
=C2=A0 =C2=A0 track.=C2=A0 The MD-1 documents are informational.=C2=A0 Thus= , as chair I
=C2=A0 =C2=A0 expect the WG to put more energy into the standards track doc= ument.


That all makes sense. What I was confused about was that all the MD-1 (fixe= d-length) definitions are informational - but maybe that's just the way= things are?

Spencer


=C2=A0 =C2=A0 Yours,
=C2=A0 =C2=A0 Joel


=C2=A0 =C2=A0 On 2/7/18 1:07 PM, Spencer Dawkins wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Spencer Dawkins has entered the following ballo= t position for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 charter-ietf-sfc-01-03: No Objection

=C2=A0 =C2=A0 =C2=A0 =C2=A0 When responding, please keep the subject line i= ntact and reply
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 email addresses included in the To and CC lines= . (Feel free to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cut this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 introductory paragraph, however.)



=C2=A0 =C2=A0 =C2=A0 =C2=A0 The document, along with other ballot positions= , can be found here:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ie= tf.org/doc/charter-ietf-sfc/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://datatracke= r.ietf.org/doc/charter-ietf-sfc/>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 ------------------------------------------= ----------------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 COMMENT:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ------------------------------------------= ----------------------------

=C2=A0 =C2=A0 =C2=A0 =C2=A0 MD-1 is explained (as fixed-length), but MD-2 i= s not explained
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in this charter.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I'm not sure who is responsible for the det= ermining in this text:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "What can be effectively provided, for whi= ch scenarios,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and how those tools can be provided need to be = determined and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the tools
=C2=A0 =C2=A0 =C2=A0 =C2=A0 standardized."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Could you rephrase this as active voice?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you for including Transport Consideration= s at the charter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 level.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Should it be obvious to me why the first delive= rable is a base
=C2=A0 =C2=A0 =C2=A0 =C2=A0 set of MD-2 type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 codes, with MD-1 type codes being pushed off to= other drafts? Is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 there more to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this than "we're just going to do vari= able length to get started"?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Is "active, passive, and hybrid OAM" = related to the work in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IPPM? If so,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 probably worth adding them to the "will co= ordinate with" list.





--001a113a3c4e9d5b5f0564ab1a84-- From nobody Thu Feb 8 05:28: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 1926D124205; Thu, 8 Feb 2018 05:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ZiYOWJx5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=p2UtjzrE 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 TuisLsLbWevG; Thu, 8 Feb 2018 05:28:33 -0800 (PST) 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 0A68112D88C; Thu, 8 Feb 2018 05:28:33 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4F40F20B71; Thu, 8 Feb 2018 08:28:32 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 08 Feb 2018 08:28:32 -0500 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=fm2; bh=+6gWJhe+tOcjmuMWaRxF11l6Kv5FC pPapXaa1c1SFkc=; b=ZiYOWJx5NU7EtHmDctD6FFdX8iuYSN6UcmV7mqpXT4OkW TcQhmOy0MCQdkoXytL35pF3rA4AqONo/LGjWa8axx8sHv40Mb4LF9mafMXWz8zWw WQXFjfeoH6L4ijDCU/tZ7WyiBIg0dcxvkCuTiwggla2od6cxhz+WxNaSqLS16l9N eScwL2PfBLKXCO0zygq1DY8OZygfAOm9vw6ePZQYEQItc4y1qaZ9fV2l/uMzCFy0 bjwz6SPbsDZFf0z13uIjRQoJNGaFh23ogMVWBY0HcltSzr1XLc/tD6XHA0g+yGe4 NqHhaUOLi0SzLn3ENit2NI8JT9QEan2VHCzGOQTZA== 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=fm1; bh=+6gWJh e+tOcjmuMWaRxF11l6Kv5FCpPapXaa1c1SFkc=; b=p2UtjzrEN+mmVFkD6yGoRS 9SXBDTMxGQYy3fP0FzLbsV1LyBnWLAIlgEontTWRuE1phvcX8H/Q2iRsJ53syknG SOVwBtCamXhhBZanNqqq+foB8iKbwSdmqJGuTTBXnZqPcsi+5qiy5RkxE7GX9W4J vVkEI0IHM/9EukxDOUPZ2dEqiL7eCbbeiKeBtjv8HCQ9FQtVaihqWKOvyY6HA2R7 IGRj5DBVD0BoCNIKe9eEfdjj9OvWJUMRMBJVzZ7L9bIvrfyB96TkKSpg6u6HqG8Y QvgV8AI9hR8mbHZV9cEdbEIKJQGXI/MKEz4o4o9u38aF7HIG0fHmsRs1cK3Y0c6g == X-ME-Sender: Received: from [10.19.234.244] (unknown [128.107.241.174]) by mail.messagingengine.com (Postfix) with ESMTPA id 414742483B; Thu, 8 Feb 2018 08:28:31 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <151699762487.4341.13082099098870205884@ietfa.amsl.com> Date: Thu, 8 Feb 2018 08:28:31 -0500 Cc: "gen-art@ietf.org Review Team" , draft-farrel-sfc-convent.all@ietf.org, sfc@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <7AF2A8C3-A101-4058-B4DE-5ADE96458337@cooperw.in> References: <151699762487.4341.13082099098870205884@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sfc] [Gen-art] Genart last call review of draft-farrel-sfc-convent-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 13:28:35 -0000 Robert, thank you for your review. I have entered a No Objection ballot. Alissa > On Jan 26, 2018, at 3:13 PM, Robert Sparks wrote: > > Reviewer: Robert Sparks > 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-farrel-sfc-convent-05 > Reviewer: Robert Sparks > Review Date: 2018-01-26 > IETF LC End Date: 2018-01-31 > IESG Telechat date: 2018-02-08 > > Summary: Ready for Publication as a Proposed Standard > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Feb 8 12:17:10 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 840061270A0; Thu, 8 Feb 2018 12:17:04 -0800 (PST) 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] 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 a1y8UFiKOZjX; Thu, 8 Feb 2018 12:17:02 -0800 (PST) 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 37B44120047; Thu, 8 Feb 2018 12:17:02 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id w18KGwIR001259; Thu, 8 Feb 2018 20:16:58 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A0B212203B; Thu, 8 Feb 2018 20:16:58 +0000 (GMT) Received: from asmtp5.iomartmail.com (unknown [10.12.10.176]) by vs1.iomartmail.com (Postfix) with ESMTPS id 8B59C2203A; Thu, 8 Feb 2018 20:16:58 +0000 (GMT) Received: from 950129200 ([193.57.120.78]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id w18KGujv005895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Feb 2018 20:16:57 GMT Reply-To: From: "Adrian Farrel" To: "'Eric Rescorla'" , "'The IESG'" Cc: , , , References: <151797352162.25862.18235247183979141834.idtracker@ietfa.amsl.com> In-Reply-To: <151797352162.25862.18235247183979141834.idtracker@ietfa.amsl.com> Date: Thu, 8 Feb 2018 20:16:54 -0000 Message-ID: <09be01d3a119$c48d8660$4da89320$@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: AQFqI5IkPYyf4zmQLNQRTemcoGvZYqRt5y/Q Content-Language: en-gb X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23650.002 X-TM-AS-Result: No--7.440-10.0-31-10 X-imss-scan-details: No--7.440-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23650.002 X-TMASE-Result: 10--7.439600-10.000000 X-TMASE-MatchedRID: HXSqh3WYKfunykMun0J1wvHkpkyUphL9AG+WI8pfMRy638ZUY6gSdzvN 6k1DPLJE7vbNU29QkanX+0jbkwoUhGE5mDD5AtZVz5rIW0RbS5hezmeoa8MJ84fAYSb4KlgZvup /d3aJh3h5Zq5B1M+nZAgm5qcgW8yDgYgAQnsnhwNoMLOoNHsM9qI0K26z6c86f7FDYGpyXq2BOj 9MIl3t3EsnypVh05u++qtD56KastmgtZVN50Ccr0fhraIl1Xgxt+hhn8Iy6GWbKItl61J/ycnjL TA/UDoAxpQ77C1A1tqOhzOa6g8KrdHffcqY0OyzfDNC6eq2YlV0puXEpc7bMhciK8qhyyCepTjS syyWfn9DDKa3G4nrLQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [sfc] Eric Rescorla's No Objection on draft-farrel-sfc-convent-05: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 20:17:04 -0000 Hey Eric, Thanks for this comment. > The need to protect the metadata is not modified by this document and > forms part of the NSH definition found in [I-D.ietf-sfc-nsh]. > Nit: I wouldn't limit this to encryption. If you care about integrity/data > origin authentication, then encryption may not supply that, If I'm reading you right, you're observing that the mechanism described in the document might allow an imposter to introduce metadata. That's sounds like a real problem and we should do something like: OLD The mechanism described in this document might possibly be used to introduce packets into the SFC overlay network. Therefore measures SHOULD be taken to ensure authorization of sources of such packets, and tunneling of such packets into the network SHOULD be prevented. The amount of packets with "Next Protocol" set to "None" on an SFP SHOULD be rate limited at each point on the SFP to provide additional security. NEW The mechanism described in this document might be used to introduce packets into the SFC overlay network and might be used to illegitimately introduce false metadata to the nodes on an SFC. Therefore measures SHOULD be taken to ensure authorization of sources of such packets, and tunneling of such packets into the network SHOULD be prevented. The amount of packets with "Next Protocol" set to "None" on an SFP SHOULD be rate limited at each point on the SFP to provide additional network security. END Does that do it? Cheers, Adrian From nobody Thu Feb 8 12:47: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 9566A1270A3; Thu, 8 Feb 2018 12:47:05 -0800 (PST) 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] 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 9u5cBvCGIheb; Thu, 8 Feb 2018 12:47:04 -0800 (PST) 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 DC192126D73; Thu, 8 Feb 2018 12:47:03 -0800 (PST) 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 w18Kl171012394; Thu, 8 Feb 2018 20:47:01 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6FCAE2203A; Thu, 8 Feb 2018 20:47:01 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 59EC122032; Thu, 8 Feb 2018 20:47:01 +0000 (GMT) Received: from 950129200 ([193.57.120.78]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id w18KkxvG023469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Feb 2018 20:47:00 GMT Reply-To: From: "Adrian Farrel" To: "'Martin Stiemerling'" , "'Mirja Kuehlewind \(IETF\)'" Cc: , , , , References: <151759289599.1342.15363054759260139160.idtracker@ietfa.amsl.com> <1bce8bb3c4ac4dcd901f0da1c2950fcc@BLUPR05MB370.namprd05.prod.outlook.com> <002e01d39c53$40045240$c00cf6c0$@olddog.co.uk> <0beb0fae-60f0-1b41-1e8a-97e0113edc8f@gmail.com> In-Reply-To: <0beb0fae-60f0-1b41-1e8a-97e0113edc8f@gmail.com> Date: Thu, 8 Feb 2018 20:46:57 -0000 Message-ID: <09c501d3a11d$f7107210$e5315630$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNaOpuO90dzvAyd/+cEP7WPMdxW0wGNyEWaAwac6u8CXZCooaBWK7LQ Content-Language: en-gb X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23650.003 X-TM-AS-Result: No--6.920-10.0-31-10 X-imss-scan-details: No--6.920-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23650.003 X-TMASE-Result: 10--6.920500-10.000000 X-TMASE-MatchedRID: VPleTT1nwdSnykMun0J1wvHkpkyUphL9XEjKf9fhKafi7ECA5q90uQaT alM8C773g4BSUQlYa3Rw9cd4urViHcwdQieqpnTaHcQQBuf4ZFuC7C2rJeUToUbkmCm1Jslr5NS 4QOzMK7uqajnR0hbY5RPFN5dKhrHeKDJiqR5tgrXhPQQVFw3HFKOI1u80g4PZ2+mPn502VC/zvp rOXn6be+fOVcxjDhcwIC0OoeD/hCbQLWxBF9DMQcRB0bsfrpPIx1FPlNAAmcBNi+PEyQOthn/Gx t1Wi9PUuCuQeIaS8yi1IESy3mdCyZ6oP1a0mRIj X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [sfc] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-farrel?= =?utf-8?q?-sfc-convent-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 20:47:06 -0000 Thanks Martin and Mirja, > and it is probably explicitly noteworthy that one incoming packet can > trigger one (or even multiple ?) new packet which may increase the > number of packets related to the incoming flow by a factor of 2. Well, it might be possible to create a use case that does that. OAM, for = example, might cause a one-for-one copy. But one might as well say that = this is a concern with IP because the payload protocol might result in = one packet creating multiple replies. But since this document is somewhat open-ended about how the is used, we = should certainly flag up the concern with two mitigations: 1. Applications using this mechanism should be careful about this issue 2. Implementations should rate limit to: a. Protect against simple volume attacks (and accidents) b. Protect against amplification I'll send some text SOON. Cheers, Adrian From nobody Thu Feb 8 16:40:31 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 8664F12DA3E for ; Thu, 8 Feb 2018 16:40:30 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 7wqsUs9Omunn for ; Thu, 8 Feb 2018 16:40:28 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 2BD1C12DA29 for ; Thu, 8 Feb 2018 16:40:28 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id l11so805777ywh.2 for ; Thu, 08 Feb 2018 16:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O0GnvJ9JEN3ymBiEH/A28noIFmtAWNqBbGN1bh2h9Xs=; b=jJHf8VWPAh6aE3ohykJo3LhUTOVVUk/4Vfd+EVEEA67a8xV3jpD2xOkBehlwcvZXSE x624fD/nJz7EZ7PyVodcmD2kvbQj/eUqcWyKMSWEmIFAadxmb7ym1/mK0jkzIFKvol4M 4Lpyd+aL6K9DGyCjd3RakR3R9pBSlW6NzhlcrjaxGt8ul0nxOb0GhSvoocageER6+l2p OOTo7A+NisZyGRB8+bNYtqLRivEEBk6TcXHPx/+WD6flpTiLv8HoIe3Y0wny6e5V4E7A faAYTwTPt5FpmaqakWP9+eafH1FeEX56AsIT1zioJUOnlHSaZMaxvQ2jvukfgq6xJYaJ JF8w== 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=O0GnvJ9JEN3ymBiEH/A28noIFmtAWNqBbGN1bh2h9Xs=; b=oG8XtENA8rVqWNW20ajqrEo8BBBogZnT1AqVOycbUlP3hzizuwm7zbxEb6Z+xhnax+ U/igvu5GjO3CxSsCOcqLbG3kg8V4wbNmwM3NZFlaPJh/ATVgwpurYCTieyiAAZkasaR8 Ypw2Er+katiClwLT/VXcMT/ZOEIfRtuiPfDANSO3akDj3OhM8Gs/vYUoMPZBnFlsJCJD b8zuPOXRVGtfs4DGyx6flUkuBNa/hjQg+Pz4RVkWxsEYgQbkIJtAT5NimeL7pe3TsPJI b/wRgaKuC4jDGAHh83hSk2U+VRQzoDpycmGZh/Y1kDx1rpJUrdqHmMePm76ofEtLeaAk c6QA== X-Gm-Message-State: APf1xPDVlwiqjtMhvvBjpbwrNk9FQQdS6bPB3T64w8mCX6mqwR7jwe2B s2R2Q09i18sUeDjTWgU0YZrvVfqNYJoyDhyo5SNN0w== X-Google-Smtp-Source: AH8x2266GFzqBfgnlNsSMuZZERlEj/ft4Cu/4o+K6SPC6AAXZgnU1U7Db7IC/EtYw6Vk3N8faquUpztI/Hu4TonCF+Q= X-Received: by 10.37.239.79 with SMTP id w15mr594337ybm.293.1518136827253; Thu, 08 Feb 2018 16:40:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.201 with HTTP; Thu, 8 Feb 2018 16:39:46 -0800 (PST) In-Reply-To: <09be01d3a119$c48d8660$4da89320$@olddog.co.uk> References: <151797352162.25862.18235247183979141834.idtracker@ietfa.amsl.com> <09be01d3a119$c48d8660$4da89320$@olddog.co.uk> From: Eric Rescorla Date: Thu, 8 Feb 2018 16:39:46 -0800 Message-ID: To: Adrian Farrel Cc: The IESG , draft-farrel-sfc-convent@ietf.org, tal.mizrahi.phd@gmail.com, sfc-chairs@ietf.org, sfc@ietf.org Content-Type: multipart/alternative; boundary="089e0828a13c4f2cc10564bcc634" Archived-At: Subject: Re: [sfc] Eric Rescorla's No Objection on draft-farrel-sfc-convent-05: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 00:40:30 -0000 --089e0828a13c4f2cc10564bcc634 Content-Type: text/plain; charset="UTF-8" This is actually a smarter point that I was intending to make. I was just looking at the following text? " according to the perceived vulnerabilities of the network. Protection of metadata may be achieved by using encrypted transport between SFC entities or by encrypting the metadata in its own right." This isn't necessarily a function of "encrypting" but rather of providing integrity and data origin authentication, although good encryption protocols do provide both. -Ekr On Thu, Feb 8, 2018 at 12:16 PM, Adrian Farrel wrote: > Hey Eric, > > Thanks for this comment. > > > The need to protect the metadata is not modified by this document and > > forms part of the NSH definition found in [I-D.ietf-sfc-nsh]. > > Nit: I wouldn't limit this to encryption. If you care about > integrity/data > > origin authentication, then encryption may not supply that, > > If I'm reading you right, you're observing that the mechanism described in > the > document might allow an imposter to introduce metadata. > > That's sounds like a real problem and we should do something like: > > OLD > The mechanism described in this document might possibly be used to > introduce packets into the SFC overlay network. Therefore measures > SHOULD be taken to ensure authorization of sources of such packets, > and tunneling of such packets into the network SHOULD be prevented. > The amount of packets with "Next Protocol" set to "None" on an SFP > SHOULD be rate limited at each point on the SFP to provide additional > security. > NEW > The mechanism described in this document might be used to introduce > packets into the SFC overlay network and might be used to > illegitimately introduce false metadata to the nodes on an SFC. > Therefore measures SHOULD be taken to ensure authorization of sources > of such packets, and tunneling of such packets into the network > SHOULD be prevented. > > The amount of packets with "Next Protocol" set to "None" on an SFP > SHOULD be rate limited at each point on the SFP to provide additional > network security. > END > > Does that do it? > > Cheers, > Adrian > > --089e0828a13c4f2cc10564bcc634 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is actually a smarter point that I was intending to m= ake.

I was just looking at the following text?
"=C2=A0 =C2=A0according to the perceived vulnerabilities of the netwo= rk. Protection of metadata may be achieved by using encrypted transport
=C2=A0 between SFC entities or by encrypting the metadata in its own= right."
=C2=A0=C2=A0
This isn't necessari= ly a function of "encrypting" but rather of providing integrity a= nd data origin authentication, although good encryption protocols do provid= e both.

-Ekr

=

On Thu, Feb 8, 20= 18 at 12:16 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:=
Hey Eric,

Thanks for this comment.

>=C2=A0 =C2=A0 The need to protect the metadata is not modified by this = document and
>=C2=A0 =C2=A0 forms part of the NSH definition found in [I-D.ietf-sfc-n= sh].
> Nit: I wouldn't limit this to encryption. If you care about integr= ity/data
> origin authentication, then encryption may not supply that,

If I'm reading you right, you're observing that the mechanis= m described in the
document might allow an imposter to introduce metadata.

That's sounds like a real problem and we should do something like:

OLD
=C2=A0 =C2=A0The mechanism described in this document might possibly be use= d to
=C2=A0 =C2=A0introduce packets into the SFC overlay network.=C2=A0 Therefor= e measures
=C2=A0 =C2=A0SHOULD be taken to ensure authorization of sources of such pac= kets,
=C2=A0 =C2=A0and tunneling of such packets into the network SHOULD be preve= nted.
=C2=A0 =C2=A0The amount of packets with "Next Protocol" set to &q= uot;None" on an SFP
=C2=A0 =C2=A0SHOULD be rate limited at each point on the SFP to provide add= itional
=C2=A0 =C2=A0security.
NEW
=C2=A0 =C2=A0The mechanism described in this document might be used to intr= oduce
=C2=A0 =C2=A0packets into the SFC overlay network and might be used to
=C2=A0 =C2=A0illegitimately introduce false metadata to the nodes on an SFC= .
=C2=A0 =C2=A0Therefore measures SHOULD be taken to ensure authorization of = sources
=C2=A0 =C2=A0of such packets, and tunneling of such packets into the networ= k
=C2=A0 =C2=A0SHOULD be prevented.

=C2=A0 =C2=A0The amount of packets with "Next Protocol" set to &q= uot;None" on an SFP
=C2=A0 =C2=A0SHOULD be rate limited at each point on the SFP to provide add= itional
=C2=A0 =C2=A0network security.
END

Does that do it?

Cheers,
Adrian


--089e0828a13c4f2cc10564bcc634-- From nobody Mon Feb 12 08:26:05 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 195A112421A; Mon, 12 Feb 2018 08:25:58 -0800 (PST) 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.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151845275804.6022.1788252810856578728@ietfa.amsl.com> Date: Mon, 12 Feb 2018 08:25:58 -0800 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-dc-allocation-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 16:25:58 -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 : Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center) Authors : Jim Guichard Michael Smith Surendra Kumar Sumandra Majee Puneet Agarwal Kevin Glavin Youcef Laribi Tal Mizrahi Filename : draft-ietf-sfc-nsh-dc-allocation-00.txt Pages : 8 Date : 2018-02-12 Abstract: This document provides a recommended default allocation for the Network Service Header (NSH) MD Type 1 fixed length context header when NSH is used for Service Function Chaining within a data center. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-dc-allocation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sfc-nsh-dc-allocation-00 https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-dc-allocation-00 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 Feb 12 08:57: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 74B1A12421A for ; Mon, 12 Feb 2018 08:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Pez-w1H6ke0X for ; Mon, 12 Feb 2018 08:57:30 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 A9DBA126DD9 for ; Mon, 12 Feb 2018 08:57:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8B5F75C002F for ; Mon, 12 Feb 2018 08:57:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1518454650; bh=5UWt6xeODYb4c3XEXqw3q0X5BQFgo5K5OMhznBzP3U8=; h=To:From:Subject:Date:From; b=TUqmiMZq3Y7cqyR8kjpSycypDmCpQgwb8oSOyIIEYbf3HNPu7uHg+0BviF6Uf59js TeNpdzkeOQ95fGet4hicJSLPWxt6JsK0V4+qR0FKlHoX9w6EKdSgkNmDWU96EXh9wk GR3rFl//20T+w6/PZVMGsTNtk6K+a8DB4xzmgl9o= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 1900B5C0027 for ; Mon, 12 Feb 2018 08:57:29 -0800 (PST) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: <62d6f107-f497-e0d4-cef7-46ea1fca61d3@joelhalpern.com> Date: Mon, 12 Feb 2018 11:57:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.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] WG Adoption Call: draft-sarikaya-sfc-hostid-serviceheader-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 16:57:32 -0000 Regarding Service Function Chaining Service, Subscriber and Host Identification Use Cases and Metadata This draft: https://tools.ietf.org/html/draft-sarikaya-sfc-hostid-serviceheader-05 has been presented several times to the WG and discussed on the email list. The authors have requested working group adoption. Please speak up in favor or opposed. Preferably with reasoning. This adoption call will end officially at 11:59 pm GMT on February 26th. Earlier responses will help the chairs and secretary judge the situation better. Thank you, Joel PS: The authors are presumed to support the adoption. They only need to comment if there is a problem. From nobody Mon Feb 12 10:26:35 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 66736129516 for ; Mon, 12 Feb 2018 10:26:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151845999441.5986.2487884599408568139.idtracker@ietfa.amsl.com> Date: Mon, 12 Feb 2018 10:26:34 -0800 From: IETF Secretariat Archived-At: Subject: [sfc] Milestones changed for sfc WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 18:26:34 -0000 Changed milestone "Informational document defining the Operation, Administration and Maintenance (OAM) framework for SFC", set state to active from review, accepting new milestone. Changed milestone "Submit to IESG Informational documents specifying the format of MD-type 1 metadata in DC and Broadband environments", set state to active from review, accepting new milestone. Changed milestone "Submit to IESG Standards Track document specifying MD-type 2 metadata formats", set state to active from review, accepting new milestone. Changed milestone "YANG models for SFF and classifier", set state to active from review, accepting new milestone. Changed milestone "Submit to IESG Informational document defining authentication, integrity protection, and confidentiality of SFC metadata", set state to active from review, accepting new milestone. Changed milestone "Informational document defining transport considerations applicable to SFC", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/sfc/about/ From nobody Mon Feb 12 10:27:41 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 8149D12D864 for ; Mon, 12 Feb 2018 10:27:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151846006052.6149.7567067658337477052.idtracker@ietfa.amsl.com> Date: Mon, 12 Feb 2018 10:27:40 -0800 From: IETF Secretariat Archived-At: Subject: [sfc] Milestones changed for sfc WG X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 18:27:40 -0000 Changed milestone "Submit to IESG Information document defining the SFC problem statement and core use cases", resolved as "Done". Changed milestone "Submit to IESG Informational document defining the architecture for SFC", resolved as "Done". Changed milestone "Informational document defining the control plane requirements for conveying information between control or management elements and SFC implementation points", resolved as "Done". Changed milestone "Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation", resolved as "Done". URL: https://datatracker.ietf.org/wg/sfc/about/ From nobody Mon Feb 12 12:32:10 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 1143C12D959; Mon, 12 Feb 2018 12:32:01 -0800 (PST) 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.72.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , sfc-chairs@ietf.org, sfc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151846752106.6121.9785986097468921114.idtracker@ietfa.amsl.com> Date: Mon, 12 Feb 2018 12:32:01 -0800 Archived-At: Subject: [sfc] WG Action: Rechartered Service Function Chaining (sfc) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 20:32:01 -0000 The Service Function Chaining (sfc) WG in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Service Function Chaining (sfc) ----------------------------------------------------------------------- Current status: Active WG Chairs: Joel Halpern Jim Guichard Secretaries: Tal Mizrahi Assigned Area Director: Alia Atlas Routing Area Directors: Alia Atlas Alvaro Retana Deborah Brungard Mailing list: Address: sfc@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/sfc Archive: https://mailarchive.ietf.org/arch/browse/sfc/ Group page: https://datatracker.ietf.org/group/sfc/ Charter: https://datatracker.ietf.org/doc/charter-ietf-sfc/ Network operators frequently utilize service functions such as packet filtering at firewalls, load-balancing and transactional proxies (for example spam filters) in the delivery of services to end users. Delivery of these types of services is undergoing significant change with the introduction of virtualization, network overlays, and orchestration. The SFC Working Group has developed an Architecture [RFC 7665] and the Network Service Header [RFC 8300] for service function chaining. The focus of the SFC working group moving forward is on aspects of the architecture and/or protocol that need to be addressed to enable effective deployment and usage of this work. In order to maintain focus, the working group primarily produces and advances documents on four topics: 1) Metadata - Define the common type-length-value encoded metadata types with Standards Track RFCs, and produce Informational RFCs to describe common fixed-length (MD-1) metadata usages. 2) Security and Privacy - Mechanisms and guidance for securing metadata via authentication, integrity protection, confidentiality, and/or data minimization are not yet defined. What can be effectively provided, for which scenarios, and how those tools can be provided need to be determined and the tools standardized. 3) OAM and Operations & Management - In order for operators to use these tools in production networks, they need Operations, Administration, and Maintenance tools, as well as management mechanisms. This includes YANG models, OAM frameworks, and specific OAM mechanisms to address operational needs. 4) Transport Considerations - This will capture the expectations SFC places on transport behavior, including dealing with issues such as congestion indications and responses. This should define how NSH works on standardized transports that are expected to see widespread use. Specifically, the SFC WG is chartered to deliver the following: 1. A Standards Track base set of the metadata MD-2 type codes within the metadata class reserved for IETF usage, as specified in RFC 8300. 2. Related Metadata drafts that require more explanation than is reasonable to include in the base MD-2 draft, including MD-1 descriptions and items done once the base draft is complete. 3. YANG models for the management of SFC Components. 4. One or more security related Standards Track and / or Informational RFCs. At least one Standards Track security mechanism RFC is needed. 5. OAM Framework document to provide a common basis for OAM work. This draft will include guidance on how active, passive, and hybrid OAM are to be supported if at all. 6. Specific OAM mechanism documents to provide the tools needed for operational environments. 7. Transport Considerations RFC to cover the expectations SFC and NSH place on transport, and the operational constraints transports used by NSH need to meet. The SFC WG may work on Informational applicability documents that show how the technology, meta-data, and associated control-plane mechanisms can be used in specific use-cases. The SFC WG may work on Informational documents that provide operational considerations. The SFC WG will coordinate with BESS and PCE on the control-plane work related to SFC. Milestones: Apr 2014 - Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining Oct 2018 - Informational document defining the Operation, Administration and Maintenance (OAM) framework for SFC Dec 2018 - Submit to IESG Informational documents specifying the format of MD-type 1 metadata in DC and Broadband environments Dec 2018 - Submit to IESG Standards Track document specifying MD-type 2 metadata formats Mar 2019 - YANG models for SFF and classifier Jul 2019 - Submit to IESG Informational document defining authentication, integrity protection, and confidentiality of SFC metadata Jul 2019 - Informational document defining transport considerations applicable to SFC From nobody Mon Feb 12 14:33:32 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 8E10C127010 for ; Mon, 12 Feb 2018 14:33:30 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 Oevl-93Ry5C4 for ; Mon, 12 Feb 2018 14:33:27 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 7ECFE126D74 for ; Mon, 12 Feb 2018 14:33:27 -0800 (PST) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1CMV06R030315; Mon, 12 Feb 2018 14:33:25 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=WfXDq8xVZRra47ge49GjL75kvk1Vrwwpbcjauqv6Ags=; b=gIu3eNyU6vr4oF8h3OtKwv5KKQOgDHEByrGTWNgbDcq4piXq1+qSDZax5U7HIU379BgR 1l4xSiwoXYRLI1MqzHek0OZrlE+bEEcNvniQfCzE0ZBxo9Yd0uh6mY5EGvOKBUwVukZG r1PXOcVsmHb8rj19Vy41w2P51I9lpK6yVKdZRLWmvWonInZ6PBRowWaFiG4O3GOZsp8R S2oC/+nQBW8dA+mQ4EXzR3MoHvuFfCHhr8dEx5Oq5/pMiwjz0s3xMhwDmmmo4mgIPrM9 zY9mSux9C0YmyCTcxJ838v0UQfAizUOX3Jvr6LoMM9mp277zfdjtiFtPqhPXMHOuW5UG Lw== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0120.outbound.protection.outlook.com [207.46.163.120]) by mx0b-00273201.pphosted.com with ESMTP id 2g3hkt86b0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Feb 2018 14:33:25 -0800 Received: from BLUPR05MB370.namprd05.prod.outlook.com (10.141.25.150) by BLUPR05MB259.namprd05.prod.outlook.com (10.141.22.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.506.7; Mon, 12 Feb 2018 22:33:22 +0000 Received: from BLUPR05MB370.namprd05.prod.outlook.com ([fe80::b531:7948:784b:9cfb]) by BLUPR05MB370.namprd05.prod.outlook.com ([fe80::b531:7948:784b:9cfb%18]) with mapi id 15.20.0506.007; Mon, 12 Feb 2018 22:33:22 +0000 From: Adrian Farrel To: "ietf@kuehlewind.net" , "mls.ietf@gmail.com" CC: "sfc@ietf.org" Thread-Topic: Proposal for congestion control in draft-farrel-sfc-convent Thread-Index: AdOkUWieWeFX83LaRmCLcmak7P8lwg== Date: Mon, 12 Feb 2018 22:33:22 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB259; 7:W2VpE2TG7hoVvg7tBzKmQu/2ZhOZ60pMqpshycQ8EA/qvIYAQpqUbobWOeIcVYTjhFfd9N64vCvEXezJescAVvS46aYJXsefKW+cRGF1M0T4M9fTGOqvSDPxqEGeVY3UlOAUS+RPoFCdQMIrFZV69WhkJk50ck5oRrOmXqDwSJL2Busbc4U8YiuMl9ms+EIIYY7TaBCPTX9T/6TqmGqfgZBWqOq84NtM2TxpTp6IHeXq+vm0g7Na6DyyoQ7GQ8+M x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 5be572cc-845e-47d5-f4d0-08d572689fd6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:BLUPR05MB259; x-ms-traffictypediagnostic: BLUPR05MB259: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(10201501046)(6055026)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:BLUPR05MB259; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB259; x-forefront-prvs: 0581B5AB35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39380400002)(366004)(39860400002)(189003)(199004)(68736007)(5660300001)(9686003)(105586002)(55016002)(305945005)(6506007)(102836004)(3660700001)(59450400001)(316002)(26005)(4326008)(6306002)(2906002)(7696005)(186003)(25786009)(53936002)(7736002)(3280700002)(6116002)(39060400002)(74316002)(3846002)(6436002)(2501003)(561944003)(33656002)(99286004)(966005)(66066001)(14454004)(97736004)(2900100001)(86362001)(478600001)(81156014)(8936002)(106356001)(81166006)(110136005)(5250100002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB259; H:BLUPR05MB370.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: EoZpEqqciHvc1DhfyNA1gSexZFPFTbemuvPBrtxsO4oxZDYjClO3qxET/J2+0Ow8Rp5Z0IIVZwtlT2Wu3NC3ew== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR05MB370BC7BDC9E741CC09ABD47BBF70BLUPR05MB370namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 5be572cc-845e-47d5-f4d0-08d572689fd6 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2018 22:33:22.6154 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB259 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-12_09:, , 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-1711220000 definitions=main-1802120284 Archived-At: Subject: [sfc] Proposal for congestion control in draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 22:33:30 -0000 --_000_BLUPR05MB370BC7BDC9E741CC09ABD47BBF70BLUPR05MB370namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mirja and Martin, Here is a proposal to address Mirja's Discuss. It is a new top-level sectio= n. It is for discussion, so please tell me what it is missing and how we shoul= d work on it. It makes sense (to me) for the WG to comment about this as well. Thanks, Adrian =3D=3D=3D=3D 6. Management and Congestion Control Considerations The mechanisms described in this document allow SFC-aware nodes in an SFC n= etwork to generate additional packets. While these packets are in the natu= re of in-band control packets and not intended to be sent frequently for an= y flow, there is still a risk that they might flood the network. For exampl= e, if an attempt is made to use this mechanism for "per-packet metadata" (S= ection 5.6) then this might double the number of packets in the network. Si= milarly, if this mechanism is used for a form of aliveness detection OAM th= at requires very frequent test messages, then the number of additional mess= ages may be very high. Such additional messages risk causing congestion in = the network. The underlay network (that is the tunnels across the underlay between SFC n= odes) will not distinguish between data-carrying packets and those packets = with next protocol set to none. All packets will be treated the same and wi= ll need to fall within the capabilities of the underlay network to process = and forward packets. Nodes in the SFC overlay network will need to perform special processing on= the additional packets according to their roles and according to the appli= cation for the metadata. For example, an SFF will likely only have to forwa= rd per-SFC metadata, while an SF will need to extract it and process it as = it would if the metadata was carried in a packet with user data. On the oth= er hand, metadata might also be used to cause actions at all nodes (see Sec= tions 5.3, 5.4 and 5.5) and could increase the processing load. In view of these potential issues, all implementations SHOULD implement rat= e limits on the generation of SFC packets with next protocol set to none. F= urthermore, these rate limits SHOULD be configurable and applied per SFC an= d per application so that one application on one SFC does not encumber a di= fferent application on a different SFC. When an implementation finds that i= t is unable to generate or send a packet it SHOULD increment a counter that= is accessible by the operator, and MAY raise an alert (although such alert= s SHOULD, themselves, be rate limited). Additionally, an SFC node needs to protect itself against another node in t= he network not applying suitable rate limits. Therefore, implementations SH= OULD apply incoming rate limits for SFC packets with next protocol set to n= one. Such rate limits SHOULD be application-aware, per SFC or interface, an= d SHOULD be configurable, but implementations MAY be more subtle if they ar= e aware of internal processing loads and have access to queues/buffers. In = any case, when an implementation drops a received packed because of these r= ate limits it SHOULD increment a counter that is accessible by the operator= , and MAY raise an alert (although such alerts SHOULD, themselves, be rate = limited). =3D=3D=3D=3D --_000_BLUPR05MB370BC7BDC9E741CC09ABD47BBF70BLUPR05MB370namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Mirja and Martin,
 
Here is a proposal to address Mirja’s Discuss. It is a new top-l= evel section.
 
It is for discussion, so please tell me what it is missing and how we = should work on it.
 
It makes sense (to me) for the WG to comment about this as well.
 
Thanks,
Adrian
 
=3D=3D=3D=3D
6. Management and Congestion Control Considerations
 
The mechanisms described in this document allow SFC-aware nodes in an = SFC network to generate additional packets.  While these packets are i= n the nature of in-band control packets and not intended to be sent frequen= tly for any flow, there is still a risk that they might flood the network. For example, if an attempt is made to us= e this mechanism for “per-packet metadata” (Section 5.6) then t= his might double the number of packets in the network. Similarly, if this m= echanism is used for a form of aliveness detection OAM that requires very frequent test messages, then the number of additiona= l messages may be very high. Such additional messages risk causing congesti= on in the network.
 
The underlay network (that is the tunnels across the underlay between = SFC nodes) will not distinguish between data-carrying packets and those pac= kets with next protocol set to none. All packets will be treated the same a= nd will need to fall within the capabilities of the underlay network to process and forward packets.
 
Nodes in the SFC overlay network will need to perform special processi= ng on the additional packets according to their roles and according to the = application for the metadata. For example, an SFF will likely only have to = forward per-SFC metadata, while an SF will need to extract it and process it as it would if the metadata wa= s carried in a packet with user data. On the other hand, metadata might als= o be used to cause actions at all nodes (see Sections 5.3, 5.4 and 5.5) and= could increase the processing load.
 
In view of these potential issues, all implementations SHOULD implemen= t rate limits on the generation of SFC packets with next protocol set to no= ne. Furthermore, these rate limits SHOULD be configurable and applied per S= FC and per application so that one application on one SFC does not encumber a different application on a diffe= rent SFC. When an implementation finds that it is unable to generate or sen= d a packet it SHOULD increment a counter that is accessible by the operator= , and MAY raise an alert (although such alerts SHOULD, themselves, be rate limited).
 
Additionally, an SFC node needs to protect itself against another node= in the network not applying suitable rate limits. Therefore, implementatio= ns SHOULD apply incoming rate limits for SFC packets with next protocol set= to none. Such rate limits SHOULD be application-aware, per SFC or interface, and SHOULD be configurable, but= implementations MAY be more subtle if they are aware of internal processin= g loads and have access to queues/buffers. In any case, when an implementat= ion drops a received packed because of these rate limits it SHOULD increment a counter that is accessible by th= e operator, and MAY raise an alert (although such alerts SHOULD, themselves= , be rate limited).
=3D=3D=3D=3D
 
 
 
 --_000_BLUPR05MB370BC7BDC9E741CC09ABD47BBF70BLUPR05MB370namprd_-- From nobody Mon Feb 12 22:14:48 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 4062A12E058 for ; Mon, 12 Feb 2018 22:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 dz7IPaP-8OFE for ; Mon, 12 Feb 2018 22:14:45 -0800 (PST) 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 4EB291205F0 for ; Mon, 12 Feb 2018 22:14:45 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id C0FEB61388; Tue, 13 Feb 2018 07:14:43 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id A781780070; Tue, 13 Feb 2018 07:14:43 +0100 (CET) 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.0382.000; Tue, 13 Feb 2018 07:14:43 +0100 From: To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] WG Adoption Call: draft-sarikaya-sfc-hostid-serviceheader-05 Thread-Index: AQHTpCKWfn0m6W6uEU2sZklrYF3X0KOh2xHA Date: Tue, 13 Feb 2018 06:14:42 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0CF598@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <62d6f107-f497-e0d4-cef7-46ea1fca61d3@joelhalpern.com> In-Reply-To: <62d6f107-f497-e0d4-cef7-46ea1fca61d3@joelhalpern.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG Adoption Call: draft-sarikaya-sfc-hostid-serviceheader-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 06:14:47 -0000 Hi Joel, all,=20 One minor comment, the latest version is -06:=20 https://tools.ietf.org/html/draft-sarikaya-sfc-hostid-serviceheader-06=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > Envoy=E9=A0: lundi 12 f=E9vrier 2018 17:57 > =C0=A0: sfc@ietf.org > Objet=A0: [sfc] WG Adoption Call: draft-sarikaya-sfc-hostid-serviceheader= -05 >=20 > Regarding Service Function Chaining Service, Subscriber and Host > Identification Use Cases and Metadata >=20 > This draft: > https://tools.ietf.org/html/draft-sarikaya-sfc-hostid-serviceheader-05 > has been presented several times to the WG and discussed on the email lis= t. >=20 > The authors have requested working group adoption. >=20 > Please speak up in favor or opposed. Preferably with reasoning. >=20 > This adoption call will end officially at 11:59 pm GMT on February 26th. > Earlier responses will help the chairs and secretary judge the situation > better. >=20 > Thank you, > Joel >=20 > PS: The authors are presumed to support the adoption. They only need to > comment if there is a problem. >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Feb 13 05:19:26 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 2412412EA59; Tue, 13 Feb 2018 05:19:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151852796414.13036.17297455691813895066.idtracker@ietfa.amsl.com> Date: Tue, 13 Feb 2018 05:19:24 -0800 Archived-At: Subject: [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.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 13:19:24 -0000 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-serviceheader/ From nobody Fri Feb 16 03:40:46 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 BBE4D12D879 for ; Fri, 16 Feb 2018 03:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 3ubKT_gyHTdt for ; Fri, 16 Feb 2018 03:40:43 -0800 (PST) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E35112D7EE for ; Fri, 16 Feb 2018 03:40:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=seEXbwhtTRRYW6PvHHiKPQ3cbMfI7O1tw6ThJp0Xq8Tz2gP+tsUNorh48ibfAOqAUT3cQVdRHM75szLaHYrFE371KM15FVK+P+DnpiW6aceQREBptTAEOIGy2x65kt2Mq7QmfYWslytgPw6195lmtUFeM/EUI0OGJF3MvulqbUs=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 20060 invoked from network); 16 Feb 2018 12:40:40 +0100 Received: from mue-88-130-61-170.dsl.tropolys.de (HELO ?192.168.178.33?) (88.130.61.170) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Feb 2018 12:40:40 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Fri, 16 Feb 2018 12:40:39 +0100 Cc: "mls.ietf@gmail.com" , "sfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <80F5D055-BA2A-4FCF-B586-75A2147FA13D@kuehlewind.net> References: To: Adrian Farrel X-Mailer: Apple Mail (2.3445.5.20) X-PPP-Message-ID: <20180216114040.20054.44308@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [sfc] Proposal for congestion control in draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 11:40:45 -0000 Hi Adrian, this text looks really good to me. Thanks! I only comment I have is that is would be even better if you could give = some more concrete guidance what the rate should be limited to. I = don=E2=80=99t know if that makes sense for the SFC use case but in = RFC8085 the guidance would be: =E2=80=9E... not sending on average more = than one UDP datagram per RTT to a destination=E2=80=9C. Please update the draft, depending on the wg feedback of course, and = I=E2=80=99ll clear my discuss. Mirja > Am 12.02.2018 um 23:33 schrieb Adrian Farrel : >=20 > Hi Mirja and Martin, > =20 > Here is a proposal to address Mirja=E2=80=99s Discuss. It is a new = top-level section. > =20 > It is for discussion, so please tell me what it is missing and how we = should work on it. > =20 > It makes sense (to me) for the WG to comment about this as well. > =20 > Thanks, > Adrian > =20 > =3D=3D=3D=3D > 6. Management and Congestion Control Considerations > =20 > The mechanisms described in this document allow SFC-aware nodes in an = SFC network to generate additional packets. While these packets are in = the nature of in-band control packets and not intended to be sent = frequently for any flow, there is still a risk that they might flood the = network. For example, if an attempt is made to use this mechanism for = =E2=80=9Cper-packet metadata=E2=80=9D (Section 5.6) then this might = double the number of packets in the network. Similarly, if this = mechanism is used for a form of aliveness detection OAM that requires = very frequent test messages, then the number of additional messages may = be very high. Such additional messages risk causing congestion in the = network. > =20 > The underlay network (that is the tunnels across the underlay between = SFC nodes) will not distinguish between data-carrying packets and those = packets with next protocol set to none. All packets will be treated the = same and will need to fall within the capabilities of the underlay = network to process and forward packets. > =20 > Nodes in the SFC overlay network will need to perform special = processing on the additional packets according to their roles and = according to the application for the metadata. For example, an SFF will = likely only have to forward per-SFC metadata, while an SF will need to = extract it and process it as it would if the metadata was carried in a = packet with user data. On the other hand, metadata might also be used to = cause actions at all nodes (see Sections 5.3, 5.4 and 5.5) and could = increase the processing load. > =20 > In view of these potential issues, all implementations SHOULD = implement rate limits on the generation of SFC packets with next = protocol set to none. Furthermore, these rate limits SHOULD be = configurable and applied per SFC and per application so that one = application on one SFC does not encumber a different application on a = different SFC. When an implementation finds that it is unable to = generate or send a packet it SHOULD increment a counter that is = accessible by the operator, and MAY raise an alert (although such alerts = SHOULD, themselves, be rate limited). > =20 > Additionally, an SFC node needs to protect itself against another node = in the network not applying suitable rate limits. Therefore, = implementations SHOULD apply incoming rate limits for SFC packets with = next protocol set to none. Such rate limits SHOULD be application-aware, = per SFC or interface, and SHOULD be configurable, but implementations = MAY be more subtle if they are aware of internal processing loads and = have access to queues/buffers. In any case, when an implementation drops = a received packed because of these rate limits it SHOULD increment a = counter that is accessible by the operator, and MAY raise an alert = (although such alerts SHOULD, themselves, be rate limited). > =3D=3D=3D=3D From nobody Fri Feb 16 05:48:47 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 2D2E61273B1 for ; Fri, 16 Feb 2018 05:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Dai9rTEcVD5O for ; Fri, 16 Feb 2018 05:48:43 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF113127023 for ; Fri, 16 Feb 2018 05:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7440; q=dns/txt; s=iport; t=1518788922; x=1519998522; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tA4CYxlVpubLVmyxLocV3jJRTTdJMeN6uE3rBqJT2FE=; b=Xm+ARWeW/GxNvjXBMsX7or7ZdZzCbC5efDzTNCVAT25va6RHmbf34kiJ bOtXDZ7I+dlbElOD0aRSEg0PXKwl/ilMtPVqTPZiSlKqp/XPBYY8rd0kL CsH4JcQU8kYkzL+Xp36zrtd/nqQFilnetMNiIcqYAuA3QcgAJWGcTmGm3 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AQDc34Za/4kNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPZnAoCoNKiiWOAoICgReWSYIWChgLhRgCGoIsVBgBAgE?= =?us-ascii?q?BAQEBAQJrKIUjAQEBAQIBAQEhETMHCwULAgEIDgoCAiYCAgIlCxUQAQEEDgW?= =?us-ascii?q?KGQgQrWeCJ4h7ghMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPg3WCKIFXghG?= =?us-ascii?q?DBYMwAQGBShoNgxcxgjQFmXc1igkJApYIDoIShiqLfpdyAhEZAYE7AR85gVF?= =?us-ascii?q?wFToqAYIYhHZ4izICJYENgRkBAQE?= X-IronPort-AV: E=Sophos;i="5.46,519,1511827200"; d="scan'208";a="349868289" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2018 13:48:41 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w1GDmfSO005231 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Feb 2018 13:48:41 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 16 Feb 2018 08:48:40 -0500 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; Fri, 16 Feb 2018 08:48:40 -0500 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel CC: "ietf@kuehlewind.net" , "mls.ietf@gmail.com" , "sfc@ietf.org" Thread-Topic: [sfc] Proposal for congestion control in draft-farrel-sfc-convent Thread-Index: AdOkUWieWeFX83LaRmCLcmak7P8lwgDBVocA Date: Fri, 16 Feb 2018 13:48: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-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.6.116] Content-Type: text/plain; charset="utf-8" Content-ID: <9B0B5C5AE6C87D42917B5EF8431D5241@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Proposal for congestion control in draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 13:48:45 -0000 SGksIEFkcmlhbiwNCg0KVGhhbmsgeW91IGZvciBwcm9kdWNpbmcgdGhpcyB0ZXh0IGFuZCBhY3Rp dmVseSBhZGRyZXNzaW5nIGFsbCBjb21tZW50cyBhbmQgcmV2aWV3IGlucHV0IG9uIHRoaXMgZG9j dW1lbnQhIE1hbnkgdGhhbmtzIGFsc28gYmVjYXVzZSDigJxzb29u4oCdIHdhcyB2ZXJ5IHNvb24g aW5kZWVkIQ0KDQpTb21lIG9mIHRoaXMgdGV4dCwgaG93ZXZlciwgc2VlbXMgcHJldHR5IGhlYXZ5 LWhhbmRlZC4gUGxlYXNlIGZpbmQgc29tZSBjb21tZW50cyBpbmxpbmUuDQoNCuKAlA0KQ2FybG9z IFBpZ25hdGFybywgY2FybG9zQGNpc2NvLmNvbQ0KDQo+IE9uIEZlYiAxMiwgMjAxOCwgYXQgNToz MyBQTSwgQWRyaWFuIEZhcnJlbCA8YWZhcnJlbEBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+IA0KPiBI aSBNaXJqYSBhbmQgTWFydGluLA0KPiAgDQo+IEhlcmUgaXMgYSBwcm9wb3NhbCB0byBhZGRyZXNz IE1pcmph4oCZcyBEaXNjdXNzLiBJdCBpcyBhIG5ldyB0b3AtbGV2ZWwgc2VjdGlvbi4NCj4gIA0K PiBJdCBpcyBmb3IgZGlzY3Vzc2lvbiwgc28gcGxlYXNlIHRlbGwgbWUgd2hhdCBpdCBpcyBtaXNz aW5nIGFuZCBob3cgd2Ugc2hvdWxkIHdvcmsgb24gaXQuDQo+ICANCj4gSXQgbWFrZXMgc2Vuc2Ug KHRvIG1lKSBmb3IgdGhlIFdHIHRvIGNvbW1lbnQgYWJvdXQgdGhpcyBhcyB3ZWxsLg0KPiAgDQo+ IFRoYW5rcywNCj4gQWRyaWFuDQo+ICANCj4gPT09PQ0KPiA2LiBNYW5hZ2VtZW50IGFuZCBDb25n ZXN0aW9uIENvbnRyb2wgQ29uc2lkZXJhdGlvbnMNCj4gIA0KPiBUaGUgbWVjaGFuaXNtcyBkZXNj cmliZWQgaW4gdGhpcyBkb2N1bWVudCBhbGxvdyBTRkMtYXdhcmUgbm9kZXMgaW4gYW4gU0ZDIG5l dHdvcmsgdG8gZ2VuZXJhdGUgYWRkaXRpb25hbCBwYWNrZXRzLiAgV2hpbGUgdGhlc2UgcGFja2V0 cyBhcmUgaW4gdGhlIG5hdHVyZSBvZiBpbi1iYW5kIGNvbnRyb2wgcGFja2V0cw0KDQpBcmUgdGhl c2Ug4oCcY29udHJvbOKAnSBwYWNrZXRzPyBUaGVzZSBhcmUgcGFja2V0cyB3aXRoIGEgc3BlY2lm aWMgY2hhcmFjdGVyaXN0aWMgKG5vdCB3aXRoIGEgc3BlY2lmaWMgZnVuY3Rpb24pLCBhbmQgYWNj b3JkaW5nIHRvIHRoZSBBYnN0cmFjdCwg4oCcdGhpcyBkb2N1bWVudCBpbGx1c3RyYXRlcyBzb21l IG9mIHRoZSBmdW5jdGlvbnMgdGhhdCBtYXkgYmUgYWNoaWV2ZWTigJ0uIEl0IGRvZXMgbm90IHNh eSDigJxUaGVzZSBhcmUgY29udHJvbCBwYWNrZXRzIOKApiINCg0KPiBhbmQgbm90IGludGVuZGVk IHRvIGJlIHNlbnQgZnJlcXVlbnRseSBmb3IgYW55IGZsb3cNCg0KTWlnaHQgYmUgdXNlZnVsIHRv IGRlZmluZSBmbG93IChieSB3YXkgb2YgYSBwb2ludGVyIGF0IGxlYXN0KSwgc2luY2UgaXTigJlz IG5vdCB1c2VkIGluIFJGQyA4MzAwLg0KDQo+ICwgdGhlcmUgaXMgc3RpbGwgYSByaXNrIHRoYXQg dGhleSBtaWdodCBmbG9vZCB0aGUgbmV0d29yay4NCg0KRmxvb2QgdGhlIHdob2xlIG5ldHdvcms/ DQoNCj4gRm9yIGV4YW1wbGUsIGlmIGFuIGF0dGVtcHQgaXMgbWFkZSB0byB1c2UgdGhpcyBtZWNo YW5pc20gZm9yIOKAnHBlci1wYWNrZXQgbWV0YWRhdGHigJ0gKFNlY3Rpb24gNS42KSB0aGVuIHRo aXMgbWlnaHQgZG91YmxlIHRoZSBudW1iZXIgb2YgcGFja2V0cyBpbiB0aGUgbmV0d29yay4gU2lt aWxhcmx5LCBpZiB0aGlzIG1lY2hhbmlzbSBpcyB1c2VkIGZvciBhIGZvcm0gb2YgYWxpdmVuZXNz IGRldGVjdGlvbiBPQU0gdGhhdCByZXF1aXJlcyB2ZXJ5IGZyZXF1ZW50IHRlc3QgbWVzc2FnZXMs IHRoZW4gdGhlIG51bWJlciBvZiBhZGRpdGlvbmFsIG1lc3NhZ2VzIG1heSBiZSB2ZXJ5IGhpZ2gu IFN1Y2ggYWRkaXRpb25hbCBtZXNzYWdlcyByaXNrIGNhdXNpbmcgY29uZ2VzdGlvbiBpbiB0aGUg bmV0d29yay4gDQo+ICANCj4gVGhlIHVuZGVybGF5IG5ldHdvcmsgKHRoYXQgaXMgdGhlIHR1bm5l bHMgYWNyb3NzIHRoZSB1bmRlcmxheSBiZXR3ZWVuIFNGQyBub2Rlcykgd2lsbCBub3QNCg0KOnMv d2lsbC9tYXkvZyA/DQoNCj4gZGlzdGluZ3Vpc2ggYmV0d2VlbiBkYXRhLWNhcnJ5aW5nIHBhY2tl dHMgYW5kIHRob3NlIHBhY2tldHMgd2l0aCBuZXh0IHByb3RvY29sIHNldCB0byBub25lLiBBbGwg cGFja2V0cyB3aWxsIGJlIHRyZWF0ZWQgdGhlIHNhbWUgYW5kIHdpbGwgbmVlZCB0byBmYWxsIHdp dGhpbiB0aGUgY2FwYWJpbGl0aWVzIG9mIHRoZSB1bmRlcmxheSBuZXR3b3JrIHRvIHByb2Nlc3Mg YW5kIGZvcndhcmQgcGFja2V0cy4NCg0KOnMvd2lsbC9tYXkvZyA/DQoNCj4gIA0KPiBOb2RlcyBp biB0aGUgU0ZDIG92ZXJsYXkgbmV0d29yayB3aWxsIG5lZWQgdG8gcGVyZm9ybSBzcGVjaWFsIHBy b2Nlc3Npbmcgb24gdGhlIGFkZGl0aW9uYWwgcGFja2V0cyBhY2NvcmRpbmcgdG8gdGhlaXIgcm9s ZXMgYW5kIGFjY29yZGluZyB0byB0aGUgYXBwbGljYXRpb24gZm9yIHRoZSBtZXRhZGF0YS4gRm9y IGV4YW1wbGUsIGFuIFNGRiB3aWxsIGxpa2VseSBvbmx5IGhhdmUgdG8gZm9yd2FyZCBwZXItU0ZD IG1ldGFkYXRhLCB3aGlsZSBhbiBTRg0KDQpwZXItU0ZQIGluc3RlYWQgb2YgcGVyLVNGQz8NCg0K PiAgd2lsbCBuZWVkIHRvIGV4dHJhY3QgaXQgYW5kIHByb2Nlc3MgaXQgYXMgaXQgd291bGQgaWYg dGhlIG1ldGFkYXRhIHdhcyBjYXJyaWVkIGluIGEgcGFja2V0IHdpdGggdXNlciBkYXRhLiBPbiB0 aGUgb3RoZXIgaGFuZCwgbWV0YWRhdGEgbWlnaHQgYWxzbyBiZSB1c2VkIHRvIGNhdXNlIGFjdGlv bnMgYXQgYWxsIG5vZGVzIChzZWUgU2VjdGlvbnMgNS4zLCA1LjQgYW5kIDUuNSkgYW5kIGNvdWxk IGluY3JlYXNlIHRoZSBwcm9jZXNzaW5nIGxvYWQuDQo+ICANCj4gSW4gdmlldyBvZiB0aGVzZSBw b3RlbnRpYWwgaXNzdWVzLCBhbGwgaW1wbGVtZW50YXRpb25zIFNIT1VMRCBpbXBsZW1lbnQgcmF0 ZSBsaW1pdHMgb24gdGhlIGdlbmVyYXRpb24gb2YgU0ZDIHBhY2tldHMgd2l0aCBuZXh0IHByb3Rv Y29sIHNldCB0byBub25lLiBGdXJ0aGVybW9yZSwgdGhlc2UgcmF0ZSBsaW1pdHMgU0hPVUxEIGJl IGNvbmZpZ3VyYWJsZSBhbmQgYXBwbGllZCBwZXIgU0ZDIGFuZCBwZXIgYXBwbGljYXRpb24gc28g dGhhdCBvbmUgYXBwbGljYXRpb24gb24gb25lIFNGQyBkb2VzIG5vdCBlbmN1bWJlciBhIGRpZmZl cmVudCBhcHBsaWNhdGlvbiBvbiBhIGRpZmZlcmVudCBTRkMuDQoNCkkgdGhpbmsg4oCccGVyLVNG Q+KAnSBtZWFucyDigJxwZXItU0ZQ4oCdICB0aHJvdWdob3V0IGFib3ZlLiBIb3dldmVyLCB3aGF0 IGlzIHRoZSBtYXBwaW5nIG9mIGFwcGxpY2F0aW9ucz8gTm90IGFsbCBub2RlcyBtYXkgaGF2ZSBw ZXItYXBwbGljYXRpb24gdmlzaWJpbGl0eSAob3Iga25vd2xlZGdlKS4gDQoNCj4gV2hlbiBhbiBp bXBsZW1lbnRhdGlvbiBmaW5kcyB0aGF0IGl0IGlzIHVuYWJsZSB0byBnZW5lcmF0ZSBvciBzZW5k IGEgcGFja2V0IGl0IFNIT1VMRCBpbmNyZW1lbnQgYSBjb3VudGVyIHRoYXQgaXMgYWNjZXNzaWJs ZSBieSB0aGUgb3BlcmF0b3IsIGFuZCBNQVkgcmFpc2UgYW4gYWxlcnQgKGFsdGhvdWdoIHN1Y2gg YWxlcnRzIFNIT1VMRCwgdGhlbXNlbHZlcywgYmUgcmF0ZSBsaW1pdGVkKS4NCj4gIA0KDQpGcm9t IGFuIG9wZXJhdGlvbmFsIHN0YW5kcG9pbnQgd2hhdCBhcmUgdGhlIGRlZmF1bHRzIGZvciB0aGVz ZSBwcm9wb3NlZCBjb25maWd1cmF0aW9uIGtub2JzPw0KDQpBbm90aGVyIGltcG9ydGFudCBjb25z aWRlcmF0aW9uOiBpZiB0aGUgcHJvdG9jb2wtbm9uZSBwYWNrZXQgaXMgZm9yIGEgc3BlY2lmaWMg ZnVuY3Rpb24sIHdoYXQgYXJlIHRoZSBpbXBsaWNhdGlvbnMgdG8gdGhhdCBhcHBsaWNhdGlvbiBv ciBmdW5jdGlvbiBsZXZlcmFnaW5nIHRoaXMgbWVjaGFuaXNtPyBGb3IgZXhhbXBsZSwgaWYsIGFz IG1lbnRpb25lZCBhYm92ZSwgdGhpcyBpcyB1c2VkIGZvciBPQU0sIHJhdGUtbGltaW5nIHdpdGhv dXQgdmlzaWJpbGl0eSB0byB0aGUgT0FNIHJhdGUgbGltaXRpbmcgb3IgZnVuY3Rpb24gY2FuIHJl c3VsdCBpbiBhY3R1YWxseSBtb3JlIGNvbmdlc3Rpb24gd2l0aCBmYWxzZS1uZWdhdGl2ZXMsIG9z Y2lsbGF0aW9ucywgaW5zdGFiaWxpdHksIGV0Yy4NCg0KSSBzdHJvbmdseSByZWNvbW1lbmQgc29t ZSBwZXItdXNlIGltcGxpY2F0aW9ucywgYW5kIGEgU0hPVUxEIHVuZGVyc3RhbmQgaW1wbGljYXRp b25zIGJlZm9yZSBibGluZGx5IHJhdGUtbGltaXRpbmcuDQoNCj4gQWRkaXRpb25hbGx5LCBhbiBT RkMgbm9kZSBuZWVkcyB0byBwcm90ZWN0IGl0c2VsZiBhZ2FpbnN0IGFub3RoZXIgbm9kZSBpbiB0 aGUgbmV0d29yayBub3QgYXBwbHlpbmcgc3VpdGFibGUgcmF0ZSBsaW1pdHMuIFRoZXJlZm9yZSwg aW1wbGVtZW50YXRpb25zIFNIT1VMRCBhcHBseSBpbmNvbWluZyByYXRlIGxpbWl0cyBmb3IgU0ZD IHBhY2tldHMgd2l0aCBuZXh0IHByb3RvY29sIHNldCB0byBub25lLg0KDQpUaGlzIHBsYWNlcyBh biBpbnRlcmVzdGluZyByZXF1aXJlbWVudDogaXQgZG9lcyBub3QgYWxsb3cgZm9yIGluY3JlbWVu dGFsIGRlcGxveW1lbnQuIE5vdCBvbmx5IHByb3RvY29sLW5vbmUgZmVhdHVyZSBnZW5lcmF0aW5n IG5vZGVzIG5lZWQgdG8gYmUgdXBncmFkZWQsIGJ1dCBldmVyeSBub2RlIGF0IG9uY2UuDQoNCj4g U3VjaCByYXRlIGxpbWl0cyBTSE9VTEQgYmUgYXBwbGljYXRpb24tYXdhcmUsIHBlciBTRkMgb3Ig aW50ZXJmYWNlLA0KDQpUaGlzIGdyYW51bGFyaXR5IHNlZW1zIGJleW9uZCB3aGF0IG1pZ2h0IGJl IHBvc3NpYmxlLiBQZXItU0ZDIHNob3VsZCBiZSBwZXItU0ZQLiBOb3QgYWx3YXlzIHRoZXJl4oCZ cyBhcHAtYXdhcmVuZXNzLiBXaGF04oCZcyBhbiBpbnRlcmZhY2UgaW4gdGhpcyBjb250ZXh0Pw0K DQo+IGFuZCBTSE9VTEQgYmUgY29uZmlndXJhYmxlLCBidXQgaW1wbGVtZW50YXRpb25zIE1BWSBi ZSBtb3JlIHN1YnRsZSBpZiB0aGV5IGFyZSBhd2FyZSBvZiBpbnRlcm5hbCBwcm9jZXNzaW5nIGxv YWRzIGFuZCBoYXZlIGFjY2VzcyB0byBxdWV1ZXMvYnVmZmVycy4gSW4gYW55IGNhc2UsIHdoZW4g YW4gaW1wbGVtZW50YXRpb24gZHJvcHMgYSByZWNlaXZlZCBwYWNrZWQgYmVjYXVzZSBvZiB0aGVz ZSByYXRlIGxpbWl0cyBpdCBTSE9VTEQgaW5jcmVtZW50IGEgY291bnRlciB0aGF0IGlzIGFjY2Vz c2libGUgYnkgdGhlIG9wZXJhdG9yLCBhbmQgTUFZIHJhaXNlIGFuIGFsZXJ0IChhbHRob3VnaCBz dWNoIGFsZXJ0cyBTSE9VTEQsIHRoZW1zZWx2ZXMsIGJlIHJhdGUgbGltaXRlZCkuDQo+ID09PT0N Cj4gIA0KDQoNClRoYW5rcyBhZ2FpbiwgQWRyaWFuIQ0KDQpDYXJsb3MuDQoNCj4gIA0KPiAgDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBt YWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQoNCg== From nobody Fri Feb 16 08:15: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 1514E126579 for ; Fri, 16 Feb 2018 08:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 FyxUjteFKFat for ; Fri, 16 Feb 2018 08:15:51 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 0D62D120454 for ; Fri, 16 Feb 2018 08:15:51 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id h78so4744825lfg.6 for ; Fri, 16 Feb 2018 08:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to:cc; bh=m3dUGvzxL/mnuqlB7hJvkGFIl8TEx3f58M0a9MVYkdE=; b=Dck8PyEAVcoY5No+M36IEvlZ9d+rfM/UMVgR7EPh8L5F0owp2JA94QegylEeUToeOY AKjYNWxrnjJXjcXdu4FHY+mBlgVynDP2oYtyzzA93vfQIeV+jP5XoUjSLL37amnldtOj S4V2S18UXGpQLgxJByhGqoHkXWxnBBEC0mScqHdv8+CRts0PjLbu5UyRobYJOCs5f4xE Uj2mzivQarAwXJKAL3elM2MRvm6ZrCVjWHx1HDqyZ76tmNRVRKl3bblJyXev/JSPPC6f V5L+hPFeViZCJMq9r7Xy4HN+XCyQvdDtVjDcRtWosimBAJe0wodJI1ShYFuC6yjSQuSU GNnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:cc; bh=m3dUGvzxL/mnuqlB7hJvkGFIl8TEx3f58M0a9MVYkdE=; b=kQc/4YVPLDPfXVBlWv3bi4mxuCpBdvA9EvX98IufeH2r1z1D8rE9rnFGUJSQAWipUX q5TnS5UXL73IYY6Oegduk3NWTNgLqpr+/ugQW0iBtnzQ9vqJ0iXXcPm456TwW4DhWnT/ fxaGHtvMjCZPwX6Vj64MpQSE+7kzoS7HCNEsSQLoJHBW8Hj2hoCT/LunUFRM7vmxPd0J TA+6WJEiHdSNUoAhiZGImBZNUR83eWOoJAKNNPpRvwpj4SOlkXW6S6enOs3QsmAHTav3 Z7zttqbXGUniVh0FljT2Dmhc2NYHHS46ZUqJ/vC+aqZpyyVwPFLjjTQ2nmo9/6nb4SQ1 /cgQ== X-Gm-Message-State: APf1xPCEpWRXTpPH637I0C4v8snqqIJT/zWYspTdL1OYocQw/FS+uB/H 74Cclf08RfeduDWdmxjgQq6VhtuP+wR5XaTFWh4gyA== X-Google-Smtp-Source: AH8x224sHMTisFyj1rwH5v02QVAu3YGocWRVFB4HuoTrM1x0v9L9e7pxeBLSZMYZrwoQ7QmqHuAaG9irHLzE+oH0Odk= X-Received: by 10.46.115.14 with SMTP id o14mr4562729ljc.98.1518797749383; Fri, 16 Feb 2018 08:15:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.65.23 with HTTP; Fri, 16 Feb 2018 08:15:48 -0800 (PST) Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Fri, 16 Feb 2018 10:15:48 -0600 Message-ID: To: draft-ietf-sfc-hierarchical@tools.ietf.org Cc: sfc@ietf.org Content-Type: multipart/alternative; boundary="f4f5e80982f05675ba056556a827" Archived-At: Subject: [sfc] Editorial comments on hSFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 16:15:53 -0000 --f4f5e80982f05675ba056556a827 Content-Type: text/plain; charset="UTF-8" Hi, Here are my editorial comments: Page 3 transport- layer coordinate (typically, 5-tuple) stickiness to specific stateful SF instances. state the 5-tuple here, source @,destination @, etc identifying a flow as the 5-tuple is mentioned in other places also. The criteria for decomposition a domain into multiple SFC-enabled sub-domains are beyond the scope of this document. decomposition -> decomposing or decomposition of Appendix A1 acronyms of WAF, IPS, IDR are not defined. Regards, Behcet --f4f5e80982f05675ba056556a827 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Here are my editorial comments:

Page 3
transport-
   layer coordinate (typically, 5-tuple) stickiness to specific stateful
   SF instances.
state the 5-tuple here, source @,destination @, etc i= dentifying a flow as the 5-tuple is mentioned in other places also.

The criteria
   for decomposition a domain into multiple SFC-enabled sub-domains are
   beyond the scope of this document.
decomposition -> decomposing = or decomposition of=C2=A0

Appendix A1
acronyms of WAF, IPS, IDR are not defined.

Regards,
Behcet
--f4f5e80982f05675ba056556a827-- From nobody Fri Feb 16 13:31:46 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 0451912D7F0 for ; Fri, 16 Feb 2018 13:31:44 -0800 (PST) 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] 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 R3sVvlE5us3V for ; Fri, 16 Feb 2018 13:31:41 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 0E3A0124207 for ; Fri, 16 Feb 2018 13:31:40 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1GLVZNc007927; Fri, 16 Feb 2018 21:31:35 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 52C2F2203B; Fri, 16 Feb 2018 21:31:35 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS id 3D6432203A; Fri, 16 Feb 2018 21:31:35 +0000 (GMT) Received: from 950129200 ([12.250.207.42]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1GLVWWH024027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Feb 2018 21:31:34 GMT Reply-To: From: "Adrian Farrel" To: "'Carlos Pignataro \(cpignata\)'" Cc: , , , "'Adrian Farrel'" References: In-Reply-To: Date: Fri, 16 Feb 2018 21:31:32 -0000 Message-ID: <02ff01d3a76d$85334540$8f99cfc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEeAghMA36BwNs7P4hKcgh5BznyYQGbi9COpQXvVkA= Content-Language: en-gb X-Originating-IP: 12.250.207.42 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-23668.003 X-TM-AS-Result: No--30.159-10.0-31-10 X-imss-scan-details: No--30.159-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23668.003 X-TMASE-Result: 10--30.159200-10.000000 X-TMASE-MatchedRID: j4nUk6F+aLYkzrQfI6wWyOYAh37ZsBDCQnVGRb78vpAY0A95tjAn+1tE UzPReCEC7Ka5xr4UMFfvvUvE5L64eAldMc3Hj8/o8eSmTJSmEv2Zf5btvM85AQ2G3vz8l/IElaO mlCPm7PAfVoLo68RF+mD78H21qaZBM47ELEmzJqbFlCgYxEaGExyDrkIwjihbIFBEE5CFomK3WR FfMFpqrUXz+wEVxyExZ/ZB0hmIptxEiFIhxLPRUZ+EzsRrGT9IQKuv8uQBDjpCu3iUFrX0Dl4rZ +EaD3uZZpbK16kfjQFZHhlaIqB7ziP0K6pQJfW4syNb+yeIRAq7atxTbKDEIEENV4Lwnu7B1sTl zu9ctp2SQFK8SNZ7c4JnAxoBUhxpb4ixR8bvk/an1yJegn+laxSpYqhygmjpSgJpILqp94b6CmP nGAtSvo/m9lOHU6+/RzwG8ij76Rd5BTB1IjcvAqtK3oodxPaxM3PBQtDBME+hUoducQu06aVDtq tHNwDxWubHxfhv8egjrJgzgUvPOT879zET5UZxMIiU395I8H2KbuU19+RNrkfLNMv2kATUNVjVq 6WuIRSKbolQvMkWPGO1TJ3jzuz4X5sgyCY2UIRZluvuHEedhEGtrAxy5ENO8oXqbPkdKPKg0hWz UrznJxyZmuozlKyT+/ydMNttdO96+aDWc6WLsC97pb4g5HCtk9atiES99p1ct5jgLX72gKtpFYo Fv0AyfPldzhHm79vnz4Gg73O3vrGfCGOAcoovOp/QO0+WfieH7D1bP/FcOuVjd+HgnRW+xUkhFM O+oXssDZiXoLHVAF+24nCsUSFNt7DW3B48kkHdB/CxWTRRuyUIayx+Skid X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [sfc] Proposal for congestion control in draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 21:31:44 -0000 Hi Carlos, Thanks for the mail. It is important, IMHO, that this sort of change is = reviewed by the WG and not just slipped in through secret agreement = between the document editor and a Discussing AD. > Some of this text, however, seems pretty heavy-handed. My hand has always been heavy - it is the secret of good childcare. > > 6. Management and Congestion Control Considerations > > > > The mechanisms described in this document allow SFC-aware nodes in = an SFC > network to generate additional packets. While these packets are in = the nature of > in-band control packets >=20 > Are these =E2=80=9Ccontrol=E2=80=9D packets? These are packets with a = specific characteristic (not > with a specific function), and according to the Abstract, = =E2=80=9Cthis document illustrates > some of the functions that may be achieved=E2=80=9D. It does not say = =E2=80=9CThese are control > packets =E2=80=A6" Are we sure this is a question of meaningful semantics and not = philology? The text you quoted does not say that the packets are control packets. = But they *do* have that nature. Of course, we could take this opportunity to open the debate as to = whether OAM packets are control plane, data plane, or management plane = packets. That might be fun, but if life has taught me anything, it is = that we would not actually be advancing the discussion of the Internet. So, we don't need the commentary and can reduce to "These are not = intended to be sent frequently for any flow, but there is still a risk = that they might flood the network." > > and not intended to be sent frequently for any flow >=20 > Might be useful to define flow (by way of a pointer at least), since = it=E2=80=99s not used in > RFC 8300. I'm going to refer you back to Section 5.2, but not put a pointer in the = text. A reader who gets this far without having first read Section 5.2 = is lost. > > , there is still a risk that they might flood the network. >=20 > Flood the whole network? English usage? A single packet will not, of course, flood the whole network. But the whole (SFC) network might be flooded with such packets. > > For example, if an attempt is made to use this mechanism for = =E2=80=9Cper-packet > metadata=E2=80=9D (Section 5.6) then this might double the number of = packets in the > network. Similarly, if this mechanism is used for a form of aliveness = detection > OAM that requires very frequent test messages, then the number of = additional > messages may be very high. Such additional messages risk causing = congestion in > the network. > > > > The underlay network (that is the tunnels across the underlay = between SFC > nodes) will not >=20 > :s/will/may/g ? Now we are really into English usage! Did you mean "might" when you said "may", or did you mean to be = proscriptive? Anyway, I intended "will not". That is mainly because it "cannot" = without a form of DPI that is, I suspect, beyond the powers of most = routers today. But it is more civilised to say what it will or will not do than it is = to assert capability deficiencies :-) > > distinguish between data-carrying packets and those packets with = next > protocol set to none. All packets will be treated the same and will = need to fall > within the capabilities of the underlay network to process and forward = packets. >=20 > :s/will/may/g ? Text as intended. When underlays start to make forwarding decisions based on the payload = and not the encapsulation, then networking is in a mess! > > Nodes in the SFC overlay network will need to perform special = processing on > the additional packets according to their roles and according to the = application for > the metadata. For example, an SFF will likely only have to forward = per-SFC > metadata, while an SF >=20 > per-SFP instead of per-SFC? Yes, per 5.1. > > will need to extract it and process it as it would if the metadata = was carried in a > packet with user data. On the other hand, metadata might also be used = to cause > actions at all nodes (see Sections 5.3, 5.4 and 5.5) and could = increase the > processing load. > > > > In view of these potential issues, all implementations SHOULD = implement rate > limits on the generation of SFC packets with next protocol set to = none. > Furthermore, these rate limits SHOULD be configurable and applied per = SFC and > per application so that one application on one SFC does not encumber a = different > application on a different SFC. >=20 > I think =E2=80=9Cper-SFC=E2=80=9D means =E2=80=9Cper-SFP=E2=80=9D = throughout above. However, what is the > mapping of applications? Not all nodes may have per-application = visibility (or > knowledge). Yes, as above. > > When an implementation finds that it is unable to generate or send a = packet it > SHOULD increment a counter that is accessible by the operator, and MAY = raise an > alert (although such alerts SHOULD, themselves, be rate limited). >=20 > From an operational standpoint what are the defaults for these = proposed > configuration knobs? I don't believe this text defines any configuration knobs. I suppose you could make them so, but this text talks about = implementation. > Another important consideration: if the protocol-none packet is for a = specific > function, what are the implications to that application or function = leveraging this > mechanism? For example, if, as mentioned above, this is used for OAM, = rate- > liming without visibility to the OAM rate limiting or function can = result in actually > more congestion with false-negatives, oscillations, instability, etc. >=20 > I strongly recommend some per-use implications, and a SHOULD = understand > implications before blindly rate-limiting. Erm, the sentence previous to the one you quoted says... Furthermore, these rate limits=20 SHOULD be configurable and applied per SFP and per application so = that one application on=20 one SFP does not encumber a different application on a different = SFP. Change to ... encumber a different application on this or a different SFP. > > Additionally, an SFC node needs to protect itself against another = node in the > network not applying suitable rate limits. Therefore, implementations = SHOULD > apply incoming rate limits for SFC packets with next protocol set to = none. >=20 > This places an interesting requirement: it does not allow for = incremental > deployment. Not only protocol-none feature generating nodes need to be > upgraded, but every node at once. No, that would be crazy. No one would do that, and I don't think anyone would read it like that. Backward compatibility is what it is (see Section 4). Besides, "SHOULD" is very useful :-) > > Such rate limits SHOULD be application-aware, per SFC or interface, >=20 > This granularity seems beyond what might be possible. Per-SFC should = be per- > SFP. Not always there=E2=80=99s app-awareness. What=E2=80=99s an = interface in this context? Obviously, this is different from packet generation, but surely the = debate could center on where the rate limits are applied. You specifically worried about "one size fits all" rate limits, and that = is wise because you probably want to allow more packets for one use than = for another. OK to drop this to "MAY"? Hope this helps, Adrian From nobody Fri Feb 16 13:43: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 CC58512D94E; Fri, 16 Feb 2018 13:43:31 -0800 (PST) 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.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151881741177.1389.6711240505872310784@ietfa.amsl.com> Date: Fri, 16 Feb 2018 13:43:31 -0800 Archived-At: Subject: [sfc] I-D Action: draft-farrel-sfc-convent-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 21:43: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 : Operating the Network Service Header (NSH) with Next Protocol "None" Authors : Adrian Farrel John Drake Filename : draft-farrel-sfc-convent-06.txt Pages : 12 Date : 2018-02-16 Abstract: This document describes the use of the Network Service Header (NSH) in a Service Function Chaining (SFC) enabled network with no payload data and carrying only metadata. This is achieved by defining a new NSH "Next Protocol" type value of "None". This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-farrel-sfc-convent/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-farrel-sfc-convent-06 https://datatracker.ietf.org/doc/html/draft-farrel-sfc-convent-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-farrel-sfc-convent-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 16 13:50:28 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 E5196126BF3 for ; Fri, 16 Feb 2018 13:50:26 -0800 (PST) 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] 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 OyBydb0gk76w for ; Fri, 16 Feb 2018 13:50:25 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 AA7C1126BF0 for ; Fri, 16 Feb 2018 13:50:24 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1GLoKtY018441; Fri, 16 Feb 2018 21:50:20 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 75E382203A; Fri, 16 Feb 2018 21:50:19 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 607A522032; Fri, 16 Feb 2018 21:50:19 +0000 (GMT) Received: from 950129200 ([12.250.207.42]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1GLoHFX012438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Feb 2018 21:50:18 GMT Reply-To: From: "Adrian Farrel" To: "Alia Atlas" , Cc: , "Mirja Kuehlewind" References: <151881741177.1389.6711240505872310784@ietfa.amsl.com> In-Reply-To: <151881741177.1389.6711240505872310784@ietfa.amsl.com> Date: Fri, 16 Feb 2018 21:50:17 -0000 Message-ID: <030b01d3a770$2355fd10$6a01f730$@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: AQLPmpy1w7mZtG8d1aE20C+grsMPlqGvqqLg Content-Language: en-gb X-Originating-IP: 12.250.207.42 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-23668.003 X-TM-AS-Result: No--11.973-10.0-31-10 X-imss-scan-details: No--11.973-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23668.003 X-TMASE-Result: 10--11.972900-10.000000 X-TMASE-MatchedRID: TyMThhr6WqUlr4UAbUFME2tGlKM15tA2YpovC7zX5q9p9fSgVPjyMOKU 8nirgnDGTWLw2jvbfpyUyz0rNNhqfoLSdZH87OpglVHM/F6YkvRReWnUUdhI9dnT/cqUnvn3ynA ZOiRypkKjWurNKl88ZzTGqq7snJaETweK12oEGftWjqaf7FeZ1fx3eAlFiEvxut/GVGOoEnfWk2 S49P8eb8aYX5VNZEad92ILRMoZN4hDEf2XTEVmBj5ta6YWuLk2hEIiqNvBrmOInvV8Dy0ZaM8BS qN56oARorYqLspSVaAFoHn9QtC/ngi0xaFtKyGqQr2qXCJMSV86En2bnefhoKXJ9vMysD/Cp2rz U3zQ5k3uX/km0O1YYB5hmP6OM/PJTX7PJ/OU3vL+xOhjarOnHrHlqZYrZqdI+gtHj7OwNO31Kzk 40dEY9TXitgfesloRJ2zNKjbOFb+qdT7y11GsbfCAwynK/VnS X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [sfc] FW: I-D Action: draft-farrel-sfc-convent-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 21:50:27 -0000 This new version is a place marker as my plane takes off soon. Needs Carlos to say yay/nay. Needs Mirja to approve and clear. Adrian > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 16 February 2018 21:44 > To: i-d-announce@ietf.org > Cc: sfc@ietf.org > Subject: [sfc] I-D Action: draft-farrel-sfc-convent-06.txt > > > 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 : Operating the Network Service Header (NSH) with Next Protocol > "None" > Authors : Adrian Farrel > John Drake > Filename : draft-farrel-sfc-convent-06.txt > Pages : 12 > Date : 2018-02-16 > > Abstract: > This document describes the use of the Network Service Header (NSH) > in a Service Function Chaining (SFC) enabled network with no payload > data and carrying only metadata. This is achieved by defining a new > NSH "Next Protocol" type value of "None". > > This document illustrates some of the functions that may be achieved > or enhanced by this mechanism, but it does not provide an exhaustive > list of use cases, nor is it intended to be definitive about the > functions it describes. It is expected that other documents will > describe specific use cases in more detail and will define the > protocol mechanics for each use case. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrel-sfc-convent/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-farrel-sfc-convent-06 > https://datatracker.ietf.org/doc/html/draft-farrel-sfc-convent-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-farrel-sfc-convent-06 > > > 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/ > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 16 13:59: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 0EAF2124205 for ; Fri, 16 Feb 2018 13:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Fg918FMUiJPL for ; Fri, 16 Feb 2018 13:59:53 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741881241F3 for ; Fri, 16 Feb 2018 13:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12690; q=dns/txt; s=iport; t=1518818393; x=1520027993; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PuzlSo4KFbh1K5J6T3ORHSxc4Iph9/OEkRfx6O2m9OE=; b=Fs1mI1wXeXQT96tDu3HS4AejgX5JbEi/KW2b1RK1dafO1JeiHOUP6v6K CI1X61k7ULTrix1xSbY+xQE7Iw1GA5OIoWF9kZAsc7InYy/aL+gizxUOa 9SMyZVj6SiRPs0buG3AFxV/DZtY/5vmh1Hl6uYJx8xB5oDnAzmb8W+i7+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAQDaU4da/5pdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPgVYoCoNKiiWOBoICfBuWSYIWCoU7AhqCLFQYAQIBAQEBAQE?= =?us-ascii?q?CayiFIwEBAQECASMRMxIFCwIBCBgCAiYCAgIwFRABAQQOBRmKAAitRYIniQGCE?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BD4N4giiBV4FoKYF3WDaEfAcBARGDJDG?= =?us-ascii?q?CNAWZdzWKCQkCi12KK4IgikKHZZdyAhEZAYE7AR85gVFwFToqAYIYglQcggZ4i?= =?us-ascii?q?20CDRiBDYEZAQEB?= X-IronPort-AV: E=Sophos;i="5.46,520,1511827200"; d="scan'208";a="71417660" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2018 21:59:43 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w1GLxgJK017159 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Feb 2018 21:59:43 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; Fri, 16 Feb 2018 16:59:42 -0500 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; Fri, 16 Feb 2018 16:59:42 -0500 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel CC: "mls.ietf@gmail.com" , "ietf@kuehlewind.net" , "sfc@ietf.org" , Adrian Farrel Thread-Topic: [sfc] Proposal for congestion control in draft-farrel-sfc-convent Thread-Index: AdOkUWieWeFX83LaRmCLcmak7P8lwgDBVocAABAqWgAAAPs8AA== Date: Fri, 16 Feb 2018 21:59:42 +0000 Message-ID: References: <02ff01d3a76d$85334540$8f99cfc0$@olddog.co.uk> In-Reply-To: <02ff01d3a76d$85334540$8f99cfc0$@olddog.co.uk> 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: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Proposal for congestion control in draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 21:59:56 -0000 SGksIEFkcmlhbiwNCg0KPiBPbiBGZWIgMTYsIDIwMTgsIGF0IDQ6MzEgUE0sIEFkcmlhbiBGYXJy ZWwgPGFkcmlhbkBvbGRkb2cuY28udWs+IHdyb3RlOg0KPiANCj4gSGkgQ2FybG9zLA0KPiANCj4g VGhhbmtzIGZvciB0aGUgbWFpbC4gSXQgaXMgaW1wb3J0YW50LCBJTUhPLCB0aGF0IHRoaXMgc29y dCBvZiBjaGFuZ2UgaXMgcmV2aWV3ZWQgYnkgdGhlIFdHIGFuZCBub3QganVzdCBzbGlwcGVkIGlu IHRocm91Z2ggc2VjcmV0IGFncmVlbWVudCBiZXR3ZWVuIHRoZSBkb2N1bWVudCBlZGl0b3IgYW5k IGEgRGlzY3Vzc2luZyBBRC4NCg0KSW5kZWVkLiBJdCBpcyBtb3JlIHRoYW4gaW1wb3J0YW50IGFu ZCBub3QgYSBtYXR0ZXIgb2Ygb3BpbmlvbiwgSU1ITy4gDQoNClRoYW5rcyBmb3IgdGhlIENjIHRv IHRoZSBsaXN0IQ0KDQo+IA0KPj4gU29tZSBvZiB0aGlzIHRleHQsIGhvd2V2ZXIsIHNlZW1zIHBy ZXR0eSBoZWF2eS1oYW5kZWQuDQo+IA0KPiBNeSBoYW5kIGhhcyBhbHdheXMgYmVlbiBoZWF2eSAt IGl0IGlzIHRoZSBzZWNyZXQgb2YgZ29vZCBjaGlsZGNhcmUuDQo+IA0KDQo6LSgNCg0KRm9jdXNp bmcgYWdhaW4gb24gdGhlIG5ldyDigJxDb25nZXN0aW9uIHBhcmFncmFwaCIsIEnigJlkIHRyeSB0 byByaWdodC1zaXplIGl0LiBUaGFua3MgZm9yIGVudGVydGFpbmluZyBteSBmZWVkYmFjaywgc2Vl IGJlbG93Lg0KDQo+Pj4gNi4gTWFuYWdlbWVudCBhbmQgQ29uZ2VzdGlvbiBDb250cm9sIENvbnNp ZGVyYXRpb25zDQo+Pj4gDQo+Pj4gVGhlIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIHRoaXMgZG9j dW1lbnQgYWxsb3cgU0ZDLWF3YXJlIG5vZGVzIGluIGFuIFNGQw0KPj4gbmV0d29yayB0byBnZW5l cmF0ZSBhZGRpdGlvbmFsIHBhY2tldHMuICBXaGlsZSB0aGVzZSBwYWNrZXRzIGFyZSBpbiB0aGUg bmF0dXJlIG9mDQo+PiBpbi1iYW5kIGNvbnRyb2wgcGFja2V0cw0KPj4gDQo+PiBBcmUgdGhlc2Ug 4oCcY29udHJvbOKAnSBwYWNrZXRzPyBUaGVzZSBhcmUgcGFja2V0cyB3aXRoIGEgc3BlY2lmaWMg Y2hhcmFjdGVyaXN0aWMgKG5vdA0KPj4gd2l0aCBhIHNwZWNpZmljIGZ1bmN0aW9uKSwgYW5kIGFj Y29yZGluZyB0byB0aGUgQWJzdHJhY3QsIOKAnHRoaXMgZG9jdW1lbnQgaWxsdXN0cmF0ZXMNCj4+ IHNvbWUgb2YgdGhlIGZ1bmN0aW9ucyB0aGF0IG1heSBiZSBhY2hpZXZlZOKAnS4gSXQgZG9lcyBu b3Qgc2F5IOKAnFRoZXNlIGFyZSBjb250cm9sDQo+PiBwYWNrZXRzIOKApiINCj4gDQo+IEFyZSB3 ZSBzdXJlIHRoaXMgaXMgYSBxdWVzdGlvbiBvZiBtZWFuaW5nZnVsIHNlbWFudGljcyBhbmQgbm90 IHBoaWxvbG9neT8NCg0KSXMgdGhpcyBxdWVzdGlvbiBhbiBhbnN3ZXIgdG8gbXkgcXVlc3Rpb24g b3IgYSBuZXcgcXVlc3Rpb24gb24gaXRzIG93biByaWdodD8gQXJlIHdlIGRpc2N1c3NpbmcgdGhl IGNvbW1lbnQgb3IgdGhlIGRpc2N1c3Npb24/DQoNCkl0IHJlYWxseSBpcyBxdWl0ZSBzaW1wbGUs IGFuZCBJIGRpZCBub3QgbWVhbiB0byBoaWRlIGFueSB0ZXh0IGluLWJldHdlZW4gbGluZXMuIFRo ZSBwcm9wb3NhbCBzYXlzICJhcmUgaW4gdGhlIG5hdHVyZSBvZiBpbi1iYW5kIGNvbnRyb2wgcGFj a2V0c+KAnSBhbmQgSSB0aGluayB0aGF0IGlzIHRvbyBsaW1pdGluZy4gU28uLi4NCg0KPiANCj4g VGhlIHRleHQgeW91IHF1b3RlZCBkb2VzIG5vdCBzYXkgdGhhdCB0aGUgcGFja2V0cyBhcmUgY29u dHJvbCBwYWNrZXRzLiBCdXQgdGhleSAqZG8qIGhhdmUgdGhhdCBuYXR1cmUuDQo+IA0KPiBPZiBj b3Vyc2UsIHdlIGNvdWxkIHRha2UgdGhpcyBvcHBvcnR1bml0eSB0byBvcGVuIHRoZSBkZWJhdGUg YXMgdG8gd2hldGhlciBPQU0gcGFja2V0cyBhcmUgY29udHJvbCBwbGFuZSwgZGF0YSBwbGFuZSwg b3IgbWFuYWdlbWVudCBwbGFuZSBwYWNrZXRzLiBUaGF0IG1pZ2h0IGJlIGZ1biwgYnV0IGlmIGxp ZmUgaGFzIHRhdWdodCBtZSBhbnl0aGluZywgaXQgaXMgdGhhdCB3ZSB3b3VsZCBub3QgYWN0dWFs bHkgYmUgYWR2YW5jaW5nIHRoZSBkaXNjdXNzaW9uIG9mIHRoZSBJbnRlcm5ldC4NCj4gDQo+IFNv LCB3ZSBkb24ndCBuZWVkIHRoZSBjb21tZW50YXJ5IGFuZCBjYW4gcmVkdWNlIHRvICJUaGVzZSBh cmUgbm90IGludGVuZGVkIHRvIGJlIHNlbnQgZnJlcXVlbnRseSBmb3IgYW55IGZsb3csIGJ1dCB0 aGVyZSBpcyAgc3RpbGwgYSByaXNrIHRoYXQgdGhleSBtaWdodCBmbG9vZCB0aGUgbmV0d29yay7i gJ0NCg0K4oCmIHRoYXQgc291bmRzIGdyZWF0IDotKSANCg0KPiANCj4+PiBhbmQgbm90IGludGVu ZGVkIHRvIGJlIHNlbnQgZnJlcXVlbnRseSBmb3IgYW55IGZsb3cNCj4+IA0KPj4gTWlnaHQgYmUg dXNlZnVsIHRvIGRlZmluZSBmbG93IChieSB3YXkgb2YgYSBwb2ludGVyIGF0IGxlYXN0KSwgc2lu Y2UgaXTigJlzIG5vdCB1c2VkIGluDQo+PiBSRkMgODMwMC4NCj4gDQo+IEknbSBnb2luZyB0byBy ZWZlciB5b3UgYmFjayB0byBTZWN0aW9uIDUuMiwgYnV0IG5vdCBwdXQgYSBwb2ludGVyIGluIHRo ZSB0ZXh0LiBBIHJlYWRlciB3aG8gZ2V0cyB0aGlzIGZhciB3aXRob3V0IGhhdmluZyBmaXJzdCBy ZWFkIFNlY3Rpb24gNS4yIGlzIGxvc3QuDQo+IA0KDQpGYWlyIGVub3VnaC4NCg0KPj4+ICwgdGhl cmUgaXMgc3RpbGwgYSByaXNrIHRoYXQgdGhleSBtaWdodCBmbG9vZCB0aGUgbmV0d29yay4NCj4+ IA0KPj4gRmxvb2QgdGhlIHdob2xlIG5ldHdvcms/DQo+IA0KPiBFbmdsaXNoIHVzYWdlPw0KPiBB IHNpbmdsZSBwYWNrZXQgd2lsbCBub3QsIG9mIGNvdXJzZSwgZmxvb2QgdGhlIHdob2xlIG5ldHdv cmsuDQo+IEJ1dCB0aGUgd2hvbGUgKFNGQykgbmV0d29yayBtaWdodCBiZSBmbG9vZGVkIHdpdGgg c3VjaCBwYWNrZXRzLg0KDQpBaCwgSSB1bmRlcnN0b29kIG5ldHdvcmsgdG8gYmUgKnRoZSogbmV0 d29yayAoZmFicmljIGFsbCB0aGUgd2F5IHRvIGxheWVyIHplcm8pLCBub3QgdGhlIOKAnFNGQyBu ZXR3b3Jr4oCdLg0KDQpJbiBhbnkgY2FzZSwgeW91IGFyZSByaWdodCwgdGhlcmUgaXMgYSByaXNr IHRoYXQgdGhlIG5ldHdvcmsgbWlnaHQgZ2V0IGZsb29kZWQuIE5vIGNvbmNlcm4uDQoNCj4gDQo+ Pj4gRm9yIGV4YW1wbGUsIGlmIGFuIGF0dGVtcHQgaXMgbWFkZSB0byB1c2UgdGhpcyBtZWNoYW5p c20gZm9yIOKAnHBlci1wYWNrZXQNCj4+IG1ldGFkYXRh4oCdIChTZWN0aW9uIDUuNikgdGhlbiB0 aGlzIG1pZ2h0IGRvdWJsZSB0aGUgbnVtYmVyIG9mIHBhY2tldHMgaW4gdGhlDQo+PiBuZXR3b3Jr LiBTaW1pbGFybHksIGlmIHRoaXMgbWVjaGFuaXNtIGlzIHVzZWQgZm9yIGEgZm9ybSBvZiBhbGl2 ZW5lc3MgZGV0ZWN0aW9uDQo+PiBPQU0gdGhhdCByZXF1aXJlcyB2ZXJ5IGZyZXF1ZW50IHRlc3Qg bWVzc2FnZXMsIHRoZW4gdGhlIG51bWJlciBvZiBhZGRpdGlvbmFsDQo+PiBtZXNzYWdlcyBtYXkg YmUgdmVyeSBoaWdoLiBTdWNoIGFkZGl0aW9uYWwgbWVzc2FnZXMgcmlzayBjYXVzaW5nIGNvbmdl c3Rpb24gaW4NCj4+IHRoZSBuZXR3b3JrLg0KPj4+IA0KPj4+IFRoZSB1bmRlcmxheSBuZXR3b3Jr ICh0aGF0IGlzIHRoZSB0dW5uZWxzIGFjcm9zcyB0aGUgdW5kZXJsYXkgYmV0d2VlbiBTRkMNCj4+ IG5vZGVzKSB3aWxsIG5vdA0KPj4gDQo+PiA6cy93aWxsL21heS9nID8NCj4gDQo+IE5vdyB3ZSBh cmUgcmVhbGx5IGludG8gRW5nbGlzaCB1c2FnZSENCj4gRGlkIHlvdSBtZWFuICJtaWdodCIgd2hl biB5b3Ugc2FpZCAibWF5Iiwgb3IgZGlkIHlvdSBtZWFuIHRvIGJlIHByb3NjcmlwdGl2ZT8NCj4g DQo+IEFueXdheSwgSSBpbnRlbmRlZCAid2lsbCBub3QiLiBUaGF0IGlzIG1haW5seSBiZWNhdXNl IGl0ICJjYW5ub3QiIHdpdGhvdXQgYSBmb3JtIG9mIERQSSB0aGF0IGlzLCBJIHN1c3BlY3QsIGJl eW9uZCB0aGUgcG93ZXJzIG9mIG1vc3Qgcm91dGVycyB0b2RheS4NCg0KVGhpbmtpbmcgdGhlIHRo ZSBzcGVjIG1pZ2h0IHN1cnZpdmUgbW9yZSB0aGFuIHRvZGF5LCBhbmQga25vd2luZyBEUEkgY2Fw YWJpbGl0aWVzIHRoYXQgZG8gdGhpcyBlYXNpbHksIGFzIHdlbGwgYXMgb3RoZXIgcG90ZW50aWFs IG1lY2hhbmlzbXMgKHN1Y2ggYXMgcmVmbGVjdGluZyB0aGUgcHJvdG9jb2wgaW50byBzb21lIHVu ZGVybGF5IGZpZWxkKSwgSSB0aGluayB0aGVyZSBhcmUgY2FzZXMgaW4gd2hpY2gg4oCcaXQgd2ls bOKAnSwgYW5kIGhlbmNlIOKAnHdpbGwgbm904oCdIGlzIGluY29ycmVjdCBhcyBhIGRlZmluaXRp dmUgc3RhdGVtZW50Lg0KDQpJIGp1c3QgaW50ZW5kZWQgc29tZSBmb3J3YXJkIGNvbXBhdGliaWxp dHkgYW5kIHdpZ2dsZSByb29tLg0KDQo+IA0KPiBCdXQgaXQgaXMgbW9yZSBjaXZpbGlzZWQgdG8g c2F5IHdoYXQgaXQgd2lsbCBvciB3aWxsIG5vdCBkbyB0aGFuIGl0IGlzIHRvIGFzc2VydCBjYXBh YmlsaXR5IGRlZmljaWVuY2llcyA6LSkNCj4gDQo+Pj4gZGlzdGluZ3Vpc2ggYmV0d2VlbiBkYXRh LWNhcnJ5aW5nIHBhY2tldHMgYW5kIHRob3NlIHBhY2tldHMgd2l0aCBuZXh0DQo+PiBwcm90b2Nv bCBzZXQgdG8gbm9uZS4gQWxsIHBhY2tldHMgd2lsbCBiZSB0cmVhdGVkIHRoZSBzYW1lIGFuZCB3 aWxsIG5lZWQgdG8gZmFsbA0KPj4gd2l0aGluIHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlIHVuZGVy bGF5IG5ldHdvcmsgdG8gcHJvY2VzcyBhbmQgZm9yd2FyZCBwYWNrZXRzLg0KPj4gDQo+PiA6cy93 aWxsL21heS9nID8NCj4gDQo+IFRleHQgYXMgaW50ZW5kZWQuDQo+IFdoZW4gdW5kZXJsYXlzIHN0 YXJ0IHRvIG1ha2UgZm9yd2FyZGluZyBkZWNpc2lvbnMgYmFzZWQgb24gdGhlIHBheWxvYWQgYW5k IG5vdCB0aGUgZW5jYXBzdWxhdGlvbiwgdGhlbiBuZXR3b3JraW5nIGlzIGluIGEgbWVzcyENCj4g DQoNCkJ1dCB5b3UgYXJlIGFzc3VtaW5nIHRoYXQgZGVjaXNpb25zIGFyZSBiYXNlZCBvbiB0aGUg cGF5bG9hZC4gSXQgaXMgcG9zc2libGUgdGhhdCB0aGUgZW5jYXBzdWxhdGlvbiByZWZsZWN0cyAv IGNvcGllcyAvIGxldHMtYmxlZWQtaW4gZmllbGRzIGZyb20gdGhlIHBheWxvYWQgYW5kIHRoZSBk ZWNpc2lvbiBpcyBiYXNlZCBvbiB0aGUgZW5jYXBzdWxhdGlvbi4gT3Igb3RoZXIgY3JlYXRpdmUg d2F5cy4gSSB0aGluayB0aGF0IGJlaW5nIHRvbyBuYXJyb3cgaW4gc3BlY3MgY2FuIGJhY2tmaXJl Lg0KDQo+Pj4gTm9kZXMgaW4gdGhlIFNGQyBvdmVybGF5IG5ldHdvcmsgd2lsbCBuZWVkIHRvIHBl cmZvcm0gc3BlY2lhbCBwcm9jZXNzaW5nIG9uDQo+PiB0aGUgYWRkaXRpb25hbCBwYWNrZXRzIGFj Y29yZGluZyB0byB0aGVpciByb2xlcyBhbmQgYWNjb3JkaW5nIHRvIHRoZSBhcHBsaWNhdGlvbiBm b3INCj4+IHRoZSBtZXRhZGF0YS4gRm9yIGV4YW1wbGUsIGFuIFNGRiB3aWxsIGxpa2VseSBvbmx5 IGhhdmUgdG8gZm9yd2FyZCBwZXItU0ZDDQo+PiBtZXRhZGF0YSwgd2hpbGUgYW4gU0YNCj4+IA0K Pj4gcGVyLVNGUCBpbnN0ZWFkIG9mIHBlci1TRkM/DQo+IA0KPiBZZXMsIHBlciA1LjEuDQoNClRo YW5rcy4vDQoNCj4gDQo+Pj4gd2lsbCBuZWVkIHRvIGV4dHJhY3QgaXQgYW5kIHByb2Nlc3MgaXQg YXMgaXQgd291bGQgaWYgdGhlIG1ldGFkYXRhIHdhcyBjYXJyaWVkIGluIGENCj4+IHBhY2tldCB3 aXRoIHVzZXIgZGF0YS4gT24gdGhlIG90aGVyIGhhbmQsIG1ldGFkYXRhIG1pZ2h0IGFsc28gYmUg dXNlZCB0byBjYXVzZQ0KPj4gYWN0aW9ucyBhdCBhbGwgbm9kZXMgKHNlZSBTZWN0aW9ucyA1LjMs IDUuNCBhbmQgNS41KSBhbmQgY291bGQgaW5jcmVhc2UgdGhlDQo+PiBwcm9jZXNzaW5nIGxvYWQu DQo+Pj4gDQo+Pj4gSW4gdmlldyBvZiB0aGVzZSBwb3RlbnRpYWwgaXNzdWVzLCBhbGwgaW1wbGVt ZW50YXRpb25zIFNIT1VMRCBpbXBsZW1lbnQgcmF0ZQ0KPj4gbGltaXRzIG9uIHRoZSBnZW5lcmF0 aW9uIG9mIFNGQyBwYWNrZXRzIHdpdGggbmV4dCBwcm90b2NvbCBzZXQgdG8gbm9uZS4NCj4+IEZ1 cnRoZXJtb3JlLCB0aGVzZSByYXRlIGxpbWl0cyBTSE9VTEQgYmUgY29uZmlndXJhYmxlIGFuZCBh cHBsaWVkIHBlciBTRkMgYW5kDQo+PiBwZXIgYXBwbGljYXRpb24gc28gdGhhdCBvbmUgYXBwbGlj YXRpb24gb24gb25lIFNGQyBkb2VzIG5vdCBlbmN1bWJlciBhIGRpZmZlcmVudA0KPj4gYXBwbGlj YXRpb24gb24gYSBkaWZmZXJlbnQgU0ZDLg0KPj4gDQo+PiBJIHRoaW5rIOKAnHBlci1TRkPigJ0g bWVhbnMg4oCccGVyLVNGUOKAnSAgdGhyb3VnaG91dCBhYm92ZS4gSG93ZXZlciwgd2hhdCBpcyB0 aGUNCj4+IG1hcHBpbmcgb2YgYXBwbGljYXRpb25zPyBOb3QgYWxsIG5vZGVzIG1heSBoYXZlIHBl ci1hcHBsaWNhdGlvbiB2aXNpYmlsaXR5IChvcg0KPj4ga25vd2xlZGdlKS4NCj4gDQo+IFllcywg YXMgYWJvdmUuDQoNClRoYW5rcyENCg0KPiANCj4+PiBXaGVuIGFuIGltcGxlbWVudGF0aW9uIGZp bmRzIHRoYXQgaXQgaXMgdW5hYmxlIHRvIGdlbmVyYXRlIG9yIHNlbmQgYSBwYWNrZXQgaXQNCj4+ IFNIT1VMRCBpbmNyZW1lbnQgYSBjb3VudGVyIHRoYXQgaXMgYWNjZXNzaWJsZSBieSB0aGUgb3Bl cmF0b3IsIGFuZCBNQVkgcmFpc2UgYW4NCj4+IGFsZXJ0IChhbHRob3VnaCBzdWNoIGFsZXJ0cyBT SE9VTEQsIHRoZW1zZWx2ZXMsIGJlIHJhdGUgbGltaXRlZCkuDQo+PiANCj4+IEZyb20gYW4gb3Bl cmF0aW9uYWwgc3RhbmRwb2ludCB3aGF0IGFyZSB0aGUgZGVmYXVsdHMgZm9yIHRoZXNlIHByb3Bv c2VkDQo+PiBjb25maWd1cmF0aW9uIGtub2JzPw0KPiANCj4gSSBkb24ndCBiZWxpZXZlIHRoaXMg dGV4dCBkZWZpbmVzIGFueSBjb25maWd1cmF0aW9uIGtub2JzLg0KDQpJIG1lYW50IOKAnHRoZXNl IHJhdGUgbGltaXRzIFNIT1VMRCBiZSBjb25maWd1cmFibGXigJ0uIEkgd2FzIHRoaW5raW5nIG9m IFJGQyA1NzA2LCBBcHBlbmRpeCBBLjEsIGl0ZW0gIzksIHN1Yi1pdGVtIDEuDQoNCj4gSSBzdXBw b3NlIHlvdSBjb3VsZCBtYWtlIHRoZW0gc28sIGJ1dCB0aGlzIHRleHQgdGFsa3MgYWJvdXQgaW1w bGVtZW50YXRpb24uDQo+IA0KPj4gQW5vdGhlciBpbXBvcnRhbnQgY29uc2lkZXJhdGlvbjogaWYg dGhlIHByb3RvY29sLW5vbmUgcGFja2V0IGlzIGZvciBhIHNwZWNpZmljDQo+PiBmdW5jdGlvbiwg d2hhdCBhcmUgdGhlIGltcGxpY2F0aW9ucyB0byB0aGF0IGFwcGxpY2F0aW9uIG9yIGZ1bmN0aW9u IGxldmVyYWdpbmcgdGhpcw0KPj4gbWVjaGFuaXNtPyBGb3IgZXhhbXBsZSwgaWYsIGFzIG1lbnRp b25lZCBhYm92ZSwgdGhpcyBpcyB1c2VkIGZvciBPQU0sIHJhdGUtDQo+PiBsaW1pbmcgd2l0aG91 dCB2aXNpYmlsaXR5IHRvIHRoZSBPQU0gcmF0ZSBsaW1pdGluZyBvciBmdW5jdGlvbiBjYW4gcmVz dWx0IGluIGFjdHVhbGx5DQo+PiBtb3JlIGNvbmdlc3Rpb24gd2l0aCBmYWxzZS1uZWdhdGl2ZXMs IG9zY2lsbGF0aW9ucywgaW5zdGFiaWxpdHksIGV0Yy4NCj4+IA0KPj4gSSBzdHJvbmdseSByZWNv bW1lbmQgc29tZSBwZXItdXNlIGltcGxpY2F0aW9ucywgYW5kIGEgU0hPVUxEIHVuZGVyc3RhbmQN Cj4+IGltcGxpY2F0aW9ucyBiZWZvcmUgYmxpbmRseSByYXRlLWxpbWl0aW5nLg0KPiANCj4gRXJt LCB0aGUgc2VudGVuY2UgcHJldmlvdXMgdG8gdGhlIG9uZSB5b3UgcXVvdGVkIHNheXMuLi4NCj4g DQo+ICAgICAgIEZ1cnRoZXJtb3JlLCB0aGVzZSByYXRlIGxpbWl0cyANCj4gICAgICAgU0hPVUxE IGJlIGNvbmZpZ3VyYWJsZSBhbmQgYXBwbGllZCBwZXIgU0ZQIGFuZCBwZXIgYXBwbGljYXRpb24g c28gdGhhdCBvbmUgYXBwbGljYXRpb24gb24gDQo+ICAgICAgIG9uZSBTRlAgZG9lcyBub3QgZW5j dW1iZXIgYSBkaWZmZXJlbnQgYXBwbGljYXRpb24gb24gYSBkaWZmZXJlbnQgU0ZQLg0KPiANCj4g Q2hhbmdlIHRvIC4uLg0KPiAgICAgZW5jdW1iZXIgYSBkaWZmZXJlbnQgYXBwbGljYXRpb24gb24g dGhpcyBvciBhIGRpZmZlcmVudCBTRlAuDQoNClRoYW5rcyENCg0KPiANCj4+PiBBZGRpdGlvbmFs bHksIGFuIFNGQyBub2RlIG5lZWRzIHRvIHByb3RlY3QgaXRzZWxmIGFnYWluc3QgYW5vdGhlciBu b2RlIGluIHRoZQ0KPj4gbmV0d29yayBub3QgYXBwbHlpbmcgc3VpdGFibGUgcmF0ZSBsaW1pdHMu IFRoZXJlZm9yZSwgaW1wbGVtZW50YXRpb25zIFNIT1VMRA0KPj4gYXBwbHkgaW5jb21pbmcgcmF0 ZSBsaW1pdHMgZm9yIFNGQyBwYWNrZXRzIHdpdGggbmV4dCBwcm90b2NvbCBzZXQgdG8gbm9uZS4N Cj4+IA0KPj4gVGhpcyBwbGFjZXMgYW4gaW50ZXJlc3RpbmcgcmVxdWlyZW1lbnQ6IGl0IGRvZXMg bm90IGFsbG93IGZvciBpbmNyZW1lbnRhbA0KPj4gZGVwbG95bWVudC4gTm90IG9ubHkgcHJvdG9j b2wtbm9uZSBmZWF0dXJlIGdlbmVyYXRpbmcgbm9kZXMgbmVlZCB0byBiZQ0KPj4gdXBncmFkZWQs IGJ1dCBldmVyeSBub2RlIGF0IG9uY2UuDQo+IA0KPiBObywgdGhhdCB3b3VsZCBiZSBjcmF6eS4N Cj4gTm8gb25lIHdvdWxkIGRvIHRoYXQsIGFuZCBJIGRvbid0IHRoaW5rIGFueW9uZSB3b3VsZCBy ZWFkIGl0IGxpa2UgdGhhdC4NCj4gQmFja3dhcmQgY29tcGF0aWJpbGl0eSBpcyB3aGF0IGl0IGlz IChzZWUgU2VjdGlvbiA0KS4NCj4gDQo+IEJlc2lkZXMsICJTSE9VTEQiIGlzIHZlcnkgdXNlZnVs IDotKQ0KPiANCg0KQWNrLg0KDQo+Pj4gU3VjaCByYXRlIGxpbWl0cyBTSE9VTEQgYmUgYXBwbGlj YXRpb24tYXdhcmUsIHBlciBTRkMgb3IgaW50ZXJmYWNlLA0KPj4gDQo+PiBUaGlzIGdyYW51bGFy aXR5IHNlZW1zIGJleW9uZCB3aGF0IG1pZ2h0IGJlIHBvc3NpYmxlLiBQZXItU0ZDIHNob3VsZCBi ZSBwZXItDQo+PiBTRlAuIE5vdCBhbHdheXMgdGhlcmXigJlzIGFwcC1hd2FyZW5lc3MuIFdoYXTi gJlzIGFuIGludGVyZmFjZSBpbiB0aGlzIGNvbnRleHQ/DQo+IA0KPiBPYnZpb3VzbHksIHRoaXMg aXMgZGlmZmVyZW50IGZyb20gcGFja2V0IGdlbmVyYXRpb24sIGJ1dCBzdXJlbHkgdGhlIGRlYmF0 ZSBjb3VsZCBjZW50ZXIgb24gd2hlcmUgdGhlIHJhdGUgbGltaXRzIGFyZSBhcHBsaWVkLg0KPiAN Cj4gWW91IHNwZWNpZmljYWxseSB3b3JyaWVkIGFib3V0ICJvbmUgc2l6ZSBmaXRzIGFsbCIgcmF0 ZSBsaW1pdHMsIGFuZCB0aGF0IGlzIHdpc2UgYmVjYXVzZSB5b3UgcHJvYmFibHkgd2FudCB0byBh bGxvdyBtb3JlIHBhY2tldHMgZm9yIG9uZSB1c2UgdGhhbiBmb3IgYW5vdGhlci4NCg0KWW91IGdv dCBpdC4NCg0KPiANCj4gT0sgdG8gZHJvcCB0aGlzIHRvICJNQVnigJ0/DQoNClRoYXQgd291bGQg YmUgcGVyZmVjdC4NCg0KTWFueSB0aGFua3MgYWdhaW4sIEFkcmlhbiENCg0KQ2FybG9zLg0KDQo+ IA0KPiBIb3BlIHRoaXMgaGVscHMsDQo+IEFkcmlhbg0KPiANCg0K From nobody Fri Feb 16 14:02:16 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 E8601126BF0 for ; Fri, 16 Feb 2018 14:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 jZm9OpJDxjQh for ; Fri, 16 Feb 2018 14:02:10 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B70124205 for ; Fri, 16 Feb 2018 14:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3524; q=dns/txt; s=iport; t=1518818530; x=1520028130; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hp0J86/jFV+T+XBVnHgCHUriBFSXaiEs80Va5a/cdk4=; b=WHQjSPgr7UuRMXxujGo4uf84eL0uPnrS8jLlLWsBWdn8ixQSzDnWKUrQ tzEqQRKVUjxl/rac8a8Zhd6OdvMAtiClLxrbBEmWaNf7Ho/PuddBYh+o4 HRkrSuDPRk7LIB+5a7/2ZKYF1gK+SvVRHNDTxiKf0tb8jpzPs8WEGEhy6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAwDaU4da/5xdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPZnAoCoNKmCuBWyeBF5ZJghYKGAuFGAIagixVFwECAQE?= =?us-ascii?q?BAQEBAmsohSMBAQEBAgEBASEROgsFBwQCAQgRBAEBAQICIwMCAgIlCxQBCAg?= =?us-ascii?q?CBA4FihkIEK01gieJAYITAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPg3iCKIF?= =?us-ascii?q?XghEMgnmDMAEBAgEBF4RtMYI0BaQ1CQKIIo1mgiBnhUOLfY4GiWwCERkBgTs?= =?us-ascii?q?BIAE3gVFwFRkhKgGCGAmEbXiNIYEZAQEB?= X-IronPort-AV: E=Sophos;i="5.46,520,1511827200"; d="scan'208";a="356831261" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2018 22:02:09 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w1GM283C020432 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Feb 2018 22:02:09 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 16 Feb 2018 17:02:08 -0500 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; Fri, 16 Feb 2018 17:02:08 -0500 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel CC: Alia Atlas , "sfc@ietf.org" , "Mirja Kuehlewind" Thread-Topic: [sfc] I-D Action: draft-farrel-sfc-convent-06.txt Thread-Index: AQHTp29K29i8Xg08rUmHeJSAusjx5aOn5TaAgAADUAA= Date: Fri, 16 Feb 2018 22:02:08 +0000 Message-ID: <1995278D-82AC-4896-ADD3-04B49748F71F@cisco.com> References: <151881741177.1389.6711240505872310784@ietfa.amsl.com> <030b01d3a770$2355fd10$6a01f730$@olddog.co.uk> In-Reply-To: <030b01d3a770$2355fd10$6a01f730$@olddog.co.uk> 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: text/plain; charset="utf-8" Content-ID: <7BF9CEB39A4779448453B81FE631DEDF@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-farrel-sfc-convent-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 22:02:14 -0000 DQoNCj4gT24gRmViIDE2LCAyMDE4LCBhdCA0OjUwIFBNLCBBZHJpYW4gRmFycmVsIDxhZHJpYW5A b2xkZG9nLmNvLnVrPiB3cm90ZToNCj4gDQo+IFRoaXMgbmV3IHZlcnNpb24gaXMgYSBwbGFjZSBt YXJrZXIgYXMgbXkgcGxhbmUgdGFrZXMgb2ZmIHNvb24uDQo+IA0KPiBOZWVkcyBDYXJsb3MgdG8g c2F5IHlheS9uYXkuDQoNCllheSDigJQgc2FmZSBmbGlnaHQhDQoNCkMuDQoNCj4gTmVlZHMgTWly amEgdG8gYXBwcm92ZSBhbmQgY2xlYXIuDQo+IA0KPiBBZHJpYW4NCj4gDQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+IFNlbnQ6IDE2IEZl YnJ1YXJ5IDIwMTggMjE6NDQNCj4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+IENjOiBz ZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFtzZmNdIEktRCBBY3Rpb246IGRyYWZ0LWZhcnJlbC1z ZmMtY29udmVudC0wNi50eHQNCj4+IA0KPj4gDQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMu DQo+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIENo YWluaW5nIFdHIG9mIHRoZSBJRVRGLg0KPj4gDQo+PiAgICAgICAgVGl0bGUgICAgICAgICAgIDog T3BlcmF0aW5nIHRoZSBOZXR3b3JrIFNlcnZpY2UgSGVhZGVyIChOU0gpIHdpdGggTmV4dA0KPiBQ cm90b2NvbA0KPj4gIk5vbmUiDQo+PiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogQWRyaWFuIEZh cnJlbA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgIEpvaG4gRHJha2UNCj4+IAlGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1mYXJyZWwtc2ZjLWNvbnZlbnQtMDYudHh0DQo+PiAJUGFnZXMgICAg ICAgICAgIDogMTINCj4+IAlEYXRlICAgICAgICAgICAgOiAyMDE4LTAyLTE2DQo+PiANCj4+IEFi c3RyYWN0Og0KPj4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNlIG9mIHRoZSBOZXR3 b3JrIFNlcnZpY2UgSGVhZGVyIChOU0gpDQo+PiAgIGluIGEgU2VydmljZSBGdW5jdGlvbiBDaGFp bmluZyAoU0ZDKSBlbmFibGVkIG5ldHdvcmsgd2l0aCBubyBwYXlsb2FkDQo+PiAgIGRhdGEgYW5k IGNhcnJ5aW5nIG9ubHkgbWV0YWRhdGEuICBUaGlzIGlzIGFjaGlldmVkIGJ5IGRlZmluaW5nIGEg bmV3DQo+PiAgIE5TSCAiTmV4dCBQcm90b2NvbCIgdHlwZSB2YWx1ZSBvZiAiTm9uZSIuDQo+PiAN Cj4+ICAgVGhpcyBkb2N1bWVudCBpbGx1c3RyYXRlcyBzb21lIG9mIHRoZSBmdW5jdGlvbnMgdGhh dCBtYXkgYmUgYWNoaWV2ZWQNCj4+ICAgb3IgZW5oYW5jZWQgYnkgdGhpcyBtZWNoYW5pc20sIGJ1 dCBpdCBkb2VzIG5vdCBwcm92aWRlIGFuIGV4aGF1c3RpdmUNCj4+ICAgbGlzdCBvZiB1c2UgY2Fz ZXMsIG5vciBpcyBpdCBpbnRlbmRlZCB0byBiZSBkZWZpbml0aXZlIGFib3V0IHRoZQ0KPj4gICBm dW5jdGlvbnMgaXQgZGVzY3JpYmVzLiAgSXQgaXMgZXhwZWN0ZWQgdGhhdCBvdGhlciBkb2N1bWVu dHMgd2lsbA0KPj4gICBkZXNjcmliZSBzcGVjaWZpYyB1c2UgY2FzZXMgaW4gbW9yZSBkZXRhaWwg YW5kIHdpbGwgZGVmaW5lIHRoZQ0KPj4gICBwcm90b2NvbCBtZWNoYW5pY3MgZm9yIGVhY2ggdXNl IGNhc2UuDQo+PiANCj4+IA0KPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1mYXJyZWwtc2ZjLWNvbnZlbnQvDQo+PiANCj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZl cnNpb25zIGF2YWlsYWJsZSBhdDoNCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1mYXJyZWwtc2ZjLWNvbnZlbnQtMDYNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtZmFycmVsLXNmYy1jb252ZW50LTA2DQo+PiANCj4+IEEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1mYXJyZWwtc2ZjLWNvbnZlbnQtMDYNCj4+IA0KPj4g DQo+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4gDQo+PiBJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4gDQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4g c2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPiANCg0K From nobody Sat Feb 17 23:13:36 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 2F6B31242F5; Sat, 17 Feb 2018 23:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 hJ37KDuLKkuj; Sat, 17 Feb 2018 23:13:32 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 1FD5312426E; Sat, 17 Feb 2018 23:13:32 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id f3so9736249wmc.1; Sat, 17 Feb 2018 23:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=2oTjEOvo7FnKxIGTGRhNTpwMcsYKp30AQYqO71HJqno=; b=EfYmYgenPdF8u9K08dg+FRbtrtBEMpwJNEhliTceKr4VFh6OPa/yPxg+ALSriebt0h fEjyRw4XNfYj/Rec9h0IzLo9LOsUx+umwgKcebMx34qBDYaloNLHuHjqymNs921hIS9H 53RTKxhHd7zFOxLB9YM0+4IPZ7PgNd2UiDmnshexLCyzrqUZYcVvJBfIXx9ry/F4WkJw TD/jKpzvxGCclNLd9ryZ9+/xxVI8o8t1l5JSSaM7gGI3LoE+FXlwigM7VPTIkbE+oNyi ko04+FlDL7NdY5CoLrMChAavcY74SIFrXzyxheE1lbfjMlVAte/W8HLqfSWG6tLeEfZd FyuA== 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:cc; bh=2oTjEOvo7FnKxIGTGRhNTpwMcsYKp30AQYqO71HJqno=; b=OnPbad4GQ9aIogWkLkplRpkEgmRMHayrOL0DmtEoSBUpmrgqm+URiMwaPZCmE0sVRh yWlkPgVbrSc/5Bo402oX464ctXYlKTr8pb5hcWkQmeAFd6WK4g9fymgODBB+sYCMP+Qm SZWa6yKlfm+tqKHPsW8ddc1oGhL7Ge/jrF5clcif2ez2+ghnO8nbpBaVnZuYisxxDeNq OPm2ojOcLJ+Nua2UkT65O67JkVqdnihnu/L4Qz89868TPzd9nrAHdErGa9CbSYaD01ds YHw+pVhDwyZjrja74O9Z6q+pHHTdQzRbbEzmfL6yaK9FSPl2PbvTzH+5O5G7CwpusqB2 smfw== X-Gm-Message-State: APf1xPDHsNjO7LBjyEDQ8iI0DxK1U9F8K769nWwM2Vh0A5keVXcWN3x7 uJVc2d0ePuWOD41GthxuZ7/yhFcDzTsAWeem6rQ/sw== X-Google-Smtp-Source: AH8x227Y26/uK/QdRKksgq4boYGJTVouQubQDiyq1IpFr0QjjcDZS3TJhbmq5+UNOUSuxGE4JVPehGwpTFeqxLsvyow= X-Received: by 10.80.170.157 with SMTP id q29mr15407010edc.43.1518938010481; Sat, 17 Feb 2018 23:13:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.174.225 with HTTP; Sat, 17 Feb 2018 23:13:30 -0800 (PST) From: Tal Mizrahi Date: Sun, 18 Feb 2018 09:13:30 +0200 Message-ID: To: sfc@ietf.org Cc: sfc-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c198fd68cfaaf05657750f8" Archived-At: Subject: [sfc] IETF 101 SFC - Call for Agenda Items X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 07:13:34 -0000 --94eb2c198fd68cfaaf05657750f8 Content-Type: text/plain; charset="UTF-8" Hi, We are starting to work on the agenda for the SFC session in IETF 101. 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 5th of March. If you are planning to update your draft(s) before IETF 101, 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 101 is available: https://datatracker.ietf.org/meeting/agenda.html Please also note that our charter has been updated, and we will be giving priority to agenda items that are within the scope of the new charter: https://datatracker.ietf.org/wg/sfc/about/ Cheers, Tal. --94eb2c198fd68cfaaf05657750f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We are starting to work on the agen= da for the SFC session in IETF 101.

If you have a = draft that you would like to discuss, please send a request to sfc-chairs@ietf.org including the name of th= e draft, the presenter's name, and how much time you need.
Also please make note of the draft cutoff date, which is the 5= th of March. If you are planning to update your draft(s) before IETF 101, w= e encourage you to do so as soon as possible, to allow people to review the= drafts before the meeting.

Please note that a pre= liminary version of the agenda for IETF 101 is available:

Please also no= te that our charter has been updated, and we will be giving priority to age= nda items that are within the scope of the new charter:

Cheers,
Tal.
--94eb2c198fd68cfaaf05657750f8-- From nobody Sun Feb 18 22:48:09 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 E41C61201FA; Sun, 18 Feb 2018 22:48:07 -0800 (PST) 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.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151902288788.18598.3643015599750883499@ietfa.amsl.com> Date: Sun, 18 Feb 2018 22:48:07 -0800 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-hierarchical-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 06:48:08 -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-07.txt Pages : 26 Date : 2018-02-18 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-sfc-hierarchical-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-hierarchical-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 Sun Feb 18 22:51: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 7B2251201FA for ; Sun, 18 Feb 2018 22:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 whgOJakTSHNP for ; Sun, 18 Feb 2018 22:51:06 -0800 (PST) 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 928E912711D for ; Sun, 18 Feb 2018 22:51:06 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 22397405D2; Mon, 19 Feb 2018 07:51:05 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 0269D120055; Mon, 19 Feb 2018 07:51:05 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0382.000; Mon, 19 Feb 2018 07:51:04 +0100 From: To: "sarikaya@ieee.org" , "draft-ietf-sfc-hierarchical@tools.ietf.org" CC: "sfc@ietf.org" Thread-Topic: [sfc] Editorial comments on hSFC Thread-Index: AQHTp0FuXJlABr26tkq/7DZ8DsPYQaOrTRyQ Date: Mon, 19 Feb 2018 06:51:04 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0D4257@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: 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.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0D4257OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Editorial comments on hSFC X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 06:51:13 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0D4257OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVoY2V0LA0KDQpBIG5ldyB2ZXJzaW9uIHdoaWNoIGZpeGVzIHRob3NlIGlzIGF2YWlsYWJs ZSBvbmxpbmUuDQoNCg0KUGxlYXNlIGNoZWNrIGF0OiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtc2ZjLWhpZXJhcmNoaWNhbC0wNw0KVGhhbmsgeW91Lg0K Q2hlZXJzLA0KTWVkDQoNCkRlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIERl IGxhIHBhcnQgZGUgQmVoY2V0IFNhcmlrYXlhDQpFbnZvecOpIDogdmVuZHJlZGkgMTYgZsOpdnJp ZXIgMjAxOCAxNzoxNg0Kw4AgOiBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWxAdG9vbHMuaWV0 Zi5vcmcNCkNjIDogc2ZjQGlldGYub3JnDQpPYmpldCA6IFtzZmNdIEVkaXRvcmlhbCBjb21tZW50 cyBvbiBoU0ZDDQoNCkhpLA0KDQpIZXJlIGFyZSBteSBlZGl0b3JpYWwgY29tbWVudHM6DQoNClBh Z2UgMw0KDQp0cmFuc3BvcnQtDQoNCiAgIGxheWVyIGNvb3JkaW5hdGUgKHR5cGljYWxseSwgNS10 dXBsZSkgc3RpY2tpbmVzcyB0byBzcGVjaWZpYyBzdGF0ZWZ1bA0KDQogICBTRiBpbnN0YW5jZXMu DQpzdGF0ZSB0aGUgNS10dXBsZSBoZXJlLCBzb3VyY2UgQCxkZXN0aW5hdGlvbiBALCBldGMgaWRl bnRpZnlpbmcgYSBmbG93IGFzIHRoZSA1LXR1cGxlIGlzIG1lbnRpb25lZCBpbiBvdGhlciBwbGFj ZXMgYWxzby4NCg0KDQpUaGUgY3JpdGVyaWENCg0KICAgZm9yIGRlY29tcG9zaXRpb24gYSBkb21h aW4gaW50byBtdWx0aXBsZSBTRkMtZW5hYmxlZCBzdWItZG9tYWlucyBhcmUNCg0KICAgYmV5b25k IHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KZGVjb21wb3NpdGlvbiAtPiBkZWNvbXBvc2lu ZyBvciBkZWNvbXBvc2l0aW9uIG9mDQoNCkFwcGVuZGl4IEExDQoNCmFjcm9ueW1zIG9mIFdBRiwg SVBTLCBJRFIgYXJlIG5vdCBkZWZpbmVkLg0KDQpSZWdhcmRzLA0KQmVoY2V0DQo= --_000_787AE7BB302AE849A7480A190F8B93300A0D4257OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWlu VGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgYnJ1dCBDYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUzt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ csOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpz cGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwg Q2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3Jt YXTDqSBIVE1MIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RlI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsN Cglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5UZXh0ZWJy dXRDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGJydXQgQ2FyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGJydXQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1 cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5IaSBCZWhjZXQsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+QSBuZXcgdmVyc2lvbiB3aGljaCBmaXhlcyB0aG9zZSBp cyBhdmFpbGFibGUgb25saW5lLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+UGxlYXNlIGNoZWNrIGF0OiA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWwtMDciPjxzcGFuIGxh bmc9IkVOLVVTIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtc2ZjLWhpZXJhcmNoaWNhbC0wNzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFuayB5b3UuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzZmMgW21haWx0bzpzZmMtYm91bmNl c0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IEJlaGNldCBTYXJpa2F5YTxicj4NCjxi PkVudm95w6kmbmJzcDs6PC9iPiB2ZW5kcmVkaSAxNiBmw6l2cmllciAyMDE4IDE3OjE2PGJyPg0K PGI+w4AmbmJzcDs6PC9iPiBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWxAdG9vbHMuaWV0Zi5v cmc8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IHNmY0BpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7 OjwvYj4gW3NmY10gRWRpdG9yaWFsIGNvbW1lbnRzIG9uIGhTRkM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIGFyZSBteSBlZGl0b3JpYWwgY29tbWVu dHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlBhZ2UgMzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iZm9udC12 YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNv bG9yOmluaXRpYWw7d29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXA7d29y ZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj50cmFuc3BvcnQtPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IGxheWVyIGNvb3JkaW5hdGUgKHR5cGljYWxseSwgNS10dXBsZSkgc3RpY2tpbmVzcyB0 byBzcGVjaWZpYyBzdGF0ZWZ1bDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBTRiBpbnN0YW5jZXMuPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zdGF0ZSB0aGUgNS10dXBsZSBoZXJl LCBzb3VyY2UgQCxkZXN0aW5hdGlvbiBALCBldGMgaWRlbnRpZnlpbmcgYSBmbG93IGFzIHRoZSA1 LXR1cGxlIGlzIG1lbnRpb25lZCBpbiBvdGhlciBwbGFjZXMgYWxzby48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczpub3Jt YWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1kZWNvcmF0 aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7d29yZC13cmFw OmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXA7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgY3JpdGVyaWE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZm9yIGRlY29tcG9z aXRpb24gYSBkb21haW4gaW50byBtdWx0aXBsZSBTRkMtZW5hYmxlZCBzdWItZG9tYWlucyBhcmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGVjb21wb3NpdGlvbiAtJmd0OyBk ZWNvbXBvc2luZyBvciBkZWNvbXBvc2l0aW9uIG9mJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFwcGVuZGl4IEExPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFjcm9ueW1zIG9mIFdB RiwgSVBTLCBJRFIgYXJlIG5vdCBkZWZpbmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVoY2V0PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300A0D4257OPEXCLILMA3corp_-- From nobody Tue Feb 20 10:03:29 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 EB2E112DA4A; Tue, 20 Feb 2018 10:03:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Cc: Behcet Sarikaya , iesg-secretary@ietf.org, sarikaya@ieee.org, sfc-chairs@ietf.org, sfc@ietf.org Message-ID: <151914980695.3854.6833858266994501803.idtracker@ietfa.amsl.com> Date: Tue, 20 Feb 2018 10:03:26 -0800 Archived-At: Subject: [sfc] Publication has been requested for draft-ietf-sfc-hierarchical-07 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 18:03:27 -0000 Joel Halpern has requested publication of draft-ietf-sfc-hierarchical-07 as Informational on behalf of the SFC working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ From nobody Sat Feb 24 22:51:41 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 79B3F1267BB; Sat, 24 Feb 2018 22:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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=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 dHzrkZsXouER; Sat, 24 Feb 2018 22:51:38 -0800 (PST) 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 4D57F124E15; Sat, 24 Feb 2018 22:51:38 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id q83so11782650wme.5; Sat, 24 Feb 2018 22:51:37 -0800 (PST) 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=icAqh9gmqVxpneotflkX4yYEgGb+L+FV6/FG1BYXHOc=; b=EytmhZ2DZSO1LfUveozVK9Rzo51+Y6uUd+yD64VZjVmOuLyIIkwIuNWHlV4NTTUd5n igaZckz/bWGTHY67PBn+apvsEIKJfO7zV1Xbc0GLO6v7cjsm729Mb+Ygjxs5Y8E64g7X bsp80zb3oRNb1eIRP+m3wL0SzWetrx1TlGFE1mebCiQyHnlyRYQTj/wd9DnX100Fp46Y A3kvtkjq+XzVBNJCRTLcDRTY0xgLYn5aNIyU6rBqdo9M8wS1GGHGXTWmOOBJEqhIG4Eu 8a0sdDTKXWz2V/RX4Mmi6xWS0NtrNsSaPYALXgNCq/rvMYOYz6DDaP71HfhUOxPwp/fB Wi/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:in-reply-to:references:from:date :message-id:subject:to:cc; bh=icAqh9gmqVxpneotflkX4yYEgGb+L+FV6/FG1BYXHOc=; b=keGOpb4kU+eZ/gdNeiLcB/bKdTrsEe+LziMf03fQ7p2Bg9UlLvluxrWCI4veIoz2Wd dGYdTOCHEjJcKYzLOvU7HBELWMvEJTeTHwJnYbuS752TpOVuiS79MjL8UoDOI7twP/t+ RzO8lXVHeWzxY5LosIgOUec1sSPxbHXaFQtmm8c5hBvQBGbNeLoVHHzpC2DUeVG1DvtC xsgFIZW8C91p10Of/q5HcEO3RU0jrqZj4R5uOrjC1JAX8zkho83catBMA2CGXutDX7Ei KNdJZFMFXRKtpv3FxJZNCUmLpOS+BpsdyZPi36BRs0ZMP08qBXskcjuS4hUNN3KPEwe/ rFSg== X-Gm-Message-State: APf1xPBkHt2mt3DyTZWGwuw514/Kg2LIzjxG/a9bsuaVkXLebZLiypSw hiEKQXRV0MGU1fEKnlBcdM1D5emDV91r4tAxWgGDQw== X-Google-Smtp-Source: AH8x226W12sDxircSmosNJ0XOPUCV0I+QhQ7fEXxUgcGWcip4QC7ifjEumOhQFQcXjTo2vM9CY3NOO/LIfi9zxlBl4U= X-Received: by 10.80.245.91 with SMTP id w27mr9414000edm.73.1519541496423; Sat, 24 Feb 2018 22:51:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.174.225 with HTTP; Sat, 24 Feb 2018 22:51:36 -0800 (PST) In-Reply-To: References: From: Tal Mizrahi Date: Sun, 25 Feb 2018 08:51:36 +0200 Message-ID: To: sfc@ietf.org Cc: sfc-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a114ddb4e1da884056603d35d" Archived-At: Subject: Re: [sfc] IETF 101 SFC - Call for Agenda Items X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 06:51:40 -0000 --001a114ddb4e1da884056603d35d Content-Type: text/plain; charset="UTF-8" Hi, The final agenda has been published: https://datatracker.ietf.org/meeting/agenda.html If you would like a slot in the SFC session please send a slot request to sfc-chairs@ietf.org by March 2nd. Requests should include the name of the draft, the presenter's name, and how much time you need. Cheers, Tal. On Sun, Feb 18, 2018 at 9:13 AM, Tal Mizrahi wrote: > Hi, > > We are starting to work on the agenda for the SFC session in IETF 101. > > 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 5th of March. > If you are planning to update your draft(s) before IETF 101, 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 101 is > available: > https://datatracker.ietf.org/meeting/agenda.html > > Please also note that our charter has been updated, and we will be giving > priority to agenda items that are within the scope of the new charter: > https://datatracker.ietf.org/wg/sfc/about/ > > Cheers, > Tal. > --001a114ddb4e1da884056603d35d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The final agenda has been published= :

If you would like a slot in the SFC session p= lease send a slot request to sfc-cha= irs@ietf.org by March 2nd.
R= equests should include the name of the draft, the presenter's name, and= how much time you need.

Cheers,
Tal.




On Sun, Feb 18, 2018 at 9:13 AM, Tal Mizrahi <tal.mi= zrahi.phd@gmail.com> wrote:
Hi,

We are starting to work on the age= nda for the SFC session in IETF 101.

If you have a= draft that you would like to discuss, please send a request to sfc-chairs@ietf.org inclu= ding the name of the draft, the presenter's name, and how much time you= need.

Also please make note of the draft cutoff d= ate, which is the 5th of March. If you are planning to update your draft(s)= before IETF 101, we encourage you to do so as soon as possible, to allow p= eople to review the drafts before the meeting.

Ple= ase note that a preliminary version of the agenda for IETF 101 is available= :

Please also note that our charter has been upda= ted, and we will be giving priority to agenda items that are within the sco= pe of the new charter:

Cheers,
Tal.

--001a114ddb4e1da884056603d35d-- From nobody Tue Feb 27 15:18:48 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 AFB1E12EA9D; Tue, 27 Feb 2018 15:11:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: sfc@ietf.org, akatlas@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977308371.5200.13230686828740037066.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:23 -0800 Archived-At: Subject: [sfc] sfc - Requested session has been scheduled for IETF 101 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:27 -0000 Dear Tal Mizrahi, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sfc Session 1 (2:00:00) Wednesday, Morning Session I 0930-1200 Room Name: Balmoral size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Service Function Chaining Area Name: Routing Area Session Requester: Tal Mizrahi Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: bess idr i2nsf ippm mpls nvo3 rtgwg spring lisp People who must be present: Joel M. Halpern Jim Guichard Alia Atlas Resources Requested: Special Requests: ---------------------------------------------------------