Subject: Re: [sfc] NSH context headers: fixed/tlv

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Fri, 20 Nov 2015 00:57:03 +0000

Agree with Paul.  There were lengthy discussions in the past that led to the current version of the draft. I see no reason to re-open the decisions made before.

Andrew

On 2015-11-19, 2:01 PM, "sfc on behalf of Paul Quinn (paulq)" wrote:

Qin,

I've updated to the subject line to reflect the topic more accurately.  Referring to "cisco" context headers is misleading, and frankly indicates a lack of understanding of how a document is adopted.

Further, and I'm sure the chairs will weigh in, but as an IETF participants, you should know that IETF procedure is _not_ vote based.  The NSH draft was adopted based on working group consensus, and as such received significant review.  Similarly, consensus is required for updates.   Please read RFC2418, section 3.3 in particular.

On Nov 18, 2015, at 10:07 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

+1, it is not clear to me why 4 context headers MUST be required for MD-TYPE 1,

This was discussed on list, prior to adoption, please feel free to review the archives.  In summary, parsing TLVs is a complex operation, particularly in hardware, and as such, a simple fixed header provided an easy to implement metadata solution.  The TLV option is there as well but since the simplest case is needed as a minimum, that is the mandatory piece.  Adding TLV support (i.e. a flexible parser) means you can probably support type-1 as well so the MUST/SHOULD does not create an added burden.

It looks more flexible to have variable length context header for MD-TYPE 2.

-Qin
From: Linda Dunbar
Sent: Wednesday, November 18, 2015 5:42 PM
To: [email-masked]<mailto:[email-masked]>'; 'Paul Quinn (paulq)'; 'Elzur, Uri'
Subject: draft-ietf-sfc-nsf-01: It makes more sense to state "MD-type = 0x2" (zero or more Variable) as "MUST" and MD-type=0x1" as " SHOULD"

Paul and Uri,

The Section 3.2 of  draft-ietf-sfc-nsf-01 says:

As both MD-type 1 and MD-type 2 are specified by the draft, a more reasonable approach is having the minimum common part (i.e. the first 8 bytes) as the MUST. As the MD-TYPE 2 allows minimum 0 context header (or 16 bytes context header), the MD-TYPE 2 should be a MUST support. And MD-TYPE 1 is a “SHOULD” support.

Let’s face it, the majority of SFC deployment probably won’t need the all 16 bytes "context header" (which has higher chance of packet fragmentation).

Linda

---

From: "Bottorff, Paul" <[email-masked]>
Date: Fri, 20 Nov 2015 01:14:31 +0000

Andrew:

I think the point here is that there may be a lot of applications which don't need either the fixed or TLV meta-data and therefore we should not force implementation to support the fixed headers.

Cheers,

Paul

From: sfc [mailto:[email-masked]] On Behalf Of Dolganow, Andrew (Andrew)
Sent: Thursday, November 19, 2015 4:57 PM
To: Paul Quinn (paulq); Qin Wu
Cc: [email-masked]; [email-masked]; Linda Dunbar
Subject: Re: [sfc] NSH context headers: fixed/tlv

Andrew

Qin,

-Qin
From: Linda Dunbar

Paul and Uri,

As both MD-type 1 and MD-type 2 are specified by the draft, a more reasonable approach is having the minimum common part (i.e. the first 8 bytes) as the MUST. As the MD-TYPE 2 allows minimum 0 context header (or 16 bytes context header), the MD-TYPE 2 should be a MUST support. And MD-TYPE 1 is a "SHOULD" support.

Let's face it, the majority of SFC deployment probably won't need the all 16 bytes "context header" (which has higher chance of packet fragmentation).

Linda

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 19 Nov 2015 20:30:23 -0500

From where I sit, it seems likely that metadata will be needed in many, 
possibly almost all, situations.

What is unclear to me is whether most of those cases can be dealt with 
reasonably well by 4 fixed length fields, or are significantly better 
dealt with by TLV structured metadata.

