Couple comments : 1. The vxlan gpe tunnels. Today I don't think netvirt adds any of those. Sfc builds up everything on the sfc overlay. I think it just happened that the ingress nodes were also sff's so it worked out. Looks look we need to coordinate now.
2. The egress from sfc. As Brady mentioned we needed the NSH header to remain so that we would not classify again. I think with genius the Metadata would do the same so sfc could strip the NSH if wanted. Or let netvirt continue, netvirt adds it so it can remove it. On Nov 18, 2016 7:10 AM, "Dayavanti Gopal Kamath" < [email protected]> wrote: > Ok, sounds good brady. > > So, next thing is to write up a doc for this feature in the new netvirt > doc format. Since anil is on vacation, I will volunteer him to do it once > he is back J unless someone else volunteers to take it up now. I think > anil is on vacation for a couple of weeks. > > > > Thanks, > > daya > > > > *From:* Brady Allen Johnson > *Sent:* Friday, November 18, 2016 5:22 PM > *To:* Dayavanti Gopal Kamath <[email protected]>; > [email protected]; [email protected]; > [email protected] > *Cc:* Manohar SL <[email protected]> > *Subject:* Re: [netvirt-dev] netvirt-SFC integration unconference ideas > > > > Daya, > > Thanks for the replies. > > There is only one outstanding question from below, that I'll answer here > regarding who/where the NSH gets removed. > > The IETF spec explicitly states that the last SFF should remove the SFC > encapsulation (NSH) when the packet is received from the last SF. Then, in > another section the spec mentions that any SFC domain boundary node can > remove it. So there's a bit of ambiguity there that I have already brought > up with the IETF SFC authors. > > Either way, we can remove the NSH header in the SFF. I think the only > reason its not that way today is because the Netvirt folks asked us to > leave it on. In the old solution, if we remove it and send it back to the > bridge, it will get classified again and create a loop. > > *Long story made short:* Yes, we can remove NSH when integrating with > Genius :) > > Regards, > > Brady > > > > On 18/11/16 12:43, Dayavanti Gopal Kamath wrote: > > Hi brady, > > Please see inline. > > > > Thanks, > > daya > > > > *From:* Brady Allen Johnson > *Sent:* Friday, November 18, 2016 2:33 PM > *To:* Dayavanti Gopal Kamath <[email protected]> > <[email protected]>; [email protected]; > [email protected]; [email protected] > *Cc:* Manohar SL <[email protected]> <[email protected]> > *Subject:* Re: [netvirt-dev] netvirt-SFC integration unconference ideas > > > > > > Comments below inline. > > Brady > > > > On 18/11/16 09:28, Dayavanti Gopal Kamath wrote: > > All, > > We had an ODL India summit here yesterday, and picked up an unconference > session on ideas on how the new netvirt service would work with SFC. Here’s > the notes, > > (disclaimer – we have not focused in the past on any such integration > discussions for the new netvirt, so please do update if any of this has > been worked out, and doesn’t align)- > > > > Existing implementation – > > Old netvirt implements the classifier, it uses augmented ACL.yang for the > same > > It receives RSP and other information from the SFC service > > In the pipeline, the classifier will create an NSH header, and punt pkt to > the SFC pipeline > > When SFC is done with it, some egress ‘classification’ is done to figure > this out, and pkt goes back into netvirt pipeline. > > This part isnt completely accurate. Its very easy for SFC to know when its > done with the packet. When the NSH header index field has the value of the > last hop, then SFC is done with the packet. Upon completion, the packet is > sent back to the Netvirt tables. The table to send it to is the SFC > configurable value: table egress. The egress classification is performed by > netvirt, and includes removing NSH and sending the packet on to its final > destination. > > daya->yes, the egress classifier today strips off the nsh header and sends > pkt to the output port. In the new approach, send to output port will be > done automatically if sfc resubmits the pkt back to the pipeline. Can > removal of nsh header be done in the last SFF upon receiving the pkt from > the SF? Then we do not need to create a separate egress classifier service > to just do this part. > > > > New proposal is substantially the same- > > New Netvirt continues to implement the classifier and use augmented > ACL.yang for the same. > > The current ACL service for security groups, is listening on a different > augmentation of ACL.yang as compared to the service chained augmented > acl.yang, but the only differences between the 2 are the actions, so it > could be added into the current Netvirt ACL service. When it gets > notifications from the service chaining augmentation for acl.yang, it can > continue to trigger the workflow for sfc integration as follows- > > ACL service continues to handshake with SFC to get an RSP ID for the > classifier. > > This handshake should happen before-hand so that the OpenFlow tables are > configured appropriately when the packets arrive. That is, it shouldnt > happen upon receiving the packets. > > > daya->yes, no changes here. > > > > > In the unconference, we explored whether stamping of the NSH header can be > done by SFC service on the ingress box, instead of by the ACL service, and > ACL service just passes the RSP handle to SFC service in metadata. but, > based on my discussion with vinayak today, it looks like the expectation is > for the classifier to put the NSH header, in the IETF draft, also more > importantly, SFC service may not even be instantiated on a node without an > SFF. > > That's right, its the role of the classifier to add the SFC encapsulation, > which is NSH in this case. > > > > So, to support this, we will have to continue with the same methodology, > where the ACL service will stamp the NSH header, convert the SFF IP to an > OF port (in the control plane), and do an output_port action to send the > pkt to the 1st SFF. If the 1st SFF is co-located, the of_port is a local > port, and if it is remote, the of_port has to map to a vxlan-gpe tunnel > interface. > > On the egress, SFC on the last SFF can just re-submit the pkt back to the > Genius dispatcher table, no further classification is needed, the pkt will > get forwarded by L2/L3 services automatically. > > One important thing to mention here is: Who will remove the NSH > encapsulation? > > > daya-> proposal above, for sfc to do it, other than purity of operation > and alignment with ietf, does this violate any usecases? i.e whether sfc or > egress netvirt does it, it will all happen on the same sff always, so can > it be subsumed in the sfc service? > > > > SFC service integration with GENIUS will be needed, and SFC should bind > service on all ports where SFs are connected to SFF. > > We are already working on this. We should also bind on ports where we > could expect SFF - SFF packets and interactions with the classifier if its > on a separate bridge, right? That is, compute node to compute node. > > daya->yes, every sff port basically. > > > > We decided the Netvirt ACL service classifier is expected to be scoped by > tenant, as such it will need to be applied on every endpoint belonging to > every vm of the tenant. > > We should also allow for packets arriving externally. That is, they dont > all have to come from local VMs. > > daya->this would need some interlock between vpn service and netvirt-acl, > such that acl service informs vpn service that it needs to classify pkts > arriving on a certain vrf, and such pkts are sent to the acl pipeline based > on vrf id. > > As an optimization - GENIUS can provide a more flexible bind service API > for such conditions, where an application can bind once on some wildcarded > entitiy, like network, or subnet and GENIUS will create default flow > entries on all relevant switches to insert the service into the pipeline > appropriately. > > > > Open question – who creates the vxlan-gpe tunnels on the ingress switch. > In case the SFF is remote, and SFC service is not running on such a switch, > would it be responsibility of the Netvirt-ACL service to fire off the > creation of a VXLAN-GPE tunnel to the 1st SFF. > > Yes, I think netvirt should indeed do this. > > > > > Thanks, > > daya > > > > > > > > _______________________________________________ > > netvirt-dev mailing list > > [email protected] > > https://lists.opendaylight.org/mailman/listinfo/netvirt-dev > > > > > > _______________________________________________ > netvirt-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/netvirt-dev > >
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
