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

From: "Suresh Boddapati" <[email-masked]>
Date: Tue, 10 Aug 2004 19:27:07 +0000

>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.

Were the TLVs within the LSPs also not intended to be idempotent?
AFAIK, they are idempotent today.

>
>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.

We are in agreement here.

>
>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.
>
Agreed. The fact is that if you ever have to solve a problem that spans 
multiple LSPs, no matter which scheme you choose, you would have to wait for 
all the LSPs to arrive (irrespective of the order in which they arrive) to 
put together the data.

>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.
>
Agreed here too. The point is simple. Why use a "little gross" scheme, when  
a cleaner one can be used. The original architecture did not foresee the 
information being more than 255 bytes. Years later, we feel that is no 
longer true. If we add a scheme that takes care of info that spills over 
into multiple TLVs  without violating the idempotence relation of TLVs 
within an LSP, why not do it?

An LSP can be viewed as space/memory where one can encode any TLV one wants, 
as long as the space is there. If an LSP X has 10 bytes free and one wants 
to encode a TLV that is 8 bytes, one can just use LSP X.

An example of monolithic information that is just over 255 bytes:
Consider the case where there are 10 bytes left in each of the 255 LSPs 
originated by an IS. Now if there are 300 bytes of data to be encoded , 
short of rearranging the LSPs and creating space for 300 bytes, OR simply 
not advertising the data, we cannot use any of the other schemes.  It can be 
argued that we could simply start generating new LSPs (using the extension 
of LSP fragments beyond 255, but then one can easily end up with lots of 
LSPs very sparsely populated). Whereas if we use a scheme where we use the 
space as and when we find it, it will just work fine and will allow for 
optimum packing of LSPs. This may not be a very far fetched scenario because 
the LSPs are constantly changing. It can be upto the implementation whether 
it really wants to pack the LSPs optimally or not. But the scheme will allow 
for it.
For the more basic case where you have enough space within the LSP, it will 
also work just fine. In both cases, it will preserve the idempotence of TLVs 
also.

My point is, please do not look at information spilling over into multiple 
LSPs as a very  remote case. It can happen even with less data depending on 
how the state of the database at any point is.

Thanks.

Suresh

_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

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

---

From: Jeff Learman <[email-masked]>
Date: Tue, 10 Aug 2004 15:51:28 -0400

At 03:27 PM 8/10/2004, Suresh Boddapati wrote:
>>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.
>

Of course -- they have to be, because you receive the same info
any number of times with different LSP sequence numbers.  There
would be no reasonable way to provide non-idempotent semantics
if you wanted to.

Jeff

---

From: Tony Li <[email-masked]>
Date: Tue, 10 Aug 2004 15:59:15 -0700

> Consider the case where there are 10 bytes left in each of the 255 
> LSPs originated by an IS. Now if there are 300 bytes of data to be 
> encoded , short of rearranging the LSPs and creating space for 300 
> bytes, OR simply not advertising the data, we cannot use any of the 
> other schemes.  It can be argued that we could simply start generating 
> new LSPs (using the extension of LSP fragments beyond 255, but then 
> one can easily end up with lots of LSPs very sparsely populated). 
> Whereas if we use a scheme where we use the space as and when we find 
> it, it will just work fine and will allow for optimum packing of LSPs. 
> This may not be a very far fetched scenario because the LSPs are 
> constantly changing. It can be upto the implementation whether it 
> really wants to pack the LSPs optimally or not. But the scheme will 
> allow for it.
> For the more basic case where you have enough space within the LSP, it 
> will also work just fine. In both cases, it will preserve the 
> idempotence of TLVs also.
>

And my point is this: the above problem is not worth solving.    Our 
goal here is to provide _engineering_, not theoretical
perfection.  Solving this problem is far outside of the cost/complexity 
envelope that IS-IS is all about.

I strongly suggest that we focus on agreeing on the problem to be 
solved.  Solutions are easy, problem statements are
the hard part.

Tony

---

From: Les Ginsberg <[email-masked]>
Date: Thu, 12 Aug 2004 09:54:34 -0700

Here is yet another approach to this issue.

I believe it is possible to address the 255 byte limitation with no changes 
to the protocol whatsoever.

The premise on which the alleged problem is based is that when and if we 
have more than 255 bytes of information to send about an object, that 
sending the information in two different TLVs is somehow fundamentally 
broken today i.e. that the recipients will fail to utilize the information 
in both TLVs - instead selecting one TLV over another. Each of the 
previously proposed solutions provides a way to overcome this alleged 
protocol deficiency. But if a clear statement is made that, in the case of 
at least certain objects, information in multiple TLVs should be considered 
additive, then the current protocol encoding requires no extension.

If a system advertises multiple IS-neighbor TLVs to the same neighbor, the 
protocol currently processes all of these TLVs when performing SPF. Indeed, 
with the advent of TE sub-TLVs, we routinely send multiple IS-neighbor 
advertisements for the same neighbor - one for every link to that neighbor 
on which we have TE information to advertise. This does not break SPF 
calculations because the SPF algorithm correctly handles these multiple 
advertisements.

Extending this notion, if a system has more than 255 bytes of TE 
information to send about a particular link to a neighbor, it could safely 
send multiple TLVs for that neighbor/link without adversely affecting the 
SPF calculation. What is needed to make this achieve the desired result 
regarding the TE information is for receiving systems to be implemented to 
consider the TE information in all TLVs associated with the same 
neighbor/link as valid and additive. This requires no protocol changes 
whatsoever - only a clear statement of the proper way to process  the 
receipt of multiple TLVs for the same object.

In looking at the various cases which might generate more than 255 bytes of 
data about an object (e.g. TE link information, SRLG, router capabilities) 
I see no usage which would be incompatible with this additive 
interpretation of advertisement.

The additive proposal has a number of advantages as compared to some or all 
of the previously outlined solutions:

a)It does not constrain the information about an object to a single LSP 
fragment
b)It automatically provides the necessary object identifiers so that all 
the TLVs associated with the same object can be reliably identified
c)No protocol changes of any kind are required. No new TLV code points, no 
new TLV attributes (e.g. fragment IDs), etc.

All that is required in the way of specification is some text in the drafts 
associated with the applications which have the potential for more than 255 
bytes defining the additive interpretation of the application information.

Legitimate concern has been expressed about solutions which involve updates 
to multiple LSP fragments because of problems associated with the lack of 
atomicity in the update. These problems are not confined to solutions which 
allow TLVs about the same object to appear in different LSP fragments. Even 
when the solution requires all information about an object to be in a 
single LSP fragment it may require updates to multiple LSP fragments in 
order to advertise additional information about an object. This arises when 
the LSP fragment which contains the current information about an object 
does not have enough room to contain the additional information which needs 
to be advertised. So the TLV(s) must be deleted from the current fragment 
and added (with additional info) to another fragment.

It can be argued that in cases where additional information needs to be 
advertised solutions which allow TLVs to appear in different fragments can 
avoid the multiple fragment issues by leaving the original advertisement 
unchanged and advertising the additional information in another LSP fragment.

NOTE: The above should NOT be interpreted as an endorsement of a strategy 
which always favors single LSP fragment updates rather than minimizing the 
number of TLVs required to advertise the information about an object. I 
believe it is still preferable to use a single TLV whenever the information 
about an object is less than 255 bytes. However, when the information 
exceeds 255 bytes in length having the flexibility to place the additional 
TLV anywhere within the set of LSP fragments can minimize instances where 
multiple fragments must be updated.

As updates to multiple LSP fragments are sometimes unavoidable no matter 
which solution might be used, the following guidelines are practices which 
minimize the disruption by maximizing the effective atomicity of multiple 
fragment updates:

1)Wherever possible, an implementation SHOULD advertise the update to 
TLV(s) in the same LSP fragment as the advertisement(s) which are being 
replaced.
2)Where #1 is not possible, the multiple affected LSP fragments should be 
flooded as an atomic action.
3)Systems which receive an update can minimize the potential disruption 
associated with the update by employing a modest delay time prior to 
processing the update so as to allow for the possible receipt of multiple 
LSP fragments associated with the same update prior to beginning processing.

     Les