Subject: [sfc] thought for the possible new requirement

From: "Jani, Nrupal" <[email-masked]>
Date: Thu, 24 Apr 2014 16:14:55 +0000

Hi there,

First of all, I want to thank this WG for putting out great RFCs capturing various requirements and usecases.

I see possibility of one additional requirement, which is either not captured or is there but not explicit, may be just the interpretation problem!!

As we know SFC domain could contain multi-vendor SFs hosted in various form factors, e.g. Virtual Machine, Linux Container, Bare-Metal or Physical Appliance.  Additionally traffic passes through the combination of SW & HW Switches, where there could be a packet loss due to various reasons.

While RFCs are calling out OAM, diagnostic and elasticity related requirements and SLA related usacases, I see a need to provide real-time effective BW for given SFC.  It can be useful for runtime provisioning of SFC instances (i.e. elasticity) of a given SFC, or to migrate SF instances to an appropriate SF node!!

For the initial thought, SF Node could be a better entity to provide real-time information of each SFC chains, given that it is the anchor point in SFC related traffic.   Or could be some other ways!!

Furthermore not related to requirement, but like TPCC perf. matrix from various server platform vendors, having upfront perf. matrix from appliance vendor for a given form factor (i.e. Virtual Machine, Linux Container, Bare-Metal or Physical Appliance) could help admin initial provisioning of a given SFC.

Thanks,

Nrupal.

---

From: <[email-masked]>
Date: Fri, 25 Apr 2014 07:59:51 +0200

Dear Nrupal,

A requirement draft I'm aware of included in a previous version this requirement (http://tools.ietf.org/html/draft-boucadair-sfc-requirements-03#page-8):

   DISC_REQ#4:  The solution SHOULD allow the dynamic discovery of
                additional information characterizing a Service
                Function, including:

                *  The capabilities of the Service Function.

                *  The capacity of the Service Function.  For example,
                   this information can refer to the maximum number of
                   binding entries that can be supported by a NAT
                   function, the maximum number of IP-in-IP tunnels that
                   can be established, the maximum link capacity, etc.

Does this text reflect what you have in mind?

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jani, Nrupal
Envoyé : jeudi 24 avril 2014 18:15
À : [email-masked]
Objet : [sfc] thought for the possible new requirement

Hi there,

Thanks,

Nrupal.

---

From: "Jani, Nrupal" <[email-masked]>
Date: Fri, 25 Apr 2014 17:14:43 +0000

Hi Med,

Yes,  this is one of the items I had in mind.  What I thinking was that info. from Service function instance alone may not be enough!! We need information at each SFC level to match the established SLA.  Given that everything is going on the physical or virtual wire, effective BW of a SFC could be one of measurable item we could present to the user.

For example SFC (FW, DPI, NAT) where these service functions are distributed in the DC.  In this case, we know that capacity of each of these SF instance but the full capacity of these functions may be used because these is CPU overcommit issue on the system where NAT virtual appliance is running or virtual switch is dropping packets or may be SF Node which coordinating interactions among the function is choking!!

I think, have a system level (which includes both the SF and other ingredients involved in the SFC) picture of each SFC could be a useful data.

Let me know what you all think!!

Thanks,

Nrupal

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, April 24, 2014 11:00 PM
To: Jani, Nrupal; [email-masked]
Subject: RE: thought for the possible new requirement

Dear Nrupal,

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jani, Nrupal
Envoyé : jeudi 24 avril 2014 18:15
À : [email-masked]<mailto:[email-masked]>
Objet : [sfc] thought for the possible new requirement

Hi there,

Thanks,

Nrupal.