Re: [sfc] Metadata structure

[<[e-mail]>]

Re-,

There is a need to assess the validity of those cases (and others which are documented in use-case drafts) to avoid over-specification. The WG need to identify the core functionally and ovoid designing a solution that would be much more complex that current practices. BTW, there should be a way to assess to what extent proposed solutions solves the issues raised in the Problem Statement draft. 

"Flexibility" cannot be blindly used as an argument to justify more complexity. There are trade-offs; we should be aware of those when making design decision. 

I really hope we can follow the principles in RFC1925 and RFC3439; particularly this one: 

" In protocol design, perfection has been reached not when there
        is nothing left to add, but when there is nothing left to take
        away."

My current position on mandatory piece of information to be included in the metadata is recorded in: http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02#section-5.5 that is one single code point.

Cheers,
Med

>-----Message d'origine-----
>De : sfc [mailto:[e-mail]] De la part de Joel M. Halpern
>Envoyé : mercredi 12 février 2014 21:54
>À : Paul Quinn (paulq); Ron Parker
>Cc : Sumandra Majee; [e-mail]; Linda Dunbar
>Objet : Re: [sfc] Metadata structure
>
>Paul, I agree that the various extension headers / options have not seen
>uptake.  This is in aprt due to it being somewhat more complex for the
>hardware.  But mostly because the initial need was not there.
>In this case, we need variable metadata.  The range of metadata that
>people have discussed with me is so high that I can not imagine a fixed
>length header handling even 80% of the cases well.
>
>Yours,
>Joel
>
>On 2/12/14, 3:39 PM, Paul Quinn (paulq) wrote:
>> 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