Re: [mpls] [sfc] An MPLS Forwarding plane for SFC

Hi,

> I believe that the approach as Adrian outlines is very pragmatic.

Thanks, Gunter.

A few points...

- As I said in my email and as we note in the draft, this approach is somewhat
   limited when compared to the full function that can be achieved with the
   NSH. 
- I quite understand that this is not the approach that the SFC working group
  adopted, and that the reasons for the development of the NSH were driven
  both by technical concerns and by constraints of the WG charter.
- This proposal is not intended as antagonistic competition to the work of 
  the SFC working group. Indeed, we have been sitting on this draft waiting
  for the NSH draft to progress.
- But we are offering a pragmatic alternative that can deliver a subset of NSH
   function in a well-known environment. Our hope is that the SFF can be
   achieved with off-the-shelf MPLS hardware.
- I copied my email to the SFC list because that seemed the polite and right
   thing to do, not because I think that working group should be developing
   this solution. IMHO, this wok belongs in the MPLS working group.

Cheers,
Adrian

> Joel, not sure I agree about being bound by transport mechanism when using
> MPLS, as the MPLS sequenced labels can be transported over any type of 
> transport just like NSH could be transported.
> For sure there is as Adrian mentions a trade-off regarding flexibility, so each will
> find its application realm.
> For many the flexibility in the sequenced MPLS label approach will be sufficient
> for business purpose.
> 
> G/
> 
> 
> On 01/09/2017, 22:25, "sfc on behalf of Joel M. Halpern" <sfc-bounces@ietf.org
> on behalf of jmh@joelhalpern.com> wrote:
> 
>     Reading this draft, what you have proposed is a specific transport
>     mechanism, using MPLS.  By removing the NSH header, you remove the
>     transport agnostic properties that the Working Group was specifically
>     chartered to achieve.
>     By recasting the metadata into a label sequence, you make any metaata
>     processing significantly harder, and make applications dependent upon
>     the MPLS transport, rather than being able to rely on the NSH format.
>     If this pattern were followed for other transports, we would require SFF
>     and SF which understood how to parse and process all of the different
>     transport encodings of the path, and SF would have to understand all the
>     different transport encodings of the metadata.
> 
>     Why is this beneficial?
> 
>     If what you want to do is carry NSH, with an MPLS label stack that
>     represents the whole sequence of places to visit, we would still have to
>     assume that SF preserved the MPLS stack, but their processing, assuming
>     they could find the carried NSH header under the MPLS stack, would at
>     least be independent of the transport.
> 
>     Yours,
>     Joel
> 
>     On 9/1/17 4:15 PM, Adrian Farrel wrote:
>     > Hi,
>     >
>     > We've been working up some ideas for using an MPLS forwarding plane
> (switching
>     > or SR) for SFC.
>     >
>     > We have constrained ourselves to the architecture developed by the SFC
> working
>     > group, and have used the NSH as a functional model.
>     >
>     > MPLS is somewhat limited compared to the NSH encapsulation, so there is a
>     > trade-off between using a new encapsulation with full function and a good
> set of
>     > function using an existing forwarding plane.
>     >
>     > At the moment this is an early version of our work, but we thought you'd like
> to
>     > see our thought processes.
>     >
>     > (FWIW draft-ietf-bess-nsh-bgp-control-plane is applicable to NSH or MPLS
>     > encapsulations and includes mechanisms to select between the two.)
>     >
>     > Cheers,
>     > Adrian
>     >
>     >> -----Original Message-----
>     >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
>     >> internet-drafts@ietf.org
>     >> Sent: 01 September 2017 21:00
>     >> To: i-d-announce@ietf.org
>     >> Subject: I-D Action: draft-farrel-mpls-sfc-00.txt
>     >>
>     >>
>     >> A New Internet-Draft is available from the on-line Internet-Drafts
>     > directories.
>     >>
>     >>
>     >>          Title           : An MPLS-Based Forwarding Plane for Service Function
>     > Chaining
>     >>          Authors         : Adrian Farrel
>     >>                            Stewart Bryant
>     >>                            John Drake
>     >> 	Filename        : draft-farrel-mpls-sfc-00.txt
>     >> 	Pages           : 23
>     >> 	Date            : 2017-09-01
>     >>
>     >> Abstract:
>     >>     Service Function Chaining (SFC) is the process of directing packets
>     >>     through a network so that they can be acted on by an ordered set of
>     >>     abstract service functions before being delivered to the intended
>     >>     destination.  An architecture for SFC is defined in RFC7665.
>     >>
>     >>     The Network Service Header (NSH) can be inserted into packets to
>     >>     steer them along a specific path to realize a Service Function Chain.
>     >>
>     >>     Multiprotocol Label Switching (MPLS) is a widely deployed forwarding
>     >>     technology that uses labels to identify the forwarding actions to be
>     >>     taken at each hop through a network.  Segment Routing is a mechanism
>     >>     that provides a source routing paradigm for steering packets in an
>     >>     MPLS network.
>     >>
>     >>     This document describes how Service Function Chaining can be achieved
>     >>     in an MPLS network by means of a logical representation of the NSH in
>     >>     an MPLS label stack.
>     >>
>     >>
>     >>
>     >> The IETF datatracker status page for this draft is:
>     >> https://datatracker.ietf.org/doc/draft-farrel-mpls-sfc/
>     >>
>     >> There are also htmlized versions available at:
>     >> https://tools.ietf.org/html/draft-farrel-mpls-sfc-00
>     >> https://datatracker.ietf.org/doc/html/draft-farrel-mpls-sfc-00
>     >>
>     >>
>     >> 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.
>     >>
>     >> Internet-Drafts are also available by anonymous FTP at:
>     >> ftp://ftp.ietf.org/internet-drafts/
>     >>
>     >> _______________________________________________
>     >> I-D-Announce mailing list
>     >> I-D-Announce@ietf.org
>     >> https://www.ietf.org/mailman/listinfo/i-d-announce
>     >> Internet-Draft directories: http://www.ietf.org/shadow.html
>     >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>     >
>     > _______________________________________________
>     > sfc mailing list
>     > sfc@ietf.org
>     > https://www.ietf.org/mailman/listinfo/sfc
>     >
> 
>     _______________________________________________
>     sfc mailing list
>     sfc@ietf.org
>     https://www.ietf.org/mailman/listinfo/sfc
> 