Subject: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

From: David Allan I <[email-masked]>
Date: Tue, 12 Nov 2013 19:04:06 +0000

Hi:
(resend with recipient list cleaned up)

I agree we are discussing multiple concepts, classification and flow-subsetting. Perhaps more ;-)

Defining a flow subset can be a result of classification, but it is not the exclusive mechanism. Branching is a mechanism by which flow subsets are exposed and mapped to a set of subchains such that it can be identified in the dataplane...

That's the view from here
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Lake (dlake)
Sent: Tuesday, November 12, 2013 10:51 AM
To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio)
Cc: Thomas Narten; [email-masked]; Sumandra Majee
Subject: Re: [nsc] Current Proposed SFC charter

Understood - maybe just a little localised warming of the sea then ?   But I still think we need to consider where and how policy is defined/set even for the single-domain instance.

I don't think we can assume that any L1-3 device will be able to determine much useful information from the data-plane.

-----Original Message-----
From: Jim Guichard (jguichar)
Sent: 12 November 2013 10:44
To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio)
Cc: Thomas Narten; [email-masked]; Sumandra Majee
Subject: Re: [nsc] Current Proposed SFC charter

As discussed during the BOF our initial work is single administrative domain for some of the very reasons you point out. We need to keep focused without trying to boil the ocean right off the bat.

On 11/12/13 1:36 PM, "David Lake (dlake)" <[email-masked]> wrote:

