Service Function Chaining
charter-ietf-sfc-02

notwithstanding that I think this is fundamentally a management and coordination function rather then a routing or transport (or internet) function I think it's fine where it is. The onus is on the IETF community as a whole to make this pig fly.

I have changed to no objection, as I am still sick and won't make it to the telechat. 

As indicated in my response to Adrian, I am willing to accept what the IESG decides on where SFC is going to be chartered. 

Here is my old DISCUSS text as reference:

This is also a DISCUSS-DISCUSS, as I am worried about the direction of the discussion where to place SFC. Right now we are not discussing on a technical level, as we definitely should.

And now let's move away from meta discussions to the technical merits of having SFC in the Transport and **Services** (TSV):

1) The service functions that are to be chained are all L4 to L7 services.
TSV sits right in the middle of everything and most of the service functions are L4 (firewall, NATs, TCP optimizers, etc) or close to it, such as SIP proxies or HTTP reverse proxies. Chaining L4 to L7 stuff does not necessarily mean that somebody of L4-L7 is in charge of this, but the requirements for service chaining are imposed by those to a large extend.

2) The overlay enabling technologies can be L3VPN, MPLS, and SPRING -- but there are also a number of other technologies. For instance, something over foo over UDP, P2P, or non-IETF protocols. Those others are not on the table by now, but I wouldn't close the door for these right now. However, tunneling foo over UDP is reading to me like very much like a TSV issue as tunneling involves typically end-to-end issues, e.g., MTU issues, mapping of DSCP and ECN, etc (apart from the INT aspects). 

3) Gathering information about the network and providing this information is ALTO to me (mentioned in the charter and in one of the SFC drafts)

4) There is for sure some control protocol needed to get this working eventually. This isn't mentioned in the charter, and I can see reasons for this, but at the very end there is something needed to distributed information about service chains to the service nodes and the service functions. This is between routing (e.g., providing the forwarding information) and transport (providing further information for distinguishing flows) and has also APPs elements (e.g., the meta-data thingy about the mobile terminal type). 

5) The service header (or encapsulation header) is also about identifying the right entity at the service node to serve the data. This sounds also like transport, as this is about multiplexing and de-multiplexing at hosts. 

6) Long term:
the inter-domain case sounds very like CDNI (as TSV WG), as it is not 
only about routing the best way, but also about finding service functions on the other end and agreement on how to get them together.

On my question about whether this work belonged in one working group (so, necessarily, one area), Thomas sent a response that included this:

"Another idea, that of dividing the work into 2 or more WGs so that
each piece can go into its own area doesn't make sense to us (at least
not yet). The work doesn't split that way (since the initial focus is
on requirements and architecture and figuring out the
management/control plane work items). Perhaps later, when more
specific work is proposed, it might make sense to do that work in
other WGs. We note that the charter already covers that."

That is responsive to my question. Thank you. I'll unblock.

For what it's worth, I wasn't suggesting an arbitrary split of the work (if that had been my goal, moving the even numbered deliverables into another charter would have met my goal). 

Solomon was talking about chopping one baby in half so both mothers got part of what they were asking for; I was asking how many babies we had, before deciding who went home with the various mothers. If the answer is "one baby", I'll continue to follow the technical discussion about where the work falls with interest.

No one ever confuses me with Solomon. 

Cf. http://en.wikipedia.org/wiki/Judgment_of_Solomon.