From nobody Wed Dec 6 15:01: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 528A2124319 for ; Wed, 6 Dec 2017 15:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 T2D1HSP_uP86 for ; Wed, 6 Dec 2017 15:01:50 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0121.outbound.protection.outlook.com [104.47.1.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91BD21205F0 for ; Wed, 6 Dec 2017 15:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cp0VuMacVbGgnLfI+UkHef+nvVG+FrrDM1TIqimOL3Q=; b=nupD5vvoSx5lBVM8AN1rQrlgHPF4DOH5kc5ZsaIf5c5nhHctDSw5NBsXQb6Wo0kL+DZhDK0bLPhXtFYHSIJdRX8mOrMbAv4dWW4OTzhyneDNAgaUzSAWvP9BJRH9COoa/woLUeLo9i/HzfNWMP7H2+OALACfOu04wJeDf6WaHVI= Received: from AM4PR0701MB2177.eurprd07.prod.outlook.com (10.167.132.150) by AM4PR0701MB2177.eurprd07.prod.outlook.com (10.167.132.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Wed, 6 Dec 2017 23:01:46 +0000 Received: from AM4PR0701MB2177.eurprd07.prod.outlook.com ([fe80::b060:eb52:e2d0:4f7a]) by AM4PR0701MB2177.eurprd07.prod.outlook.com ([fe80::b060:eb52:e2d0:4f7a%18]) with mapi id 15.20.0302.007; Wed, 6 Dec 2017 23:01:46 +0000 From: "Muley, Praveen (Nokia - US/Mountain View)" To: "Paul Quinn (paulq)" , Sumandra Majee CC: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] WG Adoption calls: two MD-1 drafts Thread-Index: AQHTaVe3Napbym+lm0yZbI/Kjs9RgaMr5tOAgAHAYgCACVJhIA== Date: Wed, 6 Dec 2017 23:01:46 +0000 Message-ID: References: <94A59F1E-2535-4F96-ABC4-4E0E382694BB@cisco.com> In-Reply-To: <94A59F1E-2535-4F96-ABC4-4E0E382694BB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.20.30] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0701MB2177; 6:/jqZB5mkWiNsc0bAg39YcCRx1gVpoKZ6pio863rbVmwNKTpGJn0FwEQzA4weGR+LueW+3LN0RvU29EX9qzU2bydrhhsNsHkPYnTmMwhdH0vbHXn2FCELr9oIGMlDBQJZtDUZwy02UFgK+LWMvG7Wzq2noLBp0YZ2B+eA59yOdqjb7jrJXo81Z5nGyS9a7eYCKTCB9jaNeetP6wXg36HD2n1IOr9qghN9hJCqrgqdtdZBmTdk2Sxby4X+z1qWa0n83FZQcXcqoDNxUTQI5kX3+BMkaHPpmvbtFyoUTfDlhjgGzSItobW8ocJ9G18DK+cn5UWvRWmG9IkgPI2986QnkPi49pYl0Llv74x5SlLZsUg=; 5:w+Tpds5kB/VjihRi6sWhU36KFfVqML1TpaelWhZhQydAg5S24v7aAwCqD/G7Y5gchEGvZA3wy9ihRxGUGBmC+KTGzfA10zpmCpoieNuKwr+qLC/uLaCDsU74/xjhdFP37H0dGKXRXQ7gjCPgKI8nXrAD94GwKLKlzztQNj/vc1s=; 24:vYw0EJiAPN632iyXOIFsJEih6h1ER66eyVbARWuLlgKNAk3Ca+2bWv8yrhqu1VRC24IhFbPs2ygu+6jIkRhW8n4uqgcR+/1frb2qWQEP7cY=; 7:/cKbnwAvGx/FINTbj6ziOm/J+p1E+7nyUiG7DMBLjI1ap9gcSLEfddvqD0iGBMGZwophTZ20/aBwFdBrj+wLWrWFYGfn9t0PGg4UYZzPWV/SRp7eDxPydLmPYAIj00JpcZpZhvykUCPNiYnGQmcl39EiqbuabWvGy9nu19/N+5d/GpqUBmTucosfIGU4f1FB8KFVYEKcNnO2I2obCS5IUmGH/hsjOdGRuMTw0grIyMFpQOFRP71q+WZ3en1immLV x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c92cf650-e947-44b6-b47e-08d53cfd5393 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286); SRVR:AM4PR0701MB2177; x-ms-traffictypediagnostic: AM4PR0701MB2177: authentication-results: spf=none (sender IP is ) smtp.mailfrom=praveen.muley@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(69137744131126); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231022)(6055026)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR0701MB2177; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR0701MB2177; x-forefront-prvs: 05134F8B4F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(366004)(13464003)(24454002)(189003)(199004)(86362001)(6436002)(7696005)(4326008)(6246003)(478600001)(305945005)(8676002)(81156014)(229853002)(81166006)(6506006)(97736004)(5250100002)(76176011)(6306002)(106356001)(2906002)(2950100002)(3280700002)(55016002)(3660700001)(7736002)(966005)(9686003)(74316002)(66066001)(53936002)(105586002)(25786009)(14454004)(5660300001)(6116002)(102836003)(3846002)(33656002)(68736007)(99286004)(54906003)(8936002)(316002)(2900100001)(53546010)(110136005)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR0701MB2177; H:AM4PR0701MB2177.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: c92cf650-e947-44b6-b47e-08d53cfd5393 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 23:01:46.8437 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0701MB2177 Archived-At: Subject: Re: [sfc] WG Adoption calls: two MD-1 drafts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 23:01:52 -0000 + 1 . Support for both. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Thursday, November 30, 2017 10:40 AM To: Sumandra Majee Cc: Joel M. Halpern ; sfc@ietf.org Subject: Re: [sfc] WG Adoption calls: two MD-1 drafts +1 > On Nov 29, 2017, at 4:55 PM, Sumandra Majee wrote: >=20 > I support both. >=20 > On 11/29/17, 1:19 PM, "sfc on behalf of Joel M. Halpern" wrote: >=20 > EXTERNAL MAIL: sfc-bounces@ietf.org >=20 > The WG chairs have been asked to issue calls for adoption for two of t= he=20 > MD-1 related drafts: >=20 > https://datatracker.ietf.org/doc/draft-napper-sfc-nsh-broadband-alloca= tion/ >=20 > and >=20 > https://datatracker.ietf.org/doc/draft-guichard-sfc-nsh-dc-allocation/ >=20 > These documents aim for publication as Informational RFCs. >=20 > As Jim is the coauthor on one of these two, I will be overseeing both= =20 > adoption calls. >=20 > Given that there are two last calls an two calls for working group=20 > adoption (see following emails) we are allowing 3 weeks for these call= s. >=20 > Please respond with either support or objection to the WG adopting=20 > either or both of these documents. >=20 > We need to see feedback. Silence does not imply consent. > We would prefer feedback with content. >=20 > Thank you, > Joel >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Dec 7 10:36:50 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 619C71294C8 for ; Thu, 7 Dec 2017 10:36:48 -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 uKC3UEXcsaD7 for ; Thu, 7 Dec 2017 10:36:45 -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 795D2127076 for ; Thu, 7 Dec 2017 10:36:44 -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 vB7IadwW001626; Thu, 7 Dec 2017 18:36:39 GMT Received: from 950129200 (86.167.112.87.dyn.plus.net [87.112.167.86]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id vB7IabE7001615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Dec 2017 18:36:38 GMT Reply-To: From: "Adrian Farrel" To: Cc: "'Joel M. Halpern'" , References: <787AE7BB302AE849A7480A190F8B93300A083F0A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A083F0A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 7 Dec 2017 18:36:35 -0000 Message-ID: <0b0401d36f8a$5027ec40$f077c4c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGU43HvhltzE+f9gyKRxwh2Tk9cFQJEuGH5o6MPaiA= X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23516.001 X-TM-AS-Result: No--10.563-10.0-31-10 X-imss-scan-details: No--10.563-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtGnykMun0J1wvHkpkyUphL96Jj6zYvfFAS/7bplhbPCQl3Q C/C5s0Zqo1rqzSpfPGeKTJY+ujYA+wtrOhDKumbSc2k2agnXN3xWjiXAsVR2K/3y7vT+lH0atx6 Lm/haEDw/pLox9E3aFJ29frqI6SG4QxH9l0xFZgY+bWumFri5Ns2FT6fvYjF56NfipxutJCcMeO Grg7Du7eAIPavt8B40RdAlp93HnNxFc1/V5NDSmx3EEAbn+GRbqvngOPHC025/tE9YIUrwYpRw0 1+QWTH6nWZq7hnNNXLKKSzkwPlvfyyTPIfegtsCwCZxkTHxccl/r8x3wtvaX/EKW0p+7bPUQfXe xN3meZCAWGuIV58l+sr9lWA66QxJwp5rCVeeTwt6pWmpFd8o3qTYf9v9flolDO+DX+rUwfbjUY3 v01SjIpCE3eXvInzph/yc/3aRpLIIG2bw0ozA5FFgymyXggMtnIM/WutR2+FJJReS9JUB3ABQ/e jtTzH4bWBuJyZ5NdrbddDw2XqQ5c6hWYVCvCyENlkA5i6kjNohwKIIdklOV+od133eVWP4RFc/M wCIIKXhBj/QBdt7EBd4yv4zZ8fg/OniQCRJsWXEUtKW4jnym6zvhlKlKrMoVz8J52OVy+QZEIpX HlCzCWqCg3StfN26wXh74ymy3HtzsdpjeK5GU0fhraIl1XgxTJDl9FKHbrlNExcPtOYyHNeul29 /x8ODSgIXuHwIeJvLfU27AwtXMripXGIeTEfEj5hLPCX3ZdO/yN2q8U674kUNHQAoZf5cUEAlsX 5jhz9ny4qsQ7MHUy1x/RP04+WYIL3YP3hQHP6eAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtUZjP5KQLigq0vmUjecqRx/QlnT0eURcX8D4eCf9uufYr9M+xzRusxA== Archived-At: Subject: Re: [sfc] WG Last Call for draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 18:36:48 -0000 Hey Med, Thanks for the review. > Below some comments that can be easily addressed by Adrian. Yes. Easy. In line. > * Section 1: > > (1) nit: > > OLD: > Metadata may be used to enhance or enable the > function preformed by SFC-aware SFs, may enable coordination and data > ^^^^^^^^^^ > exchange between SFIs, or may be used to assist a network operator in > the diagnosis and monitoring of an SFP. > > NEW: > Metadata may be used to enhance or enable the > function performed by SFC-aware SFs, may enable coordination and data > exchange between SFIs, or may be used to assist a network operator in > the diagnosis and monitoring of an SFP. Nice :-) > (2) Insist this is not a new behavior: > > OLD: > Such packets are contained within the SFC-enabled domain. > NEW: > Like any NSH packets, such packets are contained > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > within the SFC-enabled domain. Ack > (3) Point to the section where same use cases are described: > > OLD: > 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. > > NEW: > 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 (refer to Section 5). > ^^^^^^^^^^^^^^^^^^^^ Something like that, yes. > (4) Delete this text: > > It is expected that other documents will > describe specific use cases in more detail and will define the > protocol mechanics for each use case. Is this harmful? I suppose it is apple pie. > (5) Add this text at the end of the section: > > NEW: > This document uses the terms defined in [RFC7665] and [I-D.ietf-sfc-nsh]. This is true and it is harmless to add it. Not sure it is necessary given the way the text is written, but I'll add it. > * Section 2: > > (1) Merge Sections 2 and 3 + change the title accordingly > > OLD: > The Network Service Header > > NEW: > Next Protocol 'None': Specification & Behavior I think I stick at this one. Merging the sections but not changing the text in any other way is just making a major section into a subsection. I don't see the value. OTOH, I like the separation as it stands. > (2) NSH is already cited in the document > > OLD: > The NSH is defined in [I-D.ietf-sfc-nsh]. It includes a field called > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > "Next Protocol" that is used to indicate the nature of the payload > > NEW: > > The NSH includes a field called "Next Protocol" that is used to > indicate the nature of the payload OK > (3) > > OLD: > This document defines a new value for the "Next Protocol" field. > > NEW: > This document defines TBD1 value for the "Next Protocol" field. OK. Needs a little more fiddling to fix up. > * Section 3: > > (1) > > OLD: > 3. Processing Rules > > NEW: > 2.2. Processing Rules As above. > (2) Before describing the processing behavior, the reader may first need to know > about the triggers for sharing such information. Please position this two > paragraphs at the beginning of the section: > > A packet with no payload data may be inserted at the head end of an > SFP (such as at a Classifier) and may be easily forwarded by an SFF > or SFI on the SFP using the processing rules defined in > [I-D.ietf-sfc-nsh]. > > A packet with no payload may also be generated by an SFC-aware SFI as > a result of processing an incoming packet (i.e., triggered by a > condition arising from processing a normal NSH packet with a > payload). In such cases, the SPI/SI can be inherited from the > original packet or can be set according to information supplied > through the control plane, or management plane, or indicated by > information carried in the metadata of the data packet. This > document does not further specify the triggers to generate an NSH > packet with a "Next Protocol" set to "None". Yeah, that works. > (3) Insert this NEW text right after the first two ones: Some setup is needed > before a node can generate a packet with None: > > NEW: > An SFC-aware node may be instructed by the control plane about > the conditions under which such packets are to be generated. > Further, the control plane is responsible for providing the required > information to generate the corresponding NSH packet (e.g., SFP > Identifier to use, TTL). I agree that these are possible scenarios, but there are many others. I could add this as an example of how stuff might be, but that leaves me wondering how many other examples I'd need to add. I prefer to leave this as an exercise for the implementer - it is also dependent on the use case. > (4) Update this text to insist that one or multiple piece of metadata can be > inserted: > > OLD: > o MUST create a packet carrying an NSH and the desired metadata > > NEW: > o MUST create a packet carrying an NSH and the desired metadata; one or > more metadata fields may be included. What is a "metadata field"? I went back to draft-ietf-sfc-nsh and I think the grammar is correct. > (5) > > A transit node (SFF, SFI, or Classifier) receiving a packet with > "Next Protocol" indicating "None" MUST NOT attempt to parse or > process beyond the end of the NSH, but SHOULD process the NSH and the > metadata as normal. > > I wonder whether "normal" can be expanded a little bit here. For example, > indicate what to do if an intermediate node is instructed to strip a metadata, and > no metadata field is left. Should the packet be forward even if no metadata field > is included of it should stop forwarding. Yes, we can add that case. Any other cases on your mind? > (6) Add this text at the end of the section: > > NEW: > In deployments where Next-Protocol "None" is not desired, > administrators SHOULD instruct SFC-aware nodes to discard > packets with Next-Protocol "None". Would it be better to have... In deployments where use of Next-Protocol "None" is not desired, administrators SHOULD instruct SFC-aware nodes to not create such packets and to discard packets with Next- Protocol "None". > * Section 6 > > (1) Simplify this text: > > OLD: > > The procedures for handling NSH fields with unknown values are set > out in [I-D.ietf-sfc-nsh]. In particular, section 2.2 of > [I-D.ietf-sfc-nsh] describes how elements of an SFC enabled network > handle unknown values of the "Next Protocol" field. > > SFC-aware nodes that do not understand the meaning of a value > contained in the "Next Protocol" field of the NSH are unable to parse > the payload. Such nodes silently drop packets with unknown "Next > Protocol" values unless explicitly configured to forward them. > > NEW: > > SFC-aware nodes that do not understand the meaning of a value > contained in the "Next Protocol" field of the NSH are unable to parse > the payload. Such nodes silently drop packets with unknown "Next > Protocol" values unless explicitly configured to forward them > (Section 2.2 of [I-D.ietf-sfc-nsh]). OK > (2) > > o SFC Proxies will drop the packets > > o SFIs will most likely drop the packets > > - Use the same wording for SFC-aware SFs and SFC proxies given that both can > update/insert/strip metadata. This isn't about metadata, it's about unknown Next Protocol values. So an SFC Proxy exists to protect the non-SFC-aware SFI, so it really will drop the packets and would never be configured to pass packets to the SFI. But an SFC-aware SFI acts to protect itself so it can handle unknown Next Protocol values any way it wants and it *might* be configured (for some SFs) to simply 'forward' them back to the SFF. I think the text stands. > (3) > > o Reclassifiers will most likely drop the packets > > - Purely speaking, these are classifiers according to the SFC architecture. Yeah. But really? Do we write "Classifiers or functions of other components that provide non-initial classification (or reclassification)"? :-) > (4) Not sure to understand this text: > > It is a > general processing rule for all forwarders that they SHOULD NOT > attempt to send packets with zero length, and packets with the NSH > "Next Protocol" set to "None" are expected to have zero payload > length. How about... It is a general processing rule for all packet forwarding engines that they should not attempt to send packets with zero length. Packets with the NSH "Next Protocol" field set to "None" are expected to have zero payload length and so should not be forwarded once the NSH has been stripped. > (5) Please delete this text: > > In any case, SFC-aware nodes at the end of an SFP MUST NOT > forward packets with "Next Protocol" set to "None". > > Because it is redundant with the text in Section 3: > > Such nodes MUST NOT forward packets with "Next Protocol" > indicating "None" even if there are some bytes after the NSH. Hmm, can't say it often enough :-) But will make this: In any case, as noted in Section 3, SFC-aware nodes at the end of an SFP do not forward packets with "Next Protocol" set to "None". > * Section 5: > > (1) Please add this text as a preamble: Communicating the exact value of a given > context information is only one step in the process. Some setup is required to > instruct SFC-aware nodes about allowed context information to share, how to > consume it, what do after consuming it, and so on. > > NEW: > As discussed in [I-D.ietf-sfc-control-plane], the control plane is > responsible for instructing SFC-aware nodes about the metadata allowed > for a given SFP, the semantic of such data, the behavior to follow > after consuming metadata, the order of processing metadata, etc. > Such considerations are assumed to be in place within an SFC-enabled > domain. The following focuses on the provisioning of allowed metadata > values for a given SFP. But this is not the only case. It is perfectly possible that an SFC aware node (e.g., an SFI) is built to know what metadata to create without requiring interference from a control plane. Anyway, I hope that this document doesn't need to discuss all of the application scenarios of metadata. > * Section 5.1: the metadata can be provisioned on other nodes than an SFC- > aware SF: > > OLD: > Per-SFP metadata is metadata that applies to an SFP and any data > packets on that SFP. It does not need to be transmitted with every > packet, but can be installed at the SFIs on the SFP and applied to > all packets on the SFP. It could be installed by inclusion in the > NSH of a data packet sent on the SFP, by out of band control or > management plane mechanisms, or by separate metadata-only packets > using "Next Protocol" set to "None" as described in this document. > > Per-SFP metadata-only packets may be sent along the path of an SFP > simply by setting the correct SPI in the NSH, and setting the SI to > the correct value for the hop of the SFP at which the metadata is to > be introduced. Classifiers and reclassifiers will know the correct > SI values to be used from information supplied by the control or > management plane as is the case for NSH packets with payload data. > > NEW: > Per-SFP metadata are metadata that apply to an SFP and any data > ^^^^ ^^^^^^ > packets bound to that SFP. It do not need to be transmitted with every > ^^ > packet, but can be provisioned on the classifier, SFC-aware SFs, and SFC-aware > proxies for this SFP and applied to > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^^^^^^^^ > all packets on the SFP. It could be provisioned by inclusion in the > ^^^^^^^^^^^ > NSH of a data packet sent on the SFP, by out of band control or > management plane mechanisms, or by separate metadata-only packets > using "Next Protocol" set to "None" as described in this document. > > > Per-SFP metadata-only packets may be sent along the path of an SFP > by setting the correct SPI in the NSH, and setting the SI to > the correct value for the hop of the SFP at which the metadata is to > be introduced. SFC-aware nodes (e.g., Classifiers) will know the correct > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > SI values to be used from information supplied by the control or > management plane as is the case for NSH packets with payload data. This brings up two issues: one big and one small. The small one is the use of the singular for "metadata". You are, of course, correct for "proper English", but fortunately English is a living language and "data" is now used as a singular noun. The larger issue is, I think, is a confusion. What this text is talking about is installing the metadata at the point of consumption, not at the point of injection. My understanding of metadata is that it is consumed only at SFIs. > * Section 5.2: Idem as Section 5.1 > > * Section 5.6: > > OLD: > Per-packt metadata is metadata that applies specifically to a single > ^^^^^^ ^^ ^^^^^^^^ > payload packet. It informs an SFI how to handle the payload packet, > and does not apply to any other packet. > > The mechanisms described in this document are not applicable to per- > ^ ^^^^ > packet metadata because, by definition, if the "Next Protocol" > indicates "None" then there is no packet following the NSH for the > metadata to be associated with. > > NEW: > Per-packet metadata are metadata that apply specifically to a single > payload packet. It informs an SFI how to handle the payload packet, > and does not apply to any other packet. > > Evidently, the mechanism described in this document is not applicable to per- > ^^^^^^^^^^ > packet metadata because, by definition, if the "Next Protocol" > indicates "None" then there is no packet following the NSH for the > metadata to be associated with. Rule#97 of "How to write good text" says that you should never say "evidently" or "obviously" in case you insult your reader. :-) > * Section 6: SHOULD be would be more appropriate here: > > OLD: > The amount of packets with "Next Protocol" set to "None" on an SFP > MAY be rate limited at any point on the SFP to provide additional > security. > > NEW: > The amount of packets with "Next Protocol" set to "None" on an SFP > SHOULD be rate limited at any point on the SFP to provide additional > security. While I sympathise, I don't know that "SHOULD...at any point" has meaning. We can have "MAY...at any point" or "SHOULD...at every point." The latter, however, sounds pretty heavy: is it what you meant? > * Section 7: > > OLD: > > IANA has been requested to create a registry of "Next Protocol" > values in [I-D.ietf-sfc-nsh]. This document requests IANA to > allocate a value from that registry to indicate "None" (TBD1 in this > document). > > It is strongly suggested that a value of 0 (zero) be assigned. > > NEW: > > This document requests IANA to allocate a value from the > "NSH Next Protocol" registry at > https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol > (TBD1 in this document): > > Next Protocol Description Reference > 0x00 None [This-Document] Good that the registry has now been set up, and yes we should now reference it. However, we cannot demand the value zero like this. Best, Adrian From nobody Thu Dec 7 13:24: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 5052D128796 for ; Thu, 7 Dec 2017 13:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCH3Bznpm8fE for ; Thu, 7 Dec 2017 13:24:55 -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 24442127B57 for ; Thu, 7 Dec 2017 13:24:54 -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 vB7LOqR3022442; Thu, 7 Dec 2017 21:24:53 GMT Received: from 950129200 (86.167.112.87.dyn.plus.net [87.112.167.86]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id vB7LOpla022436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Dec 2017 21:24:52 GMT Reply-To: From: "Adrian Farrel" To: "'Dave Dolson'" Cc: "'Joel M. Halpern'" , References: In-Reply-To: Date: Thu, 7 Dec 2017 21:24:49 -0000 Message-ID: <0b6901d36fa1$d0a26dc0$71e74940$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGU43HvhltzE+f9gyKRxwh2Tk9cFQJmyyPwo6I9XHA= X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23516.003 X-TM-AS-Result: No--13.799-10.0-31-10 X-imss-scan-details: No--13.799-10.0-31-10 X-TMASE-MatchedRID: QfHZjzml1E+0/JWJqIoqpvHkpkyUphL9Vo4lwLFUdisBymvQWybtVaAL SYA7O2t7uAsML43hVSmTwJ3fa2PywbsIK8rkMIDhuIwLnB3Aqp39GaYSzB/shzI1sOM1H0F49qr OQOVViYfT3Vc/d8FbxLDg+Q5pepZ7NgyelB4Yx0JIRA38P/dwbuiY+s2L3xQEI/wYF6KKoMNIuD exIJcYol43UEjf6XzZ9dWG1pHE9POuLPMG9yAXPGgws6g0ewz2ZhJeJk69iY+5IifwYL1+q/O+m s5efpt74vM1YF6AJbZcLc3sLtjOt+TCMddcL/gjOwBXM346/+zRN4jMt71Uic/wk7E0AXLzI4wW JUC/8b52/z0LeTJwISDLiKuBEROU Archived-At: Subject: Re: [sfc] WG Last Call for draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 21:24:57 -0000 OK Dave, that text needs clearing up. > I also support WGLC. > > However, I found the intended behavior of service functions (SFIs) to be a bit > difficult to understand. > I believe the intent is to leave it free to the implementer and operator (per "local > policy"), but I feel like I had to read between the lines. > > Could we add a paragraph like this somewhere in section 3? > > NEW: > For backwards compatibility, SFIs are permitted to discard payload-none NSH > packets. However, SFIs SHOULD forward payload-none NSH packets (according > to the normal rules of decrementing SI and sending to SFF). Furthermore, SFIs > MAY utilize or augment the metadata in payload-none packets. The norm is that a document describes what you have to do to conform to the specification, and if there is prior deployment, it describes how interworking works for backward compatibility. So, Section 3 describes how to conform to this spec, and Section 4 describes backward compatibility. We can add some clarity as follows: At the top Section 3... OLD An SFC-aware node wishing to send metadata without a data packet: NEW An SFC-aware node wishing to send metadata without a data packet (i.e., a node that conforms to this specification): END Halfway down Section 3 OLD A transit node (SFF, SFI, or Classifier) receiving a packet with "Next Protocol" indicating "None" MUST NOT attempt to parse or process beyond the end of the NSH, but SHOULD process the NSH and the metadata as normal. NEW A transit node (SFF, SFI, or Classifier) that conforms to this specification and that receives a packet with "Next Protocol" indicating "None" MUST NOT attempt to parse or process beyond the end of the NSH, but SHOULD process the NSH and the metadata as normal. Processing for nodes that do not support "Next Protocol" set to "None" is described in Section 4. END Cheers, Adrian From nobody Thu Dec 7 14:58:52 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 7ABA61294F5 for ; Thu, 7 Dec 2017 14:58:50 -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 SZYOFPr0vMos for ; Thu, 7 Dec 2017 14:58:48 -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 20C2C1294EC for ; Thu, 7 Dec 2017 14:58:47 -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 vB7Mwiu3008740; Thu, 7 Dec 2017 22:58:44 GMT Received: from 950129200 (86.167.112.87.dyn.plus.net [87.112.167.86]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id vB7MwgiL008722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Dec 2017 22:58:43 GMT Reply-To: From: "Adrian Farrel" To: "'Greg Mirsky'" Cc: , "'Joel M. Halpern'" References: In-Reply-To: Date: Thu, 7 Dec 2017 22:58:40 -0000 Message-ID: <0b7901d36fae$ed0dbed0$c7293c70$@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 Content-Language: en-gb Thread-Index: AQGU43HvhltzE+f9gyKRxwh2Tk9cFQHTl8GFo6bgWuA= X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23516.003 X-TM-AS-Result: No--23.095-10.0-31-10 X-imss-scan-details: No--23.095-10.0-31-10 X-TMASE-MatchedRID: gzVbiXtWD9unykMun0J1wvHkpkyUphL9fkuZtv/FS5ruIAGP6QNSBQLy tDvV39h+CBH8phTrelJmzNP6yGlNFRIe6pduS+SAKhQHv3RCSeqimsR6hkcJAiWcG+dmvvoSjNE THH9N9TaBPv0CuwLicG4XysktKPJmQdZuZ42vrpFIRA38P/dwbiQqzcugG1CVgu7iPHqZqrBHOQ POaU2nWM8TMW3pdQwJT5M/Xc1IPDfU4ZeEAUvDy0Zakoam9+aelnrMq7Sriu2Yu+v96IY4TmE5N 3EsI8/SiJHU6vx+MjvdUVNqwKIcOQtrOhDKumbSV9LwT29+rzaPmFSaq6xM+Nx5dDqraCBKXEVh moR51hSyOl2uFUsM9VhuLu0gwK9g4sTHwrlKYdmUa50su1E7W+iY+s2L3xQEmP1Huhu1yDLy67H GlbS8BDavJQE20SDbpSRxkLnMC7DLz1mIn0LQ/c+ayFtEW0uYveCbyZ3xax5F+YXPIqAdvvO+ms 5efpt7585VzGMOFzABi3kqJOK62QtuKBGekqUpPjKoPgsq7cA= Archived-At: Subject: Re: [sfc] WG Last Call for draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 22:58:50 -0000 Hi Greg, Thanks for this. > I am glad that this document has been WG LC'ed. I support progressing = it but > have reservations about section 5.4 that discusses use of None value = in OAM. Yes. The discussion of SFC OAM has come on a bit recently. > Below are my comments to the section 5,4: > > "If OAM information is carried in packets that also include payload > data, that information must be carried in metadata." > > As noted in section 4 of draft-brockners-sfc-ioam-nsh, authors = consider > encapsulating iOAM data after the SFC NSH using iOAM protcol type. And > what is 'must' in this statement - normative or mere observation? Yeah, maybe I was sloppy in my use of "metadata". However I think I = stand by what is written maybe with s/must be/is/. That is, it is = neither protocol header in the SFC layer nor payload, so it is = "metadata". Yes, I think iOAM is metadata. But obviously not NSH metadata. I don't want to get into the debate (here) about the problems of using = Next Protocol =3D=3D iOAM when there is data present, or the preferable = action of defining a T2 metadata TLV to contain the iOAM stuff, or = anything else about iOAM. Anyway, the way we should cover this is... "If OAM information is carried in packets that also include payload = data, that information may be carried in metadata between the NSH and = the payload." > "Sending OAM separate from (but interleaved with) packets that carry > payload data ..." > This is the case when specially constructed test packets injected in = the network solely > for purpose of performing OAM functions, e.g. performance measurement. = This is > active OAM, according to RFC 7799, and, as discussed in = draft-wang-sfc-multi-layer-oam > and presented in the meeting in Singapore, there are different ways to = perform active > OAM over SFC NSH domain. Because progress of = draft-wang-sfc-multi-layer-oam and > other active SFC OAM drafts is awaiting new charter of the SFC WG, = including None > protocol solution in standard RFC, in my opinion, creates unnecessary = and unhelpful > multiplicity of options that will complicate implementations and may = cause interoperability > issues. All of that may be avoided if authors decide to take the = section 5.4 out from the > document and have the discussion of active OAM in scope of discussion = of > draft-wang-sfc-multi-layer-oam. Why debate today that which can usefully be put off until tomorrow? Now, I know that this document was not adopted by the WG, but it is a = bit harsh to cite another individual draft as reasoning for changing = this document. As we have known for some time, we have a multiplicity of ways to = indicate the presence of OAM, and no clarity in the WG. = draft-wang-sfc-multi-layer-oam has a neat solution to reducing the = number of mechanisms by requiring that two are used at once :-) But it is not my intention to define how OAM is performed in an NSH = network, just to show how it might be performed. What if we soften the language by adding a paragraph such as: "Mechanisms for providing active OAM [RFC7799] in an SFC network have = been proposed [I-D.wang-sfc-multi-layer-oam]. This use case is not = intended to define another mechanism for active OAM, but does illustrate = a further option for discussion by the working group." Cheers, Adrian From nobody Thu Dec 7 23:35: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 E67FD124BE8 for ; Thu, 7 Dec 2017 23:35:28 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zVwWzUeGZIlm for ; Thu, 7 Dec 2017 23:35:26 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390D01200F1 for ; Thu, 7 Dec 2017 23:35:26 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 865D3C0EAA; Fri, 8 Dec 2017 08:35:24 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 5C38820081; Fri, 8 Dec 2017 08:35:24 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0361.001; Fri, 8 Dec 2017 08:35:24 +0100 From: To: "adrian@olddog.co.uk" CC: "'Joel M. Halpern'" , "sfc@ietf.org" Thread-Topic: [sfc] WG Last Call for draft-farrel-sfc-convent Thread-Index: AQGU43HvhltzE+f9gyKRxwh2Tk9cFQJEuGH5o6MPaiCAAO8BUA== Date: Fri, 8 Dec 2017 07:35:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A093FB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A083F0A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0b0401d36f8a$5027ec40$f077c4c0$@olddog.co.uk> In-Reply-To: <0b0401d36f8a$5027ec40$f077c4c0$@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.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG Last Call for draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 07:35:29 -0000 Hi Adrian,=20 Thank you for the follow-up. Below to clarifications from my side: - by metadata fields I meant "Context Header(s)". - You said: "My understanding of metadata is that it is consumed only at SF= Is". Actually context headers can be added/striped/modified by other elemen= ts. Please refer to this table: +-----------+-----------------------+-------+---------------+-------+ | | Insert, remove, or |Forward| Update |Service| | | replace the NSH |the NSH| the NSH |policy | | | |Packets| |sel. | |Component +-------+-------+-------+ +-------+-------+ | | | | | | |Dec. |Update | | | |Insert |Remove |Replace| |Service|Context| | | | | | | |Index |Header | | +-----------+-------+-------+-------+-------+-------+-------+-------+ | | + | | + | | | + | | |Classifier | | | | | | | | +-----------+-------+-------+-------+-------+-------+-------+-------+ |Service | | + | | + | | | | |Function | | | | | | | | |Forwarder | | | | | | | | |(SFF) | | | | | | | | +-----------+-------+-------+-------+-------+-------+-------+-------+ |Service | | | | | + | + | + | |Function | | | | | | | | |(SF) | | | | | | | | +-----------+-------+-------+-------+-------+-------+-------+-------+ | | + | + | | | + | + | | |SFC Proxy | | | | | | | | +-----------+-------+-------+-------+-------+-------+-------+-------+ Cheers, Med > -----Message d'origine----- > De=A0: Adrian Farrel [mailto:adrian@olddog.co.uk] > Envoy=E9=A0: jeudi 7 d=E9cembre 2017 19:37 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: 'Joel M. Halpern'; sfc@ietf.org > Objet=A0: RE: [sfc] WG Last Call for draft-farrel-sfc-convent >=20 > Hey Med, >=20 > Thanks for the review. >=20 > > Below some comments that can be easily addressed by Adrian. >=20 > Yes. Easy. In line. >=20 > > * Section 1: > > > > (1) nit: > > > > OLD: > > Metadata may be used to enhance or enable the > > function preformed by SFC-aware SFs, may enable coordination and dat= a > > ^^^^^^^^^^ > > exchange between SFIs, or may be used to assist a network operator i= n > > the diagnosis and monitoring of an SFP. > > > > NEW: > > Metadata may be used to enhance or enable the > > function performed by SFC-aware SFs, may enable coordination and dat= a > > exchange between SFIs, or may be used to assist a network operator i= n > > the diagnosis and monitoring of an SFP. >=20 > Nice :-) >=20 > > (2) Insist this is not a new behavior: > > > > OLD: > > Such packets are contained within the SFC-enabled domain. > > NEW: > > Like any NSH packets, such packets are contained > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > within the SFC-enabled domain. >=20 > Ack >=20 > > (3) Point to the section where same use cases are described: > > > > OLD: > > 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. > > > > NEW: > > 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 (refer to Section 5). > > ^^^^^^^^^^^^^^^^^^^^ >=20 > Something like that, yes. >=20 > > (4) Delete this text: > > > > It is expected that other documents will > > describe specific use cases in more detail and will define the > > protocol mechanics for each use case. >=20 > Is this harmful? I suppose it is apple pie. >=20 > > (5) Add this text at the end of the section: > > > > NEW: > > This document uses the terms defined in [RFC7665] and [I-D.ietf-sfc- > nsh]. >=20 > This is true and it is harmless to add it. Not sure it is necessary given > the > way the text is written, but I'll add it. >=20 > > * Section 2: > > > > (1) Merge Sections 2 and 3 + change the title accordingly > > > > OLD: > > The Network Service Header > > > > NEW: > > Next Protocol 'None': Specification & Behavior >=20 > I think I stick at this one. Merging the sections but not changing the > text in > any other way is just making a major section into a subsection. I don't > see the > value. > OTOH, I like the separation as it stands. >=20 > > (2) NSH is already cited in the document > > > > OLD: > > The NSH is defined in [I-D.ietf-sfc-nsh]. It includes a field calle= d > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > "Next Protocol" that is used to indicate the nature of the payload > > > > NEW: > > > > The NSH includes a field called "Next Protocol" that is used to > > indicate the nature of the payload >=20 > OK >=20 > > (3) > > > > OLD: > > This document defines a new value for the "Next Protocol" field. > > > > NEW: > > This document defines TBD1 value for the "Next Protocol" field. >=20 > OK. Needs a little more fiddling to fix up. >=20 > > * Section 3: > > > > (1) > > > > OLD: > > 3. Processing Rules > > > > NEW: > > 2.2. Processing Rules >=20 > As above. >=20 > > (2) Before describing the processing behavior, the reader may first nee= d > to > know > > about the triggers for sharing such information. Please position this > two > > paragraphs at the beginning of the section: > > > > A packet with no payload data may be inserted at the head end of an > > SFP (such as at a Classifier) and may be easily forwarded by an SFF > > or SFI on the SFP using the processing rules defined in > > [I-D.ietf-sfc-nsh]. > > > > A packet with no payload may also be generated by an SFC-aware SFI a= s > > a result of processing an incoming packet (i.e., triggered by a > > condition arising from processing a normal NSH packet with a > > payload). In such cases, the SPI/SI can be inherited from the > > original packet or can be set according to information supplied > > through the control plane, or management plane, or indicated by > > information carried in the metadata of the data packet. This > > document does not further specify the triggers to generate an NSH > > packet with a "Next Protocol" set to "None". >=20 > Yeah, that works. >=20 > > (3) Insert this NEW text right after the first two ones: Some setup is > needed > > before a node can generate a packet with None: > > > > NEW: > > An SFC-aware node may be instructed by the control plane about > > the conditions under which such packets are to be generated. > > Further, the control plane is responsible for providing the required > > information to generate the corresponding NSH packet (e.g., SFP > > Identifier to use, TTL). >=20 > I agree that these are possible scenarios, but there are many others. >=20 > I could add this as an example of how stuff might be, but that leaves me > wondering how many other examples I'd need to add. I prefer to leave this > as an > exercise for the implementer - it is also dependent on the use case. >=20 > > (4) Update this text to insist that one or multiple piece of metadata > can be > > inserted: > > > > OLD: > > o MUST create a packet carrying an NSH and the desired metadata > > > > NEW: > > o MUST create a packet carrying an NSH and the desired metadata; on= e > or > > more metadata fields may be included. >=20 > What is a "metadata field"? I went back to draft-ietf-sfc-nsh and I think > the > grammar is correct. >=20 > > (5) > > > > A transit node (SFF, SFI, or Classifier) receiving a packet with > > "Next Protocol" indicating "None" MUST NOT attempt to parse or > > process beyond the end of the NSH, but SHOULD process the NSH and th= e > > metadata as normal. > > > > I wonder whether "normal" can be expanded a little bit here. For > example, > > indicate what to do if an intermediate node is instructed to strip a > metadata, > and > > no metadata field is left. Should the packet be forward even if no > metadata > field > > is included of it should stop forwarding. >=20 > Yes, we can add that case. > Any other cases on your mind? >=20 > > (6) Add this text at the end of the section: > > > > NEW: > > In deployments where Next-Protocol "None" is not desired, > > administrators SHOULD instruct SFC-aware nodes to discard > > packets with Next-Protocol "None". >=20 > Would it be better to have... >=20 > In deployments where use of Next-Protocol "None" is not > desired, administrators SHOULD instruct SFC-aware nodes to > not create such packets and to discard packets with Next- > Protocol "None". >=20 > > * Section 6 > > > > (1) Simplify this text: > > > > OLD: > > > > The procedures for handling NSH fields with unknown values are set > > out in [I-D.ietf-sfc-nsh]. In particular, section 2.2 of > > [I-D.ietf-sfc-nsh] describes how elements of an SFC enabled network > > handle unknown values of the "Next Protocol" field. > > > > SFC-aware nodes that do not understand the meaning of a value > > contained in the "Next Protocol" field of the NSH are unable to pars= e > > the payload. Such nodes silently drop packets with unknown "Next > > Protocol" values unless explicitly configured to forward them. > > > > NEW: > > > > SFC-aware nodes that do not understand the meaning of a value > > contained in the "Next Protocol" field of the NSH are unable to pars= e > > the payload. Such nodes silently drop packets with unknown "Next > > Protocol" values unless explicitly configured to forward them > > (Section 2.2 of [I-D.ietf-sfc-nsh]). >=20 > OK >=20 > > (2) > > > > o SFC Proxies will drop the packets > > > > o SFIs will most likely drop the packets > > > > - Use the same wording for SFC-aware SFs and SFC proxies given that bot= h > can > > update/insert/strip metadata. >=20 > This isn't about metadata, it's about unknown Next Protocol values. > So an SFC Proxy exists to protect the non-SFC-aware SFI, so it really wil= l > drop > the packets and would never be configured to pass packets to the SFI. > But an SFC-aware SFI acts to protect itself so it can handle unknown Next > Protocol values any way it wants and it *might* be configured (for some > SFs) to > simply 'forward' them back to the SFF. >=20 > I think the text stands. >=20 > > (3) > > > > o Reclassifiers will most likely drop the packets > > > > - Purely speaking, these are classifiers according to the SFC > architecture. >=20 > Yeah. > But really? Do we write "Classifiers or functions of other components tha= t > provide non-initial classification (or reclassification)"? :-) >=20 > > (4) Not sure to understand this text: > > > > It is a > > general processing rule for all forwarders that they SHOULD NOT > > attempt to send packets with zero length, and packets with the NSH > > "Next Protocol" set to "None" are expected to have zero payload > > length. >=20 > How about... >=20 > It is a general processing rule for all packet forwarding engines tha= t > they should not attempt to send packets with zero length. Packets > with the NSH "Next Protocol" field set to "None" are expected to > have zero payload length and so should not be forwarded once the > NSH has been stripped. >=20 > > (5) Please delete this text: > > > > In any case, SFC-aware nodes at the end of an SFP MUST NOT > > forward packets with "Next Protocol" set to "None". > > > > Because it is redundant with the text in Section 3: > > > > Such nodes MUST NOT forward packets with "Next Protocol" > > indicating "None" even if there are some bytes after the NSH. >=20 > Hmm, can't say it often enough :-) > But will make this: >=20 > In any case, as noted in Section 3, SFC-aware nodes at the end > of an SFP do not forward packets with "Next Protocol" set to > "None". >=20 > > * Section 5: > > > > (1) Please add this text as a preamble: Communicating the exact value o= f > a > given > > context information is only one step in the process. Some setup is > required to > > instruct SFC-aware nodes about allowed context information to share, ho= w > to > > consume it, what do after consuming it, and so on. > > > > NEW: > > As discussed in [I-D.ietf-sfc-control-plane], the control plane is > > responsible for instructing SFC-aware nodes about the metadata > allowed > > for a given SFP, the semantic of such data, the behavior to follow > > after consuming metadata, the order of processing metadata, etc. > > Such considerations are assumed to be in place within an SFC- > enabled > > domain. The following focuses on the provisioning of allowed > metadata > > values for a given SFP. >=20 > But this is not the only case. It is perfectly possible that an SFC aware > node > (e.g., an SFI) is built to know what metadata to create without requiring > interference from a control plane. >=20 > Anyway, I hope that this document doesn't need to discuss all of the > application > scenarios of metadata. >=20 > > * Section 5.1: the metadata can be provisioned on other nodes than an > SFC- > > aware SF: > > > > OLD: > > Per-SFP metadata is metadata that applies to an SFP and any data > > packets on that SFP. It does not need to be transmitted with every > > packet, but can be installed at the SFIs on the SFP and applied to > > all packets on the SFP. It could be installed by inclusion in the > > NSH of a data packet sent on the SFP, by out of band control or > > management plane mechanisms, or by separate metadata-only packets > > using "Next Protocol" set to "None" as described in this document. > > > > Per-SFP metadata-only packets may be sent along the path of an SFP > > simply by setting the correct SPI in the NSH, and setting the SI to > > the correct value for the hop of the SFP at which the metadata is to > > be introduced. Classifiers and reclassifiers will know the correct > > SI values to be used from information supplied by the control or > > management plane as is the case for NSH packets with payload data. > > > > NEW: > > Per-SFP metadata are metadata that apply to an SFP and any data > > ^^^^ ^^^^^^ > > packets bound to that SFP. It do not need to be transmitted with > every > > ^^ > > packet, but can be provisioned on the classifier, SFC-aware SFs, and > SFC-aware > > proxies for this SFP and applied to > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ^^^^^^^^^^^^ > > all packets on the SFP. It could be provisioned by inclusion in the > > ^^^^^^^^^^^ > > NSH of a data packet sent on the SFP, by out of band control or > > management plane mechanisms, or by separate metadata-only packets > > using "Next Protocol" set to "None" as described in this document. > > > > > > Per-SFP metadata-only packets may be sent along the path of an SFP > > by setting the correct SPI in the NSH, and setting the SI to > > the correct value for the hop of the SFP at which the metadata is to > > be introduced. SFC-aware nodes (e.g., Classifiers) will know the > correct > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > SI values to be used from information supplied by the control or > > management plane as is the case for NSH packets with payload data. >=20 > This brings up two issues: one big and one small. >=20 > The small one is the use of the singular for "metadata". You are, of > course, > correct for "proper English", but fortunately English is a living languag= e > and > "data" is now used as a singular noun. >=20 > The larger issue is, I think, is a confusion. What this text is talking > about is > installing the metadata at the point of consumption, not at the point of > injection. My understanding of metadata is that it is consumed only at > SFIs. >=20 > > * Section 5.2: Idem as Section 5.1 > > > > * Section 5.6: > > > > OLD: > > Per-packt metadata is metadata that applies specifically to a single > > ^^^^^^ ^^ ^^^^^^^^ > > payload packet. It informs an SFI how to handle the payload packet, > > and does not apply to any other packet. > > > > The mechanisms described in this document are not applicable to per- > > ^ ^^^^ > > packet metadata because, by definition, if the "Next Protocol" > > indicates "None" then there is no packet following the NSH for the > > metadata to be associated with. > > > > NEW: > > Per-packet metadata are metadata that apply specifically to a single > > payload packet. It informs an SFI how to handle the payload packet, > > and does not apply to any other packet. > > > > Evidently, the mechanism described in this document is not applicabl= e > to > per- > > ^^^^^^^^^^ > > packet metadata because, by definition, if the "Next Protocol" > > indicates "None" then there is no packet following the NSH for the > > metadata to be associated with. >=20 > Rule#97 of "How to write good text" says that you should never say > "evidently" > or "obviously" in case you insult your reader. :-) >=20 > > * Section 6: SHOULD be would be more appropriate here: > > > > OLD: > > The amount of packets with "Next Protocol" set to "None" on an SFP > > MAY be rate limited at any point on the SFP to provide additional > > security. > > > > NEW: > > The amount of packets with "Next Protocol" set to "None" on an SFP > > SHOULD be rate limited at any point on the SFP to provide additional > > security. >=20 > While I sympathise, I don't know that "SHOULD...at any point" has meaning= . > We > can have "MAY...at any point" or "SHOULD...at every point." The latter, > however, > sounds pretty heavy: is it what you meant? >=20 > > * Section 7: > > > > OLD: > > > > IANA has been requested to create a registry of "Next Protocol" > > values in [I-D.ietf-sfc-nsh]. This document requests IANA to > > allocate a value from that registry to indicate "None" (TBD1 in this > > document). > > > > It is strongly suggested that a value of 0 (zero) be assigned. > > > > NEW: > > > > This document requests IANA to allocate a value from the > > "NSH Next Protocol" registry at > > https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol > > (TBD1 in this document): > > > > Next Protocol Description Reference > > 0x00 None [This-Document] >=20 > Good that the registry has now been set up, and yes we should now > reference it. >=20 > However, we cannot demand the value zero like this. >=20 > Best, > Adrian From nobody Mon Dec 11 12:13: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 97376128799 for ; Mon, 11 Dec 2017 12:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, 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 cyCvTvcnWpsi for ; Mon, 11 Dec 2017 12:13:17 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF64127077 for ; Mon, 11 Dec 2017 12:13:16 -0800 (PST) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 791B3F96CD6D4 for ; Mon, 11 Dec 2017 20:13:12 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 11 Dec 2017 20:13:13 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML702-CHM.china.huawei.com ([169.254.4.18]) with mapi id 14.03.0361.001; Mon, 11 Dec 2017 12:13:08 -0800 From: James N Guichard To: 'Service Function Chaining IETF list' CC: Alia Atlas Thread-Topic: SFC WG re-chartering - initial text for WG review/comment Thread-Index: AdNyuLcja4roriHRQZ67o9nPI1G8tQ== Date: Mon, 11 Dec 2017 20:13:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.179] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3134BDFE6sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [sfc] SFC WG re-chartering - initial text for WG review/comment X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 20:13:18 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3134BDFE6sjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings WG: Joel and I have taken an initial stab at new charter text for the SFC WG. P= lease review and provide comments/suggestions by COB Friday 29th December (= 2 weeks). Network operators frequently utilize service functions such as packet filte= ring at firewalls, load-balancing and transactional proxies (for example sp= am filters) in the delivery of services to end users. Delivery of these typ= es of services is undergoing significant change with the introduction of vi= rtualization, network overlays, and orchestration. The SFC Working Group has developed an Architecture [RFC 7665] and a protoc= ol (the Network Service Header [draft-ietf-sfc-nsh-28], in the RFC Editor q= ueue as of this drafting.) The focus of the SFC working group moving forward will be on aspects of the= architecture and/or protocol that need to be addressed to enable effective= deployment and usage of this work. The SFC working group will now begin a= ddressing those items. In order to maintain focus, the working group will = primarily produce and advance documents on four topics: 1) Metadata - we need to define the common type-length-value encoded metada= ta types with standards track RFCs, and produce informational RFCs to descr= ibe common fixed-length (MD-1) metadata usages. 2) Security - The completed work does not provide mechanisms for authentica= ting or protecting (either for integrity or from inspection) metadata. The= re are a number of open questions as to what can be effectively provided an= d how to provide such tools. These need attention. 3) OAM and O&M - In order for operators to use these tools in production ne= tworks, they need Operations, Administration, and Maintenance tools, as wel= l as management mechanisms. This includes YANG models, OAM frameworks, and= specific OAM mechanisms to address operational needs. 4) Transport Considerations - this will capture the expectations SFC places= on transport behavior, including dealing with issues such as congestion in= dications and responses. Specifically, the SFC WG is chartered to deliver the following: 1. A standards track base set of MD-2 type codes within the metadata class = reserved for IETF usage. 2. Related Metadata drafts that require more explanation than is reasonable= to include in the base MD-2 draft, including MD-1 descriptions and items d= one once the base draft is complete. 3. YANG models for the SFC Components. 4. One or more security related standards track and / or informational RFCs= . At least one standards track security mechanism RFC is needed. 5. OAM Framework document to provide a common basis for OAM work. This dra= ft will include guidance on how active, passive, and in-situ OAM are to be = supported if at all. 6. Specific OAM mechanism documents to provide the tools needed for operati= onal environments. 7. Transport Considerations RFC to cover the expectations SFC and NSH place= on transport, and the operational constraints transports used by NSH need = to meet. Thanks! Jim & Joel --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3134BDFE6sjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings WG:

 

