SFC Non-transparent SF

Registered by Louis Fourie on 2017-03-14

Service Functions (SF) that do not support SFC encapsulation, such as NSH, require
an SFC Proxy to re-classify a packet that is returned from the egress port of the
SF. The SFC Proxy uses the N-tuple values of a packet header to re-classify a packet.
However, if the SF is non-transparent (it modifies a part of the N-tuple of a packet),
then re-classification cannot be done correctly.
See https://datatracker.ietf.org/doc/draft-song-sfc-legacy-sf-mapping/

This blueprint provides a mechanism for configuring the SFC Proxy to account for the N-tuple translation of the SF.

Blueprint information

Status:
Complete
Approver:
Louis Fourie
Priority:
Undefined
Drafter:
Louis Fourie
Direction:
Needs approval
Assignee:
Louis Fourie
Definition:
Approved
Series goal:
None
Implementation:
Implemented
Milestone target:
None
Started by
Louis Fourie on 2017-05-21
Completed by
Louis Fourie on 2017-05-22

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.