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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
