Subject: [sfc] Support Bidirection/Symmetric flow

From: Sumandra Majee <[email-masked]>
Date: Thu, 26 Feb 2015 22:10:43 +0000

Hello,

The SFC architecture document says (correctly) that ingress path and egress path of a given flow or work unit could symmetric, asymmetric or hybrid.  However a front/back (end) classifier is not always the correct place to derive this information.  Some cases are simple,

  IN:      Classifier -> SF1 -> SF2 -> Cache(*) - >SF3 - RTR-
 OUT:   Classifier -> SF3 --> Cache --> RTR

The actual chains are not laid out like that, but for this discussion lets stick with the above figure. In this case a device like cache detects that both direction of flow must flow thru the cache (cache miss).

Now lets replace the cache with a modern ADC device. These devices can and will make the decision for each flow. For optimal operation it is best to signal the upstream node that flow(X) must come back to this SF or should bypass this SF.

How can we do this signaling? Metadata is an option, but it is a generic use case where the format of this metadata then should be standardized.
The responsible SF can demand the return PATH to be some 221 that forces return traffic thru that SF,   well that may not always be the good.

Some sort of label stack?

Interested to hear from you..

Regards.

Sumandra

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 26 Feb 2015 22:40:44 +0000

It is my impression that if you rewrite the picture like this it might help working out the solution

                       SF1      SF2         SFF3
                        |        |          |
IN:      Classifier —> SFF1 —> SFF2 —> Cache(*)/SFF — RTR—

Since cache is actually directing (steering packets) it becomes a SFF. If you adapt the reverse picture Cache/SFF will make sure reverse flows to the same SF3.

This is the whole Service Function Groups concept.

thanks,

From: Sumandra Majee <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 26, 2015 at 2:10 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sfc] Support Bidirection/Symmetric flow

Hello,

  IN:      Classifier —> SF1 —> SF2 —> Cache(*) — >SF3 — RTR—
 OUT:   Classifier -> SF3 --> Cache ——> RTR

Regards.

Sumandra

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Feb 2015 17:44:59 -0500

I would recommend that this sort of signalling be done with control 
protocols between the SF and the control aspects of service chaining.  I 
would not try to indicate it in the dat path of the service chain.

Yours,
Joel

On 2/26/15 5:10 PM, Sumandra Majee wrote:
> Hello,
>
> The SFC architecture document says (correctly) that ingress path and
> egress path of a given flow or work unit could symmetric, asymmetric or
> hybrid.  However a front/back (end) classifier is not always the correct
> place to derive this information.  Some cases are simple,
>
> The actual chains are not laid out like that, but for this discussion
> lets stick with the above figure. In this case a device like cache
> detects that both direction of flow must flow thru the cache (cache miss).
>
> Now lets replace the cache with a modern ADC device. These devices can
> and will make the decision for each flow. For optimal operation it is
> best to signal the upstream node that flow(X) must come back to this SF
> or should bypass this SF.
>
> How can we do this signaling? Metadata is an option, but it is a generic
> use case where the format of this metadata then should be standardized.
> The responsible SF can demand the return PATH to be some 221 that forces
> return traffic thru that SF,   well that may not always be the good.
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Sumandra Majee <[email-masked]>
Date: Fri, 27 Feb 2015 01:12:18 +0000

Reinaldo,

The cache example is the easy one. As you noted it could be done by grouping, a cache must *always* see both side of the traffic.

If I replace cache with ADC or other stateful flow aware devices then the always part is not true. Flow1 can be deemed as must be bidirectional and then flow2 can be assymetric, which essentially says bypass me.

                       SF1      SF2     ADC
                        |        |       |
IN:      Classifier -> SFF1 -> SFF2 -> SFF3 - SFF4-RTR-

Building symmetric and/or hybrid path in dynamic ways is a great tool and I am hoping this is one area where NSH can help immensely.

Because these are run time decision an inband signalling is the reliable way.

Regards.

