Subject: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry

From: Linda Dunbar <[email-masked]>
Date: Tue, 14 Apr 2015 23:15:47 +0000

Joel and Carlos,

Even though draft-ietf-sfc-architecture-07 is already in the status of "request for publication", I hope you can make those simple changes suggested.

The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different ways of using "Classifiers" to achieve SFC Symmetry.

The definition of "Classifier" is "An element that performs Classification", which can be as simple as separating traffic based on some matching criteria.

For traffic between  A<->network <-> B, the classifier for traffic from "A" -> "B" could be at the "network" port facing A; and the classifier for traffic from "B" -> "A" could be at the "network" port facing B.  Therefore, using "Classifier" to achieve symmetry can be cumbersome, as your list describing "stateful classifiers", "cluster classifiers"; state exchanging among "classifiers", ...

If a centralized SFC controller is deployed, classifiers at either direction don't have to be involved in symmetry decision.

Therefore, it is not true at all that "Symmetry may be
realized in several ways depending on the SFF and classifier
functionality."

Symmetry is realized in great deal by how SFP is constructed or controlled.

Since the sfc-architecture is not to advocate certain solutions, this document shouldn't have the description on state exchanges among classifiers to achieve SFC symmetry, i.e. should delete the 4th paragraph and the bullets after.

Cheers,

Linda

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 15 Apr 2015 09:56:23 -0400

I think your correction is backwards.  It is true that the behavior you 
describe is permitted, and may even be common.  It is still true that 
symmetry "may be realized ...".  If this is a big deal, we could add a 
note that control mechanisms may play a role in achieving symmetry.  I 
am not sure such a statement is needed, but I could live with it.

The statement itself is needed to indicate that several mechanissm other 
folks want to use are also permitted by the archtiecture.

Yours,
Joel

On 4/14/15 7:15 PM, Linda Dunbar wrote:
> Joel and Carlos,
>
> Even though draft-ietf-sfc-architecture-07 is already in the status of
> “request for publication”, I hope you can make those simple changes
> suggested.
>
> The Section 2.2 of draft-ietf-sfc-architecture-07 listed 4 different
> ways of using “Classifiers” to achieve SFC Symmetry.
>
> The definition of “Classifier” is “An element that performs
> Classification”, which can be as simple as separating traffic based on
> some matching criteria.
>
> For traffic between  A<->network <-> B, the classifier for traffic from
> “A” -> “B” could be at the “network” port facing A; and the classifier
> for traffic from “B” -> “A” could be at the “network” port facing B.
>   Therefore, using "Classifier" to achieve symmetry can be cumbersome,
> as your list describing “stateful classifiers”, “cluster classifiers”;
> state exchanging among “classifiers”, …
>
> If a centralized SFC controller is deployed, classifiers at either
> direction don’t have to be involved in symmetry decision.
>
> Therefore, it is not true at all that “Symmetry may be
>
> functionality.”
> Since the sfc-architecture is not to advocate certain solutions, this
> document shouldn’t have the description on state exchanges among
> classifiers to achieve SFC symmetry, i.e. should delete the 4^th
> paragraph and the bullets after.
>
> Cheers,
>
> Linda
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 15 Apr 2015 15:55:27 +0000

Most likely classifiers at either end of the SFC domain don't even know where the FW (that require bidirectional congruency) in the network is and which instance of FW that packets will traverse. Bidirectional congruency, if required, has to be at the SF instance level. 

Therefore, very complicated mechanisms and coordination are required for a head-end Classifier (that has an embedded DPI engine) to enforce bidirectional congruency of a Firewall deployed in the middle of the network, and the complex mechanisms needed to collaborate with the other end of Classifier. 

Yes, it will make so much more sense to say:

  - symmetry "may be realized by multiple mechanisms", 
  - " The statement itself is needed to indicate that several mechanism other folks want to use are also permitted by the architecture.", and 
  - delete the description on Classifier based solutions

Linda

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, April 15, 2015 8:56 AM
To: Linda Dunbar; Carlos Pignataro (cpignata)
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry

I think your correction is backwards.  It is true that the behavior you describe is permitted, and may even be common.  It is still true that symmetry "may be realized ...".  If this is a big deal, we could add a note that control mechanisms may play a role in achieving symmetry.  I am not sure such a statement is needed, but I could live with it.

The statement itself is needed to indicate that several mechanissm other folks want to use are also permitted by the archtiecture.

Yours,
Joel

On 4/14/15 7:15 PM, Linda Dunbar wrote:
> "request for publication", I hope you can make those simple changes 
> suggested.
>
> ways of using "Classifiers" to achieve SFC Symmetry.
>
> The definition of "Classifier" is "An element that performs 
> Classification", which can be as simple as separating traffic based on 
> some matching criteria.
>
> For traffic between  A<->network <-> B, the classifier for traffic 
> from "A" -> "B" could be at the "network" port facing A; and the 
> classifier for traffic from "B" -> "A" could be at the "network" port facing B.
> as your list describing "stateful classifiers", "cluster classifiers"; 
> state exchanging among "classifiers", ...
>
> direction don't have to be involved in symmetry decision.
>
> document shouldn't have the description on state exchanges among

---

From: Ron Parker <[email-masked]>
Date: Wed, 15 Apr 2015 16:02:31 +0000

Linda,

I think there are some topological considerations, here.   If the network is arranged such that the related traffic in both directions (lets say upstream and downstream for sake of discussion) traverses the same entity always, as might be the case for various Subscriber Management Systems, then a classifier located in that place would be capable of applying bidirectional congruency.     On the other hand, a network that is solely a layer 3 routed cloud may not be able to guarantee that the same Router is always traversed for upstream and downstream wrt related traffic.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, April 15, 2015 11:55 AM
To: Joel M. Halpern; Carlos Pignataro (cpignata)
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry

Linda

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Wednesday, April 15, 2015 8:56 AM
To: Linda Dunbar; Carlos Pignataro (cpignata)
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry

Yours,
Joel

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 15 Apr 2015 16:19:52 +0000

Linda,

> On Apr 15, 2015, at 11:55 AM, Linda Dunbar <[email-masked]> wrote:
> 

I'm a bit confused by this.  Can you please give me an example of how the symmetry can be handled by the SF instance(s), which, don't perform any path forwarding?

---

From: Ian Smith <[email-masked]>
Date: Wed, 15 Apr 2015 16:34:05 +0000

I think it is also fair to say that there are cases where the chain itself is not symmetric, but a subset of that chain is.   

What I've found to be an effective way of looking situations like this is to treat them as two separate flows - one in each direction (to the internet & from the internet) and then converge the flows on the nodes that expect them to be converged.

This yields a design paradigm where there is no symmetry, only persistent nodes where both directions of traffic MUST traverse and nodes where both directions of traffic MAY traverse.  This changes the problem from one where a single full-duplex symmetry is required (usually in excess of actuality) to one where two or more half-duplex symmetries are called for, and it shifts the problem of state from a wiring problem (or the arrangement of virtual wires) to a routing problem.

Concentrating on this routing problem, not the wiring problem, is what I read the document to be suggesting is the way forward.

When you talk of using controllers, this is implicitly what you're talking about doing.  So there isn't a symmetry problem in your example of   A > network > B, because there is implicitly B > network > A which doesn't have to have the same value of "network".    And in the case of something like A > D > B, the implication is that the sequence is locked in below routing in physical or virtual  wiring domain so that there is no choice but to go through D to get to B from A and the inverse.  In those cases, the implication is often that A == B or that A and B share some sort of state management methodology either explicitly (some sort of distributed systems) or implicitly (because of link-flow associations).

Finally, I'd suggest that a FW, in this kind of scenario, probably doesn't _need_ to be tracking connections, because either it is being directed by a controller on a flow by flow basis, in which case there are two rules in the rule set (in the case of A > network > B), or because the network state is irrelevant because of a decision that was made outside of its view before the flow gets to it (in the case of A > D > B).  The bottom line being that if you try to just pick up the design patterns from an SFC-free network and use them in and SFC network, the value that SFC adds on top of "Programmable, Elastic, Virtualized, and Scalable Infrastructure with an API" is being lost.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, April 15, 2015 11:55 AM
To: Joel M. Halpern; Carlos Pignataro (cpignata)
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry

Linda

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Wednesday, April 15, 2015 8:56 AM
To: Linda Dunbar; Carlos Pignataro (cpignata)
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 15 Apr 2015 16:42:38 +0000

Paul, 

I don't mean at all that symmetry is achieved by SF instances. I am saying, if a SF (e.g. stateful FW) needs both direction of a flow, it is the FW instance that needs both direction of a flow to traverse, not the abstract SF (which can have many instances spread across the network). 

I am trying to point out that if the congruency is required by SF instance, it is very difficult for the head end classifier to achieve. More reasonable entity to achieve symmetry is the entity that manages the SFC path (or RSP) selection. 

Linda 

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Wednesday, April 15, 2015 11:20 AM
To: Linda Dunbar
Cc: Joel M. Halpern; Carlos Pignataro (cpignata); [email-masked]; Alia Atlas
Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry

Linda,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 15 Apr 2015 16:24:57 -0400

There were specific requests from working group members for fully 
symmetric SFCs.  The fact that some folks don't need them does not free 
the authors to ignore the requests.
Similarly, there were multiple approaches proposed to address tghe 
requirements, and since it can easily do so, the architecture should 
acknowledge that range.  Which is what it tries to do.

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 15 Apr 2015 21:02:55 +0000

It is perfectly reasonable to describe "full symmetric SFCs" in the architecture document. The current Section 2.2 has very good description of fully symmetric SFCs and partially symmetric SFC, etc". 

I just want to point out that SFC-architecture document shouldn't advocate the solutions of using classifiers to achieve SFC symmetry.

If you want to say something about the symmetry solutions, a more reasonable entity to achieve symmetry is the entity that manages the SFC path (or RSP) selection. 

Linda

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, April 15, 2015 3:25 PM
To: Linda Dunbar; Paul Quinn (paulq)
Cc: Carlos Pignataro (cpignata); [email-masked]; Alia Atlas
Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry

There were specific requests from working group members for fully symmetric SFCs.  The fact that some folks don't need them does not free the authors to ignore the requests.
Similarly, there were multiple approaches proposed to address tghe requirements, and since it can easily do so, the architecture should acknowledge that range.  Which is what it tries to do.

Yours,
Joel

On 4/15/15 12:42 PM, Linda Dunbar wrote:
> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate 
> various ways of using "Classifier" to achieve SFC Symmetry
>
> Linda,
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 15 Apr 2015 19:52:46 -0400

I could live with this model for symmetry.  I agree with you that it 
reflects a common case.  We were asked explicitly to include support for 
full symmetry, which is generally simpler to handle as a specific case 
rather than as a generalization of going through specific functions. 
There are mechanisms people would like to use that fit that model.

Yours,
Joel

---

From: Ian Smith <[email-masked]>
Date: Thu, 16 Apr 2015 00:13:10 +0000

I recall the conversation re: supporting full symmetry, and I get that people want it and generally think I understand why they want it.

I suppose I'm reading it to say that you MAY have symmetric flows, and when you do they should look "like this", but they aren't a MUST requirement of the architecture.  Is that what you intended?

If so, I have no issue with it as written, since that is how it is actually done today.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, April 15, 2015 7:53 PM
To: Ian Smith; Linda Dunbar; Carlos Pignataro (cpignata)
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry

I could live with this model for symmetry.  I agree with you that it reflects a common case.  We were asked explicitly to include support for full symmetry, which is generally simpler to handle as a specific case rather than as a generalization of going through specific functions. 
There are mechanisms people would like to use that fit that model.

Yours,
Joel

