Re: [sfc] NSH MD-1 description

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