Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

"Kent Leung (kleung)" <kleung@cisco.com> Fri, 14 July 2017 20:15 UTC

Return-Path: <kleung@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 BD9B6131A54 for <sfc@ietfa.amsl.com>; Fri, 14 Jul 2017 13:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpidWI7d1Wii for <sfc@ietfa.amsl.com>; Fri, 14 Jul 2017 13:15:41 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D32131950 for <sfc@ietf.org>; Fri, 14 Jul 2017 13:15:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13999; q=dns/txt; s=iport; t=1500063340; x=1501272940; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ORkWcn7LdyU64RmSnTaxqKtvNXWsMytVpj0eCJrUrPc=; b=ARSzokJkA7lwisFJiEx691mWgjtw/eBx04mpJWJ0OzSybu22XW9yCWrx D51M//LNDvorxc01H6XzIeDGSn2hZ62KOOWfCNl1A+W9ofFYMt7MmuXzW m3syZ3lXlMYYT48HDLcregHwiBLr0JU96Ph1mv3rW3Q7RXf15f7S7/W7H s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DNAAAbJmlZ/4MNJK1eGgEBAQECAQEBAQgBAQEBgm9rZIEUB44EkWKQWIUsghGFdgKDcT8YAQIBAQEBAQEBayiFGAEBAQEDLVwCAQgOAwQBASgHMhQJCAEBBAESCBOJMGSwMYsgAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMog02FBYUghT4FilCMcIdxAosRiHiSN5VVAR84gQp1FYdfdgGHZoENAQEB
X-IronPort-AV: E=Sophos;i="5.40,359,1496102400"; d="scan'208,217";a="273170779"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2017 20:15:39 +0000
Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6EKFdol026178 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Jul 2017 20:15:39 GMT
Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 14 Jul 2017 16:15:38 -0400
Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Fri, 14 Jul 2017 16:15:38 -0400
From: "Kent Leung (kleung)" <kleung@cisco.com>
To: Dave Dolson <ddolson@sandvine.com>, James N Guichard <james.n.guichard@huawei.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: clarification on Service Path ID for draft-penno-sfc-packet
Thread-Index: AdL8yGj6ijlxPpxFQhyonVi4uiBr2QABYlRQAACi1WAAAxzH0A==
Date: Fri, 14 Jul 2017 20:15:38 +0000
Message-ID: <a1bf2985b3674f9588a914566cefc70f@XCH-RTP-006.cisco.com>
References: <91d8a4564df24299a24bee2688c9f6a6@XCH-RTP-006.cisco.com> <BF1BE6D99B52F84AB9B48B7CF6F17DA3EF0D62@SJCEML702-CHM.china.huawei.com> <E8355113905631478EFF04F5AA706E98A9060316@wtl-exchp-2.sandvine.com>
In-Reply-To: <E8355113905631478EFF04F5AA706E98A9060316@wtl-exchp-2.sandvine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.63.127]
Content-Type: multipart/alternative; boundary="_000_a1bf2985b3674f9588a914566cefc70fXCHRTP006ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/L7BkO0t_DEi6FExcOkRhRumMNyY>
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 14 Jul 2017 20:15:44 -0000

Thanks for clarifying that in the case of same service path ID for both flows of a connection, the service index range is partitioned as described in sect. 5.4.1. I'm not sure if this is purely "aesthetics" as there may be assumption that service path ID identifies the direction of the flow. The meaning of service index is the sequence of service functions in the path. There are two distinct flows and each flow follows a path. That's why I lean toward sect. 5.4.2 (unique service path ID per flow/direction). But I can be convinced to using one service path ID. :)

Kent

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Friday, July 14, 2017 8:51 PM
To: James N Guichard <james.n.guichard@huawei.com>; Kent Leung (kleung) <kleung@cisco.com>; sfc@ietf.org
Subject: RE: clarification on Service Path ID for draft-penno-sfc-packet

There is not actually forwarding ambiguity, since SFF forwarding depends on *both* SPI and SI.
So for example, there is no ambiguity in forwarding to use SI in the range [0,127] of up-link and range [128,255] for down-link, on the same SPI.
The limitation is ~127 SFs per path instead of ~255.

As I see it, Kent's question is one of aesthetics. Do folks like the same SPI used for two directions?

Personally, I find use of a single SPI to be more elegant,  consuming only one path ID instead of two. (section 5.4.1).
It may make debugging easier as well.

Also, for what it's worth, we demonstrated this method of section 5.4.1 at a previous IETF hackathon.

-Dave


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of James N Guichard
Sent: Friday, July 14, 2017 2:25 PM
To: Kent Leung (kleung); sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Hi Kent,

[personal opinion ...] I have always assumed that the service path ID would be uni-directional given that it would be difficult to avoid collision in all forwarding scenarios. If you look at a basic SFC a-b-c and the service index is set to 255 at the classifiers a & c (which imho will be the normal practice) then at b you would have a conflict if the same service path ID is used in both directions.

Jim

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Kent Leung (kleung)
Sent: Friday, July 14, 2017 1:58 PM
To: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Hi. We are working on a revision for this draft. There were 4 proposed solution options in section 5. During some discussions, most folks seem to favor the use of algorithmic method in section 5.4. However, there are 2 sub-options. One is based on same Service Path ID and using Service Index to determine flow direction (sect. 5.4.1). The other is based on setting high order bit on Serve Path ID, which determines flow direction (sect. 5.4.2). There are mixed opinions. One reason is that there may be the assumption the Service Path ID is uni-directional. No explicit wording of that nature has been encountered in the RFCs, maybe we missed something?

If Serve Path ID is required to be uni-directional, then the answer is easy (=> 5.4.2). We would like to solicit WG comments to get rough consensus and revised the next version with that solution. This problem is critical to address for Service Function that generate packet in reverse direction, especially security service functions as mentioned in draft-wang-sfc-ns-use-cases.

Thanks.

Kent