Re: [sfc] Framework

["Reinaldo Penno (repenno)" <[e-mail]>]

On 2/13/14, 11:29 AM, "Joel M. Halpern" <[e-mail]> wrote:

>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.

[RP] The draft only describes the encoding and framework which can be used
in and out of band.

>
>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-fram
>>>>e)
>>>>
>>>>                     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#sectio
>>>>n-
>>>> 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