[mpls] What to do with draft-ietf-mpls-sfc-00.txt

WG,

Would it help if we added use cases to this document? Usually, the IESG frowns
on use cases, but it sounds as though this document needs some further
explanation.

Of course, not everyone likes every proposed use case. Some will say, "I don't
need that." Others will say, "I have another way, or I prefer a different way,
of achieving that."

Adding such a section would allow the inclusion of some text saying (something
like) "A use case is to achieve SFC in an MPLS-SR network, but that is discussed
in draft-xuclad-spring-sr-service-chaining."

Additionally, I have been wondering how to handle the discussion of using this
function in a brownfield network. Normally we don't tell people in our specs how
to build their boxes - we make protocol specs not design documents. However, if
in addition to how I would build this, I can see a (somewhat clunky) method to
achieve this function in existing platforms, would it be worth adding that?

Cheers,
Adrian

> -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: 04 April 2018 10:28
> To: i-d-announce@ietf.org
> Cc: mpls@ietf.org
> Subject: [mpls] I-D Action: draft-ietf-mpls-sfc-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Multiprotocol Label Switching WG of the IETF.
> 
>         Title           : An MPLS-Based Forwarding Plane for Service Function
Chaining
>         Authors         : Adrian Farrel
>                           Stewart Bryant
>                           John Drake
> 	Filename        : draft-ietf-mpls-sfc-00.txt
> 	Pages           : 24
> 	Date            : 2018-03-28
> 
> 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 placed in a packet in a label stack to
>    identify the forwarding actions to be taken at each hop through a
>    network.  Actions may include swapping or popping the labels as well,
>    as using the labels to determine the next hop for forwarding the
>    packet.  Labels may also be used to establish the context under which
>    the packet is forwarded.
> 
>    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.  It does not deprecate or replace the NSH, but
>    acknowledges that there may be a need for an interim deployment of
>    SFC functionality in brownfield networks.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-mpls-sfc-00
> https://datatracker.ietf.org/doc/html/draft-ietf-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/
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls