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