From nobody Wed Jan 4 09:46:01 2017 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 707AB12944B for ; Wed, 4 Jan 2017 09:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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_HELO_PASS=-0.001, 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 SFrJHYwY91Zl for ; Wed, 4 Jan 2017 09:45:58 -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 4A2A21293D8 for ; Wed, 4 Jan 2017 09:45:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 312E11C0432 for ; Wed, 4 Jan 2017 09:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1483551958; bh=OD1RCmsAo3ODKq14rRRY/tktLtUMTQLYd2tm1k8CDJY=; h=To:From:Subject:Date:From; b=binkn7V2HoGJEAbM5cV/+9qgSn3pX4gsrreEQP6/tVY0vsEDmBy/ra2Cq18iqr9Ik yYlNtgVBr5U6+tzEB4vo3pHdYlSKYx5A2XhnOH4/ZWCo/bBHiQvrgDMdZH2xnGGrL4 2NPjGf41LlgIAn++XzIm1tTYpIwiadUboNyY8gvE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D0FB51C01E4 for ; Wed, 4 Jan 2017 09:45:57 -0800 (PST) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Wed, 4 Jan 2017 12:45:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] Interim meeting reminder X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 17:45:59 -0000 This is a reminder to folks that we have an Interim meeting coming up, and would appreciate active participation (please come) RSVP (so we can make sure the room is suitable) Thank you. Original message below including RSVP doodle link. Yours, Joel and Jim ----- In order to get an attendance count, I have created a doodle poll. As it is a three day meeting, you can mark each day. I hope to see you folks for all three days. the link for the poll is: http://doodle.com/poll/3hfxzn8yqfmpwhyb Juniper has provided this link: https://www.juniper.net/us/en/contact-us/sales-offices/westford/#02 with directions and hotel information near the meeting facility. Thank you very much, Joel ----- The Service Function Chaining (sfc) Working Group will hold an interim meeting from 2017-01-17 at 11:00 to 2017-01-19 at 14:00 America/New_York. Meeting Location: Westford, US Agenda: (Agenda bashing.) What do we really want from the security environment draft. What do we want from OAM drafts. What does the control requirements draft need to describe; driven by AD concerns. Discuss metadata descriptions including what MD-1 and MD-2 documents we want. Finalize NSH. Information about remote participation: Remote participation information will be obtained at the time of approval Specific location: Juniper Networks, 10 Technology Park Drive, Westford, MA 01886, Stony Brook Conference Room. Ending January 19, 2017 at 14:00 ----- From nobody Sun Jan 8 19:30:24 2017 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 43B391294AD for ; Sun, 8 Jan 2017 19:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199] 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 KxFzvGj92OHW for ; Sun, 8 Jan 2017 19:30:20 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4655D129470 for ; Sun, 8 Jan 2017 19:30:19 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.5]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec587303c3822-d291c; Mon, 09 Jan 2017 11:30:12 +0800 (CST) X-RM-TRANSID: 2eec587303c3822-d291c X-RM-SPAM-FLAG: 00000000 Received: from GuRong (unknown[223.104.38.157]) by rmsmtp-syy-appsvr03-12003 (RichMail) with SMTP id 2ee3587303c19b8-e7f07; Mon, 09 Jan 2017 11:30:12 +0800 (CST) X-RM-TRANSID: 2ee3587303c19b8-e7f07 From: "Ariel Gu" To: Date: Mon, 9 Jan 2017 11:30:10 +0800 Message-ID: <004501d26a28$affc2860$0ff47920$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdJqJ7d+6S/nSGAYQNqUH8CdysFeHA== Content-Language: zh-cn Archived-At: Cc: 'wangzitao' , dekumar@cisco.com, frank.xialiang@huawei.com, jguichard1966@gmail.com, jmh@joelhalpern.com, mohamed.boucadair@orange.com Subject: [sfc] Solicit for comments: New Version Notification for draft-gu-sfc-yang-oam-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 03:30:22 -0000 Hi, dear all. I have submitted a new draft " draft-gu-sfc-yang-oam-00" defining YANG = data model for SFC OAM. As the SFC OAM mechanisms have not yet been = standardized. This draft will get alignment with the latest development = of SFC OAM mechanisms draft. Any comments and suggestions are welcomed in order to fulfill this draft = in the updated version. The information of my draft is listed as follow: A new version of I-D, draft-gu-sfc-yang-oam-00.txt has been successfully = submitted by Rong Gu and posted to the IETF repository. Name: draft-gu-sfc-yang-oam Revision: 00 Title: YANG Data Model for SFC Operations, Administration, and = Maintenance (OAM) Document date: 2017-01-08 Group: Individual Submission Pages: 19 URL: = https://www.ietf.org/internet-drafts/draft-gu-sfc-yang-oam-00.txt Status: https://datatracker.ietf.org/doc/draft-gu-sfc-yang-oam/ Htmlized: https://tools.ietf.org/html/draft-gu-sfc-yang-oam-00 Abstract: This document defines YANG data model for Service Function Chaining (SFC = Operations, Administration, and Maintenance). It derives from the basic = YANG data model for Layer independent OAM Management defined in = [I-D.ietf-lime-yang-connectionless-oam] with SFC technology specifics. = It includes SFC OAM related configuration and state data. Best regards. Gu Rong gurong_cmcc@outlook.com gurong@chinamobile.com From nobody Tue Jan 10 13:38:06 2017 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 078E31295C1; Tue, 10 Jan 2017 13:38:02 -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 qP9bM6ITGiMK; Tue, 10 Jan 2017 13:37:59 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C751295BE; Tue, 10 Jan 2017 13:37:56 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0ALbrv4000441; Tue, 10 Jan 2017 21:37:53 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0ALbogh000419 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2017 21:37:52 GMT From: "Adrian Farrel" To: , Date: Tue, 10 Jan 2017 21:37:49 -0000 Message-ID: <06b901d26b89$ccf3ff80$66dbfe80$@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: AdJricQq9zcMjzQMSkSpTySYEGP4dg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22816.002 X-TM-AS-Result: No--8.531-10.0-31-10 X-imss-scan-details: No--8.531-10.0-31-10 X-TMASE-MatchedRID: R1xiGq/shpuJ/ollFUOCKeG5dRZCgxC39pLnYtQ99xIGW3hFnC9N1ZWT If+vN5cu4e8y2TDxCW7X+4pjLOgXfGepgZKXIav+xFhT7DBLefByawdArtww58eQfu6iwSfs6Z2 96E0MIULiJ80GM+ooz/Ouevzwt0wjRBZ3QLvUqCRwUSK4/EeOxT9BLgfcJDLqQ+MGgPhHUCYhXF Y4E85YVrgVK28gazGqH2XXM8w5v7pNfs8n85Te8v7E6GNqs6ce3QfwsVk0UbtuRXh7bFKB7nChb F88XI4tHdchCWZvoLlQOnSbMP0Oe8vxF2o4c3l1YDttQUGqHZU= Archived-At: Cc: draft-mackie-bess-nsh-bgp-control-plane@ietf.org Subject: [sfc] New revision of draft-mackie-bess-nsh-bgp-control-plane X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 21:38:02 -0000 Hi, [Cross-posting to BESS and SFC as requested by the AD] We just posted an update to draft-mackie-bess-nsh-bgp-control-plane You can find it at https://datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-control-plane/ where the diff function on the History tab may be useful. In summary: - We added some sections to the "Advanced Topics" in Section 7 - Considerations for Stateful Service Functions - Flow Spec for SFC Classifiers - Choice of Data Plane SPI/SI Representation - We added some more examples in Section 8 - Examples of SFPs with Stateful Service Functions - Two new IANA sections at the end of Section 10 - New Generic Transitive Experimental Use Extended Community Sub-Type - SPI/SI Representation (Note that the diff tool makes a pig's ear of the changes around the end of section 7 trying to fold them into section 8.) Other changes are more minor and are mainly slight clarifications As usual, we'd be delighted to discuss this document on either of the mailing lists. It looks as though Eric and I will be in Westford during the SFC interim next week, so we can also talk face-to-face with anyone who is there. Thanks, Adrian From nobody Thu Jan 12 12:22:21 2017 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 3F7421293F0 for ; Thu, 12 Jan 2017 12:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, 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 PQdA0SbkJi6c for ; Thu, 12 Jan 2017 12:22:18 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 92DFD129459 for ; Thu, 12 Jan 2017 12:22:17 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id v186so22026776lfa.1 for ; Thu, 12 Jan 2017 12:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to; bh=8G/5ny/+Xfvw9XkUrl5gx0dZYagkb8pTMK/lzPVv8ho=; b=oT2/E7n7jXzlBt6b8NkOFVr+xhHKjAMVjkEBIGgzDboqVTzHn04GCgmPIprQBG3CUI sCuBTF6QjNnFqNNGw9wMPiZ0mJE2M6y8QSvAL4PJM0qOu7U0Fy9obzo4WbqgsdcyzWPR 4jnEj1aP9Yo0fm1qcectj5NOkqlP0dh7gPP4amldp3ScUlZacHuYa5IJAvqLFC1h5PCX SaknabQ2H1ZNEOlUHty0cnV9I7AeyX8pczjXym6sD8dEvUSXUwwKH7ZJTbBJKPxJPAzZ PhrDmVd7kqYeCnGZiGNghLvlNK71mGeg1TMy12UMqmvaKNJAkFSmIhxxfTbJcXCZVlT8 L4Eg== 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:in-reply-to:references :from:date:message-id:subject:to; bh=8G/5ny/+Xfvw9XkUrl5gx0dZYagkb8pTMK/lzPVv8ho=; b=V6YykMsVsOECHwS9ektZkOhUlxgOopDBOayMaVqz04GD9iGt8is8f4+k8CSgiBcPHb lDrbXH+UfCkL9yAclNJQ+x0j1XG3oGlz4OQODTFjswRSKflXmG1TNLpj++KbKlCFMIHp +euklnyj/VftolisQPIwWVUDmsaJ8aE55zKBDVDnx8fYLU5JeXQPyjknO53Mliqnpd7O cqdxo0J/iFuS+lDLgeEWjlPcJzGoBA5vxeLiUu3pAWXUD5rsc2wDSGJkHbU7FnNjfxKG uoCj/MAXmLC+/jBVtyXJf+sg7IQKgWDvcuFbldshaOda4vyW+NPmfsnoI9lGtIdZwbQz TaHA== X-Gm-Message-State: AIkVDXKPt2XF2AHsxlsYPDxWpGZEpNwTEolADDV2eU4wNnLeIkT0JMDKMwjWyZCnnUvV7ueH/MptRb2yK05SPg== X-Received: by 10.25.149.132 with SMTP id x126mr5845243lfd.100.1484252535484; Thu, 12 Jan 2017 12:22:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.134.67 with HTTP; Thu, 12 Jan 2017 12:22:14 -0800 (PST) In-Reply-To: <148425240510.2971.953304967433920868.idtracker@ietfa.amsl.com> References: <148425240510.2971.953304967433920868.idtracker@ietfa.amsl.com> From: Behcet Sarikaya Date: Thu, 12 Jan 2017 14:22:14 -0600 Message-ID: To: "sfc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [sfc] Fwd: New Version Notification for draft-sarikaya-sfc-metadatat1t2-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 20:22:20 -0000 Folks, We revised SFC Metadata draft. We hope that it will be useful in the upcoming interim meeting next week. Regards, Behcet A new version of I-D, draft-sarikaya-sfc-metadatat1t2-02.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-sarikaya-sfc-metadatat1t2 Revision: 02 Title: Service Function Chaining Metadata Type 1 and Type 2 Document date: 2017-01-12 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-sarikaya-sfc-metadatat1t2-02.txt Status: https://datatracker.ietf.org/doc/draft-sarikaya-sfc-metadatat1t2/ Htmlized: https://tools.ietf.org/html/draft-sarikaya-sfc-metadatat1t2-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-sarikaya-sfc-metadatat1t2-02 Abstract: With the definition of service function chain data plane protocol there comes the need to define the context data needed in the service function chain use cases. This document gives an account of all context data defined so far as Network Service Header metadata Type 1 and Type 2 context headers. Next, the document discusses the various options that can be taken in standardizing service function chain metadata. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Jan 13 10:12:14 2017 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 3F840129D1E for ; Fri, 13 Jan 2017 10:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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_HELO_PASS=-0.001, 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 Zj91-pKpU52W for ; Fri, 13 Jan 2017 10:12:05 -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 198FC129D1A for ; Fri, 13 Jan 2017 10:12:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0B655A20608 for ; Fri, 13 Jan 2017 10:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1484331125; bh=sMINgeuY0oLjDggi80FLTCdR/g7YCfd41lgXcdy6F5U=; h=To:From:Subject:Date:From; b=lhzfcWOGt+Io1+70dqmMWmKVO+SViejPlUH/bR3xfGUSl5Cwh26FGMGqQjvKy5fff xqFBcPxff3KUHnLxDi+26mxDbPozgCwy9a4AGZwuwBmbp2nXmJQgWV1yG6yrkVOPMd suvbLY8qeryaHFjhGVH5RsHB0K2h1Xe9YunYZYR4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id ACD381CAE04 for ; Fri, 13 Jan 2017 10:12:04 -0800 (PST) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Fri, 13 Jan 2017 13:12:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 18:12:07 -0000 Jim and I have been talking with Alia about this, and talking with each other. Along the way we realized that we have some significant concerns about what we have done with this document. We expect to discuss this next week at the interim, looking for ideas. And to discuss it further on the list. The existing control plane document when viewed from the perspective of an implementer is hard to decompose into actionable parts. Given that the IETF tends to work by solving pieces of problems, rather than an entire control solution for all aspects, it is important that requriements we define be usable for such piece-wise work. Thus, we need to describe the requirements in ways that provide components which may be combined into an overall control plane solution for SFC. While the document provides a set of control plane requirements it does not provide guidance on how those requirements can be successfully consumed into a standards compliant control plane. In particular, the interfaces C1 - C4 are each made up of behaviors likely to be provided by different solution components. Thus, while there is an attempt to document a set of interfaces (C1...C4) it is not clear how an implementer can provide a solution component that addresses a well-defined set of requirements. Given this, we need to go back and rethink the bundling of functionality so as to end up with bundles of requirements that are can be usefully addressed by IETF work while avoiding (as we have done well in the current version) prescribing the control plane architecture. In addition, functional objectives are not fine grained enough to implement; for example, text such as "Rationalize the management of classification rules" is not something one can implement. Yours, Jim & Joel From nobody Fri Jan 13 10:21:47 2017 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 5BFB3129533 for ; Fri, 13 Jan 2017 10:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEQ7sU12gqzX for ; Fri, 13 Jan 2017 10:21:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0439D1294BD for ; Fri, 13 Jan 2017 10:21:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEJ59492; Fri, 13 Jan 2017 18:21:31 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 13 Jan 2017 18:21:30 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0301.000; Fri, 13 Jan 2017 10:21:25 -0800 From: James N Guichard To: "sfc@ietf.org" Thread-Topic: Upcoming SFC WG Interim meeting Thread-Index: AdJtyPf1jf+42QB6SRiAz9Ecnd7TuQ== Date: Fri, 13 Jan 2017 18:21:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.32] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3414CFEdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58791AAC.0084, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: abcac7389d2b88f112aac88d63008bd6 Archived-At: Subject: [sfc] Upcoming SFC WG Interim meeting X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 18:21:46 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3414CFEdfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings WG: The following is a rough agenda for the upcoming SFC WG Interim meeting in = Boston. We have deliberately left the agenda as flexible as possible so tha= t we can make good use of our face-to-face time in discussion/white boardin= g rather than slide ware. Agenda: Chair Introduction: - Logistics - Agenda bashing - emphasis on discussion to move our work f= orward and capturing WG action items - accept/deny requests for any other format= s/agenda items - summary of status of planned discussion i= tems What follows is not split across days and purposefully not time-estimated: NSH document discussion: - review agreed upon document changes - review remaining open items Security Environment document discussion: - what do we want from this document - review what is already covered and what the reader should= gain from reading OAM drafts discussion: - Common work in NVO3 - how to use the common work - special needs of SFC - Discussion of what things we need OAM to address - conventional / CV problems - In-situ - What can/should we cover in the OAM framework document Control-plane Requirements document discussion: - how do we make this a useful document as an RFC that can = be implemented Metadata discussion: - documenting general attributes and review of existing dra= fts - approach for document MD-1 usages - documenting MD-2 TLVs - what do we want from a registry creation = document - what do we expect from other defining doc= uments Summary and review of action items: - with decisions to be taken to the WG list for discussion = and verification Yours, Jim & Joel --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3414CFEdfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings WG:

 

The following is a rough agenda for the upcoming SFC= WG Interim meeting in Boston. We have deliberately left the agenda as flex= ible as possible so that we can make good use of our face-to-face time in d= iscussion/white boarding rather than slide ware.

 

Agenda:

Chair Introduction:

        &nbs= p;       - Logistics

        &nbs= p;       - Agenda bashing

        &nbs= p;            &= nbsp;          - emphasis on d= iscussion to move our work forward and capturing WG action items=

        &nbs= p;            &= nbsp;          - accept/deny r= equests for any other formats/agenda items

        &nbs= p;            &= nbsp;          - summary of st= atus of planned discussion items

 

What follows is not split across days and purposeful= ly not time-estimated:

 

NSH document discussion:

        &nbs= p;       - review agreed upon document change= s

        &nbs= p;       - review remaining open items

 

Security Environment document discussion:=

        &nbs= p;       - what do we want from this document=

        &nbs= p;       - review what is already covered and= what the reader should gain from reading

 

OAM drafts discussion:

        &nbs= p;       - Common work in NVO3

        &nbs= p;            &= nbsp;          - how to use th= e common work

        &nbs= p;            &= nbsp;          - special needs= of SFC

        &nbs= p;       - Discussion of what things we need = OAM to address

        &nbs= p;            &= nbsp;          - conventional = / CV problems

        &nbs= p;            &= nbsp;          - In-situ<= /o:p>

        &nbs= p;       - What can/should we cover in the OA= M framework document

 

Control-plane Requirements document discussion:=

        &nbs= p;       - how do we make this a useful docum= ent as an RFC that can be implemented

 

Metadata discussion:

        &nbs= p;       - documenting general attributes and= review of existing drafts

        &nbs= p;       - approach for document MD-1 usages<= o:p>

        &nbs= p;       - documenting MD-2 TLVs

        &nbs= p;            &= nbsp;          - what do we wa= nt from a registry creation document

        &nbs= p;            &= nbsp;          - what do we ex= pect from other defining documents

 

Summary and review of action items:

        &nbs= p;       - with decisions to be taken to the = WG list for discussion and verification

 

Yours,

 

Jim & Joel

 

 

 

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3414CFEdfweml501mbb_-- From nobody Fri Jan 13 13:56:12 2017 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 5863712950D; Fri, 13 Jan 2017 13:56:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148434457135.9716.9493590927371583752.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2017 13:56:11 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-hierarchical-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 21:56:11 -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 of the IETF. Title : Hierarchical Service Function Chaining (hSFC) Authors : David Dolson Shunsuke Homma Diego R. Lopez Mohamed Boucadair Dapeng Liu Ting Ao Vu Anh Vu Filename : draft-ietf-sfc-hierarchical-02.txt Pages : 25 Date : 2017-01-13 Abstract: Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration. The goals of hSFC are to make a large-scale network easier to reason about, simpler to control and to support independent functional groups within large network operators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-hierarchical-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 13 14:01:58 2017 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 094E0129E95 for ; Fri, 13 Jan 2017 14:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] 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 Pj0ssGbJbM1L for ; Fri, 13 Jan 2017 14:01:56 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A31E129E93 for ; Fri, 13 Jan 2017 14:01:56 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([fe80::68ac:f071:19ff:3455%19]) with mapi id 14.03.0319.002; Fri, 13 Jan 2017 17:01:54 -0500 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-hierarchical-02.txt Thread-Index: AQHSbefejlDFYWZJTky+PX+Uk29oGqE29MFQ Date: Fri, 13 Jan 2017 22:01:54 +0000 Message-ID: References: <148434457135.9716.9493590927371583752.idtracker@ietfa.amsl.com> In-Reply-To: <148434457135.9716.9493590927371583752.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-hierarchical-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:01:58 -0000 This version includes a number of editorial and clarifying improvements: https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-02 As far as I know, all suggestions to date have been considered and incorpor= ated. Please let me know if I failed to address something. -Dave -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Friday, January 13, 2017 4:56 PM To: i-d-announce@ietf.org Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-hierarchical-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Service Function Chaining of the IETF. Title : Hierarchical Service Function Chaining (hSFC) Authors : David Dolson Shunsuke Homma Diego R. Lopez Mohamed Boucadair Dapeng Liu Ting Ao Vu Anh Vu Filename : draft-ietf-sfc-hierarchical-02.txt Pages : 25 Date : 2017-01-13 Abstract: Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration. The goals of hSFC are to make a large-scale network easier to reason about, simpler to control and to support independent functional groups within large network operators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-hierarchical-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jan 13 15:09:30 2017 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 E66EC129500 for ; Fri, 13 Jan 2017 15:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWZR0QmEXqIm for ; Fri, 13 Jan 2017 15:09:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E87E1294B0 for ; Fri, 13 Jan 2017 15:09:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYT27606; Fri, 13 Jan 2017 23:09:24 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 13 Jan 2017 23:09:23 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0301.000; Fri, 13 Jan 2017 15:09:20 -0800 From: Lucy yong To: "sfc@ietf.org" Thread-Topic: NSH text enhancement suggestion Thread-Index: AdJt8gU9qUFvdUHaRGuVS0ztkbmneA== Date: Fri, 13 Jan 2017 23:09:20 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57B9F7FD@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.89] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D57B9F7FDdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.58795E24.0062, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3e2e24d79fa2ce2587f6f88dc10b3ceb Archived-At: Subject: [sfc] NSH text enhancement suggestion X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 23:09:29 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D57B9F7FDdfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Length field in NSH base header contains value of total length of NSH. " The length field indicates the "end" of NSH and where the original packet= /frame begins." "In that case, the MD Type 0x1 node, MUST utilize the base header length fi= eld to determine the original payload offset if it requires access to the original packet/frame." Comment: above text does not accurate for the hierarchical SFC case (draft-= ietf-sfc-hierarchical-02.txt) suggested text: " The length field indicates the "end" of NSH header; if the next protocol = in base header is not "NSH", it also indicates the original packet/frame b= egins. To locate the original packet/frame begins on NSH packet, a recursiv= e process can be used until the next protocol in a based header is not "NSH= "; the sum of total length of all NSH headers on a NSH packet is the offset= of the original packet/frame. Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D57B9F7FDdfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Length field in NSH base header contains value of to= tal length of NSH.  

 

“ The length field indicates the "end&quo= t; of NSH and where the original packet/frame begins.”

 

“In that case, the MD Type 0x1 node, MUST util= ize the base header length field to determine

   the original payload offset if it requi= res access to the original

   packet/frame.”

 

Comment: above text does not accurate for the hie= rarchical SFC case (draft-ietf-sfc-hierarchical-02.txt)

 

suggested text:

 

“ The length field indicates the "end&quo= t; of NSH header; if the next protocol in base header is not “NSHR= 21;,  it also indicates the original packet/frame begins. To locate th= e original packet/frame begins on NSH packet, a recursive process can be used until the next protocol in a based header is not “NSH”= ; the sum of total length of all NSH headers on a NSH packet is the offset = of the original packet/frame.

 

Lucy

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D57B9F7FDdfweml501mbb_-- From nobody Fri Jan 13 16:41:01 2017 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 4E4EC12957A for ; Fri, 13 Jan 2017 16:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.22 X-Spam-Level: X-Spam-Status: No, score=-10.22 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.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 zqH_MJJCQ-bp for ; Fri, 13 Jan 2017 16:40:58 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F81B1294EA for ; Fri, 13 Jan 2017 16:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1484354458; x=1515890458; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ntl7TdOxOQ8Nx5n0Or5W3/MO97DQpfENdp1Bs97SUxw=; b=DEJyDWPeTQh4TQCA9UfZby4oeCmFAV10b0Q7kuPfySA+4c1W5zvg3YaC FclJtHtgVvnPSj3/xqvy9kXMYVaHlBeJAdpH+aZCEQAc9aknT/mIKI8jv 3V47tmRTcZr5Ty4J/ThS4S0zhk4mWt03pwP9UZdzOIS6K+1Nk/6DJ3Rmq k=; X-IronPort-AV: E=McAfee;i="5700,7163,8407"; a="267003562" X-IronPort-AV: E=Sophos;i="5.33,224,1477958400"; d="scan'208";a="267003562" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 14 Jan 2017 00:40:58 +0000 Received: from SV5CCPEMS01.olympus.F5Net.com (172.23.209.12) by SV5CCPEMS04.olympus.F5Net.com (172.23.209.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.27; Fri, 13 Jan 2017 16:40:57 -0800 Received: from SV5CCPEMS01.olympus.F5Net.com ([fe80::8cea:a209:8eb7:c2ab]) by SV5CCPEMS01.olympus.F5Net.com ([fe80::8cea:a209:8eb7:c2ab%19]) with mapi id 15.01.0544.027; Fri, 13 Jan 2017 16:40:57 -0800 From: Sumandra Majee To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] How to progress our control plane requirements document Thread-Index: AQHSbciskIOG8xZK3Uy0CKJpHOUgCqE3IioA Date: Sat, 14 Jan 2017 00:40:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.18.0.160709 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [172.23.251.197] Content-Type: text/plain; charset="utf-8" Content-ID: <29AE4D628981824DB0D0B0EEF66AE4CC@F5.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 00:41:00 -0000 Sm9lbCwgSmltLA0KDQpJIGFtIGluIGZ1bGwgYWdyZWVtZW50IHdpdGggdGhpcy4gSGF2aW5nIGdv bmUgdGhydSBhIGltcGxlbWVudGF0aW9uIG9mIHF1YXNpIGNvbnRyb2xsZXIgKCBJIGFtIHN1cmUg c28gaGFzIG90aGVycykgLCBJIGNhbiBzYXkgdGhhdCB0aGUgZG9jdW1lbnQgd2FzIG5vdCB2ZXJ5 IGVmZmVjdGl2ZSBmb3IgaW1wbGVtZW50ZXJzLiBXaGlsZSB0aGUgY29uY2VwdCBsYWlkIG91dCBt aWdodCBiZSB1c2VmdWwgYnV0IGl0IGRvZXNu4oCZdCB0cmFuc2xhdGUgaW50byBhbnl0aGluZyBt ZWFuaW5nZnVsLiANCg0KSSBhbSBhY3R1YWxseSB3b25kZXJpbmcgaWYgdGhlcmUgaXMgYSBuZWVk IGNvbnRyb2wgcGxhbmUgZG9jdW1lbnQsIGhvd2V2ZXIgdGhlcmUgaXMgYSBuZWVkIGZvciBkZWZp bmluZyB0aGUgQVBJL1NjaGVtYSBldGMuIA0KDQpTdW1hbmRyYQ0KDQpPbiAxLzEzLzE3LCAxMDox MiBBTSwgInNmYyBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJuIiA8c2ZjLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KDQogICAgSmlt IGFuZCBJIGhhdmUgYmVlbiB0YWxraW5nIHdpdGggQWxpYSBhYm91dCB0aGlzLCBhbmQgdGFsa2lu ZyB3aXRoIGVhY2ggDQogICAgb3RoZXIuICBBbG9uZyB0aGUgd2F5IHdlIHJlYWxpemVkIHRoYXQg d2UgaGF2ZSBzb21lIHNpZ25pZmljYW50IGNvbmNlcm5zIA0KICAgIGFib3V0IHdoYXQgd2UgaGF2 ZSBkb25lIHdpdGggdGhpcyBkb2N1bWVudC4NCiAgICANCiAgICBXZSBleHBlY3QgdG8gZGlzY3Vz cyB0aGlzIG5leHQgd2VlayBhdCB0aGUgaW50ZXJpbSwgbG9va2luZyBmb3IgaWRlYXMuIA0KICAg IEFuZCB0byBkaXNjdXNzIGl0IGZ1cnRoZXIgb24gdGhlIGxpc3QuDQogICAgDQogICAgVGhlIGV4 aXN0aW5nIGNvbnRyb2wgcGxhbmUgZG9jdW1lbnQgd2hlbiB2aWV3ZWQgZnJvbSB0aGUgcGVyc3Bl Y3RpdmUgb2YgDQogICAgYW4gaW1wbGVtZW50ZXIgaXMgaGFyZCB0byBkZWNvbXBvc2UgaW50byBh Y3Rpb25hYmxlIHBhcnRzLiBHaXZlbiB0aGF0IA0KICAgIHRoZSBJRVRGIHRlbmRzIHRvIHdvcmsg Ynkgc29sdmluZyBwaWVjZXMgb2YgcHJvYmxlbXMsIHJhdGhlciB0aGFuIGFuIA0KICAgIGVudGly ZSBjb250cm9sIHNvbHV0aW9uIGZvciBhbGwgYXNwZWN0cywgaXQgaXMgaW1wb3J0YW50IHRoYXQg DQogICAgcmVxdXJpZW1lbnRzIHdlIGRlZmluZSBiZSB1c2FibGUgZm9yIHN1Y2ggcGllY2Utd2lz ZSB3b3JrLiBUaHVzLCB3ZSBuZWVkIA0KICAgIHRvIGRlc2NyaWJlIHRoZSByZXF1aXJlbWVudHMg aW4gd2F5cyB0aGF0IHByb3ZpZGUgY29tcG9uZW50cyB3aGljaCBtYXkgDQogICAgYmUgY29tYmlu ZWQgaW50byBhbiBvdmVyYWxsIGNvbnRyb2wgcGxhbmUgc29sdXRpb24gZm9yIFNGQy4NCiAgICAN CiAgICBXaGlsZSB0aGUgZG9jdW1lbnQgcHJvdmlkZXMgYSBzZXQgb2YgY29udHJvbCBwbGFuZSBy ZXF1aXJlbWVudHMgaXQgZG9lcyANCiAgICBub3QgcHJvdmlkZSBndWlkYW5jZSBvbiBob3cgdGhv c2UgcmVxdWlyZW1lbnRzIGNhbiBiZSBzdWNjZXNzZnVsbHkgDQogICAgY29uc3VtZWQgaW50byBh IHN0YW5kYXJkcyBjb21wbGlhbnQgY29udHJvbCBwbGFuZS4gSW4gcGFydGljdWxhciwgdGhlIA0K ICAgIGludGVyZmFjZXMgQzEgLSBDNCBhcmUgZWFjaCBtYWRlIHVwIG9mIGJlaGF2aW9ycyBsaWtl bHkgdG8gYmUgcHJvdmlkZWQgDQogICAgYnkgZGlmZmVyZW50IHNvbHV0aW9uIGNvbXBvbmVudHMu ICBUaHVzLCB3aGlsZSB0aGVyZSBpcyBhbiBhdHRlbXB0IHRvIA0KICAgIGRvY3VtZW50IGEgc2V0 IG9mIGludGVyZmFjZXMgKEMxLi4uQzQpIGl0IGlzIG5vdCBjbGVhciBob3cgYW4gDQogICAgaW1w bGVtZW50ZXIgY2FuIHByb3ZpZGUgYSBzb2x1dGlvbiBjb21wb25lbnQgdGhhdCBhZGRyZXNzZXMg YSANCiAgICB3ZWxsLWRlZmluZWQgc2V0IG9mIHJlcXVpcmVtZW50cy4NCiAgICANCiAgICBHaXZl biB0aGlzLCB3ZSBuZWVkIHRvIGdvIGJhY2sgYW5kIHJldGhpbmsgdGhlIGJ1bmRsaW5nIG9mIGZ1 bmN0aW9uYWxpdHkgDQogICAgc28gYXMgdG8gZW5kIHVwIHdpdGggYnVuZGxlcyBvZiByZXF1aXJl bWVudHMgdGhhdCBhcmUgY2FuIGJlIHVzZWZ1bGx5IA0KICAgIGFkZHJlc3NlZCBieSBJRVRGIHdv cmsgd2hpbGUgYXZvaWRpbmcgKGFzIHdlIGhhdmUgZG9uZSB3ZWxsIGluIHRoZSANCiAgICBjdXJy ZW50IHZlcnNpb24pIHByZXNjcmliaW5nIHRoZSBjb250cm9sIHBsYW5lIGFyY2hpdGVjdHVyZS4N CiAgICANCiAgICBJbiBhZGRpdGlvbiwgZnVuY3Rpb25hbCBvYmplY3RpdmVzIGFyZSBub3QgZmlu ZSBncmFpbmVkIGVub3VnaCB0byANCiAgICBpbXBsZW1lbnQ7IGZvciBleGFtcGxlLCB0ZXh0IHN1 Y2ggYXMgIlJhdGlvbmFsaXplIHRoZSBtYW5hZ2VtZW50IG9mIA0KICAgIGNsYXNzaWZpY2F0aW9u IHJ1bGVzIiBpcyBub3Qgc29tZXRoaW5nIG9uZSBjYW4gaW1wbGVtZW50Lg0KICAgIA0KICAgIFlv dXJzLA0KICAgIA0KICAgIEppbSAmIEpvZWwNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHNmYyBtYWlsaW5nIGxpc3QNCiAgICBz ZmNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KICAgIA0KDQo= From nobody Sat Jan 14 07:13:40 2017 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 D2B28129C3B for ; Sat, 14 Jan 2017 07:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 316bsLnJ7K0Q for ; Sat, 14 Jan 2017 07:13:37 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 6156912945E for ; Sat, 14 Jan 2017 07:13:37 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0EFAmbl021058 for ; Sat, 14 Jan 2017 07:13:37 -0800 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 27yj7s8rqs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Sat, 14 Jan 2017 07:13:37 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 14 Jan 2017 17:13:32 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1210.000; Sat, 14 Jan 2017 17:13:32 +0200 From: Tal Mizrahi To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-mymb-sfc-nsh-allocation-timestamp-00.txt Thread-Index: AdJueGP8BZYM0pcETYqlsREVZola2Q== Date: Sat, 14 Jan 2017 15:13:31 +0000 Message-ID: <30bfc30c2fea417b9c3697ab2f814709@IL-EXCH01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-14_02:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701140229 Archived-At: Subject: [sfc] FW: New Version Notification for draft-mymb-sfc-nsh-allocation-timestamp-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 15:13:39 -0000 SGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IHRoYXQgZGVmaW5lcyBhbiBNRCBU eXBlIDEgY29udGV4dCBoZWFkZXIgYWxsb2NhdGlvbiB0aGF0IGluY2x1ZGVzIGFuIGluZ3Jlc3Mg dGltZXN0YW1wLCBpbmRpY2F0aW5nIHRoZSB0aW1lIGF0IHdoaWNoIHRoZSBwYWNrZXQgd2FzIHJl Y2VpdmVkIGJ5IHRoZSBTRkMgQ2xhc3NpZmllci4NCg0KQ29tbWVudHMgd2lsbCBiZSB3ZWxjb21l Lg0KDQpDaGVlcnMsDQpUYWwgTWl6cmFoaS4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTIsIDIwMTcgMToxNyBQTQ0K VG86IFRhbCBNaXpyYWhpOyBEYXZpZCBNZWxtYW47IFJvcnkgQnJvd25lOyBJbGFuIFllcnVzaGFs bWkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbXltYi1zZmMt bnNoLWFsbG9jYXRpb24tdGltZXN0YW1wLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1teW1iLXNmYy1uc2gtYWxsb2NhdGlvbi10aW1lc3RhbXAtMDAudHh0DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRhbCBNaXpyYWhpIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LW15bWItc2ZjLW5zaC1hbGxvY2F0aW9u LXRpbWVzdGFtcA0KUmV2aXNpb246CTAwDQpUaXRsZToJCU5ldHdvcmsgU2VydmljZSBIZWFkZXIg KE5TSCkgQ29udGV4dCBIZWFkZXIgQWxsb2NhdGlvbjogVGltZXN0YW1wDQpEb2N1bWVudCBkYXRl OgkyMDE3LTAxLTEyDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk4DQpV Ukw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LW15bWItc2ZjLW5zaC1hbGxvY2F0aW9uLXRpbWVzdGFtcC0wMC50eHQNClN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1teW1iLXNmYy1uc2gtYWxs b2NhdGlvbi10aW1lc3RhbXAvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LW15bWItc2ZjLW5zaC1hbGxvY2F0aW9uLXRpbWVzdGFtcC0wMA0KDQoNCkFi c3RyYWN0Og0KICAgVGhpcyBtZW1vIGRlZmluZXMgYW4gYWxsb2NhdGlvbiBmb3IgdGhlIENvbnRl eHQgSGVhZGVycyBvZiB0aGUNCiAgIE5ldHdvcmsgU2VydmljZSBIZWFkZXIgKE5TSCksIHdoaWNo IGluY29ycG9yYXRlcyB0aGUgcGFja2V0J3MgaW5ncmVzcw0KICAgdGltZXN0YW1wLCBhIHNlcXVl bmNlIG51bWJlciwgYW5kIGEgc291cmNlIGludGVyZmFjZSBpZGVudGlmaWVyLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Sat Jan 14 07:50:44 2017 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 7645612A02D for ; Sat, 14 Jan 2017 07:50:41 -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 YgVJjB_dxBM7 for ; Sat, 14 Jan 2017 07:50:39 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10E3129685 for ; Sat, 14 Jan 2017 07:50:39 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id r136so50913766vke.1 for ; Sat, 14 Jan 2017 07:50:39 -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=FEQUhDZ9F6Ru959EVGQKZNtlMtC68ThQl+tNooufUdc=; b=TNiO3r74ONAafLpHmfyZ8CeB0VNjtL+VsvCBvgiNhAyXIOeDl0KGx2iHBEyzVKhwIG rD9cV+Stf+iQzhNwQ5/OxvvIuNcpHFVrstELPrP44T17H+T4AuaQVsr4+U8FDMpqQ9vo uWsvFLcI1VycdDA2ftHtu52/mnG2ho00lqK2qp1xemg+EQPPV4iWHuWHAOZ/7LjziVvQ x5PTzuegE/3IppjHiN09GDPy3JBcLsLH5UYxUiq3DBxcwH98ps7vqekI5X6F37Krhbuc iMBwFO03aNN2vNv+T3JQuz7YSkq0LG2PjfCU9TMNjhz0YTbavTTSA0Gc42JvxHJjPCzs oEzw== 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=FEQUhDZ9F6Ru959EVGQKZNtlMtC68ThQl+tNooufUdc=; b=dhwa+AQ8qaF875A0gXVMSaBOtO65pLWKeeuw55G5bS2zFw+vg6xNVa9VJX5+t4DJPJ l3p/eVvqEXCidjNLY9262biNGIEPDrvj+awrvtSkAqOMrwYimwjZpv4gTYp9BB5IxOwd qu57j1RW3eegJ7GLHc6aPijR6CgdFjrM32NPRm0pfX0QSWp4sWOKnn3XIKSQYw0UaN4i /anxmxUSrHFjIGy9OVDHO2XBr3sS+dw3922XKT/YwS4feaoOCVrszAKriN4AhTKXFRzf 3aRtv5+Zoij3oQlHfFyUh0A2IUSjK7De/4uV/Uysf5bGvVfQsAs5n89DFe4Ca1uwByxH u6Vg== X-Gm-Message-State: AIkVDXJNolrKInvFFEuxbXvAbTmJ8MNECYNVfkgfegvf7aGaYL5/rHe/1Hn0KqfxFj5HG8h+A584Li3BPSg1pQ== X-Received: by 10.31.155.75 with SMTP id d72mr11381769vke.55.1484409038816; Sat, 14 Jan 2017 07:50:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.144.209 with HTTP; Sat, 14 Jan 2017 07:50:38 -0800 (PST) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D57B9F7FD@dfweml501-mbb> References: <2691CE0099834E4A9C5044EEC662BB9D57B9F7FD@dfweml501-mbb> From: Jim Guichard Date: Sat, 14 Jan 2017 10:50:38 -0500 Message-ID: To: Lucy yong Content-Type: multipart/alternative; boundary=001a1141ddd275cfc905460fe910 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH text enhancement suggestion X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 15:50:41 -0000 --001a1141ddd275cfc905460fe910 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lucy, The current text in section 3.2 says "...The length MUST be of value 0x6 for MD Type equal to 0x1 and MUST be of value 0x2 or greater for MD type equal to 0x2 .." To accommodate the hierarchical SFC case a simple addition of "or greater" to the above text for MD type 0x1 should resolve the issue you describe. I would also suggest adding text to draft-ietf-sfc-hierarchical-02 to indicate that it MUST update the NSH base header length to reflect both the original NSH header and any NSH headers added to the packet/frame by that draft. Thoughts? Jim On Fri, Jan 13, 2017 at 6:09 PM, Lucy yong wrote: > Length field in NSH base header contains value of total length of NSH. > > > > =E2=80=9C The length field indicates the "end" of NSH and where the origi= nal > packet/frame begins.=E2=80=9D > > > > =E2=80=9CIn that case, the MD Type 0x1 node, MUST utilize the base header= length > field to determine > > the original payload offset if it requires access to the original > > packet/frame.=E2=80=9D > > > > Comment: above text does not accurate for the hierarchical SFC case > (draft-ietf-sfc-hierarchical-02.txt) > > > > suggested text: > > > > =E2=80=9C The length field indicates the "end" of NSH header; if the next= protocol > in base header is not =E2=80=9CNSH=E2=80=9D, it also indicates the origi= nal packet/frame > begins. To locate the original packet/frame begins on NSH packet, a > recursive process can be used until the next protocol in a based header i= s > not =E2=80=9CNSH=E2=80=9D; the sum of total length of all NSH headers on = a NSH packet is > the offset of the original packet/frame. > > > > Lucy > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > --001a1141ddd275cfc905460fe910 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lucy,

The current text in section 3.= 2 says "...The length MUST be of value 0x6 for MD Type equal to 0x1 an= d MUST be of value 0x2 or greater for MD type equal to 0x2 .." To acco= mmodate the hierarchical SFC case a simple addition of "or greater&quo= t; to the above text for MD type 0x1 should resolve the issue you describe.= I would also suggest adding text to draft-ietf-sfc-hierarchical-02 to indi= cate that it MUST update the NSH base header length to reflect both the ori= ginal NSH header and any NSH headers added to the packet/frame by that draf= t.

Thoughts?

Jim=C2=A0



On Fri, Jan 13, 2017 at 6:09 PM, Lucy yong <lucy= .yong@huawei.com> wrote:

Length field in NSH base header contains value of to= tal length of NSH. =C2=A0

=C2=A0

=E2=80=9C The length field indicates the "end&q= uot; of NSH and where the original packet/frame begins.=E2=80=9D<= /u>

=C2=A0

=E2=80=9CIn that case, the MD Type 0x1 node, MUST ut= ilize the base header length field to determine

=C2=A0=C2=A0 the original payload offset if it requi= res access to the original

=C2=A0=C2=A0 packet/frame.=E2=80=9D

=C2=A0

Comment: above text does not= accurate for the hierarchical SFC case (draft-ietf-sfc-hierarchical-0= 2.txt)

=C2=A0

suggested text:

=C2=A0

=E2=80=9C The length field indicates the "end&q= uot; of NSH header; if the next protocol in base header is not =E2=80=9CNSH= =E2=80=9D, =C2=A0it also indicates the original packet/frame begins. To loc= ate the original packet/frame begins on NSH packet, a recursive process can be used until the next protocol in a based header is not =E2=80=9CNSH=E2= =80=9D; the sum of total length of all NSH headers on a NSH packet is the o= ffset of the original packet/frame.

=C2=A0

Lucy

=C2=A0

=C2=A0


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


--001a1141ddd275cfc905460fe910-- From nobody Sat Jan 14 09:17:42 2017 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 0C2B412987A for ; Sat, 14 Jan 2017 09:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y8KReWCR4ix for ; Sat, 14 Jan 2017 09:17:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2057A1297C2 for ; Sat, 14 Jan 2017 09:17:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYU06166; Sat, 14 Jan 2017 17:17:27 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 14 Jan 2017 17:17:26 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0301.000; Sat, 14 Jan 2017 09:17:24 -0800 From: Lucy yong To: Jim Guichard Thread-Topic: [sfc] NSH text enhancement suggestion Thread-Index: AdJt8gU9qUFvdUHaRGuVS0ztkbmneAAzvxAAAA6jIrA= Date: Sat, 14 Jan 2017 17:17:22 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57B9FAFF@dfweml501-mbb> References: <2691CE0099834E4A9C5044EEC662BB9D57B9F7FD@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.226] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D57B9FAFFdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.587A5D28.0069, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 01734d9fdf45334dedd8b297f2587479 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH text enhancement suggestion X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 17:17:36 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D57B9FAFFdfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmltLA0KDQpUbyBhY2NvbW1vZGF0ZSB0aGUgaGllcmFyY2hpY2FsIFNGQyBjYXNlLCBOU0gg ZHJhZnQgIGlzIG5lY2Vzc2FyeSB0byBzcGVjaWZ5IHRoZSBtZWFuaW5nIG9mIHRoZSBsZW5ndGgg aW4gYmFzZSBoZWFkZXI6ICAxKSBsZW5ndGggbWVhbnMgdGhlIGJ5dGVzIG9mIE5TSCBoZWFkZXI7 IG9yIDIpIGxlbmd0aCBpbmRpY2F0ZXMgdGhlIG9mZnNldCBvZiB0aGUgb3JpZ2luYWwgcGFja2V0 L2ZyYW1lLg0KDQpMdWN5DQpGcm9tOiBKaW0gR3VpY2hhcmQgW21haWx0bzpqZ3VpY2hhcmQxOTY2 QGdtYWlsLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDE0LCAyMDE3IDk6NTEgQU0NClRv OiBMdWN5IHlvbmcNCkNjOiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBOU0ggdGV4 dCBlbmhhbmNlbWVudCBzdWdnZXN0aW9uDQoNCkhpIEx1Y3ksDQoNClRoZSBjdXJyZW50IHRleHQg aW4gc2VjdGlvbiAzLjIgc2F5cyAiLi4uVGhlIGxlbmd0aCBNVVNUIGJlIG9mIHZhbHVlIDB4NiBm b3IgTUQgVHlwZSBlcXVhbCB0byAweDEgYW5kIE1VU1QgYmUgb2YgdmFsdWUgMHgyIG9yIGdyZWF0 ZXIgZm9yIE1EIHR5cGUgZXF1YWwgdG8gMHgyIC4uIiBUbyBhY2NvbW1vZGF0ZSB0aGUgaGllcmFy Y2hpY2FsIFNGQyBjYXNlIGEgc2ltcGxlIGFkZGl0aW9uIG9mICJvciBncmVhdGVyIiB0byB0aGUg YWJvdmUgdGV4dCBmb3IgTUQgdHlwZSAweDEgc2hvdWxkIHJlc29sdmUgdGhlIGlzc3VlIHlvdSBk ZXNjcmliZS4gSSB3b3VsZCBhbHNvIHN1Z2dlc3QgYWRkaW5nIHRleHQgdG8gZHJhZnQtaWV0Zi1z ZmMtaGllcmFyY2hpY2FsLTAyIHRvIGluZGljYXRlIHRoYXQgaXQgTVVTVCB1cGRhdGUgdGhlIE5T SCBiYXNlIGhlYWRlciBsZW5ndGggdG8gcmVmbGVjdCBib3RoIHRoZSBvcmlnaW5hbCBOU0ggaGVh ZGVyIGFuZCBhbnkgTlNIIGhlYWRlcnMgYWRkZWQgdG8gdGhlIHBhY2tldC9mcmFtZSBieSB0aGF0 IGRyYWZ0Lg0KDQpUaG91Z2h0cz8NCg0KSmltDQoNCg0KDQpPbiBGcmksIEphbiAxMywgMjAxNyBh dCA2OjA5IFBNLCBMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5Lnlv bmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KTGVuZ3RoIGZpZWxkIGluIE5TSCBiYXNlIGhlYWRlciBj b250YWlucyB2YWx1ZSBvZiB0b3RhbCBsZW5ndGggb2YgTlNILg0KDQrigJwgVGhlIGxlbmd0aCBm aWVsZCBpbmRpY2F0ZXMgdGhlICJlbmQiIG9mIE5TSCBhbmQgd2hlcmUgdGhlIG9yaWdpbmFsIHBh Y2tldC9mcmFtZSBiZWdpbnMu4oCdDQoNCuKAnEluIHRoYXQgY2FzZSwgdGhlIE1EIFR5cGUgMHgx IG5vZGUsIE1VU1QgdXRpbGl6ZSB0aGUgYmFzZSBoZWFkZXIgbGVuZ3RoIGZpZWxkIHRvIGRldGVy bWluZQ0KICAgdGhlIG9yaWdpbmFsIHBheWxvYWQgb2Zmc2V0IGlmIGl0IHJlcXVpcmVzIGFjY2Vz cyB0byB0aGUgb3JpZ2luYWwNCiAgIHBhY2tldC9mcmFtZS7igJ0NCg0KDQpDb21tZW50OiBhYm92 ZSB0ZXh0IGRvZXMgbm90IGFjY3VyYXRlIGZvciB0aGUgaGllcmFyY2hpY2FsIFNGQyBjYXNlIChk cmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWwtMDIudHh0KQ0KDQpzdWdnZXN0ZWQgdGV4dDoNCg0K 4oCcIFRoZSBsZW5ndGggZmllbGQgaW5kaWNhdGVzIHRoZSAiZW5kIiBvZiBOU0ggaGVhZGVyOyBp ZiB0aGUgbmV4dCBwcm90b2NvbCBpbiBiYXNlIGhlYWRlciBpcyBub3Qg4oCcTlNI4oCdLCAgaXQg YWxzbyBpbmRpY2F0ZXMgdGhlIG9yaWdpbmFsIHBhY2tldC9mcmFtZSBiZWdpbnMuIFRvIGxvY2F0 ZSB0aGUgb3JpZ2luYWwgcGFja2V0L2ZyYW1lIGJlZ2lucyBvbiBOU0ggcGFja2V0LCBhIHJlY3Vy c2l2ZSBwcm9jZXNzIGNhbiBiZSB1c2VkIHVudGlsIHRoZSBuZXh0IHByb3RvY29sIGluIGEgYmFz ZWQgaGVhZGVyIGlzIG5vdCDigJxOU0jigJ07IHRoZSBzdW0gb2YgdG90YWwgbGVuZ3RoIG9mIGFs bCBOU0ggaGVhZGVycyBvbiBhIE5TSCBwYWNrZXQgaXMgdGhlIG9mZnNldCBvZiB0aGUgb3JpZ2lu YWwgcGFja2V0L2ZyYW1lLg0KDQpMdWN5DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KDQo= --_000_2691CE0099834E4A9C5044EEC662BB9D57B9FAFFdfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tMzg1NDM1NjE1NTcwNzg3NTExOW1zb3BsYWludGV4dCwg bGkubTM4NTQzNTYxNTU3MDc4NzUxMTltc29wbGFpbnRleHQsIGRpdi5tMzg1NDM1NjE1NTcwNzg3 NTExOW1zb3BsYWludGV4dA0KCXttc28tc3R5bGUtbmFtZTptXzM4NTQzNTYxNTU3MDc4NzUxMTlt c29wbGFpbnRleHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSmltLDxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UbyBhY2NvbW1vZGF0ZSB0aGUgaGllcmFyY2hpY2FsIFNGQyBjYXNlLCBOU0gg ZHJhZnQgJm5ic3A7aXMgbmVjZXNzYXJ5IHRvIHNwZWNpZnkgdGhlIG1lYW5pbmcgb2YgdGhlIGxl bmd0aCBpbiBiYXNlIGhlYWRlcjogJm5ic3A7MSkgbGVuZ3RoIG1lYW5zIHRoZSBieXRlcyBvZiBO U0gNCiBoZWFkZXI7IG9yIDIpIGxlbmd0aCBpbmRpY2F0ZXMgdGhlIG9mZnNldCBvZiB0aGUgb3Jp Z2luYWwgcGFja2V0L2ZyYW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkx1Y3k8bzpwPjwvbzpwPjwvc3Bhbj48L2k+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IEppbSBHdWljaGFyZCBbbWFpbHRvOmpndWljaGFyZDE5NjZAZ21haWwu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKYW51YXJ5IDE0LCAyMDE3IDk6NTEg QU08YnI+DQo8Yj5Ubzo8L2I+IEx1Y3kgeW9uZzxicj4NCjxiPkNjOjwvYj4gc2ZjQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBOU0ggdGV4dCBlbmhhbmNlbWVudCBzdWdn ZXN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBM dWN5LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGN1 cnJlbnQgdGV4dCBpbiBzZWN0aW9uIDMuMiBzYXlzICZxdW90Oy4uLlRoZSBsZW5ndGggTVVTVCBi ZSBvZiB2YWx1ZSAweDYgZm9yIE1EIFR5cGUgZXF1YWwgdG8gMHgxIGFuZCBNVVNUIGJlIG9mIHZh bHVlIDB4MiBvciBncmVhdGVyIGZvciBNRCB0eXBlIGVxdWFsIHRvIDB4MiAuLiZxdW90OyBUbyBh Y2NvbW1vZGF0ZSB0aGUgaGllcmFyY2hpY2FsIFNGQyBjYXNlIGEgc2ltcGxlIGFkZGl0aW9uIG9m ICZxdW90O29yIGdyZWF0ZXImcXVvdDsNCiB0byB0aGUgYWJvdmUgdGV4dCBmb3IgTUQgdHlwZSAw eDEgc2hvdWxkIHJlc29sdmUgdGhlIGlzc3VlIHlvdSBkZXNjcmliZS4gSSB3b3VsZCBhbHNvIHN1 Z2dlc3QgYWRkaW5nIHRleHQgdG8gZHJhZnQtaWV0Zi1zZmMtaGllcmFyY2hpY2FsLTAyIHRvIGlu ZGljYXRlIHRoYXQgaXQgTVVTVCB1cGRhdGUgdGhlIE5TSCBiYXNlIGhlYWRlciBsZW5ndGggdG8g cmVmbGVjdCBib3RoIHRoZSBvcmlnaW5hbCBOU0ggaGVhZGVyIGFuZCBhbnkgTlNIIGhlYWRlcnMN CiBhZGRlZCB0byB0aGUgcGFja2V0L2ZyYW1lIGJ5IHRoYXQgZHJhZnQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob3VnaHRzPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaW0mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIEZyaSwgSmFuIDEzLCAyMDE3IGF0IDY6MDkgUE0sIEx1Y3kgeW9uZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bHVjeS55b25nQGh1 YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5MZW5ndGggZmllbGQgaW4gTlNIIGJhc2UgaGVhZGVyIGNvbnRh aW5zIHZhbHVlIG9mIHRvdGFsIGxlbmd0aCBvZiBOU0guICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+4oCcIFRoZSBsZW5ndGggZmllbGQgaW5kaWNhdGVzIHRoZSAmcXVvdDtlbmQm cXVvdDsgb2YgTlNIIGFuZCB3aGVyZSB0aGUgb3JpZ2luYWwgcGFja2V0L2ZyYW1lIGJlZ2lucy7i gJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPuKAnEluIHRoYXQgY2FzZSwgdGhlIE1EIFR5 cGUgMHgxIG5vZGUsIE1VU1QgdXRpbGl6ZSB0aGUgYmFzZSBoZWFkZXIgbGVuZ3RoIGZpZWxkIHRv IGRldGVybWluZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsm bmJzcDsgdGhlIG9yaWdpbmFsIHBheWxvYWQgb2Zmc2V0IGlmIGl0IHJlcXVpcmVzIGFjY2VzcyB0 byB0aGUgb3JpZ2luYWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7Jm5ic3A7IHBhY2tldC9mcmFtZS7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTM4NTQzNTYxNTU3MDc4 NzUxMTltc29wbGFpbnRleHQiPkNvbW1lbnQ6IGFib3ZlIHRleHQgZG9lcyBub3QgYWNjdXJhdGUg Zm9yIHRoZSBoaWVyYXJjaGljYWwgU0ZDIGNhc2UgKGRyYWZ0LWlldGYtc2ZjLWhpZXJhcmNoaWNh bC0wMi50eHQpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zdWdnZXN0ZWQgdGV4dDo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPuKAnCBUaGUgbGVuZ3RoIGZpZWxkIGluZGljYXRlcyB0 aGUgJnF1b3Q7ZW5kJnF1b3Q7IG9mIE5TSCBoZWFkZXI7IGlmIHRoZSBuZXh0IHByb3RvY29sIGlu IGJhc2UgaGVhZGVyIGlzIG5vdCDigJxOU0jigJ0sICZuYnNwO2l0IGFsc28gaW5kaWNhdGVzIHRo ZSBvcmlnaW5hbCBwYWNrZXQvZnJhbWUgYmVnaW5zLiBUbyBsb2NhdGUgdGhlIG9yaWdpbmFsDQog cGFja2V0L2ZyYW1lIGJlZ2lucyBvbiBOU0ggcGFja2V0LCBhIHJlY3Vyc2l2ZSBwcm9jZXNzIGNh biBiZSB1c2VkIHVudGlsIHRoZSBuZXh0IHByb3RvY29sIGluIGEgYmFzZWQgaGVhZGVyIGlzIG5v dCDigJxOU0jigJ07IHRoZSBzdW0gb2YgdG90YWwgbGVuZ3RoIG9mIGFsbCBOU0ggaGVhZGVycyBv biBhIE5TSCBwYWNrZXQgaXMgdGhlIG9mZnNldCBvZiB0aGUgb3JpZ2luYWwgcGFja2V0L2ZyYW1l LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+THVjeTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc2ZjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_2691CE0099834E4A9C5044EEC662BB9D57B9FAFFdfweml501mbb_-- From nobody Sat Jan 14 11:57:10 2017 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 97BB0129D62 for ; Sat, 14 Jan 2017 11:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199] 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 EPiaBcJ6ng4v for ; Sat, 14 Jan 2017 11:57:05 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB6A129410 for ; Sat, 14 Jan 2017 11:57:04 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Sat, 14 Jan 2017 14:57:02 -0500 From: Dave Dolson To: Lucy yong , Jim Guichard Thread-Topic: [sfc] NSH text enhancement suggestion Thread-Index: AdJt8gU9qUFvdUHaRGuVS0ztkbmneAAtdb0AAAMHdQD//9jJPw== Date: Sat, 14 Jan 2017 19:57:01 +0000 Message-ID: <20170114195659.5697621.49685.130444@sandvine.com> References: <2691CE0099834E4A9C5044EEC662BB9D57B9F7FD@dfweml501-mbb> , <2691CE0099834E4A9C5044EEC662BB9D57B9FAFF@dfweml501-mbb> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D57B9FAFF@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_20170114195659569762149685130444sandvinecom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] NSH text enhancement suggestion X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 19:57:06 -0000 --_000_20170114195659569762149685130444sandvinecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think it must be (1). The length in the first header should not include t= he second header. From: Lucy yong Sent: Saturday, January 14, 2017 12:17 PM To: Jim Guichard Cc: sfc@ietf.org Subject: Re: [sfc] NSH text enhancement suggestion Hi Jim, To accommodate the hierarchical SFC case, NSH draft is necessary to specif= y the meaning of the length in base header: 1) length means the bytes of N= SH header; or 2) length indicates the offset of the original packet/frame. Lucy From: Jim Guichard [mailto:jguichard1966@gmail.com] Sent: Saturday, January 14, 2017 9:51 AM To: Lucy yong Cc: sfc@ietf.org Subject: Re: [sfc] NSH text enhancement suggestion Hi Lucy, The current text in section 3.2 says "...The length MUST be of value 0x6 fo= r MD Type equal to 0x1 and MUST be of value 0x2 or greater for MD type equa= l to 0x2 .." To accommodate the hierarchical SFC case a simple addition of = "or greater" to the above text for MD type 0x1 should resolve the issue you= describe. I would also suggest adding text to draft-ietf-sfc-hierarchical-= 02 to indicate that it MUST update the NSH base header length to reflect bo= th the original NSH header and any NSH headers added to the packet/frame by= that draft. Thoughts? Jim On Fri, Jan 13, 2017 at 6:09 PM, Lucy yong > wrote: Length field in NSH base header contains value of total length of NSH. =93 The length field indicates the "end" of NSH and where the original pack= et/frame begins.=94 =93In that case, the MD Type 0x1 node, MUST utilize the base header length = field to determine the original payload offset if it requires access to the original packet/frame.=94 Comment: above text does not accurate for the hierarchical SFC case (draft-= ietf-sfc-hierarchical-02.txt) suggested text: =93 The length field indicates the "end" of NSH header; if the next protoco= l in base header is not =93NSH=94, it also indicates the original packet/f= rame begins. To locate the original packet/frame begins on NSH packet, a re= cursive process can be used until the next protocol in a based header is no= t =93NSH=94; the sum of total length of all NSH headers on a NSH packet is = the offset of the original packet/frame. Lucy _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_20170114195659569762149685130444sandvinecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
From: Lucy yong
Sent: Saturday, January 14, 2017 12:17 PM
To: Jim Guichard
Cc: sfc@ietf.org
Subject: Re: [sfc] NSH text enhancement suggestion

Hi Jim,

 

To accommodate the h= ierarchical SFC case, NSH draft  is necessary to specify the meaning o= f the length in base header:  1) length means the bytes of NSH header; or 2) length indicates the offset of the original packet/frame.

   &n= bsp;            = ;           

Lucy

From: Jim Gu= ichard [mailto:jguichard1966@gmail.com]
Sent: Saturday, January 14, 2017 9:51 AM
To: Lucy yong
Cc: sfc@ietf.org
Subject: Re: [sfc] NSH text enhancement suggestion

 

Hi Lucy,

 

The current text in section 3.2 says "...The le= ngth MUST be of value 0x6 for MD Type equal to 0x1 and MUST be of value 0x2= or greater for MD type equal to 0x2 .." To accommodate the hierarchic= al SFC case a simple addition of "or greater" to the above text for MD type 0x1 should resolve the issue you describe. I= would also suggest adding text to draft-ietf-sfc-hierarchical-02 to indica= te that it MUST update the NSH base header length to reflect both the origi= nal NSH header and any NSH headers added to the packet/frame by that draft.

 

Thoughts?

 

Jim 

 

 

 

On Fri, Jan 13, 2017 at 6:09 PM, Lucy yong <lucy.yong@huawei.com> wrote:

Length field in NSH base header contains = value of total length of NSH.  

 

=93 The length field indicates the "= end" of NSH and where the original packet/frame begins.=94

 

=93In that case, the MD Type 0x1 node, MU= ST utilize the base header length field to determine

   the original payload offset = if it requires access to the original

   packet/frame.=94

 

Comment: above text does not = accurate for the hierarchical SFC case (draft-ietf-sfc-hierarchical-02.txt)=

 

suggested text:

 

=93 The length field indicates the "= end" of NSH header; if the next protocol in base header is not =93NSH= =94,  it also indicates the original packet/frame begins. To locate th= e original packet/frame begins on NSH packet, a recursive process can be used until the next protocol in a based header is not =93NS= H=94; the sum of total length of all NSH headers on a NSH packet is the off= set of the original packet/frame.

 

Lucy=

 

 


_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

 

--_000_20170114195659569762149685130444sandvinecom_-- From nobody Mon Jan 16 07:58:51 2017 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 085D0129584 for ; Mon, 16 Jan 2017 07:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_HELO_PASS=-0.001, 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 6QNGvn5IxUP4 for ; Mon, 16 Jan 2017 07:58:48 -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 8B808129529 for ; Mon, 16 Jan 2017 07:58:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6D16326824D for ; Mon, 16 Jan 2017 07:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1484582328; bh=GxGs4BOJzA9oV6chrJ/nfgesJc31wwrK9NeZhGiyLrE=; h=Subject:References:To:From:Date:In-Reply-To:From; b=QXiR/zr9s5GryjkMnsYoRNEJG/CbKNrsHjSHuqY0weRLb5MRnqMUf+dyJ3c1opF+b zRQaKGLBDcGGGci2nQpHHJ7W3Aa3Gg2T7MALHFsfNVbPcZMqFKW3v9/b952+/LqzbI y9zhvmkJ0TY/0TMywD26yZNX6uJxzl8p2PKuabz0= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1439E240704 for ; Mon, 16 Jan 2017 07:58:48 -0800 (PST) References: To: "sfc@ietf.org" From: "Joel M. Halpern" X-Forwarded-Message-Id: Message-ID: Date: Mon, 16 Jan 2017 10:58:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------F63931636B610D119AC82390" Archived-At: Subject: [sfc] Fwd: placeholder lync conference for SFC interim X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 15:58:50 -0000 This is a multi-part message in MIME format. --------------F63931636B610D119AC82390 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The attached is the calendar invite for the Skype remote access to the SFC Interim meeting. I have tried to copy the information accurately below. Times below are in US Eastern time. In case of conflict, the ICS is more accurate than my copy. Yours, Joel When: Tue 17 Jan 2017 11:00 AM – Thu 19 Jan 2017 2:00 PM Organizer: Alia Atlas --> Join Skype Meeting This is an online meeting for Skype for Business, the professional meetings and communications app formerly known as Lync. Join by phone +19785898300 (USA, East Coast) English (United States) +14089369000 (USA, East Coast) English (United States) ILYNC (45962) (USA, East Coast) English (United States) +18446454399 (USA, East Coast) English (United States) Conference ID: 8685394 Forgot your dial-in PIN? --------------F63931636B610D119AC82390 Content-Type: text/calendar; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2010 VERSION:2.0 BEGIN:VTIMEZONE TZID:Greenwich Standard Time BEGIN:STANDARD DTSTART:16010101T000000 TZOFFSETFROM:+0000 TZOFFSETTO:+0000 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T000000 TZOFFSETFROM:+0000 TZOFFSETTO:+0000 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Alia Atlas:MAILTO:akatlas@juniper.net ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=jmh@joelha lpern.com:MAILTO:jmh@joelhalpern.com DESCRIPTION;LANGUAGE=en-US:When: Jan 17\, 2017 11:00:00 AM\nWhere: Skype Me eting\n--\n............................................................... .......................................................................... \n--> Join Skype Meeting\n Thi s is an online meeting for Skype for Business\, the professional meetings and communications app formerly known as Lync.\nJoin by phone\n+1978589830 0 (USA\, East Coast) English (United Stat es)\n+14089369000 (USA\, East Coast) Engl ish (United States)\nILYNC (45962) (USA\, East Coast) English (United States)\n+18446454399 (USA\, East Coast) English (United States)\nFind a local number\n\nConference ID: 8685394\n Forgot your dial-in PIN? |Help\n\n\nPlease consider with whom you are communicating\, including non-Juniper personnel of companies federate d on Lync\, before sharing any confidential information. Non-disclosure a greements may apply.\n[!OC([1033])!]\n.................................... .......................................................................... ...........................\n UID:040000008200E00074C5B7101A82E00800000000703EE8581252D201000000000000000 0100000001EF50759ED8C0F4AA94CFA4EB57ECB9B SUMMARY;LANGUAGE=en-US:placeholder lync conference for SFC interim DTSTART;TZID=Greenwich Standard Time:20170117T160000 DTEND;TZID=Greenwich Standard Time:20170119T190000 CLASS:PUBLIC PRIORITY:5 DTSTAMP:20170116T153642Z TRANSP:OPAQUE STATUS:CONFIRMED SEQUENCE:0 LOCATION;LANGUAGE=en-US:Skype Meeting X-MICROSOFT-CDO-APPT-SEQUENCE:0 X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-DISALLOW-COUNTER:FALSE END:VEVENT END:VCALENDAR --------------F63931636B610D119AC82390-- From nobody Mon Jan 16 08:21:02 2017 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 AC8941299A0 for ; Mon, 16 Jan 2017 08:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, 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 dGyWP6OIUTl9 for ; Mon, 16 Jan 2017 08:20:59 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 A7FB01295A3 for ; Mon, 16 Jan 2017 08:20:58 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id v186so87422851lfa.1 for ; Mon, 16 Jan 2017 08:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=EWd677fM7is5wpHht6qD172dB0xBurQDXozdc6x6zdI=; b=r2uJ/a8NpOT2bBeNvr2y2yO2gB74wd+jopCb0EGpSxulV91ZGqBB5Iq7wZqUMJ6YM5 ryYS5k4XuhHZ/tLyYvb++WRJ57ey7Q+N58sFf4OaDgCZqmcXe8xXBkgESsPAyllkip/y mUS4upmXnr9kzgpKEwTbvly7/tK8JwwnmVixQAwosqS/o3FbxXGs16gVkP03FiYnXDou D9L4u2w/Ob81om9va5hOnHXhd7P5sGkg7KJhm3oCwKXXhJzIq3XMHYHjPZyMnvceqU10 GClR2mBhPvCQee9qm2l9TIaPYoGL37bvz1jTqqdEU/i3a7Xw6ZzeYBazFcBZBOXx+pnq A3ig== 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:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=EWd677fM7is5wpHht6qD172dB0xBurQDXozdc6x6zdI=; b=olis/F1ODveX7H6cI0I/kfX4OxbZcpixX7qk0f+CmDj8TZjbdpCs+NuXl3S9iLT+QD 6hyc/WvPQE1yzUZNA811xK8yTEnyrUChn7OhRjLLCIr7rjsgLRrPR0czqH635O0fvYMD K7ETQUPn430aiAq/Z4gFstJKJdm4ZTtoA+grwwJE3OM7Y0B9Nyb3ERC5xauRqbX77JjC gSuMJVu1wDHtoe377JC4q0+193A+bKP2HX+knXiA/9Bkeh5xP1XI6DUmghSFvkp/b3f8 XSvL5mbgNTAlTywtyC9JRvGHMx8jV+AwdBD/Nw7KMbrrrrO3HYr+zqCT4qc0NIF+5rdl 6Zpg== X-Gm-Message-State: AIkVDXKKr6v4csq0bqcacCQcKJGmJJKg6of3Ako0OP05LZf33lzgnwMtqcV5WNMT/656A+jrsfq05i5OKzXbrQ== X-Received: by 10.46.72.10 with SMTP id v10mr4284178lja.46.1484583656746; Mon, 16 Jan 2017 08:20:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.134.67 with HTTP; Mon, 16 Jan 2017 08:20:55 -0800 (PST) In-Reply-To: References: From: Behcet Sarikaya Date: Mon, 16 Jan 2017 10:20:55 -0600 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Fwd: placeholder lync conference for SFC interim X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 16:21:00 -0000 Does the meeting start at 11am or at 4pm? Skype meeting says 4pm? How do we join the Skype meeting? Behcet On Mon, Jan 16, 2017 at 9:58 AM, Joel M. Halpern wrot= e: > > The attached is the calendar invite for the Skype remote access to the SF= C > Interim meeting. > > I have tried to copy the information accurately below. Times below are i= n > US Eastern time. In case of conflict, the ICS is more accurate than my > copy. > > Yours, > Joel > > When: Tue 17 Jan 2017 11:00 AM =E2=80=93 Thu 19 Jan 2017 2:00 PM > Organizer: Alia Atlas > > --> Join Skype Meeting > > This is an online meeting for Skype for Business, the professional meetin= gs > and communications app formerly known as Lync. > > Join by phone > +19785898300 (USA, East Coast) English (United States) > +14089369000 (USA, East Coast) English (United States) > ILYNC (45962) (USA, East Coast) English (United Stat= es) > +18446454399 (USA, East Coast) English (United States) > > Conference ID: 8685394 > > Forgot your dial-in PIN? > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jan 16 08:23:44 2017 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 A350C1299C5 for ; Mon, 16 Jan 2017 08:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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_HELO_PASS=-0.001, 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 HHIWgRMp331C for ; Mon, 16 Jan 2017 08:23:40 -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 8D9DA1299CA for ; Mon, 16 Jan 2017 08:23:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 75B3E2C313B; Mon, 16 Jan 2017 08:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1484583817; bh=zGRDiIaDvKTPMjG0w760dqEc0UGPOX+FoIlrMmEt9Cc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=S3NMjLJHeq+TgHZ3xEFN2t4chPAWn9rppRHL2H9rem+xImh4Y6/VCUov38RSPsn+h BE2cfIb+COloUiX7Eosd6EF0Z8NR1iqF5OpXCsKDl29pNY77+6EVCVdXixk27O5Dn/ ISQ3JXMFNPRP3oxk0Lc44IzS76bSCZ7JCNV92WcA= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E69BA2C2FC8; Mon, 16 Jan 2017 08:23:36 -0800 (PST) To: sarikaya@ieee.org References: From: Joel Halpern Direct Message-ID: <072d25bc-7663-bcdc-0b35-abb9cae4a142@joelhalpern.com> Date: Mon, 16 Jan 2017 11:23:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Fwd: placeholder lync conference for SFC interim X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 16:23:41 -0000 The meeting starts at 11am EST on Tuesday, and finishes at 2pm EST on Thursday (with adjournment for evenings, breaks for meals, etc...) The HTTPS link in the ICS body and copyied in the email should work for joining. Someone in the room will be monitoring jabber as well. Yours, Joel On 1/16/17 11:20 AM, Behcet Sarikaya wrote: > Does the meeting start at 11am or at 4pm? > Skype meeting says 4pm? > How do we join the Skype meeting? > > Behcet > > On Mon, Jan 16, 2017 at 9:58 AM, Joel M. Halpern wrote: >> >> The attached is the calendar invite for the Skype remote access to the SFC >> Interim meeting. >> >> I have tried to copy the information accurately below. Times below are in >> US Eastern time. In case of conflict, the ICS is more accurate than my >> copy. >> >> Yours, >> Joel >> >> When: Tue 17 Jan 2017 11:00 AM – Thu 19 Jan 2017 2:00 PM >> Organizer: Alia Atlas >> >> --> Join Skype Meeting >> >> This is an online meeting for Skype for Business, the professional meetings >> and communications app formerly known as Lync. >> >> Join by phone >> +19785898300 (USA, East Coast) English (United States) >> +14089369000 (USA, East Coast) English (United States) >> ILYNC (45962) (USA, East Coast) English (United States) >> +18446454399 (USA, East Coast) English (United States) >> >> Conference ID: 8685394 >> >> Forgot your dial-in PIN? >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> From nobody Mon Jan 16 09:13:22 2017 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 789531295C1 for ; Mon, 16 Jan 2017 09:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, 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 mm_Dn_lxzQZ3 for ; Mon, 16 Jan 2017 09:13:20 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 791931295BB for ; Mon, 16 Jan 2017 09:13:19 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id z134so85194611lff.3 for ; Mon, 16 Jan 2017 09:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to; bh=JYP9XkhfBRWjwOisGpd48XgyoMqMcjKXsDHYkPG12Ao=; b=viEFyMoEP1hp8mccN62NQHCA/VJGE7rGv8kpy2MvIGwFQwhaD72Um9UPf9v2zviLls /5IU+TuTw4csIU/vYtfzVcfTZP7yOMZHnJh3YT8Z0IY5ZDBQKMbSjZKLrawSNckXlF2Y vjWrSOzt6LPq9ThcWfpb63lOap9pbqG8ZePWW5lhAIAowHq9VlbMthsxyoWdvRHWNHVX DCHVtklCM3sgAENdPGocXfICI5tk80dRmXsR8dczf4pxkf54TI4pHt51CDrSw7y4594T 8Kzatn6+BkEvFUmFJSwOK3QU3dwmNBrFIOMgIoeWawtMlonbhwqVAEVCTXwD8HRlt/Sy xh5Q== 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:in-reply-to:references :from:date:message-id:subject:to; bh=JYP9XkhfBRWjwOisGpd48XgyoMqMcjKXsDHYkPG12Ao=; b=suH/PW90HhixgpEwyBo3KCedYF3kMn2b5csAWHBNfYVnMgZhidaPDA9AscoEkWVfwZ WlWTUblBS2jA7LtQI+gt9zYyVE9oDI9jYeCWgkrkOcfLYvN4ZL47Sbg6hM1Vt/u1Vx1h mbJzhCcrGmCgJ9M+MDip5Z42hocan6TWNaxjbZqtS8WWeNUP9+SlHcJkKB6rbUEg27py S/cLB9cAV7XLhgOmCLIe/N3RKBne662WuTdgEe0HOvXSBNLl99nTg0yFFKia+9PzlpXb tJsYmtL05HUMKOzVKmIJe2qiifZTlUgDT/NOulczvVA/28aNB8qwQhzqS3rRP325uPc1 5Bew== X-Gm-Message-State: AIkVDXJKDdm4fGoEsMWnoNl3CAU6EeQgI47cdVO9n6j1KDa7uA32VjLoYLfC/aqw2HA4ZKmAxZUWRUFa5VM7uQ== X-Received: by 10.25.217.205 with SMTP id s74mr407011lfi.8.1484586797338; Mon, 16 Jan 2017 09:13:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.134.67 with HTTP; Mon, 16 Jan 2017 09:13:16 -0800 (PST) In-Reply-To: <148458659558.22600.16273739396983946817.idtracker@ietfa.amsl.com> References: <148458659558.22600.16273739396983946817.idtracker@ietfa.amsl.com> From: Behcet Sarikaya Date: Mon, 16 Jan 2017 11:13:16 -0600 Message-ID: To: "sfc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [sfc] Fwd: New Version Notification for draft-sarikaya-sfc-hostid-serviceheader-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 17:13:21 -0000 Hi all, We submitted our revised solution draft entitled: Service Function Chaining Service, Subscriber and Host Identification Use Cases and Metadata I could be useful in the upcoming interim meeting this week. Behcet A new version of I-D, draft-sarikaya-sfc-hostid-serviceheader-04.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-sarikaya-sfc-hostid-serviceheader Revision: 04 Title: Service Function Chaining Service, Subscriber and Host Identification Use Cases and Metadata Document date: 2017-01-16 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-sarikaya-sfc-hostid-serviceheader-04.txt Status: https://datatracker.ietf.org/doc/draft-sarikaya-sfc-hostid-serviceheader/ Htmlized: https://tools.ietf.org/html/draft-sarikaya-sfc-hostid-serviceheader-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-sarikaya-sfc-hostid-serviceheader-04 Abstract: This document discusses considerations related to passing service-, host- and subscriber-related information to upstream Service Functions for the sake of policy enforcement and appropriate SFC- inferred forwarding. Once the information is consumed by SFC-aware elements of an SFC-enabled domain, the information is stripped from packets so that privacy-sensitive information is not leaked outside an SFC-enabled domain. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Jan 17 08:04:34 2017 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 7EF8912954C for ; Tue, 17 Jan 2017 08:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hozjB06BypZo for ; Tue, 17 Jan 2017 08:04:31 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 157AC12955B for ; Tue, 17 Jan 2017 08:04:30 -0800 (PST) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 734075EBF0E5 for ; Tue, 17 Jan 2017 16:04:26 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id v0HG4SPs008727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Jan 2017 16:04:29 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id v0HG4SWJ006800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Jan 2017 16:04:28 GMT Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.40]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Tue, 17 Jan 2017 11:04:27 -0500 From: "Muley, Praveen (Nokia - US)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-napper-sfc-nsh-broadband-allocation-02.txt Thread-Index: AQHScLI/T2jtujj2ZES3LHlabDxreaE81Rag Date: Tue, 17 Jan 2017 16:04:27 +0000 Message-ID: <22069265D1B36949926E9422EBF3B881776EDA64@US70TWXCHMBA10.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [sfc] FW: New Version Notification for draft-napper-sfc-nsh-broadband-allocation-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:04:33 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwg SmFudWFyeSAxNywgMjAxNyAzOjEwIEFNDQpUbzogTXVsZXksIFByYXZlZW4gKE5va2lhIC0gVVMp OyBIZW5kZXJpY2t4LCBXaW0gKE5va2lhIC0gQkUpOyBTdXJlbmRyYSBLdW1hcjsgTW9oYW1lZCBC b3VjYWRhaXI7IEplZmZyZXkgTmFwcGVyOyBIZW5kZXJpY2t4LCBXaW0gKE5va2lhIC0gQkUpOyBT dXJlbmRyYQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1uYXBw ZXItc2ZjLW5zaC1icm9hZGJhbmQtYWxsb2NhdGlvbi0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtbmFwcGVyLXNmYy1uc2gtYnJvYWRiYW5kLWFsbG9jYXRpb24tMDIudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEplZmZyZXkgTmFwcGVyIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LW5hcHBlci1zZmMt bnNoLWJyb2FkYmFuZC1hbGxvY2F0aW9uDQpSZXZpc2lvbjoJMDINClRpdGxlOgkJTlNIIENvbnRl eHQgSGVhZGVyIEFsbG9jYXRpb24gLS0gQnJvYWRiYW5kDQpEb2N1bWVudCBkYXRlOgkyMDE3LTAx LTE2DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk5DQpVUkw6ICAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5hcHBlci1z ZmMtbnNoLWJyb2FkYmFuZC1hbGxvY2F0aW9uLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW5hcHBlci1zZmMtbnNoLWJyb2FkYmFu ZC1hbGxvY2F0aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1uYXBwZXItc2ZjLW5zaC1icm9hZGJhbmQtYWxsb2NhdGlvbi0wMg0KRGlmZjogICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1uYXBwZXItc2Zj LW5zaC1icm9hZGJhbmQtYWxsb2NhdGlvbi0wMg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1l bnQgcHJvdmlkZXMgYSByZWNvbW1lbmRlZCBhbGxvY2F0aW9uIG9mIGNvbnRleHQgaGVhZGVycw0K ICAgZm9yIGEgTmV0d29yayBTZXJ2aWNlIEhlYWRlciAoTlNIKSB3aXRoaW4gdGhlIGJyb2FkYmFu ZCBzZXJ2aWNlDQogICBwcm92aWRlciBuZXR3b3JrIGNvbnRleHQuICBOU0ggaXMgZGVzY3JpYmVk IGluIGRldGFpbCBpbg0KICAgW2lldGYtc2ZjLW5zaF0uICBUaGlzIGFsbG9jYXRpb24gaXMgaW50 ZW5kZWQgdG8gc3VwcG9ydCB1c2VzIGNhc2VzIGFzDQogICBkZWZpbmVkIGluIFtpZXRmLXNmYy11 c2UtY2FzZS1tb2JpbGl0eV0uDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Jan 17 11:57:34 2017 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 7696D127077 for ; Tue, 17 Jan 2017 11:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-ejjX3XPzjA for ; Tue, 17 Jan 2017 11:57:30 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 7A4EB127A91 for ; Tue, 17 Jan 2017 11:57:30 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id j82so29663077ybg.1 for ; Tue, 17 Jan 2017 11:57:30 -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; bh=RKx+c/hkM4SNHsB8sbT/A0gQRB+5SGIi1R08XQxgCYU=; b=tyljXIiwOiA4jOotk2udRZ1W04JFCrxVevU9VdwG/ral5vnD27ko2NXuic9C1zK3uh hfcdPUD/YtfWvE5PlRjme/zviJSdF27Q7oveHtevFRvpbourJGuCiUgVzWjz50pQrJhF 9vYeUUkXWAXnh3PEMY5mR70EXWnT4Nrjw7z8iZAU7Yp/KjbnNbfkCIGHqQR+WJvdGLw/ 4G9ycshoJuz4L//p4qz5FrLR3y9hK5xVX2M1zHpLIX8WmU53ojemo4hvJg49otlh0BCk iVhbh3+qs8rcZbGVVEr7AHuyHJofksN1UPk+qf+WX4uEPrikak3heO28nVZnxUs74yyz kd/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RKx+c/hkM4SNHsB8sbT/A0gQRB+5SGIi1R08XQxgCYU=; b=X/q/WIQIjrSRoHjWzi79BjS/nJ0IlDy90svbSTQlO3fIeAsNM8dQNAEW6fBMc1taEq tzELniUzKzrezqOBtdsg+NKbBLtaM3xGtgCgAWm7TTmCd5sa2UG2mcKTNSmBB3rTJpKW ntzk4hWq0WWXuWHp9gcCzb2H1A3n5ZSdf/wJcSSObO94+5jUA7L+FNHm7IgO2Q+7p4ST 1N5Cz5qY0QS2z9sjGZeq7b7qpmSuGTkQBI4t1HT4gl0m65dh3OuZqzuFo2Gb6XDyDK8R EZ8JdHmMA8tQor20c5NNoONF6gNypxt7qOcb996MQFN8KR7AySieyv5pz3Qo4NnDoDZO 1nFQ== X-Gm-Message-State: AIkVDXKhJVRLaQkVRRAAK6itCbv0CasysQbnWbEEOdVqwRiSuwCTNiU9J/KpNuhYORbt1SvPiItw9CqLCaIPWQ== X-Received: by 10.37.219.193 with SMTP id g184mr26853285ybf.19.1484683049453; Tue, 17 Jan 2017 11:57:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.50.2 with HTTP; Tue, 17 Jan 2017 11:57:29 -0800 (PST) From: Alia Atlas Date: Tue, 17 Jan 2017 14:57:29 -0500 Message-ID: To: "sfc@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c186b46c44c9605464fb50b Archived-At: Subject: [sfc] IETF-Hub-Boston meeting Thursday X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 19:57:32 -0000 --94eb2c186b46c44c9605464fb50b Content-Type: text/plain; charset=UTF-8 Since we are having the SFC close by, for those who are in the Boston area and interested.... Regards, Alia ---------- Forwarded message ---------- From: Salz, Rich Date: Tue, Jan 17, 2017 at 2:53 PM Subject: [Ietf-hub-boston] But wait, there's more: IETF-Hub-Boston meeting Thursday To: "ietf-hub-boston@ietf.org" Hosted by 128 Technology in Burlington, on Thursday Jan 19. Our local host (official door unlocker if you will) is David Bond. We start at 3pm. Then dinner as the group decides/wants. Please RSVP here: http://doodle.com/poll/udeiyppcz2rbmy8m Please forward this to anyone and everyone who might be interested. Agenda: Banana means bandwidth aggregation. Margaret Cullen Happy Earballs -- Coping with Dual-Stack Connectivity Issues in SIP . Dale Worley The Mathematical Mesh is an infrastructure that makes computers easier to use by making them more secure. Phill-Hallam Baker ADDED: Using YANG for services and devices -- what's the difference between those? Dean Bogdanoic ADDED: Possible intro to SFC by Ignas Bagdonas who came overseas and battled 128 to be here. Future plans for this group? Any thoughts or ideas? _______________________________________________ Ietf-hub-boston mailing list Ietf-hub-boston@ietf.org https://www.ietf.org/mailman/listinfo/ietf-hub-boston --94eb2c186b46c44c9605464fb50b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since we are having the SFC close by, for those who a= re in the Boston area and interested....

Regards,<= /div>
Alia


---------= - Forwarded message ----------
From: Salz,= Rich <rsalz@a= kamai.com>
Date: Tue, Jan 17, 2017 at 2:53 PM
Subject: = [Ietf-hub-boston] But wait, there's more: IETF-Hub-Boston meeting Thur= sday
To: "ietf-hub-bost= on@ietf.org" <ietf-= hub-boston@ietf.org>


Hosted by 128 Technology in Burlingt= on, on Thursday Jan 19.=C2=A0 Our local host (official door unlocker if you= will) is David Bond.=C2=A0 We start at 3pm.=C2=A0 Then
dinner as the group decides/wants.

Please RSVP here: http://doodle.com/poll/udeiyppcz2rbm= y8m Please forward this to anyone and everyone who might be interested.=

Agenda:
=C2=A0 =C2=A0 =C2=A0 =C2=A0Banana means bandwidth aggregation.=C2=A0 Margar= et Cullen
=C2=A0 =C2=A0 =C2=A0 =C2=A0Happy Earballs -- Coping with Dual-Stack Connect= ivity Issues in SIP=C2=A0 . =C2=A0 Dale Worley
=C2=A0 =C2=A0 =C2=A0 =C2=A0The Mathematical Mesh is an infrastructure that = makes computers easier to use by making them more secure. Phill-Hallam Bake= r
=C2=A0 =C2=A0 =C2=A0 =C2=A0ADDED: Using YANG for services and devices -- wh= at's the difference between those?=C2=A0 Dean Bogdanoic
=C2=A0 =C2=A0 =C2=A0 =C2=A0ADDED: Possible intro to SFC by Ignas Bagdonas w= ho came overseas and battled 128 to be here.
=C2=A0 =C2=A0 =C2=A0 =C2=A0Future plans for this group?=C2=A0 Any thoughts = or ideas?

_______________________________________________
Ietf-hub-boston mailing list
Ietf-hub-boston@ietf.org https://www.ietf.org/mailman/listinfo/ietf= -hub-boston

--94eb2c186b46c44c9605464fb50b-- From nobody Wed Jan 18 06:59:02 2017 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 D3D4F129446 for ; Wed, 18 Jan 2017 06:59:00 -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 GHEc5AXfKge4 for ; Wed, 18 Jan 2017 06:58:59 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73AF1293E1 for ; Wed, 18 Jan 2017 06:58:58 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0IEwrd9013395; Wed, 18 Jan 2017 14:58:53 GMT Received: from 950129200 (westford-nat.juniper.net [66.129.232.2]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0IEwpol013388 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 18 Jan 2017 14:58:52 GMT From: "Adrian Farrel" To: Date: Wed, 18 Jan 2017 14:58:54 -0000 Message-ID: <044501d2719b$641dcd70$2c596850$@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: AdJxm2Bs/vsR+Q+ZSJ6H5rsZ51uS1A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22832.000 X-TM-AS-Result: No--4.442-10.0-31-10 X-imss-scan-details: No--4.442-10.0-31-10 X-TMASE-MatchedRID: yHe4KNz2unvYfPOPCpnfAgRH1Nr7oERdQxhbwXgdp1zFJnEpmt9OE+2l xlW3AjAI20QWNDV+woFT2j9KDY4iRftAPEfr8cPby7TSWcbz49ZmA3DvT8Mo5rKeTtOdjMy6mec 3xnR/JN8f2n5P2FPAsaoPZ/AwM3eVkfRhdidsajM5f9Xw/xqKXdivpTdmVCR2xEHRux+uk8hxKp vEGAbTDlQQiw31TNf+i0B1fXRwLIHx9seDiyIgCgzDNfLz9ZpmqyiMLQeND2xx6U27dCsavSF10 FE7Otusv+46NV9XU6Lpi3z76M6TdMQqHltHU9gWh/yQr4rUA+khyumgjE26dT+WrqjKZ1gr Archived-At: Cc: Paul Quinn Subject: [sfc] Clarifying which bits of the NSH are mandatory X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 14:59:01 -0000 Hi, In discussions at the interim there was some (potential) confusion about which of the headers in the NSH are mandatory. The chairs made a call for a proposal of new text to make this clarification. Can I propose... OLD 3.1. Network Service Header Format An NSH is composed of a 4-byte (all references to bytes in this draft refer to 8-bit bytes, or octets) Base Header, a 4-byte Service Path Header and Context Headers, as shown in Figure 1 below. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Base Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Context Headers ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Network Service Header Base header: provides information about the service header and the payload protocol. Service Path Header: provide path identification and location within a service path. Context headers: carry metadata (i.e. context data) along a service path. NEW 3.1. Network Service Header Format An NSH is composed of a 4-byte (all references to bytes in this draft refer to 8-bit bytes, or octets) Base Header, a 4-byte Service Path Header and Context Headers, as shown in Figure 1 below. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Base Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Context Headers ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Network Service Header Base Header: Provides information about the service header and the payload protocol. The Base Header is mandatory in the NSH. Service Path Header: Provides path identification and location within a service path. The Service Path Header is mandatory in the NSH. Context Headers: Carry metadata (i.e. context data) along a service path. Context Headers are optional in the NSH dependent on the setting of the MD Type field of the Base Header (see Section 3.2). END From nobody Wed Jan 18 07:14:41 2017 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 EBDF9129431 for ; Wed, 18 Jan 2017 07:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.953 X-Spam-Level: X-Spam-Status: No, score=-6.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4DKXhw6LbLo for ; Wed, 18 Jan 2017 07:14:39 -0800 (PST) Received: from relais-inet.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 77C0F1293E1 for ; Wed, 18 Jan 2017 07:14:39 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id C087140088; Wed, 18 Jan 2017 16:14:37 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 8635B1C0BA4; Wed, 18 Jan 2017 16:14:37 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0319.002; Wed, 18 Jan 2017 16:14:37 +0100 From: To: "sfc@ietf.org" Thread-Topic: NSH document: IETF Assigned MD TLV Type Registry Thread-Index: AdJxnZKRA1DNntywTUmov8pasElhGw== Date: Wed, 18 Jan 2017 15:14:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DE64F1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DE64F1OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Cc: "adrian@olddog.co.uk" Subject: [sfc] NSH document: IETF Assigned MD TLV Type Registry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 15:14:41 -0000 --_000_787AE7BB302AE849A7480A190F8B933009DE64F1OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As agreed yesterday, please find below a text proposal for the provision of= the IETF type registry. This NEW text is proposed to be added to the IANA = section of the NSH document: =3D=3D=3D=3D=3D x.x.x. IETF Assigned MD TLV Type Registry This document requests IANA to create a registry for the type values owned by the IETF (i.e., MD Class set to 0) called the "IETF Assigned MD TLV Type Registry." The type values are assigned via Standards Action [RFC5226]. No initial values are assigned at the creation of the registry. =3D=3D=3D=3D=3D Cheers, Adrian & Med --_000_787AE7BB302AE849A7480A190F8B933009DE64F1OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As agreed yesterday, please find below a te= xt proposal for the provision of the IETF type registry. This NEW text is p= roposed to be added to the IANA section of the NSH document:

 

=3D=3D=3D=3D=3D

x.x.x.  IETF Assigned M= D TLV Type Registry

 

   This document r= equests IANA to create a registry for the type values

   owned by the IE= TF (i.e., MD Class set to 0) called the "IETF Assigned

   MD TLV Type Reg= istry."

   The type v= alues are assigned via Standards Action [RFC5226].

 

   No initial valu= es are assigned at the creation of the registry.

=3D=3D=3D=3D=3D

 

Cheers,

Adrian & Med

 

--_000_787AE7BB302AE849A7480A190F8B933009DE64F1OPEXCLILMA3corp_-- From nobody Wed Jan 18 12:55:13 2017 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 E7A3F12947E for ; Wed, 18 Jan 2017 12:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199] 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 0wqEzsjovrTS for ; Wed, 18 Jan 2017 12:55:11 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D5F1293EC for ; Wed, 18 Jan 2017 12:55:11 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Wed, 18 Jan 2017 15:55:09 -0500 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: Removing C (critical) flag from draft-ietf-sfc-nsh Thread-Index: AdJxquEDIf8nEJMySiyHPorGzej0cw== Date: Wed, 18 Jan 2017 20:55:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98704D1CF4wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Cc: "Elzur, Uri" , "Paul Quinn \(paulq\)" Subject: [sfc] Removing C (critical) flag from draft-ietf-sfc-nsh X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 20:55:13 -0000 --_000_E8355113905631478EFF04F5AA706E98704D1CF4wtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the SFC interim meeting today, there seems to be support for: - removing the "C" flag from the NSH base header, returning the bit to "res= erved" status (section 3.2) - removing the "C" flag from the variable-length metadata header, making th= e Type an 8-bit field. (section 3.5.1) - and removing all of the wording about "critical metadata" The rationale: it seems that it would only be valid to set the C-flag if ev= ery single SFC component understands the critical metadata being used (othe= rwise packet will be dropped). However, if every component understands the = critical metadata there is no need for the C-flag. So it seems the C-flag m= erely serves to complicate the protocol. This question came up while trying to understand how to handle unknown MD-T= ypes when the C-flag is set. I was asked to send this question to the mailing list to see if there are o= bjections to removing the C-flag. -Dave --_000_E8355113905631478EFF04F5AA706E98704D1CF4wtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the SFC interim meeting today, there seems to be = support for:

- removing the “C” flag from the NSH bas= e header, returning the bit to “reserved” status (section 3.2)<= o:p>

- removing the “C” flag from the variabl= e-length metadata header, making the Type an 8-bit field. (section 3.5.1)

- and removing all of the wording about “criti= cal metadata”

 

The rationale: it seems that it would only be valid = to set the C-flag if every single SFC component understands the critical me= tadata being used (otherwise packet will be dropped). However, if every com= ponent understands the critical metadata there is no need for the C-flag. So it seems the C-flag merely serves to c= omplicate the protocol.

This question came up while trying to understand how= to handle unknown MD-Types when the C-flag is set.

 

I was asked to send this question to the mailing lis= t to see if there are objections to removing the C-flag.

 

-Dave

 

 

--_000_E8355113905631478EFF04F5AA706E98704D1CF4wtlexchp1sandvi_-- From nobody Wed Jan 18 13:12:54 2017 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 B9243129485 for ; Wed, 18 Jan 2017 13:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 i7J-LEvGQOjm for ; Wed, 18 Jan 2017 13:12:50 -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 34A0B127077 for ; Wed, 18 Jan 2017 13:12:50 -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 v0ILCjfi006751; Wed, 18 Jan 2017 21:12:45 GMT Received: from 950129200 (westford-nat.juniper.net [66.129.232.2]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0ILChIT006717 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 18 Jan 2017 21:12:44 GMT From: "Adrian Farrel" To: "'Dave Dolson'" , References: In-Reply-To: Date: Wed, 18 Jan 2017 21:12:45 -0000 Message-ID: <051001d271cf$9e18f390$da4adab0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0511_01D271CF.9E368DB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIPYfppmFP02gaC1N/qnU+ZI2HfCKDE2lYA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22832.002 X-TM-AS-Result: No--17.595-10.0-31-10 X-imss-scan-details: No--17.595-10.0-31-10 X-TMASE-MatchedRID: I31hiQfYWUOnykMun0J1wkhEDfw/93BulxKxrgKsgffKP6Yywb5aNhzl lv0af4rKgysnZtDulN4WqdQVHbRl3TqSEziRtwmlma6DzXaohvNlkwUvxRC7B7i7yMDZhOacdO/ tkDTEgyTuBFA2gYmurI1tYtwPvjHZNeyeXkXe6VniHyvyXeXh5kxsnegIsUXkskPO7S0r/WJhXh AzuI3NbsoT06tb0XG+TDTwHP13kXImC1NuoSXJFMLPXKYZysJRcf2CPmeUCZK15CaN3SGNHKDSF bNSvOcnAuwgUdYPZkUrOi92xWTzwVOpO+Sviejw/Sl5cYQQGW+uiAW0p38/t7rfxlRjqBJ3gC46 pyJTSnTV4yn6Kf1r098KgvULLt4X/fqypUX9VmhLc5N+0s1+DZT1elWqouGw8cWgFw6wp7OI+yd 48zjY3SWuqxiUeEX6MLog80/xRYlR4vrwuhcS/AVOLlPuctdqLdLfmiFS7fuSs1st/hpgblzOKV R59i8DP5mpBtPr/e7et/aEQRVJHkNKRRr2LbXrWCjDJRYeAZ0BL/XzNFFmHxS11FlOYRohXalr5 okxvJqf189awv9YNLRd0WwZSVdNNJyAyqAmcb/kcOvbQGFzRpdhffisWXfHJ6NLJndRi2QAx/km RQa0aiSDxZqgw5bKklPOPDP4bOhIvMFDGS9L74vptQwz5tsiwSJcbRHuoMcR34ro7k23nfPRCvs YnLTLXi2Kvy2p4MRucz/xUkOEzfEnzi0PuMx/ngIgpj8eDcBpkajQR5gb3r6qvLNjDYTwzz3jeh zenexPje6HuTNSqSEknnkdXO8Nap48dnpjS9I4C6rCHm3b4H3KIHdCuki3jEx0mLT+iF8= Archived-At: Cc: "'Elzur, Uri'" , "'Paul Quinn \(paulq\)'" Subject: Re: [sfc] Removing C (critical) flag from draft-ietf-sfc-nsh X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 21:12:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0511_01D271CF.9E368DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Dave, That captures what I heard and agrees with what I think. I would note that there is the possibility of a TLV that an implementation understands but can choose to ignore or process, and the C flag would override this choice forcing it to process. However, I do not have a use case for this and I don't think we should specify a speculative protocol feature. Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen MORE new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson Sent: 18 January 2017 20:55 To: sfc@ietf.org Cc: Elzur, Uri; Paul Quinn (paulq) Subject: [sfc] Removing C (critical) flag from draft-ietf-sfc-nsh At the SFC interim meeting today, there seems to be support for: - removing the "C" flag from the NSH base header, returning the bit to "reserved" status (section 3.2) - removing the "C" flag from the variable-length metadata header, making the Type an 8-bit field. (section 3.5.1) - and removing all of the wording about "critical metadata" The rationale: it seems that it would only be valid to set the C-flag if every single SFC component understands the critical metadata being used (otherwise packet will be dropped). However, if every component understands the critical metadata there is no need for the C-flag. So it seems the C-flag merely serves to complicate the protocol. This question came up while trying to understand how to handle unknown MD-Types when the C-flag is set. I was asked to send this question to the mailing list to see if there are objections to removing the C-flag. -Dave ------=_NextPart_000_0511_01D271CF.9E368DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks = Dave,

 

That captures what I = heard and agrees with what I think.

 

I would note that = there is the possibility of a TLV that an implementation understands but = can choose to ignore or process, and the C flag would override this = choice forcing it to process. However, I do not have a use case for this = and I don't think we should specify a speculative protocol = feature.

 

Adrian

--

Support an author and your = imagination.

Tales from the Wood - Eighteen = new fairy tales.

More Tales from the Wood - = Eighteen MORE new fairy tales.

https://www.feedaread.com/profiles= /8604/

http://www.amazon.co.uk/Tales-Wood= -Adrian-Farrel/dp/1786100924

Or buy from me = direct.

 

 

 

From: sfc = [mailto:sfc-bounces@ietf.org] On Behalf Of Dave = Dolson
Sent: 18 January 2017 20:55
To: = sfc@ietf.org
Cc: Elzur, Uri; Paul Quinn = (paulq)
Subject: [sfc] Removing C (critical) flag from = draft-ietf-sfc-nsh

 

At the SFC interim = meeting today, there seems to be support for:

- = removing the “C” flag from the NSH base header, returning = the bit to “reserved” status (section = 3.2)

- removing the “C” flag = from the variable-length metadata header, making the Type an 8-bit = field. (section 3.5.1)

- and removing all of the = wording about “critical metadata”

 

The rationale: it seems that it would = only be valid to set the C-flag if every single SFC component = understands the critical metadata being used (otherwise packet will be = dropped). However, if every component understands the critical metadata = there is no need for the C-flag. So it seems the C-flag merely serves to = complicate the protocol.

This question came up = while trying to understand how to handle unknown MD-Types when the = C-flag is set.

 

I = was asked to send this question to the mailing list to see if there are = objections to removing the C-flag.

 

-Dave

 

 

------=_NextPart_000_0511_01D271CF.9E368DB0-- From nobody Wed Jan 18 13:48:09 2017 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 449A51294F3 for ; Wed, 18 Jan 2017 13:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199] 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 ezR8bOnalkpK for ; Wed, 18 Jan 2017 13:48:06 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7008129437 for ; Wed, 18 Jan 2017 13:48:05 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Wed, 18 Jan 2017 16:48:04 -0500 From: Dave Dolson To: "Joel M. Halpern" , James N Guichard , "sfc@ietf.org" Thread-Topic: Requesting last call for draft-ietf-sfc-hierarchical Thread-Index: AdJx1Bq7XEwcZ1khTaiz2dZKvG7NiA== Date: Wed, 18 Jan 2017 21:48:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98704D2089wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Requesting last call for draft-ietf-sfc-hierarchical X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 21:48:07 -0000 --_000_E8355113905631478EFF04F5AA706E98704D2089wtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello SFC and chairs, The authors would like to request last call for the hierarchical SFC docume= nt: There is a new version, and we think it is in good shape: https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-02 -Dave --_000_E8355113905631478EFF04F5AA706E98704D2089wtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello SFC and chairs,

 

The authors would like to request last call for the = hierarchical SFC document:

There is a new version, and we think it is in good s= hape:

 

https://tools.ietf.org/html/draft-ietf-sfc-hierarchical-= 02

 

 

-Dave

 

--_000_E8355113905631478EFF04F5AA706E98704D2089wtlexchp1sandvi_-- From nobody Thu Jan 19 08:11:34 2017 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 333641296E0 for ; Thu, 19 Jan 2017 08:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, 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 PebpltAdPqdI for ; Thu, 19 Jan 2017 08:11:30 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 44B5A12946D for ; Thu, 19 Jan 2017 08:11:30 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id k86so40044782lfi.0 for ; Thu, 19 Jan 2017 08:11:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lZzGQ1ijDqmqF1V7z6oRSOxptXzK7XuJvButQMjJZ98=; b=kx4xvXGYaNdLC29vbq8e1M3LTjcnZuefW7knS/ZEh2lHZS6hEM+m5ablaIK2Rb9WXM mv6e/LMt0kvIusl9YWEQKtzHnzHTzbdf0G2ANlpdjkycDZYDeyF+Jn0q8UYZ6uvt0yJr y07lgDynLygYDarKTw6mQ02uOPo/VWT/7f9C1UzV1/8+Coh0A1r8296AKsOKsqRx+sl2 ckPjtS2HjM77s/PLObQeGEkKDiZue1aJqWpkYMSpfCTB+h8Njl0O8f+9P3az5uO5nUvo pvGZaJZHUHsGzvz76X6QenCrnjrD33g+cXX32VBM5T1MLsLP5mysV5837RzOZRq+CKQX bzMA== 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:in-reply-to:references :from:date:message-id:subject:to:cc; bh=lZzGQ1ijDqmqF1V7z6oRSOxptXzK7XuJvButQMjJZ98=; b=DNz03S+D++EpzZv81UuQQqxhnajNy8PfVn0HReJBuDN8o9r3OEvhw0ccyrvQwmXXG2 o8ILD038vb5MjzRWKdlWD+mGYLss2jIdeAekYXKoeBzvbxXvHwaFhNT51VblWKDiHHBK j7d18X0qciUsmmnl5HhqD5IJHvhrXAh5D/i5oHzELH6p2cjjxXNDO83U/v81CzjLLs+n FrT92AtLbFxheKSsDiJS4CEBVIgOZemK9VIN4XkKi/bRSEjLkHpr1w7ZTAA62wTVdzTu hyslb2wkPU3a0VnsJkHuX5u0Bv/HSeuECQVH3KahZyUmLtaJePiUrXL7GXa4MxI1jw4p RJHw== X-Gm-Message-State: AIkVDXJECzsi7/WHHf+b/L3xMzqmSC7AkkH3m7F0zGhU2JISXI0Ls/S0Kwvb+A11RITwBbfvH2cSuHNGYH/w8Q== X-Received: by 10.25.149.131 with SMTP id x125mr3509784lfd.100.1484842288338; Thu, 19 Jan 2017 08:11:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.134.67 with HTTP; Thu, 19 Jan 2017 08:11:27 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DE64F1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933009DE64F1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Behcet Sarikaya Date: Thu, 19 Jan 2017 10:11:27 -0600 Message-ID: To: Mohamed Boucadair Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "adrian@olddog.co.uk" , "sfc@ietf.org" Subject: Re: [sfc] NSH document: IETF Assigned MD TLV Type Registry X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 16:11:33 -0000 On Wed, Jan 18, 2017 at 9:14 AM, wrote: > Hi all, > > > > As agreed yesterday, please find below a text proposal for the provision of > the IETF type registry. This NEW text is proposed to be added to the IANA > section of the NSH document: > > > > ===== > > x.x.x. IETF Assigned MD TLV Type Registry > > > > This document requests IANA to create a registry for the type values > > owned by the IETF (i.e., MD Class set to 0) called the "IETF Assigned > > MD TLV Type Registry." > > The type values are assigned via Standards Action [RFC5226]. > > > > No initial values are assigned at the creation of the registry. I strongly support this NEW text. Thank you for proposing it. Regards, Behcet > > ===== > > > > Cheers, > > Adrian & Med > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Jan 19 13:05:06 2017 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 B703712957E; Thu, 19 Jan 2017 13:05:04 -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 akuS9vzb-3GT; Thu, 19 Jan 2017 13:05:03 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED15129610; Thu, 19 Jan 2017 13:05:02 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0JL50xJ007087; Thu, 19 Jan 2017 21:05:00 GMT Received: from 950129200 (THE-HIMMER.car1.Boston1.Level3.net [4.30.124.170]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0JL4wqF007070 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2017 21:04:59 GMT From: "Adrian Farrel" To: Date: Thu, 19 Jan 2017 21:05:01 -0000 Message-ID: <071801d27297$b3a48ee0$1aedaca0$@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: AdJyl6vwRIf3N8rsQ6ea9YZzKTI/dA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22834.002 X-TM-AS-Result: No--4.303-10.0-31-10 X-imss-scan-details: No--4.303-10.0-31-10 X-TMASE-MatchedRID: KRwWxLt/A1TMHUInqqZ02h3EEAbn+GRb6Jj6zYvfFAQz6JWqTMKdCGhd vY2T9l+XqKpParhRmXvhzIywjNrSx+Xjm1is2vYtQ1OcCEvT+bdAq6/y5AEOOnRNGrhtzGYfTak PH+NO07EYQOIvxOoGr9REd1RnDg47kCRuY1IDswOd4hCa7xSZoVXKDhjPZTukJ870fpj93L4Dkd 7WQNL44uLzNWBegCW2XC3N7C7YzrfkwjHXXC/4I8ZW5ai5WKlyyLv2Lb/fLKn/JicJWE4BnPsWN w0RnTCAUPAZZ7dQ4TT139N5YwYuqnCY5a/t/kusyqA6FhblhJhxPEHjJeekReojnPNROujVsJ/j xlXnd3dp9xHuM9AfUiKeUbONtgeTe1ZwdZI0d1846NqqjKQhnA== Archived-At: Cc: sfc@ietf.org Subject: [sfc] Re-reading draft-ietf-sfc-use-case-mobility X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 21:05:05 -0000 Hi, I've just been re-reading draft-ietf-sfc-use-case-mobility and am trying to draw some conclusions about metadata. I appreciate the work done to classify the metadata. This is helpful, but :-) Looking at the cases for "synchronous injection" of metadata I'd like help understanding whether this is: - per SFC - per SPI - per flow - per packet I understand there is potential for overlap given the nested hierarchy implied. I also understand that metadata may change periodically, and the change might make it look like "per packet" when it is really "changing per flow". But some clues would be really helpful. Oh, one other thing. The end of 6.3 says "or carried with http header enrichments within the user payload". If that option is chosen and melds with the asynchronous option of "from the control plane environment by means of individual standardized interfaces" does that mean that this use-case does not have a requirement for NSH metadata. Just asking! Thanks, Adrian From nobody Sun Jan 22 08:23:31 2017 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 5B499129557 for ; Sun, 22 Jan 2017 08:23:30 -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 yc2B2E4Znqex for ; Sun, 22 Jan 2017 08:23:28 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E8C1295A7 for ; Sun, 22 Jan 2017 08:23:27 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0MGNOsB021477 for ; Sun, 22 Jan 2017 16:23:24 GMT Received: from 950129200 ([176.241.251.3]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0MGNLgE021471 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 22 Jan 2017 16:23:23 GMT From: "Adrian Farrel" To: Date: Sun, 22 Jan 2017 16:23:25 -0000 Message-ID: <0a3401d274cb$dd074530$9715cf90$@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: AdJ0y9oHPeGeaA1wS2aDJxaMmxW3fA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22840.001 X-TM-AS-Result: No--14.266-10.0-31-10 X-imss-scan-details: No--14.266-10.0-31-10 X-TMASE-MatchedRID: BlqVPuIrVTqjhdS4y9NWlEhEDfw/93Bu6Jj6zYvfFARq4coTktrGXwis jC1R75QwAfaH3Y0gboAIBkpI8DnujbgSigd+50bacFEiuPxHjsUgzzoB6jqxgo5t/XRqktxJwua niM9QXy256cTx4sb1VBQ/hj/JT975Hodpx3o6Gru4jAucHcCqnVF5adRR2Ej12dP9ypSe+feXRA 57JA6vlvY91f9jU+0j/vmo5u6D2ISi7JlxxXhsGvzu9Lw9C7fAUAjrAJWsTe8GW3hFnC9N1V2YN NMOKzvwpbv9gB9QgobtcDpACIVLyEq+i9GrWzgs7/U7JmMpiiFMhH/KpYxyuz62ljLE6goxYyzk aNcuq8aynUhD2tnSEis6L3bFZPPBOnbzVLo65K8c8J6ZrWP/q9r+zN6MFrLIwnJUbJk9y/2jxYy RBa/qJX3mXSdV7KK4WKD2QKkwR8JWdFebWIc3VsRB0bsfrpPIfiAqrjYtFiSOlYVXegKo3ExK4v 96jQhgAkLX5z5IxspHWBBT/l5j1H7cGd19dSFd Archived-At: Subject: [sfc] SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 16:23:30 -0000 Hi, At the interim, Lucy and I took an action to write this draft. It allows you to send metadata on an SFP without having a data packet to attach it to. There was some discussion about whether this idea should find its way into the base NSH draft. I said "no" because of the volume of material, because it is not a fundamental of NSH, and because we don't want to hold up the publication of the NSH spec. That said, if the WG wants to fold it in, I won't object. Please review and comment. We think it is a simple idea and that the document pretty much says it all. Thanks, Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 22 January 2017 16:17 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-farrel-sfc-convent-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Operating the Network Service Header with Next Protocol "None" > Authors : Adrian Farrel > Lucy Yong > John Drake > Filename : draft-farrel-sfc-convent-00.txt > Pages : 8 > Date : 2017-01-22 > > Abstract: > This document describes the use of the Network Service Header (NSH) > in a Service Function Chaining (SFC) overlay network with no payload > data and only carrying metadata. This is achieved by defining a new > "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's also a htmlized version available at: > https://tools.ietf.org/html/draft-farrel-sfc-convent-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sun Jan 22 09:52:44 2017 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 BB38D1297BD for ; Sun, 22 Jan 2017 09:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.434 X-Spam-Level: X-Spam-Status: No, score=-4.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 zlCviup3PPk1 for ; Sun, 22 Jan 2017 09:52:41 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287851297AC for ; Sun, 22 Jan 2017 09:52:41 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Sun, 22 Jan 2017 12:52:38 -0500 From: Dave Dolson To: Adrian Farrel , "sfc@ietf.org" Thread-Topic: [sfc] SFC with next protocol = "None" Thread-Index: AdJ02FFLPeGeaA1wS2aDJxaMmxW3fA== Date: Sun, 22 Jan 2017 17:52:37 +0000 Message-ID: <20170122175237.5697621.9165.132101@sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 17:52:42 -0000 VGhhbmtzIEFkcmlhbiwgTHVjeSAmIEpvaG4NCg0KQWZ0ZXIgcmVhZGluZyBpdCwgYSBxdWVzdGlv biBvY2N1cnMgdG8gbWUgYWJvdXQgdGhlIG5zaCBkcmFmdDoNCi0gZG9lcyBpdCBwcm9wZXJseSBz cGVjaWZ5IGZvcndhcmRpbmcgYmVoYXZpb3Igd2hlbiBOZXh0LVByb3RvY29sIGlzIGFuIHVuc3Vw cG9ydGVkIHZhbHVlPyAoU0ZGIHNob3VsZG4ndCBjYXJlOyBTRiBvciBTRkMgUHJveHkgc2hvdWxk IGRlY3JlbWVudCBTSSBhbmQgcGFzcyB0aHJvdWdoKS4gIk5vbmUiIHNob3VsZCBub3QgYmUgYSBz cGVjaWFsIGNhc2Ugb2YgdW5zdXBwb3J0ZWQuDQoNCkknbSBpbmNsaW5lZCB0byBzYXkgd2Ugc2hv dWxkIGFkZCBOb25lIHRvIHRoZSBOZXh0LUhlYWRlciB2YWx1ZXMgaW4gdGhlIE5TSCBkb2N1bWVu dCwgYW5kIGNsYXJpZnkgZm9yd2FyZGluZyBiZWhhdmlvciB0byBzdXBwb3J0IHRoZSBpZGVhcyBp biB5b3VyIHNlY3Rpb24gNCBvbiBCYWNrd2FyZCBDb21wYXRpYmlsaXR5LsKgDQoNCuKAjlRoZSB1 c2UgY2FzZXMgaW4geW91ciBkcmFmdCB1c2UgY29uY2VwdHMgbm90IGRlZmluZWQgYnkgYW55IGFk b3B0ZWQgZHJhZnQsIHN1Y2ggYXMgc2VtYW50aWNzIG9mIG1ldGFkYXRhIGFuZCB1c2luZyBtZXRh ZGF0YSBmb3IgT0FNLiAoV2UgbmVlZCB0byB3b3JrIG9uIHRoZXNlISkgSSB0aGluayBtYW55IG9m IHN1Z2dlc3Rpb25zIGFwcGx5IGZvciBhbGwgTmV4dC1Qcm90b2NvbCB0eXBlcy4NCg0KLURhdmUN Cg0KDQoNCg0KwqAgT3JpZ2luYWwgTWVzc2FnZSDCoA0KRnJvbTogQWRyaWFuIEZhcnJlbA0KU2Vu dDogU3VuZGF5LCBKYW51YXJ5IDIyLCAyMDE3IDExOjIzIEFNDQpUbzogc2ZjQGlldGYub3JnDQpS ZXBseSBUbzogYWRyaWFuQG9sZGRvZy5jby51aw0KU3ViamVjdDogW3NmY10gU0ZDIHdpdGggbmV4 dCBwcm90b2NvbCA9ICJOb25lIg0KDQpIaSwNCg0KQXQgdGhlIGludGVyaW0sIEx1Y3kgYW5kIEkg dG9vayBhbiBhY3Rpb24gdG8gd3JpdGUgdGhpcyBkcmFmdC4gSXQgYWxsb3dzIHlvdSB0bw0Kc2Vu ZCBtZXRhZGF0YSBvbiBhbiBTRlAgd2l0aG91dCBoYXZpbmcgYSBkYXRhIHBhY2tldCB0byBhdHRh Y2ggaXQgdG8uDQoNClRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gYWJvdXQgd2hldGhlciB0aGlz IGlkZWEgc2hvdWxkIGZpbmQgaXRzIHdheSBpbnRvIHRoZQ0KYmFzZSBOU0ggZHJhZnQuIEkgc2Fp ZCAibm8iIGJlY2F1c2Ugb2YgdGhlIHZvbHVtZSBvZiBtYXRlcmlhbCwgYmVjYXVzZSBpdCBpcyBu b3QNCmEgZnVuZGFtZW50YWwgb2YgTlNILCBhbmQgYmVjYXVzZSB3ZSBkb24ndCB3YW50IHRvIGhv bGQgdXAgdGhlIHB1YmxpY2F0aW9uIG9mDQp0aGUgTlNIIHNwZWMuIFRoYXQgc2FpZCwgaWYgdGhl IFdHIHdhbnRzIHRvIGZvbGQgaXQgaW4sIEkgd29uJ3Qgb2JqZWN0Lg0KDQpQbGVhc2UgcmV2aWV3 IGFuZCBjb21tZW50LiBXZSB0aGluayBpdCBpcyBhIHNpbXBsZSBpZGVhIGFuZCB0aGF0IHRoZSBk b2N1bWVudA0KcHJldHR5IG11Y2ggc2F5cyBpdCBhbGwuDQoNClRoYW5rcywNCkFkcmlhbg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEktRC1Bbm5vdW5jZSBbbWFpbHRv OmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnDQo+IFNlbnQ6IDIyIEphbnVhcnkgMjAxNyAxNjoxNw0KPiBUbzogaS1k LWFubm91bmNlQGlldGYub3JnDQo+IFN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWZhcnJlbC1z ZmMtY29udmVudC0wMC50eHQNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCmRpcmVjdG9yaWVzLg0KPiAN Cj4gDQo+IFRpdGxlIDogT3BlcmF0aW5nIHRoZSBOZXR3b3JrIFNlcnZpY2UgSGVhZGVyIHdpdGgg TmV4dA0KUHJvdG9jb2wgIk5vbmUiDQo+IEF1dGhvcnMgOiBBZHJpYW4gRmFycmVsDQo+IEx1Y3kg WW9uZw0KPiBKb2huIERyYWtlDQo+IEZpbGVuYW1lIDogZHJhZnQtZmFycmVsLXNmYy1jb252ZW50 LTAwLnR4dA0KPiBQYWdlcyA6IDgNCj4gRGF0ZSA6IDIwMTctMDEtMjINCj4gDQo+IEFic3RyYWN0 Og0KPiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNlIG9mIHRoZSBOZXR3b3JrIFNlcnZp Y2UgSGVhZGVyIChOU0gpDQo+IGluIGEgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKSBv dmVybGF5IG5ldHdvcmsgd2l0aCBubyBwYXlsb2FkDQo+IGRhdGEgYW5kIG9ubHkgY2Fycnlpbmcg bWV0YWRhdGEuIFRoaXMgaXMgYWNoaWV2ZWQgYnkgZGVmaW5pbmcgYSBuZXcNCj4gIm5leHQgcHJv dG9jb2wiIHR5cGUgdmFsdWUgb2YgIk5vbmUiLg0KPiANCj4gVGhpcyBkb2N1bWVudCBpbGx1c3Ry YXRlcyBzb21lIG9mIHRoZSBmdW5jdGlvbnMgdGhhdCBtYXkgYmUgYWNoaWV2ZWQNCj4gb3IgZW5o YW5jZWQgYnkgdGhpcyBtZWNoYW5pc20sIGJ1dCBpdCBkb2VzIG5vdCBwcm92aWRlIGFuIGV4aGF1 c3RpdmUNCj4gbGlzdCBvZiB1c2UgY2FzZXMsIG5vciBpcyBpdCBpbnRlbmRlZCB0byBiZSBkZWZp bml0aXZlIGFib3V0IHRoZQ0KPiBmdW5jdGlvbnMgaXQgZGVzY3JpYmVzLiBJdCBpcyBleHBlY3Rl ZCB0aGF0IG90aGVyIGRvY3VtZW50cyB3aWxsDQo+IGRlc2NyaWJlIHNwZWNpZmljIHVzZSBjYXNl cyBpbiBtb3JlIGRldGFpbCBhbmQgd2lsbCBkZWZpbmUgdGhlDQo+IHByb3RvY29sIG1lY2hhbmlj cyBmb3IgZWFjaCB1c2UgY2FzZS4NCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWZhcnJlbC1zZmMtY29udmVudC8NCj4gDQo+IFRoZXJlJ3MgYWxzbyBh IGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZmFycmVsLXNmYy1jb252ZW50LTAwDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3Vu Y2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwNCj4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBt YWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCg== From nobody Sun Jan 22 14:41:41 2017 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 EF40512941D for ; Sun, 22 Jan 2017 14:41:39 -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 0UzVgWUVA2PN for ; Sun, 22 Jan 2017 14:41:38 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C232129412 for ; Sun, 22 Jan 2017 14:41:38 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0MMfalG006478; Sun, 22 Jan 2017 22:41:36 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0MMfQPQ006397 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 22 Jan 2017 22:41:31 GMT From: "Adrian Farrel" To: "'Dave Dolson'" References: <20170122175237.5697621.9165.132101@sandvine.com> In-Reply-To: <20170122175237.5697621.9165.132101@sandvine.com> Date: Sun, 22 Jan 2017 22:41:23 -0000 Message-ID: <0a7b01d27500$b0b5a5f0$1220f1d0$@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: AQIjbgGmjMAsF5eQhDckwn1123v4nKCjIL1w Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22840.002 X-TM-AS-Result: No--7.668-10.0-31-10 X-imss-scan-details: No--7.668-10.0-31-10 X-TMASE-MatchedRID: xcONGPdDH5o4HKI/yaqRm8NrWpY804TGLJXjpJzQSNOynk7TnYzMur/f OLqBOG2pNmYCY7jYn8KSZWowoEhCrr3YTtutwsdUlTsGW3DmpUsF15s6prCIu9qCxkzSpW/X//q MzMd3QBfDsNRbLbdXTrnJwzdR9dYUiFF8ZRP3DMwuLk8NfSpYejhaxI2If9RebcPp/oilssiJsH V20BY/2PoBg5QWD34oN+PXpASf9LQzwJ7ADkakn1bWTTCHhOTx/RmmEswf7IfYWrp179pohqiQH 9TiUzfaukFaFkPU4QBGjO51oaKVYbgiX1a2E5aJV6uR7UoeQuQg0L4Xy2OHlQKPvjSCRzuuI6qq 9xPsXYjb1k0f1ojJfccvPxYVoEVKFkrTnESQKQJ+7IhLVmN+ux83WxJo1IH1T7S4ZU4XTxBxkB9 BSmNtksIeheCCmtmcKU+sfQjEHVPlRxm3A2wKuoMbH85DUZXy3QfwsVk0UbtuRXh7bFKB7nRh+p //e4aH2BrAA21WTqNc0BbZ27BwZ2ZOi61iPmwAPpCuffGH9zI= Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 22:41:40 -0000 Hey Dave, > After reading it, a question occurs to me about the nsh draft: > - does it properly specify forwarding behavior when Next-Protocol is = an > unsupported value? (SFF shouldn't care; SF or SFC Proxy should = decrement SI and > pass through). Consider an SF needs to perform function on the packet. Hmm, that would = be most SFs :-) The Next Protocol is pretty fundamental to parsing the packet and = working on it. Now you *could* define an SF that passes "unknown" packets = transparently.=20 It's a policy issue at your SF, but I hope the firewalls I use don't = have that policy. So: - Yes we should define the behavior on *all* unknown and unsupported = values of all fields in the NSH. I believe we took an action in Westford to = do that. - For next protocol I think: - SFF should not examine, but should forward - SFC Proxy must not pass to an SF a packet of type that it cannot indicate to the SF - SFC Proxy must not pass to an SF a packet of type that the SF does not support - SFC should not return to the SFF a packet it has not passed to the = SF - SF should not return to the SFF a packet it hasn't processed unless local policy defines "process" to mean "not process" in this case > "None" should not be a special case of unsupported. Hmmm. I think that is dangerous. There is a big difference between an unknown data type and absent data. I *do* agree that for implementations that don't support "None" there = will be no distinction between "None" and "Unsupported" > I'm inclined to say we should add None to the Next-Header values in = the NSH > document, and clarify forwarding behavior to support the ideas in your = section 4 > on Backward Compatibility. Like I said, the authors would be happy to see this go into the base NSH = spec, but we don't think you can simply define the value in the IANA = section without saying what it means. So some additional text would be = needed as well (presumably culled from the draft). And that leads to the question of how quickly the WG would reach = consensus on this and get the draft updated. I keep hearing "We have to get on and publish the NSH spec" and I didn't = want to suggest changes that would only cause further delay. As to your point... =20 > =E2=80=8EThe use cases in your draft use concepts not defined by any = adopted draft, such > as semantics of metadata and using metadata for OAM. (We need to work = on > these!) I think many of suggestions apply for all Next-Protocol types. I'm not sure that the draft describes semantics of metadata. It does = talk about the scope of the metadata (per SFP, per flow, per packet) and = if this is what you mean, then all I can say is that the whole concept = of metadata may be a little under-specified.=20 You could be referring to two places where we make observations about = the content of metadata. The first is where we say that if you want to = support per-flow metadata in an NSH packet with Next Protocol =3D "None" = the metadata will need to indicate which flow the metadata applies to. I = believe this to be self-evident. The second case is where we say that = metadata could contain OAM. You're correct that this has not been stated = anywhere, but it is also "self-evident" from the current definition of = the NSH. Did I miss your point? Cheers, Adrian From nobody Sun Jan 22 19:09:24 2017 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 E5156129AB7 for ; Sun, 22 Jan 2017 19:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.434 X-Spam-Level: X-Spam-Status: No, score=-4.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665] 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 xNJQpvFGt06D for ; Sun, 22 Jan 2017 19:09:21 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A31129A42 for ; Sun, 22 Jan 2017 19:09:21 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 22 Jan 2017 22:09:19 -0500 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Sun, 22 Jan 2017 22:09:18 -0500 From: Dave Dolson To: "adrian@olddog.co.uk" Thread-Topic: [sfc] SFC with next protocol = "None" Thread-Index: AdJ02FFLPeGeaA1wS2aDJxaMmxW3fAAUj/GA///v5AM= Date: Mon, 23 Jan 2017 03:09:18 +0000 Message-ID: References: <20170122175237.5697621.9165.132101@sandvine.com>, <0a7b01d27500$b0b5a5f0$1220f1d0$@olddog.co.uk> In-Reply-To: <0a7b01d27500$b0b5a5f0$1220f1d0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 03:09:23 -0000 Adrian,=0A= =0A= You make some good points. I'm still left with the impression that *some* t= hings you say should make their way into the NSH draft.=0A= Please see inline [DD]=0A= =0A= I should say that I don't feel strongly about anything I've said; rather, I= 'm exploring questions that occurred to me while reading your draft.=0A= =0A= -Dave=0A= =0A= ________________________________________=0A= From: Adrian Farrel [adrian@olddog.co.uk]=0A= Sent: Sunday, January 22, 2017 5:41 PM=0A= To: Dave Dolson=0A= Cc: sfc@ietf.org=0A= Subject: RE: [sfc] SFC with next protocol =3D "None"=0A= =0A= Hey Dave,=0A= =0A= > After reading it, a question occurs to me about the nsh draft:=0A= > - does it properly specify forwarding behavior when Next-Protocol is an= =0A= > unsupported value? (SFF shouldn't care; SF or SFC Proxy should decrement = SI and=0A= > pass through).=0A= =0A= Consider an SF needs to perform function on the packet. Hmm, that would be = most SFs :-)=0A= The Next Protocol is pretty fundamental to parsing the packet and working o= n it.=0A= Now you *could* define an SF that passes "unknown" packets transparently.= =0A= It's a policy issue at your SF, but I hope the firewalls I use don't have t= hat policy.=0A= [DD] Point taken. Then is "Empty" as special case?=0A= =0A= =0A= So:=0A= - Yes we should define the behavior on *all* unknown and unsupported values= =0A= of all fields in the NSH. I believe we took an action in Westford to do t= hat.=0A= - For next protocol I think:=0A= - SFF should not examine, but should forward=0A= - SFC Proxy must not pass to an SF a packet of type that it cannot=0A= indicate to the SF=0A= - SFC Proxy must not pass to an SF a packet of type that the SF does=0A= not support=0A= - SFC should not return to the SFF a packet it has not passed to the SF= =0A= - SF should not return to the SFF a packet it hasn't processed unless=0A= local policy defines "process" to mean "not process" in this case=0A= =0A= [DD] The net outcome being unknown next-header types are dropped somewhere?= =0A= =0A= > "None" should not be a special case of unsupported.=0A= =0A= Hmmm. I think that is dangerous.=0A= There is a big difference between an unknown data type and absent data.=0A= I *do* agree that for implementations that don't support "None" there will = be no distinction between "None" and "Unsupported"=0A= =0A= > I'm inclined to say we should add None to the Next-Header values in the N= SH=0A= > document, and clarify forwarding behavior to support the ideas in your se= ction 4=0A= > on Backward Compatibility.=0A= =0A= Like I said, the authors would be happy to see this go into the base NSH sp= ec, but we don't think you can simply define the value in the IANA section = without saying what it means. So some additional text would be needed as we= ll (presumably culled from the draft).=0A= [DD] Except we have no explanation for handling MPLS, Ethernet, IPv4, or IP= v6. Only the values are defined in each case. Presumably the handling of Em= pty will be as self-evident as the others...=0A= =0A= And that leads to the question of how quickly the WG would reach consensus = on this and get the draft updated.=0A= I keep hearing "We have to get on and publish the NSH spec" and I didn't wa= nt to suggest changes that would only cause further delay.=0A= =0A= As to your point...=0A= =0A= > =FDThe use cases in your draft use concepts not defined by any adopted dr= aft, such=0A= > as semantics of metadata and using metadata for OAM. (We need to work on= =0A= > these!) I think many of suggestions apply for all Next-Protocol types.=0A= =0A= I'm not sure that the draft describes semantics of metadata. It does talk a= bout the scope of the metadata (per SFP, per flow, per packet) and if this = is what you mean, then all I can say is that the whole concept of metadata = may be a little under-specified.=0A= =0A= You could be referring to two places where we make observations about the c= ontent of metadata. The first is where we say that if you want to support p= er-flow metadata in an NSH packet with Next Protocol =3D "None" the metadat= a will need to indicate which flow the metadata applies to. I believe this = to be self-evident. The second case is where we say that metadata could con= tain OAM. You're correct that this has not been stated anywhere, but it is = also "self-evident" from the current definition of the NSH.=0A= =0A= Did I miss your point?=0A= [DD] I think I was trying to make the point that various statements about m= etadata and OAM should not be defined specifically for "empty" protocol. Wh= en each of these things are given treatment for MPLS, IP and Ethernet packe= ts, whatever is said should apply to Empty as well.=0A= [DD] Also, as far as I can tell, even these concepts of per-flow or per-pat= h metadata are absent from the NSH draft. =0A= =0A= Cheers,=0A= Adrian=0A= =0A= From nobody Sun Jan 22 23:07:31 2017 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 17C511295D1 for ; Sun, 22 Jan 2017 23:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_HELO_PASS=-0.001, 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 Gf25tgdiKDNh for ; Sun, 22 Jan 2017 23:07:28 -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 7EF6B1295C1 for ; Sun, 22 Jan 2017 23:07:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0D8812510CC; Sun, 22 Jan 2017 23:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1485155248; bh=4nPXef7iqgs2RO7xJk9ImmMM1K8yPc367CjwUcre0Oc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=GjRzE0LMWXd7XeXBsPp2X98cES/RpEexOaxZHuquOVJUVlXhQcd6yUANWB9JKVduq kS+J/fSXs6kXhlGcbQvphlezythJjqQAoq9ADPrUu/TsEZb3pYhLF+2rdPPnuYWq8K Zm4+nmvfC/Y/472+tP/JajXeIla1s9XMeBZm5EBk= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (74-212-241-145.static-ip.telepacific.net [74.212.241.145]) (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 8B29A240AFF; Sun, 22 Jan 2017 23:07:27 -0800 (PST) To: Dave Dolson , "adrian@olddog.co.uk" References: <20170122175237.5697621.9165.132101@sandvine.com> <0a7b01d27500$b0b5a5f0$1220f1d0$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: <4e47a7de-3a24-5e0b-a2b1-98a9fd0e313c@joelhalpern.com> Date: Mon, 23 Jan 2017 02:07:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 07:07:30 -0000 Speaking as a participant, I rather like Adrian's description. In particular, his last bullet covers a necessary case. if an SF receives an NSH packet with a next protocol that it "knows" but does not actually support, then it has to drop the packet. (For example, an SF which expects an IP packet, and receives an Ethernet packet. of the reverse.) Thus, dropping packets at SF which need to process content, but which do not understand the next protocol field seems to me to be quite appropriate. As Adrian notes, if the SF is defined to pass on unknown next protocols, then passing on the packet is fine. Yours, Joel On 1/22/17 10:09 PM, Dave Dolson wrote: > Adrian, > > You make some good points. I'm still left with the impression that *some* things you say should make their way into the NSH draft. > Please see inline [DD] > > I should say that I don't feel strongly about anything I've said; rather, I'm exploring questions that occurred to me while reading your draft. > > -Dave > > ________________________________________ > From: Adrian Farrel [adrian@olddog.co.uk] > Sent: Sunday, January 22, 2017 5:41 PM > To: Dave Dolson > Cc: sfc@ietf.org > Subject: RE: [sfc] SFC with next protocol = "None" > > Hey Dave, > >> After reading it, a question occurs to me about the nsh draft: >> - does it properly specify forwarding behavior when Next-Protocol is an >> unsupported value? (SFF shouldn't care; SF or SFC Proxy should decrement SI and >> pass through). > > Consider an SF needs to perform function on the packet. Hmm, that would be most SFs :-) > The Next Protocol is pretty fundamental to parsing the packet and working on it. > Now you *could* define an SF that passes "unknown" packets transparently. > It's a policy issue at your SF, but I hope the firewalls I use don't have that policy. > [DD] Point taken. Then is "Empty" as special case? > > > So: > - Yes we should define the behavior on *all* unknown and unsupported values > of all fields in the NSH. I believe we took an action in Westford to do that. > - For next protocol I think: > - SFF should not examine, but should forward > - SFC Proxy must not pass to an SF a packet of type that it cannot > indicate to the SF > - SFC Proxy must not pass to an SF a packet of type that the SF does > not support > - SFC should not return to the SFF a packet it has not passed to the SF > - SF should not return to the SFF a packet it hasn't processed unless > local policy defines "process" to mean "not process" in this case > > [DD] The net outcome being unknown next-header types are dropped somewhere? > >> "None" should not be a special case of unsupported. > > Hmmm. I think that is dangerous. > There is a big difference between an unknown data type and absent data. > I *do* agree that for implementations that don't support "None" there will be no distinction between "None" and "Unsupported" > >> I'm inclined to say we should add None to the Next-Header values in the NSH >> document, and clarify forwarding behavior to support the ideas in your section 4 >> on Backward Compatibility. > > Like I said, the authors would be happy to see this go into the base NSH spec, but we don't think you can simply define the value in the IANA section without saying what it means. So some additional text would be needed as well (presumably culled from the draft). > [DD] Except we have no explanation for handling MPLS, Ethernet, IPv4, or IPv6. Only the values are defined in each case. Presumably the handling of Empty will be as self-evident as the others... > > And that leads to the question of how quickly the WG would reach consensus on this and get the draft updated. > I keep hearing "We have to get on and publish the NSH spec" and I didn't want to suggest changes that would only cause further delay. > > As to your point... > >> ýThe use cases in your draft use concepts not defined by any adopted draft, such >> as semantics of metadata and using metadata for OAM. (We need to work on >> these!) I think many of suggestions apply for all Next-Protocol types. > > I'm not sure that the draft describes semantics of metadata. It does talk about the scope of the metadata (per SFP, per flow, per packet) and if this is what you mean, then all I can say is that the whole concept of metadata may be a little under-specified. > > You could be referring to two places where we make observations about the content of metadata. The first is where we say that if you want to support per-flow metadata in an NSH packet with Next Protocol = "None" the metadata will need to indicate which flow the metadata applies to. I believe this to be self-evident. The second case is where we say that metadata could contain OAM. You're correct that this has not been stated anywhere, but it is also "self-evident" from the current definition of the NSH. > > Did I miss your point? > [DD] I think I was trying to make the point that various statements about metadata and OAM should not be defined specifically for "empty" protocol. When each of these things are given treatment for MPLS, IP and Ethernet packets, whatever is said should apply to Empty as well. > [DD] Also, as far as I can tell, even these concepts of per-flow or per-path metadata are absent from the NSH draft. > > Cheers, > Adrian > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jan 23 10:13:43 2017 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 038301296F9 for ; Mon, 23 Jan 2017 10:13:41 -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 5EZ8Ul7X9L1C for ; Mon, 23 Jan 2017 10:13:38 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459BF129704 for ; Mon, 23 Jan 2017 10:13:38 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0NIDZk9030334; Mon, 23 Jan 2017 18:13:35 GMT Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0NIDW9a030302 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2017 18:13:33 GMT From: "Adrian Farrel" To: "'Joel M. Halpern'" , "'Dave Dolson'" References: <20170122175237.5697621.9165.132101@sandvine.com> <0a7b01d27500$b0b5a5f0$1220f1d0$@olddog.co.uk> <4e47a7de-3a24-5e0b-a2b1-98a9fd0e313c@joelhalpern.com> In-Reply-To: <4e47a7de-3a24-5e0b-a2b1-98a9fd0e313c@joelhalpern.com> Date: Mon, 23 Jan 2017 18:13:36 -0000 Message-ID: <000001d275a4$6b67d960$42378c20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIjbgGmjMAsF5eQhDckwn1123v4nAJPFMO3AgHA09YCBb2f/aBxtoUg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22842.001 X-TM-AS-Result: No--26.796-10.0-31-10 X-imss-scan-details: No--26.796-10.0-31-10 X-TMASE-MatchedRID: DuKherWvI/us/r1De3um7o1nuRzhSr7jTJDl9FKHbrnjsTquy0JRixyt LwNHszGWBha/rZwVYuJrKrvLA7tDFLvx3GaAhvuhb8JTZf0kEzvSde/CNbaZJXoZ5YK74mUQwua niM9QXy12mzSFmhL2YjpBc5uTSHW+2qjKAYV8LUZsG7r4Qh7N3ClayzmQ9QV0mHy7uaiMrL6hgc SssI6A0JrM16VNR3rmUOBwG9PYW5HaYQdwXEMf7ya1MaKuob8Pkd8i2lgND8vSYAzZ6KmqWnG3I Dkkj7AX6Pi20NizNOQry81cDm4Nr5ya2tEru0x7w2taljzThMYrHkgIan9a0QlbhF7ZTanLgr9t REWYnfUx77KgQZpnXtnCxxSATWpR8TjCRfuqbuyM29hkek7Xd0LyokP9aKIRCUA5NvuOPOAHtdY Fc57FhQOLVZfaSYWjibWqJyoFwCdrTkngoOvKEvVFR4sC8dPyf6/Md8Lb2l9hlbn6/nmOL7sIas nPqvyQDIy0rkKqbcEx9CrfL2T3Yt8Zc8LXK22putvHF25zoU/GdQx1K0CtmX+3cBrEL17876jDI dxjVdavSH3NkzsvhYhNVOUtRYl/M2xZ5qQpGCn87vS8PQu3wNMGD8JuBXZPjU56jjASCeFfmFUF y2HXsAFaHcUxDMbpERWBYbnH7n8FCdq0JvYbZZ1U1lojafr/QZXZg2I8JabnU40jhQv76qPFjJE Fr+olg0mnJVv2xOSNo+PRbWqfRJBlLa6MK1y4 Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 18:13:41 -0000 So probably a way forward is... - We continue to work on the NSH draft and polish it as needed (e.g., describing how to handle unknown values) - If that subsumes all of draft-farrel-sfc-convent that will be=20 fine according to the authors - While this is going on, we will continue to maintain draft-farrel-sfc-convent, stripping text that makes it into the NSH draft, and fixing any issues we fine. Depending on how things pan out, the chairs may find us enthusiastic = about getting WG adoption for our draft. Cheers, Adrian > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: 23 January 2017 07:07 > To: Dave Dolson; adrian@olddog.co.uk > Cc: sfc@ietf.org > Subject: Re: [sfc] SFC with next protocol =3D "None" >=20 > Speaking as a participant, I rather like Adrian's description. > In particular, his last bullet covers a necessary case. if an SF > receives an NSH packet with a next protocol that it "knows" but does = not > actually support, then it has to drop the packet. (For example, an SF > which expects an IP packet, and receives an Ethernet packet. of the > reverse.) Thus, dropping packets at SF which need to process content, > but which do not understand the next protocol field seems to me to be > quite appropriate. >=20 > As Adrian notes, if the SF is defined to pass on unknown next = protocols, > then passing on the packet is fine. >=20 > Yours, > Joel >=20 > On 1/22/17 10:09 PM, Dave Dolson wrote: > > Adrian, > > > > You make some good points. I'm still left with the impression that = *some* > things you say should make their way into the NSH draft. > > Please see inline [DD] > > > > I should say that I don't feel strongly about anything I've said; = rather, I'm > exploring questions that occurred to me while reading your draft. > > > > -Dave > > > > ________________________________________ > > From: Adrian Farrel [adrian@olddog.co.uk] > > Sent: Sunday, January 22, 2017 5:41 PM > > To: Dave Dolson > > Cc: sfc@ietf.org > > Subject: RE: [sfc] SFC with next protocol =3D "None" > > > > Hey Dave, > > > >> After reading it, a question occurs to me about the nsh draft: > >> - does it properly specify forwarding behavior when Next-Protocol = is an > >> unsupported value? (SFF shouldn't care; SF or SFC Proxy should = decrement SI > and > >> pass through). > > > > Consider an SF needs to perform function on the packet. Hmm, that = would be > most SFs :-) > > The Next Protocol is pretty fundamental to parsing the packet and = working on > it. > > Now you *could* define an SF that passes "unknown" packets = transparently. > > It's a policy issue at your SF, but I hope the firewalls I use don't = have that policy. > > [DD] Point taken. Then is "Empty" as special case? > > > > > > So: > > - Yes we should define the behavior on *all* unknown and unsupported = values > > of all fields in the NSH. I believe we took an action in Westford = to do that. > > - For next protocol I think: > > - SFF should not examine, but should forward > > - SFC Proxy must not pass to an SF a packet of type that it = cannot > > indicate to the SF > > - SFC Proxy must not pass to an SF a packet of type that the SF = does > > not support > > - SFC should not return to the SFF a packet it has not passed to = the SF > > - SF should not return to the SFF a packet it hasn't processed = unless > > local policy defines "process" to mean "not process" in this = case > > > > [DD] The net outcome being unknown next-header types are dropped > somewhere? > > > >> "None" should not be a special case of unsupported. > > > > Hmmm. I think that is dangerous. > > There is a big difference between an unknown data type and absent = data. > > I *do* agree that for implementations that don't support "None" = there will be > no distinction between "None" and "Unsupported" > > > >> I'm inclined to say we should add None to the Next-Header values in = the NSH > >> document, and clarify forwarding behavior to support the ideas in = your section > 4 > >> on Backward Compatibility. > > > > Like I said, the authors would be happy to see this go into the base = NSH spec, > but we don't think you can simply define the value in the IANA section = without > saying what it means. So some additional text would be needed as well > (presumably culled from the draft). > > [DD] Except we have no explanation for handling MPLS, Ethernet, = IPv4, or IPv6. > Only the values are defined in each case. Presumably the handling of = Empty will > be as self-evident as the others... > > > > And that leads to the question of how quickly the WG would reach = consensus > on this and get the draft updated. > > I keep hearing "We have to get on and publish the NSH spec" and I = didn't want > to suggest changes that would only cause further delay. > > > > As to your point... > > > >> =FDThe use cases in your draft use concepts not defined by any = adopted draft, > such > >> as semantics of metadata and using metadata for OAM. (We need to = work on > >> these!) I think many of suggestions apply for all Next-Protocol = types. > > > > I'm not sure that the draft describes semantics of metadata. It does = talk about > the scope of the metadata (per SFP, per flow, per packet) and if this = is what you > mean, then all I can say is that the whole concept of metadata may be = a little > under-specified. > > > > You could be referring to two places where we make observations = about the > content of metadata. The first is where we say that if you want to = support per- > flow metadata in an NSH packet with Next Protocol =3D "None" the = metadata will > need to indicate which flow the metadata applies to. I believe this to = be self- > evident. The second case is where we say that metadata could contain = OAM. > You're correct that this has not been stated anywhere, but it is also "self-evident" > from the current definition of the NSH. > > > > Did I miss your point? > > [DD] I think I was trying to make the point that various statements = about > metadata and OAM should not be defined specifically for "empty" = protocol. > When each of these things are given treatment for MPLS, IP and = Ethernet > packets, whatever is said should apply to Empty as well. > > [DD] Also, as far as I can tell, even these concepts of per-flow or = per-path > metadata are absent from the NSH draft. > > > > Cheers, > > Adrian > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Mon Jan 23 10:41:44 2017 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 E919812978C for ; Mon, 23 Jan 2017 10:41:42 -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 4AucTJNdKNP5 for ; Mon, 23 Jan 2017 10:41:41 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 F370C129785 for ; Mon, 23 Jan 2017 10:41:40 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id j15so85253634oih.2 for ; Mon, 23 Jan 2017 10:41:40 -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=9l+okKvMUqm1lW1PXlD3SBhMdPkEzytA9Ly8o67mMdU=; b=T3ldDpY9n1GyFpouz/R102QkYFnaCIzSgApGuPwp16+INqg4JjJkCBvcVI3aNZeu86 mbiQJcuo+tg0NF2nH8v2QDmuX6xq8bsmTMCJldav1W+jPWvYM4e0/RE35knSIvZqlvt+ JuaSXsRJOKfkrf59GStWq4mgyp7+Vj51WAXCi467vKFdwkTFgfQ5BbwmpbS7SrKcrULp T1Uu5Yi16/oi7VFhnHQgv+awJ3rsXTlpJ3Wb+B6n+fJCwya273Na8tdpmpF4TW0rZM/i MrEWOu5y3tgNGF/A3xXXIyNNhKxWWiZDJQWvFGNdXxYw902vY4p+3HdMEGzkLobpjxAm 4g5A== 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=9l+okKvMUqm1lW1PXlD3SBhMdPkEzytA9Ly8o67mMdU=; b=mSWqlHFKbXodSp7Ud6gO3VGtqSQYL/LIdoAHhIWPC7P7c7zWgO15ipZeuMbKCQ3KoJ x+ULyPm+P788ghQ6mJEX00EA5K877xtSrHEE+Pn7ltmEOSXgM8MWLHG68I+FzC2Le43E sUsgYnS8HbLiMjKaoKED7MbcEf0kS3RJliJ4CRKLP2gBBx2DaLCfAsjYzYgvYhbNEvml d38sgUXUr1Yu4eEapfdGIOHTmc3y/RtEt5zkXt7VN6Wc+qqjpJ5JkWRfA9OKobHj6lQW sla+YexN6DFmDzC7XkwOOBz+0QPJOv6zuvPX/hvtN5CIjxIBd1vTD+j51X8STp1yE89C 1xWA== X-Gm-Message-State: AIkVDXKY/nLV2j1Xb9+paTa5VEM3Qmi+tGe29B475eV/dbv3OEeqYGEggFKkk1XM7as4Q+QrIrxMqECM1Ny+nQ== X-Received: by 10.202.239.2 with SMTP id n2mr15842647oih.157.1485196900205; Mon, 23 Jan 2017 10:41:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.103 with HTTP; Mon, 23 Jan 2017 10:41:39 -0800 (PST) In-Reply-To: <0a3401d274cb$dd074530$9715cf90$@olddog.co.uk> References: <0a3401d274cb$dd074530$9715cf90$@olddog.co.uk> From: Greg Mirsky Date: Mon, 23 Jan 2017 10:41:39 -0800 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=94eb2c0931daa88dee0546c759b3 Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 18:41:43 -0000 --94eb2c0931daa88dee0546c759b3 Content-Type: text/plain; charset=UTF-8 Dear Authors, et. al, I have some questions, comments to section 5.4: - "Since OAM information will be carried in packets that also include payload data, that information must be carried in metadata." I believe that this is not the case for Active OAM per RFC 7799 definition. And that is diverging from idea of OAM Header for use in Overlay Networks . I believe that Active and Hybrid OAM methods will include OAM specific payload. How such payload identified, in my view, is to be discussed by the WG. OAM methods that do not alter SFC packet in a way that affects treatment of the packet by the network, i.e. forwarding, QoS, classification, can be viewed as passive OAM methods. - "Sending OAM separate from (but interleaved with) packets that carry payload data may have several advantages including:" Is this reference to active OAM methods? Indeed, active OAM methods have advantages comparing to passive and/or hybrid OAM methods but, at the same time, they have their disadvantages among them: - active OAM methods affect the network by adding additional load; - active OAM methods usually require additional consideration, instrumentation to ensure in-band with the flow being measured, monitored. I believe that combination of OAM methods, tools that use active, passive and, perhaps, hybrid OAM methods required to have comprehensive OAM to effectively detect and localize defects such as Loss of Continuity, Miss-connection, Severe Quality Degradation. Regards, Greg On Sun, Jan 22, 2017 at 8:23 AM, Adrian Farrel wrote: > Hi, > > At the interim, Lucy and I took an action to write this draft. It allows > you to > send metadata on an SFP without having a data packet to attach it to. > > There was some discussion about whether this idea should find its way into > the > base NSH draft. I said "no" because of the volume of material, because it > is not > a fundamental of NSH, and because we don't want to hold up the publication > of > the NSH spec. That said, if the WG wants to fold it in, I won't object. > > Please review and comment. We think it is a simple idea and that the > document > pretty much says it all. > > Thanks, > Adrian > > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: 22 January 2017 16:17 > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-farrel-sfc-convent-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Operating the Network Service Header with Next > Protocol "None" > > Authors : Adrian Farrel > > Lucy Yong > > John Drake > > Filename : draft-farrel-sfc-convent-00.txt > > Pages : 8 > > Date : 2017-01-22 > > > > Abstract: > > This document describes the use of the Network Service Header (NSH) > > in a Service Function Chaining (SFC) overlay network with no payload > > data and only carrying metadata. This is achieved by defining a new > > "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's also a htmlized version available at: > > https://tools.ietf.org/html/draft-farrel-sfc-convent-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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --94eb2c0931daa88dee0546c759b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Authors, et. al,
I have some questions, comments = to section 5.4:
  • "Since OAM information will be carri= ed in packets that also include payload data, that information must be carr= ied in metadata."
I believe that this is not the case for Act= ive OAM per RFC 7799 definition. And that is diverging from idea of OAM Hea= der for use in Overlay Networks. I believe that Active and Hybrid OAM m= ethods will include OAM specific payload. How such payload identified, in m= y view, is to be discussed by the WG. OAM methods that do not alter SFC pac= ket in a way that affects treatment of the packet by the network, i.e. forw= arding, QoS, classification, can be viewed as passive OAM methods.
  • "Sending OAM separate from (but interleaved with) pa= ckets that carry payload data may have several advantages including:"<= /li>
Is this reference to active OAM methods? Indeed, active OAM methods have= advantages comparing to passive and/or hybrid OAM methods but, at the same= time, they have their disadvantages among them:
  • active= OAM methods affect the network by adding additional load;
  • active O= AM methods usually require additional consideration, instrumentation to ens= ure in-band with the flow being measured, monitored.
= I believe that combination of OAM methods, tools that use active, passive a= nd, perhaps, hybrid OAM methods required to have comprehensive OAM to effec= tively detect and localize defects such as Loss of Continuity, Miss-connect= ion, Severe Quality Degradation.

Regards,
<= /blockquote>
Greg

On Sun, Jan 22, 2017 at 8:23 AM, Adrian Farrel <= adrian@olddog.co.uk> wrote:
Hi,

At the interim, Lucy and I took an action to write this draft. It allows yo= u to
send metadata on an SFP without having a data packet to attach it to.

There was some discussion about whether this idea should find its way into = the
base NSH draft. I said "no" because of the volume of material, be= cause it is not
a fundamental of NSH, and because we don't want to hold up the publicat= ion of
the NSH spec. That said, if the WG wants to fold it in, I won't object.=

Please review and comment. We think it is a simple idea and that the docume= nt
pretty much says it all.

Thanks,
Adrian

> -----Original Message-----
> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: 22 January 2017 16:17
> To: i-d-announce@ietf.org=
> Subject: I-D Action: draft-farrel-sfc-convent-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Operating the Network Service Header with Next
Protocol "None"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Adrian Farrel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Lucy Yong
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0John Drake
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= farrel-sfc-convent-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-01-22
>
> Abstract:
>=C2=A0 =C2=A0 This document describes the use of the Network Service He= ader (NSH)
>=C2=A0 =C2=A0 in a Service Function Chaining (SFC) overlay network with= no payload
>=C2=A0 =C2=A0 data and only carrying metadata.=C2=A0 This is achieved b= y defining a new
>=C2=A0 =C2=A0 "next protocol" type value of "None".=
>
>=C2=A0 =C2=A0 This document illustrates some of the functions that may = be achieved
>=C2=A0 =C2=A0 or enhanced by this mechanism, but it does not provide an= exhaustive
>=C2=A0 =C2=A0 list of use cases, nor is it intended to be definitive ab= out the
>=C2=A0 =C2=A0 functions it describes.=C2=A0 It is expected that other d= ocuments will
>=C2=A0 =C2=A0 describe specific use cases in more detail and will defin= e the
>=C2=A0 =C2=A0 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's also a htmlized version available at:
> https://tools.ietf.org/html/draft-f= arrel-sfc-convent-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-= d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html=
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<= br>
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--94eb2c0931daa88dee0546c759b3-- From nobody Mon Jan 23 11:58:35 2017 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 77856129854 for ; Mon, 23 Jan 2017 11:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiDlClyiQqMW for ; Mon, 23 Jan 2017 11:58:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FDF129B9D for ; Mon, 23 Jan 2017 11:57:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFB47172; Mon, 23 Jan 2017 19:57:27 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 23 Jan 2017 19:57:26 +0000 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.133]) by SJCEML703-CHM.china.huawei.com ([169.254.5.69]) with mapi id 14.03.0235.001; Mon, 23 Jan 2017 11:57:16 -0800 From: Linda Dunbar To: Greg Mirsky , Adrian Farrel Thread-Topic: [sfc] SFC with next protocol = "None" Thread-Index: AdJ0y9oHPeGeaA1wS2aDJxaMmxW3fABH4k2AAA4vQ+A= Date: Mon, 23 Jan 2017 19:57:15 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F659233A97@SJCEML702-CHM.china.huawei.com> References: <0a3401d274cb$dd074530$9715cf90$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.155] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F659233A97SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58866027.0363, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8fca052bd0544179d39a72c08b08099d Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 19:58:34 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F659233A97SJCEML702CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0K4oCcU2VuZGluZyBPQU0gc2VwYXJhdGUgZnJvbSAoYnV0IGludGVybGVhdmVkIHdp dGgpIHBhY2tldHMgdGhhdCBjYXJyeSBwYXlsb2FkIGRhdGHigJ0gY2Fu4oCZdCBndWFyYW50ZWUg dGhhdCB0aGUgT0FNIHBhY2tldHMgd2lsbCB0cmF2ZXJzZSB0aGUgc2FtZSBwYXRoIGFzIHRoZSBQ YXlsb2FkIGRhdGEgYXMgdGhlcmUgY291bGQgYmUgbWFueSBzZWdtZW50cyBvZiBFQ01QIGJlaW5n IHVzZWQuDQoNCkxpbmRhDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgR3JlZyBNaXJza3kNClNlbnQ6IDIwMTflubQx5pyIMjPml6UgMTI6NDIN ClRvOiBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0KQ2M6IHNmY0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtzZmNdIFNGQyB3aXRoIG5leHQgcHJvdG9jb2wgPSAiTm9uZSINCg0K RGVhciBBdXRob3JzLCBldC4gYWwsDQpJIGhhdmUgc29tZSBxdWVzdGlvbnMsIGNvbW1lbnRzIHRv IHNlY3Rpb24gNS40Og0KDQogICogICAiU2luY2UgT0FNIGluZm9ybWF0aW9uIHdpbGwgYmUgY2Fy cmllZCBpbiBwYWNrZXRzIHRoYXQgYWxzbyBpbmNsdWRlIHBheWxvYWQgZGF0YSwgdGhhdCBpbmZv cm1hdGlvbiBtdXN0IGJlIGNhcnJpZWQgaW4gbWV0YWRhdGEuIg0KSSBiZWxpZXZlIHRoYXQgdGhp cyBpcyBub3QgdGhlIGNhc2UgZm9yIEFjdGl2ZSBPQU0gcGVyIFJGQyA3Nzk5IGRlZmluaXRpb24u IEFuZCB0aGF0IGlzIGRpdmVyZ2luZyBmcm9tIGlkZWEgb2YgT0FNIEhlYWRlciBmb3IgdXNlIGlu IE92ZXJsYXkgTmV0d29ya3M8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW9vYW1k dC1ydGd3Zy1vb2FtLWhlYWRlci0wMT4uIEkgYmVsaWV2ZSB0aGF0IEFjdGl2ZSBhbmQgSHlicmlk IE9BTSBtZXRob2RzIHdpbGwgaW5jbHVkZSBPQU0gc3BlY2lmaWMgcGF5bG9hZC4gSG93IHN1Y2gg cGF5bG9hZCBpZGVudGlmaWVkLCBpbiBteSB2aWV3LCBpcyB0byBiZSBkaXNjdXNzZWQgYnkgdGhl IFdHLiBPQU0gbWV0aG9kcyB0aGF0IGRvIG5vdCBhbHRlciBTRkMgcGFja2V0IGluIGEgd2F5IHRo YXQgYWZmZWN0cyB0cmVhdG1lbnQgb2YgdGhlIHBhY2tldCBieSB0aGUgbmV0d29yaywgaS5lLiBm b3J3YXJkaW5nLCBRb1MsIGNsYXNzaWZpY2F0aW9uLCBjYW4gYmUgdmlld2VkIGFzIHBhc3NpdmUg T0FNIG1ldGhvZHMuDQoNCiAgKiAgICJTZW5kaW5nIE9BTSBzZXBhcmF0ZSBmcm9tIChidXQgaW50 ZXJsZWF2ZWQgd2l0aCkgcGFja2V0cyB0aGF0IGNhcnJ5IHBheWxvYWQgZGF0YSBtYXkgaGF2ZSBz ZXZlcmFsIGFkdmFudGFnZXMgaW5jbHVkaW5nOiINCklzIHRoaXMgcmVmZXJlbmNlIHRvIGFjdGl2 ZSBPQU0gbWV0aG9kcz8gSW5kZWVkLCBhY3RpdmUgT0FNIG1ldGhvZHMgaGF2ZSBhZHZhbnRhZ2Vz IGNvbXBhcmluZyB0byBwYXNzaXZlIGFuZC9vciBoeWJyaWQgT0FNIG1ldGhvZHMgYnV0LCBhdCB0 aGUgc2FtZSB0aW1lLCB0aGV5IGhhdmUgdGhlaXIgZGlzYWR2YW50YWdlcyBhbW9uZyB0aGVtOg0K DQogICogICBhY3RpdmUgT0FNIG1ldGhvZHMgYWZmZWN0IHRoZSBuZXR3b3JrIGJ5IGFkZGluZyBh ZGRpdGlvbmFsIGxvYWQ7DQogICogICBhY3RpdmUgT0FNIG1ldGhvZHMgdXN1YWxseSByZXF1aXJl IGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbiwgaW5zdHJ1bWVudGF0aW9uIHRvIGVuc3VyZSBpbi1i YW5kIHdpdGggdGhlIGZsb3cgYmVpbmcgbWVhc3VyZWQsIG1vbml0b3JlZC4NCkkgYmVsaWV2ZSB0 aGF0IGNvbWJpbmF0aW9uIG9mIE9BTSBtZXRob2RzLCB0b29scyB0aGF0IHVzZSBhY3RpdmUsIHBh c3NpdmUgYW5kLCBwZXJoYXBzLCBoeWJyaWQgT0FNIG1ldGhvZHMgcmVxdWlyZWQgdG8gaGF2ZSBj b21wcmVoZW5zaXZlIE9BTSB0byBlZmZlY3RpdmVseSBkZXRlY3QgYW5kIGxvY2FsaXplIGRlZmVj dHMgc3VjaCBhcyBMb3NzIG9mIENvbnRpbnVpdHksIE1pc3MtY29ubmVjdGlvbiwgU2V2ZXJlIFF1 YWxpdHkgRGVncmFkYXRpb24uDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFN1biwgSmFuIDIyLCAy MDE3IGF0IDg6MjMgQU0sIEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRv OmFkcmlhbkBvbGRkb2cuY28udWs+PiB3cm90ZToNCkhpLA0KDQpBdCB0aGUgaW50ZXJpbSwgTHVj eSBhbmQgSSB0b29rIGFuIGFjdGlvbiB0byB3cml0ZSB0aGlzIGRyYWZ0LiBJdCBhbGxvd3MgeW91 IHRvDQpzZW5kIG1ldGFkYXRhIG9uIGFuIFNGUCB3aXRob3V0IGhhdmluZyBhIGRhdGEgcGFja2V0 IHRvIGF0dGFjaCBpdCB0by4NCg0KVGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBhYm91dCB3aGV0 aGVyIHRoaXMgaWRlYSBzaG91bGQgZmluZCBpdHMgd2F5IGludG8gdGhlDQpiYXNlIE5TSCBkcmFm dC4gSSBzYWlkICJubyIgYmVjYXVzZSBvZiB0aGUgdm9sdW1lIG9mIG1hdGVyaWFsLCBiZWNhdXNl IGl0IGlzIG5vdA0KYSBmdW5kYW1lbnRhbCBvZiBOU0gsIGFuZCBiZWNhdXNlIHdlIGRvbid0IHdh bnQgdG8gaG9sZCB1cCB0aGUgcHVibGljYXRpb24gb2YNCnRoZSBOU0ggc3BlYy4gVGhhdCBzYWlk LCBpZiB0aGUgV0cgd2FudHMgdG8gZm9sZCBpdCBpbiwgSSB3b24ndCBvYmplY3QuDQoNClBsZWFz ZSByZXZpZXcgYW5kIGNvbW1lbnQuIFdlIHRoaW5rIGl0IGlzIGEgc2ltcGxlIGlkZWEgYW5kIHRo YXQgdGhlIGRvY3VtZW50DQpwcmV0dHkgbXVjaCBzYXlzIGl0IGFsbC4NCg0KVGhhbmtzLA0KQWRy aWFuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSS1ELUFubm91bmNl IFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5j ZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mDQo+IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiBTZW50OiAyMiBKYW51YXJ5 IDIwMTcgMTY6MTcNCj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91 bmNlQGlldGYub3JnPg0KPiBTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1mYXJyZWwtc2ZjLWNv bnZlbnQtMDAudHh0DQo+DQo+DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KZGlyZWN0b3JpZXMuDQo+DQo+DQo+ICAg ICAgICAgVGl0bGUgICAgICAgICAgIDogT3BlcmF0aW5nIHRoZSBOZXR3b3JrIFNlcnZpY2UgSGVh ZGVyIHdpdGggTmV4dA0KUHJvdG9jb2wgIk5vbmUiDQo+ICAgICAgICAgQXV0aG9ycyAgICAgICAg IDogQWRyaWFuIEZhcnJlbA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEx1Y3kgWW9uZw0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgIEpvaG4gRHJha2UNCj4gICAgICAgRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtZmFycmVsLXNmYy1jb252ZW50LTAwLnR4dA0KPiAgICAgICBQYWdlcyAg ICAgICAgICAgOiA4DQo+ICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTctMDEtMjINCj4NCj4g QWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSB1c2Ugb2YgdGhlIE5l dHdvcmsgU2VydmljZSBIZWFkZXIgKE5TSCkNCj4gICAgaW4gYSBTZXJ2aWNlIEZ1bmN0aW9uIENo YWluaW5nIChTRkMpIG92ZXJsYXkgbmV0d29yayB3aXRoIG5vIHBheWxvYWQNCj4gICAgZGF0YSBh bmQgb25seSBjYXJyeWluZyBtZXRhZGF0YS4gIFRoaXMgaXMgYWNoaWV2ZWQgYnkgZGVmaW5pbmcg YSBuZXcNCj4gICAgIm5leHQgcHJvdG9jb2wiIHR5cGUgdmFsdWUgb2YgIk5vbmUiLg0KPg0KPiAg ICBUaGlzIGRvY3VtZW50IGlsbHVzdHJhdGVzIHNvbWUgb2YgdGhlIGZ1bmN0aW9ucyB0aGF0IG1h eSBiZSBhY2hpZXZlZA0KPiAgICBvciBlbmhhbmNlZCBieSB0aGlzIG1lY2hhbmlzbSwgYnV0IGl0 IGRvZXMgbm90IHByb3ZpZGUgYW4gZXhoYXVzdGl2ZQ0KPiAgICBsaXN0IG9mIHVzZSBjYXNlcywg bm9yIGlzIGl0IGludGVuZGVkIHRvIGJlIGRlZmluaXRpdmUgYWJvdXQgdGhlDQo+ICAgIGZ1bmN0 aW9ucyBpdCBkZXNjcmliZXMuICBJdCBpcyBleHBlY3RlZCB0aGF0IG90aGVyIGRvY3VtZW50cyB3 aWxsDQo+ICAgIGRlc2NyaWJlIHNwZWNpZmljIHVzZSBjYXNlcyBpbiBtb3JlIGRldGFpbCBhbmQg d2lsbCBkZWZpbmUgdGhlDQo+ICAgIHByb3RvY29sIG1lY2hhbmljcyBmb3IgZWFjaCB1c2UgY2Fz ZS4NCj4NCj4NCj4NCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZhcnJl bC1zZmMtY29udmVudC8NCj4NCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFp bGFibGUgYXQ6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mYXJyZWwtc2Zj LWNvbnZlbnQtMDANCj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0 dHA6Ly90b29scy5pZXRmLm9yZz4uDQo+DQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFp bGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy8NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0Zi5v cmc8bWFpbHRvOkktRC1Bbm5vdW5jZUBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3Jp ZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gb3IgZnRwOi8vZnRwLmlldGYu b3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWls dG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCg0K --_000_4A95BA014132FF49AE685FAB4B9F17F659233A97SJCEML702CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1pY3Jvc29mdCBZYUhlaSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNaWNyb3NvZnQgWWFIZWkiOw0KCXBhbm9zZS0xOjIg MTEgNSAzIDIgMiA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3Vu IjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQyNTA4MTk3NjsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTE1NzY3MTk1MDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgw LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo1NzY5Mzg2MDQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjIxOTk2NzYwMjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMDc2NTg1MjEwOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTMxMDg0MDM5MDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+R3JlZywgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnFNlbmRpbmcg T0FNIHNlcGFyYXRlIGZyb20gKGJ1dCBpbnRlcmxlYXZlZCB3aXRoKSBwYWNrZXRzIHRoYXQgY2Fy cnkgcGF5bG9hZCBkYXRh4oCdIGNhbuKAmXQgZ3VhcmFudGVlIHRoYXQgdGhlIE9BTSBwYWNrZXRz IHdpbGwgdHJhdmVyc2UgdGhlIHNhbWUgcGF0aCBhcyB0aGUgUGF5bG9hZCBkYXRhIGFzIHRoZXJl IGNvdWxkIGJlIG1hbnkgc2VnbWVudHMgb2YgRUNNUCBiZWluZyB1c2VkLg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkxpbmRhPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29t cG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+R3JlZyBNaXJza3k8YnI+DQo8Yj5TZW50Ojwv Yj4gMjAxNzwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWYiPuW5tDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjE8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oyxz YW5zLXNlcmlmIj7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4yMzwvc3Bhbj48c3BhbiBsYW5n PSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9z b2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWYiPuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPg0K IDEyOjQyPGJyPg0KPGI+VG86PC9iPiBBZHJpYW4gRmFycmVsICZsdDthZHJpYW5Ab2xkZG9nLmNv LnVrJmd0Ozxicj4NCjxiPkNjOjwvYj4gc2ZjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbc2ZjXSBTRkMgd2l0aCBuZXh0IHByb3RvY29sID0gJnF1b3Q7Tm9uZSZxdW90OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgQXV0aG9ycywgZXQuIGFsLDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBzb21lIHF1 ZXN0aW9ucywgY29tbWVudHMgdG8gc2VjdGlvbiA1LjQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCiZxdW90O1NpbmNlIE9BTSBpbmZvcm1hdGlvbiB3aWxsIGJlIGNh cnJpZWQgaW4gcGFja2V0cyB0aGF0IGFsc28gaW5jbHVkZSBwYXlsb2FkIGRhdGEsIHRoYXQgaW5m b3JtYXRpb24gbXVzdCBiZSBjYXJyaWVkIGluIG1ldGFkYXRhLiZxdW90OzxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgdGhhdCB0aGlz IGlzIG5vdCB0aGUgY2FzZSBmb3IgQWN0aXZlIE9BTSBwZXIgUkZDIDc3OTkgZGVmaW5pdGlvbi4g QW5kIHRoYXQgaXMgZGl2ZXJnaW5nIGZyb20gaWRlYSBvZjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1vb2FtZHQtcnRnd2ctb29hbS1oZWFkZXItMDEiPiBPQU0gSGVh ZGVyIGZvciB1c2UgaW4gT3ZlcmxheSBOZXR3b3JrczwvYT4uIEkgYmVsaWV2ZQ0KIHRoYXQgQWN0 aXZlIGFuZCBIeWJyaWQgT0FNIG1ldGhvZHMgd2lsbCBpbmNsdWRlIE9BTSBzcGVjaWZpYyBwYXls b2FkLiBIb3cgc3VjaCBwYXlsb2FkIGlkZW50aWZpZWQsIGluIG15IHZpZXcsIGlzIHRvIGJlIGRp c2N1c3NlZCBieSB0aGUgV0cuIE9BTSBtZXRob2RzIHRoYXQgZG8gbm90IGFsdGVyIFNGQyBwYWNr ZXQgaW4gYSB3YXkgdGhhdCBhZmZlY3RzIHRyZWF0bWVudCBvZiB0aGUgcGFja2V0IGJ5IHRoZSBu ZXR3b3JrLCBpLmUuIGZvcndhcmRpbmcsDQogUW9TLCBjbGFzc2lmaWNhdGlvbiwgY2FuIGJlIHZp ZXdlZCBhcyBwYXNzaXZlIE9BTSBtZXRob2RzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwxIGxldmVsMSBsZm8yIj4NCiZxdW90O1NlbmRpbmcgT0FNIHNlcGFyYXRlIGZyb20gKGJ1 dCBpbnRlcmxlYXZlZCB3aXRoKSBwYWNrZXRzIHRoYXQgY2FycnkgcGF5bG9hZCBkYXRhIG1heSBo YXZlIHNldmVyYWwgYWR2YW50YWdlcyBpbmNsdWRpbmc6JnF1b3Q7PG86cD48L286cD48L2xpPjwv dWw+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDow Y20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHRoaXMgcmVmZXJlbmNlIHRvIGFj dGl2ZSBPQU0gbWV0aG9kcz8gSW5kZWVkLCBhY3RpdmUgT0FNIG1ldGhvZHMgaGF2ZSBhZHZhbnRh Z2VzIGNvbXBhcmluZyB0byBwYXNzaXZlIGFuZC9vciBoeWJyaWQgT0FNIG1ldGhvZHMgYnV0LCBh dCB0aGUgc2FtZSB0aW1lLCB0aGV5IGhhdmUgdGhlaXIgZGlzYWR2YW50YWdlcyBhbW9uZyB0aGVt OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjx1bCB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMi Pg0KYWN0aXZlIE9BTSBtZXRob2RzIGFmZmVjdCB0aGUgbmV0d29yayBieSBhZGRpbmcgYWRkaXRp b25hbCBsb2FkOzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwyIGxldmVsMSBsZm8zIj4NCmFjdGl2ZSBPQU0gbWV0aG9kcyB1c3VhbGx5IHJlcXVpcmUgYWRk aXRpb25hbCBjb25zaWRlcmF0aW9uLCBpbnN0cnVtZW50YXRpb24gdG8gZW5zdXJlIGluLWJhbmQg d2l0aCB0aGUgZmxvdyBiZWluZyBtZWFzdXJlZCwgbW9uaXRvcmVkLjxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgYmVsaWV2ZSB0aGF0IGNvbWJpbmF0aW9uIG9mIE9BTSBtZXRob2RzLCB0b29scyB0aGF0IHVz ZSBhY3RpdmUsIHBhc3NpdmUgYW5kLCBwZXJoYXBzLCBoeWJyaWQgT0FNIG1ldGhvZHMgcmVxdWly ZWQgdG8gaGF2ZSBjb21wcmVoZW5zaXZlIE9BTSB0byBlZmZlY3RpdmVseSBkZXRlY3QgYW5kIGxv Y2FsaXplIGRlZmVjdHMgc3VjaCBhcyBMb3NzIG9mIENvbnRpbnVpdHksIE1pc3MtY29ubmVjdGlv biwgU2V2ZXJlDQogUXVhbGl0eSBEZWdyYWRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21h cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+R3JlZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgSmFuIDIyLCAyMDE3IGF0 IDg6MjMgQU0sIEFkcmlhbiBGYXJyZWwgJmx0OzxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9n LmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+YWRyaWFuQG9sZGRvZy5jby51azwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxi cj4NCjxicj4NCkF0IHRoZSBpbnRlcmltLCBMdWN5IGFuZCBJIHRvb2sgYW4gYWN0aW9uIHRvIHdy aXRlIHRoaXMgZHJhZnQuIEl0IGFsbG93cyB5b3UgdG88YnI+DQpzZW5kIG1ldGFkYXRhIG9uIGFu IFNGUCB3aXRob3V0IGhhdmluZyBhIGRhdGEgcGFja2V0IHRvIGF0dGFjaCBpdCB0by48YnI+DQo8 YnI+DQpUaGVyZSB3YXMgc29tZSBkaXNjdXNzaW9uIGFib3V0IHdoZXRoZXIgdGhpcyBpZGVhIHNo b3VsZCBmaW5kIGl0cyB3YXkgaW50byB0aGU8YnI+DQpiYXNlIE5TSCBkcmFmdC4gSSBzYWlkICZx dW90O25vJnF1b3Q7IGJlY2F1c2Ugb2YgdGhlIHZvbHVtZSBvZiBtYXRlcmlhbCwgYmVjYXVzZSBp dCBpcyBub3Q8YnI+DQphIGZ1bmRhbWVudGFsIG9mIE5TSCwgYW5kIGJlY2F1c2Ugd2UgZG9uJ3Qg d2FudCB0byBob2xkIHVwIHRoZSBwdWJsaWNhdGlvbiBvZjxicj4NCnRoZSBOU0ggc3BlYy4gVGhh dCBzYWlkLCBpZiB0aGUgV0cgd2FudHMgdG8gZm9sZCBpdCBpbiwgSSB3b24ndCBvYmplY3QuPGJy Pg0KPGJyPg0KUGxlYXNlIHJldmlldyBhbmQgY29tbWVudC4gV2UgdGhpbmsgaXQgaXMgYSBzaW1w bGUgaWRlYSBhbmQgdGhhdCB0aGUgZG9jdW1lbnQ8YnI+DQpwcmV0dHkgbXVjaCBzYXlzIGl0IGFs bC48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KQWRyaWFuPGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogSS1ELUFubm91bmNlIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnIj5pLWQtYW5ub3Vu Y2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZjxicj4NCiZndDsgPGEgaHJlZj0i bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PC9hPjxicj4NCiZndDsgU2VudDogMjIgSmFudWFyeSAyMDE3IDE2OjE3PGJyPg0KJmd0OyBUbzog PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYu b3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtZmFycmVsLXNmYy1j b252ZW50LTAwLnR4dDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8YnI+ DQpkaXJlY3Rvcmllcy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzogT3BlcmF0aW5nIHRoZSBOZXR3b3JrIFNlcnZpY2UgSGVhZGVyIHdpdGggTmV4 dDxicj4NClByb3RvY29sICZxdW90O05vbmUmcXVvdDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0F1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7OiBBZHJpYW4gRmFycmVsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtMdWN5IFlvbmc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0pvaG4gRHJha2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7RmlsZW5hbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBkcmFmdC1mYXJyZWwtc2Zj LWNvbnZlbnQtMDAudHh0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhZ2Vz Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDg8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IDogMjAxNy0wMS0yMjxicj4NCiZndDs8YnI+DQomZ3Q7IEFic3RyYWN0Ojxi cj4NCiZndDsmbmJzcDsgJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSB1c2Ugb2Yg dGhlIE5ldHdvcmsgU2VydmljZSBIZWFkZXIgKE5TSCk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBp biBhIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgb3ZlcmxheSBuZXR3b3JrIHdpdGgg bm8gcGF5bG9hZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGRhdGEgYW5kIG9ubHkgY2Fycnlpbmcg bWV0YWRhdGEuJm5ic3A7IFRoaXMgaXMgYWNoaWV2ZWQgYnkgZGVmaW5pbmcgYSBuZXc8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmcXVvdDtuZXh0IHByb3RvY29sJnF1b3Q7IHR5cGUgdmFsdWUgb2Yg JnF1b3Q7Tm9uZSZxdW90Oy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgVGhpcyBk b2N1bWVudCBpbGx1c3RyYXRlcyBzb21lIG9mIHRoZSBmdW5jdGlvbnMgdGhhdCBtYXkgYmUgYWNo aWV2ZWQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBvciBlbmhhbmNlZCBieSB0aGlzIG1lY2hhbmlz bSwgYnV0IGl0IGRvZXMgbm90IHByb3ZpZGUgYW4gZXhoYXVzdGl2ZTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7IGxpc3Qgb2YgdXNlIGNhc2VzLCBub3IgaXMgaXQgaW50ZW5kZWQgdG8gYmUgZGVmaW5p dGl2ZSBhYm91dCB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBmdW5jdGlvbnMgaXQgZGVzY3Jp YmVzLiZuYnNwOyBJdCBpcyBleHBlY3RlZCB0aGF0IG90aGVyIGRvY3VtZW50cyB3aWxsPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgZGVzY3JpYmUgc3BlY2lmaWMgdXNlIGNhc2VzIGluIG1vcmUgZGV0 YWlsIGFuZCB3aWxsIGRlZmluZSB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBwcm90b2NvbCBt ZWNoYW5pY3MgZm9yIGVhY2ggdXNlIGNhc2UuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZhcnJlbC1zZmMtY29udmVudC8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZhcnJlbC1zZmMtY29udmVudC88L2E+PGJyPg0K Jmd0Ozxicj4NCiZndDsgVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUg YXQ6PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt ZmFycmVsLXNmYy1jb252ZW50LTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZmFycmVsLXNmYy1jb252ZW50LTAwPC9hPjxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KJmd0OyB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxi cj4NCiZndDs8YnI+DQomZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEktRC1Bbm5vdW5jZSBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmciPkkt RC1Bbm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U8L2E+PGJyPg0K Jmd0OyBJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9zaGFkb3cuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9z aGFkb3cuaHRtbDwvYT48YnI+DQomZ3Q7IG9yIDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9p ZXRmLzFzaGFkb3ctc2l0ZXMudHh0IiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3Jn L2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZmMgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4A95BA014132FF49AE685FAB4B9F17F659233A97SJCEML702CHMchi_-- From nobody Mon Jan 23 12:27:05 2017 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 DA07812987C for ; Mon, 23 Jan 2017 12:27:03 -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 dmLk3h5FCcNM for ; Mon, 23 Jan 2017 12:27:01 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 1D8791297F3 for ; Mon, 23 Jan 2017 12:27:01 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id j15so86992430oih.2 for ; Mon, 23 Jan 2017 12:27:01 -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=SEGCMNa75ctCDl8x+Nuuy4h4IthamBSH6WIkIRvc5t0=; b=j6ZWhD/tUpX/A9PGCsBIWqcXL1/7IDZFX2eiljPfBo12ohZOAaGDngqD/PwqeCbQPq baOJJ3U0sBItpM9aM0wgNIlNcvNOF3ZYKYVEzxZByCHIKXKERQWhCVDwTvqHRfTIdzfP JJDTPTve+JZ+jGgxwMEMnSV5chejyxhbshDxqE3wxiXZa6XZnXdSWpNJiefZkTjbVZjB l0iLJHJr0CHFz9ToHYyXel30ofexpCAAylTOzAYIm7GZTi6cRZphnfj5HPnwcPNEzfWB 8+bzlX+QUiA1M31AG9TIJ0Y7/b3mmtqNcACxws+YVi099pO+hG13z1ZI9fn7jGvI9kk5 iDdQ== 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=SEGCMNa75ctCDl8x+Nuuy4h4IthamBSH6WIkIRvc5t0=; b=b+iJhZezCSaE1NQCNaLo+INtodMoSB4pdPgkwulY8kUn5vn6+s0QTazV5BygzCreKK OeHFYbXJGRffC7d+KMmfeC10Xk4vyynQGfeBLjAzhWYKuUN7HfwZC/nL0FSMW2sF+a+/ C8Xdobi6IdT4Mk1YAQmKxS0jI+DDlu129Zad28xTAadiKa+qhA6lbWe8vYGcXq5VXUAc sZ7m3//OVMv3YOYve2n0y1rC3hie54XXzXJFkSZzhjnEp6J2O7RoNP6b8aa0txuEZWRV KwYJuEvA4Ren5+GRnJ5UphVId5VDQv6cnS63uPTM6qxY41yuGpuAT0yoAObFTKK8hRU+ vwTw== X-Gm-Message-State: AIkVDXJINj68fzrsBTWPgWRZNNfuvv+cDN5qTneAKcwi4De+PjE3tH7cLTJGjqxEVPX94ADBhXWaWzhTRrN1jA== X-Received: by 10.202.239.70 with SMTP id n67mr11212683oih.124.1485203220371; Mon, 23 Jan 2017 12:27:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.103 with HTTP; Mon, 23 Jan 2017 12:26:59 -0800 (PST) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F659233A97@SJCEML702-CHM.china.huawei.com> References: <0a3401d274cb$dd074530$9715cf90$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F659233A97@SJCEML702-CHM.china.huawei.com> From: Greg Mirsky Date: Mon, 23 Jan 2017 12:26:59 -0800 Message-ID: To: Linda Dunbar Content-Type: multipart/alternative; boundary=94eb2c09416a5e9eee0546c8d259 Archived-At: Cc: Adrian Farrel , "sfc@ietf.org" Subject: Re: [sfc] SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 20:27:04 -0000 --94eb2c09416a5e9eee0546c8d259 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Linda, I think that the proposed statement is not always correct. In fact, especially in cases when we define new types of encapsulation, there's good opportunity to ensure that active OAM does follow the monitored data, i.e. is fate-sharing, even in presence of ECMP environments along e2e path. We can document what methods should be used, e.g. use Entropy label rather than derive entropy from the payload in MPLS network, to ensure that active OAM is in-band. And, as the first bullet in section 5.4 notes, active OAM may not be interleaving with data flow when it is used to monitor non-working, e.g. protection, paths/segments. Regards, Greg On Mon, Jan 23, 2017 at 11:57 AM, Linda Dunbar wrote: > Greg, > > > > =E2=80=9CSending OAM separate from (but interleaved with) packets that ca= rry > payload data=E2=80=9D can=E2=80=99t guarantee that the OAM packets will t= raverse the same > path as the Payload data as there could be many segments of ECMP being > used. > > > > Linda > > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* 2017=E5=B9=B41=E6=9C=8823=E6=97=A5 12:42 > *To:* Adrian Farrel > *Cc:* sfc@ietf.org > *Subject:* Re: [sfc] SFC with next protocol =3D "None" > > > > Dear Authors, et. al, > > I have some questions, comments to section 5.4: > > - "Since OAM information will be carried in packets that also include > payload data, that information must be carried in metadata." > > I believe that this is not the case for Active OAM per RFC 7799 > definition. And that is diverging from idea of OAM Header for use in > Overlay Networks > . I > believe that Active and Hybrid OAM methods will include OAM specific > payload. How such payload identified, in my view, is to be discussed by t= he > WG. OAM methods that do not alter SFC packet in a way that affects > treatment of the packet by the network, i.e. forwarding, QoS, > classification, can be viewed as passive OAM methods. > > > - "Sending OAM separate from (but interleaved with) packets that carry > payload data may have several advantages including:" > > Is this reference to active OAM methods? Indeed, active OAM methods have > advantages comparing to passive and/or hybrid OAM methods but, at the sam= e > time, they have their disadvantages among them: > > > - active OAM methods affect the network by adding additional load; > - active OAM methods usually require additional consideration, > instrumentation to ensure in-band with the flow being measured, monito= red. > > I believe that combination of OAM methods, tools that use active, passive > and, perhaps, hybrid OAM methods required to have comprehensive OAM to > effectively detect and localize defects such as Loss of Continuity, > Miss-connection, Severe Quality Degradation. > > > > Regards, > > Greg > > > > On Sun, Jan 22, 2017 at 8:23 AM, Adrian Farrel > wrote: > > Hi, > > At the interim, Lucy and I took an action to write this draft. It allows > you to > send metadata on an SFP without having a data packet to attach it to. > > There was some discussion about whether this idea should find its way int= o > the > base NSH draft. I said "no" because of the volume of material, because it > is not > a fundamental of NSH, and because we don't want to hold up the publicatio= n > of > the NSH spec. That said, if the WG wants to fold it in, I won't object. > > Please review and comment. We think it is a simple idea and that the > document > pretty much says it all. > > Thanks, > Adrian > > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: 22 January 2017 16:17 > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-farrel-sfc-convent-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Operating the Network Service Header with Nex= t > Protocol "None" > > Authors : Adrian Farrel > > Lucy Yong > > John Drake > > Filename : draft-farrel-sfc-convent-00.txt > > Pages : 8 > > Date : 2017-01-22 > > > > Abstract: > > This document describes the use of the Network Service Header (NSH) > > in a Service Function Chaining (SFC) overlay network with no payload > > data and only carrying metadata. This is achieved by defining a new > > "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's also a htmlized version available at: > > https://tools.ietf.org/html/draft-farrel-sfc-convent-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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > --94eb2c09416a5e9eee0546c8d259 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Linda,
I think that the proposed statement is not a= lways correct. In fact, especially in cases when we define new types of enc= apsulation, there's good opportunity to ensure that active OAM does fol= low the monitored data, i.e. is fate-sharing, even in presence of ECMP envi= ronments along e2e path. We can document what methods should be used, e.g. = use Entropy label rather than derive entropy from the payload in MPLS netwo= rk, to ensure that active OAM is in-band.
And, as the first bulle= t in section 5.4 notes, active OAM may not be interleaving with data flow w= hen it is used to monitor non-working, e.g. protection, paths/segments.

Regards,
Greg=C2=A0

On Mon, Jan 23, 2017 at 11:= 57 AM, Linda Dunbar <linda.dunbar@huawei.com> wrote:

Greg,

=C2=A0

=E2=80=9CSending OAM separate from (but interleaved = with) packets that carry payload data=E2=80=9D can=E2=80=99t guarantee that= the OAM packets will traverse the same path as the Payload data as there c= ould be many segments of ECMP being used.

=C2=A0

Linda

=C2=A0

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: 2017=E5=B9=B41=E6=9C=8823= =E6=97=A5 12:42
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: sfc@ietf.org
Subject: Re: [sfc] SFC with next protocol =3D "None"

=C2=A0

Dear Authors, et. al,

I have some questions, comments to section 5.4:

  • "Since OAM information will be carried in packets that also include pa= yload data, that information must be carried in metadata."

I believe that this is not the case for Active OAM p= er RFC 7799 definition. And that is diverging from idea of= OAM Header for use in Overlay Networks. I believe that Active and Hybrid OAM methods will include OAM specific payload. How = such payload identified, in my view, is to be discussed by the WG. OAM meth= ods that do not alter SFC packet in a way that affects treatment of the pac= ket by the network, i.e. forwarding, QoS, classification, can be viewed as passive OAM methods.

  • "Sending OAM separate from (but interleaved with) packets that carry p= ayload data may have several advantages including:"
    • =

Is this reference to active OAM methods? Indeed, act= ive OAM methods have advantages comparing to passive and/or hybrid OAM meth= ods but, at the same time, they have their disadvantages among them:=

  • active OAM methods affect the network by adding additional load;<= /u>
  • active OAM methods usually require additional consideration, instrumentatio= n to ensure in-band with the flow being measured, monitored.<= /li>

I believe that combination of OAM methods, tools tha= t use active, passive and, perhaps, hybrid OAM methods required to have com= prehensive OAM to effectively detect and localize defects such as Loss of C= ontinuity, Miss-connection, Severe Quality Degradation.

=C2=A0

Regards,

Greg

=C2=A0

On Sun, Jan 22, 2017 at 8:23 AM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

Hi,

At the interim, Lucy and I took an action to write this draft. It allows yo= u to
send metadata on an SFP without having a data packet to attach it to.

There was some discussion about whether this idea should find its way into = the
base NSH draft. I said "no" because of the volume of material, be= cause it is not
a fundamental of NSH, and because we don't want to hold up the publicat= ion of
the NSH spec. That said, if the WG wants to fold it in, I won't object.=

Please review and comment. We think it is a simple idea and that the docume= nt
pretty much says it all.

Thanks,
Adrian

> -----Original Message-----
> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf O= f
> internet= -drafts@ietf.org
> Sent: 22 January 2017 16:17
> To: i-d-ann= ounce@ietf.org
> Subject: I-D Action: draft-farrel-sfc-convent-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Operating the Network Service Header with Next
Protocol "None"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Adrian Farrel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Lucy Yong
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0John Drake
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= farrel-sfc-convent-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-01-22
>
> Abstract:
>=C2=A0 =C2=A0 This document describes the use of the Network Service He= ader (NSH)
>=C2=A0 =C2=A0 in a Service Function Chaining (SFC) overlay network with= no payload
>=C2=A0 =C2=A0 data and only carrying metadata.=C2=A0 This is achieved b= y defining a new
>=C2=A0 =C2=A0 "next protocol" type value of "None".=
>
>=C2=A0 =C2=A0 This document illustrates some of the functions that may = be achieved
>=C2=A0 =C2=A0 or enhanced by this mechanism, but it does not provide an= exhaustive
>=C2=A0 =C2=A0 list of use cases, nor is it intended to be definitive ab= out the
>=C2=A0 =C2=A0 functions it describes.=C2=A0 It is expected that other d= ocuments will
>=C2=A0 =C2=A0 describe specific use cases in more detail and will defin= e the
>=C2=A0 =C2=A0 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's also a htmlized version available at:
> https://tools.ietf.org/html/draft-farrel-sfc-convent-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc

=C2=A0


--94eb2c09416a5e9eee0546c8d259-- From nobody Mon Jan 23 14:56:39 2017 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 BB6BD1299BF for ; Mon, 23 Jan 2017 14:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 uhxTkIfVfk0n for ; Mon, 23 Jan 2017 14:56:35 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475921298A1 for ; Mon, 23 Jan 2017 14:56:34 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0NMuVHu006125; Mon, 23 Jan 2017 22:56:31 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0NMuQ1X006110 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2017 22:56:29 GMT From: "Adrian Farrel" To: "'Greg Mirsky'" References: <0a3401d274cb$dd074530$9715cf90$@olddog.co.uk> In-Reply-To: Date: Mon, 23 Jan 2017 22:56:29 -0000 Message-ID: <009d01d275cb$f1876980$d4963c80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01D275CB.F18CC0B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLfQOxQmwoQwM8PwAjWDBSXq/8Z7QLCmzBenxb/FHA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22842.003 X-TM-AS-Result: No--19.238-10.0-31-10 X-imss-scan-details: No--19.238-10.0-31-10 X-TMASE-MatchedRID: vWvnoyq7eMxbJCKOm3VRCWnf+v+Bv9DlP6ugjCZDUtXi+lR4fQgbgwme 9sBVaV82nUIuFHHo9KvPmshbRFtLmIEcpMn6x9cZNEJplIoT86wHtdYFc57FhUEr0Xlqm5eDguq GL9mH4wHsEz9ycWwbCgRH1Nr7oERd+yx8oDl9BLyLoqGaSCqufKrxnUL/qmooQ+C6uNsQqdyZJV Ru9ujyj0HWbmeNr66Rrz6KEvj1EHIZskwWqoib3BsizOQuDf4xlZbRCqc/eMgHOBp9MuoPwYEt1 Y3OPabJnVzTgrSv7smdVNZaI2n6/6nvPLpXAU/WmBkO2PCy6Ev88b9wR3XaVtFXkF6ZOSZiuTUK FcBaOlGOWTPX1ucQ4LGj3LN0+Ey9CwT2DH7iMm5IjvA1/YS+0bYxEBqkV05tLz6F4X/vqKaVTBQ be5r9dnz1RWgT40MJ2p7L72NpznZ1BfUeU1jjBFZZHgYtdTB01fce4C9pfzL+Qupom5mURYCc7v lWHWJVtw/o4J9vD+an1yJegn+layJFkesvG4EA2nE29FWZ925J3WLaLAMC+KMn7KGwWNEXEp+NN lyzaQoAwWnlblYdAvHkpkyUphL9Ud7Bjfo+5jQkj7nyXxwWM2lbb2DwZL4D48CHU6S1ISGT6cAR XZZi13cjv2uL87MeZlRzaO1xpJ27tQSrsGbFkaNC2VYmF5XdfCxPmMXdYL5zrFueZ32PHTkJm5d x6PSjDyszNV8ahX2puD25aEtgt0GV2YNiPCWmg0MI3jJm6ECGOZxUAZ8FoulHkXcmFFQ4Xm9sSU te0C9HW+94FA8JF8G0UNgaZpYqssc0fOkKu+mbKItl61J/yZUdXE/WGn0FSlnU38LCY8tp7Kxue u/Ditbkrsq6X+UetVX2a1/ZsViSAifiLNK8jTZn9mEfvUp7+PwWwDZcH4k7DVjhCEiZK4RmuygF Pyrqi98PMjMcW72vryty+dBUgBwh99rmxX13eprLDgnawHQ= Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 22:56:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009E_01D275CB.F18CC0B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Greg, =20 It is not our intention to (re-)open many OAM discussions held = elsewhere. =20 Thus, it is not necessary to explain the benefits of embedding OAM in = data packets, nor the limitations of sending stand-alone OAM packets. The text notes that there are advantages to sending stand-alone OAM = packets and observes that this mechanism can achieve the function. =20 As to how OAM will be carried in NSH packets we either need to fix the = NSH spec or use metadata. This is notwithstanding any work done anywhere = else and is particularly important for implementations being done now. = It is also important for the processing rules we have discussed about = how to handle unknown "next protocol" types. =20 So, and without trying to prejudge any discussions, the following = possible mechanisms exist: =20 - Use metadata - Use next protocol =3D "OAM" - Use the O-bit to say that OAM bytes are found at some place in the = packet =20 Only using metadata is consistent with the current spec. The other two = approaches cause either: - packets to be dropped by SFs that don't know what the next protocol is = (and how to find the real data) - a road crash because the meaning of the O-bit is not tightly defined. =20 Just to stress: I don't mind which way this goes, but an implementation = of the base NSH spec needs to not barf when OAM passes by. =20 Adrian =20 =20 =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: 23 January 2017 18:42 To: Adrian Farrel Cc: sfc@ietf.org Subject: Re: [sfc] SFC with next protocol =3D "None" =20 Dear Authors, et. al, I have some questions, comments to section 5.4: * "Since OAM information will be carried in packets that also include = payload data, that information must be carried in metadata." I believe that this is not the case for Active OAM per RFC 7799 = definition. And that is diverging from idea of OAM Header for use in = Overlay Networks = . I = believe that Active and Hybrid OAM methods will include OAM specific = payload. How such payload identified, in my view, is to be discussed by = the WG. OAM methods that do not alter SFC packet in a way that affects = treatment of the packet by the network, i.e. forwarding, QoS, = classification, can be viewed as passive OAM methods. * "Sending OAM separate from (but interleaved with) packets that carry = payload data may have several advantages including:" Is this reference to active OAM methods? Indeed, active OAM methods have = advantages comparing to passive and/or hybrid OAM methods but, at the = same time, they have their disadvantages among them: * active OAM methods affect the network by adding additional load; * active OAM methods usually require additional consideration, = instrumentation to ensure in-band with the flow being measured, = monitored. I believe that combination of OAM methods, tools that use active, = passive and, perhaps, hybrid OAM methods required to have comprehensive = OAM to effectively detect and localize defects such as Loss of = Continuity, Miss-connection, Severe Quality Degradation. =20 Regards, Greg =20 On Sun, Jan 22, 2017 at 8:23 AM, Adrian Farrel = wrote: Hi, At the interim, Lucy and I took an action to write this draft. It allows = you to send metadata on an SFP without having a data packet to attach it to. There was some discussion about whether this idea should find its way = into the base NSH draft. I said "no" because of the volume of material, because = it is not a fundamental of NSH, and because we don't want to hold up the = publication of the NSH spec. That said, if the WG wants to fold it in, I won't object. Please review and comment. We think it is a simple idea and that the = document pretty much says it all. Thanks, Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 22 January 2017 16:17 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-farrel-sfc-convent-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Operating the Network Service Header with = Next Protocol "None" > Authors : Adrian Farrel > Lucy Yong > John Drake > Filename : draft-farrel-sfc-convent-00.txt > Pages : 8 > Date : 2017-01-22 > > Abstract: > This document describes the use of the Network Service Header (NSH) > in a Service Function Chaining (SFC) overlay network with no = payload > data and only carrying metadata. This is achieved by defining a = new > "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's also a htmlized version available at: > https://tools.ietf.org/html/draft-farrel-sfc-convent-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc =20 ------=_NextPart_000_009E_01D275CB.F18CC0B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Greg,

 

It is not our intention to = (re-)open many OAM discussions held elsewhere.

 

Thus, it is not necessary to = explain the benefits of embedding OAM in data packets, nor the = limitations of sending stand-alone OAM packets.

The text notes that there are = advantages to sending stand-alone OAM packets and observes that this = mechanism can achieve the function.

 

As to how OAM will be carried = in NSH packets we either need to fix the NSH spec or use metadata. This = is notwithstanding any work done anywhere else and is particularly = important for implementations being done now. It is also important for = the processing rules we have discussed about how to handle unknown = "next protocol" types.

 

So, and without trying to = prejudge any discussions, the following possible mechanisms = exist:

 

- Use = metadata

- Use next protocol =3D = "OAM"

- Use the O-bit to say that = OAM bytes are found at some place in the packet

 

Only using metadata is = consistent with the current spec. The other two approaches cause = either:

- packets to be dropped by SFs = that don't know what the next protocol is (and how to find the real = data)

- a road crash because the = meaning of the O-bit is not tightly defined.

 

Just to stress: I don't mind = which way this goes, but an implementation of the base NSH spec needs to = not barf when OAM passes by.

 

Adrian

 

 

 

From: Greg Mirsky = [mailto:gregimirsky@gmail.com]
Sent: 23 January 2017 = 18:42
To: Adrian Farrel
Cc: = sfc@ietf.org
Subject: Re: [sfc] SFC with next protocol =3D = "None"

 

Dear = Authors, et. al,

I have some = questions, comments to section 5.4:

  • "Since OAM information will be = carried in packets that also include payload data, that information must = be carried in metadata."

I believe that this is not the case for Active OAM per = RFC 7799 definition. And that is diverging from idea of = OAM Header for use in Overlay Networks. I believe that Active and = Hybrid OAM methods will include OAM specific payload. How such payload = identified, in my view, is to be discussed by the WG. OAM methods that = do not alter SFC packet in a way that affects treatment of the packet by = the network, i.e. forwarding, QoS, classification, can be viewed as = passive OAM methods.

  • "Sending OAM separate from (but = interleaved with) packets that carry payload data may have several = advantages including:"

Is this reference to active OAM methods? Indeed, = active OAM methods have advantages comparing to passive and/or hybrid = OAM methods but, at the same time, they have their disadvantages among = them:

  • active OAM methods affect the network = by adding additional load;
  • active OAM methods usually require = additional consideration, instrumentation to ensure in-band with the = flow being measured, = monitored.

I believe that combination of OAM methods, tools that = use active, passive and, perhaps, hybrid OAM methods required to have = comprehensive OAM to effectively detect and localize defects such as = Loss of Continuity, Miss-connection, Severe Quality = Degradation.

 

Regards,

Greg

=

 

On = Sun, Jan 22, 2017 at 8:23 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Hi,

At the interim, Lucy and I took an action = to write this draft. It allows you to
send metadata on an SFP without = having a data packet to attach it to.

There was some discussion = about whether this idea should find its way into the
base NSH draft. = I said "no" because of the volume of material, because it is = not
a fundamental of NSH, and because we don't want to hold up the = publication of
the NSH spec. That said, if the WG wants to fold it = in, I won't object.

Please review and comment. We think it is a = simple idea and that the document
pretty much says it = all.

Thanks,
Adrian

> -----Original = Message-----
> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.o= rg] On Behalf Of
> internet-drafts@ietf.org
= > Sent: 22 January 2017 16:17
> To: i-d-announce@ietf.org
> = Subject: I-D Action: = draft-farrel-sfc-convent-00.txt
>
>
> A New = Internet-Draft is available from the on-line = Internet-Drafts
directories.
>
>
>    =      Title           : = Operating the Network Service Header with Next
Protocol = "None"
>         Authors  =        : Adrian Farrel
>      =                     =  Lucy Yong
>              =              John Drake
>  =      Filename        : = draft-farrel-sfc-convent-00.txt
>      =  Pages           : 8
>  =      Date            : = 2017-01-22
>
> Abstract:
>    This document = describes the use of the Network Service Header (NSH)
>  =   in a Service Function Chaining (SFC) overlay network with no = payload
>    data and only carrying metadata.  This = is achieved by defining a new
>    "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-conve= nt/
>
> There's also a htmlized version available = at:
> https://tools.ietf.org/html/draft-farrel-sfc-convent-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/
>
>= _______________________________________________
> I-D-Announce = mailing list
> I-D-Announce@ietf.org
> = https://www.ietf.org/mailman/listinfo/i-d-announce<= br>> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

__= _____________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

 

------=_NextPart_000_009E_01D275CB.F18CC0B0-- From nobody Tue Jan 24 01:34:57 2017 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 584711294B7 for ; Tue, 24 Jan 2017 01:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD8N8EjhTKKB for ; Tue, 24 Jan 2017 01:34:54 -0800 (PST) Received: from relais-inet.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 C12331294C8 for ; Tue, 24 Jan 2017 01:34:53 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 4E34660C25; Tue, 24 Jan 2017 10:34:52 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 2EE6340074; Tue, 24 Jan 2017 10:34:52 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Tue, 24 Jan 2017 10:34:51 +0100 From: To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] How to progress our control plane requirements document Thread-Index: AQHSbciriLlNdAXjj0Oc0IyPYVyfL6FHafzw Date: Tue, 24 Jan 2017 09:34:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DE8FFF@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.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 09:34:55 -0000 Hi Joel, all,=20 We discussed at length this topic during the interim meeting, but I would l= ike to make some comments on the mailing list too.=20 Ideas to better structure the document are always welcome. As you know, the document was built without making any assumption that (1) = one or multiple protocols will be used to fulfil the requirements, (2) the = same or distinct protocols can be used to implement each of the interfaces = identified in the document, while (3) avoiding overloading the document wit= h deployment-specific considerations. Further, the main target audience for this document are protocols designers= . Because control protocols (extensions) are likely to be defined in other = WG, this document defines the minimum set of requirements that the SFC WG a= greed that need to be supported. Solutions documents need to comply with th= e requirements in this draft in order to be stamped as SFC-compliant soluti= on. I agree that it is easy to check the compliancy for solutions that targ= et one single CP interface, a set of CP interfaces of all the CP interfaces= defined in the CP architecture. It is indeed more difficult to assess the = compliancy for solutions that target a subset of functional requirements th= at are invoking the various interfaces (e.g., SFC forwarding control, conte= xt data control, etc.). Let's discuss how some (functional) would help here= . Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Joel M. Halpern > Envoy=E9=A0: vendredi 13 janvier 2017 19:12 > =C0=A0: sfc@ietf.org > Objet=A0: [sfc] How to progress our control plane requirements document >=20 > Jim and I have been talking with Alia about this, and talking with each > other. Along the way we realized that we have some significant concerns > about what we have done with this document. >=20 > We expect to discuss this next week at the interim, looking for ideas. > And to discuss it further on the list. >=20 > The existing control plane document when viewed from the perspective of > an implementer is hard to decompose into actionable parts. Given that > the IETF tends to work by solving pieces of problems, rather than an > entire control solution for all aspects, it is important that > requriements we define be usable for such piece-wise work. Thus, we need > to describe the requirements in ways that provide components which may > be combined into an overall control plane solution for SFC. >=20 > While the document provides a set of control plane requirements it does > not provide guidance on how those requirements can be successfully > consumed into a standards compliant control plane. In particular, the > interfaces C1 - C4 are each made up of behaviors likely to be provided > by different solution components. Thus, while there is an attempt to > document a set of interfaces (C1...C4) it is not clear how an > implementer can provide a solution component that addresses a > well-defined set of requirements. >=20 > Given this, we need to go back and rethink the bundling of functionality > so as to end up with bundles of requirements that are can be usefully > addressed by IETF work while avoiding (as we have done well in the > current version) prescribing the control plane architecture. >=20 > In addition, functional objectives are not fine grained enough to > implement; for example, text such as "Rationalize the management of > classification rules" is not something one can implement. [Med] The text about "Rationalize the management of classification rules" i= s not a requirement per se, but a reminder of an objective of the SFC effor= t; the text says explicitly=20 "..some functional objectives that can be achieved thanks to the invocation of this interface:" "Rationalize the management of classification rules" is listed to remind th= at this interface is meant to solve a problem that was called out in the SF= C Problem Statement RFC : https://tools.ietf.org/html/rfc7498#section-2.10: =3D=3D Classification occurs at each service function, independent from previously applied service functions since there are limited mechanisms to share the detailed classification information between services. The classification functionality often differs between service functions, and service functions may not leverage the classification results from other service functions. =3D=3D >=20 > Yours, >=20 > Jim & Joel >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jan 24 01:57:43 2017 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 696E7129588 for ; Tue, 24 Jan 2017 01:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCJUE1Y3m66z for ; Tue, 24 Jan 2017 01:57:40 -0800 (PST) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F3A129582 for ; Tue, 24 Jan 2017 01:57:40 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 7E92D60403; Tue, 24 Jan 2017 10:57:38 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 5D5B1180061; Tue, 24 Jan 2017 10:57:38 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Tue, 24 Jan 2017 10:57:38 +0100 From: To: Sumandra Majee , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] How to progress our control plane requirements document Thread-Index: AQHSbciriLlNdAXjj0Oc0IyPYVyfL6E3EWiAgBBdTTA= Date: Tue, 24 Jan 2017 09:57:37 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DE9028@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.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 09:57:41 -0000 RGVhciBTdW1hbmRyYSwgDQoNClRoYW5rIHlvdSBmb3Igc2hhcmluZyB5b3VyIHRob3VnaHRzLiAN Cg0KQW4gaW1wbGVtZW50ZXIgdGhhdCBtYW5hZ2VzIGJvdGggdGhlICJjb250cm9sbGVyKHMpIiBh bmQgImNvbnRyb2xsZWQgZnVuY3Rpb24iIGNhbiBhbHdheXMgaW1wbGVtZW50IHdoYXQgaXQgd2Fu dHMgd2l0aG91dCByZWZlcnJpbmcgdG8gYW4gZXh0ZXJuYWwgcmVxdWlyZW1lbnRzIGRvY3VtZW50 LiBUaGF04oCZcyBmYWlyLiBOZXZlcnRoZWxlc3MsIHN0YW5kYXJkaXplZCBwcm90b2NvbHMgKGV4 dGVuc2lvbnMpIGFyZSBuZWVkZWQgZm9yIGludGVyb3BlcmFiaWxpdHkgcHVycG9zZXMuIFRvIGdl dCB0aGVyZSwgdGhpcyBkb2N1bWVudCBncm91cHMgdGhlIHNldCBvZiBDUCByZXF1aXJlbWVudHMg dGhhdCB0aGUgU0ZDIFdHIHJlcXVpcmVzIHRvIGJlIHN1cHBvcnRlZCB0byBpbnRlcmFjdCB3aXRo IHZhcmlvdXMgaW1wbGVtZW50YXRpb24gcG9pbnRzLiAgDQoNCkdpdmVuIHRoYXQgeW91IGhhdmUg YW4gaW1wbGVtZW50YXRpb24sIG1heSBJIGFzayB5b3UgdGhlIGZvbGxvd2luZyBub24tZXhoYXVz dGl2ZSBxdWVzdGlvbnM6DQoNCiogV2hhdCBpcyB0aGUgaW5mb3JtYXRpb24gdGhhdCBpcyBuZWVk ZWQgZm9yIHlvdXIgY29udHJvbGxlciBhdCBib290c3RyYXA/IA0KKiBEb2VzIHlvdXIgY29udHJv bGxlciByZXF1aXJlIGEgcGVybWFuZW50IHNlc3Npb24gdG8gYmUgbWFpbnRhaW5lZCB3aXRoIHRo ZSBTRkMgY29udHJvbGxlZCBkZXZpY2U/DQoqIERvZXMgeW91ciBjb250cm9sbGVyIGFsbG93IHRv IGluc3RydWN0IHRoZSB1bmRlcmx5aW5nIFNGQy1hd2FyZSBub2RlIGFib3V0IHRoZSB0cmFuc3Bv cnQgZW5jYXBzdWxhdGlvbiB0byBiZSB1c2VkPyAgDQoqIERvZXMgeW91ciBpbXBsZW1lbnRhdGlv biBhbGxvdyB0byBjb250cm9sIHRoZSBzZW1hbnRpYyBvZiBjb250ZXh0IGluZm9ybWF0aW9uLCB0 aGVpciBzY29wZSwgYW5kIGhvdyBpdCBzaG91bGQgYmUgY29uc3VtZWQvc3VwcGxpZWQ/DQoqIERv ZXMgeW91ciBpbXBsZW1lbnRhdGlvbiBhbGxvdyBhIGNsYXNzaWZpZXIgdG8gYXV0by1jbGVhbiBp dHMgZW50cmllcyBieSBtZWFucyBvZiBhIGxpZmV0aW1lPw0KKiBEb2VzIHlvdXIgaW1wbGVtZW50 YXRpb24gYWxsb3cgdG8gcmVtb3ZlIHN0YWxlIGNsYXNzaWZpY2F0aW9uIGVudHJpZXM/DQoqIERv ZXMgeW91ciBpbXBsZW1lbnRhdGlvbiBhbGxvdyB0byByZXRyaWV2ZSB0aGUgbGlzdCBvZiBTRnMg dGhhdCBhcmUgYXR0YWNoZWQgdG8gYSBnaXZlbiBTRkY/DQoqIERvZXMgeW91ciBpbXBsZW1lbnRh dGlvbiBhbGxvdyB0byBpbnN0cnVjdCBhbiBTRkYgYWJvdXQgdGhlIGxpc3Qgb2YgU0ZzIGl0IGNh biBzZXJ2aWNlPw0KKiBEb2VzIHlvdXIgaW1wbGVtZW50YXRpb24gaW5zdHJ1Y3QgdGhlIGNsYXNz aWZpZXIgYWJvdXQgdGhlIHRpZS1icmVhayBydWxlcyB0byBiZSBmb2xsb3dlZCB3aGVuIG1vcmUg dGhhbiBvbmUgY2xhc3NpZmljYXRpb24gZW50cnkgaXMgbWF0Y2hlZD8gDQoqIERvZXMgeW91ciBp bXBsZW1lbnRhdGlvbiBhbGxvdyBhbiBTRkYgdG8gcmVtb3ZlIHN0YWxlIGVudHJpZXMgd2l0aG91 dCB0aGUgaGVscCBvZiB0aGUgY29udHJvbGxlcj8NCiogRG9lcyB5b3VyIGltcGxlbWVudGF0aW9u IGFsbG93IHRvIGRldGVjdCB0aGUgbGl2ZW5lc3Mgb2YgU0ZzPw0KKiBEb2VzIHlvdXIgaW1wbGVt ZW50YXRpb24gYWxsb3cgdG8gY29udHJvbCB0aGUgYmVoYXZpb3Igd2hlbiBhbiBTRiBpcyB0byBi ZSB3aXRoZHJhd24/DQoqIC4uLiAgIA0KDQpUaGFuayB5b3UuDQoNCkNoZWVycywNCk1lZA0KDQo+ IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBTdW1hbmRyYSBNYWplZQ0KPiBFbnZvecOpwqA6 IHNhbWVkaSAxNCBqYW52aWVyIDIwMTcgMDE6NDENCj4gw4DCoDogSm9lbCBNLiBIYWxwZXJuOyBz ZmNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtzZmNdIEhvdyB0byBwcm9ncmVzcyBvdXIgY29u dHJvbCBwbGFuZSByZXF1aXJlbWVudHMgZG9jdW1lbnQNCj4gDQo+IEpvZWwsIEppbSwNCj4gDQo+ IEkgYW0gaW4gZnVsbCBhZ3JlZW1lbnQgd2l0aCB0aGlzLiBIYXZpbmcgZ29uZSB0aHJ1IGEgaW1w bGVtZW50YXRpb24gb2YNCj4gcXVhc2kgY29udHJvbGxlciAoIEkgYW0gc3VyZSBzbyBoYXMgb3Ro ZXJzKSAsIEkgY2FuIHNheSB0aGF0IHRoZSBkb2N1bWVudA0KPiB3YXMgbm90IHZlcnkgZWZmZWN0 aXZlIGZvciBpbXBsZW1lbnRlcnMuIFdoaWxlIHRoZSBjb25jZXB0IGxhaWQgb3V0IG1pZ2h0DQo+ IGJlIHVzZWZ1bCBidXQgaXQgZG9lc27igJl0IHRyYW5zbGF0ZSBpbnRvIGFueXRoaW5nIG1lYW5p bmdmdWwuDQo+IA0KPiBJIGFtIGFjdHVhbGx5IHdvbmRlcmluZyBpZiB0aGVyZSBpcyBhIG5lZWQg Y29udHJvbCBwbGFuZSBkb2N1bWVudCwgaG93ZXZlcg0KPiB0aGVyZSBpcyBhIG5lZWQgZm9yIGRl ZmluaW5nIHRoZSBBUEkvU2NoZW1hIGV0Yy4NCj4gDQo+IFN1bWFuZHJhDQo+IA0KPiBPbiAxLzEz LzE3LCAxMDoxMiBBTSwgInNmYyBvbiBiZWhhbGYgb2YgSm9lbCBNLiBIYWxwZXJuIiA8c2ZjLQ0K PiBib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90 ZToNCj4gDQo+ICAgICBKaW0gYW5kIEkgaGF2ZSBiZWVuIHRhbGtpbmcgd2l0aCBBbGlhIGFib3V0 IHRoaXMsIGFuZCB0YWxraW5nIHdpdGgNCj4gZWFjaA0KPiAgICAgb3RoZXIuICBBbG9uZyB0aGUg d2F5IHdlIHJlYWxpemVkIHRoYXQgd2UgaGF2ZSBzb21lIHNpZ25pZmljYW50DQo+IGNvbmNlcm5z DQo+ICAgICBhYm91dCB3aGF0IHdlIGhhdmUgZG9uZSB3aXRoIHRoaXMgZG9jdW1lbnQuDQo+IA0K PiAgICAgV2UgZXhwZWN0IHRvIGRpc2N1c3MgdGhpcyBuZXh0IHdlZWsgYXQgdGhlIGludGVyaW0s IGxvb2tpbmcgZm9yIGlkZWFzLg0KPiAgICAgQW5kIHRvIGRpc2N1c3MgaXQgZnVydGhlciBvbiB0 aGUgbGlzdC4NCj4gDQo+ICAgICBUaGUgZXhpc3RpbmcgY29udHJvbCBwbGFuZSBkb2N1bWVudCB3 aGVuIHZpZXdlZCBmcm9tIHRoZSBwZXJzcGVjdGl2ZQ0KPiBvZg0KPiAgICAgYW4gaW1wbGVtZW50 ZXIgaXMgaGFyZCB0byBkZWNvbXBvc2UgaW50byBhY3Rpb25hYmxlIHBhcnRzLiBHaXZlbiB0aGF0 DQo+ICAgICB0aGUgSUVURiB0ZW5kcyB0byB3b3JrIGJ5IHNvbHZpbmcgcGllY2VzIG9mIHByb2Js ZW1zLCByYXRoZXIgdGhhbiBhbg0KPiAgICAgZW50aXJlIGNvbnRyb2wgc29sdXRpb24gZm9yIGFs bCBhc3BlY3RzLCBpdCBpcyBpbXBvcnRhbnQgdGhhdA0KPiAgICAgcmVxdXJpZW1lbnRzIHdlIGRl ZmluZSBiZSB1c2FibGUgZm9yIHN1Y2ggcGllY2Utd2lzZSB3b3JrLiBUaHVzLCB3ZQ0KPiBuZWVk DQo+ICAgICB0byBkZXNjcmliZSB0aGUgcmVxdWlyZW1lbnRzIGluIHdheXMgdGhhdCBwcm92aWRl IGNvbXBvbmVudHMgd2hpY2ggbWF5DQo+ICAgICBiZSBjb21iaW5lZCBpbnRvIGFuIG92ZXJhbGwg Y29udHJvbCBwbGFuZSBzb2x1dGlvbiBmb3IgU0ZDLg0KPiANCj4gICAgIFdoaWxlIHRoZSBkb2N1 bWVudCBwcm92aWRlcyBhIHNldCBvZiBjb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cyBpdA0KPiBk b2VzDQo+ICAgICBub3QgcHJvdmlkZSBndWlkYW5jZSBvbiBob3cgdGhvc2UgcmVxdWlyZW1lbnRz IGNhbiBiZSBzdWNjZXNzZnVsbHkNCj4gICAgIGNvbnN1bWVkIGludG8gYSBzdGFuZGFyZHMgY29t cGxpYW50IGNvbnRyb2wgcGxhbmUuIEluIHBhcnRpY3VsYXIsIHRoZQ0KPiAgICAgaW50ZXJmYWNl cyBDMSAtIEM0IGFyZSBlYWNoIG1hZGUgdXAgb2YgYmVoYXZpb3JzIGxpa2VseSB0byBiZSBwcm92 aWRlZA0KPiAgICAgYnkgZGlmZmVyZW50IHNvbHV0aW9uIGNvbXBvbmVudHMuICBUaHVzLCB3aGls ZSB0aGVyZSBpcyBhbiBhdHRlbXB0IHRvDQo+ICAgICBkb2N1bWVudCBhIHNldCBvZiBpbnRlcmZh Y2VzIChDMS4uLkM0KSBpdCBpcyBub3QgY2xlYXIgaG93IGFuDQo+ICAgICBpbXBsZW1lbnRlciBj YW4gcHJvdmlkZSBhIHNvbHV0aW9uIGNvbXBvbmVudCB0aGF0IGFkZHJlc3NlcyBhDQo+ICAgICB3 ZWxsLWRlZmluZWQgc2V0IG9mIHJlcXVpcmVtZW50cy4NCj4gDQo+ICAgICBHaXZlbiB0aGlzLCB3 ZSBuZWVkIHRvIGdvIGJhY2sgYW5kIHJldGhpbmsgdGhlIGJ1bmRsaW5nIG9mDQo+IGZ1bmN0aW9u YWxpdHkNCj4gICAgIHNvIGFzIHRvIGVuZCB1cCB3aXRoIGJ1bmRsZXMgb2YgcmVxdWlyZW1lbnRz IHRoYXQgYXJlIGNhbiBiZSB1c2VmdWxseQ0KPiAgICAgYWRkcmVzc2VkIGJ5IElFVEYgd29yayB3 aGlsZSBhdm9pZGluZyAoYXMgd2UgaGF2ZSBkb25lIHdlbGwgaW4gdGhlDQo+ICAgICBjdXJyZW50 IHZlcnNpb24pIHByZXNjcmliaW5nIHRoZSBjb250cm9sIHBsYW5lIGFyY2hpdGVjdHVyZS4NCj4g DQo+ICAgICBJbiBhZGRpdGlvbiwgZnVuY3Rpb25hbCBvYmplY3RpdmVzIGFyZSBub3QgZmluZSBn cmFpbmVkIGVub3VnaCB0bw0KPiAgICAgaW1wbGVtZW50OyBmb3IgZXhhbXBsZSwgdGV4dCBzdWNo IGFzICJSYXRpb25hbGl6ZSB0aGUgbWFuYWdlbWVudCBvZg0KPiAgICAgY2xhc3NpZmljYXRpb24g cnVsZXMiIGlzIG5vdCBzb21ldGhpbmcgb25lIGNhbiBpbXBsZW1lbnQuDQo+IA0KPiAgICAgWW91 cnMsDQo+IA0KPiAgICAgSmltICYgSm9lbA0KPiANCj4gICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICBzZmMgbWFpbGluZyBsaXN0DQo+ICAg ICBzZmNAaWV0Zi5vcmcNCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== From nobody Tue Jan 24 06:22:05 2017 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 AE1B41295EB for ; Tue, 24 Jan 2017 06:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48aB3p28p7dd for ; Tue, 24 Jan 2017 06:22:02 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA2212949D for ; Tue, 24 Jan 2017 06:22:02 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id D1F1360A08; Tue, 24 Jan 2017 15:22:00 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id AE6818006E; Tue, 24 Jan 2017 15:22:00 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0319.002; Tue, 24 Jan 2017 15:22:00 +0100 From: To: "adrian@olddog.co.uk" Thread-Topic: [sfc] SFC with next protocol = "None" Thread-Index: AdJ0y9oHPeGeaA1wS2aDJxaMmxW3fABf/Uog Date: Tue, 24 Jan 2017 14:21:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DE921A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <0a3401d274cb$dd074530$9715cf90$@olddog.co.uk> In-Reply-To: <0a3401d274cb$dd074530$9715cf90$@olddog.co.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 14:22:04 -0000 Hi Adrian,=20 Thank you for writing the document.=20 FWIW, you may find some comments and suggestions to your I-D here: http://t= inyurl.com/h67m5ux =20 It is tempting to include the "None" value as part of the NSH document itse= lf, but it is perfectly fine to maintain your document on its own because i= t provides some sample use cases.=20 Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Adrian Farrel > Envoy=E9=A0: dimanche 22 janvier 2017 17:23 > =C0=A0: sfc@ietf.org > Objet=A0: [sfc] SFC with next protocol =3D "None" >=20 > Hi, >=20 > At the interim, Lucy and I took an action to write this draft. It allows > you to > send metadata on an SFP without having a data packet to attach it to. >=20 > There was some discussion about whether this idea should find its way int= o > the > base NSH draft. I said "no" because of the volume of material, because it > is not > a fundamental of NSH, and because we don't want to hold up the publicatio= n > of > the NSH spec. That said, if the WG wants to fold it in, I won't object. >=20 > Please review and comment. We think it is a simple idea and that the > document > pretty much says it all. >=20 > Thanks, > Adrian >=20 > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: 22 January 2017 16:17 > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-farrel-sfc-convent-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Operating the Network Service Header with Nex= t > Protocol "None" > > Authors : Adrian Farrel > > Lucy Yong > > John Drake > > Filename : draft-farrel-sfc-convent-00.txt > > Pages : 8 > > Date : 2017-01-22 > > > > Abstract: > > This document describes the use of the Network Service Header (NSH) > > in a Service Function Chaining (SFC) overlay network with no payload > > data and only carrying metadata. This is achieved by defining a new > > "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's also a htmlized version available at: > > https://tools.ietf.org/html/draft-farrel-sfc-convent-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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jan 24 11:46:36 2017 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 A969E1296AF for ; Tue, 24 Jan 2017 11:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKZgK30gG-zU for ; Tue, 24 Jan 2017 11:46:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8D1129584 for ; Tue, 24 Jan 2017 11:46:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFD89412; Tue, 24 Jan 2017 19:46:27 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 24 Jan 2017 19:46:27 +0000 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.133]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Tue, 24 Jan 2017 11:46:23 -0800 From: Linda Dunbar To: "adrian@olddog.co.uk" , "'Joel M. Halpern'" , "'Dave Dolson'" Thread-Topic: questions about the "draft-farrel-sfc-convent" (was RE: [sfc] SFC with next protocol = "None" Thread-Index: AdJ2aAvWBBtn4KfsTIm9lSrapxAY7w== Date: Tue, 24 Jan 2017 19:46:22 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F65923407D@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.208] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5887AF14.032C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 98c736fa19c6820b5d47e9731716c33a Archived-At: Cc: "sfc@ietf.org" Subject: [sfc] questions about the "draft-farrel-sfc-convent" (was RE: SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 19:46:34 -0000 QWRyaWFuLCANCg0KVGhlICIgZHJhZnQtZmFycmVsLXNmYy1jb252ZW50IiBhbGxvd3MgbWV0YWRh dGEgdG8gYmUgZXhjaGFuZ2VkIHdpdGhvdXQgYW55IHBheWxvYWQuIEJ5IGRvaW5nIHNvLCB0aG9z ZSBtZXRhZGF0YSBjYW4gYWNoaWV2ZSB0aGUgdGFza3MgdHJhZGl0aW9uYWxseSBkb25lIGJ5IHRo ZSBJUFBNICwgc3VjaCBhcyBUV0FNUC4gSSB0aGluayBpdCBpcyBhIGdyZWF0IGlkZWEuIA0KQXMg bWFueSB2ZW5kb3JzIGhhdmUgaW1wbGVtZW50ZWQgVFdBTVAsIHBvc3NpYmxlIHRvIGFkb3B0IHRo ZSBzaW1pbGFyIGNvbnRyb2wgbWVjaGFuaXNtcyBzcGVjaWZpZWQgYnkgUkZDNTM1Nz8NCg0KWW91 ciBTZWN0aW9uIDUuMiBzYXlzICJ0aGUgaWRlbnRpdHkgb2YgdGhlIGZsb3cgd291bGQgbmVlZCB0 byBiZSBjYXJyaWVkIGluIHRoZSBtZXRhZGF0YSIuIA0KDQpFdmVuIHdpdGggZW1wdHkgcGF5bG9h ZCwgZG9lcyB0aGUgcGFja2V0IHdpdGggdGhlIG1ldGFkYXRhIHN0aWxsIGhhdmUgdGhlIHNhbWUg SVAgaGVhZGVyPyANClRoZW4sIGVhY2ggcGFja2V0IGhlYWRlciBpdHNlbGYgY2FuIGlkZW50aWZ5 IHRoZSBmbG93LiBXaHkgbmVlZCB0aGUgImZsb3cgaWRlbnRpdHkiIHRvIGJlIGNhcnJpZWQgaW4g dGhlIG1ldGFkYXRhPyANCg0KTGluZGEgDQoNCkZsb3cgaXMgbm90IGEgY29uY3JldGUgZGVmaW5p dGlvbi4gd2hhdCBkb2VzICJpZGVudGl0eSBvZiB0aGUgZmxvdyIgbWVhbj8gd2h5IG5lZWQgdG8g Y2FycmllZCBieSB0aGUgDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFtt YWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsDQpT ZW50OiAyMDE35bm0MeaciDIz5pelIDEyOjE0DQpUbzogJ0pvZWwgTS4gSGFscGVybicgPGptaEBq b2VsaGFscGVybi5jb20+OyAnRGF2ZSBEb2xzb24nIDxkZG9sc29uQHNhbmR2aW5lLmNvbT4NCkNj OiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2ZjXSBTRkMgd2l0aCBuZXh0IHByb3RvY29s ID0gIk5vbmUiDQoNClNvIHByb2JhYmx5IGEgd2F5IGZvcndhcmQgaXMuLi4NCg0KLSBXZSBjb250 aW51ZSB0byB3b3JrIG9uIHRoZSBOU0ggZHJhZnQgYW5kIHBvbGlzaCBpdCBhcyBuZWVkZWQNCiAg IChlLmcuLCBkZXNjcmliaW5nIGhvdyB0byBoYW5kbGUgdW5rbm93biB2YWx1ZXMpDQotIElmIHRo YXQgc3Vic3VtZXMgYWxsIG9mIGRyYWZ0LWZhcnJlbC1zZmMtY29udmVudCB0aGF0IHdpbGwgYmUg DQogICBmaW5lIGFjY29yZGluZyB0byB0aGUgYXV0aG9ycw0KLSBXaGlsZSB0aGlzIGlzIGdvaW5n IG9uLCB3ZSB3aWxsIGNvbnRpbnVlIHRvIG1haW50YWluDQogICBkcmFmdC1mYXJyZWwtc2ZjLWNv bnZlbnQsIHN0cmlwcGluZyB0ZXh0IHRoYXQgbWFrZXMgaXQgaW50byB0aGUNCiAgIE5TSCBkcmFm dCwgYW5kIGZpeGluZyBhbnkgaXNzdWVzIHdlIGZpbmUuDQoNCkRlcGVuZGluZyBvbiBob3cgdGhp bmdzIHBhbiBvdXQsIHRoZSBjaGFpcnMgbWF5IGZpbmQgdXMgZW50aHVzaWFzdGljIGFib3V0IGdl dHRpbmcgV0cgYWRvcHRpb24gZm9yIG91ciBkcmFmdC4NCg0KQ2hlZXJzLA0KQWRyaWFuDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWls dG86am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4gU2VudDogMjMgSmFudWFyeSAyMDE3IDA3OjA3DQo+ IFRvOiBEYXZlIERvbHNvbjsgYWRyaWFuQG9sZGRvZy5jby51aw0KPiBDYzogc2ZjQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTRkMgd2l0aCBuZXh0IHByb3RvY29sID0gIk5vbmUiDQo+ IA0KPiBTcGVha2luZyBhcyBhIHBhcnRpY2lwYW50LCBJIHJhdGhlciBsaWtlIEFkcmlhbidzIGRl c2NyaXB0aW9uLg0KPiBJbiBwYXJ0aWN1bGFyLCBoaXMgbGFzdCBidWxsZXQgY292ZXJzIGEgbmVj ZXNzYXJ5IGNhc2UuICBpZiBhbiBTRiANCj4gcmVjZWl2ZXMgYW4gTlNIIHBhY2tldCB3aXRoIGEg bmV4dCBwcm90b2NvbCB0aGF0IGl0ICJrbm93cyIgYnV0IGRvZXMgDQo+IG5vdCBhY3R1YWxseSBz dXBwb3J0LCB0aGVuIGl0IGhhcyB0byBkcm9wIHRoZSBwYWNrZXQuICAoRm9yIGV4YW1wbGUsIA0K PiBhbiBTRiB3aGljaCBleHBlY3RzIGFuIElQIHBhY2tldCwgYW5kIHJlY2VpdmVzIGFuIEV0aGVy bmV0IHBhY2tldC4gIG9mIA0KPiB0aGUNCj4gcmV2ZXJzZS4pICBUaHVzLCBkcm9wcGluZyBwYWNr ZXRzIGF0IFNGIHdoaWNoIG5lZWQgdG8gcHJvY2VzcyBjb250ZW50LCANCj4gYnV0IHdoaWNoIGRv IG5vdCB1bmRlcnN0YW5kIHRoZSBuZXh0IHByb3RvY29sIGZpZWxkIHNlZW1zIHRvIG1lIHRvIGJl IA0KPiBxdWl0ZSBhcHByb3ByaWF0ZS4NCj4gDQo+IEFzIEFkcmlhbiBub3RlcywgaWYgdGhlIFNG IGlzIGRlZmluZWQgdG8gcGFzcyBvbiB1bmtub3duIG5leHQgDQo+IHByb3RvY29scywgdGhlbiBw YXNzaW5nIG9uIHRoZSBwYWNrZXQgaXMgZmluZS4NCj4gDQo+IFlvdXJzLA0KPiBKb2VsDQo+IA0K PiBPbiAxLzIyLzE3IDEwOjA5IFBNLCBEYXZlIERvbHNvbiB3cm90ZToNCj4gPiBBZHJpYW4sDQo+ ID4NCj4gPiBZb3UgbWFrZSBzb21lIGdvb2QgcG9pbnRzLiBJJ20gc3RpbGwgbGVmdCB3aXRoIHRo ZSBpbXByZXNzaW9uIHRoYXQgDQo+ID4gKnNvbWUqDQo+IHRoaW5ncyB5b3Ugc2F5IHNob3VsZCBt YWtlIHRoZWlyIHdheSBpbnRvIHRoZSBOU0ggZHJhZnQuDQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUg W0REXQ0KPiA+DQo+ID4gSSBzaG91bGQgc2F5IHRoYXQgSSBkb24ndCBmZWVsIHN0cm9uZ2x5IGFi b3V0IGFueXRoaW5nIEkndmUgc2FpZDsgDQo+ID4gcmF0aGVyLA0KSSdtDQo+IGV4cGxvcmluZyBx dWVzdGlvbnMgdGhhdCBvY2N1cnJlZCB0byBtZSB3aGlsZSByZWFkaW5nIHlvdXIgZHJhZnQuDQo+ ID4NCj4gPiAtRGF2ZQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IEZyb206IEFkcmlhbiBGYXJyZWwgW2FkcmlhbkBvbGRkb2cuY28udWtdDQo+ ID4gU2VudDogU3VuZGF5LCBKYW51YXJ5IDIyLCAyMDE3IDU6NDEgUE0NCj4gPiBUbzogRGF2ZSBE b2xzb24NCj4gPiBDYzogc2ZjQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFtzZmNdIFNGQyB3 aXRoIG5leHQgcHJvdG9jb2wgPSAiTm9uZSINCj4gPg0KPiA+IEhleSBEYXZlLA0KPiA+DQo+ID4+ IEFmdGVyIHJlYWRpbmcgaXQsIGEgcXVlc3Rpb24gb2NjdXJzIHRvIG1lIGFib3V0IHRoZSBuc2gg ZHJhZnQ6DQo+ID4+IC0gZG9lcyBpdCBwcm9wZXJseSBzcGVjaWZ5IGZvcndhcmRpbmcgYmVoYXZp b3Igd2hlbiBOZXh0LVByb3RvY29sIA0KPiA+PiBpcyBhbiB1bnN1cHBvcnRlZCB2YWx1ZT8gKFNG RiBzaG91bGRuJ3QgY2FyZTsgU0Ygb3IgU0ZDIFByb3h5IA0KPiA+PiBzaG91bGQgZGVjcmVtZW50 IFNJDQo+IGFuZA0KPiA+PiBwYXNzIHRocm91Z2gpLg0KPiA+DQo+ID4gQ29uc2lkZXIgYW4gU0Yg bmVlZHMgdG8gcGVyZm9ybSBmdW5jdGlvbiBvbiB0aGUgcGFja2V0LiBIbW0sIHRoYXQgDQo+ID4g d291bGQgYmUNCj4gbW9zdCBTRnMgOi0pDQo+ID4gVGhlIE5leHQgUHJvdG9jb2wgaXMgcHJldHR5 IGZ1bmRhbWVudGFsIHRvIHBhcnNpbmcgdGhlIHBhY2tldCBhbmQgDQo+ID4gd29ya2luZyBvbg0K PiBpdC4NCj4gPiBOb3cgeW91ICpjb3VsZCogZGVmaW5lIGFuIFNGIHRoYXQgcGFzc2VzICJ1bmtu b3duIiBwYWNrZXRzIHRyYW5zcGFyZW50bHkuDQo+ID4gSXQncyBhIHBvbGljeSBpc3N1ZSBhdCB5 b3VyIFNGLCBidXQgSSBob3BlIHRoZSBmaXJld2FsbHMgSSB1c2UgZG9uJ3QgDQo+ID4gaGF2ZQ0K dGhhdCBwb2xpY3kuDQo+ID4gW0REXSBQb2ludCB0YWtlbi4gVGhlbiBpcyAiRW1wdHkiIGFzIHNw ZWNpYWwgY2FzZT8NCj4gPg0KPiA+DQo+ID4gU286DQo+ID4gLSBZZXMgd2Ugc2hvdWxkIGRlZmlu ZSB0aGUgYmVoYXZpb3Igb24gKmFsbCogdW5rbm93biBhbmQgdW5zdXBwb3J0ZWQgdmFsdWVzDQo+ ID4gICBvZiBhbGwgZmllbGRzIGluIHRoZSBOU0guIEkgYmVsaWV2ZSB3ZSB0b29rIGFuIGFjdGlv biBpbiBXZXN0Zm9yZCANCj4gPiB0byBkbw0KdGhhdC4NCj4gPiAtIEZvciBuZXh0IHByb3RvY29s IEkgdGhpbms6DQo+ID4gICAgLSBTRkYgc2hvdWxkIG5vdCBleGFtaW5lLCBidXQgc2hvdWxkIGZv cndhcmQNCj4gPiAgICAtIFNGQyBQcm94eSBtdXN0IG5vdCBwYXNzIHRvIGFuIFNGIGEgcGFja2V0 IG9mIHR5cGUgdGhhdCBpdCBjYW5ub3QNCj4gPiAgICAgICBpbmRpY2F0ZSB0byB0aGUgU0YNCj4g PiAgICAtIFNGQyBQcm94eSBtdXN0IG5vdCBwYXNzIHRvIGFuIFNGIGEgcGFja2V0IG9mIHR5cGUg dGhhdCB0aGUgU0YgZG9lcw0KPiA+ICAgICAgIG5vdCBzdXBwb3J0DQo+ID4gICAgLSBTRkMgc2hv dWxkIG5vdCByZXR1cm4gdG8gdGhlIFNGRiBhIHBhY2tldCBpdCBoYXMgbm90IHBhc3NlZCB0byB0 aGUgU0YNCj4gPiAgICAtIFNGIHNob3VsZCBub3QgcmV0dXJuIHRvIHRoZSBTRkYgYSBwYWNrZXQg aXQgaGFzbid0IHByb2Nlc3NlZCB1bmxlc3MNCj4gPiAgICAgIGxvY2FsIHBvbGljeSBkZWZpbmVz ICJwcm9jZXNzIiB0byBtZWFuICJub3QgcHJvY2VzcyIgaW4gdGhpcyANCj4gPiBjYXNlDQo+ID4N Cj4gPiBbRERdIFRoZSBuZXQgb3V0Y29tZSBiZWluZyB1bmtub3duIG5leHQtaGVhZGVyIHR5cGVz IGFyZSBkcm9wcGVkDQo+IHNvbWV3aGVyZT8NCj4gPg0KPiA+PiAiTm9uZSIgc2hvdWxkIG5vdCBi ZSBhIHNwZWNpYWwgY2FzZSBvZiB1bnN1cHBvcnRlZC4NCj4gPg0KPiA+IEhtbW0uIEkgdGhpbmsg dGhhdCBpcyBkYW5nZXJvdXMuDQo+ID4gVGhlcmUgaXMgYSBiaWcgZGlmZmVyZW5jZSBiZXR3ZWVu IGFuIHVua25vd24gZGF0YSB0eXBlIGFuZCBhYnNlbnQgZGF0YS4NCj4gPiBJICpkbyogYWdyZWUg dGhhdCBmb3IgaW1wbGVtZW50YXRpb25zIHRoYXQgZG9uJ3Qgc3VwcG9ydCAiTm9uZSIgDQo+ID4g dGhlcmUgd2lsbA0KYmUNCj4gbm8gZGlzdGluY3Rpb24gYmV0d2VlbiAiTm9uZSIgYW5kICJVbnN1 cHBvcnRlZCINCj4gPg0KPiA+PiBJJ20gaW5jbGluZWQgdG8gc2F5IHdlIHNob3VsZCBhZGQgTm9u ZSB0byB0aGUgTmV4dC1IZWFkZXIgdmFsdWVzIGluIA0KPiA+PiB0aGUgTlNIIGRvY3VtZW50LCBh bmQgY2xhcmlmeSBmb3J3YXJkaW5nIGJlaGF2aW9yIHRvIHN1cHBvcnQgdGhlIA0KPiA+PiBpZGVh cyBpbiB5b3VyDQpzZWN0aW9uDQo+IDQNCj4gPj4gb24gQmFja3dhcmQgQ29tcGF0aWJpbGl0eS4N Cj4gPg0KPiA+IExpa2UgSSBzYWlkLCB0aGUgYXV0aG9ycyB3b3VsZCBiZSBoYXBweSB0byBzZWUg dGhpcyBnbyBpbnRvIHRoZSBiYXNlIA0KPiA+IE5TSA0Kc3BlYywNCj4gYnV0IHdlIGRvbid0IHRo aW5rIHlvdSBjYW4gc2ltcGx5IGRlZmluZSB0aGUgdmFsdWUgaW4gdGhlIElBTkEgc2VjdGlvbiAN Cj4gd2l0aG91dCBzYXlpbmcgd2hhdCBpdCBtZWFucy4gU28gc29tZSBhZGRpdGlvbmFsIHRleHQg d291bGQgYmUgbmVlZGVkIA0KPiBhcyB3ZWxsIChwcmVzdW1hYmx5IGN1bGxlZCBmcm9tIHRoZSBk cmFmdCkuDQo+ID4gW0REXSBFeGNlcHQgd2UgaGF2ZSBubyBleHBsYW5hdGlvbiBmb3IgaGFuZGxp bmcgTVBMUywgRXRoZXJuZXQsIA0KPiA+IElQdjQsIG9yDQpJUHY2Lg0KPiBPbmx5IHRoZSB2YWx1 ZXMgYXJlIGRlZmluZWQgaW4gZWFjaCBjYXNlLiBQcmVzdW1hYmx5IHRoZSBoYW5kbGluZyBvZiAN Cj4gRW1wdHkNCndpbGwNCj4gYmUgYXMgc2VsZi1ldmlkZW50IGFzIHRoZSBvdGhlcnMuLi4NCj4g Pg0KPiA+IEFuZCB0aGF0IGxlYWRzIHRvIHRoZSBxdWVzdGlvbiBvZiBob3cgcXVpY2tseSB0aGUg V0cgd291bGQgcmVhY2ggDQo+ID4gY29uc2Vuc3VzDQo+IG9uIHRoaXMgYW5kIGdldCB0aGUgZHJh ZnQgdXBkYXRlZC4NCj4gPiBJIGtlZXAgaGVhcmluZyAiV2UgaGF2ZSB0byBnZXQgb24gYW5kIHB1 Ymxpc2ggdGhlIE5TSCBzcGVjIiBhbmQgSSANCj4gPiBkaWRuJ3QNCndhbnQNCj4gdG8gc3VnZ2Vz dCBjaGFuZ2VzIHRoYXQgd291bGQgb25seSBjYXVzZSBmdXJ0aGVyIGRlbGF5Lg0KPiA+DQo+ID4g QXMgdG8geW91ciBwb2ludC4uLg0KPiA+DQo+ID4+IOKAjlRoZSB1c2UgY2FzZXMgaW4geW91ciBk cmFmdCB1c2UgY29uY2VwdHMgbm90IGRlZmluZWQgYnkgYW55IA0KPiA+PiBhZG9wdGVkIGRyYWZ0 LA0KPiBzdWNoDQo+ID4+IGFzIHNlbWFudGljcyBvZiBtZXRhZGF0YSBhbmQgdXNpbmcgbWV0YWRh dGEgZm9yIE9BTS4gKFdlIG5lZWQgdG8gDQo+ID4+IHdvcmsgb24NCj4gPj4gdGhlc2UhKSBJIHRo aW5rIG1hbnkgb2Ygc3VnZ2VzdGlvbnMgYXBwbHkgZm9yIGFsbCBOZXh0LVByb3RvY29sIHR5cGVz Lg0KPiA+DQo+ID4gSSdtIG5vdCBzdXJlIHRoYXQgdGhlIGRyYWZ0IGRlc2NyaWJlcyBzZW1hbnRp Y3Mgb2YgbWV0YWRhdGEuIEl0IGRvZXMgDQo+ID4gdGFsaw0KYWJvdXQNCj4gdGhlIHNjb3BlIG9m IHRoZSBtZXRhZGF0YSAocGVyIFNGUCwgcGVyIGZsb3csIHBlciBwYWNrZXQpIGFuZCBpZiB0aGlz IA0KPiBpcyB3aGF0DQp5b3UNCj4gbWVhbiwgdGhlbiBhbGwgSSBjYW4gc2F5IGlzIHRoYXQgdGhl IHdob2xlIGNvbmNlcHQgb2YgbWV0YWRhdGEgbWF5IGJlIA0KPiBhIGxpdHRsZSB1bmRlci1zcGVj aWZpZWQuDQo+ID4NCj4gPiBZb3UgY291bGQgYmUgcmVmZXJyaW5nIHRvIHR3byBwbGFjZXMgd2hl cmUgd2UgbWFrZSBvYnNlcnZhdGlvbnMgDQo+ID4gYWJvdXQgdGhlDQo+IGNvbnRlbnQgb2YgbWV0 YWRhdGEuIFRoZSBmaXJzdCBpcyB3aGVyZSB3ZSBzYXkgdGhhdCBpZiB5b3Ugd2FudCB0byANCj4g c3VwcG9ydA0KcGVyLQ0KPiBmbG93IG1ldGFkYXRhIGluIGFuIE5TSCBwYWNrZXQgd2l0aCBOZXh0 IFByb3RvY29sID0gIk5vbmUiIHRoZSANCj4gbWV0YWRhdGEgd2lsbCBuZWVkIHRvIGluZGljYXRl IHdoaWNoIGZsb3cgdGhlIG1ldGFkYXRhIGFwcGxpZXMgdG8uIEkgDQo+IGJlbGlldmUgdGhpcyB0 byBiZQ0Kc2VsZi0NCj4gZXZpZGVudC4gVGhlIHNlY29uZCBjYXNlIGlzIHdoZXJlIHdlIHNheSB0 aGF0IG1ldGFkYXRhIGNvdWxkIGNvbnRhaW4gT0FNLg0KPiBZb3UncmUgY29ycmVjdCB0aGF0IHRo aXMgaGFzIG5vdCBiZWVuIHN0YXRlZCBhbnl3aGVyZSwgYnV0IGl0IGlzIGFsc28NCiJzZWxmLWV2 aWRlbnQiDQo+IGZyb20gdGhlIGN1cnJlbnQgZGVmaW5pdGlvbiBvZiB0aGUgTlNILg0KPiA+DQo+ ID4gRGlkIEkgbWlzcyB5b3VyIHBvaW50Pw0KPiA+IFtERF0gSSB0aGluayBJIHdhcyB0cnlpbmcg dG8gbWFrZSB0aGUgcG9pbnQgdGhhdCB2YXJpb3VzIHN0YXRlbWVudHMgDQo+ID4gYWJvdXQNCj4g bWV0YWRhdGEgYW5kIE9BTSBzaG91bGQgbm90IGJlIGRlZmluZWQgc3BlY2lmaWNhbGx5IGZvciAi ZW1wdHkiIHByb3RvY29sLg0KPiBXaGVuIGVhY2ggb2YgdGhlc2UgdGhpbmdzIGFyZSBnaXZlbiB0 cmVhdG1lbnQgZm9yIE1QTFMsIElQIGFuZCANCj4gRXRoZXJuZXQgcGFja2V0cywgd2hhdGV2ZXIg aXMgc2FpZCBzaG91bGQgYXBwbHkgdG8gRW1wdHkgYXMgd2VsbC4NCj4gPiBbRERdIEFsc28sIGFz IGZhciBhcyBJIGNhbiB0ZWxsLCBldmVuIHRoZXNlIGNvbmNlcHRzIG9mIHBlci1mbG93IG9yIA0K PiA+IHBlci1wYXRoDQo+IG1ldGFkYXRhIGFyZSBhYnNlbnQgZnJvbSB0aGUgTlNIIGRyYWZ0Lg0K PiA+DQo+ID4gQ2hlZXJzLA0KPiA+IEFkcmlhbg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNmYyBtYWlsaW5nIGxpc3QN Cj4gPiBzZmNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPiA+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Tue Jan 24 23:58:08 2017 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 65425129875 for ; Tue, 24 Jan 2017 23:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6anBEP4ZzwZ for ; Tue, 24 Jan 2017 23:58:05 -0800 (PST) Received: from relais-inet.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 73AB6129871 for ; Tue, 24 Jan 2017 23:58:05 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 75D7BC0BBF; Wed, 25 Jan 2017 08:58:03 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 5A26816005E; Wed, 25 Jan 2017 08:58:03 +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.0319.002; Wed, 25 Jan 2017 08:58:03 +0100 From: To: Kyle Larose Thread-Topic: Some comments on draft-ietf-sfc-control-plane/ Thread-Index: AdJ2XSWLQrZOCvI0SHOBJJB2cIUAmAAeehxA Date: Wed, 25 Jan 2017 07:58:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009DE9608@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.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Some comments on draft-ietf-sfc-control-plane/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 07:58:07 -0000 Hi Kyle, Thank you for the comments. Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Kyle Larose [mailto:klarose@sandvine.com] > Envoy=E9=A0: mardi 24 janvier 2017 17:32 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: sfc@itef.org > Objet=A0: Some comments on draft-ietf-sfc-control-plane/ >=20 > Hello Mohamed, >=20 >=20 > I'm starting to look into developing a control plane protocol for > classifiers (C1 in the draft), so I've taken a look at the sfc control > plane draft. I have a few comments on it. I'll start with the issue that > stood out the most for me. >=20 > First, thanks for authoring this draft. It definitely captured a bunch of > concepts and ideas that I'll need to think about. [Med] Thanks. >=20 > Back to the issue: after reading through the document, I had some concern= s > regarding separation of responsibility among the interfaces. In > particular, some information and actions, which I felt belonged in C2 wer= e > in C1, and vice versa. I used the SFC Architecture, RFC 7665, as a guide > in deciding which interface should be responsible for what. My concerns > could be based entirely on my narrow interpretation of it. Please let me > know if I've taken too narrow a view. :) >=20 > As an example of something belonging in C2, but not C1: >=20 > Section 3.3.1: > " The classifier may be notified (regularly or upon eventual change) > by > the control plane about the available SFs (including the SFFs they > are attached to) or be part of the service function discovery > procedure. > " >=20 > What is the purpose behind this? [Med] This is an **optional** feature that was requested by the WG particip= ants to support an SFC distributed model (Ron may further elaborate as he a= sked for it). For example, this feature allows a classifier to bind flows a= s a function of the available paths and SF instances. Then, packets can be = bound to a fully or partially constrained path accordingly. Also, the disco= very information provided to a classifier may be used for load distribution= purposes. =20 Of course, those cases may be implemented without involving the classifier = by invoking C2 as recorded in Section 3.3.2:=20 " This interface is also used by the SFF to report the connectivity to their attached (including embedded) SFs. Local means may be enabled between the SFC-aware SFs and SFFs to allow for the dynamic attachment of SFs to an SFF and/or discovery of SFs by an SFF" =20 Given that the classifiers are not > conceptually "attached" to SFs on the data plane, doesn't it seem wrong t= o > have the classifiers be aware of the SFs on the control plane? [Med] See above. The idea is to allow for a distributed model to adjust pat= hs (and implement other policies at the classifier). > I understand the classifiers may be co-located with SFs, but I don't see > how their functionality would, or should, depend on the availability of > SFs in the data plane. [Med] The SF/SFF discovery information is not MANDATORY to be provided to a= classifier, but may help in some deployment cases (such as those mentioned= above).=20 >=20 > One use-case I could see for this is having the classifier map a packet t= o > an explicit set of SFs. However, the classifier maps packets to paths, no= t > SFs. Should the logic of mapping of packet to an SF not be performed by > conjoining C1 and C2 at the controller itself? [Med] That's indeed possible. See the excerpt of Section 3.3.2 provided abo= ve. Using C1 to indicate SF > mapping seems to blur the lines between C1 and C2. >=20 > After writing the above, I saw section 4.10.2. It seems to kind of match > what I proposed above. But, I still ask: is this truly the responsibility > of the classifier, or something which may be co-located with it? If the > latter, should it not be a different interface? [Med] Good point. We can always decompose a single interface into a set of = interfaces following some functional rationale, but the reasons why I prefe= r to not add a new one are the following: * Maintain the SFC control plane architecture as simple as possible.=20 * How a classifier decides to bind flows/packets to a given chain is comple= tely policy-based and deployment-specific. There may be simple policies tha= t do not require a feedback from the SFC-enabled domain (e.g., blindly bind= a flow to a chain based on the transport coordinates) and advanced policie= s that require additional information to be enforced (e.g., bind a flow to = a chain as a function of available paths, bind a flow to a chain as a funct= ion of available SF instances, bind a flow to a chian while avoiding to cro= ss a given network region, etc.).=20 >=20 >=20 > Further, section 3.3.3 has an example of something belonging in C1, but > not C2: >=20 > " SF execution status: Some SFs may need to send information to the > control plane to fine tune SFPs. For example, a threat-detecting > SF can periodically send the threat characteristics via this > interface, such as high probability of threat with packet of a > given size. The control plane can then add an appropriate > matching criteria to SFF to steer traffic to a scrubbing center." >=20 > Should this information not be fed back to the classifier via C1, rather > than C2? [Med] It can of course! Please note that the text starts with "For example,= ". If the decision is to use a distinct service path, then a classifier is= likely to be invoked by means of C1. But if the entity managing the SFC do= main does not want to alter the service path, a local policy can be provisi= oned to an SFF via C2 to redirect subsequent packets to a scrubbing center.= =20 I thought the classifier was supposed to be where complex > matching logic runs, with the SFF being a simple forwarder. If we allow > the SFF to run complex matching logic, > (i.e. if this condition, then take this next hop), is it not really > acting as a classifier or reclassifier? >=20 > To be clear, RFC 7665 states: >=20 > "A service function forwarder is > responsible for forwarding traffic to one or more connected > service functions according to information carried in the SFC > encapsulation" >=20 > I do not think that the packet size, for example, is a property of the > encapsulation. As such, I do not think C2 should carry this type of > information. [Med] An SFF executes forwarding actions following the instructions contain= ed in its SFC Forwarding Policy Table. An SFF can forward based on instruct= ions that are compliant with its capabilities. The CP is required to be awa= re of what an SFF is capable to do priori to programming the forwarding tab= le or to enable some protocols (e.g., PCE). The draft is clear about this: An SFF node may not support some of the matching criteria listed above. It is important that SFC control plane can retrieve the supported matching criteria by SFF nodes. =20 >=20 > Building on that point, section 4.10.4 states: >=20 > "The matching criteria for SFF can be more sophisticated. For > example, it could be the SFP-id carried within the SFC encapsulation > with any fields in the data packets, such as (non-exhaustive list)" >=20 > As with my comment in 3.3.3, I don't like the statement that any field in > the data packet can be used to qualify the next hop. It really should com= e > entirely from the encapsulation. That encapsulation *could* very well be > an IP header. However, we should be clear about that. [Med] This text was the result of WG discussion. As an editor of the docume= nt, I can change the text as you propose if there is no objection from the = WG. >=20 > Now, I could see using the information listed here to make a decision as > to which specific instance of an SF to send the packet to, for example > when load-balancing. However, it does not seem correct to choose the nex= t > service function (e.g. Firewall vs content cache) based packet data. >=20 > I have a few more nits/concerns. I can send them in a separate email > thread once we've worked through this one. [Med] Please share those.=20 >=20 > Thanks! >=20 > Kyle From nobody Wed Jan 25 06:49:37 2017 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 148E012997A for ; Wed, 25 Jan 2017 06:49:36 -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 T32FgJejSUw0 for ; Wed, 25 Jan 2017 06:49:35 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4396129979 for ; Wed, 25 Jan 2017 06:49:34 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0PEnQbo005865; Wed, 25 Jan 2017 14:49:26 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0PEnJRv005707 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2017 14:49:24 GMT From: "Adrian Farrel" To: "'Linda Dunbar'" References: <4A95BA014132FF49AE685FAB4B9F17F65923407D@SJCEML702-CHM.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F65923407D@SJCEML702-CHM.china.huawei.com> Date: Wed, 25 Jan 2017 14:49:17 -0000 Message-ID: <031901d2771a$3908f8b0$ab1aea10$@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: AQLpdVFNkBukk1rL4cJEov+8q6+Xup8bRlDQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22844.006 X-TM-AS-Result: No--3.850-10.0-31-10 X-imss-scan-details: No--3.850-10.0-31-10 X-TMASE-MatchedRID: scwq2vQP8OE4HKI/yaqRm5mug812qIbzIM86Aeo6sYIUCxNejJnwywse d7xgehs0tQsQjGYTOpFjywAegvfcPuN8IkV2qksKwVaayvK71l8Lce5ZyDJAJu6NM29Mb5tJm+k Oe6hUk6OjYKE/BuDaR3hbWkjJzPSi/xzjyaAWkwy04Y/NhTxUguiY+s2L3xQEZgLkC3HUNRAcAJ RwO9xbIHxW++dtzLoP6FP/BlUvK98k3l1qOrrWWOYAh37ZsBDCfS0Ip2eEHnzWRN8STJpl3PoLR 4+zsDTt7MdlhN8HX5VADuoXKHbdRCLJdaQPT5LnxPb95l0Nj2o4KIp7TmkMw7PsW0zIx4Jq1n1S Gzt5rQNZOQiackOEDvG7sYv2HJ0lh//5ubkH3i2Hx/3593XRE+S+ZTuCPZ+tPifujgI13dqh071 fQj6NysC+ksT6a9fy Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] questions about the "draft-farrel-sfc-convent" (was RE: SFC with next protocol = "None" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 14:49:36 -0000 Hi Linda, > Your Section 5.2 says "the identity of the flow would need to be = carried in the > metadata". >=20 > Even with empty payload, does the packet with the metadata still have = the same > IP header? > Then, each packet header itself can identify the flow. Why need the = "flow > identity" to be carried in the metadata? I think this is meaningless! The payload protocol might not be IP. The transport tunnel might not be IP. What IP header are you talking about? But, suppose the payload is IP, and the flow is defined by the normal = 5-tuple and suppose the transport is IP. The answer to your question is "no". The transport IP address is used to reach the SFF (or to reach the SF, = depending on where you are standing) so it does not match the flow. And the whole point of Next Protocol "None" is to not have the payload = packet. So, in this case, *an* option is to include the 5-tuple in the metadata. Other options might include placing the hash-result in the metadata, or = using some other index that maps to the flow. I believe: 1. Use cases for per-flow metadata are not well established (even if = they might exist) 2. It is not the job of this document to define how to encode metadata = for any use case (whether it is firmly defined or not). This document = should just make some high-level observations. Thanks, Adrian From nobody Thu Jan 26 12:23:34 2017 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 E9A67129ABF for ; Thu, 26 Jan 2017 12:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s1xBThpC9R2 for ; Thu, 26 Jan 2017 12:23:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 253BA129AC6 for ; Thu, 26 Jan 2017 12:23:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZN91214; Thu, 26 Jan 2017 20:23:27 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 26 Jan 2017 20:23:26 +0000 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.133]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Thu, 26 Jan 2017 12:23:21 -0800 From: Linda Dunbar To: Jim Guichard , "sfc@ietf.org" Thread-Topic: questions to draft-guichard-sfc-nsh-dc-allocation-5 Thread-Index: AdJ4DzA4MC6B0AP/Qwa51I9MD3kByA== Date: Thu, 26 Jan 2017 20:23:19 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F659236D45@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.208] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F659236D45SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.588A5AC0.005C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 325e1b80cf4515b2e339244cdec9f296 Archived-At: Subject: [sfc] questions to draft-guichard-sfc-nsh-dc-allocation-5 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 20:23:33 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F659236D45SJCEML702CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, et al, After reading through the draft, I have a few comments and suggestions. I think the draft describes a very good approach to simplify policies and r= ules to many service functions in the network, which I think is very import= ant. Possible to add some description to address the following points? - The benefit of adding "Destination Class" and "Source class" to th= e metadata. Benefits can be that using classes (instead of actual Dest/Src)= makes it easier to describe group policies that are agnostic to where the = Dst/Src points are located, etc. - Why there are only "Source Node ID" and "Source Interface ID"? Why= not include "Destination Node ID" & "Interface ID"? - Is it the Classifier node that insert those metadata? Who provide = the criteria for what "class" to encode in the metadata for each packet? Wi= ll the criteria be described as ACL? Linda --_000_4A95BA014132FF49AE685FAB4B9F17F659236D45SJCEML702CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim, et al,

 

After reading through the draft, I have a few commen= ts and suggestions.

 

I think the draft describes a very good approach to = simplify policies and rules to many service functions in the network, which= I think is very important.

 

Possible to add some description to address the foll= owing points?

-     &= nbsp;  The benefit of adding “Destination Class̶= 1; and “Source class” to the metadata. Benefits can be that usi= ng classes (instead of actual Dest/Src) makes it easier to describe group p= olicies that are agnostic to where the Dst/Src points are located, etc.

-     &= nbsp;  Why there are only “Source Node ID” and= “Source Interface ID”? Why not include “Destination Node= ID” & “Interface ID”?

-     &= nbsp;  Is it the Classifier node that insert those metadat= a? Who provide the criteria for what “class” to encode in the m= etadata for each packet? Will the criteria be described as ACL?

 

 

 

Linda

 

--_000_4A95BA014132FF49AE685FAB4B9F17F659236D45SJCEML702CHMchi_-- From nobody Mon Jan 30 02:58:19 2017 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 25FCD12998B for ; Mon, 30 Jan 2017 02:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 PZX75muNztbW for ; Mon, 30 Jan 2017 02:58:17 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1070D12943A for ; Mon, 30 Jan 2017 02:58:16 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0UAwBwB015819; Mon, 30 Jan 2017 10:58:11 GMT Received: from 950129200 (bsr-176-153-107-31.ft.ethernet.abo.bbox.fr [176.153.107.31]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0UAw9uo015779 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 30 Jan 2017 10:58:10 GMT From: "Adrian Farrel" To: "Paul Quinn" Date: Mon, 30 Jan 2017 10:58:08 -0000 Message-ID: <008101d27ae7$be9eadf0$3bdc09d0$@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: AdJ651ekvNrU0vNhQiK+1YBvcfm2Pg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22854.006 X-TM-AS-Result: No--5.550-10.0-31-10 X-imss-scan-details: No--5.550-10.0-31-10 X-TMASE-MatchedRID: sz2FKyi+8PC5BwMHRnh09VaA5UKX+E3Vbv16+gil4jfjsTquy0JRixRY MFLgpLvI2BHbtvy6fxFpykTUaVN5SzAnrFtOMFrm5gCHftmwEMJ9LQinZ4QefL6qvLNjDYTwfyj BJDnutUhQSFbL1bvQASAHAopEd76vPiWvyIeL84sBla0HzHwuND9O8NR0hG++eRuzEXzDW4i0pS o60ksp/w== Archived-At: Cc: sfc@ietf.org Subject: [sfc] Working copy of the NSH document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 10:58:18 -0000 Hi Paul, I know that a number of additional updates were discussed in Westford, but I wonder whether you could post a working copy of the NSG document so that we have something slightly more recent and complete to work with. I suppose I might be able to take the current revision and the issue tracker and work out what the working copy would say, but I'm not confident. Thanks, Adrian From nobody Mon Jan 30 06:59:35 2017 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 7D25F1299A3 for ; Mon, 30 Jan 2017 06:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_SOFTFAIL=0.665, 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 Y3xvmdMQzKwn for ; Mon, 30 Jan 2017 06:59:32 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC16B1299A1 for ; Mon, 30 Jan 2017 06:59:31 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Mon, 30 Jan 2017 09:59:29 -0500 From: Kyle Larose To: "mohamed.boucadair@orange.com" Thread-Topic: Some comments on draft-ietf-sfc-control-plane/ Thread-Index: AdJ2XSWLQrZOCvI0SHOBJJB2cIUAmAAeehxAAQuOhgA= Date: Mon, 30 Jan 2017 14:59:28 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933009DE9608@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DE9608@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.51] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Some comments on draft-ietf-sfc-control-plane/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 14:59:34 -0000 Hey Med, sorry for taking so long to get back to you. The last few days hav= e been fairly hectic for me. Please see inline. Thanks, Kyle > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, January 25, 2017 2:58 AM > To: Kyle Larose > Cc: sfc@ietf.org > Subject: RE: Some comments on draft-ietf-sfc-control-plane/ >=20 > Hi Kyle, >=20 > Thank you for the comments. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Kyle Larose [mailto:klarose@sandvine.com] Envoy=E9=A0: mardi 24 > > janvier 2017 17:32 =C0=A0: BOUCADAIR Mohamed IMT/OLN Cc=A0: sfc@itef.or= g > > Objet=A0: Some comments on draft-ietf-sfc-control-plane/ > > > > Hello Mohamed, > > > > > > I'm starting to look into developing a control plane protocol for > > classifiers (C1 in the draft), so I've taken a look at the sfc > control > > plane draft. I have a few comments on it. I'll start with the > issue > > that stood out the most for me. > > > > First, thanks for authoring this draft. It definitely captured a > bunch > > of concepts and ideas that I'll need to think about. >=20 > [Med] Thanks. >=20 > > > > Back to the issue: after reading through the document, I had some > > concerns regarding separation of responsibility among the > interfaces. > > In particular, some information and actions, which I felt belonged > in > > C2 were in C1, and vice versa. I used the SFC Architecture, RFC > 7665, > > as a guide in deciding which interface should be responsible for > what. > > My concerns could be based entirely on my narrow interpretation of > it. > > Please let me know if I've taken too narrow a view. :) > > > > As an example of something belonging in C2, but not C1: > > > > Section 3.3.1: > > " The classifier may be notified (regularly or upon eventual > change) > > by > > the control plane about the available SFs (including the SFFs > they > > are attached to) or be part of the service function discovery > > procedure. > > " > > > > What is the purpose behind this? >=20 > [Med] This is an **optional** feature that was requested by the WG > participants to support an SFC distributed model (Ron may further > elaborate as he asked for it). For example, this feature allows a > classifier to bind flows as a function of the available paths and SF > instances. Then, packets can be bound to a fully or partially > constrained path accordingly. Also, the discovery information > provided to a classifier may be used for load distribution purposes. >=20 [Kyle] I didn't really think of that use-case. The load distribution one in= particular is interesting. I see the classifier as a mapper of packets to paths, so I've been thinking= of C1 as an interface for mapping packet information to paths. Mapping pac= kets to service functions and from there to paths seems like a higher level= concept. On the one hand, I think that keeping C1 purely about "packet -> = path" will lead to simpler protocols. On the other hand, to allow the use-c= ase you suggested, we'd need to add new interfaces, and as you've said belo= w, you don't really want to do that. But, I could ask this: if we constrain C1 to talk about only "packet -> pat= h", then it can probably be fairly well defined, and it should be easy to r= eason about. However, if we relax it to allow other information such as ser= vice functions just to support a few use-cases, why not relax it to allow a= ll information that could be relevant to SFC? I'm sure some smart people co= uld think of many use cases for that. Then again, as I say below, I could v= ery well just be approaching this document from the wrong perspective entir= ely,=20 > Of course, those cases may be implemented without involving the > classifier by invoking C2 as recorded in Section 3.3.2: >=20 > " This interface is also used by the SFF to report the > connectivity to > their attached (including embedded) SFs. Local means may be > enabled > between the SFC-aware SFs and SFFs to allow for the dynamic > attachment of SFs to an SFF and/or discovery of SFs by an SFF" >=20 >=20 > Given that the classifiers are not > > conceptually "attached" to SFs on the data plane, doesn't it seem > > wrong to have the classifiers be aware of the SFs on the control > plane? >=20 > [Med] See above. The idea is to allow for a distributed model to > adjust paths (and implement other policies at the classifier). >=20 > > I understand the classifiers may be co-located with SFs, but I > don't > > see how their functionality would, or should, depend on the > > availability of SFs in the data plane. >=20 > [Med] The SF/SFF discovery information is not MANDATORY to be > provided to a classifier, but may help in some deployment cases > (such as those mentioned above). >=20 > > > > One use-case I could see for this is having the classifier map a > > packet to an explicit set of SFs. However, the classifier maps > packets > > to paths, not SFs. Should the logic of mapping of packet to an SF > not > > be performed by conjoining C1 and C2 at the controller itself? >=20 > [Med] That's indeed possible. See the excerpt of Section 3.3.2 > provided above. >=20 > Using C1 to indicate SF > > mapping seems to blur the lines between C1 and C2. > > > > After writing the above, I saw section 4.10.2. It seems to kind of > > match what I proposed above. But, I still ask: is this truly the > > responsibility of the classifier, or something which may be co- > located > > with it? If the latter, should it not be a different interface? >=20 > [Med] Good point. We can always decompose a single interface into a > set of interfaces following some functional rationale, but the > reasons why I prefer to not add a new one are the following: > * Maintain the SFC control plane architecture as simple as possible. > * How a classifier decides to bind flows/packets to a given chain is > completely policy-based and deployment-specific. There may be simple > policies that do not require a feedback from the SFC-enabled domain > (e.g., blindly bind a flow to a chain based on the transport > coordinates) and advanced policies that require additional > information to be enforced (e.g., bind a flow to a chain as a > function of available paths, bind a flow to a chain as a function of > available SF instances, bind a flow to a chian while avoiding to > cross a given network region, etc.). >=20 [Kyle] I guess one of my challenges here is that I'm thinking as a protocol= developer, and I'm seeing stuff I would never want to put into my protocol= . So, maybe I just need to think of this from a different perspective. Rather= than saying what must or must not be in a protocol implementing C1, this d= ocument is just providing suggestions and things to think about? My concern is that if this is actually trying to put down requirements for = a set of protocols implement C1, a large number of optional requirements ar= en't really going to provide a lot of guidance.=20 > > > > > > Further, section 3.3.3 has an example of something belonging in > C1, > > but not C2: > > > > " SF execution status: Some SFs may need to send information > to the > > control plane to fine tune SFPs. For example, a threat- > detecting > > SF can periodically send the threat characteristics via this > > interface, such as high probability of threat with packet of a > > given size. The control plane can then add an appropriate > > matching criteria to SFF to steer traffic to a scrubbing > center." > > > > Should this information not be fed back to the classifier via C1, > > rather than C2? >=20 > [Med] It can of course! Please note that the text starts with "For > example, ". If the decision is to use a distinct service path, then > a classifier is likely to be invoked by means of C1. But if the > entity managing the SFC domain does not want to alter the service > path, a local policy can be provisioned to an SFF via C2 to redirect > subsequent packets to a scrubbing center. >=20 [Kyle] Is it not altering the path, though? It feels like we're just defini= ng a path through a sideways channel -- we're moving a packet to a path whi= ch isn't specified through the normal mechanisms. If it were specified norm= ally, I.e. through classify in C1, specify forwarding logic in C2, then the= SF could just reclassify the packet, or somehow indicate that it wants rec= lassification (for example, via metadata). This reclassification would not = alter the previous path of the packet, since the new path already existed. = In that case, C2 would just need to allow for indicating the information th= at would lead to reclassification, and the complex packet information neces= sary to do the classification could be transmitted in C1. Of course, perhap= s the information I'm suggesting being indicated in C2 is no less complicat= ed than what is being moved to C1. :) > I thought the classifier was supposed to be where complex > > matching logic runs, with the SFF being a simple forwarder. If we > > allow the SFF to run complex matching logic, (i.e. if this > condition, > > then take this next hop), is it not really acting as a classifier > or > > reclassifier? > > > > To be clear, RFC 7665 states: > > > > "A service function forwarder is > > responsible for forwarding traffic to one or more connected > > service functions according to information carried in the SFC > > encapsulation" > > > > I do not think that the packet size, for example, is a property of > the > > encapsulation. As such, I do not think C2 should carry this type > of > > information. >=20 > [Med] An SFF executes forwarding actions following the instructions > contained in its SFC Forwarding Policy Table. An SFF can forward > based on instructions that are compliant with its capabilities. The > CP is required to be aware of what an SFF is capable to do priori to > programming the forwarding table or to enable some protocols (e.g., > PCE). The draft is clear about this: >=20 > An SFF node may not support some of the matching criteria listed > above. It is important that SFC control plane can retrieve the > supported matching criteria by SFF nodes. >=20 > > > > Building on that point, section 4.10.4 states: > > > > "The matching criteria for SFF can be more sophisticated. For > > example, it could be the SFP-id carried within the SFC > encapsulation > > with any fields in the data packets, such as (non-exhaustive > list)" > > > > As with my comment in 3.3.3, I don't like the statement that any > field > > in the data packet can be used to qualify the next hop. It really > > should come entirely from the encapsulation. That encapsulation > > *could* very well be an IP header. However, we should be clear > about that. >=20 > [Med] This text was the result of WG discussion. As an editor of the > document, I can change the text as you propose if there is no > objection from the WG. [Kyle] I guess this point was a little bit of a nitpick, since I'm really c= omplaining about the language. I'd like to see it change to fit my interpre= tation of 7665. That said, if my interpretation is wrong, feel free to keep= it as is. >=20 > > > > Now, I could see using the information listed here to make a > decision > > as to which specific instance of an SF to send the packet to, for > > example when load-balancing. However, it does not seem correct to > > choose the next service function (e.g. Firewall vs content cache) > based packet data. > > > > I have a few more nits/concerns. I can send them in a separate > email > > thread once we've worked through this one. >=20 > [Med] Please share those. >=20 > > > > Thanks! > > > > Kyle From nobody Mon Jan 30 07:20:24 2017 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 9D92B1299C8 for ; Mon, 30 Jan 2017 07:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYjE46pLjG_I for ; Mon, 30 Jan 2017 07:20:17 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736E71294FD for ; Mon, 30 Jan 2017 07:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=864; q=dns/txt; s=iport; t=1485789616; x=1486999216; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vgoeOk7Po0CV15Flne9oMvjCfiUbM/DYnExEKdHRC6U=; b=C+U2SbrT07UdVVO6o8ufrexvsUVTHNFJX7ru7Uqa/7dugNw4B1AHQ2CO lZdBmLd0GbxpUqMfcqX7+T0teu8qUae6eONSkE3uscijkF1s/DoEKQdVB W26hp5GxJBj475WHxC/NbLBWZ5BpdVMgq303B1ldr8Os7FrX7v1dtXdEE Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AQBLWY9Y/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1OBageNV5FlH5UyggyGIgKCHT8YAQIBAQEBAQEBYh0LhGkBAQE?= =?us-ascii?q?DATo/BQsCAQgYHhAyJQEBBA4FiVkIrRCKdAEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R2GS4IFCIJihDkQgzSCEh8BBJtUAZF6gXmOfogmilgBHziBSxU7EAGGKHWHJoE?= =?us-ascii?q?MAQEB?= X-IronPort-AV: E=Sophos;i="5.33,312,1477958400"; d="scan'208";a="202163681" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jan 2017 15:19:49 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v0UFJnjh017674 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Jan 2017 15:19:49 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 30 Jan 2017 09:19:48 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Mon, 30 Jan 2017 09:19:48 -0600 From: "Paul Quinn (paulq)" To: "adrian@olddog.co.uk" Thread-Topic: Working copy of the NSH document Thread-Index: AdJ651ekvNrU0vNhQiK+1YBvcfm2PgAVz2mA Date: Mon, 30 Jan 2017 15:19:48 +0000 Message-ID: <01181999-06A5-4736-B166-BAA5E830E9FF@cisco.com> References: <008101d27ae7$be9eadf0$3bdc09d0$@olddog.co.uk> In-Reply-To: <008101d27ae7$be9eadf0$3bdc09d0$@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.131.118.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <5BC763E73F7B9D41B7A12494724F0A56@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Working copy of the NSH document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 15:20:18 -0000 Adrian, My understanding is that the chairs will send out: 1. A consolidated list of updates to go into the draft now (from the interi= m meeting, review of open tickets, prior comments on list, etc.). 2. A list of topics that require review from the list. Once we get #1, Uri and I will update the draft accordingly. Paul > On Jan 30, 2017, at 5:58 AM, Adrian Farrel wrote: >=20 > Hi Paul, >=20 > I know that a number of additional updates were discussed in Westford, bu= t I > wonder whether you could post a working copy of the NSG document so that = we have > something slightly more recent and complete to work with. >=20 > I suppose I might be able to take the current revision and the issue trac= ker and > work out what the working copy would say, but I'm not confident. >=20 > Thanks, > Adrian >=20 From nobody Mon Jan 30 08:06:13 2017 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 B4F5A129516 for ; Mon, 30 Jan 2017 08:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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, 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 oAiBubVhfd4g for ; Mon, 30 Jan 2017 08:06:11 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1BB12947C for ; Mon, 30 Jan 2017 08:06:11 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0UG67h6023096; Mon, 30 Jan 2017 16:06:07 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0UG64Qe023084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jan 2017 16:06:06 GMT From: "Adrian Farrel" To: "'Paul Quinn \(paulq\)'" References: <008101d27ae7$be9eadf0$3bdc09d0$@olddog.co.uk> <01181999-06A5-4736-B166-BAA5E830E9FF@cisco.com> In-Reply-To: <01181999-06A5-4736-B166-BAA5E830E9FF@cisco.com> Date: Mon, 30 Jan 2017 16:06:01 -0000 Message-ID: <007601d27b12$c31de5f0$4959b1d0$@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: AQJnOXfJC1Jpw6VuhMsajqnZftpx/QG0d+00oBoNnvA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22856.001 X-TM-AS-Result: No--21.595-10.0-31-10 X-imss-scan-details: No--21.595-10.0-31-10 X-TMASE-MatchedRID: IO9f4z4hIxDZeYBBoew7AFu4M/xm4KZewFk84lhmgzwujyxRHwe+HG9R uGHAYhMzBqOg8gOgqV7ZAk9mMv+VwXsQZsIG1c2HriWRB2x/Qjot0t+aIVLt+9itWyC5FGcAbF3 /GdZWzzxNYvDaO9t+nGrcWZAmT5/4XElnxg+tc0GvPooS+PUQchmyTBaqiJvcut/GVGOoEncclY FS9brCb9CRUJcyCDyyR13It5oba0+6zsztxuMjKJpWgCLYjjT99r9tEcSw8jdBDVeC8J7uwYxFH wCy/E6mOeAtlLPUOAZpykTUaVN5SxgHZ8655DOPOX/V8P8ail1bCjvvWZW+Sabj/c4OO+6RKrau Xd3MZDUD/dHyT/Xh7Q== Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] Working copy of the NSH document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 16:06:12 -0000 Thanks Paul, I appreciate the work you're doing (and committing to do) to move this draft forward. It's just that it is frankly hellishly difficult for anyone to review or implement NSH at the moment. I have raised several comments over the months and been told "these are already addressed in the working copy of the text" which is good to know, but basically no help to me. I'm not asking for a perfect copy, or one that already includes every discussed change coming from the interim, just something a little more recent that the 9/20 revision. I don't care if it fails idnits, or is badly formatted, just squirt out the working copy so the WG can see the progress. Thanks, Adrian > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com] > Sent: 30 January 2017 15:20 > To: adrian@olddog.co.uk > Cc: sfc@ietf.org > Subject: Re: Working copy of the NSH document > > Adrian, > > My understanding is that the chairs will send out: > > 1. A consolidated list of updates to go into the draft now (from the interim > meeting, review of open tickets, prior comments on list, etc.). > 2. A list of topics that require review from the list. > > Once we get #1, Uri and I will update the draft accordingly. > > Paul > > > On Jan 30, 2017, at 5:58 AM, Adrian Farrel wrote: > > > > Hi Paul, > > > > I know that a number of additional updates were discussed in Westford, but I > > wonder whether you could post a working copy of the NSG document so that > we have > > something slightly more recent and complete to work with. > > > > I suppose I might be able to take the current revision and the issue tracker and > > work out what the working copy would say, but I'm not confident. > > > > Thanks, > > Adrian > > From nobody Mon Jan 30 08:46:09 2017 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 F2790129506 for ; Mon, 30 Jan 2017 08:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 Jh6ynXACwnZb for ; Mon, 30 Jan 2017 08:46:06 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 1FF8F12952B for ; Mon, 30 Jan 2017 08:46:06 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id t8so219375550vke.3 for ; Mon, 30 Jan 2017 08:46:06 -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=d386NnMHt/Ng9mgViL612wa8a8B2WHOfYWCK7TjuugM=; b=EbYlTPoW6QCQgbftyHK12/pnyptsXbMRUr6rRoypQ7lJJXJSjEwYktgm4lTFYiGZIQ xIPAG2b++f+Zbm1+pPaXvLqT3pnns4znql+p0EybuehNDeMxoTh7LNITJmxG4b86evWz 0WqZnQORFm7Ybgesi+KoDyRd7FH8dhBspUiA2zBGo7mzOjIrM/G2AqBxVMdPOloYpKYL hlTJ999IWWWSd/4sfeUdFzdpTziI37UvnxghFFpkOFe3rybB5sEK5009kQcG5UtJYhdo aVwK2Ati4uTLJRrT8LjPTG2xgK5iyMDtdQd2rkyFgDUMQ8BdEvih8GXHLlIO+9CMAcTw YQyw== 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=d386NnMHt/Ng9mgViL612wa8a8B2WHOfYWCK7TjuugM=; b=lG/C8XefdcQhK3ZSLsxYUvyfLAzlWWUepcbQM4sP/7WPpAIahWLdZVmBoM3uZMGeL3 QPcV7U2si4Qit47NSbQLev/1IUcSxJBYMTBYAnZ7RgJZNUl6nVb5IGD4+tpZJCHZpQUz McFc+D39FdCrEXSsfXTf6g0tMKW8pzQv2Yia73aCc/pXWFOxrtgeF9ixBQ6P40G8CNkp LYF/HY8lgM82IHynxSbfmmonfrxh5m+WrWtjAAQ4F8P716jKDdCebSNHnUoR9+lBttbB lQkY1Fm4aeXlX1jXHzPeC+tFLrkzs40tA3mgA4QHOiNY/UTg7ETH2zDVUcdVgCkT5R54 Wv8A== X-Gm-Message-State: AIkVDXIiyo4H/KclxwS2IwXHc1VWMXTwpFCUabb9EH1EbJHHNrFqyKuYo+tPizWr8X/4x7wmFSSV9UkCKLEpYw== X-Received: by 10.31.92.1 with SMTP id q1mr8824934vkb.151.1485794765162; Mon, 30 Jan 2017 08:46:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.144.209 with HTTP; Mon, 30 Jan 2017 08:46:04 -0800 (PST) In-Reply-To: <008101d27ae7$be9eadf0$3bdc09d0$@olddog.co.uk> References: <008101d27ae7$be9eadf0$3bdc09d0$@olddog.co.uk> From: Jim Guichard Date: Mon, 30 Jan 2017 11:46:04 -0500 Message-ID: To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=001a114e2b6e2fd1de0547528d6b Archived-At: Cc: Paul Quinn , sfc@ietf.org Subject: Re: [sfc] Working copy of the NSH document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 16:46:08 -0000 --001a114e2b6e2fd1de0547528d6b Content-Type: text/plain; charset=UTF-8 Hi Paul/Uri, Several additional updates were discussed at the interim but they are not agreed upon by the WG at this point. However, there are several changes that should be made now as previously agreed by the WG: 1. Update the document as per https://trac.ietf.org/trac/sfc/ticket/22 2. Update the document as per https://trac.ietf.org/trac/sfc/ticket/21 3. Reference [nsh-security-requirements] in section 9 paragraph 1 has no corresponding reference in section 13.2. Please fix this. 4. Remove reference [nsh-sec] from section 9 paragraph 5 as it references an expired draft. Please make these changes and publish an updated NSH document. Thanks! Jim & Joel On Mon, Jan 30, 2017 at 5:58 AM, Adrian Farrel wrote: > Hi Paul, > > I know that a number of additional updates were discussed in Westford, but > I > wonder whether you could post a working copy of the NSG document so that > we have > something slightly more recent and complete to work with. > > I suppose I might be able to take the current revision and the issue > tracker and > work out what the working copy would say, but I'm not confident. > > Thanks, > Adrian > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --001a114e2b6e2fd1de0547528d6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul/Uri,

Several additional updates= were discussed at the interim but they are not agreed upon by the WG at th= is point. However, there are several changes that should be made now as pre= viously agreed by the WG:

1. Update the document a= s per https://trac.iet= f.org/trac/sfc/ticket/22
2. Update the document as per=C2=A0<= a href=3D"https://trac.ietf.org/trac/sfc/ticket/21">https://trac.ietf.org/t= rac/sfc/ticket/21
3. Reference [nsh-security-requirements] in= section 9 paragraph 1 has no corresponding reference in section 13.2. Plea= se fix this.
4. Remove reference [nsh-sec] from section 9 paragra= ph 5 as it references an expired draft.

Please mak= e these changes and publish an updated NSH document.

Thanks!

Jim & Joel

On Mon, Jan 30, 2017 at 5:58 A= M, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi Paul,

I know that a number of additional updates were discussed in Westford, but = I
wonder whether you could post a working copy of the NSG document so that we= have
something slightly more recent and complete to work with.

I suppose I might be able to take the current revision and the issue tracke= r and
work out what the working copy would say, but I'm not confident.

Thanks,
Adrian

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

--001a114e2b6e2fd1de0547528d6b-- From nobody Mon Jan 30 12:29:29 2017 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 6EDA0129BB7 for ; Mon, 30 Jan 2017 12:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.719 X-Spam-Level: X-Spam-Status: No, score=-17.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2RW2xMfa2Ei for ; Mon, 30 Jan 2017 12:29:25 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB943129BB6 for ; Mon, 30 Jan 2017 12:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5419; q=dns/txt; s=iport; t=1485808165; x=1487017765; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yj8C1338/lZNBhbtnJARCAOxOZFZjmUVTDBboyawpfo=; b=bxBdtjvXiBEM6rbyiR3+m4ldox19L0WaxMluNgDc/SUrNj4t7rIsAzlP Glh0yjZJyx/0gMquONP5fJHVpzpaFVA+Y6droqpe0Elq1W/BCpHT5Kzmh /hgmTUkC8zHKNRDg59qIQrrVEnoeh3i4j2FYN6qoxeQhSNjQZFrrczX85 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAQB+oY9Y/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQkHjVeRZYgoh36FK4IMHwEKhXgCgiY/GAECAQEBAQEBAWI?= =?us-ascii?q?ohGoCBAEBbAsQAgEIDjEHIQYLFBEBAQQOBYlJAxUOrVyHNA2DVAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhkuCBQiCYoJRgWiDRIISHwWIeod9hEmFXDgBhmaHA4Q?= =?us-ascii?q?RCoFvhRWJaYgmggGIVwEfOIFLFTsQAYNzOByBYXWHJoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,312,1477958400"; d="scan'208,217";a="205316978" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2017 20:29:24 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v0UKTOpZ014209 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Jan 2017 20:29:24 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 30 Jan 2017 14:29:24 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Mon, 30 Jan 2017 14:29:24 -0600 From: "Paul Quinn (paulq)" To: Jim Guichard Thread-Topic: [sfc] Working copy of the NSH document Thread-Index: AdJ651ekvNrU0vNhQiK+1YBvcfm2PgAY0tgAAAfMdQA= Date: Mon, 30 Jan 2017 20:29:24 +0000 Message-ID: References: <008101d27ae7$be9eadf0$3bdc09d0$@olddog.co.uk> 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.131.118.71] Content-Type: multipart/alternative; boundary="_000_E01496D5161D4349B5F839A1AE42DA26ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "adrian@olddog.co.uk" , "sfc@ietf.org" Subject: Re: [sfc] Working copy of the NSH document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 20:29:27 -0000 --_000_E01496D5161D4349B5F839A1AE42DA26ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you Jim. Expect to see an update by mid next week. Paul On Jan 30, 2017, at 11:46 AM, Jim Guichard > wrote: Hi Paul/Uri, Several additional updates were discussed at the interim but they are not a= greed upon by the WG at this point. However, there are several changes that= should be made now as previously agreed by the WG: 1. Update the document as per https://trac.ietf.org/trac/sfc/ticket/22 2. Update the document as per https://trac.ietf.org/trac/sfc/ticket/21 3. Reference [nsh-security-requirements] in section 9 paragraph 1 has no co= rresponding reference in section 13.2. Please fix this. 4. Remove reference [nsh-sec] from section 9 paragraph 5 as it references a= n expired draft. Please make these changes and publish an updated NSH document. Thanks! Jim & Joel On Mon, Jan 30, 2017 at 5:58 AM, Adrian Farrel > wrote: Hi Paul, I know that a number of additional updates were discussed in Westford, but = I wonder whether you could post a working copy of the NSG document so that we= have something slightly more recent and complete to work with. I suppose I might be able to take the current revision and the issue tracke= r and work out what the working copy would say, but I'm not confident. Thanks, Adrian _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_E01496D5161D4349B5F839A1AE42DA26ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7606BFC087B2A94D81DC5E4CFA01A07D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Thank you Jim.  Expect to see an  update by mid next week.

Paul


On Jan 30, 2017, at 11:46 AM, Jim Guichard <jguichard1966@gmail.com> w= rote:

Hi Paul/Uri,

Several additional updates were discussed at the interim bu= t they are not agreed upon by the WG at this point. However, there are seve= ral changes that should be made now as previously agreed by the WG:

1. Update the document as per https://trac.ietf.org/trac/sfc/ticket/22
2. Update the document as per https://trac.ietf.org/trac/sfc/tick= et/21
3. Reference [nsh-security-requirements] in section 9 parag= raph 1 has no corresponding reference in section 13.2. Please fix this.
4. Remove reference [nsh-sec] from section 9 paragraph 5 as= it references an expired draft.

Please make these changes and publish an updated NSH docume= nt.

Thanks!

Jim & Joel

On Mon, Jan 30, 2017 at 5:58 AM, Adrian Farrel <= span dir=3D"ltr" class=3D""> <adr= ian@olddog.co.uk> wrote:
Hi Paul,

I know that a number of additional updates were discussed in Westford, but = I
wonder whether you could post a working copy of the NSG document so that we= have
something slightly more recent and complete to work with.

I suppose I might be able to take the current revision and the issue tracke= r and
work out what the working copy would say, but I'm not confident.

Thanks,
Adrian

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/lis= tinfo/sfc


--_000_E01496D5161D4349B5F839A1AE42DA26ciscocom_-- From nobody Mon Jan 30 12:40:37 2017 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 ABFAE1295C0 for ; Mon, 30 Jan 2017 12:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLOcBB4qdWoF for ; Mon, 30 Jan 2017 12:40:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19E11295E2 for ; Mon, 30 Jan 2017 12:40:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZS90871; Mon, 30 Jan 2017 20:40:24 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 30 Jan 2017 20:40:22 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Mon, 30 Jan 2017 12:40:05 -0800 From: James N Guichard To: "sfc@ietf.org" Thread-Topic: SFC Interim Meeting on 1/17-19 2017 - Preliminary meeting minutes Thread-Index: AdJ7ODe85GhjUlemRvq8kIifCAtD/A== Date: Mon, 30 Jan 2017 20:40:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.211] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB24C0SJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.588FA4B9.0030, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bf2abc99adb59f210760ebef5c47a74d Archived-At: Subject: [sfc] SFC Interim Meeting on 1/17-19 2017 - Preliminary meeting minutes X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 20:40:36 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB24C0SJCEML701CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings WG, A big thank you from the chairs for those that were able to attend our SFC = WG interim meeting. We covered a *lot* of ground. Please find preliminary meeting minutes as follows. For those that attended= the meeting, please unicast corrections to the chairs: Attendees: Adrian Farrell; Alia Atlas; Andrew G. Malis; Dave Dolson; Don F= edyk; Eric C Rosen; Ignas Bagdoues; Jim Guichard; Joel M. Halpern; Lucy Yon= g; Mohamed Boucadair; Paul Quinn; Ron Parker; Tal Mizrahl. Remote Attendees: Greg Mirsky; John Drake; Linda Dunbar; Behcet Sarikaya; I= gor Bryskin; Roberta Maglione; Xufeng Liu. A. NSH document discussion: WG chairs have collected several changes that have already been agreed upon= by the WG. These changes have been communicated to the NSH document editor= s (as well as email to the WG list and updates made to the associated ticke= ts) and will be reflected in an upcoming version of the document. WG chairs= have asked the editors to publish this updated version of the document ASA= P so that it can be used as the baseline for adding further changes agreed = upon at the interim meeting (assuming WG consensus is reached). C bit discussion: Extensive discussion on the c bit in NSH base header and c bit in TLV. * Summary: Agreement that the value in the c-bit was in forcing pa= ckets to be dropped by SFF who would otherwise ignore the metadata. The co= st is that all SFF along the path would need to examine the metadata. As w= e have no use case mandating such a discard, we decided that the cost was n= ot something we needed, and agreed to drop the bit. * Room consensus: 1. Remove the c bit from the NSH base header, returning the bit to "r= eserved" status .1.1. Section 3.2 figure and associated c bit text .1.2. Section 3.4 figure .1.3. Section 3.5 figure 2. Remove the c bit from the variable-length metadata header, making = the Type an 8-bit field. .2.1. Section 3.5.1 figure and associated text 3. Remove text "and where needed to mark that data as critical" from= section 9 'Security Considerations' 4. Remove c bit from section 12.2.1 * Dave Dolson will send a proposal about removing c bit in the NSH = base header and c bit in TLV to the SFC WG mailing list. NSH base header length discussion: Discussion on the length field within the NSH base header. * Current text in section 3.2 of the NSH document has an issue. The= last sentence of the length description currently reads "The length field = indicates the "end" of NSH and where the original packet/frame begins". Dis= cussion around hierarchical NSH showed that there are cases where the end o= f the NSH base header and context headers may not be the beginning of the o= riginal packet/frame. Therefore a textual change is necessary to make it cl= ear that the length field indicates the beginning of the packet/frame of th= e next protocol reflected in the NSH base header. * WG chairs will send a proposal to the SFC WG mailing list to get = consensus on the necessary textural changes to the NSH document. NSH base header discussion: Discussion around which of the NSH headers are mandatory and which are not. * Current text in section 3.1 for the NSH header format does not in= dicate which of the headers are mandatory which is confusing and a request = was made to clarify this within the document. * Adrian Farrel will send a proposal to the SFC WG mailing list for= clarifying changes to section 3.1 of the NSH document. SFC Loop Detection discussion: * Lucy presented SFF loop prevention proposal. Adrian raised anothe= r loop case: reclassification may cause a loop too. Should use one solution= to address all loops at the service plane level. * SI can be used for some loop detection; should not change that. J= ust need a solution to detect SFF loop and reclassify loop cases. * Discussed various possible solutions. Proposal to use 6 reserved = bits from the NSH base header for TTL, and allocate some bits from MD type = field as reserved field. * Use of MD type field as TTL was raised. Not adopted. * Some concerns were raised about introducing the TTL field, and ho= w it will interoperate with pre-standard implementations. Two proposals tha= t can potentially mitigate these concerns were discussed: 1. Make the TTL optional. 2. Define a new version number. The room consensus was that both proposals are not a good idea. * Backward compatibility concern may be described in NSH appendix. = NSH is not RFC yet, BC is a bit concern but should not be a stopper. * Consider TTL usage for OAM purpose. Copy the TTL value is bad. Co= nsider other solution. * After much discussion, the room settled on a two part proposal. 1. Use the six currently reserved flag bits as a 6 bit TTL field. Ex= act processing rules need to be agreed by the WG, but roughly "decrement ev= erywhere". (Issues such as count up or count down, do SFF decrement on eve= ry reception, etc., to be discussed and resolved using a specific proposal.= ) 2. The upper bits (number to be determined) to be reserved for flag b= its. The interaction of this with implementations of the earlier specifica= tion to be discussed in a document appendix. * It is not clear when receiving a NSH packet, if SF does not suppo= rt the MD type, what to do. * WG Chairs and document editors to go through NSH document to clar= ify the process rules for SFC component to receive an NSH packet, including= SFF, SF, reclassifier, especially if a field value is not understood. SI value process discussion: * Make this explicitly in NSH "SI decremented by 1" * Handling non-contiguous decrement value, SFF set the value based = on forwarding table, etc.; no consensus on this suggestion. Other discussion results are reflected in the action items. Summary of action Items for NSH document: 1. Proposal to remove c bit in the NSH base header and c bit in TLV. = AI: Dave Dolson to send proposal to the SFC WG mailing list (Status: Done). 2. Length in NSH base header text correction. AI: WG chairs to send p= roposal to the SFC WG mailing list (Status: Open). 3. Clarify which NSH headers are mandatory. AI: Adrian Farrel to send= proposal to the SFC WG mailing list (Status: Done). 4. SFC loop prevention solution. Proposal for 6 reserved bits for TTL= , take some bits (2 or 3?) from the MD type field and make them reserved bi= ts. AI: WG chairs (or someone else) to send proposal to the SFC WG mailing = list (Status: Open) 5. "SI decremented by 1" explicitly in the NSH document. AI: WG chair= s to send mail to the SFC WG mailing list with proposal (Status: Open). 6. Make MD#2 with length 2 mandatory, and MD#2 length > 2 is optional= . AI: Adrian Farrel to send proposal to the SFC WG mailing list (Status: Op= en). 7. Next protocol list (IANA registry) needs to align with other WGs s= uch as NVO3 (will be chair/AD's work) 8. Next protocol can have a NULL value, Adrian and Lucy will have a s= eparate draft to specify the use of NULL value. AI: Adrian/Lucy to publish = draft (Status: Done). 9. Correction on Registry for MD Class: MD class code point 0 for IET= F, 1-xxxx for IETF review. All IETF specified types will use IETF code poin= t. If 3gpp define a set of types and ask code point from IETF; IETF will a= llocate code point from IETF review range. 10. IANA needs a TLV type registry for MD class 0, i.e. IETF. Should this= registry be specified in NSH document, or nsh-tlv document? Go on mailing = for consensus. 11. Clarify all process rules for SFC component to receive a NSH packet, = including SFF, SF, reclassifier, especially the rule if a field value in NS= H header is not understood. AI: WG chairs/NSH document editors to review N= SH document for clarity (Status: Open). 12. Some changes for NSH document for MD 1&2 are listed in MD discussion= (below) B. Security Environment document discussion: Discussion centered on draft-mglt-sfc-security-environment-req-02 document = and whether it satisfies the needs of the SFC WG. * The document needs to tailor for SFC specific environmental secur= ity, not general security requirements or SFC protocol security requirement= s. It can reference some existing security documents for non-SFC part such = as RFC4778 and RFC5949. * Room consensus: anything that is SFC specific protocol security r= equirement should be removed from draft-mglt-sfc-security-environment-req. * Discussion on whether the WG needs a separate SFC protocol securi= ty requirements document. An expired document exists (draft-reddy-sfc-nsh-s= ecurity-req) and the room discussed whether that document should be resurre= cted or should the protocol specific requirements be folded into the NSH do= cument. * Room agreement to move the relevant portions of this document to = specific documents where it applies. Then to re-examine the remainder to s= ee if there is a useful document for further work. Summary of action items for security discussion: 1. Chairs to email the SFC WG mailing list to get consensus on whethe= r a standalone SFC protocol security requirements document should be worked= on or should said requirements be folded into the relevant individual docu= ments. AI: WG chairs (Status: Open). 2. Security considerations in NSH document should fix citation issue:= [SFC security requirements] has no reference and [nsh-sec] is expired. AI= : NSH document editors to fix (Status: Open). C. OAM discussion: Discussion centered on how to move OAM work forward in the SFC WG and how t= o align with the common OAM approach being worked in NVO3. * Seek common approach of OAM for overlay. NVO3 support this approa= ch. * Value to support both In-situ, and conventional OAM but focus fir= st on conventional OAM. * Need to specify OAM requirement first, not the solution. * Priority: Finishing NSH is important to WG. Get basic OAM work fi= rst. * O bit, next protocol, metadata are all related to OAM operation. = Regardless what OAM solution is adopted eventually, checking o bit in base = header gives the great benefit for NSH moving ahead without depending on an= y OAM approach, in which the worst case is to have some redundant process f= or OAM, e.g. check O bit and next protocol. * Room + plus Greg Mirsky consensus: O bit to indicate OAM message = exists on NSH packet. NSH does not need to specify any OAM function except = O bit. Take the expired OAM framework draft (draft-ietf-sfc-oam-framework-0= 1) and use it to develop the OAM requirements. This document has been dorma= nt for a while and was previously adopted as a WG document but with no move= ment since adoption. Summary of action items from OAM discussion: 1. WG chairs will chase some folks to work on OAM framework draft. (N= o change to NSH draft). AI: WG chairs (Status: Open) D. Control plane requirements document discussion: Discussion on the current control plane requirements document draft-ietf-sf= c-control-plane-08. * Concerns have been expressed from several quarters that attemptin= g to use this document to guide protocol development (or implementation) of= control functionality is quite challenging. * This led to discussion of the target audience and purpose of the = document. * Discussion of what is actually need regarding the control plane r= equirements for current WG work, for future expected WG work, for protocol = designers in other working groups, for implementers, and for readers in the= future. And how to provide the needed information. * Without this document, will it cause interoperability concerns? Y= es, the control plane may contain multiple protocols, BGP is only one of th= em. Concern is that we don't know what features each protocol should cover.= Grouping will help. * Interface Information must be provided to define interoperable in= terfaces. This does not mean that a full data model is needed. * Current document may be limited by WG charter. * It is clear that there is work to be done here. However not clear= what to be done yet. Need some regrouping the requirements to make more u= seful for the control plane development? * Chair: question to room: will SFC arch and NSH doc. be sufficient= for SFC control plane implementation? If yes, we do not need to work on co= ntrol plane requirements. No consensus on chair's question. E. MD-1 discussion * Control plane needs to inform SFC components the MD-1 format per = SPI. * Publishing MD-1 formats for common use case is useful. * Lucy presented two possible ways for the control plane to inform = the data plane elements of the MD#1 format. WG will not mandate a particula= r way. * Discussion of whether a registry of MD-1 formats would be useful.= Room concluded that there is no need to create a registry and assign code= point for each published MD-1 format now. In future a control plane proto= col may request a registry for identify individual format for the protocol = to use. * SFC allows changing MD-1 format to MD-2 on a SFP or vice versa. C= urrent document has not yet made this clear. * A MD-1 format is not relevant to NSH protocol. However, it was as= ked if the MD-1 format may change along the SFP. NSH doc. needs to clarify= MD-1 format granularity. The WG needs to decide what it wants in this reg= ard. Room consensus: * Publish MD-1 formats for common use cases as informational RFCs. * Allow changing MD-1 format to MD-2 in a SFP or vice versa. * Get WG consensus the granularity of MD-1 format, 1) per SPI; 2) p= er SPI and hop; etc. (current is per SPI). Once reach consensus, update NSH= doc in section 3.4, Section 4, and figure 8 to reflect the consensus. The = MD-1 granularity will clarify what control plane and SFC components can be. Action items: 1. NSH doc. clarifies that changing MD-1 format to MD-2 in or a SFP o= r vice versa is allowed. 1. Update NSH to reflect the WG consensus on MD-1 granularity (see MD= -1 room consensus). F. MD-2 discussion * SFC needs to specify the processing rules but not all processes. = I.e. the TLV definitions need to provide enough meaning for the particular = TLVs that entities can make use of them. But internal or back end processi= ng logic is not for SFC or an SFC Metadata TLV registry to mandate. * It was observed that the current common TLV document does not hav= e enough description for some of the TLVs. Folks should provide comments to= the WG on where they would like to see more elaboration. Preferably with = proposed text. * It was also discussed that some TLVs are better explained in thei= r own documents. Particularly if the document exists for another reason, o= r if lengthy explanation is useful for some TLV (or set of TLVs. After dis= cussion, it was agreed that the common base document can and should be used= for TLVs we currently know of that need short descriptions. TLVs which fi= t naturally in some other document can and should be defined in those docum= ents. * For example, the documents defining MD-1 formats can also define = a MD-2 Type code for carrying the same block of information with the same s= tructure. * Need to consider a way for vendor to create own MD-1 format, prep= aratory one. This is not clearly covered now. Room Consensus: * The TLVs with short explanations belong to common TLV doc.; other= doc. may define the TLV needing more semantics for a use case. In particul= ar, there is no point in an entry in the common document whose only text is= "see WFC document X for structure and meaning of this TLV." In that case,= document X should reserve the type code. Action item: 1. Editors to remove inappropriate entries 2. WG to work out mechanism for vendors to create their own MD-2 type= codes. G. Transport related discussion * SFC arch are transport agnostic. However, SFC architecture has so= me requirements on transport behavior such as ECMP, data plane length, etc. * SFC arch made some assumption on transport. We should document th= ese assumptions and requirements. Transport requirement work should be don= e in this WG. Homing for transport solution work to be resolved on a case b= y case basis, with care to avoid overload. Room Consensus: * Chairs needs to work with other WG on Transport requirement and b= ehavior. Action Item: 1. SFC WG work on transport requirement document. Yours, Jim & Joel --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB24C0SJCEML701CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings WG,

 

A big thank you from the chairs for those that were = able to attend our SFC WG interim meeting. We covered a *lot* of gro= und.

 

Please find preliminary meeting minutes as follows. = For those that attended the meeting, please unicast corrections to the chai= rs:

 

Attendees:  Adrian Farrell; Alia Atlas; Andrew G= . Malis; Dave Dolson; Don Fedyk; Eric C Rosen; Ignas Bagdoues; Jim Guichard= ; Joel M. Halpern; Lucy Yong; Mohamed Boucadair; Paul Quinn; Ron Parker; Ta= l Mizrahl.

 

Remote Attendees: Greg Mirsky; John Drake; Linda Dunb= ar; Behcet Sarikaya; Igor Bryskin; Roberta Maglione; Xufeng Liu.=

 

A.      NSH document discuss= ion:

 

WG chairs have collected several changes that have al= ready been agreed upon by the WG. These changes have been communicated to t= he NSH document editors (as well as email to the WG list and updates made t= o the associated tickets) and will be reflected in an upcoming version of the document. WG chairs have asked = the editors to publish this updated version of the document ASAP so that it= can be used as the baseline for adding further changes agreed upon at the = interim meeting (assuming WG consensus is reached).

 

C bit discussion:

Extensive discussion on the c bit in NSH base header = and c bit in TLV.  

·         Summary:  Agreement that the value in t= he c-bit was in forcing packets to be dropped by SFF who would otherwise ig= nore the metadata.  The cost is that all SFF along the path would need= to examine the metadata.  As we have no use case mandating such a discard, we decided that the cost was not something = we needed, and agreed to drop the bit. 

·         Room consensus:

1.       Remove the c bit from the NSH base header, returnin= g the bit to “reserved” status

.1.1.      &= nbsp;           &nbs= p;    Section 3.2 figure and associated c bit text

.1.2.      &= nbsp;           &nbs= p;    Section 3.4 figure

.1.3.      &= nbsp;           &nbs= p;    Section 3.5 figure

2.       Remove the c bit from the variable-length metadata = header, making the Type an 8-bit field.

.2.1.      &= nbsp;           &nbs= p;    Section 3.5.1 figure and associated text=

3.        Remove text “and where needed to mark t= hat data as critical” from section 9 ‘Security Considerations&#= 8217;

4.        Remove c bit from section 12.2.1

·         Dave Dolson will send = a proposal about removing c bit in the NSH base header and c bit in TLV to = the SFC WG mailing list.

 

NSH base header length discussion:

Discussion on the length field within the NSH base he= ader.

·         Current text in section 3.2 of the NSH docum= ent has an issue. The last sentence of the length description currently rea= ds “The length field indicates the “end” of NSH and where= the original packet/frame begins”. Discussion around hierarchical NSH showed that there are cases where the end of the NSH base= header and context headers may not be the beginning of the original packet= /frame. Therefore a textual change is necessary to make it clear that the l= ength field indicates the beginning of the packet/frame of the next protocol reflected in the NSH base header.=  

·         WG chairs will send a proposal to the SFC WG= mailing list to get consensus on the necessary textural changes to the NSH= document.

 

NSH base header discussion:

Discussion around which of the NSH headers are mandat= ory and which are not.

·         Current text in section 3.1 for the NSH head= er format does not indicate which of the headers are mandatory which is con= fusing and a request was made to clarify this within the document.

·         Adrian Farrel will send a proposal to the SF= C WG mailing list for clarifying changes to section 3.1 of the NSH document= .

 

SFC Loop Detection discussion:

·         Lucy presented SFF loop prevention proposal.= Adrian raised another loop case: reclassification may cause a loop too. Sh= ould use one solution to address all loops at the service plane level.=

·         SI can be used for some loop detection; shou= ld not change that. Just need a solution to detect SFF loop and reclassify = loop cases.

·         Discussed various possible solutions. Propos= al to use 6 reserved bits from the NSH base header for TTL, and allocate so= me bits from MD type field as reserved field.

·         Use of MD type field as TTL was raised. = ; Not adopted.

·         Some concerns were raised about introducing = the TTL field, and how it will interoperate with pre-standard implementatio= ns. Two proposals that can potentially mitigate these concerns were discuss= ed:

1.       Make the TTL optional.  

2.       Define a new version number.

The room consensus was tha= t both proposals are not a good idea.

·         Backward compatibility concern may be descri= bed in NSH appendix.  NSH is not RFC yet, BC is a bit concern but shou= ld not be a stopper.

·         Consider TTL usage for OAM purpose. Copy the= TTL value is bad. Consider other solution.

·         After much discussion, the room settled on a= two part proposal.

1.       Use the six currently reserved flag bits as a 6 bit= TTL field.  Exact processing rules need to be agreed by the WG, but r= oughly “decrement everywhere”.  (Issues such as count up o= r count down, do SFF decrement on every reception, etc., to be discussed and resolved using a specific proposal.)

2.       The upper bits (number to be determined) to be rese= rved for flag bits.  The interaction of this with implementations of t= he earlier specification to be discussed in a document appendix.=

·         It is not clear when receiving a NSH packet,= if SF does not support the MD type, what to do.

·         WG Chairs and document editors to go through= NSH document to clarify the process rules for SFC component to receive an = NSH packet, including SFF, SF, reclassifier, especially if a field value is= not understood.

 

SI value process discussion:

·         Make this explicitly in NSH “SI decrem= ented by 1”

·         Handling non-contiguous decrement value, SFF= set the value based on forwarding table, etc.; no consensus on this sugges= tion.

 

Other discussion results are reflected in the action = items.

 

Summary of action Items for NSH document:<= /p>

 <= /p>

1.     &= nbsp; Proposal to remove c bit in the NSH base header and= c bit in TLV. AI: Dave Dolson to send proposal to the SFC WG mailing list = (Status: Done).

2.     &= nbsp; Length in NSH base head= er text correction. AI: WG chairs to send proposal to the SFC WG mailing li= st (Status: Open).

3.     &= nbsp; Clarify which NSH heade= rs are mandatory. AI: Adrian Farrel to send proposal to the SFC WG mailing = list (Status: Done).

4.     &= nbsp; SFC loop prevention sol= ution. Proposal for 6 reserved bits for TTL, take some bits (2 or 3?) = from the MD type field and make them reserved bits. AI: WG chairs (or someo= ne else) to send proposal to the SFC WG mailing list (Status: Open)

5.     &= nbsp; “SI decremented b= y 1” explicitly in the NSH document. AI: WG chairs to send mail to th= e SFC WG mailing list with proposal (Status: Open).

6.     &= nbsp; Make MD#2 with length 2= mandatory, and MD#2 length > 2 is optional. AI: Adrian Farrel to send p= roposal to the SFC WG mailing list (Status: Open).

7.     &= nbsp; Next protocol list (IAN= A registry) needs to align with other WGs such as NVO3 (will be chair/AD= 217;s work)

8.     &= nbsp; Next protocol can have = a NULL value, Adrian and Lucy will have a separate draft to specify the use= of NULL value. AI: Adrian/Lucy to publish draft (Status: Done).

9.     &= nbsp; Correction on Registry = for MD Class: MD class code point 0 for IETF, 1-xxxx for IETF review. All I= ETF specified types will use IETF code point.  If 3gpp define a set of= types and ask code point from IETF; IETF will allocate code point from IETF review range.

10.   IANA needs a TLV type r= egistry for MD class 0, i.e. IETF. Should this registry be specified in NSH= document, or nsh-tlv document? Go on mailing for consensus.

11.   Clarify all process rules for SFC component to rece= ive a NSH packet, including SFF, SF, reclassifier, especially the rule if a= field value in NSH header is not understood.  AI: WG chairs/NSH docum= ent editors to review NSH document for clarity (Status: Open).

12.    Some changes for NSH document for MD 1&2 = are listed in MD discussion (below)  =           

 <= /p>

B.      Security Environment= document discussion:

 <= /p>

Discussion centered on draft-mglt-sfc-security-environment-req-02 document and whether it satisfie= s the needs of the SFC WG.

 

·         The document needs to tailor for SFC specifi= c environmental security, not general security requirements or SFC protocol= security requirements. It can reference some existing security documents f= or non-SFC part such as RFC4778 and RFC5949.

·         Room consensus: anything that is SFC specifi= c protocol security requirement should be removed from draft-mglt-sfc-secur= ity-environment-req.

·         Discussion on whether the WG needs a separat= e SFC protocol security requirements document. An expired document exists (= draft-reddy-sfc-nsh-security-req) and the room discussed whether that docum= ent should be resurrected or should the protocol specific requirements be folded into the NSH document.

·         Room agreement to move the relevant portions= of this document to specific documents where it applies.  Then to re-= examine the remainder to see if there is a useful document for further work= .

 

Summary of action i= tems for security discussion:

1.     &= nbsp; Chairs to email the SFC WG mailing list to get cons= ensus on whether a standalone SFC protocol security requirements document s= hould be worked on or should said requirements be folded into the relevant = individual documents. AI: WG chairs (Status: Open).

2.     &= nbsp; Security considerations in NSH document should fix = citation issue: [SFC security requirements] has no reference and [nsh-sec] = is expired.  AI: NSH document editors to fix (Status: Open).

 

C.      OAM discussion:

Discussion centered on how to move OAM work forward i= n the SFC WG and how to align with the common OAM approach being worked in = NVO3.

 

·         Seek common approach of OAM for overlay. NVO= 3 support this approach.

·         Value to support both In-situ, and conventio= nal OAM but focus first on conventional OAM.

·         Need to specify OAM requirement first, not t= he solution.  

·         Priority: Finishing NSH is important to WG. = Get basic OAM work first.

·         O bit, next protocol, metadata are all relat= ed to OAM operation. Regardless what OAM solution is adopted eventually, ch= ecking o bit in base header gives the great benefit for NSH moving ahead wi= thout depending on any OAM approach, in which the worst case is to have some redundant process for OAM, e.g. ch= eck O bit and next protocol.

·         Room + plus Greg Mirsky consensus: O bit= to indicate OAM message exists on NSH packet. NSH does not need to specify= any OAM function except O bit. Take the expired OAM framework draft (draft= -ietf-sfc-oam-framework-01) and use it to develop the OAM requirements. This document has been dormant for a w= hile and was previously adopted as a WG document but with no movement since= adoption.

 

Summary of action items from OAM discussion:

1.       WG chairs will chase some folks to work on OAM fram= ework draft. (No change to NSH draft). AI: WG chairs (Status: Open)

 

D.      Control plane requirements document discussion:<= o:p>

Discussion on the current control plane requirements = document draft-ietf-sfc-control-plane-08.

 

·         Concerns have been expressed from several qu= arters that attempting to use this document to guide protocol development (= or implementation) of control functionality is quite challenging.

·         This led to discussion of the target audienc= e and purpose of the document.

·         Discussion of what is actually need regardin= g the control plane requirements for current WG work, for future expected W= G work, for protocol designers in other working groups, for implementers, a= nd for readers in the future.  And how to provide the needed information.

·         Without this document, will it cause interop= erability concerns? Yes, the control plane may contain multiple protocols, = BGP is only one of them. Concern is that we don’t know what features = each protocol should cover. Grouping will help.

·         Interface Information must be provided to de= fine interoperable interfaces.  This does not mean that a full data mo= del is needed.

·         Current document may be limited by WG charte= r.

·         It is clear that there is work to be done he= re. However not clear what to be done yet.  Need some regrouping the r= equirements to make more useful for the control plane development?

·         Chair: question to room: will SFC arch and N= SH doc. be sufficient for SFC control plane implementation? If yes, we do n= ot need to work on control plane requirements. No consensus on chair’= s question.

 

E.       MD-1 discussion

·         Control plane needs to inform SFC components= the MD-1 format per SPI.

·         Publishing MD-1 formats for common use case = is useful.

·         Lucy presented two possible ways for the con= trol plane to inform the data plane elements of the MD#1 format. WG will no= t mandate a particular way.

·         Discussion of whether a registry of MD-1 for= mats would be useful.  Room concluded that there is no need to create = a registry and assign code point for each published MD-1 format now.  = In future a control plane protocol may request a registry for identify individual format for the protocol to use.

·         SFC allows changing MD-1 format to MD-2 on a= SFP or vice versa. Current document has not yet made this clear.

·         A MD-1 format is not relevant to NSH protoco= l. However, it was asked if the MD-1 format may change along the SFP. = NSH doc. needs to clarify MD-1 format granularity.  The WG needs to d= ecide what it wants in this regard.

 

Room consensus:

·         Publish MD-1 formats for common use cases as= informational RFCs.

·         Allow changing MD-1 format to MD-2 in a SFP = or vice versa.

·         Get WG consensus the granularity of MD-1 for= mat, 1) per SPI; 2) per SPI and hop; etc. (current is per SPI). Once reach = consensus, update NSH doc in section 3.4, Section 4, and figure 8 to reflec= t the consensus. The MD-1 granularity will clarify what control plane and SFC components can be.

 

Action items:

1.     &= nbsp; NSH doc. clarifies that changing MD-1 format to MD-= 2 in or a SFP or vice versa is allowed.

1.     &= nbsp; Update NSH to reflect the WG consensus on MD-1 gran= ularity (see MD-1 room consensus).

 

F.       MD-2 discussion

·         SFC needs to specify the processing rules bu= t not all processes. I.e. the TLV definitions need to provide enough meanin= g for the particular TLVs that entities can make use of them.  But int= ernal or back end processing logic is not for SFC or an SFC Metadata TLV registry to mandate.

·         It was observed that the current common TLV = document does not have enough description for some of the TLVs. Folks shoul= d provide comments to the WG on where they would like to see more elaborati= on.  Preferably with proposed text.

·         It was also discussed that some TLVs are bet= ter explained in their own documents.  Particularly if the document ex= ists for another reason, or if lengthy explanation is useful for some TLV (= or set of TLVs.  After discussion, it was agreed that the common base document can and should be used for TLVs w= e currently know of that need short descriptions.  TLVs which fit natu= rally in some other document can and should be defined in those documents.&= nbsp;

·         For example, the documents defining MD-1 for= mats can also define a MD-2 Type code for carrying the same block of inform= ation with the same structure. 

·         Need to consider a way for vendor to create = own MD-1 format, preparatory one. This is not clearly covered now.

 

Room Consensus:

·         The TLVs with short explanations belong to c= ommon TLV doc.; other doc. may define the TLV needing more semantics for a = use case. In particular, there is no point in an entry in the common docume= nt whose only text is “see WFC document X for structure and meaning of this TLV.”  In that case, docume= nt X should reserve the type code.

 

Action item:

1.       Editors to remove inappropriate entries<= /p>

2.       WG to work out mechanism for vendors to create thei= r own MD-2 type codes.

 

G.     Transport related discussion

·         SFC arch are transport agnostic. However, SF= C architecture has some requirements on transport behavior such as ECMP, da= ta plane length, etc.

·         SFC arch made some assumption on transport. = We should document these assumptions and requirements.  Transport requ= irement work should be done in this WG. Homing for transport solution work = to be resolved on a case by case basis, with care to avoid overload.

 

Room Consensus:

·         Chairs needs to work with other WG on Transp= ort requirement and behavior.

 

Action Item:

1.       SFC WG work on transport requirement document.=

 

Yours,

 

Jim & Joel

 

 

 

 

 

 

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3DB24C0SJCEML701CHMchina_-- From nobody Tue Jan 31 11:15:36 2017 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 8976A12952D for ; Tue, 31 Jan 2017 11:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU4t4SYZubhg for ; Tue, 31 Jan 2017 11:15:32 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0113.outbound.protection.outlook.com [104.47.42.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB3012955B for ; Tue, 31 Jan 2017 11:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jOsjxJ7tT0j4JSz/OKVnLN+M9ZofQK0Uc34kvu2iWNg=; b=hc1Is4XWo1dQyZ9WcaBfL5/GZ3zsuAkUNriKAKkoRmLBCXJe6KKd1u/wRVhogsde8psNAL/a6PXHTJgRwVA1oX0LL8ZtrZyKNW9oRRvp8JJOiDxY2vCtSjelyNdgIc8FvMnz6mviPFh1yPTZwl7jjCfiiLk/tfOR1zqb9TGKdc8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.36.98] (66.129.241.10) by CY1PR05MB2188.namprd05.prod.outlook.com (10.166.192.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Tue, 31 Jan 2017 19:15:29 +0000 To: "Joel M. Halpern" , "sfc@ietf.org" References: From: Eric C Rosen Message-ID: <92ac7214-543b-b7ec-ef65-5f0dc9f4ea71@juniper.net> Date: Tue, 31 Jan 2017 14:15:30 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BLUPR17CA0002.namprd17.prod.outlook.com (10.164.14.140) To CY1PR05MB2188.namprd05.prod.outlook.com (10.166.192.12) X-MS-Office365-Filtering-Correlation-Id: 987a45d2-a001-4e9b-0799-08d44a0d8576 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401078); SRVR:CY1PR05MB2188; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2188; 3:YMmls8vc7ybAe4ltCJVEfIEYzfcSJIXOfQvU56Y70qFt3c5ZEuyWR3fWs+iO5V5P6b3NAl5JJXA1I0cI/sgO45umDFdOzffDrip7g/MPPnQOq6Ry2RL8jUFtX8Jzcu6sXJ4RR4uaFqNbj1cI0c/4qeQK5o8PJ/pFJG1Z1Gsstjf4DbGAw+ZjYUJRZ5YrFzalattmV/D0T6YiDPnBPy6em12YOpsZtSHmGzPkW3dP3ti8sANexXbr41Ox8nD8o7MalEySwoZ8wKdfPKlwZnfeyWtLntABmCcuWl8LWHJuw60=; 25:cNIWz0aSYfcM9v7S+uGos2vREdy0jl41lFrHT3YYH4t5pcjIoHgKkiDHH/tTyhvv+LiE+gNjr6FBF8owE87Gb6KCFeThhLDHXYmEKqd5hmxGUejKGBfCjCoexd0j50OhsVNpH9aixYPOm4hHhpiSJSKv98B0aNuQyLklHvWlAOYBTyBdUxhkulillIE/HeR5Z7b2cjxSgdQ5HoS+zm1aWn6CeNVbUBQeoCXwTKArmqUuBtzNad7agyJQ2n1/9zhvE6xGTCiCYJa65kC5aKt3RHNbrwlf/xEFpCkoSOKmH16+vX1dxyEa9sDWxLj250oX+mwn4jZ5fdeSf2PDjsML4w8/pc4q2UYTf5GtMzgf9eaKDRL/K9LlH+v0DAaGaqQlKuXs8SyzTDERMpKMhgVzBfEn2HHtf4R/6QsDUd3aYvGE9PPCt077ayc2YAGo1ZMKK7fXfq2xNi8zs6UoWFyf6Q== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2188; 31:Y/AOBnK8JrG4LrRpb6sKxbnThC8qMLGrhQ5jiUNUgWdCRlnETJDoJUSP/v6KEOYf7ifd4Wtk0tz2ZzpFu969ditP++Uj0wJlV+vUNpZRRtWQRdUxy0JHfVgtAdVaCKYo+dJDtSdCNly46pLT96evZa43KFLcVdzRIF7FFFCpVQZrOA8cOfg7BxH3jv2IR1IlIqvkNDXEP8BJ/YnjOwUk6uQ0t05fo4X7snoGnn1tdcW3KnGXuK7iScY+KxwujWbP; 20:PI3eDg3KeYbe7v4AZUsjLr4PhdD0+42oGYv8UfG2TD3PBWSkz6d3b+/GVql2GkwLgpfR9uem9t5e2bJl4gBlZZzeeVHmeSz+pSmwRHlFYHpn4TPN7NnCFML1MSLiV+u0Majni+CRoR/nSEl8ZbcHlL/TzcpYIinij8ldrFROI6xYuQHcJvJZ1/xmcy7zQI1X1OAKCuNS5luGNvK4GdGFDSOw4LxCJDedglKGoCwg/nEWAmUfrVx7AMvEZtg0L/+5Z/DhfPTZzqkxZAr3s9ParLsMfbQDfu1gv/cvUSQac+/EHVrDlvPyioB1bufBXgz4aetRb8dkSVTq1Z4k8Jc6Yflvh7epFORACJHdyxNpIdY0/+Y3tTpinzOTYg0A6SmGvqaBBVY0st3U3EoFQmjJnUf8JAlv2yhqukgKzjQFqZHbXkGUauNXOpNj/tgd0uhdqCnLQvZw0MsUWHEEs1XAh3DQ4FPbldllzup2D8eECmmzkmLZMGLGL941mdHUsnxMFbCDjTrOWJoOkI3miYmPo/Bsm3pkAmmH54yZz5Be/XLgNGTmM90NFPieZowXRMaBcNTt4dqAWqcr/Db+x4gOOP7Wz3uCdeSrsWCK8aZNfXM= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:CY1PR05MB2188; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2188; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2188; 4:6efBMFc0ag2T3lO2BkGDPMeR0bch4RoTQ7YBB0rjm8iBEPBPuM0e1tZK7TCgOHvM13ccrpsBl/sryKXU7mrT/LCFJle3j82FabM6kEVQ/53IaBbDzumBhvyLeuduy5SpTXtgIPWq7Fa06l4zc4p3xWd3GXF/vSIzCWQ+1op/bw6Rc83ksg+RdFeIJ2+HRCGqRwtSQwwpiZKPA5Xjve23+sLeO/qPDCeTrAMajxNmp302Hhr17ZKPlk2Q8zWchgFwDEFBfrzqaw3eV1FreZLTpyW4v3pPaeYJZNvMmAtrizGnFPOotFre/L9qhk5m4HxO01UYngxACxdITUjQVcWRS9sMc8ci9/GtS1CUOxlry3DUBrXlBnedsmRKZExHqe1/oXYFZ6Kfg3X1VrYvtoagWcf0jj5PK0sYYWzZQA1qyxr+rLInV9HXwv2LrOIalyEcMxT9AzxkJLUe0JDckFbxM4gBu+WNDyZhBoGJKz4pW5vImxdsu1THPpKDFNd95rZMEZhzKqxSTA91vowD53X0Ul3OhiQGAG8fQyWIBeSldsJmf26/t9fYE+Z1wJUTpcwEDHnWcQubdm6V+h4JqWkh9g== X-Forefront-PRVS: 0204F0BDE2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(39840400002)(39410400002)(39850400002)(39860400002)(189002)(199003)(42186005)(53936002)(107886002)(2950100002)(6666003)(68736007)(33646002)(25786008)(2501003)(101416001)(230700001)(31430400001)(54356999)(76176999)(64126003)(50986999)(7736002)(50466002)(5660300001)(189998001)(65826007)(23746002)(305945005)(65806001)(2906002)(81166006)(83506001)(31696002)(97736004)(6116002)(4001350100001)(5001770100001)(65956001)(66066001)(90366009)(92566002)(3846002)(229853002)(36756003)(77096006)(105586002)(6486002)(8676002)(47776003)(81156014)(38730400001)(106356001)(86362001)(31686004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2188; H:[172.29.36.98]; 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-Exchange-Diagnostics: =?Windows-1252?Q?1; CY1PR05MB2188; 23:Ibw/t1ojTaIZtvuJV3qlO6ClJvbxU8WYuONvS?= =?Windows-1252?Q?KSLPi9RdL3fqVVX8k9jB0X+YLNoFS7Yz59f8OBsTgWsB2QeANQrqQcEd?= =?Windows-1252?Q?jcnf4kEPVpcvEKXh2/KqJv3F1WfKGNj0PxYcL7W2EELCDvMaifbXugR0?= =?Windows-1252?Q?Q/z97Ul1byS7A3oXqpOjJpGOPdt5vu0Oy+Fqn0WvweNHQHpwI+1IgK+1?= =?Windows-1252?Q?NqFGNXuT4w1BkLaATlh/qxun34rcWJcq2ufKEdpDpg4g4kRstiI5zmD1?= =?Windows-1252?Q?RMGqjFA9ccr1P8p6C9Z+4AMroz0LuOyaLJCcYGlFmvzpjg6D3oPzNWiA?= =?Windows-1252?Q?/CrvXqkNn0YF9exwGOJ5ZWtZDATpl4AnUNfOefNTmTpPRZ9WZA/O7jax?= =?Windows-1252?Q?RjOr/j5iY2Ya3rFjvwTkvMGfsMGiHMJJGLFmUiC5/4qcum/QlSNag4t1?= =?Windows-1252?Q?UIgqTdfAoyCsCRLGoyqmtzNeFu6S7gFLecbbt3nFTCkUzpM8YiZctlo8?= =?Windows-1252?Q?oI0ZwuUo+j37Wz5yWlngDxNW5XrzNjoh763OclaGyX4MKhssVuYXLTgV?= =?Windows-1252?Q?VtK5B0xz2s6zvNFwgYn1uPpZkOggeGyd2KSyDuoHCveZoP85s5eWii3g?= =?Windows-1252?Q?WvWRCmEKjMpnu+w/BMfiO2ec60j1ierckyreYZpb53BEQPXIJyhie8a8?= =?Windows-1252?Q?pIG5fgJ6NiFQEoqcBFTI7v69yjMSuRGkCIu5wtnJ0PH+QLUSi1tET7yg?= =?Windows-1252?Q?ht/SLH9KUXGMOgzIQjtB3Yhk9DSl6zIMOnAq/8XVUThqlzVj4g307juP?= =?Windows-1252?Q?TE9OrXqD+Sq2I2a977gaOCpEO9KyvMGwBx9YQ/RBDERLEi2aKQnUf9P1?= =?Windows-1252?Q?CEh/4fG6ZV5Ltk7mxMRhYopG71LPADqHJk8xjSzfA14fS/wC9AU+E6zm?= =?Windows-1252?Q?5mKBsjv5ffpWA7G4quH5M1QLGK0aCHn0TKMNQxgDbiqXZa1NH6MXMfyw?= =?Windows-1252?Q?gCHOnOrC0KO+lClTAsKSQ+pMaO5RGeixalZJ87lwqvS5dHPnKSq3Iuvx?= =?Windows-1252?Q?r4hQaT0ZwrJ2keTaCgSh4ruFDFW9sT9uZ0NuenCgf9bHTrWlNbmkF6za?= =?Windows-1252?Q?0N8205QzfAqL9pBpwFJAGowDTL7OCbg71EcHjPYhziQ+e3wT5UtY1NCD?= =?Windows-1252?Q?aNrVgH16otf09D0Hp3witFDtiMVPR4WRyDgi0rCCSmLTXcDbHwRqwpwx?= =?Windows-1252?Q?f85t1OudgdJSjEcvTuEZJ2t8373MjQp+KQ1/nTUNTffE/KMVxFDWXE/P?= =?Windows-1252?Q?aocfZmdGlCpBTNXBO2gEleKBX/kpC4WaUEpc4wPufbZ3lzzVSpVYF4dl?= =?Windows-1252?Q?9CBKf1nS4LiVWHWm8tcWd5F+o9PlZh4IPSz9EEHxDTRitYaf9MwIKrcS?= =?Windows-1252?Q?PiAGWiEbNB+DWADZiqVGcPTJ9YsivgDFriEzncKk8Bu1flrdbi181TOg?= =?Windows-1252?Q?PTJyXzDKbTM1J0QXKBEa6cqbFrII4XBspCBEYZ2CG7ThkLXDYhovdta+?= =?Windows-1252?Q?iITm5m4YsL4DfiR+pM1ECfFLAY+gpsJajkS?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2188; 6:n1ruG3zQ86dxJTX3L4yqRS4g/p8V3mniFORRi8G40MPVXsC1MAkj6zyL1avoSY5XLBTtJ/ZiUzojuds7whCzVfXzk53nuDZ9Pd7hz8NbY232yskx955slzOywmJJ7I0nlJlgmqABW7qqUvxbmNysfDygpAOPcYL98RdztKmvhu6wlUV0dxaZnaTS+2Plhwoc62c7kPE4aV3vZh1KpExt/Hwdx8HKARy9GFYCrj+zOPj9kzpFYm508IpMzxzFiBC7cps2qr1o6+4fUeKblrtflpATsW8p3FqiOzJqAQtQ862X5lIsl+HJyKaiPbDa3/FIQOUPNWin3AC0I0MdCie0DQSjnrTfGtp7lwC+Zx3nal4W/HTEfwxdp8LQN8fF7nhyG5oRFcs27iL3BVkDoJkJb8/Pwuansf6BkAQupOiS9OgRbSI7s6Pa5DgF/8H+6igN; 5:Q7PB7Hs1lg1csb4y/UtECm9+HWqgdlu55BpnlLBx++HlfSwAPt90CJ0gEDwrRftx00bumbWFK0GrFi3OVAR3Us3JcCBkShkZcMEfHaets1cbHo8CZNKZ7yrba+45QFqFQLkeahte26wP4fxcjSFWbA==; 24:N1u3sO8h4/eeq46TkpZE/16A1IgqsO47aXIEPVdtb1j32HymkxEp8KaXEe3oY8sApWdqMCcaUCCCudfjF7uDUak8I42S42Onc3XfzwzeD7o= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2188; 7:4Lgc8i78mnivCf4e+b57e2b13NpomKOM/AZed/cYlH98nzcF9lXFRCfDVlifkVF0aCVB+5QhpJdmfbiNsqsdV6DjJKA6kWjhyzE0ZHFoKz7FIqDDcXdKuWvAmToYkbEJZsdpBH4/jhkHS8jceLcAvt6kRotngkA9zb/CqUU+3fxlpJCjXfpt+rIvbrNBG5VzKD5OOk/BovboGp6v8QXbBkVZyODaE3Us7FMEvUhpFYkxGgCZymZ5K6DRJ0P6kwIWOitAyG6AAOhNeZOxcSbAEb3r+WESS129JRYe0G4wfBfnDHQgEW4TtGFgZd6OJ7CEm3QmzfyzbOGWbzOnuE4g8DGmSjby0IoYKiazH3qIhhWyjvQDblYPhzapAViOjUqoMo+Zs/STfR7EWfYQZCvuez9l0Ivlb72XVrqd/PAENNBf1KcyUrVY7jJDpJT4mIc9I3qZo1MpiSO0/QOCjizJs7bevQ4O1FvWtjTzGYMWeMIhKarLu2A7ObMAODxPWebOJOM19xmc/kR5YKsWOWQj/UJOSU2mxFXCgZ2qv6HB662Oc+6Ax2CqHLLhJTc5mF7J X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2017 19:15:29.4593 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2188 Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 19:15:34 -0000 I believe the control plane requirements document should be abandoned by the WG. The document attempts to describe the information needed by the various components (e.g., SF, SFF, classifier) of the architecture. However, RFC 7665 and draft-ietf-sfc-nsh already describe the information needed by the components, and the control plane requirements document does not add anything of substance. The requirements document attempts to organize the information into four "interface reference points", but as other have pointed out already, this method of organization just is not particularly useful, and is not helpful when designing a control plane architecture. These reference points do not correspond to anything real. If the document advances, someone will ask questions like "is this protocol element part of the implementation of interface C2 or is it part of the implementation of interface C3?", and the answer will often be "well, you could think of it as part of C2, or you could think of it as part of C3, or maybe as part of both, depending on your deployment scenario, but really it doesn't matter". In this way, the document creates extra work without adding extra value. When I first looked at the document, I thought it was going to provide a set of APIs allowing one to build an SF without knowing what the control plane would be. That might be useful (if it is even possible), but the document does not seem to provide any such thing. There is important information that is absent from the prior documents, such as the information needed to support the interaction of the service layer components with the underlying transport, but that information is also absent from the requirements document. I don't think this sort of requirements document is helpful when attempting to design a control plane solution, it just gets in the way. From nobody Tue Jan 31 18:56:13 2017 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 0F3FA12984C for ; Tue, 31 Jan 2017 18:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 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, RP_MATCHES_RCVD=-3.199, 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=f5.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 kuuxqIlk5xlh for ; Tue, 31 Jan 2017 18:56:10 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581AB129801 for ; Tue, 31 Jan 2017 18:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1485917771; x=1517453771; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=e0q2TYT592VAJTsdBbp/ifhmoc5MUWi/DgwYe6wVVl8=; b=gSXp7oFZNYuz0HTLEjNF1yVQf/y8wIjUax7YXN/xUFO6DF4P4l/TvIDv OJb5scU9BN4fzWx5Doopmk/gyCfYMw8pxuPRFMjUKnA41BL8OZzTrqMEb ATMReSdX9ptMUXuVC0eNLV9iyUzt/2CUwU7TtjgYV/CEuBSa+3StZUinT k=; X-IronPort-AV: E=McAfee;i="5700,7163,8425"; a="271406323" X-IronPort-AV: E=Sophos;i="5.33,317,1477958400"; d="scan'208";a="271406323" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 01 Feb 2017 02:56:09 +0000 Received: from SV5CCPEMS05.olympus.F5Net.com (172.23.209.16) by SV5CCPEMS05.olympus.F5Net.com (172.23.209.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Tue, 31 Jan 2017 18:56:07 -0800 Received: from SV5CCPEMS05.olympus.F5Net.com ([fe80::585f:f2f8:4721:2a32]) by SV5CCPEMS05.olympus.F5Net.com ([fe80::585f:f2f8:4721:2a32%19]) with mapi id 15.01.0669.032; Tue, 31 Jan 2017 18:56:07 -0800 From: Sumandra Majee To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] How to progress our control plane requirements document Thread-Index: AQHSbciskIOG8xZK3Uy0CKJpHOUgCqE3IioAgBDY9oCAC5bFAA== Date: Wed, 1 Feb 2017 02:56:07 +0000 Message-ID: <8D1EA927-4722-425D-B776-A82948176AF0@f5.com> References: <787AE7BB302AE849A7480A190F8B933009DE9028@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DE9028@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.18.0.160709 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [172.23.251.195] Content-Type: text/plain; charset="utf-8" Content-ID: <9D6718136A2F2347811C83861D6B7C56@F5.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] How to progress our control plane requirements document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 02:56:12 -0000 TWVkLA0KDQpTb3JyeSBmb3IgdGhlIGRlbGF5LCBJIGd1ZXNzIG5ldyB5ZWFyIHN0YXJ0ZWQgd2l0 aCBhIGJhbmcg4pi5LiANCkJlZm9yZSB3ZSBnbyBpbnRvIGRldGFpbCBJIGFncmVlIHRoYXQgdGhh dCBhIGNvbW1vbi9zdGFuZGFyZGl6ZWQgaW50ZXJmYWNlIHRvIGFuIGVudGl0eSAoeW91IGNhbGwg aXQgY29udHJvbGxlciBhbmQgSSBjYWxsIGl0IG1hbmFnZXIpIGlzIHZlcnkgbXVjaCByZXF1aXJl ZC4gVGhlcmUgc2hvdWxkIGJlIGEgc2V0IG9mIGludGVyZmFjZSB0aGF0IGlzIGFic29sdXRlbHkg bmVjZXNzYXJ5LCBmb3IgZXhhbXBsZSB0aGUgaW50ZXJmYWNlICh0aGluayBDMikgYmV0d2VlbiBD b250cm9sbGVyIHRvIFNGRiBpbiBvcmRlciB0byBkaXN0cmlidXRlIHBhdGgvbmV4dGhvcCBpbmZv cm1hdGlvbi4gSSB3b3VsZCBsaWtlIHRvIHNlZSBhIHNjaGVtYSBldGMuIGZvciB0aGF0IGludGVy ZmFjZSBzbyB3ZSBhbGwgY2FuIGltcGxlbWVudCBpdCBhbmQgZXhwZWN0IHRvIHdvcmsgd2l0aCBh bnkgY29udHJvbGxlci4NCg0KVGhlIGNsYXNzaWZpZXIgbWF5IG9yIG1heSBub3QgYmUgcGFydCBv ZiBTRkMgY29udHJvbGxlciBkb21haW4uIFllcywgdGhlcmUgbmVlZHMgdG8gYmUgYSBtYXBwaW5n IG9mIDxSVUxFPiB0byA8Q0hBSU4+IGJ1dCBhIGNsYXNzaWZpZXIgbWF5IGNob29zZSB0byBhY3F1 aXJlIHRoaXMgcnVsZQ0KLSBGcm9tIFBDUkYNCi0gU0ROIENvbnRyb2xsZXINCi0gUkVTVC9TT0FQ IG5hbWUgeW91ciBpbnRlcmZhY2UgQVBJDQotIE9sZCBzdHlsZSBDTEkgDQotIEluIHRoaXMgcGFy dGljdWxhciBjYXNlIGl0IGlzIHNvbWV0aW1lcyBhIHNjcmlwdCB0aGF0IHNldHMgdGhlIGJpbmRp bmcuIA0KDQpJbiBmYWN0LCBvdXIgZXhwZXJpZW5jZSBpcyB0aGF0IGV2ZXJ5IGRlcGxveW1lbnQg aGFzIGRpZmZlcmVudCBuZWVkLCBkaWZmZXJlbnQgYXV0b21hdGlvbiBuZWVkLiBPbmUgbWF5IGNo b29zZSB0byB1c2UgY2xvdWQgZm9ybWF0aW9uIHRlbXBsYXRlLiANClNvIHNvbWUgb2YgeW91ciBx dWVzdGlvbnMgYmVsb3cgY291bGQgbm9wLiBJIHRoaW5rIGl0IHdpbGwgYmUgZ29vZCB0b3BpYyBm b3IgZGlzY3Vzc2lvbiBhcyB3ZWxsIHNvbWUgcHJlc2VudGF0aW9uLg0KDQpPbmNlIHdlIHNlcGFy YXRlIG91dCB0aGUgY2xhc3NpZmllciBhbmQgU0ZGL1NGIHRoZW4gdGhlIHNldCBvZiBpbnRlcmZh Y2VzIGFyZSBzbWFsbGVyIChhbmQgdGhlIGNsYXNzaWZpZXIgY29tcGxleGl0eSBhbmQgcmljaG5l c3MgY2FuIGJlIHR1bmVkIGZvciB0aGUgZGVwbG95bWVudC4gWWVzIGl0IGRvZXMgc3VwcG9ydCBw cmlvcml0eSBvcmRlciwgZW1iZWRkZWQgc2NyaXB0LCBhcHAgaWRlbnRpZmljYXRpb24gYW5kIGFs bCB0aGF0IGluIGFkdmFuY2VkIGZvcm0gb3IgaXQgY291bGQgYXMgZHVtYiBhcyBwa3QgbWF0Y2hp bmcgYWNsIGluIHN3aXRjaCBody4gSSBtYXkgbmVlZCBzcGVlZCBvbmx5IHNvbWV0aW1lcykuIA0K DQoqKiBbTWVkXURvZXMgeW91ciBpbXBsZW1lbnRhdGlvbiBhbGxvdyB0byBkZXRlY3QgdGhlIGxp dmVuZXNzIG9mIFNGcz8NClllcyBpdCBkb2VzLiBCdXQgZG8gSSBuZWVkIGNvbnRyb2xsZXIgdG8g ZG8gdGhpcywgbm90IGFsd2F5cy4gVGhpcyBjb3VsZCBoYXZlIGJlZW4gYnVpbHQgaW50byB0aGUg cm9vdCBvZiB0aGUgY2hhaW4sIGNhbiBiZSBkb25lIGZyb20gdGhlIFNGIHByb3h5IChpZiBpdCBp cyBwcmVzZW50LCBpdCBvZnRlbiBpcykuIEEgU0YgYWJsZSByZXBseSBIZWxsbyBkb2VzbuKAmXQg bWVhbiBpdCBpcyBhY3R1YWxseSBzZXJ2aW5nIHVzZXIgdHJhZmZpYy4gVGhlIHBvaW50IG9mIHZp ZXcgZnJvbSBjb250cm9sbGVyIGlzIG5vdCB3aGF0IGEgdXNlciB0cmFmZmljIGlzIGdvaW5nIHRo cnUuIEhvd2V2ZXIsIGEgY29udHJvbGxlciBpcyB0aGUgcmlnaHQgcGxhY2UgdG8gcHJvdmlkZSBh IHNpbmdsZSB2aWV3IG9mIHdob2xlIGNoYWluLg0KDQoNCk9uIDEvMjQvMTcsIDE6NTcgQU0sICJt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT4gd3JvdGU6DQoNCiAgICBEZWFyIFN1bWFuZHJhLCANCiAgICANCiAgICBUaGFuayB5b3UgZm9y IHNoYXJpbmcgeW91ciB0aG91Z2h0cy4gDQogICAgDQogICAgQW4gaW1wbGVtZW50ZXIgdGhhdCBt YW5hZ2VzIGJvdGggdGhlICJjb250cm9sbGVyKHMpIiBhbmQgImNvbnRyb2xsZWQgZnVuY3Rpb24i IGNhbiBhbHdheXMgaW1wbGVtZW50IHdoYXQgaXQgd2FudHMgd2l0aG91dCByZWZlcnJpbmcgdG8g YW4gZXh0ZXJuYWwgcmVxdWlyZW1lbnRzIGRvY3VtZW50LiBUaGF04oCZcyBmYWlyLiBOZXZlcnRo ZWxlc3MsIHN0YW5kYXJkaXplZCBwcm90b2NvbHMgKGV4dGVuc2lvbnMpIGFyZSBuZWVkZWQgZm9y IGludGVyb3BlcmFiaWxpdHkgcHVycG9zZXMuIFRvIGdldCB0aGVyZSwgdGhpcyBkb2N1bWVudCBn cm91cHMgdGhlIHNldCBvZiBDUCByZXF1aXJlbWVudHMgdGhhdCB0aGUgU0ZDIFdHIHJlcXVpcmVz IHRvIGJlIHN1cHBvcnRlZCB0byBpbnRlcmFjdCB3aXRoIHZhcmlvdXMgaW1wbGVtZW50YXRpb24g cG9pbnRzLiAgDQogICAgDQogICAgR2l2ZW4gdGhhdCB5b3UgaGF2ZSBhbiBpbXBsZW1lbnRhdGlv biwgbWF5IEkgYXNrIHlvdSB0aGUgZm9sbG93aW5nIG5vbi1leGhhdXN0aXZlIHF1ZXN0aW9uczoN CiAgICANCiAgICAqIFdoYXQgaXMgdGhlIGluZm9ybWF0aW9uIHRoYXQgaXMgbmVlZGVkIGZvciB5 b3VyIGNvbnRyb2xsZXIgYXQgYm9vdHN0cmFwPyANCiAgICAqIERvZXMgeW91ciBjb250cm9sbGVy IHJlcXVpcmUgYSBwZXJtYW5lbnQgc2Vzc2lvbiB0byBiZSBtYWludGFpbmVkIHdpdGggdGhlIFNG QyBjb250cm9sbGVkIGRldmljZT8NCiAgICAqIERvZXMgeW91ciBjb250cm9sbGVyIGFsbG93IHRv IGluc3RydWN0IHRoZSB1bmRlcmx5aW5nIFNGQy1hd2FyZSBub2RlIGFib3V0IHRoZSB0cmFuc3Bv cnQgZW5jYXBzdWxhdGlvbiB0byBiZSB1c2VkPyAgDQogICAgKiBEb2VzIHlvdXIgaW1wbGVtZW50 YXRpb24gYWxsb3cgdG8gY29udHJvbCB0aGUgc2VtYW50aWMgb2YgY29udGV4dCBpbmZvcm1hdGlv biwgdGhlaXIgc2NvcGUsIGFuZCBob3cgaXQgc2hvdWxkIGJlIGNvbnN1bWVkL3N1cHBsaWVkPw0K ICAgICogRG9lcyB5b3VyIGltcGxlbWVudGF0aW9uIGFsbG93IGEgY2xhc3NpZmllciB0byBhdXRv LWNsZWFuIGl0cyBlbnRyaWVzIGJ5IG1lYW5zIG9mIGEgbGlmZXRpbWU/DQogICAgKiBEb2VzIHlv dXIgaW1wbGVtZW50YXRpb24gYWxsb3cgdG8gcmVtb3ZlIHN0YWxlIGNsYXNzaWZpY2F0aW9uIGVu dHJpZXM/DQogICAgKiBEb2VzIHlvdXIgaW1wbGVtZW50YXRpb24gYWxsb3cgdG8gcmV0cmlldmUg dGhlIGxpc3Qgb2YgU0ZzIHRoYXQgYXJlIGF0dGFjaGVkIHRvIGEgZ2l2ZW4gU0ZGPw0KICAgICog RG9lcyB5b3VyIGltcGxlbWVudGF0aW9uIGFsbG93IHRvIGluc3RydWN0IGFuIFNGRiBhYm91dCB0 aGUgbGlzdCBvZiBTRnMgaXQgY2FuIHNlcnZpY2U/DQogICAgKiBEb2VzIHlvdXIgaW1wbGVtZW50 YXRpb24gaW5zdHJ1Y3QgdGhlIGNsYXNzaWZpZXIgYWJvdXQgdGhlIHRpZS1icmVhayBydWxlcyB0 byBiZSBmb2xsb3dlZCB3aGVuIG1vcmUgdGhhbiBvbmUgY2xhc3NpZmljYXRpb24gZW50cnkgaXMg bWF0Y2hlZD8gDQogICAgKiBEb2VzIHlvdXIgaW1wbGVtZW50YXRpb24gYWxsb3cgYW4gU0ZGIHRv IHJlbW92ZSBzdGFsZSBlbnRyaWVzIHdpdGhvdXQgdGhlIGhlbHAgb2YgdGhlIGNvbnRyb2xsZXI/ DQogICAgKiBEb2VzIHlvdXIgaW1wbGVtZW50YXRpb24gYWxsb3cgdG8gZGV0ZWN0IHRoZSBsaXZl bmVzcyBvZiBTRnM/DQogICAgKiBEb2VzIHlvdXIgaW1wbGVtZW50YXRpb24gYWxsb3cgdG8gY29u dHJvbCB0aGUgYmVoYXZpb3Igd2hlbiBhbiBTRiBpcyB0byBiZSB3aXRoZHJhd24/DQogICAgKiAu Li4gICANCiAgICANCiAgICBUaGFuayB5b3UuDQogICAgDQogICAgQ2hlZXJzLA0KICAgIE1lZA0K ICAgIA0KICAgID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQogICAgPiBEZSA6IHNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFN1bWFuZHJhIE1hamVl DQogICAgPiBFbnZvecOpIDogc2FtZWRpIDE0IGphbnZpZXIgMjAxNyAwMTo0MQ0KICAgID4gw4Ag OiBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0KICAgID4gT2JqZXQgOiBSZTogW3NmY10g SG93IHRvIHByb2dyZXNzIG91ciBjb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cyBkb2N1bWVudA0K ICAgID4gDQogICAgPiBKb2VsLCBKaW0sDQogICAgPiANCiAgICA+IEkgYW0gaW4gZnVsbCBhZ3Jl ZW1lbnQgd2l0aCB0aGlzLiBIYXZpbmcgZ29uZSB0aHJ1IGEgaW1wbGVtZW50YXRpb24gb2YNCiAg ICA+IHF1YXNpIGNvbnRyb2xsZXIgKCBJIGFtIHN1cmUgc28gaGFzIG90aGVycykgLCBJIGNhbiBz YXkgdGhhdCB0aGUgZG9jdW1lbnQNCiAgICA+IHdhcyBub3QgdmVyeSBlZmZlY3RpdmUgZm9yIGlt cGxlbWVudGVycy4gV2hpbGUgdGhlIGNvbmNlcHQgbGFpZCBvdXQgbWlnaHQNCiAgICA+IGJlIHVz ZWZ1bCBidXQgaXQgZG9lc27igJl0IHRyYW5zbGF0ZSBpbnRvIGFueXRoaW5nIG1lYW5pbmdmdWwu DQogICAgPiANCiAgICA+IEkgYW0gYWN0dWFsbHkgd29uZGVyaW5nIGlmIHRoZXJlIGlzIGEgbmVl ZCBjb250cm9sIHBsYW5lIGRvY3VtZW50LCBob3dldmVyDQogICAgPiB0aGVyZSBpcyBhIG5lZWQg Zm9yIGRlZmluaW5nIHRoZSBBUEkvU2NoZW1hIGV0Yy4NCiAgICA+IA0KICAgID4gU3VtYW5kcmEN CiAgICA+IA0KICAgID4gT24gMS8xMy8xNywgMTA6MTIgQU0sICJzZmMgb24gYmVoYWxmIG9mIEpv ZWwgTS4gSGFscGVybiIgPHNmYy0NCiAgICA+IGJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IGptaEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KICAgID4gDQogICAgPiAgICAgSmltIGFuZCBJ IGhhdmUgYmVlbiB0YWxraW5nIHdpdGggQWxpYSBhYm91dCB0aGlzLCBhbmQgdGFsa2luZyB3aXRo DQogICAgPiBlYWNoDQogICAgPiAgICAgb3RoZXIuICBBbG9uZyB0aGUgd2F5IHdlIHJlYWxpemVk IHRoYXQgd2UgaGF2ZSBzb21lIHNpZ25pZmljYW50DQogICAgPiBjb25jZXJucw0KICAgID4gICAg IGFib3V0IHdoYXQgd2UgaGF2ZSBkb25lIHdpdGggdGhpcyBkb2N1bWVudC4NCiAgICA+IA0KICAg ID4gICAgIFdlIGV4cGVjdCB0byBkaXNjdXNzIHRoaXMgbmV4dCB3ZWVrIGF0IHRoZSBpbnRlcmlt LCBsb29raW5nIGZvciBpZGVhcy4NCiAgICA+ICAgICBBbmQgdG8gZGlzY3VzcyBpdCBmdXJ0aGVy IG9uIHRoZSBsaXN0Lg0KICAgID4gDQogICAgPiAgICAgVGhlIGV4aXN0aW5nIGNvbnRyb2wgcGxh bmUgZG9jdW1lbnQgd2hlbiB2aWV3ZWQgZnJvbSB0aGUgcGVyc3BlY3RpdmUNCiAgICA+IG9mDQog ICAgPiAgICAgYW4gaW1wbGVtZW50ZXIgaXMgaGFyZCB0byBkZWNvbXBvc2UgaW50byBhY3Rpb25h YmxlIHBhcnRzLiBHaXZlbiB0aGF0DQogICAgPiAgICAgdGhlIElFVEYgdGVuZHMgdG8gd29yayBi eSBzb2x2aW5nIHBpZWNlcyBvZiBwcm9ibGVtcywgcmF0aGVyIHRoYW4gYW4NCiAgICA+ICAgICBl bnRpcmUgY29udHJvbCBzb2x1dGlvbiBmb3IgYWxsIGFzcGVjdHMsIGl0IGlzIGltcG9ydGFudCB0 aGF0DQogICAgPiAgICAgcmVxdXJpZW1lbnRzIHdlIGRlZmluZSBiZSB1c2FibGUgZm9yIHN1Y2gg cGllY2Utd2lzZSB3b3JrLiBUaHVzLCB3ZQ0KICAgID4gbmVlZA0KICAgID4gICAgIHRvIGRlc2Ny aWJlIHRoZSByZXF1aXJlbWVudHMgaW4gd2F5cyB0aGF0IHByb3ZpZGUgY29tcG9uZW50cyB3aGlj aCBtYXkNCiAgICA+ICAgICBiZSBjb21iaW5lZCBpbnRvIGFuIG92ZXJhbGwgY29udHJvbCBwbGFu ZSBzb2x1dGlvbiBmb3IgU0ZDLg0KICAgID4gDQogICAgPiAgICAgV2hpbGUgdGhlIGRvY3VtZW50 IHByb3ZpZGVzIGEgc2V0IG9mIGNvbnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzIGl0DQogICAgPiBk b2VzDQogICAgPiAgICAgbm90IHByb3ZpZGUgZ3VpZGFuY2Ugb24gaG93IHRob3NlIHJlcXVpcmVt ZW50cyBjYW4gYmUgc3VjY2Vzc2Z1bGx5DQogICAgPiAgICAgY29uc3VtZWQgaW50byBhIHN0YW5k YXJkcyBjb21wbGlhbnQgY29udHJvbCBwbGFuZS4gSW4gcGFydGljdWxhciwgdGhlDQogICAgPiAg ICAgaW50ZXJmYWNlcyBDMSAtIEM0IGFyZSBlYWNoIG1hZGUgdXAgb2YgYmVoYXZpb3JzIGxpa2Vs eSB0byBiZSBwcm92aWRlZA0KICAgID4gICAgIGJ5IGRpZmZlcmVudCBzb2x1dGlvbiBjb21wb25l bnRzLiAgVGh1cywgd2hpbGUgdGhlcmUgaXMgYW4gYXR0ZW1wdCB0bw0KICAgID4gICAgIGRvY3Vt ZW50IGEgc2V0IG9mIGludGVyZmFjZXMgKEMxLi4uQzQpIGl0IGlzIG5vdCBjbGVhciBob3cgYW4N CiAgICA+ICAgICBpbXBsZW1lbnRlciBjYW4gcHJvdmlkZSBhIHNvbHV0aW9uIGNvbXBvbmVudCB0 aGF0IGFkZHJlc3NlcyBhDQogICAgPiAgICAgd2VsbC1kZWZpbmVkIHNldCBvZiByZXF1aXJlbWVu dHMuDQogICAgPiANCiAgICA+ICAgICBHaXZlbiB0aGlzLCB3ZSBuZWVkIHRvIGdvIGJhY2sgYW5k IHJldGhpbmsgdGhlIGJ1bmRsaW5nIG9mDQogICAgPiBmdW5jdGlvbmFsaXR5DQogICAgPiAgICAg c28gYXMgdG8gZW5kIHVwIHdpdGggYnVuZGxlcyBvZiByZXF1aXJlbWVudHMgdGhhdCBhcmUgY2Fu IGJlIHVzZWZ1bGx5DQogICAgPiAgICAgYWRkcmVzc2VkIGJ5IElFVEYgd29yayB3aGlsZSBhdm9p ZGluZyAoYXMgd2UgaGF2ZSBkb25lIHdlbGwgaW4gdGhlDQogICAgPiAgICAgY3VycmVudCB2ZXJz aW9uKSBwcmVzY3JpYmluZyB0aGUgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUuDQogICAgPiAN CiAgICA+ICAgICBJbiBhZGRpdGlvbiwgZnVuY3Rpb25hbCBvYmplY3RpdmVzIGFyZSBub3QgZmlu ZSBncmFpbmVkIGVub3VnaCB0bw0KICAgID4gICAgIGltcGxlbWVudDsgZm9yIGV4YW1wbGUsIHRl eHQgc3VjaCBhcyAiUmF0aW9uYWxpemUgdGhlIG1hbmFnZW1lbnQgb2YNCiAgICA+ICAgICBjbGFz c2lmaWNhdGlvbiBydWxlcyIgaXMgbm90IHNvbWV0aGluZyBvbmUgY2FuIGltcGxlbWVudC4NCiAg ICA+IA0KICAgID4gICAgIFlvdXJzLA0KICAgID4gDQogICAgPiAgICAgSmltICYgSm9lbA0KICAg ID4gDQogICAgPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICA+ICAgICBzZmMgbWFpbGluZyBsaXN0DQogICAgPiAgICAgc2ZjQGlldGYub3Jn DQogICAgPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCiAg ICA+IA0KICAgID4gDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgID4gc2ZjIG1haWxpbmcgbGlzdA0KICAgID4gc2ZjQGlldGYub3JnDQog ICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KICAgIA0KDQo=