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

From: "Suresh Boddapati" <[email-masked]>
Date: Mon, 09 Aug 2004 22:04:09 +0000

>
>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.
>
Naiming, looks like you have not read my scheme in detail. My scheme does 
not have any backwards compatibility issue. Yours does and that's why you 
are proposing a transition mechanism by requiring that the high byte be zero 
before migrating the network to using larger than 255 byte TLVs.

My scheme is very simple. You define a new TLV, call it the fragment ID TLV, 
it tells you what is being fragmented (the ID) and how many fragments are 
there. Another TLV is the fragment TLV, which can be repeated as many times 
as desired. It will contain the ID, the fragment number, how long the 
fragment is and the data. There is no explicit "continue" in here. You can 
encode any fragment anywhere in any LSP. From the fragment ID in the 
fragment and the fragment number, you can put the data together. I dont see 
what the backwards compatibilty issue here is. If an implementation does not 
understand these TLVs, it just ignores them. There is no transition 
mechanism required.

>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.
>
I have trouble understanding your argument. You are suggesting that "there 
is no hard problem with the TLV length today, but let us fix it anyway. But 
we dont want to fix this problem once and for all and extend this to 
multiple LSPs, because there is no problem today that requires this". You 
are trying to split this into two problems: 1) TLV length within one LSP 
problem and 2) TLV length spanning multiple LSPs problem.  So tomorrow if 
there is a problem with multiple LSPs, then you want to add a new scheme, in 
addition to your scheme. Why do we want to use two different schemes to 
address these two problems when one will address both?

Suresh

_________________________________________________________________
Get ready for school! Find articles, homework help and more in the Back to 
School Guide! http://special.msn.com/network/04backtoschool.armx

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

---

From: Naiming Shen <[email-masked]>
Date: Tue, 10 Aug 2004 10:21:16 -0700

Suresh,

 ] >
 ] >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.
 ] >
 ] Naiming, looks like you have not read my scheme in detail. My scheme does 
 ] not have any backwards compatibility issue. Yours does and that's why you 
 ] are proposing a transition mechanism by requiring that the high byte be zero 
 ] before migrating the network to using larger than 255 byte TLVs.
 ] 
 ] My scheme is very simple. You define a new TLV, call it the fragment ID TLV 
 ] it tells you what is being fragmented (the ID) and how many fragments are 
 ] there. Another TLV is the fragment TLV, which can be repeated as many times 
 ] as desired. It will contain the ID, the fragment number, how long the 
 ] fragment is and the data. There is no explicit "continue" in here. You can 
 ] encode any fragment anywhere in any LSP. From the fragment ID in the 
 ] fragment and the fragment number, you can put the data together. I dont see 
 ] what the backwards compatibilty issue here is. If an implementation does not
 ] understand these TLVs, it just ignores them. There is no transition 
 ] mechanism required.
 ] 

I don't think it's 'simple'.

 First of all, you introduce some new items into isis TLV, fragment ID
   and fragment number as used in fragmented IP packets;
 Second, if you don't apply any rules on them, those fragments can be
   flooted anywhere, with flooding delay, purge of isis packets, it would
   not be easy to handle;
 Third, if there is a router restart/graceful-or-not, it needs to
   remember not to use the same fragment number, otherwise the new
   packets would have chance to mix with old packets which can generate
   some unexpected data(value field);
 Fourth, as Tony pointed out, "Extending this across fragments is a
   complication that is left to the reader.  ;-) " and there is a reason
   for that;-) when the TLV fragments are long enough to push some
   of the fragment TLVs over to a different LSP, there is no reason
   to believe our flooding will deliver the older and newer LSPs in
   order, and there is no way to tell how to piece them together
   without corrupt the data inside the entire TLV. when there are two
   identical fragment-number in two different packets, you can tell
   by the sequence-numbers which one is the most recent one. you may
   also need to have checksum included for each TLV to ensure the
   integrity of the data.
 Fifth, it certainly has more overhead comparing to other suggested
   schemes interms of encoded octets and the protocol complication.

 ] >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.
 ] >
 ] I have trouble understanding your argument. You are suggesting that "there 
 ] is no hard problem with the TLV length today, but let us fix it anyway. But 
 ] we dont want to fix this problem once and for all and extend this to 
 ] multiple LSPs, because there is no problem today that requires this". You 
 ] are trying to split this into two problems: 1) TLV length within one LSP 
 ] problem and 2) TLV length spanning multiple LSPs problem.  So tomorrow if 
 ] there is a problem with multiple LSPs, then you want to add a new scheme, in
 ] addition to your scheme. Why do we want to use two different schemes to 
 ] address these two problems when one will address both?

