Open Stack

Hi networking-sfc,

At the latest IRC meeting [1] it was agreed to split TAP from the possible insertion modes (initial spec version [2]).

I took the ARs to propose coexistence of insertion modes, correlation and (now) a new tap-enabled attribute, and send this email about possible directions.

Here are my thoughts, let me know yours:


1.       My expectation for future PP and PPG if TAP+insertion modes go ahead and nothing else changes (only relevant details outlined):

port-pair (service-function-params):
                correlation:
                                - MPLS
                                - None (default)
port-pair-group (port-pair-group-params):
                insertion-mode:
                                - L2
                                - L3 (default)
                tap-enabled:
                                - False (default)
                                - True


2.       What I propose for future PP and PPG (only relevant details outlined):

port-pair (service-function-params):
                <remove correlation - reasons outlined in [3] and below>
port-pair-group (port-pair-group-params):
                mode:
                                - L2
                                - L3 (default)
                                - MPLS
                                - NSH
                tap-enabled:
                                - False (default)
                                - True

With what's proposed in 2.:
- every combination will be possible with no clashes and no validation required.
- port-pair-groups will always group "homogeneous" sets of port-pairs, making load-balacing and next-hop processing simpler and consistent.
- the "forwarding" details of a Service Function are no longer dictated both by port-pair and port-pair-group, but rather only by port-pair-group.

Are there any use cases for having next-hop SF candidates (individual port-pairs) supporting different SFC Encapsulation protocols?
I understand, however, that removing correlation from port-pairs might not be ideal given that it's a subtractive API change.

[1] http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-03-16-17.02.html
[2] https://review.openstack.org/#/c/442195/
[3] https://github.com/openstack/networking-sfc/blob/17c537b35d41a3e1fd80da790ae668e52cea6b88/doc/source/system_design%20and_workflow.rst#usage

Best regards,
Igor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170320/ca729c42/attachment.html>