Service Function Chaining
charter-ietf-sfc-02

Added milestone "Submit to IESG Informational documents specifying the format of MD-type 1 metadata in DC and Broadband environments", due December 2018, from current group milestones

Added milestone "Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining", due April 2014, from current group milestones

[Ballot comment]
MD-1 is explained (as fixed-length), but MD-2 is not explained in this charter.

I'm not sure who is responsible for the determining in this text:

"What can be effectively provided, for which scenarios,
and how those tools can be provided need to be determined and the tools
standardized."

Could you rephrase this as active voice?

Thank you for including Transport Considerations at the charter level.

Should it be obvious to me why the first deliverable is a base set of MD-2 type codes, with MD-1 type codes being pushed off to other drafts? Is there more to this than "we're just going to do variable length to get started"?

Is "active, passive, and hybrid OAM" related to the work in IPPM? If so, probably worth adding them to the "will coordinate with" list.

[Ballot comment]
Would it be reasonable to add a focus on privacy considerations, either as part of item 2), or as a separate top-level item?

Update: I also mildly prefer external review.

[Ballot comment]
Building off of the discussion in Ben's ballot thread, I would suggest something like this for focus area #2:

2) Security and privacy - Mechanisms and guidance for securing metadata via authentication, integrity protection, confidentiality, and data minimization are not yet defined.  What can be effectively provided, for which scenarios, and how those tools can be provided need to be determined and the tools standardized.

[Ballot comment]
Please add a short description of MD-2, or a reference.

I would like to see milestones before approval of the updated charter.

I agree with Adam on the need for External Review.

[Ballot comment]
I'm not blocking this charter, but it needs some improvements before being ready.

-
The focus of the SFC working group moving forward will be on aspects of the
architecture and/or protocol that need to be addressed to enable effective
deployment and usage of this work. In order to maintain focus, the working
group will primarily produce and advance documents on four topics:

No need to use the future tense.
Once posted, present tense is fine

-
"1) Metadata - Define the common type-length-value encoded metadata types with
Standards Track RFCs"
Typically, the document types are mentioned at the bottom of the charter, in the milestones.

ex: Aug 2015  Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation

Or maybe you want to specifically draw attention to "Standard Track" in the charter text?


- From the old charter:
5. Manageability: Work on the management and configuration of SFC
  components related to the support of Service Function Chaining will
  certainly be needed, but first needs to be better understood and
  scoped.

Do I understand that this paragraph changed into:
3) OAM and O&M - In order for operators to use these tools in production
networks, they need Operations, Administration, and Maintenance tools, as well
as management mechanisms.  This includes YANG models, OAM frameworks, and
specific OAM mechanisms to address operational needs.

-
3) OAM and O&M - In order for operators to use these tools in production
networks, they need Operations, Administration, and Maintenance tools, as well
as management mechanisms.  This includes YANG models, OAM frameworks, and
specific OAM mechanisms to address operational needs.

The OAM work should be based on LIME? If yes, please mention it.
Btw, extend O&M

-
3. YANG models for the SFC Components.

Proposal:
3. YANG models for the management of SFC Components.

Are you missing OAM in there? I see point 5 and 6 that concern OAM documents, but no YANG models.

[Ballot comment]
I'm really excited about the addition of a standards-track security deliverable for SFC.

The ballot question is unclear about whether we're being asked to approve for external review or approval without external review. If it were clearly the former, I'd be balloting "yes" to show additional support for the security deliverable addition. If we are being asked the latter question, I feel that the changes in here are substantial enough to warrant external review, but not enough that I'd stand in the way of moving forward.

I support Ben's comment.

[Ballot comment]
Thanks for the charter work item on security.  The earlier description looks good, I'm glad to see integrity included as one of the controls to be explored.  It would be nice to see a more descriptive work item later in the charter than what's currently listed.  What are the ideas for this specific work item?

Thanks!

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot block]
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.

[Ballot block]
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.

[Ballot block]
I don't object to this work happening. Please consider this to be the BLOCK equivalent of a "DISCUSS DISCUSS" ...

I sent the following comment on the Internal Review ballot, but wasn't on the call at that telechat, and didn't get a chance to talk with Adrian at the ITAT workshop, and we haven't talked about it on e-mail, and Adrian's not on the telechat where we're balloting it for approval, and if there's not a BLOCK, the charter will be approved on the call ...

It looks (from the draft narrative minutes) like the 12/05 telechat discussion was about which area the work belonged in, as one unit of work, seeking to find the area that was least wrong. Because my question was about whether it could usefully be two units of work, I'd like to talk about it, before the working group is chartered, because talking afterwards will be awkward.

Comment from Internal Review ballot:

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 topics like this 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.

[Ballot block]
I don't object to this work happening. Please consider this to be the BLOCK equivalent of a "DISCUSS DISCUSS" ...

I sent the following comment on the Internal Review ballot, but wasn't on the call at that telechat, and didn't get a chance to talk with Adrian at the ITAT workshop, and we haven't talked about it on e-mail, and Adrian's not on the telechat where we're balloting it for approval, and if there's not a BLOCK, the charter will be approved on the call ...

