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

From: "Suresh Boddapati" <[email-masked]>
Date: Fri, 06 Aug 2004 18:06:11 +0000

I think there are two questions to be answered here.

1) Is there an application where the data is large enough that it will not 
fit within one TLV? Note here we are talking about something that cannot be 
fit into a TLV using "additive" style like Mike mentioned. I believe Dimitri 
said that they had to get around the GMPLS problem by defining additional 
TLVs. I dont believe Dimitri said there is a problem currently. Dimitri, can 
you please elaborate on this? What is the diffserv data that you consider 
will require more than 255 bytes and cannot be intelligently broken down 
into multiple TLVs?

2) Suppose we assume that we have data that is large enough that it wont fit 
into one TLV which means the data is larger than 255 bytes. Why are we 
trying to solve it using a low byte and a high byte? Are you assuming that 
the data will not be larger than the most often used 1492 bytes of an ISIS 
LSP? The order of difference between 255 and 1492 (to be more precise 1469, 
after taking out 20 bytes of LSP header + 3 bytes for Type, low byte and 
high byte) is not too much. What if tomorrow there is a need to send 1500 
bytes of data or more in an LSP because of some application. Your scheme 
will not work. If we are to conclude that there is a problem with sending 
large data in ISIS, then why dont we fix it once and for all by fragmenting 
the data and using fragment IDs for each chunk of the data in a new TLV, 
which then can be repeated as many times as desired. Then we dont even have 
to worry about backwards compatibility which your draft tries to deal with. 
We dont have to have these three modes; if an implementation does not 
support this new TLV, it will simply ignore it (and all occurrences of it). 
I would be happy to write this up. Heck, then we can even send MP3 files 
through ISIS :-)

All said and done, it seems that we may be trying to solve a problem that 
does not yet exist. However, if we agree to the contrary, or we want to make 
this future proof, because we anticipate a problem in the future, then we 
should not try to solve this problem for an ISIS LSP alone. ISIS does not 
have fragmentation and reassembly like IP does. So to handle larger data, 
the solution needs to be something that can handle data that can span 
multiple LSPs.

Suresh

>From: Naiming Shen <[email-masked]>
>To: Alex Zinin <[email-masked]>
>CC: [email-masked]
>Subject: Re: [Isis-wg] Comments on draft-shen-isis-extended-tlv-00.txt 
>Date: Thu, 05 Aug 2004 16:35:41 -0700
>
>Alex,
>
>  ] A few comments I raised at the mic today:
>  ]
>  ] 1. One of the reasons that was mention was exhaustion of the TLV type
>  ]    space. Given that we have only 36 allocations in the registry now,
>  ]    I doubt this will be a problem any time soon.
>
>Agreed. But this code point is a side effect of the draft. I think anyone
>would agree that if we take the trouble to change the length field,
>the code field better to be changed at the same time.
>
>  ]
>  ] 2. Another reason was the size of the TLV. If this becomes a problem,
>  ]    my first question would be whether this is a good idea to announce
>  ]    such info in ISIS and/or whether it is properly encoded. This is not
>  ]    to say that we could never end up with having to announce something
>  ]    bigger than 255, but I'd like to see an example of where this 
>becomes
>  ]    a problem we can't get around.
>
>Ok, let me list some of the reasoning here, others can contribute too,
>
>  - network transition is not easy, it can takes years to finish, for
>    all the boxes converge into the same capabilities.
>
>  - a pure historical note: at the time we desgined the Multi-Topology
>    IS-IS, there was a choice to use the existing TLV 22 and 135. But the
>    major concern at the time was if there were multiple topologies using
>    TE (not even talking about GMPLS), then the 255 bytes of the TLV would
>    be a serious limitation and we could not make such a choice. Thus we
>    now have the TLV 222 and 235.
>
>  - as Dimitri yesterday mentioned, in gmpls application usage, the
>    tlv limitation is a concern.
>
>  - diffServ TE usage for isis, 'clasic TE' is only a special case in
>    diffsrv TE. diffserv TE can contain a lot more data.
>
>  - when we have something like isis capability tlv, there will be various
>    'features'/ 'capabilities' a system needs to announce, they could be
>    split into multiple tlvs. then there is a concern how to keep track
>    of the versions of the 'capability' changes if they spread over
>    multiple tlvs/packets. it would be much easier, if the capability
>    tlvs are kept within the same tlv, then there will be no mistake
>    how to read the newer/older version of changes. (this was heavily
>    discussed among the isis cap draft co-authors, and it was the trigger
>    for me(us) to revisit this isis tlv limitation issue)
>
>i don't believe that we don't have a problem currently. we may not
>have a hard limit problem at hand right now, but why we are willing
>to live with this limitation for isis, and why not create the capability
>when the problem is still in a 'soft' state ?
>
>  ]
>  ] 3. Naming mentioned in his slides that backwards-compatible deployment
>  ]    is possible. I wasn't sure it was. Now that I re-read the draft, I'm
>  ]    sure it is not possible. Routers not implementing this feature will
>  ]    encounter a TLV parsing error, since the what they believe is the 
>1-octet
>  ]    length field will contain wrong value for TLVs bigger than 255 
>octets.
>
>during transitional tlv mode, a system is not allowed to generate this
>extended tlv larger than the 255 octets. this is mentioned in the network
>transition section of the draft. this is no different from the TE metric
>transition, the wide metric can not have the value over 63. this is why
>if we are going to move to this new scheme, better to do it long before 
>when
>the >255 octect is really needed.
>
>thanks.
>
>  ]
>  ] --
>  ] Alex
>  ] http://www.psg.com/~zinin
>  ]
>  ]
>  ] _______________________________________________
>  ] Isis-wg mailing list
>  ] [email-masked]
>  ] https://www1.ietf.org/mailman/listinfo/isis-wg
>
>- Naiming
>
>_______________________________________________
>Isis-wg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/isis-wg

_________________________________________________________________
Discover the best of the best at MSN Luxury Living. http://lexus.msn.com/

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 07 Aug 2004 08:40:30 +0200

Suresh Boddapati wrote:
> 1) Is there an application where the data is large enough that it will 
> not fit within one TLV? Note here we are talking about something that 
> cannot be fit into a TLV using "additive" style like Mike mentioned. I 
> believe Dimitri said that they had to get around the GMPLS problem by 
> defining additional TLVs. I dont believe Dimitri said there is a problem 
> currently. Dimitri, can you please elaborate on this? What is the 
> diffserv data that you consider will require more than 255 bytes and 
> cannot be intelligently broken down into multiple TLVs?

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

> 2) Suppose we assume that we have data that is large enough that it wont 
> fit into one TLV which means the data is larger than 255 bytes. 

note that the maximum in the above was 255 octets minus 11 octets so 
effectively 244 octets

> Why are 
> we trying to solve it using a low byte and a high byte? Are you assuming 
> that the data will not be larger than the most often used 1492 bytes of 
> an ISIS LSP? The order of difference between 255 and 1492 (to be more 
> precise 1469, after taking out 20 bytes of LSP header + 3 bytes for 
> Type, low byte and high byte) is not too much. What if tomorrow there is 
> a need to send 1500 bytes of data or more in an LSP because of some 
> application. Your scheme will not work. If we are to conclude that there 
> is a problem with sending large data in ISIS, then why dont we fix it 
> once and for all by fragmenting the data and using fragment IDs for each 
> chunk of the data in a new TLV, which then can be repeated as many times 
> as desired. Then we dont even have to worry about backwards 
> compatibility which your draft tries to deal with. We dont have to have 
> these three modes; if an implementation does not support this new TLV, 
> it will simply ignore it (and all occurrences of it). I would be happy 
> to write this up. Heck, then we can even send MP3 files through ISIS :-)
> 
> All said and done, it seems that we may be trying to solve a problem 
> that does not yet exist. However, if we agree to the contrary, or we 
> want to make this future proof, because we anticipate a problem in the 
> future, then we should not try to solve this problem for an ISIS LSP 
> alone. ISIS does not have fragmentation and reassembly like IP does. So 
> to handle larger data, the solution needs to be something that can 
> handle data that can span multiple LSPs.
> 
> Suresh
> 
> 
>>  ]    encounter a TLV parsing error, since the what they believe is 
>> the 1-octet
>> if we are going to move to this new scheme, better to do it long 
>> before when
> .

---

From: Tony Li <[email-masked]>
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
>
>

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

---

From: Radia Perlman <[email-masked]>
Date: Sat, 07 Aug 2004 23:54:16 -0700

I guess you'd have to be careful if you extend an existing T this way 
that it
wouldn't confuse existing routers that understand the existing T and 
ignore the
rest of the data associated with it (since they wouldn't understand the
"more of the same"). So as long as it would be OK for them to process only
the initial part. Hard to know without an existing example, since it might
be possible to just have multiple instances of the "T" that the old 
routers understand.

Radia

Tony Li wrote:

> two TLV code points, then you can basically encode LOTS of bytes 
> pretty easily.  The
> is the code point for "More of the same".  The semantics of this TLV 
> is that the