My logic is simple, lets solve the problem in a reasonable way, as long as
you are not encoding MP3 over isis packets, we will have a long way to
go for 1493 bytes. On the other hand, if people are auguing we don't
have problem for 254 bytes, why we are so concerned about over 1493 bytes?

As i mentioned above, it's not trivial to handle the data across the
packet boundary. We had the same dicussion in the isis capability
draft regarding capability spread over TLV boundary and over packet
boundary, it needs to have a lot of machanery to deal with them
properly. we don't need to solve this problem right now.

The fragmemtation I refer to is not the LSP fragments, I meant have
the isis packets size grow over 1493 bytes and fragment/re-assemble
the LSP fragments, then your scheme may be useful then ;-)

thanks.
- Naiming

---

From: Dave Katz <[email-masked]>
Date: Tue, 10 Aug 2004 12:19:43 -0600

Once again, I haven't been paying a great deal of attention to the 
particular problem being addressed, but once again that doesn't stop me 
from weighing in (and forgive me if one of the other fossils already 
made the same points.)

One of the architectural aspects of LSPs in IS-IS is that they are 
intended to be idempotent, with no interdependence between LSP 
"fragments" (an unfortunate choice of nomenclature, as this carries too 
much semantic baggage from IP.)  The only exception is a dependence on 
the existence of LSP fragment zero.  There is an expectation that the 
database is always internally consistent even while in flux;  at worst 
there may be stale or missing routes for a brief period of time, and 
that updates to the database are effectively atomic.

Each "fragment" is flooded, built, and rebuilt independently and 
without regard to ordering, and the flooding process is almost 
guaranteed to add a bunch of entropy as the flood moves across the 
network.

Any scheme which depends on multiple fragments to be consistent in any 
database at any instant in time is arguably broken, because there will 
*always* be some period in which they are not consistent;  this 
inconsistency can last for an arbitrarily long time.  The consistency 
issue can of course be addressed with TLV-internal sequencing hacks, 
which would require implementations to play games when not all of the 
interdependent elements have arrived--the side effects of this could be 
pretty ugly, as information would effectively flap every time it is 
updated, and updates stop being anything resembling atomic.

Any scheme which relies on LSP arrival ordering is, of course, so 
broken as to not be worth mentioning.

If the issue at hand is that there is monolithic information that 
cannot fit in 253 bytes (but can fit within 1400mumble), having 
interdependent (and perhaps order-dependent) TLVs within a single LSP 
is unavoidable and a little gross, but not terrible (IMHO).  If there 
is monolithic information that is too large to fit within a single LSP, 
perhaps IS-IS (which is now almost old enough to vote) is not the right 
vehicle.

There is a balance between making things "future-proof" and in trying 
to solve problems that do not exist (yet or perhaps ever.)  If it's the 
case that the problem trying to be solved can be done within the 
confines of a single LSP, my leaning would be to solve that problem and 
not try to solve the arbitrarily-large-data problem (which can always 
be addressed later if it turns out to be real) as it unnecessarily 
torques the protocol architecture.

--Dave

---

From: Jeff Learman <[email-masked]>
Date: Tue, 10 Aug 2004 14:46:29 -0400

If it ain't broke, don't fix it.

One of the more successful aspects of ISIS has been the
extensibility of the protocol due to the simple TLV scheme.
Let's not break existing implementations by changing the length
field for TLV tuples.

Suresh's scheme works for items that fit in a single LSP.
I wouldn't object to it if it is specifically limited to that
case.  Sure, it's not the best solution if we were starting
fresh defining a new protocol, but it doesn't cause compatibility
problems.

For spanning multiple LSPs, we would need a sequence
number or checksum scheme to validate the integrity of the
whole sequence of segments.  But since there's no need for it,
I'm certainly not inclined to do the work.  In any case, it
could involve yet another TLV.  If someone came up with a
workable scheme and demonstrated it in a complex case, I wouldn't
object to that either.

I do object to any change that causes incompatibility between
implementation versions, regardless of whether there's a transition
solution.  Such solutions should be reserved for very important
problems, when there's no other way.

Just my $0.02.  I don't represent Cisco in these matters.

Regards,
Jeff