modified for l3nd

draft-ymbk-idr-l3nd-ulpc.xml

@@ -15,7 +15,7 @@
 
 <front>
 
-  <title>L3DL Upper-Layer Protocol Configuration</title>
+  <title>L3ND Upper-Layer Protocol Configuration</title>
 
     <author fullname="Randy Bush" initials="R." surname="Bush">
       <organization>Arrcus &amp; IIJ</organization>
@@ -49,8 +49,8 @@
 
   <abstract>
 
-    <t>This document uses the Layer-3 Liveness and Discovery protocol
+    <t>This document uses the Layer-3 Neighbor Discovery protocol to
-    to communicate the parameters needed to exchange inter-device Upper
+    communicate the parameters needed to exchange inter-device Upper
     Layer Protocol Configuration for upper-layer protocols such as the
     BGP family.
     </t>
@@ -74,25 +74,24 @@
   <section anchor="intro" title="Introduction">
 
     <t>Massive Data Centers (MDCs) which use upper-layer protocols such
-    as BGP4, BGP-LS, BGP-SPF, etc. may use the Layer-3 Liveness and
+    as BGP4 and other routing protocols may use the Layer-3 Neighbor
-    Discovery Protocol, L3DP, <xref target="I-D.ietf-lsvr-l3dl"/> to
+    Discovery Protocol, L3ND, <!--xref target="I-D.ymbk,l3nd"--> to
     reveal the inter-device links of the topology.  It is desirable for
     devices to facilitate the configuration parameters of those upper
     layer protocols to enable more hands-free configuration.  This
-    document defines a new L3DP PDU to communicate these Upper-Layer
+    document defines a new L3ND PDU to communicate these Upper-Layer
     Protocol Configuration parameters.</t>
 
     </section>
 
   <section anchor="terminology" title="Reading and Terminology">
 
-    <t>The reader is assumed to have read Layer-3 Discovery and Liveness
+    <t>The reader is assumed to have read Layer-3 Neighbor Discovery
-    <xref target="I-D.ietf-lsvr-l3dl"/>.  The terminology and PDUs there
+    <!--xref target="I-D.ymbk,l3nd"-->.  The terminology and PDUs there
     are assumed here.</t>
 
     <t>Familiarity with the BGP4 Protocol <xref target="RFC4271"/> is
-    assumed.  Familiarity with BGP-SPF, <xref
+    assumed.</t>
-    target="I-D.ietf-lsvr-bgp-spf"/>, might be useful. </t>
 
     </section>
 
@@ -104,7 +103,7 @@
     PDU is defined as follows:</t>
 
 <!--
-    protocol "Type = 8:9,Payload Length:32,ULPC Type:8,AttrCount:8,Attribute List ...:24,Sig Type:8,Signature Len:16,Signature ...:24"
+    protocol "Version = 0:8,Type = 8:8,Payload Length:32,ULPC Type:8,AttrCount:8,Attribute List ...:32"
 -->
 
     <figure>
@@ -112,19 +111,17 @@
  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 = 9   |                 Payload Length                ~
+|  Version = 0  |    Type = 8   |         Payload Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-~               |   ULPC Type   |   AttrCount   |               ~
+|                               |   ULPC Type   |   AttrCount   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-~       Attribute List ...      |    Sig Type   | Signature Len ~
+|                       Attribute List ...                      |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-~               |                 Signature ...                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         </artwork>
       </figure>
 
-    <t>The Type and Payload Length are defined in <xref
+    <t>The Type and Payload Length are defined in <!--xref
-    target="I-D.ietf-lsvr-l3dl"/>.</t>
+    target="I-D.ymbk,l3nd"-->.</t>
 
     <?rfc subcompact="yes"?>
     <t>ULPC Type: An integer denoting the type of the upper-layer
@@ -179,37 +176,37 @@
       each address family.</t>
 
       <t>A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU
-      for an particular address family at any point in time; receipt of
+      for an particular address family on a specific link at any point
-      a new BGP ULPC PDU for a particular address family replaces any
+      in time; receipt of a new BGP ULPC PDU for a particular address
-      previous one.</t>
+      family replaces any previous one.</t>
 
       <t>If there are one or more open BGP sessions, receipt of a new
       BGP ULPC PDU does not affect these sessions and the PDU SHOULD be
       discarded.  If a peer wishes to replace an open BGP session, they
