Open Stack

Hi Cathy,

I understand MPLS is a special protocol because:
- It allows Service Function Path identification (rfc7665) -> compatible with SFC Encapsulation
- It doesn't fully encapsulate the original frames -> incompatible with SFC Encapsulation
- Not necessary for this conversation, but also important to keep in mind: it can't transport additional metadata -> incompatible with SFC Encapsulation

So, I will start by discussing NSH specifically (being the fully-compatible SFC Encapsulation protocol). And so, the way I look at insertion modes (if split from correlations) is that in practice they become something I would describe as "SFC Proxy modes".

If a Service Function supports NSH, great, the NSH-encapsulated packets are fully exposed to the SFs and no "SFC Proxy mode" needs to be dictated (NSH is the mechanism itself). So, specifying L2 or L3 for insertion types would be of no meaning. At runtime and at the network forwarding level we might witness different ways of reaching the SFs, which could approximate L2 or L3 insertion types - but this isn't something to be modelled in networking-sfc's API but rather automatically controlled by the backend.

If a Service Function does not support NSH, we are in the presence of a legacy SF and so more information is needed to model how this SF expects packets (since there is no standard way). Consequently, specifying the insertion types, such as L2 or L3, is important. For the former, it means the SF machine has its interfaces running in promiscuous mode and is similar to a switch, for the latter it means the SF machine's interfaces are not in promiscuous mode and it is similar to a router.

With NSH, these insertion mode details are abstracted from the SFs.
The networking backend of neutron/networking-sfc will already know where each VM is and how to reach them and will  be responsible for making sure the NSH packet is delivered to the correct hop without needing additional information (from the networking-sfc API).

So, in summary, L2, L3, NSH and (in practice today @ networking-sfc) MPLS, are all mutually exclusive.

Best regards,
Igor.

From: Cathy Zhang [mailto:Cathy.H.Zhang at huawei.com]
Sent: Monday, March 20, 2017 6:05 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation

Hi Igor,

Moving the correlation from port-pair to port-pair-group makes sense. In the future I think we should add all new attributes for a SF to port-pair-group-param.

But I think L2/L3 is different from encap type NSH or MPLS. An L3 type SF can support either NSH or MPLS. I would suggest the following:

port-pair-group (port-pair-group-params):
                insertion-mode:
                                - L2
                                - L3 (default)
               Correlation:
                                - MPLS
                                - NSH
                tap-enabled:
                                - False (default)
                                - True

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.cardoso at intel.com]
Sent: Monday, March 20, 2017 8:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation

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/20170321/ab42c9e5/attachment.html>