>Exactly.  But how can network-components "terminate" an application ????
>
>I think we need a good understanding of a recursive policy mechanism 
>(recursive because a user-land application will ride with a specific 
>policy across potentially different sets of carrier policies).
>
>I hate to bring this up now, but we also need to think about this 
>multi-domain issue - if I set a policy as a user, chances are I will be 
>crossing several domain boundaries.  Are we expecting the service 
>headers to define the service chaining for the duration of the entire 
>flow across all domains, or just across a single one ?
>
>In which case, do I have to re-set policy as I traverse domains  and
>where does that policy get set ?   It would be much better to set policy
>once based on L5-7 needs, and have that instantiated across the 
>multiple domains.
>
>Again, this appears to be outside the scope of SFC, but pretty relevant 
>to how it would operate in the real world.
>
>David
>
>-----Original Message-----
>From: Kevin J Ma [mailto:[email-masked]]
>Sent: 12 November 2013 10:27
>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda 
>Dunbar; Hongyu Li (Julio)
>Cc: Thomas Narten; [email-masked]; Sumandra Majee
>Subject: RE: [nsc] Current Proposed SFC charter
>
>> In those circumstances, only the end applications themselves or a 
>> reasonably broad-brushed classification (really traffic steering 
>> based on what we can see at ingress) is going to be useful - is THAT 
>> what we're aiming for here ?
>
>I would certainly hope not, but that has been my concern as well.
>Application layer termination and re-classification seems a must?
>
>--  Kevin J. Ma
>
>> -----Original Message-----
>> From: David Lake (dlake) [mailto:[email-masked]]
>> Sent: Tuesday, November 12, 2013 1:00 PM
>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; 
>> Hongyu Li (Julio)
>> Cc: Thomas Narten; [email-masked]; Sumandra Majee
>> Subject: RE: [nsc] Current Proposed SFC charter
>>
>> Policy may be outside of the scope of SFC, but without strong mapping 
>> between Policy and the inserted Service Header(s), we run-the-risk of 
>> limiting the efficacy of the protocol IMO.
>>
>> For example, in a world where the network has "gone dark," (as per 
>> the IETF Technical Plenary ?:-) ) what is our ability to determine 
>> policy based on DPI of packets-in-flight ?
>>
>> In those circumstances, only the end applications themselves or a 
>> reasonably broad-brushed classification (really traffic steering 
>> based on what we can see at ingress) is going to be useful - is THAT 
>> what we're aiming for here ?
>>
>> David
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
>> Surendra Kumar (smkumar)
>> Sent: 12 November 2013 09:26
>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio)
>> Cc: Thomas Narten; [email-masked]; Sumandra Majee
>> Subject: Re: [nsc] Current Proposed SFC charter
>>
>> Ron,
>>
>> Classification of traffic is well understood and we do not have to 
>> redefine it - it's been around for all the time middle boxes have 
>> been or for that matter the L2/L3 devices. All we are talking about 
>> is the applicability of the classification to branching in SFC.
>>
>> You are right, it is all about policy which is outside the scope of SFC.
>>
>> Surendra.
>>
>> On 11/12/13 7:53 AM, "Ron Parker" <[email-masked]>
>>wrote:
>>
>> >I think the lack of definition of "reclassification" may be causing
>>some
>> >misunderstandings here.    A branch would occur for some policy-driven
>> >reason based on the behavior and conclusions of the service function,
>> >itself.   The graph would represent the fact that there is a branch
>> >point, but the service function, itself, being aware that it is a 
>> >branching point would contain the policy and logic to decide on which
>> >branch to take.   Specifying that policy and logic is out of scope,
>>IMO.
>> >
>> >   Ron
>> >
>> >
>> >-----Original Message-----
>> >From: Kevin J Ma [mailto:[email-masked]]
>> >Sent: Tuesday, November 12, 2013 10:49 AM
>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio)
>> >Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); Sumandra 
>> >Majee
>> >Subject: RE: [nsc] Current Proposed SFC charter
>> >
>> >Hi Linda,
>> >
>> >  Are you saying that a branching point is "never" a 
>> > reclassification point, or are you saying that a branching point "does not have to be"
>> >  a reclassification point?
>> >
>> >  I think this is an important distinction that needs to be clarified.
>> >  If branching is never reclassification, then the meaning of a 
>> > chain is different than I originally inferred.  If the chain is a 
>> > tree with other "branching" points in it, then that limits the 
>> > scope of the problem statement goals.
>> >
>> >  While this could be a degenerate case, and any implementation 
>> > could define bad service chains, is it the intent of SFC to only 
>> > look at the simpler packet-level classification cases, or is it the 
>> > intent to consider the case where a branching point is viewed as a 
>> > re-classification point?
>> >
>> >thanx.
>> >
>> >--  Kevin J. Ma
>> >
>> >> -----Original Message-----
>> >> From: Linda Dunbar [mailto:[email-masked]]
>> >> Sent: Tuesday, November 12, 2013 10:34 AM
>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma
>> >> Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); 
>> >> Sumandra Majee
>> >> Subject: RE: [nsc] Current Proposed SFC charter
>> >>
>> >> Ron,
>> >>
>> >> First, want to make it clear that "branching" != reclassification, 
>> >>agree?
>> >>
>> >> Second, the representation of branching (or service graph) can be 
>> >> in a form of logic on a service function. Some service functions, 
>> >> especially L7 based, can use value in a Database to determine what 
>> >> is the next service function.
>> >>
>> >> Linda
>> >>
>> >> > -----Original Message-----
>> >> > From: [email-masked] [mailto:[email-masked]] On 
>> >> > Behalf Of Ron Parker
>> >> > Sent: Tuesday, November 12, 2013 8:16 AM
>> >> > To: Hongyu Li (Julio); Kevin J Ma
>> >> > Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); 
>> >> > Sumandra Majee
>> >> > Subject: Re: [nsc] Current Proposed SFC charter
>> >> >
>> >> > Hongyu,
>> >> >
>> >> > I agree completely that re-classification is not limited to DPI.
>> >> >
>> >> > And also, that an area for us to explore as a group is how to
>> >>represent
>> >> > the service graph.   Do we want to represent it as a proper graph
>> with
>> >> > an adjacency list or other representational model?   Or, do we want
>> to
>> >> > represent it as a set of linear segments and if so, how are the
>> >> > segments connected into a graph?   Other ideas?
>> >> >
>> >> >    Ron
>> >> >
>> >> >
>> >> > -----Original Message-----
>> >> > From: [email-masked] [mailto:[email-masked]] On 
>> >> > Behalf Of Hongyu Li (Julio)
>> >> > Sent: Tuesday, November 12, 2013 6:57 AM
>> >> > To: Ron Parker; Kevin J Ma
>> >> > Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); 
>> >> > Sumandra Majee
>> >> > Subject: Re: [nsc] Current Proposed SFC charter
>> >> >
>> >> > Branching/forking is a very interesting topic of SFC. About the
>> >> > re- classification point, probably we shall not limit it to DPI.
>> >> > It is also possible that packets go to different branches after 
>> >> > been processed by a certain service function, decision of which 
>> >> > branches to go is made based on the result of service function's 
>> >> > process, i.e. not just re- classification by DPI.
>> >> >
>> >> > Hongyu
>> >> >
>> >> > -----Original Message-----
>> >> > From: [email-masked] [mailto:[email-masked]] On 
>> >> > Behalf Of Ron Parker
>> >> > Sent: Tuesday, November 12, 2013 7:45 PM
>> >> > To: Kevin J Ma
>> >> > Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); 
>> >> > Sumandra Majee
>> >> > Subject: Re: [nsc] Current Proposed SFC charter
>> >> >
>> >> > Hi, Kevin
>> >> >
>> >> > You ask a great question about branching the graph.  The details 
>> >> > around how to convey the selection of the subtree/subgraph are 
>> >> > still
>> >>to be
>> >> > defined.   Is it one chain id for the whole graph?   Does each
>>branch
>> >> > have its own chain id?   Some combination?
>> >> >
>> >> >    Ron
>> >> >
>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma"
>> >> > <[email-masked]>
>> >> > wrote:
>> >> >
>> >> > >> Yes, reclassification can change the service path and 
>> >> > >> re-classification may happen at any node along a service path.
>> >> > >
>> >> > > Just to expand on that, going back to the original question 
>> >> > > about service header encapsulation, is it intended that a 
>> >> > > chain that is re-classified will get a new chain ID which 
>> >> > > fully describes a chain that is a superset of the original 
>> >> > > chain ID, prior to DPI-based re-classification?  (assuming the 
>> >> > > goal is "a single chain ID that is commonly understood along 
>> >> > > the entire service
>> chain"
>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html
>> >> > > )
>> >> > >
>> >> > > And the applicable subset of the permutative list of service 
>> >> > > paths would be configured at each appropriate service node?
>> >> > > e.g., ID 1: NAT + firewall + DPI
>> >> > >      ID 2: NAT + firewall + DPI + AV
>> >> > >      ID 3: NAT + firewall + DPI + AV + NAT
>> >> > >      ID 4: NAT + firewall + DPI + NAT
>> >> > >      ID 5: NAT + firewall + DPI + AV + LB
>> >> > >      ID 6: NAT + firewall + DPI + LB
>> >> > >      ID 7: NAT + firewall + DPI + LB + CACHE
>> >> > >      ID 8: NAT + firewall + DPI + CACHE
>> >> > >      ID 9: NAT + firewall + DPI + optimizer + LB
>> >> > >      ID 10: NAT + firewall + DPI + optimizer + LB + CACHE
>> >> > >      ID 11: NAT + firewall + DPI + optimizer + CACHE Would 
>> >> > > every flow then be initially classified as ID 1, but 
>> >> > > eventually get re-
>> >> > classified
>> >> > > to ID 2-11, after the DPI phase?
>> >> > >
>> >> > > thanx.
>> >> > >
>> >> > > --  Kevin J. Ma
>> >> > >
>> >> > >> -----Original Message-----
>> >> > >> From: Surendra Kumar (smkumar) [mailto:[email-masked]]
>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM
>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; 
>> >> > >> [email-masked]
>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" 
>> >> > >>> <[email-masked]>
>> >>wrote:
>> >> > >>>
>> >> > >>> Hi Surendra,
>> >> > >>>
>> >> > >>> Classification may be out of scope, but the level of service 
>> >> > >>> that
>> >> > is
>> >> > >>> applicable is dependent upon the level of classification 
>> >> > >>> that can
>> >> > be
>> >> > >>> performed.  An assumption of packet level encapsulation has
>> >> > >> implications
>> >> > >>> on the level of classification being performed?  If the 
>> >> > >>> stated
>> >> > goals
>> >> > >> are
>> >> > >>> for firewall and load balancer functionality, then the 
>> >> > >>> application
>> >> > >> level
>> >> > >>> nature of those functions needs to be taken into account?
>> >> > >>> If, on the other hand, the service function scope is limited 
>> >> > >>> due to limitations in classification, that would be and 
>> >> > >>> important piece of
>> >> > information?
>> >> > >>>
>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the 
>> >> > >>> fork points of the service paths seem like re-classification
>> points?
>> >> > >>> Is that the interpretation from the architecture perspective?
>> >> > >>> Or is the service function chain classification exclusive of 
>> >> > >>> DPI
>> >> > functionality?
>> >> > >> <SK> I have not fully read that draft yet. But in general, as 
>> >> > >> described in the arch draft, the collection of services form 
>> >> > >> a graph, segments of which are service paths. Yes, 
>> >> > >> reclassification can
>> >> > change
>> >> > >> the service path and re-classification may happen at any node 
>> >> > >> along
>> >> > a service path.
>> >> > >>
>> >> > >> Surendra.
>> >> > >>>
>> >> > >>> thanx.
>> >> > >>>
>> >> > >>> --  Kevin J. Ma
>> >> > >>>
>> >> > >>>> -----Original Message-----
>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:[email-masked]]
>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM
>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; 
>> >> > >>>> [email-masked]
>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter
>> >> > >>>>
>> >> > >>>> Kevin,
>> >> > >>>>
>> >> > >>>> Classification mechanism is outside the scope of SFC. It 
>> >> > >>>> can be based
>> >> > >> on
>> >> > >>>> the packet or information not in the packet(environmental 
>> >> > >>>> attributes
>> >> > >> for
>> >> > >>>> instance) or a combination thereof. What is important is 
>> >> > >>>> that such classification aids in traffic selection and 
>> >> > >>>> service path identification.
>> >> > >>>> It is no different from a policy in this regard except that 
>> >> > >>>> the policy now specifies the service path.
>> >> > >>>> Further, classification is not limited to the network 
>> >> > >>>> elements but the service functions as well. Some of this is 
>> >> > >>>> described in the
>> >> > >> architecture
>> >> > >>>> drafts as well -
>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/".
>> >> > >>>>
>> >> > >>>> Surendra.
>> >> > >>>>
>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma"
>> >> > >>>>> <[email-masked]>
>> >> > wrote:
>> >> > >>>>>
>> >> > >>>>> Hi Ron,
>> >> > >>>>>
>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with 
>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in 
>> >> > >>>>> section
>> >> > >>>>> 2 of the
>> >> > problem
>> >> > >>>>> statement:
>> >> > >>>>>
>> >> > >>>>>   11.  Per-Service (re)Classification: Classification 
>> >> > >>>>> occurs at
>> >> > each
>> >> > >>>>>        service, independent from previously applied 
>> >> > >>>>> service
>> >> > >>>> functions.
>> >> > >>>>>        These unrelated classification events consume 
>> >> > >>>>> resources
>> >> > per
>> >> > >>>>>        service.  More importantly, the classification
>> >> > functionality
>> >> > >>>>>        often differs per service function and service 
>> >> > >>>>> function
>> >> > >> cannot
>> >> > >>>>>        leverage the results from other deployed network or
>> >> > service.
>> >> > >>>>>
>> >> > >>>>> as it relates to section 5.2 of the framework document:
>> >> > >>>>>
>> >> > >>>>>   The SFC Classifier classifies packets based on (some of) 
>> >> > >>>>> the
>> >> > >>>> contents
>> >> > >>>>>   of the packet header.  Concretely, it classifies packets 
>> >> > >>>>> based on
>> >> > >>>> the
>> >> > >>>>>   possible combination of one or more header fields, such 
>> >> > >>>>> as
>> >> > source
>> >> > >>>>>   address, destination address, DS field, protocol ID, 
>> >> > >>>>> source
>> >> > port
>> >> > >>>> and
>> >> > >>>>>   destination port numbers, and any other information.
>> >> > >>>>>
>> >> > >>>>> A packet-based classifier as described in the framework 
>> >> > >>>>> document
>> >> > >>>> would
>> >> > >>>>> seem to be limited in what it can classify?  The service 
>> >> > >>>>> function identifier lookup does not seem to be a 
>> >> > >>>>> significant optimization
>> >> > >> over
>> >> > >>>>> a packet-based 5-tuple lookup?  There seems to be some 
>> >> > >>>>> missing
>> >> > >> detail
>> >> > >>>>> wrt how classification information is determined and reused?
>> >> > >>>>>
>> >> > >>>>> When thinking about higher level services, e.g., HTTP and 
>> >> > >>>>> TLS
>> >> > >>>> encrypted
>> >> > >>>>> flows, a packet-based classifier seems inadequate?  I was 
>> >> > >>>>> also
>> >> > >>>> wondering
>> >> > >>>>> how independent HLS segment requests might be classified 
>> >> > >>>>> and
>> >> > >>>> associated?
>> >> > >>>>> Were these types of use cases discussed in the BoF?
>> >> > >>>>>
>> >> > >>>>> thanx.
>> >> > >>>>>
>> >> > >>>>> --  Kevin J. Ma
>> >> > >>>>>
>> >> > >>>>>> -----Original Message-----
>> >> > >>>>>> From: [email-masked] [mailto:[email-masked]] 
>> >> > >>>>>> On Behalf
>> >> > >> Of
>> >> > >>>>>> Ron
>> >> > >>>>>> Parker
>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM
>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; [email-masked]
>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter
>> >> > >>>>>>
>> >> > >>>>>> Sumandra,
>> >> > >>>>>>
>> >> > >>>>>> As was discussed in Vancouver, there are already many 
>> >> > >>>>>> existing ways
>> >> > >>>> to
>> >> > >>>>>> accomplish service chaining.     But none of them provide a
>> >> > >>>> sufficient
>> >> > >>>>>> combination of interoperability, flexibility, and
>>resiliency.
>> >> > A
>> >> > >>>> single
>> >> > >>>>>> service chain encapsulation will go a long way to 
>> >> > >>>>>> ensuring these
>> >> > >>>> goals.
>> >> > >>>>>> It  may not be the absolutely most efficient approach for 
>> >> > >>>>>> every
>> >> > >>>> single
>> >> > >>>>>> network topology and every single use case, but its 
>> >> > >>>>>> ubiquitous
>> >> > >> nature
>> >> > >>>>>> should improve its adoption.
>> >> > >>>>>>
>> >> > >>>>>>   Ron
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>> -----Original Message-----
>> >> > >>>>>> From: Sumandra Majee [mailto:[email-masked]]
>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM
>> >> > >>>>>> To: Ron Parker; Thomas Narten; [email-masked]
>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter
>> >> > >>>>>>
>> >> > >>>>>> Ron,
>> >> > >>>>>>
>> >> > >>>>>> Absolutely, that was an example of one type of derivation.
>> >> > >>>>>> However
>> >> > >>>> this
>> >> > >>>>>> could be augmented with classification result, again one 
>> >> > >>>>>> more
>> >> > >>>> example.
>> >> > >>>>>>
>> >> > >>>>>>>> All flows from the same source IP do not necessarily 
>> >> > >>>>>>>> follow
>> >> > the
>> >> > >>>> same
>> >> > >>>>>> chain.
>> >> > >>>>>> Correct. It is also not necessary that all transaction of 
>> >> > >>>>>> the same
>> >> > >>>> flow
>> >> > >>>>>> follow the same chain either. So why stop at flow itself.
>> >> > >>>>>>
>> >> > >>>>>> Again the point here is that do we always need SFC header 
>> >> > >>>>>> or
>> >>Not.
>> >> > >>>>>>
>> >> > >>>>>> Sumandra
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>> -----Original Message-----
>> >> > >>>>>> From: Ron Parker [mailto:[email-masked]]
>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM
>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; [email-masked]
>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter
>> >> > >>>>>>
>> >> > >>>>>> Sumandra,
>> >> > >>>>>>
>> >> > >>>>>> The intention of service function chaining is to allow 
>> >> > >>>>>> for operation
>> >> > >>>> at
>> >> > >>>>>> the fully qualified flow level, or even finer grained at 
>> >> > >>>>>> the
>> >> > >>>> transaction
>> >> > >>>>>> level (this is an implementation matter for the PDP).
>>All
>> >> > flows
>> >> > >>>> from
>> >> > >>>>>> the same source IP do not necessarily follow the same chain.
>> >> > >> Source
>> >> > >>>>>> IP,
>> >> > >>>>>> therefore,  does not identify the chain ID.    Another
>> >>intention
>> >> > of
>> >> > >>>>>> service function chaining is to operate over any network
>> >> > topology
>> >> > >> and
>> >> > >>>>>> not
>> >> > >>>>>> be limited to a single LAN.   Thus, while VLAN may be part
>>of
>> >> > the
>> >> > >>>>>> transport, it does not adequately identify the service 
>> >> > >>>>>> chain,
>> >> > >> either.
>> >> > >>>>>>
>> >> > >>>>>>   Ron
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>> -----Original Message-----
>> >> > >>>>>> From: Sumandra Majee [mailto:[email-masked]]
>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM
>> >> > >>>>>> To: Ron Parker; Thomas Narten; [email-masked]
>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter
>> >> > >>>>>>
>> >> > >>>>>> Ron,
>> >> > >>>>>>
>> >> > >>>>>> The service header is meant to carry the context which 
>> >> > >>>>>> can
>> >> > *also*
>> >> > >>>>>> be derived (for example use source ip and vlan to 
>> >> > >>>>>> identify chainID and
>> >> > >>>>>> position) or encapsulated as part of another tunnel header.
>> >> > >>>>>> So this could be optional IMHO.
>> >> > >>>>>>
>> >> > >>>>>> -----Original Message-----
>> >> > >>>>>> From: Ron Parker [mailto:[email-masked]]
>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM
>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; [email-masked]
>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter
>> >> > >>>>>>
>> >> > >>>>>> Sumandra,
>> >> > >>>>>>
>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to 
>> >> > >>>>>> SF or from
>> >> > >>>> SF
>> >> > >>>>>> to
>> >> > >>>>>> SF will look like:
>> >> > >>>>>>
>> >> > >>>>>> +------------------------+
>> >> > >>>>>> |        "transport"         |
>> >> > >>>>>> +------------------------+
>> >> > >>>>>> |      service header    |
>> >> > >>>>>> +------------------------+
>> >> > >>>>>> |   original IP header  |
>> >> > >>>>>> +------------------------+
>> >> > >>>>>> |                                         |  original IP 
>> >> > >>>>>> | payload
>> >> > |
>> >> > >>>>>> |                                         |
>> >> > >>>>>> +------------------------+
>> >> > >>>>>>
>> >> > >>>>>> Where service header contains, at a minimum, enough 
>> >> > >>>>>> information to
>> >> > >>>> allow
>> >> > >>>>>> the packet to be propagated along the full length of the 
>> >> > >>>>>> chain, and optionally, other metadata that enhances the 
>> >> > >>>>>> operation of
>> >> > one
>> >> > >>>>>> or
>> >> > >> more
>> >> > >>>>>> service functions.
>> >> > >>>>>>
>> >> > >>>>>> And where "transport" could conceivably be any of, but 
>> >> > >>>>>> not limited
>> >> > >>>> to:
>> >> > >>>>>>
>> >> > >>>>>> * Ethernet
>> >> > >>>>>> * Ethernet + LLC2
>> >> > >>>>>> * Ethernet + MPLS
>> >> > >>>>>> * Ethernet + IP + GRE
>> >> > >>>>>> * Ethernet + IP +UDP
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>> Also, "original" in the diagram above is not meant to 
>> >> > >>>>>> imply immutability, but rather to specify the packet that 
>> >> > >>>>>> is
>> >> > propagated
>> >> > >>>>>> from preceding entity to succeeding entity, prior to 
>> >> > >>>>>> encapsulation.
>> >> > >>>>>>
>> >> > >>>>>>   Ron
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>> -----Original Message-----
>> >> > >>>>>> From: [email-masked] [mailto:[email-masked]] 
>> >> > >>>>>> On Behalf
>> >> > >> Of
>> >> > >>>>>> Sumandra Majee
>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM
>> >> > >>>>>> To: Thomas Narten; [email-masked]
>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter
>> >> > >>>>>>
>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A 
>> >> > >>>>>> document
>> >>will
>> >> > >>>>>>    describe the single service-level data plane 
>> >> > >>>>>> encapsulation
>> >> > >> format
>> >> > >>>>>> for
>> >> > >>>>>>    conveying the service function chain and the service 
>> >> > >>>>>> function
>> >> > >>>> path,
>> >> > >>>>>>    and for communicating context information between 
>> >> > >>>>>> nodes
>> that
>> >> > >>>>>>    implement service functions. It is intended that the
>> >> > >>>> encapsulation
>> >> > >>>>>>    be agnostic to the layer at which it is applied and 
>> >> > >>>>>> the service
>> >> > >>>> that
>> >> > >>>>>> is
>> >> > >>>>>>    being constructed. That is, the same encapsulation may 
>> >> > >>>>>> be
>> >> > used
>> >> > >> on
>> >> > >>>>>>    a service function path realized at the network layer 
>> >> > >>>>>> or at any other
>> >> > >>>>>>    layer, and the same encapsulation will apply for the
>> >> > >> construction
>> >> > >>>> of
>> >> > >>>>>>    service function paths regardless of the actual service.
>> >> > >>>>>>
>> >> > >>>>>> [SM] What does it mean by a single service-level 
>> >> > >>>>>> encapsulation,
>> >> > a
>> >> > >>>> new
>> >> > >>>>>> encapsulation format
>> >> > >>>>>>            or an ability to select one encapsulation 
>> >> > >>>>>> format that
>> >> > >>>> fits
>> >> > >>>>>> the
>> >> > >>>>>> need for a given service chain?
>> >> > >>>>>>           The ability to select a specific encapsulation 
>> >> > >>>>>> would be
>> >> > >> a
>> >> > >>>>>> management plane decision.
>> >> > >>>>>>          There are quite a few existing encapsulation 
>> >> > >>>>>> methods that
>> >> > >>>> can
>> >> > >>>>>> possibly be reused to provide
>> >> > >>>>>>          context information between   service nodes. I have
>> >> > seen
>> >> > >>>>>> mention
>> >> > >>>>>> of GRE, for HTTP based
>> >> > >>>>>>          applications contexts are transferred via headers.
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>> -----Original Message-----
>> >> > >>>>>> From: [email-masked] [mailto:[email-masked]] 
>> >> > >>>>>> On Behalf
>> >> > >> Of
>> >> > >>>>>> Thomas Narten
>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM
>> >> > >>>>>> To: [email-masked]
>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter
>> >> > >>>>>>
>> >> > >>>>>> Hi.
>> >> > >>>>>>
>> >> > >>>>>> Current charter can be found at
>> >> > >>>>>> https://datatracker.ietf.org/doc/charter-
>> >> > >>>>>> ietf-sfc/.
>> >> > >>>>>>
>> >> > >>>>>> It contains the revised management text as well as 
>> >> > >>>>>> updated
>> >> > >>>> milestones.
>> >> > >>>>>>
>> >> > >>>>>> All known issues have been addressed. If there are any 
>> >> > >>>>>> remaining
>> >> > >>>> issues,
>> >> > >>>>>> please speak up!
>> >> > >>>>>>
>> >> > >>>>>> Charter charter-ietf-sfc-00-04
>> >> > >>>>>>
>> >> > >>>>>> Networks, servers, storage technologies, and 
>> >> > >>>>>> applications, have all undergone significant change in 
>> >> > >>>>>> recent years with the introduction
>> >> > >> of
>> >> > >>>>>> virtualization, network overlays, and orchestration.
>> >> > >>>>>> Service
>> >> > >> delivery
>> >> > >>>> is
>> >> > >>>>>> currently both a technical and organizational challenge 
>> >> > >>>>>> that
>> >> > >> involves
>> >> > >>>>>> significant modification to the network configuration.
>> >> > >>>>>> Services are typically implemented by the ordered 
>> >> > >>>>>> combination of a number of service functions that are 
>> >> > >>>>>> deployed at different points within
>> >> > >> the
>> >> > >>>>>> network. Today, a common deployment model has service 
>> >> > >>>>>> functions physically inserted on the data forwarding path 
>> >> > >>>>>> between communicating peers.
>> >> > >>>> Going
>> >> > >>>>>> forward, however, there is a desire to move to a 
>> >> > >>>>>> different model,
>> >> > >>>> where
>> >> > >>>>>> service functions are not required to reside on the 
>> >> > >>>>>> default data
>> >> > >> path
>> >> > >>>>>> and
>> >> > >>>>>> traffic is instead steered through services, wherever 
>> >> > >>>>>> they are
>> >> > >>>> deployed.
>> >> > >>>>>>
>> >> > >>>>>> For a given service, the abstracted view of the required 
>> >> > >>>>>> service functions and the order in which they are to be 
>> >> > >>>>>> applied is
>> >> > called
>> >> > >>>>>> a Service Function Chain (SFC). Since a given service 
>> >> > >>>>>> function may be available on more than one node within a 
>> >> > >>>>>> network, a Service Function Chain is instantiated
>> >> > >>>> via
>> >> > >>>>>> the selection of specific service function instances and 
>> >> > >>>>>> the network nodes on which they are provided, thereby 
>> >> > >>>>>> forming a service topology:
>> >> > >>>>>> this is called a Service Function Path. The service 
>> >> > >>>>>> functions
>> >> > may
>> >> > >>>>>> be applied at a specific layer within the network 
>> >> > >>>>>> protocol stack
>> >> > >>>> (network
>> >> > >>>>>> layer, application layer, etc.).
>> >> > >>>>>>
>> >> > >>>>>> The Service Function Chaining (SFC) working group will 
>> >> > >>>>>> develop new approaches to service delivery and deployment.
>> >> > >>>>>> It will produce a framework for service function chaining 
>> >> > >>>>>> that includes the necessary protocols
>> >> > >>>> or
>> >> > >>>>>> protocol extensions to convey the service path and 
>> >> > >>>>>> service path information to nodes that implement service 
>> >> > >>>>>> functions, as well
>> >> > as
>> >> > >>>>>> mechanisms for steering traffic through service functions.
>> >> > >>>>>> The
>> >> > >>>> working
>> >> > >>>>>> group will also examine what information needs to be 
>> >> > >>>>>> gathered from
>> >> > >>>> the
>> >> > >>>>>> network and service functions in support of service 
>> >> > >>>>>> function
>> >> > >> chaining
>> >> > >>>>>> and
>> >> > >>>>>> how that information may be made available to nodes that 
>> >> > >>>>>> implement
>> >> > >>>> the
>> >> > >>>>>> service functions.
>> >> > >>>>>>
>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the
>> following:
>> >> > >>>>>>
>> >> > >>>>>> 1) Problem Statement: This document will provide a 
>> >> > >>>>>> summary of
>> >> > the
>> >> > >>>>>>    problem space to be addressed by the WG including 
>> >> > >>>>>> example
>> >> > high-
>> >> > >>>>>>    level use cases. Additionally, the WG will normalize
>> >> > >> nomenclature
>> >> > >>>>>>    and definitions for service function chaining.
>> >> > >>>>>>
>> >> > >>>>>> 2) Architecture: This document will provide a description 
>> >> > >>>>>> of
>> >>the
>> >> > >>>>>>    architectural building blocks and their relationships
>> >> > including
>> >> > >>>>>>    interconnection, placement of capabilities, management,
>> >> > >>>>>>    diagnostics, design analysis, and security models, as 
>> >> > >>>>>> well
>> >>as
>> >> > >>>>>>    requirements on the protocol mechanisms.
>> >> > >>>>>>
>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A 
>> >> > >>>>>> document
>> >> > will
>> >> > >>>>>>    describe the single service-level data plane 
>> >> > >>>>>> encapsulation
>> >> > >> format
>> >> > >>>>>> for
>> >> > >>>>>>    conveying the service function chain and the service 
>> >> > >>>>>> function
>> >> > >>>> path,
>> >> > >>>>>>    and for communicating context information between 
>> >> > >>>>>> nodes
>> that
>> >> > >>>>>>    implement service functions. It is intended that the
>> >> > >>>> encapsulation
>> >> > >>>>>>    be agnostic to the layer at which it is applied and 
>> >> > >>>>>> the service
>> >> > >>>> that
>> >> > >>>>>> is
>> >> > >>>>>>    being constructed. That is, the same encapsulation may 
>> >> > >>>>>> be
>> >> > used
>> >> > >> on
>> >> > >>>>>>    a service function path realized at the network layer 
>> >> > >>>>>> or at any other
>> >> > >>>>>>    layer, and the same encapsulation will apply for the
>> >> > >> construction
>> >> > >>>> of
>> >> > >>>>>>    service function paths regardless of the actual service.
>> >> > >>>>>>
>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be
>> >> > developed to
>> >> > >>>>>>    describe requirements and protocols necessary to 
>> >> > >>>>>> convey
>> >> > >>>> information
>> >> > >>>>>>    to service function implementation points. Where 
>> >> > >>>>>> possible,
>> >> > >>>> existing
>> >> > >>>>>>    IETF protocols will be used and extended. All protocol
>> >> > >> extensions
>> >> > >>>>>>    work should be carried out in the working groups 
>> >> > >>>>>> responsible for
>> >> > >>>> the
>> >> > >>>>>>    protocols being modified in coordination with this 
>> >> > >>>>>> working
>> >> > >> group,
>> >> > >>>>>> but
>> >> > >>>>>>    may be done in this working group after agreement with 
>> >> > >>>>>> all
>> >> > the
>> >> > >>>>>>    relevant WG chairs and responsible ADs.
>> >> > >>>>>>
>> >> > >>>>>> 5) Manageability: Work on the management and 
>> >> > >>>>>> configuration of
>> >> > >> service
>> >> > >>>>>>    functions in support of SFC components will certainly 
>> >> > >>>>>> be
>> >> > needed,
>> >> > >>>>>>    but first needs to be better understood and scoped.
>> >> > >>>>>>
>> >> > >>>>>> Proposed Milestones
>> >> > >>>>>>
>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s) 
>> >> > >>>>>> defining the
>> >> > >>>> problem
>> >> > >>>>>> statement and core use cases for Service Function 
>> >> > >>>>>> Chaining
>> >> > >>>>>>
>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter 
>> >> > >>>>>> modifications for management and configuration of SFC 
>> >> > >>>>>> components
>> >> > >>>>>>
>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining 
>> >> > >>>>>> the
>> >> > >>>> architecture
>> >> > >>>>>> for SFC
>> >> > >>>>>>
>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic 
>> >> > >>>>>> service function chaining encapsulation protocol
>> >> > >>>>>>
>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document 
>> >> > >>>>>> specifying the
>> >> > >>>> generic
>> >> > >>>>>> service function chaining header encapsulation
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>>
>> >> > >>>>>> Thomas
>> >> > >>>>>>
>> >> > >>>>>> _______________________________________________
>> >> > >>>>>> nsc mailing list
>> >> > >>>>>> [email-masked]
>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc
>> >> > >>>>>> _______________________________________________
>> >> > >>>>>> nsc mailing list
>> >> > >>>>>> [email-masked]
>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc
>> >> > >>>>>> _______________________________________________
>> >> > >>>>>> nsc mailing list
>> >> > >>>>>> [email-masked]
>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc
>> >> > >>>>> _______________________________________________
>> >> > >>>>> nsc mailing list
>> >> > >>>>> [email-masked]
>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc
>> >> > >
>> >> > _______________________________________________
>> >> > nsc mailing list
>> >> > [email-masked]
>> >> > https://www.ietf.org/mailman/listinfo/nsc
>> >> > _______________________________________________
>> >> > nsc mailing list
>> >> > [email-masked]
>> >> > https://www.ietf.org/mailman/listinfo/nsc
>> >> > _______________________________________________
>> >> > nsc mailing list
>> >> > [email-masked]
>> >> > https://www.ietf.org/mailman/listinfo/nsc
>>
>> _______________________________________________
>> nsc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nsc
>_______________________________________________
>nsc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nsc

_______________________________________________
nsc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsc

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Wed, 13 Nov 2013 10:12:02 +0000

May I suggest summary of my views here:

1. Branch is a sort of use case or scenario, while reclassification is a way to solve the problem.
2. Service Functions should be decoupled with the chain itself.
	Meaning, a SF shall not *directly* impact the forwarding of packets in a chain. Branching should be performed by chain forwarding nodes, possibly under control of a control node. The reason for this is in NFV world, service functions may come from a third party, while chain is provided by the infrastructure of the network. There must be a cushion avoiding a service function operating infrastructure directly.
3. (Re)classification is based on info in a packet.
	This is very general. Such info could be L2~L7 derived from a user's packet, as well as some info like metadata in a SFC header. As classification is out of scope of SFC, we don't have to provide too much details of how to do classification.
4. Chain segments stitching is relatively a easy way for branching. Compared with chains and subchains, which may require a more complex header and forwarding capabilities.

My two cents.
Hongyu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, November 13, 2013 3:04 AM
To: [email-masked]
Subject: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

Hi:

---

From: David Allan I <[email-masked]>
Date: Wed, 13 Nov 2013 15:45:16 +0000

HI Hongyu:

I think we will have scenarios where a service function appears in more than one chain, as would be the case, for example, if some flows could dynamically bypass DPI but still needed to transit a common set of stateful service functions...

Once you postulate a service function instance appearing in more than one chain, it seems artificially restrictive not to permit such a function to also implement branching, all the control structures would already be there.

Rgds
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, November 13, 2013 3:04 AM
To: [email-masked]
Subject: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

Hi:

---

From: Niulehong <[email-masked]>
Date: Thu, 14 Nov 2013 01:29:34 +0000

Hi David,

Service function instance serving multiple service chains is different from the branching function.

For the former , packet’s path id( service chaining id) field of the service chaining header is not changed while whole specific service chain’s packets passing through the service function. That likes parallel railways path through the railway station.

For the later,  after service function processing, packets belongs to the same service chain will be changed about their common path id value to several different path id values according the service function’s decision. That likes one railway forks several railways after the railway station.

Best Regards

Lehong Niu

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 David Allan I
发送时间: 2013年11月13日 23:45
收件人: Hongyu Li (Julio); [email-masked]
主题: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

HI Hongyu:

Rgds

Dave

-----Original Message-----

To: David Allan I; [email-masked]<mailto:[email-masked]>

My two cents.

Hongyu

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of David Allan I

To: [email-masked]<mailto:[email-masked]>

Hi:

Dave

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of David Lake (dlake)

Cc: Thomas Narten; [email-masked]<mailto:[email-masked]>; Sumandra Majee

-----Original Message-----

Cc: Thomas Narten; [email-masked]<mailto:[email-masked]>; Sumandra Majee

>Cc: Thomas Narten; [email-masked]<mailto:[email-masked]>; Sumandra Majee

>> Cc: Thomas Narten; [email-masked]<mailto:[email-masked]>; Sumandra Majee

>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of

>> Cc: Thomas Narten; [email-masked]<mailto:[email-masked]>; Sumandra Majee

>> On 11/12/13 7:53 AM, "Ron Parker" <[email-masked]<mailto:[email-masked]>>

>> >Cc: Thomas Narten; [email-masked]<mailto:[email-masked]>; Surendra Kumar (smkumar); Sumandra

>> >> Cc: Thomas Narten; [email-masked]<mailto:[email-masked]>; Surendra Kumar (smkumar);

>> >> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On

>> >> > Cc: Thomas Narten; [email-masked]<mailto:[email-masked]>; Surendra Kumar (smkumar);

>> >> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On

>> >> > Cc: Thomas Narten; [email-masked]<mailto:[email-masked]>; Surendra Kumar (smkumar);

>> >> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On

>> >> > Cc: Thomas Narten; [email-masked]<mailto:[email-masked]>; Surendra Kumar (smkumar);

>> >> > <[email-masked]<mailto:[email-masked]>>

>> >> > >> [email-masked]<mailto:[email-masked]>

>> >> > >>> <[email-masked]<mailto:[email-masked]>>

>> >> > >>>> [email-masked]<mailto:[email-masked]>

>> >> > >>>>> <[email-masked]<mailto:[email-masked]>>

>> >> > >>>>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; [email-masked]<mailto:[email-masked]>

>> >> > >>>>>> To: Ron Parker; Thomas Narten; [email-masked]<mailto:[email-masked]>

>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; [email-masked]<mailto:[email-masked]>

>> >> > >>>>>> To: Ron Parker; Thomas Narten; [email-masked]<mailto:[email-masked]>

>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; [email-masked]<mailto:[email-masked]>

>> >> > >>>>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

>> >> > >>>>>> To: Thomas Narten; [email-masked]<mailto:[email-masked]>

>> >> > >>>>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

>> >> > >>>>>> To: [email-masked]<mailto:[email-masked]>

>> >> > >>>>>> [email-masked]<mailto:[email-masked]>

>> >> > >>>>>> [email-masked]<mailto:[email-masked]>

>> >> > >>>>>> [email-masked]<mailto:[email-masked]>

>> >> > >>>>> [email-masked]<mailto:[email-masked]>

>> >> > [email-masked]<mailto:[email-masked]>

>> >> > [email-masked]<mailto:[email-masked]>

>> >> > [email-masked]<mailto:[email-masked]>

>> [email-masked]<mailto:[email-masked]>

>[email-masked]<mailto:[email-masked]>

nsc mailing list

[email-masked]<mailto:[email-masked]>

nsc mailing list

[email-masked]<mailto:[email-masked]>

nsc mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Thu, 14 Nov 2013 02:29:49 +0000

Hi Dave,

Your inferred restriction may be not always true. In general, service functions should be able to compose a chain arbitrarily. Particularly for branching, as I suggested in previous email, service function shall not directly impact packet forwarding. This precludes the restriction you mentioned. Forwarding plane can decide whether a branching action should be taken by reclassification or not per service chain.

Does this make sense?

Hongyu

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: Wednesday, November 13, 2013 11:45 PM
To: Hongyu Li (Julio); [email-masked]
Subject: RE: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

HI Hongyu:

Rgds
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, November 13, 2013 3:04 AM
To: [email-masked]
Subject: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

Hi:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 14 Nov 2013 07:46:31 -0500

You assert in the below text that "service functions should be able to 
compose a chain arbitrarily."
That does not seem to follow.
The operator defines the service chains they want.  They provision those 
service chains.
Thus, I would expect that the job of a service function is to deliver 
its specific service.  In general, it should not need to know or care 
about the chains in which it is participating.

Yours,
Joel M. Halpern

