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

From: Xuxiaohu <[email-masked]>
Date: Wed, 4 Mar 2015 04:10:13 +0000

The rationales for leveraging the MPLS-SPRING mechanism to realize the service path layer functionality of the service function chaining are as follows:

1) eliminate the SFC/SFP states on SFFs. This follows the same logic as MPLS-SPRING and BIER.
2) utilize the existing encapsulation (e.g., the MPLS-SPRING) to a maximum extent. This follows the Transport Derived SFF concept as described in Section 4.3.1 of draft-ietf-sfc-architecture. Meanwhile, this is aligned with the current SFC charter, e.g., "...The working group will consider using an existing encapsulation (with extensions as appropriate) if a suitable candidate is found..."
3) seamlessly support the SFC in a multi-tenant environment (e.g., MPLS VPN). For example, the MPLS VPN packet (containing metadata) could be further imposed with a label stack which indicates an SFC or SFP associated with that packet. SFFs receiving the above packet would strip the whole label stack and then send the payload of the MPLS packet (with metadata) to the corresponding SFs which are tenant-aware and therefore easily could determine the tenant profile according to the tenant info contained in the metadata (a.k.a., the NSH). 

Best regards,
Xiaohu

> -----Original Message-----
> From: Xuxiaohu
> Sent: Wednesday, March 04, 2015 11:31 AM
> To: [email-masked]; '<[email-masked]>'; [email-masked]
> Subject: FW: New Version Notification for draft-xu-sfc-using-mpls-spring-02.txt
> 
> Hi all,
> 
> This document describes how to leverage the MPLS-based source routing (i.e.,
> MPLS-SPRING) mechanism as developed by the SPRING WG to realize the
> service path layer functionality of the service function chaining. In addition, this
> document also describes how to carry metadata in an MPLS packet by using the
> NSH as a metadata container.
> 
> Any comments are suggestions are welcome.
> 
> Best regards,
> Xiaohu
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, March 04, 2015 11:24 AM
> > 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-02.txt
> >
> >
> > A new version of I-D, draft-xu-sfc-using-mpls-spring-02.txt
> > has been successfully submitted by Xiaohu Xu and posted to the IETF
> repository.
> >
> > Name:		draft-xu-sfc-using-mpls-spring
> > Revision:	02
> > Title:		Service Function Chaining Using MPLS-SPRING
> > Document date:	2015-03-03
> > Group:		Individual Submission
> > Pages:		8
> > URL:
> > http://www.ietf.org/internet-drafts/draft-xu-sfc-using-mpls-spring-02.
> > txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-xu-sfc-using-mpls-spring/
> > Htmlized:       http://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-02
> > Diff:
> > http://www.ietf.org/rfcdiff?url2=draft-xu-sfc-using-mpls-spring-02
> >
> > 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: Xuxiaohu <[email-masked]>
Date: Thu, 5 Mar 2015 01:58:39 +0000

Hi Ron,

Thanks a lot for your insightful comments and suggestions. By the way, in the case where there is no need to deliver metadata, does it mean the NSH just only needs to be contained the packets exchanged between SFFs and SFs? In other words, the NSH is used as a way for the SFF to retrieve the label stack which has been stripped by that SFF before.

Best regards,
Xiaohu 

