Re: [sfc] Taking the MPLS label stack representing an SFP as an overlay=Transport Derived SFF
Xuxiaohu <xuxiaohu@huawei.com> Wed, 09 July 2014 04:00 UTC
Return-Path: <xuxiaohu@huawei.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F881A0305; Tue, 8 Jul 2014 21:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 0kQ0xxZrhGIL; Tue, 8 Jul 2014 21:00:37 -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 0530A1A0302; Tue, 8 Jul 2014 21:00:36 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJT73437; Wed, 09 Jul 2014 04:00:35 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 05:00:34 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 12:00:29 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "<spring@ietf.org>" <spring@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: Taking the MPLS label stack representing an SFP as an overlay=Transport Derived SFF
Thread-Index: AQHPmlH7odT5H7A+MEepJZdtU3RfX5uWmeJw
Date: Wed, 09 Jul 2014 04:00:29 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08291A4F@NKGEML512-MBS.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F645D73306@dfweml701-chm.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8AE5FE@MBX021-W3-CA-2.exch021.domain.local> <B8F9A780D330094D99AF023C5877DABA8457FE09@nkgeml501-mbs.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B1A8AE888@MBX021-W3-CA-2.exch021.domain.local> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829115C@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829115C@NKGEML512-MBS.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.111.98.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Gk69URQoSDHShsKbuYPpbHS0aAY
Subject: Re: [sfc] Taking the MPLS label stack representing an SFP as an overlay=Transport Derived SFF
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 09 Jul 2014 04:00:40 -0000
Hi all, The following are some drafts related to the SPRING-based SFC approach which may be useful for you to get the whole picture of the SRPING-based SFC approach. Any comments and suggestions are welcome. Use Case draft: http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02 SF Auto-discovery through IGP: http://tools.ietf.org/html/draft-xu-isis-service-function-adv-02 http://tools.ietf.org/html/draft-xu-ospf-service-function-adv-02 SF Auto-discovery through DNS-SD: http://tools.ietf.org/html/draft-xu-dnssd-sf-discovery-01 SFP Computation through PCE: http://tools.ietf.org/html/draft-xu-spring-pce-based-sfc-arch-01 http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01 Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Tuesday, July 08, 2014 10:12 AM > To: Ron Parker > Cc: <spring@ietf.org>; sfc@ietf.org > Subject: [sfc] Taking the MPLS label stack representing an SFP as an > overlay=Transport Derived SFF > > (Note that I changed the subject since this is a totally different topic) > > Hi Ron, > > I agree there are some cases where the underlay network is not MPLS-capable. > In those cases, you could actually just take the MPLS label stack which > represents a given SFP > (http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) as an overlay, just > like the SFC encapsulation header > (http://tools.ietf.org/html/draft-merged-sfc-architecture-00). The MPLS packets > on the overlay could be transported over IP underlay networks with > MPLS-over-IP tunnels > (http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-00). > IMHO, this MPLS label stack based (or SPRING based) SFC approach is a concrete > example of Transport Derived SFF (see below) as defined in section 4.3.1 of the > SFC arch draft (http://tools.ietf.org/html/draft-merged-sfc-architecture-00): > > 4.3.1. Transport Derived SFF > > Service function forwarding, as described above, directly depends > upon the use of the service path information contained in the SFC > encapsulation. Existing implementations may not be able to act on > the SFC encapsulation. These platforms may opt to use a transport > mechanism which carries the service path information from the SFC > encapsulation, and information derived from the SFC encapsulation, to > build transport information. > > This results in the same architectural behavior and meaning for > service function forwarding and service function paths. It is the > responsibility of the control components to ensure that the transport > path executed in such a case is fully aligned with the path > identified by the information in the service chaining encapsulation. > > Best regards, > Xiaohu > > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > > Sent: Monday, July 07, 2014 9:47 PM > > To: Qin Wu; Linda Dunbar; 'sfc@ietf.org' > > Subject: Re: [sfc] New Version Notification for > > draft-dunbar-sfc-fun-instances-restoration-00.txt > > > > Qin, > > > > I agree that RSVP-TE style MPLS is a close architectural match to what > > SFC is trying to achieve, and that an MPLS label stack in this context > > is likely the most efficient way to encode explicit source routing, > > packet-by-packet, while preserving all the resiliency capabilities that are > required for real-world SFC. > > > > But one concern I have is the ubiquity, or lack thereof, of MPLS where SFC > > would be used. In mobile carrier environments, the SFC is seen as > applicable > > to the "Gi-LAN" set of value added services that are deployed between the > > subscriber management system (i.e., GGSN/PDN-GW) and the Internet. In > > some cases, this may be MPLS underpinning this part of the network, > > but in others it is simple Ethernet or SDN overlay over Ethernet. > > > > Please share your thoughts on this. > > > > Thanks. > > > > Ron > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc
- [sfc] FW: New Version Notification for draft-dunb… Linda Dunbar
- Re: [sfc] New Version Notification for draft-dunb… Ron Parker
- Re: [sfc] New Version Notification for draft-dunb… Qin Wu
- Re: [sfc] New Version Notification for draft-dunb… Ron Parker
- [sfc] Taking the MPLS label stack representing an… Xuxiaohu
- Re: [sfc] New Version Notification for draft-dunb… Qin Wu
- Re: [sfc] New Version Notification for draft-dunb… 이승익
- Re: [sfc] FW: New Version Notification for draft-… Ken Gray (kegray)
- Re: [sfc] Taking the MPLS label stack representin… Xuxiaohu
- Re: [sfc] New Version Notification for draft-dunb… Linda Dunbar
- Re: [sfc] FW: New Version Notification for draft-… Linda Dunbar
- Re: [sfc] FW: New Version Notification for draft-… Ron Parker