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
