Hi,
I think revisiting the RFC may be of help here. The standard describes 3
types of SFCs:
1) Uni-directional
2) Bi-directional
3) Hybrid
Type 1 SFCs consist of a single *network* path packets are steered
through, type 2 SFCs consist of two *network* paths each of them being a
reversed copy of the other, including endpoints; finally type 3 SFCs
consist of two *network* paths where one of them is a reversed copy of a
strict sub-set of the other, including the endpoints. Check the
following examples showing the *network* paths associated to each SFC type:
Uni-directional: { EPa -> SF1 -> SF2 -> SF3 -> EPb }
Bi-directional: { EPa -> SF1 -> SF2 -> SF3 -> EPb, EPb -> SF3 -> SF2 ->
SF1 -> EPa }
Hybrid: { EPa -> SF1 -> SF2 -> SF3 -> EPb, EPb -> SF3 -> SF1 -> EPa }
I remarked the attribute *network*, since the RFC leaves open to
implementations how to realize those network paths (and because they
include the endpoints, which a SFC does not). In ODL SFC for example, we
realize 1) and 2) using RSPs, whereas we don't support 3). Notice so far
I haven't needed to use the terms "symmetric/asymmetric".
If we consider only 1) and 2) it is clear from the RFC and the
description above that the uni-directional/bi-directional attribute is a
property of the SFC. A different question is whether the attribute is a
populated one, i.e. set by the operator, or calculated one, i.e. set
automatically by the system from other attributes like e.g. the
hypothetical unidirectional/bi-directional attribute of a SF being
discussed in other messages in this thread. That is an operational
aspect not having to do with the architecture.
Now it is 3) that causes a problem, because even if the 'hybrid'
attribute belongs to the SFC, that does not fully define the chain: we
need the set of SFs requiring bi-directionality. And a very good way of
defining that set would be the uni-directional/bi-directional attribute
of the SF. In the sake of completeness, notice that the same service
(e.g. a firewall) can be modeled as a uni-directional SF in one chain
but as a bi-directional one in another, perhaps depending on the other
SFs in the chain.
My conclusion is that the model is right as it is now in Carbon; we may
want to improve UX by calculating the SFC attribute from (extended) SF
attributes though. In doing so, when we support hybrid SFCs (if ever),
we'll have all the pieces in place and a small enhancement to RSP
rendering should cut it.
Take care,
/Javier
On 11/10/2016 04:50 PM, Tim Rozet wrote:
I don't think this is a good change. Indicating an SF as symmetrical creates
implications on the entire chain. This attribute affects the entire chain so
it should be configured on a per chain basis.
Think about if there is an SF that is capable of symmetry - let's say a
stateful firewall device which also acts as an stateless firewall. The SF is
configured to only perform stateful inspection on part of the traffic. Some
group of traffic I want to differentiate in chain A by indicating it should go
through the stateful firewall, which I want to be symmetrical. But then
another group of traffic in another chain B I want to also go through the same
SF via stateless fw feature and not be symmetrical. This is not possible with
this implementation.
I think a better solution is perhaps marking an SF as requires symmetry in the
case where it is a stateful only function, and leaving the actual configuration
of creating a reverse RSP (and classifier) to a symmetrical flag on the chain
and classifier creations. If a chain is created containing an SF which
requires symmetry, and the symmetrical flag is not True on the chain, then an
error should occur.
Tim Rozet
Red Hat SDN Team
----- Original Message -----
From: "Diego Jesus Granados Lopez" <[email protected]>
To: "Brady Allen Johnson" <[email protected]>, "Swati Deshpande"
<[email protected]>, "Yi Y Yang" <[email protected]>
Cc: [email protected], "Tim Rozet" <[email protected]>
Sent: Thursday, November 10, 2016 8:59:40 AM
Subject: RE: [sfc-dev] Deprecating SFC, SFP, and RSP symmetric fields
Nicely explained
Only a minor remark: since we’re rethinking symmetry, I was also saying that we
should use the occasion to move the symmetric flag (in the current yang model, in the
SF type) to the SF. The rationale is that SF types (dpi, HE…) are not symmetric in
general, but implementation-wise (that’s the point I was trying to do with the
transparent HE->not symmetric / proxy HE->symmetric example, both being SFs
belonging to the “HE” SF type), while operator thinks only in choosing the best
fitting SF in the market belonging to the “HE” type
From: Brady Allen Johnson
Sent: jueves, 10 de noviembre de 2016 13:47
To: Swati Deshpande <[email protected]>; Yang, Yi Y
<[email protected]>
Cc: Diego Jesus Granados Lopez <[email protected]>;
[email protected]; Tim Rozet <[email protected]>
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:[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
_______________________________________________
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