the reason I include the reasonably / significant caveat is that there 
are clearly processing advantages if we can keep the header small and fixed.

Yours,
Joel

On 11/19/15 8:14 PM, Bottorff, Paul wrote:
> Andrew:
>
> I think the point here is that there may be a lot of applications which
> don’t need either the fixed or TLV meta-data and therefore we should not
> force implementation to support the fixed headers.
>
> Cheers,
>
> Paul
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Dolganow,
> Andrew (Andrew)
> *Sent:* Thursday, November 19, 2015 4:57 PM
> *To:* Paul Quinn (paulq); Qin Wu
> *Cc:* [email-masked]; [email-masked]; Linda Dunbar
> *Subject:* Re: [sfc] NSH context headers: fixed/tlv
>
> Agree with Paul.  There were lengthy discussions in the past that led to
> the current version of the draft. I see no reason to re-open the
> decisions made before.
>
> Andrew
>
>     I've updated to the subject line to reflect the topic more
>     accurately.  Referring to "cisco" context headers is misleading, and
>     frankly indicates a lack of understanding of how a document is adopted.
>
>     Further, and I'm sure the chairs will weigh in, but as an IETF
>     participants, you should know that IETF procedure is _not_ vote
>     based.  The NSH draft was adopted based on working group consensus,
>     and as such received significant review.  Similarly, consensus is
>     required for updates.   Please read RFC2418, section 3.3 in particular.
>
>     This was discussed on list, prior to adoption, please feel free to
>     review the archives.  In summary, parsing TLVs is a complex
>     operation, particularly in hardware, and as such, a simple fixed
>     header provided an easy to implement metadata solution.  The TLV
>     option is there as well but since the simplest case is needed as a
>     minimum, that is the mandatory piece.  Adding TLV support (i.e. a
>     flexible parser) means you can probably support type-1 as well so
>     the MUST/SHOULD does not create an added burden.
>
>
>
>         *From:*Linda Dunbar
>         *Sent:* Wednesday, November 18, 2015 5:42 PM
>         *To:* [email-masked] <mailto:[email-masked]>'; 'Paul Quinn
>         (paulq)'; 'Elzur, Uri'
>         *Subject:* draft-ietf-sfc-nsf-01: It makes more sense to state
>         "MD-type = 0x2" (zero or more Variable) as "MUST" and
>         MD-type=0x1" as " SHOULD"
>
>         Paul and Uri,
>
>         As both MD-type 1 and MD-type 2 are specified by the draft, a
>         more reasonable approach is having the minimum common part (i.e.
>         the first 8 bytes) as the MUST. As the MD-TYPE 2 allows minimum
>         0 context header (or 16 bytes context header), the MD-TYPE 2
>         should be a MUST support. And MD-TYPE 1 is a “SHOULD” support.
>
>         Let’s face it, the majority of SFC deployment probably won’t
>         need the all 16 bytes "context header" (which has higher chance
>         of packet fragmentation).
>
>         Linda
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Fri, 20 Nov 2015 01:48:01 +0000

I see both cases of Type 1 and Type 2 being present/used. I think fixed header offers many advantages thus natural tendency will be to try to solve requirements with the metadata fixed header before considering TLVs. 

Andrew

Sent from my iPhone

> On 19 Nov 2015, at 5:30 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> From where I sit, it seems likely that metadata will be needed in many, possibly almost all, situations.
> 
> What is unclear to me is whether most of those cases can be dealt with reasonably well by 4 fixed length fields, or are significantly better dealt with by TLV structured metadata.
> 
> the reason I include the reasonably / significant caveat is that there are clearly processing advantages if we can keep the header small and fixed.
> 
> Yours,
> Joel
>

---

From: Qin Wu <[email-masked]>
Date: Fri, 20 Nov 2015 02:28:38 +0000

Hi, Andrew and Paul:
It looks I missed a lot of discussion regarding NSH context header in the past, thanks Paul to point me the archive.
Generally speaking, there is tradeoff between performance and flexibility.

