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 :) 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]><mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: Manohar SL <[email protected]><mailto:[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]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/netvirt-dev
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
