Subject: [sfc] #16 (control-plane): RSP-related Considerations (L. Dunbar/A. Malis)

From: "sfc issue tracker" <[email-masked]>
Date: Fri, 18 Sep 2015 06:08:18 -0000

#16: RSP-related Considerations (L.  Dunbar/A.  Malis)

 Discuss what to do with this appendix.

 ==
 Appendix A.  RSP-related Considerations

    NOTE: This section records some contributions proposed by L.  Dunbar
    and A.  Malis, but have not been discussed yet among authors.

 A.1.  Encoding the Exact SFF-SF-sequence in Data Packets

    Encoding the exact RSP in every packet has the benefit and the issues
    associated with source routing.  This approach may not be optimal
    when the SFP doesn't change very frequently, as in minutes or hours.

    There are contexts that it might not be feasible for the head end
    Classifier to be notified of the changes of SFF-sequence or SFF-SF-
    Sequence for a given SFP because of the time taken for the
    notification and the limited capability of the Classifier nodes.

 A.2.  Fully Controlled SFF-SF-Sequence for a SFP

    This section describes the information that can be exchanged over C2
    interface (Section 3.3.2) when the SFC Control Element explicitly
    passes the steering policies to all SFFs for the SFF-SF-Sequence of a
    given SFC.  In this model, each SFF doesn't need to signal other SFFs
    for the SFP.

    Suppose the SFC ID for this SFP is "yellow", an example of policy to
    "sff-a" is depicted in Figure 2 (for illustration proposes)

               Matching                     |       Action
    ----------------------------------------+-------------------------
    SFC ID = "yellow" & ingress = sffx-port | next-hop: "sf2" & VID
    SFC ID = "yellow" & ingress = sf2-port  | next-hop: "sf3" & VID
    SFC ID = "yellow" & ingress = sf3-port  | next-hop: sff-b

         Figure 2: Example of Traffic Steering Policy to a SFF node

    The SFF nodes may not be directly adjacent to each other.  They can
    be interconnected by tunnels, such as GRE, VxLAN, etc.  SFs are
    attached to a SFF node or SFC Proxy node via Ethernet link or other
    link types.  Therefore, the steering policies to a SFF node for
    service function chain depends on if the packet comes from previous
    SFF or comes from a specific SF, i.e., the SFC Forwarding Policy
    Table entries have to be ingress port specific.  There are multiple
    different steering policies for one flow within one SFF and each set
    of steering policies is specific for an ingress port.

    The semantics of traffic steering rules can be "Match" and "Action",
    similar to the "route" described in [I-D.ietf-i2rs-rib-info-model].
    The "match" and "action" for distinct ports can be different.  The
    matching criteria for SFF can be more sophisticated.  For example,
    the matching criteria could be any fields in the data packets:

    o  Ingress port
    o  Destination MAC address
    o  Source MAC address
    o  VLAN_id,
    o  Destination IP address
    o  Source IP address
    o  Source port number
    o  Destination port number
    o  DSCP
    o  Packet size, etc., or any combination thereof.

    A SFF node may not support some of the matching criteria listed
    above.  It is important that SFC control plane can retrieve the
    supported matching criteria by SFF nodes.  The "Actions" for traffic
    steering could be to steer traffic to the attached service function
    or SF instantiations via a specific port.

    The "Actions" to SFC Proxy may include a method to map the SFC
    Identifier carried in the packet header to a locally significant link
    identifier, e.g., VLAN-ID, and a method to construct and encapsulate
    the SFC header back to the packets when they come back from the
    attached SFs.

    This approach does not require using an end-to-end signaling protocol
    among Classier nodes and SFF nodes.  However, there may be problems
    encountered if SFF nodes are not updated in the proper order or not
    at the same time.  For example, if the SFF "A" and SFF "C" get flow
    steering policies at slightly different times, some packets might not
    be directed to some service functions on a chain.
 ==========

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-sfc-control-
  [email-masked]       |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  control-plane            |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/sfc/trac/ticket/16>
sfc <http://tools.ietf.org/sfc/>