randy/draft-l3dl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
draft-l3dl/draft-ietf-lsvr-l3dl.xml
Randy Bush 1e905ce5d3 rename ulpp to ulpc
2019-04-23 11:56:03 -07:00

1588 lines
66 KiB
XML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="6"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc category="std" docName="draft-ietf-lsvr-l3dl-00" ipr="trust200902">
<front>
<title>Layer 3 Discovery and Liveness</title>
<author fullname="Randy Bush" initials="R." surname="Bush">
<organization>Arrcus &amp; IIJ</organization>
<address>
<postal>
<street>5147 Crystal Springs</street>
<city>Bainbridge Island</city>
<region>WA</region>
<code>98110</code>
<country>United States of America</country>
</postal>
<email>randy@psg.com</email>
</address>
</author>
<author initials="R." surname="Austein" fullname="Rob Austein">
<organization abbrev="Arrcus">Arrcus, Inc</organization>
<address>
<email>sra@hactrn.net</email>
</address>
</author>
<author fullname="Keyur Patel" initials="K." surname="Patel">
<organization>Arrcus</organization>
<address>
<postal>
<street>2077 Gateway Place, Suite #400</street>
<city>San Jose</city>
<region>CA</region>
<code>95119</code>
<country>United States of America</country>
</postal>
<email>keyur@arrcus.com</email>
</address>
</author>
<date />
<abstract>
<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>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when,
and only when, they appear in all capitals, as shown here.</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Massive Data Center (MDC) environment presents unusual
problems of scale, e.g. O(10,000) devices, while its homogeneity
presents opportunities for simple approaches. Approaches such as
Jupiter Rising <xref target="JUPITER"/> use a central controller to
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 <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 but prudent reaction to (logical)
link failure.</t>
<t>Layer 3 Discovery and Liveness (L3DL) provides brutally simple
mechanisms for devices to <list style="symbols">
<t>Discover unique identities of devices/ports/... on a logical
link,</t>
<t>Run Layer 2 keep-alive messages for session continuity,</t>
<t>Discover each other's unique endpoint identification,</t>
<t>Discover mutually supported encapsulations, e.g. IP/MPLS,</t>
<t>Discover Layer 3 IP and/or MPLS addressing of interfaces of the
encapsulations,</t>
<t>Enable layer 3 link liveness such as BFD, and finally</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>
</list></t>
<t>This protocol may be more widely applicable to a range of routing
and similar protocols which need layer 3 discovery and
characterisation.</t>
</section>
<section anchor="terminology" title="Terminology">
<t>Even though it concentrates on the inter-device layer, this
document relies heavily on routing terminology. The following
attempts to clarify the use of some possibly confusing terms:
<list hangIndent="11" style="hanging">
<?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>
<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
target="RFC7752"/>.</t>
<t hangText="BGP-SPF">A hybrid protocol using BGP transport but
a Dijkstra SPF decision process. See <xref
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
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:">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:">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>
<t hangText="MTU:">Maximum Transmission Unit, the size in octets
of the largest packet that can be sent on a medium, see <xref
target="RFC1122"/> 1.3.3.</t>
<t hangText="PDU:">Protocol Data Unit, an L3DL application layer
message. A PDU may need to be broken into multiple Datagrams to
make it through MTU or other restrictions.</t>
<t hangText="RouterID:">An 32-bit identifier unique in the
current routing domain, see <xref target="RFC4271"/> updated by
<xref target="RFC6286"/>.</t>
<t hangText="Session:">An established, via OPEN PDUs, session
between two L3DL capable link end-points,</t>
<t hangText="SPF:">Shortest Path First, an algorithm for finding
the shortest paths between nodes in a graph; AKA Dijkstra's
algorithm.</t>
<t hangText="System Identifier:">An eight octet ISO System
Identifier a la <xref target="RFC1629"/> System ID</t>
<t hangText="TOR:">Top Of Rack switch, aggregates the servers in
a rack and connects to aggregation layers of the Clos tree, AKA
the Clos spine.</t>
<t hangText="ZTP:">Zero Touch Provisioning gives devices initial
addresses, credentials, etc. on boot/restart.</t>
<?rfc subcompact="no"?>
</list></t>
</section>
<section anchor="background" title="Background">
<t>L3DL assumes a Clos type datacenter scale and topology, but can
accommodate richer topologies which contain potential cycles.</t>
<t>While L3DL is designed for the MDC, there are no inherent reasons
it could not run on a WAN. The authentication and authorization
needed to run safely on a WAN need to be considered, and the
appropriate level of security options chosen.</t>
<t>L3DL assumes a new IEEE assigned EtherType (TBD).</t>
<t>The number of addresses of the Encapsulations on a link may be
fairly large given a TOR with more than 20 servers, each server
possibly having on the order of a hundred micro-services resulting
in an inordinate number of addresses. And security will further add
to the length of PDUs. PDUs with lengths over 10,000 octets are
likely or quite possible.</t>
</section>
<section anchor="top" title="Top Level Overview">
<t><list style="symbols">
<t>Devices discover each other on logical links</t>
<t>Logical Link Endpoint Identifiers are exchanged</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 these data to
discover and build a topology database</t>
</list></t>
<figure>
<artwork>
+-------------------+ +-------------------+ +-------------------+
| Device | | Device | | Device |
| | | | | |
|+-----------------+| |+-----------------+| |+-----------------+|
|| || || || || ||
|| BGP-SPF &lt;+---+&gt; BGP-SPF &lt;+---+&gt; BGP-SPF ||
|| || || || || ||
|+--------^--------+| |+--------^--------+| |+--------^--------+|
| | | | | | | | |
| | | | | | | | |
|+--------+--------+| |+--------+--------+| |+--------+--------+|
|| Encapsulations || || Encapsulations || || Encapsulations ||
|| Addresses || || Addresses || || Addresses ||
|| L2 Liveness || || L2 Liveness || || L2 Liveness ||
|+--------^--------+| |+--------^--------+| |+--------^--------+|
| | | | | | | | |
| | | | | | | | |
|+--------v--------+| |+--------v--------+| |+--------v--------+|
|| || || || || ||
||Inter-Device PDUs&lt;+---+&gt;Inter-Device PDUs&lt;+---+&gt;Inter-Device PDUs||
|| || || || || ||
|+-----------------+| |+-----------------+| |+-----------------+|
+-------------------+ +-------------------+ +-------------------+
</artwork>
</figure>
<t>There are two protocols, the inter-device per-link layer 3
discovery and the interface to the upper level BGP-like API:
<list style="symbols">
<t>Inter-device PDUs are used to exchange device and logical link
identities and layer 2.5 and 3 identifiers (not payloads), e.g.
device IDs, port identities, VLAN IDs, Encapsulations, and IP
addresses.</t>
<t>A Link Layer to BGP API presents these data up the stack to
a BGP protocol or an other device-spanning upper layer protocol,
presenting them using the BGP-LS BGP-like data format.</t>
</list></t>
<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>
</section>
<section anchor="ilpo" title="Inter-Link Protocol Overview">
<t>Two devices discover each other and their respective identities
by sending multicast HELLO PDUs (<xref target="hello"/>). To allow
discovery of new devices coming up on a multi-link topology, devices
send periodic HELLOs forever, see <xref target="dhello"/>.</t>
<t>Once a new device is recognized, both devices attempt to negotiate
and establish peering by sending unicast OPEN PDUs (<xref
target="open"/>). In an established peering, Encapsulations (<xref
target="afisafi"/>) may be announced and modified. When two
devices on a link have compatible Encapsulations and addresses,
i.e. the same AFI/SAFI and the same subnet, the link is announced
via the BGP-LS API.</t>
<section anchor="ladder" title="L3DL Ladder Diagram">
<t>The HELLO, <xref target="hello"/>, is a priming message. It is
a small L3DL PDU encapsulated in an Ethernet multicast frame with
the simple goal of discovering the identities of logical link
endpoint(s) reachable from a Logical Link Endpoint, <xref
target="llei"/>.</t>
<t>The HELLO and OPEN, <xref target="open"/>, PDUs, which are used
to discover and exchange detailed Logical Link Endpoint
Identifiers, 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>
<figure>
<artwork>
| HELLO | Logical Link Peer discovery
|----------------------------&gt;|
| HELLO | Mandatory
|&lt;----------------------------|
| |
| |
| OPEN | MACs, IDs, and Capabilities
|----------------------------&gt;|
| OPEN | Mandatory
|&lt;----------------------------|
| |
| |
| Interface IPv4 Addresses | Interface IPv4 Addresses
|----------------------------&gt;| Optional
| ACK |
|&lt;----------------------------|
| |
| Interface IPv4 Addresses |
|&lt;----------------------------|
| ACK |
|----------------------------&gt;|
| |
| |
| Interface IPv6 Addresses | Interface IPv6 Addresses
|----------------------------&gt;| Optional
| ACK |
|&lt;----------------------------|
| |
| Interface IPv6 Addresses |
|&lt;----------------------------|
| ACK |
|----------------------------&gt;|
| |
| |
| Interface MPLSv4 Labels | Interface MPLSv4 Labels
|----------------------------&gt;| Optional
| ACK |
|&lt;----------------------------|
| |
| Interface MPLSv4 Labels | Interface MPLSv4 Labels
|&lt;----------------------------| Optional
| ACK |
|----------------------------&gt;|
| |
| |
| Interface MPLSv6 Labels | Interface MPLSv6 Labels
|----------------------------&gt;| Optional
| ACK |
|&lt;----------------------------|
| |
| Interface MPLSv6 Labels | Interface MPLSv6 Labels
|&lt;----------------------------| Optional
| ACK |
|----------------------------&gt;|
| |
| |
| L3DL KEEPALIVE | Layer 2 Liveness
|----------------------------&gt;| Optional
| L3DL KEEPALIVE |
|&lt;----------------------------|
</artwork>
</figure>
</section>
</section>
<section anchor="transport" title="Transport Layer">
<t>L3DL PDUs are carried by a simple transport layer which allows
long PDUs to occupy many Ethernet frames. The L3DL data in each
frame is referred to as a Datagram.</t>
<t>The L3DL Transport Layer encapsulates each Datagram using a
common transport header.</t>
<t>If a PDU does not fit in a single datagram, it is broken into
multiple datagrams and reassembled by the receiver a la <xref
target="RFC0791"/>.</t>
<!--
protocol "Version:8,L:1,Datagram Number:7,Datagram Length:16,Checksum:32"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |L|Datagram Num.| Datagram Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The fields of the L3DL Transport Header are as follows:
<list style="hanging">
<t hangText="Version:">Version number of the protocol, currently
0. Values other than 0 are treated as errors.</t>
<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
Datagram, it is set to one. Note that this is the inverse of the
marking technique used by <xref target="RFC0791"/>.</t>
<t hangText="Datagram Number:">0..127, a monotonically increasing
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>
<t hangText="Checksum:">A 32 bit hash over the Datagram to detect
bit flips, see <xref target="checksum"/>.</t>
</list></t>
</section>
<section anchor="checksum" title="The Checksum">
<t>There is a reason conservative folk use a checksum in UDP. And
as many operators stretch to jumbo frames (over 1,500 octets) longer
checksums are the prudent approach.</t>
<t>For the purpose of computing a checksum, the checksum field
itself is assumed to be zero.</t>
<t>The following code describes the suggested algorithm.</t>
<figure>
<preamble>Sum up 32-bit unsigned ints in a 64-bit long, then take
the high-order section, shift it right, rotate, add it in, repeat
until zero.</preamble>
<artwork><![CDATA[
<CODE BEGINS>
#include <stddef.h>
#include <stdint.h>
/* The F table from Skipjack, and it would work for the S-Box. */
static const uint8_t sbox[256] = {
0xa3,0xd7,0x09,0x83,0xf8,0x48,0xf6,0xf4,0xb3,0x21,0x15,0x78,
0x99,0xb1,0xaf,0xf9,0xe7,0x2d,0x4d,0x8a,0xce,0x4c,0xca,0x2e,
0x52,0x95,0xd9,0x1e,0x4e,0x38,0x44,0x28,0x0a,0xdf,0x02,0xa0,
0x17,0xf1,0x60,0x68,0x12,0xb7,0x7a,0xc3,0xe9,0xfa,0x3d,0x53,
0x96,0x84,0x6b,0xba,0xf2,0x63,0x9a,0x19,0x7c,0xae,0xe5,0xf5,
0xf7,0x16,0x6a,0xa2,0x39,0xb6,0x7b,0x0f,0xc1,0x93,0x81,0x1b,
0xee,0xb4,0x1a,0xea,0xd0,0x91,0x2f,0xb8,0x55,0xb9,0xda,0x85,
0x3f,0x41,0xbf,0xe0,0x5a,0x58,0x80,0x5f,0x66,0x0b,0xd8,0x90,
0x35,0xd5,0xc0,0xa7,0x33,0x06,0x65,0x69,0x45,0x00,0x94,0x56,
0x6d,0x98,0x9b,0x76,0x97,0xfc,0xb2,0xc2,0xb0,0xfe,0xdb,0x20,
0xe1,0xeb,0xd6,0xe4,0xdd,0x47,0x4a,0x1d,0x42,0xed,0x9e,0x6e,
0x49,0x3c,0xcd,0x43,0x27,0xd2,0x07,0xd4,0xde,0xc7,0x67,0x18,
0x89,0xcb,0x30,0x1f,0x8d,0xc6,0x8f,0xaa,0xc8,0x74,0xdc,0xc9,
0x5d,0x5c,0x31,0xa4,0x70,0x88,0x61,0x2c,0x9f,0x0d,0x2b,0x87,
0x50,0x82,0x54,0x64,0x26,0x7d,0x03,0x40,0x34,0x4b,0x1c,0x73,
0xd1,0xc4,0xfd,0x3b,0xcc,0xfb,0x7f,0xab,0xe6,0x3e,0x5b,0xa5,
0xad,0x04,0x23,0x9c,0x14,0x51,0x22,0xf0,0x29,0x79,0x71,0x7e,
0xff,0x8c,0x0e,0xe2,0x0c,0xef,0xbc,0x72,0x75,0x6f,0x37,0xa1,
0xec,0xd3,0x8e,0x62,0x8b,0x86,0x10,0xe8,0x08,0x77,0x11,0xbe,
0x92,0x4f,0x24,0xc5,0x32,0x36,0x9d,0xcf,0xf3,0xa6,0xbb,0xac,
0x5e,0x6c,0xa9,0x13,0x57,0x25,0xb5,0xe3,0xbd,0xa8,0x3a,0x01,
0x05,0x59,0x2a,0x46
};
/* non-normative example C code, constant time even */
uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
{
uint32_t sum[4] = {0, 0, 0, 0};
uint64_t result = 0;
for (size_t i = 0; i < n; i++)
sum[i & 3] += sbox[*b++];
for (int i = 0; i < sizeof(sum)/sizeof(*sum); i++)
result = (result << 8) + sum[i];
result = (result >> 32) + (result & 0xFFFFFFFF);
result = (result >> 32) + (result & 0xFFFFFFFF);
return (uint32_t) result;
}
<CODE ENDS>
]]></artwork>
</figure>
</section>
<section anchor="tlv" title="TLV PDUs">
<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>
<!--
protocol "Type:8,Payload Length:16,Payload ...:40,Sig Type:8,Signature Length:16,Signature:40"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Payload Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Payload ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The fields of the basic L3DL header are as follows:
<list style="hanging">
<t hangText="Type:">An integer differentiating PDU payload types
<list style="empty">
<?rfc subcompact="yes"?>
<t>0 – HELLO</t>
<t>1 - OPEN</t>
<t>2 - KEEPALIVE</t>
<t>3 - ACK</t>
<t>4 - IPv4 Announcement</t>
<t>5 - IPv6 Announcement</t>
<t>6 - MPLS IPv4 Announcement</t>
<t>7 - MPLS IPv6 Announcement</t>
<t>8-254 Reserved</t>
<t>255 - VENDOR</t>
<?rfc subcompact="no"?>
</list></t>
<t hangText="Payload Length:">Total number of octets in the
Payload field.</t>
<t hangText="Payload:">The application layer content of the L3DL
PDU.</t>
<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 checksums may be sufficient for integrity,
if not for authentication.</t>
<t>Other Sig Types may be defined in other documents.</t>
<t hangText="Signature Length:">The length of the Signature,
possibly including padding, in octets. If Sig Type is 0,
Signature Length must be 0.</t>
<t hangText="Signature:">The result of running the signature
algorithm specified in Sig Type over all octets of the PDU except
for the Signature itself.</t>
</list></t>
</section>
<section anchor="llei" title="Logical Link Endpoint Identifier">
<t>L3DL discovers neighbors on logical links and establishes
sessions between the two ends of all consenting discovered logical
links. A logical link is described by a pair of Logical Link
Endpoint Identifiers, LLEIs.</t>
<t>An LLEI is a variable length descriptor which could be an ASN, a
classic RouterID, a catenation of the two, an eight octet ISO System
Identifier <xref target="RFC1629"/>, or any other identifier unique
to a single logical link endpoint in the topology.</t>
<t>An L3DL deployment will choose and define an LLEI which suits
their needs, simple or complex. Two extremes are as follows:</t>
<t>A simplistic view of a link between two devices is two ports,
identified by unique MAC addresses, carrying a layer 3 protocol
conversation. In this case, the MAC addresses might suffice for the
LLEIs.</t>
<t>Unfortunately, things can get more complex. Multiple VLANs can
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>
<!--
protocol "System Identifier:64,ifIndex:32"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ System Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>System Identifier, a la <xref target="RFC1629"/>, is an eight
octet identifier unique in the entire operational space. Routers
and switches usually have internal MAC Addresses which can be padded
with high order zeros and used if no System ID exists on the device.
If no unique identifier is burned into a device, the local L3DL
configuration SHOULD create and assign a unique one by
configuration.</t>
<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,
Ifindex is that of the logical sub-interface, so no further
disambiguation is needed.</t>
<t>L3DL PDUs learned over VLAN-ports may be interpreted by upper
layer-3 routing protocols as being learned on the corresponding
layer-3 SVI interface for the VLAN.</t>
</section>
<section anchor="hello" title="HELLO">
<t>The HELLO PDU is unique in that it is encapsulated in a multicast
Ethernet frame. It solicits response(s) from other LLEI(s) on the
link. See <xref target="dhello"/> for why multicast is used. The
destination multicast MAC Addressees to be used MUST be one of the
following, See Clause 9.2.2 of <xref target="IEEE802-2014"/>: <list
style="hanging"> <?rfc subcompact="yes"?>
<t hangText="01-80-C2-00-00-0E:">Nearest Bridge = Propagation
constrained to a single physical link; stopped by all types of
bridges (including MPRs (media converters)).</t>
<t hangText="01-80-C2-00-00-03:"> Nearest non-TPMR Bridge =
Propagation constrained by all bridges other than TPMRs; intended
for use within provider bridged networks.</t>
<?rfc subcompact="no"?></list></t>
<t>All other L3DL PDUs are encapsulated in unicast frames, as the
peer's destination MAC address is known after the HELLO
exchange.</t>
<t>When an interface is turned up on a device, it SHOULD issue a
HELLO periodically. The interval is set by configuration with a
default of 60 seconds.</t>
<!--
protocol "Type = 0:8,Payload Length = 0:16,Sig Type = 0:8,Signature Length = 0:16"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Payload Length = 0 | Sig Type = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>If more than one device responds, one adjacency is formed for
each unique source LLEI response. L3DL treats each adjacency as a
separate logical link.</t>
<t>When a HELLO is received from a source LLEI with which there is
no established L3DL adjacency, the receiver SHOULD respond with an
OPEN PDU. The two devices establish an L3DL adjacency by exchanging
OPEN PDUs.</t>
<t>The Payload Length is zero as there is no payload.</t>
<t>HELLO PDUs can not be signed as keying material has yet to be
exchanged. Hence the signature MUST always be the null type.</t>
</section>
<section anchor="open" title="OPEN">
<t>Each device has learned the other's MAC Address from the HELLO
exchange, see <xref target="hello"/>. Therefore the OPEN and
subsequent PDUs are unicast, as opposed to the HELLO's multicast
frame.</t>
<!--
protocol "Type = 1:8,Payload Length:16,Nonce:32,LLEI Length:8,My LLEI:64,AttrCount:8,Attribute List ...:24,Auth Type:8,Key Length:16,Key ...:40,Sig Type:8,Signature Length:16,Signature ...:40"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Payload Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | LLEI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ My LLEI ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AttrCount | Attribute List ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Key Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Key ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Signature ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<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
fields.</t>
<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
prevent session closure due to a repeated OPEN caused by a race or a
dropped or delayed ACK.</t>
<t>My LLEI is the sender's LLEI, see <xref target="llei"/>. LLEIs
are big-endian.</t>
<t>AttrCount is the number of attributes in the Attribute List.
Attributes are single octets whose semantics are user-defined.</t>
<t>A node may have zero or more user-defined attributes, e.g.
spine, leaf, backbone, route reflector, arabica, ...</t>
<t>Attribute syntax and semantics are local to an operator or
datacenter; hence there is no global registry. Nodes exchange
their attributes only in the OPEN PDU.</t>
<t>Auth Type is the Signature algorithm suite, see <xref
target="tlv"/>.</t>
<t>Key Length is a 16-bit field denoting the length in octets of the
Key, not including the Auth Type or the Key Lengths. If there is no
Key, the Auth Type and key Length MUST both be zero.</t>
<t>The Key is specific to the operational environment. A failure to
authenticate is a failure to start the L3DL session, an ERROR PDU is
sent (Error Code 2), and HELLOs MUST be restarted.</t>
<t>The Signature fields are described in <xref target="tlv"/> and in
an asymmetric key environment serve as a proof of possession of the
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
keep the session semantics alive. The timing and acceptable drop of
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,
then they MUST resend the same OPEN PDU, with the same Nonce.</t>
<t>Resending an unacknowledged OPEN PDU, like other ACKed PDUs,
SHOULD use exponential back-off, see <xref target="RFC1122"/>.</t>
<t>If a properly authenticated OPEN arrives with a new Nonce from an
LLEI with which the receiving logical link endpoint believes it
already has an L3DL session (OPENs have already been exchanged), the
receiver MUST assume that the sending LLEI or entire device has been
reset. All discovered encapsulation data SHOULD be withdrawn via
the BGP-LS API and the recipient MUST respond with a new OPEN. In
this circumstance encapsulations SHOULD NOT be kept because, while
the new OPEN is likely to be followed by new encapsulation PDUs of
the same data, the old session might have an encapsulation type not
in the new session.</t>
</section>
<section anchor="ack" title="ACK">
<!--
protocol "Type = 3:8,Payload Length = 5:16,PDU Type:8,EType:4,Error Code:12,Error Hint:16,Sig Type:8,Signature Length:16,Signature ...:40"
-->
<t>The ACK PDU acknowledges receipt of a PDU and reports any error
condition which might have been raised.</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Payload Length = 5 | PDU Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EType | Error Code | Error Hint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Signature ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The ACK acknowledges receipt of an OPEN, Encapsulation, VENDOR
PDU, etc.</t>
<t>The PDU Type is the Type of the PDU being acknowledged, e.g.,
OPEN or one of the Encapsulations.</t>
<t>If there was an error processing the received PDU, then the EType
is non-zero. If the EType is zero, Error Code and Error Hint MUST
also be zero.</t>
<t>A non-zero EType is the receiver's way of telling the PDU's
sender that the receiver had problems processing the PDU. The Error
Code and Error Hint will tell the sender more detail about the
error.</t>
<t>The decimal value of EType gives a strong hint how the receiver
sending the ACK believes things should proceed:
<list style="empty">
<?rfc subcompact="yes"?>
<t>0 - No Error, Error Code and Error Hint MUST be zero</t>
<t>1 - Warning, something not too serious happened, continue</t>
<t>2 - Session should not be continued, try to restart</t>
<t>3 - Restart is hopeless, call the operator</t>
<t>4-15 - Reserved</t>
<?rfc subcompact="no"?>
</list>
Someone stuck in the 1990s might think of the error codes as 0x1zzz,
0x2zzz, etc. They might be right. Or not.</t>
<t>The Error Code indicates the type of error.</t>
<t>The Error Hint is any additional data the sender of the error PDU
thinks will help the recipient or the debugger with the particular
error.</t>
<t>The Signature fields are described in <xref target="tlv"/>.</t>
<section anchor="retrans" title="Retransmission">
<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
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
case of this ACK failure.</t>
<t>If the link is broken at layer 2, retransmission MAY BE retried
when the link comes back up if data have not changed in the
interim.</t>
</section>
</section>
<section anchor="afisafi" title="The Encapsulations">
<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
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
target="ipv6"/>), MPLS IPv4 Announcement (<xref target="mpls4"/>),
MPLS IPv6 Announcement (<xref target="mpls6"/>), and/or possibly
others not defined here.</t>
<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 to assume that they
are compatible for that type.</t>
<t>A receiver of an encapsulation might recognize an addressing
conflict, such as both ends of the link trying to use the same
address. In this case, the receiver SHOULD respond with an ERROR
(Error Code 1) instead of an ACK. As there may be other usable
addresses or encapsulations, this error might log and continue,
letting an upper layer topology builder deal with what works.</t>
<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
IP subnet.</t>
<section anchor="encaps" title="The Encapsulation PDU Skeleton">
<t>The header for all encapsulation PDUs is as follows:</t>
<!--
protocol "Type:8,Payload Length:16,Count:8,...:8,Encapsulation List...:24,Sig Type:8,Signature Length:16,Signature ...:40"
-->
<figure>
<artwork>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Payload Length | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Encapsulation List... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Signature ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The 16-bit Count is the number of Encapsulations in the
Encapsulation list.</t>
<t>An Encapsulation PDU describes zero or more addresses of the
encapsulation type.</t>
<t>An Encapsulation PDU of Type T replaces all previous
encapsulations of Type T.</t>
<t>To remove all encapsulations of Type T, the sender uses a Count
of zero.</t>
<t>If an LLEI has multiple addresses for an encapsulation type,
one and only one address SHOULD be configured to be marked as
primary, see <xref target="primloop"/>.</t>
<t>Loopback addresses are generally not seen directly on an
external interface. One or more loopback addresses MAY be exposed
by configuration on one or more L3DL speaking external interfaces,
e.g. for iBGP peering. They SHOULD be marked as such, see <xref
target="primloop"/>.</t>
<t>If there is exactly one non-loopback address for an
encapsulation type on an interface, it SHOULD be marked as
primary.</t>
<t>If a sender has multiple links on the same interface, separate
data, ACKs, etc. must be kept for each peer.</t>
<t>Over time, multiple Encapsulation PDUs may be sent for an
interface as configuration changes.</t>
<t>If the length of an Encapsulation PDU exceeds the Datagram size
limit on media, the PDU is broken into multiple Datagrams.
See <xref target="tlv"/>.</t>
<t>The Signature fields are described in <xref target="tlv"/>.</t>
<t>The Receiver MUST acknowledge the Encapsulation PDU with a
Type=3, ACK PDU (<xref target="ack"/>) with the Encapsulation Type
being that of the encapsulation being announced, see <xref
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, 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
if data have not changed in the interim.</t>
</section>
<section anchor="primloop" title="Prim/Loop Flags">
<figure>
<artwork>
0 1 2 3 ... 7
+---------------+---------------+---------------+---------------+
| Primary | Loopback | Reserved ... | |
+---------------+---------------+---------------+---------------+
</artwork>
</figure>
<t>Each Encapsulation interface address MAY be marked as a primary
address, and/or a loopback, in which case the respective bit is
set to one.</t>
<t>Only one address MAY be marked as primary for an encapsulation
type.</t>
</section>
<section anchor="ipv4" title="IPv4 Encapsulation">
<t>The IPv4 Encapsulation describes a device's ability to exchange
IPv4 packets on one or more subnets. It does so by stating the
interface's addresses and the corresponding prefix lengths.</t>
<!--
protocol "Type = 4:8,Payload Length:16,Count:8,...:8,PrimLoop Flags:8,IPv4 Address:16,...:16,PrefixLen:8,more ...:8,Sig Type:8,Signature Length:16,Signature ...:40"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Payload Length | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PrimLoop Flags| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PrefixLen | more ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Signature ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The 16-bit Count is the number of IPv4 Encapsulations.</t>
</section>
<section anchor="ipv6" title="IPv6 Encapsulation">
<t>The IPv6 Encapsulation describes a logical link's ability to
exchange IPv6 packets on one or more subnets. It does so by
stating the interface's addresses and the corresponding prefix
lengths.</t>
<!--
protocol "Type = 5:8,Payload Length:16,Count:8,...:8,PrimLoop Flags:8,IPv6 Address:128,PrefixLen:8,more ...:8,Sig Type:8,Signature Length:16,Signature ...:40"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Payload Length | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PrimLoop Flags| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ +
| IPv6 Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PrefixLen | more ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Signature ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The 16-bit Count is the number of IPv6 Encapsulations.</t>
</section>
<section anchor="mplslist" title="MPLS Label List">
<t>As an MPLS enabled interface may have a label stack, see <xref
target="RFC3032"/>, a variable length list of labels is needed.</t>
<!--
protocol "Label Count:8,Label:20,Exp:3,S:1,Label:20,Exp:3,S:1,more ...:8"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Count | Label | Exp |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| more ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>A Label Count of zero is an implicit withdraw of all labels for
that prefix on that interface.</t>
</section>
<section anchor="mpls4" title="MPLS IPv4 Encapsulation">
<t>The MPLS IPv4 Encapsulation describes a logical link's ability
to exchange labeled IPv4 packets on one or more subnets. It does
so by stating the interface's addresses the corresponding prefix
lengths, and the corresponding labels.</t>
<!--
protocol "Type = 6:8,Payload Length:16,Count:8,...:8,PrimLoop Flags:8,MPLS Label List ...:16,...:16,IPv4 Address:16,...:16,PrefixLen:8,more ...:8,Sig Type:8,Signature Length:16,Signature ...:40"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Payload Length | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PrimLoop Flags| MPLS Label List ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PrefixLen | more ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Signature ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The 16-bit Count is the number of MPLSv6 Encapsulations.</t>
</section>
<section anchor="mpls6" title="MPLS IPv6 Encapsulation">
<t>The MPLS IPv6 Encapsulation describes a logical link's ability
to exchange labeled IPv6 packets on one or more subnets. It does
so by stating the interface's addresses, the corresponding prefix
lengths, and the corresponding labels.</t>
<!--
protocol "Type = 7:8,Payload Length:16,Count:8,...:8,PrimLoop Flags:8,MPLS Label List ...:16,...:16,IPv6 Address:128,Prefix Len:8,more ...:8,Sig Type:8,Signature Length:16,Signature ...:40"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Payload Length | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PrimLoop Flags| MPLS Label List ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ +
| IPv6 Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Len | more ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Signature ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The 16-bit Count is the number of MPLSv6 Encapsulations.</t>
</section>
</section>
<section anchor="keepalive" title="KEEPALIVE - Layer 2 Liveness">
<t>L3DL devices SHOULD beacon frequent Layer 2 KEEPALIVE PDUs to
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
MAY result in repeated session break 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
(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),
the link SHOULD BE presumed down. The devices MAY keep
configuration state and restore it without retransmission if no data
have changed. Otherwise, a new session SHOULD BE established and
new Encapsulation PDUs exchanged.</t>
<!--
protocol "Type = 2:8,Payload Length = 0:16,Sig Type = 0:8,Signature Length = 0:16"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Payload Length = 0 | Sig Type = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section anchor="vendor" title="VENDOR - Vendor Extensions">
<!--
protocol "Type = 255:8,Payload Length:16,...:8,Enterprise Number:24,Ent Type:8,Enterprise Data ...:32,Sig Type:8,Signature Length:16,Signature ...:40"
-->
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 255 | Payload Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number | Ent Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
~ Signature ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<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 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>
<t>As with Encapsulation PDUs, a receiver of a VENDOR PDU MUST
respond with an ACK or an ERROR PDU. Similarly, a VENDOR PDU MUST
only be sent over an open session.</t>
</section>
<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
frequently tested using BFD (<xref target="RFC5880"/>) or a similar
technique.</t>
<t>This protocol assumes that one or more Encapsulation addresses
will be used to ping, BFD, or whatever the operator configures.</t>
</section>
<section anchor="northsouth" title="The North/South Protocol">
<t>Thus far, a one-hop point-to-point logical link discovery
protocol has been defined.</t>
<t>The devices know their unique LLEIs and know the unique peer
LLEIs and Encapsulations on each logical link interface.</t>
<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 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
routing protocol(s), e.g. BGP-SPF, learn and maintain the topology,
run Dijkstra, and build the routing database(s).</t>
<t>For example, if a neighbor's IPv4 Encapsulation address changes,
the devices seeing the change push that change Northbound.</t>
<section anchor="ls" title="Use BGP-LS as Much as Possible">
<t>BGP-LS <xref target="RFC7752"/> defines BGP-like Datagrams
describing logical link state (links, nodes, link prefixes, and
many other things), and a new BGP path attribute providing
Northbound transport, all of which can be ingested by upper layer
protocols such as BGP-SPF; see Section 4 of <xref
target="I-D.ietf-lsvr-bgp-spf"/>.</t>
<t>For IPv4 links, TLVs 259 and 260 are used. For IPv6 links,
TLVs 261 and 262. If there are multiple addresses on a link,
multiple TLV pairs are pushed North, having the same ID pairs.</t>
</section>
<section anchor="ls-ext" title="Extensions to BGP-LS">
<t>The Northbound protocol needs a few minor extensions to BGP-LS.
Luckily, others have needed the same extensions.</t>
<t>Similarly to BGP-SPF, the BGP protocol is used in the
Protocol-ID field specified in table 1 of <xref
target="I-D.ietf-idr-bgpls-segment-routing-epe"/>. The local and
remote node descriptors for all NLRI are the IDs described in
<xref target="open"/>. This is equivalent to an adjacency SID or
a node SID if the address is a loopback address.</t>
<t>Label Sub-TLVs from <xref
target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/> Section 2.1.1,
are used to associate one or more MPLS Labels with a link.</t>
</section>
</section>
<section anchor="discuss" title="Discussion">
<t>This section explores some trade-offs taken and some
considerations.</t>
<section anchor="dhello" title="HELLO Discussion">
<!--
<t>There is the question of whether to allow an intermediate
switch to be transparent to discovery. We consider that an
interface on a device is a Layer 2 or a Layer 3 interface. In
theory it could be a Layer 3 interface with no encapsulation or
Layer 3 addressing currently configured.</t>
-->
<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
switch. Later, a prospective peer K could come up across the
switch. If I was not still sending and listening for HELLOs, the
potential peering with K could not be discovered. Therefore,
interfaces MUST continue to send HELLOs as long as they are turned
up.</t>
</section>
<section anchor="dkeepalive" title="HELLO versus KEEPALIVE">
<t>Both HELLO and KEEPALIVE are periodic. KEEPALIVE might be
eliminated in favor of keeping only HELLOs. But KEEPALIVEs are
unicast, and thus less noisy on the network, especially if HELLO
is configured to transit layer-2-only switches, see <xref
target="dhello"/>.</t>
</section>
</section>
<section anchor="vlans" title="VLANs/SVIs/Sub-interfaces">
<t>One can think of the protocol as an instance (i.e. state machine)
which runs on each logical link of a device.</t>
<t>As the upper routing layer must view VLAN topologies as separate
graphs, L3DL treats VLAN ports as separate links.</t>
<t>L3DL PDUs learned over VLAN-ports may be interpreted by upper
layer-3 routing protocols as being learned on the corresponding
layer-3 SVI interface for the VLAN.</t>
<t>As Sub-Interfaces each have their own LLIEs, they act as separate
interfaces, forming their own links.</t>
</section>
<section anchor="impl" title="Implementation Considerations">
<t>An implementation SHOULD provide the ability to configure a
logical interface as L3DL speaking or not.</t>
<t>An implementation SHOULD provide the ability to configure whether
HELLOs on an L3DL enabled interface send Nearest Bridge or Nearest
non-TPMR Bridge multicast frames from that interface; see <xref
target="hello"/>.</t>
<t>An implementation SHOULD provide the ability to distribute one or
more loopback addresses or interfaces into L3DL on an external L3DL
speaking interface.</t>
<t>An implementation SHOULD provide the ability to configure one of
the addresses of an encapsulation as primary on an L3DL speaking
interface. If there is only one address for a particular
encapsulation, the implementation MAY mark it as primary by
default.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>The protocol as it is MUST NOT be used outside a datacenter or
similarly closed environment due to lack of formal definition of the
authentication and authorization mechanism. Sufficient mechanisms
may be described in separate documents.</t>
<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. In the case of L3DL, Authentication and Integrity as
provided in [draft-ymbk-l3dl-signing] is strongly recommended.</t>
<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
sessions, etc. to divert, intercept, or drop traffic.</t>
<t>Similarly, 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>
<t>For these reasons, the OPEN PDU's authentication data exchange
SHOULD be used.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document requests the IANA create a registry for L3DL PDU
Type, which may range from 0 to 255. The name of the registry
should be L3DL-PDU-Type. The policy for adding to the registry is
RFC Required per <xref target="RFC5226"/>, either standards track or
experimental. The initial entries should be the following:</t>
<figure>
<artwork>
PDU
Code PDU Name
---- -------------------
0 HELLO
1 OPEN
2 KEEPALIVE
3 ACK
4 IPv4 Announcement
5 IPv6 Announcement
6 MPLS IPv4 Announcement
7 MPLS IPv6 Announcement
8-254 Reserved
255 VENDOR
</artwork>
</figure>
<t>This document requests the IANA create a registry for L3DL
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
be the following:</t>
<figure>
<artwork>
Number Name
------ -------------------
0 Null
1-255 Reserved
</artwork>
</figure>
<t>This document requests the IANA create a registry for L3DL PL
Flag Bits, which may range from 0 to 7. The name of the registry
should be L3DL-PL-Flag-Bits. The policy for adding to the registry is
RFC Required per <xref target="RFC5226"/>, either standards track or
experimental. The initial entries should be the following:</t>
<figure>
<artwork>
Bit Bit Name
---- -------------------
0 Primary
1 Loopback
2-7 Reserved
</artwork>
</figure>
<t>This document requests the IANA create a registry for L3DL Error
Codes, a 16 bit integer. The name of the registry should be
L3DL-Error-Codes. The policy for adding to the registry is RFC
Required per <xref target="RFC5226"/>, either standards track or
experimental. The initial entries should be the following:</t>
<figure>
<artwork>
Error
Code Error Name
---- -------------------
0 No Error
1 Logical Link Addressing Conflict
2 Authorization Failure in OPEN
3 Signature Failure in PDU
</artwork>
</figure>
</section>
<section anchor="ieee" title="IEEE Considerations">
<t>This document requires a new EtherType.</t>
</section>
<section anchor="acks" title="Acknowledgments">
<t>The authors thank Cristel Pelsser for multiple reviews, Jeff Haas
for review and comments, Joe Clarke for a useful review, John
Scudder for deeply serious review and comments, Larry Kreeger for a
lot of layer 2 clue, Martijn Schmidt for his contribution, Neeraj
Malhotra for review, Russ Housley for checksum discussion and sBox,
and Steve Bellovin for checksum advice.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.1213"?>
<?rfc include="reference.RFC.1629"?>
<?rfc include="reference.RFC.1982"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3032"?>
<?rfc include="reference.RFC.4271"?>
<?rfc include="reference.I-D.ietf-lsvr-bgp-spf"?>
<?rfc include="reference.RFC.5226"?>
<?rfc include="reference.RFC.5880"?>
<?rfc include="reference.RFC.6286"?>
<?rfc include="reference.RFC.7752"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.I-D.ietf-idr-bgpls-segment-routing-epe"?>
<?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext"?>
<reference anchor="IANA-PEN" target="https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers">
<front>
<title>IANA Private Enterprise Numbers</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="IEEE.802_2001"
target="http://ieeexplore.ieee.org/servlet/opac?punumber=7732">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks:
Overview and Architecture
</title>
<author>
<organization>IEEE</organization>
</author>
<date day="27" month="July" year="2002"/>
</front>
<seriesInfo name="IEEE" value="802-2001"/>
<seriesInfo name="DOI" value="10.1109/ieeestd.2002.93395"/>
</reference>
<reference anchor="IEEE802-2014">
<front>
<title>Local and Metropolitan Area Networks: Overview and Architecture</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date month="" year="2014"/>
</front>
<seriesInfo name="IEEE" value="Std 802-2014"/>
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0791"?>
<?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>
Reference in a new issue View git blame Copy permalink