[sfc] fixed lenght vs. variable length (RE: Framework)

[<[e-mail]>]

Dear Nicolas, all,

(I changed the subject to this specific issue).

In addition to the point you mention, there is also the potential impact on performances.

FWWI, an initial text to discuss this points is available at: http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#section-4.2 

It would be really helpful to record design considerations. 

Cheers,
Med

>-----Message d'origine-----
>De : sfc [mailto:[e-mail]] De la part de Nicolas BOUTHORS
>Envoyé : jeudi 13 février 2014 10:14
>À : Ron Parker; Dave Dolson; Joel M. Halpern; Paul Quinn (paulq)
>Cc : Sumandra Majee; [e-mail]; Linda Dunbar
>Objet : 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 [[e-mail]]
>Sent: Wednesday, February 12, 2014 11:25 PM
>To: Dave Dolson; Joel M. Halpern; Paul Quinn (paulq)
>Cc: Sumandra Majee; [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]]
>Sent: Wednesday, February 12, 2014 5:18 PM
>To: Joel M. Halpern; Ron Parker; Paul Quinn (paulq)
>Cc: Sumandra Majee; [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]] 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]; 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]]
>> Sent: Wednesday, February 12, 2014 4:10 PM
>> To: Ron Parker; Paul Quinn (paulq)
>> Cc: Joel M. Halpern; Sumandra Majee; [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]] 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]; 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]]
>> Sent: Wednesday, February 12, 2014 3:40 PM
>> To: Ron Parker
>> Cc: Sumandra Majee; Linda Dunbar; Joel M. Halpern; [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 <[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]]
>>> Sent: Wednesday, February 12, 2014 3:04 PM
>>> To: Ron Parker; Linda Dunbar; Joel M. Halpern; [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" <[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]] On Behalf Of Linda Dunbar
>>>> Sent: Wednesday, February 12, 2014 12:01 PM
>>>> To: Joel M. Halpern; [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]] On Behalf Of Joel M. Halpern
>>>> Sent: Wednesday, February 12, 2014 10:20 AM
>>>> To: [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]
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>>> _______________________________________________
>>>> sfc mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>>> _______________________________________________
>>>> sfc mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>> _______________________________________________
>>> sfc mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sfc
>>
>> _______________________________________________
>> sfc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>
>_______________________________________________
>sfc mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sfc
>
>
>
>_______________________________________________
>sfc mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sfc