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

trim much redundancy off front

Browse source
This commit is contained in:
Randy Bush 2022-02-15 14:27:21 -08:00
parent 2d3d6dc7c9
commit 9d78ced03b
1 changed files with 54 additions and 127 deletions
Download patch file Download diff file Expand all files Collapse all files

181
draft-ymbk-idr-l3-discovery.xml
View file

@ -127,15 +127,14 @@
</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="Clos1"/>) in order to
exchange the data needed for bootstrapping BGP-based peering. Once exchange the data needed for bootstrapping BGP-based peering, EVPNs,
IP connectivity has been leveraged to get layer-3 addressability and etc. Once IP connectivity has been leveraged to get layer-3
forwarding capabilities, normal IP forwarding and routing can take addressability and forwarding capabilities, normal IP forwarding and
over.</t> routing can take over.</t>
<t>L3ND might be found to be more widely applicable to a range of <t>L3ND might be found to be widely applicable to a range of routing
routing and similar protocols which need Layer-3 neighbor and similar protocols which need Layer-3 neighbor discovery.</t>
discovery.</t>
</section> </section>
@ -205,88 +204,25 @@
</section> </section>
<section anchor="top" title="Top Level Overview">
<t><list style="symbols">
<t>Devices discover each other's IP Addresses on logical links
using Multicast and Unicast UDP</t>
<t>The main body of the protocol runs over TCP, normally with
TLS</t>
<t>Further IP Address reachability may be exchanged</t>
<t>IP Encapsulation data are exchanged</t>
<t>A BGP-like upper layer protocol is assumed to use the
identifiers and encapsulation data to discover and build a
topology database using BGP</t>
</list></t>
<figure>
<artwork>
+-------------------+ +-------------------+ +-------------------+
| Device | | Device | | Device |
| | | | | |
|+-----------------+| |+-----------------+| |+-----------------+|
|| || || || || ||
|| BGP &lt;+---+&gt; BGP &lt;+---+&gt; BGP ||
|| || || || || ||
|+--------^--------+| |+--------^--------+| |+--------^--------+|
| | | | | | | | |
| | | | | | | | |
|+--------+--------+| |+--------+--------+| |+--------+--------+|
|| Encapsulations || || Encapsulations || || Encapsulations ||
|| &amp; Addresses || || &amp; Addresses || || &amp; Addresses ||
|+--------^--------+| |+--------^--------+| |+--------^--------+|
| | | | | | | | |
| | | | | | | | |
|+--------v--------+| |+--------v--------+| |+--------v--------+|
|| || || || || ||
||Inter-Device PDUs&lt;+---+&gt;Inter-Device PDUs&lt;+---+&gt;Inter-Device PDUs||
|| || || || || ||
|+-----------------+| |+-----------------+| |+-----------------+|
+-------------------+ +-------------------+ +-------------------+
</artwork>
</figure>
<t>There are two protocols, the inter-device (left-right in the
diagram) per-link layer-3 discovery and the API to the upper level
BGP-like routing protocol (up-down in the above diagram):
<list style="symbols">
<t>A device broadcasts a Layer-3 Multicast UDP datagram (HELLO)
containing the port number that is willing to serve a TLS or raw
TCP connection to support the data exchange of the rest of the
protocol in a reliable and preferably authenticated manner.</t>
<t>Another device on the link then establishes a TLS or raw TCP
session in which inter-device PDUs are used to exchange device and
logical link identities and layer-2.5 (MPLS) and 3 identifiers
(not payloads), e.g. more IP Addresses, loopback addresses, port
identities, and Encapsulations.</t>
<t>A L3DL extension, <!-- <xref target="I-D.ymbk-idr-l3bdl-ulpc"/>,-->
describes the next upper layer L3DL protocol to exchange BGP
parameter information.</t>
</list></t>
<t>The upper layer BGP family routing protocols cross all the
devices, but are not part of these L3ND protocols.</t>
</section>
<section anchor="ilpo" title="Inter-Link Protocol Overview"> <section anchor="ilpo" title="Inter-Link Protocol Overview">
<t>Two devices discover each other and their respective IP <t>A device broadcasts a Layer-3 Multicast UDP datagram (HELLO)
identities by one sending a Multicast UDP HELLO PDU (<xref containing the port number that is willing to serve a TLS or raw
target="hello"/>), and an other responds by attempting a TLS or raw TCP connection to support the data exchange of the rest of the
TCP connection. To assure discovery of new devices coming up on a protocol in a reliable and preferably authenticated manner.</t>
multi-link topology, devices on such a topology, and only on a
multi-link topology, send periodic HELLOs forever, see <xref <t>Another device on the link then establishes a TLS or raw TCP
session in which inter-device PDUs are used to exchange device and
logical link identities and layer-2.5 (MPLS) and 3 identifiers
(not payloads), e.g. more IP Addresses, loopback addresses, port
identities, and Encapsulations.</t>
<t>To assure discovery of new devices coming up on a multi-link
topology, devices on such a topology, and only on a multi-link
topology, send periodic HELLOs forever, see <xref
target="dhello"/>.</t> target="dhello"/>.</t>
<t>A device receivinga HELLO attempts to negotiate and establish a <t>Given the TLS/TCP session, OPEN PDUs (<xref target="open"/>) are
TCP, preferably TLS, session to the server at the source IP
addresses of the received HELLO on the port advertised in the HELLO.
Given the TCP/TLS session, OPEN PDUs (<xref target="open"/>) are
exchanged, the Encapsulations (<xref target="afisafi"/>) configured exchanged, the Encapsulations (<xref target="afisafi"/>) configured
on an end point may be announced and modified. Note that these are on an end point may be announced and modified. Note that these are
only the encapsulation and addresses configured on the announcing only the encapsulation and addresses configured on the announcing
@ -319,6 +255,10 @@
session running over one AFI MAY carry encapsulations etc. of session running over one AFI MAY carry encapsulations etc. of
different AFIs,</t> different AFIs,</t>
<t>A L3DL extension, <!-- <xref
target="I-D.ymbk-idr-l3bdl-ulpc"/>,--> describes the next upper
layer L3DL protocol to exchange BGP parameter information.</t>
<t>The following is a ladder-style diagram of the L3ND protocol <t>The following is a ladder-style diagram of the L3ND protocol
exchanges:</t> exchanges:</t>
@ -385,6 +325,7 @@
|----------------------------&gt;| |----------------------------&gt;|
</artwork> </artwork>
</figure> </figure>
</section> </section>
</section> </section>
@ -458,37 +399,32 @@ Flags (bit):
<t>The Payload Length is 24 to cover the Flags and Port fields.</t> <t>The Payload Length is 24 to cover the Flags and Port fields.</t>
<t>The Port is the TCP Port Number (TBD3) on which the HELLO sender <t>The Port is the TCP Port Number (default is TBD3) on which the
MUST have a waiting TLS/TCP (as specified in Flags) server HELLO sender MUST have a waiting TLS/TCP (as specified in Flags)
listening. Though the IANA assigned well-known port SHOULD be used, server listening. Though the IANA assigned well-known port SHOULD
this field allows configuration of alternate ports.</t> be used, this field allows configuration of alternate ports.</t>
<t>The HELLO PDU is unique in that it is encapsulated in a multicast
UDP packet. It offers TLS/TCP service to peers on a link. See
<xref target="dhello"/> for why multicast is used.</t>
<t>The HELLO PDU is an IPv4 or IPv6 UDP PDU sent to a link-local
multicast address. It solicits a unicast TLS/TCP open request(s) of
the same AFI from other devices on the link.</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).</t> 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>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>
<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
peer'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 to participate in L3ND sessions and repeat HELLOs at
a configured interval, with a default of 60 seconds.</t> a configured interval, with a default of 60 seconds.</t>
<!--
<t>If a constrained Nearest Bridge destination address has been
configured for a point-to-point interface, see above, then the HELLO
SHOULD NOT be repeated once a session has been created by an
exchange of OPENs.</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
interval, with a default of 60 seconds. This allows discovery by interval, with a default of 60 seconds. This allows discovery by
@ -496,10 +432,6 @@ Flags (bit):
the operator should be aware of the trade-off between timer tuning the operator should be aware of the trade-off between timer tuning
and network noise and adjust the inter-HELLO timer accordingly.</t> and network noise and adjust the inter-HELLO timer accordingly.</t>
<t>The source IP address of the HELLO is the address offering
TLS/TCP service, and responses MUST be unicast TLS/TCP client
session open requests to it using the same AFI.</t>
<t>By default, GTSM, <xref target="RFC5082"/>, SHOULD be enabled to <t>By default, GTSM, <xref target="RFC5082"/>, SHOULD be enabled to
test that a received HELLO MUST be on the local link. It MAY be test that a received HELLO MUST be on the local link. It MAY be
disabled by configuration. GTSM check failures SHOULD be logged, disabled by configuration. GTSM check failures SHOULD be logged,
@ -509,14 +441,9 @@ Flags (bit):
each unique source IP address. L3ND treats each adjacency as a each unique source IP address. L3ND treats each adjacency as a
separate logical link.</t> separate logical link.</t>
<t>When a HELLO is received from a source IP address with which
there is no established L3ND session, the receiver SHOULD respond by
sending a TLS/TCP client session open request to the source IP
address of the HELLO to establish an L3ND TLS/TCP session.</t>
<t>To ameliorate possible load spikes during bootstrap or event <t>To ameliorate possible load spikes during bootstrap or event
recovery, there SHOULD be a jittered delay between receipt of a recovery, there SHOULD be a jittered delay between receipt of a
HELLO and TLS/TCP openb. The default delay range SHOULD be zero to HELLO and TLS/TCP open. The default delay range SHOULD be zero to
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
@ -530,7 +457,7 @@ Flags (bit):
<section anchor="tcp" title="TCP Set-Up"> <section anchor="tcp" title="TCP Set-Up">
<t>If the receiver of a HELLO does not agree with the sender's <t>If the receiver of a HELLO does not agree with the sender's
choice of TCP/TLS or does not agree with the verification choice, choice of TLS/TCP or does not agree with the verification choice,
Self-Signed or CA-based, the receiver SHOULD respond with a HELLO Self-Signed or CA-based, the receiver SHOULD respond with a HELLO
specifying its preferences.</t> specifying its preferences.</t>
@ -553,16 +480,16 @@ Flags (bit):
<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 accptable
HELLO, the TCP/TLS 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 negotiated. If TLS, the client chooses either a self-signed
certificate or one configured from the operational CA trusted by certificate or one configured from the operational CA trusted by
both parties, as negotiated in the HELLO exchange.</t> both parties, as negotiated in the HELLO exchange.</t>
<t>If the TLS/TCP session is established, and the link is configured <t>Once the TLS/TCP session is established, if the link is
as point to point, the client side SHOULD stop listening on any port configured as point to point, the client side SHOULD stop listening
for which it has sent a HELLO. The server side SHOULD stop sending on any port for which it has sent a HELLO. The server side SHOULD
HELLOs.</t> 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.</t>
@ -763,12 +690,12 @@ Flags (bit):
<section anchor="afisafi" title="The Encapsulations"> <section anchor="afisafi" title="The Encapsulations">
<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 TCP/TLS 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 L3 interface encapsulations, L3 addresses, and L2.5
labels.</t> labels.</t>
<t>Encapsulations of any AFI/SAFI may be exchanged over a TCP/TLS <t>Encapsulations of any AFI/SAFI may be exchanged over a TLS/TCP
session irrespective of the AFI/SAFI of the session transport.</t> session irrespective of the AFI/SAFI of the session transport.</t>
<t>The Encapsulation types the peers exchange may be IPv4 (<xref <t>The Encapsulation types the peers exchange may be IPv4 (<xref
@ -852,7 +779,7 @@ Flags (bit):
SHOULD be restarted.</t> SHOULD be restarted.</t>
<t>If the link is broken below layer-3, retransmission MAY BE <t>If the link is broken below layer-3, retransmission MAY BE
retried if data have not changed in the interim and the TCP/TLS retried if data have not changed in the interim and the TLS/TCP
session is still alive.</t> session is still alive.</t>
</section> </section>