Sumandra

________________________________
From: Reinaldo Penno (repenno) <[email-masked]>
Sent: Thursday, February 26, 2015 2:40 PM
To: Sumandra Majee; [email-masked]
Subject: Re: [sfc] Support Bidirection/Symmetric flow

                       SF1      SF2         SFF3
                        |        |          |
IN:      Classifier -> SFF1 -> SFF2 -> Cache(*)/SFF - RTR-

thanks,

Hello,

Regards.

Sumandra

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Feb 2015 20:22:13 -0500

I am a little confused by your statement that these are "run time 
decisions" with an apparent implication that they are decisions made by 
the forwarding infrastructure.  Such an approach is permitted, but not 
req	uired, by the architecture and the protocol proposal.

So the question of what mechanisms are needed to enable symmetry when 
required depends upon both what we need.  For example, even the use 
cases you have suggested are ones where the control mechanisms setting 
up the paths will know whether they need to be symmetric.  So they can 
instantiate suitable state.
Now, if an implementation and deployment wants to allow data plane 
decision, then that implementation needs to come up with a way to meet 
the symmetry requirements.  It has been suggested by some of those who 
wish to deploy that way that the existing protocol hooks are sufficient 
for that.

Yours,
Joel

On 2/26/15 8:12 PM, Sumandra Majee wrote:
> Reinaldo,
>
>
> The cache example is the easy one. As you noted it could be done by
> grouping, a cache must *always* see both side of the traffic.
>
>
> If I replace cache with ADC or other stateful flow aware devices then
> the always part is not true. Flow1 can be deemed as must be
> bidirectional and then flow2 can be assymetric, which essentially says
> bypass me.
>
>
>                         SF1      SF2     ADC
>                          |        |       |
> IN:      Classifier —> SFF1 —> SFF2 —> SFF3 — SFF4-RTR—
>
> Building symmetric and/or hybrid path in dynamic ways is a great tool
> and I am hoping this is one area where NSH can help immensely.
>
> ------------------------------------------------------------------------
> *From:* Reinaldo Penno (repenno) <[email-masked]>
> *Sent:* Thursday, February 26, 2015 2:40 PM
> *To:* Sumandra Majee; [email-masked]
> *Subject:* Re: [sfc] Support Bidirection/Symmetric flow
> Since cache is actually directing (steering packets) it becomes a SFF.
> If you adapt the reverse picture Cache/SFF will make sure reverse flows
> to the same SF3.
>
> From: Sumandra Majee <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>

---

From: Sumandra Majee <[email-masked]>
Date: Fri, 27 Feb 2015 01:52:25 +0000

>>req	uired, by the architecture and the protocol proposal.

ADC, FW and other types stateful devices has a fair bit of local rules and
states. These equipments and rulesets etc. will be there as NSH is
introduced in the network. For example the local rule may decide that this
particular dst ip doesn¹t need to be TCP spliced. Since it doesn¹t do any
transformation it might want to bypass on the reverse part of flow. When I
say local rule, it could be configuration (static) or generated
dynamically from analytics. Both mechanisms are implemented on platforms
that I work on. Since it is flow by flow local decision the most reliable
way to alter the forwarding path is in band.

On 2/26/15, 5:22 PM, "Joel M. Halpern" <[email-masked]> wrote:

>> IN:      Classifier ‹> SFF1 ‹> SFF2 ‹> SFF3 ‹ SFF4-RTR‹
>>
>> IN:      Classifier ‹> SFF1 ‹> SFF2 ‹> Cache(*)/SFF ‹ RTR‹
>>
>>    IN:      Classifier ‹> SF1 ‹> SF2 ‹> Cache(*) ‹ >SF3 ‹ RTR‹
>>   OUT:   Classifier -> SF3 --> Cache ‹‹> RTR
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Feb 2015 21:06:14 -0500

