Agree with Diego, Symmetric nature of SFC should be determined based on type of SF used in the chain. SF types dpi, firewall , NAT, need to see both forward and reverse flows hence SFC built using such SFs would need to be symmetric. If any one SF in a SFC has symmetric path requirement, RSP should be symmetric.
Regards, Swati On Thu, Nov 10, 2016 at 4:59 PM, Diego Jesus Granados Lopez < [email protected]> wrote: > Hi, > > Not really following your point on this. I think the contrary: SF having a > symmetric flag makes all the sense, but it would be desirable that SFP > don't have it. E.g. think of the header enrichment service function type: > it would be great if any HE vendor could specify whether his HE SF is > symmetric or not (e.g. Ericsson sells the "Ericsson HE"; it is a > transparent HE SF that don't need symmetry, hence it is a not-symmetric > SF"; another vendor sells the "OtherVendor HE", that is a proxy, and > defines its SF as symmetric). From the SFC operator standpoint, he simply > choses a HE SF among all the vendors building SFs belonging to the header > enrichment type and defines the path, and it is SFC what determines whether > the symmetric RSP is needed or not depending on the SFs part of it. This > way, we simplify operation (i.e. the operator choses a HE based on business > needs, but never needs to think about symmetry) and prevent configuration > mistakes (e.g. the operator configuring a SFP > as not symmetric but including a SF which needed the symmetric path). I > could think of the same reasoning being applicable for other SF types: > dpi... > > Best regards, > Diego > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Yang, Yi Y > Sent: jueves, 10 de noviembre de 2016 12:06 > To: Brady Allen Johnson <[email protected]>; > [email protected] > Subject: Re: [sfc-dev] Deprecating SFC, SFP, and RSP symmetric fields > > I think SFP can keep it, others can remove it, it doesn't make sense for a > SF to have a symmetric flag. > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Brady Allen Johnson > Sent: Thursday, November 10, 2016 6:42 PM > To: [email protected] > Subject: [sfc-dev] Deprecating SFC, SFP, and RSP symmetric fields > > > Currently there is a symmetric field in the SFC, SFP, and RSP data models. > I will deprecate these fields now in Carbon. > > Instead of defining this in one of [SFC, SFP, RSP] a chain will be > symmetric if it has an SF whose SF-type has the symmetry flag set to true. > The SF-type symmetry field was also added in Beryllium. > > It was always confusing what it meant if there is some combination of > symmetric values for the SFC, SFP, and RSP. That is, what if SFC:symmetric > is true, SFP:symmetric is false, and RSP:symmetric is true? Or some similar > combination? > > Currently, a reverse RSP is created if the SFP symmetric field is true. > This will still be the case in Carbon, but we will also check the SF-types > as explained above. In Nitrogen, we'll remove the SFP symmetric field check. > > I've already updated the SFC Carbon Release Plan to mention these > deprecated fields. > > Regards, > > Brady > > > _______________________________________________ > sfc-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > _______________________________________________ > sfc-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/sfc-dev > _______________________________________________ > sfc-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/sfc-dev >
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
