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 > -----Original Message----- > From: Xuxiaohu > Sent: Friday, March 06, 2015 8:49 AM > To: 'Jim Guichard (jguichar)'; Ron Parker > Cc: [email protected]; <[email protected]>; [email protected] > Subject: RE: [sfc] New Version Notification for > draft-xu-sfc-using-mpls-spring-02.txt > > 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
