[Pce] NEXT STEP of draft-wu-pce-traffic-steering-sfc
Qin Wu <bill.wu@huawei.com> Wed, 23 December 2015 07:25 UTC
Return-Path: <bill.wu@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E67B1ACD53 for <pce@ietfa.amsl.com>; Tue, 22 Dec 2015 23:25:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 hLLUkh30wCuC for <pce@ietfa.amsl.com>; Tue, 22 Dec 2015 23:25:01 -0800 (PST)
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 98EA81ACD50 for <pce@ietf.org>; Tue, 22 Dec 2015 23:25:00 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBX84464; Wed, 23 Dec 2015 07:24:58 +0000 (GMT)
Received: from LHREML706-CAH.china.huawei.com (10.201.5.182) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Dec 2015 07:24:57 +0000
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Dec 2015 07:24:57 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.252]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 23 Dec 2015 15:24:52 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "pce@ietf.org" <pce@ietf.org>
Thread-Topic: NEXT STEP of draft-wu-pce-traffic-steering-sfc
Thread-Index: AdE9UwME48jCt9IUS+CddE8WAdC8vg==
Date: Wed, 23 Dec 2015 07:24:51 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA852A96DC@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.78.255]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA852A96DCnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.567A4C4A.0096, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.252, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 948f6153cc1a9e4f9ad6fd69a8b97d4e
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/CBkjBND21brSGprOaKLmJh9s7fw>
Subject: [Pce] NEXT STEP of draft-wu-pce-traffic-steering-sfc
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Dec 2015 07:25:04 -0000
Hi, folks: If you didn't follow the discussion on SFC mailing list, I like to draw your attention that SFC control plane architecture adopted as a WG draft in August 2015 triggered a lot of SFC control plane requirements discussions that are related to draft-wu-pce-traffic-steering-sfc-07. https://mailarchive.ietf.org/arch/msg/sfc/0H-H4BhyN0Nuroev_0hd5CMKOYM https://mailarchive.ietf.org/arch/msg/sfc/CVU-H4hP9kQD0CoLMHw9jYfZ0M4 https://mailarchive.ietf.org/arch/msg/sfc/3fy9X1VmGN6V6GIT_QMDXrXwVkY 1. The relationship between SFC,SFP and RSP was clarified, the control plane operating on SPF IDs rather than SFC ID got agreed. 2. Service Chaining work doesn't requires correlating service path IDs with service chain IDs within the data plane. The relationship of paths to chains falls in the control plane. 3.control-plane requirements defined in SFC control plane architecture allows to instruct a loose path (SFP) or a strict path (RSP),whether a full path is specified within a domain or if it is deferred to SFFs is really deployment-specific. 4.In addition, Encoding the Exact SFF-SF-sequence in Data Packets and Fully Controlled SFF-SF-Sequence for a SFP were also discussed on the list and two new sections 4.10.4 and 4.10.5 were added into version (-02) of draft-ietf-sfc-control-plane to discuss RSP related aspect. ( Referring to Section 2.3.1 of RFC7665, we can see RSP specify exact sequence of SFFs and SFs that the packets will actually visit and SFF/SF locators while SFP may be fully constrained or partial constrained and is constrained version of the original SFC. ) draft-wu-pce-traffic-steering-sfc-07 is a draft that provides a solution to SFC control plane requirements on RSP, SFC, SFP which was discussed on the SFC mailing list. We authors plan to make revision to draft-wu-pce-traffic-steering-sfc to capture all the discussing points in the SFC ML and get in line with the draft-ietf-sfc-control-plane adopted recently in SFC WG. Let us know if you have any comments/suggestion/inputs on this topic. Also wish you have a good holiday in Christmas.:-) Regards! -Qin