Re: [sfc] Framework

[Linda Dunbar <[e-mail]>]

I see two types of "metadata" being discussed here:

 1. The "flow metadata", like the transactions carried by http flows. They are inserted by applications, or inserted by a service function to pass some "cookies" to the next one. (many proxy based service functions have those capability)

 2. The "Service Chain metadata", that are inserted by "Chain Classifier" or control plane to carry extra information (in additional to Chain ID) for the purpose of controlling the sequence of functions on a chain. 

Correct? 

IMHO, the first bullet above are specific to applications or service functions internal processing. Many of today's proxy based service functions make changes to data packets, some of them make those changes for other service functions. Those changes won't be in the Service Chain Header field. 

Linda





-----Original Message-----
From: sfc [mailto:[e-mail]] On Behalf Of Sumandra Majee
Sent: Thursday, February 13, 2014 2:51 PM
To: Joel M. Halpern; Jerome Moisand; [e-mail]
Subject: Re: [sfc] Framework

I believe most of us agree that an out of bad signalling will not address the majority of requirement. Also a typical http flow carries many transactions and each can have different or additional classification. So a metadata can not be simple connected with one flow either. Current implementations of proxies and load balancers has addressed this in many ways including custome header insertion. The custom header in this case equivalent of metadata vector. 

I think we need an efficient way annotate actual data with inline metadata. I also strongly believe in solving the 80% of the use case

Regards
Sumandra
________________________________________
From: sfc [[e-mail]] on behalf of Joel M. Halpern [[e-mail]]
Sent: Thursday, February 13, 2014 11:51 AM
To: Jerome Moisand; [e-mail]
Subject: Re: [sfc] Framework

I know very well what GTP does in terms of correlators, and why.
If all you need is an identifier for the subscriber, carrying a short identifier, and using it to select the desired behavior that has been pre-populated when the subscribers session starts works really well.
That is part of why I am not objecting to having provision for out-of-band metadata.

However, claiming that a single such correlator is all that is needed for even 80% of SFC cases (and I very much supporting trying to focus on the 80% cases), just does not seem to work, given the broad range of requirements that we have seen.

Yours,
Joel

