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

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 11 Dec 2019 08:51:47 -0500

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: [email-masked]
Resent-To: [email-masked], [email-masked], 
[email-masked]
Date: Tue, 10 Dec 2019 09:27:51 -0800
From: IETF Secretariat <[email-masked]>
To: [email-masked], [email-masked]

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)

---

From: <[email-masked]>
Date: Thu, 12 Dec 2019 07:11:28 +0000

Hello sfc WG,

I believe this document is useful to optimize SFC design and operation, it's in good shape and should be moved forward.

Cheers,

Christian.

-----Message d'origine-----
De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
Envoyé : mercredi 11 décembre 2019 14:52
À : [email-masked]
Objet : [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-serviceid-header

-------- 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: [email-masked]
Resent-To: [email-masked], [email-masked], 

Comment:

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 12 Dec 2019 15:57:41 -0500

I support this draft. It provides useful features.

Minor point: for completeness, the descriptions of header fields in
Sections 3 and 4 should include all fields.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: <[email-masked]>
Date: Fri, 13 Dec 2019 09:02:47 +0000

Hi Donald,

Point taken (https://github.com/boucadair/draft-ietf-sfc-serviceid/issues/1). Thank you.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Donald Eastlake
Envoyé : jeudi 12 décembre 2019 21:58
À : Joel M. Halpern
Cc : [email-masked]
Objet : Re: [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-serviceid-header

Minor point: for completeness, the descriptions of header fields in Sections 3 and 4 should include all fields.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]<mailto:[email-masked]>

On Wed, Dec 11, 2019 at 8:52 AM Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
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: [email-masked]<mailto:[email-masked]>
Resent-To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>,
[email-masked]<mailto:[email-masked]>
Date: Tue, 10 Dec 2019 09:27:51 -0800
From: IETF Secretariat <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Comment:

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

---

From: Shunsuke Homma <[email-masked]>
Date: Mon, 16 Dec 2019 13:36:14 +0900

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

-------- 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: [email-masked]
Resent-To: [email-masked], [email-masked], [email-masked]
Date: Tue, 10 Dec 2019 09:27:51 -0800
From: IETF Secretariat <[email-masked]>
To: [email-masked], [email-masked]

Comment:

---

From: <[email-masked]>
Date: Thu, 19 Dec 2019 16:23:00 +0000

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

> From: sfc <[email-masked]> On Behalf Of Shunsuke Homma
> Sent: Montag, 16. Dezember 2019 05:36
> To: 'Joel M. Halpern' <[email-masked]>; [email-masked]
> 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?
> 
> - 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
> 
> Subject: [sfc] Fwd: IETF WG state changed for 
> draft-ietf-sfc-serviceid- header
> 
> The IETF WG state of draft-ietf-sfc-serviceid-header has been changed 
> to "In WG Last Call" from "WG Document" by Joel Halpern:
> 
> 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
> 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)
>