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. 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. 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. 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. SFC service integration with GENIUS will be needed, and SFC should bind service on all ports where SFs are connected to SFF. 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. 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. Thanks, daya
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
