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

-03 published

Browse source
This commit is contained in:
Randy Bush 2019-11-02 08:39:20 -07:00
parent deed027c06
commit 04d3fd85b3
1 changed files with 79 additions and 72 deletions
Download patch file Download diff file Expand all files Collapse all files

151
draft-ietf-lsvr-l3dl.xml
View file

@ -100,15 +100,16 @@
<t>Layer 3 Discovery and Liveness (L3DL) provides brutally simple <t>Layer 3 Discovery and Liveness (L3DL) provides brutally simple
mechanisms for devices to <list style="symbols"> mechanisms for devices to <list style="symbols">
<t>Discover each other's unique endpoint identification,</t> <t>Discover each other's unique endpoint identification,</t>
<t>Discover mutually supported layer 3 encapsulations, <t>Discover mutually supported layer 3 encapsulations, e.g.
e.g. IP/MPLS,</t> IP/MPLS,</t>
<t>Discover Layer 3 IP and/or MPLS addressing of interfaces of the <t>Discover Layer 3 IP and/or MPLS addressing of interfaces of the
encapsulations,</t> encapsulations,</t>
<t>Present these data, using a very restricted profile of a BGP-LS <t>Present these data, using a very restricted profile of a BGP-LS
<xref target="RFC7752"/> API, to BGP-SPF which computes the <xref target="RFC7752"/> API, to BGP-SPF which computes the
topology and builds routing and forwarding tables,</t> topology and builds routing and forwarding tables,</t>
<t>Enable Layer 3 link liveness such as BFD, and finally</t> <t>Enable Layer 3 link liveness such as BFD,</t>
<t>Provide Layer 2 keep-alive messages for session continuity.</t> <t>Provide Layer 2 keep-alive messages for session continuity, and
finally</t>
<t>Provide for authenticity verification of protocol messages.</t> <t>Provide for authenticity verification of protocol messages.</t>
</list></t> </list></t>
@ -211,7 +212,7 @@
<t><list style="symbols"> <t><list style="symbols">
<t>Devices discover each other on logical links</t> <t>Devices discover each other on logical links</t>
<t>Logical Link Endpoint Identifiers are exchanged</t> <t>Logical Link Endpoint Identifiers (LLEIs) are exchanged</t>
<t>Layer 2 Liveness checks may be started</t> <t>Layer 2 Liveness checks may be started</t>
<t>Encapsulation data are exchanged and IP-Level Liveness checks <t>Encapsulation data are exchanged and IP-Level Liveness checks
enabled</t> enabled</t>
@ -248,14 +249,15 @@
</artwork> </artwork>
</figure> </figure>
<t>There are two protocols, the inter-device per-link layer 3 <t>There are two protocols, the inter-device (left-right in the
discovery and the API to the upper level BGP-like routing prototol: diagram) per-link layer 3 discovery and the API to the upper level
BGP-like routing prototol (up-down in the above diagram):
<list style="symbols"> <list style="symbols">
<t>Inter-device PDUs are used to exchange device and logical link <t>Inter-device PDUs are used to exchange device and logical link
identities and layer 2.5 (MPLS) and 3 identifiers (not payloads), identities and layer 2.5 (MPLS) and 3 identifiers (not payloads),
e.g. device IDs, port identities, VLAN IDs, Encapsulations, and e.g. device IDs, port identities, VLAN IDs, Encapsulations, and IP
IP addresses.</t> addresses.</t>
<t>A Link Layer to BGP API presents these data up the stack to <t>A Link Layer to BGP API presents these data up the stack to
a BGP protocol or an other device-spanning upper layer protocol, a BGP protocol or an other device-spanning upper layer protocol,
@ -276,20 +278,21 @@
<t>Two devices discover each other and their respective identities <t>Two devices discover each other and their respective identities
by sending multicast HELLO PDUs (<xref target="hello"/>). To assure by sending multicast HELLO PDUs (<xref target="hello"/>). To assure
discovery of new devices coming up on a multi-link topology, devices discovery of new devices coming up on a multi-link topology, devices
on such a topology send periodic HELLOs forever, see <xref on such a topology, and only on a multi-link topology, send periodic
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 session by sending unicast OPEN PDUs negotiate and establish a session by sending unicast OPEN PDUs
(<xref target="open"/>) to the source MAC addresses (plus VIDs if (<xref target="open"/>) to the source MAC addresses (plus VIDs if
VLANs)of the received HELLOs. In an established session, the VLANs) of the received HELLOs. Once a session is established
Encapsulations (<xref target="afisafi"/>) configured on an end point through the OPEN exchange, the Encapsulations (<xref
may be announced and modified. Note that these are only the target="afisafi"/>) configured on an end point may be announced and
encapsuation and addresses configured on the announcing interface; modified. Note that these are only the encapsuation and addresses
though a device's loopback and overlay interface(s) may also be configured on the announcing interface; though a device's loopback
announced. When two devices on a link have compatible and overlay interface(s) may also be announced. When two devices on
Encapsulations and addresses, i.e. the same AFI/SAFI and the same a link have compatible Encapsulations and addresses, i.e. the same
subnet, the link is announced via the BGP-LS API.</t> AFI/SAFI and the same subnet, the link is announced via the BGP-LS
API.</t>
<section anchor="ladder" title="L3DL Ladder Diagram"> <section anchor="ladder" title="L3DL Ladder Diagram">
@ -383,9 +386,9 @@
<section anchor="transport" title="Transport Layer"> <section anchor="transport" title="Transport Layer">
<t>L3DL PDUs are carried by a simple transport layer which allows <t>L3DL PDUs are carried by a simple transport layer which allows
PDUs to occupy many Ethernet frames. The L3DL content of an long PDUs to occupy many Ethernet frames. The L3DL content of a
Ethernet frame, exclusive of Ethernet framing data, is referred to single Ethernet frame, exclusive of Ethernet framing data, is
as a Datagram.</t> referred to as a Datagram.</t>
<t>The L3DL Transport Layer encapsulates each Datagram using a <t>The L3DL Transport Layer encapsulates each Datagram using a
common transport header.</t> common transport header.</t>
@ -396,7 +399,7 @@
<t>Should a PDU need to be retransmitted, it MUST BE sent as the <t>Should a PDU need to be retransmitted, it MUST BE sent as the
identical Datagram set as the original transmission. The identical Datagram set as the original transmission. The
Transmission Sequence Number assures the receiver that it is the Transmission Sequence Number informs the receiver that it is the
same PDU.</t> same PDU.</t>
<!-- <!--
@ -446,7 +449,8 @@
<t hangText="Datagram Length:">Total number of octets in the <t hangText="Datagram Length:">Total number of octets in the
Datagram including all payloads and fields. Note that this limits Datagram including all payloads and fields. Note that this limits
a datagram to 2^16 octets.</t> a datagram to 2^16 octets; though Ethernet framing is likely to
impose a smaller limit.</t>
<t hangText="Checksum:">A 32 bit hash over the Datagram to detect <t hangText="Checksum:">A 32 bit hash over the Datagram to detect
bit flips, see <xref target="checksum"/>.</t> bit flips, see <xref target="checksum"/>.</t>
@ -462,8 +466,8 @@
<t>To avoid the need for a receiver to reassemble two PDUs at the <t>To avoid the need for a receiver to reassemble two PDUs at the
same time, a sender MUST NOT send a subsequent PDU when a PDU is same time, a sender MUST NOT send a subsequent PDU when a PDU is
already in flight and not yet acknowledged if it is an ACKed PDU already in flight and not yet acknowledged; assuming it is an ACKed
Type.</t> PDU Type.</t>
</section> </section>
@ -580,9 +584,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>Sig Type 0 indicates a null Signature. For a trivial PDU such <t>Sig Type 0 indicates a null Signature. For a trivial PDU such
as KEEPALIVE, the underlying Datagram checksum may be sufficient as KEEPALIVE, the underlying Datagram checksum may be sufficient
for integrity, though it lacks authentication.</t> for integrity, though it lacks authenticity.</t>
<t>Other Sig Types may be defined in other documents.</t> <t>Other Sig Types may be defined in other documents, cf. <xref
target="I-D.ymbk-lsvr-l3dl-signing"/>.</t>
<t hangText="Signature Length:">The length of the Signature, <t hangText="Signature Length:">The length of the Signature,
possibly including padding, in octets. If Sig Type is 0, possibly including padding, in octets. If Sig Type is 0,
@ -609,7 +614,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
to a single logical link endpoint in the topology.</t> to a single logical link endpoint in the topology.</t>
<t>An L3DL deployment will choose and define an LLEI which suits its <t>An L3DL deployment will choose and define an LLEI which suits its
needs, simple or complex. Two extremes are as follows:</t> needs, simple or complex. Examples of two extremes follow:</t>
<t>A simplistic view of a link between two devices is two ports, <t>A simplistic view of a link between two devices is two ports,
identified by unique MAC addresses, carrying a layer 3 protocol identified by unique MAC addresses, carrying a layer 3 protocol
@ -645,7 +650,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
and switches usually have internal MAC Addresses which can be padded and switches usually have internal MAC Addresses which can be padded
with high order zeros and used if no System ID exists on the device. with high order zeros and used if no System ID exists on the device.
If no unique identifier is burned into a device, the local L3DL If no unique identifier is burned into a device, the local L3DL
configuration SHOULD create and assign a unique one by configuration SHOULD create and assign a unique one, likely by
configuration.</t> configuration.</t>
<t>ifIndex is the SNMP identifier of the (sub-)interface, see <xref <t>ifIndex is the SNMP identifier of the (sub-)interface, see <xref
@ -730,7 +735,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
OPEN PDUs.</t> OPEN PDUs.</t>
<t>If a HELLO is received from a MAC address with which there is an <t>If a HELLO is received from a MAC address with which there is an
established session, it should be dropped.</t> established session, the HELLO should be dropped.</t>
<t>The Payload Length is zero as there is no payload.</t> <t>The Payload Length is zero as there is no payload.</t>
@ -742,7 +747,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<section anchor="open" title="OPEN"> <section anchor="open" title="OPEN">
<t>Each device has learned the other's MAC Address from the HELLO <t>Each device has learned the other's MAC Address from the HELLO
exchange, see <xref target="hello"/>. Therefore the OPEN and exchange, see <xref target="hello"/>. Therefore the OPEN and all
subsequent PDUs MUST BE unicast, as opposed to the HELLO's multicast subsequent PDUs MUST BE unicast, as opposed to the HELLO's multicast
frame.</t> frame.</t>
@ -806,7 +811,7 @@ q-->
<t>The Key is specific to the operational environment. A failure to <t>The Key is specific to the operational environment. A failure to
authenticate is a failure to start the L3DL session, an ERROR PDU authenticate is a failure to start the L3DL session, an ERROR PDU
MUST BE sent (Error Code 2), and HELLOs MUST be restarted.</t> MUST BE sent (Error Code 3), and HELLOs MUST be restarted.</t>
<t>The Serial Number is that of the last received and processed PDU. <t>The Serial Number is that of the last received and processed PDU.
This allows a receiver sending an OPEN to tell the sender that the This allows a receiver sending an OPEN to tell the sender that the
@ -846,7 +851,7 @@ q-->
the Serial Number in the OPEN is zero, then the receiver MUST assume the Serial Number in the OPEN is zero, then the receiver MUST assume
that the sending LLEI or entire device has been reset. All that the sending LLEI or entire device has been reset. All
previously discovered encapsulation data MUST NOT be kept and MUST previously discovered encapsulation data MUST NOT be kept and MUST
be withdrawn via the BGP-LS API and the recipient MUST respond with BE withdrawn via the BGP-LS API and the recipient MUST respond with
a new OPEN.</t> a new OPEN.</t>
</section> </section>
@ -903,10 +908,10 @@ q-->
<?rfc subcompact="no"?> <?rfc subcompact="no"?>
</list></t> </list></t>
<t>The Error Codes, noting protocol failures listed in thi document, <t>The Error Codes, noting protocol failures, are listed in <xref
are listed in <xref target="iana-error"/>. Someone stuck in the target="iana-error"/>. Someone stuck in the 1990s might think the
1990s might think the catenation of EType and Error Code as an echo catenation of EType and Error Code as an echo of 0x1zzz, 0x2zzz,
of 0x1zzz, 0x2zzz, etc. They might be right; or not.</t> etc. They might be right; or not.</t>
<t>The Error Hint, an arbitrary 16 bits, is any additional data the <t>The Error Hint, an arbitrary 16 bits, is any additional data the
sender of the error PDU thinks will help the recipient or the sender of the error PDU thinks will help the recipient or the
@ -935,9 +940,10 @@ q-->
<section anchor="afisafi" title="The Encapsulations"> <section anchor="afisafi" title="The Encapsulations">
<t>Once the devices know each other's LLEIs, know each other's upper <t>Once the devices know each other's LLEIs, know each other's upper
layer identities, have means to ensure link state, etc., the L3DL layer (L2.5 and L3) identities, have means to ensure link state,
session is considered established, and the devices SHOULD exchange etc., the L3DL session is considered established, and the devices
L3 interface encapsulations, L3 addresses, and L2.5 labels.</t> SHOULD exchange L3 interface encapsulations, L3 addresses, and L2.5
labels.</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
@ -953,7 +959,7 @@ q-->
<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 SHOULD respond with an error address. In this case, the receiver SHOULD respond with an error
(Error Code 1) ACK. As there may be other usable addresses or (Error Code 2) ACK. As there may be other usable addresses or
encapsulations, this error might log and continue, letting an upper encapsulations, this error might log and continue, letting an upper
layer topology builder deal with what works.</t> layer topology builder deal with what works.</t>
@ -1027,9 +1033,11 @@ q-->
if data have not changed in the interim.</t> if data have not changed in the interim.</t>
</section> </section>
<section anchor="eflags" title="Encapsulaion Flags"> <section anchor="eflags" title="Encapsulaion Flags">
<t>The Encapsulation Flags are a sequence of bit fields as
follows:</t>
<figure> <figure>
<artwork> <artwork>
0 1 2 3 4 ... 7 0 1 2 3 4 ... 7
@ -1053,9 +1061,8 @@ q-->
target="ack"/> so all encapsulations will be resent.</t> target="ack"/> so all encapsulations will be resent.</t>
<t>If an LLEI has multiple addresses for an encapsulation type, <t>If an LLEI has multiple addresses for an encapsulation type,
one and only one address SHOULD be configured to be marked as one and only one address MAY be marked as primary (Primary Flag ==
primary (Primary Flag == 1). Only one address on an interface MAY 1) for that Encapsulation Type.</t>
be marked as primary for a particular encapsulation type.</t>
<t>An Encapsulation interface address in an Encapsulation PDU MAY <t>An Encapsulation interface address in an Encapsulation PDU MAY
be marked as a loopback, in which case the Loopback bit is set. be marked as a loopback, in which case the Loopback bit is set.
@ -1103,8 +1110,8 @@ q-->
</artwork> </artwork>
</figure> </figure>
<t>The 24-bit Count is the number of IPv4 Encapsulations being <t>The 24-bit Count is the sum of the number of IPv4
announced and/or withdrawn.</t> Encapsulations being announced and/or withdrawn.</t>
</section> </section>
@ -1145,8 +1152,8 @@ q-->
</artwork> </artwork>
</figure> </figure>
<t>The 24-bit Count is the number of IPv6 Encapsulations being <t>The 24-bit Count is the sum of the number of IPv6
announced and/or withdrawn.</t> Encapsulations being announced and/or withdrawn.</t>
</section> </section>
@ -1212,15 +1219,15 @@ q-->
</artwork> </artwork>
</figure> </figure>
<t>The 24-bit Count is the number of MPLSv4 Encapsulation being <t>The 24-bit Count is the sum of the number of MPLSv4
announced and/or withdrawns.</t> Encapsulation being announced and/or withdrawns.</t>
</section> </section>
<section anchor="mpls6" title="MPLS IPv6 Encapsulation"> <section anchor="mpls6" title="MPLS IPv6 Encapsulation">
<t>The MPLS IPv4 Encapsulation describes a logical link's ability <t>The MPLS IPv6 Encapsulation describes a logical link's ability
to exchange labeled IPv4 packets on one or more subnets. It does to exchange labeled IPv6 packets on one or more subnets. It does
so by stating the interface's addresses, the corresponding prefix so by stating the interface's addresses, the corresponding prefix
lengths, and the corresponding labels which will be accepted for lengths, and the corresponding labels which will be accepted for
each address.</t> each address.</t>
@ -1256,8 +1263,8 @@ q-->
</artwork> </artwork>
</figure> </figure>
<t>The 24-bit Count is the number of MPLSv6 Encapsulations being <t>The 24-bit Count is the sum of the number of MPLSv6
announced and/or withdrawn.</t> Encapsulations being announced and/or withdrawn.</t>
</section> </section>
</section> </section>
@ -1326,9 +1333,9 @@ q-->
to ignore KEEPALIVE PDUs.</t> to ignore KEEPALIVE PDUs.</t>
<t>An operational deployment MUST BE configured whether to use <t>An operational deployment MUST BE configured whether to use
KEEPALIVEs or not, either globally, or down to per-link granularity. KEEPALIVEs or not, either globally, or as finely as to per-link
Disagreement MAY result in repeated session break and granularity. Disagreement MAY result in repeated session failure
reestablishment.</t> and reestablishment.</t>
<t>KEEPALIVEs SHOULD be beaconed at a configured frequency. One per <t>KEEPALIVEs SHOULD be beaconed at a configured frequency. One per
second is the default. Layer 3 liveness, such as BFD, may be more second is the default. Layer 3 liveness, such as BFD, may be more
@ -1467,7 +1474,7 @@ q-->
<section anchor="impl" title="Implementation Considerations"> <section anchor="impl" title="Implementation Considerations">
<t>An implementation SHOULD provide the ability to configure a <t>An implementation SHOULD provide the ability to configure each
logical interface as L3DL speaking or not.</t> logical interface as L3DL speaking or not.</t>
<t>An implementation SHOULD provide the ability to configure whether <t>An implementation SHOULD provide the ability to configure whether
@ -1498,15 +1505,15 @@ q-->
<section anchor="security" title="Security Considerations"> <section anchor="security" title="Security Considerations">
<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 due to lack of formal definition of the similarly closed environment without authentication ans
authentication and authorization mechanism. Sufficient mechanisms authorisation mechanisms such as <xref
may be described in separate documents.</t> target="I-D.ymbk-lsvr-l3dl-signing"/>.</t>
<t>Many MDC operators have a strange belief that physical walls and <t>Many MDC operators have a strange belief that physical walls and
firewalls provide sufficient security. This is not credible. All firewalls provide sufficient security. This is not credible. All
MDC protocols need to be examined for exposure and attack MDC protocols need to be examined for exposure and attack surface.
surface. In the case of L3DL, Authentication and Integrity as In the case of L3DL, Authentication and Integrity as provided in
provided in [draft-ymbk-l3dl-signing] is strongly recommended.</t> <xref target="I-D.ymbk-lsvr-l3dl-signing"/> is strongly recommended.</t>
<t>It is generally unwise to assume that on the wire Layer 2 is <t>It is generally unwise to assume that on the wire Layer 2 is
secure. Strange/unauthorized devices may plug into a port. secure. Strange/unauthorized devices may plug into a port.
@ -1613,9 +1620,8 @@ q-->
0 No Error 0 No Error
1 Checksum Error 1 Checksum Error
2 Logical Link Addressing Conflict 2 Logical Link Addressing Conflict
3 Authorization Failure in OPEN 3 Authorization Failure
4 Signature Failure in PDU 4 Announce/Withdraw Error
5 Announce/Withdraw Error
</artwork> </artwork>
</figure> </figure>
@ -1639,9 +1645,9 @@ q-->
comments, Joe Clarke for a useful review, John Scudder for deeply comments, Joe Clarke for a useful review, John Scudder for deeply
serious review and comments, Larry Kreeger for a lot of layer 2 serious review and comments, Larry Kreeger for a lot of layer 2
clue, Martijn Schmidt for his contribution, Nalinaksh Pai for clue, Martijn Schmidt for his contribution, Nalinaksh Pai for
transport discussions, Neeraj Malhotra for review, Russ Housley for transport discussions, Neeraj Malhotra for review, Paul Congdon for
checksum discussion and sBox, and Steve Bellovin for checksum Ethernet hints, Russ Housley for checksum discussion and sBox, and
advice.</t> Steve Bellovin for checksum advice.</t>
</section> </section>
@ -1663,6 +1669,7 @@ q-->
<?rfc include="reference.RFC.8174"?> <?rfc include="reference.RFC.8174"?>
<?rfc include="reference.I-D.ietf-idr-bgpls-segment-routing-epe"?> <?rfc include="reference.I-D.ietf-idr-bgpls-segment-routing-epe"?>
<?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext"?> <?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext"?>
<?rfc include="reference.I-D.ymbk-lsvr-l3dl-signing"?>
<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">
<front> <front>
<title>IANA Private Enterprise Numbers</title> <title>IANA Private Enterprise Numbers</title>