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

"Kent Leung (kleung)" <kleung@cisco.com> Fri, 14 July 2017 17:58 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 1AC8F126E64 for <sfc@ietfa.amsl.com>; Fri, 14 Jul 2017 10:58:25 -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 VOmCtFwQs-4i for <sfc@ietfa.amsl.com>; Fri, 14 Jul 2017 10:58:24 -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 F1159131537 for <sfc@ietf.org>; Fri, 14 Jul 2017 10:58:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4522; q=dns/txt; s=iport; t=1500055102; x=1501264702; h=from:to:subject:date:message-id:mime-version; bh=AT/lUMUaeq1SL0hL80MGQeZCC/+zRQK1EM64cGJe4vc=; b=ZutHi6RVGWiMeMkYmou18ApTBavv/UHKMkK9gqS6GPnUvUipfQxbabJb E8VIonfuBv4jYHqVfc1W0X/jNZmlzeSUOu1eSUGSlbrKD6pTgc4NRRkAa 6GHmgfD8WNB+9dGJziC/ddz+np19/5iWSDtGFf7ZRLka4ISNXirFWxUyt 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DWAQDxBGlZ/5RdJa1dHAEBBAEBCgEBgm9rZIEbjgSiOoUsghGJaT8YAQIBAQEBAQEBax0LhUxeAQx0JgEEGxOJMGSwc4shAQEBAQYBAQEBASODKINNj2MFl0CHcQKLEYh4kjeVVQEfOIEKdRWHX4g5gQ0BAQE
X-IronPort-AV: E=Sophos;i="5.40,359,1496102400"; d="scan'208,217";a="273126514"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jul 2017 17:58:22 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v6EHwLga015221 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <sfc@ietf.org>; Fri, 14 Jul 2017 17:58:22 GMT
Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 14 Jul 2017 13:58:21 -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 13:58:21 -0400
From: "Kent Leung (kleung)" <kleung@cisco.com>
To: "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: clarification on Service Path ID for draft-penno-sfc-packet
Thread-Index: AdL8yGj6ijlxPpxFQhyonVi4uiBr2Q==
Date: Fri, 14 Jul 2017 17:58:21 +0000
Message-ID: <91d8a4564df24299a24bee2688c9f6a6@XCH-RTP-006.cisco.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_91d8a4564df24299a24bee2688c9f6a6XCHRTP006ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/SZEZTDMp5W9WQP4zC_L49san_BM>
Subject: [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 17:58:25 -0000

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