Subject: [sfc] SFC as an IP or UDP application, pros and cons?

From: Lucy yong <[email-masked]>
Date: Tue, 25 Mar 2014 20:01:45 +0000

Hi,

There are many ways to implement SFCs. However, one of our goals in standard is to develop a solution that is simple and less cost for venders and service providers.  Other goals are that the solution can apply to common and majority use cases.

If we implement SFC as an IP or UDP/IP application, i.e. once traffic is classified by the classification, it adds SFC header and IP header (outer) on the packets (UDP header too in latter case), and send such packets as a regular IP packet. The src IP of outer header can be classification IP address, and dst IP can be next SF Instance IP address. Many transport networks can carry IP traffic and route IP packets based on dst IP address.  We only need to request a new IP protocol type for SFC. At the service forwarder point, it can look up next SF IP address based on Path ID in SFC header and src IP address (previous SF) on the packet.  A SF also forwards the packet with SFC header as an IP packet and fills its IP address as src IP and the service forwarder point IP address as the dst IP on the packet.

This solution works for either SFC as an IP application or UDP/IP application, which one is more proper from SF and service forwarder point?

This solution seems simple to me and only need Path ID in SFC header for steering traffic through the SFC path. But like to see others' opinion on this solution, pros and cons.

Thanks,
Lucy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 25 Mar 2014 16:17:28 -0400

This proposal specifies the transport mechanism for the service 
chaining.  I had thought that we were not going to mandate a specific 
transport, as there are reasons for making different choices, and 
boundary interworking is quite tractable.

Yours,
Joel

On 3/25/14, 4:01 PM, Lucy yong wrote:
> Hi,
>
> There are many ways to implement SFCs. However, one of our goals in
> standard is to develop a solution that is simple and less cost for
> venders and service providers.  Other goals are that the solution can
> apply to common and majority use cases.
>
> If we implement SFC as an IP or UDP/IP application, i.e. once traffic is
> classified by the classification, it adds SFC header and IP header
> (outer) on the packets (UDP header too in latter case), and send such
> packets as a regular IP packet. The src IP of outer header can be
> classification IP address, and dst IP can be next SF Instance IP
> address. Many transport networks can carry IP traffic and route IP
> packets based on dst IP address.  We only need to request a new IP
> protocol type for SFC. At the service forwarder point, it can look up
> next SF IP address based on Path ID in SFC header and src IP address
> (previous SF) on the packet.  A SF also forwards the packet with SFC
> header as an IP packet and fills its IP address as src IP and the
> service forwarder point IP address as the dst IP on the packet.
>
> This solution works for either SFC as an IP application or UDP/IP
> application, which one is more proper from SF and service forwarder point?
>
> This solution seems simple to me and only need Path ID in SFC header for
> steering traffic through the SFC path. But like to see others’ opinion
> on this solution, pros and cons.
>
> Thanks,
>
> Lucy
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Dave Dolson <[email-masked]>
Date: Tue, 25 Mar 2014 20:20:42 +0000

I do not see why source IP address (previous SF) would be required to look up the next SF. The path ID should be sufficient to determine the next SF.

From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, March 25, 2014 4:02 PM
To: [email-masked]
Subject: [sfc] SFC as an IP or UDP application, pros and cons?

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Tue, 25 Mar 2014 20:51:29 +0000

Hi Joel,

I believe that transporting between service forwarder points is what you mean. Although service forwarder point sends/receives the packet with SFC header as IP packet, IP packets can be transported by any transport solution such as Ethernet, PW/MPLS, Overlay Technologies, isn't? IP is network technology, and not a transport technology. 

If service forwarder point is a service router, the solution will not change the router behavior, i.e. forward on IP destination address on the packet. Only addition to a service router is if that destination address is the router itself, the router terminates the packet and checks the protocol, if it is SFC, it retrieve the SFC header and performs the table lookup based on Path ID and src IP address. 

Thanks,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, March 25, 2014 3:17 PM
To: Lucy yong; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

This proposal specifies the transport mechanism for the service chaining.  I had thought that we were not going to mandate a specific transport, as there are reasons for making different choices, and boundary interworking is quite tractable.

Yours,
Joel

On 3/25/14, 4:01 PM, Lucy yong wrote:
> If we implement SFC as an IP or UDP/IP application, i.e. once traffic 
> is classified by the classification, it adds SFC header and IP header
> This solution seems simple to me and only need Path ID in SFC header 
> for steering traffic through the SFC path. But like to see others' 
> opinion on this solution, pros and cons.
>
> Thanks,
>
> Lucy
>
>
>

---

From: Lucy yong <[email-masked]>
Date: Tue, 25 Mar 2014 20:56:06 +0000

In this solution, service forwarder and SF instance are separated entities. Service forwarder needs Path ID and previous SF IP address to uniquely identify the next SF IP address.

Lucy

From: Dave Dolson [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 3:21 PM
To: Lucy yong; [email-masked]
Subject: RE: SFC as an IP or UDP application, pros and cons?

From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, March 25, 2014 4:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] SFC as an IP or UDP application, pros and cons?

Hi,

Thanks,
Lucy

---

From: Ron Parker <[email-masked]>
Date: Tue, 25 Mar 2014 21:04:30 +0000

Hi, Lucy.

I originally had some confusion around the terminology so I thought I'd share.   When I first heard "transport" I though layer 4 UDP/TCP/etc.    But what I believe is meant by "transport" in this context is, instead, a full encapsulation that will get the desired packet or frame to the intended place.   So in the SFC terminology, some possible examples for "transport" that is applied in front of the SFC-specific header could theoretically be: 

MAC (ethertype = SFC)
MAC (ethertype = IP) / IP (protocol = SFC)
MAC (ethertype = IP) / IP (protocol = GRE) / GRE (ethertype = SFC)
MAC (ethertype = IP) / IP (protocol = UDP) / UDP (dport = SFC)
Frame-Relay 
...

     Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, March 25, 2014 4:51 PM
To: Joel M. Halpern; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Joel,

Thanks,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, March 25, 2014 3:17 PM
To: Lucy yong; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Tue, 25 Mar 2014 21:09:32 +0000

Why do you think the previous SF IP address is required to determine the next SF IP address? Why is the Path ID not sufficient information?

