Juliano, Not sure if this will help... but the trick we used when GBP was using SFC and needed to recover info to handle the packet after it exited the chain was to put that information into the NSH metadata.
It turns out, in my experience at least, once you scratch the surface on SFC.. you discover you *really* need metadata to function reasonably. YMMV :) Ed On Fri, Dec 16, 2016 at 10:52 AM, Vacaro, Juliano (R&D Brazil) < [email protected]> wrote: > Hi Joel, > > About your first question, the answer would be no. Chains that use MAC > Chaining strategy can be shared with any number of subscribers. That's > because each chain is identified based on a chaind id (similar to NSP) > which is added into the MAC address of the packets, and that is done in the > classification phase. From this point on, only such ids are used to perform > the packet forwarding. This is very similar to NSH, but here we store the > NSP and NSI into the MAC address, not into NSH header. > > We are evaluating different strategies to restore the original destination > MAC address at the end of the chain. I know that OpenStack may use DVR > (Distributed Virtual Routing), and that could be an interesting service for > MAC Chaining. However, when ODL/netvirt is used, I suspect that ODL takes > care of this service too. If that is the case, we could leverage the same > component since it is already present in the target environment. > > Thanks, > Juliano > > -----Original Message----- > From: Joel Halpern [mailto:[email protected]] > Sent: sexta-feira, 16 de dezembro de 2016 15:28 > To: Vacaro, Juliano (R&D Brazil) <[email protected]>; > [email protected] > Subject: RE: [sfc-dev] SFC project to contribute to the community > > I may be missing something, but it seems that to have the exist gateway > restore the original MAC address, when one has not metadata in the packet > (use of mac chaining without NSH), one has to make one of two assumptions: > 1) That each source MAC uses a separate MAC chain. I hope not. > 2) That the inner header information can be used to determine the original > MAC address. This seems to imply both significant egress state and > specific topological and address usage by the packet originators. > > Yours, > Joel > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Vacaro, Juliano (R&D > Brazil) > Sent: Friday, December 16, 2016 12:24 PM > To: [email protected] > Subject: Re: [sfc-dev] SFC project to contribute to the community > > Hi Brady, > > We'll investigate the OPNFV recommended environment. So far we've been > targeting an OpenStack setup like this: > > Openstack: > tacker -> networking-sfc -> networking-odl > ODL: > neutron north bound -> netvirt -> sfc -> openflow renderer -> mac > chaining processor > > We want to understand better how netvirt deals with L3 routing, and > perhaps leverage the same infrastructure to restore the original > destination MAC address at the end of the MAC chain. In this setup, one > possibility would be the sfc translator component in netvirt configure this > last step in the SFC model for MAC chaining. > > Thanks, > Juliano > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 16 Dec 2016 09:31:40 +0100 > From: Brady Allen Johnson <[email protected]> > To: "Eichelberger, Rafael (Brazil R&D-ECL)" <[email protected]>, > "Trajkovska Irena (traj)" <[email protected]>, "Yang, Yi Y" > <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [sfc-dev] SFC project to contribute to the community > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Rafael, > > > How would that work in an OpenStack environment? Im thinking of OPNFV SFC, > which is the ideal testing environment for ODL SFC. > > > Regards, > > > Brady > > > On 16/12/16 01:08, Eichelberger, Rafael (Brazil R&D-ECL) wrote: > > > > Hi Brady, > > > > Regarding our discussion of Mac Chaining technique and how the > > original MAC address could be recovery at the end of the chain. > > > > We agreed that a L3 router or gateway could do this job. So, I am > > wondering how could we put this gateway configuration on the SFC model. > > > > It?s clear to me that a gateway would NOT be part of the chain itself. > > So I am think we could create a DPL augmentation to configure the > > gateway on the topology. Therefore, on the switch that the gateway is > > connected, we can configure a dpl augmented to be gateway connection, > > and then set its parameters, such as IP address. In other words, it > > would be a DPL for the chain termination point. > > > > Is that make sense? Do you have any alternative approaches?? > > > > Thanks, > > > > Rafael Eichelberger. > > > > *From:*Brady Allen Johnson [mailto:[email protected]] > > *Sent:* segunda-feira, 12 de dezembro de 2016 08:29 > > *To:* Trajkovska Irena (traj) <[email protected]>; Eichelberger, Rafael > > (Brazil R&D-ECL) <[email protected]>; Yang, Yi Y > > <[email protected]>; [email protected] > > *Subject:* Re: [sfc-dev] SFC project to contribute to the community > > > > Irena/Rafael, > > > > I have looked at both of your ideas, and they seem quite similar. I > > think it would be worthwhile for the 2 of you to consider joining > > forces to submit a common MAC-based service chaining solution to ODL SFC. > > > > I have already replied to Irena when she contacted me in private, and > > think her Netfloc solution is similar to the ODL Genius project, thus > > I suggested she also contact the Genius project about adding what may > > be needed there. > > > > Regards, > > > > Brady > > > > On 12/12/16 10:26, Trajkovska Irena (traj) wrote: > > > > Thanks for getting back, i will submit a patch as suggested.? > > > > You can check out section 5.3 in [1] for the source code > > implementation and [2] > > > > for the sfc solution. Also some progress work related to Netfloc > > and the sfc in [3]. > > > > [1] > > > > http://cordis.europa.eu/docs/projects/cnect/0/619520/080/deliverables/ > > 001-TNOVAD431SDKforSDNInterimv10Ares20162347437.pdf > > > > [2] > > https://www.ch-open.ch/fileadmin/OCD_2016/1_Irena_Trajkovska.pdf > > > > [3] https://blog.zhaw.ch/icclab/tag/netfloc/? > > > > -------------------------------------------- > > > > Irena Trajkovska > > > > Researcher, InIT Cloud Computing Lab > > Zurich University of Applied Sciences (ZHAW) > > > > [Research Lab] blog.zhaw.ch/icclab <http://blog.zhaw.ch/icclab> > > > > Phone: +41(0)589344742 > > > > > > ---------------------------------------------------------------------- > > -- > > > > *Von:*Eichelberger, Rafael (Brazil R&D-ECL) > > <[email protected]> <mailto:[email protected]> > > *Gesendet:* Samstag, 10. Dezember 2016 18:26 > > *An:* Yang, Yi Y; Trajkovska Irena (traj); > > [email protected] <mailto:sfc-dev@lists. > opendaylight.org> > > *Betreff:* RE: SFC project to contribute to the community > > > > I was the one from HPE. We are finishing an implementation of MAC > > Chaining under ODL, and we are planning to publish a gerrit on > > ODL SFC project shortly. > > > > for further details see > > https://datatracker.ietf.org/doc/draft-fedyk-sfc-mac-chain/ > > > > Regards. > > > > Rafael Eichelberger > > > > *From:*[email protected] > > <mailto:[email protected]> > > [mailto:[email protected]] *On Behalf Of > > *Yang, Yi Y > > *Sent:* s?bado, 10 de dezembro de 2016 06:12 > > *To:* Trajkovska Irena (traj) <[email protected]> > > <mailto:[email protected]>; [email protected] > > <mailto:[email protected]> > > *Subject:* Re: [sfc-dev] SFC project to contribute to the > > community > > > > I remember a guy from HPE mentioned they implemented service > > function chaining by using mac, when ODL SFC can support different > > data plane therefore different service function chaining > > implementation, Now it can implement service function chaining by > > MPLS label, VLAN tag and NSH, so the framework can support new > > implementation without any issue, please submit your patch to > > Opendaylight gerrit, ODL SFC is very open for anything new J > > > > Do you have any document about your implementation? I?m just very > > curious how you can implement cross-datacenter service function > > chaining by rewriting MAC. > > > > *From:*[email protected] > > <mailto:[email protected]> > > [mailto:[email protected]] *On Behalf Of > > *Trajkovska Irena (traj) > > *Sent:* Friday, December 9, 2016 9:07 PM > > *To:* [email protected] > > <mailto:[email protected]> > > *Subject:* [sfc-dev] SFC project to contribute to the community > > > > Hi all, > > > > after contacting few of this community and writing to the irc, i > > am writing here. > > > > The objective is to contribute a sfc project to the community. > > > > I am involved with SDN topics at the ICCLab in Switzerland and for > > two years > > > > we've been working on SDK for SDN (Netfloc) based on OpenDaylight. > > > > Shortly, Netfloc is an archetype of ODL using ovsdb, openflow > > plugin, > > > > neutron-northbound and md-sal. > > > > The SFC project is OpenFlow based, uses standard OVS (not NSH > > enabled and > > > > Yang models for the service definition. > > > > The implementation is based on abstract mac rewriting pattern and > > it is bound to > > > > Netfloc that uses shortest path algorithm for the virtual network > > topology. > > > > On the management side, it has gui interface and integrates with > > NFV orchestrator > > > > (via ETSI NSD and VNFGD) and OpenStack Heat. > > > > The sfc project completed a full cycle of development in the past > > year and has been > > > > validated in PoC cloud-NVI scenario using VNFs as virtual traffic > > classifier and video transcoding VNF > > > > ..now we are deploying multi-dc demo (chaining is only intra-DC). > > > > As the sfc is alternative to the odl-sfc project, i would like to > > know if the best approach is to submit it as > > > > a standalone solution, or it rather fits closer to the sfc-odl. I > > also looked into the opnfv-sfc community that > > > > happens to be aligned to the odl, so i am looking to find the best > > fit for this work. > > > > Few links of interest: [blog.zhaw.ch/icclab, > > https://github.com/icclab/netfloc] > > > > BR, > > > > Irena > > > > -------------------------------------------- > > > > Irena Trajkovska > > > > Researcher, InIT Cloud Computing Lab > > Zurich University of Applied Sciences (ZHAW) > > > > [Research Lab] blog.zhaw.ch/icclab <http://blog.zhaw.ch/icclab> > > > > Phone: +41(0)589344742 > > > > > > > > > > _______________________________________________ > > > > sfc-dev mailing list > > > > [email protected] > > <mailto:[email protected]> > > > > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.opendaylight.org/pipermail/sfc-dev/ > attachments/20161216/ae9f4e21/attachment.html> > > ------------------------------ > > _______________________________________________ > sfc-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > > > End of sfc-dev Digest, Vol 32, Issue 22 > *************************************** > _______________________________________________ > sfc-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > _______________________________________________ > sfc-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/sfc-dev >
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
