Clarification of the Use of the IS-IS Generic Information TLV

defines the Generic Information TLV for carrying non-routing information in IS-IS. The current document clarifies some aspects of .

In order to avoid duplicating information sent in IS-IS advertisements, it is useful for an application to be able to associate information carried in application-specific GENINFO APPsub-TLVs with the underlying objects being described by other IS-IS advertisements. This is allowed as long as the requirements of Section 6 of are met. As an example, an application may need to learn the latency of a particular link using the existing Unidirectional Link Delay sub-TLV(#33) carried in TLV#22, while at the same time using an application-specific GENINFO APPsub-TLV to distribute application-specific information about the same link. If the APPsub-TLV carries the System ID of the neighbor together with an interface identifier, and the TLV#22 that carries the Unidirectional Link Delay sub-TLV also carries an interface identifer, then the application can uniquely identify the underlying link being described by the two advertisements. A document that specifies how an application-specific GENINFO TLV is used should also specify how associations of information in different advertisements should be made.

specifies a mechanism for multiple IS-IS protocol instances to share the same circuit by including the IID-TLV in the PDUs associated with a particular IS-IS protocol instance. GENINFO TLVs can be carried in different IS-IS instances. When an application associates information carried in GENINFO TLVs with information carried in other IS-IS advertisements, it may be useful for the application to take into account the particular IS-IS instance in which those other IS-IS advertisements appear. As an example, in a particular network some links participate in three different IS-IS instances. PDUs with IID=50 and IID=60 correspond to two different IS-IS routing protocol instances, each with an independent IS-IS adjacency establishment, Update process, and Decision process. PDUs with IID=70 correspond to an IS-IS instance dedicated to carrying the GENINFO TLVs for a particular application. This application-specific IS-IS instance has an independent IS-IS adjacency establishment and Update process, but does not implement the IS-IS Decision process. The network operator intends that the application should use the latency advertised using TLV#22/sub-TLV#33 in the IS-IS instance with IID=60. This can be accomplished using configuration or other mechanisms. A document that specifies how an application-specific GENINFO TLV is used should also specify how associations of information in different advertisements should be made when multiple IS-IS instances are used.

Neither nor places any requirements on the use of congruent or incongruent IS-IS instances when multiple IS-IS instances are used. In the example described in , the three IS-IS instances may be congruent with one another (that is, use the same set of links on which to form adjacencies) or not.

Section 4.1 of contains the following requirement. In order to prevent the use of stale GENINFO information, a system MUST NOT use a GENINFO TLV present in an LSP of a system that is not currently reachable via Level-x paths, where "x" is the level (1 or 2) associated with the LSP in which the GENINFO TLV appears. The above requirement does not provide an unambiguous specification for determining the reachability of a system originating a GENINFO TLV when multiple IS-IS instances are present. The current document clarifies the requirement of Section 4.1 of in the following manner. A document that specifies how an application-specific GENINFO TLV is to be leaked should also specify the means by which the leaking of stale GENINFO information is to be prevented.

TBD