Hi sam,
For point #2, if sfc strips off the NSH header, the pkt can go directly
to l3 service, then netvirt-acl can be a single higher priority service,
positioned in genius before sfc. If we need it to handle an nsh pkt
after sfc, we need to explicitly create an sfc-egress sub-service, lower
priority than sfc to do this task. so, while it is not uniform behavior,
it might not be worth it.
Thanks,
daya
*From:*Sam Hague [mailto:[email protected]]
*Sent:* Friday, November 18, 2016 9:04 PM
*To:* Dayavanti Gopal Kamath <[email protected]>
*Cc:* sfc-dev opendaylight <[email protected]>;
[email protected]; Brady Allen Johnson
<[email protected]>; Manohar SL
<[email protected]>; [email protected]
*Subject:* Re: [netvirt-dev] netvirt-SFC integration unconference ideas
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]
<mailto:[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]
<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
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
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
_______________________________________________
netvirt-dev mailing list
[email protected]
<mailto:[email protected]>
https://lists.opendaylight.org/mailman/listinfo/netvirt-dev
_______________________________________________
netvirt-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/netvirt-dev
