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.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> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
