Opened 6 years ago

Last modified 6 years ago

#16 new defect

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

Reported by: mohamed.boucadair@… Owned by: draft-ietf-sfc-control-plane@…
Priority: major Milestone:
Component: control-plane Version:
Severity: - Keywords:


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 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.


Change History (1)

comment:1 Changed 6 years ago by mohamed.boucadair@…

These two sections are moved to the core text in -01. These two sections appear in -01 as: 4.10.4 and 4.10.5.

Note: See TracTickets for help on using tickets.