[openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation
Vikash Kumar
Vikash.Kumar at oneconvergence.com
Tue Mar 21 18:29:17 UTC 2017
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.kumar at oneconvergence.com>
wrote:
Hi Igor,
On Tue, Mar 21, 2017 at 10:02 PM, Duarte Cardoso, Igor <
igor.duarte.cardoso at 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.
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.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>
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/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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Regards,
Vikash
__________________________________________________________________________
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/58f1742e/attachment.html>
More information about the OpenStack-dev
mailing list