-Qin
发件人: Dolganow, Andrew (Andrew) [mailto:[email-masked]]
发送时间: 2015年11月20日 8:57
收件人: Paul Quinn (paulq); Qin Wu
抄送: [email-masked]; [email-masked]; Linda Dunbar
主题: Re: [sfc] NSH context headers: fixed/tlv

Andrew

Qin,

-Qin
From: Linda Dunbar

Paul and Uri,

Linda

---

From: Qin Wu <[email-masked]>
Date: Fri, 20 Nov 2015 02:47:15 +0000

-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Joel M. Halpern
发送时间: 2015年11月20日 9:30
收件人: Qin Wu
抄送: [email-masked]; [email-masked]; Linda Dunbar
主题: Re: [sfc] NSH context headers: fixed/tlv

[Qin]:That's my point, sorry not make this clear in the previous email.

[Qin]: No doubt about this.

Yours,
Joel

On 11/19/15 8:14 PM, Bottorff, Paul wrote:
> Andrew:
>
> I think the point here is that there may be a lot of applications 
> which don’t need either the fixed or TLV meta-data and therefore we 
> should not force implementation to support the fixed headers.
>
> Cheers,
>
> Paul
>
> Agree with Paul.  There were lengthy discussions in the past that led 
> to the current version of the draft. I see no reason to re-open the 
> decisions made before.
>
> Andrew
>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 20 Nov 2015 14:26:30 +0000

On Nov 19, 2015, at 9:28 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Andrew and Paul:

Absolutely, and that's the reason for offering the two options: balance speed/simplicity and flexibility.

The philosophy is to mandate the simplest form of metadata, enabling a broad implementation base.  If/when more flexibility is needed a more flexible NSH type is available, along with the associated tradeoffs.  That's the balance that we decided to strike and it seems to be reasonable and well accepted.

Thanks,
Paul

---

From: "Bottorff, Paul" <[email-masked]>
Date: Fri, 20 Nov 2015 17:20:09 +0000

I think we all could agree that fixed headers are easier to implement than TLVs, however that does not rationalize mandating a fixed header implementation. It would rationalize supporting only fixed length headers, however we have been unable to do this. Options always weaken standards agreement.

If the application requires TLVs, then it does not provide any standards advantage to mandate support for fixed headers. It will not be possible for an application that requires TLVs to fall back to fixed length headers. If they could, then we should eliminate the TLV option from NSH.

IMHO we should be looking at the abstract semantics for meta-data before we consider how to encode it. Once we decide what needs to be encoded then we can consider the best encodings and what should be mandatory or optional.

Cheers,

Paul
From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Friday, November 20, 2015 6:27 AM
To: Qin Wu
Cc: [email-masked]; Dolganow, Andrew (Andrew); [email-masked]; Linda Dunbar
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi, Andrew and Paul:

Thanks,
Paul

---

From: <[email-masked]>
Date: Mon, 23 Nov 2015 07:10:38 +0000

Hi Paul,

IMHO, the discussion is not about having fixed headers but why some “metadata” should be part of those let alone having two versions of the same header may not facilitate interoperability.

I still don’t see the technical reason for 4 mandatory context headers. Why not 2, 3, 5, 10? Thank you.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Paul Quinn (paulq)
Envoyé : vendredi 20 novembre 2015 15:27
À : Qin Wu
Cc : [email-masked]; Dolganow, Andrew (Andrew); [email-masked]; Linda Dunbar
Objet : Re: [sfc] NSH context headers: fixed/tlv

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 23 Nov 2015 10:50:51 -0500

I agree with Paul B. that interoperability is best served by using a header
that accommodates the greatest number of possible applications and use
cases as the common denominator. This argues for type 2 being the MUST to
implement, with type 1 being an optional optimization for some particular
use cases or applications that require at most a particular number context
headers.

