Re: [sfc] Framework

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

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-frame)
>>>
>>>                     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#section-
>>> 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
>
>