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