Joel and I have taken an initial stab at new charter= text for the SFC WG. Please review and provide comments/suggestions by COB= Friday 29th December (2 weeks).

 <= /p>

 

Network operators frequently utilize service functio= ns such as packet filtering at firewalls, load-balancing and transactional = proxies (for example spam filters) in the delivery of services to end users= . Delivery of these types of services is undergoing significant change with the introduction of virtualization, = network overlays, and orchestration.

 

The SFC Working Group has developed an Architecture = [RFC 7665] and a protocol (the Network Service Header [draft-ietf-sfc-nsh-2= 8], in the RFC Editor queue as of this drafting.)

 

The focus of the SFC working group moving forward wi= ll be on aspects of the architecture and/or protocol that need to be addres= sed to enable effective deployment and usage of this work.  The SFC wo= rking group will now begin addressing those items.  In order to maintain focus, the working group will primarily = produce and advance documents on four topics:

 

1) Metadata - we need to define the common type-leng= th-value encoded metadata types with standards track RFCs, and produce info= rmational RFCs to describe common fixed-length (MD-1) metadata usages.=

 

2) Security - The completed work does not provide me= chanisms for authenticating or protecting (either for integrity or from ins= pection) metadata.  There are a number of open questions as to what ca= n be effectively provided and how to provide such tools.  These need attention.

 

3) OAM and O&M - In order for operators to use t= hese tools in production networks, they need Operations, Administration, an= d Maintenance tools, as well as management mechanisms.  This includes = YANG models, OAM frameworks, and specific OAM mechanisms to address operational needs.

 

4) Transport Considerations - this will capture the = expectations SFC places on transport behavior, including dealing with issue= s such as congestion indications and responses.

 

Specifically, the SFC WG is chartered to deliver the= following:

 

1. A standards track base set of MD-2 type codes wit= hin the metadata class reserved for IETF usage.

 

2. Related Metadata drafts that require more explana= tion than is reasonable to include in the base MD-2 draft, including MD-1 d= escriptions and items done once the base draft is complete.

 

3. YANG models for the SFC Components.

 

4. One or more security related standards track and = / or informational RFCs.  At least one standards track security mechan= ism RFC is needed.

 

5. OAM Framework document to provide a common basis = for OAM work.  This draft will include guidance on how active, passive= , and in-situ OAM are to be supported if at all.

 

6. Specific OAM mechanism documents to provide the t= ools needed for operational environments.

 

7. Transport Considerations RFC to cover the expecta= tions SFC and NSH place on transport, and the operational constraints trans= ports used by NSH need to meet.

 <= /p>

 

Thanks!

 

Jim & Joel

 

 

 

 

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3134BDFE6sjceml521mbxchi_-- From nobody Mon Dec 11 22:34:18 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 298A9126C26 for ; Mon, 11 Dec 2017 22:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mfxlMbjYzSA3 for ; Mon, 11 Dec 2017 22:34:13 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A13DC12700F for ; Mon, 11 Dec 2017 22:34:12 -0800 (PST) Received: from [192.168.1.10] (unknown [119.94.162.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 764B21801353; Tue, 12 Dec 2017 07:34:09 +0100 (CET) To: James N Guichard , 'Service Function Chaining IETF list' Cc: Alia Atlas References: From: Loa Andersson Message-ID: Date: Tue, 12 Dec 2017 14:34:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 06:34:16 -0000 Jim and Joel, This is a very good start of the new charter. I agree with the scope. There are a few things - it might be of interest to mention working groups you are supposed to cooperate with - since there is an interest in SFC from people with a background in "transport" as it is understood in the ITU-T world, we should make it clear(er) that when we mention "transport" we are using the term as it is defined in IETF /Loa - On 2017-12-12 04:13, James N Guichard wrote: > Greetings WG: > > Joel and I have taken an initial stab at new charter text for the SFC > WG. Please review and provide comments/suggestions by COB Friday 29^th > December (2 weeks). > > Network operators frequently utilize service functions such as packet > filtering at firewalls, load-balancing and transactional proxies (for > example spam filters) in the delivery of services to end users. Delivery > of these types of services is undergoing significant change with the > introduction of virtualization, network overlays, and orchestration. > > The SFC Working Group has developed an Architecture [RFC 7665] and a > protocol (the Network Service Header [draft-ietf-sfc-nsh-28], in the RFC > Editor queue as of this drafting.) > > The focus of the SFC working group moving forward will be on aspects of > the architecture and/or protocol that need to be addressed to enable > effective deployment and usage of this work.  The SFC working group will > now begin addressing those items.  In order to maintain focus, the > working group will primarily produce and advance documents on four topics: > > 1) Metadata - we need to define the common type-length-value encoded > metadata types with standards track RFCs, and produce informational RFCs > to describe common fixed-length (MD-1) metadata usages. > > 2) Security - The completed work does not provide mechanisms for > authenticating or protecting (either for integrity or from inspection) > metadata.  There are a number of open questions as to what can be > effectively provided and how to provide such tools.  These need attention. > > 3) OAM and O&M - In order for operators to use these tools in production > networks, they need Operations, Administration, and Maintenance tools, > as well as management mechanisms.  This includes YANG models, OAM > frameworks, and specific OAM mechanisms to address operational needs. > > 4) Transport Considerations - this will capture the expectations SFC > places on transport behavior, including dealing with issues such as > congestion indications and responses. > > Specifically, the SFC WG is chartered to deliver the following: > > 1. A standards track base set of MD-2 type codes within the metadata > class reserved for IETF usage. > > 2. Related Metadata drafts that require more explanation than is > reasonable to include in the base MD-2 draft, including MD-1 > descriptions and items done once the base draft is complete. > > 3. YANG models for the SFC Components. > > 4. One or more security related standards track and / or informational > RFCs.  At least one standards track security mechanism RFC is needed. > > 5. OAM Framework document to provide a common basis for OAM work.  This > draft will include guidance on how active, passive, and in-situ OAM are > to be supported if at all. > > 6. Specific OAM mechanism documents to provide the tools needed for > operational environments. > > 7. Transport Considerations RFC to cover the expectations SFC and NSH > place on transport, and the operational constraints transports used by > NSH need to meet. > > Thanks! > > Jim & Joel > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Dec 13 06:54: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 3EA9B126CC7 for ; Wed, 13 Dec 2017 06:54:36 -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 9Q9WGOeKIAsa for ; Wed, 13 Dec 2017 06:54:33 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80E0124B0A for ; Wed, 13 Dec 2017 06:54:33 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id q3so2166395oth.2 for ; Wed, 13 Dec 2017 06:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+9h1jnSCVOBgl/cE9TdMHedhUg+SJqnpP/T7WTnKYCw=; b=ODxphRHQAsY6TWyBmTDJReIIFCGLiuJzCxDXikicyStC1+abcZ2sXxcl/LfJH9z8Rr tni9Wh2Up5aSk1sz6+zOhLD0v9FgwpkKL6AqJ8oYIQrXk5UG/sHAGXj+qV6xKN3zY/MP YGWYqyMXTwPcDnKHMaKLwjKThG3NDlNC3OgPUjnz19DO10wFmUVauZj7PhOlYt368N6H AqU7TR82FHlH/LMhnpplgi9tewct0/cEL6A3z6zidyBvxoqVsQvWsQaIcaKCqH6/ULPE PMEeWVydM09OIWKdEvkWgmqje5DihxgiyDAz+vdJM/PVQiMBljouNq66pEq4yULDedru JAcA== 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=+9h1jnSCVOBgl/cE9TdMHedhUg+SJqnpP/T7WTnKYCw=; b=AG7aMyqth1jWvqs5WgFnl8I1JBXrxoq4fwuHTemPZJefvLn1kYuxwMHaugt8+AuPPo drDh/kKa4jODQwzCZXTVOC75E/mRmdqEyz6WBhqcnYWpfs+/d5H7Jd89xP8JE1WSafR8 eD8TYApU/bZGfZsc4Av2ueBvcx4Xj1PTEh2lg41iVfkgz0PYpWeSiB07ArPwyGBEcLWr PC7glVmShfVp7DpVHKgEhaeSXo/QeyU6O/nU6ZxyU2imUpHxNjn8iBpo+Z8O+xWao3IG 5i87wh/T/mffPkwrbZldi5JnKGiABn1jrhd5yLb4iOC//4J/2uYJji3FAiUSnKBk/kR0 sW+g== X-Gm-Message-State: AKGB3mJl2mwzllqyGOrOE9ZPJCkbqSGkCHMeOfo4bSbanDJuRrfyXVne yTITR0FrXsaerlbuwWlM8/FUoOtjeGYHtdA34jE= X-Google-Smtp-Source: ACJfBot07x/beqZzkCQs+7WVBf1kpC5ykPGeV0zqhylH5C4Of8sYMBRWkGaK9BG/9OUbHVmVGfMmhjjl8RaMxVVBn+k= X-Received: by 10.157.47.104 with SMTP id h95mr2249328otb.77.1513176873066; Wed, 13 Dec 2017 06:54:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.83.141 with HTTP; Wed, 13 Dec 2017 06:54:12 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Wed, 13 Dec 2017 09:54:12 -0500 Message-ID: To: James N Guichard Cc: Service Function Chaining IETF list , Alia Atlas Content-Type: multipart/alternative; boundary="94eb2c03222a006510056039f288" Archived-At: Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 14:54:36 -0000 --94eb2c03222a006510056039f288 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jim, For item 5, it=E2=80=99s unclear whether you=E2=80=99re discussing in-situ = OAM for SFC, or SFC as a potential in-situ OAM enabler/mechanism (or both). Perhaps that could be made more clear. Cheers, Andy On Mon, Dec 11, 2017 at 3:13 PM, James N Guichard < james.n.guichard@huawei.com> wrote: > Greetings WG: > > > > Joel and I have taken an initial stab at new charter text for the SFC WG. > Please review and provide comments/suggestions by COB Friday 29th > December (2 weeks). > > > > > > Network operators frequently utilize service functions such as packet > filtering at firewalls, load-balancing and transactional proxies (for > example spam filters) in the delivery of services to end users. Delivery = of > these types of services is undergoing significant change with the > introduction of virtualization, network overlays, and orchestration. > > > > The SFC Working Group has developed an Architecture [RFC 7665] and a > protocol (the Network Service Header [draft-ietf-sfc-nsh-28], in the RFC > Editor queue as of this drafting.) > > > > The focus of the SFC working group moving forward will be on aspects of > the architecture and/or protocol that need to be addressed to enable > effective deployment and usage of this work. The SFC working group will > now begin addressing those items. In order to maintain focus, the workin= g > group will primarily produce and advance documents on four topics: > > > > 1) Metadata - we need to define the common type-length-value encoded > metadata types with standards track RFCs, and produce informational RFCs = to > describe common fixed-length (MD-1) metadata usages. > > > > 2) Security - The completed work does not provide mechanisms for > authenticating or protecting (either for integrity or from inspection) > metadata. There are a number of open questions as to what can be > effectively provided and how to provide such tools. These need attention= . > > > > 3) OAM and O&M - In order for operators to use these tools in production > networks, they need Operations, Administration, and Maintenance tools, as > well as management mechanisms. This includes YANG models, OAM frameworks= , > and specific OAM mechanisms to address operational needs. > > > > 4) Transport Considerations - this will capture the expectations SFC > places on transport behavior, including dealing with issues such as > congestion indications and responses. > > > > Specifically, the SFC WG is chartered to deliver the following: > > > > 1. A standards track base set of MD-2 type codes within the metadata clas= s > reserved for IETF usage. > > > > 2. Related Metadata drafts that require more explanation than is > reasonable to include in the base MD-2 draft, including MD-1 descriptions > and items done once the base draft is complete. > > > > 3. YANG models for the SFC Components. > > > > 4. One or more security related standards track and / or informational > RFCs. At least one standards track security mechanism RFC is needed. > > > > 5. OAM Framework document to provide a common basis for OAM work. This > draft will include guidance on how active, passive, and in-situ OAM are t= o > be supported if at all. > > > > 6. Specific OAM mechanism documents to provide the tools needed for > operational environments. > > > > 7. Transport Considerations RFC to cover the expectations SFC and NSH > place on transport, and the operational constraints transports used by NS= H > need to meet. > > > > > > Thanks! > > > > Jim & Joel > > > > > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > --94eb2c03222a006510056039f288 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jim,

For item 5, it=E2=80=99s unclear w= hether you=E2=80=99re discussing=C2=A0in-situ OAM for SFC, or SFC as a potential=C2=A0in-situ OAM enabl= er/mechanism (or both). Perhaps that could be made=C2=A0more clear.<= /div>

<= div>Cheers,
Andy


On Mon, Dec 11, 2017 at 3:1= 3 PM, James N Guichard <james.n.guichard@huawei.com> wrote:

Greetings WG:

=C2=A0

Joel and I have taken an initial stab at new charter= text for the SFC WG. Please review and provide comments/suggestions by COB= Friday 29th December (2 weeks).

=C2=A0

=C2=A0

Network operators frequently utilize service functio= ns such as packet filtering at firewalls, load-balancing and transactional = proxies (for example spam filters) in the delivery of services to end users= . Delivery of these types of services is undergoing significant change with the introduction of virtualization, = network overlays, and orchestration.

=C2=A0

The SFC Working Group has developed an Architecture = [RFC 7665] and a protocol (the Network Service Header [draft-ietf-sfc-nsh-2= 8], in the RFC Editor queue as of this drafting.)

=C2=A0

The focus of the SFC working group moving forward wi= ll be on aspects of the architecture and/or protocol that need to be addres= sed to enable effective deployment and usage of this work.=C2=A0 The SFC wo= rking group will now begin addressing those items.=C2=A0 In order to maintain focus, the working group will primarily = produce and advance documents on four topics:

=C2=A0

1) Metadata - we need to define the common type-leng= th-value encoded metadata types with standards track RFCs, and produce info= rmational RFCs to describe common fixed-length (MD-1) metadata usages.

=C2=A0

2) Security - The completed work does not provide me= chanisms for authenticating or protecting (either for integrity or from ins= pection) metadata.=C2=A0 There are a number of open questions as to what ca= n be effectively provided and how to provide such tools.=C2=A0 These need attention.

=C2=A0

3) OAM and O&M - In order for operators to use t= hese tools in production networks, they need Operations, Administration, an= d Maintenance tools, as well as management mechanisms.=C2=A0 This includes = YANG models, OAM frameworks, and specific OAM mechanisms to address operational needs.

=C2=A0

4) Transport Considerations - this will capture the = expectations SFC places on transport behavior, including dealing with issue= s such as congestion indications and responses.

=C2=A0

Specifically, the SFC WG is chartered to deliver the= following:

=C2=A0

1. A standards track base set of MD-2 type codes wit= hin the metadata class reserved for IETF usage.

=C2=A0

2. Related Metadata drafts that require more explana= tion than is reasonable to include in the base MD-2 draft, including MD-1 d= escriptions and items done once the base draft is complete.

=C2=A0