On 4/15/15 12:34 PM, Ian Smith wrote:
>> Even though draft-ietf-sfc-architecture-07 is already in the status 
>> of "request for publication", I hope you can make those simple 
>> changes suggested.
>>
>> Classification", which can be as simple as separating traffic based 
>> on some matching criteria.
>>
>>    Therefore, using "Classifier" to achieve symmetry can be 
>> cumbersome, as your list describing "stateful classifiers", "cluster 
>> classifiers"; state exchanging among "classifiers", ...
>>

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 15 Apr 2015 20:15:49 -0400

We are certainly not mandating that all service function paths have to 
by symmetric.  They clearly don't.
I did not even think that we were mandating that if you want symmetry 
you have to do it this way.  Using classifiers and SFF behaviors is one 
way to achieve it.  Using control mechanisms so that from the point of 
view of the data plane mechanisms the two paths just happen to be the 
reverse of each other is also fine.  And I am betting someone will come 
up with some alternative I have not even thought of.

Is there a clarification we can add to make clear that the range of 
solutions is allowed by the architecture?

Yours,
Joel

---

From: Ian Smith <[email-masked]>
Date: Thu, 16 Apr 2015 01:04:53 +0000

I think it is clear as written, I was just confirming that I was on the same page.    

Particularly, paragraph 1 in section 2.2 covers the MAY - MUST topic in a way that shouldn't create uncertainty.  And the rest of that section does a fine job, I think, of explicating the tradeoffs of symmetric vs asymmetric flows without being prescriptive.  

A general observation that shouldn't delay publication is that we (networking writ large) are, in general, experiencing namespace collisions that just make things hard.  "Classifier" comes with baggage in the form of assumptions about the form factor a vendor might deliver the functionality, as this thread shows, even if that is a pretty good label to hang on the function.  It is, in fact, a thing that is assigning a class or category to a datagram, packet, transport session, application transaction, or any other distinguishing criteria; the very definition of "classifier".  But that does not mean, necessarily, that an SFC classifier is a deep packet inspector or that it is, necessarily, burdened by the technological shortcomings of current DPI offerings.  It simply means that such a thing as an "SFC Classifier" exists and if DPI vendors (or vendors of any product) want their products to be SFC classifiers, they have certain challenges to overcome, some of which you touch on in section 2.2 regarding the relationship between state and symmetry.  

As Linda pointed out, there are other challenges as well, in particular the relationship between decision and action.  I don't believe that this is the document to delve into those things, in part because I don't believe that the answers are complete enough to document.  And in part because it takes us down a rabbit hole that sounds much more like current best practices than architectural guidance.  Maybe I'm wrong.  Maybe we'll be rewriting this sooner than we'd like because things have changed significantly.  But I don't think that we have data to say that is the case today, so I feel that we should continue to press forward and not go down the rabbit hole (even though I find it pretty darn interesting).   

The corollary observation is that when we try to avoid such namespace baggage, we end up with cumbersome names for things that end up being just as bad, if not worse.  Again, there is no specific thing that I'm pointing at in this draft, just a general observation after a day of heavy reading.

-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Wednesday, April 15, 2015 8:16 PM
To: Ian Smith; Linda Dunbar; Carlos Pignataro (cpignata)
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate various ways of using "Classifier" to achieve SFC Symmetry

We are certainly not mandating that all service function paths have to by symmetric.  They clearly don't.
I did not even think that we were mandating that if you want symmetry you have to do it this way.  Using classifiers and SFF behaviors is one way to achieve it.  Using control mechanisms so that from the point of view of the data plane mechanisms the two paths just happen to be the reverse of each other is also fine.  And I am betting someone will come up with some alternative I have not even thought of.

Is there a clarification we can add to make clear that the range of solutions is allowed by the architecture?

Yours,
Joel

On 4/15/15 8:13 PM, Ian Smith wrote:
>>> Since the sfc-architecture is not to advocate certain solutions, 
>>> this document shouldn't have the description on state exchanges 
>>> among classifiers to achieve SFC symmetry, i.e. should delete the 
>>> 4^th paragraph and the bullets after.
>>>
>>> Cheers,
>>>
>>> Linda
>>>
>>>
>>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 16 Apr 2015 12:46:58 +0000

