Internet-Draft reliable-snp October 2026
Ginsberg, et al. Expires 2 May 2027 [Page]
Workgroup:
LSR Working Group
Internet-Draft:
draft-ginsberg-lsr-reliable-snp-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
L. Ginsberg
Cisco Systems
M. Karasek
Cisco Systems
P. Psenak
Cisco Systems

IS-IS Reliable SNP

Abstract

Complete Sequence Number PDUs (CSNPs) are exchanged as part of adjacency bringup on point-to-point interfaces. However, this exchange is unreliable. This document defines protocol extensions to support reliable exchange of CSNPs as well as optimizations to the encoding of advertisements in Sequence Number PDUs.

Status of This Memo

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 2 May 2027.

▲

Table of Contents

1. Introduction

[ISO10589] Section 7.3.17 specifies that on Point-to-Point(P2P) circuits a router MUST send a complete set of Complete Sequence Number PDUs(CSNPs) when an adjacency is being formed. This allows the neighboring router to determine what are the differences in the Link State Database (LSDB) between the local copy and the neighbor's copy and trigger synchronization of the two databases.

NOTE1: A complete set of CSNPs is defined as "a set whose Start LSPID and End LSPID ranges cover the complete possible range of LSPIDs."

Reception of CSNPs allows the receiver to determine which Link State PDUs(LSPs) need to be exchanged in order to fully synchronize the two LSDBs. This provides a means of optimizing the exchange of LSPs which occur when an adjacency is formed so that the full LSDB does not have to be exchanged - only the LSPs which are not already synchronized need to be exchanged.

The transmission of CSNPs is, however, unreliable i.e., it is possible for some transmitted CSNPs to not be received by the neighbor. This may result in inefficiencies in the LSDB synchronization i.e., some LSPs which are already synchronized between the two neighbors may be unnecessarily transmitted because a CSNP which includes that LSPID was never received. At low to moderate scale, this inefficiency does not have a significant impact. But with large LSDBs this can result in the unnecessary exchange of large numbers of LSPs.

NOTE2: Loss of some CSNPs does NOT compromise the reliability of the LSDB exchange.

Unreliability in the CSNP exchange also contributes to premature use of a neighbor in the best path calculation as it compromises the ability to determine when the LSDBs are in sync. Use of a neighbor whose LSDB is not in sync may result in traffic loss or forwarding loops.

This document defines protocol extensions to support reliable exchange of CSNPs when adjacencies are brought up. This document also defines protocol extensions to increase the efficiency of the encoding of the information sent in Sequence Number PDUs (SNPs).

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Overview of the Solution

There are two protocol extensions required to support reliable CSNP exchange.

1)Nodes need to signal support for reliable CSNP exchange.

2)A means of acknowledging receipt of the LSPID ranges advertised in CSNP needs to be provided.

The following sections define these protocol extensions. These extensions apply only on point-to-point circuits.

3.1. Signalling Support for Reliable CSNP Exchange

A capability bit is assigned from the IS-IS Bit Values for the Hello Capabilities TLV registry defined by [ID.draft-ginsberg-lsr-hello-capability-01]. This bit indicates that the node supports reliable CSNP transmissions. The capability applies to all levels supported on the adjacency.

3.2. CSNP Entry Acknowledgement TLV Definition

A new TLV is defined to signal acknowledgement of the receipt of LSPID ranges. This TLV is sent in Partial Sequence Number PDUs(PSNP). This section defines the format of this TLV.

0 1 2 3 4 5 6 7
+--+--+--+--+--+
| TLV Type     |
+--+--+--+--+--+
| TLV Length   |
+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  System ID of Max Contiguous LSPID Received                 |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| System ID (cont.)             | Pnode ID      | LSP #       |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  System ID of Max Contiguous LSPID Acknowledgement Received |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| System ID (cont.)             | Pnode ID      | LSP #       |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7
+--+--+--+--+--+
| # of ranges  |
+--+--+--+--+--+
0 or more Pairs of the following
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Start System ID of Non-Contiguous LSPID Received           |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| System ID (cont.)             | Pnode ID      | LSP #       |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  End System ID of Non-Contiguous LSPID Received           |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| System ID (cont.)             | Pnode ID      | LSP #       |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
...

