Open Stack

Hi Vikash,

It’s best to start with RFC 7665.

NSH decouples traffic forwarding from both the internals of packets and service functions. A special entity called SFF will take on that job. L2/L3 then become something that the SFF might have to deal with it. However, networking-sfc API doesn’t expose or require details about individual SFC dataplane elements such as the SFF… it is up to the backend/driver to know those low-level details.

NSH doesn’t classify and forward traffic itself. It’s only a header that identifies what and where in the chain the packet belongs to/is (plus other goodies such as metadata). Classifier will classify, SFF will forward.


By the way, I left a question on the tap blueprint whiteboard, I’ll copy it here too:
“Is there a use case for "tap chains"? I.e. not only you send traffic to your tap function, but then your tap function also sends traffic to a next hop too, so a full chain starts after traffic gets tapped at the first chain (the first chain also continues).”
I suppose the answer is no since you mentioned “Note - TAP SFs do not forward packet”, but I’m happy to hear extended info about this – from anyone reading.

Best regards,
Igor.

From: Vikash Kumar [mailto:vikash.kumar at oneconvergence.com]
Sent: Tuesday, March 21, 2017 3:32 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,
   Moving definition of SF from port-pair to port-pair-group looks good.
   TAP is also an insertion mode like L2/L3 but since it simplifies to keep 'tap-enabled' field also in port-pair-group, so it should be fine from implementation point of view (Note - TAP SFs do not forward packet). TAP enabled and L2/L3 insertion mode should be mutually exclusive.
   According to IETF draft NSH can classify & forward traffic (correct ?) but then the draft assumes uniformity of working of devices (which IMHO refers L3) which doesn't cover the entire use case. Can insertion mode (L2/L3) & traffic encapsulation(NSH) co-exist also ?



On Mon, Mar 20, 2017 at 11:35 PM, Cathy Zhang <Cathy.H.Zhang at huawei.com<mailto:Cathy.H.Zhang at huawei.com>> wrote:
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<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.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Regards,
Vikash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170321/31daca76/attachment.html>