+--------------------------------------------+
             |  Type = 3 (1 octet)                        |
             +--------------------------------------------|
             |  Length (2 octets)                         |
             +--------------------------------------------|
             |  Service Function Type (2 octets)          |
             +--------------------------------------------|
             |  SFIR-RD List (variable)                   |
             +--------------------------------------------+
                 
               

Figure 7: The Format of the SFT TLV

The fields are as follows:

• Type is set to 3 to indicate an SFT TLV.
• Length indicates the length in octets of the Service Function Type and SFIR-RD List fields.
• The Service Function Type is used to identify a Service Function Instance Route in the service function overlay network which, in turn, will allow lookup of routes to SFIs implementing the SF. SFT values in the range 1-31 are Special Purpose SFT values and have meanings defined by the documents that describe them - the value 'Change Sequence' is defined in Section 6.1 of this document.
• The SFIR-RD List is made up of one or more SFIR-RD values from the advertisements of SFIs in SFIRs. An SFIR-RD of value zero has special meaning as described in Section 5. Each entry in the list is 8 octets long, and the number of entries in the list can be deduced from the value of the Length field.

3.2.2. General Rules For The SFP Attribute

It is possible for the same SFI, as described by an SFIR, to be used in multiple SFPRs.

When two SFPRs have the same SPI but different SFPR-RDs there can be three cases:

• Two or more Controllers are originating SFPRs for the same SFP. In this case the content of the SFPRs is identical and the duplication is to ensure receipt and to provide Controller redundancy.
• There is a transition in content of the advertised SFP and the advertisements may originate from one or more Controllers. In this case the content of the SFPRs will be different.
• The reuse of an SPI may result from a configuration error.

In all cases, there is no way for the receiving SFF to know which SFPR to process, and the SFPRs could be received in any order. At any point in time, when multiple SFPRs have the same SPI but different SFPR-RDs, the SFF MUST use the SFPR with the numerically lowest SFPR-RD. The SFF SHOULD log this occurrence to assist with debugging.

Furthermore, a Controller that wants to change the content of an SFP is RECOMMENDED to use a new SPI and so create a new SFP onto which the Classifiers can transition packet flows before the SFPR for the old SFP is withdrawn. This avoids any race conditions with SFPR advertisements.

Additionally, a Controller SHOULD NOT re-use an SPI after it has withdrawn the SFPR that used it until at least a configurable amount of time has passed. This timer SHOULD have a default of one hour.

4. Mode of Operation

This document describes the use of BGP as a control plane to create and manage a service function overlay network.

4.1. Route Targets

The main feature introduced by this document is the ability to create multiple service function overlay networks through the use of Route Targets (RTs) [RFC4364].

Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs. The RT carried by a particular SFIR or SFPR is determined by the provisioning of the route's originator.

Every node in a service function overlay network is configured with one or more import RTs. Thus, each SFF will import only the SFPRs with matching RTs allowing the construction of multiple service function overlay networks or the instantiation of Service Function Chains within an L3VPN or EVPN instance (see Section 7.4). An SFF that has a presence in multiple service function overlay networks (i.e., imports more than one RT) may find it helpful to maintain separate forwarding state for each overlay network.

4.2. Service Function Instance Routes

The SFIR (see Section 3.1) is used to advertise the existence and location of a specific Service Function Instance and consists of:

• The RT as just described.
• A Service Function Type (SFT) that is the category of Service Function that is provided (such as "firewall").
• A Route Distinguisher (RD) that is unique to a specific instance of a service function.

4.3. Service Function Path Routes

The SFPR (see Section 3.2) describes a specific path of a Service Function Chain. The SFPR contains the Service Path Identifier (SPI) used to identify the SFP in the NSH in the data plane. It also contains a sequence of Service Indexes (SIs). Each SI identifies a hop in the SFP, and each hop is a choice between one of more SFIs.

As described in this document, each Service Function Path Route is identified in the service function overlay network by an RD and an SPI. The SPI is unique across all service function overlay networks supported by the underlay network.

The SFPR advertisement comprises:

• An RT as described in Section 4.1.
• A tuple that identifies the SFPR
  • An RD that identifies an advertisement of an SFPR.
  • The SPI that uniquely identifies this path within all service function overlay networks supported by the underlay network. This SPI also appears in the NSH.
