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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