On 11/13/13 9:29 PM, Hongyu Li (Julio) wrote:
> Hi Dave,
>
> Your inferred restriction may be not always true. In general, service
> functions should be able to compose a chain arbitrarily. Particularly
> for branching, as I suggested in previous email, service function
> shall not directly impact packet forwarding. This precludes the
> restriction you mentioned. Forwarding plane can decide whether a
> branching action should be taken by reclassification or not per
> service chain.
>
> Does this make sense?
>
> Hongyu
>
> -----Original Message----- From: David Allan I
> [mailto:[email-masked]] Sent: Wednesday, November 13,
> 2013 11:45 PM To: Hongyu Li (Julio); [email-masked] Subject: RE: [nsc]
> FW: re classification & branching, was: Current Proposed SFC charter
>
> HI Hongyu:
>
> I think we will have scenarios where a service function appears in
> more than one chain, as would be the case, for example, if some flows
> could dynamically bypass DPI but still needed to transit a common set
> of stateful service functions...
>
> Once you postulate a service function instance appearing in more than
> one chain, it seems artificially restrictive not to permit such a
> function to also implement branching, all the control structures
> would already be there.
>
> Rgds Dave
>
> -----Original Message----- From: Hongyu Li (Julio)
> [mailto:[email-masked]] Sent: Wednesday, November 13, 2013 2:12
> AM To: David Allan I; [email-masked] Subject: RE: [nsc] FW: re
> classification & branching, was: Current Proposed SFC charter
>
> 1. Branch is a sort of use case or scenario, while reclassification
> is a way to solve the problem. 2. Service Functions should be
> decoupled with the chain itself. Meaning, a SF shall not *directly*
> impact the forwarding of packets in a chain. Branching should be
> performed by chain forwarding nodes, possibly under control of a
> control node. The reason for this is in NFV world, service functions
> may come from a third party, while chain is provided by the
> infrastructure of the network. There must be a cushion avoiding a
> service function operating infrastructure directly. 3.
> (Re)classification is based on info in a packet. This is very
> general. Such info could be L2~L7 derived from a user's packet, as
> well as some info like metadata in a SFC header. As classification is
> out of scope of SFC, we don't have to provide too much details of how
> to do classification. 4. Chain segments stitching is relatively a
> easy way for branching. Compared with chains and subchains, which may
> require a more complex header and forwarding capabilities. My two
> cents. Hongyu
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of David Allan I Sent:
> Wednesday, November 13, 2013 3:04 AM To: [email-masked] Subject: [nsc]
> FW: re classification & branching, was: Current Proposed SFC charter
>
> Hi: (resend with recipient list cleaned up)
>
> Defining a flow subset can be a result of classification, but it is
> not the exclusive mechanism. Branching is a mechanism by which flow
> subsets are exposed and mapped to a set of subchains such that it can
> be identified in the dataplane...
>
> That's the view from here Dave
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of David Lake (dlake) Sent:
> Tuesday, November 12, 2013 10:51 AM To: Jim Guichard (jguichar);
> Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Linda Dunbar;
> Hongyu Li (Julio) Cc: Thomas Narten; [email-masked]; Sumandra Majee
> Understood - maybe just a little localised warming of the sea then ?
> But I still think we need to consider where and how policy is
> defined/set even for the single-domain instance.
>
> I don't think we can assume that any L1-3 device will be able to
> determine much useful information from the data-plane.
>
> -----Original Message----- From: Jim Guichard (jguichar) Sent: 12
> November 2013 10:44 To: David Lake (dlake); Kevin J Ma; Surendra
> Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio) Cc:
> Thomas Narten; [email-masked]; Sumandra Majee Subject: Re: [nsc]
> Current Proposed SFC charter
>
> As discussed during the BOF our initial work is single administrative
> domain for some of the very reasons you point out. We need to keep
> focused without trying to boil the ocean right off the bat.
>
>> I think we need a good understanding of a recursive policy
>> mechanism (recursive because a user-land application will ride with
>> a specific policy across potentially different sets of carrier
>> policies).
>>
>> multi-domain issue - if I set a policy as a user, chances are I
>> will be crossing several domain boundaries.  Are we expecting the
>> service headers to define the service chaining for the duration of
>> the entire flow across all domains, or just across a single one ?
>>
>> In which case, do I have to re-set policy as I traverse domains
>> and where does that policy get set ?   It would be much better to
>> set policy once based on L5-7 needs, and have that instantiated
>> across the multiple domains.
>>
>> Again, this appears to be outside the scope of SFC, but pretty
>> relevant to how it would operate in the real world.
>>
>> David
>>
>> -----Original Message----- From: Kevin J Ma
>> [mailto:[email-masked]] Sent: 12 November 2013 10:27 To:
>> David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda
>> Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; [email-masked]; Sumandra
>> Majee Subject: RE: [nsc] Current Proposed SFC charter
>>
>>> In those circumstances, only the end applications themselves or
>>> a reasonably broad-brushed classification (really traffic
>>> steering based on what we can see at ingress) is going to be
>>> useful - is THAT what we're aiming for here ?
>>
>>> -----Original Message----- From: David Lake (dlake)
>>> [mailto:[email-masked]] Sent: Tuesday, November 12, 2013 1:00
>>> PM To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda
>>> Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; [email-masked];
>>> Sumandra Majee Subject: RE: [nsc] Current Proposed SFC charter
>>>
>>> Policy may be outside of the scope of SFC, but without strong
>>> mapping between Policy and the inserted Service Header(s), we
>>> run-the-risk of limiting the efficacy of the protocol IMO.
>>>
>>> For example, in a world where the network has "gone dark," (as
>>> per the IETF Technical Plenary ?:-) ) what is our ability to
>>> determine policy based on DPI of packets-in-flight ?
>>>
>>> In those circumstances, only the end applications themselves or
>>> a reasonably broad-brushed classification (really traffic
>>> steering based on what we can see at ingress) is going to be
>>> useful - is THAT what we're aiming for here ?
>>>
>>> David
>>>
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Surendra Kumar
>>> (smkumar) Sent: 12 November 2013 09:26 To: Ron Parker; Kevin J
>>> Ma; Linda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten;
>>> [email-masked]; Sumandra Majee Subject: Re: [nsc] Current Proposed
>>> SFC charter
>>>
>>> Ron,
>>>
>>> Classification of traffic is well understood and we do not have
>>> to redefine it - it's been around for all the time middle boxes
>>> have been or for that matter the L2/L3 devices. All we are
>>> talking about is the applicability of the classification to
>>> branching in SFC.
>>>
>>> On 11/12/13 7:53 AM, "Ron Parker"
>>> <[email-masked]> wrote:
>>>
>>>> misunderstandings here.    A branch would occur for some
>>>> policy-driven reason based on the behavior and conclusions of
>>>> the service function, itself.   The graph would represent the
>>>> fact that there is a branch point, but the service function,
>>>> itself, being aware that it is a branching point would contain
>>>> the policy and logic to decide on which branch to take.
>>>> Specifying that policy and logic is out of scope,
>>> IMO.
>>>>
>>>> Ron
>>>>
>>>>
>>>> -----Original Message----- From: Kevin J Ma
>>>> [mailto:[email-masked]] Sent: Tuesday, November 12,
>>>> 2013 10:49 AM To: Linda Dunbar; Ron Parker; Hongyu Li (Julio)
>>>> Sumandra Majee Subject: RE: [nsc] Current Proposed SFC charter
>>>>
>>>> Hi Linda,
>>>>
>>>> reclassification point, or are you saying that a branching
>>>> point "does not have to be" a reclassification point?
>>>>
>>>> I think this is an important distinction that needs to be
>>>> clarified. If branching is never reclassification, then the
>>>> meaning of a chain is different than I originally inferred.  If
>>>> the chain is a tree with other "branching" points in it, then
>>>> that limits the scope of the problem statement goals.
>>>>
>>>> could define bad service chains, is it the intent of SFC to
>>>> only look at the simpler packet-level classification cases, or
>>>> is it the intent to consider the case where a branching point
>>>> is viewed as a re-classification point?
>>>>
>>>> thanx.
>>>>
>>>> --  Kevin J. Ma
>>>>
>>>>> -----Original Message----- From: Linda Dunbar
>>>>> [mailto:[email-masked]] Sent: Tuesday, November 12,
>>>>> 2013 10:34 AM To: Ron Parker; Hongyu Li (Julio); Kevin J Ma
>>>>> Sumandra Majee Subject: RE: [nsc] Current Proposed SFC
>>>>> charter
>>>>>
>>>>> Ron,
>>>>>
>>>>> First, want to make it clear that "branching" !=
>>>>> reclassification, agree?
>>>>>
>>>>> Second, the representation of branching (or service graph)
>>>>> can be in a form of logic on a service function. Some service
>>>>> functions, especially L7 based, can use value in a Database
>>>>> to determine what is the next service function.
>>>>>
>>>>> Linda
>>>>>
>>>>>> -----Original Message----- From: [email-masked]
>>>>>> [mailto:[email-masked]] On Behalf Of Ron Parker Sent:
>>>>>> Tuesday, November 12, 2013 8:16 AM To: Hongyu Li (Julio);
>>>>>> Kevin J Ma Cc: Thomas Narten; [email-masked]; Surendra Kumar
>>>>>> (smkumar); Sumandra Majee Subject: Re: [nsc] Current
>>>>>> Proposed SFC charter
>>>>>>
>>>>>> Hongyu,
>>>>>>
>>>>>> represent it as a set of linear segments and if so, how are
>>>>>> the segments connected into a graph?   Other ideas?
>>>>>>
>>>>>> Ron
>>>>>>
>>>>>>
>>>>>> -----Original Message----- From: [email-masked]
>>>>>> [mailto:[email-masked]] On Behalf Of Hongyu Li
>>>>>> (Julio) Sent: Tuesday, November 12, 2013 6:57 AM To: Ron
>>>>>> Parker; Kevin J Ma Cc: Thomas Narten; [email-masked];
>>>>>> Surendra Kumar (smkumar); Sumandra Majee Subject: Re: [nsc]
>>>>>> Current Proposed SFC charter
>>>>>>
>>>>>> Branching/forking is a very interesting topic of SFC. About
>>>>>> the re- classification point, probably we shall not limit
>>>>>> it to DPI. It is also possible that packets go to different
>>>>>> branches after been processed by a certain service
>>>>>> function, decision of which branches to go is made based on
>>>>>> the result of service function's process, i.e. not just re-
>>>>>> classification by DPI.
>>>>>>
>>>>>> Hongyu
>>>>>>
>>>>>> -----Original Message----- From: [email-masked]
>>>>>> [mailto:[email-masked]] On Behalf Of Ron Parker Sent:
>>>>>> Tuesday, November 12, 2013 7:45 PM To: Kevin J Ma Cc:
>>>>>> Thomas Narten; [email-masked]; Surendra Kumar (smkumar);
>>>>>> Sumandra Majee Subject: Re: [nsc] Current Proposed SFC
>>>>>> charter
>>>>>>
>>>>>> Hi, Kevin
>>>>>>
>>>>>> You ask a great question about branching the graph.  The
>>>>>> details around how to convey the selection of the
>>>>>> subtree/subgraph are still
>>>>> to be
>>>>>> <[email-masked]> wrote:
>>>>>>
>>>>>>> Just to expand on that, going back to the original
>>>>>>> question about service header encapsulation, is it
>>>>>>> intended that a chain that is re-classified will get a
>>>>>>> new chain ID which fully describes a chain that is a
>>>>>>> superset of the original chain ID, prior to DPI-based
>>>>>>> re-classification?  (assuming the goal is "a single chain
>>>>>>> ID that is commonly understood along the entire service
>>> chain"
)
>>>>>>>
>>>>>>> And the applicable subset of the permutative list of
>>>>>>> service paths would be configured at each appropriate
>>>>>>> service node? e.g., ID 1: NAT + firewall + DPI ID 2: NAT
>>>>>>> + firewall + DPI + AV ID 3: NAT + firewall + DPI + AV +
>>>>>>> NAT ID 4: NAT + firewall + DPI + NAT ID 5: NAT + firewall
>>>>>>> + DPI + AV + LB ID 6: NAT + firewall + DPI + LB ID 7: NAT
>>>>>>> + firewall + DPI + LB + CACHE ID 8: NAT + firewall + DPI
>>>>>>> + CACHE ID 9: NAT + firewall + DPI + optimizer + LB ID
>>>>>>> 10: NAT + firewall + DPI + optimizer + LB + CACHE ID 11:
>>>>>>> NAT + firewall + DPI + optimizer + CACHE Would every flow
>>>>>>> then be initially classified as ID 1, but eventually get
>>>>>>> re-
>>>>>> classified
>>>>>>>> -----Original Message----- From: Surendra Kumar
>>>>>>>> (smkumar) [mailto:[email-masked]] Sent: Tuesday,
>>>>>>>> November 12, 2013 1:01 AM To: Kevin J Ma; Ron Parker;
>>>>>>>> Sumandra Majee; Thomas Narten; [email-masked] Subject:
>>>>>>>> Re: [nsc] Current Proposed SFC charter
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Classification may be out of scope, but the level of
>>>>>>>>> service that
>>>>>> is
>>>>>>>>> applicable is dependent upon the level of
>>>>>>>>> classification that can
>>>>>> be
>>>>>>>>> on the level of classification being performed?  If
>>>>>>>>> the stated
>>>>>> goals
>>>>>>>> are
>>>>>>>>> for firewall and load balancer functionality, then
>>>>>>>>> the application
>>>>>>>> level
>>>>>>>>> nature of those functions needs to be taken into
>>>>>>>>> account? If, on the other hand, the service function
>>>>>>>>> scope is limited due to limitations in
>>>>>>>>> classification, that would be and important piece of
>>>>>> information?
>>>>>>>>>
>>>>>>>>> Wrt section 4.4 of
>>>>>>>>> draft-liu-service-chaining-use-cases the fork points
>>>>>>>>> of the service paths seem like re-classification
>>> points?
>>>>>>>>> Is that the interpretation from the architecture
>>>>>>>>> perspective? Or is the service function chain
>>>>>>>>> classification exclusive of DPI
>>>>>> functionality?
>>>>>>>> <SK> I have not fully read that draft yet. But in
>>>>>>>> general, as described in the arch draft, the collection
>>>>>>>> of services form a graph, segments of which are service
>>>>>>>> paths. Yes, reclassification can
>>>>>> change
>>>>>>>> the service path and re-classification may happen at
>>>>>>>> any node along
>>>>>> a service path.
>>>>>>>>
>>>>>>>> Surendra.
>>>>>>>>>
>>>>>>>>> thanx.
>>>>>>>>>
>>>>>>>>> --  Kevin J. Ma
>>>>>>>>>
>>>>>>>>>> -----Original Message----- From: Surendra Kumar
>>>>>>>>>> (smkumar) [mailto:[email-masked]] Sent: Tuesday,
>>>>>>>>>> November 12, 2013 12:08 AM To: Kevin J Ma; Ron
>>>>>>>>>> Parker; Sumandra Majee; Thomas Narten;
>>>>>>>>>> [email-masked] Subject: Re: [nsc] Current Proposed
>>>>>>>>>> SFC charter
>>>>>>>>>>
>>>>>>>>>> Kevin,
>>>>>>>>>>
>>>>>>>>>> Classification mechanism is outside the scope of
>>>>>>>>>> SFC. It can be based
>>>>>>>> on
>>>>>>>>>> the packet or information not in the
>>>>>>>>>> packet(environmental attributes
>>>>>>>> for
>>>>>>>>>> instance) or a combination thereof. What is
>>>>>>>>>> important is that such classification aids in
>>>>>>>>>> traffic selection and service path identification.
>>>>>>>>>> It is no different from a policy in this regard
>>>>>>>>>> except that the policy now specifies the service
>>>>>>>>>> path. Further, classification is not limited to the
>>>>>>>>>> network elements but the service functions as well.
>>>>>>>>>> Some of this is described in the
>>>>>>>> architecture
>>>>>>>>>> drafts as well -
Surendra.
>>>>>>>>>>> I was unable to make the SFC BoF due to a
>>>>>>>>>>> conflict with CDNI, but I had a similar question
>>>>>>>>>>> wrt bullet 11 in section 2 of the
>>>>>> problem
>>>>>>>>>>> statement:
>>>>>>>>>>>
>>>>>>>>>>> 11.  Per-Service (re)Classification:
>>>>>>>>>>> Classification occurs at
>>>>>> each
>>>>>>>>>>> The SFC Classifier classifies packets based on
>>>>>>>>>>> (some of) the
>>>>>>>>>> contents
>>>>>>>>>>> of the packet header.  Concretely, it classifies
>>>>>>>>>>> packets based on
>>>>>>>>>> the
>>>>>>>>>>> possible combination of one or more header
>>>>>>>>>>> fields, such as
>>>>>> source
>>>>>>>>>>> address, destination address, DS field, protocol
>>>>>>>>>>> ID, source
>>>>>> port
>>>>>>>>>> and
>>>>>>>>>>> A packet-based classifier as described in the
>>>>>>>>>>> framework document
>>>>>>>>>> would
>>>>>>>>>>> seem to be limited in what it can classify?  The
>>>>>>>>>>> service function identifier lookup does not seem
>>>>>>>>>>> to be a significant optimization
>>>>>>>> over
>>>>>>>>>>> a packet-based 5-tuple lookup?  There seems to be
>>>>>>>>>>> some missing
>>>>>>>> detail
>>>>>>>>>>> When thinking about higher level services, e.g.,
>>>>>>>>>>> HTTP and TLS
>>>>>>>>>> encrypted
>>>>>>>>>>> flows, a packet-based classifier seems
>>>>>>>>>>> inadequate?  I was also
>>>>>>>>>> wondering
>>>>>>>>>>> how independent HLS segment requests might be
>>>>>>>>>>> classified and
>>>>>>>>>> associated?
>>>>>>>>>>>> -----Original Message----- From:
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> [mailto:[email-masked]] On Behalf
>>>>>>>> Of
>>>>>>>>>>>> Ron Parker Sent: Monday, November 11, 2013
>>>>>>>>>>>> 10:16 PM To: Sumandra Majee; Thomas Narten;
>>>>>>>>>>>> [email-masked] Subject: Re: [nsc] Current
>>>>>>>>>>>> Proposed SFC charter
>>>>>>>>>>>>
>>>>>>>>>>>> Sumandra,
>>>>>>>>>>>>
>>>>>>>>>>>> As was discussed in Vancouver, there are
>>>>>>>>>>>> already many existing ways
>>>>>>>>>> to
>>>>>>>>>>>> service chain encapsulation will go a long way
>>>>>>>>>>>> to ensuring these
>>>>>>>>>> goals.
>>>>>>>>>>>> It  may not be the absolutely most efficient
>>>>>>>>>>>> approach for every
>>>>>>>>>> single
>>>>>>>>>>>> network topology and every single use case, but
>>>>>>>>>>>> its ubiquitous
>>>>>>>> nature
>>>>>>>>>>>> -----Original Message----- From: Sumandra Majee
>>>>>>>>>>>> [mailto:[email-masked]] Sent: Monday, November
>>>>>>>>>>>> 11, 2013 10:10 PM To: Ron Parker; Thomas
>>>>>>>>>>>> Narten; [email-masked] Subject: RE: [nsc] Current
>>>>>>>>>>>> Proposed SFC charter
>>>>>>>>>>>>
>>>>>>>>>>>> Ron,
>>>>>>>>>>>>
>>>>>>>>>>>> Absolutely, that was an example of one type of
>>>>>>>>>>>> derivation. However
>>>>>>>>>> this
>>>>>>>>>>>> could be augmented with classification result,
>>>>>>>>>>>> again one more
>>>>>>>>>> example.
>>>>>>>>>>>>
>>>>>>>>>>>>>> All flows from the same source IP do not
>>>>>>>>>>>>>> necessarily follow
>>>>>> the
>>>>>>>>>> same
>>>>>>>>>>>> chain. Correct. It is also not necessary that
>>>>>>>>>>>> all transaction of the same
>>>>>>>>>> flow
>>>>>>>>>>>> Again the point here is that do we always need
>>>>>>>>>>>> SFC header or
>>>>> Not.
>>>>>>>>>>>>
>>>>>>>>>>>> Sumandra
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message----- From: Ron Parker
>>>>>>>>>>>> [mailto:[email-masked]] Sent:
>>>>>>>>>>>> Monday, November 11, 2013 7:02 PM To: Sumandra
>>>>>>>>>>>> Majee; Thomas Narten; [email-masked] Subject: RE:
>>>>>>>>>>>> [nsc] Current Proposed SFC charter
>>>>>>>>>>>>
>>>>>>>>>>>> Sumandra,
>>>>>>>>>>>>
>>>>>>>>>>>> The intention of service function chaining is
>>>>>>>>>>>> to allow for operation
>>>>>>>>>> at
>>>>>>>>>>>> the fully qualified flow level, or even finer
>>>>>>>>>>>> grained at the
>>>>>>>>>> transaction
>>>>>>>>>>>> IP, therefore,  does not identify the chain ID.
>>>>>>>>>>>> Another
>>>>> intention
>>>>>> of
>>>>>>>>>>>> not be limited to a single LAN.   Thus, while
>>>>>>>>>>>> VLAN may be part
>>> of
>>>>>> the
>>>>>>>>>>>> transport, it does not adequately identify the
>>>>>>>>>>>> service chain,
>>>>>>>> either.
>>>>>>>>>>>>
>>>>>>>>>>>> Ron
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message----- From: Sumandra Majee
>>>>>>>>>>>> [mailto:[email-masked]] Sent: Monday, November
>>>>>>>>>>>> 11, 2013 9:56 PM To: Ron Parker; Thomas Narten;
>>>>>>>>>>>> [email-masked] Subject: RE: [nsc] Current
>>>>>>>>>>>> Proposed SFC charter
>>>>>>>>>>>>
>>>>>>>>>>>> Ron,
>>>>>>>>>>>>
>>>>>>>>>>>> The service header is meant to carry the
>>>>>>>>>>>> context which can
>>>>>> *also*
>>>>>>>>>>>> be derived (for example use source ip and vlan
>>>>>>>>>>>> to identify chainID and position) or
>>>>>>>>>>>> encapsulated as part of another tunnel header.
>>>>>>>>>>>> -----Original Message----- From: Ron Parker
>>>>>>>>>>>> [mailto:[email-masked]] Sent:
>>>>>>>>>>>> Monday, November 11, 2013 4:36 PM To: Sumandra
>>>>>>>>>>>> Majee; Thomas Narten; [email-masked] Subject: RE:
>>>>>>>>>>>> [nsc] Current Proposed SFC charter
>>>>>>>>>>>>
>>>>>>>>>>>> Sumandra,
>>>>>>>>>>>>
>>>>>>>>>>>> As I understand it, an SFC packet traversing
>>>>>>>>>>>> from PDP to SF or from
>>>>>>>>>> SF
>>>>>>>>>>>> to SF will look like:
>>>>>>>>>>>>
>>>>>>>>>>>> +------------------------+ |        "transport"
>>>>>>>>>>>> | +------------------------+ |      service
>>>>>>>>>>>> header    | +------------------------+ |
>>>>>>>>>>>> original IP header  |
>>>>>>>>>>>> +------------------------+ |
>>>>>>>>>>>> |  original IP | payload
>>>>>> |
>>>>>>>>>>>> |                                         |
>>>>>>>>>>>> Where service header contains, at a minimum,
>>>>>>>>>>>> enough information to
>>>>>>>>>> allow
>>>>>>>>>>>> the packet to be propagated along the full
>>>>>>>>>>>> length of the chain, and optionally, other
>>>>>>>>>>>> metadata that enhances the operation of
>>>>>> one
>>>>>>>>>>>> or
>>>>>>>> more
>>>>>>>>>>>> service functions.
>>>>>>>>>>>>
>>>>>>>>>>>> And where "transport" could conceivably be any
>>>>>>>>>>>> of, but not limited
>>>>>>>>>> to:
>>>>>>>>>>>>
>>>>>>>>>>>> * Ethernet * Ethernet + LLC2 * Ethernet + MPLS
>>>>>>>>>>>> * Ethernet + IP + GRE * Ethernet + IP +UDP
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Also, "original" in the diagram above is not
>>>>>>>>>>>> meant to imply immutability, but rather to
>>>>>>>>>>>> specify the packet that is
>>>>>> propagated
>>>>>>>>>>>> from preceding entity to succeeding entity,
>>>>>>>>>>>> prior to encapsulation.
>>>>>>>>>>>>
>>>>>>>>>>>> Ron
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message----- From:
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> [mailto:[email-masked]] On Behalf
>>>>>>>> Of
>>>>>>>>>>>> Sumandra Majee Sent: Monday, November 11, 2013
>>>>>>>>>>>> 6:46 PM To: Thomas Narten; [email-masked]
>>>>>>>>>>>> Generic Service Function Chaining
>>>>>>>>>>>> Encapsulation: A document
>>>>> will
>>>>>>>>>>>> for conveying the service function chain and
>>>>>>>>>>>> the service function
>>>>>>>>>> path,
>>>>>>>>>>>> and for communicating context information
>>>>>>>>>>>> between nodes
>>> that
>>>>>>>>>>>> be agnostic to the layer at which it is applied
>>>>>>>>>>>> and the service
>>>>>>>>>> that
>>>>>>>>>>>> is being constructed. That is, the same
>>>>>>>>>>>> encapsulation may be
>>>>>> used
>>>>>>>> on
>>>>>>>>>>>> a service function path realized at the network
>>>>>>>>>>>> layer or at any other layer, and the same
>>>>>>>>>>>> encapsulation will apply for the
>>>>>>>> construction
>>>>>>>>>> of
>>>>>>>>>>>> [SM] What does it mean by a single
>>>>>>>>>>>> service-level encapsulation,
>>>>>> a
>>>>>>>>>> new
>>>>>>>>>>>> encapsulation format or an ability to select
>>>>>>>>>>>> one encapsulation format that
>>>>>>>>>> fits
>>>>>>>>>>>> the need for a given service chain? The ability
>>>>>>>>>>>> to select a specific encapsulation would be
>>>>>>>> a
>>>>>>>>>>>> management plane decision. There are quite a
>>>>>>>>>>>> few existing encapsulation methods that
>>>>>>>>>> can
>>>>>>>>>>>> possibly be reused to provide context
>>>>>>>>>>>> information between   service nodes. I have
>>>>>> seen
>>>>>>>>>>>> mention of GRE, for HTTP based applications
>>>>>>>>>>>> contexts are transferred via headers.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message----- From:
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> [mailto:[email-masked]] On Behalf
>>>>>>>> Of
>>>>>>>>>>>> Thomas Narten Sent: Wednesday, November 06,
>>>>>>>>>>>> 2013 11:07 AM To: [email-masked] Subject: [nsc]
>>>>>>>>>>>> Current Proposed SFC charter
>>>>>>>>>>>>
>>>>>>>>>>>> Hi.
>>>>>>>>>>>>
>>>>>>>>>>>> It contains the revised management text as well
>>>>>>>>>>>> as updated
>>>>>>>>>> milestones.
>>>>>>>>>>>>
>>>>>>>>>>>> All known issues have been addressed. If there
>>>>>>>>>>>> are any remaining
>>>>>>>>>> issues,
>>>>>>>>>>>> please speak up!
>>>>>>>>>>>>
>>>>>>>>>>>> applications, have all undergone significant
>>>>>>>>>>>> change in recent years with the introduction
>>>>>>>> of
>>>>>>>>>>>> virtualization, network overlays, and
>>>>>>>>>>>> orchestration. Service
>>>>>>>> delivery
>>>>>>>>>> is
>>>>>>>>>>>> currently both a technical and organizational
>>>>>>>>>>>> challenge that
>>>>>>>> involves
>>>>>>>>>>>> significant modification to the network
>>>>>>>>>>>> configuration. Services are typically
>>>>>>>>>>>> implemented by the ordered combination of a
>>>>>>>>>>>> number of service functions that are deployed
>>>>>>>>>>>> at different points within
>>>>>>>> the
>>>>>>>>>>>> network. Today, a common deployment model has
>>>>>>>>>>>> service functions physically inserted on the
>>>>>>>>>>>> data forwarding path between communicating
>>>>>>>>>>>> peers.
>>>>>>>>>> Going
>>>>>>>>>>>> forward, however, there is a desire to move to
>>>>>>>>>>>> a different model,
>>>>>>>>>> where
>>>>>>>>>>>> service functions are not required to reside on
>>>>>>>>>>>> the default data
>>>>>>>> path
>>>>>>>>>>>> and traffic is instead steered through
>>>>>>>>>>>> services, wherever they are
>>>>>>>>>> deployed.
>>>>>>>>>>>>
>>>>>>>>>>>> For a given service, the abstracted view of the
>>>>>>>>>>>> required service functions and the order in
>>>>>>>>>>>> which they are to be applied is
>>>>>> called
>>>>>>>>>>>> a Service Function Chain (SFC). Since a given
>>>>>>>>>>>> service function may be available on more than
>>>>>>>>>>>> one node within a network, a Service Function
>>>>>>>>>>>> Chain is instantiated
>>>>>>>>>> via
>>>>>>>>>>>> the selection of specific service function
>>>>>>>>>>>> instances and the network nodes on which they
>>>>>>>>>>>> are provided, thereby forming a service
>>>>>>>>>>>> topology: this is called a Service Function
>>>>>>>>>>>> Path. The service functions
>>>>>> may
>>>>>>>>>>>> be applied at a specific layer within the
>>>>>>>>>>>> network protocol stack
>>>>>>>>>> (network
>>>>>>>>>>>> The Service Function Chaining (SFC) working
>>>>>>>>>>>> group will develop new approaches to service
>>>>>>>>>>>> delivery and deployment. It will produce a
>>>>>>>>>>>> framework for service function chaining that
>>>>>>>>>>>> includes the necessary protocols
>>>>>>>>>> or
>>>>>>>>>>>> protocol extensions to convey the service path
>>>>>>>>>>>> and service path information to nodes that
>>>>>>>>>>>> implement service functions, as well
>>>>>> as
>>>>>>>>>>>> mechanisms for steering traffic through service
>>>>>>>>>>>> functions. The
>>>>>>>>>> working
>>>>>>>>>>>> group will also examine what information needs
>>>>>>>>>>>> to be gathered from
>>>>>>>>>> the
>>>>>>>>>>>> network and service functions in support of
>>>>>>>>>>>> service function
>>>>>>>> chaining
>>>>>>>>>>>> and how that information may be made available
>>>>>>>>>>>> to nodes that implement
>>>>>>>>>> the
>>>>>>>>>>>> service functions.
>>>>>>>>>>>>
>>>>>>>>>>>> 1) Problem Statement: This document will
>>>>>>>>>>>> provide a summary of
>>>>>> the
>>>>>>>>>>>> problem space to be addressed by the WG
>>>>>>>>>>>> including example
>>>>>> high-
>>>>>>>>>>>> 2) Architecture: This document will provide a
>>>>>>>>>>>> description of
>>>>> the
>>>>>>>>>>>> interconnection, placement of capabilities,
>>>>>>>>>>>> management, diagnostics, design analysis, and
>>>>>>>>>>>> security models, as well
>>>>> as
>>>>>>>>>>>> 3) Generic Service Function Chaining
>>>>>>>>>>>> Encapsulation: A document
>>>>>> will
>>>>>>>>>>>> for conveying the service function chain and
>>>>>>>>>>>> the service function
>>>>>>>>>> path,
>>>>>>>>>>>> and for communicating context information
>>>>>>>>>>>> between nodes
>>> that
>>>>>>>>>>>> be agnostic to the layer at which it is applied
>>>>>>>>>>>> and the service
>>>>>>>>>> that
>>>>>>>>>>>> is being constructed. That is, the same
>>>>>>>>>>>> encapsulation may be
>>>>>> used
>>>>>>>> on
>>>>>>>>>>>> a service function path realized at the network
>>>>>>>>>>>> layer or at any other layer, and the same
>>>>>>>>>>>> encapsulation will apply for the
>>>>>>>> construction
>>>>>>>>>> of
>>>>>>>>>>>> describe requirements and protocols necessary
>>>>>>>>>>>> to convey
>>>>>>>>>> information
>>>>>>>>>>>> to service function implementation points.
>>>>>>>>>>>> Where possible,
>>>>>>>>>> existing
>>>>>>>>>>>> work should be carried out in the working
>>>>>>>>>>>> groups responsible for
>>>>>>>>>> the
>>>>>>>>>>>> protocols being modified in coordination with
>>>>>>>>>>>> this working
>>>>>>>> group,
>>>>>>>>>>>> but may be done in this working group after
>>>>>>>>>>>> agreement with all
>>>>>> the
>>>>>>>>>>>> functions in support of SFC components will
>>>>>>>>>>>> certainly be
>>>>>> needed,
>>>>>>>>>>>> Apr 2014 Submit to IESG Informational
>>>>>>>>>>>> document(s) defining the
>>>>>>>>>> problem
>>>>>>>>>>>> statement and core use cases for Service
>>>>>>>>>>>> Function Chaining
>>>>>>>>>>>>
>>>>>>>>>>>> May 2014 Consult with OPS Area on possible
>>>>>>>>>>>> charter modifications for management and
>>>>>>>>>>>> configuration of SFC components
>>>>>>>>>>>>
>>>>>>>>>>>> Jan 2015 Submit to IESG Informational document
>>>>>>>>>>>> defining the
>>>>>>>>>> architecture
>>>>>>>>>>>> for SFC
>>>>>>>>>>>>
>>>>>>>>>>>> Jan 2015 Submit to IESG requirements for a
>>>>>>>>>>>> generic service function chaining encapsulation
>>>>>>>>>>>> protocol
>>>>>>>>>>>>
>>>>>>>>>>>> Aug 2015 Submit to IESG Standards Track
>>>>>>>>>>>> document specifying the
>>>>>>>>>> generic
nsc mailing list
nsc mailing list
nsc mailing list
>>>>>>>>>>> nsc mailing list [email-masked]
>>>>>> _______________________________________________ nsc mailing
>>>>>> list [email-masked]
>>>>>> _______________________________________________ nsc mailing
>>>>>> list [email-masked]
>>>>>> _______________________________________________ nsc mailing
>>>>>> list [email-masked]
>>> _______________________________________________ nsc mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/nsc
>> _______________________________________________ nsc mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/nsc
>
> _______________________________________________ nsc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/nsc
> _______________________________________________ nsc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/nsc
> _______________________________________________ nsc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/nsc
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 14 Nov 2013 12:49:26 +0000

