From b9ed685ed4ad37c6682b33f6601842018e7d63be Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Tue, 4 Jun 2019 12:17:11 -0700 Subject: [PATCH] open is acked, smoothed some wording --- draft-ietf-lsvr-l3dl.xml | 139 ++++++++++++++++++++++----------------- 1 file changed, 78 insertions(+), 61 deletions(-) diff --git a/draft-ietf-lsvr-l3dl.xml b/draft-ietf-lsvr-l3dl.xml index 0cae67e..9b36772 100644 --- a/draft-ietf-lsvr-l3dl.xml +++ b/draft-ietf-lsvr-l3dl.xml @@ -182,8 +182,9 @@
- L3DL assumes a Clos type datacenter scale and topology, but can - accommodate richer topologies which contain potential cycles. + L3DL is primarily designed for 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. The authentication and authorization @@ -194,14 +195,14 @@ The number of addresses of one Encapsulation type on an interface link may be quite large given a TOR with tens of servers, each - server having o few hundred micro-services, resulting in an + server having a few hundred micro-services, resulting in an inordinate number of addresses. And highly automated micro-service migration can cause serious address prefix disaggregation, resulting in interfaces with thousands of disaggregated prefixes. Therefore the L3DL protocol is session oriented and uses - incremental announcement and widrawal, a la BGP (). + incremental announcement and widrawal with hot restart, a la BGP + ().
@@ -273,7 +274,8 @@ 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 - send periodic HELLOs forever, see . + on such a topology send periodic HELLOs forever, see . Once a new device is recognized, both devices attempt to negotiate and establish peering by sending unicast OPEN PDUs (The HELLO and OPEN, , PDUs, which are used 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 + PDUs are optional; though at least one encapsulation SHOULD be agreed at some point. The following is a ladder-style sketch of the L3DL protocol @@ -313,9 +315,13 @@ | | | OPEN | MACs, IDs, etc. |---------------------------->| +| ACK | +|<----------------------------| | | | OPEN | Mandatory |<----------------------------| +| ACK | +|---------------------------->| | | | | | Interface IPv4 Addresses | Interface IPv4 Addresses @@ -403,11 +409,11 @@ The fields of the L3DL Transport Header are as follows: - + Seven-bit Version number of the protocol, currently 0. Values other than 0 are treated as errors. The protocol version nees to be in one and only one place, so it is in - the datagram as opposed to, for example, the PDU. + the datagram as opposed to, for example, the PDU header. A bit that set to one if this Datagram is the last Datagram of the PDU. For a PDU which fits in only one @@ -426,6 +432,9 @@ A 32 bit hash over the Datagram to detect bit flips, see . + The PDU being transported or a fragment + thereof. + @@ -527,8 +536,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) The fields of the basic L3DL header are as follows: - An integer differentiating PDU payload types. - See . + An integer differentiating PDU payload + types. See . Total number of octets in the Payload field. @@ -570,8 +579,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) Identifier , or any other identifier unique to a single logical link endpoint in the topology. - An L3DL deployment will choose and define an LLEI which suits - their needs, simple or complex. Two extremes are as follows: + An L3DL deployment will choose and define an LLEI which suits its + needs, simple or complex. Two extremes are as follows: A simplistic view of a link between two devices is two ports, identified by unique MAC addresses, carrying a layer 3 protocol @@ -628,9 +637,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
WARNING: The second multicast address below is incorrect. We - need to get a new assignment. When a switch receives a frame with a - multicast destination MAC it does not recognize, it forwards to all - ports, which is what we really wanted with the second address + need to get a new assignment. , which is what we really wanted with the second address below. The HELLO PDU is unique in that it is encapsulated in a multicast @@ -644,9 +651,11 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) constrained to a single physical link; stopped by all types of bridges (including MPRs (media converters)). - Nearest non-TPMR Bridge = - Propagation constrained by all bridges other than TPMRs; intended - for use within provider bridged networks. + When a switch receives a frame with + a multicast destination MAC it does not recognize, it forwards to + all ports. This destination MAC is to be sent when the interface + is known to be connected to a switch. See . @@ -658,7 +667,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) HELLO. If a constrained destination address configured, see above, then - the HELLO need not be repeated. + the HELLO need not be repeated once a session has been created by an + exchange of OPENs. If the configured destination address is one that is propagated by switches, the HELLO SHOULD be repeated at a configured interval, @@ -685,10 +695,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) each unique source LLEI response. L3DL treats each adjacency as a separate logical link. - 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. + When a HELLO is received from a source MAC 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. The Payload Length is zero as there is no payload. @@ -733,13 +743,13 @@ q--> The Payload Length is the number of octets in all fields of the - PDU from the Nonce through the Key, not including the signature - fields. + PDU from the Nonce through the Serial Number, not including the + three final signature fields. The Nonce enables detection of a duplicate OPEN PDU. It SHOULD - be either a random number or the time of day. It is needed to - prevent session closure due to a repeated OPEN caused by a race or a - dropped or delayed ACK. + be either a random number or a high resolution timestamp. It is + needed to prevent session closure due to a repeated OPEN caused by a + race or a dropped or delayed ACK. My LLEI is the sender's LLEI, see . @@ -766,9 +776,10 @@ q--> The Serial Number is that of the last received and processed Encapsulation PDU. This allows a receiver sending an OPEN to tell - the sender that it only needs to send data more recent than the - Serial Number. If this OPEN is not trying to restart a lost - session, the Serial Number MUST be set to zero. + the sender that the receiver wants to resume a session and the + sender only needs to send data more recent than the Serial Number. + If this OPEN is not trying to restart a lost session, the Serial + Number MUST be set to zero. The Signature fields are described in and in an asymmetric key environment serve as a proof of possession of the @@ -781,21 +792,18 @@ q--> KEEPALIVE PDUs are discussed in . If a sender of OPEN does not receive an ACK of the OPEN PDU Type, - then they MUST resend the same OPEN PDU, with the same Nonce. - - Resending an unacknowledged OPEN PDU, like other ACKed PDUs, - SHOULD use exponential back-off, see . + then they MUST resend the same OPEN PDU, with the same Nonce. + Resending an unacknowledged OPEN PDU, like other ACKed PDUs, SHOULD + use exponential back-off, see . If a properly authenticated OPEN arrives with a new Nonce from an LLEI with which the receiving logical link endpoint believes it already has an L3DL session (OPENs have already been exchanged), the - receiver MUST assume that the sending LLEI or entire device has been - reset. All discovered encapsulation data SHOULD be withdrawn via - the BGP-LS API and the recipient MUST respond with a new OPEN. In - this circumstance encapsulations SHOULD NOT be kept because, while - the new OPEN is likely to be followed by new encapsulation PDUs of - the same data, the old session might have an encapsulation type not - in the new session. + receiver MAY assume that the sending LLEI or entire device has been + reset. If the Serial Number in the OPEN is zero, then all + discovered encapsulation data SHOULD be withdrawn via the BGP-LS API + and the recipient MUST respond with a new OPEN. In this + circumstance encapsulations SHOULD NOT be kept.
@@ -893,10 +901,10 @@ q--> A receiver of an encapsulation might recognize an addressing conflict, such as both ends of the link trying to use the same - address. In this case, the receiver SHOULD respond with an ERROR - (Error Code 1) instead of an ACK. As there may be other usable - addresses or encapsulations, this error might log and continue, - letting an upper layer topology builder deal with what works. + address. In this case, the receiver SHOULD respond with an error + (Error Code 1) ACK. As there may be other usable addresses or + encapsulations, this error might log and continue, letting an upper + layer topology builder deal with what works. Further, to consider a logical link of a type to formally be established so that it may be pushed up to upper layer protocols, @@ -942,14 +950,14 @@ q--> send newer data. If a sender has multiple links on the same interface, separate - data, ACKs, etc. must be kept for each peer. + state: data, ACKs, etc. must be kept for each peer. Over time, multiple Encapsulation PDUs may be sent for an interface as configuration changes. If the length of an Encapsulation PDU exceeds the Datagram size - limit on media, the PDU is broken into multiple Datagrams. - See . + limit on media, the PDU is broken into multiple Datagrams. See + . The Signature fields are described in . @@ -981,7 +989,7 @@ q--> An Encapsulation PDU of Type T may announce new and/or withdraw - old encapsulations of Type T. It indicates this with the Add/With + old encapsulations of Type T. It indicates this with the Ann/With Encapsulation Flag, Announce == 1, Withdraw == 0. Each Encapsulation interface address in an Encapsulation PDU is @@ -995,10 +1003,10 @@ q--> If an LLEI has multiple addresses for an encapsulation type, one and only one address SHOULD be configured to be marked as primary (Primary Flag == 1). Only one address on an interface MAY - be marked as primary for each encapsulation type. + be marked as primary for a particular encapsulation type. An Encapsulation interface address in an Encapsulation PDU MAY - be marked as a loopback, in which case the respective bit is + be marked as a loopback, in which case the Loopback bit is set. Loopback addresses are generally not seen directly on an @@ -1010,8 +1018,8 @@ q--> Each Encapsulation interface address in an Encapsulation PDU is that of the direct 'underlay interface (Under/Over == 1), or an 'overlay' address (Under/Over == 0), likely that of a VM or - container guest bridged on to an underlay address on the - interface. + container guest bridged on to the interface with an underlay + address. @@ -1247,9 +1255,10 @@ q--> ensure session continuity. A receiver may choose to ignore KEEPALIVE PDUs. - An operational deployment MUST BE configured to use KEEPALIVEs or - not, either globally, or down to per-link granularity. Disagreement - MAY result in repeated session break and reestablishment. + An operational deployment MUST BE configured whether to use + KEEPALIVEs or not, either globally, or down to per-link granularity. + Disagreement MAY result in repeated session break and + reestablishment. KEEPALIVEs SHOULD be beaconed at a configured frequency. One per second is the default. Layer 3 liveness, such as BFD, may be more @@ -1289,7 +1298,8 @@ q--> technique. This protocol assumes that one or more Encapsulation addresses - will be used to ping, BFD, or whatever the operator configures. + will be used to ping, run BFD, or whatever the operator + configures. @@ -1411,14 +1421,18 @@ q--> logical interface as L3DL speaking or not. An implementation SHOULD provide the ability to configure whether - HELLOs on an L3DL enabled interface send Nearest Bridge or Nearest - non-TPMR Bridge multicast frames from that interface; see . An implementation SHOULD provide the ability to distribute one or more loopback addresses or interfaces into L3DL on an external L3DL speaking interface. + An implementation SHOULD provide the ability to distribute one or + more overlay and/or underlay addresses or interfaces into L3DL on an + external L3DL speaking interface. + An implementation SHOULD provide the ability to configure one of the addresses of an encapsulation as primary on an L3DL speaking interface. If there is only one address for a particular @@ -1558,6 +1572,9 @@ q--> This document requires a new EtherType. + This document requires a new multicast MAC address that will be + broadcast through a switch. +