diff --git a/draft-ymbk-idr-l3-discovery.xml b/draft-ymbk-idr-l3-discovery.xml index b551148..138c0c2 100644 --- a/draft-ymbk-idr-l3-discovery.xml +++ b/draft-ymbk-idr-l3-discovery.xml @@ -266,17 +266,16 @@ HELLOs forever, see . Once a new device is recognized, both devices attempt to - negotiate and establish a TCP session by sending unicast OPEN PDUs - () to the source MAC addresses (plus VIDs if - VLANs) of the received HELLOs. Once a session is established - through the OPEN exchange, 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 interface; though a device's loopback - and overlay interface(s) may also be announced. When two devices on - a link have compatible Encapsulations and addresses, i.e. the same - AFI/SAFI and the same subnet, the link is announced via the BGP-LS - API. + negotiate and establish a TCP session by sending unicast TCP + OPEN_REQ and OPEN_RESP to the source IP addresses of the received + HELLO/HOWDY. Once a TCP session is established, STARTTLS is used to + try and up-level the TCP session to TLS. Given the TCP/TLS 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 interface; though a + device's loopback and overlay interface(s) may also be + announced.
@@ -421,9 +420,7 @@ target="iana-sigtype"/>. Type 0, a null signature, is defined in this document. - Sig Type 0 indicates a null Signature. For a trivial PDU such - as KEEPALIVE, the underlying Datagram checksum may be sufficient - for integrity, though it lacks authenticity. + Sig Type 0 indicates a null Signature. Other Sig Types may be defined in other documents, cf. . @@ -445,42 +442,34 @@ The HELLO PDU is unique in that it is encapsulated in a multicast UDP PDU. It solicits HOWDY, , response(s) from other peers on the link. See for why - multicast is used. The destination Multicast Addressees to be - used MUST be one of the following, see clause 9.2.2 of xref - IEEE802-2014: + multicast is used. - + The HELLO PDU is an IPv4 or IPv6 UDP PDU sent to a link-local + multicast address. It solicits unicast HOWDY response(s) from other + devices on the link. - Nearest Bridge = Propagation - constrained to a single physical link; stopped by all types of - bridges (including MPRs (media converters)). This SHOULD be used - when the link is known to be a simple point to point link. - - When a switch receives a frame with - a multicast destination MAC it does not recognize, it forwards to - all ports. This destination MAC SHOULD be sent when the interface - is known to be connected to a switch. See . This SHOULD be used when the link may be a - multi-point link. - - - - All L3BND PDUs than HELLO AND HOWDY sent via TCP, as the + 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). + + All L3BND PDUs than HELLO AND HOWDY are sent via TCP, as the peer's destination IP address is known after the HELLO/HOWDY exchange. When an interface is turned up on a device, it SHOULD issue a HELLO if it is to participate in L3BND sessions. + If the configured 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 new devices - which come up on the layer-2 mesh. In this multi-link scenario, the + which come up on the mesh. In this multi-link scenario, the operator should be aware of the trade-off between timer tuning and network noise and adjust the inter-HELLO timer accordingly. @@ -564,9 +553,9 @@ As the HELLO/HOWDY exchange was extremely sparse, the peers could not yet have agreed on security data for authentication. This will be done in the OPEN exchange. If the OPEN exchange agrees on an - authorization mechansim and keys, then this TCP session MUST be - closed, and a new TLS session with the newly agreed credentials MUST - opened, see . + authorization mechansim and credentials, then this TCP session MUST + be closed, and a new TLS session with the newly agreed credentials + MUST opened, see . If the TCP open fails, then this SHOULD be logged and the parties MUST go back to the initial state and try HELLO/HOWDY. @@ -685,10 +674,10 @@ signing auth data by the sender. Once two logical link endpoints know each other, and have ACKed - each other's OPEN PDUs, Layer-2 KEEPALIVEs (see ) MAY be started to ensure Layer-2 liveness and + each other's OPEN PDUs, Layer-2 KEEPALIVEs (see xref + target="keepalive") MAY be started to ensure Layer-2 liveness and keep the session semantics alive. The timing and acceptable drop of - KEEPALIVE PDUs are discussed in . + KEEPALIVE PDUs are discussed in xref target="keepalive". If a sender of OPEN does not receive an ACK of the OPEN PDU, then they MUST resend the same OPEN PDU, with the same Nonce. Resending @@ -1182,121 +1171,6 @@
-
- - - -
- - 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 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| PDU Type = 2 | Payload Length = 0 ~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~ | Sig Type = 0 | Signature Length = 0 | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- - L3BND devices SHOULD beacon frequent Layer-2 KEEPALIVE PDUs to - ensure session continuity. The inter-KEEPALIVE interval is - configurable, with a default of ten seconds. A receiver may choose - to ignore KEEPALIVE PDUs. - - An operational deployment MUST BE configured whether to use - KEEPALIVEs or not, either globally, or as finely as to per-link - granularity. Disagreement MAY result in repeated session failure - and reestablishment. - - KEEPALIVEs SHOULD be beaconed at a configured frequency. One per - second is the default. Layer-3 liveness, such as BFD, may be more - (or less) aggressive. - - When a sender transmits a PDU which is not a KEEPALIVE, the - sender SHOULD reset the KEEPALIVE timer. I.e. sending any PDU acts - as a keepalive. Once the last fragment has been sent, the - KEEPALIVE timer SHOULD be restarted. Do not wait for the ACK. - - If a KEEPALIVE or other PDUs have not been received from a peer - with which a receiver has an open session for a configurable time - (default 30 seconds), the link SHOULD be presumed down. The devices - MAY keep configuration state and restore it without retransmission - if no data have changed. Otherwise, a new session SHOULD be - established and new Encapsulation PDUs exchanged. - -
- -
- - Layer-2 liveness may be continuously tested by KEEPALIVE PDUs, - see . As layer-2.5 or layer-3 - connectivity could still break, liveness above layer-2 MAY be - frequently tested using BFD () or a similar - technique. - - This protocol assumes that one or more Encapsulation addresses - may be used to ping, run BFD, or whatever the operator - configures. - -
- -
- - Thus far, a one-hop point-to-point logical link discovery - protocol has been defined. - - The devices know their unique LLEIs and know the unique peer - LLEIs and Encapsulations on each logical link interface. - - Full topology discovery is not appropriate at the L3BND layer, so - Dijkstra a la IS-IS etc. is assumed to be done by higher level - protocols such as BGP-SPF. - - Therefore the LLEIs, link Encapsulations, and state changes are - pushed North via a small subset of the BGP-LS API. The upper layer - routing protocol(s), e.g. BGP-SPF, learn and maintain the topology, - run Dijkstra, and build the routing database(s). - - For example, if a neighbor's IPv4 Encapsulation address changes, - the devices seeing the change push that change Northbound. - -
- - BGP-LS defines BGP-like Datagrams - describing logical link state (links, nodes, link prefixes, and - many other things), and a new BGP path attribute providing - Northbound transport, all of which can be ingested by upper layer - protocols such as BGP-SPF; see Section 4 of . - - For IPv4 links, TLVs 259 and 260 are used. For IPv6 links, - TLVs 261 and 262. If there are multiple addresses on a link, - multiple TLV pairs are pushed North, having the same ID pairs. - -
- -
- - The Northbound protocol needs a few minor extensions to BGP-LS. - Luckily, others have needed the same extensions. - - Similarly to BGP-SPF, the BGP protocol is used in the - Protocol-ID field specified in table 1 of . The local and - remote node descriptors for all NLRI are the IDs described in - . This is equivalent to an adjacency SID or - a node SID if the address is a loopback address. - - Label Sub-TLVs from Section 2.1.1, - are used to associate one or more MPLS Labels with a link. - -
- -
-
This section explores some trade-offs taken and some @@ -1304,28 +1178,27 @@
+ A device may send IP packets an L3 interface which transmit + data over a single Layer-2 (L2) interface or multiple L2 + interfaces. Packets sourced by one L3 IP interface over multiple + L2 should consider that an L3 interface with multiple Layer-2 + interfaces may come at various times, therefore the HELLO PDU + configuration time SHOULD be set to a non-zero value. Packets + transmitted on a single L2 interface on a point-to-point (p2p) + connection, MAY set the configuration value to zero. + A device with multiple Layer-2 interfaces, traditionally called a switch, may be used to forward frames and therefore packets from - multiple devices to one logical interface (LLEI), I, on an L3BND - speaking device. Interface I could discover a peer J across the - switch. Later, a prospective peer K could come up across the - switch. If I was not still sending and listening for HELLOs, the - potential peering with K could not be discovered. Therefore, on - multi-link interfaces, L3BND MUST continue to send HELLOs as long - as they are turned up. + multiple devices to one Layer-3 interface, I, on an L3BND speaking + device. Interface I could discover a peer J across the switch. + Later, a prospective peer K could come up across the switch. If I + was not still sending and listening for HELLOs, the potential + peering with K could not be discovered. Therefore, on multi-link + interfaces, L3BND MUST continue to send HELLOs as long as they are + turned up.
-
- - Both HELLO and KEEPALIVE are periodic. KEEPALIVE might be - eliminated in favor of keeping only HELLOs. But KEEPALIVEs are - unicast, and thus less noisy on the network, especially if HELLO - is configured to transit layer-2-only switches, see . - -
-
@@ -1403,13 +1276,23 @@ For these reasons, the OPEN PDU's authentication data exchange SHOULD be used. - If the KEEPALIVE PDU is not signed (as suggested in ) to save computation, then a MITM could fake a - session being alive. -
-
+
+ +
+ + IANA is requested to assignment one address (TBD1) for + L3DL-L3-LL from the IPv4 Multicast Address Space Registry from + the Local Network Control Block (224.0.0.0 - 224.0.0.255 + (224.0.0/24)). + + IANA is requested to assign one address (TBD2) for L3DL-L3-LL + from the IPv6 Multicast Address Space Registry in the the IPv6 + Link-Local Scope Multicast address (TBD:2). + +
+
@@ -1425,7 +1308,7 @@ ---- ------------------- 0 HELLO 1 OPEN - 2 KEEPALIVE + 2 reserved 3 ACK 4 IPv4 Announcement 5 IPv6 Announcement @@ -1533,14 +1416,10 @@ - - - -