idnits 2.17.1 draft-ymbk-lsvr-lsoe-02.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 27, 2018) is 2038 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '256' on line 425 -- Looks like a reference, but probably isn't: '4' on line 454 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-08 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-15 == Outdated reference: A later version (-29) exists of draft-ietf-lsvr-bgp-spf-02 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Arrcus & IIJ 4 Intended status: Standards Track K. Patel 5 Expires: March 31, 2019 Arrcus 6 September 27, 2018 8 Link State Over Ethernet 9 draft-ymbk-lsvr-lsoe-02 11 Abstract 13 Used in Massive Data Centers (MDCs), BGP-SPF and similar protocols 14 need link neighbor discovery, link encapsulation data, and Layer 2 15 liveness. The Link State Over Ethernet protocol provides link 16 discovery, exchanges supported encapsulations (IPv4, IPv6, ...), 17 discovers encapsulation addresses (Layer 3 / MPLS identifiers) over 18 raw Ethernet, and provides layer 2 liveness checking. The interface 19 data are pushed directly to a BGP-LS API, obviating the need for 20 centralized controller architectures. This protocol is intended to 21 be more widely applicable to other upper layer routing protocols 22 which need link discovery and characterisation. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 28 be interpreted as described in [RFC2119] only when they appear in all 29 upper case. They may also appear in lower or mixed case as English 30 words, without normative meaning. See [RFC8174]. 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 March 31, 2019. 49 Copyright Notice 51 Copyright (c) 2018 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 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Top Level Overview . . . . . . . . . . . . . . . . . . . . . 5 70 5. Ethernet to Ethernet Protocols . . . . . . . . . . . . . . . 6 71 5.1. Inter-Link Ether Protocol Overview . . . . . . . . . . . 6 72 5.2. Messages, PDUs, and Frames . . . . . . . . . . . . . . . 8 73 5.2.1. Frame TLV . . . . . . . . . . . . . . . . . . . . . . 8 74 5.2.1.1. The Checksum . . . . . . . . . . . . . . . . . . 9 75 5.3. HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5.4. OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 5.5. The Encapsulations . . . . . . . . . . . . . . . . . . . 13 78 5.5.1. The Encapsulation Message Skeleton . . . . . . . . . 13 79 5.5.2. Prim/Loop Flags . . . . . . . . . . . . . . . . . . . 15 80 5.5.3. IPv4 Encapsulation . . . . . . . . . . . . . . . . . 15 81 5.5.4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . 15 82 5.5.5. MPLS Label List . . . . . . . . . . . . . . . . . . . 16 83 5.5.6. MPLS IPv4 Encapsulation . . . . . . . . . . . . . . . 16 84 5.5.7. MPLS IPv6 Encapsulation . . . . . . . . . . . . . . . 17 85 5.6. Encapsulation ACK . . . . . . . . . . . . . . . . . . . . 18 86 5.7. KEEPALIVE - Layer 2 Liveness . . . . . . . . . . . . . . 18 87 6. Layers 2.5 and 3 Liveness . . . . . . . . . . . . . . . . . . 19 88 7. The North/South Protocol . . . . . . . . . . . . . . . . . . 19 89 7.1. Use BGP-LS as Much as Possible . . . . . . . . . . . . . 19 90 7.2. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . 20 91 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 8.1. HELLO Discussion . . . . . . . . . . . . . . . . . . . . 20 93 8.2. HELLO versus KEEPALIVE . . . . . . . . . . . . . . . . . 21 94 8.3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 21 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 97 11. IEEE Considerations . . . . . . . . . . . . . . . . . . . . . 22 98 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 100 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 101 13.2. Informative References . . . . . . . . . . . . . . . . . 24 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 104 1. Introduction 106 The Massive Data Center (MDC) environment presents unusual problems 107 of scale, e.g. O(10,000) devices, while its homogeneity presents 108 opportunities for simple approaches. Approaches such as Jupiter 109 Rising [JUPITER] use a central controller to deal with scaling, while 110 BGP-SPF [I-D.ietf-lsvr-bgp-spf] provides massive scale out without 111 centralization using a tried and tested scalable distributed control 112 plane, offering a scalable routing solution in Clos and similar 113 environments. But BGP-SPF and similar higher level device-spanning 114 protocols need link state and addressing data from the network to 115 build the routing topology. LLDP has scaling issues, e.g. in 116 extending a PDU beyond 1,500 bytes. 118 Link State Over Ethernet (LSOE) provides brutally simple mechanisms 119 for devices to 121 o Discover each other's Layer 2 (MAC) Addresses, 123 o Run Layer 2 keep-alive messages for liveness continuity, 125 o Discover each other's unique IDs (ASN, RouterID, ...), 127 o Discover mutually supported encapsulations, e.g. IP/MPLS, 129 o Discover Layer 3 and/or MPLS addressing of interfaces of the link 130 encapsulations, 132 o Enable layer 3 link liveness such as BFD, and finally 134 o Present these data, using a very restricted profile of a BGP-LS 135 [RFC7752] API, to BGP-SPF which computes the topology and builds 136 routing and forwarding tables. 138 This protocol may be more widely applicable to a range of routing and 139 similar protocols which need link discovery and characterisation. 141 2. Terminology 143 Even though it concentrates on the Ethernet layer, this document 144 relies heavily on routing terminology. The following are some 145 possibly confusing terms: 147 Association: An established, vis OPEN messages, session between two 148 LSOE capable devices, 149 ASN: Autonomous System Number [RFC4271], a BGP identifier for 150 an originator of Layer 3 routes, particularly BGP 151 announcements. 152 BGP-LS: A mechanism by which link-state and TE information can be 153 collected from networks and shared with external 154 components using the BGP routing protocol. See [RFC7752]. 155 BGP-SPF A hybrid protocol using BGP transport but a Dijkstra SPF 156 decision process. See [I-D.ietf-lsvr-bgp-spf]. 157 Clos: A hierarchic subset of a crossbar switch topology commonly 158 used in data centers. 159 Encapsulation: Address Family Indicator and Subsequent Address 160 Family Indicator (AFI/SAFI). I.e. classes of addresses 161 such as IPv4, IPv6, MPLS, ... 162 Frame: An Ethernet Layer 2 packet. 163 MAC Address: Media Access Control Address, essentially an Ethernet 164 address, six octets. 165 MDC: Massive Data Center, commonly thousands of TORs. 166 Message: A complete application layer message. These may be longer 167 than will fit in a single Ethernet frame. 168 PDU: Protocol Data Unit, essentially an application layer 169 packet. A Message may need to be broken into multiple 170 PDUs to make it through MTU or other restrictions. 171 RouterID: An 32-bit identifier unique in the current routing domain, 172 see [RFC4271] updated by [RFC6286]. 173 SPF: Shortest Path First, an algorithm for finding the shortest 174 paths between nodes in a graph; AKA Dijkstra's algorithm. 175 TOR: Top Of Rack switch, aggregates the servers in a rack and 176 connects to aggregation layers of the Clos tree, AKA the 177 Clos spine. 178 ZTP: Zero Touch Provisioning gives devices initial addresses, 179 credentials, etc. on boot/restart. 181 3. Background 183 LSOE assumes a datacenter scale and topology, but can accommodate 184 richer topologies which contain potential cycles. 186 While LSOE is designed for the MDC, there are no inherent reasons it 187 could not run on a WAN; though, as it is simply a discovery protocol, 188 it is not clear that this would be useful. The authentication and 189 authorisation needed to run safely on the WAN are not provided in 190 detail in this version of the protocol, although future versions/ 191 extensions could expend on them. 193 LSOE assumes a new IEEE assigned EtherType (TBD). 195 4. Top Level Overview 197 o Devices discover each other on Ethernet links 199 o MAC addresses and Link State are exchanged over Ethernet 201 o Layer 2 Liveness Checks are begun 203 o Encapsulation data are exchanged and IP-Level Liveness Checks done 205 o A BGP-like protocol is assumed to use these data to discover and 206 build a topology database 208 +-------------------+ +-------------------+ +-------------------+ 209 | Device | | Device | | Device | 210 | | | | | | 211 |+-----------------+| |+-----------------+| |+-----------------+| 212 || || || || || || 213 || BGP-SPF <+---+> BGP-SPF <+---+> BGP-SPF || 214 || || || || || || 215 |+--------^--------+| |+--------^--------+| |+--------^--------+| 216 | | | | | | | | | 217 | | | | | | | | | 218 |+--------+--------+| |+--------+--------+| |+--------+--------+| 219 || L2 Liveness || || L2 Liveness || || L2 Liveness || 220 || Encapsulations || || Encapsulations || || Encapsulations || 221 || Addresses || || Addresses || || Addresses || 222 |+--------^--------+| |+--------^--------+| |+--------^--------+| 223 | | | | | | | | | 224 | | | | | | | | | 225 |+--------v--------+| |+--------v--------+| |+--------v--------+| 226 || || || || || || 227 || Ether PDUs <+---+> Ether PDUs <+---+> Ether PDUs || 228 || || || || || || 229 |+-----------------+| |+-----------------+| |+-----------------+| 230 +-------------------+ +-------------------+ +-------------------+ 232 There are two protocols, the Ethernet discovery and the interface to 233 the upper level BGP-like protocol: 235 o Layer 2 Ethernet protocols are used to exchange Layer 2 data, i.e. 236 MAC addresses, and layer 2.5 and 3 identifiers (not payloads), 237 i.e. ASNs, Encapsulations, and interface addresses. 239 o A Link Layer to BGP API presents these data up the stack to a BGP 240 protocol or an other device-spanning upper layer protocol, 241 presenting them using the BGP-LS BGP-like data format. 243 The upper layer BGP family routing protocols cross all the devices, 244 though they are not part of these LSOE protocols. 246 To simplify this document, Layer 2 Ethernet framing is not shown. 248 5. Ethernet to Ethernet Protocols 250 Two devices discover each other and their respective MAC addresses by 251 sending multicast HELLO messages (Section 5.3). To allow discovery 252 of new devices coming up on a multi-link topology, devices send 253 periodic HELLOs forever, see Section 8.1. 255 Once a new device is recognized, both devices attempt to negotiate 256 and establish peering by sending unicast OPEN messages (Section 5.4). 257 In an established peering, Encapsulations (Section 5.5) may be 258 announced and modified. When two devices on a link have compatible 259 Encapsulations and addresses, i.e. the same AFI/SAFI and the same 260 subnet, the link is announced via the BGP-LS API. 262 5.1. Inter-Link Ether Protocol Overview 264 The HELLO, Section 5.3, is a priming message. It is an Ethernet 265 multicast of a minimal message with the simple goal of discovering 266 the Ethernet MAC address(es) of devices reachable via an interface. 268 The HELLO and OPEN, Section 5.4, messages, which are used to discover 269 and exchange MAC address and IDs, are mandatory; other messages are 270 optional; though at least one encapsulation MUST be agreed at some 271 point. 273 The following is a ladder-style sketch of the Ethernet protocol 274 exchanges: 276 | HELLO | MAC Address discovery 277 |---------------------------->| 278 | HELLO | Mandatory 279 |<----------------------------| 280 | | 281 | | 282 | OPEN | MACs, IDs, and Capabilities 283 |---------------------------->| 284 | OPEN | Mandatory 285 |<----------------------------| 286 | | 287 | | 288 | Interface IPv4 Addresses | Interface IPv4 Addresses 289 |---------------------------->| Optional 290 | ACK | 291 |<----------------------------| 292 | | 293 | Interface IPv4 Addresses | 294 |<----------------------------| 295 | ACK | 296 |---------------------------->| 297 | | 298 | | 299 | Interface IPv6 Addresses | Interface IPv6 Addresses 300 |---------------------------->| Optional 301 | ACK | 302 |<----------------------------| 303 | | 304 | Interface IPv6 Addresses | 305 |<----------------------------| 306 | ACK | 307 |---------------------------->| 308 | | 309 | | 310 | Interface MPLSv4 Labels | Interface MPLSv4 Labels 311 |---------------------------->| Optional 312 | ACK | 313 |<----------------------------| 314 | | 315 | Interface MPLSv4 Labels | Interface MPLSv4 Labels 316 |<----------------------------| Optional 317 | ACK | 318 |---------------------------->| 319 | | 320 | | 321 | Interface MPLSv6 Labels | Interface MPLSv6 Labels 322 |---------------------------->| Optional 323 | ACK | 324 |<----------------------------| 325 | | 326 | Interface MPLSv6 Labels | Interface MPLSv6 Labels 327 |<----------------------------| Optional 328 | ACK | 329 |---------------------------->| 330 | | 331 | | 332 | LSOE KEEPALIVE | Layer 2 Liveness 333 |---------------------------->| Optional 334 | LSOE KEEPALIVE | 335 |<----------------------------| 337 5.2. Messages, PDUs, and Frames 339 An LSOE Message occupies one or more Ethernet Frames. We refer to 340 the payload in an Ethernet frame as a PDU (Protocol Data Unit). 342 If a message will not fit in a single frame/PDU, likely due to MTU 343 issues, then the message is broken into multiple PDUs each in its own 344 frame, each with a full header. The OPEN message and the 345 Encapsulation messages provide for multi-PDU packaging. 347 The Flags field indicates whether the message required multiple PDUs 348 and if the current PDU is the last of a multi-PDU sequence; see 349 Section 5.2.1. 351 The PDU Number field of a multi-PDU message must monotonically 352 increase, modulo 256, see [RFC1982]. This and the Flags field may be 353 used to re-assemble long messages. 355 5.2.1. Frame TLV 357 The basic LSOE message is a typical TLV (Type Length Value) PDU with 358 a Version number in front. 360 Aside from the HELLO, Section 5.3, and KEEPALIVE, Section 5.7, an 361 LSOE PDU has a PDU Sequence Number and a Flags field to allow 362 assembly of out order PDUs/frames of messages too long to fit in one 363 Ethernet frame. 365 All LSOE frames/PDUs, other than the HELLO and KEEPALIVE, have the 366 following header: 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Version | Type | PDU Length | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Checksum | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | PDU Number | Flags | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 The fields of the basic LSOE header are as follows: 380 Version: Version number of the protocol, currently 0. 382 Type: An integer differentiating message payload types 384 0 - HELLO 385 1 - OPEN 386 2 - KEEPALIVE 387 3 - Encapsulation ACK 388 4 - IPv4 Announcement 389 5 - IPv6 Announcement 390 6 - MPLS IPv4 Announcement 391 7 - MPLS IPv6 Announcement 392 8-255 Reserved 394 PDU Length: Total number of octets in the PDU including all payloads 395 and fields 397 Checksum: A 32 bit hash over the message to detect bit flips, see 398 Section 5.2.1.1 400 PDU Number: 0..255, a monotonically increasing value, modulo 256, 401 see [RFC1982]. 403 Flags: A bit field, the low order bit is number 0 405 0 - One of a multi-Frame sequence 406 1 - last of a multi-Frame sequence 407 2-7 - Reserved 409 5.2.1.1. The Checksum 411 There is a reason conservative folk use a checksum in UDP. And as 412 many operators stretch to jumbo frames (over 1,500 octets) longer 413 checksums are the conservative approach. 415 For the purpose of computing a checksum, the checksum field itself is 416 assumed to be zero. 418 Sum up 32-bit unsigned ints in a 64-bit long, then take the high- 419 order section, shift it right, rotate, add it in, repeat until zero. 421 #include 422 #include 424 /* The F table from Skipjack, and it would work for the S-Box. */ 425 static const uint8_t sbox[256] = { 426 0xa3,0xd7,0x09,0x83,0xf8,0x48,0xf6,0xf4,0xb3,0x21,0x15,0x78, 427 0x99,0xb1,0xaf,0xf9,0xe7,0x2d,0x4d,0x8a,0xce,0x4c,0xca,0x2e, 428 0x52,0x95,0xd9,0x1e,0x4e,0x38,0x44,0x28,0x0a,0xdf,0x02,0xa0, 429 0x17,0xf1,0x60,0x68,0x12,0xb7,0x7a,0xc3,0xe9,0xfa,0x3d,0x53, 430 0x96,0x84,0x6b,0xba,0xf2,0x63,0x9a,0x19,0x7c,0xae,0xe5,0xf5, 431 0xf7,0x16,0x6a,0xa2,0x39,0xb6,0x7b,0x0f,0xc1,0x93,0x81,0x1b, 432 0xee,0xb4,0x1a,0xea,0xd0,0x91,0x2f,0xb8,0x55,0xb9,0xda,0x85, 433 0x3f,0x41,0xbf,0xe0,0x5a,0x58,0x80,0x5f,0x66,0x0b,0xd8,0x90, 434 0x35,0xd5,0xc0,0xa7,0x33,0x06,0x65,0x69,0x45,0x00,0x94,0x56, 435 0x6d,0x98,0x9b,0x76,0x97,0xfc,0xb2,0xc2,0xb0,0xfe,0xdb,0x20, 436 0xe1,0xeb,0xd6,0xe4,0xdd,0x47,0x4a,0x1d,0x42,0xed,0x9e,0x6e, 437 0x49,0x3c,0xcd,0x43,0x27,0xd2,0x07,0xd4,0xde,0xc7,0x67,0x18, 438 0x89,0xcb,0x30,0x1f,0x8d,0xc6,0x8f,0xaa,0xc8,0x74,0xdc,0xc9, 439 0x5d,0x5c,0x31,0xa4,0x70,0x88,0x61,0x2c,0x9f,0x0d,0x2b,0x87, 440 0x50,0x82,0x54,0x64,0x26,0x7d,0x03,0x40,0x34,0x4b,0x1c,0x73, 441 0xd1,0xc4,0xfd,0x3b,0xcc,0xfb,0x7f,0xab,0xe6,0x3e,0x5b,0xa5, 442 0xad,0x04,0x23,0x9c,0x14,0x51,0x22,0xf0,0x29,0x79,0x71,0x7e, 443 0xff,0x8c,0x0e,0xe2,0x0c,0xef,0xbc,0x72,0x75,0x6f,0x37,0xa1, 444 0xec,0xd3,0x8e,0x62,0x8b,0x86,0x10,0xe8,0x08,0x77,0x11,0xbe, 445 0x92,0x4f,0x24,0xc5,0x32,0x36,0x9d,0xcf,0xf3,0xa6,0xbb,0xac, 446 0x5e,0x6c,0xa9,0x13,0x57,0x25,0xb5,0xe3,0xbd,0xa8,0x3a,0x01, 447 0x05,0x59,0x2a,0x46 448 }; 450 /* non-normative example C code, constant time even */ 452 uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) 453 { 454 uint32_t sum[4] = {0, 0, 0, 0}; 455 uint64_t result = 0; 456 for (size_t i = 0; i < n; i++) 457 sum[i & 3] += sbox[*b++]; 458 for (int i = 0; i < sizeof(sum)/sizeof(*sum); i++) 459 result = (result << 8) + sum[i]; 460 result = (result >> 32) + (result & 0xFFFFFFFF); 461 result = (result >> 32) + (result & 0xFFFFFFFF); 462 return (uint32_t) result; 463 } 465 5.3. HELLO 467 The HELLO message is unique in that it is a multicast Ethernet frame. 468 It solicits response(s) from other device(s) on the link. See 469 Section 8.1 for why multicast is used. 471 All other LSOE messages are unicast Ethernet frames, as the peer's 472 MAC Address is known after the HELLO exchange. 474 When an interface is turned up on a device, it SHOULD issue a HELLO 475 periodically. The interval is set by configuration. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Version = 0 | Type = 0 | PDU Length = 14 | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Checksum | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | MyMAC Address | 485 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 If more than one device responds, one adjacency is formed for each 490 unique (MAC address) response. LSOE treats the adjacencies as 491 separate links. 493 When a HELLO is received from a MAC address where there is no 494 established LSOE adjacency, the receiver SHOULD respond with an OPEN 495 message. The two devices establish an LSOE adjacency by exchanging 496 OPEN messages. 498 The PDU Length is the octet count of the entire PDU, including the 499 Version, the Type, the PDU Length field itself, the Checksum, and the 500 following payload. 502 5.4. OPEN 504 Each device has learned the other's MAC address from the HELLO 505 exchange, see Section 5.3. Therefore the OPEN and subsequent 506 messages are unicast, as opposed to the HELLO's multicast, Ethernet 507 frames. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Version | Type = 1 | PDU Length | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Checksum | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | PDU Number | Flags | | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 518 | | 519 + Local ID + 520 | | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | | 523 + + 524 | Remote ID (or Zero) | 525 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | | AttrCount | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Attribute List ... | Auth Length | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Authentication Data ... | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 An ID can be an ASN with high order bits zero, a classic RouterID 534 with high order bits zero, a catenation of the two, a 80-bit ISO 535 System-ID, or any other identifier unique to a single device in the 536 current routing space. IDs are big-endian. 538 When the local device sends an OPEN without knowing the remote 539 device's ID, the Remote ID MUST be zero. The Local ID MUST NOT be 540 zero. 542 AttrCount is the number of attributes in the Attribute List. 543 Attributes are single octets whose semantics are user-defined. 545 A node may have zero or more user-defined attributes, e.g. spine, 546 leaf, backbone, route reflector, arabica, ... 548 Attribute syntax and semantics are local to an operator or 549 datacenter; hence there is no global registry. Nodes exchange their 550 attributes only in the OPEN message. 552 Auth Length is the length in octets of the Authentication Data, not 553 including the Auth Length itself. If there are no Authentication 554 Data, the Auth Length MUST BE zero. 556 The Authentication Data are specific to the operational environment. 557 A failure to authenticate is a failure to start the LSOE association, 558 and HELLOs MUST BE restarted. 560 Once two devices know each other's MAC addresses, and have exchanged 561 OPEN messages, Layer 2 KEEPALIVEs (see Section 5.7) SHOULD be started 562 to ensure Layer 2 liveness and keep the association semantics alive. 563 The timing and acceptable drop of the KEEPALIVE messages SHOULD be 564 configured. 566 If a properly authenticated OPEN arrives from a device with which the 567 receiving device believes it already has an LSOE association (OPENs 568 have already been exchanged), the receiver MUST assume that the 569 sending device has been reset. All discovered data MUST BE withdrawn 570 via the BGP-LS API and the recipient MUST respond with a new OPEN. 572 5.5. The Encapsulations 574 Once the devices know each other's MAC addresses, know each other's 575 upper layer identities, have means to ensure link state, etc., the 576 LSOE 'association' is considered established, and the devices SHOULD 577 announce their interface encapsulation, addresses, (and labels). 579 The Encapsulation types the peers exchange may be IPv4 Announcement 580 (Section 5.5.3), IPv6 Announcement (Section 5.5.4), MPLS IPv4 581 Announcement (Section 5.5.6), MPLS IPv6 Announcement (Section 5.5.7), 582 or possibly others not defined here. 584 The sender of an Encapsulation message MUST NOT assume that the peer 585 is capable of the same Encapsulation Type. An Encapsulation ACK 586 (Section 5.6) merely acknowledges receipt. Only if both peers have 587 sent the same Encapsulation Type is it safe to assume that they are 588 compatible for that type. 590 Further, to consider a link of a type to formally be established so 591 that it may be pushed up to upper layer protocols, the addressing for 592 the type must be compatible, i.e. on the same IPvX subnet. 594 5.5.1. The Encapsulation Message Skeleton 596 The header for all encapsulation messages is as follows: 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Version | Type | PDU Length | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Checksum | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | PDU Number | Flags | Encapsulation Count | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Encapsulation List... | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 If the length of an Encapsulation message exceeds the PDU size limit 611 on media, the message is broken into multiple PDUs. See Section 5.2. 613 The Encapsulation Exchange is over an unreliable transport so the PDU 614 Number and ACKs are used for reassembly. 616 The Receiver MUST acknowledge the Encapsulation PDU with a Type=3, 617 Encapsulation ACK PDU (Section 5.6) with the Encapsulation Type being 618 that of the encapsulation being announced, see Section 5.6 and the 619 PDU Number being the PDU Number of the Encapsulation PDU being 620 ACKnowledged. 622 If the Sender does not receive an ACK in one second, they SHOULD 623 retransmit. After a user configurable number of failures, the LSOE 624 association should be considered dead and the OPEN process SHOULD be 625 restarted. 627 An Encapsulation message MAY describe multiple addresses of the 628 encapsulation type. 630 An Encapsulation message of Type T replaces all previous 631 encapsulations of Type T. 633 To remove all encapsulations of Type T, the sender uses and 634 Encapsulation Count of zero. 636 If an interface has multiple addresses for an encapsulation type, one 637 address SHOULD be marked as primary, see Section 5.5.2. 639 If a loopback address needs to be exposed, e.g. for iBGP peering, 640 then it should be marked as such, see Section 5.5.2. 642 If a sender has multiple links on the same interface, separate data, 643 ACKs, etc. must be kept for each peer. 645 Over time, multiple Encapsulation messages may be sent for an 646 interface as configuration changes. 648 5.5.2. Prim/Loop Flags 650 0 1 2 3 ... 7 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Primary | Loopback | Reserved ... | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 Each Encapsulation interface address MAY be marked as a primary 656 address, and/or a loopback, in which case the respective bit is set 657 to one. 659 Only one address MAY be marked as primary for an encapsulation type. 661 5.5.3. IPv4 Encapsulation 663 The IPv4 Encapsulation describes a device's ability to exchange IPv4 664 packets on one or more subnets. It does so by stating the 665 interface's address and the prefix length. 667 0 1 2 3 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Version | Type = 4 | Length | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Checksum | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | PDU Number | Flags | Encaps Count | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | PrimLoop Flags| IPv4 Address | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | | PrefixLen | PrimLoop Flags| | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | IPv4 Address | PrefixLen | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | more ... | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 5.5.4. IPv6 Encapsulation 687 The IPv6 Encapsulation describes a device's ability to exchange IPv6 688 packets on one or more subnets. It does so by stating the 689 interface's address and the prefix length. 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Version | Type = 5 | Length | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Checksum | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | PDU Number | Flags | Encaps Count | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | PrimLoop Flags| | 701 +-+-+-+-+-+-+-+-+ + 702 | | 703 + + 704 | | 705 + + 706 | IPv6 Address | 707 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | | PrefixLen | more ... | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 5.5.5. MPLS Label List 713 As an MPLS enabled interface may have a label stack, see [RFC3032], a 714 variable length list of labels is needed. 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Label Count | Label | Exp |S| 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Label | Exp |S| more ... | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 A Label Count of zero is an implicit withdraw of all labels for that 725 prefix on that interface. 727 5.5.6. MPLS IPv4 Encapsulation 729 The MPLS IPv4 Encapsulation describes a device's ability to exchange 730 labeled IPv4 packets on one or more subnets. It does so by stating 731 the interface's address and the prefix length. 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Version | Type = 6 | Length | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Checksum | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | PDU Number | Flags | Encaps Count | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | PrimLoop Flags| MPLS Label List ... | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | | IPv4 Address | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | | PrefixLen | PrimLoop Flags| | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | MPLS Label List ... | | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | IPv4 Address | Prefix Len | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | more ... | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 5.5.7. MPLS IPv6 Encapsulation 757 The MPLS IPv6 Encapsulation describes a device's ability to exchange 758 labeled IPv6 packets on one or more subnets. It does so by stating 759 the interface's address and the prefix length. 761 0 1 2 3 762 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 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Version | Type = 7 | Length | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Checksum | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | PDU Number | Flags | Encaps Count | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | PrimLoop Flags| MPLS Label | List ... | | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 772 | | 773 + + 774 | | 775 + + 776 | IPv6 Address | 777 + +-+-+-+-+-+-+-+-+ 778 | | Prefix Len | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | more ... | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 5.6. Encapsulation ACK 785 0 1 2 3 786 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 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Version | Type = 3 | Length = 11 | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Checksum | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | PDU Number | Flags | Encap Type | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 The header is as described in Section 5.5. 797 The PDU Number is the number of the received PDU being acknowledged. 798 This provides is a lock-step exchange of an Encapsulation message. 800 The Encap Type is the Type of the Encapsulation Message being 801 acknowledged. 803 5.7. KEEPALIVE - Layer 2 Liveness 805 LSOE devices MUST exchange occasional Layer 2 KEEPALIVE messages to 806 ensure association continuity. 808 They SHOULD be exchanged at a configured frequency. One per second 809 is the default. Layer 3 liveness, such as BFD, will likely be more 810 aggressive. 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Version | Type = 2 | Length = 8 | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Checksum | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 6. Layers 2.5 and 3 Liveness 822 Ethernet liveness is continuously tested by KEEPALIVE messages, see 823 Section 5.7. As layer 2.5 or layer 3 connectivity could still break, 824 liveness above layer 2 SHOULD be frequently tested using BFD 825 ([RFC5880]) or a similar technique. 827 This protocol assumes that one or more Encapsulation addresses will 828 be used to ping, BFD, or whatever the operator configures. 830 7. The North/South Protocol 832 Thus far, a one-hop point-to-point link discovery protocol has been 833 defined. 835 The nodes know the unique node identifiers (ASNs, RouterIDs, ...) and 836 Encapsulations on each link interface. 838 Full topology discovery is not appropriate at the Ethernet layer, so 839 Dijkstra a la IS-IS etc. is assumed to be done by higher level 840 protocols. 842 Therefore the node identifiers, link Encapsulations, and state 843 changes are pushed North via a small subset of the BGP-LS API. The 844 upper layer routing protocol(s), e.g. BGP-SPF, learn and maintain 845 the topology, run Dijkstra, and build the routing database(s). 847 For example, if a neighbor's IPv4 Encapsulation address changes, the 848 devices seeing the change push that change Northbound. 850 7.1. Use BGP-LS as Much as Possible 852 BGP-LS [RFC7752] defines BGP-like PDUs describing link state (links, 853 nodes, link prefixes, and many other things), and a new BGP path 854 attribute providing Northbound transport, all of which can be 855 ingested by upper layer protocols such as BGP-SPF; see Section 4 of 856 [I-D.ietf-lsvr-bgp-spf]. 858 For IPv4 links, TLVs 259 and 260 are used. For IPv6 links, TLVs 261 859 and 262. If there are multiple addresses on a link, multiple TLV 860 pairs are pushed North, having the same ID pairs. 862 7.2. Extensions to BGP-LS 864 The Northbound protocol needs a few minor extensions to BGP-LS. 865 Luckily, others have needed the same extensions. 867 Similarly to BGP-SPF, the BGP protocol is used in the Protocol-ID 868 field specified in table 1 of 869 [I-D.ietf-idr-bgpls-segment-routing-epe]. The local and remote node 870 descriptors for all NLRI are the ID's described in Section 5.4. This 871 is equivalent to an adjacency SID or a node SID if the address is a 872 loopback address. 874 Label Sub-TLVs from [I-D.ietf-idr-bgp-ls-segment-routing-ext] 875 Section 2.1.1, are used to associate one or more MPLS Labels with a 876 link. 878 8. Discussion 880 This section explores some trade-offs taken and some considerations. 882 8.1. HELLO Discussion 884 There is the question of whether to allow an intermediate switch to 885 be transparent to discovery. We consider that an interface on a 886 device is a Layer 2 or a Layer 3 interface. In theory it could be a 887 Layer 3 interface with no encapsulation or Layer 3 addressing 888 currently configured. 890 A device with multiple Layer 2 interfaces, traditionally called a 891 switch, may be used to forward frames and therefore packets from 892 multiple devices to one interface, I, on an LSOE speaking device. 893 Interface I could discover a peer J across the switch. Later, a 894 prospective peer K could come up across the switch. If I was not 895 still sending and listening for HELLOs, the potential peering with K 896 could not be discovered. Therefore, interfaces MUST continue to send 897 HELLOs as long as they are turned up. 899 8.2. HELLO versus KEEPALIVE 901 Both HELLO and KEEPALIVE are periodic. KEEPALIVE might be eliminated 902 in favor of keeping only HELLOs. But currently KEEPALIVE is unicast, 903 has a checksum, is acknowledged, and thus more firmly verifies 904 association existence. 906 This warrants discussion. 908 8.3. Open Issues 910 VLANs/SVIs/Subinterfaces 912 9. Security Considerations 914 The protocol as is MUST NOT be used outside a datacenter or similarly 915 closed environment due to lack of formal definition of the 916 authentication and authorisation mechanism. These will be worked on 917 in a later effort, likely using credentials configured using ZTP. 919 Many MDC operators have a strange belief that physical walls and 920 firewalls provide sufficient security. This is not credible. All 921 MDC protocols need to be examined for exposure and attack surface. 923 It is generally unwise to assume that on the wire Ethernet is secure. 924 Strange/unauthorized devices may plug into a port. Mis-wiring is 925 very common in datacenter installations. A poisoned laptop might be 926 plugged into a device's port. 928 Malicious nodes/devices could mis-announce addressing, form malicious 929 associations, etc. 931 For these reasons, the OPEN message's authentication data exchange 932 SHOULD be used. [ A mandatory to implement authentication is in 933 development. ] 935 10. IANA Considerations 937 This document requests the IANA create a registry for LSOE Message 938 Type, which may range from 0 to 255. The name of the registry should 939 be LSOE-Message-Type. The policy for adding to the registry is RFC 940 Required per [RFC5226], either standards track or experimental. The 941 initial entries should be the following: 943 Message 944 Code Message Name 945 ---- ------------------- 946 0 HELLO 947 1 OPEN 948 2 KEEPALIVE 949 3 Encapsulation ACK 950 4 IPv4 Announce / Withdraw 951 5 IPv6 Announce / Withdraw 952 6 MPLS IPv4 Announce / Withdraw 953 7 MPLS IPv6 Announce / Withdraw 954 8-255 Reserved 956 This document requests the IANA create a registry for LSOE Flag Bits, 957 which may range from 0 to 7. The name of the registry should be 958 LSOE-Flag-Bits. The policy for adding to the registry is RFC 959 Required per [RFC5226], either standards track or experimental. The 960 initial entries should be the following: 962 Bit Bit Name 963 ---- ------------------- 964 0 One of a multi-Frame sequence 965 1 last of a multi-Frame sequence 966 2-7 Reserved 968 This document requests the IANA create a registry for LSOE PL Flag 969 Bits, which may range from 0 to 7. The name of the registry should 970 be LSOE-PL-Flag-Bits. The policy for adding to the registry is RFC 971 Required per [RFC5226], either standards track or experimental. The 972 initial entries should be the following: 974 Bit Bit Name 975 ---- ------------------- 976 0 Primary 977 1 Loopback 978 2-7 Reserved 980 11. IEEE Considerations 982 This document needs a new EtherType. 984 12. Acknowledgments 986 The authors thank Cristel Pelsser for multiple reviews, Jeff Haas for 987 review and comments, Joe Clarke for a useful review, John Scudder 988 deeply serious review and comments, Larry Kreeger for a lot of layer 989 2 clue, Martijn Schmidt for his contribution, Rob Austein for reviews 990 and checksum code, Russ Housley for checksum discussion and sBox, and 991 Steve Bellovin for checksum advice. 993 13. References 995 13.1. Normative References 997 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 998 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 999 and M. Chen, "BGP Link-State extensions for Segment 1000 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 1001 (work in progress), May 2018. 1003 [I-D.ietf-idr-bgpls-segment-routing-epe] 1004 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 1005 Dong, "BGP-LS extensions for Segment Routing BGP Egress 1006 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 1007 epe-15 (work in progress), March 2018. 1009 [I-D.ietf-lsvr-bgp-spf] 1010 Patel, K., Lindem, A., Zandi, S., and W. Henderickx, 1011 "Shortest Path Routing Extensions for BGP Protocol", 1012 draft-ietf-lsvr-bgp-spf-02 (work in progress), August 1013 2018. 1015 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 1016 DOI 10.17487/RFC1982, August 1996, 1017 . 1019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1020 Requirement Levels", BCP 14, RFC 2119, 1021 DOI 10.17487/RFC2119, March 1997, 1022 . 1024 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1025 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1026 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1027 . 1029 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1030 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1031 DOI 10.17487/RFC4271, January 2006, 1032 . 1034 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1035 IANA Considerations Section in RFCs", RFC 5226, 1036 DOI 10.17487/RFC5226, May 2008, 1037 . 1039 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1040 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1041 . 1043 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 1044 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 1045 June 2011, . 1047 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1048 S. Ray, "North-Bound Distribution of Link-State and 1049 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1050 DOI 10.17487/RFC7752, March 2016, 1051 . 1053 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1054 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1055 May 2017, . 1057 13.2. Informative References 1059 [JUPITER] Singh, A., Germano, P., Kanagala, A., Liu, H., Provost, 1060 J., Simmons, J., Tanda, E., Wanderer, J., HAP.lzle, U., 1061 Stuart, S., Vahdat, A., Ong, J., Agarwal, A., Anderson, 1062 G., Armistead, A., Bannon, R., Boving, S., Desai, G., and 1063 B. Felderman, "Jupiter rising", Communications of the 1064 ACM Vol. 59, pp. 88-97, DOI 10.1145/2975159, August 2016. 1066 Authors' Addresses 1068 Randy Bush 1069 Arrcus & IIJ 1070 5147 Crystal Springs 1071 Bainbridge Island, WA 98110 1072 United States of America 1074 Email: randy@psg.com 1076 Keyur Patel 1077 Arrcus 1078 2077 Gateway Place, Suite #250 1079 San Jose, CA 95119 1080 United States of America 1082 Email: keyur@arrcus.com