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]
*Cc:* Manohar SL <[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 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?
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 1^st
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
