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 protected]> 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 protected]> 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 >> >>> -----Original Message----- >>> From: Ron Parker [mailto:[email protected]] >>> Sent: Thursday, March 05, 2015 12:41 AM >>> To: Xuxiaohu; [email protected]; <[email protected]>; [email protected] >>> Subject: RE: [sfc] New Version Notification for >>> draft-xu-sfc-using-mpls-spring-02.txt >>> >>> 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 >>> >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:[email protected]] On Behalf Of Xuxiaohu >>> Sent: Tuesday, March 3, 2015 11:10 PM >>> To: Xuxiaohu; [email protected]; <[email protected]>; [email protected] >>> Subject: Re: [sfc] New Version Notification for >>> draft-xu-sfc-using-mpls-spring-02.txt >>> >>> 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 protected]; '<[email protected]>'; [email protected] >>>> 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 protected] [mailto:[email protected]] >>>>> 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 >>> >>> _______________________________________________ >>> sfc mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/sfc > >_______________________________________________ >sfc mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