From: Lucy yong [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 4:56 PM
To: Dave Dolson; [email-masked]
Subject: RE: SFC as an IP or UDP application, pros and cons?

Lucy

From: Dave Dolson [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 3:21 PM
To: Lucy yong; [email-masked]<mailto:[email-masked]>
Subject: RE: SFC as an IP or UDP application, pros and cons?

Hi,

Thanks,
Lucy

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 25 Mar 2014 14:12:29 -0700

This is an interesting discussion.  Given that many encap proposals in the
NVO3 WG use UDP because they want to play nice with available hashing
mechanisms in existing hardware, it looks like SFC is about break things
all over again. :)

Anoop

On Tue, Mar 25, 2014 at 2:04 PM, Ron Parker <[email-masked]
> wrote:

> Hi, Lucy.
>
> I originally had some confusion around the terminology so I thought I'd
> share.   When I first heard "transport" I though layer 4 UDP/TCP/etc.
>  But what I believe is meant by "transport" in this context is, instead, a
> full encapsulation that will get the desired packet or frame to the
> intended place.   So in the SFC terminology, some possible examples for
> "transport" that is applied in front of the SFC-specific header could
> theoretically be:
>
> MAC (ethertype = SFC)
> I believe that transporting between service forwarder points is what you
> mean. Although service forwarder point sends/receives the packet with SFC
> header as IP packet, IP packets can be transported by any transport
> solution such as Ethernet, PW/MPLS, Overlay Technologies, isn't? IP is
> network technology, and not a transport technology.
>
> If service forwarder point is a service router, the solution will not
> change the router behavior, i.e. forward on IP destination address on the
> packet. Only addition to a service router is if that destination address is
> the router itself, the router terminates the packet and checks the
> protocol, if it is SFC, it retrieve the SFC header and performs the table
> lookup based on Path ID and src IP address.
>
> Thanks,
> Lucy
>
> This proposal specifies the transport mechanism for the service chaining.
>  I had thought that we were not going to mandate a specific transport, as
> there are reasons for making different choices, and boundary interworking
> is quite tractable.
>
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 25 Mar 2014 17:13:52 -0400

Yes, that is what I meant by transport.  And yes, there are many options 
(for example an MPLS label).

Further, and to the reason I raised this in response to Lucy, the 
transport header may direct the forwarding to and through several 
service functions along a chain.  It need not be limited to forwarding 
to a single service function in the chain.
Note that in such cases I still need the SFC header for metadata, and 
may well want it for simpler interworking with other transports.

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Tue, 25 Mar 2014 21:19:28 +0000

Hi Ron,

Sorry to create such confusion. Yes, for network people, transport means the technology used below IP layer in OSI architecture. For Application people, transport means TCP or UDP. 
To clarify, the transport in this context means transport solution in L2.5 or below.  

See below.

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Tuesday, March 25, 2014 4:05 PM
To: Lucy yong; Joel M. Halpern; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hi, Lucy.

MAC (ethertype = SFC)
MAC (ethertype = IP) / IP (protocol = SFC) MAC (ethertype = IP) / IP (protocol = GRE) / GRE (ethertype = SFC) MAC (ethertype = IP) / IP (protocol = UDP) / UDP (dport = SFC) Frame-Relay ...

[Lucy] What is the benefit to allow SFC header being transported in many ways? I certainly see that creates the complex in control and management plane. What use case requires a special SFC transport mechanism? 

Thanks,
Lucy

     Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, March 25, 2014 4:51 PM
To: Joel M. Halpern; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Joel,

Thanks,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, March 25, 2014 3:17 PM
To: Lucy yong; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Tue, 25 Mar 2014 21:25:47 +0000

Hi Dave,

If a service forwarder point connects more than one SF instances that belong to the same SFC, how can one Path ID determine which SF instances is the next? If you draw a service chain path with many SF instances, you can easily see, if Path ID represents that path, service forwarder needs to use previous SF on the path to position the next SF on that path.

Lucy

From: Dave Dolson [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 4:10 PM
To: Lucy yong; [email-masked]
Subject: RE: SFC as an IP or UDP application, pros and cons?

From: Lucy yong [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 4:56 PM
To: Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: RE: SFC as an IP or UDP application, pros and cons?

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Tue, 25 Mar 2014 21:31:38 +0000

Hi Joel,

I agree that SFC header may carry metadata and that metadata will be used by SFs ( I see that (re)classification is also as a SF). So the metadata does not relate to forwarding the packets with SFC header. This is the reason I do not mention that.

Thanks,
Lucy 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, March 25, 2014 4:14 PM
To: Ron Parker; Lucy yong; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Yes, that is what I meant by transport.  And yes, there are many options (for example an MPLS label).

Further, and to the reason I raised this in response to Lucy, the transport header may direct the forwarding to and through several service functions along a chain.  It need not be limited to forwarding to a single service function in the chain.
Note that in such cases I still need the SFC header for metadata, and may well want it for simpler interworking with other transports.

Yours,
Joel

On 3/25/14, 5:04 PM, Ron Parker wrote:
> MAC (ethertype = IP) / IP (protocol = SFC) MAC (ethertype = IP) / IP 
> (protocol = GRE) / GRE (ethertype = SFC) MAC (ethertype = IP) / IP 
> (protocol = UDP) / UDP (dport = SFC) Frame-Relay ...
>
>
>       Ron
>
>

---

From: Lucy yong <[email-masked]>
Date: Tue, 25 Mar 2014 21:37:12 +0000

Hi Joel and Ron,

Yes, that is what I meant by transport.  And yes, there are many options (for example an MPLS label).
[Lucy] all these transport solutions can transport IP packets. IP network technology provide many capabilities, we can easily reuse them in many SFC use cases. What are cons to implement SFC as IP application? 

Lucy

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 25 Mar 2014 21:56:29 +0000

Hi,

There are several solution to this problem. Some of them implementation specific, others more elegant.

1 - One of the more elegant ones is to use the Service Index to determine the next service function instance.  It makes for a completely stateless solution (code wise).

2 – Another option is from a coding perspective you can just keep more state in your SN/SFF while you process the packet and determine what is the “next” service.

But irrespective, the SN needs to know the Path ID and the list of SFIs internal to its node. This provisioning can happen in a variety of ways, I implemented with RESTconf and Netconf.

As far as UDP/IP vs.IP, I give preference to UDP/IP. If you have a fixed port over UDP in which to receive/send packets:

- You can have your entire dataplane in userpace and use a variety of programming languages.
- You do not need raw packet access to pull/send packets. Therefore no root support.
- UDP can traverse non-SFC aware middlexboxes. Or you can use any of the available methods( TURN, STUN, etc).  If you encap in something else other than IP/UDP the applicability of SFC will be considerably diminished.Just check STCP and its problem on getting adopted given middlexboxes  not recognizing its protocol number.
- It jives with other IETF work in the areas of metadata and transport services (say, TAPS).

regards,

Reinaldo

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 25, 2014 at 2:25 PM
To: Dave Dolson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Dave,

Lucy

Lucy

Hi,

This solution seems simple to me and only need Path ID in SFC header for steering traffic through the SFC path. But like to see others’ opinion on this solution, pros and cons.

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Tue, 25 Mar 2014 22:38:40 +0000

Hi Reinaldo,

Thank you to share your views on this solution. We want to have an elegant and general solution with one standard SFC header to cover majority use cases

See inline below.

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 4:56 PM
To: Lucy yong; Dave Dolson; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi,

1 - One of the more elegant ones is to use the Service Index to determine the next service function instance.  It makes for a completely stateless solution (code wise).
[Lucy] when using Path ID and Service Index on SFC header, it requires assigning index # to each SF instance, configuring them in the forwarding table, which is very complex process and easily prune for error in may opinion.  In addition, each SF instance may serve more than one SFC, so need to assign index # for each SFC, which is more complex. Regarding the stateless, I don't get it. Isn't index # a state as well (may be few bit less)?

To implement true stateless, SFC header needs ability to carry all SFIs IP addresses in SFC header, which was considered as non-scale solution.

2 - Another option is from a coding perspective you can just keep more state in your SN/SFF while you process the packet and determine what is the "next" service.
[Lucy] Agree.

- You can have your entire dataplane in userpace and use a variety of programming languages.
- You do not need raw packet access to pull/send packets. Therefore no root support.
- UDP can traverse non-SFC aware middlexboxes.
[Lucy] Agree on this statement. But for SFC domain, do we want to allow such midboxes on SFC path? Maybe happen if a SFC domain crosses more than transport domains? This is one I like to know from SPs and SF vendors.

Regards,
Lucy
Or you can use any of the available methods( TURN, STUN, etc).  If you encap in something else other than IP/UDP the applicability of SFC will be considerably diminished.Just check STCP and its problem on getting adopted given middlexboxes  not recognizing its protocol number.

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 25 Mar 2014 18:56:25 -0400

We want to have one SFC header.
The IP header would be a Transport header, and therefore is one of 
several valid options.
Also, as I tried to explain before, IP as a transport is rather limited 
since it can only specify the next service function, while various of 
the other transports can identify the chain.
So there are trad-offs with different transports.
And since the charter is clear that transport for the SFC header is out 
of scope, I would hope we will not get into an extended debate about them.

Yours,
Joel

On 3/25/14, 6:38 PM, Lucy yong wrote:
> Hi Reinaldo,
>
> Thank you to share your views on this solution. We want to have an
> elegant and general solution with one standard SFC header to cover
> majority use cases
>
> See inline below.
>
> *From:*Reinaldo Penno (repenno) [mailto:[email-masked]]
> *Sent:* Tuesday, March 25, 2014 4:56 PM
> *To:* Lucy yong; Dave Dolson; [email-masked]
> *Subject:* Re: [sfc] SFC as an IP or UDP application, pros and cons?
>
> Hi,
>
> 1 - One of the more elegant ones is to use the Service Index to
> determine the next service function instance.  It makes for a completely
> stateless solution (code wise).
>
> */[Lucy] /*when using Path ID and Service Index on SFC header, it
> requires assigning index # to each SF instance, configuring them in the
> forwarding table, which is very complex process and easily prune for
> error in may opinion.  In addition, each SF instance may serve more than
> one SFC, so need to assign index # for each SFC, which is more complex.
> Regarding the stateless, I don’t get it. Isn’t index # a state as well
> (may be few bit less)?
>
> To implement true stateless, SFC header needs ability to carry all SFIs
> IP addresses in SFC header, which was considered as non-scale solution.
>
> 2 – Another option is from a coding perspective you can just keep more
> state in your SN/SFF while you process the packet and determine what is
> the “next” service.
>
> */[Lucy] Agree./*
>
> But irrespective, the SN needs to know the Path ID and the list of SFIs
> internal to its node. This provisioning can happen in a variety of ways,
> I implemented with RESTconf and Netconf.
>
> As far as UDP/IP vs.IP, I give preference to UDP/IP. If you have a fixed
> port over UDP in which to receive/send packets:
>
> */[Lucy] Agree on this statement. But for SFC domain, do we want to
> allow such midboxes on SFC path? Maybe happen if a SFC domain crosses
> more than transport domains? This is one I like to know from SPs and SF
> vendors. /*
>
> *//*
>
> */Regards,/*
>
> */Lucy/*
>
> Or you can use any of the available methods( TURN, STUN, etc).  If you
> encap in something else other than IP/UDP the applicability of SFC will
> be considerably diminished.Just check STCP and its problem on getting
> adopted given middlexboxes  not recognizing its protocol number.
>
> *//*
>
> *From: *Lucy yong <[email-masked] <mailto:[email-masked]>>
> *Date: *Tuesday, March 25, 2014 at 2:25 PM
> *To: *Dave Dolson <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Subject: *Re: [sfc] SFC as an IP or UDP application, pros and cons?
>
> Hi Dave,
>
> If a service forwarder point connects more than one SF instances that
> belong to the same SFC, how can one Path ID determine which SF instances
> is the next? If you draw a service chain path with many SF instances,
> you can easily see, if Path ID represents that path, service forwarder
> needs to use previous SF on the path to position the next SF on that path.
>
> Lucy
>
> *From:*Dave Dolson [mailto:[email-masked]]
> *Sent:* Tuesday, March 25, 2014 4:10 PM
> *To:* Lucy yong; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: SFC as an IP or UDP application, pros and cons?
>
> Why do you think the previous SF IP address is required to determine the
> next SF IP address? Why is the Path ID not sufficient information?
>
> *From:*Lucy yong [mailto:[email-masked]]
> *Sent:* Tuesday, March 25, 2014 4:56 PM
> *To:* Dave Dolson; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: SFC as an IP or UDP application, pros and cons?
>
> In this solution, service forwarder and SF instance are separated
> entities. Service forwarder needs Path ID and previous SF IP address to
> uniquely identify the next SF IP address.
>
> Lucy
>
> *From:*Dave Dolson [mailto:[email-masked]]
> *Sent:* Tuesday, March 25, 2014 3:21 PM
> *To:* Lucy yong; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: SFC as an IP or UDP application, pros and cons?
>
> I do not see why source IP address (previous SF) would be required to
> look up the next SF. The path ID should be sufficient to determine the
> next SF.
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Lucy yong
> *Sent:* Tuesday, March 25, 2014 4:02 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [sfc] SFC as an IP or UDP application, pros and cons?
>
> Hi,
>

---

From: Lucy yong <[email-masked]>
Date: Tue, 25 Mar 2014 23:09:00 +0000

Hi Joel,

Yes, we want one SFC header. To follow your assumption, if we have a Path ID and previous SFI IP address in SFC Header, it achieves the same result in the forwarding without depending on the transport header.

Thanks,
Lucy 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, March 25, 2014 5:56 PM
To: Lucy yong; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

We want to have one SFC header.
The IP header would be a Transport header, and therefore is one of several valid options.
Also, as I tried to explain before, IP as a transport is rather limited since it can only specify the next service function, while various of the other transports can identify the chain.
So there are trad-offs with different transports.
And since the charter is clear that transport for the SFC header is out of scope, I would hope we will not get into an extended debate about them.

Yours,
Joel

On 3/25/14, 6:38 PM, Lucy yong wrote:
> There are several solution to this problem. Some of them 
> implementation specific, others more elegant.
>
> determine the next service function instance.  It makes for a 
> completely stateless solution (code wise).
>
> requires assigning index # to each SF instance, configuring them in 
> the forwarding table, which is very complex process and easily prune 
> for error in may opinion.  In addition, each SF instance may serve 
> more than one SFC, so need to assign index # for each SFC, which is more complex.
> Regarding the stateless, I don't get it. Isn't index # a state as well 
> (may be few bit less)?
>
> To implement true stateless, SFC header needs ability to carry all 
> SFIs IP addresses in SFC header, which was considered as non-scale solution.
>
> 2 - Another option is from a coding perspective you can just keep more 
> state in your SN/SFF while you process the packet and determine what 
> is the "next" service.
>
> */[Lucy] Agree./*
>
> But irrespective, the SN needs to know the Path ID and the list of 
> SFIs internal to its node. This provisioning can happen in a variety 
> of ways, I implemented with RESTconf and Netconf.
>
> As far as UDP/IP vs.IP, I give preference to UDP/IP. If you have a 
> fixed port over UDP in which to receive/send packets:
>
> more than transport domains? This is one I like to know from SPs and 
> SF vendors. /*
>
> *//*
>
> */Regards,/*
>
> */Lucy/*
>
> encap in something else other than IP/UDP the applicability of SFC 
> will be considerably diminished.Just check STCP and its problem on 
> getting adopted given middlexboxes  not recognizing its protocol number.
>
> *//*
>
> *To: *Dave Dolson <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>
> belong to the same SFC, how can one Path ID determine which SF 
> instances is the next? If you draw a service chain path with many SF 
> instances, you can easily see, if Path ID represents that path, 
> service forwarder needs to use previous SF on the path to position the next SF on that path.
>
> Lucy
>
> Why do you think the previous SF IP address is required to determine 
> the next SF IP address? Why is the Path ID not sufficient information?
>
> entities. Service forwarder needs Path ID and previous SF IP address 
> to uniquely identify the next SF IP address.
>
> Lucy
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 25 Mar 2014 19:13:03 -0400

You are assuming that there is a "previous SF IP Address".  Youa re also 
assuming it is useful for forwarding logic.
Both cases may be true.  But neither case needs to apply.  I can do pure 
SFID based forwarding with just the index.  (If I assume that individual 
chains don't loop through the same SFF, I could even do it without the 
index.  But having the index is more robust.)

So I do not see why SFC should mandate that the structure uses an SF IP 
Address, or carriers one (or two).  You can use IP as the transport if 
you want.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Tue, 25 Mar 2014 23:13:20 +0000

Lucy,

Regarding the service function index that would be contained in the service header, I think it is simply incremented from 1 to indicate the next service function within the chain.   For example, if the path ID is X, for a path {SF-A-5, SF-B-2, SF-C-6}, then packets destined from a classifier towards SF-A-5 would carry (path X, index 1), packets from SF-A-5 to SF-B-2 would carry (path X, index 2), etc.

   Ron

________________________________
From: sfc [[email-masked]] on behalf of Lucy yong [[email-masked]]
Sent: Tuesday, March 25, 2014 6:38 PM
To: Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Reinaldo,

See inline below.

Hi,

1 - One of the more elegant ones is to use the Service Index to determine the next service function instance.  It makes for a completely stateless solution (code wise).
[Lucy] when using Path ID and Service Index on SFC header, it requires assigning index # to each SF instance, configuring them in the forwarding table, which is very complex process and easily prune for error in may opinion.  In addition, each SF instance may serve more than one SFC, so need to assign index # for each SFC, which is more complex. Regarding the stateless, I don’t get it. Isn’t index # a state as well (may be few bit less)?

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 25 Mar 2014 23:29:42 +0000

Inline

Sent from my iPhone

On Mar 25, 2014, at 6:39 PM, "Lucy yong" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Reinaldo,

See inline below.

From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 4:56 PM
To: Lucy yong; Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi,

1 - One of the more elegant ones is to use the Service Index to determine the next service function instance.  It makes for a completely stateless solution (code wise).
[Lucy] when using Path ID and Service Index on SFC header, it requires assigning index # to each SF instance, configuring them in the

Jim> not at all. It's a very simple mechanism; see draft-quinn-sfc-nsh.

forwarding table, which is very complex process and easily prune for error in may opinion.  In addition, each SF instance may serve more than one SFC, so need to assign index # for each SFC, which is more complex. Regarding the stateless, I don’t get it. Isn’t index # a state as well (may be few bit less)?

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "He, Peng" <[email-masked]>
Date: Tue, 25 Mar 2014 19:33:47 -0400

Agree.. would prefer SFID-only based forwarding.

Regards,
Peng

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
Sent: Tuesday, March 25, 2014 7:13 PM
To: Lucy yong; Joel M. Halpern; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

You are assuming that there is a "previous SF IP Address".  Youa re also assuming it is useful for forwarding logic.
Both cases may be true.  But neither case needs to apply.  I can do pure SFID based forwarding with just the index.  (If I assume that individual chains don't loop through the same SFF, I could even do it without the index.  But having the index is more robust.)

So I do not see why SFC should mandate that the structure uses an SF IP Address, or carriers one (or two).  You can use IP as the transport if you want.

Yours,
Joel

On 3/25/14, 7:09 PM, Lucy yong wrote:
>> Regarding the stateless, I don't get it. Isn't index # a state as 
>> well (may be few bit less)?
>>
>> 2 - Another option is from a coding perspective you can just keep 
>> more state in your SN/SFF while you process the packet and determine 
>> what is the "next" service.
>>
>> */[Lucy] Agree./*
>>
>> Or you can use any of the available methods( TURN, STUN, etc).  If 
>> you encap in something else other than IP/UDP the applicability of 
>> SFC will be considerably diminished.Just check STCP and its problem 
>> on getting adopted given middlexboxes  not recognizing its protocol number.
>>
>> *//*
>>
>> look up the next SF. The path ID should be sufficient to determine 
>> the next SF.
>>

---

From: Dave Dolson <[email-masked]>
Date: Tue, 25 Mar 2014 23:43:36 +0000

I'd rather see the approach in which every path ID is unique and unambiguous, not qualified by sender.

From: Lucy yong [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 5:26 PM
To: Dave Dolson; [email-masked]
Subject: RE: SFC as an IP or UDP application, pros and cons?

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 25 Mar 2014 23:46:39 +0000

By using the index; that's the whole point of it.

Sent from my iPhone

On Mar 25, 2014, at 5:26 PM, "Lucy yong" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: "Changcheng Huang" <[email-masked]>
Date: Tue, 25 Mar 2014 21:44:06 -0700

Very good point.

Chang

From: sfc [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Tuesday, March 25, 2014 2:12 PM
To: Ron Parker
Cc: Joel M. Halpern; [email-masked]; Lucy yong
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

This is an interesting discussion.  Given that many encap proposals in the
NVO3 WG use UDP because they want to play nice with available hashing
mechanisms in existing hardware, it looks like SFC is about break things all
over again. :)

Anoop

On Tue, Mar 25, 2014 at 2:04 PM, Ron Parker
<[email-masked]> wrote:

Hi, Lucy.

I originally had some confusion around the terminology so I thought I'd
share.   When I first heard "transport" I though layer 4 UDP/TCP/etc.    But
what I believe is meant by "transport" in this context is, instead, a full
encapsulation that will get the desired packet or frame to the intended
place.   So in the SFC terminology, some possible examples for "transport"
that is applied in front of the SFC-specific header could theoretically be:

MAC (ethertype = SFC)

     Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, March 25, 2014 4:51 PM
To: Joel M. Halpern; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Joel,

I believe that transporting between service forwarder points is what you
mean. Although service forwarder point sends/receives the packet with SFC
header as IP packet, IP packets can be transported by any transport solution
such as Ethernet, PW/MPLS, Overlay Technologies, isn't? IP is network
technology, and not a transport technology.

If service forwarder point is a service router, the solution will not change
the router behavior, i.e. forward on IP destination address on the packet.
Only addition to a service router is if that destination address is the
router itself, the router terminates the packet and checks the protocol, if
it is SFC, it retrieve the SFC header and performs the table lookup based on
Path ID and src IP address.

Thanks,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, March 25, 2014 3:17 PM
To: Lucy yong; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

This proposal specifies the transport mechanism for the service chaining.  I
had thought that we were not going to mandate a specific transport, as there
are reasons for making different choices, and boundary interworking is quite
tractable.

Yours,
Joel

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Wed, 26 Mar 2014 08:10:44 +0000

Hello Lucy,

We can imagine  a chain going twice through the same location possibly expecting to receive services from different set of SFs  each time. 

This could be achieved easily if we have an index in the header in addition to the path ID. I don't see how we could allow this use case if we rely on previous SFI IP to identify where we are in a chain.

Aslo we can imagine MPLS labels inserted between Layer2 and layer 3, used to route the traffic along a chain via some SDN controlled environment, as an underlay transport mechanism. In this case there could be no source IP address to work with.

Nicolas

________________________________________
From: Lucy yong [[email-masked]]
Sent: Wednesday, March 26, 2014 12:09 AM
To: Joel M. Halpern; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Joel,

Thanks,
Lucy

-

---

From: <[email-masked]>
Date: Wed, 26 Mar 2014 13:23:42 +0100

Hi Reinaldo, all,

In addition to these two ones, other alternatives are discussed in http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#section-5

   5<http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#section-5>.  Format of the Service Function Chaining Header  . . . . . . .   6<http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#page-6>
     5.1<http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#section-5.1>.  Format 1: Single Marking Code Point . . . . . . . . . . .   7<http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#page-7>
     5.2<http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#section-5.2>.  Format 2: Marking Code Point & Profile Index  . . . . . .   7<http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#page-7>
     5.3<http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#section-5.3>.  Format 3: Explicit Route List . . . . . . . . . . . . . .   8<http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#page-8>
     5.4<http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#section-5.4>.  Format 4: Compact Explicit Route List . . . . . . . . . .   9<http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#page-9>

Cheers;
Med

De : sfc [mailto:[email-masked]] De la part de Reinaldo Penno (repenno)
Envoyé : mardi 25 mars 2014 22:56
À : Lucy yong; Dave Dolson; [email-masked]
Objet : Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi,

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Tim Chown <[email-masked]>
Date: Wed, 26 Mar 2014 14:08:42 +0000

On 26 Mar 2014, at 12:23, <[email-masked]> <[email-masked]> wrote:

> Hi Reinaldo, all,
>  
> In addition to these two ones, other alternatives are discussed in http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02

Hi,

A couple of comments on the potential use of IPv6 EHs referenced in your design document.

Firstly, RFC6564 is being updated by draft-gont-6man-ipv6-universal-extension-header-00.

Secondly, some tests that we’ve run recently (to Alexa top1m IPv6-enabled sites) show the drop rate on packets with IPv6 EHs is quite significant. These were reported by ourselves and Fernando Gont in the IETF89 IEPG meeting. There have been a number of I-Ds discussing EH handling, but the results ‘in the wild’ are poor.  I understand that SFC is targeted at single domain environments, but it’s not clear as yet whether drops are due to administrative policy, or implementation shortcomings. If the latter, then these may be an issue for at least some time for any SFC solution dependent on their use.

Tim

---

From: Lucy yong <[email-masked]>
Date: Wed, 26 Mar 2014 14:38:13 +0000

Good observation. It is indeed.

SFC solution, in theory, does not limit to certain transport solution that will get the desired packet or frame to the intended place.  In reality, we want a simple and low cost solution. We need to make both goals.

Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Tuesday, March 25, 2014 4:12 PM
To: Ron Parker
Cc: Lucy yong; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

This is an interesting discussion.  Given that many encap proposals in the NVO3 WG use UDP because they want to play nice with available hashing mechanisms in existing hardware, it looks like SFC is about break things all over again. :)

Anoop

On Tue, Mar 25, 2014 at 2:04 PM, Ron Parker <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Lucy.

MAC (ethertype = SFC)

     Ron

-----Original Message-----
From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Lucy yong
Sent: Tuesday, March 25, 2014 4:51 PM
To: Joel M. Halpern; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Joel,

Thanks,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Joel M. Halpern
Sent: Tuesday, March 25, 2014 3:17 PM
To: Lucy yong; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Wed, 26 Mar 2014 15:04:33 +0000

Hi Joel,

You are assuming that there is a "previous SF IP Address".  Youa re also assuming it is useful for forwarding logic.
[Lucy] Yes, this is my assumption. If it is true, we can have a simple solution. 
Both cases may be true.  But neither case needs to apply.
[Lucy] That is what I try to get for this discussion. What requirements do we have on SFI? How we differentiate and identify SFIs? Use address or other identification. IMO: making SFIs as a host in the network allows SFC as an IP/UDP application.  
 
  I can do pure SFID based forwarding with just the index.  (If I assume that individual chains don't loop through the same SFF, I could even do it without the index.  But having the index is more robust.)
[Lucy] pure SFID is not in format of address. I understand what index intends and think that will be more complex solution. That is why I throw this solution to discuss pros and cons.

So I do not see why SFC should mandate that the structure uses an SF IP Address, or carriers one (or two).  You can use IP as the transport if you want.
[Lucy] Yeah, but we aim in a simple solution here for the use cases. carriers already can do SFC today. 

Thanks,
Lucy

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Wed, 26 Mar 2014 15:32:18 +0000

Hi Nicolas,

-----Original Message-----
From: Nicolas BOUTHORS [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 3:11 AM
To: Lucy yong; Joel M. Halpern; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hello Lucy,

We can imagine  a chain going twice through the same location possibly expecting to receive services from different set of SFs  each time. 
[Lucy] Yes, that can happen. But each time come from different SFIs, so previous SFI IP address are different when reaching the same location. Path ID + previous SFI IP address can uniquely position the next SFI.

This could be achieved easily if we have an index in the header in addition to the path ID. I don't see how we could allow this use case if we rely on previous SFI IP to identify where we are in a chain.
[Lucy] yes, you can use index and make implementation work. Index assignment and programming the forwarding table with Path ID + index is complex process and easily prune error. If one SFI serves multiple SFCs, you have multiple index # mapping to the same SFI, which is the complex.

Aslo we can imagine MPLS labels inserted between Layer2 and layer 3, used to route the traffic along a chain via some SDN controlled environment, as an underlay transport mechanism. In this case there could be no source IP address to work with.
[Lucy] LER is used to transport IP packets over MPLS. It is perfect to use SDN controller to control those LERs that are used for SFC implementation.

Regards,
Lucy

Nicolas

Hi Joel,

Thanks,
Lucy

-

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Mar 2014 11:36:51 -0400

I am confused by your reference to error-prone.  I don't think any of 
these approaches are tractable for human configuration.  It is going to 
require orchestration.  And that orchestration is not more error prone 
in one case than another.

If you really want human beings to be manually setting up service chains 
we have a very different simplification problem to tackle.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Wed, 26 Mar 2014 15:39:51 +0000

Ron>> I will paint a counter-example.   There are SF-A and SF-B at one locator (e.g., running on the same host).   There are SF-C and SF-D at another locator (e.g., running on another host).   A chain is built to invoke, in order, {SF-A, SF-C, SF-B, SF-D}.    Let's say this is SF path ID X.  When the traffic arrives to the host that contains SF-B and SF-D, the previous hop IP would be that of the host containing SF-A and SF-C.   There is no way, without an SF index, for the second host to know the difference between the SF-A to SF-C hop and the SF-B to SF-D hop. 

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Wednesday, March 26, 2014 11:32 AM
To: Nicolas BOUTHORS; Joel M. Halpern; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Nicolas,

-----Original Message-----
From: Nicolas BOUTHORS [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 3:11 AM
To: Lucy yong; Joel M. Halpern; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hello Lucy,

Regards,
Lucy

Nicolas

Hi Joel,

Thanks,
Lucy

-

---

From: Lucy yong <[email-masked]>
Date: Wed, 26 Mar 2014 17:23:50 +0000

Hi Ron,

[snip]

[Lucy] I agree this case. In my proposed solution, it uses SF-X IP address in the lookup, not the previous hop IP address. It works perfectly in this case. I know that you can use index to achieve it too. 

[Lucy] Could you explain how to use index in achieving this and preventing loop as well. Your draft state:  "The first service function instance in the path is identified with service index 1."

Thanks,
Lucy 

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Wednesday, March 26, 2014 11:32 AM
To: Nicolas BOUTHORS; Joel M. Halpern; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Nicolas,

-----Original Message-----
From: Nicolas BOUTHORS [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 3:11 AM
To: Lucy yong; Joel M. Halpern; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hello Lucy,

Regards,
Lucy

Nicolas

Hi Joel,

Thanks,
Lucy

-

---

From: <[email-masked]>
Date: Thu, 27 Mar 2014 08:42:01 +0100

Hi Tim,

Thank you for this feedback.

If you have a pointer to cite, I can add it to the document. Note, that applying to conclusions of some experiments to the SFC use case is governed by this bullet:

   o  Despite it is widely known that routers and middleboxes filter IP
      options (e.g., drop IP packets with unknown IP options, strip
      unknown IP options, etc.), this concern does not apply for the
      Service Function Chaining case because the support of new IP
      options can be enabled within a domain operated by the same
      administrative domain.

As you rightfully said, assessing whether drops are due to "administrative policy, or implementation shortcomings." is key. This is exactly why the current text identifies the following items:

   | 1. Assess the impact on performance.                              |
   |                                                                   |
   | 2. Compare the impact of using the IPv4 option and the IPv6       |
   |    extension header vs. an encapsulation mode (i.e., in contexts  |
   |    where no encapsulation is required to reach the next SF hop).  |
   |                                                                   |
   | 3. Assess to what extent the use of an IPv4 option/IPv6 extension |
   |    header simplify internal tagging mechanisms specific to each SF|

Cheers,
Med

De : Tim Chown [mailto:[email-masked]]
Envoyé : mercredi 26 mars 2014 15:09
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Use of IPv6 EHs?

On 26 Mar 2014, at 12:23, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Reinaldo, all,

Hi,

Secondly, some tests that we've run recently (to Alexa top1m IPv6-enabled sites) show the drop rate on packets with IPv6 EHs is quite significant. These were reported by ourselves and Fernando Gont in the IETF89 IEPG meeting. There have been a number of I-Ds discussing EH handling, but the results 'in the wild' are poor.  I understand that SFC is targeted at single domain environments, but it's not clear as yet whether drops are due to administrative policy, or implementation shortcomings. If the latter, then these may be an issue for at least some time for any SFC solution dependent on their use.

Tim

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 27 Mar 2014 09:44:05 +0000

发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
发送时间: 2014年3月26日 7:13
收件人: Lucy yong; Reinaldo Penno (repenno); Dave Dolson; [email-masked]<mailto:[email-masked]>
主题: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

[Xiaohu] I think the value of the service index should be decremented, rather than being incremented when travelling along the service path since that index is not only used for indicating the next service function within the chain, but also used for other purposes (e.g., TTL of the service path, indicator of the end of the service chain), unless you want to introduce an additional field which indicates the total length of the service chain.

Best regards,
Xiaohu

   Ron

To: Reinaldo Penno (repenno); Dave Dolson; [email-masked]<mailto:[email-masked]>

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Ron Parker <[email-masked]>
Date: Thu, 27 Mar 2014 14:34:53 +0000

Xiaohu,

I don’t think we need to view the SF index as a TTL.   Appropriate validation and loop suppression can be done even with the current proposed definition.    Any SFF receiving an SFC encapsulated packet or frame would need to know to which of its dependent SF’s it should forward the packet or frame.   To do so means that it can validate that the path ID is one that it expects to participate in and that the SF instance identified by the index on that path is one that it is responsible for.    Such chain path data may have been locally provisioned or may have been distributed in a control plane.

When the SFF receives the good packet or frame back from one of its dependent SF’s, it will identify the next SF and SFF by consulting its local database.   If it is not the final SF, then the SF index is incremented, the transport header updated as necessary, and the packet or frame progressed.    Failure to properly increment the SF Index would be akin to failure to decrement a TTL by a router – there is no protection from that.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, March 27, 2014 5:44 AM
To: Ron Parker; Lucy yong; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Thu, 27 Mar 2014 16:26:00 +0000

Hi Ron,

I assume that the index usage you mentioned below is the same whether these three SFs are on one SFF or two SFFs, which means that the index # is assigned to SF-X-I per SFC and by the incremental. A SF-X-I may be served to many SFCs and position differently in SFCs. This means that, in this method, a SF-X-I is mapped with different index #, one per each SFC that has the SF-X-I. IMO:  when operator/system creates a SFC and selects SF-X-Is for the SFC, and then assign index # to them and configure the forwarding table with path ID and index # in the related SFFs. Furthermore, each index # also need to be associated to the address or port that transport layer can understand.  IMO: this is a complex process for the system, uneasy to manger too, and may easily prone an error.

Second, your draft also mention that the use of index to prevent the loop.  The loop does not occur in normal condition. The loop occurs in abnormal condition. So the loop prevention mechanism is to prevent no loop happen in any abnormal condition. That is why TTL is designed for in IP network. If SFC header is expected to transport over any transport network beside IP, it needs the similar mechanism as IP/TTL. The usage of index in your proposal does not achieve this purpose.

If we use IP as transport, IMO: no need to implement TTL mechanism within SFC, just leverage IP TTL capability. But, if over other transports, we need to implement IP/TTL like mechanism in SFC.

Regards,
Lucy

From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 9:35 AM
To: Xuxiaohu; Lucy yong; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Xiaohu,

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, March 27, 2014 5:44 AM
To: Ron Parker; Lucy yong; Reinaldo Penno (repenno); Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Ron Parker <[email-masked]>
Date: Thu, 27 Mar 2014 17:08:57 +0000

Lucy,

Regarding the SF Index, draft-zhang-sfc-sch defines this as relative to the path, and not as a globally unique identifier of an SF instance.

Regarding TTL, my first thought is that is a property of the transport, and if it is important to you, choose the transport accordingly.   But, I’m open to further discussion along these lines.

   Ron

From: Lucy yong [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 12:26 PM
To: Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Ron,

Regards,
Lucy

From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 9:35 AM
To: Xuxiaohu; Lucy yong; Reinaldo Penno (repenno); Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Thu, 27 Mar 2014 19:40:43 +0000

Hi Ron,

From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 12:09 PM
To: Lucy yong; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

Regarding the SF Index, draft-zhang-sfc-sch defines this as relative to the path, and not as a globally unique identifier of an SF instance.
[Lucy] This is my understanding too. “The path” here means a SFC, right? I do not see index as an SF instance identifier at all, it is an alias and only used in forwarding. This is the reason, I think, that assigning these aliases and configuring then in forwarding table is complex for management and controller and may prune an error easily. For supporting bi-directional or branching use cases, using index in forwarding may also bring other concerns.

Regarding TTL, my first thought is that is a property of the transport, and if it is important to you, choose the transport accordingly.   But, I’m open to further discussion along these lines.
[Lucy] Thank you for the clarification. This is related to the discussion under this title. If SPC is implemented as IP or IP/UDP application, it can leverage a lot what IP technology have done. If we assume that SFC may be carried over any transport solution, SFC implementation has to provide these functions, which, IMO, related to what information that SFC header need to hold.

Thanks,
Lucy

   Ron

From: Lucy yong [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 12:26 PM
To: Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Ron Parker <[email-masked]>
Date: Thu, 27 Mar 2014 20:00:54 +0000

Lucy,

One clarification.   “The path” does not exactly mean the SFC.   The SFC is abstract, before accounting for network locators.   As a special case, if all of the SF’s in the SFC have only a single network locator, then the path and chain are the same.   But, if any or all of those SF’s are multiply located, then the path is specific to an exact sequence of located service function instances.

    Ron

From: Lucy yong [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 3:41 PM
To: Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Ron,

From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 12:09 PM
To: Lucy yong; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Thu, 27 Mar 2014 20:07:32 +0000

Ron,

From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 3:01 PM
To: Lucy yong; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

One clarification.   “The path” does not exactly mean the SFC.   The SFC is abstract, before accounting for network locators.   As a special case, if all of the SF’s in the SFC have only a single network locator, then the path and chain are the same.   But, if any or all of those SF’s are multiply located, then the path is specific to an exact sequence of located service function instances.
[Lucy] Thank you for clarification. I agree with that. The path is an exact sequence of located service function instances. For a bi-directional SFC, it has to be treated as two distinct paths in this solution. Any concern on the complexity in managing them?

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Ron Parker <[email-masked]>
Date: Thu, 27 Mar 2014 20:11:24 +0000

Lucy,

You raise a good point on bidirectional chains, which I think is a majority use case for functional, simplification, or observability reasons.    The way we’ve expressed things so far, it would be up to the management plane or control plane to indicate how such individual paths are paired together.

   Ron

From: Lucy yong [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 4:08 PM
To: Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Thu, 27 Mar 2014 20:18:25 +0000

Ron,

IMO, We can’t make one part simple and good looking but leave other parts to be in complex. Our goal is to have a simple and low cost SFC solution to cover majority use cases. SP already can implement SFC on today’s network. If we can’t make this goal, then the solution may not be useful.

Thanks,
Lucy

From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 3:11 PM
To: Lucy yong; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Ron Parker <[email-masked]>
Date: Thu, 27 Mar 2014 20:24:15 +0000

Lucy.

Do you have a specific proposal for making bidirectional chains easier to deploy and manage?   If so, would you suggest changes to the requirements?   Architecture?   Header encapsulation?   Control plane (future)?

    Ron

From: Lucy yong [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 4:18 PM
To: Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Thu, 27 Mar 2014 21:25:30 +0000

Hi Ron,

If we treat SFC as an IP or IP/UPD application, we do not change the requirement and architecture. We have a simple solution to achieve bi-directional SFC with the same Path ID. Let me explain the solution again.

If we implement SFC as an IP or UDP/IP application, i.e. once traffic is classified by the classification, it adds SFC header and IP header (outer) on the packets (UDP header too in latter case), and send such packets as a regular IP packet. The src IP on outer header is classification IP address, and dst IP is next SF-X Instance IP address. We only need to request a new IP protocol type for SFC.  At the SFF, it can search next SF-X Instance IP address based on Path ID in SFC header and src IP address (previous SF) on the packet when receiving a packet from previous SF-X instance; it forwards the packet on dst IP  on the packet when receiving a packet from another SFF/SNF.  A SF-X instance also forwards the packet with SFC header as an IP packet and fills its IP address as src IP on outer header and the SFF/SNF IP address as the dst IP on the outer header.

For bi-directional SFC, both directions can use the same Path ID in this solution. Path ID + src IP address let SFF uniquely get the next SF-X instance in forwarding table.

This solution can implement SNF/SFF function on a regular router without changing the router behavior, i.e. forward the packet based on its destination IP address. If the destination address is router itself, the router terminates and check the protocol type. If the type is SFC, the router will perform a table lookup based on Path ID in SFC header + src IP on outer IP header. As simple as that. This solution allow leveraging a lot of IP functions too.

Since IP can be transported over many transport solutions, Ethernet, MPLS, overlay, etc, in theory, SFC can be implemented over any transport network too. The solution can make control and management easy because we don’t have to assign index for each SF-X instances. SF-X IP address as unique identifier is used in all SFCs.

Any comment on this proposal.

Thanks,
Lucy

From: Ron Parker [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 3:24 PM
To: Lucy yong; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 28 Mar 2014 02:48:55 +0000

Lucy,

Was not following the thread fully; happened to read this one. This seems to be architecturally ill-thought-out IMO - comments inline..

Rgds,
Surendra.

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 27, 2014 2:25 PM
To: Ron Parker <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>, Dave Dolson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Ron,

If we implement SFC as an IP or UDP/IP application, i.e. once traffic is classified by the classification, it adds SFC header and IP header (outer) on the packets (UDP header too in latter case), and send such packets as a regular IP packet. The src IP on outer header is classification IP address, and dst IP is next SF-X Instance IP address. We only need to request a new IP protocol type for SFC.  At the SFF, it can search next SF-X Instance IP address based on Path ID in SFC header and src IP address (previous SF) on the packet when receiving a packet from previous SF-X instance; it forwards the packet on dst IP  on the packet when receiving a packet from another SFF/SNF.  A SF-X instance also forwards the packet with SFC header as an IP packet and fills its IP address as src IP on outer header and the SFF/SNF IP address as the dst IP on the outer header.
SK> It seems like SFC cannot be used in a layer-2 environment. Lot of assumptions have been made in describing this implementation. Where does the overlay start/end etc.  for instance, which may change before the pkt is delivered to the SF.

For bi-directional SFC, both directions can use the same Path ID in this solution. Path ID + src IP address let SFF uniquely get the next SF-X instance in forwarding table.
SK> This breaks correctness if you know how SFs behave.

This solution can implement SNF/SFF function on a regular router without changing the router behavior, i.e. forward the packet based on its destination IP address. If the destination address is router itself, the router terminates and check the protocol type. If the type is SFC, the router will perform a table lookup based on Path ID in SFC header + src IP on outer IP header. As simple as that. This solution allow leveraging a lot of IP functions too.
SK> Since you mention a router, what if it is a switch ? What are my considerations to make this work ? Does it even work as described ?

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

From: sfc [[email-masked]<mailto:[email-masked]>] on behalf of Lucy yong [[email-masked]<mailto:[email-masked]>]

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 28 Mar 2014 03:05:44 +0000

发件人: Ron Parker [mailto:[email-masked]]
发送时间: 2014年3月27日 22:35
收件人: Xuxiaohu; Lucy yong; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
主题: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Xiaohu,

[Xiaohu] I got it now. Yes it works. Thanks for your explanation.

Best regards,
Xiaohu

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Fri, 28 Mar 2014 08:08:28 +0000

Hello Lucy,

Your proposal supposes that the Path Id is included somewhere. Either in the IP/UDP overlay fields or in a specific header. I think the latter should prevail.

Your proposal does not cover Metadata transport which is one objective of the SFC group. So that would have to be added to the header either as a set of fixed fields or as a variable sized option. We are not that far from the quinn and zhang drafts.

The main difference being then on whether or not we should have an index in the header as well.

I don't see how it is more complex to provision a routing table in a SFF containg a list of pairs (previous IP address, [next IP address,..])* or an indexed list of pairs: (received index,[ [(next index, next IP address),..]]) *.

What we see tough is that that relying the previous IP sources for routing does not allow in all cases to have a SFF serve multiple SF sets (next SFs allowed) when they appear in the same chain. The index mechanism allows it instead.

The limitation seem to be that an SFF instance, in the model you propose, should not receive traffic from another one twice in a chain.

Is it correct ? and if so is it acceptable?

Nicolas

Note: * - second element in the pair is a list as we could have multiple possible next hops (e.g; LBS)

Based on Ron example of IP source model limitation:

   Network configration:
            SFF0(Ingres),  SFF1 ( SFA, SFB),    SFF2 (SFC, SFD), SFF(Egress).
             So 4 host, each with its separate SFF IP address, serving one or more local SF (same address as SFF)

   chain: Ingress,  SFA,  SFC,  SFB, SFD , Egress.
            Runs into a problem on SFF2 as it cannot distinguish traffic coming out of SFA or SFB based on SFF1 IP address only.

   chain: Ingress, SFA ,SFC, SFA, SFD, Egress.
            Has some issues as well as SFF2 the second time cannot distinguish that it is hit the first time of the second time.

Sent: Thursday, March 27, 2014 10:25 PM

Hi Ron,

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Fri, 28 Mar 2014 13:38:06 +0000

Surendra,

My reply inline.
From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Thursday, March 27, 2014 9:49 PM
To: Lucy yong; Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

Was not following the thread fully; happened to read this one. This seems to be architecturally ill-thought-out IMO - comments inline..
[Lucy] I see this as unhealthy comment.

Rgds,
Surendra.

Hi Ron,

If we implement SFC as an IP or UDP/IP application, i.e. once traffic is classified by the classification, it adds SFC header and IP header (outer) on the packets (UDP header too in latter case), and send such packets as a regular IP packet. The src IP on outer header is classification IP address, and dst IP is next SF-X Instance IP address. We only need to request a new IP protocol type for SFC.  At the SFF, it can search next SF-X Instance IP address based on Path ID in SFC header and src IP address (previous SF) on the packet when receiving a packet from previous SF-X instance; it forwards the packet on dst IP  on the packet when receiving a packet from another SFF/SNF.  A SF-X instance also forwards the packet with SFC header as an IP packet and fills its IP address as src IP on outer header and the SFF/SNF IP address as the dst IP on the outer header.
SK> It seems like SFC cannot be used in a layer-2 environment. Lot of assumptions have been made in describing this implementation. Where does the overlay start/end etc.  for instance, which may change before the pkt is delivered to the SF.
[Lucy] This is not true at all. The underlay network can be layer-2 environment. IP applications run over layer2 environment for many years. Overlay starts as the classification, i.e. the time insert SFC header and IP header.

For bi-directional SFC, both directions can use the same Path ID in this solution. Path ID + src IP address let SFF uniquely get the next SF-X instance in forwarding table.
SK> This breaks correctness if you know how SFs behave.
[Lucy] For your statement, I need to claim I don’t know SF behave, please explain what is SF behave and why it break. Thanks.

This solution can implement SNF/SFF function on a regular router without changing the router behavior, i.e. forward the packet based on its destination IP address. If the destination address is router itself, the router terminates and check the protocol type. If the type is SFC, the router will perform a table lookup based on Path ID in SFC header + src IP on outer IP header. As simple as that. This solution allow leveraging a lot of IP functions too.
SK> Since you mention a router, what if it is a switch ? What are my considerations to make this work ? Does it even work as described ?
[Lucy] As mentioned above, underlay network can be layer 2, only requires that devices implementing SFC forwarding function is IP aware, many switches have such capabilities. If you use programmable controller to control these SFC enabled devices, it works. What is your concern?

Lucy

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Fri, 28 Mar 2014 14:02:41 +0000

From: Nicolas BOUTHORS [mailto:[email-masked]]
Sent: Friday, March 28, 2014 3:08 AM
To: Lucy yong; Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hello Lucy,

Your proposal supposes that the Path Id is included somewhere. Either in the IP/UDP overlay fields or in a specific header. I think the latter should prevail.
[Lucy] To clarify, in my proposal it use the latter. The proposal is to treat SFC as an IP (/UDP) application. SFC solution relies on SFC header to convey the path ID and metadata. I did not mention metadata because the forwarding part does not use metadata. Again, in this proposal,  there is a SFC header that includes Path ID, metadata, etc.

Your proposal does not cover Metadata transport which is one objective of the SFC group. So that would have to be added to the header either as a set of fixed fields or as a variable sized option. We are not that far from the quinn and zhang drafts.
[Lucy] Hope above statement help here.

The main difference being then on whether or not we should have an index in the header as well.
[Lucy] No, this is not my point. My point is what information should be used in forwarding. We know that has to be PATH ID + something that represents to SF-X instance. Should we use index or SF-X IP address? I see the complexity to use index than IP address.

I don't see how it is more complex to provision a routing table in a SFF containg a list of pairs (previous IP address, [next IP address,..])* or an indexed list of pairs: (received index,[ [(next index, next IP address),..]]) *.
[Lucy] complexity I see were described in previous email.

What we see tough is that that relying the previous IP sources for routing does not allow in all cases to have a SFF serve multiple SF sets (next SFs allowed) when they appear in the same chain. The index mechanism allows it instead.
[Lucy] IMO:  PATH ID + SF-X instance IP address can uniquely determine the next SF-X instance IP in all cases.  Maybe I miss the case, could you give an example that does not work?

The limitation seem to be that an SFF instance, in the model you propose, should not receive traffic from another one twice in a chain.
[Lucy] It is not true. Don’t know where do you get that impression? Please give an example.

Thanks,
Lucy

Nicolas

   Network configration:

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Ron Parker <[email-masked]>
Date: Fri, 28 Mar 2014 14:14:17 +0000

Hi, Lucy.

Whether or not your implementation concept for IP/UDP makes sense for your product or your network environment, our charter is to create a solution that is not dependent on any one exact transport encapsulation.    That being said, any particular implementation could conceivably require a single type of encapsulation.   In short, I think your proposal falls into the implementation approach category which is out of scope from a standards perspective, IMO.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Friday, March 28, 2014 10:03 AM
To: Nicolas BOUTHORS; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

From: Nicolas BOUTHORS [mailto:[email-masked]]
Sent: Friday, March 28, 2014 3:08 AM
To: Lucy yong; Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hello Lucy,

Thanks,
Lucy

Nicolas

   Network configration:

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Fri, 28 Mar 2014 14:45:32 +0000

Ron,

Please see inline.

From: Ron Parker [mailto:[email-masked]]
Sent: Friday, March 28, 2014 9:14 AM
To: Lucy yong; Nicolas BOUTHORS; [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hi, Lucy.

Whether or not your implementation concept for IP/UDP makes sense for your product or your network environment, our charter is to create a solution that is not dependent on any one exact transport encapsulation.    That being said, any particular implementation could conceivably require a single type of encapsulation.   In short, I think your proposal falls into the implementation approach category which is out of scope from a standards perspective, IMO.
[Lucy] this is a “con” from logistics, not from technical. :(   Alternative to address this is to encode SF-X Instance identifier in SFC header instead of index, and use PATH ID + SF-X instance identifier in SFC forwarding process, which effectively achieves the same and simpler than use of index, IMO.

Lucy

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Friday, March 28, 2014 10:03 AM
To: Nicolas BOUTHORS; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hello Lucy,

Thanks,
Lucy

Nicolas

   Network configration:

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 28 Mar 2014 17:11:15 +0000

Folks,

While I appreciate this discussion please bring it to a close on the list. Our charter clearly states that we will not tie the service encapsulation to the transport. I draw your attention to this snippet of the charter:

"It is intended that the encapsulation format be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function chain applied at the network layer or at any other layer, and the same encapsulation format will apply for the construction of Service Function Paths regardless of the actual service."

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 28, 2014 at 10:45 AM
To: Ron Parker <[email-masked]<mailto:[email-masked]>>, Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Ron,

Please see inline.

From: Ron Parker [mailto:[email-masked]]
Sent: Friday, March 28, 2014 9:14 AM
To: Lucy yong; Nicolas BOUTHORS; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hi, Lucy.

Whether or not your implementation concept for IP/UDP makes sense for your product or your network environment, our charter is to create a solution that is not dependent on any one exact transport encapsulation.    That being said, any particular implementation could conceivably require a single type of encapsulation.   In short, I think your proposal falls into the implementation approach category which is out of scope from a standards perspective, IMO.
[Lucy] this is a “con” from logistics, not from technical. ☹   Alternative to address this is to encode SF-X Instance identifier in SFC header instead of index, and use PATH ID + SF-X instance identifier in SFC forwarding process, which effectively achieves the same and simpler than use of index, IMO.

Lucy

   Ron

Hello Lucy,

Thanks,
Lucy

Nicolas

   Network configration:

From: Lucy yong [[email-masked]<mailto:[email-masked]>]

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 28 Mar 2014 17:25:35 +0000

Lucy,

Comments inline.

Rgds,
Surendra.

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 28, 2014 6:38 AM
To: Surendra Kumar <[email-masked]<mailto:[email-masked]>>, Ron Parker <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, "Reinaldo Penno (repenno)" <[email-masked]<mailto:[email-masked]>>, Dave Dolson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Surendra,

My reply inline.

Lucy,

Was not following the thread fully; happened to read this one. This seems to be architecturally ill-thought-out IMO - comments inline..
[Lucy] I see this as unhealthy comment.
SK1> Please don't read too much into it. I was being very casual, no harm intended. Coffee/drink is on me in Toronto :)
Frankly, I see what is being described as way too narrow and with assumptions.

Rgds,
Surendra.

Hi Ron,

If we implement SFC as an IP or UDP/IP application, i.e. once traffic is classified by the classification, it adds SFC header and IP header (outer) on the packets (UDP header too in latter case), and send such packets as a regular IP packet. The src IP on outer header is classification IP address, and dst IP is next SF-X Instance IP address. We only need to request a new IP protocol type for SFC.  At the SFF, it can search next SF-X Instance IP address based on Path ID in SFC header and src IP address (previous SF) on the packet when receiving a packet from previous SF-X instance; it forwards the packet on dst IP  on the packet when receiving a packet from another SFF/SNF.  A SF-X instance also forwards the packet with SFC header as an IP packet and fills its IP address as src IP on outer header and the SFF/SNF IP address as the dst IP on the outer header.
SK> It seems like SFC cannot be used in a layer-2 environment. Lot of assumptions have been made in describing this implementation. Where does the overlay start/end etc.  for instance, which may change before the pkt is delivered to the SF.
[Lucy] This is not true at all. The underlay network can be layer-2 environment. IP applications run over layer2 environment for many years. Overlay starts as the classification, i.e. the time insert SFC header and IP header.
SK1> THe overlay itself can be L2 and we should not prevent that architecturally. There will not be a src IP address. As for using the same PathID, we need to use SrcIP in one case and dstIP in another. Does it mean the SF is fully aware of service forwarding ? When a SFF receives a pkt from a SF, what is the criteria to determine where it came from etc. Don't we want broader scope from an architecture perspective to accommodate as many implementations ?

For bi-directional SFC, both directions can use the same Path ID in this solution. Path ID + src IP address let SFF uniquely get the next SF-X instance in forwarding table.
SK> This breaks correctness if you know how SFs behave.
[Lucy] For your statement, I need to claim I don’t know SF behave, please explain what is SF behave and why it break. Thanks.
SK1> SFs send traffic in either direction on the flow. They can originate packets in the middle of a flow. Unless the SF is taught to figure out the next service hop, how do we know which way the packet is supposed to be forwarded on the chain. And why should we teach the SF, what the next hop is ?

This solution can implement SNF/SFF function on a regular router without changing the router behavior, i.e. forward the packet based on its destination IP address. If the destination address is router itself, the router terminates and check the protocol type. If the type is SFC, the router will perform a table lookup based on Path ID in SFC header + src IP on outer IP header. As simple as that. This solution allow leveraging a lot of IP functions too.
SK> Since you mention a router, what if it is a switch ? What are my considerations to make this work ? Does it even work as described ?
[Lucy] As mentioned above, underlay network can be layer 2, only requires that devices implementing SFC forwarding function is IP aware, many switches have such capabilities. If you use programmable controller to control these SFC enabled devices, it works. What is your concern?
SK> Not true. Switch can do a layer-2 overlay. Further, switch/router needs to do end-of-chain forwarding of the inner packet (L2 or L3). Each have to be given their considerations and they may lead to different implementation choices with implications.

Lucy

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Fri, 28 Mar 2014 20:45:37 +0000

Hi Surendra,

Please see inline.

[snip]
[Lucy1] SF is not aware of service forwarding at all except how to reach the SFF.  SF flips flop src and dst on packet when returning the packet back to SFF. Thus, SFF uses src addr to know where it came from. As simple as that.

[Lucy1] This solution works for bi-direction SFC and branching. SFF send a pkt to a SF, it puts SF addr as dst and SFF addr as src on outer IP header on pkt. SF return pkt by flipping src and dst. SF does not need to figure out, it is told by SFF in this way.

[Lucy1] I don’t see their conflict each other.

Lucy

Lucy

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Fri, 28 Mar 2014 21:01:02 +0000

My 2 cent:

Both SFC header and SFC header + IP header meet following criteria. In my proposal, SFC header + IP header serves as the encapsulation format and agnostic to the layer at which it is applied and the service that is being constricted.

SFC header  for the encap.

                   +--------------------------+

                   |      Original Payload    |

                   +--------------------------+

                   |      SFC Header          |

                   +--------------------------+

                   |   Transport header       |

                   +--------------------------+

SFC header + IP header for the encap.

                   +--------------------------+

                   |      Original Payload    |

                   +--------------------------+

                   |      SFC Header          |

                   +--------------------------+

                   |       IP Header          |

                   +--------------------------+

                   |   Transport header       |

                   +--------------------------+

Thanks,
Lucy

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Friday, March 28, 2014 12:11 PM
To: Lucy yong; Ron Parker; Nicolas BOUTHORS; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Folks,

Ron,

Please see inline.

Hi, Lucy.

Lucy

   Ron

Hello Lucy,

Thanks,
Lucy

Nicolas

   Network configration:

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: "Zarny, Myo" <[email-masked]>
Date: Fri, 28 Mar 2014 17:59:09 -0400

Hi Lucy,

Could you explain why you’ve chosen to peel out IP+SFC? Seems to me the upper diagram already covers the IP+SFC use case (assuming by transport we mean “IP, MAC, etc”.) Perhaps you may want to clarify what you mean by transport?

To me, the first diagram is the most generic/basic representation of the SFC header, its payload and its encapsulating/transport mechanism. A bunch of encapsulating mechanisms are possible but not all makes sense. IP encapsulating SFC Header is theoretically possible but what are benefits over other existing options like GRE or UDP? More specifically, why mandate an IP encapsulation mechanism – which seems not to be agnostic.

Regards,

From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: 28 March 2014 5:01 PM
To: Jim Guichard (jguichar); Ron Parker; Nicolas BOUTHORS; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

My 2 cent:

                   |      Original Payload    |

                   |      SFC Header          |

                   |   Transport header       |

                   |      Original Payload    |

                   |      SFC Header          |

                   |       IP Header          |

                   |   Transport header       |

Thanks,
Lucy

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Friday, March 28, 2014 12:11 PM
To: Lucy yong; Ron Parker; Nicolas BOUTHORS; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Folks,

Ron,

Please see inline.

Hi, Lucy.

Lucy

   Ron

Hello Lucy,

Thanks,
Lucy

Nicolas

   Network configration:

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: "Changcheng Huang" <[email-masked]>
Date: Sat, 29 Mar 2014 09:58:26 +0900

In order to make SFC independent from the transport, the transport must be
at higher layer. If, for example, the transport is at Layer 2, any router on
the path will terminate the Chain ID. Therefore where the transport is
located does matter.

Chang

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Friday, March 28, 2014 11:14 PM
To: Lucy yong; Nicolas BOUTHORS; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi, Lucy.

Whether or not your implementation concept for IP/UDP makes sense for your
product or your network environment, our charter is to create a solution
that is not dependent on any one exact transport encapsulation.    That
being said, any particular implementation could conceivably require a single
type of encapsulation.   In short, I think your proposal falls into the
implementation approach category which is out of scope from a standards
perspective, IMO.

   Ron

 

From: Nicolas BOUTHORS [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Friday, March 28, 2014 3:08 AM
To: Lucy yong; Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson;
<mailto:[email-masked]> [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hello Lucy, 

Your proposal supposes that the Path Id is included somewhere. Either in the
IP/UDP overlay fields or in a specific header. I think the latter should
prevail.

[Lucy] To clarify, in my proposal it use the latter. The proposal is to
treat SFC as an IP (/UDP) application. SFC solution relies on SFC header to
convey the path ID and metadata. I did not mention metadata because the
forwarding part does not use metadata. Again, in this proposal,  there is a
SFC header that includes Path ID, metadata, etc.

Your proposal does not cover Metadata transport which is one objective of
the SFC group. So that would have to be added to the header either as a set
of fixed fields or as a variable sized option. We are not that far from the
quinn and zhang drafts.

The main difference being then on whether or not we should have an index in
the header as well.

[Lucy] No, this is not my point. My point is what information should be used
in forwarding. We know that has to be PATH ID + something that represents to
SF-X instance. Should we use index or SF-X IP address? I see the complexity
to use index than IP address.

I don't see how it is more complex to provision a routing table in a SFF
containg a list of pairs (previous IP address, [next IP address,..])* or an
indexed list of pairs: (received index,[ [(next index, next IP
address),..]]) *.

What we see tough is that that relying the previous IP sources for routing
does not allow in all cases to have a SFF serve multiple SF sets (next SFs
allowed) when they appear in the same chain. The index mechanism allows it
instead.

[Lucy] IMO:  PATH ID + SF-X instance IP address can uniquely determine the
next SF-X instance IP in all cases.  Maybe I miss the case, could you give
an example that does not work?

The limitation seem to be that an SFF instance, in the model you propose,
should not receive traffic from another one twice in a chain.

[Lucy] It is not true. Don’t know where do you get that impression? Please
give an example.

Thanks,

Lucy

 

Nicolas

Note: * - second element in the pair is a list as we could have multiple
possible next hops (e.g; LBS)

   Network configration:

            SFF0(Ingres),  SFF1 ( SFA, SFB),    SFF2 (SFC, SFD),
SFF(Egress).   

             So 4 host, each with its separate SFF IP address, serving one
or more local SF (same address as SFF)

            Runs into a problem on SFF2 as it cannot distinguish traffic
coming out of SFA or SFB based on SFF1 IP address only.

            Has some issues as well as SFF2 the second time cannot
distinguish that it is hit the first time of the second time.

  _____  

From: Lucy yong [[email-masked]]
Sent: Thursday, March 27, 2014 10:25 PM
To: Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson;
<mailto:[email-masked]> [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Ron,

If we treat SFC as an IP or IP/UPD application, we do not change the
requirement and architecture. We have a simple solution to achieve
bi-directional SFC with the same Path ID. Let me explain the solution again.

If we implement SFC as an IP or UDP/IP application, i.e. once traffic is
classified by the classification, it adds SFC header and IP header (outer)
on the packets (UDP header too in latter case), and send such packets as a
regular IP packet. The src IP on outer header is classification IP address,
and dst IP is next SF-X Instance IP address. We only need to request a new
IP protocol type for SFC.  At the SFF, it can search next SF-X Instance IP
address based on Path ID in SFC header and src IP address (previous SF) on
the packet when receiving a packet from previous SF-X instance; it forwards
the packet on dst IP  on the packet when receiving a packet from another
SFF/SNF.  A SF-X instance also forwards the packet with SFC header as an IP
packet and fills its IP address as src IP on outer header and the SFF/SNF IP
address as the dst IP on the outer header. 

For bi-directional SFC, both directions can use the same Path ID in this
solution. Path ID + src IP address let SFF uniquely get the next SF-X
instance in forwarding table.

This solution can implement SNF/SFF function on a regular router without
changing the router behavior, i.e. forward the packet based on its
destination IP address. If the destination address is router itself, the
router terminates and check the protocol type. If the type is SFC, the
router will perform a table lookup based on Path ID in SFC header + src IP
on outer IP header. As simple as that. This solution allow leveraging a lot
of IP functions too.

Since IP can be transported over many transport solutions, Ethernet, MPLS,
overlay, etc, in theory, SFC can be implemented over any transport network
too. The solution can make control and management easy because we don’t
have to assign index for each SF-X instances. SF-X IP address as unique
identifier is used in all SFCs.

Thanks,

Lucy 

From: Ron Parker [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Thursday, March 27, 2014 3:24 PM
To: Lucy yong; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson;
<mailto:[email-masked]> [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy.

Do you have a specific proposal for making bidirectional chains easier to
deploy and manage?   If so, would you suggest changes to the requirements?
Architecture?   Header encapsulation?   Control plane (future)?

    Ron

From: Lucy yong [mailto:[email-masked]] 
Sent: Thursday, March 27, 2014 4:18 PM
To: Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson;
[email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Ron,

IMO, We can’t make one part simple and good looking but leave other parts
to be in complex. Our goal is to have a simple and low cost SFC solution to
cover majority use cases. SP already can implement SFC on today’s network.
If we can’t make this goal, then the solution may not be useful.

Thanks,

Lucy

From: Ron Parker [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Thursday, March 27, 2014 3:11 PM
To: Lucy yong; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson;
<mailto:[email-masked]> [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

You raise a good point on bidirectional chains, which I think is a majority
use case for functional, simplification, or observability reasons.    The
way we’ve expressed things so far, it would be up to the management plane
or control plane to indicate how such individual paths are paired together.

   Ron

From: Lucy yong [mailto:[email-masked]] 
Sent: Thursday, March 27, 2014 4:08 PM
To: Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson;
[email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Ron,

From: Ron Parker [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Thursday, March 27, 2014 3:01 PM
To: Lucy yong; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson;
<mailto:[email-masked]> [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

One clarification.   “The path” does not exactly mean the SFC.   The SFC
is abstract, before accounting for network locators.   As a special case, if
all of the SF’s in the SFC have only a single network locator, then the
path and chain are the same.   But, if any or all of those SF’s are
multiply located, then the path is specific to an exact sequence of located
service function instances.

[Lucy] Thank you for clarification. I agree with that. The path is an exact
sequence of located service function instances. For a bi-directional SFC, it
has to be treated as two distinct paths in this solution. Any concern on the
complexity in managing them?

Thanks,

Lucy

    Ron

From: Lucy yong [mailto:[email-masked]] 
Sent: Thursday, March 27, 2014 3:41 PM
To: Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson;
[email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Ron,

From: Ron Parker [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Thursday, March 27, 2014 12:09 PM
To: Lucy yong; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson;
<mailto:[email-masked]> [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy,

Regarding the SF Index, draft-zhang-sfc-sch defines this as relative to the
path, and not as a globally unique identifier of an SF instance.

[Lucy] This is my understanding too. “The path” here means a SFC, right? I
do not see index as an SF instance identifier at all, it is an alias and
only used in forwarding. This is the reason, I think, that assigning these
aliases and configuring then in forwarding table is complex for management
and controller and may prune an error easily. For supporting bi-directional
or branching use cases, using index in forwarding may also bring other
concerns.

Regarding TTL, my first thought is that is a property of the transport, and
if it is important to you, choose the transport accordingly.   But, I’m
open to further discussion along these lines.

[Lucy] Thank you for the clarification. This is related to the discussion
under this title. If SPC is implemented as IP or IP/UDP application, it can
leverage a lot what IP technology have done. If we assume that SFC may be
carried over any transport solution, SFC implementation has to provide these
functions, which, IMO, related to what information that SFC header need to
hold.

Thanks,

Lucy

   Ron

From: Lucy yong [mailto:[email-masked]] 
Sent: Thursday, March 27, 2014 12:26 PM
To: Ron Parker; Xuxiaohu; Reinaldo Penno (repenno); Dave Dolson;
[email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Ron,

I assume that the index usage you mentioned below is the same whether these
three SFs are on one SFF or two SFFs, which means that the index # is
assigned to SF-X-I per SFC and by the incremental. A SF-X-I may be served to
many SFCs and position differently in SFCs. This means that, in this method,
a SF-X-I is mapped with different index #, one per each SFC that has the
SF-X-I. IMO:  when operator/system creates a SFC and selects SF-X-Is for the
SFC, and then assign index # to them and configure the forwarding table with
path ID and index # in the related SFFs. Furthermore, each index # also need
to be associated to the address or port that transport layer can understand.
IMO: this is a complex process for the system, uneasy to manger too, and may
easily prone an error. 

Second, your draft also mention that the use of index to prevent the loop.
The loop does not occur in normal condition. The loop occurs in abnormal
condition. So the loop prevention mechanism is to prevent no loop happen in
any abnormal condition. That is why TTL is designed for in IP network. If
SFC header is expected to transport over any transport network beside IP, it
needs the similar mechanism as IP/TTL. The usage of index in your proposal
does not achieve this purpose. 

If we use IP as transport, IMO: no need to implement TTL mechanism within
SFC, just leverage IP TTL capability. But, if over other transports, we need
to implement IP/TTL like mechanism in SFC. 

Regards,

Lucy 

From: Ron Parker [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Thursday, March 27, 2014 9:35 AM
To: Xuxiaohu; Lucy yong; Reinaldo Penno (repenno); Dave Dolson;
<mailto:[email-masked]> [email-masked]
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Xiaohu,

I don’t think we need to view the SF index as a TTL.   Appropriate
validation and loop suppression can be done even with the current proposed
definition.    Any SFF receiving an SFC encapsulated packet or frame would
need to know to which of its dependent SF’s it should forward the packet or
frame.   To do so means that it can validate that the path ID is one that it
expects to participate in and that the SF instance identified by the index
on that path is one that it is responsible for.    Such chain path data may
have been locally provisioned or may have been distributed in a control
plane.

When the SFF receives the good packet or frame back from one of its
dependent SF’s, it will identify the next SF and SFF by consulting its
local database.   If it is not the final SF, then the SF index is
incremented, the transport header updated as necessary, and the packet or
frame progressed.    Failure to properly increment the SF Index would be
akin to failure to decrement a TTL by a router – there is no protection
from that.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, March 27, 2014 5:44 AM
To: Ron Parker; Lucy yong; Reinaldo Penno (repenno); Dave Dolson;
[email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

发件人: sfc [ <mailto:[email-masked]> mailto:[email-masked]] 代
表 Ron Parker
发送时间: 2014年3月26日 7:13
收件人: Lucy yong; Reinaldo Penno (repenno); Dave Dolson;  <mailto:sfc@ietf.
org> [email-masked]
主题: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Lucy, 

Regarding the service function index that would be contained in the service
header, I think it is simply incremented from 1 to indicate the next service
function within the chain.   For example, if the path ID is X, for a path
{SF-A-5, SF-B-2, SF-C-6}, then packets destined from a classifier towards
SF-A-5 would carry (path X, index 1), packets from SF-A-5 to SF-B-2 would
carry (path X, index 2), etc.

[Xiaohu] I think the value of the service index should be decremented,
rather than being incremented when travelling along the service path since
that index is not only used for indicating the next service function within
the chain, but also used for other purposes (e.g., TTL of the service path,
indicator of the end of the service chain), unless you want to introduce an
additional field which indicates the total length of the service chain.

Best regards,

Xiaohu

   Ron

  _____  

From: sfc [[email-masked]] on behalf of Lucy yong
[[email-masked]]
Sent: Tuesday, March 25, 2014 6:38 PM
To: Reinaldo Penno (repenno); Dave Dolson;  <mailto:[email-masked]>
[email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Reinaldo,

Thank you to share your views on this solution. We want to have an elegant
and general solution with one standard SFC header to cover majority use
cases

See inline below.

From: Reinaldo Penno (repenno) [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Tuesday, March 25, 2014 4:56 PM
To: Lucy yong; Dave Dolson;  <mailto:[email-masked]> [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi,

There are several solution to this problem. Some of them implementation
specific, others more elegant. 

1 - One of the more elegant ones is to use the Service Index to determine
the next service function instance.  It makes for a completely stateless
solution (code wise).  

[Lucy] when using Path ID and Service Index on SFC header, it requires
assigning index # to each SF instance, configuring them in the forwarding
table, which is very complex process and easily prune for error in may
opinion.  In addition, each SF instance may serve more than one SFC, so need
to assign index # for each SFC, which is more complex. Regarding the
stateless, I don’t get it. Isn’t index # a state as well (may be few bit
less)?

To implement true stateless, SFC header needs ability to carry all SFIs IP
addresses in SFC header, which was considered as non-scale solution.

2 – Another option is from a coding perspective you can just keep more
state in your SN/SFF while you process the packet and determine what is the
“next” service.  

[Lucy] Agree.

But irrespective, the SN needs to know the Path ID and the list of SFIs
internal to its node. This provisioning can happen in a variety of ways, I
implemented with RESTconf and Netconf. 

- You can have your entire dataplane in userpace and use a variety of
programming languages. 

- You do not need raw packet access to pull/send packets. Therefore no root
support. 

[Lucy] Agree on this statement. But for SFC domain, do we want to allow such
midboxes on SFC path? Maybe happen if a SFC domain crosses more than
transport domains? This is one I like to know from SPs and SF vendors. 

Regards,

Lucy

Or you can use any of the available methods( TURN, STUN, etc).  If you encap
in something else other than IP/UDP the applicability of SFC will be
considerably diminished.Just check STCP and its problem on getting adopted
given middlexboxes  not recognizing its protocol number.   

- It jives with other IETF work in the areas of metadata and transport
services (say, TAPS). 

regards, 

Reinaldo 

From: Lucy yong <[email-masked]>
Date: Tuesday, March 25, 2014 at 2:25 PM
To: Dave Dolson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Dave,

If a service forwarder point connects more than one SF instances that belong
to the same SFC, how can one Path ID determine which SF instances is the
next? If you draw a service chain path with many SF instances, you can
easily see, if Path ID represents that path, service forwarder needs to use
previous SF on the path to position the next SF on that path.

Lucy 

From: Dave Dolson [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Tuesday, March 25, 2014 4:10 PM
To: Lucy yong;  <mailto:[email-masked]> [email-masked]
Subject: RE: SFC as an IP or UDP application, pros and cons?

 

From: Lucy yong [ <mailto:[email-masked]> mailto:[email-masked]]

Sent: Tuesday, March 25, 2014 4:56 PM
To: Dave Dolson;  <mailto:[email-masked]> [email-masked]
Subject: RE: SFC as an IP or UDP application, pros and cons?

In this solution, service forwarder and SF instance are separated entities.
Service forwarder needs Path ID and previous SF IP address to uniquely
identify the next SF IP address. 

Lucy

From: Dave Dolson [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Tuesday, March 25, 2014 3:21 PM
To: Lucy yong;  <mailto:[email-masked]> [email-masked]
Subject: RE: SFC as an IP or UDP application, pros and cons?

I do not see why source IP address (previous SF) would be required to look
up the next SF. The path ID should be sufficient to determine the next SF.

 

From: sfc [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of Lucy yong
Sent: Tuesday, March 25, 2014 4:02 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: [sfc] SFC as an IP or UDP application, pros and cons?

Hi,

There are many ways to implement SFCs. However, one of our goals in standard
is to develop a solution that is simple and less cost for venders and
service providers.  Other goals are that the solution can apply to common
and majority use cases. 

If we implement SFC as an IP or UDP/IP application, i.e. once traffic is
classified by the classification, it adds SFC header and IP header (outer)
on the packets (UDP header too in latter case), and send such packets as a
regular IP packet. The src IP of outer header can be classification IP
address, and dst IP can be next SF Instance IP address. Many transport
networks can carry IP traffic and route IP packets based on dst IP address.
We only need to request a new IP protocol type for SFC. At the service
forwarder point, it can look up next SF IP address based on Path ID in SFC
header and src IP address (previous SF) on the packet.  A SF also forwards
the packet with SFC header as an IP packet and fills its IP address as src
IP and the service forwarder point IP address as the dst IP on the packet. 

This solution seems simple to me and only need Path ID in SFC header for
steering traffic through the SFC path. But like to see others’ opinion on
this solution, pros and cons.

Thanks,

Lucy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Mar 2014 00:34:01 -0400

If the world were strictly layered, and we were confined to obedience to 
those layers, then your statement would be true.

But, for example, if the transport uses MPLS that can easily pass 
through many routers, even though we consider MPLS to be layer 2.5.
Even if the transport were VLAN based, one could arrange for it to pass 
through multiple routers, in parallel with and not disrupting normal IP 
routing.

Layering is a descriptive tool.  We need not treat it as a straight-jacket.

Yours,
Joel

On 3/28/14, 8:58 PM, Changcheng Huang wrote:
> In order to make SFC independent from the transport, the transport must
> be at higher layer. If, for example, the transport is at Layer 2, any
> router on the path will terminate the Chain ID. Therefore where the
> transport is located does matter.
>
> Chang

---

From: "Changcheng Huang" <[email-masked]>
Date: Sat, 29 Mar 2014 17:59:35 +0900

MPLS can pass many MPLS switches, but not routers.

Chang

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Saturday, March 29, 2014 1:34 PM
To: [email-masked]; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

But, for example, if the transport uses MPLS that can easily pass through
many routers, even though we consider MPLS to be layer 2.5.
Even if the transport were VLAN based, one could arrange for it to pass
through multiple routers, in parallel with and not disrupting normal IP
routing.

Yours,
Joel

On 3/28/14, 8:58 PM, Changcheng Huang wrote:
> In order to make SFC independent from the transport, the transport 
> must be at higher layer. If, for example, the transport is at Layer 2, 
> any router on the path will terminate the Chain ID. Therefore where 
> the transport is located does matter.
>
> Chang

---

From: "Zarny, Myo" <[email-masked]>
Date: Sat, 29 Mar 2014 18:24:15 -0400

Hi Chang,

I agree that “where transport is located does matter”. You can certainly make a strong case that placing the SFC info (through use of an SF header) at higher layers is more preferable (especially in the beginning when most devices in the network won’t understand SFC). But I’m not sure we need to mandate that the header “MUST” be at a particular higher layer and forgo other layers. That precludes the possibility of lower layer devices like switches and routers understanding SFC in the future.

IMO, we don’t need to conflate the job of the SFC header (which is to inform SF forwarding nodes) and that of transport (which is to carry SFC headers). Of course, being transport independent doesn’t mean every possible SFC header placement makes sense (at this point or ever.) We could and should make recommendations as to which transport mechanisms are more preferable for what reasons. But I see them as implementation best practices, not those that need to be codified into an SF header standard and preclude other implementation possibilities forever. Wouldn’t you agree?

Regards,

From: sfc [mailto:[email-masked]] On Behalf Of Changcheng Huang
Sent: 28 March 2014 8:58 PM
To: 'Ron Parker'; 'Lucy yong'; 'Nicolas BOUTHORS'; [email-masked]
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

In order to make SFC independent from the transport, the transport must be at higher layer. If, for example, the transport is at Layer 2, any router on the path will terminate the Chain ID. Therefore where the transport is located does matter.

Chang

Hi, Lucy.

   Ron

Hello Lucy,

Thanks,
Lucy

Nicolas

   Network configration:

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Ron Parker <[email-masked]>
Date: Sat, 29 Mar 2014 22:41:51 +0000

Myo,

I agree that this does not need to be codified.   If there is a desire, for example, to use a layer 2 transport encapsulation, then clearly the involved nodes must be on the same layer 2 network.

   Ron

________________________________
From: Zarny, Myo [[email-masked]]
Sent: Saturday, March 29, 2014 6:24 PM
To: [email-masked]'; Ron Parker; 'Lucy yong'; 'Nicolas BOUTHORS'; [email-masked]'
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Chang,

Regards,

Chang

Hi, Lucy.

   Ron

Hello Lucy,

Thanks,
Lucy

Nicolas

   Network configration:

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: "Changcheng Huang" <[email-masked]>
Date: Sun, 30 Mar 2014 08:51:26 +0900

I agree with your comments. 

Chang

From: sfc [mailto:[email-masked]] On Behalf Of Zarny, Myo
Sent: Sunday, March 30, 2014 7:24 AM
To: [email-masked]'; 'Ron Parker'; 'Lucy yong'; 'Nicolas BOUTHORS';
[email-masked]'
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Chang,

I agree that “where transport is located does matter”. You can certainly
make a strong case that placing the SFC info (through use of an SF header)
at higher layers is more preferable (especially in the beginning when most
devices in the network won’t understand SFC). But I’m not sure we need to
mandate that the header “MUST” be at a particular higher layer and forgo
other layers. That precludes the possibility of lower layer devices like
switches and routers understanding SFC in the future.

IMO, we don’t need to conflate the job of the SFC header (which is to
inform SF forwarding nodes) and that of transport (which is to carry SFC
headers). Of course, being transport independent doesn’t mean every
possible SFC header placement makes sense (at this point or ever.) We could
and should make recommendations as to which transport mechanisms are more
preferable for what reasons. But I see them as implementation best
practices, not those that need to be codified into an SF header standard and
preclude other implementation possibilities forever. Wouldn’t you agree?

Regards,

Chang

Hi, Lucy.

   Ron

 

Hello Lucy, 

Thanks,

Lucy

 

Nicolas

 

   Network configration:

  _____  

Hi Ron,

Thanks,

Lucy 

Lucy.

    Ron

Ron,

Thanks,

Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,

Lucy

    Ron

Hi Ron,

Lucy,

Thanks,

Lucy

   Ron

Hi Ron,

Regards,

Lucy 

Xiaohu,

   Ron

 

Lucy, 

Best regards,

Xiaohu

   Ron

  _____  

Hi Reinaldo,

See inline below.

Hi,

 

[Lucy] Agree.

Regards,

Lucy

regards, 

Reinaldo 

Hi Dave,

Lucy 

 

Lucy

 

Hi,

Thanks,

Lucy

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sun, 30 Mar 2014 03:15:03 +0000

Where every header is located always matters, no question about that.

Primary purpose of SFC is to chain SFs whether they are L2 or L3 hop away, on a service overlay. What that overlay technology is, does not matter, as long as that overlay supports conveying the SFC Header. I don't see any reason to express preference of one overlay technology over another – it is up to the vendors and operators to determine what suits them best. What certainly matters to us (SFC) is, compatibility with as many overlay technologies as possible.

SFs have been built to operate in a  certain fashion today and I certainly hope, with the focus in this WG, SFs will be built differently to take advantage of SFC and not for the the legacy mode of deployment and operation. And please don't underestimate L2 as it has its benefits given how virtual access layer has become the edge of the network today, although not the only example.

Rgds,
Surendra.

From: <Zarny>, Myo <[email-masked]<mailto:[email-masked]>>
Date: Saturday, March 29, 2014 3:24 PM
To: "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>, 'Ron Parker' <[email-masked]<mailto:[email-masked]>>, 'Lucy yong' <[email-masked]<mailto:[email-masked]>>, 'Nicolas BOUTHORS' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Chang,

Regards,

From: sfc [mailto:[email-masked]] On Behalf Of Changcheng Huang
Sent: 28 March 2014 8:58 PM
To: 'Ron Parker'; 'Lucy yong'; 'Nicolas BOUTHORS'; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Chang

Hi, Lucy.

   Ron

Hello Lucy,

Thanks,
Lucy

Nicolas

   Network configration:

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: "Zarny, Myo" <[email-masked]>
Date: Mon, 31 Mar 2014 10:38:35 -0400

Well said.

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: 29 March 2014 11:15 PM
To: Zarny, Myo [Tech]; [email-masked]'; 'Ron Parker'; 'Lucy yong'; 'Nicolas BOUTHORS'; [email-masked]'
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Rgds,
Surendra.

Hi Chang,

Regards,

Chang

Hi, Lucy.

   Ron

Hello Lucy,

Thanks,
Lucy

Nicolas

   Network configration:

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Mon, 31 Mar 2014 15:25:28 +0000

Myo,

The reason is to make SFC as an IP application. (as it was titled in the subject) regardless which transport used to carry this application. People see that mandates IP as transport, I don’t.  SFC is just an IP application and use IP function.

The subject of this mail is to solicit the pros and cons for this approach. Share my views on pros and cons.

Pros:

·         SFC implementation is independent on what transport is used

·         SFC implementation can leverage IP functions directly, which makes SFC header simpler and the solution simper as well.

·         Many overlay technologies is built over IP and can be benefit from.

·         Leverage application centric architecture, easy to integrate and use controller/orchestration based management

Cons:

·         more overhead in packet (SFC header + IP header)  than using SFC header only although the header space is less than one in SFC header only . Consume more data plane resources

I would like to hear other input on the pros and cons.

Regards,
Lucy

From: sfc [mailto:[email-masked]] On Behalf Of Zarny, Myo
Sent: Friday, March 28, 2014 4:59 PM
To: Lucy yong; 'Jim Guichard (jguichar)'; 'Ron Parker'; 'Nicolas BOUTHORS'; [email-masked]'
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Hi Lucy,

Regards,

From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: 28 March 2014 5:01 PM
To: Jim Guichard (jguichar); Ron Parker; Nicolas BOUTHORS; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

My 2 cent:

                   |      Original Payload    |

                   |      SFC Header          |

                   |   Transport header       |

                   |      Original Payload    |

                   |      SFC Header          |

                   |       IP Header          |

                   |   Transport header       |

Thanks,
Lucy

Folks,

Ron,

Please see inline.

Hi, Lucy.

Lucy

   Ron

Hello Lucy,

Thanks,
Lucy

Nicolas

   Network configration:

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: Lucy yong <[email-masked]>
Date: Mon, 31 Mar 2014 15:57:39 +0000

Please see inline below.

From: Surendra Kumar (smkumar) [mailto:[email-masked]]
Sent: Saturday, March 29, 2014 10:15 PM
To: Zarny, Myo; [email-masked]'; 'Ron Parker'; Lucy yong; 'Nicolas BOUTHORS'; [email-masked]'
Subject: Re: [sfc] SFC as an IP or UDP application, pros and cons?

Primary purpose of SFC is to chain SFs whether they are L2 or L3 hop away, on a service overlay.
[Lucy] good point! It is regardless what type of original traffic (L2 or L3) and regardless what underlay transport is used. The question is what is the incentive for the service overlay to support both L2 and L3 hop away? What use case you want to use as L2 hop away and what as L3 hop way? From SFC graph, we can’t see or it does not matter. Like to operator opinion on this.
 What that overlay technology is, does not matter, as long as that overlay supports conveying the SFC Header.
[Lucy] don’t know what you mean here. The service overlay relies on the SFC header or the SFC header + IP header (I proposed) to achieve it. In other words, IMO: SFC is about to implement an overlay technology for this special purpose. Of course, it may work with other overlay technologies in some use cases such as NVO3.
I don't see any reason to express preference of one overlay technology over another – it is up to the vendors and operators to determine what suits them best. What certainly matters to us (SFC) is, compatibility with as many overlay technologies as possible.
[Lucy] this is not my point. Good way to put is: SFC as any transport application or SFC as IP application.

SFs have been built to operate in a  certain fashion today and I certainly hope, with the focus in this WG, SFs will be built differently to take advantage of SFC and not for the the legacy mode of deployment and operation. And please don't underestimate L2 as it has its benefits given how virtual access layer has become the edge of the network today, although not the only example.
[Lucy] not sure how that relevant to this discussion? Please give an example that the service overlay is better to be implemented that SF are L2 hops than L3 hops away.

Thanks,
Lucy

Rgds,
Surendra.

Hi Chang,

Regards,

Chang

Hi, Lucy.

   Ron

Hello Lucy,

Thanks,
Lucy

Nicolas

   Network configration:

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy

---

From: "Zarny, Myo" <[email-masked]>
Date: Mon, 31 Mar 2014 18:09:35 -0400

Hi Lucy,

As already mentioned by others on this thread, SFC and transport (which, to me, includes IP and UDP) shouldn’t be tied together. “SFC as an IP application” can be construed as ruling out other transport mechanisms.

Please see my comments in red below.

Regards,

From: Lucy yong [mailto:[email-masked]]
Sent: 31 March 2014 11:25 AM
To: Zarny, Myo [Tech]; 'Jim Guichard (jguichar)'; 'Ron Parker'; 'Nicolas BOUTHORS'; [email-masked]'
Subject: RE: [sfc] SFC as an IP or UDP application, pros and cons?

Myo,

Pros:

·         SFC implementation is independent on what transport is used
MZ:  May I ask again what your definition of transport is? (I posed the question earlier.) By saying “SFC as an IP application”, to someone like me who thinks IP as transport, you’re requiring IP transport alone—hence the solution isn’t transport independent.

·         SFC implementation can leverage IP functions directly, which makes SFC header simpler and the solution simper as well.
MZ:  You’ll have to show that benefits of a simpler SFC header by tying it to IP outweigh the benefits of shutting out other transport mechanisms.

·         Leverage application centric architecture, easy to integrate and use controller/orchestration based management
MZ:  Please explain the above two points. At this point, I don’t see what they have to do with the discussion at hand.

Cons:

Regards,
Lucy

Hi Lucy,

Regards,

My 2 cent:

                   |      Original Payload    |

                   |      SFC Header          |

                   |   Transport header       |

                   |      Original Payload    |

                   |      SFC Header          |

                   |       IP Header          |

                   |   Transport header       |

Thanks,
Lucy

Folks,

Ron,

Please see inline.

Hi, Lucy.

Lucy

   Ron

Hello Lucy,

Thanks,
Lucy

Nicolas

   Network configration:

Thanks,
Lucy

Lucy.

    Ron

Ron,

Thanks,
Lucy

Lucy,

   Ron

Ron,

Lucy,

Thanks,
Lucy

    Ron

Hi Ron,

Lucy,

Thanks,
Lucy

   Ron

Hi Ron,

Regards,
Lucy

Xiaohu,

   Ron

Lucy,

Best regards,
Xiaohu

   Ron

See inline below.

Hi,

Regards,
Lucy

regards,

Reinaldo

Hi Dave,

Lucy

Lucy

Hi,

Thanks,
Lucy