-      must first close the running session and then send a new BGP ULPC
+      MUST first close the running BGP session and then send a new BGP
-      PDU.</t>
+      ULPC PDU.</t>
       
       <t>As a link may have multiple encapsulations and multiple
-      addresses for an IP encapsulation, which address of which
+      addresses for an IP encapsulation; therefore which address of
-      encapsulation is to be used for the BGP session MUST be
+      which encapsulation is to be used for the BGP session MUST be
       specified.</t>
 
       <t>For each BGP peering on a link here MUST be one agreed
       encapsulation, and the addresses used MUST be in the corresponding
-      L3DP IPv4/IPv6 Announcement PDUs.  If the choice is ambiguous, an
+      L3ND IPv4/IPv6 Announcement PDUs.  If the choice is ambiguous, an
       Attribute may be used to signal preferences.</t>
 
-      <t>If a peering address has been announced as a loopback,
+      <t>If a peering address has been announced as a loopback, i.e.
-      i.e. MUST BE flagged as such in the L3DL Encapsulation PDU (see
+      MUST BE flagged as such in the L3ND Encapsulation PDU (see <xref
-      <xref target="I-D.ietf-lsvr-l3dl"/> Sec. 13.2), a two or three hop
+      target="I-D.ietf-lsvr-l3dl"/> Sec. 13.2), a two or three hop BGP
-      BGP session will be established.  Otherwise a direct one hop
+      session will be established.  Otherwise a direct one hop session
-      session is used.  The BGP session to a loopback will forward to
+      is used.  The BGP session to a loopback will forward to the peer's
-      the peer's address which was marked as Primary in the L3DL
+      address which was marked as Primary in the L3DL Encapsulation
-      Encapsulation Flags, iff it is in a subnet which is shared with
+      Flags, iff it is in a subnet which is shared with both BGP
-      both BGP speakers.  If the primary is not in a common subnet, then
+      speakers.  If the primary is not in a common subnet, then the BGP
-      the BGP speaker MAY pick a forwarding next hop that is in a subnet
+      speaker MAY pick a forwarding next hop that is in a subnet they
-      they share.  If there are multiple choices, the BGP speaker SHOULD
+      share.  If there are multiple choices, the BGP speaker SHOULD have
-      have signaled which subnet to choose in an Upper-Layer Protocol
+      signaled which subnet to choose in an Upper-Layer Protocol
       Configuration PDU Attribute.</t>
         
 <!--
@@ -218,9 +215,9 @@
 
       <section anchor="asn" title="BGP ASN">
 
-        <t>The Autonomous System number MUST be specified.  If the AS
+        <t>The Autonomous System number of the sender MUST be specified.
-        Number is less than 32 bits, it is padded with high order
+        If the AS Number is less than 32 bits, it is padded with high
-        zeros.</t>
+        order zeros.</t>
 
         <figure>
           <artwork>
@@ -365,11 +362,11 @@
   
   <section anchor="security" title="Security Considerations">
 
-    <t>All the Security considerations of <xref
+    <t>All the Security considerations of <!--xref
-    target="I-D.ietf-lsvr-l3dl"/> apply to this PDU.</t>
+    target="I-D.ymbk,l3nd"--> apply to this PDU.</t>
 
     <t>As the ULPC PDU may contain keying material, see <xref
-    target="bgpmd5"/>, it SHOULD BE signed.</t>
+    target="bgpmd5"/>, it SHOULD BE over TLS.</t>
 
     <t>Any keying material in the PDU SHOULD BE salted and hashed.</t>
 
@@ -435,7 +432,6 @@
     <?rfc include="reference.RFC.2385.xml"?>
     <?rfc include="reference.RFC.4808.xml"?>
     <?rfc include="reference.RFC.7210.xml"?>
-    <?rfc include="reference.I-D.ietf-lsvr-bgp-spf.xml"?>
     </references>
     
   </back>