Hi Dave,

I am not sure I am catching your point. There is no doubt that a service
function may appear in more than one chain; it must as otherwise you would
be spinning up service function instances that could only ever be used by
traffic flowing through a single service chain. Simple example is a chain
a-b-c; I see no reason why you could not also build a chain d-b-e where b
is the same service function instance in both chains. Branching seems to
me to be independent of how many service function instances you have for a
given service function.

On 11/13/13 10:45 AM, "David Allan I" <[email-masked]> wrote:

>HI Hongyu:
>
>I think we will have scenarios where a service function appears in more
>than one chain, as would be the case, for example, if some flows could
>dynamically bypass DPI but still needed to transit a common set of
>stateful service functions...
>
>Once you postulate a service function instance appearing in more than one
>chain, it seems artificially restrictive not to permit such a function to
>also implement branching, all the control structures would already be
>there.
>
>Rgds
>Dave
>
>	Meaning, a SF shall not *directly* impact the forwarding of packets in a
>chain. Branching should be performed by chain forwarding nodes, possibly
>under control of a control node. The reason for this is in NFV world,
>service functions may come from a third party, while chain is provided by
>the infrastructure of the network. There must be a cushion avoiding a
>service function operating infrastructure directly.
>	This is very general. Such info could be L2~L7 derived from a user's
>packet, as well as some info like metadata in a SFC header. As
>classification is out of scope of SFC, we don't have to provide too much
>details of how to do classification.
>4. Chain segments stitching is relatively a easy way for branching.
>Compared with chains and subchains, which may require a more complex
>header and forwarding capabilities.
>My two cents.
>Hongyu
>
>David Allan I
>Defining a flow subset can be a result of classification, but it is not
>the exclusive mechanism. Branching is a mechanism by which flow subsets
>are exposed and mapped to a set of subchains such that it can be
>identified in the dataplane...
>
>David Lake (dlake)
>But I still think we need to consider where and how policy is defined/set
>even for the single-domain instance.
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 14 Nov 2013 13:00:24 +0000

