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

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

@ -127,7 +127,7 @@
</list></t>
<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,
etc. Once IP connectivity has been leveraged to get layer-3
addressability and forwarding capabilities, normal IP forwarding and
@ -149,30 +149,30 @@
target="RFC4271"/>, a BGP identifier for an originator of
Layer-3 routes, particularly BGP announcements.</t> -->
<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
UDP Datagram.</t>
<t hangText="Encapsulation:">Address Family Indicator and
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
two interfaces on two devices. E.g. two VLANs between the same
two ports are two links.</t>
two interfaces on two different devices. E.g. two VLANs between
the same two ports are two links.</t>
<t hangText="MDC:">Massive Data Center, commonly composed of
thousands of Top of Rack Switches (TORs).</t>
<t hangText="MTU:">Maximum Transmission Unit, the size in octets
of the largest packet that can be sent on a medium, see <xref
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
Datagrams to make it through MTU or other restrictions.</t>
<!-- <t hangText="RouterID:">An 32-bit identifier unique in the
current routing domain, see <xref target="RFC6286"/>.</t> -->
<t hangText="Session:">An established, via exchange of OPEN PDUs,
session between two L3ND capable IP interfaces on a link,</t>
<t hangText="TOR:">Top Of Rack switch, aggregates the servers in
a rack and connects to aggregation layers of the Clos tree, AKA
the Clos spine.</t>
session between two L3ND capable IP interfaces on a link.</t>
<t hangText="TOR Switch:">Top Of Rack switch, aggregates the
servers in a rack and connects to aggregation layers of the Clos
tree, AKA the Clos spine.</t>
<!-- <t hangText="ZTP:">Zero Touch Provisioning gives devices initial
addresses, credentials, etc. on boot/restart.</t> -->
<?rfc subcompact="no"?>
@ -393,7 +393,7 @@
Flags (bit):
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>
</figure>
@ -478,13 +478,13 @@ Flags (bit):
very large data PDUs while obviating the need to invent complex
transports.</t>
<t> The server, the sender of the HELLO, listens on the advertised
port for the TLS/TCP session open. The receiver of the accptable
<t>The server, the sender of the HELLO, listens on the advertised
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
the sender of the HELLO, the TLS/TCP server, preferably TLS, as
negotiated. If TLS, the client chooses either a self-signed
certificate or one configured from the operational CA trusted by
both parties, as negotiated in the HELLO exchange.</t>
advertised. If TLS, the server has chosen and signaled either a
self-signed certificate or one configured from the operational CA
trusted by both parties, as negotiated in the HELLO exchange.</t>
<t>Once the TLS/TCP session is established, if the link is
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
reconfigured changing the TLS/TCP parameters, the TLS/TCP session
should be torn down and the devices should restart/resume
HELLOs.</t>
should be closed or torn down.</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
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
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
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
node may send zero or more attributes.</t>
<t>Attributes are single octets the semantics of which are
operator-defined, e.g.: spine, leaf, backbone, route reflector,
arabica, ....</t>
arabica, ...</t>
<t>Attribute syntax and semantics are local to an operator or
datacenter; hence there is no global registry. Nodes exchange
their attributes only in the OPEN PDU.</t>
<t>Unlike L3DL <xref target="I-D.ietf-lsvr-l3dl"/>, there are no
verifyable keys in the PDUs. If the operator wants authentication,
integrity, etc. TLS MUST be configured.</t>
verifiable keys in the PDUs. If the operator wants authentication,
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
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
again.</t>
<t>On session restart (new OPEN), a receiver MAY send the last
received Serial Number to tell the sender to only send data with a
Serial Number greater (in the <xref target="RFC1982"/> sense), or
send a Serial Number of zero to request all data.</t>
<t>On session restart (new OPEN, same Nonce), a receiver MAY send
the last received Serial Number to tell the sender to only send data
with a Serial Number greater (in the <xref target="RFC1982"/>
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
sender would like to resume a session and that the receiver only
needs to send data starting with the PDU with the lowest Serial
sender would like to resume a logical session and that the receiver
only needs to send data starting with the PDU with the lowest Serial
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
session, the Serial Number MUST be zero.</t>
@ -583,10 +590,9 @@ Flags (bit):
of zero.</t>
<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
same OPEN PDU, with the same Nonce. Resending an unacknowledged
OPEN PDU, like other ACKed PDUs, SHOULD use exponential back-off,
see <xref target="RFC1122"/>.</t>
configurable time (default 30 seconds), then they SHOULD close or
otherwise terminate the TLS/TCP session and restart from the HELLO
state.</t>
<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
@ -605,7 +611,8 @@ Flags (bit):
with a new OPEN with a Serial Number of zero.</t>
<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>
@ -672,17 +679,10 @@ Flags (bit):
<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
for a configurable time (default three seconds), and the interface
and TLS/TCP session are live, 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 this case of this ACK failure, and both sides revert to
for a configurable time (default three seconds) the TLS/TCP
session should be closed or dropped, and both sides revert to
HELLO state.</t>
<t>If the link is broken below layer-3, retransmission MAY BE
retried when the link is restored.</t>
</section>
</section>
@ -692,7 +692,7 @@ Flags (bit):
<t>Once the devices know each other's IP Addresses, and have
established a TLS/TCP session and have successfully exchanged OPENs,
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>
<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
target="ack"/> so all encapsulations will be resent.</t>
<t>If an LLEI has multiple addresses for an encapsulation type,
one and only one address MAY be marked as primary (Primary Flag ==
1) for that Encapsulation Type.</t>
<t>If an interface on a link has multiple addresses for an
encapsulation type, one and only one address MAY be marked as
primary (Primary Flag == 1) for that Encapsulation Type.</t>
<t>An Encapsulation interface address in an Encapsulation PDU MAY
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">
<t>A device may send IP packets an L3 interface which transmits
data over a single Layer-2 (L2) interface or multiple L2
interfaces. Packets sourced by one L3 IP interface over multiple
L2 should consider that an L3 interface with multiple Layer-2
interfaces could have many devices which might come at various
times, therefore the configured HELLO PDU retransmit time SHOULD
be set to a non-zero value, and periodic HELLOs should continue.
Packets transmitted on a single L2 interface on a point-to-point
(p2p) connection, MAY set the configuration value to zero, so once
a TLS/TCP session is up, HELLOs are no longer desirable.</t>
<t>A device may send IP packets an Layer-3 interface which
transmits data over a single Layer-2 interface or multiple Layer-2
interfaces. Packets sourced by one Layer-3 IP interface over
multiple Layer-2 should consider that an Layer-3 interface with
multiple Layer-2 interfaces could have many devices which might
come at various times, therefore the configured HELLO PDU
retransmit time SHOULD be set to a non-zero value, and periodic
HELLOs should continue. Packets transmitted on a single Layer-2
interface on a point-to-point (p2p) connection, MAY set the
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
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
walls and firewalls provide sufficient security. This is not
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
is strongly recommended.</t>
is strongly RECOMMENDED.</t>
<t>It is generally unwise to assume that on the wire Layer-3 is
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
OPEN for an existing session and cause the session to be reset.</t>
<t>For these reasons, TLS SHOULD be used.</t>
</section>
<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
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">
<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>
<figure>
@ -1255,7 +1254,13 @@ Flags (bit):
<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>
@ -1288,7 +1293,7 @@ Flags (bit):
<?rfc include="reference.RFC.1982.xml"?>
<?rfc include="reference.RFC.4760.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>
<title>Clos Network</title>
<author/>