It looks (from the draft narrative minutes) like the 12/05 telechat discussion was about which area the work belonged in, as one unit of work, seeking to find the area that was least wrong. Because my question was about whether it could usefully be two units of work, I'd like to talk about it, before the working group is chartered, because talking afterwards will be awkward.

Comment from Internal Review ballot:

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 topics like this 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 proposed for SFC, I'm just asking about the proposed organization ...

[Ballot block]
I don't object to this work happening. Please consider this to be the BLOCK equivalent of a "DISCUSS DISCUSS" ...

I sent the following comment on the Internal Review ballot, but wasn't on the call at that telechat, and didn't get a chance to talk with Adrian at the ITAT workshop, and we haven't talked about it on e-mail, and Adrian's not on the telechat where we're balloting it for approval, and if there's not a BLOCK, the charter will be approved on the call ...

It looks (from the draft narrative minutes) like the 12/05 telechat discussion was about which area the work belonged in, as one unit of work. Because my question was about whether it could usefully be two units of work, I'd like to talk about it, before the working group is chartered, because talking afterwards will be awkward.

Comment from Internal Review ballot:

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 topics like this 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 ...

[Ballot comment]
I would like to discuss during the telechat/by mail where this WG-to-be should find its home, as many work items are not routing related, but are service related.

[Ballot block]
[Update of the update...based on the changed charter (version -00-10)]

Thanks for addressing my concern about item 3 (Generic SFC Encapsulation)


Here is my text proposal about the identifier issue, now much narrower:

"The WG will examine existing identifier schemes, if there is a
a need for such identifiers in the context of the Generic SFC
encapsulation, before defining any new identifier scheme."

[Ballot block]
[Updated after the changed charter (version -00-10)]

Thanks for addressing my concern about item 3 (Generic SFC Encapsulation)


Here is my text proposal about the identifier issue:

"The WG will examine existing identifier schemes, if there is a
a need for such identifiers for the steering of packets to the
service functions in the service chain, before defining any new
identifier scheme."

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]

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.

[Ballot comment]
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 ...

[Ballot block]
[Updated with a text proposal and also the comments part, plus Erik Nordmark's concerns about 'locators']

I have no general objection to the charter and the chartering of the SFC WG, but the item no 3 about Generic SFC Encapsulation makes me nervous.

From the charter:
  " This document will describe a single
  service-level data plane encapsulation format for conveying the
  service function chain and the service function path, and for
  communicating context information between nodes that implement
  service functions and service function chains."

This essentially means an overload of the encapsulation with these functions:
- data plane encapsulation with information about the service function chain (the abstract view)

- data plane encapsulation with information about the service function path (the instantiation of the SFC)

- and further unspecified context information to be exchanged between nodes.

This sounds to me like to what's called in Germany "Eierlegende Wollmilchsau" [1], i.e., a single animal that gives you eggs, milk, pork meat and wool.

Here is my text proposal to fix item 3:
***********************************************************************************
3. Generic SFC Encapsulation: This document will describe a single
  service-level data plane encapsulation format for conveying

  information on identifying a particular service chain, specifying
  the service path through the service functions, and for
  communicating context information between nodes that implement
  service functions.


  It is intended that
  the encapsulation format be agnostic to the layer at which it is
  applied and the service that is being constructed. That is, the same
  encapsulation may be used on a service function chain applied at
  the network layer or at any other layer, and the same encapsulation
  format will apply for the construction of service function paths
  regardless of the actual service. The working group will consider
  using an existing encapsulation (with extensions as appropriate) if
  a suitable candidate can be found.
***********************************************************************************

Here is Erik's concern/proposed text about any new identifier ('locator'):
"If there is a need for locators for the steering of packets to the service functions in the service chain, then the WG should (?) reuse some existing (set of) mechanism."



[1] http://en.wiktionary.org/wiki/eierlegende_Wollmilchsau

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot block]
[Updated with a text proposal and also the comments part]

I have no general objection to the charter and the chartering of the SFC WG, but the item no 3 about Generic SFC Encapsulation makes me nervous.

From the charter:
  " This document will describe a single
  service-level data plane encapsulation format for conveying the
  service function chain and the service function path, and for
  communicating context information between nodes that implement
  service functions and service function chains."

This essentially means an overload of the encapsulation with these functions:
- data plane encapsulation with information about the service function chain (the abstract view)

- data plane encapsulation with information about the service function path (the instantiation of the SFC)

- and further unspecified context information to be exchanged between nodes.

This sounds to me like to what's called in Germany "Eierlegende Wollmilchsau" [1], i.e., a single animal that gives you eggs, milk, pork meat and wool.

Here is my text proposal to fix item 3:
***********************************************************************************
3. Generic SFC Encapsulation: This document will describe a single
  service-level data plane encapsulation format for conveying

  information on identifying a particular service chain, specifying
  the service path through the service functions, and for
  communicating context information between nodes that implement
  service functions.


  It is intended that
  the encapsulation format be agnostic to the layer at which it is
  applied and the service that is being constructed. That is, the same
  encapsulation may be used on a service function chain applied at
  the network layer or at any other layer, and the same encapsulation
  format will apply for the construction of service function paths
  regardless of the actual service. The working group will consider
  using an existing encapsulation (with extensions as appropriate) if
  a suitable candidate can be found.
