congdon comments incorporated

draft-ietf-lsvr-l3dl.xml

@@ -107,8 +107,9 @@
       <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>
-      <t>Enable layer 3 link liveness such as BFD, and finally</t>
+      <t>Enable Layer 3 link liveness such as BFD, and finally</t>
       <t>Provide Layer 2 keep-alive messages for session continuity.</t>
+      <t>Provide for authenticity verification of protocol messages.</t>
     </list></t>
 
     <t>This protocol may be more widely applicable to a range of routing
@@ -214,8 +215,9 @@
       <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
+      <t>A BGP-like upper layer protocol is assumed to use the
-      discover and build a topology database</t>
+      identiiers and encapsulation data to discover and build a topology
+      database</t>
       </list></t>
 
     <figure>
@@ -251,9 +253,9 @@
       <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.
+      identities and layer 2.5 (MPLS) and 3 identifiers (not payloads),
-      device IDs, port identities, VLAN IDs, Encapsulations, and IP
+      e.g.  device IDs, port identities, VLAN IDs, Encapsulations, and
-      addresses.</t>
+      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,
@@ -279,7 +281,8 @@
 
     <t>Once a new device is recognized, both devices attempt to
     negotiate and establish a session by sending unicast OPEN PDUs
-    (<xref target="open"/>).  In an established session, the
+    (<xref target="open"/>) to the source MAC addresses (plus VIDs if
+    VLANs) of the received HELLOs.  In an established session, the
     Encapsulations (<xref target="afisafi"/>) configured on an end point
     may be announced and modified.  Note that these are only the
     encapsuation and addresses configured on the announcing interface;
@@ -290,11 +293,11 @@
  
     <section anchor="ladder" title="L3DL Ladder Diagram">
 
-      <t>The HELLO, <xref target="hello"/>, is a priming message.  It is
+      <t>The HELLO, <xref target="hello"/>, is a priming message sent on
-      a small L3DL PDU encapsulated in an Ethernet multicast frame with
+      all configured logical links.  It is a small L3DL PDU encapsulated
-      the simple goal of discovering the identities of logical link
+      in an Ethernet multicast frame with the simple goal of discovering
-      endpoint(s) reachable from a Logical Link Endpoint, <xref
+      the identities of logical link endpoint(s) reachable from a
-      target="llei"/>.</t>
+      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
@@ -397,16 +400,16 @@
     same PDU.</t>
 
 <!--
-    protocol "Version:8,Transmission Sequence Number:16,L:1,Datagram Number:24,Datagram Length:15,Checksum:32,Payload...:32"
+    protocol "Version:8,Transmission Sequence Number:16,L:1,Datagram Number:23,Datagram Length:16,Checksum:32,Payload...: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    |  Transmission Sequence Number |L|             |
+|    Version    |  Transmission Sequence Number |L|             ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|         Datagram Number         |       Datagram Length       |
+~        Datagram Number        |        Datagram Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            Checksum                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -420,7 +423,7 @@
 
       <t hangText="Version:">Seven-bit Version number of the protocol,
       currently 0.  Values other than 0 MUST BE treated as an error.
-      The protocol version nees to be in one and only one place, so it
+      The protocol version needs to be in one and only one place, so it
       is in the datagram as opposed to, for example, the PDU header.</t>
 
       <t hangText="L:">A bit that set to one if this Datagram is the
@@ -690,10 +693,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     <t>When an interface is turned up on a device, it SHOULD issue a
     HELLO if it is to participate in L3DL sessions.</t>
 
-    <t>If a constrained Nearest Bridge destination address is configured
+    <t>If a constrained Nearest Bridge destination address has been
-    for a point-to-point interface, see above, then the HELLO SHOULD NOT
+    configured for a point-to-point interface, see above, then the HELLO
-    be repeated once a session has been created by an exchange of
+    SHOULD NOT be repeated once a session has been created by an
-    OPENs.</t>
+    exchange of OPENs.</t>
 
     <t>If the configured destination address is one that is propagated
     by switches, the HELLO SHOULD be repeated at a configured interval,
@@ -720,10 +723,11 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     each unique source LLEI response.  L3DL treats each adjacency as a
     separate logical link.</t>
 
-    <t>When a HELLO is received from a source MAC address with which
+    <t>When a HELLO is received from a source MAC address (plus VID if
-    there is no established L3DL session, the receiver SHOULD respond
+    VLAN) with which there is no established L3DL session, the receiver
-    with an OPEN PDU.  The two devices establish an L3DL session by
+    SHOULD respond by sending an OPEN PDU to the source MAC address
-    exchanging OPEN PDUs.</t>
+    (plus VID).  The two devices establish an L3DL session by exchanging
+    OPEN PDUs.</t>
 
     <t>The Payload Length is zero as there is no payload.</t>
 
@@ -793,8 +797,9 @@ q-->
     target="tlv"/>.</t>
 
     <t>Key Length is a 16-bit field denoting the length in octets of the
-    Key itself, not including the Auth Type or the Key Length.  If there
+    Key itself, not including the Auth Type or the Key Length.  If the
-    is no Key, the Auth Type and key Length MUST both be zero.</t>
+    Auth Type is zero, then the Key Length MUST also be zero, and there
+    MUST BE no Key data.</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
@@ -900,9 +905,9 @@ q-->
     1990s might think the catenation of EType and Error Code as an echo
     of 0x1zzz, 0x2zzz, etc.  They might be right; or not.</t>
 
-    <t>The Error Hint is any additional data the sender of the error PDU
+    <t>The Error Hint, an arbitrary 16 bits, is any additional data the
-    thinks will help the recipient or the debugger with the particular
+    sender of the error PDU thinks will help the recipient or the
-    error.</t>
+    debugger with the particular error.</t>
 
     <t>The Signature fields are described in <xref target="tlv"/>.</t>
     
@@ -939,8 +944,8 @@ q-->
     <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
+    have sent the same Encapsulation Type is it safe for Layer 3
-    are compatible for that type.</t>
+    protocols 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
@@ -1012,8 +1017,8 @@ q-->
       <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
+      failures (default three), the L3DL session should be considered
-      process SHOULD be restarted.</t>
+      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>