"TLV Type" is TBA by IANA (1 octet)

"TLV Length" is the total length of the data which follows (1 octet)

Max Contiguous LSPID Received is the 8 octet LSPID of the highest numbered LSPID received in a CSNP. It serves as an acknowledgment that CSNPs covering entries 0 - Max Contiguous LSPID Received have been successfully received.

Max Contiguous LSPID Acknowledgment Received is the 8 octet LSPID of the highest numbered Max Contiguous LSPID Received from the neighbor in an LSP Entry Acknowledgement TLV. It serves as an acknowledgment that the neighbor is aware of the set of CSNPs which have been successfully received.

Non-contiguous LSPID ID ranges received (start/end) indicate what CSNPs have been successfully received beyond those CSNPs covered by Max Contiguous LSPID Received. This serves to let the neighbor know that CSNPs covering these ranges need not be retransmitted. Multiple such ranges can be included in a TLV. It is RECOMMENDED that these be sent in ascending order.

CSNP Entry Acknowledgment TLVs are advertised in a PSNP when initial CSNP exchange is in progress. Multiple such TLVs MAY be sent in a PSNP, but it is suggested that the number of such TLVs be limited to one. If there are multiple such TLVs, the Max Contiguous LSPID Received and Max Contiguous LSPID Acknowledgment Received MUST be the same in all such TLVs

3.3. Reliable CSNP Exchange State Procedures

Routers which support Reliable CSNP Exchange will enable a timer to trigger periodic sending of a PSNP with a CSNP Entry Acknowledgment TLV whenever Reliable CSNP Exchange is in progress. Suggested value for this timer is 1 second.

Reliable CSNP Exchange is completed when the following is achieved

1)A complete set of CSNPs has been sent.

2)A complete set of CSNPs has been received.

3)A CSNP Entry Acknowledgment TLV has been received where Max Contiguous LSPID Received and Max Contiguous LSPID Acknowledgement Received are both FFFFFF.FF-FF.

Once a node has sent a complete set of CSNPs, receipt of a CSNP Entry Acknowledgment TLV with Max Contiguous LSPID Received less than FFFFFF.FF-FF triggers scheduling of (re)sending one or more CSNPs. The ranges covered in the resent CSNPs SHOULD include ranges between (Max Contiguous LSPID Received+1) and FFFFFF.FF-FF and SHOULD exclude ranges advertised in the set of Non-contiguous LSPID ID ranges received from the neighbor. In this way retransmission of CSNPs covering ranges which have already been successfully received by the neighbor are minimized.

Once both the Last LSPID Sent and the Last LSPID Received indicate that the complete set of CSNPs have been sent and successfully received (both LSPIDs are FFFFFF.FF-FF) the CSNP exchange state is set to completed.

Once CSNP exchange has been successfully completed the timer triggering sending CSNP Entry Acknowledgment TLVs is cancelled.

In order to avoid other routers prematurely directing traffic via the adjacency being established, routers SHOULD suppress the advertisement of the adjacency until CSNP exchange state is complete, the LSDB is synchronized, and the router has updated its forwarding plane based upon the revised topology. Procedures equivalent to that described in [RFC8706] Section 3.4 SHOULD be used to determine when the LSDB is synchronized.

4. Optimizing LSP Entries

[ISO10589] defines the LSP Entry TLV which is used in Partial Sequence Number PDUs(PSNPs) and CSNPs to advertise the description of LSPs in the sender's LSPDB. The format of the TLV is shown below.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+-+--+--+--+--+-+
|  Remaining Lifetime          |
+--+--+--+--+--+-+--+--+--+--+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          System ID                                          |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| System ID (cont.)             | Pnode ID      | LSP #       |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          Sequence #                                         |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+-+--+--+--+--+-+
|     Checksum                 |
+--+--+--+--+--+-+--+--+--+--+-+

This requires a total of 16 octets per LSP.

The value of the Remaining Lifetime is significant only to indicate whether the LSP is active (non-zero) or has been purged (zero). But this indication can be derived from the checksum value since a checksum is NOT calculated for purged LSPs. Therefore it is possible to infer a purged LSP from a 0 checksum value and thereby omit the Remaining Lifetime in an LSP Entry without loss of information. This reduces the amount of information need to fully describe an LSP to 12 octets.

