idnits 2.17.1 draft-li-lsr-droid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 April 2022) is 753 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group T. Li 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track 4 April 2022 5 Expires: 6 October 2022 7 Distributed Routing Object Information Database (DROID) 8 draft-li-lsr-droid-00 10 Abstract 12 Over time, the routing protocols have been burdended with the 13 responsiblity of carrying a variety of information that is not 14 directly relevant to their mission. This includes VPN parameters, 15 configuration information, and capability data. All of the 16 additional data impacts the performance and stability of the routing 17 protocols negatively. 19 This has been convenient since the backbone of a routing protocol is 20 a small distributed database of routing information. Any service 21 needing a distributed database has considered injecting its data into 22 a routing protocol so that it can leverage the protocols database 23 service. Architecturally, this is a mistake that puts the protocol 24 at risk from undue complexity and overhead. 26 To avoid this, DROID is a subsystem that is tangential to, but 27 independent of the routing protocols, and provides distributed 28 database services for other routing services. It is based on the 29 publish-subscribe (pub/sub) architecture and is intentionally crafted 30 to be an open mechanism for the transport of ancillary data. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 6 October 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Use Case: Node Liveness . . . . . . . . . . . . . . . . . 4 67 1.2. Use Case: Capabilities . . . . . . . . . . . . . . . . . 4 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 69 3. DROID Capability Advertisement . . . . . . . . . . . . . . . 5 70 3.1. DROID Advertisement in IS-IS . . . . . . . . . . . . . . 5 71 3.2. DROID Advertisement in OSPF . . . . . . . . . . . . . . . 6 72 4. DROID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.3. Object Values . . . . . . . . . . . . . . . . . . . . . . 7 76 4.4. Client Actions . . . . . . . . . . . . . . . . . . . . . 8 77 4.4.1. Client Liveness Actions . . . . . . . . . . . . . . . 8 78 4.4.2. Client Capability Actions . . . . . . . . . . . . . . 8 79 4.5. ABR Actions . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.5.1. ABR Liveness Actions . . . . . . . . . . . . . . . . 9 81 4.5.2. Autonomous Notification Mode . . . . . . . . . . . . 10 82 4.5.3. Proxy ABRs . . . . . . . . . . . . . . . . . . . . . 10 83 4.6. Publish Messages . . . . . . . . . . . . . . . . . . . . 10 84 4.7. Subscribe Messages . . . . . . . . . . . . . . . . . . . 11 85 4.8. Notification Messages . . . . . . . . . . . . . . . . . . 11 86 4.9. Message Sub-TLVs . . . . . . . . . . . . . . . . . . . . 12 87 4.9.1. Prefix sub-TLV . . . . . . . . . . . . . . . . . . . 12 88 4.9.2. Key Sub-TLV . . . . . . . . . . . . . . . . . . . . . 12 89 4.9.3. Object Value Sub-TLV . . . . . . . . . . . . . . . . 13 90 4.9.4. Liveness Sub-TLV . . . . . . . . . . . . . . . . . . 13 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 92 5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 5.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 5.3. DROID Parameters . . . . . . . . . . . . . . . . . . . . 14 95 5.4. DROID Sub-TLV Types Registry . . . . . . . . . . . . . . 14 96 5.5. DROID Capability Values Registry . . . . . . . . . . . . 15 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 99 7. Normative References . . . . . . . . . . . . . . . . . . . . 15 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 102 1. Introduction 104 Over time, the routing protocols have been burdended with the 105 responsiblity of carrying a variety of information that is not 106 directly relevant to their mission. This includes VPN parameters, 107 configuration information, and capability data. All of the 108 additional data impacts the performance and stability of the routing 109 protocols negatively. 111 This has been convenient since the backbone of a routing protocol is 112 a small distributed database of routing information. Any service 113 needing a distributed database has considered injecting its data into 114 a routing protocol so that it can leverage the protocols database 115 service. Architecturally, this is a mistake that puts the protocol 116 at risk from undue complexity and overhead. 118 To avoid this, DROID is a subsystem that is tangential to, but 119 independent of the routing protocols, and provides distributed 120 database services for other routing services. It is based on the 121 publish-subscribe (pub/sub) architecture and is intentionally crafted 122 to be an open mechanism for the transport of ancillary data. 124 The service itself runs on OSPF [RFC2328] [RFC5340] Area Border 125 Routers (ABRs) or IS-IS [ISO10589] L1-L2 routers. For brevity, we 126 will use the term 'ABRs' for both cases. 128 This service uses a simple, hierarchical publish-subscribe 129 architecture. Clients are nodes within non-backbone OSPF areas or L1 130 IS-IS area. They subscribe with their local ABRs. The ABRs are 131 fully meshed, with the exception that ABRs of the same area need not 132 interact. Notifications initiated by an ABR flow to other ABRs and 133 from there to client nodes. 135 The availability of this service is advertised as part of the IGP, so 136 that discovery of the service is automatic. Clients can 137 automatically detect their local ABRs and ABRs can detect each other 138 and automatically form the necessary hierarchy. 140 The protocol runs on top of TCP [RFC0793] and/or QUIC [RFC9000] for 141 reliability. Security is provided by conventional transport protocol 142 mechanisms, such as TLS [RFC5246]. 144 1.1. Use Case: Node Liveness 146 Overlay services are increasingly common and are implemented by 147 creating tunnels over a physical infrastructure. The failure of one 148 of the tunnel endpoints implies that the traffic towards that 149 endpoint will be lost until the other endpoint recognizes the 150 situation and takes remedial action. Prompt notification of the 151 failure of the other endpoint is useful in minimizing the duration of 152 the outage. 154 Some network designs have come to rely on examining the IGP's Link 155 State Database (LSDB) to determine node liveness and, through the IGP 156 SPF computation, the node's reachability. However, if the network is 157 to scale, some form of summarization must be employed, resulting in 158 this information no longer being directly available. DROID can 159 address this need by combining its distributed database capabilities 160 with the ability to infer knowledge learned from the IGP. 162 Node liveness should not be confused with service liveness. If a 163 node is alive, then a service may or may not be up. This protocol 164 only tries to convey node liveness. 166 1.2. Use Case: Capabilities 168 Different nodes in the network have different capabilities. Other 169 nodes need to know what these capabilities are for a variety of 170 purposes. The management plane could learn and distribute this 171 information, but asking all nodes to retain all of this information 172 is not efficient. Rather, this information should be made available 173 to the nodes that need the information, when they need it. 175 Capability information has been carried in the IGP frequently, but 176 when the capabilities are not directly related to the IGP, it is an 177 overuse of the IGP itself. This would be a good application of 178 DROID. Each node should be able to advertise its capabilities into 179 DROID. Interested nodes should be able to request capability 180 information from DROID about any node in the network. 182 2. Requirements Language 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described in BCP 187 14 [RFC2119] [RFC8174] when, and only when, they appear in all 188 capitals, as shown here. 190 3. DROID Capability Advertisement 192 DROID itself is run by ABRs and is advertised in the IGP for 193 connections by clients and other ABRs. Advertisements are done both 194 into the backbone (L2) and into non-backbone (L1) areas. The 195 advertisements into the backbone allow ABRs to automatically mesh. 196 The advertisements into the non-backbone areas allow clients to 197 automatically determine where the service is available. 199 3.1. DROID Advertisement in IS-IS 201 An ABR advertises the IS-IS DROID sub-TLV as part of the IS-IS Router 202 Capability TLV [RFC7981]. This is injected into the ABRs L1 and L2 203 LSP. The format of the IS-IS Node Liveness sub-TLV is: 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Type | Length |O|N| Reserved | TPI | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Port Number | IPv4 Address | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | IPv4 Address | IPv6 Address... | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Type: TBD1 217 Length: n * (4 octets + 4 octets if O is set + 16 octets if N is 218 set) 220 O: 1 if an IPv4 Address is included 222 N: 1 if an IPv6 Address is included 224 Reserved: must be zero and ignored on receipt, 6 bits 226 TPI: Transport Protocol Identifier, 1 octet 228 0: TCP 230 1: QUIC 232 Port Number: Transport protocol port number, 2 octets 234 IPv4 Address: Service contact address, 4 octets if the O bit is 235 set, 0 otherwise. 237 IPv6 Address: Service contact address, 16 octets if the N bit is 238 set, 0 otherwise. 240 The advertisement of this capability indicates that the node is 241 providing the DROID service on the designated port using the 242 designated protocol. The TPI indicates the transport protocol to be 243 used and the Port Number indicates the associated port to be used. 244 The TPI and Port Number pair may be included multiple times to 245 indicate that multiple protocols and port numbers are available. The 246 length of the sub-TLV can be used to determine the number of TPI and 247 Port Number pairs. 249 An IP address for the ABR MUST be included so that correspondents 250 will know how to access the service. An ABR MUST provide an IPv4 251 address, an IPv6 address, or both. 253 3.2. DROID Advertisement in OSPF 255 The availabilty of the DROID service is provided by the OSPF Node 256 Liveness Sub-TLV. The OSPF Node Liveness Sub-TLV is used by both 257 OSPFv2 and OSPFv3. The semantics are the same as the IS-IS Node 258 Liveness Sub-TLV. The format of the OSPF DROID Sub-TLV is: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 |O|N| Reserved | TPI | Port Number | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | IPv4 Address | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | IPv6 Address... | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Type: TBD2 274 Length: n * 3 octets 276 O: 1 if an IPv4 Address is included 278 N: 1 if an IPv6 Address is included 280 Reserved: must be zero and ignored on receipt, 6 bits 282 TPI: Transport Protocol Identifier, 1 octet 284 0: TCP 285 1: QUIC 287 Port Number: Transport protocol port number, 2 octets 289 IPv4 Address: Service contact address, 4 octets if the O bit is 290 set, 0 otherwise. 292 IPv6 Address: Service contact address, 16 octets if the N bit is 293 set, 0 otherwise. 295 The TPI and Port Number fields are used in the same way as for IS-IS. 297 4. DROID 299 4.1. Messages 301 DROID sends messages in a stream inside of the selected transport 302 protocol. The protocol uses three message types: 304 Publish: A node generates a Publish message to change a data value 305 in the database. If another node has subscribed to this data 306 item, it will be informed by a Notification message. 308 Subscribe: A Subscribe message creates a subscription for a set of 309 data items. Subsequent updates for the data will generate a 310 corresponding Notification message containing the data items. 312 Notification: A Notification message is generated when a database 313 item is modified. Any nodes that have subscribed to the data item 314 are sent a Notification message with the value of the data item. 316 Each message has sub-TLVs to carry more specific information. 318 4.2. Keys 320 Each item in the database must have a key. The key space is 321 hierarchical and variable length. Traditionally, keys have been an 322 ASCII string, with levels in the hierarchy separated by the '/' 323 character, but this is extremely ineffcient. A hierarchical binary 324 key would be more efficient but is harder to manage. 326 Definition of the key space is out of scope for this document. 328 4.3. Object Values 330 An object in the database is an opaque, variable length string of 331 octets. The interpretation of an object value is outside of the 332 scope of this document. 334 4.4. Client Actions 336 The client may determine the set of ABRs that it wishes to 337 communicate with by examination of its LSDB. The client SHOULD open 338 connections to at least two ABRs for redundancy. If the client 339 cannot open two connections, then the management system should be 340 informed. 342 Clients send Subscribe messages to subscribe to particular data that 343 it would like to receive Notifications about. A client MAY set the G 344 bit in the Subscribe message if it would like to get the current 345 value of the data as of when it subscribes. 347 Clients never send Notification messages and never receive Subscribe 348 messages. The actions of the client on receiving a Notification 349 message are out of scope for this document. 351 4.4.1. Client Liveness Actions 353 The client MAY send Subscribe messages (with a Liveness Subscribe 354 sub-TLV) on each of its ABR connections. A client MAY subscribe for 355 any number of prefixes, but it is expected that a client will send a 356 subscription for each of the tunnel endpoints that it will correspond 357 with. A client may subscribe for a host (a /32 or /128 prefix) or a 358 shorter prefix. 360 4.4.2. Client Capability Actions 362 A client MAY send Publish messages to advertise its own capabilities. 363 A client MAY send Subscribe messages to subscribe for capabilities of 364 other nodes. 366 There are no special mechanisms to support client capabilities. This 367 is simply a straightforward example of DROID mechanisms. 369 4.5. ABR Actions 371 Each ABR MUST advertise the availability of the Node Liveness service 372 into the backbone (L2) area and into any non-backbone (L1) areas. 374 Each ABR MUST have a single connection to each other ABR that is part 375 of a different non-backbone (L1) area. To prevent duplicate 376 connections, only one ABR should initiate the connection. For IS-IS, 377 the node with the lowest system ID should initiate the connection. 378 For OSPFv4, the node with the lowest IPv4 router ID should initiate 379 the connection. For OSPFv3, the node with the lowest IPv6 router ID 380 should initiate the connection. 382 Each ABR may receive Subscribe messages, each containing a prefix. 383 These are retained in a Subscription Database (SDB) along with its 384 associated connection information. If a transport connection closes, 385 then all subscriptions associated with the connection should be 386 removed from the SDB. If an ABR receives a Subscription message 387 requesting a prefix be unsubscribed, then the prefix should be 388 removed from the SDB for that connection. 390 If an ABR receives a Subscribe message for a prefix that is being 391 injected by a non-attached area, then it SHOULD determine the set of 392 ABRs that are advertising that prefix or less specifics and subscribe 393 with only those ABRs. The ABR MAY subscribe for the prefix or any of 394 the less specifics. It is RECOMMENDED that the ABR subscribe for the 395 most specific prefix that is less specific than the original prefix. 396 If the ABR cannot find a matching prefix or less specific prefix, 397 then the ABR MAY subscribe for all of prefixes that are more 398 specific. Extreme caution should be used before subscribing for 0/0. 400 If the ABR has subscribed for a prefix and that prefix is no longer 401 advertised by another ABR then an ABR MAY unsubscribe, re-evaluate 402 its subscription and subscribe for a different prefix. In this way, 403 if a summary prefix changes, the ABR can shift to the new summary 404 prefix. 406 An ABR or client SHOULD NOT send duplicate subscriptions. If an ABR 407 or client is already subscribed for a prefix, a duplicate 408 subscription MUST NOT create a duplicate entry in the SDB. 410 A client may be co-located with an ABR. In other words, an ABR may 411 create subscriptions for its own purposes. 413 4.5.1. ABR Liveness Actions 415 Each ABR should monitor its IGP LSDB for changes in node liveness. 416 If an ABR sees an addition to the LSDB, then it is considered an Up 417 Event for that node. If an ABR sees a LSP/LSA time out or become 418 unreachable, then it is considered a Down Event for that node. Up 419 Events and Down Events for non-host prefixes are out of scope for 420 this document. 422 If an ABR receives a Notification message with an Up Event for a 423 prefix, then it is considered an Up Event for the prefix. If an ABR 424 receives a Notification message with a Down Event for a prefix, then 425 it is considered a Down Event for the prefix. 427 If an ABR observes an Up Event for a host, it examines its SDB for 428 subscriptions for that node or for any less specific prefixes. If 429 there are any, then the ABR sends a Notification message (with a 430 Liveness Notification sub-TLV) with an Up Event for that host to each 431 node that subscribed. If there are no subscriptions, then the event 432 MUST be ignored. 434 Similarly, if an ABR observes a Down Event for a host, it examines 435 its SDB for subscriptions for that node or for any less specific 436 prefixes. If there are any, then the ABR sends a Notification 437 message (with a Liveness Notification sub-TLV) with a Down Event for 438 that host to each node that subscribed. If there are no 439 subscriptions, then the event MUST be ignored. 441 4.5.2. Autonomous Notification Mode 443 This section describes OPTIONAL ABR behavior. 445 An ABR MAY learn a set of prefixes from its management plane and 446 enter those prefixes into its SDB. Upon an Up or Down Event for such 447 a prefix, the ABR MAY send corresponding notification messages to all 448 other ABRs. 450 This may cause ABRs to receive unexpected Notification messages. 451 Since these do not match client subscription messages in its own SDB, 452 such messages SHALL be ignored. 454 4.5.3. Proxy ABRs 456 Another node may perform ABR functions instead of the ABR itself. 457 The alternate node is a 'proxy ABR' and performs all of the functions 458 of the ABR with respect to this protocol, except for injecting 459 capability advertisements into the LSDB. The proxy ABR should listen 460 to the IGP within the area so that it can correctly generate 461 notifications. The proxy ABR must also listen to the backbone or L2 462 area so that it can locate other ABRs. One or more ABRs SHOULD 463 advertise the availability of the proxy ABR in its capability 464 advertisements. How the real ABRs learn about the proxy ABR is out 465 of scope for this document. 467 4.6. Publish Messages 469 A Publish message has the following format: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Type | Length | Sub-TLVs ... 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Type: 1 (Publish message), 1 octet 478 Length: length of the sub-TLVs, 2 octets 480 Sub-TLVs: One or more sub-TLVs, specifying the subscription/ 481 unsubscription. Variable length. 483 4.7. Subscribe Messages 485 A Subscribe message has the following format: 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Type | Length |S|G| Reserved | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Sub-TLVs ... 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Type: 2 (Subscribe message), 1 octet 497 Length: 1 + length of the sub-TLVs, 2 octets 499 S: 1 bit 501 0: Subscribe 503 1: Unsubscribe 505 G: if set, then the receiver should generate an immediate 506 Notification with the data value(s), 1 bit 508 Reserved: must be zero and ignored on receipt, 6 bits 510 Sub-TLVs: One or more sub-TLVs, specifying the subscription/ 511 unsubscription. Variable length. 513 Use of the G bit for large queries can generate large amounts of 514 data. 516 4.8. Notification Messages 518 A Notification message has the following format: 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Type | Length | Sub-TLVs ... 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Type: 3 (Notification message), 1 octet 527 Length: length of the sub-TLVs, 2 octets 529 Sub-TLVs: One or more sub-TLVs, specifying the subscription and 530 data value(s). Variable length. 532 4.9. Message Sub-TLVs 534 The following sub-TLVs may be used with any of the messages above. 535 Multiple sub-TLVs are expected to be used in combination to qualify 536 the containing message. Type codes for DROID Sub-TLVs are allocated 537 from the "DROID Sub-TLV Types" registry, defined below. 539 4.9.1. Prefix sub-TLV 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Type | Length | Prefix len | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | AFI | Prefix ... 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Type: 1, 1 octet 551 Length: 3 + the number of octets for the prefix, 2 octets 553 AFI: Address Family Identifier [afireg], 2 octets 555 Prefix len: number of significant bits in the prefix, 1 octet 557 Prefix: n octets 559 4.9.2. Key Sub-TLV 561 The Key sub-TLV has the format: 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Type | Length | Key .... 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Type: 2, 1 octet 571 Length: length of the Key field, in octets, 2 octets 572 Key: variable length 574 The Key is an opaque variable length list of octets. 576 4.9.3. Object Value Sub-TLV 578 The Object Value sub-TLV has the format: 580 0 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Type | Length | Object Value ... 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Type: 3, 1 octet 588 Length: length of the Object Value field, in octets, 2 octets 590 Object Value: variable length 592 The Object Value is an opaque variable length list of octets. 594 The Object Value sub-TLV should never appear in a Subscribe message. 596 4.9.4. Liveness Sub-TLV 598 The Liveness sub-TLV has the format: 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type | Length |U|D| Reserved | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 Type: 128, 1 octet 608 Length: 1, 2 octets 610 U: Up event, 1 bit 612 D: Down event, 1 bit 614 Reserved: must be zero and ignored on receipt, 6 bits 616 Up events and Down events MAY be subscribed independently or jointly. 618 5. IANA Considerations 619 5.1. IS-IS 621 This document requests the following code points from the "IS-IS Sub- 622 TLVs for IS-IS Router CAPABILITY TLV" registry. 624 Type: TBD 1 626 Description: IS-IS Node Liveness sub-TLV 628 Reference: This document 630 5.2. OSPF 632 This document requests the following code points from the "OSPF 633 Router Information (RI) TLVs" registry: 635 Type: TBD 2 637 Description: OSPF Node Liveness Sub-TLV 639 Reference: This document 641 5.3. DROID Parameters 643 This document requests that IANA create a new Protocol Registry for 644 "DROID Parameters". The initial contents are the "DROID Sub-TLV 645 Types Registry" and the "DROID Capability Values Registry" defined 646 below. 648 5.4. DROID Sub-TLV Types Registry 650 This document requests that IANA create a new registry called the 651 "DROID Sub-TLV Types" registry under the "DROID Parameters" protocol 652 registry. For this registry, the registration procedure is 653 "Standards Action". The range of available numeric values is 0-255. 654 Generic sub-TLVs should be allocated from the range of 0-127. Data 655 specific sub-TLVs should be allocated from the range 128-255. The 656 fields in this registry are a "Value" and a "Name". The initial 657 contents of this registry should be: 659 +-------+----------------------+ 660 | Value | Name | 661 +-------+----------------------+ 662 | 1 | Prefix sub-TLV | 663 +-------+----------------------+ 664 | 2 | Key sub-TLV | 665 +-------+----------------------+ 666 | 3 | Object Value sub-TLV | 667 +-------+----------------------+ 668 | 128 | Liveness sub-TLV | 669 +-------+----------------------+ 671 Table 1 673 5.5. DROID Capability Values Registry 675 This document requests that IANA create a new registry called the 676 "DROID Capability Values" registry under the "DROID Parameters" 677 protocol registry. For this registry, the registration procedure is 678 "Standards Action". The range of available numeric values is 0-255. 679 There are no initial contents. The fields in this registry are a 680 "Value" and a "Name". 682 Values in this registry should be allocated in increasing order, 683 starting with zero. 685 Each value in this registry corresponds to a bit position within the 686 Capabilities field of the Capabilities sub-TLV. Value 0 indicates 687 the most significant bit of the first octet, with subsequent values 688 indicating bits of decreasing signficance and then subsequent octets, 689 starting with the most significant bit. Thus, value 8 would 690 correspond to the most signficant bit of the second octet. 692 6. Security Considerations 694 Security of transport protocol connections are addressed by the use 695 of conventional transport protocol security techniques, such as TLS. 696 IGP advertisements are not expected to have privacy, so the 697 advertisement of the service is not a security issue. 699 Authentication is an outstanding issue, to be handled in a future 700 version of this document. 702 7. Normative References 704 [afireg] IANA, "Address Family Numbers", November 1988, 705 . 708 [ISO10589] ISO, "Intermediate system to Intermediate system routing 709 information exchange protocol for use in conjunction with 710 the Protocol for providing the Connectionless-mode Network 711 Service (ISO 8473)", August 1987, . 713 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 714 RFC 793, DOI 10.17487/RFC0793, September 1981, 715 . 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, 719 DOI 10.17487/RFC2119, March 1997, 720 . 722 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 723 DOI 10.17487/RFC2328, April 1998, 724 . 726 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 727 (TLS) Protocol Version 1.2", RFC 5246, 728 DOI 10.17487/RFC5246, August 2008, 729 . 731 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 732 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 733 . 735 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 736 for Advertising Router Information", RFC 7981, 737 DOI 10.17487/RFC7981, October 2016, 738 . 740 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 741 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 742 May 2017, . 744 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 745 Multiplexed and Secure Transport", RFC 9000, 746 DOI 10.17487/RFC9000, May 2021, 747 . 749 Author's Address 751 Tony Li 752 Juniper Networks 753 1133 Innovation Way 754 Sunnyvale, California 94089 755 United States of America 756 Email: tony.li@tony.li