Hi Ron, Thanks for your comments. Please see my response inline.
> -----邮件原件----- > 发件人: sfc [mailto:sfc-boun...@ietf.org] 代表 Ron Parker > 发送时间: 2014年4月18日 20:43 > 收件人: Xuxiaohu; s...@ietf.org > 抄送: spring@ietf.org > 主题: Re: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D > Action: draft-ietf-sfc-problem-statement-04.txt > > Xiaohu, > > While the stack of IP addresses is simple, conceptually, it is quite > expensive on > the wire, especially with IPv6 addresses. Personally I agree. However, it seems that there are a lot of SPs who are in favor of carrying a stack of IPv6 addresses on the IPv6 packet. For more details, please see the IPv6-SR use case draft. > 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 Within data center environments as you mentioned, the MPLS label stack would just be used for representing a particular service path, and you could still use IP-based tunnels to forward packets from one service node to another (for more details, see http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-00). In other word, the MPLS label stack plays the similar role of the service path ID. > 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. A MPLS label stack can be used to realize the source routing paradigm, see http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-mpls-01 and http://tools.ietf.org/html/draft-gredler-spring-mpls-03. > Perhaps that issue could be solved, but at the expense of a more complex and > invasive control plane. How to simply use the MPLS label stack to realize the SFC has been described in http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-00. Any comments are welcome. Best regards, Xiaohu > Ron > > > -----Original Message----- > From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of Xuxiaohu > Sent: Friday, April 18, 2014 5:00 AM > To: s...@ietf.org > Cc: spring@ietf.org > 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:sfc-boun...@ietf.org] 代表 internet-dra...@ietf.org > > 发送时间: 2014年4月17日 3:18 > > 收件人: i-d-annou...@ietf.org > > 抄送: s...@ietf.org > > 主题: [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 > > s...@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > s...@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > s...@ietf.org > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
