Open Stack

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>
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]
> *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/201
> 7/service_chaining.2017-03-16-17.02.html
>
> [2] https://review.openstack.org/#/c/442195/
>
> [3] https://github.com/openstack/networking-sfc/blob/17c537b35d4
> 1a3e1fd80da790ae668e52cea6b88/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://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/207bbb06/attachment.html>