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

just a clean-up pass, getting octet counts in etc.

Browse source
This commit is contained in:
Randy Bush 2022-03-07 03:44:12 -08:00
parent 861cdba4e1
commit e5b117c6cd
1 changed files with 56 additions and 66 deletions
Download patch file Download diff file Expand all files Collapse all files

122
draft-ymbk-idr-l3nd.xml
View file

@ -719,31 +719,34 @@ Flags (bit):
exchange Layer-3 interface encapsulations, Layer-3 addresses, and Layer-2.5
labels.</t>
<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>Encapsulation data for 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
target="ipv4"/>), IPv6 (<xref target="ipv6"/>), MPLS IPv4 (<xref
target="mpls4"/>), MPLS IPv6 (<xref target="mpls6"/>), and/or
possibly others not defined here.</t>
<t>The sender of an Encapsulation PDU MUST NOT assume that the peer
is capable of the same Encapsulation Type. An ACK (<xref
target="ack"/>) merely acknowledges receipt. Only if both peers
have sent the same Encapsulation Type is it safe for Layer-3
protocols to assume that they are compatible for that type.</t>
<t>The sender of an Encapsulation PDU MUST NOT assume that the
receiver is capable of the same Encapsulation Type. An ACK (<xref
target="ack"/>) with EType of 0 merely acknowledges receipt. Only
if both peers have sent the same Encapsulation Type is it safe for
Layer-3 protocols to assume that they are compatible for that
Encapsulation Type.</t>
<t>A receiver of an encapsulation might recognize an addressing
conflict, such as both ends of the link trying to use the same
address. In this case, the receiver MUST respond with an error
(Error Code 2) ACK. As there may be other usable addresses or
encapsulations, this error might log and continue, letting an upper
layer topology builder deal with what works.</t>
(Error Code 2, Logical Link Addressing Conflict) ACK. As there may
be other usable addresses or encapsulations, this error might log
and continue, letting an upper layer topology builder deal with what
works.</t>
<t>Further, to consider a logical link of a type to formally be
established so that it may be pushed up to upper layer protocols,
the addressing for the type must be compatible, e.g. on the same
IP subnet.</t>
<t>Further, to consider a logical link of a Encapsulation Type to
formally be established so that it may be used by other protocols,
the addressing for the type must be compatible, e.g. on the same IP
subnet.</t>
<section anchor="encaps" title="The Encapsulation PDU Skeleton">
@ -772,35 +775,30 @@ Flags (bit):
<t>An Encapsulation PDU describes zero or more addresses of the
encapsulation type.</t>
<t>The 24-bit Count is the number of Encapsulations in the
Encapsulation list.</t>
<t>The three octet Count is the number of Encapsulations in the
Encapsulation List.</t>
<t>The Serial Number is a monotonically increasing 32-bit value
representing the sender's state in time. It may be an integer, a
timestamp, etc. On session restart (new OPEN), a receiver MAY
send the last received Session Number to tell the sender to only
send newer data.</t>
<t>The Serial Number is a monotonically increasing four octet
value representing the sender's state in time. It may be an
integer, a timestamp, etc. On session restart (new OPEN), a
receiver MAY send the last received Serial Number to request the
sender to only send newer data.</t>
<t>If a sender has multiple links on the same interface, separate
state: data, ACKs, etc. must be kept for each peer session.</t>
<t>Over time, multiple Encapsulation PDUs may be sent for an
interface in a session as configuration changes.</t>
<!--
<t>If the length of an Encapsulation PDU exceeds the Datagram size
limit on media, the PDU is broken into multiple Datagrams. See
<xref target="tlv"/>.</t>
-->
<t>The Receiver MUST acknowledge the Encapsulation PDU with a
Type=3, ACK PDU (<xref target="ack"/>) with the Encapsulation Type
being that of the encapsulation being announced, see <xref
target="ack"/>.</t>
<t>The Receiver MUST acknowledge the Encapsulation PDU with an ACK
PDU (<xref target="ack"/>) with the PDU Type being that of the
type PDU being announced, see <xref target="ack"/>.</t>
<t>If the Sender does not receive an ACK in a configurable
interval (default five seconds), they SHOULD retransmit. After a
user configurable number of failures (default three), the L3ND
session should be considered dead and the HELLO process
SHOULD be restarted.</t>
session should be considered dead, TLS/TCP torn down, and the
HELLO process 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 TLS/TCP
@ -816,8 +814,8 @@ Flags (bit):
<section anchor="eflags" title="Encapsulaion Flags">
<t>The Encapsulation Flags are a sequence of bit fields as
follows:</t>
<t>The one octet Encapsulation Flags field is a sequence of one bit
fields as follows:</t>
<figure>
<artwork>
@ -833,12 +831,9 @@ Flags (bit):
indicates this with the Ann/With Encapsulation Flag, Announce ==
1, Withdraw == 0.</t>
<t>Each Encapsulation interface address in an Encapsulation PDU is
either a new encapsulation be announced (Ann/With == 1) (yes, a la
BGP) or requests one be withdrawn (Ann/With == 0). Adding an
encapsulation which already exists SHOULD raise an
Announce/Withdraw Error (see <xref target="iana-error"/>); the EType
SHOULD be 2, suggesting a session restart (see <xref
<t>Announcing an encapsulation which already exists SHOULD raise
an Announce/Withdraw Error (see <xref target="iana-error"/>); the
EType SHOULD be 2, suggesting a session restart (see <xref
target="ack"/>) so all encapsulations will be resent.</t>
<t>If an interface on a link has multiple addresses for an
@ -889,7 +884,7 @@ Flags (bit):
</artwork>
</figure>
<t>The 24-bit Count is the sum of the number of IPv4
<t>The three octet Count is the sum of the number of IPv4
Encapsulations being announced and/or withdrawn.</t>
</section>
@ -929,7 +924,7 @@ Flags (bit):
</artwork>
</figure>
<t>The 24-bit Count is the sum of the number of IPv6
<t>The three octet Count is the sum of the number of IPv6
Encapsulations being announced and/or withdrawn.</t>
</section>
@ -957,8 +952,8 @@ Flags (bit):
</artwork>
</figure>
<t>A Label Count of zero is an implicit withdraw of all labels for
that prefix on that interface.</t>
<t>A one octet Label Count of zero is an implicit withdraw of all
labels for that prefix on that interface.</t>
<t>The bottom of the stack flag, S, MUST be set on one and only
one label. Should this not be the case, the receiver of the
@ -999,7 +994,7 @@ Flags (bit):
</artwork>
</figure>
<t>The 24-bit Count is the sum of the number of MPLSv4
<t>The three octet Count is the sum of the number of MPLSv4
Encapsulation being announced and/or withdrawn.</t>
</section>
@ -1041,7 +1036,7 @@ Flags (bit):
</artwork>
</figure>
<t>The 24-bit Count is the sum of the number of MPLSv6
<t>The three octet Count is the sum of the number of MPLSv6
Encapsulations being announced and/or withdrawn.</t>
</section>
@ -1071,8 +1066,8 @@ Flags (bit):
<t>Vendors or enterprises may define TLVs beyond the scope of L3ND
standards. This is done using a Private Enterprise Number <xref
target="IANA-PEN"/> followed by Enterprise Data in a format
defined for that Enterprise Number and Ent Type.</t>
target="IANA-PEN"/> followed by Enterprise Data in a format defined
for that three octet Enterprise Number and one octet Ent Type.</t>
<t>Ent Type allows a Vendor PDU to be sub-typed in the event that
the vendor/enterprise needs multiple PDU types.</t>
@ -1090,27 +1085,27 @@ Flags (bit):
<section anchor="dhello" title="HELLO Discussion">
<t>A device may send IP packets an Layer-3 interface which
<t>A device may send IP packets over a Layer-3 interface which
transmits data over a single Layer-2 interface or multiple Layer-2
interfaces. Packets sourced by one Layer-3 IP interface over
multiple Layer-2 should consider that an Layer-3 interface with
multiple Layer-2 should consider that a Layer-3 interface with
multiple Layer-2 interfaces could have many devices which might
come at various times, therefore the configured HELLO PDU
retransmit time SHOULD be set to a non-zero value, and periodic
HELLOs should continue. Packets transmitted on a single Layer-2
interface on a point-to-point (p2p) connection, MAY set the
configuration value to zero, so once a TLS/TCP session is up,
configuration value to zero, so when a TLS/TCP session is up,
HELLOs are no longer desirable.</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 Layer-3 interface, I, on an L3ND 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, L3ND MUST continue to send HELLOs as long as they are
turned up.</t>
a switch, may be used to forward packets from multiple devices to
one Layer-3 interface, I, on an L3ND 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,
L3ND MUST continue to send HELLOs as long as they are turned
up.</t>
</section>
@ -1133,12 +1128,7 @@ Flags (bit):
<t>An implementation SHOULD provide the ability to configure each
logical interface as L3ND speaking or not.</t>
<!--
<t>An implementation SHOULD provide the ability to configure whether
HELLOs on an L3ND enabled interface send Nearest Bridge or the MAC
which is propagated by switches from that interface; see <xref
target="hello"/>.</t>
-->
<t>An implementation SHOULD provide the ability to distribute one or
more loopback addresses or interfaces into L3ND on an external L3ND
speaking interface.</t>
@ -1161,7 +1151,7 @@ Flags (bit):
<section anchor="security" title="Security Considerations">
<t>For TLS, version 1.1 or later MUST be used.</t>
<t>For TLS, version 1.1 or higher MUST be used.</t>
<t>The protocol as is MUST NOT be used outside a datacenter or
similarly closed environment without using TLS encapsulation which