Re: [sfc] New Version Notification for draft-trossen-sfc-name-based-sff-01.txt

Dear Dirk,

Many thanks for the response. Indeed, we have in mind to bring the discussion on describing control plane workflows as (named) SFCs into the eSBA study you mentioned below. 

Best,

Dirk

-----Original Message-----
From: Hugo, Dirk 
Sent: 31 October 2018 15:59
To: Trossen, Dirk <Dirk.Trossen@InterDigital.com>; sfc@ietf.org
Subject: RE: New Version Notification for draft-trossen-sfc-name-based-sff-01.txt

Dear Dirk and co-authors,

Thanks for providing the useful draft again.
I would like to point out the relation to 3GPPs 5G SBA use case again where network function services are introduced to be combined in a chain like manner to provide a communication service or logical network slice. Name-based addressing and routing would allow to select the optimal appropriate SF instance. 
I think thus it could be helpful for ongoing 3GPP SA2 study on 'Enhancements to the Service-Based Architecture' for Release 16 (TR 23.742).

One minor comment for update is to refer in [_3GPP_SBA] to the actually approved version of 3GPP TS 29.500 (15.1.0) instead of draft (0.4.0) one.
;-)
Thanks!

Best Regards
Dirk
-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Trossen, Dirk
Sent: Donnerstag, 18. Oktober 2018 14:56
To: Service Function Chaining IETF list <sfc@ietf.org>
Subject: [sfc] FW: New Version Notification for draft-trossen-sfc-name-based-sff-01.txt

All,

Based on the input received during the Montreal meeting, we updated the name-based SFF draft (see below), providing significantly more detail on issues like SF registration, nSFF forwarding, local SF forwarding and alike. We also simplified yet focused the use case with reference to ongoing 3GPP Rel16 work.

Please review and share comments on this draft version.

Best,

Dirk

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: 17 October 2018 20:34
To: Purkayastha, Debashish <Debashish.Purkayastha@InterDigital.com>; Trossen, Dirk <Dirk.Trossen@InterDigital.com>; Purkayastha, Debashish <Debashish.Purkayastha@InterDigital.com>; Rahman, Akbar <Akbar.Rahman@InterDigital.com>; Trossen, Dirk <Dirk.Trossen@InterDigital.com>
Subject: New Version Notification for draft-trossen-sfc-name-based-sff-01.txt

A new version of I-D, draft-trossen-sfc-name-based-sff-01.txt
has been successfully submitted by Debashish Purkayastha and posted to the IETF repository.

Name:		draft-trossen-sfc-name-based-sff
Revision:	01
Title:		Name-Based Service Function Forwarder (nSFF) component within SFC framework
Document date:	2018-10-17
Group:		Individual Submission
Pages:		24
URL:            https://www.ietf.org/internet-drafts/draft-trossen-sfc-name-based-sff-01.txt
Status:         https://datatracker.ietf.org/doc/draft-trossen-sfc-name-based-sff/
Htmlized:       https://tools.ietf.org/html/draft-trossen-sfc-name-based-sff-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-trossen-sfc-name-based-sff
Diff:           https://www.ietf.org/rfcdiff?url2=draft-trossen-sfc-name-based-sff-01

Abstract:
   Many stringent requirements are imposed on today's network, such as
   low latency, high availability and reliability in order to support
   several use cases such as IoT, Gaming, Content distribution, Robotics
   etc.  Adoption of cloud and fog technology at the edge of the network
   allows operator to deploy a single "Service Function" to multiple
   "Execution locations".  The decision to steer traffic to a specific
   location may change frequently based on load, proximity etc.  Under
   the current SFC framework, steering traffic dynamically to the
   different execution end points require a specific 're-chaining',
   i.e., a change in the service function path reflecting the different
   IP endpoints to be used for the new execution points.  In order to
   address this, we discuss separating the logical Service Function Path
   from the specific execution end points.  This can be done by
   identifying the Service Functions using a name rather than a routable
   IP endpoint (or Layer 2 address).  This draft describes the necessary
   extensions, additional functions and protocol details in SFF to
   handle name based relationships.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc