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>
<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
exchange the data needed for bootstrapping BGP-based peering. Once
IP connectivity has been leveraged to get layer-3 addressability and
forwarding capabilities, normal IP forwarding and routing can take
over.</t>
links in a datacenter Clos (<xref target="Clos1"/>) 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
routing can take over.</t>
<t>L3ND might be found to be more widely applicable to a range of
routing and similar protocols which need Layer-3 neighbor
discovery.</t>
<t>L3ND might be found to be widely applicable to a range of routing
and similar protocols which need Layer-3 neighbor discovery.</t>
</section>
@ -205,88 +204,25 @@
</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">
<t>Two devices discover each other and their respective IP
identities by one sending a Multicast UDP HELLO PDU (<xref
target="hello"/>), and an other responds by attempting a TLS or raw
TCP connection. 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
<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>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>
<t>A device receivinga HELLO attempts to negotiate and establish a
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
<t>Given the TLS/TCP session, OPEN PDUs (<xref target="open"/>) are
exchanged, the Encapsulations (<xref target="afisafi"/>) configured
on an end point may be announced and modified. Note that these are
only the encapsulation and addresses configured on the announcing
@ -319,6 +255,10 @@
session running over one AFI MAY carry encapsulations etc. of
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
exchanges:</t>
@ -385,6 +325,7 @@
|----------------------------&gt;|
</artwork>
</figure>
</section>
</section>
@ -458,37 +399,32 @@ Flags (bit):
<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
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 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 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
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
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
HELLO if it is to participate in L3ND sessions and repeat HELLOs at
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
propagated by switches, the HELLO SHOULD be repeated at a configured
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
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
test that a received HELLO MUST be on the local link. It MAY be
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
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
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>
<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">
<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
specifying its preferences.</t>
@ -553,16 +480,16 @@ Flags (bit):
<t> The server, the sender of the HELLO, listens on the advertised
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
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>
<t>If the TLS/TCP session is established, and the link 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>
<t>Once the TLS/TCP session is established, if the link 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>
<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>
@ -763,12 +690,12 @@ Flags (bit):
<section anchor="afisafi" title="The Encapsulations">
<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
exchange L3 interface encapsulations, L3 addresses, and L2.5
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>
<t>The Encapsulation types the peers exchange may be IPv4 (<xref
@ -852,7 +779,7 @@ Flags (bit):
SHOULD be restarted.</t>
<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>
</section>