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:[email protected]>>
*Cc:* Yang, Yi Y <[email protected]
<mailto:[email protected]>>; Brady Allen Johnson
<[email protected]
<mailto:[email protected]>>;
[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]>
[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
<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
<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
<https://lists.opendaylight.org/mailman/listinfo/sfc-dev>
_______________________________________________
sfc-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
