refs and other russ details
This commit is contained in:
parent
ce7fcee117
commit
12f1e3c974
1 changed files with 69 additions and 45 deletions
|
|
@ -56,17 +56,13 @@
|
|||
|
||||
<abstract>
|
||||
|
||||
<t>Used in Massive Data Centers (MDCs), BGP-SPF and similar
|
||||
protocols need IP neighbor discovery, logical link encapsulation
|
||||
data, and Layer 2 liveness. The Layer 3 Discovery and Liveness
|
||||
protocol provides discovery of the neighbor on a logical link,
|
||||
exchanges supported encapsulations (IPv4, IPv6, ...) with neighbors,
|
||||
discovers encapsulation addresses (Layer 3 / MPLS identifiers), and
|
||||
provides layer 2 liveness checking. The interface data are pushed
|
||||
directly to a BGP API (for LSVR), obviating the need for centralized
|
||||
topology distribution architectures. This protocol is intended to
|
||||
be more widely applicable to other upper layer routing protocols
|
||||
which need logical link discovery and characterisation.</t>
|
||||
<t>In Massive Data Centers (MDCs), 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 logical link IP encapsulation abilities, IP neighbor address
|
||||
discovery, and link liveness. The Layer 3 Discovery and Liveness
|
||||
protocol specified in this document collects these data, which are
|
||||
then disseminated using BGP-SPF and similar protocols.</t>
|
||||
|
||||
</abstract>
|
||||
|
||||
|
|
@ -93,11 +89,12 @@
|
|||
deal with scaling, while BGP-SPF <xref
|
||||
target="I-D.ietf-lsvr-bgp-spf"/> provides massive scale-out without
|
||||
centralization using a tried and tested scalable distributed control
|
||||
plane, offering a scalable routing solution in Clos and similar
|
||||
environments. But BGP-SPF and similar higher level device-spanning
|
||||
protocols, e.g. <xref target="I-D.malhotra-bess-evpn-lsoe"/>, need
|
||||
logical link state and addressing data from the network to build the
|
||||
routing topology. They also need prompt reaction to (logical) link
|
||||
plane, offering a scalable routing solution in Clos <xref
|
||||
target="Clos0"/><xref target="Clos1"/> and similar environments. But
|
||||
BGP-SPF and similar higher level device-spanning protocols,
|
||||
e.g. <xref target="I-D.malhotra-bess-evpn-lsoe"/>, need logical link
|
||||
state and addressing data from the network to build the routing
|
||||
topology. They also need prompt reaction to (logical) link
|
||||
failure.</t>
|
||||
|
||||
<t>Layer 3 Discovery and Liveness (L3DL) provides brutally simple
|
||||
|
|
@ -140,20 +137,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 Ethernet
|
||||
<t hangText="Datagram:">The L3DL content of a single Layer 2
|
||||
frame. 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, ...</t>
|
||||
<t hangText="Frame:">An Ethernet Layer 2 packet.</t>
|
||||
<t hangText="Frame:">A Layer 2 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:">Media Access Control Address,
|
||||
essentially an Ethernet address, six octets. See <xref
|
||||
<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 thousands of
|
||||
TORs.</t>
|
||||
|
|
@ -294,9 +292,9 @@
|
|||
endpoint(s) reachable from an LLEI.</t>
|
||||
|
||||
<t>The HELLO and OPEN, <xref target="open"/>, PDUs, which are used
|
||||
to discover and exchange detailed LLEIs, are mandatory; other PDUs
|
||||
are optional; though at least one encapsulation MUST be agreed at
|
||||
some point.</t>
|
||||
to discover and exchange detailed LLEIs, and the ACK/ERROR PDU,
|
||||
are mandatory; other PDUs are optional; though at least one
|
||||
encapsulation MUST be agreed at some point.</t>
|
||||
|
||||
<t>The following is a ladder-style sketch of the L3DL protocol
|
||||
exchanges:</t>
|
||||
|
|
@ -403,8 +401,9 @@
|
|||
Datagram, it is set to one.</t>
|
||||
|
||||
<t hangText="Datagram Number:">0..127, a monotonically increasing
|
||||
value, modulo 128, see <xref target="RFC1982"/>. Note that this
|
||||
does not limit an L3DL PDU to 128 frames.</t>
|
||||
value, modulo 128, see <xref target="RFC1982"/> which starts at 0
|
||||
for each PDU. Note that this does not limit an L3DL PDU to 128
|
||||
frames.</t>
|
||||
|
||||
<t hangText="Datagram Length:">Total number of octets in the
|
||||
Datagram including all payloads and fields.</t>
|
||||
|
|
@ -488,7 +487,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
<t>The basic L3DL application layer PDU is a typical TLV (Type
|
||||
Length Value) PDU. It includes a signature to provide optional
|
||||
integrity and authentication. It may be broken into multiple
|
||||
Datagrams, see <xref target="transport"/> </t>
|
||||
Datagrams, see <xref target="transport"/>.</t>
|
||||
|
||||
<!--
|
||||
protocol "Type:8,Payload Length:16,Payload ...:40,Sig Type:8,Signature Length:16,Signature:40"
|
||||
|
|
@ -535,15 +534,15 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
<t hangText="Payload:">The application layer content of the L3DL
|
||||
PDU.</t>
|
||||
|
||||
<t hangText="Sec Type:">The type of the Signature. Type 0, a null
|
||||
<t hangText="Sig Type:">The type of the Signature. Type 0, a null
|
||||
signature, is defined in this document.</t>
|
||||
|
||||
<t>Sig Type 0 indicates a null Signature. For very short PDUs,
|
||||
the underlying Datagram cheksums may be sufficient for integrity,
|
||||
if not for authentication.</t>
|
||||
|
||||
<t>Sig Type 1, aimed at Trust On First Use, AKA TOFU, is specified
|
||||
in a companion document [ref later].</t>
|
||||
<t>Sig Type 1, aimed at Trust On First Use (TOFU) is specified in
|
||||
a companion document [ref later].</t>
|
||||
|
||||
<t>Other Sig Types may be defined in other documents.</t>
|
||||
|
||||
|
|
@ -580,8 +579,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
LLEIs.</t>
|
||||
|
||||
<t>Unfortunately, things can get more complex. Multiple VLANs can
|
||||
run between those two MACS addresses. In practice, real devices use
|
||||
the same MAC address on multiple ports and/or sub-interfaces.</t>
|
||||
run between those two MAC addresses. In practice, many real devices
|
||||
use the same MAC address on multiple ports and/or
|
||||
sub-interfaces.</t>
|
||||
|
||||
<t>Therefore, in the general circumstance, a fully described LLEI
|
||||
might be as follows:</t>
|
||||
|
|
@ -857,7 +857,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
<t>Once the devices know each other's LLEIs, know each other's upper
|
||||
layer identities, have means to ensure link state, etc., the L3DL
|
||||
session is considered established, and the devices SHOULD exchange
|
||||
interface encapsulations, addresses, (and labels).</t>
|
||||
L3 interface encapsulations, L3 addresses, and L2.5 labels.</t>
|
||||
|
||||
<t>The Encapsulation types the peers exchange may be IPv4
|
||||
Announcement (<xref target="ipv4"/>), IPv6 Announcement (<xref
|
||||
|
|
@ -881,7 +881,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
<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,
|
||||
the addressing for the type must be compatible, e.g. on the same
|
||||
IPvX subnet.</t>
|
||||
IP subnet.</t>
|
||||
|
||||
<section anchor="encaps" title="The Encapsulation PDU Skeleton">
|
||||
|
||||
|
|
@ -1152,11 +1152,16 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
<section anchor="keepalive" title="KEEPALIVE - Layer 2 Liveness">
|
||||
|
||||
<t>L3DL devices SHOULD beacon frequent Layer 2 KEEPALIVE PDUs to
|
||||
ensure session continuity.</t>
|
||||
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
|
||||
will result in repeated session break and restablishment.</t>
|
||||
|
||||
<t>They SHOULD be beaconed at a configured frequency. One per
|
||||
second is the default. Layer 3 liveness, such as BFD, may be more
|
||||
aggressive.</t>
|
||||
(or less) aggressive.</t>
|
||||
|
||||
<t>If a KEEPALIVE is not received from a peer with which a receiver
|
||||
has an open session for a configurable time (default 30 seconds),
|
||||
|
|
@ -1208,7 +1213,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
|
||||
<t>Vendors or enterprises may define TLVs beyond the scope of L3DL
|
||||
standards. This is done using a Private Enterprise Number <xref
|
||||
target="IANA-PEN"/> followed by free form data.</t>
|
||||
target="IANA-PEN"/> followed by Enterprise Data in a format
|
||||
defined for that Enterprise Number and Ent Type.</t>
|
||||
|
||||
<t>Ent Type allows a VENDOR PDU to be sub-typed in the event that
|
||||
the vendor/enterprise needs multiple PDU types.</t>
|
||||
|
|
@ -1242,7 +1248,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
|
||||
<t>Full topology discovery is not appropriate at the L3DL layer, so
|
||||
Dijkstra à la IS-IS etc. is assumed to be done by higher level
|
||||
protocols.</t>
|
||||
protocols such as BGP-SPF.</t>
|
||||
|
||||
<t>Therefore the LLEIs, link Encapsulations, and state changes are
|
||||
pushed North via a small subset of the BGP-LS API. The upper layer
|
||||
|
|
@ -1376,15 +1382,17 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
<t>Many MDC operators have a strange belief that physical walls and
|
||||
firewalls provide sufficient security. This is not credible. All
|
||||
MDC protocols need to be examined for exposure and attack
|
||||
surface.</t>
|
||||
surface. In the case of L3DL, Authentication and Integrity as
|
||||
provided in [draft-ymbk-l3dl-signing] is stronly recommended.</t>
|
||||
|
||||
<t>It is generally unwise to assume that on the wire Ethernet 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.</t>
|
||||
laptop might be plugged into a device's port, form malicious
|
||||
sessions, etc. to divert, intercept, or drop traffic.</t>
|
||||
|
||||
<t>Malicious nodes/devices could mis-announce addressing, form
|
||||
malicious sessions, etc.</t>
|
||||
<t>Siilarly, malicious nodes/devices could mis-announce
|
||||
addressing.</t>
|
||||
|
||||
<t>If OPENs are not being authenticated, an attacker could forge an
|
||||
OPEN for an existing session and cause the session to be reset.</t>
|
||||
|
|
@ -1420,7 +1428,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
</figure>
|
||||
|
||||
<t>This document requests the IANA create a registry for L3DL
|
||||
Signature Type, AKA Sig Tyoe, which may range from 0 to 255. The
|
||||
Signature Type, AKA Sig Type, which may range from 0 to 255. The
|
||||
name of the registry should be L3DL-Signature-Type. The policy for
|
||||
adding to the registry is RFC Required per <xref target="RFC5226"/>,
|
||||
either standards track or experimental. The initial entries should
|
||||
|
|
@ -1541,8 +1549,24 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
<?rfc include="reference.RFC.1122"?>
|
||||
<?rfc include="reference.I-D.malhotra-bess-evpn-lsoe"?>
|
||||
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-doi/reference.DOI.10.1145/2975159.xml?anchor=JUPITER"?>
|
||||
<reference anchor="Clos0" >
|
||||
<front>
|
||||
<title>A study of non-blocking switching networks [PAYWALLED]</title>
|
||||
<author initials="C." surname="Clos" fullname="Charles Clos">
|
||||
<organization></organization>
|
||||
</author>
|
||||
<date month="March" year="1953"/>
|
||||
</front>
|
||||
<seriesInfo name="Bell System Technical Journal" value="32 (2), pp 406-424"/>
|
||||
</reference>
|
||||
<reference anchor="Clos1" target="https://en.wikipedia.org/wiki/Clos_network/">
|
||||
<front>
|
||||
<title>Clos Network</title>
|
||||
<author/>
|
||||
<date/>
|
||||
</front>
|
||||
</reference>
|
||||
</references>
|
||||
|
||||
</back>
|
||||
|
||||
</rfc>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue