Hi Brady, I'm afraid I did not read your last e-mail carefully, I think your last proposal is ok considering the SFP value prevails over the SF type one.
Best regards, Juanma -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Juan Manuel Fernandez Sent: domingo, 13 de noviembre de 2016 10:13 To: Brady Allen Johnson <[email protected]>; Tim Rozet <[email protected]> Cc: [email protected] Subject: Re: [sfc-dev] Deprecating SFC, SFP, and RSP symmetric fields Hi Brady, If we look at how the symmetry and the symmetric fields are described in both Service Function type and SFP respectively in current YANG model, we can see the following: Service Function Type: leaf symmetry { type boolean; description "SF is involved in a symmetric service path"; } Service Chain Path: leaf symmetric { type boolean; default false; description "If the chain is symmetric we will create two service paths, one ingress and another egress. Packets traverse the egress service path in the reverse order of the ingress path"; } I don't mind we want to call the name of the symmetry field in Service Function Type, but in my opinion, what it is not right is that a Service Function Type with symmetry field equals to true is involved in a symmetric Service Chain Path, but that it needs to receive packets in the reverse direction. Yi Yang already showed that very well in his e-mail: > SF1 ----------- SF2-----------------SF3 > > (False) (True) (False) > > > > For such RSP, reverse RSP must include this SF2 > > > > SF4------------SF2-------------------SF5 > > (False) (True) (False) Taking into account current's YANG model and the understanding I have from your proposal Brady, if Service Function Type has symmetry (stateful) field set to TRUE, that would mean the following: > SF1 ----------- SF2-----------------SF3 > > (False) (True) (False) > > > > For such RSP, reverse RSP must be associated to a symmetric SFP > > > > SF3------------SF2-------------------SF1 > > (False) (True) (False) Even that would be the normal situation, why do we have to force that? Why a "symmetric" (or stateful) SF must mandate having a symmetric chain. I understand it needs a reverse RSP, but why it must traverse the exact same SFs? This is what I would not limit Best regards, Juanma -----Original Message----- From: Brady Allen Johnson Sent: viernes, 11 de noviembre de 2016 17:00 To: Tim Rozet <[email protected]>; Juan Manuel Fernandez <[email protected]> Cc: [email protected] Subject: Re: [sfc-dev] Deprecating SFC, SFP, and RSP symmetric fields Again, the main motivation for SFC determining internally if a service chain is symmetric is to simplify the configuration for the operators. I think its best for SF providers to state if their device needs symmetric traffic or not, and SFC can use that info internally, without the operator having to know too much about the internals of the SFs. If we call the SF attribute "symmetry" or "stateful", well that's splitting hairs. But a stateful SF doesnt always mean it needs both uplink and downlink traffic. I think calling the attribute symmetry is more explicit, as it states our intention to create a symmetric service chain. That is, it needs both uplink and downlink packets, ie symmetric packets. I think the best solution would be to leave the symmetric field on the SFP, and to deprecate it (remove it next release) on the SFC and RSP. The SF-type symmetric field would still be used to determine chain symmetry, but the SFP symmetric flag could optionally be specified, and would override the SF-type symmetric fields. Regards, Brady On 11/11/16 16:36, Tim Rozet wrote: > Right. Thanks for correcting me Yi. I also agree a stateful attribute on > the SF and symmetrical attribute on the SFC is the best solution. > > Tim Rozet > Red Hat SDN Team > > ----- Original Message ----- > From: "Juan Manuel Fernandez" <[email protected]> > To: "Yi Y Yang" <[email protected]> > Cc: "Tim Rozet" <[email protected]>, [email protected] > Sent: Friday, November 11, 2016 2:11:08 AM > Subject: Re: [sfc-dev] Deprecating SFC, SFP, and RSP symmetric fields > > Hi, > > Just to be clear, I would not deprecate the symmetric attribute in SFC and > SFP and would chante symmetric attribute in SF to stateful. > > Best regards > > El nov. 11, 2016 8:06 AM, Juan Manuel Fernandez > <[email protected]> escribió: > > hi, > > I fully agree with Yi Yang. As far as I see we are mixing concepts. > > Service Chains can be unidirectional or bidirectional and can also be > symmetric or asymmetric. > > On the other hand SFs can be stateless or stateful and can be transparent or > not transparent (e.g. of non transparent an HTTP proxy). > > As far as I understand from previous emails, what some of you is saying is > that having a stateful SF (some of you call it symmetric) implies having a > symmetric chain and in line with Yi Yang, I would say this is not right. A > stateful chain implies this SF will have a reverse path, but not that the > complete chain must be symmetric. I mean, the SF does not need the packet to > traverse through the same SFs in both chain directions, but to get both the > reply and the answer and in some cases even all the flows related to the same > subscriber. > > I agree with Yi Yang and Tim when saying it would be good having a stateful > property in the SF to ensure there is a reverse path traversing this SF, but > not to ensure there is a symmetric chain, SFP or RSP. > > Best regards, > > Juanma > > El nov. 11, 2016 2:00 AM, "Yang, Yi Y" > <[email protected]<http://intel.com>> escribió: > > I think you’re confusing the symmetry a stateful SF requires and symmetric > chain. We can still create symmetric chains even if every SF in these chains > is stateless. So I think Tim’s proposal is ok, you can mark a SF stateful by > other property such as “stateful”, using “symmetric” here will make people > confused. You can let SFC consider this when your chain includes such a > stateful SF and create RSP. Let me make an example. > > > > SF1 ------------à SF2-----------------àSF3 > > (stateless) (stateful) (stateless) > > > > For such RSP, reverse RSP must include this SF2 because it is stateful. > > > > SF4------------àSF2-------------------àSF5 > > (stateless) (stateful) (stateless) > > > > > > You can refer to https://tools.ietf.org/html/rfc7665 and extend it if > it didn’t consider your use case J > > > > From: Brady Allen Johnson > [mailto:[email protected]<http://ericsson.com>] > Sent: Thursday, November 10, 2016 8:47 PM > To: Swati Deshpande <[email protected]<http://serro.com>>; > Yang, Yi Y <[email protected]<http://intel.com>> > Cc: Diego Jesus Granados Lopez > <[email protected]<http://ericsson.com>>; > [email protected]<http://lists.opendaylight.org>; Tim > Rozet <[email protected]<http://redhat.com>> > Subject: Re: [sfc-dev] Deprecating SFC, SFP, and RSP symmetric fields > > > > I agree. > > You have to ask the question: > > Why would a Service Chain be symmetric? > > Answer: > > Because one or several Service Functions in that chain need both uplink > and downlink packets. > > > > So, as Swati mentioned, instead of putting the burden on the Operator to know > about the Service Functions, configure the symmetric property on the Service > Function, and let SFC create the reverse/symmetric Service Chain internally > when needed. > > This change simplifies the SFC configuration. > > Regards, > > Brady > > > > On 10/11/16 13:34, Swati Deshpande wrote: > > > > As an Abstract object , SF can be in symmetric SFC or asymmetric SFC. > > If we think of use cases, there is one category of SFs, that can function > only when set up in symmetric SFC, and second category of SF that can > function in both symmetric as well as asymmetric SFC. > > So the real question is "Do we put onus on operator to know about > category of SFs being deployed and set up SFC accordingly? Or > > do we derive symmetric nature of SFC based on category of SF being deployed > in the chain. > > If we want to make life easy for operators and also give them control, by > default symmetric nature of SFC can be derived from SF category and > additional control can be added on SFC to override the default behavior. > > > > > > Regards, > > Swati > > > > On Thu, Nov 10, 2016 at 5:28 PM, Yang, Yi Y > <[email protected]<mailto:[email protected]>> wrote: > > 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]<mailto:[email protected]>] > Sent: Thursday, November 10, 2016 7:45 PM > To: Diego Jesus Granados Lopez > <[email protected]<mailto:diego.jesus.granados.l > [email protected]>> > Cc: Yang, Yi Y <[email protected]<mailto:[email protected]>>; > Brady Allen Johnson > <[email protected]<mailto:brady.allen.johnson@ericsson. > com>>; > [email protected]<mailto:[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] > endaylight.org> > [mailto:[email protected]<mailto:sfc-dev-bounces@ > lists.opendaylight.org>] On Behalf Of Yang, Yi Y > Sent: jueves, 10 de noviembre de 2016 12:06 > To: Brady Allen Johnson > <[email protected]<mailto:brady.allen.johnson@ericsson. > com>>; > [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] > endaylight.org> > [mailto:[email protected]<mailto:sfc-dev-bounces@ > lists.opendaylight.org>] 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 _______________________________________________ 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