Completely agree Joel although the service function *may* directly update
metadata context and service path identification (which effectively forces
a branching operation).

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 14 Nov 2013 08:10:21 -0500

I agree that there are cases where the service function will need to 
make such updates.  I believe they are rare, and will therefore need to 
be supported in the architecture in an appropriate fashion.
But the debate about frequency and mechanism can wait until we get a WG 
chartered.

Yours,
Joel

---

From: David Allan I <[email-masked]>
Date: Thu, 14 Nov 2013 14:56:42 +0000

I think it is going to be a rare event, as what is more likely is the front end of the chain is dynamically modified so subsequent packets in a flow skip certain functions. Hence a graph more often than not is logically P2P. Facilitates testing amongst other benefits.

As such I'd not want to be prescriptive as to how and where it is done....

Dave

-----Original Message-----
From: Hongyu Li (Julio) [mailto:[email-masked]] 
Sent: Wednesday, November 13, 2013 6:30 PM
To: David Allan I; [email-masked]
Subject: RE: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

Hi Dave,

Does this make sense?

Hongyu

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: Wednesday, November 13, 2013 11:45 PM
To: Hongyu Li (Julio); [email-masked]
Subject: RE: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

HI Hongyu:

Rgds
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, November 13, 2013 3:04 AM
To: [email-masked]
Subject: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

Hi:

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 14 Nov 2013 15:14:26 +0000

I think it is misleading to say that a service function does not impact
packet forwarding. If branching occurs then the service function does
impact packet forwarding, whether directly or indirectly, as otherwise
packets would not take the new path as a result of the branch. For
example, if the chain is a-b-c and b decides that for certain flows the
traffic should go to d rather than c then it *must* force the forwarding
component to direct traffic to the new next-hop. While the service
function may not modify forwarding in terms of updating forwarding tables
and so forth, it has to inform the forwarding component of its intent
somehow. Also, I think what you describe Dave is a bypass operation rather
than a branch? 

On 11/14/13 9:56 AM, "David Allan I" <[email-masked]> wrote:

>I think it is going to be a rare event, as what is more likely is the
>front end of the chain is dynamically modified so subsequent packets in a
>flow skip certain functions. Hence a graph more often than not is
>logically P2P. Facilitates testing amongst other benefits.
>
>functions should be able to compose a chain arbitrarily. Particularly for
>branching, as I suggested in previous email, service function shall not
>directly impact packet forwarding. This precludes the restriction you
>mentioned. Forwarding plane can decide whether a branching action should
>be taken by reclassification or not per service chain.
>
>Does this make sense?
>
>Hongyu
>

---

From: David Allan I <[email-masked]>
Date: Thu, 14 Nov 2013 15:22:02 +0000

My point was once a function in participating in more than one chain, the parallel tracks Niulehong refers to, then conceptually there is no reason why a switch in the function woundn't allow a train to change tracks.

As I've indicated I think it is a rare case, causes traceability issues etc. and therefore is actually undesirable  but I'd rather not be prescriptive on whether this is possible or not, or HOW it MUST be done....Conceptually I think what you refer to as bypass is the far more likely dynamic chain behavior we would expect...

Dave

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Thursday, November 14, 2013 4:49 AM
To: David Allan I; Hongyu Li (Julio); [email-masked]
Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

Hi Dave,

I am not sure I am catching your point. There is no doubt that a service function may appear in more than one chain; it must as otherwise you would be spinning up service function instances that could only ever be used by traffic flowing through a single service chain. Simple example is a chain a-b-c; I see no reason why you could not also build a chain d-b-e where b is the same service function instance in both chains. Branching seems to me to be independent of how many service function instances you have for a given service function.

On 11/13/13 10:45 AM, "David Allan I" <[email-masked]> wrote:

>function to also implement branching, all the control structures would 
>already be there.
>
>Rgds
>Dave
>
>	Meaning, a SF shall not *directly* impact the forwarding of packets in 
>a chain. Branching should be performed by chain forwarding nodes, 
>possibly under control of a control node. The reason for this is in NFV 
>world, service functions may come from a third party, while chain is 
>provided by the infrastructure of the network. There must be a cushion 
>avoiding a service function operating infrastructure directly.
>classification is out of scope of SFC, we don't have to provide too 
>much details of how to do classification.
>>multi-domain issue - if I set a policy as a user, chances are I will 
>>be crossing several domain boundaries.  Are we expecting the service 
>>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>>> Of Surendra Kumar (smkumar)
>>> > look at the simpler packet-level classification cases, or is it 
>>> > the intent to consider the case where a branching point is viewed 
>>> > as a re-classification point?
>>> >
>>> >thanx.
>>> >
>>> >--  Kevin J. Ma
>>> >
>>> >> especially L7 based, can use value in a Database to determine 
>>> >> what is the next service function.
>>> >>
>>> >> Linda
>>> >>
>>> >> > branches to go is made based on the result of service 
>>> >> > function's process, i.e. not just re- classification by DPI.
>>> >> >
>>> >> > Hongyu
>>> >> >
>>> >> > > chain ID, prior to DPI-based re-classification?  (assuming 
>>> >> > > the goal is "a single chain ID that is commonly understood 
>>> >> > > along the entire service
>>> chain"
>>> >> > >>> If, on the other hand, the service function scope is 
>>> >> > >>> limited due to limitations in classification, that would be 
>>> >> > >>> and important piece of
>>> >> > information?
>>> >> > >>>
>>> >> > >>> Or is the service function chain classification exclusive 
>>> >> > >>> of DPI
>>> >> > functionality?
>>> >> > >> <SK> I have not fully read that draft yet. But in general, 
>>> >> > >> as described in the arch draft, the collection of services 
>>> >> > >> form a graph, segments of which are service paths. Yes, 
>>> >> > >> reclassification can
>>> >> > change
>>> >> > >> the service path and re-classification may happen at any 
>>> >> > >> node along
>>> >> > a service path.
>>> >> > >>
>>> >> > >> Surendra.
>>> >> > >>>
>>> >> > >>> thanx.
>>> >> > >>>
>>> >> > >>> --  Kevin J. Ma
>>> >> > >>>
>>> >> > >>>> It is no different from a policy in this regard except 
>>> >> > >>>> that the policy now specifies the service path.
>>> >> > >>>> elements but the service functions as well. Some of this 
>>> >> > >>>> is described in the
>>> >> > >> architecture
>>> >> > >>>> drafts as well -
>>> >> > >>>>>   The SFC Classifier classifies packets based on (some 
>>> >> > >>>>> of) the
>>> >> > >>>> contents
>>> >> > >>>>>> It  may not be the absolutely most efficient approach 
>>> >> > >>>>>> for every
>>> >> > >>>> single
>>> >> > >>>>>> Correct. It is also not necessary that all transaction 
>>> >> > >>>>>> of the same
>>> >> > >>>> flow
>>> >> > >>>>>> Again the point here is that do we always need SFC 
>>> >> > >>>>>> header or
>>> >>Not.
>>> >> > >>>>>>
>>> >> > >>>>>> Sumandra
>>> >> > >>>>>>
>>> >> > >>>>>>
>>> >> > >>>>>> imply immutability, but rather to specify the packet 
>>> >> > >>>>>> that is
>>> >> > propagated
>>> >> > >>>>>>    being constructed. That is, the same encapsulation 
>>> >> > >>>>>> may be
>>> >> > used
>>> >> > >> on
>>> >> > >>>>>> functions physically inserted on the data forwarding 
>>> >> > >>>>>> path between communicating peers.
>>> >> > >>>> Going
>>> >> > >>>>>> It will produce a framework for service function 
>>> >> > >>>>>> chaining that includes the necessary protocols
>>> >> > >>>> or
>>> >> > >>>>>>    being constructed. That is, the same encapsulation 
>>> >> > >>>>>> may be
>>> >> > used
>>> >> > >> on
>>> >> > >>>>>>    may be done in this working group after agreement 
>>> >> > >>>>>> with all
>>> >> > the

---

From: Ron Parker <[email-masked]>
Date: Thu, 14 Nov 2013 15:24:02 +0000

Hi, Jim.

I agree that forwarding is affected indirectly.   Whether function b forwards to function c or function d is accomplished by b correctly adding (modifying) the transport header so that d is addressed or c is addressed.   In the most general case of utilizing an IP-based transport encapsulation (e.g., IP/UDP, IP/GRE, etc.), the selection of next hop is not made at this level.   The transport location (IP address) for c and d may or may not share the same next-hop based on the newtwork topology (i.e., c and/or d may or may not be on the same subnet as b, may or may not be reached via the same next hop router).

   Ron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, November 14, 2013 10:14 AM
To: David Allan I; Hongyu Li (Julio); [email-masked]
Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

I think it is misleading to say that a service function does not impact packet forwarding. If branching occurs then the service function does impact packet forwarding, whether directly or indirectly, as otherwise packets would not take the new path as a result of the branch. For example, if the chain is a-b-c and b decides that for certain flows the traffic should go to d rather than c then it *must* force the forwarding component to direct traffic to the new next-hop. While the service function may not modify forwarding in terms of updating forwarding tables and so forth, it has to inform the forwarding component of its intent somehow. Also, I think what you describe Dave is a bypass operation rather than a branch? 

On 11/14/13 9:56 AM, "David Allan I" <[email-masked]> wrote:

>front end of the chain is dynamically modified so subsequent packets in 
>a flow skip certain functions. Hence a graph more often than not is 
>for branching, as I suggested in previous email, service function shall 
>not directly impact packet forwarding. This precludes the restriction 
>you mentioned. Forwarding plane can decide whether a branching action 
>should be taken by reclassification or not per service chain.
>
>Does this make sense?
>
>Hongyu
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 14 Nov 2013 15:29:40 +0000

Hi Ron,

I would not say that b modifies the transport header but rather b informs
the forwarding component of it's intent so that it may insert the
appropriate transport header to meet b's requirement.

On 11/14/13 10:24 AM, "Ron Parker" <[email-masked]> wrote:

>Hi, Jim.
>
>I agree that forwarding is affected indirectly.   Whether function b
>forwards to function c or function d is accomplished by b correctly
>adding (modifying) the transport header so that d is addressed or c is
>addressed.   In the most general case of utilizing an IP-based transport
>encapsulation (e.g., IP/UDP, IP/GRE, etc.), the selection of next hop is
>not made at this level.   The transport location (IP address) for c and d
>may or may not share the same next-hop based on the newtwork topology
>(i.e., c and/or d may or may not be on the same subnet as b, may or may
>not be reached via the same next hop router).
>
>   Ron
>
>
>somehow. Also, I think what you describe Dave is a bypass operation
>rather than a branch?
>
>>>>policy-driven
>>>>clarified.

---

From: Ian Smith <[email-masked]>
Date: Thu, 14 Nov 2013 15:37:02 +0000

I think the metaphor is wrong:  the service function chain is the train, the packets are the shipping containers loaded on the train, and the tracks are the data link/switching/routing infrastructure.

How the cars of the train are arranged is a sfc configuration function.

Which containers go onto the train is a function of classification.

Where the tracks go is a function of network infrastructure.

Which train goes on which track is a policy decision.

David Allan I <[email-masked]> wrote:

Dave

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Thursday, November 14, 2013 4:49 AM
To: David Allan I; Hongyu Li (Julio); [email-masked]
Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

Hi Dave,

---

From: Ron Parker <[email-masked]>
Date: Thu, 14 Nov 2013 15:40:38 +0000

Jim,

I think that could be an implementation decision.   One implementation approach is that the SFC IP-layer transport tunnels are known at the forwarding layer (like the way IP-in-IP and GRE tunnels are frequently supported -- as an IP interface).   Another possible approach is to handle the SFC IP-layer transport tunnels at a level above the forwarding layer (like the way GTP-U tunnels are frequently supported -- they are not represented as distinct IP interfaces).

    Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Thursday, November 14, 2013 10:30 AM
To: Ron Parker; David Allan I; Hongyu Li (Julio); [email-masked]
Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

Hi Ron,

I would not say that b modifies the transport header but rather b informs the forwarding component of it's intent so that it may insert the appropriate transport header to meet b's requirement.

On 11/14/13 10:24 AM, "Ron Parker" <[email-masked]> wrote:

>Jim Guichard (jguichar)
>traffic should go to d rather than c then it *must* force the 
>forwarding component to direct traffic to the new next-hop. While the 
>service function may not modify forwarding in terms of updating 
>forwarding tables and so forth, it has to inform the forwarding 
>component of its intent somehow. Also, I think what you describe Dave 
>is a bypass operation rather than a branch?
>
>>front end of the chain is dynamically modified so subsequent packets 
>>in a flow skip certain functions. Hence a graph more often than not is 
>>branching action should be taken by reclassification or not per service chain.
>>
>>Does this make sense?
>>
>>Hongyu
>>
>>	Meaning, a SF shall not *directly* impact the forwarding of packets 
>>in a chain. Branching should be performed by chain forwarding nodes, 
>>possibly under control of a control node. The reason for this is in 
>>NFV world, service functions may come from a third party, while chain 
>>is provided by the infrastructure of the network. There must be a 
>>cushion avoiding a service function operating infrastructure directly.
>>>> based on what we can see at ingress) is going to be useful - is 
>>>> THAT what we're aiming for here ?
>>>
>>>> based on what we can see at ingress) is going to be useful - is 
>>>> THAT what we're aiming for here ?
>>>>
>>>> David
>>>>
>>>> >> Second, the representation of branching (or service graph) can 
>>>> >> be in a form of logic on a service function. Some service 
>>>> >> functions, especially L7 based, can use value in a Database to 
>>>> >> determine what is the next service function.
>>>> >>
>>>> >> Linda
>>>> >>
>>>> >> > It is also possible that packets go to different branches 
>>>> >> > after been processed by a certain service function, decision 
>>>> >> > of which branches to go is made based on the result of service 
>>>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.ht
>>>> >> > > m
>>>> >> > > l
>>>> >> > > )
>>>> >> > >
>>>> >> > >>> limited due to limitations in classification, that would 
>>>> >> > >>> be and important piece of
>>>> >> > information?
>>>> >> > >>>
>>>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases 
>>>> >> > >>> the fork points of the service paths seem like 
>>>> >> > >>> re-classification
>>>> points?
>>>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas 
>>>> >> > >>>> Narten; [email-masked]
>>>> >> > >>>>>   possible combination of one or more header fields, 
>>>> >> > >>>>> such as
>>>> >> > source
>>>> >> > >>>>> When thinking about higher level services, e.g., HTTP 
>>>> >> > >>>>> and TLS
>>>> >> > >>>> encrypted
>>>> >> > >>>>> flows, a packet-based classifier seems inadequate?  I 
>>>> >> > >>>>> was also
>>>> >> > >>>> wondering
>>>> >> > >>>>>> could be augmented with classification result, again 
>>>> >> > >>>>>> one more
>>>> >> > >>>> example.
>>>> >> > >>>>>>
>>>> >> > >>>>>> the fully qualified flow level, or even finer grained 
>>>> >> > >>>>>> at the
>>>> >> > >>>> transaction
>>>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP 
>>>> >> > >>>>>> to SF or from
>>>> >> > >>>> SF
>>>> >> > >>>>>> to
>>>> >> > >>>>>> SF will look like:
>>>> >> > >>>>>>
>>>> >> > >>>>>> |                                         |  original 
>>>> >> > >>>>>> | IP payload
>>>> >> > >>>>>> the packet to be propagated along the full length of 
>>>> >> > >>>>>> the chain, and optionally, other metadata that enhances 
>>>> >> > >>>>>> the operation of
>>>> >> > one
>>>> >> > >>>>>> or
>>>> >> > >> more
>>>> >> > >>>>>> service functions.
>>>> >> > >>>>>>
>>>> >> > >>>>>> layer or at any other
>>>> >> > >>>>>>           The ability to select a specific 
>>>> >> > >>>>>> encapsulation would be
>>>> >> > >> a
>>>> >> > >>>>>> required service functions and the order in which they 
>>>> >> > >>>>>> are to be applied is
>>>> >> > called
>>>> >> > >>>>>> function may be available on more than one node within 
>>>> >> > >>>>>> a network, a Service Function Chain is instantiated
>>>> >> > >>>> via
>>>> >> > >>>>>> the selection of specific service function instances 
>>>> >> > >>>>>> and the network nodes on which they are provided, 
>>>> >> > >>>>>> thereby forming a service topology:
>>>> >> > >>>>>> service path information to nodes that implement 
>>>> >> > >>>>>> service functions, as well
>>>> >> > as
>>>> >> > >>>>>> how that information may be made available to nodes 
>>>> >> > >>>>>> that implement
>>>> >> > >>>> the
>>>> >> > >>>>>> service functions.
>>>> >> > >>>>>>
>>>> >> > >>>>>>    diagnostics, design analysis, and security models, 
>>>> >> > >>>>>> as well
>>>> >>as
>>>> >> > >>>>>> layer or at any other

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 14 Nov 2013 15:46:21 +0000

Sure but architecturally the service function and forwarding components are separate entities. Whether you choose to combine them in implementation is your own choice.

Sent from my iPhone

> On Nov 14, 2013, at 10:40 AM, "Ron Parker" <[email-masked]> wrote:
> 
> Jim,
>

---

From: Jerome Moisand <[email-masked]>
Date: Thu, 14 Nov 2013 16:48:44 +0000

All those discussions need to be grounded in concrete use cases...

Seems relatively clear to me though that we'll see chains starting by a L3 component with subscriber/service awareness (e.g. BNG or PGW), then going to a DPI or an IDP service function, and then forking out depending on the application being identified to one set of additional service functions or another. 

So yeah, changing tracks will likely be needed. And for sure, this is an SF-driven decision (the DPI SF). 

Although I'd like to see a network operator (SP or EN) clearly articulate such a use case before jumping through hoops... Because this has all sorts of interesting implications in terms of programming APIs (sockets or else), propagation of metadata, etc. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Thursday, November 14, 2013 10:22 AM
To: Jim Guichard (jguichar); Hongyu Li (Julio); [email-masked]
Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

Dave

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Thursday, November 14, 2013 4:49 AM
To: David Allan I; Hongyu Li (Julio); [email-masked]
Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

Hi Dave,

---

From: Ron Parker <[email-masked]>
Date: Thu, 14 Nov 2013 16:58:13 +0000

Agree.   But is it necessary for us to force the transport encapsulation into one or the other layer?   Can we just say that there is, necessarily, a transport de-encapsulation, sfc header de-encapsulation, service function processing, sfc header encapsulation, transport encapsulation, and finally forwarding and transmission of the fully encapsulated packet?

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Thursday, November 14, 2013 10:46 AM
To: Ron Parker
Cc: David Allan I; Hongyu Li (Julio); [email-masked]
Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

Sent from my iPhone

>> (i.e., c and/or d may or may not be on the same subnet as b, may or 
>> may not be reached via the same next hop router).
>> 
>>  Ron
>> 
>> 
>> I think it is misleading to say that a service function does not 
>> impact packet forwarding. If branching occurs then the service 
>> function does impact packet forwarding, whether directly or 
>> indirectly, as otherwise packets would not take the new path as a 
>> result of the branch. For example, if the chain is a-b-c and b 
>> decides that for certain flows the traffic should go to d rather than 
>> c then it *must* force the forwarding component to direct traffic to 
>> the new next-hop. While the service function may not modify 
>> forwarding in terms of updating forwarding tables and so forth, it 
>> has to inform the forwarding component of its intent somehow. Also, I 
>> think what you describe Dave is a bypass operation rather than a branch?
>> 
>>> I think it is going to be a rare event, as what is more likely is 
>>> the front end of the chain is dynamically modified so subsequent 
>>> packets in a flow skip certain functions. Hence a graph more often 
>>> than not is logically P2P. Facilitates testing amongst other benefits.
>>> 
>>> Your inferred restriction may be not always true. In general, 
>>> service functions should be able to compose a chain arbitrarily. 
>>> Particularly for branching, as I suggested in previous email, 
>>> service function shall not directly impact packet forwarding. This 
>>> precludes the restriction you mentioned. Forwarding plane can decide 
>>> whether a branching action should be taken by reclassification or not per service chain.
>>> 
>>> Does this make sense?
>>> 
>>> Hongyu
>>> 
>>> more than one chain, as would be the case, for example, if some 
>>> flows could dynamically bypass DPI but still needed to transit a 
>>> common set of stateful service functions...
>>> 
>>> Once you postulate a service function instance appearing in more 
>>> than one chain, it seems artificially restrictive not to permit such 
>>> a function to also implement branching, all the control structures 
>>> would already be there.
>>> 
>>> Rgds
>>> Dave
>>> 
>>> is a way to solve the problem.
>>>    Meaning, a SF shall not *directly* impact the forwarding of 
>>> packets in a chain. Branching should be performed by chain 
>>> forwarding nodes, possibly under control of a control node. The 
>>> reason for this is in NFV world, service functions may come from a 
>>> third party, while chain is provided by the infrastructure of the 
>>> network. There must be a cushion avoiding a service function operating infrastructure directly.
>>>    This is very general. Such info could be L2~L7 derived from a 
>>> user's packet, as well as some info like metadata in a SFC header. 
>>> As classification is out of scope of SFC, we don't have to provide 
>>> too much details of how to do classification.
>>> Of David Allan I
>>> subsets are exposed and mapped to a set of subchains such that it 
>>> can be identified in the dataplane...
>>> 
>>> Of David Lake (dlake)
>>> To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); 
>>> Ron Parker; Linda Dunbar; Hongyu Li (Julio)
>>> As discussed during the BOF our initial work is single 
>>> administrative domain for some of the very reasons you point out. We 
>>> need to keep focused without trying to boil the ocean right off the bat.
>>> 
>>>> a specific policy across potentially different sets of carrier policies).
>>>> 
>>>>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda 
>>>>> been or for that matter the L2/L3 devices. All we are talking 
>>>>> about is the applicability of the classification to branching in SFC.
>>>>> 
>>>>>>>>>>>>>       service, independent from previously applied service
>>>>>>>>>>>> functions.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 14 Nov 2013 17:05:05 +0000

I don¹t think we are forcing anything into a layer but simply call out
different components of the overall system that will work together in
forming the SFC architecture. If an implementor wishes to combine the
service function and forwarding components I see no reason why this would
not be compliant with the architecture.

On 11/14/13 11:58 AM, "Ron Parker" <[email-masked]> wrote:

>Agree.   But is it necessary for us to force the transport encapsulation
>into one or the other layer?   Can we just say that there is,
>necessarily, a transport de-encapsulation, sfc header de-encapsulation,
>service function processing, sfc header encapsulation, transport
>encapsulation, and finally forwarding and transmission of the fully
>encapsulated packet?
>
>   Ron
>
>
>Sure but architecturally the service function and forwarding components
>are separate entities. Whether you choose to combine them in
>implementation is your own choice.
>
>Sent from my iPhone
>
>> I think that could be an implementation decision.   One implementation
>>approach is that the SFC IP-layer transport tunnels are known at the
>>forwarding layer (like the way IP-in-IP and GRE tunnels are frequently
>>supported -- as an IP interface).   Another possible approach is to
>>handle the SFC IP-layer transport tunnels at a level above the
>>forwarding layer (like the way GTP-U tunnels are frequently supported --
>>they are not represented as distinct IP interfaces).
>> 
>>    Ron
>> 
>> 
>> I would not say that b modifies the transport header but rather b
>>informs the forwarding component of it's intent so that it may insert
>>the appropriate transport header to meet b's requirement.
>>

---

From: Andre Beliveau <[email-masked]>
Date: Thu, 14 Nov 2013 17:15:18 +0000

Hi, 

In draft-beliveau-sfc-architecture, I was explicit to describe 3 separate logical set of components:  the services (SF), the Service Chaining enforcement functions and the transport functions because we want to keep those separate from each other and have clear interface between them.  And for now, we should discuss about them in logical term and not physical nodes as one physical node might very well include all 3 functions.

The SC enforcement functions should own service chains as defined by an operator while an SF might decide to which chain (track) the packet should continue its route it should not be able to create new chains (tracks).

/AB

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: November-14-13 12:05 PM
To: Ron Parker
Cc: [email-masked]; Hongyu Li (Julio); David Allan I
Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

I don¹t think we are forcing anything into a layer but simply call out different components of the overall system that will work together in forming the SFC architecture. If an implementor wishes to combine the service function and forwarding components I see no reason why this would not be compliant with the architecture.

On 11/14/13 11:58 AM, "Ron Parker" <[email-masked]> wrote:

>>forwarding layer (like the way GTP-U tunnels are frequently supported 
>>-- they are not represented as distinct IP interfaces).
>> 
>>    Ron
>> 
>> 
>>> may or may not share the same next-hop based on the newtwork 
>>>topology  (i.e., c and/or d may or may not be on the same subnet as 
>>>b, may or  may not be reached via the same next hop router).
>>> 
>>>  Ron
>>> 
>>> 
>>> Of Jim Guichard (jguichar)
>>>> than one chain, it seems artificially restrictive not to permit 
>>>> such a function to also implement branching, all the control 
>>>> structures would already be there.
>>>> 
>>>> Rgds
>>>> Dave
>>>> 
>>>> Compared with chains and subchains, which may require a more 
>>>>complex  header and forwarding capabilities.
>>>> My two cents.
>>>> Hongyu
>>>> 
>>>>> To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; 
>>>>> Linda Dunbar; Hongyu Li (Julio)
>>>>>> Behalf Of Surendra Kumar (smkumar)
>>>>>>> point, but the service function, itself, being aware that it is 
>>>>>>>a  branching point would contain the policy and logic to decide 
>>>>>>>on which
>>>>>>> chain is different than I originally inferred.  If the chain is 
>>>>>>> a tree with other "branching" points in it, then that limits the 
>>>>>>> the intent to consider the case where a branching point is 
>>>>>>> viewed as a re-classification point?
>>>>>>> 
>>>>>>> thanx.
>>>>>>> 
>>>>>>> --  Kevin J. Ma
>>>>>>>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 14 Nov 2013 17:22:11 +0000

This separation is a very important architecture consideration IMO. Select
services can dictate the forwarding path at a higher level through the
service path. Actual forwarding may be left to the forwarding components.

Surendra.

On 11/14/13 7:46 AM, "Jim Guichard (jguichar)" <[email-masked]> wrote:

>>>impact 
>>>> a way to solve the problem.
>>>>packets 
>>>>user's 
>>>> Parker; Linda Dunbar; Hongyu Li (Julio)

---

From: Ken Gray <[email-masked]>
Date: Thu, 14 Nov 2013 17:51:14 +0000

+1 

Fair-warning - I'm not a huge fan of a fan-out of interface definitions (many of which only seem to disappear in implementation because nobody really was going to build anything so super-atomic).

That said, from a practical perspective, a service function can operate on a packet ... it can transform the packet ...I don't see how you can preclude this.  In transforming the packet, it IS potentially altering the forwarding on the egress side of the function - depending on the logic it used to alter the packet.  Unless we're proposing all of this sort of transformation logic is going to suddenly be externalized for all service functions, then branching is logically going to happen - potentially driven by the service function.

Depending on how you do "fix-up" or whatever your company calls this handoff, you involve (or don't) some additional actions in the forwarding component - implementation.  So, we're arguing about implementation here in this thread, IMO.  Yeah, go ahead and create your interface if it clarifies things for you, but it's going to be a logical division and not a practical protocol or API.

Finally, without the possibility of branching (which was the fundamental question in the title, and we're straying away from it, IMO), you beg an entirely centralized control system (every chain, for every circumstance is pre-defined).  That too, IMO, is an implementation choice but it's enabled by creating roof for it int he architecture.  If you remove branching, you remove the choice.

My .02.
________________________________________
From: [email-masked] <[email-masked]> on behalf of Surendra Kumar (smkumar) <[email-masked]>
Sent: Thursday, November 14, 2013 12:22 PM
To: Jim Guichard (jguichar); Ron Parker
Cc: [email-masked]; Hongyu Li (Julio); David Allan I
Subject: Re: [nsc] FW:  re classification & branching, was: Current Proposed SFC charter

Surendra.

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Fri, 15 Nov 2013 02:24:02 +0000

HI Joel,

The word "arbitrarily" here may be too arbitrarily selected. What I really want to say is that whatever the operators defines its service chains, they should be able to be deployed. So, I think we have the same view.

HOngyu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 14, 2013 8:47 PM
To: Hongyu Li (Julio); David Allan I; [email-masked]
Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

You assert in the below text that "service functions should be able to compose a chain arbitrarily."
That does not seem to follow.
The operator defines the service chains they want.  They provision those service chains.
Thus, I would expect that the job of a service function is to deliver its specific service.  In general, it should not need to know or care about the chains in which it is participating.

Yours,
Joel M. Halpern

On 11/13/13 9:29 PM, Hongyu Li (Julio) wrote:
> 1. Branch is a sort of use case or scenario, while reclassification is 
> a way to solve the problem. 2. Service Functions should be decoupled 
> with the chain itself. Meaning, a SF shall not *directly* impact the 
> forwarding of packets in a chain. Branching should be performed by 
> chain forwarding nodes, possibly under control of a control node. The 
> network. There must be a cushion avoiding a service function operating 
> infrastructure directly. 3.
> (Re)classification is based on info in a packet. This is very general. 
> Such info could be L2~L7 derived from a user's packet, as well as some 
> info like metadata in a SFC header. As classification is out of scope 
> of SFC, we don't have to provide too much details of how to do 
> classification. 4. Chain segments stitching is relatively a easy way 
> for branching. Compared with chains and subchains, which may require a 
> more complex header and forwarding capabilities. My two cents. Hongyu
>
> Tuesday, November 12, 2013 10:51 AM To: Jim Guichard (jguichar); Kevin 
> J Ma; Surendra Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li 
> (Julio) Cc: Thomas Narten; [email-masked]; Sumandra Majee
> November 2013 10:44 To: David Lake (dlake); Kevin J Ma; Surendra Kumar 
> (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio) Cc:
> Thomas Narten; [email-masked]; Sumandra Majee Subject: Re: [nsc] Current 
> Proposed SFC charter
>
>>> [mailto:[email-masked]] Sent: Tuesday, November 12, 2013 1:00 PM 
>>> (smkumar) Sent: 12 November 2013 09:26 To: Ron Parker; Kevin J Ma; 
>>> Linda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; [email-masked]; 
>>> Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter
>>>
>>> Ron,
>>>
>>>> itself, being aware that it is a branching point would contain the 
>>>> policy and logic to decide on which branch to take.
>>>> Are you saying that a branching point is "never" a reclassification 
>>>> point, or are you saying that a branching point "does not have to 
>>>> be" a reclassification point?
>>>>
>>>> clarified. If branching is never reclassification, then the meaning 
>>>> of a chain is different than I originally inferred.  If the chain 
>>>> is a tree with other "branching" points in it, then that limits the 
>>>> While this could be a degenerate case, and any implementation could 
>>>> define bad service chains, is it the intent of SFC to only look at 
>>>> the simpler packet-level classification cases, or is it the intent 
>>>> to consider the case where a branching point is viewed as a 
>>>> re-classification point?
>>>>
>>>> thanx.
>>>>
>>>> --  Kevin J. Ma
>>>>
>>>>>> Tuesday, November 12, 2013 8:16 AM To: Hongyu Li (Julio); Kevin J 
>>>>>> Ma Cc: Thomas Narten; [email-masked]; Surendra Kumar (smkumar); 
>>>>>> Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter
>>>>>>
>>>>>> Hongyu,
>>>>>>
>>>>>> (Julio) Sent: Tuesday, November 12, 2013 6:57 AM To: Ron Parker; 
>>>>>> (smkumar); Sumandra Majee Subject: Re: [nsc] Current Proposed SFC 
>>>>>> charter
>>>>>>
>>>>>> Thomas Narten; [email-masked]; Surendra Kumar (smkumar); Sumandra 
>>>>>> Majee Subject: Re: [nsc] Current Proposed SFC charter
>>>>>>
>>>>>> Hi, Kevin
>>>>>>
>>>>>>> about service header encapsulation, is it intended that a chain 
>>>>>>> that is re-classified will get a new chain ID which fully 
>>>>>>> describes a chain that is a superset of the original chain ID, 
>>>>>>> prior to DPI-based re-classification?  (assuming the goal is "a 
>>>>>>> single chain ID that is commonly understood along the entire 
>>>>>>> service
>>> chain"
)
>>>>>>> e.g., ID 1: NAT + firewall + DPI ID 2: NAT
>>>>>>> + firewall + DPI + LB + CACHE ID 8: NAT + firewall + DPI CACHE 
>>>>>>> + ID 9: NAT + firewall + DPI + optimizer + LB ID
>>>>>>> NAT + firewall + DPI + optimizer + CACHE Would every flow then 
>>>>>>> be initially classified as ID 1, but eventually get
>>>>>>> re-
>>>>>> classified
>>>>>>>> (smkumar) [mailto:[email-masked]] Sent: Tuesday, November 
>>>>>>>> 12, 2013 1:01 AM To: Kevin J Ma; Ron Parker; Sumandra Majee; 
>>>>>>>> Thomas Narten; [email-masked] Subject:
>>>>>>>>> applicable is dependent upon the level of classification that 
>>>>>>>>> can
>>>>>> be
>>>>>>>>> on the level of classification being performed?  If the stated
>>>>>> goals
>>>>>>>> are
>>>>>>>>> nature of those functions needs to be taken into account? If, 
>>>>>>>>> on the other hand, the service function scope is limited due 
>>>>>>>>> to limitations in classification, that would be and important 
>>>>>>>>> piece of
>>>>>> information?
>>>>>>>>>
>>>>>>>>> Wrt section 4.4 of
>>>>>>>>> draft-liu-service-chaining-use-cases the fork points of the 
>>>>>>>>> service paths seem like re-classification
>>> points?
>>>>>>>> described in the arch draft, the collection of services form a 
>>>>>>>> graph, segments of which are service paths. Yes, 
>>>>>>>> reclassification can
>>>>>> change
>>>>>>>>>> (smkumar) [mailto:[email-masked]] Sent: Tuesday, November 
>>>>>>>>>> 12, 2013 12:08 AM To: Kevin J Ma; Ron Parker; Sumandra Majee; 
>>>>>>>>>> Thomas Narten; [email-masked] Subject: Re: [nsc] Current 
>>>>>>>>>> Proposed SFC charter
>>>>>>>>>>
>>>>>>>>>> Kevin,
>>>>>>>>>>
>>>>>>>>>> Classification mechanism is outside the scope of SFC. It can 
>>>>>>>>>> be based
>>>>>>>> on
>>>>>>>>>> instance) or a combination thereof. What is important is that 
>>>>>>>>>> such classification aids in traffic selection and service 
>>>>>>>>>> path identification.
>>>>>>>>>> the policy now specifies the service path. Further, 
>>>>>>>>>> classification is not limited to the network elements but the 
>>>>>>>>>> service functions as well.
Surendra.
>>>>>>>>>>> CDNI, but I had a similar question wrt bullet 11 in section 
>>>>>>>>>>> 2 of the
>>>>>> problem
>>>>>>>>>>> statement:
>>>>>>>>>>>
>>>>>>>>>>> These unrelated classification events consume resources
>>>>>> per
>>>>>>>>>>> often differs per service function and service function
>>>>>>>> cannot
nsc mailing list
nsc mailing list
nsc mailing list

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Fri, 15 Nov 2013 02:31:41 +0000

Before we move to variant implementations, we need to have a reasonable logical design. That's why separation of different layers is important for the architecture.

If we have in mind that besides omnipotent physical box, there are also demands from NFV, it would be easier to agree that service functions, service chain forwarding layer and transport layer should be separated in the architecture. Based on this, service functions may alter a packet, but they don't need to and shall not know what's the next hop, 'cause this is the job of service chain forwarding layer.

Hongyu

-----Original Message-----
From: Ken Gray [mailto:[email-masked]] 
Sent: Friday, November 15, 2013 1:51 AM
To: Surendra Kumar (smkumar); Jim Guichard (jguichar); Ron Parker
Cc: [email-masked]; Hongyu Li (Julio); David Allan I
Subject: RE: [nsc] FW: re classification & branching, was: Current Proposed SFC charter

+1

My .02.

This separation is a very important architecture consideration IMO. Select services can dictate the forwarding path at a higher level through the service path. Actual forwarding may be left to the forwarding components.

Surendra.

On 11/14/13 7:46 AM, "Jim Guichard (jguichar)" <[email-masked]> wrote:

>>>decides that for certain flows the  traffic should go to d rather 
>>>than c then it *must* force the  forwarding component to direct 
>>>traffic to the new next-hop. While the  service function may not 
>>>modify forwarding in terms of updating  forwarding tables and so 
>>>forth, it has to inform the forwarding  component of its intent 
>>>>precludes the  restriction you mentioned. Forwarding plane can 
>>>>decide whether a  branching action should be taken by 
>>>>reclassification or not per service chain.
>>>>
>>>> Does this make sense?
>>>>
>>>> Hongyu
>>>>
>>>> administrative domain for some of the very reasons you point out. 
>>>> We need to keep focused without trying to boil the ocean right off the bat.
>>>>
>>>>> mechanism (recursive because a user-land application will ride 
>>>>> with a specific policy across potentially different sets of carrier policies).
>>>>>
>>>>>> talking about is the applicability of the classification to branching in SFC.
>>>>>>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 15 Nov 2013 03:15:50 +0000

AB,

On 11/14/13 9:15 AM, "Andre Beliveau" <[email-masked]> wrote:

>Hi, 
>
>In draft-beliveau-sfc-architecture, I was explicit to describe 3 separate
>logical set of components:  the services (SF), the Service Chaining
>enforcement functions and the transport functions because we want to keep
>those separate from each other and have clear interface between them.
>And for now, we should discuss about them in logical term and not
>physical nodes as one physical node might very well include all 3
>functions.
>
--
>The SC enforcement functions should own service chains as defined by an
>operator while an SF might decide to which chain (track) the packet
>should continue its route it should not be able to create new chains
>(tracks).
--
<SK> Yes, service chain creation is a control plane activity. CP creates
corresponding service paths and some SFs may choose one among the
available service-paths for the out-bound packets.

Surendra.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 15 Nov 2013 03:38:54 +0000

You hit it on the head, Ken!

Surendra.

On 11/14/13 9:51 AM, "Ken Gray" <[email-masked]> wrote:

>+1 
>
>Fair-warning - I'm not a huge fan of a fan-out of interface definitions
>(many of which only seem to disappear in implementation because nobody
>really was going to build anything so super-atomic).
>
>That said, from a practical perspective, a service function can operate
>on a packet ... it can transform the packet ...I don't see how you can
>preclude this.  In transforming the packet, it IS potentially altering
>the forwarding on the egress side of the function - depending on the
>logic it used to alter the packet.  Unless we're proposing all of this
>sort of transformation logic is going to suddenly be externalized for all
>service functions, then branching is logically going to happen -
>potentially driven by the service function.
>
>Depending on how you do "fix-up" or whatever your company calls this
>handoff, you involve (or don't) some additional actions in the forwarding
>component - implementation.  So, we're arguing about implementation here
>in this thread, IMO.  Yeah, go ahead and create your interface if it
>clarifies things for you, but it's going to be a logical division and not
>a practical protocol or API.
>
>Finally, without the possibility of branching (which was the fundamental
>question in the title, and we're straying away from it, IMO), you beg an
>entirely centralized control system (every chain, for every circumstance
>is pre-defined).  That too, IMO, is an implementation choice but it's
>enabled by creating roof for it int he architecture.  If you remove
>branching, you remove the choice.
>
>My .02.