first hacking started

draft-ymbk-idr-l3-discovery.xml

@@ -440,73 +440,6 @@
 
     </section>
 
-  <section anchor="llei" title="Logical Link Endpoint Identifier">
-
-    <t>L3BND discovers neighbors on logical links and establishes
-    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 LLEI is a variable length descriptor which could be an ASN, a
-    classic RouterID, a catenation of the two, an eight octet ISO System
-    Identifier <xref target="RFC1629"/>, or any other identifier unique
-    to a single logical link endpoint in the topology.</t>
-
-    <t>An L3BND deployment will choose and define an LLEI which suits its
-    needs, simple or complex.  Examples of two extremes follow:</t>
-      
-    <t>A simplistic view of a link between two devices is two ports,
-    identified by unique MAC addresses, carrying a layer-3 protocol
-    conversation.  In this case, the MAC addresses might suffice for the
-    LLEIs.</t>
-
-    <t>Unfortunately, things can get more complex.  Multiple VLANs can
-    run between those two MAC addresses.  In practice, many real devices
-    use the same MAC address on multiple ports and/or
-    sub-interfaces.</t>
-
-    <t>Therefore, in the general circumstance, a fully described LLEI
-    might be as follows:</t>
- <!--
-    protocol "System Identifier:64,ifIndex: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
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                                                               |
-+                       System Identifier                       +
-|                                                               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                            ifIndex                            |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      </artwork>
-    </figure>
-
-    <t>System Identifier, a la <xref target="RFC1629"/>, is an eight
-    octet identifier unique in the entire operational space.  Routers
-    and switches usually have internal MAC Addresses which can be padded
-    with high order zeros and used if no System ID exists on the device.
-    If no unique identifier is burned into a device, the local L3BND
-    configuration SHOULD create and assign a unique one, likely by
-    configuration.</t>
-    
-    <t>ifIndex is the SNMP identifier of the (sub-)interface, see <xref
-    target="RFC1213"/>.  This uniquely identifies the port.</t>
-
-    <t>For a layer-3 tagged sub-interface or a VLAN/SVI interface,
-    IfIndex is that of the logical sub-interface, so no further
-    disambiguation is needed.</t>
-
-    <t>L3BND PDUs learned over VLAN-ports may be interpreted by upper
-    layer-3 routing protocols as being learned on the corresponding
-    layer-3 SVI interface for the VLAN.</t>
-
-    <t>LLEIs are big-endian.</t>
-
-    </section>
-
   <section anchor="hello" title="HELLO">
 
     <t>The HELLO PDU is unique in that it is encapsulated in a multicast
@@ -594,6 +527,17 @@
 
   <section anchor="howdy" title="HOWDY">
 
+    <t>The HOWDY PDU is identical in format to the HELLO PDU except it
+    is sent unicast.</t>
+
+    <t>The unicast source address is that of the interface responding to
+    the HELLO multicast PDU, and the AFI MUST be the same as the HELLO
+    to which it is responding.</t>
+
+    <t>The receiver knows it is a HOWDY because it is unicast and the
+    destination address is the source address of the HELLO sent by the
+    receiver of the HOWDY.</t>
+    
 <!--
     protocol "PDU Type = 0:8,Payload Length = 0:32"
 -->
@@ -602,7 +546,7 @@
       <artwork>
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|  PDU Type = 1 |               Payload Length = 0              |
+|  PDU Type = 0 |               Payload Length = 0              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               |
 +-+-+-+-+-+-+-+-+
@@ -610,6 +554,25 @@
       </figure>
     </section>
 
+  <section anchor="tcp0" title="TCP Set-Up">
+
+    <t>With the HELLO/HOWDY exchange, both sides have agreed on an AFI
+    and each other's IP address in that AFI.  This is sufficient to open
+    a TCP session between them, which will allow for very large data
+    PDUs while obviating the need to invent complex transports.</t>
+
+    <t>As the HELLO/HOWDY exchange was extremely sparse, the peers could
+    not yet have agreed on security data for authentication.  This will
+    be done in the OPEN exchange.  If the OPEN exchange agrees on an
+    authorization mechansim and keys, then this TCP session MUST be
+    closed, and a new TLS session with the newly agreed credentials MUST
+    opened, see <xref target="tls"/>.</t>
+
+    <t>If the TCP open fails, then this SHOULD be logged and the parties
+    MUST go back to the initial state and try HELLO/HOWDY.</t>
+
+    </section>
+    
   <section anchor="open" title="OPEN">
 
     <t>Each device has learned the other's MAC Address from the HELLO
@@ -654,7 +617,7 @@
     needed to prevent session closure due to a repeated OPEN caused by a
     race or a dropped or delayed ACK.</t>
 
-    <t>My LLEI is the sender's LLEI, see <xref target="llei"/>.</t>
+    <t>My LLEI is the sender's LLEI, see xref target="llei".</t>
 
     <t>AttrCount is the number of attributes in the Attribute List.
     Attributes are single octets the semantics of which are
@@ -753,6 +716,19 @@
 
     </section>
 
+  <section anchor="tls" title="TLS Set-Up">
+
+    <t>With the OPEN exchange, both sides MAY have agreed  on the
+    credentials and methods to move from naked TCP to TLS.  If so,
+    the initial TCP session is closed and a TLS session between the same
+    two parties is negotiated and opened.</t>
+
+    <t>If the Naked TCP close fails or the TLS negotiation is
+    unsuccessful, then this SHOULD be logged and the parties MUST go
+    back to the initial state and try HELLO/HOWDY.</t>
+
+    </section>
+    
   <section anchor="ack" title="ACK">
 
 <!--
@@ -1554,8 +1530,6 @@
 <back>
 
   <references title="Normative References">
-    <?rfc include="reference.RFC.1213.xml"?>
-    <?rfc include="reference.RFC.1629.xml"?>
     <?rfc include="reference.RFC.2119.xml"?>
     <?rfc include="reference.RFC.3032.xml"?>
     <?rfc include="reference.RFC.4271.xml"?>