[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-filsfils-spring-srv6-network-programming) 00 01 02 03 04

SPRING                                                  C. Filsfils, Ed.
Internet-Draft                                         P. Camarillo, Ed.
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: April 9, 2020                                          J. Leddy
                                                  Individual Contributor
                                                                D. Voyer
                                                             Bell Canada
                                                           S. Matsushima
                                                                SoftBank
                                                                   Z. Li
                                                     Huawei Technologies
                                                         October 7, 2019


                        SRv6 Network Programming
             draft-ietf-spring-srv6-network-programming-04

Abstract

   This document describes the SRv6 network programming concept and its
   most basic functions.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

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 April 9, 2020.





Filsfils, et al.          Expires April 9, 2020                 [Page 1]


Internet-Draft          SRv6 Network Programming            October 2019


Copyright Notice

   Copyright (c) 2019 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  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  SRv6 SID  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  SID format  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  SID reachability  . . . . . . . . . . . . . . . . . . . .   7
   4.  Behaviors associated with a SID . . . . . . . . . . . . . . .   8
     4.1.  End: Endpoint . . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  End.X: Layer-3 cross-connect  . . . . . . . . . . . . . .  10
     4.3.  End.T: Specific IPv6 table lookup . . . . . . . . . . . .  11
     4.4.  End.DX6: Decapsulation and IPv6 cross-connect . . . . . .  12
     4.5.  End.DX4: Decapsulation and IPv4 cross-connect . . . . . .  13
     4.6.  End.DT6: Decapsulation and specific IPv6 table lookup . .  14
     4.7.  End.DT4: Decapsulation and specific IPv4 table lookup . .  15
     4.8.  End.DT46: Decapsulation and specific IP table lookup  . .  16
     4.9.  End.DX2: Decapsulation and L2 cross-connect . . . . . . .  17
     4.10. End.DX2V: Decapsulation and VLAN L2 table lookup  . . . .  18
     4.11. End.DT2U: Decapsulation and unicast MAC L2 table lookup .  18
     4.12. End.DT2M: Decapsulation and L2 table flooding . . . . . .  19
     4.13. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps  20
     4.14. End.B6.Encaps.Red: [...] with reduced SRH . . . . . . . .  21
     4.15. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . .  22
     4.16. Flavors . . . . . . . . . . . . . . . . . . . . . . . . .  24
       4.16.1.  PSP: Penultimate Segment Pop of the SRH  . . . . . .  24
       4.16.2.  USP: Ultimate Segment Pop of the SRH . . . . . . . .  24
       4.16.3.  USD: Ultimate Segment Decapsulation  . . . . . . . .  24
   5.  Transit behaviors . . . . . . . . . . . . . . . . . . . . . .  26
     5.1.  T: Transit behavior . . . . . . . . . . . . . . . . . . .  26
     5.2.  T.Encaps: Transit with encapsulation in an SRv6 Policy  .  26
     5.3.  T.Encaps.Red: Transit with reduced encapsulation  . . . .  27
     5.4.  T.Encaps.L2: Transit with encapsulation of L2 frames  . .  28
     5.5.  T.Encaps.L2.Red: Transit with reduced encaps of L2 frames  28



Filsfils, et al.          Expires April 9, 2020                 [Page 2]


Internet-Draft          SRv6 Network Programming            October 2019


   6.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .  29
     6.1.  Counters  . . . . . . . . . . . . . . . . . . . . . . . .  29
     6.2.  Flow-based hash computation . . . . . . . . . . . . . . .  29
     6.3.  OAM . . . . . . . . . . . . . . . . . . . . . . . . . . .  29
   7.  Basic security for intra-domain deployment  . . . . . . . . .  30
   8.  Control Plane . . . . . . . . . . . . . . . . . . . . . . . .  30
     8.1.  IGP . . . . . . . . . . . . . . . . . . . . . . . . . . .  30
     8.2.  BGP-LS  . . . . . . . . . . . . . . . . . . . . . . . . .  31
     8.3.  BGP IP/VPN/EVPN . . . . . . . . . . . . . . . . . . . . .  31
     8.4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  31
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  32
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  35
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  35
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  38
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  38
     12.2.  Informative References . . . . . . . . . . . . . . . . .  38
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40


































Filsfils, et al.          Expires April 9, 2020                 [Page 3]


Internet-Draft          SRv6 Network Programming            October 2019


1.  Introduction

   Segment Routing leverages the source routing paradigm.  An ingress
   node steers a packet through an ordered list of instructions, called
   segments.  Each one of these instructions represents a function to be
   called at a specific location in the network.  A function is locally
   defined on the node where it is executed and may range from simply
   moving forward in the segment list to any complex user-defined
   behavior.  The network programming consists in combining segment
   routing functions, both simple and complex, to achieve a networking
   objective that goes beyond mere packet routing.

   This document defines the SRv6 Network Programming concept and aims
   at standardizing the main segment routing behaviors to enable the
   creation of interoperable overlays with underlay optimization and
   service programming.

   The companion document
   [I-D.filsfils-spring-srv6-net-pgm-illustration] illustrates the
   concepts defined in this document.

   Familiarity with the Segment Routing Header
   [I-D.ietf-6man-segment-routing-header] is assumed.

2.  Terminology

   Terminology used within this document is defined in detail in
   [RFC8402].  Specifically, the terms: Segment Routing, SR Domain,
   SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy.

   SRH: Segment Routing Header as defined in
   [I-D.ietf-6man-segment-routing-header].  We assume that the SRH may
   be present multiple times inside each packet.

   NH: Next-header field of the IPv6 header.  NH=SRH means that the
   next-header of the IPv6 header is Routing Header for IPv6(43) with
   the Type field set to 4.

   SL: The Segments Left field of the SRH

   FIB: Forwarding Information Base.  A FIB lookup is a lookup in the
   forwarding table.

   SA: Source Address

   DA: Destination Address





Filsfils, et al.          Expires April 9, 2020                 [Page 4]