Net-net, it seems this thread is converging on no change needed.

Alia,

What’s the status of your AD review of the SFC Architecture?

Thanks!

— Carlos.

> On Apr 15, 2015, at 8:13 PM, Ian Smith <[email-masked]> wrote:
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 16 Apr 2015 12:38:04 -0400

Carlos,

Agreed as to the thread convergence.
I'm still woefully behind on review the SFC architecture and other drafts.
I will try and get to it this week - but if not this week, it may sit for 3
more weeks
due to vacation, work-travel (a couple days that week might be possible),
and
IESG/IAB retreat.

Do keep pinging me.

Alia

On Thu, Apr 16, 2015 at 8:46 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> > I recall the conversation re: supporting full symmetry, and I get that
> people want it and generally think I understand why they want it.
> >
> > I suppose I'm reading it to say that you MAY have symmetric flows, and
> when you do they should look "like this", but they aren't a MUST
> requirement of the architecture.  Is that what you intended?
> >
> >> I think it is also fair to say that there are cases where the chain
> itself is not symmetric, but a subset of that chain is.
> >>
> >> What I've found to be an effective way of looking situations like this
> is to treat them as two separate flows - one in each direction (to the
> internet & from the internet) and then converge the flows on the nodes that
> expect them to be converged.
> >>
> >> This yields a design paradigm where there is no symmetry, only
> persistent nodes where both directions of traffic MUST traverse and nodes
> where both directions of traffic MAY traverse.  This changes the problem
> from one where a single full-duplex symmetry is required (usually in excess
> of actuality) to one where two or more half-duplex symmetries are called
> for, and it shifts the problem of state from a wiring problem (or the
> arrangement of virtual wires) to a routing problem.
> >>
> >> Concentrating on this routing problem, not the wiring problem, is what
> I read the document to be suggesting is the way forward.
> >>
> >> When you talk of using controllers, this is implicitly what you're
> talking about doing.  So there isn't a symmetry problem in your example of
>  A > network > B, because there is implicitly B > network > A which doesn't
> have to have the same value of "network".    And in the case of something
> like A > D > B, the implication is that the sequence is locked in below
> routing in physical or virtual  wiring domain so that there is no choice
> but to go through D to get to B from A and the inverse.  In those cases,
> the implication is often that A == B or that A and B share some sort of
> state management methodology either explicitly (some sort of distributed
> systems) or implicitly (because of link-flow associations).
> >>
> >> Finally, I'd suggest that a FW, in this kind of scenario, probably
> doesn't _need_ to be tracking connections, because either it is being
> directed by a controller on a flow by flow basis, in which case there are
> two rules in the rule set (in the case of A > network > B), or because the
> network state is irrelevant because of a decision that was made outside of
> its view before the flow gets to it (in the case of A > D > B).  The bottom
> line being that if you try to just pick up the design patterns from an
> SFC-free network and use them in and SFC network, the value that SFC adds
> on top of "Programmable, Elastic, Virtualized, and Scalable Infrastructure
> with an API" is being lost.
> >>
> >>
> >>
> >> Most likely classifiers at either end of the SFC domain don't even know
> where the FW (that require bidirectional congruency) in the network is and
> which instance of FW that packets will traverse. Bidirectional congruency,
> if required, has to be at the SF instance level.
> >>
> >> Therefore, very complicated mechanisms and coordination are required
> for a head-end Classifier (that has an embedded DPI engine) to enforce
> bidirectional congruency of a Firewall deployed in the middle of the
> network, and the complex mechanisms needed to collaborate with the other
> end of Classifier.
> >>
> >>
> >>   - " The statement itself is needed to indicate that several mechanism
> other folks want to use are also permitted by the architecture.", and
> symmetry "may be realized ...".  If this is a big deal, we could add a note
> that control mechanisms may play a role in achieving symmetry.  I am not
> sure such a statement is needed, but I could live with it.
> >>
> >> The statement itself is needed to indicate that several mechanissm
> other folks want to use are also permitted by the archtiecture.
> >>
> >> Yours,
> >> Joel
> >>