Re: ForCES TLV size

"Wang,Weiming" <[email protected]> Mon, 20 Aug 2007 00:00:22 +0800
Newsgroups gmane.ietf.forces
Message-ID <[email protected]>
Jamal, 

By providing a flag to extend the meaning of flags in one TLV over to other TLVs is not a good solution. I'm not sure if you'v considered carefully enough that this method does not induce possible parsing problem for TLVs? I'm just worried that the Path-Data structure has already been a complex body where even path-data TLV can be nested. 

Fenggen is in my implementation team.I think this solution is not we expected when Fenggen raised this question. If anyone has ever been doing the implementation completely, I'm afraid he will never be happy with such design.

Comparatively, we can more live with no change.

thanks,
Weiming

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email protected]>

> Weiming,
> 
> On Sun, 2007-19-08 at 20:08 +0800, Wang,Weiming wrote:
> > Jamal,
> > 
> > Note that when the oper-TLV is 64k, the LFB-select TLV is definitely over 64k. 
> 
> True, but that is not specific to the proposal made and is not an issue
> at all. If you implement nested TLV as the protocol does - you have to
> understand and program that the layering requires that  length and
> content of an inner TLV affects the outer TLVs length.
> 
> > In this case, I would rather not providing any solution to the issue, 
> 
> Joel, Avri - is this fine by you? Havent heard from Fenggen who brought
> up this issue originally. 
> 
> > rather, with a text to indicate the issue and to limit the length 
> > within 64k while leaving solutions to implementation.
> 
> The issue is not the 64K TLV size, so i would rather not put
> text that says that is a limitation. A single forces message can carry a
> lot more than 64K with multiple LFB selectors. And huge tables can be
> transfered in multiple messages.
> The issue is when having a single atomic entity (atomic in this case
> would imply the path cannnot be decomposed further - such as a table
> cell) that in such a case if this object is greater than 64K, it cannot
> be fragmented. We dont know of anything that fits that bill.
> 
> cheers,
> jamal