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.
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.
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 1^st SFF. If the 1^st 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?
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.
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.
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 1^st 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
_______________________________________________
sfc-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