Internet-Draft          SRv6 Network Programming            October 2019


   SRv6 SID function: The function part of the SID is an opaque
   identification of a local behavior bound to the SID.  It is formally
   defined in Section 3.1 of this document.

   SRv6 segment behavior: A packet processing behavior executed at an
   SRv6 segment endpoint.  Section 4 of this document defines behaviors
   related to traffic-engineering and both L2VPN and L3VPN use-cases.
   Other behaviors (e.g. service programming) are outside the scope of
   this document.

   An SR Policy is resolved to a SID list.  A SID list is represented as
   <S1, S2, S3> where S1 is the first SID to visit, S2 is the second SID
   to visit and S3 is the last SID to visit along the SR path.

   (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:

   - Source Address is SA, Destination Address is DA, and next-header is
     SRH

   - SRH with SID list <S1, S2, S3> with Segments Left = SL

   - Note the difference between the <> and () symbols: <S1, S2, S3>
     represents a SID list where S1 is the first SID and S3 is the last
     SID to traverse.  (S3, S2, S1; SL) represents the same SID list but
     encoded in the SRH format where the rightmost SID in the SRH is the
     first SID and the leftmost SID in the SRH is the last SID.  When
     referring to an SR policy in a high-level use-case, it is simpler
     to use the <S1, S2, S3> notation.  When referring to an
     illustration of the detailed packet behavior, the (S3, S2, S1; SL)
     notation is more convenient.

   - The payload of the packet is omitted.

   When a packet is intercepted on a wire, it is possible that SRH[SL]
   is different from the DA.
















Filsfils, et al.          Expires April 9, 2020                 [Page 5]


Internet-Draft          SRv6 Network Programming            October 2019


3.  SRv6 SID

   As introduced in RFC8402 an SRv6 Segment Identifier is a 128-bit
   value.

   When an SRv6 SID is in the Destination Address field of an IPv6
   header of a packet, it is routed through an IPv6 network as an IPv6
   address.

   Its processing is defined in [I-D.ietf-6man-segment-routing-header]
   section 4.3 and reproduced here as a reminder.

      Without constraining the details of an implementation, the SR
      segment endpoint node creates Forwarding Information Base (FIB)
      entries for its local SIDs.

      When an SRv6-capable node receives an IPv6 packet, it performs a
      longest-prefix-match lookup on the packets destination address.
      This lookup can return any of the following:

      - A FIB entry that represents a locally instantiated SRv6 SID

      - A FIB entry that represents a local interface, not locally
        instantiated as an SRv6 SID

      - A FIB entry that represents a non-local route

      - No Match

   This document formally defines behaviors and parameters for SRv6
   SIDs.

3.1.  SID format

   An SRv6 SID is represented as LOC:FUNCT where LOC (locator) is the L
   most significant bits and FUNCT (function) is the 128-L least
   significant bits of the SID.  L is called the locator length and is
   flexible.  Each operator is free to use the locator length it
   chooses.  Most often the locator is routable and leads to the node
   which instantiates that SID.  A control-plane protocol might
   represent the locator as B:N where B is the SRv6 SID block (IPv6
   subnet allocated for SRv6 SIDs by the operator) and N is the
   identifier of the parent node.

   The function part of the SID is an opaque identification of a local
   behavior bound to the SID.  The FUNCT value zero is invalid.





Filsfils, et al.          Expires April 9, 2020                 [Page 6]


Internet-Draft          SRv6 Network Programming            October 2019


   The terminology "function" refers to the bit-string in the SRv6 SID.
   The terminology "behavior" identifies the pseudocode bound to the
   SID.  The behaviors are defined in Section 4 of this document.

   A behavior may require additional arguments that would be placed
   immediately after the FUNCT.  In such case, the SRv6 SID will have
   the form LOC:FUNCT:ARGS::. For this reason, the SRv6 SIDs are matched
   on a per longest-prefix-match basis.

   ARG may contain information related to the flow, service, or any
   other information required by FUNCT.  The ARG value of a routed SID
   SHOULD remain constant among packets in a given flow.  Varying ARG
   values among packets in a flow may result in different ECMP hashing
   and cause re-ordering.

3.2.  SID reachability

   Most often, the node N would advertise IPv6 prefix(es) matching the
   LOC parts covering its SIDs or shorter-mask prefix.  The distribution
   of these advertisements and calculation of their reachability are
   routing protocol specific aspects that are outside the scope of this
   document.

   An SRv6 SID is said to be routed if its SID belongs to an IPv6 prefix
   advertised via a routing protocol.  An SRv6 SID that does not fulfill
   this condition is non-routed.

   Let's provide a classic illustration:

   Node N is configured explicitly with two SIDs: 2001:DB8:B:1:100:: and
   2001:DB8:B:2:101::.

   The network learns about a path to 2001:DB8:B:1::/64 via the IGP and
   hence a packet destined to 2001:DB8:B:1:100:: would be routed up to
   N.  The network does not learn about a path to 2001:DB8:B:2::/64 via
   the IGP and hence a packet destined to 2001:DB8:B:2:101:: would not
   be routed up to N.

   A packet could be steered to a non-routed SID 2001:DB8:B:2:101:: by
   using a SID list <...,2001:DB8:B:1:100::,2001:DB8:B:2:101::,...>
   where the non-routed SID is preceded by a routed SID to the same
   node.  Routed and non-routed SRv6 SIDs are the SRv6 instantiation of
   global and local segments, respectively [RFC8402].








Filsfils, et al.          Expires April 9, 2020                 [Page 7]


Internet-Draft          SRv6 Network Programming            October 2019


4.  Behaviors associated with a SID

   Each FIB entry indicates the behavior associated with a SID instance
   and its parameters.

   We define hereafter a set of well-known behaviors that can be
   associated with a SID.

  End                Endpoint function
                     The SRv6 instantiation of a prefix SID
  End.X              Endpoint with Layer-3 cross-connect
                     The SRv6 instantiation of a Adj SID
  End.T              Endpoint with specific IPv6 table lookup
  End.DX6            Endpoint with decaps and IPv6 cross-connect
                     e.g. IPv6-L3VPN (equivalent to per-CE VPN label)
  End.DX4            Endpoint with decaps and IPv4 cross-connect
                     e.g. IPv4-L3VPN (equivalent to per-CE VPN label)
  End.DT6            Endpoint with decaps and IPv6 table lookup
                     e.g. IPv6-L3VPN (equivalent to per-VRF VPN label)
  End.DT4            Endpoint with decaps and IPv4 table lookup
                     e.g. IPv4-L3VPN (equivalent to per-VRF VPN label)
  End.DT46           Endpoint with decaps and IP table lookup
                     e.g. IP-L3VPN (equivalent to per-VRF VPN label)
  End.DX2            Endpoint with decaps and L2 cross-connect
                     e.g. L2VPN use-case
  End.DX2V           Endpoint with decaps and VLAN L2 table lookup
                     e.g. EVPN Flexible cross-connect use-case
  End.DT2U           Endpoint with decaps and unicast MAC L2table lookup
                     e.g. EVPN Bridging unicast use-case
  End.DT2M           Endpoint with decaps and L2 table flooding
                     e.g. EVPN Bridging BUM use-case with ESI filtering
  End.B6.Encaps      Endpoint bound to an SRv6 policy with encaps
                     SRv6 instantiation of a Binding SID
  End.B6.Encaps.RED  [...] with reduced SRH insertion
                     SRv6 instantiation of a Binding SID
  End.BM             Endpoint bound to an SR-MPLS Policy
                     SRv6 instantiation of an SR-MPLS Binding SID

   The list is not exhaustive.  In practice, any function can be
   attached to a local SID: e.g. a node N can bind a SID to a local VM
   or container which can apply any complex processing on the packet.

   The following subsections detail the behavior that a node (N) binds
   to a SID (S).

   At the end of this section, we also present some flavors of these
   well-known behaviors.




Filsfils, et al.          Expires April 9, 2020                 [Page 8]


Internet-Draft          SRv6 Network Programming            October 2019


4.1.  End: Endpoint

   The Endpoint behavior ("End" for short) is the most basic behavior.
   It is the instantiation of a Prefix-SID [RFC8402].

   It does not allow for decapsulation of an outer header nor the
   removal of an SRH.  As a consequence, an End SID cannot be the last
   SID of a SID list and cannot be the DA of a packet without an SRH
   (unless combined with the PSP, USP or USD flavors Section 4.16).

   The following defines SRH processing and, if SRH is not present,
   upper-layer header processing when a matched FIB entry represents a
   locally instantiated End SID.


   When N receives a packet whose IPv6 DA is S and S is a local End SID,
   N does:

  S01. When an SRH is processed {
  S02.   If (Segments Left == 0) {
  S03.      Send an ICMP Parameter Problem message to the Source Address
               Code TBD-SRH (SR Upper-layer Header Error),
               Pointer set to the offset of the upper-layer header,
               interrupt packet processing and discard the packet
  S04.   }
  S05.   If (IPv6 Hop Limit <= 1) {
  S06.      Send an ICMP Time Exceeded message to the Source Address,
               Code 0 (Hop limit exceeded in transit),
               interrupt packet processing and discard the packet
  S07.   }
  S08.   max_LE = (Hdr Ext Len / 2) - 1
  S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
  S10.      Send an ICMP Parameter Problem to the Source Address,
               Code 0 (Erroneous header field encountered),
               Pointer set to the Segments Left field,
               interrupt packet processing and discard the packet
  S11.   }
  S12.   Decrement Hop Limit by 1
  S13.   Decrement Segments Left by 1
  S14.   Update IPv6 DA with Segment List[Segments Left]
  S15.   Resubmit the packet to the egress IPv6 FIB lookup and
            transmission to the new destination
  S16. }

   Notes:
   The End behavior operates on the same FIB table (i.e.  VRF, L3 relay
   id) associated to the packet.  Hence the FIB lookup on line S15 is
   done in the same FIB table as the ingress interface.



Filsfils, et al.          Expires April 9, 2020                 [Page 9]


Internet-Draft          SRv6 Network Programming            October 2019


   When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 End SID, send an ICMP parameter
   problem message to the Source Address and discard the packet.  Error
   code TBD-SRH (SR Upper-layer Header Error) and Pointer set to the
   offset of the upper-layer header.

4.2.  End.X: Layer-3 cross-connect

   The "Endpoint with cross-connect to an array of layer-3 adjacencies"
   behavior (End.X for short) is a variant of the End behavior.

   It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is
   required to express any traffic-engineering policy.

   An instance of the End.X behavior is associated with a set of J of
   one or more Layer-3 adjacencies.


   When N receives a packet destined to S and S is a local End.X SID,
   the line S15 from the End processing is replaced by the following:

   S15.   Set the packet's egress adjacency to J

   Notes:
   S15.  If the set J contains several L3 adjacencies, then one element
   of the set is selected based on a hash of the packet's header
   Section 6.2.


   When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 End.X SID, send an ICMP
   parameter problem message to the Source Address and discard the
   packet.  Error code "SR Upper-layer Header Error", Pointer set to the
   offset of the upper-layer header.

   Note that the End.X SID cannot be the last SID of a SID list and
   cannot be the DA of a packet without an SRH (unless combined with the
   PSP, USP or USD flavors Section 4.16).  Hence the Upper-layer header
   should never be processed.


   If a node N has 30 outgoing interfaces to 30 neighbors, usually the
   operator would explicitly instantiate 30 End.X SIDs at N: one per
   layer-3 adjacency to a neighbor.  Potentially, more End.X could be
   explicitly defined (groups of layer-3 adjacencies to the same
   neighbor or to different neighbors).





Filsfils, et al.          Expires April 9, 2020                [Page 10]


Internet-Draft          SRv6 Network Programming            October 2019


   Note that if N has an outgoing interface bundle I to a neighbor Q
   made of 10 member links, N may allocate up to 11 End.X local SIDs:
   one for the bundle(LAG) itself and then up to one for each Layer-2
   member link.


   The End.X behavior can be also associated with a BGP Next-Hop, in
   which case it is the SRv6 instantiation of the BGP Peering Segments
   [RFC8402].

4.3.  End.T: Specific IPv6 table lookup

   The "Endpoint with specific IPv6 table lookup" behavior (End.T for
   short) is a variant of the End behavior.

   The End.T behavior is used for multi-table operation in the core.
   For this reason, an instance of the End.T behavior must be associated
   with an IPv6 FIB table T.


   When N receives a packet destined to S and S is a local End.T SID,
   the line S15 from the End processing is replaced by the following:

   S15.1.   Set the packet's associated FIB table to T
   S15.2.   Resubmit the packet to the egress IPv6 FIB lookup and
              transmission to the new destination


   When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 End.T SID, send an ICMP
   parameter problem message to the Source Address and discard the
   packet.  Error code "SR Upper-layer Header Error", Pointer set to the
   offset of the upper-layer header.

   Note that the End.T SID cannot be the last SID of a SID list and
   cannot be the DA of a packet without an SRH (unless combined with the
   PSP, USP or USD flavors Section 4.16).  Hence the Upper-layer header
   should never be processed.













Filsfils, et al.          Expires April 9, 2020                [Page 11]


Internet-Draft          SRv6 Network Programming            October 2019


