randy/draft-l3dl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

open is acked, smoothed some wording

Browse source
This commit is contained in:
Randy Bush 2019-06-04 12:17:11 -07:00
parent cacd4323ce
commit b9ed685ed4
1 changed files with 78 additions and 61 deletions
Download patch file Download diff file Expand all files Collapse all files

137
draft-ietf-lsvr-l3dl.xml
View file

@ -182,8 +182,9 @@
<section anchor="background" title="Background"> <section anchor="background" title="Background">
<t>L3DL assumes a Clos type datacenter scale and topology, but can <t>L3DL is primarily designed for a Clos type datacenter scale and
accommodate richer topologies which contain potential cycles.</t> topology, but can accommodate richer topologies which contain
potential cycles.</t>
<t>While L3DL is designed for the MDC, there are no inherent reasons <t>While L3DL is designed for the MDC, there are no inherent reasons
it could not run on a WAN. The authentication and authorization 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 <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 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 inordinate number of addresses. And highly automated micro-service
migration can cause serious address prefix disaggregation, resulting migration can cause serious address prefix disaggregation, resulting
in interfaces with thousands of disaggregated prefixes.</t> in interfaces with thousands of disaggregated prefixes.</t>
<t>Therefore the L3DL protocol is session oriented and uses <t>Therefore the L3DL protocol is session oriented and uses
incremental announcement and widrawal, a la BGP (<xref incremental announcement and widrawal with hot restart, a la BGP
target="RFC4271"/>).</t> (<xref target="RFC4271"/>).</t>
</section> </section>
@ -273,7 +274,8 @@
<t>Two devices discover each other and their respective identities <t>Two devices discover each other and their respective identities
by sending multicast HELLO PDUs (<xref target="hello"/>). To allow by sending multicast HELLO PDUs (<xref target="hello"/>). To allow
discovery of new devices coming up on a multi-link topology, devices 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 <t>Once a new device is recognized, both devices attempt to
negotiate and establish peering by sending unicast OPEN PDUs (<xref 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 <t>The HELLO and OPEN, <xref target="open"/>, PDUs, which are used
to discover and exchange detailed Logical Link Endpoint to discover and exchange detailed Logical Link Endpoint
Identifiers, LLEIs, and the ACK/ERROR PDU, are mandatory; other 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> agreed at some point.</t>
<t>The following is a ladder-style sketch of the L3DL protocol <t>The following is a ladder-style sketch of the L3DL protocol
@ -313,9 +315,13 @@
| | | |
| OPEN | MACs, IDs, etc. | OPEN | MACs, IDs, etc.
|----------------------------&gt;| |----------------------------&gt;|
| ACK |
|&lt;----------------------------|
| | | |
| OPEN | Mandatory | OPEN | Mandatory
|&lt;----------------------------| |&lt;----------------------------|
| ACK |
|----------------------------&gt;|
| | | |
| | | |
| Interface IPv4 Addresses | Interface IPv4 Addresses | Interface IPv4 Addresses | Interface IPv4 Addresses
@ -407,7 +413,7 @@
<t hangText="Version:">Seven-bit Version number of the protocol, <t hangText="Version:">Seven-bit Version number of the protocol,
currently 0. Values other than 0 are treated as errors. The 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 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 <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 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 <t hangText="Checksum:">A 32 bit hash over the Datagram to detect
bit flips, see <xref target="checksum"/>.</t> bit flips, see <xref target="checksum"/>.</t>
<t hangText="Payload:">The PDU being transported or a fragment
thereof.</t>
</list></t> </list></t>
</section> </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: <t>The fields of the basic L3DL header are as follows:
<list style="hanging"> <list style="hanging">
<t hangText="Type:">An integer differentiating PDU payload types. <t hangText="PDU Type:">An integer differentiating PDU payload
See <xref target="iana-types"/>.</t> types. See <xref target="iana-types"/>.</t>
<t hangText="Payload Length:">Total number of octets in the <t hangText="Payload Length:">Total number of octets in the
Payload field.</t> 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 Identifier <xref target="RFC1629"/>, or any other identifier unique
to a single logical link endpoint in the topology.</t> to a single logical link endpoint in the topology.</t>
<t>An L3DL deployment will choose and define an LLEI which suits <t>An L3DL deployment will choose and define an LLEI which suits its
their needs, simple or complex. Two extremes are as follows:</t> needs, simple or complex. Two extremes are as follows:</t>
<t>A simplistic view of a link between two devices is two ports, <t>A simplistic view of a link between two devices is two ports,
identified by unique MAC addresses, carrying a layer 3 protocol 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"> <section anchor="hello" title="HELLO">
<t>WARNING: The second multicast address below is incorrect. We <t>WARNING: The second multicast address below is incorrect. We
need to get a new assignment. When a switch receives a frame with a need to get a new assignment. , which is what we really wanted with the second address
multicast destination MAC it does not recognize, it forwards to all
ports, which is what we really wanted with the second address
below.</t> below.</t>
<t>The HELLO PDU is unique in that it is encapsulated in a multicast <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 constrained to a single physical link; stopped by all types of
bridges (including MPRs (media converters)).</t> bridges (including MPRs (media converters)).</t>
<t hangText="01-80-C2-00-00-03:"> Nearest non-TPMR Bridge = <t hangText="To Be Assigned:"> When a switch receives a frame with
Propagation constrained by all bridges other than TPMRs; intended a multicast destination MAC it does not recognize, it forwards to
for use within provider bridged networks.</t> 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> <?rfc subcompact="no"?></list></t>
@ -658,7 +667,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
HELLO.</t> HELLO.</t>
<t>If a constrained destination address configured, see above, then <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 <t>If the configured destination address is one that is propagated
by switches, the HELLO SHOULD be repeated at a configured interval, 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 each unique source LLEI response. L3DL treats each adjacency as a
separate logical link.</t> separate logical link.</t>
<t>When a HELLO is received from a source LLEI with which there is <t>When a HELLO is received from a source MAC address with which
no established L3DL adjacency, the receiver SHOULD respond with an there is no established L3DL adjacency, the receiver SHOULD respond
OPEN PDU. The two devices establish an L3DL adjacency by exchanging with an OPEN PDU. The two devices establish an L3DL adjacency by
OPEN PDUs.</t> exchanging OPEN PDUs.</t>
<t>The Payload Length is zero as there is no payload.</t> <t>The Payload Length is zero as there is no payload.</t>
@ -733,13 +743,13 @@ q-->
</figure> </figure>
<t>The Payload Length is the number of octets in all fields of the <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 PDU from the Nonce through the Serial Number, not including the
fields.</t> three final signature fields.</t>
<t>The Nonce enables detection of a duplicate OPEN PDU. It SHOULD <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 be either a random number or a high resolution timestamp. It is
prevent session closure due to a repeated OPEN caused by a race or a needed to prevent session closure due to a repeated OPEN caused by a
dropped or delayed ACK.</t> race or a dropped or delayed ACK.</t>
<t>My LLEI is the sender's LLEI, see <xref target="llei"/>.</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 <t>The Serial Number is that of the last received and processed
Encapsulation PDU. This allows a receiver sending an OPEN to tell Encapsulation PDU. This allows a receiver sending an OPEN to tell
the sender that it only needs to send data more recent than the the sender that the receiver wants to resume a session and the
Serial Number. If this OPEN is not trying to restart a lost sender only needs to send data more recent than the Serial Number.
session, the Serial Number MUST be set to zero.</t> 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 <t>The Signature fields are described in <xref target="tlv"/> and in
an asymmetric key environment serve as a proof of possession of the 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> 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, <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> then they MUST resend the same OPEN PDU, with the same Nonce.
Resending an unacknowledged OPEN PDU, like other ACKed PDUs, SHOULD
<t>Resending an unacknowledged OPEN PDU, like other ACKed PDUs, use exponential back-off, see <xref target="RFC1122"/>.</t>
SHOULD use exponential back-off, see <xref target="RFC1122"/>.</t>
<t>If a properly authenticated OPEN arrives with a new Nonce from an <t>If a properly authenticated OPEN arrives with a new Nonce from an
LLEI with which the receiving logical link endpoint believes it LLEI with which the receiving logical link endpoint believes it
already has an L3DL session (OPENs have already been exchanged), the already has an L3DL session (OPENs have already been exchanged), the
receiver MUST assume that the sending LLEI or entire device has been receiver MAY assume that the sending LLEI or entire device has been
reset. All discovered encapsulation data SHOULD be withdrawn via reset. If the Serial Number in the OPEN is zero, then all
the BGP-LS API and the recipient MUST respond with a new OPEN. In discovered encapsulation data SHOULD be withdrawn via the BGP-LS API
this circumstance encapsulations SHOULD NOT be kept because, while and the recipient MUST respond with a new OPEN. In this
the new OPEN is likely to be followed by new encapsulation PDUs of circumstance encapsulations SHOULD NOT be kept.</t>
the same data, the old session might have an encapsulation type not
in the new session.</t>
</section> </section>
@ -893,10 +901,10 @@ q-->
<t>A receiver of an encapsulation might recognize an addressing <t>A receiver of an encapsulation might recognize an addressing
conflict, such as both ends of the link trying to use the same conflict, such as both ends of the link trying to use the same
address. In this case, the receiver SHOULD respond with an ERROR address. In this case, the receiver SHOULD respond with an error
(Error Code 1) instead of an ACK. As there may be other usable (Error Code 1) ACK. As there may be other usable addresses or
addresses or encapsulations, this error might log and continue, encapsulations, this error might log and continue, letting an upper
letting an upper layer topology builder deal with what works.</t> layer topology builder deal with what works.</t>
<t>Further, to consider a logical link of a type to formally be <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, established so that it may be pushed up to upper layer protocols,
@ -942,14 +950,14 @@ q-->
send newer data.</t> send newer data.</t>
<t>If a sender has multiple links on the same interface, separate <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 <t>Over time, multiple Encapsulation PDUs may be sent for an
interface as configuration changes.</t> interface as configuration changes.</t>
<t>If the length of an Encapsulation PDU exceeds the Datagram size <t>If the length of an Encapsulation PDU exceeds the Datagram size
limit on media, the PDU is broken into multiple Datagrams. limit on media, the PDU is broken into multiple Datagrams. See
See <xref target="tlv"/>.</t> <xref target="tlv"/>.</t>
<t>The Signature fields are described in <xref target="tlv"/>.</t> <t>The Signature fields are described in <xref target="tlv"/>.</t>
@ -981,7 +989,7 @@ q-->
</figure> </figure>
<t>An Encapsulation PDU of Type T may announce new and/or withdraw <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> Encapsulation Flag, Announce == 1, Withdraw == 0.</t>
<t>Each Encapsulation interface address in an Encapsulation PDU is <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, <t>If an LLEI has multiple addresses for an encapsulation type,
one and only one address SHOULD be configured to be marked as one and only one address SHOULD be configured to be marked as
primary (Primary Flag == 1). Only one address on an interface MAY 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 <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> set.</t>
<t>Loopback addresses are generally not seen directly on an <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 <t>Each Encapsulation interface address in an Encapsulation PDU is
that of the direct 'underlay interface (Under/Over == 1), or an that of the direct 'underlay interface (Under/Over == 1), or an
'overlay' address (Under/Over == 0), likely that of a VM or 'overlay' address (Under/Over == 0), likely that of a VM or
container guest bridged on to an underlay address on the container guest bridged on to the interface with an underlay
interface.</t> address.</t>
</section> </section>
@ -1247,9 +1255,10 @@ q-->
ensure session continuity. A receiver may choose to ignore ensure session continuity. A receiver may choose to ignore
KEEPALIVE PDUs.</t> KEEPALIVE PDUs.</t>
<t>An operational deployment MUST BE configured to use KEEPALIVEs or <t>An operational deployment MUST BE configured whether to use
not, either globally, or down to per-link granularity. Disagreement KEEPALIVEs or not, either globally, or down to per-link granularity.
MAY result in repeated session break and reestablishment.</t> Disagreement MAY result in repeated session break and
reestablishment.</t>
<t>KEEPALIVEs SHOULD be beaconed at a configured frequency. One per <t>KEEPALIVEs SHOULD be beaconed at a configured frequency. One per
second is the default. Layer 3 liveness, such as BFD, may be more second is the default. Layer 3 liveness, such as BFD, may be more
@ -1289,7 +1298,8 @@ q-->
technique.</t> technique.</t>
<t>This protocol assumes that one or more Encapsulation addresses <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> </section>
@ -1411,14 +1421,18 @@ q-->
logical interface as L3DL speaking or not.</t> logical interface as L3DL speaking or not.</t>
<t>An implementation SHOULD provide the ability to configure whether <t>An implementation SHOULD provide the ability to configure whether
HELLOs on an L3DL enabled interface send Nearest Bridge or Nearest HELLOs on an L3DL enabled interface send Nearest Bridge or the MAC
non-TPMR Bridge multicast frames from that interface; see <xref which is propagated by switches from that interface; see <xref
target="hello"/>.</t> target="hello"/>.</t>
<t>An implementation SHOULD provide the ability to distribute one or <t>An implementation SHOULD provide the ability to distribute one or
more loopback addresses or interfaces into L3DL on an external L3DL more loopback addresses or interfaces into L3DL on an external L3DL
speaking interface.</t> 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 <t>An implementation SHOULD provide the ability to configure one of
the addresses of an encapsulation as primary on an L3DL speaking the addresses of an encapsulation as primary on an L3DL speaking
interface. If there is only one address for a particular 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 EtherType.</t>
<t>This document requires a new multicast MAC address that will be
broadcast through a switch.</t>
</section> </section>
<section anchor="acks" title="Acknowledgments"> <section anchor="acks" title="Acknowledgments">