randy/draft-l3nd
1
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

spell check, -00 published

Browse source
This commit is contained in:
Randy Bush 2022-02-17 11:11:14 -08:00
parent 4a77ec5870
commit 2b8c305273
1 changed files with 69 additions and 64 deletions
Download patch file Download diff file Expand all files Collapse all files

131
draft-ymbk-idr-l3nd.xml
View file

@ -127,7 +127,7 @@
</list></t> </list></t>
<t>In this document, the use case for L3ND is for point to point <t>In this document, the use case for L3ND is for point to point
links in a datacenter Clos (<xref target="Clos1"/>) in order to links in a datacenter Clos (<xref target="Clos"/>) in order to
exchange the data needed for bootstrapping BGP-based peering, EVPNs, exchange the data needed for bootstrapping BGP-based peering, EVPNs,
etc. Once IP connectivity has been leveraged to get layer-3 etc. Once IP connectivity has been leveraged to get layer-3
addressability and forwarding capabilities, normal IP forwarding and addressability and forwarding capabilities, normal IP forwarding and
@ -149,30 +149,30 @@
target="RFC4271"/>, a BGP identifier for an originator of target="RFC4271"/>, a BGP identifier for an originator of
Layer-3 routes, particularly BGP announcements.</t> --> Layer-3 routes, particularly BGP announcements.</t> -->
<t hangText="Clos:">A hierarchic subset of a crossbar switch <t hangText="Clos:">A hierarchic subset of a crossbar switch
topology commonly used in data centers <xref target="Clos1"/>.</t> topology commonly used in data centers <xref target="Clos"/>.</t>
<t hangText="Datagram:">The L3ND content of a single Layer-3 <t hangText="Datagram:">The L3ND content of a single Layer-3
UDP Datagram.</t> UDP Datagram.</t>
<t hangText="Encapsulation:">Address Family Indicator and <t hangText="Encapsulation:">Address Family Indicator and
Subsequent Address Family Indicator (AFI/SAFI). I.e. classes of Subsequent Address Family Indicator (AFI/SAFI). I.e. classes of
layer-2.5 and 3 addresses such as IPv4, IPv6, MPLS, etc.</t> Layer-2.5 and Layer-3 addresses such as IPv4, IPv6, MPLS.</t>
<t hangText="Link or Logical Link:">A logical connection between <t hangText="Link or Logical Link:">A logical connection between
two interfaces on two devices. E.g. two VLANs between the same two interfaces on two different devices. E.g. two VLANs between
two ports are two links.</t> the same two ports are two links.</t>
<t hangText="MDC:">Massive Data Center, commonly composed of <t hangText="MDC:">Massive Data Center, commonly composed of
thousands of Top of Rack Switches (TORs).</t> thousands of Top of Rack Switches (TORs).</t>
<t hangText="MTU:">Maximum Transmission Unit, the size in octets <t hangText="MTU:">Maximum Transmission Unit, the size in octets
of the largest packet that can be sent on a medium, see <xref of the largest packet that can be sent on a medium, see <xref
target="RFC1122"/> 1.3.3.</t> target="RFC1122"/> 1.3.3.</t>
<t hangText="PDU:">Protocol Data Unit, an L3DL application layer <t hangText="PDU:">Protocol Data Unit, an L3ND application layer
message. A PDU's content may need to be broken into multiple message. A PDU's content may need to be broken into multiple
Datagrams to make it through MTU or other restrictions.</t> Datagrams to make it through MTU or other restrictions.</t>
<!-- <t hangText="RouterID:">An 32-bit identifier unique in the <!-- <t hangText="RouterID:">An 32-bit identifier unique in the
current routing domain, see <xref target="RFC6286"/>.</t> --> current routing domain, see <xref target="RFC6286"/>.</t> -->
<t hangText="Session:">An established, via exchange of OPEN PDUs, <t hangText="Session:">An established, via exchange of OPEN PDUs,
session between two L3ND capable IP interfaces on a link,</t> session between two L3ND capable IP interfaces on a link.</t>
<t hangText="TOR:">Top Of Rack switch, aggregates the servers in <t hangText="TOR Switch:">Top Of Rack switch, aggregates the
a rack and connects to aggregation layers of the Clos tree, AKA servers in a rack and connects to aggregation layers of the Clos
the Clos spine.</t> tree, AKA the Clos spine.</t>
<!-- <t hangText="ZTP:">Zero Touch Provisioning gives devices initial <!-- <t hangText="ZTP:">Zero Touch Provisioning gives devices initial
addresses, credentials, etc. on boot/restart.</t> --> addresses, credentials, etc. on boot/restart.</t> -->
<?rfc subcompact="no"?> <?rfc subcompact="no"?>
@ -393,7 +393,7 @@
Flags (bit): Flags (bit):
0 - 0 Raw TCP, 1 TLS 0 - 0 Raw TCP, 1 TLS
1 - 0 Self-Signed Cert for TLS, CA-based 1 - 0 Self-Signed Cert for TLS, 1 CA-based
</artwork> </artwork>
</figure> </figure>
@ -479,12 +479,12 @@ Flags (bit):
transports.</t> transports.</t>
<t>The server, the sender of the HELLO, listens on the advertised <t>The server, the sender of the HELLO, listens on the advertised
port for the TLS/TCP session open. The receiver of the accptable port for the TLS/TCP session open. The receiver of the acceptable
HELLO, the TLS/TCP client, initiates a TLS or raw TCP session with HELLO, the TLS/TCP client, initiates a TLS or raw TCP session with
the sender of the HELLO, the TLS/TCP server, preferably TLS, as the sender of the HELLO, the TLS/TCP server, preferably TLS, as
negotiated. If TLS, the client chooses either a self-signed advertised. If TLS, the server has chosen and signaled either a
certificate or one configured from the operational CA trusted by self-signed certificate or one configured from the operational CA
both parties, as negotiated in the HELLO exchange.</t> trusted by both parties, as negotiated in the HELLO exchange.</t>
<t>Once the TLS/TCP session is established, if the link is <t>Once the TLS/TCP session is established, if the link is
configured as point to point, the client side SHOULD stop listening configured as point to point, the client side SHOULD stop listening
@ -496,8 +496,13 @@ Flags (bit):
<t>Should an interface with an established TLS/TCP session be <t>Should an interface with an established TLS/TCP session be
reconfigured changing the TLS/TCP parameters, the TLS/TCP session reconfigured changing the TLS/TCP parameters, the TLS/TCP session
should be torn down and the devices should restart/resume should be closed or torn down.</t>
HELLOs.</t>
<t>Should the TLS/TCP session terminate for any reason, the devices
SHOULD restart/resume HELLOs. When the new TLS/TCP session is
started, if possible the OPEN PDU SHOULD try to resume the lost
logical session by using the same nonce and resuming from the last
Serial Number.</t>
<t>Once the TLS/TCP session has been established, the two devices <t>Once the TLS/TCP session has been established, the two devices
exchange L3ND PDUs, starting with OPENs.</t> exchange L3ND PDUs, starting with OPENs.</t>
@ -541,22 +546,24 @@ Flags (bit):
<t>The Nonce enables detection of a duplicate OPEN PDU. It SHOULD <t>The Nonce enables detection of a duplicate OPEN PDU. It SHOULD
be either a random number or a high resolution timestamp. It is be either a random number or a high resolution timestamp. It is
needed to prevent session closure due to a repeated OPEN caused by a needed to prevent session closure due to a repeated OPEN caused by a
race or a dropped or delayed ACK.</t> race or a dropped or delayed ACK. It can be used to resume a
dropped logical session.</t>
<t>AttrCount is the number of attributes in the Attribute List. A <t>AttrCount is the number of attributes in the Attribute List. A
node may send zero or more attributes.</t> node may send zero or more attributes.</t>
<t>Attributes are single octets the semantics of which are <t>Attributes are single octets the semantics of which are
operator-defined, e.g.: spine, leaf, backbone, route reflector, operator-defined, e.g.: spine, leaf, backbone, route reflector,
arabica, ....</t> arabica, ...</t>
<t>Attribute syntax and semantics are local to an operator or <t>Attribute syntax and semantics are local to an operator or
datacenter; hence there is no global registry. Nodes exchange datacenter; hence there is no global registry. Nodes exchange
their attributes only in the OPEN PDU.</t> their attributes only in the OPEN PDU.</t>
<t>Unlike L3DL <xref target="I-D.ietf-lsvr-l3dl"/>, there are no <t>Unlike L3DL <xref target="I-D.ietf-lsvr-l3dl"/>, there are no
verifyable keys in the PDUs. If the operator wants authentication, verifiable keys in the PDUs. If the operator wants authentication,
integrity, etc. TLS MUST be configured.</t> integrity, confidentiality, then TLS MUST have been requested by the
HELLO and agreed by the TLS session open.</t>
<t>The Serial Number is a monotonically increasing 32-bit value <t>The Serial Number is a monotonically increasing 32-bit value
representing the sender's state at the time of sending the last PDU. representing the sender's state at the time of sending the last PDU.
@ -564,14 +571,14 @@ Flags (bit):
Number would cause it to be zero, it should be incremented Number would cause it to be zero, it should be incremented
again.</t> again.</t>
<t>On session restart (new OPEN), a receiver MAY send the last <t>On session restart (new OPEN, same Nonce), a receiver MAY send
received Serial Number to tell the sender to only send data with a the last received Serial Number to tell the sender to only send data
Serial Number greater (in the <xref target="RFC1982"/> sense), or with a Serial Number greater (in the <xref target="RFC1982"/>
send a Serial Number of zero to request all data.</t> sense), or send a Serial Number of zero to request all data.</t>
<t>This allows a sender of an OPEN to tell the receiver that the <t>This allows a sender of an OPEN to tell the receiver that the
sender would like to resume a session and that the receiver only sender would like to resume a logical session and that the receiver
needs to send data starting with the PDU with the lowest Serial only needs to send data starting with the PDU with the lowest Serial
Number greater (in the <xref target="RFC1982"/> sense) than the one Number greater (in the <xref target="RFC1982"/> sense) than the one
sent in the OPEN. If the sender is not trying to resume a dropped sent in the OPEN. If the sender is not trying to resume a dropped
session, the Serial Number MUST be zero.</t> session, the Serial Number MUST be zero.</t>
@ -583,10 +590,9 @@ Flags (bit):
of zero.</t> of zero.</t>
<t>If a sender of OPEN does not receive an ACK of the OPEN PDU in a <t>If a sender of OPEN does not receive an ACK of the OPEN PDU in a
configurable time (default 30 seconds), then they MUST resend the configurable time (default 30 seconds), then they SHOULD close or
same OPEN PDU, with the same Nonce. Resending an unacknowledged otherwise terminate the TLS/TCP session and restart from the HELLO
OPEN PDU, like other ACKed PDUs, SHOULD use exponential back-off, state.</t>
see <xref target="RFC1122"/>.</t>
<t>If an OPEN arrives at L3ND speaker A from B with which A believes <t>If an OPEN arrives at L3ND speaker A from B with which A believes
it already has an L3ND session (i.e. OPENs have already been it already has an L3ND session (i.e. OPENs have already been
@ -605,7 +611,8 @@ Flags (bit):
with a new OPEN with a Serial Number of zero.</t> with a new OPEN with a Serial Number of zero.</t>
<t>TCP KeepAlives should be configured and tuned to meet local <t>TCP KeepAlives should be configured and tuned to meet local
operational needs.</t> operational needs. Some defaults and recommendations are needed
here.</t>
</section> </section>
@ -672,17 +679,10 @@ Flags (bit):
<t>If a PDU sender expects an ACK, e.g. for an OPEN, an <t>If a PDU sender expects an ACK, e.g. for an OPEN, an
Encapsulation, a Vendor PDU, etc., and does not receive the ACK Encapsulation, a Vendor PDU, etc., and does not receive the ACK
for a configurable time (default three seconds), and the interface for a configurable time (default three seconds) the TLS/TCP
and TLS/TCP session are live, the sender resends the PDU using session should be closed or dropped, and both sides revert to
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 this case of this ACK failure, and both sides revert to
HELLO state.</t> HELLO state.</t>
<t>If the link is broken below layer-3, retransmission MAY BE
retried when the link is restored.</t>
</section> </section>
</section> </section>
@ -692,7 +692,7 @@ Flags (bit):
<t>Once the devices know each other's IP Addresses, and have <t>Once the devices know each other's IP Addresses, and have
established a TLS/TCP session and have successfully exchanged OPENs, established a TLS/TCP session and have successfully exchanged OPENs,
the L3ND session is considered established, and the devices SHOULD the L3ND session is considered established, and the devices SHOULD
exchange L3 interface encapsulations, L3 addresses, and L2.5 exchange Layer-3 interface encapsulations, Layer-3 addresses, and Layer-2.5
labels.</t> labels.</t>
<t>Encapsulations of any AFI/SAFI may be exchanged over a TLS/TCP <t>Encapsulations of any AFI/SAFI may be exchanged over a TLS/TCP
@ -811,9 +811,9 @@ Flags (bit):
SHOULD be 2, suggesting a session restart (see <xref SHOULD be 2, suggesting a session restart (see <xref
target="ack"/> so all encapsulations will be resent.</t> target="ack"/> so all encapsulations will be resent.</t>
<t>If an LLEI has multiple addresses for an encapsulation type, <t>If an interface on a link has multiple addresses for an
one and only one address MAY be marked as primary (Primary Flag == encapsulation type, one and only one address MAY be marked as
1) for that Encapsulation Type.</t> primary (Primary Flag == 1) for that Encapsulation Type.</t>
<t>An Encapsulation interface address in an Encapsulation PDU MAY <t>An Encapsulation interface address in an Encapsulation PDU MAY
be marked as a loopback, in which case the Loopback bit is set. be marked as a loopback, in which case the Loopback bit is set.
@ -1055,16 +1055,17 @@ Flags (bit):
<section anchor="dhello" title="HELLO Discussion"> <section anchor="dhello" title="HELLO Discussion">
<t>A device may send IP packets an L3 interface which transmits <t>A device may send IP packets an Layer-3 interface which
data over a single Layer-2 (L2) interface or multiple L2 transmits data over a single Layer-2 interface or multiple Layer-2
interfaces. Packets sourced by one L3 IP interface over multiple interfaces. Packets sourced by one Layer-3 IP interface over
L2 should consider that an L3 interface with multiple Layer-2 multiple Layer-2 should consider that an Layer-3 interface with
interfaces could have many devices which might come at various multiple Layer-2 interfaces could have many devices which might
times, therefore the configured HELLO PDU retransmit time SHOULD come at various times, therefore the configured HELLO PDU
be set to a non-zero value, and periodic HELLOs should continue. retransmit time SHOULD be set to a non-zero value, and periodic
Packets transmitted on a single L2 interface on a point-to-point HELLOs should continue. Packets transmitted on a single Layer-2
(p2p) connection, MAY set the configuration value to zero, so once interface on a point-to-point (p2p) connection, MAY set the
a TLS/TCP session is up, HELLOs are no longer desirable.</t> configuration value to zero, so once a TLS/TCP session is up,
HELLOs are no longer desirable.</t>
<t>A device with multiple Layer-2 interfaces, traditionally called <t>A device with multiple Layer-2 interfaces, traditionally called
a switch, may be used to forward frames and therefore packets from a switch, may be used to forward frames and therefore packets from
@ -1132,9 +1133,9 @@ Flags (bit):
<t>Many datacenter operators have a strange belief that physical <t>Many datacenter operators have a strange belief that physical
walls and firewalls provide sufficient security. This is not walls and firewalls provide sufficient security. This is not
credible. All DC protocols need to be examined for exposure and credible. All DC protocols need to be examined for exposure and
attack surface. In the case of L3ND, Authentication and Integrity attack surface. In the case of L3ND, authentication and integrity
as provided by TLS validated to a configured shared CA trust anchor as provided by TLS validated to a configured shared CA trust anchor
is strongly recommended.</t> is strongly RECOMMENDED.</t>
<t>It is generally unwise to assume that on the wire Layer-3 is <t>It is generally unwise to assume that on the wire Layer-3 is
secure. Strange/unauthorized devices may plug into a port. secure. Strange/unauthorized devices may plug into a port.
@ -1148,13 +1149,11 @@ Flags (bit):
<t>If OPENs are not using validated TLS, an attacker could forge an <t>If OPENs are not using validated TLS, an attacker could forge an
OPEN for an existing session and cause the session to be reset.</t> OPEN for an existing session and cause the session to be reset.</t>
<t>For these reasons, TLS SHOULD be used.</t>
</section> </section>
<section anchor="iana" title="IANA Considerations"> <section anchor="iana" title="IANA Considerations">
<section anchor="iana-l3addr" title="Link Local L3 Addresses"> <section anchor="iana-l3addr" title="Link Local Layer-3 Addresses">
<t>IANA is requested to assignment one address (TBD1) for <t>IANA is requested to assignment one address (TBD1) for
L3DL-L3-LL from the IPv4 Multicast Address Space Registry from L3DL-L3-LL from the IPv4 Multicast Address Space Registry from
@ -1170,7 +1169,7 @@ Flags (bit):
<section anchor="iana-ports" title="Ports for TLS/TCP"> <section anchor="iana-ports" title="Ports for TLS/TCP">
<t>This document requests the IANA to assign a well-known TCP <t>This document requests the IANA to assign a well-known TCP
Port Number (TBD3) to the L3 Neighbor Discovery Protocol for the Port Number (TBD3) to the Layer-3 Neighbor Discovery Protocol for the
following, see <xref target="tcp"/>:</t> following, see <xref target="tcp"/>:</t>
<figure> <figure>
@ -1255,7 +1254,13 @@ Flags (bit):
<section anchor="acks" title="Acknowledgments"> <section anchor="acks" title="Acknowledgments">
<t>The authors thank .</t> <t>Many kind people helped with the Layer-2 cousin of this protocol,
L3DL. Cristel Pelsser provided multiple reviews, Harsha Kovuru
commented during implementation, Jeff Haas reviewed and commented,
Joerg Ott did an early but deep transport review, Joe Clarke
provided a useful ops review, John Scudder a deeply serious review
and comments, Martijn Schmidt contributed, and Neeraj Malhotra
reviewed.</t>
</section> </section>
@ -1288,7 +1293,7 @@ Flags (bit):
<?rfc include="reference.RFC.1982.xml"?> <?rfc include="reference.RFC.1982.xml"?>
<?rfc include="reference.RFC.4760.xml"?> <?rfc include="reference.RFC.4760.xml"?>
<?rfc include="reference.I-D.ymbk-idr-l3nd-ulpc.xml"?> <?rfc include="reference.I-D.ymbk-idr-l3nd-ulpc.xml"?>
<reference anchor="Clos1" target="https://en.wikipedia.org/wiki/Clos_network/"> <reference anchor="Clos" target="https://en.wikipedia.org/wiki/Clos_network/">
<front> <front>
<title>Clos Network</title> <title>Clos Network</title>
<author/> <author/>