Subject: Re: [nsc] Progress toward WG formation

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Dec 2013 16:22:20 +0000

Ron, 

Thanks for the good description. 

Just a question, sub-5-tuple operation (like your HTTP2.0 example) won't be possible if communications are over TLS (Transport Layer Security), correct? 

Linda

> -----Original Message-----
> From: nsc [mailto:[email-masked]] On Behalf Of Ron Parker
> Sent: Friday, November 29, 2013 11:15 AM
> To: Kevin J Ma; Diego R. Lopez
> Cc: [email-masked]; Jim Guichard (jguichar); Melinda Shore
> Subject: Re: [nsc] Progress toward WG formation
> 
> As Kevin mentioned, he and I had an offline discussion on this topic
> and I'd like to summarize for the group what we discussed.
> 
> The issue at hand is whether the SFC architecture will include those
> service functions that operate sub-5-tuple, at the transaction level.
> Take, for example, HTTP2.0 where an HTTP2.0 aware service
> function/classifier may choose to send some transactions on one chain
> and others on another.   Since these transactions were separated out
> from a common five-tuple, in practical terms, all of those transaction-
> level chains would need to return back to the original service function
> (which perhaps is represented as two distrinct service functions --
> front-half and back half.
> 
> Kevin's basic question is whether the SFC architecture supports this
> type of functionality and my view is categorically, yes.   In fact 5-
> tuple aware and transaction aware decision making is one of the prime
> advantages over existing physical or VLAN-based chaining.
> 
> Clearly, there are additional complexities to do this (i.e., what is
> the full encapsulation stackup for those packets that represent a
> subset of the original 5-tuple?).   As a group we would need to decide
> what, if any, of that complexity was pushed down into the SFC
> capability set or whether that complexity remains solely within the
> domain of the affected service functions (i.e., do those service
> functions that are chained after the HTTP2.0-aware classifier need to
> implicitly know that they are indeed participating in such a scenario?).
> 
>    Ron
> 
> 
> ________________________________________
> From: Kevin J Ma [[email-masked]]
> Sent: Thursday, November 28, 2013 10:08 AM
> To: Diego R. Lopez; Ron Parker
> Cc: [email-masked]; Jim Guichard (jguichar); Melinda Shore
> Subject: RE: [nsc] Progress toward WG formation
> 
> Hi Ron/Diego,
> 
>   Certainly there are ways to implement it, but again, my original
> question
>   was simply: is this discussion in or out of scope?  And I think the
> simple
>   answer was/is no.
> 
> thanx.
> 
> --  Kevin J. Ma
> 
> > -----Original Message-----
> > From: Diego R. Lopez [mailto:[email-masked]]
> > Sent: Thursday, November 28, 2013 4:15 AM
> > To: Ron Parker
> > Cc: Kevin J Ma; [email-masked]; Jim Guichard (jguichar); Melinda Shore
> > Subject: Re: [nsc] Progress toward WG formation
> >
> > Indeed. In a typical HTTP application scenario, you have by default
> access
> > to local and remote IP addresses, TCP port numbers, TLS identity
> > parameters, and process environment variables, to name the essential
> ones.
> > I think it would be reasonable to expect that a SFC module (not to
> use the
> > accursed "layer": I fully agree with Melinda's previous statement on
> the
> > layering confusion) would be able to expose some information on its
> > metadata. Anyway, that should be a design decision and certainly out
> of
> > scope for this group.
> >
> > Be goode,
> >
> > On 28 Nov 2013, at 03:57 , Ron Parker wrote:
> >
> > > I don't think there is a strict prohibition on seeing data from
> lower
> > layers.  Even in a traditional user space application implementation
> there
> > is limited capability to get lower layer information via sockopt and
> > recvmsg.
> > >
> > >    Ron
> > >
> > >
> > >> On Nov 27, 2013, at 7:45 PM, "Kevin J Ma"
> <[email-masked]>
> > wrote:
> > >>
> > >> Hi Melinda,
> > >>
> > >>> Unless someone's written something
> > >>> *extremely* funky, as a rule encapsulations/headers/
> > >>> etc. are not available to the services "above" them.
> > >>
> > >> Indeed.  That is precisely the problem.
> > >>
> > >> If I have a service that runs above that encapsulation layer,
> > >> (e.g., an HTTP load balancer, AV Scanner, Video Optimizer, etc.)
> > >> how does that service know what chain it's in, and how does
> > >> it indicate to the lower encapsulation layer what chain to
> > >> send it back out on if reclassification occurs?
> > >>
> > >> --  Kevin J. Ma
> > >>
> > >>> -----Original Message-----
> > >>> From: Melinda Shore [mailto:[email-masked]]
> > >>> Sent: Wednesday, November 27, 2013 7:03 PM
> > >>> To: Kevin J Ma
> > >>> Cc: Ron Parker; Jim Guichard (jguichar); [email-masked]
> > >>> Subject: Re: [nsc] Progress toward WG formation
> > >>>
> > >>>> On 11/27/13 11:03 AM, Kevin J Ma wrote:
> > >>>> My question was partially about whether it would always be the
> IP
> > >>> datagram,
> > >>>> or whether it could be an ethernet frame, or a TCP payload, or
> > whether
> > >>> it
> > >>>> might be just the HTTP entity body.
> > >>>
> > >>> Where I think you've wandered into the weeds is that you
> > >>> appear to believe that the nsc "application" is going to
> > >>> receive the entire datagram, from the Ethernet (or
> > >>> whatever) frame up.  Unless someone's written something
> > >>> *extremely* funky, as a rule encapsulations/headers/
> > >>> etc. are not available to the services "above" them.  That's
> > >>> certainly true for all modern operating systems (TCP
> > >>> does not see the Ethernet frame [or the IP datagram], and
> > >>> so on).
> > >>>
> > >>> Melinda
> > >>
> > > _______________________________________________
> > > nsc mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/nsc
> >
> >
> > --
> > "Esta vez no fallaremos, Doctor Infierno"
> >
> > Dr Diego R. Lopez
> > Telefonica I+D
> > http://people.tid.es/diego.lopez/
> >
> > e-mail: [email-masked]
> > Tel:    +34 913 129 041
> > Mobile: +34 682 051 091
> > -----------------------------------------
> >
> >
> > ________________________________
> >
> > Este mensaje se dirige exclusivamente a su destinatario. Puede
> consultar
> > nuestra política de envío y recepción de correo electrónico en el
> enlace
> > situado más abajo.
> > This message is intended exclusively for its addressee. We only send
> and
> > receive email on the basis of the terms set out at:
> > http://www.tid.es/ES/PAGINAS/disclaimer.aspx
> _______________________________________________
> nsc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsc

---

From: Melinda Shore <[email-masked]>
Date: Tue, 03 Dec 2013 07:27:31 -0900

On 12/3/13 7:22 AM, Linda Dunbar wrote:
> Just a question, sub-5-tuple operation (like your HTTP2.0 example)
> won't be possible if communications are over TLS (Transport Layer
> Security), correct?

There are a lot of reasons to convey that information in the
'signaling' (metadata) and this is prominent among them.
The chief counter-argument is NAT, but NAT is generally a
hairball issue, particularly in cases where you're describing
a third party.  To be clear, I haven't been arguing against
including 5-tuple or other cross-layer data in the signaling
data, but rather than they should be carried explicitly and
encapsulated within the nsc message rather than handing the
entire frame up the stack.

Melinda