[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

SFC                                                     J. Guichard, Ed.
Internet-Draft                                                   H. Song
Intended status: Informational                                    Huawei
Expires: October 8, 2018                                     J. Tantsura
                                                          Nuage Networks
                                                              J. Halpern
                                                                Ericsson
                                                           W. Henderickx
                                                                   Nokia
                                                            M. Boucadair
                                                                  Orange
                                                           April 6, 2018


NSH and Segment Routing Integration for Service Function Chaining (SFC)
                      draft-guichard-sfc-nsh-sr-01

Abstract

   This document describes two application scenarios where Network
   Service Header (NSH) and Segment Routing (SR) techniques can be
   deployed together to support Service Function Chaining (SFC) in an
   efficient manner while maintaining separation of the service and
   transport planes as originally intended by the SFC architecture.

   In the first scenario, an NSH-based SFC is created using SR as the
   transport between SFFs.  SR in this case is just one of many
   encapsulations that could be used to maintain the transport-
   independent nature of NSH-based service chains.

   In the second scenario, SR is used to represent each service hop of
   the NSH-based SFC as a segment within the segment-list.  SR and NSH
   in this case are integrated.

   In both scenarios SR is responsible for steering packets between SFFs
   of a given SFP while NSH is responsible for maintaining the integrity
   of the service plane, the SFC instance context, and any associated
   metadata.

   These application scenarios demonstrate that NSH and SR can work
   jointly and complement each other leaving the network operator with
   the flexibility to use whichever transport technology makes sense in
   specific areas of their network infrastructure, and still maintain an
   end-to-end service plane using NSH.







Guichard, et al.         Expires October 8, 2018                [Page 1]


Internet-Draft                 NSH-SR SFC                     April 2018


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 8, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  SFC Overview and Rationale  . . . . . . . . . . . . . . .   3
     1.2.  SFC within SR Networks  . . . . . . . . . . . . . . . . .   4
   2.  NSH-based SFC with SR-based transport tunnel  . . . . . . . .   4
   3.  SR-based SFC with integrated NSH service plane  . . . . . . .   9
   4.  Encapsulation Details . . . . . . . . . . . . . . . . . . . .  11
     4.1.  NSH using MPLS-SR Transport . . . . . . . . . . . . . . .  11
     4.2.  NSH using SRv6 Transport  . . . . . . . . . . . . . . . .  12
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13



Guichard, et al.         Expires October 8, 2018                [Page 2]


Internet-Draft                 NSH-SR SFC                     April 2018


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

1.1.  SFC Overview and Rationale

   The dynamic enforcement of a service-derived, adequate forwarding
   policy for packets entering a network that supports advanced Service
   Functions (SFs) has become a key challenge for operators and service
   providers.  Particularly, cascading SFs, for example at the Gi
   interface in the context of mobile network infrastructure, have shown
   their limits, such as the same redundant classification features must
   be supported by many SFs in order to execute their function, some SFs
   are receiving traffic that they are not supposed to process (e.g.,
   TCP proxies receiving UDP traffic), which inevitably affects their
   dimensioning and performance, an increased design complexity related
   to the properly ordered invocation of several SFs, etc.

   In order to solve those problems and to avoid the adherence with the
   underlying physical network topology while allowing for simplified
   service delivery, Service Function Chaining (SFC) techniques have
   been introduced.

   SFC techniques are meant to rationalize the service delivery logic
   and master the companion complexity while optimizing service
   activation time cycles for operators that need more agile service
   delivery procedures to better accommodate ever-demanding customer
   requirements.  Indeed, SFC allows to dynamically create service
   planes that can be used by specific traffic flows.  Each service
   plane is realized by invoking and chaining the relevant service
   functions in the right sequence.  RFC7498 [RFC7498] provides an
   overview of the SFC problem space and RFC7665 [RFC7665] specifies an
   SFC architecture.

   Many approaches can be considered for encoding the information
   required for SFC purposes (e.g., communicate a service chain pointer,
   encode a list of loose/explicit paths, disseminate a service chain
   identifier together with a set of context information, etc.).
   Likewise, many approaches can also be considered for the channel to
   be used to carry SFC-specific information (e.g., define a new header,
   re-use existing fields, define an IPv6 extension header, etc.).
   Among all these approaches, the IETF endorsed a transport-independent
   SFC encapsulation scheme: NSH [RFC8300]; which is the most mature SFC
   encapsulation solution.  This design is pragmatic as it does not
   require replicating the same specification effort as a function of
   underlying transport encapsulation.  Moreover, this design approach
   encourages consistent SFC-based service delivery in networks enabling
   distinct transport protocols in various segments of the network.



Guichard, et al.         Expires October 8, 2018                [Page 3]


Internet-Draft                 NSH-SR SFC                     April 2018


1.2.  SFC within SR Networks

   As described in [I-D.ietf-spring-segment-routing], Segment Routing
   (SR) leverages the source routing technique.  Concretely, a node
   steers a packet through an SR Policy instantiated as an ordered list
   of instructions called segments.  While initially designed for
   policy-based source routing, SR also finds its application in
   supporting SFC [I-D.xu-clad-spring-sr-service-chaining].  The two SR
   flavors, namely MPLS-SR [I-D.ietf-spring-segment-routing-mpls] and
   SRv6 [I-D.ietf-6man-segment-routing-header], can both encode a
   Service Function (SF) as a segment so that an SFC can be specified as
   a segment list.  Nevertheless, and as discussed in RFC7498 [RFC7498],
   traffic steering is only a subset of the issues that motivated the
   design of the SFC architecture.  Further considerations such as
   simplifying classification at intermediate SFs and allowing for
   coordinated behaviors among SFs by means of supplying context
   information should be taken into account when designing an SFC data
   plane solution.

   While each scheme (i.e., NSH-based SFC and SR-based SFC) can work
   independently, this document describes how the two can work together
   in concert and complement each other through two representative
   application scenarios.  Both application scenarios may be supported
   using either MPLS-SR or SRv6:

   o  NSH-based SFC with SR-based transport: in this scenario segment
      routing provides the transport encapsulation between SFFs while
      NSH is used to convey and trigger SFC polices.

   o  SR-based SFC with integrated NSH service plane: in this scenario
      each service hop of the SFC is represented as a segment of the SR
      segment-list.  SR is responsible for steering traffic through the
      necessary SFFs as part of the segment routing path and NSH is
      responsible for maintaining the service plane, and holding the SFC
      instance context and associated metadata.

   It is of course possible to combine both of these two scenarios so as
   to support specific deployment requirements and use cases.

2.  NSH-based SFC with SR-based transport tunnel

   Because of the transport-independent nature of NSH-based service
   chains, it is expected that the NSH has broad applicability across
   different domains of a network.  By way of illustration the various
   SFs involved in a service chain are available in a single data
   center, or spread throughout multiple locations (e.g., data centers,
   different POPs), depending upon the operator preference and/or
   availability of service resources.  Regardless of where the service



Guichard, et al.         Expires October 8, 2018                [Page 4]


Internet-Draft                 NSH-SR SFC                     April 2018


   resources are deployed it is necessary to provide traffic steering
   through a set of SFFs and NSH-based service chains provide the
   flexibility for the network operator to choose which particular
   transport encapsulation to use between SFFs, which may be different
   depending upon which area of the network the SFFs/SFs are currently
   deployed.  Therefore from an SFC architecture perspective, segment
   routing is simply one of multiple available transport encapsulations
   that can be used for traffic steering between SFFs.

   The following 3 figures provide an example of an SFC established for
   flow F that has SFs located in different data centers, DC1 and DC2.
   For the purpose of illustration, let the SFC's Service Path
   Identifier (SPI) be 100 and the initial Service Index (SI) be 255.

   Referring to Figure 1, packets of flow F in DC1 are classified into
   an NSH-based SFC and encapsulated after classification as <Inner
   Pkt><NSH: SPI 100, SI 255><Outer-transport> and forwarded to SFF1.

   After removing the outer transport encapsulation, that may or may not
   be MPLS-SR or SRv6, SFF1 uses the SPI, SI carried within the NSH
   encapsulation to determine that it should forward the packet to SF1.
   SF1 applies its service, decrements the SI by 1, and returns the
   packet to SFF1.  SFF1 therefore has <SPI 100, SI 254> when the packet
   comes back from SF1.  SFF1 does a lookup on <SPI 100, SI 254> which
   results in <next-hop: DC1-GW1> and forwards the packet to DC1-GW1.


























Guichard, et al.         Expires October 8, 2018                [Page 5]


Internet-Draft                 NSH-SR SFC                     April 2018


   +--------------------------- DC1 ----------------------------+
   |                          +-----+                           |
   |                          | SF1 |                           |
   |                          +--+--+                           |
   |                             |                              |
   |                             |                              |
   |        +------------+       |    +------------+            |
   |        | N(100,255) |       |    | F:Inner Pkt|            |
   |        +------------+       |    +------------+            |
   |        | F:Inner Pkt|       |    | N(100,254) |            |
   |        +------------+  ^    |  | +------------+            |
   |                    (2) |    |  | (3)                       |
   |                        |    |  v                           |
   |                  (1)        |         (4)                  |
   |+------------+   ---->    +--+---+    ---->     +---------+ |
   ||            |    NSH     |      |     NSH      |         | |
   || Classifier +------------+ SFF1 +--------------+ DC1-GW1 + |
   ||            |            |      |              |         | |
   |+------------+            +------+              +---------+ |
   |                                                            |
   |             +------------+       +------------+            |
   |             | N(100,255) |       | N(100,254) |            |
   |             +------------+       +------------+            |
   |             | F:Inner Pkt|       | F:Inner Pkt|            |
   |             +------------+       +------------+            |
   |                                                            |
   +------------------------------------------------------------+


                  Figure 1: SR for inter-DC SFC - Part 1

   Referring now to Figure 2 DC1-GW1 performs a lookup on the
   information conveyed in the NSH which results in <next-hop: DC2-GW1,
   encapsulation: SR>.  The SR encapsulation has the SR segment-list to
   forward the packet across the Inter-DC network to DC2.
















Guichard, et al.         Expires October 8, 2018                [Page 6]


Internet-Draft                 NSH-SR SFC                     April 2018


                     +----------- Inter DC ----------------+
                     |              (5)                    |
   +------+  ---->   | +---------+   ---->     +---------+ |
   |      |   NSH    | |         |     SR      |         | |
   + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + |
   |      |          | |         |             |         | |
   +------+          | +---------+             +---------+ |
                     |                                     |
                     |          +------------+             |
                     |          | S(DC2-GW1) |             |
                     |          +------------+             |
                     |          | N(100,254) |             |
                     |          +------------+             |
                     |          | F:Inner Pkt|             |
                     |          +------------+             |
                     +-------------------------------------+


                  Figure 2: SR for inter-DC SFC - Part 2

   When the packet arrives at DC2, as shown in Figure 3, the SR
   encapsulation is removed and DC2-GW1 performs a lookup on the NSH
   which results in <next-hop: SFF2.  The outer transport encapsulation
   may be any transport that is able to identify NSH as the next
   protocol.


























Guichard, et al.         Expires October 8, 2018                [Page 7]


Internet-Draft                 NSH-SR SFC                     April 2018


   +------------------------ DC2 ----------------------+
   |                       +-----+                     |
   |                       | SF2 |                     |
   |                       +--+--+                     |
   |                          |                        |
   |                          |                        |
   |        +------------+    |    +------------+      |
   |        | N(100,254) |    |    | F:Inner Pkt|      |
   |        +------------+    |    +------------+      |
   |        | F:Inner Pkt|    |    | N(100,253) |      |
   |        +------------+  ^ |  | +------------+      |
   |                    (7) | |  | (8)                 |
   |                        | |  v                     |
   |              (6)         |     (9)                |
   |+----------+   ---->    +--+---+ ---->             |
   ||          |    NSH     |      |  IP               |
   || DC2-GW1  +------------+ SFF2 |                   |
   ||          |            |      |                   |
   |+----------+            +------+                   |
   |                                                   |
   |          +------------+      +------------+       |
   |          | N(100,254) |      | F:Inner Pkt|       |
   |          +------------+      +------------+       |
   |          | F:Inner Pkt|                           |
   |          +------------+                           |
   +---------------------------------------------------+


                  Figure 3: SR for inter-DC SFC - Part 3

   The benefits of this scheme are listed hereafter:

   o  The network operator is able to take advantage of the transport-
      independent nature of the NSH encapsulation.

   o  The network operator is able to take advantage of the traffic
      steering capability of SR where appropriate.

   o  Light-weight NSH is used in the data center for SFC and avoids
      more complex hierarchical SFC schemes between data centers.

   o  Clear responsibility division and scope between NSH and SR.

   Note that this scenario is applicable to any case where multiple
   segments of a service chain are distributed into multiple domains or
   where traffic engineered paths are necessary between SFFs (RSPs
   typically).




Guichard, et al.         Expires October 8, 2018                [Page 8]


Internet-Draft                 NSH-SR SFC                     April 2018


3.  SR-based SFC with integrated NSH service plane

   In this scenario we assume that the SFs are NSH-aware and therefore
   it should not be necessary to implement an SFC proxy to achieve
   Service Function Chaining.  The operation relies upon SR to perform
   SFF-SFF transport and NSH to provide the service plane between SFs
   thereby maintaining SFC context and metadata.

   When a service chain is established, a packet associated with that
   chain will first encapsulate an NSH that will be used to maintain the
   end-to-end service plane through use of the SFC context.  The SFC
   context (e.g., the service plane path referenced by the SPI) is used
   by an SFF to determine the SR segment list for forwarding the packet
   to the next-hop SFFs.  The packet is then encapsulated using the
   (transport specific) SR header and forwarded in the SR domain
   following normal SR operation.

   When a packet has to be forwarded to an SF attached to an SFF, the
   SFF strips the SR information of the packet, updates the SR
   information, and saves it to a cache indexed by the NSH SPI.  This
   saved SR information is used to encapsulate and forward the packet(s)
   coming back from the SF.

   When the SF receives the packet, it processes it as usual and sends
   it back to the SFF.  Once the SFF receives this packet, it extracts
   the SR information using the NSH SPI as the index into the cache.
   The SFF then pushes the SR header on top of the NSH header, and
   forwards the packet to the next segment in the segment list.

   Figure 4 illustrates an example of this scenario.





















Guichard, et al.         Expires October 8, 2018                [Page 9]


Internet-Draft                 NSH-SR SFC                     April 2018


                        +-----+                       +-----+
                        | SF1 |                       | SF2 |
                        +--+--+                       +--+--+
                           |                             |
                           |                             |
             +-----------+ | +-----------+ +-----------+ | +-----------+
             |N(100,255) | | |F:Inner Pkt| |N(100,254) | | |F:Inner Pkt|
             +-----------+ | +-----------+ +-----------+ | +-----------+
             |F:Inner Pkt| | |N(100,254) | |F:Inner Pkt| | |N(100,253) |
             +-----------+ | +-----------+ +-----------+ | +-----------+
                     (2) ^ | (3) |                 (5) ^ | (6) |
                         | |     |                     | |     |
                         | |     v                     | |     v
   +------------+ (1)--> +-+----+       (4)-->        +---+--+ (7)-->IP
   |            | NSHoSR |      |       NSHoSR        |      |
   | Classifier +--------+ SFF1 +---------------------+ SFF2 |
   |            |        |      |                     |      |
   +------------+        +------+                     +------+

                +------------+     +------------+
                |   S(SF1)   |     |   S(SF2)   |
                +------------+     +------------+
                |   S(SFF2)  |     | N(100,254) |
                +------------+     +------------+
                |   S(SF2)   |     | F:Inner Pkt|
                +------------+     +------------+
                | N(100,255) |
                +------------+
                | F:Inner Pkt|
                +------------+


                       Figure 4: NSH over SR for SFC

   The benefits of this scheme include:

   o  It is economically sound for SF vendors to only support one
      unified SFC solution.  The SF is unaware of the SR.

   o  It simplifies the SFF (i.e., the SR router) by nullifying the
      needs for re-classification and SR proxy.

   o  It provides a unique and standard way to pass metadata to SFs.
      Note that currently there is no solution for MPLS-SR to carry
      metadata and there is no solution to pass metadata to SR-unaware
      SFs.

   o  SR is also used for forwarding purposes including between SFFs.



Guichard, et al.         Expires October 8, 2018               [Page 10]


Internet-Draft                 NSH-SR SFC                     April 2018


   o  It takes advantage of SR to eliminate the NSH forwarding state in
      SFFs.  This applies each time strict or loose SFPs are in use.

   o  It requires no interworking as would be the case if MPLS-SR based
      SFC and NSH-based SFC were deployed as independent mechanisms in
      different parts of the network.

4.  Encapsulation Details

4.1.  NSH using MPLS-SR Transport

   MPLS-SR instantiates Segment IDs (SIDs) as MPLS labels and therefore
   the segment routing header is a stack of MPLS labels.

   When carrying NSH within an MPLS-SR transport, the full encapsulation
   headers are as illustrated in Figure 5.


                          +------------------+
                          ~   MPLS-SR Labels ~
                          +------------------+
                          |   NSH Base Hdr   |
                          +------------------+
                          | Service Path Hdr |
                          +------------------+
                          ~     Metadata     ~
                          +------------------+


                   Figure 5: NSH using MPLS-SR Transport

   As described in [I-D.ietf-spring-segment-routing] the IGP signaling
   extension for IGP-Prefix segment includes a flag to indicate whether
   directly connected neighbors of the node on which the prefix is
   attached should perform the NEXT operation or the CONTINUE operation
   when processing the SID.  When NSH is carried beneath MPLS-SR it is
   necessary to terminate the NSH-based SFC at the tail-end node of the
   MPLS-SR label stack.  This is the equivalent of MPLS Ultimate Hop
   Popping (UHP) and therefore the prefix-SID associated with the tail-
   end of the SFC MUST be advertised with the CONTINUE operation so that
   the penultimate hop node does not pop the top label of the MPLS-SR
   label stack and thereby expose NSH to the wrong SFF.  It is
   RECOMMENDED that a specific prefix-SID be allocated at each node for
   use by the SFC application for this purpose.

   At the end of the MPLS-SR path it is necessary to provide an
   indication to the tail-end that NSH follows the MPLS-SR label stack.




Guichard, et al.         Expires October 8, 2018               [Page 11]


Internet-Draft                 NSH-SR SFC                     April 2018


   There are several ways to achieve this but its specification is
   outside the scope of this document.

4.2.  NSH using SRv6 Transport

   When carrying NSH within an SRv6 transport the full encapsulation is
   as illustrated in Figure 6.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Next Header   |  Hdr Ext Len  | Routing Type  | Segments Left |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Last Entry   |     Flags     |              Tag              | S
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e
     |                                                               | g
     |            Segment List[0] (128 bits IPv6 address)            | m
     |                                                               | e
     |                                                               | n
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t
     |                                                               |
     |                                                               | R
     ~                              ...                              ~ o
     |                                                               | u
     |                                                               | t
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i
     |                                                               | n
     |            Segment List[n] (128 bits IPv6 address)            | g
     |                                                               |
     |                                                               | S
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
     //                                                             // H
     //         Optional Type Length Value objects (variable)       //
     //                                                             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Ver|O|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
     |          Service Path Identifier              | Service Index | S
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
     |                                                               |
     ~              Variable-Length Context Headers  (opt.)          ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                    Figure 6: NSH using SRv6 Transport




Guichard, et al.         Expires October 8, 2018               [Page 12]


Internet-Draft                 NSH-SR SFC                     April 2018


5.  Security Considerations

   Generic SFC-related security considerations are discussed in RFC7665
   [RFC7665].  NSH-specific security considerations are discussed in
   RFC8300 [RFC8300].

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Acknowledgments

   TBD.

8.  References

8.1.  Normative References

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-15 (work
              in progress), January 2018.

   [I-D.ietf-spring-segment-routing-mpls]
              Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing with MPLS
              data plane", draft-ietf-spring-segment-routing-mpls-12
              (work in progress), February 2018.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

8.2.  Informative References










Guichard, et al.         Expires October 8, 2018               [Page 13]


Internet-Draft                 NSH-SR SFC                     April 2018


   [I-D.ietf-6man-segment-routing-header]
              Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
              Field, B., daniel.voyer@bell.ca, d.,
              daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
              Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
              D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
              Header (SRH)", draft-ietf-6man-segment-routing-header-09
              (work in progress), March 2018.

   [I-D.xu-clad-spring-sr-service-chaining]
              Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
              d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano,
              S., and S. Ma, "Segment Routing for Service Chaining",
              draft-xu-clad-spring-sr-service-chaining-00 (work in
              progress), December 2017.

   [RFC7498]  Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
              Service Function Chaining", RFC 7498,
              DOI 10.17487/RFC7498, April 2015,
              <https://www.rfc-editor.org/info/rfc7498>.

Authors' Addresses

   James N Guichard (editor)
   Huawei
   2330 Central Express Way
   Santa Clara
   USA

   Email: james.n.guichard@huawei.com


   Haoyu Song
   Huawei
   2330 Central Express Way
   Santa Clara
   USA

   Email: haoyu.song@huawei.com


   Jeff Tantsura
   Nuage Networks
   USA

   Email: jefftant.ietf@gmail.com





Guichard, et al.         Expires October 8, 2018               [Page 14]


Internet-Draft                 NSH-SR SFC                     April 2018


   Joel Halpern
   Ericsson
   USA

   Email: joel.halpern@ericsson.com


   Wim Henderickx
   Nokia
   USA

   Email: wim.henderickx@nokia.com


   Mohamed Boucadair
   Orange
   USA

   Email: mohamed.boucadair@orange.com
































Guichard, et al.         Expires October 8, 2018               [Page 15]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/