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

refs and other russ details

Browse source
This commit is contained in:
Randy Bush 2019-04-19 14:03:34 -07:00
parent ce7fcee117
commit 12f1e3c974
1 changed files with 69 additions and 45 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -56,17 +56,13 @@
<abstract> <abstract>
<t>Used in Massive Data Centers (MDCs), BGP-SPF and similar <t>In Massive Data Centers (MDCs), BGP-SPF and similar routing
protocols need IP neighbor discovery, logical link encapsulation protocols are used to build topology and reachability databases.
data, and Layer 2 liveness. The Layer 3 Discovery and Liveness These protocols need to discover IP Layer 3 attributes of links,
protocol provides discovery of the neighbor on a logical link, such as logical link IP encapsulation abilities, IP neighbor address
exchanges supported encapsulations (IPv4, IPv6, ...) with neighbors, discovery, and link liveness. The Layer 3 Discovery and Liveness
discovers encapsulation addresses (Layer 3 / MPLS identifiers), and protocol specified in this document collects these data, which are
provides layer 2 liveness checking. The interface data are pushed then disseminated using BGP-SPF and similar protocols.</t>
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>
</abstract> </abstract>
@ -93,11 +89,12 @@
deal with scaling, while BGP-SPF <xref deal with scaling, while BGP-SPF <xref
target="I-D.ietf-lsvr-bgp-spf"/> provides massive scale-out without target="I-D.ietf-lsvr-bgp-spf"/> provides massive scale-out without
centralization using a tried and tested scalable distributed control centralization using a tried and tested scalable distributed control
plane, offering a scalable routing solution in Clos and similar plane, offering a scalable routing solution in Clos <xref
environments. But BGP-SPF and similar higher level device-spanning target="Clos0"/><xref target="Clos1"/> and similar environments. But
protocols, e.g. <xref target="I-D.malhotra-bess-evpn-lsoe"/>, need BGP-SPF and similar higher level device-spanning protocols,
logical link state and addressing data from the network to build the e.g. <xref target="I-D.malhotra-bess-evpn-lsoe"/>, need logical link
routing topology. They also need prompt reaction to (logical) link state and addressing data from the network to build the routing
topology. They also need prompt reaction to (logical) link
failure.</t> failure.</t>
<t>Layer 3 Discovery and Liveness (L3DL) provides brutally simple <t>Layer 3 Discovery and Liveness (L3DL) provides brutally simple
@ -140,20 +137,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 Ethernet <t hangText="Datagram:">The L3DL content of a single Layer 2
frame. A full L3DL PDU may be packaged in multiple Datagrams.</t> frame. A full L3DL PDU may be packaged in 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, ...</t> 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 <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:">Media Access Control Address, <t hangText="MAC Address:">48-bit Layer 2 addresses are assumed
essentially an Ethernet address, six octets. See <xref since they are used by all widely deployed Layer 2 network
technologies of interest, especially Ethernet. See <xref
target="IEEE.802_2001"/>.</t> target="IEEE.802_2001"/>.</t>
<t hangText="MDC:">Massive Data Center, commonly thousands of <t hangText="MDC:">Massive Data Center, commonly thousands of
TORs.</t> TORs.</t>
@ -294,9 +292,9 @@
endpoint(s) reachable from an LLEI.</t> endpoint(s) reachable from an LLEI.</t>
<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 LLEIs, are mandatory; other PDUs to discover and exchange detailed LLEIs, and the ACK/ERROR PDU,
are optional; though at least one encapsulation MUST be agreed at are mandatory; other PDUs are optional; though at least one
some point.</t> encapsulation MUST be 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
exchanges:</t> exchanges:</t>
@ -403,8 +401,9 @@
Datagram, it is set to one.</t> Datagram, it is set to one.</t>
<t hangText="Datagram Number:">0..127, a monotonically increasing <t hangText="Datagram Number:">0..127, a monotonically increasing
value, modulo 128, see <xref target="RFC1982"/>. Note that this value, modulo 128, see <xref target="RFC1982"/> which starts at 0
does not limit an L3DL PDU to 128 frames.</t> 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 <t hangText="Datagram Length:">Total number of octets in the
Datagram including all payloads and fields.</t> 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 <t>The basic L3DL application layer PDU is a typical TLV (Type
Length Value) PDU. It includes a signature to provide optional Length Value) PDU. It includes a signature to provide optional
integrity and authentication. It may be broken into multiple 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" 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 <t hangText="Payload:">The application layer content of the L3DL
PDU.</t> 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> signature, is defined in this document.</t>
<t>Sig Type 0 indicates a null Signature. For very short PDUs, <t>Sig Type 0 indicates a null Signature. For very short PDUs,
the underlying Datagram cheksums may be sufficient for integrity, the underlying Datagram cheksums may be sufficient for integrity,
if not for authentication.</t> if not for authentication.</t>
<t>Sig Type 1, aimed at Trust On First Use, AKA TOFU, is specified <t>Sig Type 1, aimed at Trust On First Use (TOFU) is specified in
in a companion document [ref later].</t> a companion document [ref later].</t>
<t>Other Sig Types may be defined in other documents.</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> LLEIs.</t>
<t>Unfortunately, things can get more complex. Multiple VLANs can <t>Unfortunately, things can get more complex. Multiple VLANs can
run between those two MACS addresses. In practice, real devices use run between those two MAC addresses. In practice, many real devices
the same MAC address on multiple ports and/or sub-interfaces.</t> use the same MAC address on multiple ports and/or
sub-interfaces.</t>
<t>Therefore, in the general circumstance, a fully described LLEI <t>Therefore, in the general circumstance, a fully described LLEI
might be as follows:</t> 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 <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 layer identities, have means to ensure link state, etc., the L3DL
session is considered established, and the devices SHOULD exchange 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 <t>The Encapsulation types the peers exchange may be IPv4
Announcement (<xref target="ipv4"/>), IPv6 Announcement (<xref 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 <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,
the addressing for the type must be compatible, e.g. on the same 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"> <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"> <section anchor="keepalive" title="KEEPALIVE - Layer 2 Liveness">
<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.</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 <t>They 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
aggressive.</t> (or less) aggressive.</t>
<t>If a KEEPALIVE is not received from a peer with which a receiver <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), 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 <t>Vendors or enterprises may define TLVs beyond the scope of L3DL
standards. This is done using a Private Enterprise Number <xref 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 <t>Ent Type allows a VENDOR PDU to be sub-typed in the event that
the vendor/enterprise needs multiple PDU types.</t> 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 <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 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 <t>Therefore the LLEIs, link Encapsulations, and state changes are
pushed North via a small subset of the BGP-LS API. The upper layer 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 <t>Many MDC operators have a strange belief that physical walls and
firewalls provide sufficient security. This is not credible. All firewalls provide sufficient security. This is not credible. All
MDC protocols need to be examined for exposure and attack 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. 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.</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 <t>Siilarly, malicious nodes/devices could mis-announce
malicious sessions, etc.</t> addressing.</t>
<t>If OPENs are not being authenticated, an attacker could forge an <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> 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> </figure>
<t>This document requests the IANA create a registry for L3DL <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 name of the registry should be L3DL-Signature-Type. The policy for
adding to the registry is RFC Required per <xref target="RFC5226"/>, adding to the registry is RFC Required per <xref target="RFC5226"/>,
either standards track or experimental. The initial entries should 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.RFC.1122"?>
<?rfc include="reference.I-D.malhotra-bess-evpn-lsoe"?> <?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"?> <?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-doi/reference.DOI.10.1145/2975159.xml?anchor=JUPITER"?>
</references> <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> </back>
</rfc> </rfc>