Subject: [sfc] NSH MD-1 description

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 2 Nov 2016 13:57:01 -0400

<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>

---

From: Ron Parker <[email-masked]>
Date: Wed, 2 Nov 2016 18:30:16 +0000

Agree with this position. 

   Ron

> On Nov 2, 2016, at 10:02 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> 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
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Wed, 2 Nov 2016 18:52:11 +0000

+1

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, November 02, 2016 2:30 PM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] NSH MD-1 description

   Ron

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 2 Nov 2016 19:26:58 +0000

Agree

On 11/2/16, 10:57 AM, "sfc on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    
    Yours,
    Joel

---

From: <[email-masked]>
Date: Thu, 3 Nov 2016 06:55:03 +0000

Hi Joel,

Agree. 

Please consider processing this ticket to record the WG feedback: https://trac.tools.ietf.org/wg/sfc/trac/ticket/22 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
> Envoyé : mercredi 2 novembre 2016 18:57
> À : [email-masked]
> Objet : [sfc] NSH MD-1 description
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 3 Nov 2016 13:01:59 +0000

Hi Med,

I will process the ticket and update it.

Jim

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 3 Nov 2016 16:29:07 +0000

Hi Med & SFC WG:

Having considered the WG feedback the chairs feel that rough consensus has been reached to support this change. 

SFC editors:

Please update the relevant text as per https://trac.tools.ietf.org/wg/sfc/trac/ticket/22 and post a new version.

Thanks!

Jim & Joel

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 3 Nov 2016 18:39:38 +0000

Joel,

That works for me.

Paul

> On Nov 2, 2016, at 1:57 PM, Joel M. Halpern <[email-masked]> wrote:
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 4 Nov 2016 15:13:01 -0500

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 <[email-masked]> wrote:
> 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
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 4 Nov 2016 20:25:16 +0000

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.

Jim

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 4 Nov 2016 16:11:13 -0500

Hi Jim,

> 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 chan…

I am not sure.

That might bring the question of why 1?

I think that we need a more flexible mechanism.

Regards,

Behcet

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 4 Nov 2016 17:38:25 -0400

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 7 Nov 2016 10:56:14 -0600

On Fri, Nov 4, 2016 at 4:38 PM, Joel M. Halpern <[email-masked]> wrote:
> 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.
>
> 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
>>> 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.
>>
>>> On 11/4/16, 4:13 PM, "sfc on behalf of Behcet Sarikaya"
>>> <[email-masked] on behalf of [email-masked]> wrote:
>>>