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

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 10 May 2015 13:58:42 +0000

Hi Alia,

Ping, as requested :-)

> On Apr 16, 2015, at 12:38 PM, Alia Atlas <[email-masked]> wrote:
> 
> 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.

Any progress on draft-ietf-sfc-architecture now that we are past the 3+ extra weeks of wait?

Thanks,

— Carlos.

> 
> Do keep pinging me.
> 
> Alia
> 
> On Thu, Apr 16, 2015 at 8:46 AM, Carlos Pignataro (cpignata) <[email-masked] <mailto:[email-masked]>> wrote:
> 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:
> >
> > 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] <mailto:[email-masked]>]
> > Sent: Wednesday, April 15, 2015 7:53 PM
> > To: Ian Smith; Linda Dunbar; Carlos Pignataro (cpignata)
> > Cc: [email-masked] <mailto:[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:
> >> 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] <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] <mailto:[email-masked]>; 'Alia Atlas'
> >> Subject: Re: [sfc] draft-ietf-sfc-architecture-07 shouldn't advocate
> >> various ways of using "Classifier" to achieve SFC Symmetry
> >>
> >> 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] <mailto:[email-masked]>]
> >> Sent: Wednesday, April 15, 2015 8:56 AM
> >> To: Linda Dunbar; Carlos Pignataro (cpignata)
> >> Cc: [email-masked] <mailto:[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:
> >>> 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 4^th
> >>> paragraph and the bullets after.
> >>>
> >>> Cheers,
> >>>
> >>> Linda
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> sfc mailing list
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>
> >>>
> >>
> >> _______________________________________________
> >> sfc mailing list
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>
> >>
> 
>