Re: [sfc] Benjamin Kaduk's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)

"Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com> Sun, 24 May 2020 02:11 UTC

Return-Path: <naikumar@cisco.com>
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 CA6273A1019; Sat, 23 May 2020 19:11:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ZIF5PRGW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IwOaGZLP
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 XsWTbXAYJ2MY; Sat, 23 May 2020 19:11:51 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C0A3A0EDB; Sat, 23 May 2020 19:11:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38512; q=dns/txt; s=iport; t=1590286311; x=1591495911; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vWMZznVQ/B9RXSHeXvsh3ptjhRsGEHZqc+dLD43K2jo=; b=ZIF5PRGWi0hJN2mdf5/dN5L1X7XV1Tnpk1tqUte9/gFmuxgUrdTR9myE I5SsctSu2wZ2rDMjmYy4oJlIjdYwOEkncK5fAh12fAgrMHN7ArM0I3MlC 2MPcIpCGw/EwMS1S27KfoWxVmY8+/PncOFM5MQgehNNbVICr2auPJO2Wf o=;
IronPort-PHdr: 9a23:kqv5DBzJTptaUfnXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5ZRWHt/BskBnEUZiIo/5Hiu+DtafmVCRA5Juaq3kNfdRKUANNksQZmQEsQavnQU32JfLndWo2ScJFUlI2+nCnd0VZBZW2a1jbuHbn6zkUF132PhZ0IeKgHInUgoy32um+9oeVbR9PgW+2YKh5K1O9qgCCuw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B/AACk1sle/4ENJK1lDgsBAQEBAQEBAQEBAQEBAQEBAQESAQEBAQEBAQEBAQEBQIFHgVQjLgdvWC8sCoQag0YDjUKYPIFCgRADVQsBAQEMAQEjCgIEAQGERAIXggYkOBMCAwEBCwEBBQEBAQIBBQRthSoIJAyFcgEBAQECARIICREMAQE3AQ8CAQgYAgImAgICMBUQAgQOBRsHgwQBgksDDiABDqBNAoE5iGF2gTKDAQEBBYFGQYMiGIIOAwaBDioBgmOHFIJMGoIAgRABJxyBT34+gmcCAQIBgSwBCwEGASEHMQKCWjOCLY42AREGAgoGKoIfATyJI5ckfQqCVIgphg6KJR2CY4kCkBqCA442g3SIEpN0AgQCBAUCDgEBBYFpImZYEQdwFWUBgj5QGA2Ff4pBOIM6hRSFBD50AgE0AgYBBwEBAwl8ihYBASYHgQYBMF8BAQ
X-IronPort-AV: E=Sophos;i="5.73,427,1583193600"; d="scan'208";a="494499547"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2020 02:11:47 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 04O2Blq9006350 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 24 May 2020 02:11:47 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 23 May 2020 21:11:46 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 23 May 2020 22:11:45 -0400
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 23 May 2020 21:11:45 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mK51K4oFl/NUpSpaaDNwYam51zDKvWCkzGkjlbHQFDb4XNWhscDghqGYSJ+CnYIvum8W4gSZYAdr4wobeSzi1iBL8wgkNz11X/zNIgiGV1twJdt14MREnhuH6lPRddQ9kfvDO3jTXbqBg38PCZc+0YyIvm6FSuOd+bp81JlwPiv4bN/ctPrqUAly5BkT6OBKREv7+NI/APP6IPg/+1Kr5IsjgSyVICTeYL9vKgqxqf5j0Vwx5ksebSMkklOh6xx13pvJ4dI4rlDMJXvE09efFrY1ZSTit/+NFTxej9skxDCUv2r17Z/IPt2qg7A/RRqYbT0M+qBbqm7D6KtXpMLn3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vWMZznVQ/B9RXSHeXvsh3ptjhRsGEHZqc+dLD43K2jo=; b=CQlrnUEURubRHgfZ4Gcxreami9Xv373cwDY9GENqHftEuRJZunsA7tJdGwxoFjVd8ugMi2wSXVDRTRKH6EMuf/TenV46DbyBHiTpSZmFhFnR47/5wkBNFYAFH7G9Gg5mFSAqGxml2z0VKD55Cs01uiNZ/hIJb3jBPmErELal7uDbTXuEqnbznFTymK7UvInmTKrDOibkByOl9dKwYCNolj4hRaN9JCkTRZJOc6uGNe+6PA0wqBr0HWXxRnNr0SAA942XIQjdOmigSBITwSGUCX9jShYxJxmQrVO9bPfkMiQvLJDJ6dAlBCP83/yra4FBYZvyUEz/G/bkjilEj0h/9A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vWMZznVQ/B9RXSHeXvsh3ptjhRsGEHZqc+dLD43K2jo=; b=IwOaGZLPoiycZGdqoe1gfQewvJOp8SLWJrNkfHyT6LWOaXyzeJkFAUqhe8C2faZjdjdH/82mQ/cJOFl4UFGWqLagup9n/6nybhO2xoibizuPNHZzETnGc7GKvLCn7MTH0OziydkOEUjRoElRO3qwi+wAWrCh6V754WtCVzd/Fn8=
Received: from BN6PR11MB4068.namprd11.prod.outlook.com (2603:10b6:405:7c::31) by BN6PR11MB1970.namprd11.prod.outlook.com (2603:10b6:404:100::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.27; Sun, 24 May 2020 02:11:42 +0000
Received: from BN6PR11MB4068.namprd11.prod.outlook.com ([fe80::6d40:9e8a:252a:4f34]) by BN6PR11MB4068.namprd11.prod.outlook.com ([fe80::6d40:9e8a:252a:4f34%3]) with mapi id 15.20.3021.026; Sun, 24 May 2020 02:11:42 +0000
From: "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "draft-ietf-sfc-oam-framework@ietf.org" <draft-ietf-sfc-oam-framework@ietf.org>, "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, Tal Mizrahi <tal.mizrahi.phd@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)
Thread-Index: AQHWI/r7n4nGFylM8k67PRRkYrO8AqinX1yAgA13RQCAAJ3ZAIAAnDWAgABFoIA=
Date: Sun, 24 May 2020 02:11:42 +0000
Message-ID: <D69FEC02-D604-4F25-BE5F-FB824E1A64E7@cisco.com>
References: <158880638274.2656.5377824170907686634@ietfa.amsl.com> <D7409C1E-9509-42B4-B167-72CCACB542E7@cisco.com> <20200522231826.GO58497@kduck.mit.edu> <3B869171-4818-4542-8E83-CA0EDFCC54CA@cisco.com> <20200523180229.GY58497@kduck.mit.edu>
In-Reply-To: <20200523180229.GY58497@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.55.90]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d07495ab-88a3-4709-55ee-08d7ff87cd43
x-ms-traffictypediagnostic: BN6PR11MB1970:
x-microsoft-antispam-prvs: <BN6PR11MB19700493241E62A75E8A4271C6B20@BN6PR11MB1970.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0413C9F1ED
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7srn2vNkGu1Ja1sjsF1ax10Ykag7U0BSq4qFvw9pROeE8zR0AFE2PgidPH0KD4NPXtD27EzRGlqX4dY8rGUel/U1jp/777nWtyzgjMQllG+hq7vp3rWo8BFAzv+MyRXWoHvsqa5kmLhxRTKQdRsrkJjbvitJ0t4EPZsb5ERE6ATi8LgtyGrHb5nsRYqbEydDvUIa4ERFj+ETpWjanmqzAjoY74DIxAOfTVwMXhFa8K0hmek7o1TikRraHBURhYXco8bVD/JxaKNtYOWQHpZ1EH1wJHQSWpV+cPspP53WSi3IlhfJDWXB9MfqRj1dwU9mIZGNuKNfImyog9dVhwp5BFb7hg8GcR4yHIC6hP3nX9KQKhalScp9P0p+TRq7DvGDgXDznZoCZRDi3b4GdHpNZQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4068.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(39860400002)(396003)(136003)(366004)(66476007)(66946007)(91956017)(64756008)(66556008)(8936002)(76116006)(186003)(2616005)(36756003)(478600001)(8676002)(30864003)(316002)(966005)(5660300002)(54906003)(6512007)(53546011)(26005)(6506007)(4326008)(71200400001)(86362001)(33656002)(2906002)(66446008)(6486002)(6916009)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: PvTBioMKaOHzXMXIwbRE1P3aeGTSZPJsmds55ktFJNG0xuZFlUhWX1yW8oxX84NGbfHf4J48jsbf2Ph8RY1GO8bxdGgkHlKeGTcJZAiRooBY7Yph7QyROOFJbBXgvWQckC6rNwrGPnuWcBOOGDlV267KE+XKTCc44S842HpWTdFWOsN82usSWHV+LX1jcvKDpg0vM13GJklF2DHUXVnPu/QGxld3JbJSnaKam/zdKFVJU60EdVgXgGlQCpXO6CMLUpHvWk6JOiJ+d86/jTdDFRSiaLUZ8FzQbDNfplMY0vXpFRNVX8yxnUzsH35rAOO026hOB9I4XSCrIKAi9amKlrj8sH6X3x3+vl481qs0Fjk8l6h9RFerPU1zPqaVPluhzqUNJE5T1gAyfrBhExpT6WP+K76c3o5vVq4yx1LnAW0d+ggJG+kuMhBBdQRfwFhBfNRMVYNKNKcf+dcAcM00c5vUghy3rUIhWpM7zc7Jx6k=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <28A4064AE970AB4B8745579D13E8089F@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d07495ab-88a3-4709-55ee-08d7ff87cd43
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2020 02:11:42.3375 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OeK7rxVMOUe0HWa+RzVvuIo5XluqRXlaZMwyAlNq4YFlu3ewWZzVoqsEB9vgBrLNVPFIxpHCNdXXqE+ZhecLSA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1970
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/oy8kozxI070O9yOxfjgYe0dkkqk>
Subject: Re: [sfc] Benjamin Kaduk's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 May 2020 02:11:55 -0000

