Hi Igor,
On Tue, Mar 21, 2017 at 10:02 PM, Duarte Cardoso, Igor < [email protected]> 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:[email protected]] > *Sent:* Tuesday, March 21, 2017 3:32 PM > *To:* OpenStack Development Mailing List (not for usage questions) < > [email protected]> > *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 <[email protected]> > 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:[email protected]] > *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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > > Regards, > > Vikash > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Regards, Vikash
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
