Subject: [mpls] FW: New Version Notification for draft-xu-sfc-using-mpls-spring-04.txt

From: Xuxiaohu <[email-masked]>
Date: Wed, 9 Sep 2015 09:45:18 +0000

Hi all,

Service chaining is an important function for all type of networks including those using the source routing paradigm as specified by the SPRING working group. This draft is especially focused on the SPRING/MPLS network scenario.

When we posted the early versions (-00 to -02), the feedback from the SFC working group chairs was that the solution required changes to the MPLS architecture. We discussed this among the authors and posted a new version (-03) that does not require any change to the MPLS Architecture anymore. Version -04 merely corrects some typos.

Now we would like to ask the SFC chairs and WGs if the draft can now be considered for adoption by the SFC working group.

Best regards,
Xiaohu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 09, 2015 5:23 PM
> To: Lizhenbin; Luis M. Contreras; Xuxiaohu; Himanshu C. Shah; Xuxiaohu;
> Himanshu Shah; Luis M. Contreras; Lizhenbin
> Subject: New Version Notification for draft-xu-sfc-using-mpls-spring-04.txt
> 
> 
> A new version of I-D, draft-xu-sfc-using-mpls-spring-04.txt
> has been successfully submitted by Xiaohu Xu and posted to the IETF repository.
> 
> Name:		draft-xu-sfc-using-mpls-spring
> Revision:	04
> Title:		Service Function Chaining Using MPLS-SPRING
> Document date:	2015-09-09
> Group:		Individual Submission
> Pages:		7
> URL:
> https://www.ietf.org/internet-drafts/draft-xu-sfc-using-mpls-spring-04.txt
> Status:
> https://datatracker.ietf.org/doc/draft-xu-sfc-using-mpls-spring/
> Htmlized:       https://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-04
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-xu-sfc-using-mpls-spring-04
> 
> Abstract:
>    Source Packet Routing in Networking (SPRING) WG specifies a special
>    source routing mechanism.  Such source routing mechanism can be
>    leveraged to realize the service path layer functionality of the
>    service function chaining (i.e, steering traffic through a particular
>    service function path) by encoding the service function path or the
>    service function chain information as the explicit path information.
>    This document describes how to leverage the MPLS-based source routing
>    mechanism as developed by the SPRING WG to realize the service path
>    layer functionality of the service function chaining.
> 
> 
> 
> 
> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 9 Sep 2015 10:21:29 -0400

This draft seems to be written as if MPLS were a transport-independent 
forwarding mechanism for SFC.  While I expect MPLS (and MPLS-SPRING) to 
be used as a transport for MPLS, and sometimes as a transport across 
multiple service functions, I would NOT claim that it is itself 
transport independent.

As such, I am unclear on how the SFC working group could adopt this 
document.

Considered as a transport description, it does not appear to standardize 
anything, so it would seem at most to be an informational document.

Yours,
Joel M. Halpern

On 9/9/15 5:45 AM, Xuxiaohu wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 10 Sep 2015 02:40:20 +0000

Hi Joel,

As described in this draft, an MPLS label stack is used to indicate a certain service function path. In other word, the MPLS label stack is now looked as another SFC encapsulation form. As MPLS encapsulated packets could be transported over MPLS networks or IP networks through IP-based tunnels (e.g., GRE or UDP), the MPLS-formatted SFC header could be safely deemed as transport-independent.

Since the MPLS-SPRING-based SFC approach as described in this draft is built on the mature MPLS forwarding paradigm, SFF functionalities could be easily implemented on existing MPLS devices without any change to their data-planes if the attached SFs are SFC-aware. Note that SFC-aware here (i.e., in the MPLS-SPRING-based SFC context) means MPLS-aware at least (e.g., being capable of receiving and treating received packets with the MPLS encapsulation). As SFC-aware SFs tend to be implemented in the NFV form, MPLS-awareness would not be a excessive demand for them, IMHO.

Best regards,
Xiaohu

> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Wednesday, September 09, 2015 10:21 PM
> To: Xuxiaohu; [email-masked]'
> Cc: [email-masked]'
> Subject: Re: [sfc] [mpls] FW: New Version Notification for
> draft-xu-sfc-using-mpls-spring-04.txt
> 
> forwarding mechanism for SFC.  While I expect MPLS (and MPLS-SPRING) to be
> used as a transport for MPLS, and sometimes as a transport across multiple
> service functions, I would NOT claim that it is itself transport independent.
> 
> As such, I am unclear on how the SFC working group could adopt this document.
> 
> > Service chaining is an important function for all type of networks including
> those using the source routing paradigm as specified by the SPRING working
> group. This draft is especially focused on the SPRING/MPLS network scenario.
> >
> > When we posted the early versions (-00 to -02), the feedback from the SFC
> working group chairs was that the solution required changes to the MPLS
> architecture. We discussed this among the authors and posted a new version
> (-03) that does not require any change to the MPLS Architecture anymore.
> Version -04 merely corrects some typos.
> >
> > Now we would like to ask the SFC chairs and WGs if the draft can now be
> considered for adoption by the SFC working group.
> >
> > Best regards,
> > Xiaohu
> >
> >> To: Lizhenbin; Luis M. Contreras; Xuxiaohu; Himanshu C. Shah;
> >> Xuxiaohu; Himanshu Shah; Luis M. Contreras; Lizhenbin
> >> Htmlized:
> https://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-04
> >> Diff:
> >> 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