Subject: [sfc] Question on draft-penno-sfc-yang-00

From: Nicolas BOUTHORS <[email-masked]>
Date: Wed, 5 Feb 2014 15:18:12 +0000

The model uses an IP address as a way to identify a Service Function. I assume that this address is for management and control point of view.

Otherwise it raises a couple of questions

- A service function could be reachable via different IP addresses as the traffic comes from different directions.
Would this be  in line with the specification of the service-function-chain container ?

- Also  a service function for example responsible to load balance traffic to other virtual service functions
could be best attached to a set of IP addresses on a private subnet.  So these addresses might not be usable
for say a management application to locate the service function.

So if those addresses are for management and control purposes, where should the addresses used to route the traffic fit in the model?

---

From: Ron Parker <[email-masked]>
Date: Wed, 5 Feb 2014 15:23:31 +0000

Nicolas,

I think each service function will need one or more management IP addresses.   Whether or not a service function requires IP addresses for data plane operations is dependent on the choice of transport encapsulation.   If, for example, a simple VLAN is used for transport, then no additional IP addresses are required.   However, if, for example, GRE tunnels are used for transport, then the service function will require one or more iP addresses to terminate its GRE tunnels.   In such a case, the IP addresses for GRE tunnel termination will likely be different than the management IP address.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Nicolas BOUTHORS
Sent: Wednesday, February 05, 2014 10:18 AM
To: [email-masked]
Subject: [sfc] Question on draft-penno-sfc-yang-00

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Wed, 5 Feb 2014 15:31:41 +0000

Hi Ron

I agree with you that these addresses are then for management purposes, and that there could be more than one.

The question remains of how the information model identifies the overlay addresses (IP address, Ethernet addresses) required at each step to locate the next hop. This has to be part of the configuration information,
so I would think it should be part of the model described in this draft.

Nicolas

________________________________
From: Ron Parker [[email-masked]]
Sent: Wednesday, February 05, 2014 4:23 PM
To: Nicolas BOUTHORS; [email-masked]
Subject: RE: Question on draft-penno-sfc-yang-00

Nicolas,

   Ron

---

From: Ron Parker <[email-masked]>
Date: Wed, 5 Feb 2014 15:37:20 +0000

The original concept, as I understood it, was that for data plane operations, each service function would be identified with a name (i.e., a chain of "sf-a", "sf-b", etc.).   A separate "locator table" would map the service function names to one or more transport-dependent addresses.   In my previous example, that locator could provide a VLAN for simple L2 transport, or could provide an IP address and GRE key for GRE transport, or any other transport we choose to support.

   Ron

From: Nicolas BOUTHORS [mailto:[email-masked]]
Sent: Wednesday, February 05, 2014 10:32 AM
To: Ron Parker; [email-masked]
Subject: RE: Question on draft-penno-sfc-yang-00

Hi Ron

Nicolas

To: Nicolas BOUTHORS; [email-masked]<mailto:[email-masked]>

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Nicolas BOUTHORS
Sent: Wednesday, February 05, 2014 10:18 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] Question on draft-penno-sfc-yang-00

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Wed, 5 Feb 2014 15:49:37 +0000

Good point, service-functions have a mandatory name in the model.

Looking at the model, a service-node holds a list of service-functions. The service-node also has
an ip-address field (for management?).

So we need at some point a spec for this locator table which will be shared somehow.

Nicolas
Sent: Wednesday, February 05, 2014 4:37 PM

The original concept, as I understood it, was that for data plane operations, each service function would be identified with a name (i.e., a chain of “sf-a”, “sf-b”, etc.).   A separate “locator table” would map the service function names to one or more transport-dependent addresses.   In my previous example, that locator could provide a VLAN for simple L2 transport, or could provide an IP address and GRE key for GRE transport, or any other transport we choose to support.

   Ron

Hi Ron

Nicolas

   Ron

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 5 Feb 2014 20:02:56 +0000

Hi,

Thanks for the question. There are a few things we are working on the next revision and one of them is what you brought up.

We left this out of the draft on purpose because we are discussing how to properly reference the interfaces and IP management Yang models (http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-16) (http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-12) in SFC without creating strong coupling.

We assume that each Service Function will have data plane interfaces and those will follow the models above. The idea is to enhance  the Service Function Path module and insert for each Service Function the next-hop identifier which would be  based on the above models.  If we identify we need to define something else we will do it, but at this point this is not clear.

Another change in the next revision would be addition of statistics and consequently a operational data tree.

Thanks,

Reinaldo

From: Nicolas BOUTHORS <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 5, 2014 at 7:31 AM
To: Ron Parker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Question on draft-penno-sfc-yang-00

Hi Ron

Nicolas

From: Ron Parker [[email-masked]<mailto:[email-masked]>]

Nicolas,

   Ron