In a separate email, Med asked a very reasonable question - for type 1, why
are there four mandatory context headers, rather than 2, 3, 5, 10, etc.?
The draft contains no particular justification for this choice.

It’s true that there are two particular use
cases, draft-guichard-sfc-nsh-dc-allocation
and draft-napper-sfc-nsh-mobility-allocation, that look to make good use of
exactly 4 context headers. However, these are just two particular examples,
and not yet accepted by the WG.  Further development of these drafts, or
even implementation, may show that four are insufficient.

Cheers,
Andy

On Fri, Nov 20, 2015 at 12:20 PM, Bottorff, Paul <[email-masked]>
wrote:

> I think we all could agree that fixed headers are easier to implement than
> TLVs, however that does not rationalize mandating a fixed header
> implementation. It would rationalize supporting only fixed length headers,
> however we have been unable to do this. Options always weaken standards
> agreement.
>
>
>
> If the application requires TLVs, then it does not provide any standards
> advantage to mandate support for fixed headers. It will not be possible for
> an application that requires TLVs to fall back to fixed length headers. If
> they could, then we should eliminate the TLV option from NSH.
>
>
>
> IMHO we should be looking at the abstract semantics for meta-data before
> we consider how to encode it. Once we decide what needs to be encoded then
> we can consider the best encodings and what should be mandatory or
> optional.
>
>
>
> Cheers,
>
>
>
> Paul
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Paul Quinn
> (paulq)
> *Sent:* Friday, November 20, 2015 6:27 AM
> *To:* Qin Wu
> *Cc:* [email-masked]; Dolganow, Andrew (Andrew); [email-masked]; Linda
> Dunbar
> On Nov 19, 2015, at 9:28 PM, Qin Wu <[email-masked]> wrote:
>
>
>
> Hi, Andrew and Paul:
>
> It looks I missed a lot of discussion regarding NSH context header in the
> past, thanks Paul to point me the archive.
>
> The philosophy is to mandate the simplest form of metadata, enabling a
> broad implementation base.  If/when more flexibility is needed a more
> flexible NSH type is available, along with the associated tradeoffs.
> That's the balance that we decided to strike and it seems to be reasonable
> and well accepted.
>
>
>
> Thanks,
>
> Paul
>
>
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 25 Nov 2015 20:02:26 +0000

There are 2 distinctions between types 1 and 2.

Type 1:

·        Fixed length metadata

·        Unstructured metadata

Type 2:

·        Variable length metadata

·        Structured metadata

Wouldn’t type 1 be more flexible if it supported a variable length of unstructured metadata?   Perhaps in 4 byte increments?   Then the distinction would be only whether or not the metadata was structured and perhaps a reasonable justification for the continued existence of both is that the byte length to encode the additional structure in type 2 is greater and perhaps less efficient to parse and that certain deployment scenarios would benefit from the simplicity of type 1.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Monday, November 23, 2015 10:51 AM
To: Bottorff, Paul <[email-masked]>
Cc: [email-masked]; Dolganow, Andrew (Andrew) <[email-masked]>; Linda Dunbar <[email-masked]>; Paul Quinn (paulq) <[email-masked]>; [email-masked]; Qin Wu <[email-masked]>
Subject: Re: [sfc] NSH context headers: fixed/tlv

I agree with Paul B. that interoperability is best served by using a header that accommodates the greatest number of possible applications and use cases as the common denominator. This argues for type 2 being the MUST to implement, with type 1 being an optional optimization for some particular use cases or applications that require at most a particular number context headers.

In a separate email, Med asked a very reasonable question - for type 1, why are there four mandatory context headers, rather than 2, 3, 5, 10, etc.? The draft contains no particular justification for this choice.

It’s true that there are two particular use cases, draft-guichard-sfc-nsh-dc-allocation and draft-napper-sfc-nsh-mobility-allocation, that look to make good use of exactly 4 context headers. However, these are just two particular examples, and not yet accepted by the WG.  Further development of these drafts, or even implementation, may show that four are insufficient.

Cheers,
Andy