3. YANG models for the SFC Components.=

=C2=A0

4. One or more security related standards track and = / or informational RFCs.=C2=A0 At least one standards track security mechan= ism RFC is needed.

=C2=A0

5. OAM Framework document to provide a common basis = for OAM work.=C2=A0 This draft will include guidance on how active, passive= , and in-situ OAM are to be supported if at all.

=C2=A0

6. Specific OAM mechanism documents to provide the t= ools needed for operational environments.

=C2=A0

7. Transport Considerations RFC to cover the expecta= tions SFC and NSH place on transport, and the operational constraints trans= ports used by NSH need to meet.

=C2=A0

=C2=A0

Thanks!

=C2=A0

Jim & Joel

=C2=A0

=C2=A0

=C2=A0

=C2=A0


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


--94eb2c03222a006510056039f288-- From nobody Wed Dec 13 07:13: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 F1DFE126CF6 for ; Wed, 13 Dec 2017 07:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z25AI9shqfCp for ; Wed, 13 Dec 2017 07:13:00 -0800 (PST) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) (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 E8B36126CD8 for ; Wed, 13 Dec 2017 07:13:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id CE238360D63; Wed, 13 Dec 2017 07:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1513177980; bh=/I9nVxsQmWbsx6v8WRi8uWXmKg00AStIOMa3EUJQfvc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=L7i4GuuLyUicJp1Ss8UCm6pcTrljqBtoaMyJ3sqomianryiJ27Pt1dUCy6V7bfyUk sdYFwd/CrYQj6xSLlc5vM3etJqtGEI/sxTpRgh90gu5Kj2l6hVekSolhOTgFPwVHhx /MuJ2rN9r1zHUkS6xWZkkAJ15WMuNJbu+UEAmQ2U= X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id 4E2C6360D64; Wed, 13 Dec 2017 07:12:59 -0800 (PST) To: "Andrew G. Malis" , James N Guichard Cc: Service Function Chaining IETF list , Alia Atlas References: From: "Joel M. Halpern" Message-ID: <52e8476a-fd26-55dc-fac1-b096cee0259a@joelhalpern.com> Date: Wed, 13 Dec 2017 10:12:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 15:13:03 -0000 Andy, I am haing trouble following the question. The intention of the text is to indicate that work on carrying OAM information along with user packets carried in SFC (in-situ OAM as part of SFC) is within scope for the OAM work. I am not sure what the alternative you raise means. Can you suggest better wording we can use? Loosely related to this, Loa as suggested the following rewording of goal 3, which the chairs have agreed to: 3) OAM and Management - In order for operators to use these tools in production networks, they need Operations, Administration, and Maintenance tools, as well as management mechanisms. This includes YANG models, OAM frameworks, and specific OAM mechanisms to address operational needs. (I realize that does not talk explicitly about in-situ. This seemed a good hook to let the WG know of a change that was suggested.) Yours, Joel On 12/13/17 9:54 AM, Andrew G. Malis wrote: > Jim, > > For item 5, it’s unclear whether you’re discussing in-situ OAM for SFC, > or SFC as a potential in-situ OAM enabler/mechanism (or both). Perhaps > that could be made more clear. > > Cheers, > Andy > > > On Mon, Dec 11, 2017 at 3:13 PM, James N Guichard > > wrote: > > Greetings WG:____ > > __ __ > > Joel and I have taken an initial stab at new charter text for the > SFC WG. Please review and provide comments/suggestions by COB Friday > 29^th December (2 weeks).____ > > __ __ > > __ __ > > Network operators frequently utilize service functions such as > packet filtering at firewalls, load-balancing and transactional > proxies (for example spam filters) in the delivery of services to > end users. Delivery of these types of services is undergoing > significant change with the introduction of virtualization, network > overlays, and orchestration.____ > > __ __ > > The SFC Working Group has developed an Architecture [RFC 7665] and a > protocol (the Network Service Header [draft-ietf-sfc-nsh-28], in the > RFC Editor queue as of this drafting.)____ > > __ __ > > The focus of the SFC working group moving forward will be on aspects > of the architecture and/or protocol that need to be addressed to > enable effective deployment and usage of this work.  The SFC working > group will now begin addressing those items.  In order to maintain > focus, the working group will primarily produce and advance > documents on four topics:____ > > __ __ > > 1) Metadata - we need to define the common type-length-value encoded > metadata types with standards track RFCs, and produce informational > RFCs to describe common fixed-length (MD-1) metadata usages.____ > > __ __ > > 2) Security - The completed work does not provide mechanisms for > authenticating or protecting (either for integrity or from > inspection) metadata.  There are a number of open questions as to > what can be effectively provided and how to provide such tools. > These need attention.____ > > __ __ > > 3) OAM and O&M - In order for operators to use these tools in > production networks, they need Operations, Administration, and > Maintenance tools, as well as management mechanisms.  This includes > YANG models, OAM frameworks, and specific OAM mechanisms to address > operational needs.____ > > __ __ > > 4) Transport Considerations - this will capture the expectations SFC > places on transport behavior, including dealing with issues such as > congestion indications and responses.____ > > __ __ > > Specifically, the SFC WG is chartered to deliver the following:____ > > __ __ > > 1. A standards track base set of MD-2 type codes within the metadata > class reserved for IETF usage.____ > > __ __ > > 2. Related Metadata drafts that require more explanation than is > reasonable to include in the base MD-2 draft, including MD-1 > descriptions and items done once the base draft is complete.____ > > __ __ > > 3. YANG models for the SFC Components.____ > > __ __ > > 4. One or more security related standards track and / or > informational RFCs.  At least one standards track security mechanism > RFC is needed.____ > > __ __ > > 5. OAM Framework document to provide a common basis for OAM work. > This draft will include guidance on how active, passive, and in-situ > OAM are to be supported if at all.____ > > __ __ > > 6. Specific OAM mechanism documents to provide the tools needed for > operational environments.____ > > __ __ > > 7. Transport Considerations RFC to cover the expectations SFC and > NSH place on transport, and the operational constraints transports > used by NSH need to meet.____ > > __ __ > > __ __ > > Thanks!____ > > __ __ > > Jim & Joel____ > > __ __ > > __ __ > > __ __ > > __ __ > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Dec 13 07:20: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 8EF27127058 for ; Wed, 13 Dec 2017 07:20:11 -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 tmDQg4xGtOA9 for ; Wed, 13 Dec 2017 07:20:09 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 9A797126E7A for ; Wed, 13 Dec 2017 07:20:08 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id j124so3066359lfg.2 for ; Wed, 13 Dec 2017 07:20:08 -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=AF3UqvytIcBb05u/FcCFCSVD8TTspnqhlnuNwjzom8s=; b=a1VjoX+GanknshRc4CpaW+ojQBAgw554GQG8f+PDwh5df48GJMhD+u6SHDDQf0ITeX jChaJj7uhm9qunU4V1aS3vlcgO7mnQdmn93DCQNsGltHN8jB9JdGKNILVCFWCmN0oQW3 tUmYjmrOMNeDtjujkZuxnKXfE3k3rdrf+Bo6EsiSv9gf7uNlLxIS9oKOyfgBe+jk7waG zwnEsPTZnZmFua1q83CWT0i0Ei3+50pmiZsgLgW/kZiGZEyJFR5vZomhZRZ6cWcUgUv4 svWbLORgJhYaUzczYez6k8WKArGpa++sArcSfZBjhEhdYtB2dckxYEbXBi4Nz3PeGBu0 6sQg== 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=AF3UqvytIcBb05u/FcCFCSVD8TTspnqhlnuNwjzom8s=; b=LbGPpPHjqp9smrBVOqsU/7qxNmpj+EXDSKmbgyUWWAdVb8Az86H4dtOcgkpdz4wtV4 7FXGYFfty9cSthQpsDtVvdDXS2Ml2FhDa+Z6aw23v5RHgG0dxZQstWaPRB8G1+iQFgg6 qO+4XpI25e0qQgUBuBG8YVFtfUotbZcTN/oJSD0JbdTl1qE69dZqO9fy6gLY9fMjQ3hM kN958/GCUuowHC8qolpuMcsVkOJc7c48pxFISZsJwdD8/S3RfS7PtnivntNgLp4ctQJ8 0/Um9xzGjPuJLAQt0TGhoRK57TjTEZlMOD65N3ggLaxbybF5yO66ZwO9Wsm3T4bDRVHz J6+g== X-Gm-Message-State: AKGB3mK5n3pYeLORsHLfZKRYoJklEgozQDa0ZgVmbRk4rWSDqBTYJQip 8ITg1SXmFQGWwZjzaUgA3cp5yFzozdYjagLFe6c= X-Google-Smtp-Source: ACJfBos1z1MpwBkBeVIn/KNUDaod22pilSGEcvQtc1ZtFv8cnwmuQLzdE5WFFDhzxzPU5uEwlk8/59mjTDzOFFFn3uw= X-Received: by 10.46.0.166 with SMTP id e38mr1698006lji.13.1513178406463; Wed, 13 Dec 2017 07:20:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.32.136 with HTTP; Wed, 13 Dec 2017 07:20:05 -0800 (PST) In-Reply-To: References: From: Greg Mirsky Date: Wed, 13 Dec 2017 09:20:05 -0600 Message-ID: To: James N Guichard Cc: Service Function Chaining IETF list , Alia Atlas Content-Type: multipart/alternative; boundary="001a1142bae2662b0605603a4d3a" Archived-At: Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 15:20:11 -0000 --001a1142bae2662b0605603a4d3a Content-Type: text/plain; charset="UTF-8" Hi Jim and Joel, thank you for such great start on the WG charter update. I agree with the stated scope and goals. The question I have is on the expected role of the SFC OAM Framework document. There are already solution proposals, both for active and hybrid OAM in SFC, and if the goal is to publish the SFC OAM Framework document, that will delay progress of the solutions. Perhaps it will be more efficient to discuss applicability of the proposed SFC OAM solutions not as part of the framework document but when reviewing the solution. And minor terminology clarification. In-situ OAM is an example of hybrid OAM, per RFC 7799, the class of OAM mechanisms that the alternate marking methods are also part of. To keep the list of goals generic I propose to update #5 s/in-situ/hybrid/ to the following: OAM Framework document to provide a common basis for OAM work. This draft will include guidance on how active, passive, and hybrid OAM are to be supported if at all. Regards, Greg On Mon, Dec 11, 2017 at 2:13 PM, James N Guichard < james.n.guichard@huawei.com> wrote: > Greetings WG: > > > > Joel and I have taken an initial stab at new charter text for the SFC WG. > Please review and provide comments/suggestions by COB Friday 29th > December (2 weeks). > > > > > > Network operators frequently utilize service functions such as packet > filtering at firewalls, load-balancing and transactional proxies (for > example spam filters) in the delivery of services to end users. Delivery of > these types of services is undergoing significant change with the > introduction of virtualization, network overlays, and orchestration. > > > > The SFC Working Group has developed an Architecture [RFC 7665] and a > protocol (the Network Service Header [draft-ietf-sfc-nsh-28], in the RFC > Editor queue as of this drafting.) > > > > The focus of the SFC working group moving forward will be on aspects of > the architecture and/or protocol that need to be addressed to enable > effective deployment and usage of this work. The SFC working group will > now begin addressing those items. In order to maintain focus, the working > group will primarily produce and advance documents on four topics: > > > > 1) Metadata - we need to define the common type-length-value encoded > metadata types with standards track RFCs, and produce informational RFCs to > describe common fixed-length (MD-1) metadata usages. > > > > 2) Security - The completed work does not provide mechanisms for > authenticating or protecting (either for integrity or from inspection) > metadata. There are a number of open questions as to what can be > effectively provided and how to provide such tools. These need attention. > > > > 3) OAM and O&M - In order for operators to use these tools in production > networks, they need Operations, Administration, and Maintenance tools, as > well as management mechanisms. This includes YANG models, OAM frameworks, > and specific OAM mechanisms to address operational needs. > > > > 4) Transport Considerations - this will capture the expectations SFC > places on transport behavior, including dealing with issues such as > congestion indications and responses. > > > > Specifically, the SFC WG is chartered to deliver the following: > > > > 1. A standards track base set of MD-2 type codes within the metadata class > reserved for IETF usage. > > > > 2. Related Metadata drafts that require more explanation than is > reasonable to include in the base MD-2 draft, including MD-1 descriptions > and items done once the base draft is complete. > > > > 3. YANG models for the SFC Components. > > > > 4. One or more security related standards track and / or informational > RFCs. At least one standards track security mechanism RFC is needed. > > > > 5. OAM Framework document to provide a common basis for OAM work. This > draft will include guidance on how active, passive, and in-situ OAM are to > be supported if at all. > > > > 6. Specific OAM mechanism documents to provide the tools needed for > operational environments. > > > > 7. Transport Considerations RFC to cover the expectations SFC and NSH > place on transport, and the operational constraints transports used by NSH > need to meet. > > > > > > Thanks! > > > > Jim & Joel > > > > > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > --001a1142bae2662b0605603a4d3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jim and Joel,
thank you for such great start on the= WG charter update. I agree with the stated scope and goals.=C2=A0
The question I have is on the expected role of the SFC OAM Framework docu= ment. There are already solution proposals, both for active and hybrid OAM = in SFC, and if the goal is to publish the SFC OAM Framework document, that = will delay progress of the solutions. Perhaps it will be more efficient to = discuss applicability of the proposed SFC OAM solutions not as part of the = framework document but when reviewing the solution.
And minor ter= minology clarification. In-situ OAM is an example of hybrid OAM, per RFC 77= 99, the class of OAM mechanisms that the alternate marking methods are also= part of. To keep the list of goals generic I propose to update #5 s/in-sit= u/hybrid/ to the following:

= OAM Framework document to provide a common basis for OAM work.=C2=A0 This d= raft will include guidance on how active, passive, and hybrid OAM are to be= supported if at all.

Regards,
Greg

On Mon, Dec 11, 2017 at = 2:13 PM, James N Guichard <james.n.guichard@huawei.com> wrote:

Greetings WG:

=C2=A0

Joel and I have taken an initial stab at new c= harter text for the SFC WG. Please review and provide comments/suggestions = by COB Friday 29th December (2 weeks).

=C2= =A0

=C2=A0

Network operators frequently utilize service f= unctions such as packet filtering at firewalls, load-balancing and transact= ional proxies (for example spam filters) in the delivery of services to end= users. Delivery of these types of services is undergoing significant change with the introduction of virtualization, = network overlays, and orchestration.

=C2=A0

The SFC Working Group has developed an Archite= cture [RFC 7665] and a protocol (the Network Service Header [draft-ietf-sfc= -nsh-28], in the RFC Editor queue as of this drafting.)

=C2=A0

The focus of the SFC working group moving forw= ard will be on aspects of the architecture and/or protocol that need to be = addressed to enable effective deployment and usage of this work.=C2=A0 The = SFC working group will now begin addressing those items.=C2=A0 In order to maintain focus, the working group will primarily = produce and advance documents on four topics:

=C2=A0

1) Metadata - we need to define the common typ= e-length-value encoded metadata types with standards track RFCs, and produc= e informational RFCs to describe common fixed-length (MD-1) metadata usages= .

=C2=A0

2) Security - The completed work does not prov= ide mechanisms for authenticating or protecting (either for integrity or fr= om inspection) metadata.=C2=A0 There are a number of open questions as to w= hat can be effectively provided and how to provide such tools.=C2=A0 These need attention.

=C2=A0

3) OAM and O&M - In order for operators to= use these tools in production networks, they need Operations, Administrati= on, and Maintenance tools, as well as management mechanisms.=C2=A0 This inc= ludes YANG models, OAM frameworks, and specific OAM mechanisms to address operational needs.

=C2=A0

4) Transport Considerations - this will captur= e the expectations SFC places on transport behavior, including dealing with= issues such as congestion indications and responses.

=C2=A0

Specifically, the SFC WG is chartered to deliv= er the following:

=C2=A0

1. A standards track base set of MD-2 type cod= es within the metadata class reserved for IETF usage.

=C2=A0

2. Related Metadata drafts that require more e= xplanation than is reasonable to include in the base MD-2 draft, including = MD-1 descriptions and items done once the base draft is complete.=

=C2=A0

3. YANG models for the SFC Components.<= u>

=C2=A0

4. One or more security related standards trac= k and / or informational RFCs.=C2=A0 At least one standards track security = mechanism RFC is needed.

=C2=A0

5. OAM Framework document to provide a common = basis for OAM work.=C2=A0 This draft will include guidance on how active, p= assive, and in-situ OAM are to be supported if at all.

=C2=A0

6. Specific OAM mechanism documents to provide= the tools needed for operational environments.

=C2=A0

7. Transport Considerations RFC to cover the e= xpectations SFC and NSH place on transport, and the operational constraints= transports used by NSH need to meet.

=C2= =A0

=C2=A0

Thanks!

=C2=A0

Jim & Joel

=C2=A0

=C2=A0

=C2=A0

=C2=A0


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


--001a1142bae2662b0605603a4d3a-- From nobody Wed Dec 13 13:22:25 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 64EB51292F4 for ; Wed, 13 Dec 2017 13:22:24 -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 FHz8FFStuq_V for ; Wed, 13 Dec 2017 13:22:22 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 8C8DD12922E for ; Wed, 13 Dec 2017 13:22:19 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id 184so2556320oii.2 for ; Wed, 13 Dec 2017 13:22:19 -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=e3tSSwQSIDZ7zVCB7QeLW3tQCJvh22GSjnuc+NsO0+c=; b=CM2XmD/9Idh6VDYyBi/eQGtqvUZ14iljtCQliDyDWnY8wWL572DCqgNv1P+ge22Slr ogBh41XWqMgbb9ihtMSK+bYfKmuLDceP64RRcPH3ZtpehXg4r6N1b5+2L1FSct1T1iLa 9dlRLXv+9xkc/HOtLpoqKC42/evm57w4PS3o7Qn+x2y9/7JjxZ/DJCV5TK9eMSniqY7b ZrK8IfJTZMFIrQGi7W4Zl0SAmKNEPSe9zLOQUQJtcizDFZBk9rPvPET5xS2mP4xNiwZV xyP12dMXJ/mPw2J3Uga2g9afoJWdCO3zT67aIzmE3KafEGfV4XPQj97d9T/qCHdaR5XA ZWWg== 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=e3tSSwQSIDZ7zVCB7QeLW3tQCJvh22GSjnuc+NsO0+c=; b=JTkTwb+xRxtxZOx6kZZhu9yUmUU5q/IRw2JAU6NcF4CK4+FNxluzhdVwod3pf+TooU ASS/vwahmkufKSlYKO78FhWjo7oYSxCcnhRo/AL03HZSUjoKbkc2pa626p7kYNkfYOcp T8HPki8/ycg6BAqOvcv3OIGuQ4YMGr3+YndRNjw5LEE4U3hfZp277K0vAHNvVrMruiU8 +cAjmKQP+A1O5XfgPhBQtaUWkoVPEbaboo7RHPrpy2Bt+prJug2bSv1aG5PfsV/NEFvQ 9kciOe41YX+Nh9uYmpOfmip5KraWJnSfme5EKViwmZJZayFnJQw/oTNXxrDTq5GDxUCY WBGw== X-Gm-Message-State: AKGB3mJBJkdFX2JmFcQrt9JuwbiwlR9cDAMulmrEQua4gJ1cc7gAgX8m UAs9KCQp/TcjBmYKgMktpPlbjYREEToULyB58VapNw== X-Google-Smtp-Source: ACJfBov5vn0JURPfCqTJv6pV3ehzSR+V/yyNCY060kK36YJuwJQ0pLvzqWT1BSY+bQozhpaqTpBVF9Z/SRAszkwKur0= X-Received: by 10.202.227.84 with SMTP id a81mr2895958oih.82.1513200138737; Wed, 13 Dec 2017 13:22:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.83.141 with HTTP; Wed, 13 Dec 2017 13:21:58 -0800 (PST) In-Reply-To: <52e8476a-fd26-55dc-fac1-b096cee0259a@joelhalpern.com> References: <52e8476a-fd26-55dc-fac1-b096cee0259a@joelhalpern.com> From: "Andrew G. Malis" Date: Wed, 13 Dec 2017 16:21:58 -0500 Message-ID: To: "Joel M. Halpern" Cc: James N Guichard , Service Function Chaining IETF list , Alia Atlas Content-Type: multipart/alternative; boundary="001a11408d96be6e8505603f5ca4" Archived-At: Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 21:22:24 -0000 --001a11408d96be6e8505603f5ca4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Joel, I was thinking of perhaps using the NSH packet header as a general approach to do iOAM (carrying the OAM information as type 2 metadata), as opposed to iOAM as a part of SFC itself. But the former is probably out of scope for this WG. So a slight rewording: 5. OAM Framework document to provide a common basis for OAM work. This draft will include guidance on how active, passive, and in-situ OAM may be supported for SFC, if at all. Cheers, Andy On Wed, Dec 13, 2017 at 10:12 AM, Joel M. Halpern wrote: > Andy, I am haing trouble following the question. > > The intention of the text is to indicate that work on carrying OAM > information along with user packets carried in SFC (in-situ OAM as part o= f > SFC) is within scope for the OAM work. > > I am not sure what the alternative you raise means. > > Can you suggest better wording we can use? > > > Loosely related to this, Loa as suggested the following rewording of goal > 3, which the chairs have agreed to: > > 3) OAM and Management - In order for operators to use these tools in > production networks, they need Operations, Administration, and Maintenanc= e > tools, as well as management mechanisms. This includes YANG models, OAM > frameworks, and specific OAM mechanisms to address operational needs. > > (I realize that does not talk explicitly about in-situ. This seemed a > good hook to let the WG know of a change that was suggested.) > > Yours, > Joel > > On 12/13/17 9:54 AM, Andrew G. Malis wrote: > >> Jim, >> >> For item 5, it=E2=80=99s unclear whether you=E2=80=99re discussing in-si= tu OAM for SFC, >> or SFC as a potential in-situ OAM enabler/mechanism (or both). Perhaps t= hat >> could be made more clear. >> >> Cheers, >> Andy >> >> >> On Mon, Dec 11, 2017 at 3:13 PM, James N Guichard < >> james.n.guichard@huawei.com > wrote: >> >> Greetings WG:____ >> >> __ __ >> >> Joel and I have taken an initial stab at new charter text for the >> SFC WG. Please review and provide comments/suggestions by COB Friday >> 29^th December (2 weeks).____ >> >> __ __ >> >> __ __ >> >> Network operators frequently utilize service functions such as >> packet filtering at firewalls, load-balancing and transactional >> proxies (for example spam filters) in the delivery of services to >> end users. Delivery of these types of services is undergoing >> significant change with the introduction of virtualization, network >> overlays, and orchestration.____ >> >> __ __ >> >> The SFC Working Group has developed an Architecture [RFC 7665] and a >> protocol (the Network Service Header [draft-ietf-sfc-nsh-28], in the >> RFC Editor queue as of this drafting.)____ >> >> __ __ >> >> The focus of the SFC working group moving forward will be on aspects >> of the architecture and/or protocol that need to be addressed to >> enable effective deployment and usage of this work. The SFC working >> group will now begin addressing those items. In order to maintain >> focus, the working group will primarily produce and advance >> documents on four topics:____ >> >> __ __ >> >> 1) Metadata - we need to define the common type-length-value encoded >> metadata types with standards track RFCs, and produce informational >> RFCs to describe common fixed-length (MD-1) metadata usages.____ >> >> __ __ >> >> 2) Security - The completed work does not provide mechanisms for >> authenticating or protecting (either for integrity or from >> inspection) metadata. There are a number of open questions as to >> what can be effectively provided and how to provide such tools. >> These need attention.____ >> >> __ __ >> >> 3) OAM and O&M - In order for operators to use these tools in >> production networks, they need Operations, Administration, and >> Maintenance tools, as well as management mechanisms. This includes >> YANG models, OAM frameworks, and specific OAM mechanisms to address >> operational needs.____ >> >> __ __ >> >> 4) Transport Considerations - this will capture the expectations SFC >> places on transport behavior, including dealing with issues such as >> congestion indications and responses.____ >> >> __ __ >> >> Specifically, the SFC WG is chartered to deliver the following:____ >> >> __ __ >> >> 1. A standards track base set of MD-2 type codes within the metadata >> class reserved for IETF usage.____ >> >> __ __ >> >> 2. Related Metadata drafts that require more explanation than is >> reasonable to include in the base MD-2 draft, including MD-1 >> descriptions and items done once the base draft is complete.____ >> >> __ __ >> >> 3. YANG models for the SFC Components.____ >> >> __ __ >> >> 4. One or more security related standards track and / or >> informational RFCs. At least one standards track security mechanism >> RFC is needed.____ >> >> __ __ >> >> 5. OAM Framework document to provide a common basis for OAM work. >> This draft will include guidance on how active, passive, and in-situ >> OAM are to be supported if at all.____ >> >> __ __ >> >> 6. Specific OAM mechanism documents to provide the tools needed for >> operational environments.____ >> >> __ __ >> >> 7. Transport Considerations RFC to cover the expectations SFC and >> NSH place on transport, and the operational constraints transports >> used by NSH need to meet.____ >> >> __ __ >> >> __ __ >> >> Thanks!____ >> >> __ __ >> >> Jim & Joel____ >> >> __ __ >> >> __ __ >> >> __ __ >> >> __ __ >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> --001a11408d96be6e8505603f5ca4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Joel,

I was thinking of perhaps using t= he NSH packet header as a general approach to do iOAM (carrying the OAM inf= ormation as type 2 metadata), as opposed to iOAM as a part of SFC itself. B= ut the former is probably out of scope for this WG.

So a slight rewording:

=C2=A0 5. OAM Framework document t= o provide a common basis for OAM work.=C2=A0 This draft will include guidan= ce on how active, passive, and in-situ=C2=A0OAM may be supported for SFC, if at all.

Cheers,
Andy


On Wed, Dec 13, 2017 at 10:12 AM, Joel M. Halpern <jmh@j= oelhalpern.com> wrote:
Andy= , I am haing trouble following the question.

The intention of the text is to indicate that work on carrying OAM informat= ion along with user packets carried in SFC (in-situ OAM as part of SFC) is = within scope for the OAM work.

I am not sure what the alternative you raise means.

Can you suggest better wording we can use?


Loosely related to this, Loa as suggested the following rewording of goal 3= , which the chairs have agreed to:

3) OAM and Management - In order for operators to use these tools in produc= tion networks, they need Operations, Administration, and Maintenance tools,= as well as management mechanisms.=C2=A0 This includes YANG models, OAM fra= meworks, and specific OAM mechanisms to address operational needs.

(I realize that does not talk explicitly about in-situ.=C2=A0 This seemed a= good hook to let the WG know of a change that was suggested.)

Yours,
Joel

On 12/13/17 9:54 AM, Andrew G. Malis wrote:
Jim,

For item 5, it=E2=80=99s unclear whether you=E2=80=99re discussing in-situ = OAM for SFC, or SFC as a potential=C2=A0in-situ OAM enabler/mechanism (or b= oth). Perhaps that could be made=C2=A0more clear.

Cheers,
Andy


 On Mon, Dec 11, 2017 at 3:13 PM, James N Guichard <james.n.guichard@huawei.com= <mailto:james.n.guichard@huawei.com>> wrote:

=C2=A0 =C2=A0 Greetings WG:____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 Joel and I have taken an initial stab at new charter text for= the
=C2=A0 =C2=A0 SFC WG. Please review and provide comments/suggestions by COB= Friday
 =C2=A0 =C2=A0 29^th December (2 weeks).____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 Network operators frequently utilize service functions such a= s
=C2=A0 =C2=A0 packet filtering at firewalls, load-balancing and transaction= al
=C2=A0 =C2=A0 proxies (for example spam filters) in the delivery of service= s to
=C2=A0 =C2=A0 end users. Delivery of these types of services is undergoing<= br> =C2=A0 =C2=A0 significant change with the introduction of virtualization, n= etwork
 =C2=A0 =C2=A0 overlays, and orchestration.____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 The SFC Working Group has developed an Architecture [RFC 7665= ] and a
=C2=A0 =C2=A0 protocol (the Network Service Header [draft-ietf-sfc-nsh-28],= in the
 =C2=A0 =C2=A0 RFC Editor queue as of this drafting.)____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 The focus of the SFC working group moving forward will be on = aspects
=C2=A0 =C2=A0 of the architecture and/or protocol that need to be addressed= to
=C2=A0 =C2=A0 enable effective deployment and usage of this work.=C2=A0 The= SFC working
=C2=A0 =C2=A0 group will now begin addressing those items.=C2=A0 In order t= o maintain
=C2=A0 =C2=A0 focus, the working group will primarily produce and advance =C2=A0 =C2=A0 documents on four topics:____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 1) Metadata - we need to define the common type-length-value = encoded
=C2=A0 =C2=A0 metadata types with standards track RFCs, and produce informa= tional
 =C2=A0 =C2=A0 RFCs to describe common fixed-length (MD-1) metadata usages._= ___

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 2) Security - The completed work does not provide mechanisms = for
=C2=A0 =C2=A0 authenticating or protecting (either for integrity or from =C2=A0 =C2=A0 inspection) metadata.=C2=A0 There are a number of open questi= ons as to
 =C2=A0 =C2=A0 what can be effectively provided and how to provide such tool= s.=C2=A0 =C2=A0 =C2=A0These need attention.____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 3) OAM and O&M - In order for operators to use these tool= s in
=C2=A0 =C2=A0 production networks, they need Operations, Administration, an= d
=C2=A0 =C2=A0 Maintenance tools, as well as management mechanisms.=C2=A0 Th= is includes
=C2=A0 =C2=A0 YANG models, OAM frameworks, and specific OAM mechanisms to a= ddress
 =C2=A0 =C2=A0 operational needs.____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 4) Transport Considerations - this will capture the expectati= ons SFC
=C2=A0 =C2=A0 places on transport behavior, including dealing with issues s= uch as
 =C2=A0 =C2=A0 congestion indications and responses.____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 Specifically, the SFC WG is chartered to deliver the followin= g:____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 1. A standards track base set of MD-2 type codes within the m= etadata
 =C2=A0 =C2=A0 class reserved for IETF usage.____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 2. Related Metadata drafts that require more explanation than= is
=C2=A0 =C2=A0 reasonable to include in the base MD-2 draft, including MD-1<= br> =C2=A0 =C2=A0 descriptions and items done once the base draft is complete._= ___

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 3. YANG models for the SFC Components.____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 4. One or more security related standards track and / or
=C2=A0 =C2=A0 informational RFCs.=C2=A0 At least one standards track securi= ty mechanism
 =C2=A0 =C2=A0 RFC is needed.____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 5. OAM Framework document to provide a common basis for OAM w= ork.=C2=A0 =C2=A0 =C2=A0This draft will include guidance on how active, pas= sive, and in-situ
 =C2=A0 =C2=A0 OAM are to be supported if at all.____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 6. Specific OAM mechanism documents to provide the tools need= ed for
 =C2=A0 =C2=A0 operational environments.____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 7. Transport Considerations RFC to cover the expectations SFC= and
=C2=A0 =C2=A0 NSH place on transport, and the operational constraints trans= ports
 =C2=A0 =C2=A0 used by NSH need to meet.____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 Thanks!____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 Jim & Joel____

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 __ __

=C2=A0 =C2=A0 __ __


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 sfc mailing list
=C2=A0 =C2=A0 sfc@ietf.or= g <mailto:sfc@ietf= .org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/sf= c
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinf= o/sfc>




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


