Re: [sfc] SFC WG re-chartering - initial text for WG review/comment

["Trossen, Dirk" <[e-mail]>]

Ramin, all,

Flexible chaining is also essential if the goal is to guarantee some QoS metric, e.g. end-to-end, latency, for the traffic, particularly in edge environments. A reference to ongoing efforts in this space can be found in the ongoing H2020 efforts FLAME (see https://www.ict-flame.eu/). These efforts are driven by city-scale many-POP deployments of compute infrastructure, all SDN-connected and OpenStack managed. Localized media use cases drive the need for name-based (HTTP as the main transport protocol here) service instances being chained with the relationship between specific virtual instances being controlled at the underlying routing/switching level. First trials at city scale are planned for mid 2018.

Best,

Dirk


From: Ramin Khalili <[e-mail]>
Sent: 22 December 2017 10:44 AM
To: Trossen, Dirk; James N Guichard; 'Service Function Chaining IETF list'
Cc: Alia Atlas
Subject: RE: SFC WG re-chartering - initial text for WG review/comment
  

Dirk, James,
 
These are excellent points. I support them. 
 
The chaining should be optimized to reduce the initial request latency. Flexible chaining is also necessary if the goal is to guarantee some  QoS metric, e.g. end-to-end, latency, for the traffic.  These two properties are essential for latency sensitive traffics, such as URLLC (Ultra Reliable Low Latency) defined by 3GPP standardization. Currently, there is no specific discussion regarding these  requirements within the WG and hence I found them important for the new charter.
 
Regards,
Ramin. 
 
 


From: sfc [mailto:[e-mail]] On Behalf Of Trossen, Dirk
Sent: Thursday, December 21, 2017 10:58 AM
To: James N Guichard <[e-mail]>; 'Service Function Chaining IETF list' <[e-mail]>
Cc: Alia Atlas <[e-mail]>
Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment
   


James, all,
 
 
 
Thanks for this excellent start for the planned re-chartering. I'd would like to pick on this, particularly on the fourth topic (transport considerations), and propose  two specific topics for a new charter:
 
 
 
Optimized chaining: this extends on the proposed fourth topic (which I support) by incorporating feedback, such as congestion indications, from transport networks  as well as the (possibly virtualized) service instances along the SFP. Hence, this topic is about optimized control for the construction and re-chaining of SFPs where the ‘data points’ for the decision making can come from above or below the SFC delivery mechanism.

Flexible chaining: this proposed topic extends the previous item in that it builds on the desire to flexibly re-chain SFCs, particularly in situations where virtualized service instances exist and dynamic decisions are being taken for such re-chaining between  such virtualized instances. Such flexibility could be achieved by raising the abstraction level of the SFP from layer2/3 to that of a name-based service where the SF endpoint is being provided as a name rather than a MAC or IP address. With that, the name-based  SFP remains the same even if changes in the currently used virtualized service instances occur, bringing SFC closer to data centre networking and many of the associated scenarios.
 
 
 
What drives the need for such optimization and flexibility? Virtualization of service instances, particularly through containers,  certainly does and particular  when such virtualized service instances reside in a number of (possibly regionally) distributed micro-data centres.
 
 
 
In terms of delivery, item 1 would lead to an (informational?) RFC specifying the possible data points leading to the construction of optimized SFCs, while item  2 would lead to an RFC for a design for flexible chaining for a name-level SFP.
 
 
 
Looking forward to receiving comments on this.
 
 
 
Best,
 
 
 
Dirk
  
 


  
From: sfc <[e-mail]>  on behalf of James N Guichard <[e-mail]>
Sent: 11 December 2017 8:13 PM
To: 'Service Function Chaining IETF list'
Cc: Alia Atlas
Subject: [sfc] SFC WG re-chartering - initial text for WG review/comment 

 
  

Greetings WG:
 
Joel and I have taken an initial stab at new charter text for the SFC WG. Please review and provide comments/suggestions by COB Friday 29th December  (2 weeks).

 
  
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 a protocol (the Network Service Header [draft-ietf-sfc-nsh-28], in the RFC Editor queue as of  this drafting.)
 
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.  The SFC working group will now begin addressing those items.  In order to maintain focus, the working group will primarily produce and advance documents on four topics:
 
1) Metadata - we need to 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 - The completed work does not provide mechanisms for authenticating or protecting (either for integrity or from inspection) metadata.  There are a number  of open questions as to what can be effectively provided and how to provide such tools.  These need attention.
 
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.
 
4) Transport Considerations - this will capture the expectations SFC places on transport behavior, including dealing with issues such as congestion indications  and responses.
 
Specifically, the SFC WG is chartered to deliver the following:
 
1. A standards track base set of MD-2 type codes within the metadata class reserved for IETF usage.
 
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 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 in-situ 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.

 
  
Thanks!
 
Jim & Joel