On Fri, Nov 20, 2015 at 12:20 PM, Bottorff, Paul <[email-masked]<mailto:[email-masked]>> wrote:
I think we all could agree that fixed headers are easier to implement than TLVs, however that does not rationalize mandating a fixed header implementation. It would rationalize supporting only fixed length headers, however we have been unable to do this. Options always weaken standards agreement.

Cheers,

Paul
From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Paul Quinn (paulq)
Sent: Friday, November 20, 2015 6:27 AM
To: Qin Wu
Cc: [email-masked]<mailto:[email-masked]>; Dolganow, Andrew (Andrew); [email-masked]<mailto:[email-masked]>; Linda Dunbar
Subject: Re: [sfc] NSH context headers: fixed/tlv

Hi, Andrew and Paul:

Thanks,
Paul

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 25 Nov 2015 15:32:41 -0500

Ron,

While discussing the distinctions between Types 1 and 2, another thing
that’s currently unsaid in the current text, but probably should be, is
that one of the TLV Types should be for the Type 1 four-octet unstructured
metadata, making Type 2 a true superset of Type 1.

There’s also a bug with section 14.2.3. The text should be corrected as
follows:

OLD:

14.2.3 <https://tools.ietf.org/html/draft-ietf-sfc-nsh-01#section-14.2.3>.
TLV Class Registry

   IANA is requested to set up a registry of "TLV Types".  These are 16-
   bit values.  Registry entries are assigned by using the "IETF Review"
   policy defined in RFC 5226 <https://tools.ietf.org/html/rfc5226>