• A series of Service Indexes. Each SI is used in the context of a particular SPI and identifies one or more SFs (distinguished by their SFTs) and for each SF a set of SFIs that instantiate the SF. The values of the SI indicate the order in which the SFs are to be executed in the SFP that is represented by the SPI.
• The SI is used in the NSH to identify the entries in the SFP. Note that the SI values have meaning only relative to a specific path. They have no semantic other than to indicate the order of Service Functions within the path and are assumed to be monotonically decreasing from the start to the end of the path [I-D.ietf-sfc-nsh].
• Each Service Index is associated with a set of one or more Service Function Instances that can be used to provide the indexed Service Function within the path. Each member of the set comprises:
  • The RD used in an SFIR advertisement of the SFI.
  • The SFT that indicates the type of function as used in the same SFIR advertisement of the SFI.

This may be summarized as follows where the notations "SFPR-RD" and "SFIR-RD" are used to distinguish the two different RDs:

• RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } }

Where:

• RT: Route Target
• SFPR-RD: The Route Descriptor of the Service Function Path Route advertisement
• SPI: Service Path Identifier used in the NSH
• m: The number of hops in the Service Function Path
• n: The number of choices of Service Function Type for a specific hop
• p: The number of choices of Service Function Instance for given Service Function Type in a specific hop
• SI: Service Index used in the NSH to indicate a specific hop
• SFT: The Service Function Type used in the same advertisement of the Service Function Instance Route
• SFIR-RD: The Route Descriptor used in an advertisement of the Service Function Instance Route

Note that the values of SI are from the set {255, ..., 1} and are monotonically decreasing within the SFP. SIs MUST appear in order within the SFPR (i.e., monotonically decreasing) and MUST NOT appear more than once. Malformed SFPRs MUST be discarded and MUST cause any previous instance of the SFPR (same SFPR-RD and SPI) to be discarded.

The choice of SFI is explained further in Section 5. Note that an SFIR-RD value of zero has special meaning as described in that Section.

4.4. Classifier Operation

As shown in Figure 1, the Classifier is a special Service Function that is used to assign packets to an SFP.

The Classifier is responsible for determining to which packet flow a packet belongs (usually by inspecting the packet header), imposing an NSH, and initializing the NSH to include the SPI of the selected SFPR and to include the SI from first hop of the selected SFP.

The Classifier may also provide an entropy indicator as described in Section 7.1.

4.5. Service Function Forwarder Operation

Each packet sent to an SFF is transmitted encapsulated in an NSH. The NSH includes an SPI and SI: the SPI indicates the SFPR advertisement that announced the Service Function Path; the tuple SPI/SI indicates a specific hop in a specific path and maps to the RD/SFT of a particular SFIR advertisement.

When an SFF gets an SFPR advertisement it will first determine whether to import the route by examining the RT. If the SFPR is imported the SFF then determines whether it is on the SFP by looking for its own SFIR-RDs in the SFPR. For each occurrence in the SFP, the SFF creates forwarding state for incoming packets and forwarding state for outgoing packets that have been processed by the specified SFI.

The SFF creates local forwarding state for packets that it receives from other SFFs. This state makes the association between the SPI/SI in the NSH of the received packet and one or more specific local SFIs as identified by the SFIR-RD/SFT. If there are multiple local SFIs that match this is because a single advertisement was made for a set of equivalent SFIs and the SFF may use local policy (such as load balancing) to determine to which SFI to forward a received packet.

The SFF also creates next hop forwarding state for packets received back from the local SFI that need to be forwarded to the next hop in the SFP. There may be a choice of next hops as described in Section 4.3. The SFF could install forwarding state for all potential next hops, or it could choose to only install forwarding state to a subset of the potential next hops. If a choice is made then it will be as described in Section 5.

The installed forwarding state may change over time reacting to changes in the underlay network and the availability of particular SFIs.

Note that SFFs only create and store forwarding state for the SFPs on which they are included. They do not retain state for all SFPs advertised.

An SFF may also install forwarding state to support looping, jumping, and branching. The protocol mechanism for explicit control of looping, jumping, and branching is described in Section 6.1 using a special value of the SFT within an entry in an SFPR.

5. Selection in Service Function Paths

As described in Section 2 the SPI/SI in the NSH passed back from an SFI to the SFF may leave the SFF with a choice of next hop SFTs, and a choice of SFIs for each SFT. That is, the SPI indicates an SFPR, and the SI indicates an entry in that SFPR. Each entry in an SFPR is a set of one or more SFT/SFIR-RD pairs. The SFF must choose one of these, identify the SFF that supports the chosen SFI, and send the packet to that next hop SFF.

In the typical case, the SFF chooses a next hop SFF by looking at the set of all SFFs that support the SFs identified by the SI (that set having been advertised in individual SFIR advertisements), finding the one or more that are "nearest" in the underlay network, and choosing between next hop SFFs using its own load-balancing algorithm.

An SFI may influence this choice process by passing additional information back along with the packet and NSH. This information may influence local policy at the SFF to cause it to favor a next hop SFF (perhaps selecting one that is not nearest in the underlay), or to influence the load-balancing algorithm.

This selection applies to the normal case, but also applies in the case of looping, jumping, and branching (see Section 6).

Suppose an SFF in a particular service overlay network (identified by a particular import RT, RT-z) needs to forward an NSH-encapsulated packet whose SPI is SPI-x and whose SI is SI-y. It does the following:

1. It looks for an installed SFPR that carries RT-z and that has SPI-x in its NLRI. If there is none, then such packets cannot be forwarded.
2. From the SFP attribute of that SFPR, it finds the Hop TLV with SI value set to SI-y. If there is no such Hop TLV, then such packets cannot be forwarded.
3. It then finds the "relevant" set of SFIRs by going through the list of SFT TLVs contained in the Hop TLV as follows:
   1. An SFIR is relevant if it carries RT-z, the SFT in its NLRI matches the SFT value in one of the SFT TLVs, and the RD value in its NLRI matches an entry in the list of SFIR-RDs in that SFT TLV.
   2. If an entry in the SFIR-RD list of an SFT TLV contains the value zero, then an SFIR is relevant if it carries RT-z and the SFT in its NLRI matches the SFT value in that SFT TLV. I.e., any SFIR in the service function overlay network defined by RT-z and with the correct SFT is relevant.

Each of the relevant SFIRs identifies a single SFI, and contains a Tunnel Encapsulation attribute that specifies how to send a packet to that SFI. For a particular packet, the SFF chooses a particular SFI from the set of relevant SFIRs. This choice is made according to local policy.

A typical policy might be to figure out the set of SFIs that are closest, and to load balance among them. But this is not the only possible policy.

6. Looping, Jumping, and Branching

As described in Section 2 an SFI or an SFF may cause a packets to "loop back" to a previous SF on a path in order that a sequence of functions may be re-executed. This is simply achieved by replacing the SI in the NSH with a higher value instead of decreasing it as would normally be the case to determine the next hop in the path.

Section 2 also describes how an SFI or an SFF may cause a packets to "jump forward" to an SF on a path that is not the immediate next SF in the SFP. This is simply achieved by replacing the SI in the NSH with a lower value than would be achieved by decreasing it by the normal amount.

A more complex option to move packets from one SFP to another is described in [I-D.ietf-sfc-nsh] and Section 2 where it is termed "branching". This mechanism allows an SFI or SFF to make a choice of downstream treatments for packets based on local policy and output of the local SF. Branching is achieved by changing the SPI in the NSH to indicate the new path and setting the SI to indicate the point in the path at which the packets should enter.

Note that the NSH does not include a marker to indicate whether a specific packet has been around a loop before. Therefore, the use of NSH metadata may be required in order to prevent infinite loops.

6.1. Protocol Control of Looping, Jumping, and Branching

If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT value "Change Sequence" (see Section 10) then this is an indication that the SFF may make a loop, jump, or branch according to local policy and information returned by the local SFI.

In this case, the SPI and SI of the next hop is encoded in the eight bytes of an entry in the SFIR-RD list as follows:

• 3 bytes SPI
• 2 bytes SI
• 3 bytes Reserved (SHOULD be set to zero and ignored)

If the SI in this encoding is not part of the SFPR indicated by the SPI in this encoding, then this is an explicit error that SHOULD be detected by the SFF when it parses the SFPR. The SFPR SHOULD NOT cause any forwarding state to be installed in the SFF and packets received with the SPI that indicates this SFPR SHOULD be silently discarded.

If the SPI in this encoding is unknown, the SFF SHOULD NOT install any forwarding state for this SFPR, but MAY hold the SFPR pending receipt of another SFPR that does use the encoded SPI.

If the SPI matches the current SPI for the path, this is a loop or jump. In this case, if the SI is greater than to the current SI it is a loop. If the SPI matches and the SI is less than the next SI, it is a jump.

If the SPI indicates anther path, this is a branch and the SI indicates the point at which to enter that path.

The Change Sequence SFT is just another SFT that may appear in a set of SFI/SFT tuples within an SI and is selected as described in Section 5.

Note that Special Purpose SFTs MUST NOT be advertised in SFIRs.

6.2. Implications for Forwarding State

Support for looping and jumping requires that the SFF has forwarding state established to an SFF that provides access to an instance of the appropriate SF. This means that the SFF must have seen the relevant SFIR advertisements and known that it needed to create the forwarding state. This is a matter of local configuration and implementation: for example, an implementation could be configured to install forwarding state for specific looping/jumping.

Support for branching requires that the SFF has forwarding state established to an SFF that provides access to an instance of the appropriate entry SF on the other SFP. This means that the SFF must have seen the relevant SFIR and SFPR advertisements and known that it needed to create the forwarding state. This is a matter of local configuration and implementation: for example, an implementation could be configured to install forwarding state for specific branching (identified by SPI and SI).

7. Advanced Topics

This section highlights several advanced topics introduced elsewhere in this document.

7.1. Preserving Entropy

Forwarding decisions in the underlay network in the presence of equal cost multipath (ECMP) are usually made by inspecting key invariant fields in a packet header so that all packets from the same packet flow receive the same forwarding treatment. However, when an NSH is included in a packet, those key fields may be inaccessible. For example, the fields may be too far inside the packet for a forwarding engine to quickly find them and extract their values, or the node performing the examination may be unaware of the format and meaning of the NSH and so unable to parse far enough into the packet.

Various mechanisms exist within forwarding technologies to include an "entropy indicator" within a forwarded packet. For example, in MPLS there is the entropy label [RFC6790], while for encapsulations in UDP the source port field is often used to carry an entropy indicator (such as for MPLS in UDP [RFC7510]).

Implementations of this specification are RECOMMENDED to include an entropy indicator within the packet's underlay network header, and SHOULD preserve any entropy indicator from a received packet for use on the same packet when it is forwarded along the path but MAY choose to generate a new entropy indicator so long as the method used is constant for all packets. Note that preserving per packet entropy may require that the entropy indicator is passed to and returned by the SFI to prevent the SFF from having to maintain per-packet state.

7.2. Correlating Service Function Path Instances

It is often useful to create bidirectional SFPs to enable packet flows to traverse the same set of SFs, but in the reverse order. However, packets on SFPs in the data plane (per [I-D.ietf-sfc-nsh]) do not contain a direction indicator, so each direction must use a different SPI.

As described in Section 3.2.1.1 an SFPR can contain one or more correlators encoded in Association TLVs. If the Association Type indicates "Bidirectional SFP" then the SFP advertised in the SFPR is one direction of a bidirectional pair of SFPs where the other in the pair is advertised in the SFPR with RD as carried in the Associated SFPR-RD field of the Association TLV. The SPI carried in the Associated SPI field of the Association TLV provides a cross-check and should match the SPI advertised in the SFPR with RD as carried in the Associated SFPR-RD field of the Association TLV.

As noted in Section 3.2.1.1 SFPRs reference each other one SFPR advertisement will be received before the other. Therefore processing of an association will require that the first SFPR is not rejected simply because the Associated SFPR-RD it carries is unknown. However, the SFP defined by the first SFPR is valid and SHOULD be available for use as a unidirectional SFP even in the absence of an advertisement of its partner.

Furthermore, in error cases where SFPR-a associates with SFPR-b, but SFPR-b associates with SFPR-c such that a bidirectional pair of SFPs cannot be formed, the individual SFPs are still valid and SHOULD be available for use as unidirectional SFPs. An implementation SHOULD log this situation because it represents a Controller error.

Usage of a bidirectional SFP may be programmed into the Classifiers by the Controller. Alternatively, a Classifier may look at incoming packets on a bidirectional packet flow, extract the SPI from the received NSH, and look up the SFPR to find the reverse direction SFP to use when it sends packets.

See Section 8 for an example of how this works.

7.3. Considerations for Stateful Service Functions

Some service functions are stateful. That means that they build and maintain state derived from configuration or from the packet flows that they handle. In such cases it can be important or necessary that all packets from a flow continue to traverse the same instance of a service function so that the state can be leveraged and does not need to be regenerated.

In the case of bidirectional SFPs, it may be necessary to traverse the same instances of a stateful service function in both directions. A firewall is a good example of such a service function.

This issue becomes a concern where there are multiple parallel instances of a service function and a determination of which one to use could normally be left to the SFF as a load-balancing or local policy choice.

For the forward direction SFP, the concern is that the same choice of service function is made for all packets of a flow under normal network conditions. It may be possible to guarantee that the load balancing functions applied in the SFFs are stable and repeatable, but a controller that constructs SFPs might not want to trust to this. The controller can, in these cases, build a number of more specific SFPs each traversing a specific instance of the stateful SFs. In this case, the load balancing choice can be left up to the Classifier. Thus the Classifier selects which instance of a stateful SF is used by a particular flow by selecting the SFP that the flow uses.

For bidirectional SFPs where the same instance of a stateful SF must be traversed in both directions, it is not enough to leave the choice of service function instance as a local choice even if the load balancing is stable because coordination would be required between the decision points in the forward and reverse directions and this may be hard to achieve in all cases except where it is the same SFF that makes the choice in both directions.

