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

[<[e-mail]>]

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:[e-mail]] De la part de Adrian Farrel
> Envoyé : lundi 4 septembre 2017 11:27
> À : 'Van De Velde, Gunter (Nokia - BE/Antwerp)'; 'Joel M. Halpern';
> [e-mail]
> 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-
> [e-mail]
> > on behalf of [e-mail]> 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:[e-mail]] On
> Behalf Of
> >     >> [e-mail]
> >     >> Sent: 01 September 2017 21:00
> >     >> To: [e-mail]
> >     >> 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
> >     >> [e-mail]
> >     >> 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
> >     > [e-mail]
> >     > https://www.ietf.org/mailman/listinfo/sfc
> >     >
> >
> >     _______________________________________________
> >     sfc mailing list
> >     [e-mail]
> >     https://www.ietf.org/mailman/listinfo/sfc
> >
> 
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc