[mpls] Proposed text changes to draft-ietf-mpls-sfc

["Adrian Farrel" <[e-mail]>]

Hi WG,

There were two areas of discussion about this document. The first concerned
whether it would really be possible to use the "MPLS-encoded logical NSH" as a
transition technology utilising existing MPLS devices. The second was to give
some use-case explanation for a label stack approach that is distinctly not
Segment Routing.

On April 4th I offered to draft some text on these topics and since no one
demurred I have (finally) done so and discussed it with my co-authors.

Here are the proposed changes.

Cheers,
Adrian

===

Section 1, near the end
ADD
   Section 4 provides a short overview of several use case scenarios
   that help to explain the relationship between the MPLS label
   operations (swapping, popping, stacking) and the MPLS encoding of
   the logical NSH described in this document).
END

---

New Section 4
ADD
4.  Use Case Scenarios

   There are five scenarios that can be considered for the use of an
   MPLS encoding in support of SFC.  These are set out in the following
   sub-sections.

4.1.  Label Swapping for Logical NSH

   The primary use case for SFC is described in [RFC7665] and delivered
   using the NSH which, as described in [RFC8300], uses an encapsulation
   that is modified at each SFC hop along the chain to indicate the next
   hop.

   The label swapping use case scenario effectively replaces the NSH
   with an MPLS encapsulation as described in Section 6.  The MPLS
   labels encode the same information as the NSH to form a logical NSH.
   The labels are modified (swapped per [RFC3031]) at each SFC hop along
   the chain to indicate the next hop.  The processing and forwarding
   state for a chain (i.e., the actions to take on a received label) are
   programmed in to the network using a control plane or management
   plane.

4.2.  Hierarchical Encapsulation

   [I-D.ietf-sfc-hierarchical] describes an architecture for
   hierarchical encapsulation using the NSH.  It facilitates
   partitioning of SFC domains for administrative reasons, and allows
   concatenation of service function chains under the control of a
   service classifier.

   The same function can be achieved in an MPLS network using an MPLS
   encoding of the logical NSH, and label stacking as defined in
   [RFC3031] and described in Section 7.  In this model, swapping is
   used per Section 4.1 to navigate one chain, and when the end of the
   chain is reached, the final label is popped revealing the label for
   another chain.  Thus, the primary mode is swapping, but stacking is
   used to enable the ingress classifier to control concatenation of
   service function chains.

4.3.  Fine Control of Service Function Instances

   It may be that a service function chain (as described in Section 4.1
   allows some leeway in the choice of service function instances along
   the chain.  However, it may be that a service classifier wishes to
   constrain the choice and this can be achieved using chain
   concatenation so that the first chain ends at the point of choice,
   the next label in the stack indicates the specific service function
   instance to be executed, and the next label in the stack starts a new
   chain.  Thus, a mixture of label swapping and stacking is used.

4.4.  Micro Chains and Label Stacking

   The scenario in Section 4.2 may be extended to its logical extreme by
   making each concatenated chain as short as it can be: one service
   function.  Each label in the stack indicates the next service
   function to be executed, and the network is programmed through the
   control plane or management plane to know how to route to the next
   (i.e., first) hop in each chain just as it would be to support the
   scenarios in Section 4.1 and Section 4.2.

4.5.  SFC and Segment Routing

   Segment Routing (SR) in an MPLS network (known as MPLS-SR) uses a
   stack of MPLS labels to encode information about the path and network
   functions that a packet should traverse.  MPLS-SR is achieved by
   applying control plane and management plane techniques to program the
   MPLS forwarding plane, and by imposing labels on packets at the
   entrance to the MPLS-SR network.

   The application of SR to SFC was considered in early versions of the
   SR architecture [I-D.ietf-spring-segment-routing] and the MPLS-SR
   specification [I-D.ietf-spring-segment-routing-mpls], but has since
   been moved out of those documents.  An implementation proposal for
   achieving SFC using MPLS-SR can be found in
   [I-D.xuclad-spring-sr-service-chaining] and is not discussed further
   in this document.
END

---

Section 13 (was 12) new first paragraph
ADD
   This section reverts to the simplified descriptions of networks that
   rely wholly on label swapping or label stacking.  As described in
   Section 4, actual deployment scenarios may depend on the use of both
   mechanisms and utilize a mixed mode as described in Section 8.
END

---

New Section 14
ADD
14.  Implementation Notes

   It is not the job of an IETF specification to describe the internals
   of an implementation except where that directly impacts upon the bits
   on the wire that change the likelihood of interoperability, or where
   the availability of configuration or security options directly affect
   the utility of an implementation.

   However, in view of the objective of this document to acknowledge
   that there may be a need for an interim deployment of SFC
   functionality in brownfield MPLS networks, this section provides some
   observations about how an SFF might utilize MPLS features that are
   available in existing routers.  This section is not intended to be
   definitive or technically complete, but is indicative.

   Consider the mechanism used to indicate to which Virtual Routing and
   Forwarding (VRF) an incoming MPLS packet should be routed in a Layer
   3 Virtual Private Network (L3VPN) [RFC4364].  In this case, the top
   MPLS label is an indicator of the VRF that is to be used to route the
   payload.

   A similar approach can be taken with the label swapping SFC technique
   described in Section 6 such that the SFC Context Label identifies a
   routing table specific to the SFP.  The SF Label can be looked up in
   the context of this routing table to determine to which SF to direct
   the packet, and how to forward it to the next SFF.

   Advanced features (such as metadata) are not inspected by SFFs.  The
   packets are passed to SFIs that are MPLS-SFC-aware or to SFC proxies,
   and those components are responsible for handling all metadata
   issues.

   Of course, an actual implementation might make considerable
   optimizations on this approach, but this section should provide hints
   about how MPLS-based SFC might be achieved with relatively small
   modifications to deployed MPLS devices.
END