--001a11408d96be6e8505603f5ca4-- From nobody Wed Dec 13 13:31: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 64371128C81 for ; Wed, 13 Dec 2017 13:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVkAXMMbhMkb for ; Wed, 13 Dec 2017 13:31:01 -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 9C1E912726E for ; Wed, 13 Dec 2017 13:31:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 813AFBC0218; Wed, 13 Dec 2017 13:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1513200661; bh=uzeq4lj0m3S2A5CxVVDxKitk13UfZEgzXucD856ozNE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=iksMXXsMZNITgRpD/WJYkN6f52sEd2d+mGKb0NimBfa/zr2DJvhgoZkm65MFGM+q6 P1r20k6RzjVyzlqL+Kz49uZzvVS06f977OlclKYWWQiZPRoBursgVtIrr7AcWEaLXQ tLmriUGjxDntCJkaAV4KQTIQAaOHtqmcvlANEODk= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 859FBBC0215; Wed, 13 Dec 2017 13:31:00 -0800 (PST) To: "Andrew G. Malis" Cc: James N Guichard , Service Function Chaining IETF list , Alia Atlas References: <52e8476a-fd26-55dc-fac1-b096cee0259a@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 13 Dec 2017 16:30:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 21:31:06 -0000 Does it work better or worse in your view (and others view) with "hybrid" instead of "in-situ"? Do folks agree with Greg that such would be a good substitution? Yours, Joel On 12/13/17 4:21 PM, Andrew G. Malis wrote: > Joel, > > I was thinking of perhaps using the NSH packet header as a general > approach to do iOAM (carrying the OAM information as type 2 metadata), > as opposed to iOAM as a part of SFC itself. But the former is probably > out of scope for this WG. > > So a slight rewording: > >   5. OAM Framework document to provide a common basis for OAM work. > This draft will include guidance on how active, passive, and in-situ OAM > may be supported for SFC, if at all. > > Cheers, > Andy > > > On Wed, Dec 13, 2017 at 10:12 AM, Joel M. Halpern > wrote: > > Andy, I am haing trouble following the question. > > The intention of the text is to indicate that work on carrying OAM > information along with user packets carried in SFC (in-situ OAM as > part of SFC) is within scope for the OAM work. > > I am not sure what the alternative you raise means. > > Can you suggest better wording we can use? > > > Loosely related to this, Loa as suggested the following rewording of > goal 3, which the chairs have agreed to: > > 3) OAM and Management - In order for operators to use these tools in > production networks, they need Operations, Administration, and > Maintenance tools, as well as management mechanisms.  This includes > YANG models, OAM frameworks, and specific OAM mechanisms to address > operational needs. > > (I realize that does not talk explicitly about in-situ.  This seemed > a good hook to let the WG know of a change that was suggested.) > > Yours, > Joel > > On 12/13/17 9:54 AM, Andrew G. Malis wrote: > > Jim, > > For item 5, it’s unclear whether you’re discussing in-situ OAM > for SFC, or SFC as a potential in-situ OAM enabler/mechanism (or > both). Perhaps that could be made more clear. > > Cheers, > Andy > > > On Mon, Dec 11, 2017 at 3:13 PM, James N Guichard > > >> wrote: > >     Greetings WG:____ > >     __ __ > >     Joel and I have taken an initial stab at new charter text > for the >     SFC WG. Please review and provide comments/suggestions by > COB Friday >     29^th December (2 weeks).____ > >     __ __ > >     __ __ > >     Network operators frequently utilize service functions such as >     packet filtering at firewalls, load-balancing and transactional >     proxies (for example spam filters) in the delivery of > services to >     end users. Delivery of these types of services is undergoing >     significant change with the introduction of virtualization, > network >     overlays, and orchestration.____ > >     __ __ > >     The SFC Working Group has developed an Architecture [RFC > 7665] and a >     protocol (the Network Service Header > [draft-ietf-sfc-nsh-28], in the >     RFC Editor queue as of this drafting.)____ > >     __ __ > >     The focus of the SFC working group moving forward will be > on aspects >     of the architecture and/or protocol that need to be > addressed to >     enable effective deployment and usage of this work.  The > SFC working >     group will now begin addressing those items.  In order to > maintain >     focus, the working group will primarily produce and advance >     documents on four topics:____ > >     __ __ > >     1) Metadata - we need to define the common > type-length-value encoded >     metadata types with standards track RFCs, and produce > informational >     RFCs to describe common fixed-length (MD-1) metadata > usages.____ > >     __ __ > >     2) Security - The completed work does not provide > mechanisms for >     authenticating or protecting (either for integrity or from >     inspection) metadata.  There are a number of open questions > as to >     what can be effectively provided and how to provide such > tools.     These need attention.____ > >     __ __ > >     3) OAM and O&M - In order for operators to use these tools in >     production networks, they need Operations, Administration, and >     Maintenance tools, as well as management mechanisms.  This > includes >     YANG models, OAM frameworks, and specific OAM mechanisms to > address >     operational needs.____ > >     __ __ > >     4) Transport Considerations - this will capture the > expectations SFC >     places on transport behavior, including dealing with issues > such as >     congestion indications and responses.____ > >     __ __ > >     Specifically, the SFC WG is chartered to deliver the > following:____ > >     __ __ > >     1. A standards track base set of MD-2 type codes within the > metadata >     class reserved for IETF usage.____ > >     __ __ > >     2. Related Metadata drafts that require more explanation > than is >     reasonable to include in the base MD-2 draft, including MD-1 >     descriptions and items done once the base draft is > complete.____ > >     __ __ > >     3. YANG models for the SFC Components.____ > >     __ __ > >     4. One or more security related standards track and / or >     informational RFCs.  At least one standards track security > mechanism >     RFC is needed.____ > >     __ __ > >     5. OAM Framework document to provide a common basis for OAM > work.     This draft will include guidance on how active, > passive, and in-situ >     OAM are to be supported if at all.____ > >     __ __ > >     6. Specific OAM mechanism documents to provide the tools > needed for >     operational environments.____ > >     __ __ > >     7. Transport Considerations RFC to cover the expectations > SFC and >     NSH place on transport, and the operational constraints > transports >     used by NSH need to meet.____ > >     __ __ > >     __ __ > >     Thanks!____ > >     __ __ > >     Jim & Joel____ > >     __ __ > >     __ __ > >     __ __ > >     __ __ > > >     _______________________________________________ >     sfc mailing list > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > >     > > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > From nobody Wed Dec 13 15:41: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 E258B1241F5 for ; Wed, 13 Dec 2017 15:41:41 -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 T_Jb-mDM9lHd for ; Wed, 13 Dec 2017 15:41:38 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 9425D1201F8 for ; Wed, 13 Dec 2017 15:41:38 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id r63so2759973oia.6 for ; Wed, 13 Dec 2017 15:41:38 -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=Zr/q1VBVtgohsXjs8ZAq66d8U+RoDLpXkZbfxsSblhE=; b=FsKnagZp8RSp/P16AkEA9TSAKfkunFbWZJnLpPzSmFL6XETIwIKDVQYZQ526LbqAkV K5k3I2JIAfs7u6+tQsvk1SLhKBqpWJ+zOu0Lwqe/kcYHCdJwgmYPHr+bMLEiBxU6I1Ve UB3UXxUUghgDfRBGrdFw4C9LXSb9BI02IZzEgb6HqtrU5cbfJNffK33oSO9NQHnwpju5 zpiEVW5BEpStyhJYfhHaBjNx2yX118surXMj4BhpYmKn6emPR2Ga2WgvCFSC8fTYdD01 3aSyc3+WAmWUA9CMMGvt7QNzPCvZDuiySZzDl9psIZjxjKnUXJQPM09AtPxFmuBc4+es Ev9Q== 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=Zr/q1VBVtgohsXjs8ZAq66d8U+RoDLpXkZbfxsSblhE=; b=nBEyXGEtZvFKKGpAsyiCHU4U9o8eV6UlBDx4zVgW9fVJmPTrVRH0GBXhILpcxP6QP3 J6CiDQUenAG3LkLuM4Xp1dbz/7CVfCUF7pzTEdRtqlGnZiAFqCeGS9PuhegiAcMWtEiT vLxPXEZf5DONEm+REtY8UxRu5rSAD1dhOBpnZyPgQxnwu5Faj028AzrpiFffi67W0epw Ze2Ot5zZ4SS2ng7DGah9ZYpKcioSPPyDMNcAzTJJq5AbJZLYyS2A8wxE/oKKkJdu/Kn/ UNvjhXPPfm+/0AlrjurIqz2WDemJeBFLryG758BALX+HM2BOyrI3sxd0E97CUFdBEC2T PrxA== X-Gm-Message-State: AKGB3mLlEo/X3Mq2PFdnnO/p2M2IJwVVYqRqU9B2LbYoKow5Lyq5BqWv Tb7cUMwiwwe8OJOwOjryaERgE8j7qupdX7ks8as= X-Google-Smtp-Source: ACJfBouDZ3gyABQhiv47H5TYKhj9isKlqAKRhOwGOztNGkDOG5pAJZwetCNpFSp36d1mao2VVJoPIfxeJGdoL+Vkj3M= X-Received: by 10.202.245.12 with SMTP id t12mr2947999oih.125.1513208497700; Wed, 13 Dec 2017 15:41:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.83.141 with HTTP; Wed, 13 Dec 2017 15:41:17 -0800 (PST) In-Reply-To: References: <52e8476a-fd26-55dc-fac1-b096cee0259a@joelhalpern.com> From: "Andrew G. Malis" Date: Wed, 13 Dec 2017 18:41:17 -0500 Message-ID: To: "Joel M. Halpern" Cc: James N Guichard , Service Function Chaining IETF list , Alia Atlas Content-Type: multipart/alternative; boundary="001a114971cefa05040560414ee3" Archived-At: Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 23:41:42 -0000 --001a114971cefa05040560414ee3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Joel, =E2=80=9CHybrid=E2=80=9D is consistent with the introductory text in draft-brockners-inband-oam-requirements (which also references 7799), so using hybrid is fine with me. Cheers, Andy On Wed, Dec 13, 2017 at 4:30 PM, Joel M. Halpern wrote: > Does it work better or worse in your view (and others view) with "hybrid" > instead of "in-situ"? Do folks agree with Greg that such would be a good > substitution? > > Yours, > Joel > > On 12/13/17 4:21 PM, Andrew G. Malis wrote: > >> Joel, >> >> I was thinking of perhaps using the NSH packet header as a general >> approach to do iOAM (carrying the OAM information as type 2 metadata), a= s >> opposed to iOAM as a part of SFC itself. But the former is probably out = of >> scope for this WG. >> >> So a slight rewording: >> >> 5. OAM Framework document to provide a common basis for OAM work. >> This draft will include guidance on how active, passive, and in-situ OAM >> may be supported for SFC, if at all. >> >> Cheers, >> Andy >> >> >> On Wed, Dec 13, 2017 at 10:12 AM, Joel M. Halpern > > wrote: >> >> Andy, I am haing trouble following the question. >> >> The intention of the text is to indicate that work on carrying OAM >> information along with user packets carried in SFC (in-situ OAM as >> part of SFC) is within scope for the OAM work. >> >> I am not sure what the alternative you raise means. >> >> Can you suggest better wording we can use? >> >> >> Loosely related to this, Loa as suggested the following rewording of >> goal 3, which the chairs have agreed to: >> >> 3) OAM and Management - In order for operators to use these tools in >> production networks, they need Operations, Administration, and >> Maintenance tools, as well as management mechanisms. This includes >> YANG models, OAM frameworks, and specific OAM mechanisms to address >> operational needs. >> >> (I realize that does not talk explicitly about in-situ. This seemed >> a good hook to let the WG know of a change that was suggested.) >> >> Yours, >> Joel >> >> On 12/13/17 9:54 AM, Andrew G. Malis wrote: >> >> Jim, >> >> For item 5, it=E2=80=99s unclear whether you=E2=80=99re discussi= ng in-situ OAM >> for SFC, or SFC as a potential in-situ OAM enabler/mechanism (or >> both). Perhaps that could be made more clear. >> >> Cheers, >> Andy >> >> >> On Mon, Dec 11, 2017 at 3:13 PM, James N Guichard >> > >> > >> >> wrote: >> >> Greetings WG:____ >> >> __ __ >> >> Joel and I have taken an initial stab at new charter text >> for the >> SFC WG. Please review and provide comments/suggestions by >> COB Friday >> 29^th December (2 weeks).____ >> >> __ __ >> >> __ __ >> >> Network operators frequently utilize service functions such >> as >> packet filtering at firewalls, load-balancing and >> transactional >> proxies (for example spam filters) in the delivery of >> services to >> end users. Delivery of these types of services is undergoin= g >> significant change with the introduction of virtualization, >> network >> overlays, and orchestration.____ >> >> __ __ >> >> The SFC Working Group has developed an Architecture [RFC >> 7665] and a >> protocol (the Network Service Header >> [draft-ietf-sfc-nsh-28], in the >> RFC Editor queue as of this drafting.)____ >> >> __ __ >> >> The focus of the SFC working group moving forward will be >> on aspects >> of the architecture and/or protocol that need to be >> addressed to >> enable effective deployment and usage of this work. The >> SFC working >> group will now begin addressing those items. In order to >> maintain >> focus, the working group will primarily produce and advance >> documents on four topics:____ >> >> __ __ >> >> 1) Metadata - we need to define the common >> type-length-value encoded >> metadata types with standards track RFCs, and produce >> informational >> RFCs to describe common fixed-length (MD-1) metadata >> usages.____ >> >> __ __ >> >> 2) Security - The completed work does not provide >> mechanisms for >> authenticating or protecting (either for integrity or from >> inspection) metadata. There are a number of open questions >> as to >> what can be effectively provided and how to provide such >> tools. These need attention.____ >> >> __ __ >> >> 3) OAM and O&M - In order for operators to use these tools = in >> production networks, they need Operations, Administration, >> and >> Maintenance tools, as well as management mechanisms. This >> includes >> YANG models, OAM frameworks, and specific OAM mechanisms to >> address >> operational needs.____ >> >> __ __ >> >> 4) Transport Considerations - this will capture the >> expectations SFC >> places on transport behavior, including dealing with issues >> such as >> congestion indications and responses.____ >> >> __ __ >> >> Specifically, the SFC WG is chartered to deliver the >> following:____ >> >> __ __ >> >> 1. A standards track base set of MD-2 type codes within the >> metadata >> class reserved for IETF usage.____ >> >> __ __ >> >> 2. Related Metadata drafts that require more explanation >> than is >> reasonable to include in the base MD-2 draft, including MD-= 1 >> descriptions and items done once the base draft is >> complete.____ >> >> __ __ >> >> 3. YANG models for the SFC Components.____ >> >> __ __ >> >> 4. One or more security related standards track and / or >> informational RFCs. At least one standards track security >> mechanism >> RFC is needed.____ >> >> __ __ >> >> 5. OAM Framework document to provide a common basis for OAM >> work. This draft will include guidance on how active, >> passive, and in-situ >> OAM are to be supported if at all.____ >> >> __ __ >> >> 6. Specific OAM mechanism documents to provide the tools >> needed for >> operational environments.____ >> >> __ __ >> >> 7. Transport Considerations RFC to cover the expectations >> SFC and >> NSH place on transport, and the operational constraints >> transports >> used by NSH need to meet.____ >> >> __ __ >> >> __ __ >> >> Thanks!____ >> >> __ __ >> >> Jim & Joel____ >> >> __ __ >> >> __ __ >> >> __ __ >> >> __ __ >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sfc >> >> > > >> >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> >> >> >> --001a114971cefa05040560414ee3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Joel,

=E2=80=9CHybrid=E2=80=9D is consi= stent with the introductory text in=C2=A0draft-brockners-inband-oam-require= ments (which also references 7799), so using hybrid is fine with me.
<= div>
Cheers,
Andy


On Wed, Dec 13, 2017 at = 4:30 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Does it work better or worse in your view (an= d others view) with "hybrid" instead of "in-situ"?=C2= =A0 Do folks agree with Greg that such would be a good substitution?

Yours,
Joel

On 12/13/17 4:21 PM, Andrew G. Malis wrote:
Joel,

I was thinking of perhaps using the NSH packet header as a general approach= to do iOAM (carrying the OAM information as type 2 metadata), as opposed t= o iOAM as a part of SFC itself. But the former is probably out of scope for= this WG.

So a slight rewording:

=C2=A0=C2=A0 5. OAM Framework document to provide a common basis for OAM wo= rk.=C2=A0 This draft will include guidance on how active, passive, and in-s= itu OAM may be supported for SFC, if at all.

Cheers,
Andy


On Wed, Dec 13, 2017 at 10:12 AM, Joel M. Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> wrote:

=C2=A0 =C2=A0 Andy, I am haing trouble following the question.

=C2=A0 =C2=A0 The intention of the text is to indicate that work on carryin= g OAM
=C2=A0 =C2=A0 information along with user packets carried in SFC (in-situ O= AM as
=C2=A0 =C2=A0 part of SFC) is within scope for the OAM work.

=C2=A0 =C2=A0 I am not sure what the alternative you raise means.

=C2=A0 =C2=A0 Can you suggest better wording we can use?


=C2=A0 =C2=A0 Loosely related to this, Loa as suggested the following rewor= ding of
=C2=A0 =C2=A0 goal 3, which the chairs have agreed to:

=C2=A0 =C2=A0 3) OAM and Management - In order for operators to use these t= ools in
=C2=A0 =C2=A0 production networks, they need Operations, Administration, an= d
=C2=A0 =C2=A0 Maintenance tools, as well as management mechanisms.=C2=A0 Th= is includes
=C2=A0 =C2=A0 YANG models, OAM frameworks, and specific OAM mechanisms to a= ddress
=C2=A0 =C2=A0 operational needs.

=C2=A0 =C2=A0 (I realize that does not talk explicitly about in-situ.=C2=A0= This seemed
=C2=A0 =C2=A0 a good hook to let the WG know of a change that was suggested= .)

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

=C2=A0 =C2=A0 On 12/13/17 9:54 AM, Andrew G. Malis wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jim,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 For item 5, it=E2=80=99s unclear whether you=E2= =80=99re discussing in-situ OAM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for SFC, or SFC as a potential=C2=A0in-situ OAM= enabler/mechanism (or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 both). Perhaps that could be made=C2=A0more cle= ar.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Andy


=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Mon, Dec 11, 2017 at 3:13 PM, James N Guicha= rd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <james.n.guichard@huawei.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:james.n.guichard@huawei.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:james.n.guichard@huawei.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:james.n.guichard@huawei.com>>&g= t; wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 Greetings WG:____

=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=A0 Joel and I have taken an in= itial stab at new charter text
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 SFC WG. Please review and p= rovide comments/suggestions by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 COB Friday
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 29^th December (2 weeks).__= __

=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=A0 __ __

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 Network operators frequentl= y utilize service functions such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 packet filtering at firewal= ls, load-balancing and transactional
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 proxies (for example spam f= ilters) in the delivery of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 services to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 end users. Delivery of thes= e types of services is undergoing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 significant change with the= introduction of virtualization,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 overlays, and orchestration= .____

=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=A0 The SFC Working Group has d= eveloped an Architecture [RFC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 7665] and a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 protocol (the Network Servi= ce Header
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [draft-ietf-sfc-nsh-28], in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 RFC Editor queue as of this= drafting.)____

=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=A0 The focus of the SFC workin= g group moving forward will be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 on aspects
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 of the architecture and/or = protocol that need to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 addressed to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 enable effective deployment= and usage of this work.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SFC working
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 group will now begin addres= sing those items.=C2=A0 In order to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 maintain
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 focus, the working group wi= ll primarily produce and advance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 documents on four topics:__= __

=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=A0 1) Metadata - we need to de= fine the common
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type-length-value encoded
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 metadata types with standar= ds track RFCs, and produce
=C2=A0 =C2=A0 =C2=A0 =C2=A0 informational
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 RFCs to describe common fix= ed-length (MD-1) metadata
=C2=A0 =C2=A0 =C2=A0 =C2=A0 usages.____

=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=A0 2) Security - The completed= work does not provide
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanisms for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 authenticating or protectin= g (either for integrity or from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 inspection) metadata.=C2=A0= There are a number of open questions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 what can be effectively pro= vided and how to provide such
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tools.=C2=A0 =C2=A0 =C2=A0These need attention.= ____

=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=A0 3) OAM and O&M - In ord= er for operators to use these tools in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 production networks, they n= eed Operations, Administration, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 Maintenance tools, as well = as management mechanisms.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0 =C2=A0 includes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 YANG models, OAM frameworks= , and specific OAM mechanisms to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 operational needs.____

=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=A0 4) Transport Considerations= - this will capture the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 expectations SFC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 places on transport behavio= r, including dealing with issues
=C2=A0 =C2=A0 =C2=A0 =C2=A0 such as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 congestion indications and = responses.____

=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=A0 Specifically, the SFC WG is= chartered to deliver the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 following:____

=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=A0 1. A standards track base s= et of MD-2 type codes within the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 metadata
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 class reserved for IETF usa= ge.____

=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=A0 2. Related Metadata drafts = that require more explanation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 than is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 reasonable to include in th= e base MD-2 draft, including MD-1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 descriptions and items done= once the base draft is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 complete.____

=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=A0 3. YANG models for the SFC = Components.____

=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=A0 4. One or more security rel= ated standards track and / or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 informational RFCs.=C2=A0 A= t least one standards track security
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanism
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 RFC is needed.____

=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=A0 5. OAM Framework document t= o provide a common basis for OAM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 work.=C2=A0 =C2=A0 =C2=A0This draft will includ= e guidance on how active,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 passive, and in-situ
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 OAM are to be supported if = at all.____

=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=A0 6. Specific OAM mechanism d= ocuments to provide the tools
=C2=A0 =C2=A0 =C2=A0 =C2=A0 needed for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 operational environments.__= __

=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=A0 7. Transport Considerations= RFC to cover the expectations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SFC and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 NSH place on transport, and= the operational constraints
=C2=A0 =C2=A0 =C2=A0 =C2=A0 transports
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 used by NSH need to meet.__= __

=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=A0 __ __

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 Thanks!____

=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=A0 Jim & Joel____

=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=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=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=A0=C2=A0 =C2=A0 sfc mailing list
<= /div> =C2=A0 =C2=A0 =C2=A0 =C2=A0 sfc@ietf.org <mailto:sfc@ietf.org> <mailto:sfc@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:sfc@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/l<= wbr>istinfo/sfc
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/sfc>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 <https:/= /www.ietf.org/mailman/listinfo/sfc
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/sfc>>




=C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sfc mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sfc@ietf.org <mailto:sfc@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/l<= wbr>istinfo/sfc
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mailma= n/listinfo/sfc>



--001a114971cefa05040560414ee3-- From nobody Thu Dec 14 10:15:52 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 8BC0D128616; Thu, 14 Dec 2017 10:15:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151327534656.28708.15044769825798409030@ietfa.amsl.com> Date: Thu, 14 Dec 2017 10:15:46 -0800 Archived-At: Subject: [sfc] IPR Disclosure Orange's Statement about IPR related to draft-ietf-sfc-oam-framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 18:15:47 -0000 Dear Sam Aldrin, Carlos Pignataro, Nagendra Kumar, Nobo Akiya, Ram (Ramki) Krishnan, Anoop Ghanwani: An IPR disclosure that pertains to your Internet-Draft entitled "Service Function Chaining (SFC) Operation, Administration and Maintenance (OAM) Framework" (draft-ietf-sfc-oam-framework) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3121/). The title of the IPR disclosure is "Orange's Statement about IPR related to draft-ietf-sfc-oam-framework" Thank you IETF Secretariat From nobody Fri Dec 15 16:49:25 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 A3441126DC2 for ; Fri, 15 Dec 2017 16:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2PqHfgOxJHN for ; Fri, 15 Dec 2017 16:49:22 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 D99E01201FA for ; Fri, 15 Dec 2017 16:49:21 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id f20so12254438lfe.3 for ; Fri, 15 Dec 2017 16:49:21 -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=TnCUNEHEODa1mFEZM5ihZO3ByA0pUElYlsyhUp4ipR8=; b=Fg9+sSBJwTc2Ib6SUtEFWbip6FVoekykERI3zuF7QtOqnVxbTPj0AJhCrEPFBfJyZi z1V0QBM9PwcJRnS548w7Mi1c9h3jtuuHifjmiCXl1i4Ot2FAtTLW1oUlaXUh41P6V7Hr Whmpvsp114p/ZalzCZaS4rr+ERs+vhljYmhw72Bom/xJXFtcCP7/hxLQ9ds1NmMqfOWq k2HFv0z/HX44bD93KKpxbZJZ49m9Y3cOOwJ8TBadjmx7aRQDrclGDzkwp6rMDaF2d2EZ tDBrjQ9dC0wDYSpy3I1MiargWHq+olWl1bR7LMAuOfSXT1NzEGxChcvckoUYXn8r6sJZ cByg== 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=TnCUNEHEODa1mFEZM5ihZO3ByA0pUElYlsyhUp4ipR8=; b=Wh1p4x9kJIiCEb5S6l4AjebbxuGZwG8bNEhv1emsKDBwmz/jm3oDRJdi88FP4uArwP 53EV+dadqVWd7D+L+45AjFIwOehOQecEiwkQ72FJhAbCD6q3Pt33lasSYITYBDuhvtOb KzuTCwZLnMNBduyMdlV9sHpilMzAMzNAAxmCWm4u5nROEMcsZ2sTNj2dbplQF42GUr0c yuX9oEnFUaT/t4pGbsmGjl7MkC+XgqlT8jurGNtiZQrhwj6UWZ5buBWBAtwL+b0+DasD 376NUY5vNSRmeOkiW61xPh2yWIXSUyOTbhn5E2qlAZ+kunaYf9qa5k5C4zrb2WYg47Oa uHZw== X-Gm-Message-State: AKGB3mIwKdt7b17bP/qvj/XGaAha4GnJ3CD/fdYAR6C1ZNsA7uZSvyBD qzocOI9acdVyiDlcLNmeA5ZeAbOSXD9+ZOkmOpQHfqWC X-Google-Smtp-Source: ACJfBosVayzddmDFZ53EFjpWOceZZPUzUazj5OVrCcNEonYFJTWL0cjStEPhaCqCitgVAO00aUf+lR7n0ryAt0hLfzU= X-Received: by 10.25.193.199 with SMTP id r190mr7472821lff.55.1513385359998; Fri, 15 Dec 2017 16:49:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.32.136 with HTTP; Fri, 15 Dec 2017 16:49:19 -0800 (PST) In-Reply-To: <0b7901d36fae$ed0dbed0$c7293c70$@olddog.co.uk> References: <0b7901d36fae$ed0dbed0$c7293c70$@olddog.co.uk> From: Greg Mirsky Date: Fri, 15 Dec 2017 18:49:19 -0600 Message-ID: To: Adrian Farrel Cc: Service Function Chaining IETF list , "Joel M. Halpern" Content-Type: multipart/alternative; boundary="94eb2c1a1baeca87fe05606a7c72" Archived-At: Subject: Re: [sfc] WG Last Call for draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 00:49:25 -0000 --94eb2c1a1baeca87fe05606a7c72 Content-Type: text/plain; charset="UTF-8" Hi Adrian, thank you for your kind consideration of my comments and thoughtful responses. Please find my follow-up notes in-line tagged GIM>>. Happy holidays and the best wishes to all! Regards, Greg On Thu, Dec 7, 2017 at 4:58 PM, Adrian Farrel wrote: > Hi Greg, > > Thanks for this. > > > I am glad that this document has been WG LC'ed. I support progressing it > but > > have reservations about section 5.4 that discusses use of None value in > OAM. > > Yes. The discussion of SFC OAM has come on a bit recently. > > > Below are my comments to the section 5,4: > > > > "If OAM information is carried in packets that also include payload > > data, that information must be carried in metadata." > > > > As noted in section 4 of draft-brockners-sfc-ioam-nsh, authors consider > > encapsulating iOAM data after the SFC NSH using iOAM protcol type. And > > what is 'must' in this statement - normative or mere observation? > > Yeah, maybe I was sloppy in my use of "metadata". However I think I stand > by what is written maybe with s/must be/is/. That is, it is neither > protocol header in the SFC layer nor payload, so it is "metadata". > GIM>> True, RFC 7665 does not define where the metadata may be placed but in the very Introduction to NSH SFC stated that the metadata is part of NSH: The NSH is composed of the following elements: 1. Service Function Path identification. 2. Indication of location within a Service Function Path. 3. Optional, per packet metadata (fixed length or variable). > Yes, I think iOAM is metadata. But obviously not NSH metadata. > > I don't want to get into the debate (here) about the problems of using > Next Protocol == iOAM when there is data present, or the preferable action > of defining a T2 metadata TLV to contain the iOAM stuff, or anything else > about iOAM. > > Anyway, the way we should cover this is... > > "If OAM information is carried in packets that also include payload data, > that information may be carried in metadata between the NSH and the > payload." > GIM>> As noted, the metadata is one of the elements of NSH and thus cannot be outside of it. > > > "Sending OAM separate from (but interleaved with) packets that carry > > payload data ..." > > This is the case when specially constructed test packets injected in the > network solely > > for purpose of performing OAM functions, e.g. performance measurement. > This is > > active OAM, according to RFC 7799, and, as discussed in > draft-wang-sfc-multi-layer-oam > > and presented in the meeting in Singapore, there are different ways to > perform active > > OAM over SFC NSH domain. Because progress of > draft-wang-sfc-multi-layer-oam and > > other active SFC OAM drafts is awaiting new charter of the SFC WG, > including None > > protocol solution in standard RFC, in my opinion, creates unnecessary > and unhelpful > > multiplicity of options that will complicate implementations and may > cause interoperability > > issues. All of that may be avoided if authors decide to take the section > 5.4 out from the > > document and have the discussion of active OAM in scope of discussion of > > draft-wang-sfc-multi-layer-oam. > > Why debate today that which can usefully be put off until tomorrow? > > Now, I know that this document was not adopted by the WG, but it is a bit > harsh to cite another individual draft as reasoning for changing this > document. > > As we have known for some time, we have a multiplicity of ways to indicate > the presence of OAM, and no clarity in the WG. > draft-wang-sfc-multi-layer-oam has a neat solution to reducing the number > of mechanisms by requiring that two are used at once :-) > > But it is not my intention to define how OAM is performed in an NSH > network, just to show how it might be performed. > > What if we soften the language by adding a paragraph such as: > > "Mechanisms for providing active OAM [RFC7799] in an SFC network have been > proposed [I-D.wang-sfc-multi-layer-oam]. This use case is not intended to > define another mechanism for active OAM, but does illustrate a further > option for discussion by the working group." > GIM>> I fully agree with the proposed text. > > Cheers, > Adrian > > --94eb2c1a1baeca87fe05606a7c72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,
thank you for your kind consideration of my= comments and thoughtful responses. Please find my follow-up notes in-line = tagged GIM>>.

Happy holidays and the best wi= shes to all!

Regards,
Greg

On Thu, Dec 7, 2017 at 4:= 58 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi Greg,

Thanks for this.

> I am glad that this document has been WG LC'ed. I support progress= ing it but
> have reservations about section 5.4 that discusses use of None value i= n OAM.

Yes. The discussion of SFC OAM has come on a bit recently.

> Below are my comments to the section 5,4:
>
> "If OAM information is carried in packets that also include paylo= ad
> data, that information must be carried in metadata."
>
> As noted in section 4 of draft-brockners-sfc-ioam-nsh, authors conside= r
> encapsulating iOAM data after the SFC NSH using iOAM protcol type. And=
> what is 'must' in this statement - normative or mere observati= on?

Yeah, maybe I was sloppy in my use of "metadata". However = I think I stand by what is written maybe with s/must be/is/. That is, it is= neither protocol header in the SFC layer nor payload, so it is "metad= ata".
GIM>> True, RFC 7665 does not define = where the metadata may be placed but in the very Introduction to NSH SFC st= ated that the metadata is part of NSH:
   The N=
SH is composed of the following elements:
   1.  Service Function Path identification.
   2.  Indication of location within a Service Function Path.
   3.  Optional, per packet metadata (fixed length or variable).


Yes, I think iOAM is metadata. But obviously not NSH metadata.

I don't want to get into the debate (here) about the problems of using = Next Protocol =3D=3D iOAM when there is data present, or the preferable act= ion of defining a T2 metadata TLV to contain the iOAM stuff, or anything el= se about iOAM.

Anyway, the way we should cover this is...

"If OAM information is carried in packets that also include payload da= ta, that information may be carried in metadata between the NSH and the pay= load."
GIM>> As noted, the metadata is one = of the elements of NSH and thus cannot be outside of it.=C2=A0

> "Sending OAM separate from (but interleaved with) packets that ca= rry
> payload data ..."
> This is the case when specially constructed test packets injected in t= he network solely
> for purpose of performing OAM functions, e.g. performance measurement.= This is
> active OAM, according to RFC 7799, and, as discussed in draft-wang-sfc= -multi-layer-oam
> and presented in the meeting in Singapore, there are different ways to= perform active
> OAM over SFC NSH domain. Because progress of draft-wang-sfc-multi-laye= r-oam and
> other active SFC OAM drafts is awaiting new charter of the SFC WG, inc= luding None
> protocol solution in standard RFC, in my opinion, creates unnecessary = and unhelpful
> multiplicity of options that will complicate implementations and may c= ause interoperability
> issues. All of that may be avoided if authors decide to take the secti= on 5.4 out from the
> document and have the discussion of active OAM in scope of discussion = of
> draft-wang-sfc-multi-layer-oam.

Why debate today that which can usefully be put off until tomorrow?<= br>
Now, I know that this document was not adopted by the WG, but it is a bit h= arsh to cite another individual draft as reasoning for changing this docume= nt.

As we have known for some time, we have a multiplicity of ways to indicate = the presence of OAM, and no clarity in the WG. draft-wang-sfc-multi-layer-o= am has a neat solution to reducing the number of mechanisms by requiring th= at two are used at once :-)

But it is not my intention to define how OAM is performed in an NSH network= , just to show how it might be performed.

What if we soften the language by adding a paragraph such as:

"Mechanisms for providing active OAM [RFC7799] in an SFC network have = been proposed [I-D.wang-sfc-multi-layer-oam]. This use case is not int= ended to define another mechanism for active OAM, but does illustrate a fur= ther option for discussion by the working group."
GIM>> I fully agree with the proposed text.=C2=A0

Cheers,
Adrian


--94eb2c1a1baeca87fe05606a7c72-- From nobody Fri Dec 15 16:57: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 93137126DC2 for ; Fri, 15 Dec 2017 16:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 N3MxCRPLOjEc for ; Fri, 15 Dec 2017 16:57:20 -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 B6D651201FA for ; Fri, 15 Dec 2017 16:57:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 992B7529736; Fri, 15 Dec 2017 16:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1513385840; bh=VuYRs2A/HcH5TCZIYUUIE+D/HaPMgBlbh+yo0fE9Gz4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NOYd3AOXMy+XkHQr/LxLxlf8JNChm3agsvhit8OuZFnDDhd73NOEHx2kMfODLmlPq qT0HlDFjukuN7GgzL92Xk1iQ9mvXlhsBN0MJpX1LknS0eQZc38DXxIEigFLJt3/k5q 1JCiAsiQWvr4CvIdyx5So7/2H/lJDNa8x4Pc1Ms4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 94E5152972C; Fri, 15 Dec 2017 16:57:19 -0800 (PST) To: Greg Mirsky , Adrian Farrel Cc: Service Function Chaining IETF list References: <0b7901d36fae$ed0dbed0$c7293c70$@olddog.co.uk> From: "Joel M. Halpern" Message-ID: <4b563068-3011-2649-e7cc-d2cf619de3c2@joelhalpern.com> Date: Fri, 15 Dec 2017 19:57:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] WG Last Call for draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 00:57:22 -0000 In order that we know where we stand on this document, let me ask you two opposite questions: 1) There are clearly some aspects of this document with which you are unhappy. With the change noted in the final portion of the email below, can you live with the rest of the document as is? 2) Conversely, can you suggest specific text changes that would help address your concerns? And to round out the set, are there other people in the working group who share Greg's concern? If so, can you please comment, preferably with a text suggestion that would address what drives your view of the issue? Yours, Joel On 12/15/17 7:49 PM, Greg Mirsky wrote: > Hi Adrian, > thank you for your kind consideration of my comments and thoughtful > responses. Please find my follow-up notes in-line tagged GIM>>. > > Happy holidays and the best wishes to all! > > Regards, > Greg > > On Thu, Dec 7, 2017 at 4:58 PM, Adrian Farrel > wrote: > > Hi Greg, > > Thanks for this. > > > I am glad that this document has been WG LC'ed. I support progressing it but > > have reservations about section 5.4 that discusses use of None value in OAM. > > Yes. The discussion of SFC OAM has come on a bit recently. > > > Below are my comments to the section 5,4: > > > > "If OAM information is carried in packets that also include payload > > data, that information must be carried in metadata." > > > > As noted in section 4 of draft-brockners-sfc-ioam-nsh, authors consider > > encapsulating iOAM data after the SFC NSH using iOAM protcol type. And > > what is 'must' in this statement - normative or mere observation? > > Yeah, maybe I was sloppy in my use of "metadata". However I think I > stand by what is written maybe with s/must be/is/. That is, it is > neither protocol header in the SFC layer nor payload, so it is > "metadata". > > GIM>> True, RFC 7665 does not define where the metadata may be placed > but in the very Introduction to NSH SFC stated that the metadata is part > of NSH: > > The NSH is composed of the following elements: 1. Service Function Path > identification. 2. Indication of location within a Service Function > Path. 3. Optional, per packet metadata (fixed length or variable). > > > > Yes, I think iOAM is metadata. But obviously not NSH metadata. > > I don't want to get into the debate (here) about the problems of > using Next Protocol == iOAM when there is data present, or the > preferable action of defining a T2 metadata TLV to contain the iOAM > stuff, or anything else about iOAM. > > Anyway, the way we should cover this is... > > "If OAM information is carried in packets that also include payload > data, that information may be carried in metadata between the NSH > and the payload." > > GIM>> As noted, the metadata is one of the elements of NSH and thus > cannot be outside of it. > > > > "Sending OAM separate from (but interleaved with) packets that carry > > payload data ..." > > This is the case when specially constructed test packets injected in the network solely > > for purpose of performing OAM functions, e.g. performance measurement. This is > > active OAM, according to RFC 7799, and, as discussed in draft-wang-sfc-multi-layer-oam > > and presented in the meeting in Singapore, there are different ways to perform active > > OAM over SFC NSH domain. Because progress of draft-wang-sfc-multi-layer-oam and > > other active SFC OAM drafts is awaiting new charter of the SFC WG, including None > > protocol solution in standard RFC, in my opinion, creates unnecessary and unhelpful > > multiplicity of options that will complicate implementations and may cause interoperability > > issues. All of that may be avoided if authors decide to take the section 5.4 out from the > > document and have the discussion of active OAM in scope of discussion of > > draft-wang-sfc-multi-layer-oam. > > Why debate today that which can usefully be put off until tomorrow? > > Now, I know that this document was not adopted by the WG, but it is > a bit harsh to cite another individual draft as reasoning for > changing this document. > > As we have known for some time, we have a multiplicity of ways to > indicate the presence of OAM, and no clarity in the WG. > draft-wang-sfc-multi-layer-oam has a neat solution to reducing the > number of mechanisms by requiring that two are used at once :-) > > But it is not my intention to define how OAM is performed in an NSH > network, just to show how it might be performed. > > What if we soften the language by adding a paragraph such as: > > "Mechanisms for providing active OAM [RFC7799] in an SFC network > have been proposed [I-D.wang-sfc-multi-layer-oam]. This use case is > not intended to define another mechanism for active OAM, but does > illustrate a further option for discussion by the working group." > > GIM>> I fully agree with the proposed text. > > > Cheers, > Adrian > > From nobody Fri Dec 15 17:16:46 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 147A4128ACA for ; Fri, 15 Dec 2017 17:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwNM0_LHVNXQ for ; Fri, 15 Dec 2017 17:16:43 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C714126B7F for ; Fri, 15 Dec 2017 17:16:42 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id g74so2343590lfk.7 for ; Fri, 15 Dec 2017 17:16:42 -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=UeObiInfNPEwQh54Lcyw7wx02IQSh1qISeXf2eGsyPg=; b=Mehv9hlPFHy4rKKm6R0dn7dS2A7/zfUEbqJKuB8+LTD6N08ib3NRnxV/wCd6I/0tLq Wj2VkqNyMoMhNbM9LvyL+eO1BuRErmU0RfSOLm1sWHYcJ2BCHEnQFonq84UjkLLKePS1 uDv5+jHkTqobuoyCCCMMuAVbQKQn8RFSQEEgf1u5s7bha1urq4jDcTD5t75rcppt+GCx UAZMMoPXodcEwVGyjKgR3P0qfuVxaSd99XaE/7aS12HBM7gmQzkeKrS5DVtfrjeND2xR Xq0ypTvwDJ0o8Ca2l/7a6afrUqwMJ96aopC6gUoBIFuydnbNjASRLsOWLRtClAAoSKya 6H8A== 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=UeObiInfNPEwQh54Lcyw7wx02IQSh1qISeXf2eGsyPg=; b=Oixli9fI/Fum6SnfS6ex4nT8Pzity9IKOLziB6luCacdAfArcrIM3rRvOXnj8lJvfu fThykGTs+OOsvOOtpDf26KMKET5yBcsiPabmqwP5dQRCTHIKsVN88DvP5q75vbxhYlpc 8i0lju6Uav//KMz6USjq2w+EQBuAcBnh//N3wjmSD2hRpJeexVsnap2qZhLVk0UUikcN rtyENrGylZ1LmNwtZjM3rOKj92wFLnUnnvoWR4/r7tFnL22EdqeXIvwH8xBaQth8svYv jc1uAZQ139njUhGLwm4t+2chFIdZKDZsCEGLJF8aoEYjVlJVChYf6QbmZaKC7clcSHey sYHg== X-Gm-Message-State: AKGB3mKGZrntMs3mSEzvT4U4u2ug1wSTRjCODd3+9or3AfJJLAOBw32i LJ0lTKqgMKeuCXF6XdaCxxP0+A8sxcypj7Uwsgs= X-Google-Smtp-Source: ACJfBouJl1X+R9c9S0GgG/DfhjmnmoDY6/9pK9j7or4nOjfPyRRwPsl6E4d9OSVY2WWrdtL+NsJCISVJftoJ574WWEw= X-Received: by 10.46.34.134 with SMTP id i128mr6951650lji.11.1513387000615; Fri, 15 Dec 2017 17:16:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.32.136 with HTTP; Fri, 15 Dec 2017 17:16:39 -0800 (PST) In-Reply-To: <4b563068-3011-2649-e7cc-d2cf619de3c2@joelhalpern.com> References: <0b7901d36fae$ed0dbed0$c7293c70$@olddog.co.uk> <4b563068-3011-2649-e7cc-d2cf619de3c2@joelhalpern.com> From: Greg Mirsky Date: Fri, 15 Dec 2017 19:16:39 -0600 Message-ID: To: "Joel M. Halpern" Cc: Adrian Farrel , Service Function Chaining IETF list Content-Type: multipart/alternative; boundary="f4030439dfa494589605606adebd" Archived-At: Subject: Re: [sfc] WG Last Call for draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 01:16:45 -0000 --f4030439dfa494589605606adebd Content-Type: text/plain; charset="UTF-8" Hi Joel, thank you for formulating clear questions to clarify my view on the document. My remaining concern is with the proposed new text: "If OAM information is carried in packets that also include payload data, that information may be carried in metadata between the NSH and the payload." I can suggest to omit reference to metadata in this sentence, like "that information may be carried between the NSH and the payload". But that would effectively open the door for solutions similar to the one proposed in draft-ooamdt-rtgwg-ooam-header. And it was strongly opposed by some participants of SFC WG for exactly enabling such solution. Perhaps if no one else speaks up, we'll have rough consensus to move the document forward as suggested by WG Chairs. Regards, Greg On Fri, Dec 15, 2017 at 6:57 PM, Joel M. Halpern wrote: > In order that we know where we stand on this document, let me ask you two > opposite questions: > > 1) There are clearly some aspects of this document with which you are > unhappy. With the change noted in the final portion of the email below, > can you live with the rest of the document as is? > > 2) Conversely, can you suggest specific text changes that would help > address your concerns? > > And to round out the set, are there other people in the working group who > share Greg's concern? If so, can you please comment, preferably with a > text suggestion that would address what drives your view of the issue? > > Yours, > Joel > > On 12/15/17 7:49 PM, Greg Mirsky wrote: > >> Hi Adrian, >> thank you for your kind consideration of my comments and thoughtful >> responses. Please find my follow-up notes in-line tagged GIM>>. >> >> Happy holidays and the best wishes to all! >> >> Regards, >> Greg >> >> On Thu, Dec 7, 2017 at 4:58 PM, Adrian Farrel > > wrote: >> >> Hi Greg, >> >> Thanks for this. >> >> > I am glad that this document has been WG LC'ed. I support >> progressing it but >> > have reservations about section 5.4 that discusses use of None >> value in OAM. >> >> Yes. The discussion of SFC OAM has come on a bit recently. >> >> > Below are my comments to the section 5,4: >> > >> > "If OAM information is carried in packets that also include payload >> > data, that information must be carried in metadata." >> > >> > As noted in section 4 of draft-brockners-sfc-ioam-nsh, authors >> consider >> > encapsulating iOAM data after the SFC NSH using iOAM protcol type. >> And >> > what is 'must' in this statement - normative or mere observation? >> >> Yeah, maybe I was sloppy in my use of "metadata". However I think I >> stand by what is written maybe with s/must be/is/. That is, it is >> neither protocol header in the SFC layer nor payload, so it is >> "metadata". >> >> GIM>> True, RFC 7665 does not define where the metadata may be placed but >> in the very Introduction to NSH SFC stated that the metadata is part of NSH: >> >> The NSH is composed of the following elements: 1. Service Function Path >> identification. 2. Indication of location within a Service Function Path. >> 3. Optional, per packet metadata (fixed length or variable). >> >> >> >> Yes, I think iOAM is metadata. But obviously not NSH metadata. >> >> I don't want to get into the debate (here) about the problems of >> using Next Protocol == iOAM when there is data present, or the >> preferable action of defining a T2 metadata TLV to contain the iOAM >> stuff, or anything else about iOAM. >> >> Anyway, the way we should cover this is... >> >> "If OAM information is carried in packets that also include payload >> data, that information may be carried in metadata between the NSH >> and the payload." >> >> GIM>> As noted, the metadata is one of the elements of NSH and thus >> cannot be outside of it. >> >> >> > "Sending OAM separate from (but interleaved with) packets that carry >> > payload data ..." >> > This is the case when specially constructed test packets injected >> in the network solely >> > for purpose of performing OAM functions, e.g. performance >> measurement. This is >> > active OAM, according to RFC 7799, and, as discussed in >> draft-wang-sfc-multi-layer-oam >> > and presented in the meeting in Singapore, there are different ways >> to perform active >> > OAM over SFC NSH domain. Because progress of >> draft-wang-sfc-multi-layer-oam and >> > other active SFC OAM drafts is awaiting new charter of the SFC WG, >> including None >> > protocol solution in standard RFC, in my opinion, creates >> unnecessary and unhelpful >> > multiplicity of options that will complicate implementations and >> may cause interoperability >> > issues. All of that may be avoided if authors decide to take the >> section 5.4 out from the >> > document and have the discussion of active OAM in scope of >> discussion of >> > draft-wang-sfc-multi-layer-oam. >> >> Why debate today that which can usefully be put off until tomorrow? >> >> Now, I know that this document was not adopted by the WG, but it is >> a bit harsh to cite another individual draft as reasoning for >> changing this document. >> >> As we have known for some time, we have a multiplicity of ways to >> indicate the presence of OAM, and no clarity in the WG. >> draft-wang-sfc-multi-layer-oam has a neat solution to reducing the >> number of mechanisms by requiring that two are used at once :-) >> >> But it is not my intention to define how OAM is performed in an NSH >> network, just to show how it might be performed. >> >> What if we soften the language by adding a paragraph such as: >> >> "Mechanisms for providing active OAM [RFC7799] in an SFC network >> have been proposed [I-D.wang-sfc-multi-layer-oam]. This use case is >> not intended to define another mechanism for active OAM, but does >> illustrate a further option for discussion by the working group." >> >> GIM>> I fully agree with the proposed text. >> >> >> Cheers, >> Adrian >> >> >> --f4030439dfa494589605606adebd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joel,
thank you for formulating clear questions to = clarify my view on the document.=C2=A0
My remaining concern is wi= th the proposed new text:
=C2=A0 =C2=A0 "If OAM informat= ion is carried in packets that also include payload
=C2=A0 =C2=A0 data, that= information may be carried in metadata between the NSH
=C2=A0 =C2=A0 and th= e payload."
I can suggest to omit refe= rence to metadata in this sentence, like "that information may be carr= ied between the NSH and the payload". But that would effectively open = the door for solutions similar to the one proposed in=C2=A0draft-ooamdt-rtgwg-ooam-heade= r. And it was strongly opposed by some participants of SFC WG for exactly e= nabling such solution.

=
Perhaps if no one else spe= aks up, we'll have rough consensus to move the document forward as sugg= ested by WG Chairs.

Regards,
<= div>Greg

On Fri, Dec 15, 2017 at 6:57 PM, Joel M.= Halpern <jmh@joelhalpern.com> wrote:
In order that we know where we stand on th= is document, let me ask you two opposite questions:

1) There are clearly some aspects of this document with which you are unhap= py.=C2=A0 With the change noted in the final portion of the email below, ca= n you live with the rest of the document as is?

2) Conversely, can you suggest specific text changes that would help addres= s your concerns?

And to round out the set, are there other people in the working group who s= hare Greg's concern?=C2=A0 If so, can you please comment, preferably wi= th a text suggestion that would address what drives your view of the issue?=

Yours,
Joel

On 12/15/17 7:49 PM, Greg Mirsky wrote:
Hi Adrian,
thank you for your kind consideration of my comments and thoughtful respons= es. Please find my follow-up notes in-line tagged GIM>>.

Happy holidays and the best wishes to all!

Regards,
Greg

On Thu, Dec 7, 2017 at 4:58 PM, Adrian Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk&g= t;> wrote:

=C2=A0 =C2=A0 Hi Greg,

=C2=A0 =C2=A0 Thanks for this.

=C2=A0 =C2=A0 > I am glad that this document has been WG LC'ed. I su= pport progressing it but
=C2=A0 =C2=A0 > have reservations about section 5.4 that discusses use o= f None value in OAM.

=C2=A0 =C2=A0 Yes. The discussion of SFC OAM has come on a bit recently.
=C2=A0 =C2=A0 > Below are my comments to the section 5,4:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > "If OAM information is carried in packets that also= include payload
=C2=A0 =C2=A0 > data, that information must be carried in metadata."= ;
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > As noted in section 4 of draft-brockners-sfc-ioam-nsh, a= uthors consider
=C2=A0 =C2=A0 > encapsulating iOAM data after the SFC NSH using iOAM pro= tcol type. And
=C2=A0 =C2=A0 > what is 'must' in this statement - normative or = mere observation?

=C2=A0 =C2=A0 Yeah, maybe I was sloppy in my use of "metadata". H= owever I think I
=C2=A0 =C2=A0 stand by what is written maybe with s/must be/is/. That is, i= t is
=C2=A0 =C2=A0 neither protocol header in the SFC layer nor payload, so it i= s
=C2=A0 =C2=A0 "metadata".

GIM>> True, RFC 7665 does not define where the metadata may be placed= but in the very Introduction to NSH SFC stated that the metadata is part o= f NSH:

The NSH is composed of the following elements: 1. Service Function Path ide= ntification. 2. Indication of location within a Service Function Path. 3. O= ptional, per packet metadata (fixed length or variable).



=C2=A0 =C2=A0 Yes, I think iOAM is metadata. But obviously not NSH metadata= .

=C2=A0 =C2=A0 I don't want to get into the debate (here) about the prob= lems of
=C2=A0 =C2=A0 using Next Protocol =3D=3D iOAM when there is data present, o= r the
=C2=A0 =C2=A0 preferable action of defining a T2 metadata TLV to contain th= e iOAM
=C2=A0 =C2=A0 stuff, or anything else about iOAM.

=C2=A0 =C2=A0 Anyway, the way we should cover this is...

=C2=A0 =C2=A0 "If OAM information is carried in packets that also incl= ude payload
=C2=A0 =C2=A0 data, that information may be carried in metadata between the= NSH
=C2=A0 =C2=A0 and the payload."

GIM>> As noted, the metadata is one of the elements of NSH and thus c= annot be outside of it.


=C2=A0 =C2=A0 > "Sending OAM separate from (but interleaved with) p= ackets that carry
=C2=A0 =C2=A0 > payload data ..."
=C2=A0 =C2=A0 > This is the case when specially constructed test packets= injected in the network solely
=C2=A0 =C2=A0 > for purpose of performing OAM functions, e.g. performanc= e measurement. This is
=C2=A0 =C2=A0 > active OAM, according to RFC 7799, and, as discussed in = draft-wang-sfc-multi-layer-oam
=C2=A0 =C2=A0 > and presented in the meeting in Singapore, there are dif= ferent ways to perform active
=C2=A0 =C2=A0 > OAM over SFC NSH domain. Because progress of draft-wang-= sfc-multi-layer-oam and
=C2=A0 =C2=A0 > other active SFC OAM drafts is awaiting new charter of t= he SFC WG, including None
=C2=A0 =C2=A0 > protocol solution in standard RFC, in my opinion, create= s unnecessary and unhelpful
=C2=A0 =C2=A0 > multiplicity of options that will complicate implementat= ions and may cause interoperability
=C2=A0 =C2=A0 > issues. All of that may be avoided if authors decide to = take the section 5.4 out from the
=C2=A0 =C2=A0 > document and have the discussion of active OAM in scope = of discussion of
=C2=A0 =C2=A0 > draft-wang-sfc-multi-layer-oam.

=C2=A0 =C2=A0 Why debate today that which can usefully be put off until tom= orrow?

=C2=A0 =C2=A0 Now, I know that this document was not adopted by the WG, but= it is
=C2=A0 =C2=A0 a bit harsh to cite another individual draft as reasoning for=
=C2=A0 =C2=A0 changing this document.

=C2=A0 =C2=A0 As we have known for some time, we have a multiplicity of way= s to
=C2=A0 =C2=A0 indicate the presence of OAM, and no clarity in the WG.
=C2=A0 =C2=A0 draft-wang-sfc-multi-layer-oam has a neat solution to reducin= g the
=C2=A0 =C2=A0 number of mechanisms by requiring that two are used at once := -)

=C2=A0 =C2=A0 But it is not my intention to define how OAM is performed in = an NSH
=C2=A0 =C2=A0 network, just to show how it might be performed.

=C2=A0 =C2=A0 What if we soften the language by adding a paragraph such as:=

=C2=A0 =C2=A0 "Mechanisms for providing active OAM [RFC7799] in an SFC= network
=C2=A0 =C2=A0 have been proposed [I-D.wang-sfc-multi-layer-oam]. This = use case is
=C2=A0 =C2=A0 not intended to define another mechanism for active OAM, but = does
=C2=A0 =C2=A0 illustrate a further option for discussion by the working gro= up."

GIM>> I fully agree with the proposed text.


=C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 Adrian



--f4030439dfa494589605606adebd-- From nobody Sat Dec 16 14:05: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 D7B4C127B60 for ; Sat, 16 Dec 2017 14:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 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, 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 w9FHSMiD-YsJ for ; Sat, 16 Dec 2017 14:05:06 -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 42AD71275AB for ; Sat, 16 Dec 2017 14:05:05 -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 vBGM520M004943; Sat, 16 Dec 2017 22:05:02 GMT Received: from 950129200 (83.20.112.87.dyn.plus.net [87.112.20.83]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id vBGM50Yf004893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Dec 2017 22:05:01 GMT Reply-To: From: "Adrian Farrel" To: "'Greg Mirsky'" Cc: "'Service Function Chaining IETF list'" , "'Joel M. Halpern'" References: <0b7901d36fae$ed0dbed0$c7293c70$@olddog.co.uk> <4b563068-3011-2649-e7cc-d2cf619de3c2@joelhalpern.com> In-Reply-To: Date: Sat, 16 Dec 2017 22:04:55 -0000 Message-ID: <043501d376b9$e8c9e850$ba5db8f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0436_01D376B9.E8CDB8E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGU43HvhltzE+f9gyKRxwh2Tk9cFQHTl8GFAhDmWSAB6R2v4wKQdJQIArkFKI2jat5O8A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.2.0.1013-23534.003 X-TM-AS-Result: No--29.506-10.0-31-10 X-imss-scan-details: No--29.506-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtERqNE+xcwLcJmug812qIbzbfVFVoam0SEP5UNwUjScFOPH xOjyBbJAWrUDg/te4VyovjJSfpaFEJ6UWRnAaUWJ3FqOVb7PDEIUqWKocoJo6brfxlRjqBJ3IE9 v7dw1ta78kJKsMYKuJfxlqJHWkg+JtrZWHaNDZ4QXrP0cYcrA22Wuy5Lm0L4/q8z7POX8FJOjwC wSrNodh/fpVklYFVN9nNYlB8mT9g+o9BpM221NMwRH1Nr7oERdK4yIKeenMgprRM6wvXgDaeMrx NNEfOGZ5U7S7ocAtU9P3gSzzc3vgOClVqpL2c7Q081phgl5F/kUOnkJcyxUvwzvg1/q1MH2t/nL SQcqKPCdkBUvcLzFIyiXQyJaXmhz1GwaHEr6jXezI1v7J4hECh9fNWA7SFWqSmNTroCFcOLyPMw vb6lrcxwg7bRTaugz3Szg1f96HghFU837xhvQxv+rNjeetG+OyeUl7aCTy8iCsBeCv8CM/SM2Gq GKs1KAtGcNwwjR1YJMXCxRWpeZ5oJiSQkXWLNVHcQQBuf4ZFtdymZBcuGGRDCmUYns3FLTjpumH 917sg7X9MnsiLkSb0/ZO7dtMsCcarxSAYMw4YNX0vBPb36vNo+YVJqrrEz43Hl0OqtoIEpcRWGa hHnWFLI6Xa4VSwz1WG4u7SDAr2DixMfCuUph2ZRrnSy7UTtbOFrEjYh/1F5BDVeC8J7uwToWdKp hqUwY1oyFfXes1rbOHyiFumtKQZ9fZl5hHX1Z4Tzr6T25NkffVqwz+Cynace0H7LMCFcVwRq4ts fhpBwOxu2s7fdNV4sWCfP6Gmv5dbSgks66AoGeAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyL3PDiXO /tFSYVH0dq7wY7uB72j9GKLB3b72ALY7Ne1avXdO+wbteAk490cRou+YXN/Th3hMCayFQ== Archived-At: Subject: Re: [sfc] WG Last Call for draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 22:05:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0436_01D376B9.E8CDB8E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable OK, I think we are close. =20 Rather than spending time defining what is and what is not "metadata" = (whether in the SFC context or more generally), we can leverage your = formulation.=20 =20 If we agree that OAM information might be carried between the NSH and = the payload, then we can have... OLD If OAM information is carried in packets that also include payload data, that information may be carried in metadata between the NSH and the payload. NEW If OAM information is carried in packets that also include payload data, that information might be carried between the NSH and the payload. END =20 I see no reason to debate whether this OAM information is to be called = metadata or not, and so we can close the final issue from your review. =20 BTW, I understand your concern that this might open up the field for = doing things that there is not support to do. But I don't think this = section is providing more than commentary on this point. Furthermore, if = we were to attempt to be proscriptive in this document, we would need a = wider and probably more fraught debate which would not sit well with the = season of goodwill that is Hanukkah. =20 Cheers, Adrian =20 =20 From: Greg Mirsky [mailto:gregimirsky@gmail.com]=20 Sent: 16 December 2017 01:17 To: Joel M. Halpern Cc: Adrian Farrel; Service Function Chaining IETF list Subject: Re: [sfc] WG Last Call for draft-farrel-sfc-convent =20 Hi Joel, thank you for formulating clear questions to clarify my view on the = document.=20 My remaining concern is with the proposed new text: "If OAM information is carried in packets that also include payload data, that information may be carried in metadata between the NSH and the payload." I can suggest to omit reference to metadata in this sentence, like "that = information may be carried between the NSH and the payload". But that = would effectively open the door for solutions similar to the one = proposed in draft-ooamdt-rtgwg-ooam-header. And it was strongly opposed = by some participants of SFC WG for exactly enabling such solution. =20 Perhaps if no one else speaks up, we'll have rough consensus to move the = document forward as suggested by WG Chairs. =20 Regards, Greg =20 On Fri, Dec 15, 2017 at 6:57 PM, Joel M. Halpern = wrote: In order that we know where we stand on this document, let me ask you = two opposite questions: 1) There are clearly some aspects of this document with which you are = unhappy. With the change noted in the final portion of the email below, = can you live with the rest of the document as is? 2) Conversely, can you suggest specific text changes that would help = address your concerns? And to round out the set, are there other people in the working group = who share Greg's concern? If so, can you please comment, preferably = with a text suggestion that would address what drives your view of the = issue? Yours, Joel On 12/15/17 7:49 PM, Greg Mirsky wrote: Hi Adrian, thank you for your kind consideration of my comments and thoughtful = responses. Please find my follow-up notes in-line tagged GIM>>. Happy holidays and the best wishes to all! Regards, Greg On Thu, Dec 7, 2017 at 4:58 PM, Adrian Farrel > wrote: Hi Greg, Thanks for this. > I am glad that this document has been WG LC'ed. I support = progressing it but > have reservations about section 5.4 that discusses use of None = value in OAM. Yes. The discussion of SFC OAM has come on a bit recently. > Below are my comments to the section 5,4: > > "If OAM information is carried in packets that also include = payload > data, that information must be carried in metadata." > > As noted in section 4 of draft-brockners-sfc-ioam-nsh, authors = consider > encapsulating iOAM data after the SFC NSH using iOAM protcol type. = And > what is 'must' in this statement - normative or mere observation? Yeah, maybe I was sloppy in my use of "metadata". However I think I stand by what is written maybe with s/must be/is/. That is, it is neither protocol header in the SFC layer nor payload, so it is "metadata". GIM>> True, RFC 7665 does not define where the metadata may be placed = but in the very Introduction to NSH SFC stated that the metadata is part = of NSH: The NSH is composed of the following elements: 1. Service Function Path = identification. 2. Indication of location within a Service Function = Path. 3. Optional, per packet metadata (fixed length or variable). Yes, I think iOAM is metadata. But obviously not NSH metadata. I don't want to get into the debate (here) about the problems of using Next Protocol =3D=3D iOAM when there is data present, or the preferable action of defining a T2 metadata TLV to contain the iOAM stuff, or anything else about iOAM. Anyway, the way we should cover this is... "If OAM information is carried in packets that also include payload data, that information may be carried in metadata between the NSH and the payload." GIM>> As noted, the metadata is one of the elements of NSH and thus = cannot be outside of it. > "Sending OAM separate from (but interleaved with) packets that = carry > payload data ..." > This is the case when specially constructed test packets injected = in the network solely > for purpose of performing OAM functions, e.g. performance = measurement. This is > active OAM, according to RFC 7799, and, as discussed in = draft-wang-sfc-multi-layer-oam > and presented in the meeting in Singapore, there are different = ways to perform active > OAM over SFC NSH domain. Because progress of = draft-wang-sfc-multi-layer-oam and > other active SFC OAM drafts is awaiting new charter of the SFC WG, = including None > protocol solution in standard RFC, in my opinion, creates = unnecessary and unhelpful > multiplicity of options that will complicate implementations and = may cause interoperability > issues. All of that may be avoided if authors decide to take the = section 5.4 out from the > document and have the discussion of active OAM in scope of = discussion of > draft-wang-sfc-multi-layer-oam. Why debate today that which can usefully be put off until tomorrow? Now, I know that this document was not adopted by the WG, but it is a bit harsh to cite another individual draft as reasoning for changing this document. As we have known for some time, we have a multiplicity of ways to indicate the presence of OAM, and no clarity in the WG. draft-wang-sfc-multi-layer-oam has a neat solution to reducing the number of mechanisms by requiring that two are used at once :-) But it is not my intention to define how OAM is performed in an NSH network, just to show how it might be performed. What if we soften the language by adding a paragraph such as: "Mechanisms for providing active OAM [RFC7799] in an SFC network have been proposed [I-D.wang-sfc-multi-layer-oam]. This use case is not intended to define another mechanism for active OAM, but does illustrate a further option for discussion by the working group." GIM>> I fully agree with the proposed text. Cheers, Adrian =20 ------=_NextPart_000_0436_01D376B9.E8CDB8E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

OK, I think we are = close.

 

Rather than spending time = defining what is and what is not "metadata" (whether in the = SFC context or more generally), we can leverage your formulation. =

 

If we agree that OAM = information might be carried between the NSH and the payload, then we = can have...

OLD

=C2=A0=C2=A0=C2=A0 If OAM information = is carried in packets that also include payload

=C2=A0=C2=A0=C2=A0 data, that = information may be carried in metadata between the = NSH

=C2=A0=C2=A0=C2=A0 and the = payload.

NEW

=C2=A0=C2=A0=C2=A0 If OAM information = is carried in packets that also include payload

=C2=A0=C2=A0=C2=A0 data, that = information might be carried between the NSH and = the

=C2=A0=C2=A0 =C2=A0payload.

END

 

I see no reason to debate = whether this OAM information is to be called metadata or not, and so we = can close the final issue from your review.

 

BTW, I understand your concern = that this might open up the field for doing things that there is not = support to do. But I don't think this section is providing more than = commentary on this point. Furthermore, if we were to attempt to be = proscriptive in this document, we would need a wider and probably more = fraught debate which would not sit well with the season of goodwill that = is Hanukkah.

 

Cheers,

Adrian

 

 

From: Greg Mirsky = [mailto:gregimirsky@gmail.com]
Sent: 16 December 2017 = 01:17
To: Joel M. Halpern
Cc: Adrian Farrel; Service = Function Chaining IETF list
Subject: Re: [sfc] WG Last Call = for draft-farrel-sfc-convent

 

Hi = Joel,

thank you for formulating = clear questions to clarify my view on the = document. 

My = remaining concern is with the proposed new = text:

    = "If OAM information is carried in packets that also include = payload
    data, that information may be carried in = metadata between the NSH
    and the = payload."

I can suggest = to omit reference to metadata in this sentence, like "that = information may be carried between the NSH and the payload". But = that would effectively open the door for solutions similar to the one = proposed in draft-ooamdt-rtg= wg-ooam-header. And it was strongly opposed by some participants of SFC = WG for exactly enabling such = solution.

 

Perhaps if no = one else speaks up, we'll have rough consensus to move the document = forward as suggested by WG Chairs.

 

Regards,<= o:p>

Greg=

 

On Fri, Dec 15, 2017 at 6:57 PM, Joel M. Halpern = <jmh@joelhalpern.com> wrote:

In order that we know where we stand on this document, = let me ask you two opposite questions:

1) There are clearly some = aspects of this document with which you are unhappy.  With the = change noted in the final portion of the email below, can you live with = the rest of the document as is?

2) Conversely, can you suggest = specific text changes that would help address your concerns?

And = to round out the set, are there other people in the working group who = share Greg's concern?  If so, can you please comment, preferably = with a text suggestion that would address what drives your view of the = issue?

Yours,
Joel

On 12/15/17 = 7:49 PM, Greg Mirsky wrote:

Hi = Adrian,
thank you for your kind = consideration of my comments and thoughtful responses. Please find my = follow-up notes in-line tagged GIM>>.

Happy holidays and the best wishes to = all!

Regards,
Greg

On Thu, Dec 7, 2017 at 4:58 PM, Adrian = Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>> wrote:

  =   Hi Greg,

    Thanks for this.

  =   > I am glad that this document has been WG LC'ed. I support = progressing it but
    > have reservations about section = 5.4 that discusses use of None value in OAM.

    Yes. = The discussion of SFC OAM has come on a bit recently.

  =   > Below are my comments to the section 5,4:
    = >
    > "If OAM information is carried in = packets that also include payload
    > data, that = information must be carried in metadata."
    = >
    > As noted in section 4 of = draft-brockners-sfc-ioam-nsh, authors consider
    > = encapsulating iOAM data after the SFC NSH using iOAM protcol type. = And
    > what is 'must' in this statement - normative = or mere observation?

    Yeah, maybe I was sloppy in my = use of "metadata". However I think I
    stand by = what is written maybe with s/must be/is/. That is, it is
  =   neither protocol header in the SFC layer nor payload, so it = is
    "metadata".

GIM>> True, RFC = 7665 does not define where the metadata may be placed but in the very = Introduction to NSH SFC stated that the metadata is part of = NSH:

The NSH is composed of the following elements: 1. Service = Function Path identification. 2. Indication of location within a Service = Function Path. 3. Optional, per packet metadata (fixed length or = variable).



    Yes, I think iOAM is metadata. = But obviously not NSH metadata.

    I don't want to get = into the debate (here) about the problems of
    using Next = Protocol =3D=3D iOAM when there is data present, or the
    = preferable action of defining a T2 metadata TLV to contain the = iOAM
    stuff, or anything else about iOAM.

  =   Anyway, the way we should cover this is...

    = "If OAM information is carried in packets that also include = payload
    data, that information may be carried in = metadata between the NSH
    and the = payload."

GIM>> As noted, the metadata is one of the = elements of NSH and thus cannot be outside of it.


  =   > "Sending OAM separate from (but interleaved with) = packets that carry
    > payload data = ..."
    > This is the case when specially = constructed test packets injected in the network solely
    = > for purpose of performing OAM functions, e.g. performance = measurement. This is
    > active OAM, according to RFC = 7799, and, as discussed in draft-wang-sfc-multi-layer-oam
  =   > and presented in the meeting in Singapore, there are = different ways to perform active
    > OAM over SFC NSH = domain. Because progress of draft-wang-sfc-multi-layer-oam and
  =   > other active SFC OAM drafts is awaiting new charter of the = SFC WG, including None
    > protocol solution in = standard RFC, in my opinion, creates unnecessary and unhelpful
  =   > multiplicity of options that will complicate implementations = and may cause interoperability
    > issues. All of that = may be avoided if authors decide to take the section 5.4 out from = the
    > document and have the discussion of active OAM = in scope of discussion of
    > = draft-wang-sfc-multi-layer-oam.

    Why debate today = that which can usefully be put off until tomorrow?

    = Now, I know that this document was not adopted by the WG, but it = is
    a bit harsh to cite another individual draft as = reasoning for
    changing this document.

  =   As we have known for some time, we have a multiplicity of ways = to
    indicate the presence of OAM, and no clarity in the = WG.
    draft-wang-sfc-multi-layer-oam has a neat solution = to reducing the
    number of mechanisms by requiring that = two are used at once :-)

    But it is not my intention = to define how OAM is performed in an NSH
    network, just = to show how it might be performed.

    What if we = soften the language by adding a paragraph such as:

    = "Mechanisms for providing active OAM [RFC7799] in an SFC = network
    have been proposed = [I-D.wang-sfc-multi-layer-oam]. This use case is
    not = intended to define another mechanism for active OAM, but does
  =   illustrate a further option for discussion by the working = group."

GIM>> I fully agree with the proposed = text.


    Cheers,
    Adrian

 

------=_NextPart_000_0436_01D376B9.E8CDB8E0-- From nobody Sat Dec 16 14:44:45 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 6DA40127A91 for ; Sat, 16 Dec 2017 14:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHy0e4pwC7oa for ; Sat, 16 Dec 2017 14:44:40 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 C76D0127444 for ; Sat, 16 Dec 2017 14:44:39 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id i2so14042785lfe.9 for ; Sat, 16 Dec 2017 14:44: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=8cMFE0DuoYS3RdY9/XOALh9SxeiwugWpAImGY6SD/74=; b=JjMkdb0mJ/Qy9S769Rj/bCnbm1hF5dFseFjkM7kaoQIV2epqpeCJ2ohkYuUj3YUeFR V01oag5v5hP4/Ie4MeEz2QrTkoI/XuwRtJ19nUdXoJbcJ3IJ2kEknT6qWyu3mMgZe8CM tQwFHhW11NhGxLCqD5MowSB/+wXujMa7mxjU/NDGGoVFGR4Aa6u8RGq7pfMfZfuTTtdq w0wEDgPYK5CdZU9cYmC1MvKUA7h8cloJQvvcUIIhJBVG/zqVHrDuAF+2TQFYRIX7gG5i Zq2ldJ9BPfjTNmOtylAhHxzpQ6yRGY01jna8QCSNeGu5tWHYHywkYw1A+UxdInxh6qc5 pkxg== 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=8cMFE0DuoYS3RdY9/XOALh9SxeiwugWpAImGY6SD/74=; b=KF8zqssW4feh1lc2LAIG8w8kUwZelMzpwLi3zaDp1KB/QnmI9it3rSf3n0/Ee/+xto L+os55HbQuG2wqHC9HIM2shAdC7xMjVTiIYydozuM5S2CAD+e5DTEmA0p4gfamPPYgZm kQoDkYrs3BR6kcXaN5mhekk6J4AWQJ8bEggrxzXJBa03++/Y3i+SgA8eT8Otp1g2Kffx 7INz0ABWloSAZYsE4Hw83ams9N7ofIUc1ACwCZCuvtDG8C9kNWKPFzaCTf555G8GHbE7 6HX0HmFJQwde02Bi/VZOUyVBAqB2juirAVHqD7MhkBdOxvwpqCZd1j4L9fOG+34NhpYF h0Uw== X-Gm-Message-State: AKGB3mJUKa5LEgZ9lsnWwd5VycoEL2onSzbb/qBw3PcdJFAaMdPc3LvJ I2TFx6DLy2lNyxtZ6DRs/N8oHziEeqSiwXGDWBY= X-Google-Smtp-Source: ACJfBosBOzEZZ2iMVYOE6k4JBzHAQ5msyjWqlM93Snr2O9Q0LbVjwSl0YNoXmR8cIep47JIqr+xqOhtxg8z1SrX4f+o= X-Received: by 10.46.1.205 with SMTP id f74mr8302089lji.16.1513464277944; Sat, 16 Dec 2017 14:44:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.32.136 with HTTP; Sat, 16 Dec 2017 14:44:37 -0800 (PST) In-Reply-To: <043501d376b9$e8c9e850$ba5db8f0$@olddog.co.uk> References: <0b7901d36fae$ed0dbed0$c7293c70$@olddog.co.uk> <4b563068-3011-2649-e7cc-d2cf619de3c2@joelhalpern.com> <043501d376b9$e8c9e850$ba5db8f0$@olddog.co.uk> From: Greg Mirsky Date: Sat, 16 Dec 2017 16:44:37 -0600 Message-ID: To: Adrian Farrel Cc: Service Function Chaining IETF list , "Joel M. Halpern" Content-Type: multipart/alternative; boundary="001a1142bbc2aacd4505607cdcca" Archived-At: Subject: Re: [sfc] WG Last Call for draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 22:44:43 -0000 --001a1142bbc2aacd4505607cdcca Content-Type: text/plain; charset="UTF-8" Hi Adrian, thank you for your thoughtful consideration and patience. I agree with the proposed new text. Happy holidays and the best wishes to all! Regards, Greg On Sat, Dec 16, 2017 at 4:04 PM, Adrian Farrel wrote: > OK, I think we are close. > > > > Rather than spending time defining what is and what is not "metadata" > (whether in the SFC context or more generally), we can leverage your > formulation. > > > > If we agree that OAM information might be carried between the NSH and the > payload, then we can have... > > OLD > > If OAM information is carried in packets that also include payload > > data, that information may be carried in metadata between the NSH > > and the payload. > > NEW > > If OAM information is carried in packets that also include payload > > data, that information might be carried between the NSH and the > > payload. > > END > > > > I see no reason to debate whether this OAM information is to be called > metadata or not, and so we can close the final issue from your review. > > > > BTW, I understand your concern that this might open up the field for doing > things that there is not support to do. But I don't think this section is > providing more than commentary on this point. Furthermore, if we were to > attempt to be proscriptive in this document, we would need a wider and > probably more fraught debate which would not sit well with the season of > goodwill that is Hanukkah. > > > > Cheers, > > Adrian > > > > > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* 16 December 2017 01:17 > *To:* Joel M. Halpern > *Cc:* Adrian Farrel; Service Function Chaining IETF list > *Subject:* Re: [sfc] WG Last Call for draft-farrel-sfc-convent > > > > Hi Joel, > > thank you for formulating clear questions to clarify my view on the > document. > > My remaining concern is with the proposed new text: > > "If OAM information is carried in packets that also include payload > data, that information may be carried in metadata between the NSH > and the payload." > > I can suggest to omit reference to metadata in this sentence, like "that > information may be carried between the NSH and the payload". But that would > effectively open the door for solutions similar to the one proposed in > draft-ooamdt-rtgwg-ooam-header. And it was strongly opposed by some > participants of SFC WG for exactly enabling such solution. > > > > Perhaps if no one else speaks up, we'll have rough consensus to move the > document forward as suggested by WG Chairs. > > > > Regards, > > Greg > > > > On Fri, Dec 15, 2017 at 6:57 PM, Joel M. Halpern > wrote: > > In order that we know where we stand on this document, let me ask you two > opposite questions: > > 1) There are clearly some aspects of this document with which you are > unhappy. With the change noted in the final portion of the email below, > can you live with the rest of the document as is? > > 2) Conversely, can you suggest specific text changes that would help > address your concerns? > > And to round out the set, are there other people in the working group who > share Greg's concern? If so, can you please comment, preferably with a > text suggestion that would address what drives your view of the issue? > > Yours, > Joel > > On 12/15/17 7:49 PM, Greg Mirsky wrote: > > Hi Adrian, > thank you for your kind consideration of my comments and thoughtful > responses. Please find my follow-up notes in-line tagged GIM>>. > > Happy holidays and the best wishes to all! > > Regards, > Greg > > On Thu, Dec 7, 2017 at 4:58 PM, Adrian Farrel > wrote: > > Hi Greg, > > Thanks for this. > > > I am glad that this document has been WG LC'ed. I support > progressing it but > > have reservations about section 5.4 that discusses use of None value > in OAM. > > Yes. The discussion of SFC OAM has come on a bit recently. > > > Below are my comments to the section 5,4: > > > > "If OAM information is carried in packets that also include payload > > data, that information must be carried in metadata." > > > > As noted in section 4 of draft-brockners-sfc-ioam-nsh, authors > consider > > encapsulating iOAM data after the SFC NSH using iOAM protcol type. > And > > what is 'must' in this statement - normative or mere observation? > > Yeah, maybe I was sloppy in my use of "metadata". However I think I > stand by what is written maybe with s/must be/is/. That is, it is > neither protocol header in the SFC layer nor payload, so it is > "metadata". > > GIM>> True, RFC 7665 does not define where the metadata may be placed but > in the very Introduction to NSH SFC stated that the metadata is part of NSH: > > The NSH is composed of the following elements: 1. Service Function Path > identification. 2. Indication of location within a Service Function Path. > 3. Optional, per packet metadata (fixed length or variable). > > > > Yes, I think iOAM is metadata. But obviously not NSH metadata. > > I don't want to get into the debate (here) about the problems of > using Next Protocol == iOAM when there is data present, or the > preferable action of defining a T2 metadata TLV to contain the iOAM > stuff, or anything else about iOAM. > > Anyway, the way we should cover this is... > > "If OAM information is carried in packets that also include payload > data, that information may be carried in metadata between the NSH > and the payload." > > GIM>> As noted, the metadata is one of the elements of NSH and thus cannot > be outside of it. > > > > "Sending OAM separate from (but interleaved with) packets that carry > > payload data ..." > > This is the case when specially constructed test packets injected in > the network solely > > for purpose of performing OAM functions, e.g. performance > measurement. This is > > active OAM, according to RFC 7799, and, as discussed in > draft-wang-sfc-multi-layer-oam > > and presented in the meeting in Singapore, there are different ways > to perform active > > OAM over SFC NSH domain. Because progress of > draft-wang-sfc-multi-layer-oam and > > other active SFC OAM drafts is awaiting new charter of the SFC WG, > including None > > protocol solution in standard RFC, in my opinion, creates > unnecessary and unhelpful > > multiplicity of options that will complicate implementations and may > cause interoperability > > issues. All of that may be avoided if authors decide to take the > section 5.4 out from the > > document and have the discussion of active OAM in scope of > discussion of > > draft-wang-sfc-multi-layer-oam. > > Why debate today that which can usefully be put off until tomorrow? > > Now, I know that this document was not adopted by the WG, but it is > a bit harsh to cite another individual draft as reasoning for > changing this document. > > As we have known for some time, we have a multiplicity of ways to > indicate the presence of OAM, and no clarity in the WG. > draft-wang-sfc-multi-layer-oam has a neat solution to reducing the > number of mechanisms by requiring that two are used at once :-) > > But it is not my intention to define how OAM is performed in an NSH > network, just to show how it might be performed. > > What if we soften the language by adding a paragraph such as: > > "Mechanisms for providing active OAM [RFC7799] in an SFC network > have been proposed [I-D.wang-sfc-multi-layer-oam]. This use case is > not intended to define another mechanism for active OAM, but does > illustrate a further option for discussion by the working group." > > GIM>> I fully agree with the proposed text. > > > Cheers, > Adrian > > > --001a1142bbc2aacd4505607cdcca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,
thank you for your thoughtful consideration= and patience. I agree with the proposed new text.

Happy holidays and the best wishes to all!

Regard= s,
Greg

On Sat, Dec 16, 2017 at 4:04 PM, Adrian Farrel <adrian@olddo= g.co.uk> wrote:

OK, I thi= nk we are close.

=C2=A0

Rather than spending time defining what is and what i= s not "metadata" (whether in the SFC context or more generally), = we can leverage your formulation.

=C2=A0

If we agree that OAM information = might be carried between the NSH and the payload, then we can have...

OLD=

=C2=A0=C2=A0=C2=A0 If OAM information is carri= ed in packets that also include payload

=C2=A0=C2=A0=C2=A0 data= , that information may be carried in metadata between the NSH=

=C2=A0= =C2=A0=C2=A0 and the payload.

NEW

=C2=A0= =C2=A0=C2=A0 If OAM information is carried in packets that also incl= ude payload

=C2=A0=C2=A0=C2=A0 data, that information mi= ght be carried between the NSH and the

=C2=A0=C2=A0 =C2= =A0payload.

END

=C2=A0

= I see no reason to debate whether this OAM infor= mation is to be called metadata or not, and so we can close the final issue= from your review.

=C2=A0

BTW, I understand your concern that this might open= up the field for doing things that there is not support to do. But I don&#= 39;t think this section is providing more than commentary on this point. Fu= rthermore, if we were to attempt to be proscriptive in this document, we wo= uld need a wider and probably more fraught debate which would not sit well = with the season of goodwill that is Hanukkah.

=C2=A0

Cheers,

Adrian<= /u>

=C2= =A0

<= /u>=C2=A0

<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif"">From: Greg = Mirsky [mailto:g= regimirsky@gmail.com]
Sent: 16 December 2017 01:17
To:= Joel M. Halpern
Cc: Adrian Farrel; Service Function Chaining= IETF list
Subject: Re: [sfc] WG Last Call for d= raft-farrel-sfc-convent

=C2=A0

Hi Joel,=

thank = you for formulating clear questions to clarify my view on the document.=C2= =A0

My remaining concern= is with the proposed new text:

=C2=A0 =C2=A0 "If OAM information is carried in packet= s that also include payload
=C2=A0 =C2=A0 data, that information may be = carried in metadata between the NSH
=C2=A0 =C2=A0 and the payload."=

I can su= ggest to omit reference to metadata in this sentence, like "that infor= mation may be carried between the NSH and the payload". But that would= effectively open the door for solutions similar to the one proposed in=C2= =A0draft-ooamdt-rtgwg-ooam-header. And it was strongly = opposed by some participants of SFC WG for exactly enabling such solution.<= /span>

=C2=A0<= /u>

Perhaps if no one else spe= aks up, we'll have rough consensus to move the document forward as sugg= ested by WG Chairs.

=C2=A0

Regard= s,

Greg

=C2=A0

On Fri, Dec 15, 2017 at 6:57 PM, Joel M. = Halpern <jmh@jo= elhalpern.com> wrote:

In ord= er that we know where we stand on this document, let me ask you two opposit= e questions:

1) There are clearly some aspects of this document with= which you are unhappy.=C2=A0 With the change noted in the final portion of= the email below, can you live with the rest of the document as is?

= 2) Conversely, can you suggest specific text changes that would help addres= s your concerns?

And to round out the set, are there other people in= the working group who share Greg's concern?=C2=A0 If so, can you pleas= e comment, preferably with a text suggestion that would address what drives= your view of the issue?

Yours,
Joel

On 12/15/17 7:49 PM, Greg Mirsky wrote:

Hi Adrian,
thank you for your kind consideration of my commen= ts and thoughtful responses. Please find my follow-up notes in-line tagged = GIM>>.

Happ= y holidays and the best wishes to all!

Regards,
Greg

On Thu, Dec 7, 2017 at 4:58 PM, Adrian Farrel &= lt;adrian@olddog.c= o.uk <mailto:adrian@olddog.co.uk>> wrote:

=C2=A0 =C2=A0 Hi Greg,
<= br>=C2=A0 =C2=A0 Thanks for this.

=C2=A0 =C2=A0 > I am glad that = this document has been WG LC'ed. I support progressing it but
=C2=A0= =C2=A0 > have reservations about section 5.4 that discusses use of None= value in OAM.

=C2=A0 =C2=A0 Yes. The discussion of SFC OAM has come= on a bit recently.

=C2=A0 =C2=A0 > Below are my comments to the = section 5,4:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > "If OAM infor= mation is carried in packets that also include payload
=C2=A0 =C2=A0 >= ; data, that information must be carried in metadata."
=C2=A0 =C2= =A0 >
=C2=A0 =C2=A0 > As noted in section 4 of draft-brockners-sfc= -ioam-nsh, authors consider
=C2=A0 =C2=A0 > encapsulating iOAM data a= fter the SFC NSH using iOAM protcol type. And
=C2=A0 =C2=A0 > what is= 'must' in this statement - normative or mere observation?

= =C2=A0 =C2=A0 Yeah, maybe I was sloppy in my use of "metadata". H= owever I think I
=C2=A0 =C2=A0 stand by what is written maybe with s/mus= t be/is/. That is, it is
=C2=A0 =C2=A0 neither protocol header in the SF= C layer nor payload, so it is
=C2=A0 =C2=A0 "metadata".
GIM>> True, RFC 7665 does not define where the metadata may be place= d but in the very Introduction to NSH SFC stated that the metadata is part = of NSH:

The NSH is composed of the following elements: 1. Service Fu= nction Path identification. 2. Indication of location within a Service Func= tion Path. 3. Optional, per packet metadata (fixed length or variable).
=


=C2=A0 =C2=A0 Yes, I think iOAM is metadata. But obviously not = NSH metadata.

=C2=A0 =C2=A0 I don't want to get into the debate = (here) about the problems of
=C2=A0 =C2=A0 using Next Protocol =3D=3D iO= AM when there is data present, or the
=C2=A0 =C2=A0 preferable action of= defining a T2 metadata TLV to contain the iOAM
=C2=A0 =C2=A0 stuff, or = anything else about iOAM.

=C2=A0 =C2=A0 Anyway, the way we should co= ver this is...

=C2=A0 =C2=A0 "If OAM information is carried in = packets that also include payload
=C2=A0 =C2=A0 data, that information m= ay be carried in metadata between the NSH
=C2=A0 =C2=A0 and the payload.= "

GIM>> As noted, the metadata is one of the elements of = NSH and thus cannot be outside of it.


=C2=A0 =C2=A0 > "S= ending OAM separate from (but interleaved with) packets that carry
=C2= =A0 =C2=A0 > payload data ..."
=C2=A0 =C2=A0 > This is the ca= se when specially constructed test packets injected in the network solely=C2=A0 =C2=A0 > for purpose of performing OAM functions, e.g. performa= nce measurement. This is
=C2=A0 =C2=A0 > active OAM, according to RFC= 7799, and, as discussed in draft-wang-sfc-multi-layer-oam
=C2=A0 =C2=A0= > and presented in the meeting in Singapore, there are different ways t= o perform active
=C2=A0 =C2=A0 > OAM over SFC NSH domain. Because pro= gress of draft-wang-sfc-multi-layer-oam and
=C2=A0 =C2=A0 > other act= ive SFC OAM drafts is awaiting new charter of the SFC WG, including None=C2=A0 =C2=A0 > protocol solution in standard RFC, in my opinion, creat= es unnecessary and unhelpful
=C2=A0 =C2=A0 > multiplicity of options = that will complicate implementations and may cause interoperability
=C2= =A0 =C2=A0 > issues. All of that may be avoided if authors decide to tak= e the section 5.4 out from the
=C2=A0 =C2=A0 > document and have the = discussion of active OAM in scope of discussion of
=C2=A0 =C2=A0 > dr= aft-wang-sfc-multi-layer-oam.

=C2=A0 =C2=A0 Why debate today th= at which can usefully be put off until tomorrow?

=C2=A0 =C2=A0 Now, = I know that this document was not adopted by the WG, but it is
=C2=A0 = =C2=A0 a bit harsh to cite another individual draft as reasoning for
=C2= =A0 =C2=A0 changing this document.

=C2=A0 =C2=A0 As we have known fo= r some time, we have a multiplicity of ways to
=C2=A0 =C2=A0 indicate th= e presence of OAM, and no clarity in the WG.
=C2=A0 =C2=A0 draft-wang-sf= c-multi-layer-oam has a neat solution to reducing the
=C2=A0 =C2=A0 numb= er of mechanisms by requiring that two are used at once :-)

=C2=A0 = =C2=A0 But it is not my intention to define how OAM is performed in an NSH<= br>=C2=A0 =C2=A0 network, just to show how it might be performed.

= =C2=A0 =C2=A0 What if we soften the language by adding a paragraph such as:=

=C2=A0 =C2=A0 "Mechanisms for providing active OAM [RFC7799] i= n an SFC network
=C2=A0 =C2=A0 have been proposed [I-D.wang-sfc-multi-la= yer-oam]. This use case is
=C2=A0 =C2=A0 not intended to define ano= ther mechanism for active OAM, but does
=C2=A0 =C2=A0 illustrate a furth= er option for discussion by the working group."

GIM>> I f= ully agree with the proposed text.


=C2=A0 =C2=A0 Cheers,
=C2= =A0 =C2=A0 Adrian

=

=C2=A0


--001a1142bbc2aacd4505607cdcca-- From nobody Thu Dec 21 01:57: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 C0FFF12D77B for ; Thu, 21 Dec 2017 01:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=interdigital.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 1gAf7alZdF1R for ; Thu, 21 Dec 2017 01:57:34 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0102.outbound.protection.outlook.com [104.47.40.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10DBD1273E2 for ; Thu, 21 Dec 2017 01:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interdigital.onmicrosoft.com; s=selector1-interdigital-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BjiYAR8qd8MrE03AMvjMiyddAAKWsVWDLGx3BsHqZsg=; b=GIUjUyecUJXlEOxhS2912hrEaRe/YiT8Faiwp8/VVRIZoqEw8CYIBFnXe1vzkQblIiSpLEQd8c754s3Lu9qr8zDs/GyWFkA4bwiZG4OJ583C+haKyRmsJ+InsIXa+FHHg37d4xC9bX+2sLOVSVn5HC64feGBGg3P4Sp1J7Taxr4= Received: from BN6PR1001MB2324.namprd10.prod.outlook.com (10.174.88.32) by BN6PR1001MB2322.namprd10.prod.outlook.com (10.174.88.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Thu, 21 Dec 2017 09:57:31 +0000 Received: from BN6PR1001MB2324.namprd10.prod.outlook.com ([10.174.88.32]) by BN6PR1001MB2324.namprd10.prod.outlook.com ([10.174.88.32]) with mapi id 15.20.0323.018; Thu, 21 Dec 2017 09:57:31 +0000 From: "Trossen, Dirk" To: James N Guichard , "'Service Function Chaining IETF list'" CC: Alia Atlas Thread-Topic: SFC WG re-chartering - initial text for WG review/comment Thread-Index: AdNyuLcja4roriHRQZ67o9nPI1G8tQHiLsEB Date: Thu, 21 Dec 2017 09:57:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dirk.Trossen@InterDigital.com; x-originating-ip: [141.0.151.202] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR1001MB2322; 6:PgbqCBOatFzaQna/c+Ah8bCWTXIvW1/CSpF9j+/6qAxUMwZ8af9jks7lnJ0b1kusYbaA9ZrFeANJqB9WKgK0yTt+Ijm4yibsFyAogE8WO+aZnc81Gbp1Y9YPJ4n2ysGREXevlmN5Euoy0wxnepcFthUvn1xh5irMB/QF+Hd3nkyXSejbI4OFv9sivzsRM13hzz4d9/6jaYeejJ5RKpNeQRtiFuy9lt/nLp4EYccu2hDEHMsQxbfAjKKodeDLcK4exhWj+udSEM9clBppwtmxzd1kg5gyPNqq1X+ayeW1O/mg6LCdWNl3t++gt9zDU1pWMGNAGv68GvIJBcugdfc1oypR9f5V5mL1Nau6vTI+C1M=; 5:IO5NyzJ+lekWfsPC+zp3+4qok2uIFvnXMPtMQVEZN05mR0vbrLBehT/U9w+UVbUjduXsA0rDX3PPdE8RrLg3cPF7jkbiYc9Hcu0Fs4MRYKLW3RrHY+aRCPixSa3MDDsdJu5xAhB/TI03ja7HAh9m6IyRjHmKHF/mV0MmZ7B4foo=; 24:aTf/FrCmF2uo28eOnEmE7rEi091qRwKm6G+yUE79HMijPBbp0yRZ7TRzadsOzXYfnP8GxR5UWbyCs4VVzT+wB01JqTcjIAdqJjTG1rBA17g=; 7:8tUY/96CilquDpvx4N+bjMLwMjRWANPpJJva30xxBBY9dYhNxNKM6C+4OgnWBNSxjEXKGMnialBXpC3N66bB3KQvXjAbWKxw9Uubx6WEGbgThEMLMEFeJIP0P+8/DJZT2deyKsE4mDv2JCG8JDwJovWR+LoiZGt872QKSk/TGGWzMiewhF6h176xTfD0KjhLhe9omZ/6N5Ps0WhVDNCVdq0qAjVzNhdPQ6Zf2sNYmc60Mwy5INMZcOfyzTy/YoDh x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 087f56dd-6824-483f-dd00-08d548594075 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(3008031)(2017052603307)(7153060); SRVR:BN6PR1001MB2322; x-ms-traffictypediagnostic: BN6PR1001MB2322: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231023)(93006095)(93001095)(6041268)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(2016111802025)(20161123564045)(6072148)(6043046)(201708071742011); SRVR:BN6PR1001MB2322; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR1001MB2322; x-forefront-prvs: 0528942FD8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(396003)(366004)(346002)(39380400002)(39830400003)(376002)(189003)(199004)(66066001)(4326008)(99286004)(7696005)(6246003)(25786009)(76176011)(39060400002)(55016002)(54896002)(9686003)(59450400001)(478600001)(102836004)(77096006)(53546011)(229853002)(6506007)(68736007)(74316002)(72206003)(7736002)(97736004)(14454004)(2906002)(110136005)(106356001)(19627405001)(3280700002)(6436002)(6116002)(3660700001)(2900100001)(3846002)(8936002)(2950100002)(6606003)(105586002)(86362001)(81166006)(5660300001)(33656002)(53936002)(8676002)(316002)(81156014)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1001MB2322; H:BN6PR1001MB2324.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: InterDigital.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR1001MB2324D21445864DE32D1B018DF30D0BN6PR1001MB2324_" MIME-Version: 1.0 X-OriginatorOrg: interdigital.com X-MS-Exchange-CrossTenant-Network-Message-Id: 087f56dd-6824-483f-dd00-08d548594075 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2017 09:57:31.1673 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e351b779-f6d5-4e50-8568-80e922d180ae X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1001MB2322 Archived-At: Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 09:57:37 -0000 --_000_BN6PR1001MB2324D21445864DE32D1B018DF30D0BN6PR1001MB2324_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable James, all, Thanks for this excellent start for the planned re-chartering. I'd would li= ke to pick on this, particularly on the fourth topic (transport considerati= ons), and propose two specific topics for a new charter: Optimized chaining: this extends on the proposed fourth topic (which I supp= ort) by incorporating feedback, such as congestion indications, from transp= ort networks as well as the (possibly virtualized) service instances along = the SFP. Hence, this topic is about optimized control for the construction = and re-chaining of SFPs where the =91data points=92 for the decision making= can come from above or below the SFC delivery mechanism. Flexible chaining: this proposed topic extends the previous item in that it= builds on the desire to flexibly re-chain SFCs, particularly in situations= where virtualized service instances exist and dynamic decisions are being = taken for such re-chaining between such virtualized instances. Such flexibi= lity could be achieved by raising the abstraction level of the SFP from lay= er2/3 to that of a name-based service where the SF endpoint is being provid= ed as a name rather than a MAC or IP address. With that, the name-based SFP= remains the same even if changes in the currently used virtualized service= instances occur, bringing SFC closer to data centre networking and many of= the associated scenarios. What drives the need for such optimization and flexibility? Virtualization = of service instances, particularly through containers, certainly does and = particular when such virtualized service instances reside in a number of (p= ossibly regionally) distributed micro-data centres. In terms of delivery, item 1 would lead to an (informational?) RFC specifyi= ng the possible data points leading to the construction of optimized SFCs, = while item 2 would lead to an RFC for a design for flexible chaining for a = name-level SFP. Looking forward to receiving comments on this. Best, Dirk ________________________________ From: sfc on behalf of James N Guichard Sent: 11 December 2017 8:13 PM To: 'Service Function Chaining IETF list' Cc: Alia Atlas Subject: [sfc] SFC WG re-chartering - initial text for WG review/comment Greetings WG: Joel and I have taken an initial stab at new charter text for the SFC WG. P= lease review and provide comments/suggestions by COB Friday 29th December (= 2 weeks). Network operators frequently utilize service functions such as packet filte= ring at firewalls, load-balancing and transactional proxies (for example sp= am filters) in the delivery of services to end users. Delivery of these typ= es of services is undergoing significant change with the introduction of vi= rtualization, network overlays, and orchestration. The SFC Working Group has developed an Architecture [RFC 7665] and a protoc= ol (the Network Service Header [draft-ietf-sfc-nsh-28], in the RFC Editor q= ueue as of this drafting.) The focus of the SFC working group moving forward will be on aspects of the= architecture and/or protocol that need to be addressed to enable effective= deployment and usage of this work. The SFC working group will now begin a= ddressing those items. In order to maintain focus, the working group will = primarily produce and advance documents on four topics: 1) Metadata - we need to define the common type-length-value encoded metada= ta types with standards track RFCs, and produce informational RFCs to descr= ibe common fixed-length (MD-1) metadata usages. 2) Security - The completed work does not provide mechanisms for authentica= ting or protecting (either for integrity or from inspection) metadata. The= re are a number of open questions as to what can be effectively provided an= d how to provide such tools. These need attention. 3) OAM and O&M - In order for operators to use these tools in production ne= tworks, they need Operations, Administration, and Maintenance tools, as wel= l as management mechanisms. This includes YANG models, OAM frameworks, and= specific OAM mechanisms to address operational needs. 4) Transport Considerations - this will capture the expectations SFC places= on transport behavior, including dealing with issues such as congestion in= dications and responses. Specifically, the SFC WG is chartered to deliver the following: 1. A standards track base set of MD-2 type codes within the metadata class = reserved for IETF usage. 2. Related Metadata drafts that require more explanation than is reasonable= to include in the base MD-2 draft, including MD-1 descriptions and items d= one once the base draft is complete. 3. YANG models for the SFC Components. 4. One or more security related standards track and / or informational RFCs= . At least one standards track security mechanism RFC is needed. 5. OAM Framework document to provide a common basis for OAM work. This dra= ft will include guidance on how active, passive, and in-situ OAM are to be = supported if at all. 6. Specific OAM mechanism documents to provide the tools needed for operati= onal environments. 7. Transport Considerations RFC to cover the expectations SFC and NSH place= on transport, and the operational constraints transports used by NSH need = to meet. Thanks! Jim & Joel --_000_BN6PR1001MB2324D21445864DE32D1B018DF30D0BN6PR1001MB2324_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

James, all,
 
Thanks for this excellent start for the planned re-chartering. I'd wou= ld like to pick on this, particularly on the fourth topic (transport consid= erations), and propose two specific topics for a new charter:

Optimized chaining: this extends on t= he proposed fourth topic (which I support) by incorporating feedback, such = as congestion indications, from transport networks as well as the (possibly= virtualized) service instances along the SFP. Hence, this topic is about optimized control for the construction= and re-chaining of SFPs where the =91data points=92 for the decision makin= g can come from above or below the SFC delivery mechanism.

Flexible chaining: this proposed topic ext= ends the previous item in that it builds on the desire to flexibly re-chain= SFCs, particularly in situations where virtualized service instances exist= and dynamic decisions are being taken for such re-chaining between such virtualized instances. Such flexibility = could be achieved by raising the abstraction level of the SFP from lay= er2/3 to that of a name-based service where the SF endpoint is being provid= ed as a name rather than a MAC or IP address. With that, the name-based SFP remains the same even if changes in= the currently used virtualized service instances occur, bringing SFC close= r to data centre networking and many of the associated scenarios.
 
What drives the need for such optimiz= ation and flexibility? Virtualization of service instances, particularly th= rough containers,  certainly does and particular when such virtualized= service instances reside in a number of (possibly regionally) distributed micro-data centres.
 
In terms of delivery, item 1 would le= ad to an (informational?) RFC specifying the possible data points leading t= o the construction of optimized SFCs, while item 2 would lead to an RFC for= a design for flexible chaining for a name-level SFP.

Looking forward to receiving comments on this.

Best,

Dirk



From: sfc <sfc-bounces@i= etf.org> on behalf of James N Guichard <james.n.guichard@huawei.com&g= t;
Sent: 11 December 2017 8:13 PM
To: 'Service Function Chaining IETF list'
Cc: Alia Atlas
Subject: [sfc] SFC WG re-chartering - initial text for WG review/com= ment
 

Greetings WG:

 

Joel and I have taken an initial stab at new chart= er text for the SFC WG. Please review and provide comments/suggestions by C= OB Friday 29th December (2 weeks).

 

 

Network operators frequently utilize service funct= ions such as packet filtering at firewalls, load-balancing and transactiona= l proxies (for example spam filters) in the delivery of services to end use= rs. Delivery of these types of services is undergoing significant change with the introduction of virtualization, = network overlays, and orchestration.

 

The SFC Working Group has developed an Architectur= e [RFC 7665] and a protocol (the Network Service Header [draft-ietf-sfc-nsh= -28], in the RFC Editor queue as of this drafting.)

 

The focus of the SFC working group moving forward = will be on aspects of the architecture and/or protocol that need to be addr= essed to enable effective deployment and usage of this work.  The SFC = working group will now begin addressing those items.  In order to maintain focus, the working group will prim= arily produce and advance documents on four topics:

 

1) Metadata - we need to define the common type-le= ngth-value encoded metadata types with standards track RFCs, and produce in= formational RFCs to describe common fixed-length (MD-1) metadata usages.

 

2) Security - The completed work does not provide = mechanisms for authenticating or protecting (either for integrity or from i= nspection) metadata.  There are a number of open questions as to what = can be effectively provided and how to provide such tools.  These need attention.

 

3) OAM and O&M - In order for operators to use= these tools in production networks, they need Operations, Administration, = and Maintenance tools, as well as management mechanisms.  This include= s YANG models, OAM frameworks, and specific OAM mechanisms to address operational needs.

 

4) Transport Considerations - this will capture th= e expectations SFC places on transport behavior, including dealing with iss= ues such as congestion indications and responses.

 

Specifically, the SFC WG is chartered to deliver t= he following:

 

1. A standards track base set of MD-2 type codes w= ithin the metadata class reserved for IETF usage.

 

2. Related Metadata drafts that require more expla= nation than is reasonable to include in the base MD-2 draft, including MD-1= descriptions and items done once the base draft is complete.

 

3. YANG models for the SFC Components.

 

4. One or more security related standards track an= d / or informational RFCs.  At least one standards track security mech= anism RFC is needed.

 

5. OAM Framework document to provide a common basi= s for OAM work.  This draft will include guidance on how active, passi= ve, and in-situ OAM are to be supported if at all.

 

6. Specific OAM mechanism documents to provide the= tools needed for operational environments.

 

7. Transport Considerations RFC to cover the expec= tations SFC and NSH place on transport, and the operational constraints tra= nsports used by NSH need to meet.

 

 

Thanks!

 

Jim & Joel

 

 

 

 

--_000_BN6PR1001MB2324D21445864DE32D1B018DF30D0BN6PR1001MB2324_-- From nobody Thu Dec 21 08:56:11 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 2550212D779 for ; Thu, 21 Dec 2017 08:56:10 -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 mFrrBQ7bAWRh for ; Thu, 21 Dec 2017 08:56:07 -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 6F9C8129C6A for ; Thu, 21 Dec 2017 08:56:07 -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 vBLGu3J6031446 for ; Thu, 21 Dec 2017 16:56:04 GMT Received: from 950129200 (59.200.112.87.dyn.plus.net [87.112.200.59]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id vBLGu1GV031416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Dec 2017 16:56:02 GMT Reply-To: From: "Adrian Farrel" To: "'Service Function Chaining IETF list'" References: <151387499457.12912.2560094618016656526@ietfa.amsl.com> In-Reply-To: <151387499457.12912.2560094618016656526@ietfa.amsl.com> Date: Thu, 21 Dec 2017 16:56:01 -0000 Message-ID: <02aa01d37a7c$95b6b9b0$c1242d10$@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: AQIbiC7worCSwTykaVkb26f7cITWE6K96BLw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.2.0.1013-23544.001 X-TM-AS-Result: No--8.604-10.0-31-10 X-imss-scan-details: No--8.604-10.0-31-10 X-TMASE-MatchedRID: r0+rmqCHJUXVFtf7bVfns+G5dRZCgxC3C4rWEiK1Igeo+b+yOP0oGPls PPuhHQmUMelH7qhnqUF3LAVrYE2iqYx8jP90278eQr2qXCJMSV8gIlfZcIw7oB2MqMQkpb/vaRn uwdqIKHv+JciIkC3M9vFPDHhQkgxygtJ1kfzs6mBlFfOakgtegxtPDNiPbNC6RjHvrQ40NxY20Y +0MQ/nvYSaYXP5Ehtmg1emVz3Y/UKeJDeXRpqc2s5Scd0yVs+bbv16+gil4jfQpokFSTvCgBREX ZwhDuFxMd29FAZi1bbuPbbc/RTvR0MR/ZdMRWYGPm1rpha4uTaEQiKo28GuY4ie9XwPLRlozwFK o3nqgBGitiouylJVoAWgef1C0L+eCLTFoW0rIaq8coKUcaOOvSGZtiDVlw6eZNidnn9zXd+YQaA gPdwqQ6sYtBg6eQ9370Qm3YXk6SxNfs8n85Te8v7E6GNqs6ceseWplitmp0j6C0ePs7A07RjOlt 1Pi553Zj6TELqJpXDEemHdE5NTwNgXOGxqKTtM3cwsX0bL6mI= Archived-At: Subject: [sfc] FW: I-D Action: draft-farrel-sfc-convent-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 16:56:10 -0000 Hi, If my arithmetic is correct, the allotted time (3 weeks0 for WG last call of this draft has completed. So I made an update picking up the comments as discussed on the mailing list. Thanks, and best wishes for a festive period. Adrian -- Buy someone a book for Christmas Tales from the Wood - Eighteen new fairy tales More Tales from the Wood - Eighteen MORE new fairy tales Tales from Beyond the Wood - A bumper collection of twenty-two new tales https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 21 December 2017 16:50 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-farrel-sfc-convent-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Operating the Network Service Header (NSH) with Next Protocol > "None" > Authors : Adrian Farrel > John Drake > Filename : draft-farrel-sfc-convent-04.txt > Pages : 11 > Date : 2017-12-21 > > Abstract: > This document describes the use of the Network Service Header (NSH) > in a Service Function Chaining (SFC) enabled network with no payload > data and carrying only metadata. This is achieved by defining a new > NSH "Next Protocol" type value of "None". > > This document illustrates some of the functions that may be achieved > or enhanced by this mechanism, but it does not provide an exhaustive > list of use cases, nor is it intended to be definitive about the > functions it describes. It is expected that other documents will > describe specific use cases in more detail and will define the > protocol mechanics for each use case. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrel-sfc-convent/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-farrel-sfc-convent-04 > https://datatracker.ietf.org/doc/html/draft-farrel-sfc-convent-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-farrel-sfc-convent-04 > > > 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 Thu Dec 21 10:24: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 ECA82129C6D for ; Thu, 21 Dec 2017 10:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8tXzfaT0JQ7 for ; Thu, 21 Dec 2017 10:24:39 -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 B3F0B1241F3 for ; Thu, 21 Dec 2017 10:24:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9C96BCA6C7C for ; Thu, 21 Dec 2017 10:24:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1513880679; bh=I9+egpWew58q2k90+6/NIKEgGrRqyjEbez7lnwhpotQ=; h=Subject:From:To:References:Date:In-Reply-To:From; b=YxX5YJBMYi8Tf9xcZRZbB3yV0uzQ64wz0IA4NCXrI1n9SQQb5GfJNbF9O8Oyqx2Qn paR6EvEtjLXraPdwxnyejSzVyzx9VCCCMwq4dQRETuGkohJE1lV4iIE7nT2TVOD2sh dC/VzHZvERuVOEP3ZFLfqZJ5f2GlxbDBEX0I33E8= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4411324030E for ; Thu, 21 Dec 2017 10:24:39 -0800 (PST) From: "Joel M. Halpern" To: "sfc@ietf.org" References: Message-ID: <4ff4abb8-ea45-1704-b138-b39c293df310@joelhalpern.com> Date: Thu, 21 Dec 2017 13:24:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG Adoption calls: two MD-1 drafts X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 18:24:41 -0000 This Adoption call has completed. Based on the positive feedback, the working group has adopted these documents. Authors, please submit new documents: draft-ietf-sfc-nsh-broadband-allocation and draft-ietf-sfc-nsh-dc-allocation. Yours, Joel On 11/29/17 4:19 PM, Joel M. Halpern wrote: > The WG chairs have been asked to issue calls for adoption for two of the > MD-1 related drafts: > > https://datatracker.ietf.org/doc/draft-napper-sfc-nsh-broadband-allocation/ > > and > > https://datatracker.ietf.org/doc/draft-guichard-sfc-nsh-dc-allocation/ > > These documents aim for publication as Informational RFCs. > > As Jim is the coauthor on one of these two, I will be overseeing both > adoption calls. > > Given that there are two last calls an two calls for working group > adoption (see following emails) we are allowing 3 weeks for these calls. > > Please respond with either support or objection to the WG adopting > either or both of these documents. > > We need to see feedback.  Silence does not imply consent. > We would prefer feedback with content. > > Thank you, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Dec 21 10:27:17 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 0D3FC129C6D for ; Thu, 21 Dec 2017 10:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2iBStQFblft for ; Thu, 21 Dec 2017 10:27:13 -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 5F0DD1241F3 for ; Thu, 21 Dec 2017 10:27:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4A1EACA6C82 for ; Thu, 21 Dec 2017 10:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1513880833; bh=V9AUORgqxSkkCeu8SByts/JD9paG8zHhcPyUvxBBngI=; h=Subject:From:To:References:Date:In-Reply-To:From; b=hQsU+n6I/Rl4Q3zG4M4e1L2J5Jp+ROkP/ZFZJlspmnGBEXAcupMTLpbIjcqImhuOH DEhgVT3M2ngnvmfK26UUaQgyEXNKn+6eVy6eKFnoPdgJZmIXDLEnzPL9QWKfS7CX5B avY4L0Cdn7unjZoee50dMkEraD3k8j/e00o3+2Qk= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E2E8ECA6C70 for ; Thu, 21 Dec 2017 10:27:12 -0800 (PST) From: "Joel M. Halpern" To: "sfc@ietf.org" References: Message-ID: <2db58a00-e439-d5ae-c26a-4de7931266f0@joelhalpern.com> Date: Thu, 21 Dec 2017 13:27:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] WG Last Call for draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 18:27:15 -0000 This WG Last Call is completed. With the changes that were discussed and have been applied (thank you Adrian) the document is approved. We will be getting a shepherd and shepherd writeup so as to get this in front of our Area Director when she returns from the holidays. Thank you to all who helped with this. Yours, Joel and Jim On 11/29/17 4:13 PM, Joel M. Halpern wrote: > This draft > https://tools.ietf.org/html/draft-farrel-sfc-convent-02 > > has been rpesented at several IETF meetings.  It provides a small > elaboration on the NSH document.  There seemed to be good working group > acceptance of the work, although we never formally adopted it. > > The WG Chairs have determined that it makes sense to go directly to a WG > last call on this document. > Given that there are two last calls an two calls for working group > adoption (see following emails) we are allowing 3 weeks for these calls. > > Please respond with either support or objection to the WG delivering > this document to our area director for publication as a Proposed > Standard RFC. > > We need to see feedback.  Silence does not imply consent. > We would prefer feedback with content. > > Thank you, > Joel (& Jim) > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Dec 21 10:30:39 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 29BB6129C6A; Thu, 21 Dec 2017 10:30:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151388103716.12962.18317546245092968321.idtracker@ietfa.amsl.com> Date: Thu, 21 Dec 2017 10:30:37 -0800 Archived-At: Subject: [sfc] The SFC WG has placed draft-farrel-sfc-convent in state "WG Consensus: Waiting for Write-Up" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 18:30:37 -0000 The SFC WG has placed draft-farrel-sfc-convent in state WG Consensus: Waiting for Write-Up (entered by Joel Halpern) The document is available at https://datatracker.ietf.org/doc/draft-farrel-sfc-convent/ Comment: Document has completed WG Last call successfully. From nobody Thu Dec 21 10:33:08 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 028EC12DA16; Thu, 21 Dec 2017 10:33:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151388118700.12887.11272121539530805336.idtracker@ietfa.amsl.com> Date: Thu, 21 Dec 2017 10:33:07 -0800 Archived-At: Subject: [sfc] The SFC WG has placed draft-napper-sfc-nsh-broadband-allocation in state "Adopted by a WG" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 18:33:07 -0000 The SFC WG has placed draft-napper-sfc-nsh-broadband-allocation in state Adopted by a WG (entered by Joel Halpern) The document is available at https://datatracker.ietf.org/doc/draft-napper-sfc-nsh-broadband-allocation/ Comment: Document adopted by WG. ID will be resubmitted by authors under new name. From nobody Thu Dec 21 11:11: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 20F0112D7EB for ; Thu, 21 Dec 2017 11:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 eHsX2b5N439Q for ; Thu, 21 Dec 2017 11:11:38 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162BC124BE8 for ; Thu, 21 Dec 2017 11:11:38 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id EB7ADF2FC350 for ; Thu, 21 Dec 2017 19:11:33 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 21 Dec 2017 19:11:35 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML702-CHM.china.huawei.com ([169.254.4.18]) with mapi id 14.03.0361.001; Thu, 21 Dec 2017 11:11:28 -0800 From: James N Guichard To: 'Service Function Chaining IETF list' CC: Alia Atlas Thread-Topic: WGLC draft-ietf-sfc-hierarchical-05 Thread-Index: AdN6jBO9dBwJqMzhR1COhKMUTf/1Qw== Date: Thu, 21 Dec 2017 19:11:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.14] Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3134C578Fsjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [sfc] WGLC draft-ietf-sfc-hierarchical-05 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 19:11:40 -0000 --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3134C578Fsjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG: The chairs issued a WG last call for https://datatracker.ietf.org/doc/draft= -ietf-sfc-hierarchical/ on 11/29/17. We have received little feedback and w= ould prefer to see more WG participants voice support before we pass the do= cument to our AD. Therefore, this email extends the WG last call for a further 3 weeks (takin= g into consideration holidays) and will therefore expire on 1/11/18. Please respond with either support or objection to the WG delivering this d= ocument to our area director for publication as an Informational RFC. Thanks! Jim & Joel --_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3134C578Fsjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG:

 

The chairs issued a WG last call for https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ on 11/29/= 17. We have received little feedback and would prefer to see more WG partic= ipants voice support before we pass the document to our AD.

 

Therefore, this email extends the WG last call for a= further 3 weeks (taking into consideration holidays) and will therefore ex= pire on 1/11/18.

 

Please respond with either support or objection to t= he WG delivering this document to our area director for publication as an I= nformational RFC.

 

Thanks!

 

Jim & Joel

 

 

--_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3134C578Fsjceml521mbxchi_-- From nobody Fri Dec 22 02:44: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 5AE33124239 for ; Fri, 22 Dec 2017 02:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 13NS3wj6Y4cZ for ; Fri, 22 Dec 2017 02:44:15 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3904C120227 for ; Fri, 22 Dec 2017 02:44:15 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7613E78D78D79; Fri, 22 Dec 2017 10:44:11 +0000 (GMT) Received: from LHREML501-MBB.china.huawei.com ([10.201.109.51]) by lhreml705-cah.china.huawei.com ([10.201.108.46]) with mapi id 14.03.0361.001; Fri, 22 Dec 2017 10:44:05 +0000 From: Ramin Khalili To: "Trossen, Dirk" , James N Guichard , 'Service Function Chaining IETF list' CC: Alia Atlas Thread-Topic: SFC WG re-chartering - initial text for WG review/comment Thread-Index: AdNyuLcja4roriHRQZ67o9nPI1G8tQHiLsEBADQE7RA= Date: Fri, 22 Dec 2017 10:44:05 +0000 Message-ID: <566C56D84391B845A5669C78BB642FC0013CCD39@lhreml501-mbb> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.98.183] Content-Type: multipart/alternative; boundary="_000_566C56D84391B845A5669C78BB642FC0013CCD39lhreml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 10:44:18 -0000 --_000_566C56D84391B845A5669C78BB642FC0013CCD39lhreml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dirk, James, These are excellent points. I support them. The chaining should be optimized to reduce the initial request latency. Fle= xible chaining is also necessary if the goal is to guarantee some QoS metri= c, e.g. end-to-end, latency, for the traffic. These two properties are ess= ential for latency sensitive traffics, such as URLLC (Ultra Reliable Low La= tency) defined by 3GPP standardization. Currently, there is no specific dis= cussion regarding these requirements within the WG and hence I found them i= mportant for the new charter. Regards, Ramin. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Trossen, Dirk Sent: Thursday, December 21, 2017 10:58 AM To: James N Guichard ; 'Service Function Chain= ing IETF list' Cc: Alia Atlas Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/commen= t James, all, Thanks for this excellent start for the planned re-chartering. I'd would li= ke to pick on this, particularly on the fourth topic (transport considerati= ons), and propose two specific topics for a new charter: Optimized chaining: this extends on the proposed fourth topic (which I supp= ort) by incorporating feedback, such as congestion indications, from transp= ort networks as well as the (possibly virtualized) service instances along = the SFP. Hence, this topic is about optimized control for the construction = and re-chaining of SFPs where the 'data points' for the decision making can= come from above or below the SFC delivery mechanism. Flexible chaining: this proposed topic extends the previous item in that it= builds on the desire to flexibly re-chain SFCs, particularly in situations= where virtualized service instances exist and dynamic decisions are being = taken for such re-chaining between such virtualized instances. Such flexibi= lity could be achieved by raising the abstraction level of the SFP from lay= er2/3 to that of a name-based service where the SF endpoint is being provid= ed as a name rather than a MAC or IP address. With that, the name-based SFP= remains the same even if changes in the currently used virtualized service= instances occur, bringing SFC closer to data centre networking and many of= the associated scenarios. What drives the need for such optimization and flexibility? Virtualization = of service instances, particularly through containers, certainly does and = particular when such virtualized service instances reside in a number of (p= ossibly regionally) distributed micro-data centres. In terms of delivery, item 1 would lead to an (informational?) RFC specifyi= ng the possible data points leading to the construction of optimized SFCs, = while item 2 would lead to an RFC for a design for flexible chaining for a = name-level SFP. Looking forward to receiving comments on this. Best, Dirk ________________________________ From: sfc > on behalf of = James N Guichard > Sent: 11 December 2017 8:13 PM To: 'Service Function Chaining IETF list' Cc: Alia Atlas Subject: [sfc] SFC WG re-chartering - initial text for WG review/comment Greetings WG: Joel and I have taken an initial stab at new charter text for the SFC WG. P= lease review and provide comments/suggestions by COB Friday 29th December (= 2 weeks). Network operators frequently utilize service functions such as packet filte= ring at firewalls, load-balancing and transactional proxies (for example sp= am filters) in the delivery of services to end users. Delivery of these typ= es of services is undergoing significant change with the introduction of vi= rtualization, network overlays, and orchestration. The SFC Working Group has developed an Architecture [RFC 7665] and a protoc= ol (the Network Service Header [draft-ietf-sfc-nsh-28], in the RFC Editor q= ueue as of this drafting.) The focus of the SFC working group moving forward will be on aspects of the= architecture and/or protocol that need to be addressed to enable effective= deployment and usage of this work. The SFC working group will now begin a= ddressing those items. In order to maintain focus, the working group will = primarily produce and advance documents on four topics: 1) Metadata - we need to define the common type-length-value encoded metada= ta types with standards track RFCs, and produce informational RFCs to descr= ibe common fixed-length (MD-1) metadata usages. 2) Security - The completed work does not provide mechanisms for authentica= ting or protecting (either for integrity or from inspection) metadata. The= re are a number of open questions as to what can be effectively provided an= d how to provide such tools. These need attention. 3) OAM and O&M - In order for operators to use these tools in production ne= tworks, they need Operations, Administration, and Maintenance tools, as wel= l as management mechanisms. This includes YANG models, OAM frameworks, and= specific OAM mechanisms to address operational needs. 4) Transport Considerations - this will capture the expectations SFC places= on transport behavior, including dealing with issues such as congestion in= dications and responses. Specifically, the SFC WG is chartered to deliver the following: 1. A standards track base set of MD-2 type codes within the metadata class = reserved for IETF usage. 2. Related Metadata drafts that require more explanation than is reasonable= to include in the base MD-2 draft, including MD-1 descriptions and items d= one once the base draft is complete. 3. YANG models for the SFC Components. 4. One or more security related standards track and / or informational RFCs= . At least one standards track security mechanism RFC is needed. 5. OAM Framework document to provide a common basis for OAM work. This dra= ft will include guidance on how active, passive, and in-situ OAM are to be = supported if at all. 6. Specific OAM mechanism documents to provide the tools needed for operati= onal environments. 7. Transport Considerations RFC to cover the expectations SFC and NSH place= on transport, and the operational constraints transports used by NSH need = to meet. Thanks! Jim & Joel --_000_566C56D84391B845A5669C78BB642FC0013CCD39lhreml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dirk, James,<= span lang=3D"EN-US" style=3D"font-family:"Calibri",sans-serif;col= or:black">

 

These are excellent = points. I support them.

 

The chaining should = be optimized to reduce the initial request latency. Flexible chaining is al= so necessary if the goal is to guarantee some QoS metric, e.g. end-to-end, latency, for the traffic.  These two propert= ies are essential for latency sensitive traffics, such as URLLC (Ultra Reli= able Low Latency) defined by 3GPP standardization. Currently, there is no s= pecific discussion regarding these requirements within the WG and hence I found them important for the new charter.=

 

Regards,

Ramin.

 

 

From: = sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Trossen, Dirk
Sent: Thursday, December 21, 2017 10:58 AM
To: James N Guichard <james.n.guichard@huawei.com>; 'Service F= unction Chaining IETF list' <sfc@ietf.org>
Cc: Alia Atlas <akatlas@gmail.com>
Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review= /comment

 

James, all,

 

Thanks for this excellent start for the p= lanned re-chartering. I'd would like to pick on this, particularly on the f= ourth topic (transport considerations), and propose two specific topics for a new charter:

 

Optimized chaining: this extends on the p= roposed fourth topic (which I support) by incorporating feedback, such as c= ongestion indications, from transport networks as well as the (possibly virtualized) service instances along the SFP. Hence,= this topic is about optimized control for the construction and re-chaining= of SFPs where the ‘data points’ for the decision making can co= me from above or below the SFC delivery mechanism.

Flexible chaining: this proposed topic extends the previous item in that it= builds on the desire to flexibly re-chain SFCs, particularly in situations= where virtualized service instances exist and dynamic decisions are being = taken for such re-chaining between such virtualized instances. Such flexibility could be achieved by rai= sing the abstraction level of the SFP from layer2/3 to that of a name-based= service where the SF endpoint is being provided as a name rather than a MA= C or IP address. With that, the name-based SFP remains the same even if changes in the currently used virtualized ser= vice instances occur, bringing SFC closer to data centre networking and man= y of the associated scenarios.

 

What drives the need for such optimizatio= n and flexibility? Virtualization of service instances, particularly throug= h containers,  certainly does and particular when such virtualized service instances reside in a number of (possibly regiona= lly) distributed micro-data centres.

 

In terms of delivery, item 1 would lead t= o an (informational?) RFC specifying the possible data points leading to th= e construction of optimized SFCs, while item 2 would lead to an RFC for a design for flexible chaining for a name-level SFP.

 

Looking forward to receiving comments on = this.

 

Best,

 

Dirk

 

 = ;

From: sfc <sfc= -bounces@ietf.org> on behalf of James N Guichard <james.n.guichard@huawei.com>
Sent: 11 December 2017 8:13 PM
To: 'Service Function Chaining IETF list'
Cc: Alia Atlas
Subject: [sfc] SFC WG re-chartering - initial text for WG review/com= ment

 

Greetings WG:

 

Joel and I have taken an initial stab at= new charter text for the SFC WG. Please review and provide comments/sugges= tions by COB Friday 29th December (2 weeks).

 

 

Network operators frequently utilize ser= vice functions such as packet filtering at firewalls, load-balancing and tr= ansactional proxies (for example spam filters) in the delivery of services to end users. Delivery of these types of services= is undergoing significant change with the introduction of virtualization, = network overlays, and orchestration.

 

The SFC Working Group has developed an A= rchitecture [RFC 7665] and a protocol (the Network Service Header [draft-ie= tf-sfc-nsh-28], in the RFC Editor queue as of this drafting.)

 

The focus of the SFC working group movin= g forward will be on aspects of the architecture and/or protocol that need = to be addressed to enable effective deployment and usage of this work.  The SFC working group will now begin addressing = those items.  In order to maintain focus, the working group will prima= rily produce and advance documents on four topics:

 

1) Metadata - we need to define the comm= on type-length-value encoded metadata types with standards track RFCs, and = produce informational RFCs to describe common fixed-length (MD-1) metadata usages.

 

2) Security - The completed work does no= t provide mechanisms for authenticating or protecting (either for integrity= or from inspection) metadata.  There are a number of open questions as to what can be effectively provided and how to provid= e such tools.  These need attention.

 

3) OAM and O&M - In order for operat= ors to use these tools in production networks, they need Operations, Admini= stration, and Maintenance tools, as well as management mechanisms.  This includes YANG models, OAM frameworks, and specific = OAM mechanisms to address operational needs.

 

4) Transport Considerations - this will = capture the expectations SFC places on transport behavior, including dealin= g with issues such as congestion indications and responses.

 

Specifically, the SFC WG is chartered to= deliver the following:

 

1. A standards track base set of MD-2 ty= pe codes within the metadata class reserved for IETF usage.

 

2. Related Metadata drafts that require = more explanation than is reasonable to include in the base MD-2 draft, incl= uding MD-1 descriptions and items done once the base draft is complete.

 

3. YANG models for the SFC Components.

 

4. One or more security related standard= s track and / or informational RFCs.  At least one standards track sec= urity mechanism RFC is needed.

 

5. OAM Framework document to provide a c= ommon basis for OAM work.  This draft will include guidance on how act= ive, passive, and in-situ OAM are to be supported if at all.

 

6. Specific OAM mechanism documents to p= rovide the tools needed for operational environments.

 

7. Transport Considerations RFC to cover= the expectations SFC and NSH place on transport, and the operational const= raints transports used by NSH need to meet.

 

 

Thanks!

 

Jim & Joel

 

 

 

 

