a pass to make it cleaner and more consistent

draft-ietf-lsvr-l3dl.xml

@@ -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
+    document relies heavily on routing terminology.  The following
-    some possibly confusing terms:
+    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
+      <t hangText="Link or Logical Link:">A logical connection between
-      on two devices.  E.g. two VLANs between the same two ports are two
+      two logical ports on two devices.  E.g. two VLANs between the same
-      links.</t>
+      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),
+      identities and layer 2.5 and 3 identifiers (not payloads), e.g.
-      e.g. device IDs, port identities, VLAN IDs, Encapsulations, and IP
+      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
+    sessions between the two ends of all consenting discovered logical
-    logical link is described by a pair of Logical Link Endpoint
+    links.  A logical link is described by a pair of Logical Link
-    Identifiers, LLEIs.</t>
+    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
+    space.  Routers and switches have internal system MACs which can be
-    exists on a device, the local L3DL configuration SHOULD assign one
+    used.  If none exists on a device, the local L3DL configuration
-    by configuration.</t>
+    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
 |----------------------------&gt;|
 |             HELLO           | Mandatory
 |&lt;----------------------------|
@@ -432,9 +436,7 @@
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Version    |L|Datagram Num.|        Datagram Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|    Sec Type   |           Sec Length          |               ~
+|                            Checksum                           |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               ~
-~                            Sec Data                           ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         </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
+      <t hangText="L:">A bit that set to one if this Datagram is the
-      Datagram of the PDU.  For a PDU which fits in only one Datagram,
+      last Datagram of the PDU.  For a PDU which fits in only one
-      it is set to one.</t>
+      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
+    Length Value) PDU.  It includes a signature to provide optional
-    <xref target="transport"/> </t>
+    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
+      <t hangText="Sec Type:">The type of the Signature.  Type 0, a null
-      are defined in this document.</t>
+      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
+      Signature Length must be 0.</t>
-      TO BE SPECIFIED.</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  
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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   |         PDU Length = 3        |
+|    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
+    <t>The Payload Length is zero as there is no payload.</t>
-    exchanged.</t>
 
-    <t>The PDU Length is the octet count of the entire PDU, including
+    <t>HELLO PDUs can not be signed as keying material has yet to be
-    the Type and the Datagram Length field itself.</t>
+    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
+    be either a random number or the time of day.  It is needed to
-    session closure due to a repeated OPEN caused by a race or a dropped
+    prevent session closure due to a repeated OPEN caused by a race or a
-    or delayed ACK.</t>
+    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
+    other identifier unique to a single logical link endpoint in the
-    big-endian.</t>
+    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
+    <t>The Signature fileds are described in <xref target="tlv"/> and in
-    serve as a proof of possession of the signing auth data by
+    an asymmetric key environment serve as a proof of possession of the
-    sender.</t>
+    signing auth data by the sender.</t>
 
-    <t>Once two devices know each other's LLEIs, and have ACKed each
+    <t>Once two logical link endpoints know each other, and have ACKed
-    other's OPEN PDUs, Layer 2 KEEPALIVEs (see <xref
+    each other's OPEN PDUs, Layer 2 KEEPALIVEs (see <xref
     target="keepalive"/>) MAY be started to ensure Layer 2 liveness and
     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
+    LLEI with which the receiving logical link endpoint believes it
-    session (OPENs have already been exchanged), the receiver MUST
+    already has an L3DL session (OPENs have already been exchanged), the
-    assume that the sending LLEI or entire device has been reset.  All
+    receiver MUST assume that the sending LLEI or entire device has been
-    discovered encapsulation data SHOULD be withdrawn via the BGP-LS API
+    reset.  All discovered encapsulation data SHOULD be withdrawn via
-    and the recipient MUST respond with a new OPEN.  In this
+    the BGP-LS API and the recipient MUST respond with a new OPEN.  In
-    circumstance encapsulations SHOULD NOT be kept because, while the
+    this circumstance encapsulations SHOULD NOT be kept because, while
-    new OPEN is likely to be followed by new encapsulation PDUs of the
+    the new OPEN is likely to be followed by new encapsulation PDUs of
-    same data, the old session might have an encapsulation type not in
+    the same data, the old session might have an encapsulation type not
-    the new session.</t>
+    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
+    <t>Further, to consider a logical link of a type to formally be
-    so that it may be pushed up to upper layer protocols, the addressing
+    established so that it may be pushed up to upper layer protocols,
-    for the type must be compatible, e.g. on the same IPvX subnet.</t>
+    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
+    second is the default.  Layer 3 liveness, such as BFD, may be more
-    be more aggressive.</t>
+    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  
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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   |           Length = 3          |
+|    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
+    <t>The devices know their unique LLEIs and know the unique peer
-    interface.</t>
+    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.
+      multiple devices to one logical interface (LLEI), I, on an L3DL
-      Interface I could discover a peer J across the switch.  Later, a
+      speaking device.  Interface I could discover a peer J across the
-      prospective peer K could come up across the switch.  If I was not
+      switch.  Later, a prospective peer K could come up across the
-      still sending and listening for HELLOs, the potential peering with
+      switch.  If I was not still sending and listening for HELLOs, the
-      K could not be discovered.  Therefore, interfaces MUST continue to
+      potential peering with K could not be discovered.  Therefore,
-      send HELLOs as long as they are turned up.</t>
+      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
+      eliminated in favor of keeping only HELLOs.  But KEEPALIVEs are
-      KEEPALIVE is unicast, and thus less noisy on the network,
+      unicast, and thus less noisy on the network, especially if HELLO
-      especially if HELLO is configured to transit layer-2-only
+      is configured to transit layer-2-only switches, see <xref
-      switches.</t>
+      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
+    <t>An implementation SHOULD provide the ability to configure a
-    interface as L3DL speaking or not.</t>
+    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
+    authentication and authorisation mechanism.  Sufficient mechanisms
-    process.</t>
+    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