open is acked, smoothed some wording
This commit is contained in:
parent
cacd4323ce
commit
b9ed685ed4
1 changed files with 78 additions and 61 deletions
|
|
@ -182,8 +182,9 @@
|
|||
|
||||
<section anchor="background" title="Background">
|
||||
|
||||
<t>L3DL assumes a Clos type datacenter scale and topology, but can
|
||||
accommodate richer topologies which contain potential cycles.</t>
|
||||
<t>L3DL is primarily designed for a Clos type datacenter scale and
|
||||
topology, but can accommodate richer topologies which contain
|
||||
potential cycles.</t>
|
||||
|
||||
<t>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 @@
|
|||
|
||||
<t>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.</t>
|
||||
|
||||
<t>Therefore the L3DL protocol is session oriented and uses
|
||||
incremental announcement and widrawal, a la BGP (<xref
|
||||
target="RFC4271"/>).</t>
|
||||
incremental announcement and widrawal with hot restart, a la BGP
|
||||
(<xref target="RFC4271"/>).</t>
|
||||
|
||||
</section>
|
||||
|
||||
|
|
@ -273,7 +274,8 @@
|
|||
<t>Two devices discover each other and their respective identities
|
||||
by sending multicast HELLO PDUs (<xref target="hello"/>). To allow
|
||||
discovery of new devices coming up on a multi-link topology, devices
|
||||
send periodic HELLOs forever, see <xref target="dhello"/>.</t>
|
||||
on such a topology send periodic HELLOs forever, see <xref
|
||||
target="dhello"/>.</t>
|
||||
|
||||
<t>Once a new device is recognized, both devices attempt to
|
||||
negotiate and establish peering by sending unicast OPEN PDUs (<xref
|
||||
|
|
@ -297,7 +299,7 @@
|
|||
<t>The HELLO and OPEN, <xref target="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.</t>
|
||||
|
||||
<t>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 @@
|
|||
|
||||
<t>The fields of the L3DL Transport Header are as follows:
|
||||
<list style="hanging">
|
||||
|
||||
|
||||
<t hangText="Version:">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.</t>
|
||||
the datagram as opposed to, for example, the PDU header.</t>
|
||||
|
||||
<t hangText="L:">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 @@
|
|||
<t hangText="Checksum:">A 32 bit hash over the Datagram to detect
|
||||
bit flips, see <xref target="checksum"/>.</t>
|
||||
|
||||
<t hangText="Payload:">The PDU being transported or a fragment
|
||||
thereof.</t>
|
||||
|
||||
</list></t>
|
||||
</section>
|
||||
|
||||
|
|
@ -527,8 +536,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
<t>The fields of the basic L3DL header are as follows:
|
||||
<list style="hanging">
|
||||
|
||||
<t hangText="Type:">An integer differentiating PDU payload types.
|
||||
See <xref target="iana-types"/>.</t>
|
||||
<t hangText="PDU Type:">An integer differentiating PDU payload
|
||||
types. See <xref target="iana-types"/>.</t>
|
||||
|
||||
<t hangText="Payload Length:">Total number of octets in the
|
||||
Payload field.</t>
|
||||
|
|
@ -570,8 +579,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
Identifier <xref target="RFC1629"/>, or any other identifier unique
|
||||
to a single logical link endpoint in the topology.</t>
|
||||
|
||||
<t>An L3DL deployment will choose and define an LLEI which suits
|
||||
their needs, simple or complex. Two extremes are as follows:</t>
|
||||
<t>An L3DL deployment will choose and define an LLEI which suits its
|
||||
needs, simple or complex. Two extremes are as follows:</t>
|
||||
|
||||
<t>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)
|
|||
<section anchor="hello" title="HELLO">
|
||||
|
||||
<t>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.</t>
|
||||
|
||||
<t>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)).</t>
|
||||
|
||||
<t hangText="01-80-C2-00-00-03:"> Nearest non-TPMR Bridge =
|
||||
Propagation constrained by all bridges other than TPMRs; intended
|
||||
for use within provider bridged networks.</t>
|
||||
<t hangText="To Be Assigned:"> 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 <xref
|
||||
target="ieee"/>.</t>
|
||||
|
||||
<?rfc subcompact="no"?></list></t>
|
||||
|
||||
|
|
@ -658,7 +667,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
HELLO.</t>
|
||||
|
||||
<t>If a constrained destination address configured, see above, then
|
||||
the HELLO need not be repeated.</t>
|
||||
the HELLO need not be repeated once a session has been created by an
|
||||
exchange of OPENs.</t>
|
||||
|
||||
<t>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.</t>
|
||||
|
||||
<t>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.</t>
|
||||
<t>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.</t>
|
||||
|
||||
<t>The Payload Length is zero as there is no payload.</t>
|
||||
|
||||
|
|
@ -733,13 +743,13 @@ q-->
|
|||
</figure>
|
||||
|
||||
<t>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.</t>
|
||||
PDU from the Nonce through the Serial Number, not including the
|
||||
three final signature fields.</t>
|
||||
|
||||
<t>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.</t>
|
||||
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.</t>
|
||||
|
||||
<t>My LLEI is the sender's LLEI, see <xref target="llei"/>.</t>
|
||||
|
||||
|
|
@ -766,9 +776,10 @@ q-->
|
|||
|
||||
<t>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.</t>
|
||||
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.</t>
|
||||
|
||||
<t>The Signature fields are described in <xref target="tlv"/> and in
|
||||
an asymmetric key environment serve as a proof of possession of the
|
||||
|
|
@ -781,21 +792,18 @@ q-->
|
|||
KEEPALIVE PDUs are discussed in <xref target="keepalive"/>.</t>
|
||||
|
||||
<t>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.</t>
|
||||
|
||||
<t>Resending an unacknowledged OPEN PDU, like other ACKed PDUs,
|
||||
SHOULD use exponential back-off, see <xref target="RFC1122"/>.</t>
|
||||
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 <xref target="RFC1122"/>.</t>
|
||||
|
||||
<t>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.</t>
|
||||
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.</t>
|
||||
|
||||
</section>
|
||||
|
||||
|
|
@ -893,10 +901,10 @@ q-->
|
|||
|
||||
<t>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.</t>
|
||||
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.</t>
|
||||
|
||||
<t>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.</t>
|
||||
|
||||
<t>If a sender has multiple links on the same interface, separate
|
||||
data, ACKs, etc. must be kept for each peer.</t>
|
||||
state: data, ACKs, etc. must be kept for each peer.</t>
|
||||
|
||||
<t>Over time, multiple Encapsulation PDUs may be sent for an
|
||||
interface as configuration changes.</t>
|
||||
|
||||
<t>If the length of an Encapsulation PDU exceeds the Datagram size
|
||||
limit on media, the PDU is broken into multiple Datagrams.
|
||||
See <xref target="tlv"/>.</t>
|
||||
limit on media, the PDU is broken into multiple Datagrams. See
|
||||
<xref target="tlv"/>.</t>
|
||||
|
||||
<t>The Signature fields are described in <xref target="tlv"/>.</t>
|
||||
|
||||
|
|
@ -981,7 +989,7 @@ q-->
|
|||
</figure>
|
||||
|
||||
<t>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.</t>
|
||||
|
||||
<t>Each Encapsulation interface address in an Encapsulation PDU is
|
||||
|
|
@ -995,10 +1003,10 @@ q-->
|
|||
<t>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.</t>
|
||||
be marked as primary for a particular encapsulation type.</t>
|
||||
|
||||
<t>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.</t>
|
||||
|
||||
<t>Loopback addresses are generally not seen directly on an
|
||||
|
|
@ -1010,8 +1018,8 @@ q-->
|
|||
<t>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.</t>
|
||||
container guest bridged on to the interface with an underlay
|
||||
address.</t>
|
||||
|
||||
</section>
|
||||
|
||||
|
|
@ -1247,9 +1255,10 @@ q-->
|
|||
ensure session continuity. A receiver may choose to ignore
|
||||
KEEPALIVE PDUs.</t>
|
||||
|
||||
<t>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.</t>
|
||||
<t>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.</t>
|
||||
|
||||
<t>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.</t>
|
||||
|
||||
<t>This protocol assumes that one or more Encapsulation addresses
|
||||
will be used to ping, BFD, or whatever the operator configures.</t>
|
||||
will be used to ping, run BFD, or whatever the operator
|
||||
configures.</t>
|
||||
|
||||
</section>
|
||||
|
||||
|
|
@ -1411,14 +1421,18 @@ q-->
|
|||
logical interface as L3DL speaking or not.</t>
|
||||
|
||||
<t>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 <xref
|
||||
HELLOs on an L3DL enabled interface send Nearest Bridge or the MAC
|
||||
which is propagated by switches from that interface; see <xref
|
||||
target="hello"/>.</t>
|
||||
|
||||
<t>An implementation SHOULD provide the ability to distribute one or
|
||||
more loopback addresses or interfaces into L3DL on an external L3DL
|
||||
speaking interface.</t>
|
||||
|
||||
<t>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.</t>
|
||||
|
||||
<t>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-->
|
|||
|
||||
<t>This document requires a new EtherType.</t>
|
||||
|
||||
<t>This document requires a new multicast MAC address that will be
|
||||
broadcast through a switch.</t>
|
||||
|
||||
</section>
|
||||
|
||||
<section anchor="acks" title="Acknowledgments">
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue