Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt

From: "Suresh Boddapati" <[email-masked]>
Date: Sun, 08 Aug 2004 13:25:48 +0000

Tony,
An existing TLV can already nicely fit within 255 bytes. I dont believe we 
need a scheme to extend the length of existing TLVs. I thought the problem 
that Naiming set out to solve was for new TLVs.   Like Alex pointed out, we 
have enough TLV codepoints. If we solve the length problem for TLVs in 
general, we can extend existing TLVs (even all of them, if necessary), by 
defining new ones which copy the whole information from older TLVs (or reorg 
it intelligently like we did for wide metrics) and append the new 
information using sub TLVs if necessary.

Also, ordering of information across TLVs is not a good idea. The very idea 
of TLVs is not to have a relation between one TLV and the other, each TLV 
being independent of the other, as far as encoding is concerned. It also 
enables for optimum packing. If I can squeeze in 4 bytes of a different TLV 
in an LSP fragment because I cannot encode the "More of the same" TLV (due 
to lack of space), I should be able to do that. Imposing an ordering 
restriction between TLVs takes away this advantage. We do not say TLV X must 
follow TLV Y today in ISIS. Nor do we say the first instance of TLV X must 
precede the second instance of TLV X, which the "More of the same" TLV will 
impose.  We dont want a new scheme to impose such a restriction on 
encoding/decoding rules. Plus, extending it to multiple LSPs will be a 
"complication" as you point out. That will impose an ordering relation 
between data in LSPs as well. Data that will not fit in LSP fragment 1 will 
have to be encoded in LSP fragment 2. The essential drawback here is that 
the data in the TLV is not self identifying, it is saying "More of the same" 
which immediately requires a relation to "same", i.e. needs to be identified 
from information immediately preceding it (either in the TLV preceding it or 
LSP preceding it).

If you read my scheme, it will achieve the desired without the above issue.  
Nothing new, just applying the concept of fragmentation and reassembly to 
ISIS. It takes away the ordering restriction by explicitly using a fragment 
id associated with the data (which would, to be more precise,  need its own 
data or context id of course, either as part of the fragment ID or 
separately,  in order to distinguish between two identical fragment numbers 
associated with two different contexts of data). Like I said earlier, I can 
draft this up, but the bigger question remains. Do we really need to solve 
this problem?

Suresh

>From: Tony Li <[email-masked]>
>To: [email-masked], [email-masked]
>CC: Suresh Boddapati <[email-masked]>, [email-masked], 
>[email-masked]
>Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt
>Date: Sat, 7 Aug 2004 00:33:32 -0700
>
>>the comment raised following the question whether there as ever been any 
>>application where data was so large that it would not fit within one TLV 
>>so that a dedicated TLV had to be defined; hence i pointed out to the SRLG 
>>TLV (Type 138) definition because the corr. SRLG sub-TLV would have not 
>>fit within the extended IS reachability TLV (Type 22) - now i am not aware 
>>of a topology that currently requires more than a single SRLG TLV
>>
>>
>>note that the maximum in the above was 255 octets minus 11 octets so 
>>effectively 244 octets
>>
>
>
>Can I point out a grody coding trick?
>
>If you have a large amount of data (that still fits in an LSP fragment), 
>and you have
>two TLV code points, then you can basically encode LOTS of bytes pretty 
>easily.  The
>first code point is an existing code point that you need to extend.  The 
>second
>is the code point for "More of the same".  The semantics of this TLV is 
>that the
>value of this TLV should be concatenated to the previous TLV before 
>processing it.
>Recurse as necessary.
>
>Note that the "More of the same" TLV can be used with just about any other 
>existing
>TLV type, so it's really only ONE additional code point above and beyond 
>what we
>have today.
>
>Extending this across fragments is a complication that is left to the 
>reader.  ;-)
>
>If it will cease these discussions, I would be more than happy to write the 
>draft....
>But as we have many free code points, I don't think we're in a rush.
>
>Tony
>

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Naiming Shen <[email-masked]>
Date: Mon, 09 Aug 2004 11:01:31 -0700

It seems we have two basic questions,

 (1) do we have a problem of the current isis TLV ?
 (2) if positive on (1), then how to do it nicely ?

For (1), I stated the problem in my presentation, and also an email
to this working group last week. I think we have already 'hit' this
problem a couple of times, even though it's a 'soft' problem, not a
'hard' problem. so we have some ways to get around in some cases,
while in other it much complicated the protocol scheme. But it's
up to this working group to decide.

For (2), we seems have a couple of ways to do it,

 - the draft on exteneded-tlv
 - Mike mentioned using a 'sub-tlv' to indicate a 'continue'; while
   we were designing the MT extension, Derek Yeung also mentioned this.
 - Tony's way to have a new TLV 'continuing' on the old TLV.
 - Suresh's way to have two TLVs with copying old TLV onto this new TLV,
   then do 'continue' among TLVs.

>From the all above, none of them can be 'backwards compatible' without
introduce transition mechanism. extended-tlv scheme gives advantage
of without multiple TLVs within the same LSP fragment, which is a
huge benefit. It can simplify lots of protocol logic. extended-tlv
scheme is also the only one address the code-space issue. yes, there
may not need to be concerned right now, but there is also no reason
not to extend this code space if we are making changes the the isis
TLVs.

I don't think we should start to worry about the LSP fragment size,
we have enough to go. We can extend the fragmantation capability later
when we need this, but this fragmentation is orthogonal to the
TLV extension, they don't have to be done at the same time.

thanks.
- Naiming

---

From: Christian Hopps <[email-masked]>
Date: Mon, 9 Aug 2004 22:14:17 -0700

>  (2) if positive on (1), then how to do it nicely ?

I would prefer if we could please show some concrete examples of 1. I 
believe this was the consensus during the IETF WG slot. I counted at 
few people that came to the mic, and a few more that talked with me 
privately, who seemed to think there is no need for this draft. 
Conversely I didn't notice any one in support. We agreed in the meeting 
that concrete examples of a real problem should be provided on the 
mailing list.

I think it is important that we not get mired down in discussing what 
the best solution to a non-problem is.

Chris.

---

From: Naiming Shen <[email-masked]>
Date: Tue, 10 Aug 2004 11:00:18 -0700

Chris,

 ] On Aug 9, 2004, at 11:01 AM, Naiming Shen wrote:
 ] > It seems we have two basic questions,
 ] >
 ] >  (1) do we have a problem of the current isis TLV ?
 ] >  (2) if positive on (1), then how to do it nicely ?
 ] 
 ] I would prefer if we could please show some concrete examples of 1. I 
 ] believe this was the consensus during the IETF WG slot. I counted at 
 ] few people that came to the mic, and a few more that talked with me 
 ] privately, who seemed to think there is no need for this draft. 
 ] Conversely I didn't notice any one in support. We agreed in the meeting 
 ] that concrete examples of a real problem should be provided on the 
 ] mailing list.

I personally don't have experience a system generating TLV over 253
bytes yet; the same experience i have is we have not running out
IPv4 address space yet; and the same experience i have is i don't
know any ISPs running out LSP fragment yet(besides someone leaked
entire BGP routes into isis, but that would not be a good example);
the same experience i have noticed RSVP still have enough class numbers
and way enough c-types.

But I do have experience that when some new service is defined,
this 255 limit is a concern, and it usually ended up with picking
a different TLV code.  Not only this waste code space, but also
complicate the protocol design. I gave some examples in my
previous email under this thread(the 'concrete' examples i have),
and most recent one is about the capability TLV handling over multiple
TLVs, and we simply don't have a good solution for that(see the
cap draft discussion thread).

 ] 
 ] I think it is important that we not get mired down in discussing what 
 ] the best solution to a non-problem is.
 ] 

agreed.

thanks.

 ] Chris.
 ] 
 ] > For (1), I stated the problem in my presentation, and also an email
 ] > to this working group last week. I think we have already 'hit' this
 ] > problem a couple of times, even though it's a 'soft' problem, not a
 ] > 'hard' problem. so we have some ways to get around in some cases,
 ] > while in other it much complicated the protocol scheme. But it's
 ] > up to this working group to decide.
 ] >
 ] > For (2), we seems have a couple of ways to do it,
 ] 

- Naiming