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

<mohamed.boucadair@orange.com> Thu, 21 September 2017 09:04 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401B11344FC; Thu, 21 Sep 2017 02:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvQgkwTsdJnF; Thu, 21 Sep 2017 02:04:13 -0700 (PDT)
Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCFE1344B7; Thu, 21 Sep 2017 02:02:43 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 6651360671; Thu, 21 Sep 2017 11:02:41 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 43A1018006A; Thu, 21 Sep 2017 11:02:41 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0361.001; Thu, 21 Sep 2017 11:02:40 +0200
From: mohamed.boucadair@orange.com
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Van De Velde, Gunter (Nokia - BE/Antwerp)'" <gunter.van_de_velde@nokia.com>, "'Joel M. Halpern'" <jmh@joelhalpern.com>, "mpls@ietf.org" <mpls@ietf.org>
CC: 'Service Function Chaining IETF list' <sfc@ietf.org>
Thread-Topic: [sfc] An MPLS Forwarding plane for SFC
Thread-Index: AdMjXxXVPkarGltYRZ25UDV5w+jgOv//4TmAgAPeI4CAACDZgP/lNE4w
Date: Thu, 21 Sep 2017 09:02:40 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A046ED4@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <034601d3235f$1f4ef590$5dece0b0$@olddog.co.uk> <f9620aae-d138-8478-8f3b-f021ad016603@joelhalpern.com> <A645332D-72B7-4E86-949F-2B18987BF9AE@nokia.com> <04bb01d3255f$f53a5d00$dfaf1700$@olddog.co.uk>
In-Reply-To: <04bb01d3255f$f53a5d00$dfaf1700$@olddog.co.uk>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/WBQIiBVqWe7ehCBeHQpX3MuTjek>
Subject: Re: [mpls] [sfc] An MPLS Forwarding plane for SFC
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Sep 2017 09:04:16 -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:sfc-bounces@ietf.org] De la part de Adrian Farrel
> Envoyé : lundi 4 septembre 2017 11:27
> À : 'Van De Velde, Gunter (Nokia - BE/Antwerp)'; 'Joel M. Halpern';
> mpls@ietf.org
> Cc : 'Service Function Chaining IETF list'
> Objet : Re: [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
> >
> 
> 
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc