revert and make it transmission sequence number in the datagram

draft-ietf-lsvr-l3dl.xml

@@ -390,8 +390,13 @@
     multiple Datagrams and reassembled by the receiver a la <xref
     target="RFC0791"/> Section 2.3 Fragmentation.</t>
 
+    <t>Should a PDU need to be retransmitted, it MUST BE sent as the
+    identical Datagram set as the original transmission.  The
+    Transmission Sequence Number assures the receiver that it is the
+    same PDU.</t>
+
 <!--
-    protocol "Version:7,L:1,Datagram Number:24,Datagram Length:16,Checksum:32,Payload...:16"
+    protocol "Version:7,L:1,Transmission Sequence Number:16,Datagram Number:24,Datagram Length:16,Checksum:32,Payload...:32"
 -->
       <figure>
         <artwork> 
@@ -416,9 +421,17 @@
       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
-      last Datagram of the PDU.  For a PDU which fits in only one
+      last Datagram of the PDU.  For a PDU which fits in
-      Datagram, it is set to one.  Note that this is the inverse of the
+      only one Datagram, it is set to one.  Note that this is the
-      marking technique used by <xref target="RFC0791"/>.</t>
+      inverse of the marking technique used by <xref
+      target="RFC0791"/>.</t>
+
+      <t hangText="Transmission Sequence Number:">A 16-bit strictly
+      increasing unsigned integer identifying this PDU, possibly across
+      retransmissions, that wraps from 2^24-1 to 0.  The initial value
+      is arbitrary.  See <xref target="RFC1982"/> on DNS Serial Number
+      Arithmetic for too much detail on comparison and incrementing a
+      wrapping sequence number.</t>
 
       <t hangText="Datagram Number:">A monotonically increasing 24-bit
       value which starts at zero for each PDU.  This is used to
@@ -1295,8 +1308,9 @@ q-->
       </figure>
 
     <t>L3DL devices SHOULD beacon frequent Layer 2 KEEPALIVE PDUs to
-    ensure session continuity.  A receiver may choose to ignore
+    ensure session continuity.  The inter-KEEPALIVE interval is
-    KEEPALIVE PDUs.</t>
+    configurable, with a default of ten seconds.  A receiver may choose
+    to ignore KEEPALIVE PDUs.</t>
 
     <t>An operational deployment MUST BE configured whether to use
     KEEPALIVEs or not, either globally, or down to per-link granularity.
@@ -1611,9 +1625,9 @@ q-->
     Kovuru for comments during implementation, 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
+    clue, Martijn Schmidt for his contribution, Nalin Pai for transport
-    review, Russ Housley for checksum discussion and sBox, and Steve
+    discussions, Neeraj Malhotra for review, Russ Housley for checksum
-    Bellovin for checksum advice.</t>
+    discussion and sBox, and Steve Bellovin for checksum advice.</t>
     
     </section>
 
@@ -1671,6 +1685,7 @@ q-->
   <references title="Informative References">
     <?rfc include="reference.RFC.0791"?>
     <?rfc include="reference.RFC.1122"?>
+    <?rfc include="reference.RFC.1982"?>
     <?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" >