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

sue's hacks and some progress on structural change

Browse source
This commit is contained in:
Randy Bush 2022-02-02 11:41:31 -08:00
parent 957f614e51
commit ea3c97ed81
1 changed files with 61 additions and 182 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -266,17 +266,16 @@
HELLOs forever, see <xref target="dhello"/>.</t> HELLOs forever, see <xref target="dhello"/>.</t>
<t>Once a new device is recognized, both devices attempt to <t>Once a new device is recognized, both devices attempt to
negotiate and establish a TCP session by sending unicast OPEN PDUs negotiate and establish a TCP session by sending unicast TCP
(<xref target="open"/>) to the source MAC addresses (plus VIDs if OPEN_REQ and OPEN_RESP to the source IP addresses of the received
VLANs) of the received HELLOs. Once a session is established HELLO/HOWDY. Once a TCP session is established, STARTTLS is used to
through the OPEN exchange, the Encapsulations (<xref try and up-level the TCP session to TLS. Given the TCP/TLS session,
target="afisafi"/>) configured on an end point may be announced and OPEN PDUs <xref target="open"/> are exchanged, the Encapsulations
modified. Note that these are only the encapsulation and addresses (<xref target="afisafi"/>) configured on an end point may be
configured on the announcing interface; though a device's loopback announced and modified. Note that these are only the encapsulation
and overlay interface(s) may also be announced. When two devices on and addresses configured on the announcing interface; though a
a link have compatible Encapsulations and addresses, i.e. the same device's loopback and overlay interface(s) may also be
AFI/SAFI and the same subnet, the link is announced via the BGP-LS announced.</t>
API.</t>
<section anchor="ladder" title="L3BND Ladder Diagram"> <section anchor="ladder" title="L3BND Ladder Diagram">
@ -421,9 +420,7 @@
target="iana-sigtype"/>. Type 0, a null signature, is defined in target="iana-sigtype"/>. Type 0, a null signature, is defined in
this document.</t> this document.</t>
<t>Sig Type 0 indicates a null Signature. For a trivial PDU such <t>Sig Type 0 indicates a null Signature.</t>
as KEEPALIVE, the underlying Datagram checksum may be sufficient
for integrity, though it lacks authenticity.</t>
<t>Other Sig Types may be defined in other documents, cf. <xref <t>Other Sig Types may be defined in other documents, cf. <xref
target="I-D.ietf-lsvr-l3dl-signing"/>.</t> target="I-D.ietf-lsvr-l3dl-signing"/>.</t>
@ -445,42 +442,34 @@
<t>The HELLO PDU is unique in that it is encapsulated in a multicast <t>The HELLO PDU is unique in that it is encapsulated in a multicast
UDP PDU. It solicits HOWDY, <xref target="howdy"/>, response(s) UDP PDU. It solicits HOWDY, <xref target="howdy"/>, response(s)
from other peers on the link. See <xref target="dhello"/> for why from other peers on the link. See <xref target="dhello"/> for why
multicast is used. The destination Multicast Addressees to be multicast is used.</t>
used MUST be one of the following, see clause 9.2.2 of xref
IEEE802-2014: <list style="hanging"> <?rfc subcompact="yes"?>
<!-- HACK HACK HACK --> <t>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.</t>
<t hangText="01-80-C2-00-00-0E:">Nearest Bridge = Propagation <t>The IPv4 UDP packets are sent to the IPv4 link local multicast
constrained to a single physical link; stopped by all types of address (TBD1) and the IPv6 UDP packets are sent to an IPv6 link
bridges (including MPRs (media converters)). This SHOULD be used Local multicast address (TBD2).</t>
when the link is known to be a simple point to point link.</t>
<t>All L3BND PDUs than HELLO AND HOWDY are sent via TCP, as the
<t hangText="To Be Assigned:"> 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 <xref
target="ieee"/>. This SHOULD be used when the link may be a
multi-point link.</t>
<?rfc subcompact="no"?></list></t>
<t>All L3BND PDUs than HELLO AND HOWDY sent via TCP, as the
peer's destination IP address is known after the HELLO/HOWDY peer's destination IP address is known after the HELLO/HOWDY
exchange.</t> exchange.</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 L3BND sessions.</t> HELLO if it is to participate in L3BND sessions.</t>
<!--
<t>If a constrained Nearest Bridge destination address has been <t>If a constrained Nearest Bridge destination address has been
configured for a point-to-point interface, see above, then the HELLO configured for a point-to-point interface, see above, then the HELLO
SHOULD NOT be repeated once a session has been created by an SHOULD NOT be repeated once a session has been created by an
exchange of OPENs.</t> exchange of OPENs.</t>
-->
<t>If the configured destination address is one that is propagated <t>If the configured destination address is one that is propagated
by switches, the HELLO SHOULD be repeated at a configured interval, by switches, the HELLO SHOULD be repeated at a configured interval,
with a default of 60 seconds. This allows discovery by new devices 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 operator should be aware of the trade-off between timer tuning and
network noise and adjust the inter-HELLO timer accordingly.</t> network noise and adjust the inter-HELLO timer accordingly.</t>
@ -564,9 +553,9 @@
<t>As the HELLO/HOWDY exchange was extremely sparse, the peers could <t>As the HELLO/HOWDY exchange was extremely sparse, the peers could
not yet have agreed on security data for authentication. This will not yet have agreed on security data for authentication. This will
be done in the OPEN exchange. If the OPEN exchange agrees on an be done in the OPEN exchange. If the OPEN exchange agrees on an
authorization mechansim and keys, then this TCP session MUST be authorization mechansim and credentials, then this TCP session MUST
closed, and a new TLS session with the newly agreed credentials MUST be closed, and a new TLS session with the newly agreed credentials
opened, see <xref target="tls"/>.</t> MUST opened, see <xref target="tls"/>.</t>
<t>If the TCP open fails, then this SHOULD be logged and the parties <t>If the TCP open fails, then this SHOULD be logged and the parties
MUST go back to the initial state and try HELLO/HOWDY.</t> MUST go back to the initial state and try HELLO/HOWDY.</t>
@ -685,10 +674,10 @@
signing auth data by the sender.</t> signing auth data by the sender.</t>
<t>Once two logical link endpoints know each other, and have ACKed <t>Once two logical link endpoints know each other, and have ACKed
each other's OPEN PDUs, Layer-2 KEEPALIVEs (see <xref each other's OPEN PDUs, Layer-2 KEEPALIVEs (see xref
target="keepalive"/>) MAY be started to ensure Layer-2 liveness and target="keepalive") MAY be started to ensure Layer-2 liveness and
keep the session semantics alive. The timing and acceptable drop of keep the session semantics alive. The timing and acceptable drop of
KEEPALIVE PDUs are discussed in <xref target="keepalive"/>.</t> KEEPALIVE PDUs are discussed in xref target="keepalive".</t>
<t>If a sender of OPEN does not receive an ACK of the OPEN PDU, then <t>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 they MUST resend the same OPEN PDU, with the same Nonce. Resending
@ -1182,121 +1171,6 @@
</section> </section>
<section anchor="keepalive" title="KEEPALIVE - Layer-2 Liveness">
<!--
protocol "PDU Type = 2:8,Payload Length = 0:32,Sig Type = 0:8,Signature Length = 0:16"
-->
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="l3liveness" title="Layers-2.5 and 3 Liveness">
<t>Layer-2 liveness may be continuously tested by KEEPALIVE PDUs,
see <xref target="keepalive"/>. As layer-2.5 or layer-3
connectivity could still break, liveness above layer-2 MAY be
frequently tested using BFD (<xref target="RFC5880"/>) or a similar
technique.</t>
<t>This protocol assumes that one or more Encapsulation addresses
may be used to ping, run BFD, or whatever the operator
configures.</t>
</section>
<section anchor="northsouth" title="The North/South Protocol">
<t>Thus far, a one-hop point-to-point logical link discovery
protocol has been defined.</t>
<t>The devices know their unique LLEIs and know the unique peer
LLEIs and Encapsulations on each logical link interface.</t>
<t>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.</t>
<t>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).</t>
<t>For example, if a neighbor's IPv4 Encapsulation address changes,
the devices seeing the change push that change Northbound.</t>
<section anchor="ls" title="Use BGP-LS as Much as Possible">
<t>BGP-LS <xref target="RFC7752"/> 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 <xref
target="I-D.ietf-lsvr-bgp-spf"/>.</t>
<t>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.</t>
</section>
<section anchor="ls-ext" title="Extensions to BGP-LS">
<t>The Northbound protocol needs a few minor extensions to BGP-LS.
Luckily, others have needed the same extensions.</t>
<t>Similarly to BGP-SPF, the BGP protocol is used in the
Protocol-ID field specified in table 1 of <xref
target="I-D.ietf-idr-bgpls-segment-routing-epe"/>. The local and
remote node descriptors for all NLRI are the IDs described in
<xref target="open"/>. This is equivalent to an adjacency SID or
a node SID if the address is a loopback address.</t>
<t>Label Sub-TLVs from <xref
target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/> Section 2.1.1,
are used to associate one or more MPLS Labels with a link.</t>
</section>
</section>
<section anchor="discuss" title="Discussion"> <section anchor="discuss" title="Discussion">
<t>This section explores some trade-offs taken and some <t>This section explores some trade-offs taken and some
@ -1304,28 +1178,27 @@
<section anchor="dhello" title="HELLO Discussion"> <section anchor="dhello" title="HELLO Discussion">
<t>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.</t>
<t>A device with multiple Layer-2 interfaces, traditionally called <t>A device with multiple Layer-2 interfaces, traditionally called
a switch, may be used to forward frames and therefore packets from a switch, may be used to forward frames and therefore packets from
multiple devices to one logical interface (LLEI), I, on an L3BND multiple devices to one Layer-3 interface, I, on an L3BND speaking
speaking device. Interface I could discover a peer J across the device. Interface I could discover a peer J across the switch.
switch. Later, a prospective peer K could come up across the Later, a prospective peer K could come up across the switch. If I
switch. If I was not still sending and listening for HELLOs, the was not still sending and listening for HELLOs, the potential
potential peering with K could not be discovered. Therefore, on peering with K could not be discovered. Therefore, on multi-link
multi-link interfaces, L3BND MUST continue to send HELLOs as long interfaces, L3BND MUST continue to send HELLOs as long as they are
as they are turned up.</t> turned up.</t>
</section> </section>
<section anchor="dkeepalive" title="HELLO versus KEEPALIVE">
<t>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 <xref
target="dhello"/>.</t>
</section>
</section> </section>
<section anchor="vlans" title="VLANs/SVIs/Sub-interfaces"> <section anchor="vlans" title="VLANs/SVIs/Sub-interfaces">
@ -1403,13 +1276,23 @@
<t>For these reasons, the OPEN PDU's authentication data exchange <t>For these reasons, the OPEN PDU's authentication data exchange
SHOULD be used.</t> SHOULD be used.</t>
<t>If the KEEPALIVE PDU is not signed (as suggested in <xref
target="tlv"/>) to save computation, then a MITM could fake a
session being alive.</t>
</section> </section>
<section anchor="iana" title="IANA Considerations"> <section anchor="iana" title="IANA Considerations">
<section anchor="iana-l3addr" title="Link Local L3 Addresses">
<t>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)).</t>
<t>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).</t>
</section>
<section anchor="iana-types" title="PDU Types"> <section anchor="iana-types" title="PDU Types">
@ -1425,7 +1308,7 @@
---- ------------------- ---- -------------------
0 HELLO 0 HELLO
1 OPEN 1 OPEN
2 KEEPALIVE 2 reserved
3 ACK 3 ACK
4 IPv4 Announcement 4 IPv4 Announcement
5 IPv6 Announcement 5 IPv6 Announcement
@ -1533,14 +1416,10 @@
<?rfc include="reference.RFC.2119.xml"?> <?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.3032.xml"?> <?rfc include="reference.RFC.3032.xml"?>
<?rfc include="reference.RFC.4271.xml"?> <?rfc include="reference.RFC.4271.xml"?>
<?rfc include="reference.I-D.ietf-lsvr-bgp-spf.xml"?>
<?rfc include="reference.RFC.5226.xml"?> <?rfc include="reference.RFC.5226.xml"?>
<?rfc include="reference.RFC.5880.xml"?> <?rfc include="reference.RFC.5880.xml"?>
<?rfc include="reference.RFC.6286.xml"?> <?rfc include="reference.RFC.6286.xml"?>
<?rfc include="reference.RFC.7752.xml"?>
<?rfc include="reference.RFC.8174.xml"?> <?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.I-D.ietf-idr-bgpls-segment-routing-epe.xml"?>
<?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext.xml"?>
<?rfc include="reference.I-D.ietf-lsvr-l3dl.xml"?> <?rfc include="reference.I-D.ietf-lsvr-l3dl.xml"?>
<?rfc include="reference.I-D.ietf-lsvr-l3dl-signing.xml"?> <?rfc include="reference.I-D.ietf-lsvr-l3dl-signing.xml"?>
<reference anchor="IANA-PEN" target="https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers"> <reference anchor="IANA-PEN" target="https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers">