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

hyphenate layer-x

Browse source
This commit is contained in:
Randy Bush 2021-02-06 12:29:28 -08:00
parent a65e2c0444
commit aa5277c9c9
1 changed files with 47 additions and 47 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -15,7 +15,7 @@
<front>
<title>Layer 3 Discovery and Liveness</title>
<title>Layer-3 Discovery and Liveness</title>
<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>Arrcus &amp; Internet Initiative Japan</organization>
@ -58,9 +58,9 @@
<t>In Massive Data Centers, BGP-SPF and similar routing protocols
are used to build topology and reachability databases. These
protocols need to discover IP Layer 3 attributes of links, such as
protocols need to discover IP Layer-3 attributes of links, such as
neighbor IP addressing, logical link IP encapsulation abilities, and
link liveness. This Layer 3 Discovery and Liveness protocol
link liveness. This Layer-3 Discovery and Liveness protocol
collects these data, which may then be disseminated using BGP-SPF
and similar protocols.</t>
@ -97,18 +97,18 @@
topology. They also need prompt but prudent reaction to (logical)
link failure.</t>
<t>Layer 3 Discovery and Liveness (L3DL) provides brutally simple
<t>Layer-3 Discovery and Liveness (L3DL) provides brutally simple
mechanisms for devices to <list style="symbols">
<t>Discover each other's unique endpoint identification,</t>
<t>Discover mutually supported layer 3 encapsulations, e.g.
<t>Discover mutually supported layer-3 encapsulations, e.g.
IP/MPLS,</t>
<t>Discover Layer 3 IP and/or MPLS addressing of interfaces of the
<t>Discover Layer-3 IP and/or MPLS addressing of interfaces of the
encapsulations,</t>
<t>Present these data, using a very restricted profile of a BGP-LS
<xref target="RFC7752"/> API, to BGP-SPF which computes the
topology and builds routing and forwarding tables,</t>
<t>Enable Layer 3 link liveness such as BFD,</t>
<t>Provide Layer 2 keep-alive messages for session continuity, and
<t>Enable Layer-3 link liveness such as BFD,</t>
<t>Provide Layer-2 keep-alive messages for session continuity, and
finally</t>
<t>Provide for authenticity verification of protocol messages.</t>
</list></t>
@ -116,12 +116,12 @@
<t>In this document, the use case for L3DL is for point to point
links in a datacenter Clos in order to exchange the data needed for
BGP-SPF <xref target="I-D.ietf-lsvr-bgp-spf"/> bootstrap and
continuity. Once layer two connectivity has been leveraged to get
layer three addressability and forwarding capabilities, normal layer
three forwarding and routing can take over.</t>
continuity. Once layer-2 connectivity has been leveraged to get
layer-3 addressability and forwarding capabilities, normal layer-3
forwarding and routing can take over.</t>
<t>L3DL might be found to be more widely applicable to a range of
routing and similar protocols which need layer three discovery and
routing and similar protocols which need layer-3 discovery and
characterisation.</t>
</section>
@ -135,7 +135,7 @@
<?rfc subcompact="yes"?>
<t hangText="ASN:">Autonomous System Number <xref
target="RFC4271"/>, a BGP identifier for an originator of
Layer 3 routes, particularly BGP announcements.</t>
Layer-3 routes, particularly BGP announcements.</t>
<t hangText="BGP-LS:">A mechanism by which link-state and TE
information can be collected from networks and shared with
external components using the BGP routing protocol. See <xref
@ -145,21 +145,21 @@
target="I-D.ietf-lsvr-bgp-spf"/>.</t>
<t hangText="Clos:">A hierarchic subset of a crossbar switch
topology commonly used in data centers.</t>
<t hangText="Datagram:">The L3DL content of a single Layer 2
<t hangText="Datagram:">The L3DL content of a single Layer-2
frame, sans Ethernet framing. A full L3DL PDU may be packaged in
multiple Datagrams.</t>
<t hangText="Encapsulation:">Address Family Indicator and
Subsequent Address Family Indicator (AFI/SAFI). I.e. classes of
layer 2.5 and 3 addresses such as IPv4, IPv6, MPLS, etc.</t>
<t hangText="Frame:">A Layer 2 Ethernet packet.</t>
layer-2.5 and 3 addresses such as IPv4, IPv6, MPLS, etc.</t>
<t hangText="Frame:">A Layer-2 Ethernet packet.</t>
<t hangText="Link or Logical Link:">A logical connection between
two logical ports on two devices. E.g. two VLANs between the same
two ports are two links.</t>
<t hangText="LLEI:">Logical Link Endpoint Identifier, the unique
identifier of one end of a logical link, see <xref
target="llei"/>.</t>
<t hangText="MAC Address:">48-bit Layer 2 addresses are assumed
since they are used by all widely deployed Layer 2 network
<t hangText="MAC Address:">48-bit Layer-2 addresses are assumed
since they are used by all widely deployed Layer-2 network
technologies of interest, especially Ethernet. See <xref
target="IEEE.802_2001"/>.</t>
<t hangText="MDC:">Massive Data Center, commonly composed of
@ -220,7 +220,7 @@
<t><list style="symbols">
<t>Devices discover each other on logical links</t>
<t>Logical Link Endpoint Identifiers (LLEIs) are exchanged</t>
<t>Layer 2 Liveness checks may be started</t>
<t>Layer-2 Liveness checks may be started</t>
<t>Encapsulation data are exchanged and IP-Level Liveness checks
enabled</t>
<t>A BGP-like upper layer protocol is assumed to use the
@ -257,12 +257,12 @@
</figure>
<t>There are two protocols, the inter-device (left-right in the
diagram) per-link layer 3 discovery and the API to the upper level
diagram) per-link layer-3 discovery and the API to the upper level
BGP-like routing protocol (up-down in the above diagram):
<list style="symbols">
<t>Inter-device PDUs are used to exchange device and logical link
identities and layer 2.5 (MPLS) and 3 identifiers (not payloads),
identities and layer-2.5 (MPLS) and 3 identifiers (not payloads),
e.g. device IDs, port identities, VLAN IDs, Encapsulations, and IP
addresses.</t>
@ -275,8 +275,8 @@
<t>The upper layer BGP family routing protocols cross all the
devices, though they are not part of these L3DL protocols.</t>
<t>To simplify this document, Layer 2 framing is not shown. L3DL is
about layer 3.</t>
<t>To simplify this document, Layer-2 framing is not shown. L3DL is
about layer-3.</t>
</section>
@ -381,7 +381,7 @@
|----------------------------&gt;|
| |
| |
| L3DL KEEPALIVE | Layer 2 Liveness
| L3DL KEEPALIVE | Layer-2 Liveness
|----------------------------&gt;| Optional
| L3DL KEEPALIVE |
|&lt;----------------------------|
@ -415,7 +415,7 @@
<t>L3DL is carrying relatively small amounts of data on relatively
high bandwidth links, and at a time when the link is not active with
other data as it does not yet have layer three connectivity. So
other data as it does not yet have layer-3 connectivity. So
congestion is not considered a sufficiently significant risk to
warrant additional complexity.</t>
@ -643,7 +643,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
needs, simple or complex. Examples of two extremes follow:</t>
<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
conversation. In this case, the MAC addresses might suffice for the
LLEIs.</t>
@ -682,7 +682,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>ifIndex is the SNMP identifier of the (sub-)interface, see <xref
target="RFC1213"/>. This uniquely identifies the port.</t>
<t>For a layer 3 tagged sub-interface or a VLAN/SVI interface,
<t>For a layer-3 tagged sub-interface or a VLAN/SVI interface,
Ifindex is that of the logical sub-interface, so no further
disambiguation is needed.</t>
@ -710,7 +710,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<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
all ports. This destination MAC SHOULD BE sent when the interface
is known to be connected to a switch. See <xref
target="ieee"/>. This SHOULD BE used when the link may be a
multi-point link.</t>
@ -864,8 +864,8 @@ q-->
signing auth data by the sender.</t>
<t>Once two logical link endpoints know each other, and have ACKed
each other's OPEN PDUs, Layer 2 KEEPALIVEs (see <xref
target="keepalive"/>) MAY be started to ensure Layer 2 liveness and
each other's OPEN PDUs, Layer-2 KEEPALIVEs (see <xref
target="keepalive"/>) MAY be started to ensure Layer-2 liveness and
keep the session semantics alive. The timing and acceptable drop of
KEEPALIVE PDUs are discussed in <xref target="keepalive"/>.</t>
@ -963,13 +963,13 @@ q-->
<t>If a PDU sender expects an ACK, e.g. for an OPEN, an
Encapsulation, a VENDOR PDU, etc., and does not receive the ACK
for a configurable time (default one second), and the interface is
live at layer 2, the sender resends the PDU using exponential
live at layer-2, the sender resends the PDU using exponential
back-off, see <xref target="RFC1122"/>. This cycle MAY be
repeated a configurable number of times (default three) before it
is considered a failure. The session MAY BE considered closed
in this case of this ACK failure.</t>
<t>If the link is broken at layer 2, retransmission MAY BE retried
<t>If the link is broken at layer-2, retransmission MAY BE retried
when the link is restored.</t>
</section>
@ -992,7 +992,7 @@ q-->
<t>The sender of an Encapsulation PDU MUST NOT assume that the peer
is capable of the same Encapsulation Type. An ACK (<xref
target="ack"/>) merely acknowledges receipt. Only if both peers
have sent the same Encapsulation Type is it safe for Layer 3
have sent the same Encapsulation Type is it safe for Layer-3
protocols to assume that they are compatible for that type.</t>
<t>A receiver of an encapsulation might recognize an addressing
@ -1063,12 +1063,12 @@ q-->
target="ack"/>.</t>
<t>If the Sender does not receive an ACK in a configurable
interval (default one second), and the interface is live at layer
2, they SHOULD retransmit. After a user configurable number of
failures (default three), the L3DL session should be considered
interval (default one second), and the interface is live at
layer-2, they SHOULD retransmit. After a user configurable number
of failures (default three), the L3DL session should be considered
dead and the OPEN process SHOULD be restarted.</t>
<t>If the link is broken at layer 2, retransmission MAY BE retried
<t>If the link is broken at layer-2, retransmission MAY BE retried
if data have not changed in the interim.</t>
</section>
@ -1348,7 +1348,7 @@ q-->
</section>
<section anchor="keepalive" title="KEEPALIVE - Layer 2 Liveness">
<section anchor="keepalive" title="KEEPALIVE - Layer-2 Liveness">
<!--
protocol "PDU Type = 2:8,Payload Length = 0:32,Sig Type = 0:8,Signature Length = 0:16"
@ -1366,7 +1366,7 @@ q-->
</artwork>
</figure>
<t>L3DL devices SHOULD beacon frequent Layer 2 KEEPALIVE PDUs to
<t>L3DL devices SHOULD beacon frequent Layer-2 KEEPALIVE PDUs to
ensure session continuity. The inter-KEEPALIVE interval is
configurable, with a default of ten seconds. A receiver may choose
to ignore KEEPALIVE PDUs.</t>
@ -1377,7 +1377,7 @@ q-->
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
second is the default. Layer-3 liveness, such as BFD, may be more
(or less) aggressive.</t>
<t>When a sender transmits a PDU which is not a KEEPALIVE, the
@ -1394,11 +1394,11 @@ q-->
</section>
<section anchor="l3liveness" title="Layers 2.5 and 3 Liveness">
<section anchor="l3liveness" title="Layers-2.5 and 3 Liveness">
<t>Layer 2 liveness may be continuously tested by KEEPALIVE PDUs,
see <xref target="keepalive"/>. As layer 2.5 or layer 3
connectivity could still break, liveness above layer 2 MAY be
<t>Layer-2 liveness may be continuously tested by KEEPALIVE PDUs,
see <xref target="keepalive"/>. As layer-2.5 or layer-3
connectivity could still break, liveness above layer-2 MAY be
frequently tested using BFD (<xref target="RFC5880"/>) or a similar
technique.</t>
@ -1470,7 +1470,7 @@ q-->
<section anchor="dhello" title="HELLO Discussion">
<t>A device with multiple Layer 2 interfaces, traditionally called
<t>A device with multiple Layer-2 interfaces, traditionally called
a switch, may be used to forward frames and therefore packets from
multiple devices to one logical interface (LLEI), I, on an L3DL
speaking device. Interface I could discover a peer J across the
@ -1554,7 +1554,7 @@ q-->
In the case of L3DL, Authentication and Integrity as provided in
<xref target="I-D.ymbk-lsvr-l3dl-signing"/> is strongly recommended.</t>
<t>It is generally unwise to assume that on the wire Layer 2 is
<t>It is generally unwise to assume that on the wire Layer-2 is
secure. Strange/unauthorized devices may plug into a port.
Mis-wiring is very common in datacenter installations. A poisoned
laptop might be plugged into a device's port, form malicious
@ -1683,7 +1683,7 @@ q-->
Kovuru for comments during implementation, Jeff Haas for review and
comments, Jörg Ott for an early but deep transport review, Joe
Clarke for a useful review, John Scudder for deeply serious review
and comments, Larry Kreeger for a lot of layer 2 clue, Martijn
and comments, Larry Kreeger for a lot of layer-2 clue, Martijn
Schmidt for his contribution, Nalinaksh Pai for transport
discussions, Neeraj Malhotra for review, Paul Congdon for Ethernet
hints, Russ Housley for checksum discussion and sBox, and Steve