a pass to make it cleaner and more consistent
This commit is contained in:
parent
ee01fba1ea
commit
92543b7a98
1 changed files with 138 additions and 126 deletions
|
|
@ -60,7 +60,7 @@
|
|||
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 them,
|
||||
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
|
||||
|
|
@ -97,7 +97,8 @@
|
|||
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.</t>
|
||||
routing topology. They also need prompt reaction to (logical) link
|
||||
failure.</t>
|
||||
|
||||
<t>Layer 3 Discovery and Liveness (L3DL) provides brutally simple
|
||||
mechanisms for devices to <list style="symbols">
|
||||
|
|
@ -106,7 +107,7 @@
|
|||
<t>Run Layer 2 keep-alive messages for session continuity,</t>
|
||||
<t>Discover each other's unique IDs (ASN, RouterID, ...),</t>
|
||||
<t>Discover mutually supported encapsulations, e.g. IP/MPLS,</t>
|
||||
<t>Discover Layer 3 and/or MPLS addressing of interfaces of the
|
||||
<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
|
||||
|
|
@ -123,8 +124,8 @@
|
|||
<section anchor="terminology" title="Terminology">
|
||||
|
||||
<t>Even though it concentrates on the inter-device layer, this
|
||||
document relies heavily on routing terminology. The following are
|
||||
some possibly confusing terms:
|
||||
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
|
||||
|
|
@ -143,11 +144,11 @@
|
|||
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
|
||||
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="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="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>
|
||||
|
|
@ -166,7 +167,7 @@
|
|||
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 devices,</t>
|
||||
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>
|
||||
|
|
@ -182,7 +183,7 @@
|
|||
|
||||
<section anchor="background" title="Background">
|
||||
|
||||
<t>L3DL assumes a datacenter scale and topology, but can
|
||||
<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
|
||||
|
|
@ -196,7 +197,7 @@
|
|||
|
||||
<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
|
||||
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>
|
||||
|
|
@ -244,12 +245,12 @@
|
|||
</figure>
|
||||
|
||||
<t>There are two protocols, the inter-device per-link layer 3
|
||||
discovery and the interface to the upper level BGP-like protocol:
|
||||
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
|
||||
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
|
||||
|
|
@ -269,9 +270,12 @@
|
|||
<section anchor="llei" title="Logical Link Endpoint Identifier">
|
||||
|
||||
<t>L3DL discovers neighbors on logical links and establishes
|
||||
sessions between the two ends of all discovered logical links. A
|
||||
logical link is described by a pair of Logical Link Endpoint
|
||||
Identifiers, LLEIs.</t>
|
||||
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 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
|
||||
|
|
@ -302,12 +306,12 @@
|
|||
</figure>
|
||||
|
||||
<t>ifIndex is the SNMP identifier of the (sub-)interface, see <xref
|
||||
target="RFC1213"/>.</t>
|
||||
target="RFC1213"/>. This uniquely identifies the port.</t>
|
||||
|
||||
<t>System MAC is an identifier unique in the entore operational
|
||||
space. Routers and switches have internal system MACs. If none
|
||||
exists on a device, the local L3DL configuration SHOULD assign one
|
||||
by configuration.</t>
|
||||
space. Routers and switches have internal system MACs which can be
|
||||
used. If none exists on a device, the local L3DL configuration
|
||||
SHOULD create and assign a unique one by configuration.</t>
|
||||
|
||||
<t>The VLAN ID is the 802.1Q identifier of the virtual link's VLAN
|
||||
if a VLAN is configured, otherwise zero.</t>
|
||||
|
|
@ -348,7 +352,7 @@
|
|||
|
||||
<figure>
|
||||
<artwork>
|
||||
| HELLO | Link Peer discovery
|
||||
| HELLO | Logical Link Peer discovery
|
||||
|---------------------------->|
|
||||
| HELLO | Mandatory
|
||||
|<----------------------------|
|
||||
|
|
@ -432,9 +436,7 @@
|
|||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Version |L|Datagram Num.| Datagram Length |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Sec Type | Sec Length | ~
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
|
||||
~ Sec Data ~
|
||||
| Checksum |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
</artwork>
|
||||
</figure>
|
||||
|
|
@ -445,12 +447,13 @@
|
|||
<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 1 if this Datagram is the last
|
||||
Datagram of the PDU. For a PDU which fits in only one Datagram,
|
||||
it is set to one.</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.</t>
|
||||
|
||||
<t hangText="Datagram Number:">0..127, a monotonically increasing
|
||||
value, modulo 128, see <xref target="RFC1982"/>.</t>
|
||||
value, modulo 128, see <xref target="RFC1982"/>. 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>
|
||||
|
|
@ -533,8 +536,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
<section anchor="tlv" title="TLV PDUs">
|
||||
|
||||
<t>The basic L3DL application layer PDU is a typical TLV (Type
|
||||
Length Value) PDU. It may be broken into multiple Datagrams, see
|
||||
<xref target="transport"/> </t>
|
||||
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"
|
||||
|
|
@ -579,23 +583,23 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
Payload field.</t>
|
||||
|
||||
<t hangText="Payload:">The application layer content of the L3DL
|
||||
PDU beyond the type.</t>
|
||||
PDU.</t>
|
||||
|
||||
<t hangText="Sec Type:">The type of the Signature. Types 0 and 1
|
||||
are defined in this document.</t>
|
||||
<t hangText="Sec 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 is TO BE SPECIFIED.</t>
|
||||
<t>Sig Type 1 is specified in a companion document [ref
|
||||
later].</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. If Sec Type is 1 Sig Length must be
|
||||
TO BE SPECIFIED.</t>
|
||||
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
|
||||
|
|
@ -625,7 +629,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
<?rfc subcompact="no"?></list></t>
|
||||
|
||||
<t>All other L3DL PDUs are encapsulated in unicast Ethernet frames,
|
||||
as the peer's destination link address is known after the HELLO
|
||||
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
|
||||
|
|
@ -633,33 +637,34 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
default of 60 seconds.</t>
|
||||
|
||||
<!--
|
||||
protocol "Type = 0:8,PDU Length = 3:16"
|
||||
protocol "Type = 0:8,Payload Length = 0:16,Sig Type = 0:8,Signature Length = 0:16"
|
||||
-->
|
||||
|
||||
<figure>
|
||||
<artwork>
|
||||
0 1 2
|
||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Type = 0 | PDU Length = 3 |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
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 link address) response. L3DL treats each
|
||||
adjacency as a separate link.</t>
|
||||
adjacency as a separate logical link.</t>
|
||||
|
||||
<t>When a HELLO is received from a source link address 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>HELLO PDUs can not be signed as keying material has yet to be
|
||||
exchanged.</t>
|
||||
<t>The Payload Length is zero as there is no payload.</t>
|
||||
|
||||
<t>The PDU Length is the octet count of the entire PDU, including
|
||||
the Type and the Datagram Length field itself.</t>
|
||||
<t>HELLO PDUs can not be signed as keying material has yet to be
|
||||
exchanged. Hence the signature MUST always be null.</t>
|
||||
|
||||
</section>
|
||||
|
||||
|
|
@ -679,7 +684,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
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 | |
|
||||
| Type = 1 | Payload Length | ~
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Nonce | ID Length |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
|
@ -701,19 +706,19 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
</figure>
|
||||
|
||||
<t>The Payload Length is the number of octets in all fields of the
|
||||
PDU from the Type to the Authentication Data, excluding the Sig
|
||||
PDU from the Nonce to the Authentication Data, excluding the Sig
|
||||
Type, the Signature Length, and the Signature.</t>
|
||||
|
||||
<t>The Nonce enables detection of a duplicate OPEN PDU. It SHOULD
|
||||
be either a random number or 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>
|
||||
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 ID is the sending LLEI, see <xref target="llei"/>. It can be
|
||||
an ASN with high order bits zero, a classic RouterID with high order
|
||||
bits zero, a catenation of the two, a 80-bit ISO System-ID, or any
|
||||
other identifier unique to a single device in the topology. IDs are
|
||||
big-endian.</t>
|
||||
other identifier unique to a single logical link endpoint in the
|
||||
topology. IDs 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>
|
||||
|
|
@ -738,12 +743,12 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
L3DL session, an ERROR PDU is sent (Error Code 2), and HELLOs MUST
|
||||
be restarted.</t>
|
||||
|
||||
<t>The Signature fileds are described in <xref target="tlv"/> and
|
||||
serve as a proof of possession of the signing auth data by
|
||||
sender.</t>
|
||||
<t>The Signature fileds 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 devices know each other's LLEIs, and have ACKed each
|
||||
other's OPEN PDUs, Layer 2 KEEPALIVEs (see <xref
|
||||
<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>
|
||||
|
|
@ -755,22 +760,22 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
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 device 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>
|
||||
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 = 8:16,PDU Type:8,EType:4,Error Code:12,Error Hint:16,Sig Type:8,Signature Length:16,Signature ...:40"
|
||||
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
|
||||
|
|
@ -781,7 +786,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
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 = 8 | PDU Type |
|
||||
| Type = 3 | Payload Length = 5 | PDU Type |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| EType | Error Code | Error Hint |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
|
@ -848,7 +853,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
|
||||
their interface encapsulations, addresses, (and labels).</t>
|
||||
interface encapsulations, addresses, (and labels).</t>
|
||||
|
||||
<t>The Encapsulation types the peers exchange may be IPv4
|
||||
Announcement (<xref target="ipv4"/>), IPv6 Announcement (<xref
|
||||
|
|
@ -869,9 +874,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
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 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>
|
||||
<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>
|
||||
|
||||
<section anchor="encaps" title="The Encapsulation PDU Skeleton">
|
||||
|
||||
|
|
@ -1141,30 +1147,32 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
|
||||
<section anchor="keepalive" title="KEEPALIVE - Layer 2 Liveness">
|
||||
|
||||
<t>L3DL devices MUST beacon occasional Layer 2 KEEPALIVE PDUs to
|
||||
<t>L3DL devices SHOULD beacon frequent Layer 2 KEEPALIVE PDUs to
|
||||
ensure session continuity.</t>
|
||||
|
||||
<t>They SHOULD be beaconed at a configured frequency. One per
|
||||
second is the default. Layer 3 liveness, such as BFD, will likely
|
||||
be more aggressive.</t>
|
||||
second is the default. Layer 3 liveness, such as BFD, may be more
|
||||
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 one minute),
|
||||
has an open session for a configurable time (default 30 seconds),
|
||||
the session SHOULD BE presumed closed. The devices MAY keep
|
||||
configuration state until a new session is established and new
|
||||
Encapsulation PDUs are received.</t>
|
||||
|
||||
<!--
|
||||
protocol "Type = 2:8,Length = 3:16"
|
||||
protocol "Type = 2:8,Payload Length = 0:16,Sig Type = 0:8,Signature Length = 0:16"
|
||||
-->
|
||||
|
||||
<figure>
|
||||
<artwork>
|
||||
0 1 2
|
||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Type = 2 | Length = 3 |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
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>
|
||||
|
||||
|
|
@ -1173,7 +1181,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
<section anchor="vendor" title="VENDOR - Vendor Extensions">
|
||||
|
||||
<!--
|
||||
protocol "Type = 255:8,Length:16,...:8,Enterprise Number:24,Ent Type:8,Enterprise Data ...:32,Sig Type:8,Signature Length:16,Signature ...:40"
|
||||
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>
|
||||
|
|
@ -1181,7 +1189,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
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 | Length | ... |
|
||||
| Type = 255 | Payload Length | ... |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Enterprise Number | Ent Type |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
|
@ -1225,8 +1233,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
<t>Thus far, a one-hop point-to-point logical link discovery
|
||||
protocol has been defined.</t>
|
||||
|
||||
<t>The nodes know the unique LLEIs and Encapsulations on each link
|
||||
interface.</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
|
||||
|
|
@ -1282,30 +1290,34 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
|
||||
<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 interface, 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>
|
||||
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 currently
|
||||
KEEPALIVE is unicast, and thus less noisy on the network,
|
||||
especially if HELLO is configured to transit layer-2-only
|
||||
switches.</t>
|
||||
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>
|
||||
|
||||
|
|
@ -1330,8 +1342,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
|
||||
<section anchor="impl" title="Implementation Considerations">
|
||||
|
||||
<t>An implementation SHOULD provide the ability to configure an
|
||||
interface as L3DL speaking or not.</t>
|
||||
<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
|
||||
|
|
@ -1354,8 +1366,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
|
||||
<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 authorisation mechanism. These are works in
|
||||
process.</t>
|
||||
authentication and authorisation mechanism. Sufficient mechanisms
|
||||
may be descrived 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
|
||||
|
|
@ -1411,8 +1423,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
|
|||
be the following:</t>
|
||||
<figure>
|
||||
<artwork>
|
||||
Bit Bit Name
|
||||
---- -------------------
|
||||
Number Name
|
||||
------ -------------------
|
||||
0 Null
|
||||
1 TOFU - Trust On First Use
|
||||
2-255 Reserved
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue