Jeorg Ott reviewed

draft-ietf-lsvr-l3dl.xml

@@ -11,7 +11,7 @@
 <?rfc tocindent="yes"?>
 <?rfc tocompact="yes"?>
 
-<rfc category="std" docName="draft-ietf-lsvr-l3dl-03" ipr="trust200902">
+<rfc category="std" docName="draft-ietf-lsvr-l3dl-04" ipr="trust200902">
 
 <front>
 
@@ -113,8 +113,15 @@
       <t>Provide for authenticity verification of protocol messages.</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
+    <t>In this document, the use case for L3DL is for point to point
+    links in a datacenter Clos in order to exchange the data needed for
+    BGP-SPF <xref target="I-D.ietf-lsvr-bgp-spf"/> bootstrap and
+    continuity.  Once layer two connectivity has been leveraged to get
+    layer three addressability and forwarding capabilities, normal layer
+    three forwarding and routing can take over.</t>
+
+    <t>L3DL might be found to be more widely applicable to a range of
+    routing and similar protocols which need layer three discovery and
     characterisation.</t>
 
     </section>
@@ -397,6 +404,17 @@
     multiple Datagrams and reassembled by the receiver a la <xref
     target="RFC0791"/> Section 2.3 Fragmentation.</t>
 
+    <t>This is not classic 'fragmentation', but rather decomposition at
+    the origin to allow PDU payloads larger than the frame allows.
+    There are no intermediate devices capable of further fragmentation
+    or reassembly.</t>
+
+    <t>L3DL is carrying relatively small amounts of data on relatively
+    high bandwidth links, and when the link is not active with other
+    data as it does not yet have layer three connectivity.  So
+    congestion is not considered a sufficiently significant risk to
+    warrent additional complexity.</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 informs the receiver that it is the
@@ -439,7 +457,7 @@
       increasing unsigned integer identifying this PDU, possibly across
       retransmissions, that wraps from 2^16-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
+      Arithmetic for too much detail on comparing and incrementing a
       wrapping sequence number.</t>
 
       <t hangText="Datagram Number:">A monotonically increasing 24-bit
@@ -480,7 +498,10 @@
     <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>
+    <t>The following code describes a suggested algorithm.  This
+    specification avoids mandatory to implement, algorithm agility, etc.
+    What matters is that the same algorithm is used consistently in any
+    deployment.</t>
 
    <figure>
      <preamble>Sum up 32-bit unsigned ints in a 64-bit long, then take
@@ -706,7 +727,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     <t>If the configured destination address is one that is propagated
     by switches, the HELLO SHOULD be repeated at a configured interval,
     with a default of 60 seconds.  This allows discovery by new devices
-    which come up on the layer-2 mesh.</t>
+    which come up on the layer-2 mesh.  In this multi-link scenario, the
+    operator should be aware of the trade-off between timer tuning and
+    network noise and adjust the inter-HELLO timer accordingly.</t>
 
 <!--
     protocol "PDU Type = 0:8,Payload Length = 0:32,Sig Type = 0:8,Signature Length = 0:16"
@@ -734,6 +757,11 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
     (plus VID).  The two devices establish an L3DL session by exchanging
     OPEN PDUs.</t>
 
+    <t>To ameliorate possible load spikes during bootstrap or event
+    recovery, there SHOULD be a jittered delay between receipt of a
+    HELLO and issue of the OPEN.  The default delay range SHOULD BE zero
+    to five seconds, and MUST be configurable.</t>
+
     <t>If a HELLO is received from a MAC address with which there is an
     established session, the HELLO should be dropped.</t>
 
@@ -838,12 +866,12 @@ q-->
     <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), and
-    the Serial Number in the OPEN is non-zero, the receiver SHOULD
-    establish a new session by sending an OPEN with the Serial Number of
-    the last data it received.  Each party MUST resume sending
-    encapsulations etc. subsequent to the other party's Sequence Number.
-    And each MUST retain all previously discovered encapsulation and
-    other data.</t>
+    the Serial Number in the OPEN PDU is non-zero, the receiver SHOULD
+    establish a new session by sending an OPEN with the Serial Number
+    being the same as that of the last sent and ACKed PDU.  Each party
+    MUST resume sending encapsulations etc. subsequent to the other
+    party's Sequence Number.  And each MUST retain all previously
+    discovered encapsulation and other data.</t>
 
     <t>If a properly authenticated OPEN arrives with a new Nonce from an
     LLEI with which the receiving logical link endpoint believes it
@@ -927,8 +955,8 @@ q-->
       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>
+      is considered a failure.  The session MAY BE considered closed
+      this in case of this ACK failure.</t>
 
       <t>If the link is broken at layer 2, retransmission MAY BE retried
       when the link is restored.</t>
@@ -1642,12 +1670,12 @@ q-->
 
     <t>The authors thank Cristel Pelsser for multiple reviews, Harsha
     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, Nalinaksh Pai for
-    transport discussions, Neeraj Malhotra for review, Paul Congdon for
-    Ethernet hints, Russ Housley for checksum discussion and sBox, and
-    Steve Bellovin for checksum advice.</t>
+    comments, Joerg Ott for review, 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, Nalinaksh
+    Pai for transport discussions, Neeraj Malhotra for review, Paul
+    Congdon for Ethernet hints, Russ Housley for checksum discussion and
+    sBox, and Steve Bellovin for checksum advice.</t>
     
     </section>