***********************************************************************************


[1] http://en.wiktionary.org/wiki/eierlegende_Wollmilchsau

[Ballot comment]
I would like to discuss during the telechat where this WG-to-be should find its home, as many work items are not routing related, but are service related.

[Ballot block]
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.

[Ballot comment]
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?

[Ballot comment]
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

[Ballot block]
I have no general objection to the charter and the chartering of the SFC WG, but the item no 3 about Generic SFC Encapsulation makes me nervous.

From the charter:
  " This document will describe a single
  service-level data plane encapsulation format for conveying the
  service function chain and the service function path, and for
  communicating context information between nodes that implement
  service functions and service function chains."

This essentially means an overload of the encapsulation with these functions:
- data plane encapsulation with information about the service function chain (the abstract view)

- data plane encapsulation with information about the service function path (the instantiation of the SFC)

- and further unspecified context information to be exchanged between nodes.

This sounds to me like to what's called in Germany "Eierlegende Wollmilchsau" [1], i.e., a single animal that gives you eggs, milk, pork meat and wool.

[1] http://en.wiktionary.org/wiki/eierlegende_Wollmilchsau

[Ballot block]
I have no general objection to the charter and the chartering of the SFC WG, but the item no 3 about Generic SFC Encapsulation makes me nervous.

From the charter:
  " This document will describe a single
  service-level data plane encapsulation format for conveying the
  service function chain and the service function path, and for
  communicating context information between nodes that implement
  service functions and service function chains."

This essentially means an overload of the encapsulation with these functions:
- data plane encapsulation with information about the service function chain (the abstract view)
- data plane encapsulation with information about the service function path (the instantiation of the SFC)
- and further unspecified context information to be exchanged between nodes.

This sounds to me like to what's called in Germany "Eierlegende Wollmilchsau" [1], i.e., a single animal that gives you eggs, milk, pork meat and wool.

[1] http://en.wiktionary.org/wiki/eierlegende_Wollmilchsau

[Ballot comment]
Let me also support Jari's point that existing encapsulations should be considered.

A clarifying question about item no. 3 "Generic SFC Encapsulation":

Do I understand correctly that this generic encapsulation can be used within existing tunnels? For instance running GRE (or whatever) and to push this Generic SFC Encapsulation in front of the data running through the tunnel.

[Ballot comment]
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.

Changed charter milestone "Submit to IESG requirements for a generic service function chaining encapsulation protocol", set description to "Informational document defining the control plane requirements for conveying information between control or management elements and SFC implementation points"

Changed charter milestone "Consult with OPS Area on possible charter modifications for management and configuration of SFC components", set description to "Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining", set due date to April 2014 from May 2014

Changed charter milestone "Submit to IESG Informational document(s) defining the problem statement and core use cases for Service Function Chaining", set description to "Submit to IESG Information document defining the SFC problem statement and core use cases"

Changed charter milestone "Request the IESG for publication of Informational documents specifying control plane requirements in support of specific SFC use cases. ", set description to "Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation", set due date to August 2015 from January 2013

Changed charter milestone "Request the IESG for publication of a Standards Track document specifying the generic service function chaining encapsulation protocol.", set description to "Submit to IESG requirements for a generic service function chaining encapsulation protocol", set due date to January 2015 from January 2013

Changed charter milestone "Request the IESG for publication of Informational documents defining the architecture for SFC and describing the framework and requirements for a generic service function chaining encapsulation protocol. ", set description to "Submit to IESG Informational document defining the architecture for SFC", set due date to January 2015 from January 2013

Changed charter milestone "Request the IESG for publication of an Informational document defining the problem statement and core use cases for Service Function Chaining ", set description to "Submit to IESG Informational document(s) defining the problem statement and core use cases for Service Function Chaining", set due date to April 2014 from January 2013

Deleted charter milestone "Request the IESG for publication of Informational applicability documents defining how the protocol elements developed by the WG may be combined with other IETF protocols to satisfy the use cases. "

Deleted charter milestone "Request the IESG for publication of an Informational document defining SFC manageability including diagnostics, and MIB and YANG information/data models to IESG ."

Added charter milestone "Request the IESG for publication of Informational applicability documents defining how the protocol elements developed by the WG may be combined with other IETF protocols to satisfy the use cases. ", due January 2013

Added charter milestone "Request the IESG for publication of an Informational document defining SFC manageability including diagnostics, and MIB and YANG information/data models to IESG .", due January 2013

Added charter milestone "Request the IESG for publication of Informational documents specifying control plane requirements in support of specific SFC use cases. ", due January 2013

Added charter milestone "Request the IESG for publication of Informational documents defining the architecture for SFC and describing the framework and requirements for a generic service function chaining encapsulation protocol. ", due January 2013

Added charter milestone "Request the IESG for publication of an Informational document defining the problem statement and core use cases for Service Function Chaining ", due January 2013