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

From: "Trossen, Dirk" <[email-masked]>
Date: Wed, 3 Jan 2018 11:22:30 +0000

Forgot to mention that the document at https://ict-flame.eu/wp-content/uploads/sites/3/2017/10/D3.3-FLAME-Platform-Architecture-and-Infrastructure-Specification-v1.0.pdf shows (among other things) how SFC is utilized in the mentioned EC-funded effort to realize flexible orchestration in many-POP/edge deployment scenarios.

Dirk

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Trossen, Dirk
Sent: 22 December 2017 10:51
To: Ramin Khalili <[email-masked]>; James N Guichard <[email-masked]>; 'Service Function Chaining IETF list' <[email-masked]>
Cc: Alia Atlas <[email-masked]>
Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment

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 <[email-masked]>
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:[email-masked]] On Behalf Of Trossen, Dirk
Sent: Thursday, December 21, 2017 10:58 AM
To: James N Guichard <[email-masked]>; 'Service Function Chaining IETF list' <[email-masked]>
Cc: Alia Atlas <[email-masked]>
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 <[email-masked]>  on behalf of James N Guichard <[email-masked]>
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

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 03 Jan 2018 13:40:13 +0100

Hi,
 
Thanks a lot for initiating the rechartering discussion. I fully
support the list of topics you have initially proposed. I'd like to
bring an additional one for consideration:
 
- SFC management/configuration. I think this fits into the topic 3 from
the proposed recharter (OAM and O&M), but it would be nice to keep the
door open to include configuration extensions for specific use-case
environments such as fog ones. We have been working on it, we presented
a draft a 2-3 IETFs ago and we plan to do an update for London IETF.
 
Thanks,
 
Carlos

On Mon, 2017-12-11 at 20:13 +0000, James N Guichard wrote:
> 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.
>  
> 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.
>  
> 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.
>  
> 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
>  
>  
>  
>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 5 Jan 2018 15:26:36 -0500

Feedback on this seems to have died down.  I'll work with Jim & Joel on
finalizing a charter to
bring back to the WG and then the IESG.

I hear the enthusiasm for flexible chaining - but there's still a lot of
basic work to be done.

Regards,
Alia

On Wed, Jan 3, 2018 at 7:40 AM, Carlos Jesús Bernardos Cano <[email-masked]
> wrote:

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 5 Jan 2018 13:14:47 -0800

Hi Jim and Joel,
the recent IPR disclosure by Orange <https://datatracker.ietf.org/ipr/3121/>
with the reference to SFC OAM Framework concerns me because of the RAND
condition. I think I understand where there's intersection between the IPR
and the draft but my opinion is far from authoritative on the matter.
Perhaps it is something the WG should discuss and consider in regard to #5
of the proposed charter.
Also, will note, that the date of the disclosure is rather too far, in my
opinion, from the date of filing.

Regards,
Greg

On Mon, Dec 11, 2017 at 12:13 PM, James N Guichard <
[email-masked]> wrote:

> 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).
>
>
>
>
>
> 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.
>
>
>
> 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:
>
>
>
> metadata types with standards track RFCs, and produce informational RFCs to
> describe common fixed-length (MD-1) metadata usages.
>
>
>
> 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.
>
>
>
> reasonable to include in the base MD-2 draft, including MD-1 descriptions
> and items done once the base draft is complete.
>
>
>
> 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.
>
>
>
> place on transport, and the operational constraints transports used by NSH
> need to meet.
>
>
>
>
>
> Thanks!
>
>
>
> Jim & Joel
>
>
>
>
>
>
>
>
>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sat, 6 Jan 2018 05:50:32 +0000

Hi Alia,

Just wanted to add one more point regarding the flexible chaining point for the re-charter discussions.  We have already started discussing this topic in the Singapore F2F meeting, specifically via the following draft:

https://tools.ietf.org/html/draft-purkayastha-sfc-service-indirection-01

We are planning to have an update ready for the next IETF meeting to answer some of the good questions brought up during the discussion.  We believe that this functionality will provide an important feature for the evolution of SFC, and hope that you will strongly consider incorporating it into the updated SFC charter.

Best Regards,

Akbar

From: sfc [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Friday, January 5, 2018 3:27 PM
To: [email-masked]
Cc: Service Function Chaining IETF list <[email-masked]>; James N Guichard <[email-masked]>
Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment

Feedback on this seems to have died down.  I'll work with Jim & Joel on finalizing a charter to
bring back to the WG and then the IESG.

I hear the enthusiasm for flexible chaining - but there's still a lot of basic work to be done.

Regards,
Alia

On Wed, Jan 3, 2018 at 7:40 AM, Carlos Jesús Bernardos Cano <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks,

Carlos

On Mon, 2017-12-11 at 20:13 +0000, James N Guichard wrote:
> [email-masked]<mailto:[email-masked]>

---

From: Ron Parker <[email-masked]>
Date: Sun, 7 Jan 2018 17:44:05 +0000

Hi,

Regarding draft-purkayastha-sfc-service-indirection, I whole heartedly support the proposed evolution towards rationalization of an SFP (i.e., identified by an SPI) as a sequence of named service functions rather than (or in addition to) an exact sequence of Service Function Endpoints (SFEs), as I believe the authors are proposing.   Towards this end, I suggest the authors revisit the concept of Rendered Service Path (RSP) in the SFC architecture draft.   Although draft-purkayastha does not mention RSP, it was this dual-view of the SFP that was envisioned at the time – as an exact “concrete” sequence if you wanted it to be or a more abstract sequence with “late binding”.   The means of that late binding was not developed at the time and I think your proposal is a step in that direction.

Thanks.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Saturday, January 6, 2018 12:51 AM
To: Alia Atlas <[email-masked]>
Cc: [email-masked]; James N Guichard <[email-masked]>; Service Function Chaining IETF list <[email-masked]>
Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment

Hi Alia,

Best Regards,

Akbar

From: sfc [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Friday, January 5, 2018 3:27 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Service Function Chaining IETF list <[email-masked]<mailto:[email-masked]>>; James N Guichard <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment

Regards,
Alia

Thanks,

Carlos