Service Function Chaining (sfc)
|WG||Name||Service Function Chaining|
|Area||Routing Area (rtg)|
|Additional resources||Issue tracker, Wiki, Zulip Stream|
|Personnel||Chairs||Jim Guichard, Joel M. Halpern|
|Area Director||Andrew Alston|
|Liaison Contacts||Jim Guichard, Joel M. Halpern|
|Jabber chat||Room address||xmpp:firstname.lastname@example.org?join|
Charter for Working Group
Network operators frequently utilize service functions such as packet filtering at firewalls, load-balancing and transactional proxies (for example spam filters) in the delivery of services to end users. Delivery of these types of services is undergoing significant change with the introduction of virtualization, network overlays, and orchestration.
The SFC Working Group has developed an Architecture [RFC 7665] and the Network Service Header [RFC 8300] for service function chaining.
The focus of the SFC working group moving forward is 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 primarily produces and advances documents on four topics:
1) Metadata - Define the common type-length-value encoded metadata types with Standards Track RFCs, and produce Informational RFCs to describe common fixed-length (MD-1) metadata usages.
2) Security and Privacy - Mechanisms and guidance for securing metadata via authentication, integrity protection, confidentiality, and/or 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.
3) OAM and Operations & Management - 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.
4) Transport Considerations - This will capture the expectations SFC places on transport behavior, including dealing with issues such as congestion indications and responses. This should define how NSH works on standardized transports that are expected to see widespread use.
Specifically, the SFC WG is chartered to deliver the following:
1. A Standards Track base set of the metadata MD-2 type codes within the metadata class reserved for IETF usage, as specified in RFC 8300.
2. Related Metadata drafts that require more explanation than is reasonable to include in the base MD-2 draft, including MD-1 descriptions and items done once the base draft is complete.
3. YANG models for the management of SFC Components.
4. One or more security related Standards Track and / or Informational RFCs. At least one Standards Track security mechanism RFC is needed.
5. OAM Framework document to provide a common basis for OAM work. This draft will include guidance on how active, passive, and hybrid OAM are to be supported if at all.
6. Specific OAM mechanism documents to provide the tools needed for operational environments.
7. Transport Considerations RFC to cover the expectations SFC and NSH place on transport, and the operational constraints transports used by NSH need to meet.
The SFC WG may work on Informational applicability documents that show how the technology, meta-data, and associated control-plane mechanisms can be used in specific use-cases. The SFC WG may work on Informational documents that provide operational considerations.
The SFC WG will coordinate with BESS and PCE on the control-plane work related to SFC.
|Jul 2019||Informational document defining transport considerations applicable to SFC|
|Jul 2019||Submit to IESG Informational document defining authentication, integrity protection, and confidentiality of SFC metadata|
|Mar 2019||YANG models for SFF and classifier|
|Dec 2018||Submit to IESG Standards Track document specifying MD-type 2 metadata formats|
|Dec 2018||Submit to IESG Informational documents specifying the format of MD-type 1 metadata in DC and Broadband environments|
|Oct 2018||Informational document defining the Operation, Administration and Maintenance (OAM) framework for SFC|
|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|