Re: [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-serviceid-header

[<[e-mail]>]

Hi Shunsuke,
obviously there is some kind of seasonal holiday break globally - so no problem at all and happy new year!
;-)
We currently are in process of updating the draft and will publish soon where we hopefully will have considered your ideas properly.
Awaiting your feedback then!
Thanks!  
Kind regards
Dirk

-----Original Message-----
From: Shunsuke Homma <[e-mail]> 
Sent: Mittwoch, 8. Januar 2020 09:53
To: von Hugo, Dirk <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-serviceid-header

Hi Dirk,

Thank you very much for your kind reply, and I'm sorry for my too late response.

I understood your thoughts on the two items. It is just my personal opinion, but it may be help for readers to understand the motivation on use of service performance identifier if you describe some sample scenario where the identifier is useful.

Regarding e2e communication, I don't need detailed description about mechanisms to cooperate with underlay infrastructure. As you described, it should be out of scope in this document. 
While, I expect that the identifier can be used for not only loadbalancing of SFs but also optimization of whole of service path, and I personally wanted to add some light explanation about it.

Thank you very much.

Best regards,

Shunsuke  

-----Original Message-----
From: sfc <[e-mail]> On Behalf Of [e-mail]
Sent: Friday, December 20, 2019 1:23 AM
To: [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-serviceid-header

Hi Shunsuke,
thanks for your comments. Fair points raised! 
We therefore addressed the ways to control SFC entities according to service specific policies/rules by saying in the draft: 

==
   Thus, the performance policy identifier allows for the distributed
   enforcement of a per-service policy such as a service function path
   to only include specific SFs instances.  Details of this process are
   implementation-specific.  For illustration purposes, an SFF may
   retrieve the details of usable SFs based upon the corresponding
   performance policy identifier.  Typical criteria for instantiating
   specific SFs include location, performance, or proximity
   considerations.  For the particular case of UHR services, the stand-
   by operation of back-up capacity or the deployment of multiple SF
   instances may be requested.
==

.... and think that - especially a dynamic SFP choice - cannot be achieved by CF alone. 

Regarding e2e communication we think that actually any SFC decision relies on underlying transport or user plane layers and routing decisions to be enforced there. So a description of interworking mechanisms seems to ber out of scope for our document. If you think it would help of course we could state this explicitly.
 
We are fine to add references to 3GPP specs and extending to 5G NFs as UPF etc. where applicable!

Thanks again!

Best regards - on behalf of the co-authors Dirk
 
 
> -----Original Message-----
> From: sfc <[e-mail]> On Behalf Of Shunsuke Homma
> Sent: Montag, 16. Dezember 2019 05:36
> To: 'Joel M. Halpern' <[e-mail]>; [e-mail]
> Subject: Re: [sfc] Fwd: IETF WG state changed for
> draft-ietf-sfc-serviceid- header
> 
> Hi authors,
> 
> I agree with that subscriber id will be useful, and simultaneously I 
> have some questions on Performance Policy Identifier as below:
> - In my understanding, SFC path and SF instance selection will be done 
> at CF as starting point of SFC, and these information would be implied in SFP.
> Why is the information needed to be represented as metadata in context 
> header? (I agree that information for policy selection at SFs would be 
> needed because, for example, customers use multiple applications and 
> they may have different requirements for processes at SFs.)
> - ULL and UHR should be fulfilled as e2e communication, and some 
> interwork with underlay transport (and maybe user plane in 3GPP if it 
> is used in mobile network) would be needed. Don't you describe some 
> means how to interwork with other layers by using performance policy identifier?
> 
> Also, I have some small comments:
> - This document uses some 3GPP terms such as SGi and P/S-GW, and 3GPP 
> documents(e.g., TS23.401) should be referred.
> - SGi and P/S-GW are terms of 4G, but 5G is coming soon, thus why 
> don't you add 5G terms (e.g., N6/DN, UPF) in addition to 4G terms?
> 
> Regards,
> 
> Shunsuke
> 
> -----Original Message-----
> From: sfc <[e-mail]> On Behalf Of Joel M. Halpern
> Sent: Wednesday, December 11, 2019 10:52 PM
> To: [e-mail]
> Subject: [sfc] Fwd: IETF WG state changed for
> draft-ietf-sfc-serviceid- header
> 
> Starting WG Last call.  See comment below for description.
> Thank you,
> Joel
> 
> 
> -------- Forwarded Message --------
> Subject: IETF WG state changed for draft-ietf-sfc-serviceid-header
> Resent-Date: Tue, 10 Dec 2019 09:27:51 -0800 (PST)
> Resent-From: [e-mail]
> Resent-To: [e-mail], [e-mail], 
> [e-mail]
> Date: Tue, 10 Dec 2019 09:27:51 -0800
> From: IETF Secretariat <[e-mail]>
> To: [e-mail], [e-mail]
> 
> 
> The IETF WG state of draft-ietf-sfc-serviceid-header has been changed 
> to "In WG Last Call" from "WG Document" by Joel Halpern:
> 
> https://datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header/
> 
> Comment:
> This starts the working group last call for this document.  It has 
> been discussed on the email list.  We need to see responses.  If you 
> see issues with publishing this document as an RFC, please speak up 
> now.  And please be
> clear about what your concerns are.   At the same time, if you think that
> publishing this as an RFC is a good thing for the working group, 
> please speak up.
> 
> As a note for those who may be concerned about the relationship to the 
> TLV draft, the chairs have noticed that problem, and we believe we 
> have gotten that document unstuck.
> 
> Given the propensity for people to disappear at this time of year, I 
> am giving the document a 4 week last call.
> 
> Thank you for your time and attention, Joel (& Jim)
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
> 
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc

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