Hello all,
This email is to explain how the topic presented in this email [0] has
been implemented in this patch [1].
Previously there was a symmetric boolean flag in the SFC, SFP, and RSP
RPC data models. Only the SFP symmetric flag was being used to create
symmetric service chains. In the patch I deprecated the symmetric flag
in the SFC and RSP RPC data models, and left the SFP symmetric flag as
it was before. Additionally, I added changes to start using the Service
Function SF-type bidirectional flag (I changed the name from
bidirectionality to bidirectional).
In this email thread [0] I originally mentioned we would use the SF-type
symmetry flag, but based on discussions, we decided it was better to
instead use the SF-type bidirectional flag.
Now there are 2 different ways as follows to make an RSP (Rendered
Service Path) symmetric. A symmetric RSP means that when an RSP is
created, an additional symmetric, reverse RSP will also be created since
RSPs are directional. This is basically for the case when you want an
upstream and a matching downstream RSP.
* If any Service Function is of a SF-type that has the bidirectional
field set true, then the resulting RSP will be symmetric
* The SFP symmetric flag, if present, will /*override*/ the SF-type
bidirectional fields.
o If the SFP symmetric flag is present and is true, then a
symmetric RSP will be created independently of how the SF-type
fields are set.
o If the SFP symmetric flag is present and is false, then a
symmetric RSP will not be created.
The motivation behind using the SF-type bidirectional flag is to allow
for flexibility when creating RSPs. With this change, an operator doesnt
need to know details about the SFs in the service chain. The SF
providers set the SF-type configuration accordingly, and internally SFC
will automatically determine if the resulting RSP needs to be symmetric
or not.
Regards,
Brady
[0]
https://lists.opendaylight.org/pipermail/sfc-dev/2016-November/003599.html
[1] https://git.opendaylight.org/gerrit/#/c/49546/
_______________________________________________
sfc-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