--_000_566C56D84391B845A5669C78BB642FC0013CCD39lhreml501mbb_-- From nobody Fri Dec 22 02:50: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 01104124239 for ; Fri, 22 Dec 2017 02:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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_H2=-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=interdigital.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 F7U_yjCsmowZ for ; Fri, 22 Dec 2017 02:50:53 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0103.outbound.protection.outlook.com [104.47.32.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9AD120227 for ; Fri, 22 Dec 2017 02:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interdigital.onmicrosoft.com; s=selector1-interdigital-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vSTao8l4T++sKFoUgrUND6/F+VLXvQk5A02zTAY6TkM=; b=sEciNzjNF/HLoQ2m9vsgkkXSkuCej89gjFI/4Qot/JOh1nam6puoaayeD2YRbPglnOb0cIMtmLgLlFj9WUCmjpQBoNZsZHw5FhUVW+SouXRIUFNQnNIz1hWeDiX3l1KXQ0jsPIOmM9UMVCZG6YEFb7sKOMe9LixgUqCuF12Sm58= Received: from BN6PR1001MB2324.namprd10.prod.outlook.com (10.174.88.32) by BN6PR1001MB2323.namprd10.prod.outlook.com (10.174.88.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Fri, 22 Dec 2017 10:50:51 +0000 Received: from BN6PR1001MB2324.namprd10.prod.outlook.com ([10.174.88.32]) by BN6PR1001MB2324.namprd10.prod.outlook.com ([10.174.88.32]) with mapi id 15.20.0323.018; Fri, 22 Dec 2017 10:50:51 +0000 From: "Trossen, Dirk" To: Ramin Khalili , James N Guichard , 'Service Function Chaining IETF list' CC: Alia Atlas Thread-Topic: SFC WG re-chartering - initial text for WG review/comment Thread-Index: AdNyuLcja4roriHRQZ67o9nPI1G8tQHiLsEBADQE7RAAADdirw== Date: Fri, 22 Dec 2017 10:50:51 +0000 Message-ID: References: , <566C56D84391B845A5669C78BB642FC0013CCD39@lhreml501-mbb> In-Reply-To: <566C56D84391B845A5669C78BB642FC0013CCD39@lhreml501-mbb> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.0.151.202] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR1001MB2323; 6:cpZosnxmUikHk3AMTZ4TSafmFFFAWqY5bvDzARcN00Tln6NiiukSMFjt9Htr6ExjRQWjLqy1oibioBvUKUziXxKNYzwE2n4mIa1KYqYNnblZyZsheXMSELAjc3wQ4uVo9Ywh+CJXQdNgBR5MAWxbtT3UtxYOzSQKWkfINY6IC0GMMlcqT7lYEr6k3/6JG7NcCQp0xDBYqctOLvcykjY3jl9v/dvQYUcZtEbJwgBEytyo/K+8+QZ5Ii6bZ4ab8QpY2Qu1JyPJIGFGPM7kznq+pCuuYD2Wb7ms4r5LRLmlttLK4oV8BNqoy2WBk57/qM9KET2LP1VijmpM6RC6pnuIRcOHSEgVonYcJBD/6P2PAZQ=; 5:6kKQpvLed0UlM7/vMbyV4ZmZ/8WacLx/2RXwXsU8Z6TVJ8QlHO7Zu+Lr/QOPhZW/U3wx/OfPCKLho2cwfYFAqTSkMIBTyqI1nzDh6sRvkxEo48sv0GGigHr3MdC6ScOu1leFA/Dyy9QdBgjoQGx7rXLG4unfa4rO5YguXxiVG2Y=; 24:HEhHNXWwSF5p9XwjvOVDFluLW1UMBdDhRpm7rwofiT6BBNKsjSG6f77oT5DB4NGNnxnRr1EzNDHJ/h0KhYP4jY1N6oBmtgJF+HjJwxdUsM4=; 7:+nILW7nEIBoacZ2CDHmNjA+c2ptFNpY4aeoVGsB8FefXQo0QEks6aKYH6YVLGHqBFVZajeCUDsicd52gNwFKHrx7QsfG4V0HB27lKyiB0491zJ6EKRgrqQXglbAdfa1Nx9v1rJOFNjz2bIzK/B0lI7d0Ib9WJioLRVCy6g3NA5ZEUXI/2cPQNmCLHUMw4ZM2mItnaK9yQNlMWJr7ABVoV7lGP/IAtQXlMgbvaHQAGrxr8+QWneKwRhEj1c/NJyWc x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ed0da000-d53e-4ea2-54d8-08d54929de5a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(3008031)(2017052603307)(7153060); SRVR:BN6PR1001MB2323; x-ms-traffictypediagnostic: BN6PR1001MB2323: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dirk.Trossen@InterDigital.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231023)(944501041)(93006095)(93001095)(6041268)(20161123564045)(2016111802025)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6043046)(6072148)(201708071742011); SRVR:BN6PR1001MB2323; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR1001MB2323; x-forefront-prvs: 05299D545B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(346002)(366004)(396003)(376002)(39380400002)(199004)(189003)(25786009)(53546011)(106356001)(4326008)(76176011)(105586002)(478600001)(966005)(7696005)(59450400001)(6506007)(14454004)(7736002)(72206003)(6246003)(68736007)(5660300001)(53936002)(8936002)(102836004)(39060400002)(316002)(99286004)(110136005)(97736004)(9686003)(55016002)(6306002)(3660700001)(6436002)(2906002)(8676002)(3280700002)(74316002)(81156014)(6116002)(2900100001)(3846002)(33656002)(66066001)(77096006)(81166006)(2950100002)(305945005)(229853002)(86362001)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1001MB2323; H:BN6PR1001MB2324.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: InterDigital.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: interdigital.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed0da000-d53e-4ea2-54d8-08d54929de5a X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2017 10:50:51.4335 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e351b779-f6d5-4e50-8568-80e922d180ae X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1001MB2323 Archived-At: Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 10:50:56 -0000 Ramin, all, Flexible chaining is also essential if the goal is to guarantee some QoS me= tric, e.g. end-to-end, latency, for the traffic, particularly in edge envir= onments. A reference to ongoing efforts in this space can be found in the o= ngoing H2020 efforts FLAME (see https://www.ict-flame.eu/). These efforts a= re driven by city-scale many-POP deployments of compute infrastructure, all= SDN-connected and OpenStack managed. Localized media use cases drive the n= eed for name-based (HTTP as the main transport protocol here) service insta= nces being chained with the relationship between specific virtual instances= being controlled at the underlying routing/switching level. First trials a= t city scale are planned for mid 2018. Best, Dirk From: Ramin Khalili Sent: 22 December 2017 10:44 AM To: Trossen, Dirk; James N Guichard; 'Service Function Chaining IETF list' Cc: Alia Atlas Subject: RE: SFC WG re-chartering - initial text for WG review/comment =A0=20 Dirk, James, =A0 These are excellent points. I support them.=20 =A0 The chaining should be optimized to reduce the initial request latency. Fle= xible chaining is also necessary if the goal is to guarantee some QoS metr= ic, e.g. end-to-end, latency, for the traffic.=A0 These two properties are = essential for latency sensitive traffics, such as URLLC (Ultra Reliable Low= Latency) defined by 3GPP standardization. Currently, there is no specific = discussion regarding these requirements within the WG and hence I found th= em important for the new charter. =A0 Regards, Ramin.=20 =A0 =A0 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Trossen, Dirk Sent: Thursday, December 21, 2017 10:58 AM To: James N Guichard ; 'Service Function Chain= ing IETF list' Cc: Alia Atlas Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/commen= t =A0 James, all, =20 =A0 =20 Thanks for this excellent start for the planned re-chartering. I'd would li= ke to pick on this, particularly on the fourth topic (transport considerati= ons), and propose two specific topics for a new charter: =20 =A0 =20 Optimized chaining: this extends on the proposed fourth topic (which I supp= ort) by incorporating feedback, such as congestion indications, from transp= ort networks as well as the (possibly virtualized) service instances along= the SFP. Hence, this topic is about optimized control for the construction= and re-chaining of SFPs where the =91data points=92 for the decision makin= g can come from above or below the SFC delivery mechanism. Flexible chaining: this proposed topic extends the previous item in that it= builds on the desire to flexibly re-chain SFCs, particularly in situations= where virtualized service instances exist and dynamic decisions are being = taken for such re-chaining between such virtualized instances. Such flexib= ility could be=A0achieved by raising the abstraction level of the SFP from = layer2/3 to that of a name-based service where the SF endpoint is being pro= vided as a name rather than a MAC or IP address. With that, the name-based = SFP remains the same even if changes in the currently used virtualized ser= vice instances occur, bringing SFC closer to data centre networking and man= y of the associated scenarios. =20 =A0 =20 What drives the need for such optimization and flexibility? Virtualization = of service instances, particularly through containers,=A0 certainly does an= d particular when such virtualized service instances reside in a number of= (possibly regionally) distributed micro-data centres. =20 =A0 =20 In terms of delivery, item 1 would lead to an (informational?) RFC specifyi= ng the possible data points leading to the construction of optimized SFCs, = while item 2 would lead to an RFC for a design for flexible chaining for a= name-level SFP. =20 =A0 =20 Looking forward to receiving comments on this. =20 =A0 =20 Best, =20 =A0 =20 Dirk =A0 =A0 =20 From: sfc on behalf of James N Guichard Sent: 11 December 2017 8:13 PM To: 'Service Function Chaining IETF list' Cc: Alia Atlas Subject: [sfc] SFC WG re-chartering - initial text for WG review/comment=20 =A0 =20 Greetings WG: =A0 Joel and I have taken an initial stab at new charter text for the SFC WG. P= lease review and provide comments/suggestions by COB Friday 29th December = (2 weeks). =A0 =A0 Network operators frequently utilize service functions such as packet filte= ring at firewalls, load-balancing and transactional proxies (for example sp= am filters) in the delivery of services to end users. Delivery of these ty= pes of services is undergoing significant change with the introduction of v= irtualization, network overlays, and orchestration. =A0 The SFC Working Group has developed an Architecture [RFC 7665] and a protoc= ol (the Network Service Header [draft-ietf-sfc-nsh-28], in the RFC Editor q= ueue as of this drafting.) =A0 The focus of the SFC working group moving forward will be on aspects of the= architecture and/or protocol that need to be addressed to enable effective= deployment and usage of this work.=A0 The SFC working group will now begi= n addressing those items.=A0 In order to maintain focus, the working group = will primarily produce and advance documents on four topics: =A0 1) Metadata - we need to define the common type-length-value encoded metada= ta types with standards track RFCs, and produce informational RFCs to descr= ibe common fixed-length (MD-1) metadata usages. =A0 2) Security - The completed work does not provide mechanisms for authentica= ting or protecting (either for integrity or from inspection) metadata.=A0 T= here are a number of open questions as to what can be effectively provided= and how to provide such tools.=A0 These need attention. =A0 3) OAM and O&M - In order for operators to use these tools in production ne= tworks, they need Operations, Administration, and Maintenance tools, as wel= l as management mechanisms.=A0 This includes YANG models, OAM frameworks, = and specific OAM mechanisms to address operational needs. =A0 4) Transport Considerations - this will capture the expectations SFC places= on transport behavior, including dealing with issues such as congestion in= dications and responses. =A0 Specifically, the SFC WG is chartered to deliver the following: =A0 1. A standards track base set of MD-2 type codes within the metadata class = reserved for IETF usage. =A0 2. Related Metadata drafts that require more explanation than is reasonable= to include in the base MD-2 draft, including MD-1 descriptions and items d= one once the base draft is complete. =A0 3. YANG models for the SFC Components. =A0 4. One or more security related standards track and / or informational RFCs= .=A0 At least one standards track security mechanism RFC is needed. =A0 5. OAM Framework document to provide a common basis for OAM work.=A0 This d= raft will include guidance on how active, passive, and in-situ OAM are to b= e supported if at all. =A0 6. Specific OAM mechanism documents to provide the tools needed for operati= onal environments. =A0 7. Transport Considerations RFC to cover the expectations SFC and NSH place= on transport, and the operational constraints transports used by NSH need = to meet. =A0 =A0 Thanks! =A0 Jim & Joel =A0 =A0 =A0 =A0 = From nobody Sun Dec 24 23:32:45 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 4F5A0126E3A; Sun, 24 Dec 2017 23:32:43 -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 QSTQ9IyVP_Dx; Sun, 24 Dec 2017 23:32:42 -0800 (PST) Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD14A1205F0; Sun, 24 Dec 2017 23:32:41 -0800 (PST) Received: by mail-ot0-x244.google.com with SMTP id g59so4827621otg.11; Sun, 24 Dec 2017 23:32:41 -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=iSw5j6SLufoWl6tr+7Pu6vdqO+aGSTpEgGy5esRtKKA=; b=QdXUM7DMPcOald4uQMGJqymUUejUOw96ReDk3lvNBCZ2AB2KtIzXIGakIoKlhfEiPV Ibm6wU881QxUD+qOOohWdSPr6hnVdrkVdl6QTAk11rxU64v1QZacDQUV1/dwW6Pw4ZJ7 KxTqLQyRiQ3IHza2HH0UrEksFLkm0VKt96GesCjVx2c3rITwPPbcK91fUVSL12jaiYvx WIhjpXnj8gUva3bcPP9fUkVZ38UizqhhhO+1kNJHSbtGjBRcKBmpBTAD+l7nLrY588J8 DnLFyfc60/IxAmappic1+wzhGTnogEcL7uwy0VsSWx+hF4T1J9AiA4qzrxstNaDIjUl2 9jqA== 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=iSw5j6SLufoWl6tr+7Pu6vdqO+aGSTpEgGy5esRtKKA=; b=snvlKYW77Hztt9Kq8hpgkza1g3Rnigq3apuzG5UIvrs32G+44L96/lqAa8JNYZwDpp xEcXu9trO64PWqLpE+tT+JjQGtcZFTeR02UqBNrfaWfvEAmaWhzxjKa8BTKBSZ2MJY6c 6ydR5Pf6tCHeAC7Lnhn88d20o9JDAcHFa+716vsCxMbKDBUeUVbROdD3OPXeMFR6oTD7 o+iEAHAOlXY8fdhlljdR09vqOoNamW4Hz9hfhRpU0jS8yEnHJgirlcCBixnCxTmKo06X uMBe1clZbGAogv2mjOKgXGCNbHYDrN3e4VYdZVCjgI4vcmjqoTzo+7M6q3rhh5OBp4/H Z4ZQ== X-Gm-Message-State: AKGB3mLHwfw38UwPhVQT9jM2o6N2BwUNk5uzRogHRQbv6EtlqEq7bvpf V6SmtMG1BAND58j0QVWDRM++LMmRB8fF+CyDnU+OPg== X-Google-Smtp-Source: ACJfBoubT48kPnmnteVLRZTD63mC+OmvgatC1mVRgSJZ+JW9dTpdehZHhkprtP/WKZzkVhJXxhu+0Q1WX3zGIsMWgoA= X-Received: by 10.157.47.37 with SMTP id h34mr16009160otb.311.1514187161244; Sun, 24 Dec 2017 23:32:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.168.70.1 with HTTP; Sun, 24 Dec 2017 23:32:40 -0800 (PST) From: Tal Mizrahi Date: Mon, 25 Dec 2017 09:32:40 +0200 Message-ID: To: draft-farrel-sfc-convent@ietf.org, sfc@ietf.org, sfc-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0356a0de97d70561252ba2" Archived-At: Subject: [sfc] IPR Poll Regarding draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Dec 2017 07:32:43 -0000 --94eb2c0356a0de97d70561252ba2 Content-Type: text/plain; charset="UTF-8" Hi, This email begins a two-week poll for any IPRs that may apply to draft-farrel-sfc-convent. Are you aware of any IPR that applies to draft-farrel-sfc-convent? Specifically, if you are listed as a document author or contributor, please respond to this email (reply-to-all) stating whether or not you are aware of any relevant IPR. If you are aware of a relevant IPR, please state whether this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This poll closes on the 8th of January 2018. Best regards, Tal. --94eb2c0356a0de97d70561252ba2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This email begins a two-= week poll for any IPRs that may apply to draft-farrel-sfc-convent.

Are you aware of any IPR that applies to draft-farrel-sfc-= convent?=C2=A0

Specifically, if you are listed as = a document author or contributor, please respond to this email (reply-to-al= l) stating whether or not you are aware of any relevant IPR.

=
If you are aware of a relevant IPR, please state whether this IP= R been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 36= 69 and 5378 for more details).

This poll closes on= the 8th of January 2018.

Best regards,
= Tal.
--94eb2c0356a0de97d70561252ba2-- From nobody Tue Dec 26 12:41:25 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 0D7DC12422F; Tue, 26 Dec 2017 12:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1tCV6SI3lMY; Tue, 26 Dec 2017 12:41:20 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A89124F57; Tue, 26 Dec 2017 12:41:20 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBQKdKTK012253; Tue, 26 Dec 2017 12:41:19 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=B0XK7mFVMMAQuvZyZC5XBUgbCjsrnbE03lB9Wa/YM2I=; b=SFJ9re1Rg7iat0AfiqcDTv3KrTTPU+gX60Rgn/+QeADTMn3SM3VSl49l1qhEB+PH0DvE AzILbeNhokUpMjjeTqMiNuGl+/MDcMjCBiKNlJPfzXSe2oQKANUyvZAx3Bsh2ioBZJw7 5Vbk1NCpKca/bTpoDL6jRvFF+bGF2blotxRDWnDbElKsJ4ctl8qDKDXtAukdhGbm4KCs koEhByq6OKhahzwpAWJIw2cSrHJpJ5qTu/D7gZ7qlENxIKu0MRMzZcWkceU6TIHbz+F+ a1M6gwZl8aLKLInsUCmB/SXbBo4ksrmGmm9vVdU0j2LsCAYOf6VMmASga868bNO9YMyw CA== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0017.outbound.protection.outlook.com [207.46.163.17]) by mx0a-00273201.pphosted.com with ESMTP id 2f3tyt068s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 26 Dec 2017 12:41:18 -0800 Received: from MWHPR05MB3551.namprd05.prod.outlook.com (10.174.250.154) by MWHPR05MB3552.namprd05.prod.outlook.com (10.174.250.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.3; Tue, 26 Dec 2017 20:41:17 +0000 Received: from MWHPR05MB3551.namprd05.prod.outlook.com ([10.174.250.154]) by MWHPR05MB3551.namprd05.prod.outlook.com ([10.174.250.154]) with mapi id 15.20.0323.018; Tue, 26 Dec 2017 20:41:17 +0000 From: John E Drake To: Tal Mizrahi , "draft-farrel-sfc-convent@ietf.org" , "sfc@ietf.org" , "sfc-chairs@ietf.org" Thread-Topic: IPR Poll Regarding draft-farrel-sfc-convent Thread-Index: AQHTfVKP+X7mO80f/EqERY4o0hK5EKNV59ew Date: Tue, 26 Dec 2017 20:41:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR05MB3552; 6:LZBf9pNpFQUYZtR1ACnAdWd0fOXLopjSJtWriWZ1BotosqpsTWi6AAwFXOuoIhJWj38VgKCbTRZQh+3OdOITH9iL75lu9yThco9CZT83YosZtrEV8kEFD9qzEtqP2RnUYYa33nqa7A/5aGitCNXMe6X9HjR+zZKT6jZXkMh8gmmw5hK0Jk4g7dWGxp0Y5t2A86fMYBHCL8491FTUeNJx37EYYSD6Wvcmxbwth3kaqdOrgjOKdnzvLX/5Kg0fEN6fMTjHW+2LuYBUD5Ihanu2mb7xCT5MpXD7Zq7dT4WB5OQvbclnIl446j63h8EyvGrG2TkjxMQA3bEMQMb0BIG9m7y3trXZcRZ9oXwMds7WAa+YXLA/CgU5PY+j9KyyNRhx; 5:u0hnStuJFgFUYTQMFst3ZweaefKI9xyBSq6rzLbOVkC8h3OsqadRLMnEbb/3byeAkBFxvNaenfAMiiBL/HENTadpm5G2X7zSxoO+l99hGPLYBzRvg9aC+GttG0P8aOf/k12JlOh/YLKKLzQgRgjsXU2ojwiF6qg8xk3TcU8o2JQ=; 24:ZxH9zFIwMXSvqt8ZNKw6q19KQEBdc1GG6UAQXcCrBl2KUD3dSg99z6z0uzcEst12ABNPGHBc7CIOovl2XOPX87FQcwkrwuWdaCzlzImFPZM=; 7:kBHz063lVHHAPqDbUTHPiuxMtLfxroE8zRD8qc6+kW/Z0wkpJC1AzySRtMkK//vE5Y6FkwRNn56mAj3c1WoWnuYzYfrIRMg6/t+/pY6y42VtoYgzbkqnuGtu8AIXeHoW3itYf9nms00fPogWe4qwg7HjC4jTEU/OxLoOKV4s2oZ9pBrcpaCADj86NZO6rhtSZoFZ4SdmuhDzTlDTC9pqdhoC6+iirOfsPME71n1MLweU4SRNuqh4AeGo0/K2x/Ib x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 08936af6-72ca-424a-a39b-08d54ca1033d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(48565401081)(2017052603307)(7153060); SRVR:MWHPR05MB3552; x-ms-traffictypediagnostic: MWHPR05MB3552: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231023)(944501075)(6055026)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:MWHPR05MB3552; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR05MB3552; x-forefront-prvs: 053315510E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(346002)(396003)(376002)(39860400002)(199004)(189003)(229853002)(3846002)(316002)(102836004)(76176011)(7696005)(2900100001)(5660300001)(8936002)(478600001)(230783001)(68736007)(6246003)(6506007)(53546011)(77096006)(54896002)(3280700002)(9686003)(2501003)(39060400002)(74316002)(2201001)(8676002)(25786009)(105586002)(6306002)(3660700001)(106356001)(66066001)(2950100002)(14454004)(6436002)(97736004)(2906002)(33656002)(81166006)(110136005)(81156014)(790700001)(86362001)(7736002)(53936002)(55016002)(99286004)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3552; H:MWHPR05MB3551.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: h58dasTFDBNBmIZ9gpavJgeNbbLmAoh+t45BYKs8TPuLwQT247veE/5nacIGCcCssz4eiwKjxpcpYgWfuwKhxw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR05MB3551C8B194F6ABD231B64E74C7060MWHPR05MB3551namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 08936af6-72ca-424a-a39b-08d54ca1033d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Dec 2017 20:41:17.0141 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3552 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-26_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712260276 Archived-At: Subject: Re: [sfc] IPR Poll Regarding draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 20:41:23 -0000 --_000_MWHPR05MB3551C8B194F6ABD231B64E74C7060MWHPR05MB3551namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBmb3IgdGhpcyBkcmFmdA0KDQpZb3VycyBJcnJlc3Bl Y3RpdmVseSwNCg0KSm9obg0KDQpGcm9tOiBUYWwgTWl6cmFoaSBbbWFpbHRvOnRhbC5taXpyYWhp LnBoZEBnbWFpbC5jb21dDQpTZW50OiBNb25kYXksIERlY2VtYmVyIDI1LCAyMDE3IDI6MzMgQU0N ClRvOiBkcmFmdC1mYXJyZWwtc2ZjLWNvbnZlbnRAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzsgc2Zj LWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogSVBSIFBvbGwgUmVnYXJkaW5nIGRyYWZ0LWZhcnJl bC1zZmMtY29udmVudA0KDQpIaSwNCg0KVGhpcyBlbWFpbCBiZWdpbnMgYSB0d28td2VlayBwb2xs IGZvciBhbnkgSVBScyB0aGF0IG1heSBhcHBseSB0byBkcmFmdC1mYXJyZWwtc2ZjLWNvbnZlbnQu DQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtZmFycmVs LXNmYy1jb252ZW50Pw0KDQpTcGVjaWZpY2FsbHksIGlmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9j dW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWls IChyZXBseS10by1hbGwpIHN0YXRpbmcgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBh bnkgcmVsZXZhbnQgSVBSLg0KDQpJZiB5b3UgYXJlIGF3YXJlIG9mIGEgcmVsZXZhbnQgSVBSLCBw bGVhc2Ugc3RhdGUgd2hldGhlciB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNl IHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzgg Zm9yIG1vcmUgZGV0YWlscykuDQoNClRoaXMgcG9sbCBjbG9zZXMgb24gdGhlIDh0aCBvZiBKYW51 YXJ5IDIwMTguDQoNCkJlc3QgcmVnYXJkcywNClRhbC4NCg== --_000_MWHPR05MB3551C8B194F6ABD231B64E74C7060MWHPR05MB3551namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg dmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFtIG5vdCBhd2FyZSBv ZiBhbnkgSVBSIGZvciB0aGlzIGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5Zb3VycyBJcnJlc3BlY3RpdmVseSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkpvaG48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUYWwgTWl6cmFoaSBbbWFpbHRvOnRh bC5taXpyYWhpLnBoZEBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBEZWNl bWJlciAyNSwgMjAxNyAyOjMzIEFNPGJyPg0KPGI+VG86PC9iPiBkcmFmdC1mYXJyZWwtc2ZjLWNv bnZlbnRAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzsgc2ZjLWNoYWlyc0BpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBJUFIgUG9sbCBSZWdhcmRpbmcgZHJhZnQtZmFycmVsLXNmYy1jb252ZW50 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhpcyBlbWFpbCBiZWdpbnMgYSB0d28td2VlayBwb2xsIGZvciBhbnkgSVBScyB0aGF0 IG1heSBhcHBseSB0byBkcmFmdC1mYXJyZWwtc2ZjLWNvbnZlbnQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFyZSB5b3UgYXdhcmUgb2YgYW55 IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtZmFycmVsLXNmYy1jb252ZW50PyZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVjaWZp Y2FsbHksIGlmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1 dG9yLCBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIChyZXBseS10by1hbGwpIHN0YXRpbmcg d2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgYXJl IGF3YXJlIG9mIGEgcmVsZXZhbnQgSVBSLCBwbGVhc2Ugc3RhdGUgd2hldGhlciB0aGlzIElQUiBi ZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNz IDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgcG9sbCBjbG9z ZXMgb24gdGhlIDh0aCBvZiBKYW51YXJ5IDIwMTguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRhbC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR05MB3551C8B194F6ABD231B64E74C7060MWHPR05MB3551namp_-- From nobody Wed Dec 27 01:35:11 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 335CE126C23; Wed, 27 Dec 2017 01:35:09 -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 ORotOyFZBw2l; Wed, 27 Dec 2017 01:35:06 -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 760FA120726; Wed, 27 Dec 2017 01:35:05 -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 vBR9Z18W024604; Wed, 27 Dec 2017 09:35:03 GMT Received: from 950129200 (AGrenoble-651-1-584-63.w90-42.abo.wanadoo.fr [90.42.104.63]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id vBR9F8qk014266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Dec 2017 09:16:07 GMT Reply-To: From: "Adrian Farrel" To: "'Tal Mizrahi'" , , , References: In-Reply-To: Date: Wed, 27 Dec 2017 09:15:11 -0000 Message-ID: <038201d37ef3$5631e6e0$0295b4a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0383_01D37EF3.563457E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHt16SzvlBpr0fwBIrYHEupPNaxgaMhbXvw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.2.0.1013-23556.006 X-TM-AS-Result: No--19.111-10.0-31-10 X-imss-scan-details: No--19.111-10.0-31-10 X-TMASE-MatchedRID: nI1cAR4k0HbZfnct5UBzceYAh37ZsBDC+kuaU6pTXgK1eX0jEQ9c6lMg FaPCixwUX/FdXQdFwlCdOD5rR8gn6QlwXR3PN2FZvHKClHGjjr23Tv9y50YCe7t4BAaULwAVdZO FfPnyDNo22uoEm245fkFWCvm86w840sXpjQvtH9B3vIzA7XyIiCEF1RdqrHVdtdx2lXHjF1Ii/B 2gujrEHzB6EdCmNDGVVbEDP0uzojXyTBeqcpWTVlRe8joruKtpIFb2VdwQdkDROhK+RFWo5lthO gNFYwZakNCK/RB7QjECSHHGjA3FAhfyTevQtfkQkdcpJKX5Jwr8BlbXy+O/WnKuL8SC59l3YCow KSvpI+95QzetarMsxEgF6uuiHQ769Z8q6rO+Ih6Ycl4BgqVyk8MdI0UcXEHzj2iyfwmt0k9o4tO BMzo2ODw3BSolHKG+16FIKoCRjlU1gbUlmfmxOm/+RwWenb0Yf6/Md8Lb2l8no0smd1GLZADH+S ZFBrRqJIPFmqDDlsqSU848M/hs6Ei8wUMZL0vvi+m1DDPm2yL/fHyH+MCF5RUZTfM00s4+SLg3s SCXGKJUsBrwpfAq3hQAXi4Ga9GRHxPMjOKY7A+DGx/OQ1GV8qYdro8t3UQW+gtHj7OwNO2O3Uus 78ELwvBFmyOBP4jf7ojLUenqxrPCRr3wcqrc9w/wPc9buJpE Archived-At: Subject: Re: [sfc] IPR Poll Regarding draft-farrel-sfc-convent X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 09:35:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0383_01D37EF3.563457E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, =20 I am not aware of any IPR that applies to this draft. =20 Thanks, Adrian =20 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Tal Mizrahi Sent: 25 December 2017 07:33 To: draft-farrel-sfc-convent@ietf.org; sfc@ietf.org; sfc-chairs@ietf.org Subject: [sfc] IPR Poll Regarding draft-farrel-sfc-convent =20 Hi, =20 This email begins a two-week poll for any IPRs that may apply to = draft-farrel-sfc-convent. =20 Are you aware of any IPR that applies to draft-farrel-sfc-convent?=20 =20 Specifically, if you are listed as a document author or contributor, = please respond to this email (reply-to-all) stating whether or not you = are aware of any relevant IPR. =20 If you are aware of a relevant IPR, please state whether this IPR been = disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 = and 5378 for more details). =20 This poll closes on the 8th of January 2018. =20 Best regards, Tal. ------=_NextPart_000_0383_01D37EF3.563457E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am not aware of any IPR that = applies to this draft.

 

Thanks,

Adrian

 

From: sfc = [mailto:sfc-bounces@ietf.org] On Behalf Of Tal = Mizrahi
Sent: 25 December 2017 07:33
To: = draft-farrel-sfc-convent@ietf.org; sfc@ietf.org; = sfc-chairs@ietf.org
Subject: [sfc] IPR Poll Regarding = draft-farrel-sfc-convent

 

Hi,

 

This email begins a two-week poll for any IPRs that = may apply to draft-farrel-sfc-convent.

 

Are you aware of any IPR that applies to = draft-farrel-sfc-convent? 

 

Specifically, if you are listed as a document author = or contributor, please respond to this email (reply-to-all) stating = whether or not you are aware of any relevant = IPR.

 

If you are aware of a relevant IPR, please state = whether this IPR been disclosed in compliance with IETF IPR rules (see = RFCs 3979, 4879, 3669 and 5378 for more = details).

 

This poll closes on the 8th of January = 2018.

 

Best regards,

Tal.

------=_NextPart_000_0383_01D37EF3.563457E0-- From nobody Fri Dec 29 06:46:02 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 51252120046; Fri, 29 Dec 2017 06:45:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151455875629.6951.15114283020413839336@ietfa.amsl.com> Date: Fri, 29 Dec 2017 06:45:56 -0800 Archived-At: Subject: [sfc] I-D Action: draft-farrel-sfc-convent-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 14:45:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Operating the Network Service Header (NSH) with Next Protocol "None" Authors : Adrian Farrel John Drake Filename : draft-farrel-sfc-convent-05.txt Pages : 11 Date : 2017-12-29 Abstract: This document describes the use of the Network Service Header (NSH) in a Service Function Chaining (SFC) enabled network with no payload data and carrying only metadata. This is achieved by defining a new NSH "Next Protocol" type value of "None". This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-farrel-sfc-convent/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-farrel-sfc-convent-05 https://datatracker.ietf.org/doc/html/draft-farrel-sfc-convent-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-farrel-sfc-convent-05 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 Dec 29 06:53: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 8780D127869 for ; Fri, 29 Dec 2017 06:53:05 -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 uZt59ND6MrvD for ; Fri, 29 Dec 2017 06:53: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 40E241242F5 for ; Fri, 29 Dec 2017 06:53:03 -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 vBTEr1JB016279 for ; Fri, 29 Dec 2017 14:53:01 GMT Received: from 950129200 ([193.57.120.231]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id vBTEqxHg016273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Dec 2017 14:53:00 GMT Reply-To: From: "Adrian Farrel" To: Date: Fri, 29 Dec 2017 14:53:02 -0000 Message-ID: <007801d380b4$bb04a9f0$310dfdd0$@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: AdOAtLUzfHGQvUi0SdehuLgL0EPHnw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.2.0.1013-23562.000 X-TM-AS-Result: No--12.168-10.0-31-10 X-imss-scan-details: No--12.168-10.0-31-10 X-TMASE-MatchedRID: WJa0hpkNE2Mdj9vNGYhpkW/+RwWenb0Ye6fn5Q3HlHraqqH/oHw+kcFk Mp+HRF4cxrdD9xIog3LANNz/A2ARw3xdsN+0TsizNPNOsxwkkn7J5SXtoJPLyGsSgW01iDQLlwW f7/4SyDthx2jCmHkQPpAQDGK85Dp4YqmUd3tOErVVTfJWlqPdDILsLasl5ROhmP1Huhu1yDLci+ d/J4L+58YtOSRj0UCjNWPYAkCKHy450T0UypCRwX8c8oKMbgYYKVrLOZD1BXQ4YKAM3oRt9nkvY GlzSDgVTWLw2jvbfpzxP0/UCnihG8gwfRwI6g6dlVHM/F6YkvRReWnUUdhI9dnT/cqUnvn3YID9 Y+Lh/TyEmmFz+RIbZsm5OkecJebfouyZccV4bBpmVHNo7XGknbu1BKuwZsWRo0LZViYXld18LE+ Yxd1gvnOsW55nfY8dvoD4RkkKl2kItMWhbSshqkK9qlwiTElfOhJ9m53n4aClyfbzMrA/wqdq81 N80OZN7l/5JtDtWGALmwDBEqgqzsQ9PRRk5ZGsngIgpj8eDcC063Wh9WVqgqbyPFGTn+O41GcRA JRT6PP3FLeZXNZS4DjAdLIal4R6xEPFxvnDbxJF52Ffr9QA3F9wHM/MH7IYzrWiH9c3RG82jyph HMMTGg== Archived-At: Subject: [sfc] Update to draft-farrel-sfc-convent after shepherd review X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 14:53:05 -0000 Hi, Tal did a review as document shepherd. This resulted in the following changes.. Requirements Language OLD The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. NEW The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. END --- Section 1: OLD This document defines a mechanism for metadata to be carried on an SFP without the need for payload data. This may enable diagnosis and monitoring of SFPs, and coordination between SFC-aware SFIs, without the need for traffic to be flowing, and without the need to rewrite data packets to insert what might be substantial amounts of metadata. NEW This document defines a mechanism for metadata to be carried on an SFP without the need for payload data. This mechanism enables diagnosis and monitoring of SFPs, and coordination between SFC-aware SFIs. The mechanism can be applied without the need for traffic to be flowing, and if traffic is flowing it can be applied without the need to insert what might be substantial amounts of metadata into data packets (an operation that may be costly in some hardware). END --- Section 1 OLD This function is achieved by defining a new value for the NSH "Next Protocol" field to indicate "None". Like any NSH packets, such packets are contained within the SFC-enabled domain. NEW This document describes how this function is achieved through the use of a new value for the NSH "Next Protocol" field to indicate "None". Like any NSH packets, such packets are contained within the SFC- enabled domain. END Section 2.1: OLD When the next protocol is "None" the rest of the NSH still has meaning and, in particular, the metadata carried in the NSH may still be present. NEW When the next protocol is "None" the rest of the NSH still has meaning and, in particular, the metadata carried in the NSH may still be present. It is not intended that a packet with next protocol set to "None" is sent with no metadata (see Section 3). Thus, an SFC- aware node SHOULD NOT create a packet with next protocol set to "None", Metadata Type set to 0x2, and with NSH Length of 0x2. END --- Tal also asked about the lower case "may"s in Section 3. I reviewed and think they're all good. Cheers, Adrian > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 29 December 2017 14:46 > To: i-d-announce@ietf.org > Cc: sfc@ietf.org > Subject: I-D Action: draft-farrel-sfc-convent-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Service Function Chaining WG of the IETF. > > Title : Operating the Network Service Header (NSH) with Next Protocol > "None" > Authors : Adrian Farrel > John Drake > Filename : draft-farrel-sfc-convent-05.txt > Pages : 11 > Date : 2017-12-29 > > Abstract: > This document describes the use of the Network Service Header (NSH) > in a Service Function Chaining (SFC) enabled network with no payload > data and carrying only metadata. This is achieved by defining a new > NSH "Next Protocol" type value of "None". > > This document illustrates some of the functions that may be achieved > or enhanced by this mechanism, but it does not provide an exhaustive > list of use cases, nor is it intended to be definitive about the > functions it describes. It is expected that other documents will > describe specific use cases in more detail and will define the > protocol mechanics for each use case. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-farrel-sfc-convent/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-farrel-sfc-convent-05 > https://datatracker.ietf.org/doc/html/draft-farrel-sfc-convent-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-farrel-sfc-convent-05 > > > 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