Subject: [mpls] An MPLS Forwarding plane for SFC

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 Sep 2017 21:15:55 +0100

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:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 01 September 2017 21:00
> To: [email-masked]
> 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
> [email-masked]
> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 1 Sep 2017 16:25:33 -0400

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

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 4 Sep 2017 07:29:23 +0000

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

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" <[email-masked] on behalf of [email-masked]> wrote:

    Why is this beneficial?

    Yours,
    Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 4 Sep 2017 10:26:57 +0100

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.

---

From: <[email-masked]>
Date: Thu, 21 Sep 2017 09:02:40 +0000

Hi Adrian, all,

Fully agree, this is a pragmatic solution for a given type of networks. That's said, there are some implications on SFs, that need to be MPLS-aware too. Of course, if your take is that supplying metadata to SFs won't fly, then this confirms again the pragmatism of the proposal for a particular deployment case. 

FWIW, we have considered in the past a similar approach for IPv6-enbaled networks (https://tools.ietf.org/html/draft-jacquenet-sfc-ipv6-eh-01). It has the merit to have the same expectations on routers as for SR. 

For all these proposals, a new behavior is needed to be followed by SFC-aware nodes. What differs is the channel used to signal a chain and to supply additional data for SFC purposes. 

Leveraging on existing code/capabilities is good for a vendor/implementer, but the risk is that a given solution will need to support all/many of these flavors. Which is not optimal. 

Putting aside which WG will work on what, we need to think about this collectively. 

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Adrian Farrel
> Envoyé : lundi 4 septembre 2017 11:27
> À : 'Van De Velde, Gunter (Nokia - BE/Antwerp)'; 'Joel M. Halpern';
> [email-masked]
> Cc : 'Service Function Chaining IETF list'
> Objet : Re: [sfc] An MPLS Forwarding plane for SFC
> 
> Hi,
> 
> > 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-
> [email-masked]
> > on behalf of [email-masked]> wrote:
> >
> >     > 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
> >     > trade-off between using a new encapsulation with full function and
> a good
> > set of
> >     > At the moment this is an early version of our work, but we thought
> you'd like
> > to