Hi Jim, Understood.
Best regards, Xiaohu > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:[email protected]] > Sent: Thursday, March 05, 2015 11:11 PM > To: Ron Parker; Xuxiaohu > Cc: [email protected]; <[email protected]>; [email protected] > Subject: Re: [sfc] New Version Notification for > draft-xu-sfc-using-mpls-spring-02.txt > > 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
