diff --git a/draft-ietf-lsvr-l3dl.xml b/draft-ietf-lsvr-l3dl.xml index 049de87..5d8ddb3 100644 --- a/draft-ietf-lsvr-l3dl.xml +++ b/draft-ietf-lsvr-l3dl.xml @@ -90,19 +90,19 @@ target="I-D.ietf-lsvr-bgp-spf"/> provides massive scale-out without centralization using a tried and tested scalable distributed control plane, offering a scalable routing solution in Clos and similar environments. But - BGP-SPF and similar higher level device-spanning protocols, + target="Clos0"/> and similar environments. + But BGP-SPF and similar higher level device-spanning protocols, e.g. , need logical link state and addressing data from the network to build the routing - topology. They also need prompt reaction to (logical) link - failure. + topology. They also need prompt but prudent reaction to (logical) + link failure. Layer 3 Discovery and Liveness (L3DL) provides brutally simple mechanisms for devices to Discover unique identities of devices/ports/... on a logical link, Run Layer 2 keep-alive messages for session continuity, - Discover each other's unique IDs (ASN, RouterID, ...), + Discover each other's unique endpoint identification, Discover mutually supported encapsulations, e.g. IP/MPLS, Discover Layer 3 IP and/or MPLS addressing of interfaces of the encapsulations, @@ -186,12 +186,10 @@ L3DL assumes a Clos type datacenter scale and topology, but can accommodate richer topologies which contain potential cycles. - While L3DL is designed for the MDC, there are no inherent - reasons it could not run on a WAN; though, as it is simply a - discovery protocol, it is not clear that this would be useful. - The authentication and authorization needed to run safely on a - WAN need to be considered, and the appropriate level of security - options chosen. + While L3DL is designed for the MDC, there are no inherent reasons + it could not run on a WAN. The authentication and authorization + needed to run safely on a WAN need to be considered, and the + appropriate level of security options chosen. L3DL assumes a new IEEE assigned EtherType (TBD). @@ -212,8 +210,8 @@ Layer 2 Liveness Checks may be started Encapsulation data are exchanged and IP-Level Liveness Checks enabled - A BGP-like protocol is assumed to use these data to discover - and build a topology database + A BGP-like upper layer protocol is assumed to use these data to + discover and build a topology database
@@ -262,15 +260,13 @@ The upper layer BGP family routing protocols cross all the devices, though they are not part of these L3DL protocols. - To simplify this document, Layer 2 Ethernet framing is not - shown. L3DL is about layer 3. + To simplify this document, Layer 2 framing is not shown. L3DL is + about layer 3.
- - Two devices discover each other and their respective identities by sending multicast HELLO PDUs (). To allow discovery of new devices coming up on a multi-link topology, devices @@ -289,12 +285,14 @@ The HELLO, , is a priming message. It is a small L3DL PDU encapsulated in an Ethernet multicast frame with the simple goal of discovering the identities of logical link - endpoint(s) reachable from an LLEI. + endpoint(s) reachable from a Logical Link Endpoint, . The HELLO and OPEN, , PDUs, which are used - to discover and exchange detailed LLEIs, and the ACK/ERROR PDU, - are mandatory; other PDUs are optional; though at least one - encapsulation MUST be agreed at some point. + to discover and exchange detailed Logical Link Endpoint + Identifiers, LLEIs, and the ACK/ERROR PDU, are mandatory; other + PDUs are optional; though at least one encapsulation MUST be + agreed at some point. The following is a ladder-style sketch of the L3DL protocol exchanges: @@ -375,6 +373,10 @@ The L3DL Transport Layer encapsulates each Datagram using a common transport header. + If a PDU does not fit in a single datagram, it is broken into + multiple datagrams and reassembled by the receiver a la . + @@ -398,7 +400,8 @@ A bit that set to one if this Datagram is the last Datagram of the PDU. For a PDU which fits in only one - Datagram, it is set to one. + Datagram, it is set to one. Note that this is the inverse of the + marking technique used by . 0..127, a monotonically increasing value, modulo 128, see which starts at 0 @@ -541,9 +544,6 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) the underlying Datagram checksums may be sufficient for integrity, if not for authentication. - Sig Type 1, aimed at Trust On First Use (TOFU) is specified in - a companion document [ref later]. - Other Sig Types may be defined in other documents. The length of the Signature, @@ -605,9 +605,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) System Identifier, a la , is an eight octet identifier unique in the entire operational space. Routers and switches usually have internal MAC Addresses which can be padded - and used if no System ID exists on the device. If no unique - identifier is burned into a device, the local L3DL configuration - SHOULD create and assign a unique one by configuration. + with high order zeros and used if no System ID exists on the device. + If no unique identifier is burned into a device, the local L3DL + configuration SHOULD create and assign a unique one by + configuration. ifIndex is the SNMP identifier of the (sub-)interface, see . This uniquely identifies the port. @@ -616,6 +617,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) Ifindex is that of the logical sub-interface, so no further disambiguation is needed. + L3DL PDUs learned over VLAN-ports may be interpreted by upper + layer-3 routing protocols as being learned on the corresponding + layer-3 SVI interface for the VLAN. +
@@ -637,8 +642,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) - All other L3DL PDUs are encapsulated in unicast Ethernet frames, - as the peer's destination MAC address is known after the HELLO + All other L3DL PDUs are encapsulated in unicast frames, as the + peer's destination MAC address is known after the HELLO exchange. When an interface is turned up on a device, it SHOULD issue a @@ -662,18 +667,18 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
If more than one device responds, one adjacency is formed for - each unique (source link address) response. L3DL treats each - adjacency as a separate logical link. + each unique source LLEI response. L3DL treats each adjacency as a + separate logical link. - When a HELLO is received from a source link address with which - there is no established L3DL adjacency, the receiver SHOULD respond - with an OPEN PDU. The two devices establish an L3DL adjacency by - exchanging OPEN PDUs. + When a HELLO is received from a source LLEI with which there is + no established L3DL adjacency, the receiver SHOULD respond with an + OPEN PDU. The two devices establish an L3DL adjacency by exchanging + OPEN PDUs. The Payload Length is zero as there is no payload. HELLO PDUs can not be signed as keying material has yet to be - exchanged. Hence the signature MUST always be null. + exchanged. Hence the signature MUST always be the null type. @@ -681,8 +686,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) Each device has learned the other's MAC Address from the HELLO exchange, see . Therefore the OPEN and - subsequent PDUs are unicast, as opposed to the HELLO's multicast, - Ethernet frames. + subsequent PDUs are unicast, as opposed to the HELLO's multicast + frame. - -
- - 0 1 2 3 - 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 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Type = 8 | Payload Length | ULP Type | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| AttrCount | Attribute List ... ~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Sig Type | Signature Length | Signature ... ~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- - ULP Type: - - - BGP - - -
- - The parameters needed for BGP peering on a link are exchanged - in sub-TLVs within an Upper Layer Protocol PDU. The following - describe the various sub-TLVs for BGP. - - If there are multiple BGP sessions on a link, e.g. IPv4 and - IPv6, then multiple Upper Layer Protocol PDUs are exchanged. - - As a link may have multiple encapsulations and multiple - addresses for an IP encapsulation, which address of which - encapsulation MUST be specified. - - For each BGP peering on a link here MUST be one agreed - encapsulation and matching subnet, and the addresses used MUST be - in the corresponding IPv4/IPv6 Announcement PDUs. - - - -
- - The Autonomous System number MUST be specified. If the AS - Number is less than 32 bits, it is padded with high order - zeros. - -
- - 0 1 2 3 - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Attr Type = 1 | Attr Len = 48 | My ASN ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- -
- -
- - - - The BGP IPv Address sub-TLV announces the sender's IPv4 BGP - peering source address to be used by the receiver. At least one - of IPv4 or IPv6 BGP source addresses MUST be announced. - -
- - 0 1 2 3 - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Attr Type = 2 | Attr Len = 56 | My IPv4 Peering Address ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ | Prefix Len | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- -
- -
- - The BGP IPv6 Address sub-TLV announces the sender's IPv6 BGP - peering source address to be used by the receiver. At least one - of IPv4 or IPv6 BGP source addresses MUST be announced. - - - -
- - 0 1 2 3 - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Attr Type = 3 | Attr Len = 144| | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | | - + + - | | - + + - | My IPv6 Peering Address | - + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | Prefix Len | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- -
- -
- - - -
- - 0 1 2 3 - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Attr Type = 4 | Attr Len | Auth Len | ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - ~ MD5 Auth ... ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- -
- -
- - The BGP session OPENs have great capability negotiation - facilities. In case one or more extra attributes might be - needed, the BGP Miscellaneous Flags sub-TLV may be used. No - flags are currently defined. - - -
- - 0 1 2 3 - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Attr Type = 5 | Attr Len = 32 | Misc Flags | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- - Misc Attrs: - - - Ghu knows what. - - -
- -
- - -
Layer 2 liveness may be continuously tested by KEEPALIVE PDUs, see . As layer 2.5 or layer 3 - connectivity could still break, liveness above layer 2 SHOULD be + connectivity could still break, liveness above layer 2 MAY be frequently tested using BFD () or a similar technique. @@ -1609,8 +1437,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) 5 IPv6 Announcement 6 MPLS IPv4 Announcement 7 MPLS IPv6 Announcement - 8 Upper Layer Protocol - 9-254 Reserved + 8-254 Reserved 255 VENDOR @@ -1734,6 +1561,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) +