> From: Ron Parker [mailto:[email-masked]]
> Sent: Thursday, March 05, 2015 12:41 AM
> To: Xuxiaohu; [email-masked]; <[email-masked]>; [email-masked]
> Subject: RE: [sfc] New Version Notification for
> Xiaohu,
> I read your latest draft and I do see the elegance of describing a sequence of
> must-visit nodes as a stack of MPLS labels.   And I see that you've addressed
> the transport-independence requirement by stating that the MPLS frames could
> be carried within IP tunnels (i.e., MPLS in UDP, etc.).    But, I have a couple of
> issues that I suggest be addressed.
> 
> First, the text is written as if the NSH header is optional and present only if
> metadata is required.    The SFC architecture is such that the NSH is
> mandatory.   I think this issue can be combined with the second issue that I'll
> raise below.
> 
> Second, the notion is that the SFF's strip the label stack and then restore the
> label stack.    And since the text states that even when NSH is present, the SFP
> ID is not used, the only remaining basis to do this is flow learning in the SFF.
> While I think there are many reasons that may cause SFF's to utilize flow
> learning advantageously, it should not be a fundamental necessity to realize an
> SFF, IMO.   But even if the SFF is a flow learner, this is still inadequate since the
> SF may change the 5-tuple (e.g., NAT) or may launch internally generated flows
> (e.g., HTTP proxy).   Both cases could not be satisfied by flow learning.
> 
> What I suggest, instead, is a tighter coupling between the NSH header and the
> MPLS label stack.   That there be a 1:1 equivalency between {SFP ID, SFP hop
> index} and the label stack.   Thus, when the SFC-aware SF returns a packet to
> the SFF, the {SFP ID, SFP hop index} contained in the NSH be used to push the
> appropriate label stack onto the packet.    I believe this would bring the
> approach into conformance with the SFC architectural requirements
> (mandatory NSH, transport independence) and would solve the problems with
> flow learning identified above.
> 
>    Ron
> 
> 
> 
> From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
> Sent: Tuesday, March 3, 2015 11:10 PM
> To: Xuxiaohu; [email-masked]; <[email-masked]>; [email-masked]
> Subject: Re: [sfc] New Version Notification for
> The rationales for leveraging the MPLS-SPRING mechanism to realize the service
> path layer functionality of the service function chaining are as follows:
> 
> 2) utilize the existing encapsulation (e.g., the MPLS-SPRING) to a maximum
> extent. This follows the Transport Derived SFF concept as described in Section
> 4.3.1 of draft-ietf-sfc-architecture. Meanwhile, this is aligned with the current
> SFC charter, e.g., "...The working group will consider using an existing
> encapsulation (with extensions as appropriate) if a suitable candidate is found..."
> 3) seamlessly support the SFC in a multi-tenant environment (e.g., MPLS VPN).
> For example, the MPLS VPN packet (containing metadata) could be further
> imposed with a label stack which indicates an SFC or SFP associated with that
> packet. SFFs receiving the above packet would strip the whole label stack and
> then send the payload of the MPLS packet (with metadata) to the corresponding
> SFs which are tenant-aware and therefore easily could determine the tenant
> profile according to the tenant info contained in the metadata (a.k.a., the NSH).
> 
> Best regards,
> Xiaohu
> 
> 
> > (i.e.,
> > service path layer functionality of the service function chaining. In
> > addition, this document also describes how to carry metadata in an
> > MPLS packet by using the NSH as a metadata container.
> >
> > > Htmlized:
> http://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-02
> > > Diff:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 5 Mar 2015 15:10:55 +0000

Hi Xiaohu,

Thomas and I read your latest draft and believe that you will need to take
it to the MPLS WG as a first step. There are a number of things within the
document that may require changes to the base MPLS architecture and the
SFC WG is not the right community to address those. Given this we will not
be able to consider this document in the SFC WG without agreement from the
broader MPLS community.

Regards,

Jim & Thomas

On 3/4/15, 9:20 PM, "Ron Parker" <[email-masked]> wrote:

>I think it needs to be there between SFF's, too.  In the case where there
>is no metadata, you could argue that the data in NSH and the label stack
>are redundantly saying the same thing, but an optimization along these
>lines would not be justified, IMO.
>
>   Ron
>
>
>> On Mar 4, 2015, at 8:58 PM, Xuxiaohu <[email-masked]> wrote:
>> 
>> Hi Ron,
>> 
>> Thanks a lot for your insightful comments and suggestions. By the way,
>>in the case where there is no need to deliver metadata, does it mean the
>>NSH just only needs to be contained the packets exchanged between SFFs
>>and SFs? In other words, the NSH is used as a way for the SFF to
>>retrieve the label stack which has been stripped by that SFF before.
>> 
>> Best regards,
>> Xiaohu 
>>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 6 Mar 2015 00:48:47 +0000

Hi Jim,

Understood.

Best regards,
Xiaohu

> From: Jim Guichard (jguichar) [mailto:[email-masked]]
> Sent: Thursday, March 05, 2015 11:11 PM
> To: Ron Parker; Xuxiaohu
> Cc: [email-masked]; <[email-masked]>; [email-masked]
> Thomas and I read your latest draft and believe that you will need to take it to
> the MPLS WG as a first step. There are a number of things within the document
> that may require changes to the base MPLS architecture and the SFC WG is not
> the right community to address those. Given this we will not be able to consider
> this document in the SFC WG without agreement from the broader MPLS
> community.
> 
> Regards,
> 
> Jim & Thomas
> 
> 
> >I think it needs to be there between SFF's, too.  In the case where
> >there is no metadata, you could argue that the data in NSH and the
> >label stack are redundantly saying the same thing, but an optimization
> >along these lines would not be justified, IMO.
> >
> >   Ron
> >
> >
> >> Thanks a lot for your insightful comments and suggestions. By the
> >>way, in the case where there is no need to deliver metadata, does it
> >>mean the NSH just only needs to be contained the packets exchanged
> >>between SFFs and SFs? In other words, the NSH is used as a way for the
> >>SFF to retrieve the label stack which has been stripped by that SFF before.
> >>
> >> Best regards,
> >> Xiaohu
> >>
> >>> While I think there are many reasons that may cause SFF's to utilize
> >>>flow  learning advantageously, it should not be a fundamental
> >>>necessity to realize an
> >>>(mandatory NSH, transport independence) and would solve the problems
> >>>with  flow learning identified above.
> >>>
> >>>   Ron
> >>>
> >>>
> >>>
> >>> The rationales for leveraging the MPLS-SPRING mechanism to realize
> >>>the service  path layer functionality of the service function
> >>>chaining are as
> >>>follows:
> >>>
> >>> 2) utilize the existing encapsulation (e.g., the MPLS-SPRING) to a
> >>>maximum  extent. This follows the Transport Derived SFF concept as
> >>>described in Section
> >>> 4.3.1 of draft-ietf-sfc-architecture. Meanwhile, this is aligned
> >>>with the current  SFC charter, e.g., "...The working group will
> >>>consider using an existing  encapsulation (with extensions as
> >>>appropriate) if a suitable candidate is found..."
> >>> For example, the MPLS VPN packet (containing metadata) could be
> >>>further  imposed with a label stack which indicates an SFC or SFP
> >>>associated with that  packet. SFFs receiving the above packet would
> >>>strip the whole label stack and  then send the payload of the MPLS
> >>>packet (with metadata) to the corresponding  SFs which are
> >>>tenant-aware and therefore easily could determine the tenant  profile
> >>>according to the tenant info contained in the metadata (a.k.a., the
> >>>NSH).
> >>>
> >>> Best regards,
> >>> Xiaohu
> >>>
> >>>
> >>>> service path layer functionality of the service function chaining.
> >>>> In addition, this document also describes how to carry metadata in
> >>>> an MPLS packet by using the NSH as a metadata container.
> >>>>

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 9 Mar 2015 03:03:00 +0000

