Xiaohu, While the stack of IP addresses is simple, conceptually, it is quite expensive on the wire, especially with IPv6 addresses.
A stack of MPLS labels is also conceptually simple, but the use of MPLS is not universal, especially within data center environments. Also, this use of the MPLS labels is somewhat different, semantically, and could cause issues if used concurrently with traditional MPLS use cases. Especially given that existing MPLS labels are downstream allocated but SFC is essentially source routed. Perhaps that issue could be solved, but at the expense of a more complex and invasive control plane. Ron -----Original Message----- From: sfc [mailto:[email protected]] On Behalf Of Xuxiaohu Sent: Friday, April 18, 2014 5:00 AM To: [email protected] Cc: [email protected] Subject: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt Hi all, It said in section 2.6. Transport Dependence of the PS draft: "Service functions can and will be deployed in networks with a range of transports, including under and overlays. The coupling of service functions to topology requires service functions to support many transport encapsulations or for a transport gateway function to be present." Assume the function of service chain can be divided into two layers: one is the service path layer which is responsible for steering the packets along the service path, the other is the service function layer which is responsible for applying a given service to the packet. I agree that transport dependence is bad for the service function layer. However, I don't understand why transport dependence is also bad for the service path layer. In fact, there are only two underlay transports (i.e., IP and MPLS) which need to be considered for service chain. Therefore, we just need to leverage the source routing capability associated with IP or MPLS to realize the function of the service path layer. That's to say, we can use an ordered list of IP addresses or MPLS labels carried in the packet to represent the service path. A MPLS label in the ordered list of MPLS labels (i.e., a MPLS label stack) or an IP address in the ordered list of IP addresses can be used to indicate either a service node within the service path or a service function on a given service node. Note that MPLS labels and IP addresses have been successfully used for indicating services (e.g., VPN labels and multicast addresses in the range of 224.0.0.x or FF02::x ). Of course, if you still think there are too much work to do, you could actually only consider the MPLS-based approach (i.e., using a MPLS label stack to represent a service path) since it could also be applicable in both IPv4 and IPv6 networks with the help of any kind of MPLS over IP encapsulation technologies. Best regards, Xiaohu > -----邮件原件----- > 发件人: sfc [mailto:[email protected]] 代表 [email protected] > 发送时间: 2014年4月17日 3:18 > 收件人: [email protected] > 抄送: [email protected] > 主题: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Service Function Chaining Working > Group of the IETF. > > Title : Service Function Chaining Problem Statement > Authors : Paul Quinn > Thomas Nadeau > Filename : draft-ietf-sfc-problem-statement-04.txt > Pages : 18 > Date : 2014-04-16 > > Abstract: > This document provides an overview of the issues associated with the > deployment of service functions (such as firewalls, load balancers) > in large-scale environments. The term service function chaining is > used to describe the definition and instantiation of an ordered set > of instances of such service functions, and the subsequent "steering" > of traffic flows through those service functions. > > The set of enabled service function chains reflect operator service > offerings and is designed in conjunction with application delivery > and service and network policy. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-04 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sfc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list [email protected] https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
