IETF Logo Mail Archive

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

James N Guichard <james.n.guichard@huawei.com> Fri, 14 July 2017 18:24 UTC

Return-Path: <james.n.guichard@huawei.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 884F5131691 for <sfc@ietfa.amsl.com>; Fri, 14 Jul 2017 11:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 KJz_-vUu7xkN for <sfc@ietfa.amsl.com>; Fri, 14 Jul 2017 11:24:49 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8806127978 for <sfc@ietf.org>; Fri, 14 Jul 2017 11:24:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRD33744; Fri, 14 Jul 2017 18:24:46 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 14 Jul 2017 19:24:45 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML701-CHM.china.huawei.com ([169.254.3.186]) with mapi id 14.03.0301.000; Fri, 14 Jul 2017 11:24:42 -0700
From: James N Guichard <james.n.guichard@huawei.com>
To: "Kent Leung (kleung)" <kleung@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: clarification on Service Path ID for draft-penno-sfc-packet
Thread-Index: AdL8yGj6ijlxPpxFQhyonVi4uiBr2QABYlRQ
Date: Fri, 14 Jul 2017 18:24:42 +0000
Message-ID: <BF1BE6D99B52F84AB9B48B7CF6F17DA3EF0D62@SJCEML702-CHM.china.huawei.com>
References: <91d8a4564df24299a24bee2688c9f6a6@XCH-RTP-006.cisco.com>
In-Reply-To: <91d8a4564df24299a24bee2688c9f6a6@XCH-RTP-006.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.148.15]
Content-Type: multipart/alternative; boundary="_000_BF1BE6D99B52F84AB9B48B7CF6F17DA3EF0D62SJCEML702CHMchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.59690C6F.0006, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9121345f4c62bdf7827dcd79a828b2e7
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/ekn0fvnX5ua9AjtCAPWILTVlcRA>
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 18:24:50 -0000

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
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

v2.23.0 | Report a Bug | By Email