[RFC5226 <https://tools.ietf.org/html/rfc5226>].

NEW:

14.2.3 <https://tools.ietf.org/html/draft-ietf-sfc-nsh-01#section-14.2.3>.
TLV Class Registry

   IANA is requested to set up a registry of "TLV Classes".  These are 16-
   bit values.  Registry entries are assigned by using the "IETF Review"
   policy defined in RFC 5226 <https://tools.ietf.org/html/rfc5226>
[RFC5226 <https://tools.ietf.org/html/rfc5226>].

I would then also recommend adding:

TLV Class 0x0001 is allocated to “IETF”.

For TLV Class x0001, there will be a new TLV Type registry. These are 7-bit
values. Registry entries are assigned by using the "IETF Review” policy
defined in RFC 5226 [RFC5226].

For TLV Class x0001, TLV Type x01 is allocated to “32-bit unstructured
metadata”.

Cheers,
Andy

On Wed, Nov 25, 2015 at 3:02 PM, Ron Parker <[email-masked]

> Wouldn’t type 1 be more flexible if it supported a variable length of
> unstructured metadata?   Perhaps in 4 byte increments?   Then the
> distinction would be only whether or not the metadata was structured and
> perhaps a reasonable justification for the continued existence of both is
> that the byte length to encode the additional structure in type 2 is
> greater and perhaps less efficient to parse and that certain deployment
> scenarios would benefit from the simplicity of type 1.
>
>
>
>    Ron
>
>
>
>
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Andrew G. Malis
> *Sent:* Monday, November 23, 2015 10:51 AM
> *To:* Bottorff, Paul <[email-masked]>
> *Cc:* [email-masked]; Dolganow, Andrew (Andrew) <
> [email-masked]>; Linda Dunbar <[email-masked]>;
> Paul Quinn (paulq) <[email-masked]>; [email-masked]; Qin Wu <
> [email-masked]>
>
> I agree with Paul B. that interoperability is best served by using a
> header that accommodates the greatest number of possible applications and
> use cases as the common denominator. This argues for type 2 being the MUST
> to implement, with type 1 being an optional optimization for some
> particular use cases or applications that require at most a particular
> number context headers.
>
>
>
> In a separate email, Med asked a very reasonable question - for type 1,
> why are there four mandatory context headers, rather than 2, 3, 5, 10,
> etc.? The draft contains no particular justification for this choice.
>
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 25 Nov 2015 20:58:51 +0000

Hi, Ron, Andy,

MD Type 1 is not "unstructured" metadata. MD Type 1 has a pre-defined structure and model. It does not use TLVs however, it is not self-describing but its structure is pre-allocated (DC and mobility examples) and contextually revealed.

Hi, Ron,

The benefit of an MD Type 1 is friendliness to hardware processing. Making it of variable length defeats that goal and would make it in my opinion of only very incremental value.

Hi, Andy,

What would be the goal of making MD Type 2 "a true superset of MD Type 1" when it is really not a superset. [I can imagine (perhaps) that such Type value might potentially be used in interworking scenarios, but I'd suggest not to go there and turn SFC into a routed layer network, and cross that bridge if we ever get there.]

I do not see a use case for that four-32-bit-word (not four-octet) opaque Type.

I do agree with the editorial bug you found.

But I object with an allocation of a "32-bit (or 128-bit) unstructured data" Type.

And in any case, might be useful to discuss this within the context of https://tools.ietf.org/html/draft-quinn-sfc-nsh-tlv-00

Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Nov 25, 2015, at 15:33, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Ron,

While discussing the distinctions between Types 1 and 2, another thing that’s currently unsaid in the current text, but probably should be, is that one of the TLV Types should be for the Type 1 four-octet unstructured metadata, making Type 2 a true superset of Type 1.

There’s also a bug with section 14.2.3. The text should be corrected as follows:

OLD:

14.2.3<https://tools.ietf.org/html/draft-ietf-sfc-nsh-01#section-14.2.3>.  TLV Class Registry

   IANA is requested to set up a registry of "TLV Types".  These are 16-
   bit values.  Registry entries are assigned by using the "IETF Review"
   policy defined in RFC 5226<https://tools.ietf.org/html/rfc5226> [RFC5226<https://tools.ietf.org/html/rfc5226>].

NEW:

14.2.3<https://tools.ietf.org/html/draft-ietf-sfc-nsh-01#section-14.2.3>.  TLV Class Registry

   IANA is requested to set up a registry of "TLV Classes".  These are 16-
   bit values.  Registry entries are assigned by using the "IETF Review"
   policy defined in RFC 5226<https://tools.ietf.org/html/rfc5226> [RFC5226<https://tools.ietf.org/html/rfc5226>].

For TLV Class x0001, there will be a new TLV Type registry. These are 7-bit values. Registry entries are assigned by using the "IETF Review” policy defined in RFC 5226 [RFC5226].

For TLV Class x0001, TLV Type x01 is allocated to “32-bit unstructured metadata”.

Cheers,
Andy

On Wed, Nov 25, 2015 at 3:02 PM, Ron Parker <[email-masked]<mailto:[email-masked]>> wrote:
There are 2 distinctions between types 1 and 2.

Type 1:

•        Fixed length metadata

•        Unstructured metadata

Type 2:

•        Variable length metadata

•        Structured metadata

   Ron

From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrew G. Malis
Sent: Monday, November 23, 2015 10:51 AM
To: Bottorff, Paul <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Dolganow, Andrew (Andrew) <[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Paul Quinn (paulq) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Qin Wu <[email-masked]<mailto:[email-masked]>>

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 25 Nov 2015 21:07:19 +0000

My apologies, I'm behind on this thread...

On Nov 25, 2015, at 3:58 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Ron, Andy,

Hi, Ron,

I would add: the value of the fixed, simple size goes beyond hardware: software implementation derive significant benefit as well by not having to parse a set of TLVs.  I'm not saying they can't do it, rather that the simplicity and "cost" savings should not be ignored.

Hi, Andy,

Thanks!

Ron,

OLD:

NEW:

Cheers,
Andy

Type 1:

•        Fixed length metadata

•        Unstructured metadata

Type 2:

•        Structured metadata

   Ron

Cheers,
Andy

Cheers,

Paul

Hi, Andrew and Paul:

Thanks,
Paul