Subject: [sfc] PCEP Extensions for Service Function Chaining (SFC)

From: Qin Wu <[email-masked]>
Date: Thu, 17 Nov 2016 07:01:01 +0000

Hi, folks:
Chair remind us recently to announce to this list that PCE WG is working on PCE Extension for Service Function Chaining. Here is the relevant draft:
https://tools.ietf.org/html/draft-wu-pce-traffic-steering-sfc-09
Please take a look at it and your comments and suggestions are welcome.

-Qin

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 17 Nov 2016 07:42:32 +0000

Hi,

It's great to know that the PCE WG is now working on PCE Extensions for Service Function Chaining.

The following is a draft about PCEP extensions for the MPLS source routing based SFC (see https://tools.ietf.org/html/draft-xu-mpls-service-chaining-00):

https://tools.ietf.org/html/draft-xu-pce-sr-sfc-03

Any suggestions and comments are welcome as well.

Best regards,

Xiaohu

________________________________
发件人: sfc [[email-masked]] 代表 Qin Wu [[email-masked]]
发送时间: 2016年11月17日 15:01
收件人: [email-masked]
主题: [sfc] PCEP Extensions for Service Function Chaining (SFC)

Hi, folks:

-Qin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Nov 2016 03:46:07 -0500

Xu, it is unclear in this draft whether your intention is to carry NSH 
to support interoperation with other transports and carriage of metadata.

Can you please clarify?

Thank you,
Joel

On 11/17/16 2:42 AM, Xuxiaohu wrote:
> The following is a draft about PCEP extensions for the MPLS
> source routing based SFC (see
> https://tools.ietf.org/html/draft-xu-mpls-service-chaining-00):
>
>
>
> ------------------------------------------------------------------------
> *发件人:* sfc [[email-masked]] 代表 Qin Wu [[email-masked]]
> *发送时间:* 2016年11月17日 15:01
> *收件人:* [email-masked]
> *主题:* [sfc] PCEP Extensions for Service Function Chaining (SFC)
>
> Hi, folks:
>
> Chair remind us recently to announce to this list that PCE WG is working
> on PCE Extension for Service Function Chaining. Here is the relevant draft:
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 17 Nov 2016 09:06:47 +0000

Hi Joel,

The current version of this draft just describes neccessary PCEP extensions to realize the MPLS source routing based SFC approach as described in (https://tools.ietf.org/html/draft-xu-mpls-service-chaining-00). It doesn't touch the NSH-based SFC approach. I think it's Qin's draft that covers the NSH-based SFC approach.

Best regards,
Xiaohu

________________________________________
发件人: Joel M. Halpern [[email-masked]]
发送时间: 2016年11月17日 16:46
收件人: Xuxiaohu; Qin Wu; [email-masked]
主题: Re: [sfc] 答复: PCEP Extensions for Service Function Chaining (SFC)

Can you please clarify?

Thank you,
Joel

---

From: Qin Wu <[email-masked]>
Date: Sat, 26 Nov 2016 02:42:05 +0000

Joel:
The idea is when stateful PCE can be used to compute traffic-engineered SFPs, SFP ID can also be predetermined. That is why we add
SFP identifier TLV and send it back to classifier. This SFP Identifier received by Classifier can be inserted into NSH and used to select the path, invoke SF instance, identify next SFF.
There may have other case when PCE only compute traffic-engineered SFP, encode a full sequence of SFF/SF in the PCEP message, Classifier then allocate a SFP identifier, but how
do we prevent other classifier assign the same SFP ID to another Service Function Path? Add SFP ID conflict detection mechanism is complicated.

-Qin
-----邮件原件-----
发件人: Xuxiaohu 
发送时间: 2016年11月17日 17:07
收件人: Joel M. Halpern; Qin Wu; [email-masked]
主题: 答复: [sfc] 答复: PCEP Extensions for Service Function Chaining (SFC)

Hi Joel,

Best regards,
Xiaohu

Xu, it is unclear in this draft whether your intention is to carry NSH to support interoperation with other transports and carriage of metadata.

Can you please clarify?

Thank you,
Joel

On 11/17/16 2:42 AM, Xuxiaohu wrote:
> The following is a draft about PCEP extensions for the MPLS source 
> routing based SFC (see
> Chair remind us recently to announce to this list that PCE WG is 
> working on PCE Extension for Service Function Chaining. Here is the relevant draft:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Nov 2016 21:51:12 -0500

That sounds reasonable.  I was looking for some of that in the draft so 
as to evaluate the (likely sound) details.

Yours,
Joel

---

From: Qin Wu <[email-masked]>
Date: Sat, 26 Nov 2016 10:20:56 +0000

Thanks Joel, we can make text more clear in the next version if confusion is caused.

-Qin
-----邮件原件-----
发件人: Joel M. Halpern [mailto:[email-masked]] 
发送时间: 2016年11月26日 10:51
收件人: Qin Wu; [email-masked]
抄送: BOUCADAIR Mohamed IMT/OLN
主题: Re: [sfc] RE: PCEP Extensions for Service Function Chaining (SFC)

That sounds reasonable.  I was looking for some of that in the draft so as to evaluate the (likely sound) details.

Yours,
Joel

On 11/25/16 9:42 PM, Qin Wu wrote:
> Joel:
> The idea is when stateful PCE can be used to compute 
> traffic-engineered SFPs, SFP ID can also be predetermined. That is why we add SFP identifier TLV and send it back to classifier. This SFP Identifier received by Classifier can be inserted into NSH and used to select the path, invoke SF instance, identify next SFF.
> There may have other case when PCE only compute traffic-engineered 
> SFP, encode a full sequence of SFF/SF in the PCEP message, Classifier then allocate a SFP identifier, but how do we prevent other classifier assign the same SFP ID to another Service Function Path? Add SFP ID conflict detection mechanism is complicated.
>
> -Qin
> -----邮件原件-----
> 发件人: Xuxiaohu
> 发送时间: 2016年11月17日 17:07
>> ---------------------------------------------------------------------
>> -
>> --