Further optimization can be achieved by defining an encoding which allows the same system ID to be applied to a set of LSPs originated by the same node. In cases where a given node is generating multiple LSPs at a given level, this can provide further significant reduction in the space required to advertise LSP entries.

4.1. Optimized LSP Entry TLV

This section defines the format of a new TLV which is functionally equivalent to the existing LSP Entry TLV (9) but consumes significantly less space without loss of information.

0 1 2 3 4 5 6 7
+--+--+--+--+--+
| Type         | 1 octet - TBA by IANA
+--+--+--+--+--+
| Length       | 1 octet - # of octets to follow
+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          System ID                                          |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+-+--+--+--+--+--+
| System ID (cont.)             |
+--+--+--+--+--+-+--+--+--+--+--+
+--+--+--+--+--+
| # of entries | 1 octet - entries to follow
+--+--+--+--+--+

1 or more entries with the following information
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+-+--+--+--+--+--+
| Pnode-ID     | LSPnum         |
+--+--+--+--+--+-+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|       LSP Sequence #                                        |
+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+-+--+--+--+--+--+
| LSP Checksum                  |
+--+--+--+--+--+-+--+--+--+--+--+
         ...

The above encoding reduces the octets required to advertise multiple LSPs originated by a given node as shown in the below table.

          --------------------------------------------------
          | #LSPs  | LSP Entry TLV | Optimized LSP Entry TLV|
          --------------------------------------------------
          |  1     |   16          |      15                |
          ---------------------------------------------------
          |  2     |   32          |      23                |
          ---------------------------------------------------
          |  3     |   48          |      31                |
          ---------------------------------------------------
          | 15     |  240          |     127                |
          --------------------------------------------------

4.2. Advertising Support for Optimized LSP Entry TLV

Use of the Optimized LSP Entry TLV in SNPs can only be done safely when it is known that the neighbor supports this new TLV. Support can be advertised using the Hello Capability TLV defined in [ID.draft-ginsberg-lsr-hello-capability-01].

A capability bit is assigned from the IS-IS Bit Values for the Hello Capabilities TLV registry defined by [ID.draft-ginsberg-lsr-hello-capability-01]. This bit indicates that the node is capable of sending and receiving the Optimized LSP Entry TLV in SNPs.

Advertisement of this capability bit is only valid in P2P Hello PDUs. If received in a LAN IIH it MUST be ignored.

4.3. IANA Considerations

4.3.1. Hello Capabilities

This document updates the "IS-IS Bit Values for the Hello Capabilites TLV" registry as follows:

IS-IS Reliable CSNP Transmission Support(R-CSNP) Value TBA

IS-IS Optimized LSP Entry Support(O-LSP-Entry: Value TBA

4.3.2. IS-IS Top Level TLVs

This document updates the "IS-IS Top Level TLV Codepoints Registry as follows:

Table 1
Value Name IIH LSP SNP Purge MP Status/Reference
TBA Optimized LSP Entry N N Y N N draft-ginsberg-lsr-reliable-snp
TBA CSNP Entry Ack N N Y N N draft-ginsberg-lsr-reliable-snp

5. Security Considerations

Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310].

TBD

6. Normative References

[ID.draft-ginsberg-lsr-hello-capability-01]
Ginsberg et al., L., "IS-IS Hello Capability", , <https://www.ietf.org/id/draft-ginsberg-lsr-hello-capability-01.txt>.
[ISO10589]
ISO, "Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, .
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5304]
Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, , <https://www.rfc-editor.org/info/rfc5304>.
[RFC5310]
Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, , <https://www.rfc-editor.org/info/rfc5310>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8706]
Ginsberg, L. and P. Wells, "Restart Signaling for IS-IS", RFC 8706, DOI 10.17487/RFC8706, , <https://www.rfc-editor.org/info/rfc8706>.

Authors' Addresses

Les Ginsberg
Cisco Systems
Marek Karasek
Cisco Systems
Peter Psenak
Cisco Systems