Look at the long-lived flows draft.  We talk about exactly that case, 
and propose an approach to solving it.
For local optimization, there is also the bypass draft.

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Fri, 27 Feb 2015 17:34:09 +0000

Look also at section 3.2.2.1 in draft-homma-sfc-forwarding-methods-analysis-01
https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analysis-01#section-3.2.2.1

This shows a network architecture that allows asymmetric traffic arriving
at a large network to be brought to an "SF Domain Proxy" having 
a single classifier responsible for using bidirectional chains properly.

The problem we faced was how to arrange for geographically distributed classifiers 
to be coordinated well enough to select the correct chains.

So the geographically distributed classifiers instead select a data center,
using stateless decision-making, and the required coordination is local, by re-classifying
both directions of traffic using a single instance of classifier.

Then it becomes reasonable to talk about an SF signaling a single local classifier
to change the chain for a flow.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, February 26, 2015 9:06 PM
To: Sumandra Majee; Reinaldo Penno (repenno); [email-masked]
Subject: Re: [sfc] Support Bidirection/Symmetric flow

Yours,
Joel

On 2/26/15 8:52 PM, Sumandra Majee wrote:
>>> IN:      Classifier <> SFF1 <> SFF2 <> SFF3 < SFF4-RTR<
>>>
>>> IN:      Classifier <> SFF1 <> SFF2 <> Cache(*)/SFF < RTR<
>>>
>>>     IN:      Classifier <> SF1 <> SF2 <> Cache(*) < >SF3 < RTR<
>>>    OUT:   Classifier -> SF3 --> Cache <<> RTR
>>>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 27 Feb 2015 17:37:33 +0000

I think the problem is the same and well-understood.  Joel has provided some good references on the subject.

From: Sumandra Majee <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 26, 2015 at 5:12 PM
To: Reinaldo Penno <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Support Bidirection/Symmetric flow

Reinaldo,

                       SF1      SF2     ADC
                        |        |       |

Regards.

Sumandra

________________________________
From: Reinaldo Penno (repenno) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 26, 2015 2:40 PM
To: Sumandra Majee; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Support Bidirection/Symmetric flow

                       SF1      SF2         SFF3
                        |        |          |

thanks,

Hello,

Regards.

Sumandra

---

From: Sumandra Majee <[email-masked]>
Date: Sat, 28 Feb 2015 00:02:28 +0000

>>Look also at section 3.2.2.1 in draft-homma-sfc-forwarding-methods-analysis-01
Thanks for pointing to this draft. Yes, many of these methods are already in use when a single vendor distribute/clusterize their own devices.  The problem I am talking about can be approximated via Sub Domain concept (as in the draft), but that does not automatically means a single processing point. 

>>both directions of traffic using a single instance of classifier.

This problem does not need to span multiple data center. A cluster of ADC, classifiers etc. are required to handle current load multiple TB layer 7 processing load today in some to South East Asian countries. An ability to do signalling would clean up the network design. Not all customers are very willing or fond of creating tunnels (especially if those need to be setup manually). 
________________________________________
From: Dave Dolson <[email-masked]>
Sent: Friday, February 27, 2015 9:34 AM
To: Joel M. Halpern; Sumandra Majee; Reinaldo Penno (repenno); [email-masked]
Subject: RE: [sfc] Support Bidirection/Symmetric flow

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, February 26, 2015 9:06 PM
To: Sumandra Majee; Reinaldo Penno (repenno); [email-masked]
Subject: Re: [sfc] Support Bidirection/Symmetric flow

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 27 Feb 2015 19:36:40 -0500

Sumandra, I am not sure what you are asking for at this point.  The SFC 
working group is not standardizing the control channels between policy 
or control entities and the SF / SFF / classifier components.

The cases you seem to be talking about do not seem to need signaling in 
the data plane across the infrastructure.  They can be addressed quite 
well by various combinations of local communication to the local SFF and 
control signaling to the entities which set up the rules.  And that is 
why we have pointed at several different drafts.

Yours,
Joel