Re: [sfc] NSH MD-1 description

I seem to be missing your point Behcet.  Can I ask you to explain?
The concern that was raised was that the description of the MD-1 data as 
being 4x4 bytes was confusing.  The proposal, given the way we are using 
it, was to treat it as a 16 byte block.  There seemed to be working 
group agreement on that, so Jim call the observed rough consensus.

You seem to be arguing for some other aspects of the interpretation 
question, separate from the way we talk about the size of the fields. 
If you have some other concern, and have new information to raise 
relative to that concern, I would be happy to hear it.

Yours,
Joel

On 11/4/16 5:11 PM, Behcet Sarikaya wrote:
> Hi Jim,
>
>
> On Fri, Nov 4, 2016 at 3:25 PM, Jim Guichard (jguichar)
> <jguichar@cisco.com> wrote:
>> Hi Behcet,
>>
>> Please see my earlier email and https://trac.tools.ietf.org/wg/sfc/trac/ticket/22 where rough consensus has been reached to change the 4 contexts to a single 16-byte fixed context header. This change will be reflected in the next revision of the NSH document.
>>
>
> I am not sure.
>
> That might bring the question of why 1?
>
> I think that we need a more flexible mechanism.
>
> Regards,
>
> Behcet
>> Jim
>>
>>
>>
>>
>> On 11/4/16, 4:13 PM, "sfc on behalf of Behcet Sarikaya" <sfc-bounces@ietf.org on behalf of sarikaya2012@gmail.com> wrote:
>>
>>> I think that definitely some action is needed on the definition of
>>> metadata Type 1
>>>
>>> draft-ietf-sfc-nsh-10
>>>
>>> I have never been able to figure out why
>>>
>>> four Context Headers,
>>>   4-byte each, MUST be added immediately following the Service Path Header.
>>>
>>> What is the role of the number 4? It has not been explained in the document.
>>>
>>> Different use cases have different requirements and I have not seen 4
>>> MD Type 1 defined in a sensible manner for each use case that we know
>>> so far. There is a proposal for the data center use case in
>>> draft-guichard which contains exactly 4 data types. That seems to be
>>> about it.
>>>
>>> For the mobility use there is a proposal but it defines 3 data not 4.
>>>
>>> I don't understand why this point waited so long (until Rev. 11) to get fixed?
>>>
>>> I think fixing it is not going to be easy, it should have been
>>> addressed much earlier.
>>>
>>> Regards
>>>
>>> Behcet
>>>
>>>
>>> On Wed, Nov 2, 2016 at 12:57 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>>> <speaking as a participant>
>>>> Given that various existing MD-1 proposals break up the "4" fields in
>>>> various ways, and given that we may want to allow , for example, a singl 64
>>>> bit field in some MD-1 allocation, it seems cleaner and more consistent to
>>>> me to describe the MD-1 content as a block of 16 bytes rather than as 4 4
>>>> byte words.
>>>>
>>>> Given that this is purely descriptive for the NSH document, I do not see a
>>>> down side.  YANG models for metadata are a more complex question, but the
>>>> simple 4x4 byte representation is probably not want we want there either.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> </speaking as a participant>
>>>>
>>>> _______________________________________________
>>>> sfc mailing list
>>>> sfc@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>
>>> _______________________________________________
>>> sfc mailing list
>>> sfc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sfc
>