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