Note that this approach necessarily increases the amount of SFP state in the network (i.e., there are more SFPs). It is possible to mitigate this effect by careful construction of SFPs built from a concatenation of other SFPs.

Section 8.9 includes some simple examples of SFPs for stateful service functions.

7.4. VPN Considerations and Private Service Functions

Likely deployments include reserving specific instances of Service Functions for specific customers or allowing customers to deploy their own Service Functions within the network. Building Service Functions in such environments requires that suitable identifiers are used to ensure that SFFs distinguish which SFIs can be used and which cannot.

This problem is similar to how VPNs are supported and is solved in a similar way. The RT field is used to indicate a set of Service Functions from which all choices must be made.

7.5. Flow Spec for SFC Classifiers

[RFC5575] defines a set of BGP routes that can be used to identify the packets in a given flow using fields in the header of each packet, and a set of actions, encoded as extended communities, that can be used to disposition those packets. This document enables the use of RFC 5575 mechanisms by SFC Classifiers by defining a new action extended community called "Flow spec for SFC classifiers" identified by the value TBD4.

This extended community is encoded as an 8-octet value, as shown in Figure 8:

          
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type=0x80     | Sub-Type=TBD4 |  SPI                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  SPI  (cont.) |   SI          |  SFT                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          
        

          
 ---------------
| Tunnel Labels |
+---------------+
~   Optional    ~
~ Entropy Label ~
+---------------+
|   SI Label    |
+---------------+
|               |
~    Payload    ~
|               |
 ---------------
           
         

           
   SFF1 192.0.2.1
   SFF2 192.0.2.2
   SFF3 192.0.2.3
   SFF4 192.0.2.4
           
         

           
   SFF1 SFT=41 and SFT=42
   SFF2 SFT=41 and SFT=43
   SFF3 SFT=42 and SFT=44
   SFF4 SFT=43 and SFT=44
           
         

           
       --------------
      |  Controller  |
      | 198.51.100.1 |   ------     ------    ------     ------
       --------------   | SFI  |   | SFI  |  | SFI  |   | SFI  |
                        |SFT=41|   |SFT=42|  |SFT=41|   |SFT=43|
                         ------     ------    ------     ------
                              \     /              \     /
                             ---------            ---------
               ----------   |   SFF1  |          |   SFF2  |
   Packet --> |          |  |192.0.2.1|          |192.0.2.2|
   Flows  --> |Classifier|   ---------            ---------  -->Dest
              |          |                                   -->
               ----------    ---------            ---------
                            |   SFF3  |          |   SFF4  |
                            |192.0.2.3|          |192.0.2.4|
                             ---------            ---------
                              /     \              /     \
                         ------     ------    ------     ------
                        | SFI  |   | SFI  |  | SFI  |   | SFI  |
                        |SFT=42|   |SFT=44|  |SFT=43|   |SFT=44|
                         ------     ------    ------     ------
           
         

           
   RD = 192.0.2.1,1, SFT = 41
   RD = 192.0.2.1,2, SFT = 42
   RD = 192.0.2.2,1, SFT = 41
   RD = 192.0.2.2,2, SFT = 43
   RD = 192.0.2.3,7, SFT = 42
   RD = 192.0.2.3,8, SFT = 44
   RD = 192.0.2.4,5, SFT = 43
   RD = 192.0.2.4,6, SFT = 44
           
         

           
   SFP1:  RD = 198.51.100.1,101, SPI = 15,
          [SI = 255, SFT = 41, RD = 192.0.2.1,1],
          [SI = 250, SFT = 43, RD = 192.0.2.2,2]
           
         

           
   SFP2:  RD = 198.51.100.1,102, SPI = 16,
          [SI = 255, SFT = 41, RD = 192.0.2.1,],
          [SI = 250, SFT = 43, {RD = 192.0.2.2,2,
                                RD = 192.0.2.4,5 } ]
           
         

           
   SFP3:  RD = 198.51.100.1,103, SPI = 17,
          [SI = 255, SFT = 41, RD = 192.0.2.1,1],
          [SI = 250, SFT = 44, RD = 0]
           
         

           
   SFP4:  RD = 198.51.100.1,104, SPI = 18,
          [SI = 255, SFT = 41, RD = 192.0.2.1,1],
          [SI = 250, {SFT = 43, RD = 192.0.2.2,2,
                      SFT = 44, RD = 192.0.2.3,8 } ]
           
         

           
  SFP5:  RD = 198.51.100.1,105, SPI = 19,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,106, Assoc-SPI = 20,
         [SI = 255, SFT = 41, RD = 192.0.2.1,1],
         [SI = 250, SFT = 43, RD = 192.0.2.2,2]

  SFP6:  RD = 198.51.100.1,106, SPI = 20,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,105, Assoc-SPI = 19,
         [SI = 254, SFT = 43, RD = 192.0.2.2,2],
         [SI = 249, SFT = 41, RD = 192.0.2.1,1]
           
         

           
  SFP7:  RD = 198.51.100.1,107, SPI = 21,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,108, Assoc-SPI = 22,
         [SI = 255, SFT = 41, RD = 192.0.2.1,1],
         [SI = 250, SFT = 43, RD = 192.0.2.2,2]

  SFP8:  RD = 198.51.100.1,108, SPI = 22,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,107, Assoc-SPI = 21,
         [SI = 254, SFT = 44, RD = 192.0.2.4,6],
         [SI = 249, SFT = 41, RD = 192.0.2.1,1]
          
         

           
   SFP9:  RD = 198.51.100.1,109, SPI = 23,
          [SI = 255, SFT = 41, RD = 192.0.2.1,1],
          [SI = 250, SFT = 44, RD = 192.0.2.4,5],
          [SI = 245, SFT = 1, RD = {SPI=23, SI=255, Rsv=0}],
          [SI = 245, SFT = 42, RD = 192.0.2.3,7]
           
         

           
   SFP10:  RD = 198.51.100.1,110, SPI = 24,
          [SI = 254, SFT = 42, RD = 192.0.2.3,7],
          [SI = 249, SFT = 43, RD = 192.0.2.2,2]

   SFP11:  RD = 198.51.100.1,111, SPI = 25,
          [SI = 255, SFT = 41, RD = 192.0.2.1,1],
          [SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}]
           
         

           
                ------     ------   ------   ------    ------
               | SFI  |   | SFIa | | SFIb | | SFIc |  | SFI  |
               |SFT=41|   |SFT=42| |SFT=42| |SFT=42|  |SFT=43|
                ------     ------\  ------  /------    ------
                     \            \   |    /           /
                    ---------     ---------     ---------
      ----------   |   SFF1  |   |   SFF2  |   |   SFF3  |
 --> |          |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|-->
 --> |Classifier|   ---------     ---------     ---------
     |          |
      ----------
           
         

           
   RD = 192.0.2.1,11, SFT = 41
   RD = 192.0.2.2,11, SFT = 42  (for SFIa)
   RD = 192.0.2.2,12, SFT = 42  (for SFIb)
   RD = 192.0.2.2,13, SFT = 42  (for SFIc)
   RD = 192.0.2.3,11, SFT = 43
           
         

           
   SFP12:  RD = 198.51.100.1,112, SPI = 26,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,113, Assoc-SPI = 27,
          [SI = 255, SFT = 41, RD = 192.0.2.1,11],
          [SI = 254, SFT = 42, {RD = 192.0.2.2,11,
                                     192.0.2.2,12,
                                     192.0.2.2,13 }],
          [SI = 253, SFT = 43, RD = 192.0.2.3,11]
           
         

           
   SFP13:  RD = 198.51.100.1,113, SPI = 27,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,112, Assoc-SPI = 26,
          [SI = 255, SFT = 43, RD = 192.0.2.3,11],
          [SI = 254, SFT = 42, {RD = 192.0.2.2,11,
                                     192.0.2.2,12,
                                     192.0.2.2,13 }],
          [SI = 253, SFT = 41, RD = 192.0.2.1,11]
           
         

           
   SFP14:  RD = 198.51.100.1,114, SPI = 28,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,117, Assoc-SPI = 31,
          [SI = 255, SFT = 41, RD = 192.0.2.1,11],
          [SI = 254, SFT = 42, RD = 192.0.2.2,11],
          [SI = 253, SFT = 43, RD = 192.0.2.3,11]

   SFP15:  RD = 198.51.100.1,115, SPI = 29,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,118, Assoc-SPI = 32,
          [SI = 255, SFT = 41, RD = 192.0.2.1,11],
          [SI = 254, SFT = 42, RD = 192.0.2.2,12],
          [SI = 253, SFT = 43, RD = 192.0.2.3,11]

   SFP16:  RD = 198.51.100.1,116, SPI = 30,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,119, Assoc-SPI = 33,
          [SI = 255, SFT = 41, RD = 192.0.2.1,11],
          [SI = 254, SFT = 42, RD = 192.0.2.2,13],
          [SI = 253, SFT = 43, RD = 192.0.2.3,11]

   SFP17:  RD = 198.51.100.1,117, SPI = 31,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,114, Assoc-SPI = 28,
          [SI = 255, SFT = 43, RD = 192.0.2.3,11],
          [SI = 254, SFT = 42, RD = 192.0.2.2,11],
          [SI = 253, SFT = 41, RD = 192.0.2.1,11]

   SFP18:  RD = 198.51.100.1,118, SPI = 32,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,115, Assoc-SPI = 29,
          [SI = 255, SFT = 43, RD = 192.0.2.3,11],
          [SI = 254, SFT = 42, RD = 192.0.2.2,12],
          [SI = 253, SFT = 41, RD = 192.0.2.1,11]

   SFP19:  RD = 198.51.100.1,119, SPI = 33,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,116, Assoc-SPI = 30,
          [SI = 255, SFT = 43, RD = 192.0.2.3,11],
          [SI = 254, SFT = 42, RD = 192.0.2.2,13],
          [SI = 253, SFT = 41, RD = 192.0.2.1,11]
           
         

           
                                     ------
                                    | SFIa |
                                    |SFT=42|
                                     ------
                      ------           |
                     | SFI  |      ---------
                     |SFT=41|     |   SFF5  |
                      ------    ..|192.0.2.5|..
                        |     ..:  ---------  :..
                    ---------.:                 :.---------
      ----------   |   SFF1  |     ---------     |   SFF3  |
 --> |          |..|192.0.2.1|....|   SFF6  |....|192.0.2.3| -->
 --> |Classifier|   ---------:    |192.0.2.6|    :---------
     |          |            :     ---------     :    |
      ----------             :         |         :  ------
                             :       ------      : | SFI  |
                             :..    | SFIb |   ..: |SFT=43|
                               :..  |SFT=42| ..:    ------
                                 :   ------  :
                                 :.---------.:
                                  |   SFF7  |
                                  |192.0.2.7|
                                   ---------
                                       |
                                     ------
                                    | SFIc |
                                    |SFT=42|
                                     ------
           
         

           
   RD = 192.0.2.1,11, SFT = 41
   RD = 192.0.2.5,11, SFT = 42  (for SFIa)
   RD = 192.0.2.6,11, SFT = 42  (for SFIb)
   RD = 192.0.2.7,11, SFT = 42  (for SFIc)
   RD = 192.0.2.3,11, SFT = 43
           
         

           
   SFP20:  RD = 198.51.100.1,120, SPI = 34,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,123, Assoc-SPI = 37,
          [SI = 255, SFT = 41, RD = 192.0.2.1,11],
          [SI = 254, SFT = 42, RD = 192.0.2.5,11],
          [SI = 253, SFT = 43, RD = 192.0.2.3,11]

   SFP21:  RD = 198.51.100.1,121, SPI = 35,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,124, Assoc-SPI = 38,
          [SI = 255, SFT = 41, RD = 192.0.2.1,11],
          [SI = 254, SFT = 42, RD = 192.0.2.6,11],
          [SI = 253, SFT = 43, RD = 192.0.2.3,11]

   SFP22:  RD = 198.51.100.1,122, SPI = 36,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,125, Assoc-SPI = 39,
          [SI = 255, SFT = 41, RD = 192.0.2.1,11],
          [SI = 254, SFT = 42, RD = 192.0.2.7,11],
          [SI = 253, SFT = 43, RD = 192.0.2.3,11]

   SFP23:  RD = 198.51.100.1,123, SPI = 37,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,120, Assoc-SPI = 34,
          [SI = 255, SFT = 43, RD = 192.0.2.3,11],
          [SI = 254, SFT = 42, RD = 192.0.2.5,11],
          [SI = 253, SFT = 41, RD = 192.0.2.1,11]

   SFP24:  RD = 198.51.100.1,124, SPI = 38,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,121, Assoc-SPI = 35,
          [SI = 255, SFT = 43, RD = 192.0.2.3,11],
          [SI = 254, SFT = 42, RD = 192.0.2.6,11],
          [SI = 253, SFT = 41, RD = 192.0.2.1,11]

   SFP25:  RD = 198.51.100.1,125, SPI = 39,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,122, Assoc-SPI = 36,
          [SI = 255, SFT = 43, RD = 192.0.2.3,11],
          [SI = 254, SFT = 42, RD = 192.0.2.7,11],
          [SI = 253, SFT = 41, RD = 192.0.2.1,11]
           
         

           
                                          ------
                                         | SFIa |
                                         |SFT=43|
                                          ------
               ------      ------           |
              | SFI  |    | SFI  |      ---------
              |SFT=41|    |SFT=42|     |   SFF5  |
               ------      ------    ..|192.0.2.5|..
                 |           |     ..:  ---------  :..
             ---------   ---------.:                 :.---------
    ------  |   SFF1  | |   SFF2  |     ---------     |   SFF3  |
-->|Class-|.|192.0.2.1|.|192.0.2.2|....|   SFF6  |....|192.0.2.3|-->
-->| ifier|  ---------   ---------:    |192.0.2.6|    :---------
    ------                        :     ---------     :    |
                                  :         |         :  ------
                                  :       ------      : | SFI  |
                                  :..    | SFIb |   ..: |SFT=44|
                                    :..  |SFT=43| ..:    ------
                                      :   ------  :
                                      :.---------.:
                                       |   SFF7  |
                                       |192.0.2.7|
                                        ---------
                                            |
                                          ------
                                         | SFIc |
                                         |SFT=43|
                                          ------
           
         

           
   RD = 192.0.2.1,11, SFT = 41
   RD = 192.0.2.2,11, SFT = 42
   RD = 192.0.2.5,11, SFT = 43  (for SFIa)
   RD = 192.0.2.6,11, SFT = 43  (for SFIb)
   RD = 192.0.2.7,11, SFT = 43  (for SFIc)
   RD = 192.0.2.3,11, SFT = 44
           
         

           
   SFP26:  RD = 198.51.100.1,126, SPI = 40,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,130, Assoc-SPI = 44,
          [SI = 255, SFT = 43, RD = 192.0.2.5,11],
          [SI = 254, SFT = 44, RD = 192.0.2.3,11]

   SFP27:  RD = 198.51.100.1,127, SPI = 41,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,131, Assoc-SPI = 45,
          [SI = 255, SFT = 43, RD = 192.0.2.6,11],
          [SI = 254, SFT = 44, RD = 192.0.2.3,11]

   SFP28:  RD = 198.51.100.1,128, SPI = 42,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,132, Assoc-SPI = 46,
          [SI = 255, SFT = 43, RD = 192.0.2.7,11],
          [SI = 254, SFT = 44, RD = 192.0.2.3,11]
           
         

           
   SFP29:  RD = 198.51.100.1,129, SPI = 43,
          [SI = 255, SFT = 41, RD = 192.0.2.1,11],
          [SI = 254, SFT = 42, RD = 192.0.2.2,11],
          [SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0},
                               RD = {SPI=41, SI=255, Rsv=0},
                               RD = {SPI=42, SI=255, Rsv=0} } ]
           
         

           
   SFP30:  RD = 198.51.100.1,130, SPI = 44,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,126, Assoc-SPI = 40,
          [SI = 255, SFT = 44, RD = 192.0.2.4,11],
          [SI = 254, SFT = 43, RD = 192.0.2.5,11],
          [SI = 253, SFT = 42, RD = 192.0.2.2,11],
          [SI = 252, SFT = 41, RD = 192.0.2.1,11]

   SFP31:  RD = 198.51.100.1,131, SPI = 45,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,127, Assoc-SPI = 41,
          [SI = 255, SFT = 44, RD = 192.0.2.4,11],
          [SI = 254, SFT = 43, RD = 192.0.2.6,11],
          [SI = 253, SFT = 42, RD = 192.0.2.2,11],
          [SI = 252, SFT = 41, RD = 192.0.2.1,11]

   SFP32:  RD = 198.51.100.1,132, SPI = 46,
         Assoc-Type = 1, Assoc-RD = 198.51.100.1,128, Assoc-SPI = 42,
          [SI = 255, SFT = 44, RD = 192.0.2.4,11],
          [SI = 254, SFT = 43, RD = 192.0.2.7,11],
          [SI = 253, SFT = 42, RD = 192.0.2.2,11],
          [SI = 252, SFT = 41, RD = 192.0.2.1,11]

           
         

           
    Type  | Name                  | Reference     | Date
    ------+-----------------------+---------------+---------------
    1     | Association TLV       | [This.I-D]    | Date-to-be-set
    2     | Hop TLV               | [This.I-D]    | Date-to-be-set
    3     | SFT TLV               | [This.I-D]    | Date-to-be-set
           
         

           
 Association Type | Name               | Reference  | Date
 -----------------+--------------------+------------+---------------
 1                | Bidirectional SFP  | [This.I-D] | Date-to-be-set
           
         

           
    Value | Name                  | Reference     | Date
    ------+-----------------------+---------------+---------------
    1     | Change Sequence       | [This.I-D]    | Date-to-be-set
           
         

        
   Stuart Mackie
   Juniper Networks

   Email: wsmackie@juinper.net

   Keyur Patel
   Arrcus, Inc.

   Email: keyur@arrcus.com