Hi, To answer the questions from Juanma:
- When having different service chains for different pairs of origin IP – destination IP The assumption is that the different pairs of src/dest will not affect the chain behavior, if the classification is based on type of traffic. The tests performed included streaming UDP video and ICMP traffic via 2 chains, from one origin to one destination. In this case, the traffic classification was done in the SF, with chain starting points on the egress ports of classifier SF - one for the UDP and other for the ICMP traffic. - How one SF involved in several service chains would work This works with setting multiple chain rules on the SFF by netfloc, differentiated by the chainID. The case of the Slide 1 where the ingress/egress ports of a firewall SF overlap for all the 3 chains, has not been tested yet. - How do we ensure a SF will not settle its own MAC address. The implementation makes the assumption that the SF is L2 based and will not change the 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 rewriting (netfloc-sfc), I guess the MAC address settled by this SF is always rewritten but the SFF, right? The answer to this is similar as the previous question. The assumption is that the SF is making transparent L2 forwarding w/o modifying the address. The MAC address is settled by netfloc and for each SF's egress port. - 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? The SFF connected to the firewall will have the virtual MAC addresses set by netfloc, mapped according to chain ID for each chain. We have not however done testing using firewall SF, rather vTC (traffic classifier) with multiple egress ports, but if the mac is not altered within the SF, then the SF type should not affect. 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: Juan Manuel Fernandez <[email protected]> Gesendet: Dienstag, 20. Dezember 2016 16:58 An: Trajkovska Irena (traj); Joel Halpern; [email protected]; [email protected]; Eichelberger, Rafael (Brazil R&D-ECL); Brady Allen Johnson Betreff: 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]] On Behalf Of Trajkovska Irena (traj) Sent: sábado, 17 de diciembre de 2016 12:15 To: Joel Halpern <[email protected]>; [email protected]; [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 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
