Re: [sfc] SFC WG re-chartering

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:sfc-bounces@ietf.org] On Behalf Of Rahman, Akbar
Sent: Saturday, January 6, 2018 12:51 AM
To: Alia Atlas <akatlas@gmail.com>
Cc: cjbc@it.uc3m.es; James N Guichard <james.n.guichard@huawei.com>; Service Function Chaining IETF list <sfc@ietf.org>
Subject: Re: [sfc] SFC WG re-chartering - initial text for WG review/comment

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:sfc-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Friday, January 5, 2018 3:27 PM
To: cjbc@it.uc3m.es<mailto:cjbc@it.uc3m.es>
Cc: Service Function Chaining IETF list <sfc@ietf.org<mailto:sfc@ietf.org>>; James N Guichard <james.n.guichard@huawei.com<mailto:james.n.guichard@huawei.com>>
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 <cjbc@it.uc3m.es<mailto:cjbc@it.uc3m.es>> wrote:
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.
>
> 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
> sfc@ietf.org<mailto:sfc@ietf.org>
> https://www.ietf.org/mailman/listinfo/sfc