Service Function Chaining
charter-ietf-sfc-02

Apr 2014 Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining

I applause this use of the proposed milestones!
Basically, it says: we know it's important, we don't know yet what we need, we want to find out, and because we don't want to forget, here is the reminder with a milestones. Even if the OPS AD changes, that will remain.

I have no issues with this charter going for external review, but I have a few observations.

1. Given the mention of encapsulation, what relationship does this proposed WG have with the newly formed SPRING WG?  It seems to me that SPRING's steering through a network is very similar to building a service chain.

2. I find the ordering of the work items in the charter much more reasonable/functional than the timing of the deliverables in the milestones.  Wouldn't the architecture work need to be close to completion before you start collaborating with OPS on *how* to configure and manage these service chains?

I would suggest that item three (encapsulation) should explicitly say that the format will be either defined or refer to an existing one. Not sure the invention of a new format is necessary.

converging on something ready for external review.

was:

this block is to frame the  2 points I want to see discussed it's not because I forsee something being particularly objectionable after this dicussion is had.

...

The SFC working group will document a new approach to service delivery
and operation. It will produce an architecture for service function 
chaining that includes the necessary protocols or protocol extensions to
convey the service path and service path information to nodes that are 
involved in the implementation of service functions and service function
chains, as well as mechanisms for steering traffic through service
functions. The working group will examine what information needs to be
gathered from the network and service functions in support of service 
function chaining and how that information may be made available to the
components of the service function chaining architecture. The SFC WG 
will closely consider the security implications when documenting these
deliverables.  
...

This is  a management or coordination problem in the management of multiple elements. Which I'd like to see mentioned explicitly (using the M word). The dreaded API word also comes up in this context, we're talking about programatic extension of configuration across multipe devices/device-types.

The dates on the milestones are silly. While I think the goals are fine, they imply that the authors have this stop all ready to go which I hope is not the case, because otherwise there're going to be pretty unhappy when the working group gets messy paw prints all over it. if the work were complete circa q2 2014 I'd be rather shocked.

I am fine with this going forward for external review, but a question:

We see more and more problem statement/use case documents produced, used by the WG in draft form before it ever gets published as an RFC, and then subsequently published and ignored for the rest of eternity. Is there a reason to require (or even suggest) that this WG produce as output a problem statement document? Is there an expectation that this document is desired and will have use outside of the WG? If not, I'd rather see a non-RFC-producing work item.

Is firewall filtering = packet filtering?  If so can we call it that.  I'm not entirely sure what it is that you mean by firewall filtering.

I know you're going to actually address the security implications in addition to considering them so can the charter explicitly state that :)  

  The SFC WG will consider and address the security implications
  when documenting these deliverables.

Updated to add the following:

I am reading Martin's comment about some of this work being routing-related while other work is service-related with interest, but I agree that there is routing work. So I wanted to ask whether there is any division of the work that would put the right pieces in the right places, area-wise.

It seems like when we talk about this topic with the community, we hear questions about what area is appropriate. One explanation for that might be that there are a couple of types of work in one proposed charter(*).

The answer could be "no, the work has to go in one area", but I'd rather ask before the proposed charter goes for external review, just in case the answer is "maybe".

(*) This charter isn't even _close_ to the recent record holder for stuffing work into one charter, which the then-IAB and IESG decided was proposing work that belonged in at least five IETF areas, so I'm not criticizing the collection of work in SFC, I'm just asking about the proposed organization ...

Previous comment: 

I'm also supportive of Jari's comment on whether we need another encapsulation mechanism ...

Taking Sean's comment and raising him... 

Would it be reasonable to do:

OLD:

The SFC WG 
will closely consider the security implications when documenting these
deliverables.  

NEW:

The SFC WG 
will closely consider the security and privacy implications when documenting these
deliverables.

Thanks for addressing my comments!