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

From: James N Guichard <[email-masked]>
Date: Mon, 11 Dec 2017 20:13:07 +0000

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

---

From: Loa Andersson <[email-masked]>
Date: Tue, 12 Dec 2017 14:34:04 +0800

Jim and Joel,

This is a very good start of the new charter. I agree with the scope.
There are a few things

- it might be of interest to mention working groups you are supposed
   to cooperate with
- since there is an interest in SFC from people with a background in
   "transport" as it is understood in the ITU-T world, we should make it
   clear(er) that when we mention "transport" we are using the term as
   it is defined in IETF

/Loa
-
On 2017-12-12 04:13, 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 29^th 
> 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
> 
> 
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 13 Dec 2017 09:54:12 -0500

Jim,

For item 5, it’s unclear whether you’re discussing in-situ OAM for SFC, or
SFC as a potential in-situ OAM enabler/mechanism (or both). Perhaps that
could be made more clear.

Cheers,
Andy

On Mon, Dec 11, 2017 at 3: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
> 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.
>
>
>
> 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.
>
>
>
> 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: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Dec 2017 10:12:58 -0500

Andy, I am haing trouble following the question.

The intention of the text is to indicate that work on carrying OAM 
information along with user packets carried in SFC (in-situ OAM as part 
of SFC) is within scope for the OAM work.

I am not sure what the alternative you raise means.

Can you suggest better wording we can use?

Loosely related to this, Loa as suggested the following rewording of 
goal 3, which the chairs have agreed to:

3) OAM and 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.

(I realize that does not talk explicitly about in-situ.  This seemed a 
good hook to let the WG know of a change that was suggested.)

Yours,
Joel

On 12/13/17 9:54 AM, Andrew G. Malis wrote:
> Jim,
> 
> For item 5, it’s unclear whether you’re discussing in-situ OAM for SFC, 
> or SFC as a potential in-situ OAM enabler/mechanism (or both). Perhaps 
> that could be made more clear.
> 
> Cheers,
> Andy
> 
> 
> On Mon, Dec 11, 2017 at 3:13 PM, James N Guichard 
> <[email-masked] <mailto:[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
>     29^th 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.____
> 
>     __ __
> 
>     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.____
> 
>     __ __
> 
>     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.____
> 
>     __ __
> 
>     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____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/sfc>
> 
> 
> 
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 13 Dec 2017 09:20:05 -0600

Hi Jim and Joel,
thank you for such great start on the WG charter update. I agree with the
stated scope and goals.
The question I have is on the expected role of the SFC OAM Framework
document. There are already solution proposals, both for active and hybrid
OAM in SFC, and if the goal is to publish the SFC OAM Framework document,
that will delay progress of the solutions. Perhaps it will be more
efficient to discuss applicability of the proposed SFC OAM solutions not as
part of the framework document but when reviewing the solution.
And minor terminology clarification. In-situ OAM is an example of hybrid
OAM, per RFC 7799, the class of OAM mechanisms that the alternate marking
methods are also part of. To keep the list of goals generic I propose to
update #5 s/in-situ/hybrid/ to the following:

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.

Regards,
Greg

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

> operational environments.
>
>
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 13 Dec 2017 16:21:58 -0500

Joel,

I was thinking of perhaps using the NSH packet header as a general approach
to do iOAM (carrying the OAM information as type 2 metadata), as opposed to
iOAM as a part of SFC itself. But the former is probably out of scope for
this WG.

So a slight rewording:

  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 may be
supported for SFC, if at all.

Cheers,
Andy

On Wed, Dec 13, 2017 at 10:12 AM, Joel M. Halpern <[email-masked]>
wrote:

> information along with user packets carried in SFC (in-situ OAM as part of
> SFC) is within scope for the OAM work.
>
> Loosely related to this, Loa as suggested the following rewording of goal
> 3, which the chairs have agreed to:
>
> production networks, they need Operations, Administration, and Maintenance
> tools, as well as management mechanisms.  This includes YANG models, OAM
>> or SFC as a potential in-situ OAM enabler/mechanism (or both). Perhaps that
>> [email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Greetings WG:____
>>
>>     __ __
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Dec 2017 16:30:59 -0500

Does it work better or worse in your view (and others view) with 
"hybrid" instead of "in-situ"?  Do folks agree with Greg that such would 
be a good substitution?

Yours,
Joel

On 12/13/17 4:21 PM, Andrew G. Malis wrote:
> Joel,
> 
> I was thinking of perhaps using the NSH packet header as a general 
> approach to do iOAM (carrying the OAM information as type 2 metadata), 
> as opposed to iOAM as a part of SFC itself. But the former is probably 
> out of scope for this WG.
> 
> So a slight rewording:
> 
> This draft will include guidance on how active, passive, and in-situ OAM 
> may be supported for SFC, if at all.
> 
> Cheers,
> Andy
> 
> 
> On Wed, Dec 13, 2017 at 10:12 AM, Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     information along with user packets carried in SFC (in-situ OAM as
>     part of SFC) is within scope for the OAM work.
> 
>     (I realize that does not talk explicitly about in-situ.  This seemed
>     a good hook to let the WG know of a change that was suggested.)
> 
>     Yours,
>     Joel
> 
>         For item 5, it’s unclear whether you’re discussing in-situ OAM
>         for SFC, or SFC as a potential in-situ OAM enabler/mechanism (or
>         both). Perhaps that could be made more clear.
> 
>         Cheers,
>         Andy
> 
> 
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>              Greetings WG:____
> 
>              __ __
> 
>              what can be effectively provided and how to provide such
>         tools.     These need attention.____
> 
>              __ __
> 
>              5. OAM Framework document to provide a common basis for OAM
>         work.     This draft will include guidance on how active,
>         passive, and in-situ
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>              <https://www.ietf.org/mailman/listinfo/sfc
>         <https://www.ietf.org/mailman/listinfo/sfc>>
> 
> 
> 
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 13 Dec 2017 18:41:17 -0500

Joel,

“Hybrid” is consistent with the introductory text
in draft-brockners-inband-oam-requirements (which also references 7799), so
using hybrid is fine with me.

Cheers,
Andy

On Wed, Dec 13, 2017 at 4:30 PM, Joel M. Halpern <[email-masked]>
wrote:

> Does it work better or worse in your view (and others view) with "hybrid"
> instead of "in-situ"?  Do folks agree with Greg that such would be a good
> substitution?
>
> Yours,
> Joel
>
>> approach to do iOAM (carrying the OAM information as type 2 metadata), as
>> opposed to iOAM as a part of SFC itself. But the former is probably out of
>> scope for this WG.
>>
>> So a slight rewording:
>>

---

From: "Trossen, Dirk" <[email-masked]>
Date: Thu, 21 Dec 2017 09:57:31 +0000

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:

Thanks!

Jim & Joel

---

From: Ramin Khalili <[email-masked]>
Date: Fri, 22 Dec 2017 10:44:05 +0000

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,

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.

Best,

Dirk

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of James N Guichard <[email-masked]<mailto:[email-masked]>>

Greetings WG:

Thanks!

Jim & Joel

---

From: "Trossen, Dirk" <[email-masked]>
Date: Fri, 22 Dec 2017 10:50:51 +0000

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,

 
Regards,
Ramin. 

James, all,

 

 

 

Best,

Dirk

  

Greetings WG:

  

 

 

 

 

  
Thanks!
 
Jim & Joel