Hello, Regarding the question how we assure that the SF will not overwrite the virtual MAC. MAC Chaining relies on L2 transparent SFs, in other words, SFs that do no change L2 addresses. We already tested on real SFs such as Snort, an open source IDS/IPS, and a linux machine with iptables only, to emulate a firewall, both cases MAC Chaining worked fine. For non-transparent SFs, we tested some proxy strategies with good results, however they are under research phases.
Question related to SFs on different chains. MAC Chaining does support SF on multiples chains. The virtual MAC have chain identification encoded, then the SFF match this chain ID (in the MAC address) and based on that, forward to the next SF. We expected that the same virtual MAC will be seen on the SFF when the packet return from SFs (L2 transparent SFs). Then, the chain ID is preserved throughout the chain. Note that we decrement virtual MAC address before send packets to SFs to indicate chain progress (e.g. service index for NSH). See the example bellow with OF rules for tow chains (MAC VA and MAC VB), note that SF1 is present in both chain. Chain 1 Match Action MAC VA 255 Set MAC VA 254, port=SF1 MAC VA 254 Set MAC VA 253, port=SF2 MAV VA 253 End of the chain Chain 2 Match Action MAC VB 255 Set MAC VB 254, port=SF1 MAC VB 254 Set MAC VB 253, port=SF3 MAV VB 253 End of the chain Regards, Rafael Eichelberger. From: Juan Manuel Fernandez [mailto:[email protected]] Sent: terça-feira, 20 de dezembro de 2016 13:58 To: Trajkovska Irena (traj) <[email protected]>; Joel Halpern <[email protected]>; [email protected]; Vacaro, Juliano (R&D Brazil) <[email protected]>; Eichelberger, Rafael (Brazil R&D-ECL) <[email protected]>; Brady Allen Johnson <[email protected]> Subject: RE: [sfc-dev] SFC project to contribute to the community Hi, Unfortunately I cannot say whether it is better having a new project for Netfloc or not, as far as I see, the SFC forwarding based on MACs is very similar in both solutions and for Netfloc there might be other collisions with other projects like Netvirt or Genius inside ODL when it comes to normal packet forwarding, but I think that should be something ODL Technical Steering Committee should judge. On the other hand, I still have some questions to both Irina, and Juliano and Rafael in relation to how both solutions will work in the following situations: - When having different service chains for different pairs of origin IP - destination IP - How one SF involved in several service chains would work - How do we ensure a SF will not settle its own MAC address. I have prepared a couple of slides which might be useful to understand the use cases: https://docs.google.com/presentation/d/1nuleObRbCXBkFD1Ifw5NJ226bmPmzyIH3_bXUG4u8Us/edit?usp=sharing So, let's imagine we have a transparent firewall which is the first SF in a chain: - for the case of MAC service chaining, how do we ensure this SF is not changing the virtual MAC address settled by the SFF? Most of the SFs will not understand anything about this MAC address and will overwrite it (the source address with its own MAC address and the destination address with the MAC address of the default gateway). How do we ensure any of these destination or source addresses is the virtual address identifying the MAC segment between two SFFs? Are you guys programming the answer of the ARP message to be the MAC address of this segment? Are you implementing the proxy forwarder defined in the draft? - For the case of MAC rewriting (netfloc-sfc), I guess the MAC address settled by this SF is always rewritten but the SFF, right? And now, when it comes to having this same firewall involved in more than one service chain: - For the case of MAC rewriting (netfloc-sfc), how does the SFF connected to the firewall know which is the MAC address to be settled, I guess different MAC addresses will have to be applied depending on the chain, right? Or are you assuming this firewall can only be in one Service Chain? - For the case of MAC service chaining, one option could be firewall is keeping the virtual MAC address, but that would mean, we need SFs understanding MAC service chaining. The other option could be having a proxy forwarder able to do a re-classification as described in the draft. Which is the option you have chosen in the existing implementation? Or are you guys assuming one SF can only be in one chain? Thanks and best regards, Juanma From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Trajkovska Irena (traj) Sent: sábado, 17 de diciembre de 2016 12:15 To: Joel Halpern <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Eichelberger, Rafael (Brazil R&D-ECL) <[email protected]<mailto:[email protected]>>; Brady Allen Johnson <[email protected]<mailto:[email protected]>> Subject: Re: [sfc-dev] SFC project to contribute to the community Hi Brady, all, after the discussion on the weekly meeting wrt. merging the two solutions (zhaw and hpe) in one, we held a call with Julian and Rafael yesterday to discuss if and how it can be achieved. We made with this comparative list of the key features and current status of the two projects: https://docs.google.com/document/d/1eNubeC3Jti52BT504x88Hqw3TuLvXkwu1DfZbtCHS0A/edit?usp=sharing As a general view, it looks like the mac chaining project fits inside the sfc-odl, offering alternative forwarding once the IETF parameters are mapped to OF rules. However the netfloc-sfc approach would most likely feet as a separate library (alternative to the ITEF), and the best way to test it would be importing it as a feature in ODL and adapt the proper features to make sfc work. I would go with this solution and submit a patch once the code is refactored, so we can get a feedback from the community and decide furthermore the best fit for this solution. What do you think? In my opinion there is not much difference in trying to merge netfloc with the mac chaining approach, than merging it with the native sfc-odl, since they are both based on the ITEF specification. 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 ________________________________ Von: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> im Auftrag von Joel Halpern <[email protected]<mailto:[email protected]>> Gesendet: Freitag, 16. Dezember 2016 20:20 An: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Betreff: Re: [sfc-dev] SFC project to contribute to the community I would also note that if the underlying packet being serviced is an IP packet, then there is no need to restore the original MAC address. Yours, Joel Sent from my Android phone using TouchDown (www.symantec.com<http://www.symantec.com>) -----Original Message----- From: Vacaro, Juliano (R&D Brazil) [[email protected]] Received: Friday, 16 Dec 2016, 12:52 To: Joel Halpern [[email protected]]; [email protected]<mailto:[email protected]> [[email protected]] Subject: RE: [sfc-dev] SFC project to contribute to the community 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]<mailto:[email protected]>>; [email protected]<mailto:[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]> [mailto:[email protected]] On Behalf Of Vacaro, Juliano (R&D Brazil) Sent: Friday, December 16, 2016 12:24 PM To: [email protected]<mailto:[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]<mailto:[email protected]>> To: "Eichelberger, Rafael (Brazil R&D-ECL)" <[email protected]<mailto:[email protected]>>, "Trajkovska Irena (traj)" <[email protected]<mailto:[email protected]>>, "Yang, Yi Y" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [sfc-dev] SFC project to contribute to the community Message-ID: <[email protected]<mailto:[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]<mailto:[email protected]>>; > Eichelberger, Rafael > (Brazil R&D-ECL) <[email protected]<mailto:[email protected]>>; Yang, > Yi Y > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[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]>> > <mailto:[email protected]> > *Gesendet:* Samstag, 10. Dezember 2016 18:26 > *An:* Yang, Yi Y; Trajkovska Irena (traj); > [email protected]<mailto:[email protected]> > <mailto:[email protected]> > *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]>> > <mailto:[email protected]>; > [email protected]<mailto:[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]> > <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]> > <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]<mailto:[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]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/sfc-dev
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