Hi Jim,

I have remove those options which may cause changes to the MPLS architecture in the latest version (http://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-03). 

Best regards,
Xiaohu

> Sent: Friday, March 06, 2015 8:49 AM
> To: 'Jim Guichard (jguichar)'; Ron Parker
> > Thomas and I read your latest draft and believe that you will need to
> > take it to the MPLS WG as a first step. There are a number of things
> > within the document that may require changes to the base MPLS
> > architecture and the SFC WG is not the right community to address
> > those. Given this we will not be able to consider this document in the
> > SFC WG without agreement from the broader MPLS community.
> >
> > Regards,
> >
> > Jim & Thomas
> >
> >
> > >label stack are redundantly saying the same thing, but an
> > >optimization along these lines would not be justified, IMO.
> > >
> > >   Ron
> > >
> > >
> > >>between SFFs and SFs? In other words, the NSH is used as a way for
> > >>the SFF to retrieve the label stack which has been stripped by that SFF
> before.
> > >>
> > >> Best regards,
> > >> Xiaohu
> > >>
> > >>> While I think there are many reasons that may cause SFF's to
> > >>>utilize flow  learning advantageously, it should not be a
> > >>>fundamental necessity to realize an
> > >>>(mandatory NSH, transport independence) and would solve the
> > >>>problems with  flow learning identified above.
> > >>>
> > >>>   Ron
> > >>>
> > >>>
> > >>>
> > >>>tenant-aware and therefore easily could determine the tenant
> > >>>> MPLS-SPRING) mechanism as developed by the SPRING WG to realize
> > >>>> the service path layer functionality of the service function chaining.
> > >>>> In addition, this document also describes how to carry metadata
> > >>>> in an MPLS packet by using the NSH as a metadata container.
> > >>>>
> > >>>>> 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
> > >>>