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.zh...@huawei.com] Sent: Monday, March 20, 2017 6:05 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 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] 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
