Re: [sfc] comments on draft-quinn-sfc-problem-statement-02

Jim,
Most certainly. CCing them. I am at the IETF if anyone wants to talk.
Otherwise, I hope the changes are simple enough to suck in.

cheers,
jamal

On Tue, Mar 4, 2014 at 10:54 AM, Jim Guichard (jguichar)
<jguichar@cisco.com> wrote:
> Hi Jamal,
> Please can you work with the editors of the problem statement to discuss your suggested changes and requirements.. Many thanks for you inputs.
>
> Sent from my iPhone
>
>> On Mar 3, 2014, at 10:45 AM, "Jamal Hadi Salim" <hadi@mojatatu.com> wrote:
>>
>> Jim,
>> Finally getting back to this (I am at the meeting as i type this); here are some
>> suggestions, section 3 - bullet #4:
>>
>> ---------
>>> Dataplane Metadata: Data plane metadata provides the ability to
>>> exchange information between the network and service functions,
>>> between service functions, and service functions and the network.
>>> Metadata can include the result of antecedent classification,
>>> information from external sources or forwarding related data.
>>> For example, service functions utilize metadata, as required, for
>>> localized policy decisions.
>>
>> to:
>>
>>> Dataplane Metadata: Data plane metadata provides the ability to
>>> exchange information between the network and service functions,
>>> between service functions, and service functions and the network.
>>> Metadata can include the result of antecedent classification,
>>> information from external sources or forwarding related data.
>>> For example, service functions utilize metadata, as required, for
>>> localized policy decisions
>> or global (across service chain) pipeline stage processing indices.
>>
>> YMMV, I feel it may require more text as to what is meant as "pipeline
>> stage processing index".
>>
>> The one more requirement we have may be more solution space on achieving
>> pipeline indexing, but could fit in the problem statement, to be specific:
>> we have a requirement to be able pass arbitrary metadata between
>> nodes (means desire to have more than just basic 32/64 bit constructs).
>>
>> It may mean adding one or two more sentences above.
>> Thoughts?
>>
>> cheers,
>> jamal
>>
>>
>>
>>
>> On Tue, Jan 14, 2014 at 8:19 AM, Jim Guichard (jguichar)
>> <jguichar@cisco.com> wrote:
>>> Hi Jamal,
>>>
>>> Thanks for this input. Comments inline.
>>>
>>>> On 1/14/14 6:16 AM, "Jamal Hadi Salim" <hadi@mojatatu.com> wrote:
>>>>
>>>> Some context:
>>>> ForCES is defining what is known as the inter-FE LFB
>>>> (http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-03)
>>>> to describe chaining of network functions.
>>>>
>>>> One of the desires ForCES has is for horizontal scaling of
>>>> network functions/service.
>>>> We would like to take a network function or service and split
>>>> its parts across several processing resources. This requires to
>>>> pass around relevant "Pipeline stage indices"
>>>> Brad McConnell did touch on it here (slide 6):
>>>> http://www.ietf.org/proceedings/87/slides/slides-87-nsc-6.pdf
>>>>
>>>> This view is missing from the problem space.
>>>
>>> Jim> I agree. Do you have suggested text that can be reviewed and
>>> discussed further?
>>>
>>>>
>>>> Additionally - we have a requirement to be able pass arbitrary
>>>> metadata between nodes (means desire to have more than just
>>>> basic 32/64 bit constructs)
>>>
>>> Jim> I think this is an area that will require some discussion as part of
>>> the SFC architecture. The problem statement has no "solution" text and
>>> simply states that metadata between the network and SF's, and between
>>> SF's, is needed. The format of that metadata should be discussed outside
>>> of the problem statement.
>>>
>>>>
>>>> cheers,
>>>> jamal
>>>> _______________________________________________
>>>> sfc mailing list
>>>> sfc@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>