Hi Benjamin,

Thank you for the response. 

I had in mind a scenario where a classifier might receive traffic from a
    given source that is allowed to supply data-plane packets to a SFC but is
    not allowed (by policy or contract) to send OAM probes.  In that case (if
    such a case exists), the classifier would need to act as a firewall,
    dropping OAM-marked packets from that source entirely, instead of just
    rate-limiting them.

<Nagendra> Oh ok. I think this still could be achieved by configuring the classifier to rate-limit at a rate of 0 packets (. If this does not satisfy the criteria, we can consider the below: 

NEW:
The documents proposing the OAM solution for any service layer components should consider some form of message filtering to control OAM messages entering the administrative domain or to prevent leaking any internal service layer information outside the administrative domain.

Thanks,
Nagendra

On 5/23/20, 2:03 PM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:

    Hi Nagendra,

    Generally this all looks good; just a couple final notes inline.

    On Sat, May 23, 2020 at 12:43:24PM +0000, Nagendra Kumar Nainar (naikumar) wrote:
    > Hi Benjamin,
    > 
    > Thank you for the response. Please see inline for <Nagendra>2
    > 
    > On 5/22/20, 7:18 PM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
    > 
    >     Hi Nagendra,
    > 
    >     On Thu, May 14, 2020 at 01:40:13PM +0000, Nagendra Kumar Nainar (naikumar) wrote:
    >     > Hi Benjamin,
    >     > 
    >     > Thank you for the comments. Please see inline for more response.
    >     > 
    >     >     Benjamin Kaduk has entered the following ballot position for
    >     >     draft-ietf-sfc-oam-framework-13: No Objection
    >     >     
    >     >     When responding, please keep the subject line intact and reply to all
    >     >     email addresses included in the To and CC lines. (Feel free to cut this
    >     >     introductory paragraph, however.)
    >     >     
    >     >     
    >     >     Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    >     >     for more information about IESG DISCUSS and COMMENT positions.
    >     >     
    >     >     
    >     >     The document, along with other ballot positions, can be found here:
    >     >     https://datatracker.ietf.org/doc/draft-ietf-sfc-oam-framework/
    >     >     
    >     >     
    >     >     
    >     >     ----------------------------------------------------------------------
    >     >     COMMENT:
    >     >     ----------------------------------------------------------------------
    >     >     
    >     >     Section 2
    >     >     
    >     >     I'm not sure that I understand why a node in the underlay network (the
    >     >     "VM2" one) doesn't line up with a node in the link layer, in Figure 1.
    >     >    
    >     > <Nagendra>Am I assuming right that the question is about the misalignment between the nodes on Link layer and underlay layer?. If so, it was a typo and we fixed it. If I misunderstood the question, please let me know.
    > 
    >     Yes, that was the question, and thanks for the fix!
    > 
    >     >     Section 3
    >     >     
    >     >            classifiers, controllers, other service nodes).  Testing an SF
    >     >            may not be restricted to connectivity to the SF, but also whether
    >     >     
    >     >     nit(?) perhaps "may be more expansive than just checking connectivity to
    >     >     the SF", to avoid questions about what the "not" binds to.
    >     >   
    >     > <Nagendra> Yes. Your suggested text seems to make it easy to parse the statement. Please check the below text:
    >     > 
    >     > OLD:
    >     > Testing an SF
    >     >        may not be restricted to connectivity to the SF, but also whether
    >     >        the SF is providing its intended service.
    >     > 
    >     > NEW:
    >     > Testing an SF
    >     >        may be more expansive than just checking connectivity to the SF
    >     >        such as checking if the SF is providing its intended service.
    >     > 
    >     >        3.  Classifier component: OAM functions applicable at this component
    >     >            includes testing the validity of the classification rules and
    >     >            detecting any incoherence among the rules installed in different
    >     >            classifiers.
    >     >     
    >     >     It seems important to include both positive and negative tests of
    >     >     classification functionality (i.e., that traffic that should not match
    >     >     in fact does not match).  Section 3.3 might be a good place to mention
    >     >     this.
    >     >     
    >     > <Nagendra> The below text in Section 3.3 is intended to cover such misclassification:
    >     > 
    >     > " The SFC OAM must be able to validate the classification
    >     >    rules by assessing whether a flow is appropriately mapped to the
    >     >    relevant SFC."
    >     > 
    >     > If the above is not clear, we can update the same as:
    >     > 
    >     > NEW:
    >     > The SFC OAM must be able to validate the classification
    >     >    rules by assessing whether a flow is appropriately mapped to the
    >     >    relevant SFC and detect any misclassification.
    > 
    >     I'd suggest making the update.  The original is probably clear to most
    >     people, but maybe not to everyone.
    > 
    > <Nagendra2> Done.
    > 
    >     >     Section 3.1.1
    >     >     
    >     >        service function is available?.  On one end of the spectrum, one
    >     >        might argue that an SF is sufficiently available if the service node
    >     >        (physical or virtual) hosting the SF is available and is functional.
    >     >        On the other end of the spectrum, one might argue that the SF's
    >     >        availability can only be concluded if the packet, after passing
    >     >     
    >     >     I agree with the other reviewers that the first "end" of the spectrum
    >     >     seems surprising.
    >     >     
    >     >        firewall).  The cost of this approach is that the OAM mechanism for
    >     >        some SF will need to be continuously modified in order to "keep up"
    >     >        with new functionality being introduced: lack of extendibility.
    >     >    
    >     >     nit: the grammar doesn't seem right around "lack of extendibility"
    >     >     (also, is "extendibility" preferred or "extensibility"?).
    >     > 
    >     >  <Nagendra> We have this changed to extensibility.
    >     > 
    >     >        The SF availability can be performed using a generalized approach
    >     >        (i.e., an adequate granularity to provide a basic SF service).  More
    >     >     
    >     >     nit: I think it's an availability *check* that can be performed.
    >     >  
    >     > <Nagendra> Good catch (. Fixed it.
    >     > 
    >     >     Section 3.2.2
    >     >     
    >     >     Mandating the ability to measure every arbitrary segment of SFs within
    >     >     an SFC seems like it might be over-constraining.
    >     > 
    >     > <Nagendra>This is not a normative statement but intended to detect and isolate performance issue within the SFC.
    >     > 
    >     >     Section 4
    >     >     
    >     >        to perform OAM functionality at different layers.  In order to apply
    >     >        such OAM functions at the service layer, they need to be enhanced to
    >     >        operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in
    >     >        multiple SFCs.
    >     >     
    >     >     I don't understand what "operate a single SFF to multiple SFs/SFFs"
    >     >     means.
    >     >  
    >     > <Nagendra> We got similar comments from other reviewers highlighting the ambiguity. We changed it as below:
    >     > 
    >     > OLD:
    >     > In order to apply
    >     >    such OAM functions at the service layer, they need to be enhanced to
    >     >    operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in
    >     >    multiple SFCs.
    >     > 
    >     > NEW:
    >     > In order to apply such OAM functions at the service layer, they need to be enhanced 
    >     > to operate a single SF/SFF to multiple SFs/SFFs in an SFC and also in multiple SFCs.
    > 
    >     I think I'm failing to see the difference, unfortunately.
    > 
    > <Nagendra2> It was a copy paste error. Below is the updated text:
    > 
    > In order to apply such OAM functions at the service layer, they need to be enhanced to 
    > operate a single SF/SFF to multiple SFs/SFFs spanning across one or more SFCs.

    Ah, thanks, this looks better.

    >     >     Section 4.1
    >     >     
    >     >        o  Verify any packet re-ordering and corruption.
    >     >     
    >     >     nit: this wording doesn't really make sense.  Do we want to verify the
    >     >     absence of such things, or that it is within configured tolerances, or
    >     >     something else?  Just noting any occurrences and verifying that the
    >     >     noted occurrences are as noted doesn't seem useful...
    >     >    
    >     > <Nagendra> We changed this as "detect" instead of "verify".
    >     > 
    >     >        o  Verify the policy of an SFC or SF.
    >     >     
    >     >     nit: similarly, is this to verify the configuration, or to verify that
    >     >     operation matches the expected configuration?
    >     >     
    >     > <Nagendra> This section is about connectivity function and so it is intended to verify the operation based on the configuration.
    > 
    >     Perhaps "verify that an SFC or SF is applying the expected policy"?
    > 
    >     >     Section 4.2
    >     >     
    >     >        Continuity is a model where OAM messages are sent periodically to
    >     >        validate or verify the reachability to a given SF within an SFC or
    >     >     
    >     >     nit: while it's "connectivity to", I think it's "reachability of".
    >     >     
    >     > <Nagendra> Changed it.
    >     > 
    >     >        o  Notifying the detected failures to other OAM functions or
    >     >           applications to take appropriate action.
    >     >     
    >     >     nit: the subject of a notification is the entity receiving notification,
    >     >     not the content of the notification.  So "notifying other OAM functions
    >     >     or applications of the detected failures so they can take appropriate
    >     >     action", or "Sending notifications of the detected failures to other
    >     >     [...]".
    >     >     
    >     > <Nagendra> The former one looks more appropriate. 
    >     > 
    >     >     Section 4.4
    >     >     
    >     >        delay [RFC7679] is important.  In order to measure one-way delay,
    >     >        time synchronization MUST be supported by means such as NTP, PTP,
    >     >        GPS, etc.
    >     >     
    >     >     I think (informational) references are in order for these.  (PTP is not
    >     >     listed as "well-known" at
    >     >     https://www.rfc-editor.org/materials/abbrev.expansion.txt , though the
    >     >     other two are.)
    >     >     
    >     > <Nagendra> Based on my understanding on the above cited document, I expanded PTP and left the other two as it is. Let me know if the other two should be expanded.
    > 
    >     The other two don't need to be expanded.  In addition to expanding PTP, I
    >     was wondering whether to reference the RFCs for each protocol mentioned.
    >     Perhaps it is not worth the extra effort at this time.
    > 
    > <Nagendra2> I will leave it as it is now. 
    > 
    >     >        One-way delay variation [RFC3393] could also be calculated by sending
    >     >        OAM packets and measuring the jitter between the packets passing
    >     >        through an SFC.
    >     >     
    >     >     Looking at jitter between (measurement) packets to ascertain delay
    >     >     variation seems to require foreknowledge of the (e.g., periodic) pacing
    >     >     of the initial packet transmission.  If, on the other hand, the idea is
    >     >     to look at the jitter across the measured delay of each packet, then
    >     >     that works fine (but that's not what the current text says).
    >     >     
    >     > <Nagendra> Agreed. The measurement may need time synchronization and additional negotiation such as probe pace etc. But I think that this should be clarified in the solution documents.
    > 
    >     I agree that the details should be in other documents.  Would you be
    >     willing to have this text be "measuring packet jitter for traffic passing
    >     through an SFC"?
    > 
    > <Nagendra2> Looks better. Done.
    > 
    >     >        o  Ability to measure the packet loss [RFC7680] within an SF or an
    >     >           SFP bound to a given SFC.
    >     >     
    >     >     nit(?): packet loss "within an SF" (as opposed to between two SFs) is
    >     >     not something I would have expected to need measuring, on first thought.
    >     >     Though on further reflection it is less surprising; still, I wanted to
    >     >     check that this is indeed as intended.
    >     >     
    >     > <Nagendra> The ability to measure packet loss within an SFP helps detect such loss while the ability to measure packet loss within an SF helps isolate the issue. 
    >     > 
    >     >     Section 5.2
    >     >     
    >     >        As shown in Table 3, there are no standards-based tools available for
    >     >        the verification of SFs and SFCs.
    >     >     
    >     >     Some note about "at the time of this writing" or similar seems advised;
    >     >     otherwise this statement is unlikely to age well.
    >     >     
    >     > <Nagendra> That make sense. Please find the updated text below:
    >     > 
    >     > OLD:
    >     > As shown in Table 3, there are no standards-based tools available for
    >     >    the verification of SFs and SFCs.
    >     > 
    >     > NEW:
    >     > As shown in Table 3, there are no standards-based tools available at the 
    >     > time of this writing for the verification of SFs and SFCs.
    >     > 
    >     >     Section 6.2
    >     >     
    >     >        An SFF may choose not to forward the OAM packet to an SF if the SF
    >     >        does not support OAM or if the policy does not allow to forward OAM
    >     >        packet to an SF.  The SFF may choose to skip the SF, modify the
    >     >        header and forward to next SFC node in the chain.  It should be noted
    >     >        that skipping an SF might have implication on some OAM functions
    >     >        (e.g. the delay measurement may not be accurate).  The method by
    >     >     
    >     >     This behavior was initially surprising to me, and "might have
    >     >     implication on" feels like weaker text than is merited.  While I can
    >     >     perhaps imagine that not forwarding an OAM packet to an SF that will
    >     >     choke on it instead of doing something useful, it seems like it's rather
    >     >     divergent from the OAM expectations to silently bypass a given SF and is
    >     >     quite likely to affect the accuracy of the resulting OAM results.
    >     >     
    >     > <Nagendra> Forwarding the OAM packet to an SF that does not support (or the policy config does not allow) OAM may result in packet drops depending on the type of SF. For example, a FW may drop the OAM packet while other SF such as pkt-capture-sf may simply pass it through. It may be difficult to differentiate if the drop is due to the lack of feature support or some forwarding/processing issue. Such inaccuracy on the OAM function is highlighted in this section.
    >     > 
    >     >        process OAM packets is outside the scope of this document.  It could
    >     >        be a configuration parameter instructed by the controller or it can
    >     >        be done by dynamic negotiation between the SF and SFF.
    >     >     
    >     >     (Is there an existing mechanism for dynamic negotation between SF and
    >     >     SFF?)
    >     >     
    >     > <Nagendra>Not that I know of. If it vitiates the section or sentence, we can remove it.
    > 
    >     No need to remove it.  I'd consider adding "(the details of which are out
    >     of scope for this document)" since there's no other document to reference,
    >     but it's not necessary.
    > 
    > <Nagendra2> We have this emphasized in the section already.
    > 
    >     >     Section 6.3
    >     >     
    >     >        As described in Section 4, there are different OAM functions that may
    >     >        require different OAM solutions.  While the presence of the OAM
    >     >        marker in the overlay header (e.g., O bit in the NSH header)
    >     >        indicates it as OAM packet, it is not sufficient to indicate what OAM
    >     >        function the packet is intended for.  The Next Protocol field in NSH
    >     >        header may be used to indicate what OAM function is intended to or
    >     >        what toolset is used.
    >     >     
    >     >     Elsewhere in the document we make reference to what would be required of
    >     >     a non-NSH encapsulation header; is it appropriate to also do so here?
    >     >     
    >     > <Nagendra> Does the below modified text looks better?:
    >     > 
    >     > OLD:
    >     > The Next Protocol field in NSH
    >     >    header may be used to indicate what OAM function is intended to or
    >     >    what toolset is used.
    >     > 
    >     > NEW:
    >     > The Next Protocol field in NSH
    >     >    header may be used to indicate what OAM function is intended to or
    >     >    what toolset is used. Any other overlay encapsulations used at the service 
    >     > layer must have a similar way to indicate the intended OAM function.
    > 
    >     That does look better, thanks!
    > 
    >     >     Section 6.4.2
    >     >     
    >     >        BFD or S-BFD could be leveraged to perform continuity function for SF
    >     >        or SFC.  An initiator could generate a BFD control packet and set the
    >     >        "Your Discriminator" value as last SFF in the control packet.  Upon
    >     >     
    >     >     nit: I think this "your discriminator" would be the address or
    >     >     identifier of the last SFF, not just "the last SFF" itself, right?
    >     >     Or be set "to indicate" the last SFF, or similar.
    >     >     (Also occurs a few sentences later.)
    >     >     
    >     > <Nagendra> Yes, good catch (. Modified the same in the relevant sentences.
    >     > 
    >     >        with relevant DIAG code.  The TTL field in the NSH header could be
    >     >        used to perform partial SFC availability.  For example, the initiator
    >     >     
    >     >     nit: availability checks/checking
    >     >     
    >     > <Nagendra> Fixed.
    >     > 
    >     >     Section 6.4.4
    >     >     
    >     >        [I-D.penno-sfc-trace] defines a protocol that checks for path
    >     >        liveliness and traces the service hops in any SFP.  Section 3 of
    >     >        [I-D.penno-sfc-trace] defines the SFC trace packet format while
    >     >        Sections 4 and 5 of [I-D.penno-sfc-trace] defines the behavior of SF
    >     >        and SFF respectively.  While [I-D.penno-sfc-trace] has expired, the
    >     >        proposal is implemented in Open Daylight and available.
    >     >     
    >     >     Why is draft-penno-sfc-trace not progressing towards publication?
    >     >     
    >     > <Nagendra> I will let the authors of penno-sfc-trace to comment on the plans to move it towards publication.
    >     > 
    >     >     Section 7
    >     >     
    >     >     I think this table really needs more lead-in to what it's communicating.
    >     >     
    >     >        As depicted in Table 4, information and data models are needed for
    >     >        configuration, manageability and orchestration for SFC.  With
    >     >     
    >     >     I don't see where that is actually indicated by the table.
    >     >     
    >     > <Nagendra> The data models required for config/orchestration of any SFC elements (such as classifier/SF/SFF) is not available today. We can clarify this in the section. Please see if the below text clarifies:
    >     > 
    >     > OLD:
    >     > As depicted in Table 4, information and data models are needed for
    >     >    configuration, manageability and orchestration for SFC.
    >     > 
    >     > NEW:
    >     > While the NETCONF capabilities are readily available as depicted in Table 4, the information and data models are needed for
    >     >    configuration, manageability and orchestration for SFC.
    > 
    >     That looks better, yes.
    > 
    >     >     Section 8
    >     >     
    >     >     OAM information (though most usefully as summary statistics), if leaked,
    >     >     could also be used by an attacker to gauge the efficacy of an ongoing
    >     >     attack.
    >     >     
    >     > <Nagendra> Section 8 already defines the below:
    >     > 
    >     > "The documents proposing the OAM solution for any service layer components should consider some form of message filtering to prevent leaking any internal service layer information outside the administrative domain."
    >     > 
    >     > I believe this covers the point you raised. Please let us know if it doesn’t. 
    > 
    >     The text you refer to describes an appropriate mitigation to take, but does
    >     not discuss the potential consequences when the mitigation is not taken.  I
    >     was hoping to see a mention of how the data could be misused if the
    >     operator failed to apply the recommended protective measures (as a way to
    >     incentive proper use of protective measures).
    > 
    > <Nagendra2> Some info around the potential misuse of such data is in the  same section (as below):
    > 
    > The mapping and the rules information at the classifier component may reveal the traffic rules and the traffic mapped to the SFC. The SFC information collected at an SFC component may reveal the SFs associated within each chain and this information together with classifier rules may be used to manipulate the header of synthetic attack packets that may be used to bypass the SFC and trigger any internal attacks.
    > 
    > The SF information at the SF component may be used by a malicious user to trigger Denial of Service (DoS) attack by overloading any specific SF using rogue OAM traffic.
    > 
    >     >        Any security consideration defined in [RFC7665] and [RFC8300] are
    >     >        applicable for this document.
    >     >     
    >     >     The rest of the document implies that NSH is not mandatory, so I'd
    >     >     suggest rewording this reference to clarify what from RFC 8300 is (or is
    >     >     not) applicable to the whole of the document.
    >     >     
    >     > <Nagendra> While not mandatory, NSH is one of the overlay headers that could be used for encapsulating the OAM packets. So, any security considerations defined in RFC8300 is applicable when the OAM solutions are using NSH as overlay header. 
    >     > 
    >     >        The mapping and the rules information at the classifier component may
    >     >        reveal the traffic rules and the traffic mapped to the SFC.  The SFC
    >     >        information collected at an SFC component may reveal the SF
    >     >        associated within each chain and this information together with
    >     >     
    >     >     nit: s/the SF/the SFs/
    >     >     
    >     > <Nagendra> Fixed.
    >     > 
    >     >        To address the above concerns, SFC and SF OAM may provide mechanism
    >     >        for:
    >     >     
    >     >     (1) The crucial missing word that Roman notes is indeed crucial!
    >     >     (2) Can we say something stronger than "may"?
    >     >     
    >     > <Nagendra> This is changed to "should" based on the SecDir comments.
    >     > 
    >     >        The documents proposing the OAM solution for any service layer
    >     >        components should consider some form of message filtering to prevent
    >     >        leaking any internal service layer information outside the
    >     >        administrative domain.
    >     >     
    >     >     "should consider" is fairly weak guidance; would "should provide" be
    >     >     appropriate?
    >     >     
    >     > <Nagendra> Changed the same as "should provide".
    >     > 
    >     >     Also, is it worth mentioning that this filtering would include dropping
    >     >     OAM-marked messages from outside the domain (at least by default)?
    >     >     
    >     > <Nagendra> I checked the section and didn’t see any specifics about incoming OAM packets. Does the below text clarify?
    >     > 
    >     > OLD:
    >     > Rate-limiting may be applied at the SFF or the SF
    >     > 
    >     > NEW:
    >     > Rate-limiting may be applied at the Classifier, SFF or the SF
    > 
    >     My remark was about the "filtering to prevent leaking any internal service
    >     information outside the administrative domain", so rate-limiting at the
    >     classifier would not really be the appropriate mechanism.  Rather, the
    >     classifier should reject/discard incoming traffic with unexpected OAM
    >     markings.
    > 
    > <Nagendra2> AFAIK, the OAM marking in the header classifies a packet as OAM probe/packet and must be rate-limited based on the above. I am not sure I understand what is unexpected OAM marking.

    I had in mind a scenario where a classifier might receive traffic from a
    given source that is allowed to supply data-plane packets to a SFC but is
    not allowed (by policy or contract) to send OAM probes.  In that case (if
    such a case exists), the classifier would need to act as a firewall,
    dropping OAM-marked packets from that source entirely, instead of just
    rate-limiting them.

    Thanks for all the updates,

    Ben

    >     >     Section 12.1
    >     >     
    >     >     The only citation to RFC 8300 that appears to require a normative
    >     >     reference is the bit in the security considerations that I noted was
    >     >     unclear about its scope of applicability.
    >     >     
    >     > <Nagendra> We updated the document to avoid using normative statements. Let me check with my co-authors to see if we should move all the references as Informative.
    > 
    >     I think you should not blanket move all references to Informative; there
    >     can still be need for normative references even without BCP 14 keywords.
    > 
    >     >     Section 12.2
    >     >     
    >     >     RFC 6291 is a BCP, so we should probably cite it as such.  Also, given
    >     >     its content, perhaps it ought to be normative?
    >     >     
    >     > <Nagendra> Same as above.
    >     > 
    >     > Once again, thanks a lot for the great comments. 
    > 
    >     And thank you for the updates!
    > 
    >     -Ben
    >