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

longer ACK fields

Browse source
This commit is contained in:
Randy Bush 2022-03-06 17:26:00 -08:00
parent 8fec18824e
commit 861cdba4e1
1 changed files with 72 additions and 64 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -411,33 +411,34 @@ Flags (bit):
</artwork>
</figure>
<t>The Payload Length is 24 to cover the Flags and Port fields.</t>
<t>The Payload Length is 3 to cover the Flags and Port fields.</t>
<t>The Port is the TCP Port Number (default is TBD3) on which the
HELLO sender MUST have a waiting TLS/TCP (as specified in Flags)
server listening. Though the IANA assigned well-known port SHOULD
be used, this field allows configuration of alternate ports.</t>
<t>The Port is the two octet TCP Port Number (default is TBD3) on
which the HELLO sender MUST have a waiting TLS/TCP (as specified in
Flags) server listening. Though the IANA assigned well-known port
SHOULD be used, this field allows configuration of alternate
ports.</t>
<t>The IPv4 UDP packets are sent to the IPv4 link local multicast
address (TBD1) and the IPv6 UDP packets are sent to an IPv6 link
Local multicast address (TBD2). See <xref target="dhello"/> for why
multicast is used.</t>
<t>The HELLO PDU solicits a unicast TLS/TCP open request(s) of the
same AFI from other devices on the link.</t>
<t>The HELLO PDU solicits a unicast TLS/TCP session open request of
the same AFI from other devices on the link.</t>
<t>When a HELLO is received from a source IP address with which
there is no established TLS/TCP L3ND session, the receiver SHOULD
respond by sending a TLS/TCP client open request, using the same
AFI, to the source IP address of the HELLO to establish an L3ND
TLS/TCP session.</t>
there is no established TLS/TCP L3ND session, if the receiver has
the higher of the two IP addresses, it SHOULD respond by sending a
TLS/TCP client open request, using the same AFI, to the source IP
address of the HELLO to establish an L3ND TLS/TCP session.</t>
<t>All L3ND PDUs other than HELLO are sent via TLS/TCP, as the
server's destination IP address is known after the HELLO.</t>
<t>When an interface is turned up on a device, it SHOULD issue a
HELLO if it is to participate in L3ND sessions and repeat HELLOs at
a configured interval, with a default of 60 seconds.</t>
HELLO if it is configured to participate in L3ND sessions and repeat
HELLOs at a configured interval, with a default of 60 seconds.</t>
<t>If the configured multicast destination address is one that is
propagated by switches, the HELLO SHOULD be repeated at a configured
@ -461,7 +462,7 @@ Flags (bit):
five seconds, and MUST be configurable.</t>
<t>If a HELLO is received from an IP Address with which there is an
established session for that AFI, the HELLO should be dropped.</t>
established session for that AFI, the HELLO SHOULD be dropped.</t>
<t>A device with a TLS/TCP listener SHOULD log or otherwise report
repeated failed inbound attempts.</t>
@ -477,45 +478,49 @@ Flags (bit):
<t>As it is assumed that the configured deployment of a data center
would have compatible parameters on all devices, any disagreement
over TLS/TCP or trust anchors MUST be logged.</t>
over TLS/TCP or trust anchors MUST be logged; with rate limiting of
the logging.</t>
<t>By default, GTSM, <xref target="RFC5082"/>, SHOULD be enabled to
ensure that a SYN received in response to a HELLO is on the local
link. It MAY be disabled by configuration. GTSM check failures
SHOULD be logged, though with rate limiting to keep from
SHOULD be logged; though with rate limiting to keep from
overwhelming logs.</t>
<t>If the receiver of a HELLO agrees with the sender's choice of
TLS/TCP and authentication, both sides have agreed on an AFI for the
transport and on 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>
reliable transport of very large data PDUs while obviating the need
to invent complex transports.</t>
<t>The L3ND peer with the higher IP address MUST act as the TLS/TCP
client and open the transport session (send SYN) toward the peer
with the lower IP address.</t>
<t>The server, the sender of the HELLO with the lower IP address,
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 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
<t>The server, the sender of the HELLO with from the lower IP
address, 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 toward the sender of the HELLO,
the TLS/TCP server, preferably TLS, as 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
<t>Once the TLS/TCP session is established, if its interface is
configured as point to point, the client side SHOULD stop listening
on any port for which it has sent a HELLO. The server side SHOULD
stop sending HELLOs.</t>
on any port for which it has sent a HELLO. The server, if
configured as a point to point interface SHOULD stop sending
HELLOs.</t>
<t>If the TLS/TCP open fails, then this SHOULD be logged and the
parties MUST go back to the initial state and try HELLO.</t>
parties MUST go back to the initial state and try HELLO. Loggin
SHOULD be rate limited.</t>
<t>Should an interface with an established TLS/TCP session be
reconfigured changing the TLS/TCP parameters, the TLS/TCP session
should be closed or torn down.</t>
should be closed or torn down and both parties should return to the
HELLO state.</t>
<t>Should the TLS/TCP session terminate for any reason, the devices
SHOULD restart/resume HELLOs. When the new TLS/TCP session is
@ -532,7 +537,7 @@ Flags (bit):
<t>Each device has learned the other's IP Address from the
HELLO exchange, see <xref target="hello"/> and established a
TLS/TCP session for a particular AFI.</t>
TLS/TCP session over a particular AFI.</t>
<t>The first PDU each sends MUST be an OPEN, and the other side MUST
respond with an ACK PDU.</t>
@ -559,8 +564,8 @@ Flags (bit):
</artwork>
</figure>
<t>The Payload Length is the number of octets in all fields of the
PDU from the Nonce through the Serial Number.</t>
<t>The four octet Payload Length is the number of octets in all
fields of the PDU from the Nonce through the Serial Number.</t>
<t>The four octet Nonce enables detection of a duplicate OPEN PDU.
It SHOULD be either a random number or a high resolution timestamp.
@ -568,8 +573,8 @@ Flags (bit):
caused by a 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>The one octet 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,
@ -584,11 +589,11 @@ Flags (bit):
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 four octet value
representing the sender's state at the time of sending the last PDU.
It may be an integer, a timestamp, etc. If incrementing the Serial
Number would cause it to be zero, it should be incremented
again.</t>
It may be an non-negative integer, a timestamp, etc. If
incrementing the Serial Number would cause it to be zero, it should
be incremented again.</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
@ -597,16 +602,16 @@ Flags (bit):
<t>This allows a sender of an OPEN to tell the receiver that the
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>
of the OPEN PDU 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>
<t>If the receiver of an OPEN PDU with a non-zero Serial Number can
not resume from the requested point, it should return an ACK with an
Error Code of 2, Session could not be continued. The sender of the
failing OPEN PDU SHOULD then send an OPEN PDU with a Serial Number
of zero.</t>
Error Code of 5, Session May Not Be Continued, EType of 1. The
sender of the failing OPEN PDU SHOULD respond with an OPEN PDU with
a Serial Number of zero.</t>
<t>If a sender of OPEN does not receive an ACK of the OPEN PDU in a
configurable time (default 5 seconds), then they SHOULD close or
@ -641,7 +646,7 @@ Flags (bit):
condition which might have been raised.</t>
<!--
protocol "Version = 0:8,PDU Type = 3:8,Payload Length = 5:32,ACKed PDU:8,EType:4,Error Code:12,Error Hint:16"
protocol "Version = 0:8,PDU Type = 3:8,Payload Length = 6:32,ACKed PDU:8,EType:8,Error Code:16,Error Hint:16"
-->
<figure>
@ -649,24 +654,24 @@ Flags (bit):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0 | PDU Type = 3 | Payload Length = 5 ~
| Version = 0 | PDU Type = 3 | Payload Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ACKed PDU | EType | ~
| | ACKed PDU | EType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Error Hint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Error Code | Error Hint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The ACK acknowledges receipt of an OPEN, Encapsulation, Vendor
PDU, etc.</t>
<t>The ACK PDU acknowledges receipt of an OPEN, Encapsulation,
Vendor PDU, etc. and is used to return error codes if any.</t>
<t>The ACKed PDU is the PDU Type of the PDU being acknowledged,
e.g., OPEN, one of the Encapsulations, etc.</t>
<t>The one octet ACKed PDU is the PDU Type of the PDU being
acknowledged, e.g., OPEN, one of the Encapsulations, etc.</t>
<t>If there was an error processing the received PDU, then the EType
is non-zero. If the EType is zero, Error Code and Error Hint MUST
also be zero.</t>
<t>If there was an error processing the received PDU, then the one
octet EType is non-zero. If the EType is zero, Error Code and Error
Hint MUST also be zero.</t>
<t>A non-zero EType is the receiver's way of telling the PDU's
sender that the receiver had problems processing the PDU. The Error
@ -685,14 +690,14 @@ Flags (bit):
<?rfc subcompact="no"?>
</list></t>
<t>The 12 bit Error Code, noting protocol failures, are listed in
<t>The two octet Error Code, noting protocol failures, are listed in
<xref target="iana-error"/>. Someone stuck in the 1990s might think
the catenation of EType and Error Code as an echo of 0x1zzz, 0x2zzz,
etc. They might be right; or not.</t>
<t>The Error Hint, an arbitrary 16 bits, is any additional data the
sender of the error PDU thinks will help the recipient or the
debugger with the particular error.</t>
<t>The two octet Error Hint, is arbitrary additional data the sender
of the error PDU thinks will help the recipient or the debugger with
the particular error.</t>
<section anchor="retrans" title="Retransmission">
@ -956,7 +961,9 @@ Flags (bit):
that prefix on that interface.</t>
<t>The bottom of the stack flag, S, MUST be set on one and only
one label.</t>
one label. Should this not be the case, the receiver of the
erroneous PDU MUST respond with an ACK PDU of EType 1 and Error
Code 1, MPLS Error.</t>
</section>
@ -1272,10 +1279,11 @@ Flags (bit):
Code Error Name
---- -------------------
0 No Error
1 Checksum Error
1 MPLS Error
2 Logical Link Addressing Conflict
3 Encapsulation Error
4 Announce/Withdraw Error
5 Session May Not Be Continued
</artwork>
</figure>