But a SF can be in symmetric chain, it also can be in asymmetric chain, symmetric or asymmetric is for chain or path, not for SF. It is really weird a bit if you say a SF is symmetric or asymmetric.
From: Swati Deshpande [mailto:[email protected]] Sent: Thursday, November 10, 2016 7:45 PM To: Diego Jesus Granados Lopez <[email protected]> Cc: Yang, Yi Y <[email protected]>; Brady Allen Johnson <[email protected]>; [email protected] Subject: Re: [sfc-dev] Deprecating SFC, SFP, and RSP symmetric fields 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]<mailto:[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]> [mailto:[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]<mailto:[email protected]>>; [email protected]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Brady Allen Johnson Sent: Thursday, November 10, 2016 6:42 PM To: [email protected]<mailto:[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]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/sfc-dev _______________________________________________ sfc-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/sfc-dev _______________________________________________ sfc-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/sfc-dev
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
