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

[<[e-mail]>]

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:[e-mail]] De la part de Reinaldo Penno (repenno)
Envoyé : mardi 25 mars 2014 22:56
À : Lucy yong; Dave Dolson; [e-mail]
Objet : 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).

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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, March 25, 2014 at 2:25 PM
To: Dave Dolson <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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:[e-mail]]
Sent: Tuesday, March 25, 2014 4:10 PM
To: Lucy yong; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Tuesday, March 25, 2014 4:56 PM
To: Dave Dolson; [e-mail]<mailto:[e-mail]>
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:[e-mail]]
Sent: Tuesday, March 25, 2014 3:21 PM
To: Lucy yong; [e-mail]<mailto:[e-mail]>
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:[e-mail]] On Behalf Of Lucy yong
Sent: Tuesday, March 25, 2014 4:02 PM
To: [e-mail]<mailto:[e-mail]>
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 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