Re: [sfc] NSH MD-1 description

[Behcet Sarikaya <[e-mail]>]

On Fri, Nov 4, 2016 at 4:38 PM, Joel M. Halpern <[e-mail]> wrote:
> 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.
>

I suggest defining a delimiter and anything before that is Metadata
Type 1 and after it is so called TLVs. In fact common way of defining
data in IETF is TLVs. So before and after could be TLVs also.

My 2cents.

Behcet
> 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)
>> <[e-mail]> 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"
>>> <[e-mail] on behalf of [e-mail]> 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 <[e-mail]>
>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>
>>>>
>>>> _______________________________________________
>>>> sfc mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>
>>
>