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

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

Hi:

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