Re: [sfc] Framework

["Joel M. Halpern" <[e-mail]>]

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#sec
>>>> 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
>
>
>
>