From 9d78ced03bc69b00b22ab62f68e40ecaa970b094 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Tue, 15 Feb 2022 14:27:21 -0800 Subject: [PATCH] trim much redundancy off front --- draft-ymbk-idr-l3-discovery.xml | 181 ++++++++++---------------------- 1 file changed, 54 insertions(+), 127 deletions(-) diff --git a/draft-ymbk-idr-l3-discovery.xml b/draft-ymbk-idr-l3-discovery.xml index 8880289..5d117a6 100644 --- a/draft-ymbk-idr-l3-discovery.xml +++ b/draft-ymbk-idr-l3-discovery.xml @@ -127,15 +127,14 @@ In this document, the use case for L3ND is for point to point - links in a datacenter Clos ()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. + links in a datacenter 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 + routing can take over. - L3ND might be found to be more widely applicable to a range of - routing and similar protocols which need Layer-3 neighbor - discovery. + L3ND might be found to be widely applicable to a range of routing + and similar protocols which need Layer-3 neighbor discovery. @@ -205,88 +204,25 @@ -
- - - Devices discover each other's IP Addresses on logical links - using Multicast and Unicast UDP - The main body of the protocol runs over TCP, normally with - TLS - Further IP Address reachability may be exchanged - IP Encapsulation data are exchanged - A BGP-like upper layer protocol is assumed to use the - identifiers and encapsulation data to discover and build a - topology database using BGP - - -
- -+-------------------+ +-------------------+ +-------------------+ -| Device | | Device | | Device | -| | | | | | -|+-----------------+| |+-----------------+| |+-----------------+| -|| || || || || || -|| BGP <+---+> BGP <+---+> BGP || -|| || || || || || -|+--------^--------+| |+--------^--------+| |+--------^--------+| -| | | | | | | | | -| | | | | | | | | -|+--------+--------+| |+--------+--------+| |+--------+--------+| -|| Encapsulations || || Encapsulations || || Encapsulations || -|| & Addresses || || & Addresses || || & Addresses || -|+--------^--------+| |+--------^--------+| |+--------^--------+| -| | | | | | | | | -| | | | | | | | | -|+--------v--------+| |+--------v--------+| |+--------v--------+| -|| || || || || || -||Inter-Device PDUs<+---+>Inter-Device PDUs<+---+>Inter-Device PDUs|| -|| || || || || || -|+-----------------+| |+-----------------+| |+-----------------+| -+-------------------+ +-------------------+ +-------------------+ - -
- - 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): - - - 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. - - 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. - - A L3DL extension, - describes the next upper layer L3DL protocol to exchange BGP - parameter information. - - - - The upper layer BGP family routing protocols cross all the - devices, but are not part of these L3ND protocols. - -
-
- Two devices discover each other and their respective IP - identities by one sending a Multicast UDP HELLO PDU (), 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 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. + + 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. + + 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 . - 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 () are + Given the TLS/TCP session, OPEN PDUs () are exchanged, the Encapsulations () 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, + A L3DL extension, describes the next upper + layer L3DL protocol to exchange BGP parameter information. + The following is a ladder-style diagram of the L3ND protocol exchanges: @@ -385,6 +325,7 @@ |---------------------------->| +
@@ -458,37 +399,32 @@ Flags (bit): The Payload Length is 24 to cover the Flags and Port fields. - 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. + 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. - 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 - for why multicast is used. - - 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. - 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). - + Local multicast address (TBD2). See for why + multicast is used. + + The HELLO PDU solicits a unicast TLS/TCP open request(s) of the + same AFI from other devices on the link. + + 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. + All L3ND PDUs other than HELLO are sent via TLS/TCP, as the - peer's destination IP address is known after the HELLO. + server's destination IP address is known after the HELLO. 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. - - 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. - 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. - By default, GTSM, , 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. - 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. - 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. If a HELLO is received from an IP Address with which there is an @@ -530,7 +457,7 @@ Flags (bit):
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. @@ -553,16 +480,16 @@ Flags (bit): 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. - 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. + 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. If the TLS/TCP open fails, then this SHOULD be logged and the parties MUST go back to the initial state and try HELLO. @@ -763,12 +690,12 @@ Flags (bit):
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. - Encapsulations of any AFI/SAFI may be exchanged over a TCP/TLS + Encapsulations of any AFI/SAFI may be exchanged over a TLS/TCP session irrespective of the AFI/SAFI of the session transport. The Encapsulation types the peers exchange may be IPv4 ( 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.