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

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

@ -266,17 +266,16 @@
HELLOs forever, see <xref target="dhello"/>.</t>
<t>Once a new device is recognized, both devices attempt to
negotiate and establish a TCP session by sending unicast OPEN PDUs
(<xref target="open"/>) to the source MAC addresses (plus VIDs if
VLANs) of the received HELLOs. Once a session is established
through the OPEN exchange, 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 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.</t>
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 <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 interface; though a
device's loopback and overlay interface(s) may also be
announced.</t>
<section anchor="ladder" title="L3BND Ladder Diagram">
@ -421,9 +420,7 @@
target="iana-sigtype"/>. Type 0, a null signature, is defined in
this document.</t>
<t>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.</t>
<t>Sig Type 0 indicates a null Signature.</t>
<t>Other Sig Types may be defined in other documents, cf. <xref
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
UDP PDU. It solicits HOWDY, <xref target="howdy"/>, response(s)
from other peers on the link. See <xref target="dhello"/> 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: <list style="hanging"> <?rfc subcompact="yes"?>
multicast is used.</t>
<!-- 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
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.</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>
<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
<t>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.</t>
<t>When an interface is turned up on a device, it SHOULD issue a
HELLO if it is to participate in L3BND sessions.</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 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.</t>
@ -564,9 +553,9 @@
<t>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 <xref target="tls"/>.</t>
authorization mechansim and credentials, then this TCP session MUST
be closed, and a new TLS session with the newly agreed credentials
MUST opened, see <xref target="tls"/>.</t>
<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>
@ -685,10 +674,10 @@
signing auth data by the sender.</t>
<t>Once two logical link endpoints know each other, and have ACKed
each other's OPEN PDUs, Layer-2 KEEPALIVEs (see <xref
target="keepalive"/>) 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 <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
they MUST resend the same OPEN PDU, with the same Nonce. Resending
@ -1182,121 +1171,6 @@
</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">
<t>This section explores some trade-offs taken and some
@ -1304,25 +1178,24 @@
<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
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.</t>
</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>
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.</t>
</section>
@ -1403,14 +1276,24 @@
<t>For these reasons, the OPEN PDU's authentication data exchange
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 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">
<t>This document requests the IANA create a registry for L3BND PDU
@ -1425,7 +1308,7 @@
---- -------------------
0 HELLO
1 OPEN
2 KEEPALIVE
2 reserved
3 ACK
4 IPv4 Announcement
5 IPv6 Announcement
@ -1533,14 +1416,10 @@
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.3032.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.5880.xml"?>
<?rfc include="reference.RFC.6286.xml"?>
<?rfc include="reference.RFC.7752.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-signing.xml"?>
<reference anchor="IANA-PEN" target="https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers">