Below, Best regards, Igor.
From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com] Sent: Tuesday, March 21, 2017 6:29 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>; Duarte Cardoso, Igor <igor.duarte.card...@intel.com> Subject: Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation Also, for TAP devices, they can be deployed in both active ( forward traffic back to networking devices) and passive mode . Our *current BP* scope is only for passive TAP. Apart from these two, there are other mode of deployment s also. Others reading can add. On Tue, Mar 21, 2017, 11:16 PM Vikash Kumar <vikash.ku...@oneconvergence.com<mailto:vikash.ku...@oneconvergence.com>> wrote: Hi Igor, On Tue, Mar 21, 2017 at 10:02 PM, Duarte Cardoso, Igor <igor.duarte.card...@intel.com<mailto:igor.duarte.card...@intel.com>> wrote: 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. which means it can co-exist with (L2/L3 insertion mode) and not necessarily mutually exclusive. [IDC] It can’t because it shouldn’t be captured in the API. When you create a port-chain you have to specify the encap protocol that will render it as a whole, let’s say NSH. Then you go to the port-pairs and specify whether they support that protocol or whether they have to be proxied in an L2 or an L3 way (and these three possibilities are mutually exclusive). If the port-pair supports NSH, you don’t specify anything about L2 or L3 insertion modes. The logical SFFs (physically OVS e.g.) will be configured with the flows that will be able to forward traffic to the right service function – those flows can look like an L2 if the port-pair is on the current node and we just need to push NSH on Ethernet, or maybe they will look like an L4 insertion mode, if we have to cross nodes using VXLAN – but this will be backend/deployment/environment specific, and that’s what I mean by “L2/L3 then become something that the SFF might have to deal with it”. It’s not something to capture in the API. 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. Agree. 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. I was referring to NSH in totality and not excluding SFF (https://tools.ietf.org/html/draft-ietf-sfc-nsh-12). Look like I extended the scope of NSH in term of SFC. 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.ku...@oneconvergence.com<mailto:vikash.ku...@oneconvergence.com>] Sent: Tuesday, March 21, 2017 3:32 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org<mailto:openstack-dev@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.zh...@huawei.com<mailto:cathy.h.zh...@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.card...@intel.com<mailto:igor.duarte.card...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Vikash __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Vikash
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