4.4.  End.DX6: Decapsulation and IPv6 cross-connect

   The "Endpoint with decapsulation and cross-connect to an array of
   IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the
   End.X behavior.

   One of the applications of the End.DX6 behavior is the L3VPNv6 use-
   case where a FIB lookup in a specific tenant table at the egress PE
   is not required.  This is equivalent to the per-CE VPN label in MPLS
   [RFC4364].

   The End.DX6 SID must be the last segment in a SR Policy, and it must
   be associated with one or more L3 IPv6 adjacencies J.


   When N receives a packet destined to S and S is a local End.DX6 SID,
   N does the following processing:

   S01. When an SRH is processed {
   S02.   If (Segments Left != 0) {
   S03.      Send an ICMP Parameter Problem to the Source Address,
                Code 0 (Erroneous header field encountered),
                Pointer set to the Segments Left field,
                interrupt packet processing and discard the packet
   S04.   }
   S05.   Proceed to process the next header in the packet
   S06. }


   When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 End.DX6 SID, the following must
   be done.

   S01. If (Upper-Layer Header type != 41) {
   S02.    Send an ICMP Parameter Problem message to the Source Address
              Code TBD-SRH (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header,
              interrupt packet processing and discard the packet
   S03. }
   S04. Remove the outer IPv6 Header with all its extension headers
   S05. Forward the exposed IPv6 packet to the L3 adjacency J

   Notes:
   S01. 41 refers to IPv6 encapsulation as defined by IANA allocation
   for Internet Protocol Numbers.
   S05.  If the End.DX6 SID is bound to an array of L3 adjacencies, then
   one entry of the array is selected based on the hash of the packet's
   header Section 6.2.



Filsfils, et al.          Expires April 9, 2020                [Page 12]


Internet-Draft          SRv6 Network Programming            October 2019


4.5.  End.DX4: Decapsulation and IPv4 cross-connect

   The "Endpoint with decapsulation and cross-connect to an array of
   IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the
   End.X behavior.

   One of the applications of the End.DX4 behavior is the L3VPNv4 use-
   case where a FIB lookup in a specific tenant table at the egress PE
   is not required.  This is equivalent to the per-CE VPN label in MPLS
   [RFC4364].

   The End.DX4 SID must be the last segment in a SR Policy, and it must
   be associated with one or more L3 IPv4 adjacencies J.


   When N receives a packet destined to S and S is a local End.DX4 SID,
   N does the following processing:

   S01. When an SRH is processed {
   S02.   If (Segments Left != 0) {
   S03.      Send an ICMP Parameter Problem to the Source Address,
                Code 0 (Erroneous header field encountered),
                Pointer set to the Segments Left field,
                interrupt packet processing and discard the packet
   S04.   }
   S05.   Proceed to process the next header in the packet
   S06. }


   When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 End.DX4 SID, the following must
   be done.

   S01. If (Upper-Layer Header type != 4) {
   S02.    Send an ICMP Parameter Problem message to the Source Address
              Code TBD-SRH (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header,
              interrupt packet processing and discard the packet
   S03. }
   S04. Remove the outer IPv6 Header with all its extension headers
   S05. Forward the exposed IPv4 packet to the L3 adjacency J

   Notes:
   S01. 4 refers to IPv4 encapsulation as defined by IANA allocation for
   Internet Protocol Numbers
   S05.  If the End.DX4 SID is bound to an array of L3 adjacencies, then
   one entry of the array is selected based on the hash of the packet's
   header Section 6.2.



Filsfils, et al.          Expires April 9, 2020                [Page 13]


Internet-Draft          SRv6 Network Programming            October 2019


4.6.  End.DT6: Decapsulation and specific IPv6 table lookup

   The "Endpoint with decapsulation and specific IPv6 table lookup"
   behavior (End.DT6 for short) is a variant of the End.T behavior.

   One of the applications of the End.DT6 behavior is the L3VPNv6 use-
   case where a FIB lookup in a specific tenant table at the egress PE
   is required.  This would be equivalent to the per-VRF VPN label in
   MPLS [RFC4364].

   Note that an End.DT6 may be defined for the main IPv6 table in which
   case and End.DT6 supports the equivalent of an IPv6inIPv6
   decapsulation (without VPN/tenant implication).

   The End.DT6 SID must be the last segment in a SR Policy, and a SID
   instance must be associated with an IPv6 FIB table T.


   When N receives a packet destined to S and S is a local End.DT6 SID,
   N does the following processing:

   S01. When an SRH is processed {
   S02.   If (Segments Left != 0) {
   S03.      Send an ICMP Parameter Problem to the Source Address,
                Code 0 (Erroneous header field encountered),
                Pointer set to the Segments Left field,
                interrupt packet processing and discard the packet
   S04.   }
   S05.   Proceed to process the next header in the packet
   S06. }


   When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 End.DT6 SID, N does the
   following:

   S01. If (Upper-Layer Header type != 41) {
   S02.    Send an ICMP Parameter Problem message to the Source Address
              Code TBD-SRH (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header,
              interrupt packet processing and discard the packet
   S03. }
   S04. Remove the outer IPv6 Header with all its extension headers
   S05. Set the packet's associated FIB table to T
   S06. Resubmit the packet to the egress IPv6 FIB lookup and
           transmission to the new destination





Filsfils, et al.          Expires April 9, 2020                [Page 14]


Internet-Draft          SRv6 Network Programming            October 2019


4.7.  End.DT4: Decapsulation and specific IPv4 table lookup

   The "Endpoint with decapsulation and specific IPv4 table lookup"
   behavior (End.DT4 for short) is a variant of the End behavior.

   One of the applications of the End.DT4 behavior is the L3VPNv4 use-
   case where a FIB lookup in a specific tenant table at the egress PE
   is required.  This would be equivalent to the per-VRF VPN label in
   MPLS [RFC4364].

   Note that an End.DT4 may be defined for the main IPv4 table in which
   case an End.DT4 supports the equivalent of an IPv4inIPv6
   decapsulation (without VPN/tenant implication).

   The End.DT4 SID must be the last segment in a SR Policy, and a SID
   instance must be associated with an IPv4 FIB table T.


   When N receives a packet destined to S and S is a local End.DT4 SID,
   N does the following processing:

   S01. When an SRH is processed {
   S02.   If (Segments Left != 0) {
   S03.      Send an ICMP Parameter Problem to the Source Address,
                Code 0 (Erroneous header field encountered),
                Pointer set to the Segments Left field,
                interrupt packet processing and discard the packet
   S04.   }
   S05.   Proceed to process the next header in the packet
   S06. }


   When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 End.DT4 SID, N does the
   following:

   S01. If (Upper-Layer Header type != 4) {
   S02.    Send an ICMP Parameter Problem message to the Source Address
              Code TBD-SRH (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header,
              interrupt packet processing and discard the packet
   S03. }
   S04. Remove the outer IPv6 Header with all its extension headers
   S05. Set the packet's associated FIB table to T
   S06. Resubmit the packet to the egress IPv4 FIB lookup and
           transmission to the new destination





Filsfils, et al.          Expires April 9, 2020                [Page 15]


Internet-Draft          SRv6 Network Programming            October 2019


4.8.  End.DT46: Decapsulation and specific IP table lookup

   The "Endpoint with decapsulation and specific IP table lookup"
   behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6
   behavior.

   One of the applications of the End.DT46 behavior is the L3VPN use-
   case where a FIB lookup in a specific IP tenant table at the egress
   PE is required.  This would be equivalent to single per-VRF VPN label
   (for IPv4 and IPv6) in MPLS[RFC4364].

   Note that an End.DT46 may be defined for the main IP table in which
   case an End.DT46 supports the equivalent of an IPinIPv6
   decapsulation(without VPN/tenant implication).

   The End.DT46 SID must be the last segment in a SR Policy, and a SID
   instance must be associated with an IPv4 FIB table T4 and an IPv6 FIB
   table T6.


   When N receives a packet destined to S and S is a local End.DT46 SID,
   N does the following processing:

   S01. When an SRH is processed {
   S02.   If (Segments Left != 0) {
   S03.      Send an ICMP Parameter Problem to the Source Address,
                Code 0 (Erroneous header field encountered),
                Pointer set to the Segments Left field,
                interrupt packet processing and discard the packet
   S04.   }
   S05.   Proceed to process the next header in the packet
   S06. }


   When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 End.DT46 SID, N does the
   following:














Filsfils, et al.          Expires April 9, 2020                [Page 16]


Internet-Draft          SRv6 Network Programming            October 2019


   S01. If (Upper-layer Header type == 4) {
   S02.    Remove the outer IPv6 Header with all its extension headers
   S03.    Set the packet's associated FIB table to T4
   S04.    Resubmit the packet to the egress IPv4 FIB lookup and
              transmission to the new destination
   S05. } Else if (Upper-layer Header type == 41) {
   S06.    Remove the outer IPv6 Header with all its extension headers
   S07.    Set the packet's associated FIB table to T6
   S08.    Resubmit the packet to the egress IPv6 FIB lookup and
              transmission to the new destination
   S09. } Else {
   S10.    Send an ICMP Parameter Problem message to the Source Address
              Code TBD-SRH (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header,
              interrupt packet processing and discard the packet
   S11. }

4.9.  End.DX2: Decapsulation and L2 cross-connect

   The "Endpoint with decapsulation and Layer-2 cross-connect to an
   outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the
   endpoint behavior.

   One of the applications of the End.DX2 behavior is the L2VPN/EVPN
   VPWS use-case.

   The End.DX2 SID must be the last segment in a SR Policy, and it must
   be associated with one outgoing interface I.


   When N receives a packet destined to S and S is a local End.DX2 SID,
   N does:

   S01. When an SRH is processed {
   S02.   If (Segments Left != 0) {
   S03.      Send an ICMP Parameter Problem to the Source Address,
                Code 0 (Erroneous header field encountered),
                Pointer set to the Segments Left field,
                interrupt packet processing and discard the packet
   S04.   }
   S05.   Proceed to process the next header in the packet
   S06. }


   When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 End.DX2 SID, the following must
   be done.




Filsfils, et al.          Expires April 9, 2020                [Page 17]


Internet-Draft          SRv6 Network Programming            October 2019


   S01. If (Upper-Layer Header type != TBD1) {
   S02.    Send an ICMP Parameter Problem message to the Source Address
              Code TBD-SRH (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header,
              interrupt packet processing and discard the packet
   S03. }
   S04. Remove the outer IPv6 Header with all its extension headers and
           forward the ethernet frame to the OIF I.


   Notes:
   S04.  An End.DX2 behavior could be customized to expect a specific
   VLAN format and rewrite the egress VLAN header before forwarding on
   the outgoing interface.

4.10.  End.DX2V: Decapsulation and VLAN L2 table lookup

   The "Endpoint with decapsulation and specific VLAN table lookup"
   behavior (End.DX2V for short) is a variant of the End.DX2 behavior.

   One of the applications of the End.DX2V behavior is the EVPN Flexible
   cross-connect use-case.  The End.DX2V behavior is used to perform a
   lookup of the ethernet frame VLANs in a particular L2 table.  Any SID
   instance of the End.DX2V behavior must be associated with an L2
   Table T.


   When N receives a packet whose IPv6 DA is S and S is a local End.DX2
   SID, the processing is identical to the End.DX2 behavior except for
   the Upper-layer header processing which is modified as follows:

   S04. Remove the outer IPv6 Header with all its extension headers,
           lookup the exposed inner VLANs in L2 table T, and forward
           via the matched table entry.

   Notes:
   An End.DX2V behavior could be customized to expect a specific VLAN
   format and rewrite the egress VLAN header before forwarding on the
   outgoing interface.

4.11.  End.DT2U: Decapsulation and unicast MAC L2 table lookup

   The "Endpoint with decapsulation and specific unicast MAC L2 table
   lookup" behavior (End.DT2U for short) is a variant of the End
   behavior.






Filsfils, et al.          Expires April 9, 2020                [Page 18]


Internet-Draft          SRv6 Network Programming            October 2019


   One of the applications of the End.DT2U behavior is the EVPN Bridging
   unicast . Any SID instance of the End.DT2U behavior must be
   associated with an L2 Table T.


   When N receives a packet whose IPv6 DA is S and S is a local End.DT2U
   SID, the processing is identical to the End.DX2 behavior except for
   the Upper-layer header processing which is as follows:

   S01. If (Upper-Layer Header type != TBD1) {
   S02.    Send an ICMP Parameter Problem message to the Source Address
              Code TBD-SRH (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header,
              interrupt packet processing and discard the packet
   S03. }
   S04. Remove the IPv6 header and all its extension headers
   S05. Learn the exposed inner MAC Source Address in L2 Table T
   S06. Lookup the exposed inner MAC Destination Address in L2 Table T
   S07. If (matched entry in T) {
   S08.    Forward via the matched table T entry
   S09. } Else {
   S10.    Forward via all L2OIFs entries in table T
   S11. }

   Notes:
   S05.  In EVPN, the learning of the exposed inner MAC SA is done via
   control plane.

4.12.  End.DT2M: Decapsulation and L2 table flooding

   The "Endpoint with decapsulation and specific L2 table flooding"
   behavior (End.DT2M for short) is a variant of the End.DT2U behavior.

   Two of the applications of the End.DT2M behavior are the EVPN
   Bridging BUM with ESI filtering and the EVPN ETREE use-cases.

   Any SID instance of this behavior must be associated with a L2 table
   T.  Additionally the behavior may take an argument: "Arg.FE2".  It is
   an argument specific to EVPN ESI filtering and EVPN-ETREE used to
   exclude specific OIF (or set of OIFs) from L2 table T flooding.


   When N receives a packet whose IPv6 DA is S and S is a local End.DT2M
   SID, the processing is identical to the End.DT2M behavior except for
   the Upper-layer header processing which is as follows:






Filsfils, et al.          Expires April 9, 2020                [Page 19]


Internet-Draft          SRv6 Network Programming            October 2019


   S01. If (Upper-Layer Header type != TBD1) {
   S02.    Send an ICMP Parameter Problem message to the Source Address
              Code TBD-SRH (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header,
              interrupt packet processing and discard the packet
   S03. }
   S04. Remove the IPv6 header and all its extension headers
   S05. Learn the exposed inner MAC Source Address in L2 Table T
   S06. Forward via all L2 OIFs excluding the one specified in Arg.F2


   Notes:
   S05.  In EVPN, the learning of the exposed inner MAC SA is done via
   control plane

4.13.  End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps

   This is a variation of the End behavior.

   One of its applications is to express scalable traffic-engineering
   policies across multiple domains.  It is the one of the SRv6
   instantiations of a Binding SID [RFC8402].

   Instead of simply inserting an SRH with the policy (End.B6.Insert),
   this behavior also adds an outer IPv6 header.

   An End.B6.Encaps SID is never the last segment in a SID list.  Any
   SID instantiation must be associated with an SR Policy
   B[I-D.ietf-spring-segment-routing-policy] and a source address A.


   When N receives a packet whose IPv6 DA is S and S is a local
   End.B6.Encaps SID, does:


















Filsfils, et al.          Expires April 9, 2020                [Page 20]


Internet-Draft          SRv6 Network Programming            October 2019


  S01. When an SRH is processed {
  S02.   If (Segments Left == 0) {
  S03.      Send an ICMP Parameter Problem message to the Source Address
               Code TBD-SRH (SR Upper-layer Header Error),
               Pointer set to the offset of the upper-layer header,
               interrupt packet processing and discard the packet
  S04.   }
  S05.   If (IPv6 Hop Limit <= 1) {
  S06.       Send an ICMP Time Exceeded message to the Source Address,
               Code 0 (Hop limit exceeded in transit),
               interrupt packet processing and discard the packet
  S07.   }
  S08.   max_LE = (Hdr Ext Len / 2) - 1
  S09.   If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) {
  S10.      Send an ICMP Parameter Problem to the Source Address,
               Code 0 (Erroneous header field encountered),
               Pointer set to the Segments Left field,
               interrupt packet processing and discard the packet
  S11.   }
  S12.   Decrement Hop Limit by 1
  S13.   Decrement Segments Left by 1
  S14.   Push a new IPv6 header with its own SRH containing B
  S15.   Set the outer IPv6 SA to A
  S16.   Set the outer IPv6 DA to the first SID of B
  S17.   Set the outer PayloadLength, Traffic Class, FlowLabel and
            Next-Header fields
  S18.   Resubmit the packet to the egress IPv6 FIB lookup and
            transmission to the new destination
  S19. }

   Notes:
   S13.  The SRH MAY be omitted when the SRv6 Policy B only contains one
   SID and there is no need to use any flag, tag or TLV.
   S16.  The Payload Length, Traffic Class and Next-Header fields are
   set as per [RFC2473].  The Flow Label is computed as per [RFC6437].


   When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 End.B6.Encaps SID, send an ICMP
   parameter problem message to the Source Address and discard the
   packet.  Error code "SR Upper-layer Header Error", Pointer set to the
   offset of the upper-layer header.

4.14.  End.B6.Encaps.Red: [...] with reduced SRH

   This is an optimization of the End.B6.Encaps behavior.





Filsfils, et al.          Expires April 9, 2020                [Page 21]


Internet-Draft          SRv6 Network Programming            October 2019


   End.B6.Encaps.Red reduces the size of the SRH by one SID by avoiding
   the insertion of the first SID in the outer SRH.  In this way, the
   first segment is only introduced in the DA and the packet is
   forwarded according to it.

   The new SRH is created as described in Section 4.1.1 of
   [I-D.ietf-6man-segment-routing-header].

   The SRH MAY be omitted when the SRv6 Policy only contains one segment
   and there is no need to use any flag, tag or TLV.

4.15.  End.BM: Endpoint bound to an SR-MPLS policy

   The "Endpoint bound to an SR-MPLS Policy" is a variant of the End
   behavior.

   The End.BM behavior is required to express scalable traffic-
   engineering policies across multiple domains where some domains
   support the MPLS instantiation of Segment Routing.  This is an SRv6
   instantiation of an SR-MPLS Binding SID [RFC8402].

   An End.BM SID is never the last SID, and any SID instantiation must
   be associated with an SR-MPLS Policy
   B[I-D.ietf-spring-segment-routing-policy].


   When N receives a packet whose IPv6 DA is S and S is a local End.BM
   SID, does:























Filsfils, et al.          Expires April 9, 2020                [Page 22]


Internet-Draft          SRv6 Network Programming            October 2019


  S01. When an SRH is processed {
  S02.   If (Segments Left == 0) {
  S03.      Send an ICMP Parameter Problem message to the Source Address
               Code TBD-SRH (SR Upper-layer Header Error),
               Pointer set to the offset of the upper-layer header,
               interrupt packet processing and discard the packet
  S04.   }
  S05.   If (IPv6 Hop Limit <= 1) {
  S06.      Send an ICMP Time Exceeded message to the Source Address,
               Code 0 (Hop limit exceeded in transit),
               interrupt packet processing and discard the packet
  S07.   }
  S08.   max_LE = (Hdr Ext Len / 2) - 1
  S09.   If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) {
  S10.      Send an ICMP Parameter Problem to the Source Address,
               Code 0 (Erroneous header field encountered),
               Pointer set to the Segments Left field,
               interrupt packet processing and discard the packet
  S11.   }
  S12.   Decrement Hop Limit by 1
  S13.   Decrement Segments Left by 1
  S14.   Push a the MPLS label stack for B
  S15.   Submit the packet to the MPLS engine for transmission to the
            topmost label.
  S16. }


   When processing the Upper-layer header of a packet matching a FIB
   entry locally instantiated as an SRv6 End.BM SID, send an ICMP
   parameter problem message to the Source Address and discard the
   packet.  Error code "SR Upper-layer Header Error", Pointer set to the
   offset of the upper-layer header.



















Filsfils, et al.          Expires April 9, 2020                [Page 23]


Internet-Draft          SRv6 Network Programming            October 2019


4.16.  Flavors

   The PSP, USP and USD flavors are variants of the End, End.X and End.T
   behaviors.  For each of these behaviors these flavors may be
   supported for a SID either individually or in combinations.

4.16.1.  PSP: Penultimate Segment Pop of the SRH

   The SRH processing of the End, End.X and End.T behaviors are
   modified: after the instruction "S14.  Update IPv6 DA with Segment
   List[Segments Left]" is executed, the following instructions must be
   executed as well:

   S14.1.   If (updated SL == 0) {
   S14.2.      Pop the SRH
   S14.3.   }

4.16.2.  USP: Ultimate Segment Pop of the SRH

   The SRH processing of the End, End.X and End.T behaviors are
   modified: the instructions S02-S04 are substituted by the following
   ones:

   S02.   If (Segments Left == 0) {
   S03.       Pop the SRH
   S04.   }

4.16.3.  USD: Ultimate Segment Decapsulation

   The SRH processing of the End, End.X and End.T behaviors are
   modified: the instructions S02-S04 are substituted by the following
   ones:

   S02.   If (Segments Left == 0) {
   S03.      Skip the SRH processing and proceed to the next header
   S04.   }


   Further on, the Upper-layer header processing of the End, End.X and
   End.T behaviors are modified as follows:











Filsfils, et al.          Expires April 9, 2020                [Page 24]


Internet-Draft          SRv6 Network Programming            October 2019


   End:
   S01. If (Upper-layer Header type == 41) {
   S02.    Remove the outer IPv6 Header with all its extension headers
   S03.    Resubmit the packet to the egress IPv6 FIB lookup and
              transmission to the new destination
   S04. } Else {
   S05.    Send an ICMP Parameter Problem message to the Source Address
              Code TBD-SRH (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header,
              interrupt packet processing and discard the packet
   S06. }

   End.T:
   S01. If (Upper-layer Header type == 41) {
   S02.    Remove the outer IPv6 Header with all its extension headers
   S03.    Set the packet's associated FIB table to T
   S04.    Resubmit the packet to the egress IPv6 FIB lookup and
              Transmission to the new destination
   S05. } Else {
   S06.    Send an ICMP Parameter Problem message to the Source Address
              Code TBD-SRH (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header,
              interrupt packet processing and discard the packet
   S07. }

   End.X:
   S01. If (Upper-layer Header type == 41) {
   S02.    Remove the outer IPv6 Header with all its extension headers
   S03.    Forward the exposed IPv6 packet to the L3 adjacency J
   S04. } Else {
   S05.    Send an ICMP Parameter Problem message to the Source Address
              Code TBD-SRH (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header,
              interrupt packet processing and discard the packet
   S06. }
















Filsfils, et al.          Expires April 9, 2020                [Page 25]


Internet-Draft          SRv6 Network Programming            October 2019


5.  Transit behaviors

   We define hereafter the set of basic transit behaviors.  These
   behaviors are not bound to a SID and they correspond to source SR
   nodes or transit nodes [I-D.ietf-6man-segment-routing-header].

 T                Transit behavior
 T.Encaps         Transit behavior with encapsulation in an SRv6 policy
 T.Encaps.Red     Transit behavior with reduced encaps in an SRv6 policy
 T.Encaps.L2      T.Encaps applied to received L2 frames
 T.Encaps.L2.Red  T.Encaps.Red applied to received L2 frames

   This list can be expanded in case any new functionality requires it.

5.1.  T: Transit behavior

   As per [RFC8200], if a node N receives a packet (A, S2)(S3, S2, S1;
   SL=1) and S2 is neither a local address nor a local SID of N then N
   forwards the packet without inspecting the SRH.

   This means that N treats the following two packets P1 and P2 with the
   same performance:

      P1 = (A, S2)

      P2 = (A, S2)(S3, S2, S1; SL=1)

   A transit node does not need to count by default the amount of
   transit traffic with an SRH extension header.  This accounting might
   be enabled as an optional behavior.

   A transit node MUST include the outer flow label in its ECMP load-
   balancing hash [RFC6437].

5.2.  T.Encaps: Transit with encapsulation in an SRv6 Policy

   Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1;
   SL=1).  B2 is neither a local address nor SID of N.

   N steers the transit packets P1 and P2 into an SR Encapsulation
   Policy with a Source Address T and a Segment list <S1, S2, S3>.

   The T.Encaps transit encapsulation behavior is defined as follows:








Filsfils, et al.          Expires April 9, 2020                [Page 26]


Internet-Draft          SRv6 Network Programming            October 2019


1.   push an IPv6 header with its own SRH (S3, S2, S1; SL=2)
2.   set outer IPv6 SA = T and outer IPv6 DA = S1
3.   set outer payload length, traffic class and flow label    ;; Ref1,2
4.   update the Next-Header value                              ;; Ref1
5.   decrement inner Hop Limit or TTL                          ;; Ref1
6.   forward along the shortest path to S1

   After the T.Encaps behavior, P1 and P2 respectively look like:

   - (T, S1) (S3, S2, S1; SL=2) (A, B2)

   - (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1)

   The T.Encaps behavior is valid for any kind of Layer-3 traffic.  This
   behavior is commonly used for L3VPN with IPv4 and IPv6 deployments.

   The SRH MAY be omitted when the SRv6 Policy only contains one segment
   and there is no need to use any flag, tag or TLV.

   Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6
   Specification)

   Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification)

5.3.  T.Encaps.Red: Transit with reduced encapsulation

   The T.Encaps.Red behavior is an optimization of the T.Encaps
   behavior.  It is defined as follows:

 1.   push an IPv6 header with its own SRH (S3, S2; SL=2)
 2.   set outer IPv6 SA = T and outer IPv6 DA = S1
 3.   set outer payload length, traffic class and flow label   ;; Ref1,2
 4.   update the Next-Header value                             ;; Ref1
 5.   decrement inner Hop Limit or TTL                         ;; Ref1
 6.   forward along the shortest path to S1

   Ref 1: As described in [RFC2473] (Generic Packet Tunneling in IPv6
   Specification)

   Ref 2: As described in [RFC6437] (IPv6 Flow Label Specification)

   T.Encaps.Red will reduce the size of the SRH by one segment by
   avoiding the insertion of the first SID in the SRH of the pushed IPv6
   packet.  In this way, the first segment is only introduced in the DA
   and the packet is forwarded according to it.

   After the T.Encaps.Red behavior, P1 and P2 respectively look like:




Filsfils, et al.          Expires April 9, 2020                [Page 27]


Internet-Draft          SRv6 Network Programming            October 2019


   - (T, S1) (S3, S2; SL=2) (A, B2)

   - (T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1)

   The SRH MAY be omitted when the SRv6 Policy only contains one segment
   and there is no need to use any flag, tag or TLV.

5.4.  T.Encaps.L2: Transit with encapsulation of L2 frames

   While T.Encaps encapsulates the received IP packet, T.Encaps.L2
   encapsulates the received L2 frame (i.e. the received ethernet header
   and its optional VLAN header is in the payload of the outer packet).

   If the outer header is pushed without SRH, then the DA must be a SID
   of type End.DX2, End.DX2V, End.DT2U or End.DT2M and the next-header
   must be TBD1.  The received Ethernet frame follows the IPv6 header
   and its extension headers.

   Else, if the outer header is pushed with an SRH, then the last SID of
   the SRH must be of type End.DX2, End.DX2V, End.DT2U or End.DT2M and
   the next-header of the SRH must be TBD1.  The received Ethernet frame
   follows the IPv6 header and its extension headers.

   The SRH MAY be omitted when the SRv6 Policy only contains one segment
   and there is no need to use any flag, tag or TLV.

5.5.  T.Encaps.L2.Red: Transit with reduced encaps of L2 frames

   The T.Encaps.L2.Red behavior is an optimization of the T.Encaps.L2
   behavior.

   T.Encaps.L2.Red will reduce the size of the SRH by one segment by
   avoiding the insertion of the first SID in the SRH of the pushed IPv6
   packet.  In this way, the first segment is only introduced in the DA
   and the packet is forwarded according to it.

   The SRH MAY be omitted when the SRv6 Policy only contains one segment
   and there is no need to use any flag, tag or TLV.













Filsfils, et al.          Expires April 9, 2020                [Page 28]


Internet-Draft          SRv6 Network Programming            October 2019


6.  Operation

6.1.  Counters

   Any SRv6 capable node SHOULD implement the following set of combined
   counters (packets and bytes):

   - CNT-1: Per local SID entry, traffic that matched that SID and was
     processed correctly.

   - CNT-2: Per SRv6 Policy, traffic steered into it and processed
     correctly.

   Furthermore, an SRv6 capable node maintains an aggregate counter
   CNT-3 tracking the IPv6 traffic that was received with a destination
   address matching a local interface address that is not a locally
   instantiated SID and the next-header is SRH with SL>0.  We remind
   that this traffic is dropped as an interface address is not a local
   SID by default.  A SID must be explicitly instantiated.

6.2.  Flow-based hash computation

   When a flow-based selection within a set needs to be performed, the
   source address, the destination address and the flow-label MUST be
   included in the flow-based hash.

   This occurs when the destination address is updated, a FIB lookup is
   performed and multiple ECMP paths exist to the updated destination
   address.

   This occurs when End.X, End.DX4, or End.DX6 are bound to an array of
   adjacencies.

   This occurs when the packet is steered in an SR policy whose selected
   path has multiple SID lists [I-D.ietf-spring-segment-routing-policy].

   Additionally, any transit router in an SRv6 domain MUST include the
   outer flow label in its ECMP load-balancing hash [RFC6437].

6.3.  OAM

   [I-D.ali-spring-srv6-oam] defines the OAM behavior for SRv6.  This
   includes the definition of the SRH Flag 'O-bit', as well as
   additional OAM Endpoint behaviors.







Filsfils, et al.          Expires April 9, 2020                [Page 29]


Internet-Draft          SRv6 Network Programming            October 2019


7.  Basic security for intra-domain deployment

   The SRH Section 5.1 defines how a domain of trust can operate
   SRv6-based services for internal traffic while preventing any
   external traffic from accessing the internal SRv6-based services.

   Future documents will detail inter-domain security mechanisms for
   SRv6 (e.g. how to allow external traffic to leverage internal SRv6
   services).

8.  Control Plane

   In an SDN environment, one expects the controller to explicitly
   provision the SIDs and/or discover them as part of a service
   discovery function.  Applications residing on top of the controller
   could then discover the required SIDs and combine them to form a
   distributed network program.

   The concept of "SRv6 network programming" refers to the capability
   for an application to encode any complex program as a set of
   individual functions distributed through the network.  Some functions
   relate to underlay SLA, others to overlay/tenant, others to complex
   applications residing in VM and containers.

   The specification of the SRv6 control-plane is outside the scope of
   this document.

   We limit ourselves to a few important observations.

8.1.  IGP

   The End, End.T and End.X SIDs express topological behaviors and hence
   are expected to be signaled in the IGP together with the flavors PSP,
   USP and USD[I-D.bashandy-isis-srv6-extensions].

   The presence of SIDs in the IGP do not imply any routing semantics to
   the addresses represented by these SIDs.  The routing reachability to
   an IPv6 address is solely governed by the classic, non-SID-related,
   IGP information.  Routing is not governed neither influenced in any
   way by a SID advertisement in the IGP.

   These three SIDs provide important topological behaviors for the IGP
   to build FRR/TI-LFA solution and for TE processes relying on IGP LSDB
   to build SR policies.







Filsfils, et al.          Expires April 9, 2020                [Page 30]


Internet-Draft          SRv6 Network Programming            October 2019


8.2.  BGP-LS

   BGP-LS is expected to be the key service discovery protocol.  Every
   node is expected to advertise via BGP-LS its SRv6 capabilities (e.g.
   how many SIDs it can insert as part of a T.Encaps behavior) and any
   locally instantiated SID [I-D.dawra-idr-bgpls-srv6-ext].

8.3.  BGP IP/VPN/EVPN

   The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V,
   End.DT2U and End.DT2M SIDs are expected to be signaled in BGP
   [I-D.dawra-idr-srv6-vpn].

8.4.  Summary

   The following table summarizes which SIDs are signaled in which
   signaling protocol.

        +-----------------------+-----+--------+-----------------+
        |                       | IGP | BGP-LS | BGP IP/VPN/EVPN |
        +-----------------------+-----+--------+-----------------+
        | End   (PSP, USP, USD) |  X  |   X    |                 |
        | End.X (PSP, USP, USD) |  X  |   X    |                 |
        | End.T (PSP, USP, USD) |  X  |   X    |                 |
        | End.DX6               |  X  |   X    |        X        |
        | End.DX4               |  X  |   X    |        X        |
        | End.DT6               |  X  |   X    |        X        |
        | End.DT4               |  X  |   X    |        X        |
        | End.DT46              |  X  |   X    |        X        |
        | End.DX2               |     |   X    |        X        |
        | End.DX2V              |     |   X    |        X        |
        | End.DT2U              |     |   X    |        X        |
        | End.DT2M              |     |   X    |        X        |
        | End.B6.Encaps         |     |   X    |                 |
        | End.B6.Encaps.Red     |     |   X    |                 |
        | End.B6.BM             |     |   X    |                 |
        +-----------------------+-----+--------+-----------------+

             Table 1: SRv6 locally instantiated SIDs signaling

   The following table summarizes which transit capabilities are
   signaled in which signaling protocol.









Filsfils, et al.          Expires April 9, 2020                [Page 31]


Internet-Draft          SRv6 Network Programming            October 2019


           +-----------------+-----+--------+-----------------+
           |                 | IGP | BGP-LS | BGP IP/VPN/EVPN |
           +-----------------+-----+--------+-----------------+
           | T               |     |   X    |                 |
           | T.Encaps        |  X  |   X    |                 |
           | T.Encaps.Red    |  X  |   X    |                 |
           | T.Encaps.L2     |     |   X    |                 |
           | T.Encaps.L2.Red |     |   X    |                 |
           +-----------------+-----+--------+-----------------+

                 Table 2: SRv6 transit behaviors signaling

   The previous table describes generic capabilities.  It does not
   describe specific instantiated SR policies.

   For example, a BGP-LS advertisement of the T capability of node N
   would indicate that node N supports the basic transit behavior.  The
   T.Encaps behavior would describe the capability of node N to perform
   a T.Encaps behavior, specifically it would describe how many SIDs
   could be inserted by N without significant performance degradation.


   The reader should also remember that any specific instantiated SR
   policy is always assigned a Binding SID.  They should remember that
   BSIDs are advertised in BGP-LS as shown in Table 1.  Hence, it is
   normal that Table 2 only focuses on the generic capabilities related
   to T.Encaps as Table 1 advertises the specific instantiated BSID
   properties.

9.  IANA Considerations

   This document requests IANA to allocate a new IP Protocol Number
   value for "Ethernet" with the following definition: The value TBD1 in
   the Next Header field of an IPv6 header or any extension header
   indicates that the payload is Ethernet.

   Additionally, this document requests the following new IANA
   registries:

   - A new top-level registry "Segment-routing with IPv6 dataplane
     (SRv6) Parameters" to be created under IANA Protocol registries.
     This registry is being defined to serve as a top-level registry for
     keeping all other SRv6 sub-registries.

   - A sub-registry "SRv6 Endpoint Behaviors" to be defined under top-
     level "Segment-routing with IPv6 dataplane (SRv6) Parameters"
     registry.  This sub-registry maintains 16-bit identifiers for the
     SRv6 Endpoint behaviors.  The range of the registry is 0-65535



Filsfils, et al.          Expires April 9, 2020                [Page 32]


Internet-Draft          SRv6 Network Programming            October 2019


     (0x0000 - 0xFFFF) and has the following registration rules and
     allocation policies:

   +-------------+---------------+---------------------------+---------+
   | Range       |      Hex      |   Registration procedure  |  Notes  |
   +-------------+---------------+---------------------------+---------+
   | 0           |     0x0000    |          Reserved         | Invalid |
   | 1-32767     | 0x0001-0x7FFF |   Specification Required  |         |
   | 32768-49151 | 0x8000-0xBFFF | Reserved for experimental |         |
   |             |               |            use            |         |
   | 49152-65534 | 0xC000-0xFFFE |  Reserved for private use |         |
   | 65535       |     0xFFFF    |          Reserved         |  Opaque |
   +-------------+---------------+---------------------------+---------+

                 Table 3: SRv6 Endpoint Behaviors Registry

   The initial registrations for the "Specification Required" portion of
   the sub-registry are as follows:

   +------+------+----------------+------------------------------------+
   | Valu | Hex  |    Endpoint    |             Reference              |
   | e    |      |    behavior    |                                    |
   +------+------+----------------+------------------------------------+
   | 1    | 0x00 |  End (no PSP,  |             [This.ID]              |
   |      |  01  |    no USP)     |                                    |
   | 2    | 0x00 |  End with PSP  |             [This.ID]              |
   |      |  02  |                |                                    |
   | 3    | 0x00 |  End with USP  |             [This.ID]              |
   |      |  03  |                |                                    |
   | 4    | 0x00 |    End with    |             [This.ID]              |
   |      |  04  |    PSP&USP     |                                    |
   | 5    | 0x00 | End.X (no PSP, |             [This.ID]              |
   |      |  05  |    no USP)     |                                    |
   | 6    | 0x00 | End.X with PSP |             [This.ID]              |
   |      |  06  |                |                                    |
   | 7    | 0x00 | End.X with USP |             [This.ID]              |
   |      |  07  |                |                                    |
   | 8    | 0x00 |   End.X with   |             [This.ID]              |
   |      |  08  |    PSP&USP     |                                    |
   | 9    | 0x00 | End.T (no PSP, |             [This.ID]              |
   |      |  09  |    no USP)     |                                    |
   | 10   | 0x00 | End.T with PSP |             [This.ID]              |
   |      |  0A  |                |                                    |
   | 11   | 0x00 | End.T with USP |             [This.ID]              |
   |      |  0B  |                |                                    |
   | 12   | 0x00 |   End.T with   |             [This.ID]              |
   |      |  0C  |    PSP&USP     |                                    |
   | 13   | 0x00 | End.B6.Insert  | [I-D.filsfils-spring-srv6-net-pgm- |



Filsfils, et al.          Expires April 9, 2020                [Page 33]


Internet-Draft          SRv6 Network Programming            October 2019


   |      |  0D  |                |             insertion]             |
   | 14   | 0x00 | End.B6.Encaps  |             [This.ID]              |
   |      |  0E  |                |                                    |
   | 15   | 0x00 |     End.BM     |             [This.ID]              |
   |      |  0F  |                |                                    |
   | 16   | 0x00 |    End.DX6     |             [This.ID]              |
   |      |  10  |                |                                    |
   | 17   | 0x00 |    End.DX4     |             [This.ID]              |
   |      |  11  |                |                                    |
   | 18   | 0x00 |    End.DT6     |             [This.ID]              |
   |      |  12  |                |                                    |
   | 19   | 0x00 |    End.DT4     |             [This.ID]              |
   |      |  13  |                |                                    |
   | 20   | 0x00 |    End.DT46    |             [This.ID]              |
   |      |  14  |                |                                    |
   | 21   | 0x00 |    End.DX2     |             [This.ID]              |
   |      |  15  |                |                                    |
   | 22   | 0x00 |    End.DX2V    |             [This.ID]              |
   |      |  16  |                |                                    |
   | 23   | 0x00 |    End.DT2U    |             [This.ID]              |
   |      |  17  |                |                                    |
   | 24   | 0x00 |    End.DT2M    |             [This.ID]              |
   |      |  18  |                |                                    |
   | 25   | 0x00 |    Reserved    |             [This.ID]              |
   |      |  19  |                |                                    |
   | 26   | 0x00 | End.B6.Insert. | [I-D.filsfils-spring-srv6-net-pgm- |
   |      |  1A  |      Red       |             insertion]             |
   | 27   | 0x00 | End.B6.Encaps. |             [This.ID]              |
   |      |  1B  |      Red       |                                    |
   | 28   | 0x00 |  End with USD  |             [This.ID]              |
   |      |  1C  |                |                                    |
   | 29   | 0x00 |    End with    |             [This.ID]              |
   |      |  1D  |    PSP&USD     |                                    |
   | 30   | 0x00 |    End with    |             [This.ID]              |
   |      |  1E  |    USP&USD     |                                    |
   | 31   | 0x00 | End with PSP,  |             [This.ID]              |
   |      |  1F  |   USP & USD    |                                    |
   | 32   | 0x00 | End.X with USD |             [This.ID]              |
   |      |  20  |                |                                    |
   | 33   | 0x00 |   End.X with   |             [This.ID]              |
   |      |  21  |    PSP&USD     |                                    |
   | 34   | 0x00 |   End.X with   |             [This.ID]              |
   |      |  22  |    USP&USD     |                                    |
   | 35   | 0x00 |   End.X with   |             [This.ID]              |
   |      |  23  | PSP, USP & USD |                                    |
   | 36   | 0x00 | End.T with USD |             [This.ID]              |
   |      |  24  |                |                                    |
   | 37   | 0x00 |   End.T with   |             [This.ID]              |



Filsfils, et al.          Expires April 9, 2020                [Page 34]


Internet-Draft          SRv6 Network Programming            October 2019


   |      |  25  |    PSP&USD     |                                    |
   | 38   | 0x00 |   End.T with   |             [This.ID]              |
   |      |  26  |    USP&USD     |                                    |
   | 39   | 0x00 |   End.T with   |             [This.ID]              |
   |      |  27  | PSP, USP & USD |                                    |
   +------+------+----------------+------------------------------------+

                  Table 4: IETF - SRv6 Endpoint Behaviors

   The SRv6 Endpoint Behavior numbers are maintained by the working
   group until the RFC is published.  Note to the RFC Editor: Remove
   this paragraph before publication.

10.  Acknowledgements

   The authors would like to acknowledge Stefano Previdi, Dave Barach,
   Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul
   Wells, Robert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu
   Rajamanickam, David Toscano, Asif Islam, Jianda Liu, Yunpeng Zhang,
   Jiaoming Li, Narendra A.K, Mike Mc Gourty, Bhupendra Yadav, Sherif
   Toulan, Satish Damodaran, John Bettink, Kishore Nandyala Veera Venk,
   Jisu Bhattacharya and Saleem Hafeez.

11.  Contributors

   Daniel Bernier
   Bell Canada
   Canada

   Email: daniel.bernier@bell.ca

   Dirk Steinberg
   Lapishills Consulting Limited
   Cyprus

   Email: dirk@lapishills.com

   Robert Raszuk
   Bloomberg LP
   United States of America

   Email: robert@raszuk.net

   Bruno Decraene
   Orange
   France

   Email: bruno.decraene@orange.com



Filsfils, et al.          Expires April 9, 2020                [Page 35]


Internet-Draft          SRv6 Network Programming            October 2019


   Bart Peirens
   Proximus
   Belgium

   Email: bart.peirens@proximus.com

   Hani Elmalky
   Ericsson
   United States of America

   Email: hani.elmalky@gmail.com

   Prem Jonnalagadda
   Barefoot Networks
   United States of America

   Email: prem@barefootnetworks.com

   Milad Sharif
   Barefoot Networks
   United States of America

   Email: msharif@barefootnetworks.com

   David Lebrun
   Google
   Belgium

   Email: dlebrun@google.com

   Stefano Salsano
   Universita di Roma "Tor Vergata"
   Italy

   Email: stefano.salsano@uniroma2.it

   Ahmed AbdelSalam
   Gran Sasso Science Institute
   Italy

   Email: ahmed.abdelsalam@gssi.it

   Gaurav Naik
   Drexel University
   United States of America

   Email: gn@drexel.edu




Filsfils, et al.          Expires April 9, 2020                [Page 36]


Internet-Draft          SRv6 Network Programming            October 2019


   Arthi Ayyangar
   Arista
   United States of America

   Email: arthi@arista.com

   Satish Mynam
   Innovium Inc.
   United States of America

   Email: smynam@innovium.com

   Wim Henderickx
   Nokia
   Belgium

   Email: wim.henderickx@nokia.com

   Shaowen Ma
   Juniper
   Singapore

   Email: mashao@juniper.net

   Ahmed Bashandy
   Individual
   United States of America

   Email: abashandy.ietf@gmail.com

   Francois Clad
   Cisco Systems, Inc.
   France

   Email: fclad@cisco.com

   Kamran Raza
   Cisco Systems, Inc.
   Canada

   Email: skraza@cisco.com

   Darren Dukes
   Cisco Systems, Inc.
   Canada

   Email: ddukes@cisco.com




Filsfils, et al.          Expires April 9, 2020                [Page 37]


Internet-Draft          SRv6 Network Programming            October 2019


   Patrice Brissete
   Cisco Systems, Inc.
   Canada

   Email: pbrisset@cisco.com

   Zafar Ali
   Cisco Systems, Inc.
   United States of America

   Email: zali@cisco.com

12.  References

12.1.  Normative References

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
              Routing Header (SRH)", draft-ietf-6man-segment-routing-
              header-23 (work in progress), September 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

12.2.  Informative References

   [I-D.ali-spring-srv6-oam]
              Ali, Z., Filsfils, C., Kumar, N., Pignataro, C.,
              faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima,
              S., Raszuk, R., daniel.voyer@bell.ca, d., Dawra, G.,
              Peirens, B., Chen, M., and G. Naik, "Operations,
              Administration, and Maintenance (OAM) in Segment Routing
              Networks with IPv6 Data plane (SRv6)", draft-ali-spring-
              srv6-oam-02 (work in progress), October 2018.

   [I-D.bashandy-isis-srv6-extensions]
              Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
              Z. Hu, "IS-IS Extensions to Support Routing over IPv6
              Dataplane", draft-bashandy-isis-srv6-extensions-05 (work
              in progress), March 2019.




Filsfils, et al.          Expires April 9, 2020                [Page 38]


Internet-Draft          SRv6 Network Programming            October 2019


   [I-D.dawra-idr-bgpls-srv6-ext]
              Dawra, G., Filsfils, C., Talaulikar, K., Chen, M.,
              daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and
              H. Elmalky, "BGP Link State Extensions for SRv6", draft-
              dawra-idr-bgpls-srv6-ext-06 (work in progress), March
              2019.

   [I-D.dawra-idr-srv6-vpn]
              Dawra, G., Filsfils, C., Dukes, D., Brissette, P.,
              Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d.,
              daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
              Decraene, B., Matsushima, S., and S. Zhuang, "BGP
              Signaling for SRv6 based Services.", draft-dawra-idr-
              srv6-vpn-05 (work in progress), October 2018.

   [I-D.filsfils-spring-srv6-net-pgm-illustration]
              Filsfils, C., Camarillo, P., Li, Z., Matsushima, S.,
              Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and
              J. Leddy, "Illustrations for SRv6 Network Programming",
              draft-filsfils-spring-srv6-net-pgm-illustration-01 (work
              in progress), August 2019.

   [I-D.filsfils-spring-srv6-net-pgm-insertion]
              Filsfils, C., Camarillo, P., Leddy, J.,
              daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
              NET-PGM extension: Insertion", draft-filsfils-spring-srv6-
              net-pgm-insertion-00 (work in progress), September 2019.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
              bogdanov@google.com, b., and P. Mattes, "Segment Routing
              Policy Architecture", draft-ietf-spring-segment-routing-
              policy-03 (work in progress), May 2019.

   [I-D.raza-spring-srv6-yang]
              Raza, K., Rajamanickam, J., Liu, X., Hu, Z., Hussain, I.,
              Shah, H., daniel.voyer@bell.ca, d., Elmalky, H.,
              Matsushima, S., Horiba, K., and A. Abdelsalam, "YANG Data
              Model for SRv6 Base and Static", draft-raza-spring-
              srv6-yang-04 (work in progress), July 2019.

   [I-D.xuclad-spring-sr-service-programming]
              Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
              d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
              Henderickx, W., and S. Salsano, "Service Programming with
              Segment Routing", draft-xuclad-spring-sr-service-
              programming-02 (work in progress), April 2019.




Filsfils, et al.          Expires April 9, 2020                [Page 39]


Internet-Draft          SRv6 Network Programming            October 2019


   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
              December 1998, <https://www.rfc-editor.org/info/rfc2473>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437,
              DOI 10.17487/RFC6437, November 2011,
              <https://www.rfc-editor.org/info/rfc6437>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

Authors' Addresses

   Clarence Filsfils (editor)
   Cisco Systems, Inc.
   Belgium

   Email: cf@cisco.com


   Pablo Camarillo Garvia (editor)
   Cisco Systems, Inc.
   Spain

   Email: pcamaril@cisco.com


   John Leddy
   Individual Contributor
   United States of America

   Email: john@leddy.net







Filsfils, et al.          Expires April 9, 2020                [Page 40]


Internet-Draft          SRv6 Network Programming            October 2019


   Daniel Voyer
   Bell Canada
   Canada

   Email: daniel.voyer@bell.ca


   Satoru Matsushima
   SoftBank
   1-9-1,Higashi-Shimbashi,Minato-Ku
   Tokyo  105-7322
   Japan

   Email: satoru.matsushima@g.softbank.co.jp


   Zhenbin Li
   Huawei Technologies
   China

   Email: lizhenbin@huawei.com






























Filsfils, et al.          Expires April 9, 2020                [Page 41]


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