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> </artwork>
</figure> </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 <t>The Port is the two octet TCP Port Number (default is TBD3) on
HELLO sender MUST have a waiting TLS/TCP (as specified in Flags) which the HELLO sender MUST have a waiting TLS/TCP (as specified in
server listening. Though the IANA assigned well-known port SHOULD Flags) server listening. Though the IANA assigned well-known port
be used, this field allows configuration of alternate ports.</t> SHOULD be used, this field allows configuration of alternate
ports.</t>
<t>The IPv4 UDP packets are sent to the IPv4 link local multicast <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 address (TBD1) and the IPv6 UDP packets are sent to an IPv6 link
Local multicast address (TBD2). See <xref target="dhello"/> for why Local multicast address (TBD2). See <xref target="dhello"/> for why
multicast is used.</t> multicast is used.</t>
<t>The HELLO PDU solicits a unicast TLS/TCP open request(s) of the <t>The HELLO PDU solicits a unicast TLS/TCP session open request of
same AFI from other devices on the link.</t> the same AFI from other devices on the link.</t>
<t>When a HELLO is received from a source IP address with which <t>When a HELLO is received from a source IP address with which
there is no established TLS/TCP L3ND session, the receiver SHOULD there is no established TLS/TCP L3ND session, if the receiver has
respond by sending a TLS/TCP client open request, using the same the higher of the two IP addresses, it SHOULD respond by sending a
AFI, to the source IP address of the HELLO to establish an L3ND TLS/TCP client open request, using the same AFI, to the source IP
TLS/TCP session.</t> 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 <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> 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 <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 HELLO if it is configured to participate in L3ND sessions and repeat
a configured interval, with a default of 60 seconds.</t> HELLOs at a configured interval, with a default of 60 seconds.</t>
<t>If the configured multicast destination address is one that is <t>If the configured multicast destination address is one that is
propagated by switches, the HELLO SHOULD be repeated at a configured propagated by switches, the HELLO SHOULD be repeated at a configured
@ -461,7 +462,7 @@ Flags (bit):
five seconds, and MUST be configurable.</t> five seconds, and MUST be configurable.</t>
<t>If a HELLO is received from an IP Address with which there is an <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 <t>A device with a TLS/TCP listener SHOULD log or otherwise report
repeated failed inbound attempts.</t> repeated failed inbound attempts.</t>
@ -477,45 +478,49 @@ Flags (bit):
<t>As it is assumed that the configured deployment of a data center <t>As it is assumed that the configured deployment of a data center
would have compatible parameters on all devices, any disagreement 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 <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 ensure that a SYN received in response to a HELLO is on the local
link. It MAY be disabled by configuration. GTSM check failures 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> overwhelming logs.</t>
<t>If the receiver of a HELLO agrees with the sender's choice of <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 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 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 sufficient to open a TCP session between them, which will allow for
very large data PDUs while obviating the need to invent complex reliable transport of very large data PDUs while obviating the need
transports.</t> to invent complex transports.</t>
<t>The L3ND peer with the higher IP address MUST act as the TLS/TCP <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 client and open the transport session (send SYN) toward the peer
with the lower IP address.</t> with the lower IP address.</t>
<t>The server, the sender of the HELLO with the lower IP address, <t>The server, the sender of the HELLO with from the lower IP
listens on the advertised port for the TLS/TCP session open. The address, listens on the advertised port for the TLS/TCP session
receiver of the acceptable HELLO, the TLS/TCP client, initiates a open. The receiver of the acceptable HELLO, the TLS/TCP client,
TLS or raw TCP session with the sender of the HELLO, the TLS/TCP initiates a TLS or raw TCP session toward the sender of the HELLO,
server, preferably TLS, as advertised. If TLS, the server has the TLS/TCP server, preferably TLS, as advertised. If TLS, the
chosen and signaled either a self-signed certificate or one server has chosen and signaled either a self-signed certificate or
configured from the operational CA trusted by both parties, as one configured from the operational CA trusted by both parties, as
negotiated in the HELLO exchange.</t> 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 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 on any port for which it has sent a HELLO. The server, if
stop sending HELLOs.</t> 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 <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 <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 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 <t>Should the TLS/TCP session terminate for any reason, the devices
SHOULD restart/resume HELLOs. When the new TLS/TCP session is 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 <t>Each device has learned the other's IP Address from the
HELLO exchange, see <xref target="hello"/> and established a 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 <t>The first PDU each sends MUST be an OPEN, and the other side MUST
respond with an ACK PDU.</t> respond with an ACK PDU.</t>
@ -559,8 +564,8 @@ Flags (bit):
</artwork> </artwork>
</figure> </figure>
<t>The Payload Length is the number of octets in all fields of the <t>The four octet Payload Length is the number of octets in all
PDU from the Nonce through the Serial Number.</t> fields of the PDU from the Nonce through the Serial Number.</t>
<t>The four octet Nonce enables detection of a duplicate OPEN PDU. <t>The four octet Nonce enables detection of a duplicate OPEN PDU.
It SHOULD be either a random number or a high resolution timestamp. 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 caused by a race or a dropped or delayed ACK. It can be used to
resume a dropped logical session.</t> resume a dropped logical session.</t>
<t>AttrCount is the number of attributes in the Attribute List. A <t>The one octet AttrCount is the number of attributes in the
node may send zero or more attributes.</t> Attribute List. A 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,
@ -584,11 +589,11 @@ Flags (bit):
integrity, confidentiality, then TLS MUST have been requested by the integrity, confidentiality, then TLS MUST have been requested by the
HELLO and agreed by the TLS session open.</t> 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. 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 It may be an non-negative integer, a timestamp, etc. If
Number would cause it to be zero, it should be incremented incrementing the Serial Number would cause it to be zero, it should
again.</t> be incremented again.</t>
<t>On session restart (new OPEN, same Nonce), a receiver MAY send <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 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 <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 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 of the OPEN PDU only needs to send data starting with the PDU with
Number greater (in the <xref target="RFC1982"/> sense) than the one the lowest Serial Number greater (in the <xref target="RFC1982"/>
sent in the OPEN. If the sender is not trying to resume a dropped sense) than the one sent in the OPEN. If the sender is not trying
session, the Serial Number MUST be zero.</t> 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 <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 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 Error Code of 5, Session May Not Be Continued, EType of 1. The
failing OPEN PDU SHOULD then send an OPEN PDU with a Serial Number sender of the failing OPEN PDU SHOULD respond with an OPEN PDU with
of zero.</t> a Serial Number 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 5 seconds), then they SHOULD close or configurable time (default 5 seconds), then they SHOULD close or
@ -641,7 +646,7 @@ Flags (bit):
condition which might have been raised.</t> 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> <figure>
@ -649,24 +654,24 @@ Flags (bit):
0 1 2 3 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 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> </artwork>
</figure> </figure>
<t>The ACK acknowledges receipt of an OPEN, Encapsulation, Vendor <t>The ACK PDU acknowledges receipt of an OPEN, Encapsulation,
PDU, etc.</t> 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, <t>The one octet ACKed PDU is the PDU Type of the PDU being
e.g., OPEN, one of the Encapsulations, etc.</t> acknowledged, e.g., OPEN, one of the Encapsulations, etc.</t>
<t>If there was an error processing the received PDU, then the EType <t>If there was an error processing the received PDU, then the one
is non-zero. If the EType is zero, Error Code and Error Hint MUST octet EType is non-zero. If the EType is zero, Error Code and Error
also be zero.</t> Hint MUST also be zero.</t>
<t>A non-zero EType is the receiver's way of telling the PDU's <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 sender that the receiver had problems processing the PDU. The Error
@ -685,14 +690,14 @@ Flags (bit):
<?rfc subcompact="no"?> <?rfc subcompact="no"?>
</list></t> </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 <xref target="iana-error"/>. Someone stuck in the 1990s might think
the catenation of EType and Error Code as an echo of 0x1zzz, 0x2zzz, the catenation of EType and Error Code as an echo of 0x1zzz, 0x2zzz,
etc. They might be right; or not.</t> etc. They might be right; or not.</t>
<t>The Error Hint, an arbitrary 16 bits, is any additional data the <t>The two octet Error Hint, is arbitrary additional data the sender
sender of the error PDU thinks will help the recipient or the of the error PDU thinks will help the recipient or the debugger with
debugger with the particular error.</t> the particular error.</t>
<section anchor="retrans" title="Retransmission"> <section anchor="retrans" title="Retransmission">
@ -956,7 +961,9 @@ Flags (bit):
that prefix on that interface.</t> that prefix on that interface.</t>
<t>The bottom of the stack flag, S, MUST be set on one and only <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> </section>
@ -1272,10 +1279,11 @@ Flags (bit):
Code Error Name Code Error Name
---- ------------------- ---- -------------------
0 No Error 0 No Error
1 Checksum Error 1 MPLS Error
2 Logical Link Addressing Conflict 2 Logical Link Addressing Conflict
3 Encapsulation Error 3 Encapsulation Error
4 Announce/Withdraw Error 4 Announce/Withdraw Error
5 Session May Not Be Continued
</artwork> </artwork>
</figure> </figure>