On 2/13/14, 2:35 PM, Jerome Moisand wrote:
> Joel,
>
> Protocols like GTP and L2TP work exactly that, with a form of session correlator between the data plane and the control plane. This is very handy for subscriber and service management. Also if a correlator is defined as an opaque and unique number, then one can avoid some of the pitfalls you described. Long-lived metadata is clearly useful (and thanks for sharing, Reinaldo, will read), and there is clear applicability to various service chaining needs.
>
> Now this is just one way. The I-D Bruno referred to was just listing this approach as one possible way among others. I totally agree with you that other forms of metadata (like an outcome of the classification of a packet or a sequence of a few packets) may not be suitable for out-of-band signaling.
>
> Bottomline seems to be that we have too many options to choose from, and none of them solving it all... Tough.
>
> -----Original Message-----
> From: sfc [mailto:[e-mail]] On Behalf Of Joel M. Halpern
> Sent: Thursday, February 13, 2014 2:29 PM
> To: [e-mail]
> Subject: Re: [sfc] Framework
>
> As I understand it, the tsvwg (and aeon) work is about flow metadata.
> That is long-lived metadata of use across many packets.  That does indeed seem well-suited to out-of-band cases.
>
> My concern is that in SFC, there are many cases which are at best badly-addressed if we insist that they be solved using out-of-band metadata.
>
> Yours,
> Joel
>
> On 2/13/14, 2:22 PM, Reinaldo Penno (repenno) wrote:
>> There is draft about transport independent metadata.
>>
>> http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding
>> -
>> 01
>>
>> The complexities you mention are discussed there: variable-encoding, 
>> direction, security of metadata, etc.
>>
>> Thanks,
>>
>> -RP
>>
>>
>> On 2/13/14, 11:15 AM, "Joel M. Halpern" <[e-mail]> wrote:
>>
>>> While there are cases where out-of-band metadata makes sense, There 
>>> are many cases I would not want to try to cover that way.  The best 
>>> examples are situations where the metadata changes from packet to 
>>> packet (such as the data produced by a DPI engine for consumption by 
>>> other applications in the chain.)
>>>
>>> More importantly, if you are putting correlators in the packet, it 
>>> is still very complex if you want to use one correlator to handle 
>>> metadata produced by several different entities (the initial 
>>> classifer, the DPI engine, ...)  You quickly end up deciding that 
>>> you need several correlators.  At which point we are back to variable amounts of metadata.
>>>
>>> The alternative is to require exceedingly specific and strong 
>>> coupling to a mandated out-of-band mechanism.  That seems to me to 
>>> be a very bad idea.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 2/13/14, 1:40 PM, Bruno Rijsman wrote:
>>>> resend to avoid "too many recipients" warning
>>>>
>>>>
>>>> On Thu, Feb 13, 2014 at 1:39 PM, Bruno Rijsman 
>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>>       There are ways to signal variable length amounts of metadata without
>>>>       needing an additional variable-length header on each data packet.
>>>>
>>>>       draft-rijsman-sfc-metadata-considerations-00 discusses some of the
>>>>       possible approaches: out-of-band signaling (congruent or
>>>>       non-congruent) or a hybrid approach using a fix-length in-band
>>>>       correlator and out-of-band additional metadata.  See sections 3.3,
>>>>       3.4 and 3.5 in the draft.
>>>>
>>>>       The issue of fixed-length encoding versus variable length encoding
>>>>       is discussion in the challenges chapter in section 4.3.  I should
>>>>       probably mention the MTU and segmentation issues as well in that
>>>>       section.
>>>>
>>>>
>>>>       On Thu, Feb 13, 2014 at 1:16 PM, Joel M. Halpern
>>>>       <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>>           The variable length shim header is needed even if every
>>>>           individual piece of metadata has a fixed length.  Different
>>>>           service chains will need different combinations of metadata.  So
>>>>           the metadata portion of the header needs to be variable length.
>>>>
>>>>           I think the approach of a fixed length initial part, and a
>>>>           variable length extension part, is the right model.
>>>>
>>>>           Yours,
>>>>           Joel
>>>>
>>>>
>>>>           On 2/13/14, 11:13 AM, Jerome Moisand wrote:
>>>>
>>>>               Yes, fragmentation and variable headers are usually a really
>>>>               bad thing for forwarding performance. Let's not forget that
>>>>               we live in a 100G-ish kind of world nowadays.
>>>>
>>>>               Now the question should be: WHY would we want to do that
>>>>               (variable headers leading to fragmentation issues)?
>>>>
>>>>               For example, the type of metadata that may require
>>>>               variable-length fields might be a better candidate for some
>>>>               out-of-band signaling mechanism. If this is service
>>>>               authorization data (e.g. a service profile/policy), this
>>>>               sounds likely. Not 100% sure this is true for all use cases
>>>>               though. Only a good understanding of use cases, grounded by
>>>>               reflecting on existing network architectures (notably
>>>>               broadband, fixed or mobile), would tell us if one approach
>>>>               or another is the most appropriate.
>>>>
>>>>               Anyhoo, we're jumping way deep in the detailed protocol
>>>>               design here. This seems a tad premature.
>>>>
>>>>               -----Original Message-----
>>>>               From: sfc [mailto:[e-mail]
>>>>               <mailto:[e-mail]>] On Behalf Of Dave Dolson
>>>>               Sent: Thursday, February 13, 2014 11:03 AM
>>>>               To: '[e-mail] <mailto:[e-mail]>';
>>>>               'Ron_Parker@affirmednetworks.__com
>>>>               <mailto:[e-mail]>';
>>>>               '[e-mail]
>>>>               <mailto:[e-mail]>'__;
>>>>               '[e-mail]
>>>>               <mailto:[e-mail]>'; '[e-mail]
>>>>               <mailto:[e-mail]>'
>>>>               Cc: '[e-mail]'; '[e-mail] <mailto:[e-mail]>';
>>>>               '[e-mail] <mailto:[e-mail]>'
>>>>               Subject: Re: [sfc] Framework
>>>>
>>>>               it is overall more efficient to support PMTU discovery
>>>>               rather than fragmenting every large packet. The is why TCP
>>>>               adopted it so early on.
>>>>
>>>>               The fragmenting also puts huge performance burden on the
>>>>               service functions.
>>>>               Fragmenting may also affect the ability of load balancers to
>>>>               get each fragment to the correct destination.
>>>>
>>>>               So PMTU discovery SHOULD be used, in my opinion. By this I
>>>>               mean the client or server is informed that its packets are
>>>>               too big (for IPv6 or IPv4 with DF=1).
>>>>
>>>>               Some operators may wish to incur the extra cost to hide the
>>>>               existence of the tunneling, when the elements of the chain
>>>>               can support it, so we could consider that as an optional
>>>>               mechanism.
>>>>
>>>>               -Dave
>>>>
>>>>
>>>>               ----- Original Message -----
>>>>               From: Joel M. Halpern [mailto:[e-mail]
>>>>               <mailto:[e-mail]>]
>>>>               Sent: Thursday, February 13, 2014 10:31 AM
>>>>               To: Ron Parker <Ron_Parker@affirmednetworks.__com
>>>>               <mailto:[e-mail]>>;
>>>>               [e-mail]
>>>>               <mailto:[e-mail]>
>>>>               <[e-mail]
>>>>               <mailto:[e-mail]>>__; Dave Dolson;
>>>>               '[e-mail]
>>>>               <mailto:[e-mail]>'
>>>>               <[e-mail]
>>>>               <mailto:[e-mail]>>; '[e-mail]
>>>>               <mailto:[e-mail]>' <[e-mail]
>>>>               <mailto:[e-mail]>>
>>>>               Cc: '[e-mail]' <[e-mail]>; '[e-mail]
>>>>               <mailto:[e-mail]>' <[e-mail] <mailto:[e-mail]>>;
>>>>               '[e-mail] <mailto:[e-mail]>'
>>>>               <[e-mail] <mailto:[e-mail]>>
>>>>               Subject: Re: [sfc] Framework
>>>>
>>>>               I mostly agree with you Ron.  I can probably come up with
>>>>               some other variations, but your second point is that the
>>>>               transport must deal with the issue of frame size / fit.
>>>>
>>>>               I would note that if we assume that the carrying encaps
>>>>               (IPv4/v6 outer) is being fragmented, then we are assuming
>>>>               that the exit from service chaining can and will reassemble.
>>>>
>>>>               Yours,
>>>>               Joel
>>>>
>>>>               On 2/13/14, 10:18 AM, Ron Parker wrote:
>>>>
>>>>                   Joel,
>>>>
>>>>                   That is an excellent point to consider when choosing
>>>>                   transport
>>>>                   encapsulations.   If the transport encapsulation is IPv4
>>>>                   or IPv6
>>>>                   based (i.e., IPx/UDP, IPx/GRE, IPx/UDP/VxLAN, 
>>>> etc.), then
>>>>                   fragmentation and defragmentation are naturally
>>>>                   supported.    If the
>>>>                   transport encapsulation is VLAN, MPLS, etc., then I
>>>>                   believe one of the
>>>>                   following must be true:
>>>>
>>>>                   * The end-to-end path is known to support the resulting
>>>>                   larger frames
>>>>                   * A path discovery mechanism is mandated by SFC when
>>>>                   non-IP transports
>>>>                   are used * An SFC-specific fragmentation header and
>>>>                   mechanisms must be
>>>>                   defined (i.e.,
>>>>
>>>> SFC-transport/SFC-__fragmentation/SFC-service/__original-packet-or-
>>>> f
>>>> rame)
>>>>
>>>>                      Ron
>>>>
>>>>
>>>>                   -----Original Message----- From: Joel M. Halpern
>>>>                   [mailto:[e-mail]
>>>>                   <mailto:[e-mail]>] Sent: Thursday, February
>>>>                   13, 2014 10:10
>>>>                   AM To: [e-mail]
>>>>                   <mailto:[e-mail]>; Dave Dolson;
>>>>                   '[e-mail]
>>>>                   <mailto:[e-mail]>'; Ron Parker;
>>>>                   '[e-mail] <mailto:[e-mail]>' Cc:
>>>>                   '[e-mail]'; '[e-mail] <mailto:[e-mail]>';
>>>>                   '[e-mail]
>>>>                   <mailto:[e-mail]>' Subject:
>>>>                   Re: [sfc] Framework
>>>>
>>>>                   There is a related complexity. I hope that we expect to
>>>>                   support IPv6.
>>>>                   IPv6 explicitly prohibits network elements from
>>>>                   fragmenting end user
>>>>                   packets.
>>>>
>>>>                   Yours, Joel
>>>>
>>>>                   On 2/13/14, 8:21 AM, [e-mail]
>>>>                   <mailto:[e-mail]> wrote:
>>>>
>>>>                       Re-,
>>>>
>>>>                       FWIW, one of the existing architecture drafts
>>>>                       includes the following
>>>>                       behavior
>>>>
>>>> (http://tools.ietf.org/html/__draft-boucadair-sfc-framework-__02#se
>>>> c
>>>> tion-
>>>> 6
>>>>
>>>> <http://tools.ietf.org/html/draft-boucadair-sfc-framework-02#section-6>):
>>>>
>>>>
>>>>
>>>>               "
>>>>
>>>>                       6. Fragmentation Considerations
>>>>
>>>>                       If adding the Service Chaining Header would result
>>>>                       in a fragmented
>>>>                       packet, the classifier should include a Service
>>>>                       Chaining Header in
>>>>                       each fragment.  Doing so would prevent SF Nodes to
>>>>                       dedicate resource
>>>>                       to handle fragments. "
>>>>
>>>>                       Cheers, Med
>>>>
>>>>
>>>>                           -----Message d'origine----- De : sfc
>>>>                           [mailto:[e-mail]
>>>>                           <mailto:[e-mail]>]
>>>>                           De la part de Dave Dolson Envoyé :
>>>>                           jeudi 13 février 2014 13:39 À :
>>>>                           '[e-mail]
>>>>                           <mailto:[e-mail]>';
>>>>                           'Ron_Parker@affirmednetworks.__com
>>>>                           <mailto:[e-mail]>';
>>>>                           '[e-mail] 
>>>> <mailto:[e-mail]>';
>>>>                           '[e-mail] <mailto:[e-mail]>' Cc :
>>>>                           '[e-mail]'; '[e-mail]
>>>>                           <mailto:[e-mail]>';
>>>>                           '[e-mail]
>>>>                           <mailto:[e-mail]>' Objet : Re:
>>>>                           [sfc] Framework
>>>>
>>>>                           Good point to consider fragmentation.
>>>>
>>>>                           We should design the encapsulation such that the
>>>>                           forwarding
>>>>                           functions do not need to reassemble. Each
>>>>                           fragment should be
>>>>                           independently forwardable; some SFs may choose
>>>>                           to ignore these
>>>>                           packets.
>>>>
>>>>                           Any layer 2.5 protocol like VLAN or MPLS would
>>>>                           support this.
>>>>                           Otherwise, a reassembly layer could be added
>>>>                           after the forwarding
>>>>                           coordinates. Think of something like the IPv6
>>>>                           reassembly option
>>>>                           after a GRE header, for instance.
>>>>
>>>>                           IP | GRE | reassem | frag data
>>>>
>>>>                           We could alternatively mandate the inner IP be
>>>>                           fragmented and that
>>>>                           path-MTU discovery be supported.
>>>>
>>>>
>>>>
>>>>
>>>>                           ----- Original Message ----- From: 
>>>> Nicolas BOUTHORS
>>>>                           [mailto:Nicolas.BOUTHORS@__qosmos.com
>>>>                           <mailto:[e-mail]>] Sent:
>>>>                           Thursday, February 13,
>>>>                           2014 04:13 AM To: Ron Parker
>>>>                           <Ron_Parker@affirmednetworks.__com
>>>>                           <mailto:[e-mail]>>;
>>>>                           Dave Dolson; Joel M. Halpern
>>>>                           <[e-mail]
>>>>                           <mailto:[e-mail]>>; Paul Quinn
>>>>                           (paulq) <[e-mail]
>>>>                           <mailto:[e-mail]>> Cc: Sumandra Majee
>>>>                           <[e-mail]>;
>>>>                           [e-mail] <mailto:[e-mail]> <[e-mail]
>>>>                           <mailto:[e-mail]>>; Linda Dunbar
>>>>                           <[e-mail]
>>>>                           <mailto:[e-mail]>>
>>>>                           Subject: Re: [sfc] Framework
>>>>
>>>>                           If we do not enforce a fix header size we have
>>>>                           other implication.
>>>>
>>>>                           There is the question of segmentation and
>>>>                           reassembly responsibility
>>>>                           as well.
>>>>
>>>>                           If adding length to the service header forces
>>>>                           segmentation, then
>>>>                           whose responsibility is it to reassemble the
>>>>                           payload before passing
>>>>                           it to the SF.
>>>>
>>>>                           Similar question for packet re-ordering.
>>>>
>>>>
>>>>                           __________________________________________ From:
>>>>                           Ron Parker
>>>>                           [Ron_Parker@affirmednetworks.__com
>>>>                           <mailto:[e-mail]>] Sent:
>>>>                           Wednesday, February 12,
>>>>                           2014 11:25 PM To: Dave Dolson; Joel M. Halpern;
>>>>                           Paul Quinn
>>>>                           (paulq) Cc: Sumandra Majee; [e-mail]
>>>>                           <mailto:[e-mail]>; Linda Dunbar Subject:
>>>>                           Re: [sfc] Framework
>>>>
>>>>                           Dave,
>>>>
>>>>                           Yes, that is a good point if we logically
>>>>                           separate the forwarding
>>>>                           function from the SFC-aware service function, as
>>>>                           we should.   The
>>>>                           forwarding function is concerned with only the
>>>>                           inbound transport
>>>>                           header, the fixed  portion of the service header
>>>>                           containing the
>>>>                           chain information, and the outbound transport
>>>>                           header.    The
>>>>                           service function may look at the entirety of the
>>>>                           service header and
>>>>                           would look at the encapsulated packet.
>>>>
>>>>                           Ron
>>>>
>>>>
>>>>                           -----Original Message----- From: Dave Dolson
>>>>                           [mailto:[e-mail]
>>>>                           <mailto:[e-mail]>] Sent: Wednesday,
>>>>                           February 12, 2014
>>>>                           5:18 PM To: Joel M. Halpern; Ron Parker; Paul
>>>>                           Quinn (paulq) Cc:
>>>>                           Sumandra Majee; [e-mail]
>>>>                           <mailto:[e-mail]>; Linda Dunbar Subject: RE:
>>>>                           [sfc]
>>>>                           Framework
>>>>
>>>>                           The forwarding plane might not even need to look
>>>>                           at the encapsulated
>>>>                           packet.
>>>>
>>>>                           For example, (if the SF Identifier is a VLAN
>>>>                           tag), an Ethernet
>>>>                           switch can forward packets of the form:  Ether |
>>>>                           VLAN | BLOB.
>>>>
>>>>
>>>>
>>>>                           -----Original Message----- From: sfc
>>>>                           [mailto:[e-mail]
>>>>                           <mailto:[e-mail]>]
>>>>                           On Behalf Of Joel M. Halpern Sent:
>>>>                           Wednesday, February 12, 2014 4:30 PM To: Ron
>>>>                           Parker; Dave Dolson;
>>>>                           Paul Quinn (paulq) Cc: Sumandra Majee;
>>>>                           [e-mail] <mailto:[e-mail]>; Linda Dunbar
>>>>                           Subject: Re: [sfc] Framework
>>>>
>>>>                           I agree as well. Yours, Joel
>>>>
>>>>                           On 2/12/14, 4:24 PM, Ron Parker wrote:
>>>>
>>>>                               Hi, Dave.
>>>>
>>>>                               I  Agree with your statement.    And if the
>>>>                               total length of the
>>>>                               header is
>>>>
>>>>                           contained in the mandatory portion, the hardware
>>>>                           implementation can
>>>>                           easily locate the encapsulated packet.
>>>>
>>>>
>>>>                               Ron
>>>>
>>>>
>>>>                               -----Original Message----- From: Dave Dolson
>>>>                               [mailto:[e-mail]
>>>>                               <mailto:[e-mail]>] Sent:
>>>>                               Wednesday, February 12,
>>>>                               2014 4:10 PM To: Ron Parker; Paul Quinn
>>>>                               (paulq) Cc: Joel M.
>>>>                               Halpern; Sumandra Majee; [e-mail]
>>>>                               <mailto:[e-mail]>; Linda Dunbar Subject:
>>>>                               RE: [sfc] Framework
>>>>
>>>>                               I think a good approach would be:
>>>>
>>>>                               The information required for forwarding (the
>>>>                               SF Identifier) should
>>>>                               be in
>>>>
>>>>                           a mandatory fixed-size header.
>>>>
>>>>
>>>>                               Optional information (if any) is NOT to be
>>>>                               used for forwarding, but
>>>>                               is
>>>>
>>>>                           for consumption by one or more of the
>>>>                           applications in the chain.
>>>>
>>>>
>>>>                               Then the forwarding plane, and even the PDP,
>>>>                               can be agnostic about
>>>>                               the
>>>>
>>>>                           meta-data.
>>>>
>>>>
>>>>                               -Dave
>>>>
>>>>
>>>>                               -----Original Message----- From: sfc
>>>>                               [mailto:[e-mail]
>>>>                               <mailto:[e-mail]>]
>>>>                               On Behalf Of Ron Parker Sent:
>>>>                               Wednesday, February 12, 2014 4:05 PM To:
>>>>                               Paul Quinn (paulq) Cc:
>>>>                               Joel M. Halpern; Sumandra Majee;
>>>>                               [e-mail] <mailto:[e-mail]>; 
>>>> Linda Dunbar
>>>>                               Subject: Re: [sfc] Framework
>>>>
>>>>                               Paul,
>>>>
>>>>                               That is why I am proposing a hybrid where
>>>>                               extensions or options can
>>>>                               be
>>>>
>>>>                           added but the total length is contained in the
>>>>                           fixed portion.   I
>>>>                           can envision certain deployments (e.g.,
>>>>                           Enterprise) where perhaps
>>>>                           extensions are not needed and the SFC
>>>>                           functionality is realized
>>>>                           in hardware.   And, I can envision certain other
>>>>                           deployments
>>>>                           (e.g., 3gpp) where the extension headers add
>>>>                           sufficient value to
>>>>                           justify software based implementations.
>>>>
>>>>
>>>>                               Ron
>>>>
>>>>
>>>>                               -----Original Message----- From: Paul Quinn
>>>>                               (paulq)
>>>>                               [mailto:[e-mail]
>>>>                               <mailto:[e-mail]>] Sent: Wednesday,
>>>>                               February 12, 2014
>>>>                               3:40 PM To: Ron Parker Cc: Sumandra Majee;
>>>>                               Linda Dunbar; Joel M.
>>>>                               Halpern; [e-mail] <mailto:[e-mail]>
>>>>                               Subject: Re: [sfc] Framework
>>>>
>>>>                               Hi,
>>>>
>>>>                               We certainly need to be very careful with
>>>>                               variable length headers
>>>>                               when
>>>>
>>>>                           hardware platform are in play.
>>>>
>>>>
>>>>                               Ron, your examples of IP options and v6 EH
>>>>                               have both suffered from
>>>>
>>>>                           significant implementation and deployment
>>>>                           hurdles due to the
>>>>                           complexity and cost associated with hardware
>>>>                           support for the
>>>>                           option/EH.
>>>>
>>>>
>>>>                               Paul
>>>>
>>>>                               On Feb 12, 2014, at 3:10 PM, Ron Parker
>>>>                               <Ron_Parker@affirmednetworks.__com
>>>>
>>>> <mailto:[e-mail]>>
>>>>
>>>>                           wrote:
>>>>
>>>>
>>>>                                   Hi, Sumandra.
>>>>
>>>>                                   Regarding service header flexibility, I
>>>>                                   completely agree.   I
>>>>                                   might
>>>>
>>>>                           suggest a compromise between hardware
>>>>                           friendliness and software
>>>>                           flexibility.    If the header had the ability to
>>>>                           add extensions
>>>>                           (perhaps similar to IPv6) but also had the
>>>>                           header length encoded in
>>>>                           the mandatory part (like IPv4), then a hardware
>>>>                           implementation would
>>>>                           be free to skip over the extensions (in cases
>>>>                           where the deployment
>>>>                           justifies ignoring the extensions).
>>>>
>>>>
>>>>                                   Ron
>>>>
>>>>
>>>>                                   -----Original Message----- From:
>>>>                                   Sumandra Majee
>>>>                                   [mailto:[e-mail]
>>>>                                   <mailto:[e-mail]>] Sent:
>>>>                                   Wednesday, February 12, 2014
>>>>                                   3:04 PM To: Ron Parker; Linda Dunbar;
>>>>                                   Joel M. Halpern;
>>>>                                   [e-mail] <mailto:[e-mail]>
>>>>                                   Subject: Re: [sfc] Framework
>>>>
>>>>                                           For all of those reasons, I
>>>>                                           strongly support a 
>>>> canonical service
>>>>                                           header that is independent of
>>>>                                           the transport methodology.
>>>>
>>>>
>>>>
>>>>                                   I agree. However the format of service
>>>>                                   header should be
>>>>                                   standardized in
>>>>
>>>>                           a way that is flexible. Some of us would like to
>>>>                           see variable length
>>>>                           header that is also HW friendly. The service
>>>>                           header can be
>>>>                           represented as a mandotory fixed length header
>>>>                           (like IP
>>>>                           header) along with an optional variable length
>>>>                           attribute field.
>>>>                           Different services can be interested in
>>>>                           different metadata, for
>>>>                           example subscriber ID could be of interest in
>>>>                           the mobile core
>>>>                           service chain only.
>>>>
>>>>
>>>>                                   Sumandra
>>>>
>>>>                                   On 2/12/14, 11:32 AM, "Ron Parker"
>>>>                                   
>>>> <Ron_Parker@affirmednetworks.__com
>>>>
>>>> <mailto:[e-mail]>>
>>>>
>>>>                           wrote:
>>>>
>>>>
>>>>                                       Linda,
>>>>
>>>>                                       My interpretation of the
>>>>                                       architecture docs is that the 
>>>> service
>>>>                                       function chain is built in an
>>>>                                       abstract manner (i.e., SF-A then
>>>>                                       SF-B
>>>>
>>>>                           then SF-C).
>>>>
>>>>                                       Separately, a locator table provides
>>>>                                       network location for
>>>>                                       each of those service functions.
>>>>                                       In this way, you can
>>>>                                       locate the service functions
>>>>
>>>>                           in
>>>>
>>>>                                       a manner appropriate to the type of
>>>>                                       transport you are
>>>>                                       using.   If you want that to be
>>>>                                       interface+VLAN,
>>>>                                       gateway-IP+MPLS label stack, 
>>>> IP
>>>>
>>>>                           address,
>>>>
>>>>                                       GRE tunnel remote IP + key, etc.,
>>>>                                       you can do that.    You
>>>>                                       can even potentially locate
>>>>                                       different service functions that
>>>>                                       reside in the same chain with
>>>>                                       different flavors of
>>>>                                       network locators.    Another
>>>>                                       justification to separate the
>>>>                                       identity of a service function from
>>>>                                       its network location is
>>>>                                       load balancing.   If, for example,
>>>>                                       SF-A had 3 IP addresses,
>>>>                                       that would imply load balancing to 3
>>>>                                       instances using IP as a
>>>>                                       transport layer.
>>>>
>>>>                                       For all of those reasons, I strongly
>>>>                                       support a canonical service
>>>>                                       header that is independent of the
>>>>                                       transport
>>>>                                       methodology.    At a particular
>>>>                                       node, the decision as to
>>>>                                       where to go next should be based
>>>>                                       solely on information carried in
>>>>                                       the canonical service header and not
>>>>                                       on the
>>>>
>>>>                           fields
>>>>
>>>>                                       in the transport header.   That is,
>>>>                                       the SFC node discards
>>>>                                       the transport header and extracts
>>>>                                       the chain ID from the
>>>>                                       service header.    Through
>>>>                                       mechanisms we have not yet begun
>>>>                                       to discuss, the SFC node knows how
>>>>                                       to interpret the chain ID and
>>>>                                       ultimately how to progress 
>>>> the packet.
>>>>
>>>>                                       Ron
>>>>
>>>>
>>>>                                       -----Original Message----- From: sfc
>>>>                                       [mailto:[e-mail]
>>>>                                       <mailto:[e-mail]>] On
>>>>                                       Behalf Of Linda Dunbar
>>>>                                       Sent: Wednesday, February 12, 2014
>>>>                                       12:01 PM To: Joel M.
>>>>                                       Halpern; [e-mail]
>>>>                                       <mailto:[e-mail]> Subject: Re:
>>>>                                       [sfc] Framework
>>>>
>>>>                                       Agree with Joel's statement.
>>>>
>>>>                                       I think a simple sentence below
>>>>                                       should be added Section 5.2 (SFC
>>>>                                       Classifier) to emphasize this point.
>>>>
>>>>                                       "A Service Chain Classifier node can
>>>>                                       associate a unique Layer 2
>>>>                                       or 3 Label (e.g. VLAN, MPLS label)
>>>>                                       to the packets in the flow.
>>>>                                       Those Layer 2 or 3 Label makes it
>>>>                                       easier for subsequent nodes
>>>>                                       along the flow path to steer the
>>>>                                       flow to the service functions
>>>>                                       specified by the flow's 
>>>> service chain."
>>>>
>>>>
>>>>                                       Linda -----Original Message-----
>>>>                                       From: sfc
>>>>                                       [mailto:[e-mail]
>>>>                                       <mailto:[e-mail]>] On
>>>>                                       Behalf Of Joel M. Halpern
>>>>                                       Sent: Wednesday, February 12, 2014
>>>>                                       10:20 AM To:
>>>>                                       [e-mail] <mailto:[e-mail]>
>>>>                                       Subject: [sfc] Framework
>>>>
>>>>                                       I was looking at the framework
>>>>                                       proposal. The proposal has a very
>>>>                                       specific model of the scope of the
>>>>                                       transport header (that it is
>>>>                                       derived from, and relates only to,
>>>>                                       the first service function to
>>>>                                       which the packet will be directed.
>>>>                                       That is clearly an operational
>>>>                                       model we need to support.
>>>>
>>>>                                       However, I would like to allow other
>>>>                                       transport operational
>>>>                                       models, such as the use of a VLAN to
>>>>                                       direct traffic along a
>>>>                                       chain.  Or the use of an MPLS label,
>>>>                                       or an MPLS label stack.
>>>>
>>>>                                       Yours, Joel M. Halpern
>>>>
>>>>
>>>> _________________________________________________
>>>>                                       sfc mailing list
>>>>                                       [e-mail] 
>>>> <mailto:[e-mail]>
>>>>
>>>> https://www.ietf.org/mailman/__listinfo/sfc
>>>>
>>>> <https://www.ietf.org/mailman/listinfo/sfc>
>>>>
>>>>
>>>> _________________________________________________
>>>>                                       sfc mailing list
>>>>                                       [e-mail] 
>>>> <mailto:[e-mail]>
>>>>
>>>> https://www.ietf.org/mailman/__listinfo/sfc
>>>>
>>>> <https://www.ietf.org/mailman/listinfo/sfc>
>>>>
>>>>
>>>> _________________________________________________
>>>>                                       sfc mailing list
>>>>                                       [e-mail] 
>>>> <mailto:[e-mail]>
>>>>
>>>> https://www.ietf.org/mailman/__listinfo/sfc
>>>>
>>>> <https://www.ietf.org/mailman/listinfo/sfc>
>>>>
>>>>
>>>>
>>>> _________________________________________________
>>>>                                   sfc mailing list
>>>>                                   [e-mail] 
>>>> <mailto:[e-mail]>
>>>>
>>>> https://www.ietf.org/mailman/__listinfo/sfc
>>>>
>>>> <https://www.ietf.org/mailman/listinfo/sfc>
>>>>
>>>>
>>>>
>>>> _________________________________________________
>>>>                               sfc mailing list
>>>>                               [e-mail] <mailto:[e-mail]>
>>>>                               
>>>> https://www.ietf.org/mailman/__listinfo/sfc
>>>>
>>>> <https://www.ietf.org/mailman/listinfo/sfc>
>>>>
>>>>
>>>>
>>>> _________________________________________________ sfc
>>>>                           mailing list
>>>>                           [e-mail] <mailto:[e-mail]>
>>>>                           https://www.ietf.org/mailman/__listinfo/sfc
>>>>                           
>>>> <https://www.ietf.org/mailman/listinfo/sfc>
>>>>
>>>>
>>>>
>>>>
>>>> _________________________________________________ sfc
>>>>                           mailing list
>>>>                           [e-mail] <mailto:[e-mail]>
>>>>                           https://www.ietf.org/mailman/__listinfo/sfc
>>>>                           
>>>> <https://www.ietf.org/mailman/listinfo/sfc>
>>>>
>>>>
>>>> _________________________________________________ sfc
>>>>                           mailing list
>>>>                           [e-mail] <mailto:[e-mail]>
>>>>                           https://www.ietf.org/mailman/__listinfo/sfc
>>>>                           
>>>> <https://www.ietf.org/mailman/listinfo/sfc>
>>>>
>>>>
>>>>
>>>>
>>>>               _________________________________________________
>>>>               sfc mailing list
>>>>               [e-mail] <mailto:[e-mail]>
>>>>               https://www.ietf.org/mailman/__listinfo/sfc
>>>>               <https://www.ietf.org/mailman/listinfo/sfc>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>           _________________________________________________
>>>>           sfc mailing list
>>>>           [e-mail] <mailto:[e-mail]>
>>>>           https://www.ietf.org/mailman/__listinfo/sfc
>>>>           <https://www.ietf.org/mailman/listinfo/sfc>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> sfc mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sfc
>>
>>
>
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>
>
>
>

_______________________________________________
sfc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sfc