| Internet-Draft | GENINFO TLV Clarification | March 2021 |
| Bowers | Expires 23 September 2021 | [Page] |
This document clarifies some aspects of [RFC6823], "Advertising Generic Information in IS-IS".¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 September 2021.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
[RFC6823] defines the Generic Information TLV for carrying non-routing information in IS-IS. The current document clarifies some aspects of [RFC6823].¶
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 [RFC6823] 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.¶
[RFC8202] 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 [RFC8202] nor [RFC6823] 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 Section 3, 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 [RFC6823] 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 [RFC6823] 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¶