Subject: Re: [sfc] draft-wu-pce-traffic-steering-sfc-04

From: "Ken Gray (kegray)" <[email-masked]>
Date: Wed, 9 Jul 2014 02:24:05 +0000

I had a couple questions on this …

If the point is that a PCE could compute the path based on a policy, we're
probably all in agreement. Where I get lost is in the need for the TLV
extension to indicate it's an SFP.  That fact would, IMO, be managed at a
higher level - as it would be for any overlay construct (VXLAN, GRE,
your-favorite-overlay-encap-here).  It appears an unnecessary
informational burden, IMO.  Can you explain how you envision this being
used?

On 7/7/14 9:12 AM, "Qin Wu" <[email-masked]> wrote:

>Ron:
>We also have draft to discuss how to instantiate service function path
>using PCE-initiate LSP instantiation.
>http://tools.ietf.org/html/draft-wu-pce-traffic-steering-sfc-04
>It supports dynamic creation and deletion of service function path.
>Your may check out.
>
>Regards!
>-Qin
>-----邮件原件-----
>发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
>发送时间: 2014年7月7日 20:52
>收件人: Linda Dunbar; [email-masked]'
>主题: Re: [sfc] New Version Notification for
>draft-dunbar-sfc-fun-instances-restoration-00.txt
>
>Linda & Andy,
>
>Thanks for putting this together.   I'm happy to see more work on the
>"chain-to-path" topic.   I agree with all of your analysis regarding
>pros/cons of various approaches.     Encapsulation and Control Plane will
>be dependent on our architectural decisions in this area.   The elusive
>thing for all of us, as a group, is to come to some conclusions!
>
>   Ron
>
>
>-----Original Message-----
>From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
>Sent: Friday, July 04, 2014 4:49 PM
>To: [email-masked]'
>Subject: [sfc] FW: New Version Notification for
>draft-dunbar-sfc-fun-instances-restoration-00.txt
>
>Hi, 
>
>This draft describes the framework of protection and restoration of
>   Service Chain Instance Path when some instances on the path fail or
>   need to be replaced.
>
>Appreciate to hear your comments or suggestions.
>
>Linda & Andy
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, April 30, 2014 11:25 AM
>To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar
>Subject: New Version Notification for
>draft-dunbar-sfc-fun-instances-restoration-00.txt
>
>
>A new version of I-D, draft-dunbar-sfc-fun-instances-restoration-00.txt
>has been successfully submitted by Linda Dunbar and posted to the IETF
>repository.
>
>Name:		draft-dunbar-sfc-fun-instances-restoration
>Revision:	00
>Title:		Framework for Service Function Instances Restoration
>Document date:	2014-04-29
>Group:		Individual Submission
>Pages:		12
>URL:            
>http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-instances-restora
>tion-00.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-instances-restoratio
>n/
>Htmlized:       
>http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-00
>
>
>Abstract:
>   This draft describes the framework of protection and restoration of
>   Service Chain Instance Path when some instances on the path fail or
>   need to be replaced.
>
>                  
>        
>
>
>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sfc
>
>_______________________________________________
>sfc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sfc
>_______________________________________________
>sfc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sfc

---

From: Qin Wu <[email-masked]>
Date: Wed, 9 Jul 2014 02:35:44 +0000

Not only indicate it is an SFP, but also you need to tell classifier which service function path you need to instantiate?
Without service function path ID, how do you know which path you need to create, which path you need to update ,which path you need to delete?

Regarding where to put SFP, I think at least classifier should maintain path information which use SFP ID to distinct one path from another,
You may put it into whatever overlay header you want to use. If you think it is a burden, you can choose not put it into the overlay header and 
use other signaling to setup service function path, e.g., you have SDN controller or you have NMS/OSS, NMS/OSS will translate Service function chain
into path information based on SFP ID and populate such path information with SFP ID to each participating node in the service chain.
All in all, as I clarified earlier, SFP ID based solution doesn't couple with the signaling you are used.

Regards!
-Qin
-----邮件原件-----
发件人: Ken Gray (kegray) [mailto:[email-masked]] 
发送时间: 2014年7月9日 10:24
收件人: Qin Wu; Ron Parker; Linda Dunbar; [email-masked]'
主题: RE: draft-wu-pce-traffic-steering-sfc-04

If the point is that a PCE could compute the path based on a policy, we're probably all in agreement. Where I get lost is in the need for the TLV extension to indicate it's an SFP.  That fact would, IMO, be managed at a higher level - as it would be for any overlay construct (VXLAN, GRE, your-favorite-overlay-encap-here).  It appears an unnecessary informational burden, IMO.  Can you explain how you envision this being used?

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Sat, 12 Jul 2014 02:14:10 +0000

I'm not convinced that you need that, to be honest.  It seems that the need for extensions is tied to the assumption that you need some sort of special label to indicate that an overlay instance (LSP, SR SID, etc) was created to be a service path - but I just don't see that as a requirement.  Its already labeled (as tunnelx or SID value y or NextHopz) and the association as a SP can be maintained elsewhere (like sfc control/management app).  To me, it seems more of a convenience than a necessity.

Sent from my iPhone

> On Jul 8, 2014, at 10:35 PM, "Qin Wu" <[email-masked]> wrote:
>

---

From: Qin Wu <[email-masked]>
Date: Mon, 14 Jul 2014 01:24:39 +0000

Hi, Ken:
Just to clarify, what we proposed in draft-wu-pce-traffic-steering-sfc-04 is not related to segment routing or source routing based approach.
To identify a service function chain, you need a chain ID or service function map index proposed in boucadir framework draft.
To identify a service function path, you can use a set of locators and each locator corresponding to each service function for a given service function chain.
Depending on what the ID of the SFC Header should reference (the chain or the path), see Mike's comment
http://www.ietf.org/mail-archive/web/sfc/current/msg02222.html

PCE can return corresponding to ID (either path ID or chain ID) to the classifier and establish
The mapping between service function chain and service function path.
So the SFP ID proposed in draft-wu-pce-traffic-steering-sfc-04 can be that path ID or chain ID. In my opinion, chain ID may be more appropriate.

Regards!
-Qin
-----邮件原件-----
发件人: Ken Gray (kegray) [mailto:[email-masked]] 
发送时间: 2014年7月12日 10:14
收件人: Qin Wu
抄送: Ron Parker; Linda Dunbar; [email-masked]; Dhruv Dhody
主题: Re: draft-wu-pce-traffic-steering-sfc-04

Sent from my iPhone

> Regarding where to put SFP, I think at least classifier should 
> maintain path information which use SFP ID to distinct one path from 
> another, You may put it into whatever overlay header you want to use. 
> If you think it is a burden, you can choose not put it into the overlay header and use other signaling to setup service function path, e.g., you have SDN controller or you have NMS/OSS, NMS/OSS will translate Service function chain into path information based on SFP ID and populate such path information with SFP ID to each participating node in the service chain.
>> We also have draft to discuss how to instantiate service function 
>> path using PCE-initiate LSP instantiation.
>> A new version of I-D, 
>> has been successfully submitted by Linda Dunbar and posted to the 
>> IETF repository.
>> 
>> http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-instances-re
>> st
>> ora
>> tion-00.txt
>> Status:         
>> https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-instances-resto
>> ra
>> tio
>> n/
>> Htmlized:       
>> http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration
>> -0
>> 0
>> 
>> 
>> Abstract: