Subject: [spring] Why Transport Dependence is deemed as a problem?//re: [sfc] I-D Action: draft-ietf-sfc-problem-statement-04.txt

From: Xuxiaohu <[email-masked]>
Date: Fri, 18 Apr 2014 09:00:28 +0000

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-masked]] 代表 [email-masked]
> 发送时间: 2014年4月17日 3:18
> 收件人: [email-masked]
> 抄送: [email-masked]
> 主题: [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-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Ron Parker <[email-masked]>
Date: Fri, 18 Apr 2014 12:42:40 +0000

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-masked]] On Behalf Of Xuxiaohu
Sent: Friday, April 18, 2014 5:00 AM
To: [email-masked]
Cc: [email-masked]
Subject: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt

Hi all,

Best regards,
Xiaohu

>  This draft is a work item of the Service Function Chaining Working 
> Group of the IETF.
> 
> 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.
>

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 21 Apr 2014 08:26:43 +0000

Hi Ron,

Thanks for your comments. Please see my response inline.

> -----邮件原件-----
> 发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
> 发送时间: 2014年4月18日 20:43
> 收件人: Xuxiaohu; [email-masked]
> 抄送: [email-masked]
> 主题: 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

> Subject: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D
> Action: draft-ietf-sfc-problem-statement-04.txt
> 
> Hi all,
> 
> 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
> 
> 
> > -----邮件原件-----

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 21 Apr 2014 12:29:01 +0200

Hi Xu,

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.
>

​The draft says:​

"that packet, SN1 could further consume the metadata contained in the

NSH and meanwhile decrease the service index value within the NSH by

on
​e​
"​

I would observe after reading this draft that S
​x service node may not be capable of handling NSH of any sort (including
SR header - be it MPLS label stack or IPv6 EHs) therefor much more then
just decreasing the index value is required at SNx.

​It seems that to realize any service chain via most of today's service
nodes a full removal of NSH and re-application is required at directly
attached SNs.

That actually means that network needs to carry the state pretty much out
of band. Such state could be carried within routing protocols (today BGP is
used for that in L3VPN case) or by new overlay control plane - same as is
used to carry the metadata.

Cheers,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 22 Apr 2014 01:12:17 +0000

Hi Robert,

发件人: [email-masked] [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2014年4月21日 18:29
收件人: Xuxiaohu
抄送: Ron Parker; [email-masked]; [email-masked]
主题: Re: [sfc] Why Transport Dependence is deemed as a problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt

Hi Xu,

​The draft says:​

on

​e​

"​

I would observe after reading this draft that S
​x service node may not be capable of handling NSH of any sort (including SR header - be it MPLS label stack or IPv6 EHs) therefor much more then just decreasing the index value is required at SNx.

​It seems that to realize any service chain via most of today's service nodes a full removal of NSH and re-application is required at directly attached SNs.

[Xiaohu] Your observation is correct. The SF proxy must strip the NSH and the SR header before sending the packets to the directly attached legacy service functions. When the packets was returned by service functions, the SF proxy must reimpose those headers on the packets. Meanwhile, the SF proxy must decrease the service index value by 1.

That actually means that network needs to carry the state pretty much out of band. Such state could be carried within routing protocols (today BGP is used for that in L3VPN case) or by new overlay control plane - same as is used to carry the metadata.

[Xiaohu] Did you mean that the metadata should be transferred through the control plane?

Best regards,
Xiaohu

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Apr 2014 09:28:06 +0200

> [Xiaohu] Your observation is correct. The SF proxy must strip the NSH and the
SR header before sending the packets to the directly attached legacy
service functions. When the packets was returned by service functions,
the SF proxy must reimpose those headers on the packets. Meanwhile,
the SF proxy must decrease the service index value by 1.

Good so we agree on that point.

What actually worries me a bit that to "reimpose" you need to do full
classification again - just like you do it on all ingress nodes.

Moreover how you reimpose could be also a function of service product.

> [Xiaohu] Did you mean that the metadata should be transferred through the control plane?

How else would you carry it ? It's not data plane after all. Of course
perhaps your definition of control plane = routing protocols, but I
did not mean that.

Control plane is just a information overlay of some form. Just like IN
networks in well known telephone networks :)

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Apr 2014 10:19:47 +0200

Hi Haibin,

Actually my comments were in regards to non transparent SF (your section 3.2).

And honestly I am not consider those as legacy. IMO even modern
service nodes should not be forced to "handle" SF headers.

So much more focus should be made to make the solutions well
understood as those directly have great impact on the entire network
control plane side. Simply stating removing all the packet/flow state
from the network is not possible.

Cheers,
R.

On Wed, Apr 23, 2014 at 9:06 AM, Songhaibin (A) <[email-masked]> wrote:
> Hi,
>> From: sfc [mailto:[email-masked]] On Behalf Of Robert Raszuk
>> Sent: Tuesday, April 22, 2014 3:28 PM
>> To: Xuxiaohu
>> Cc: [email-masked]; Ron Parker; [email-masked]
>> Subject: Re: [sfc] 答复: Why Transport Dependence is deemed as a
>> problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt
>>
>> SR header before sending the packets to the directly attached legacy service
>> functions. When the packets was returned by service functions, the SF proxy
>> must reimpose those headers on the packets. Meanwhile, the SF proxy must
>> decrease the service index value by 1.
>> >
>>
> Actually we have a draft to talk about the legacy support. First, things have to be classified according to whether the legacy service function instance is transparent or not. Then if it is transparent, you can use different fields in the packet to map to service header and then retrieval it again. If not, things become much more complicated. Here is the link for the draft.
> https://datatracker.ietf.org/doc/draft-song-sfc-legacy-sf-mapping/
>
> BR,
> -Haibin
>
>>
>>
>> >
>> > That actually means that network needs to carry the state pretty much out of
>> band. Such state could be carried within routing protocols (today BGP is used
>> for that in L3VPN case) or by new overlay control plane - same as is used to
>> carry the metadata.
>> >
>> >
>> How else would you carry it ? It's not data plane after all. Of course perhaps
>> your definition of control plane = routing protocols, but I did not mean that.
>>
>> Control plane is just a information overlay of some form. Just like IN networks
>> in well known telephone networks :)
>>
>> Cheers,
>> R.
>>

---

From: "Songhaibin (A)" <[email-masked]>
Date: Wed, 23 Apr 2014 07:06:21 +0000

Hi,

 -----Original Message-----

BR,
-Haibin