Re: [Isis-wg] Comments on draft-lu-isis-transaction-tlv-00

[Wenhu Lu <[e-mail]>]

Hi Les,

Thank you very much for taking time with such detailed review.
We will think about these carefully and get back to you, probably in person if you go Paris next week. 

Regards,
-wenhu

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[e-mail]] 
Sent: Monday, March 19, 2012 10:18 PM
To: Wenhu Lu; Albert Tian
Cc: [e-mail]
Subject: Comments on draft-lu-isis-transaction-tlv-00

Wenhu/Albert -

I acknowledge that the problem which this draft is trying to address exists - at least in theory - but I am concerned as to whether the solution offered will actually result in significant benefits. Here's why.

ISO 10589 highly recommends that once a particular advertisement is assigned to a given LSP that it not be gratuitously moved to an LSP with a different number. (See Section 7.3.4.4) This means that the example you provide in Section 1.3 of the draft is something that should be avoided - and can be avoided in most (but admittedly not all) cases.
This fact alone lessens the value of your proposal.

ISO 10589 also recommends that if a particular advertisement is moved to an LSP with different # that the two affected LSPs be flooded "as an atomic action".

In the context of fast convergence behavior, implementations have taken advantage of ISO 10589 Note 35 so that when multiple LSPs need to be flooded "atomically" the default delay between transmission of LSPs on the same circuit is not required for modest burst sizes.

Implementations also support delayed triggering of the Decision Process in a way which provides for quick response time - but delays long enough for multiple LSP updates to be processed if they are sent as per the guidelines above.

What this draft tries to address is the cases where multiple LSP updates are required to provide all the updates for a particular event. It provides a way for the receiving ISs to know when they have received the full set of updates. In doing so, the above guidelines from 10589 should still be followed since it is still important to receive the full set of updates as quickly as possible so that the Decision Process is not unnecessarily delayed.

While from an "academic" standpoint your proposal adds some determinism into the Update Process machinery for the multiple LSP case, it isn't clear to me from a practical standpoint that we would achieve significantly better behavior than is achievable today simply by following the guidelines/behaviors I listed above.

Have you done any prototyping which demonstrates that an implementation which carefully follows the ISO 10589 guidelines in regards to flooding
- and also uses a judicious method of triggering the Decision Process - is significantly improved by the use of the "transaction TLV"? In order to generate enthusiasm for this proposal I think that needs to be demonstrated with a real implementation. Otherwise we are adding complexity and consuming some LSP space without real gain.

Some other issues that I think need to be more fully addressed:

I rather suspect that once the Transaction TLV is introduced into a particular LSP it will be difficult to remove it. Any removal needs to be delayed long enough to insure that the full transaction has been flooded everywhere - and as removal of the transaction TLV would result in a new LSP update which is gratuitous the only way the transaction TLV could be removed "efficiently" is if there is a subsequent update which is confined to the single LSP. Also, in order for the introduction of the transaction TLV into a given LSP to not be the cause of moving other information out of that LSP into an LSP with different number you will need to reserve space for the transaction TLV in each LSP whether it is actually included in the LSP or not. So your proposal really amounts to carving out space for the transaction TLV in each LSP. This decreases the available LSP space (in a modest way) which might be a concern in scale environments.

As LSPs can be purged (under certain conditions) by other systems, how you avoid "transaction confusion" in this case needs to be addressed.

Minor Issues:

The choice of the acronym "TID" is unfortunate as this can easily be confused with topology ids as used in RFC 5120 and http://datatracker.ietf.org/doc/draft-ietf-isis-mi/

The remark in 3.2.8 about "LSP maximum age (21 minutes usually)" isn't accurate. It is true that ISO 10589 defined Maxage as 1200 seconds (20
minutes) and ZeroAgeLifetime as 60 seconds, but modern implementations allow Maxage to be configurable and it is common to see values of 65000
(18 hours) used in deployments.

In the references (Section 9.2) you really should be referencing the
2002 version of IOS 10589.

   Les