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
mechanisms for devices to <list style="symbols">
<t>Discover each other's unique endpoint identification,</t>
<t>Discover mutually supported layer 3 encapsulations,
e.g. IP/MPLS,</t>
<t>Discover mutually supported layer 3 encapsulations, e.g.
IP/MPLS,</t>
<t>Discover Layer 3 IP and/or MPLS addressing of interfaces of the
encapsulations,</t>
<t>Present these data, using a very restricted profile of a BGP-LS
<xref target="RFC7752"/> API, to BGP-SPF which computes the
topology and builds routing and forwarding tables,</t>
<t>Enable Layer 3 link liveness such as BFD, and finally</t>
<t>Provide Layer 2 keep-alive messages for session continuity.</t>
<t>Enable Layer 3 link liveness such as BFD,</t>
<t>Provide Layer 2 keep-alive messages for session continuity, and
finally</t>
<t>Provide for authenticity verification of protocol messages.</t>
</list></t>
@ -211,7 +212,7 @@
<t><list style="symbols">
<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>Encapsulation data are exchanged and IP-Level Liveness checks
enabled</t>
@ -248,14 +249,15 @@
</artwork>
</figure>
<t>There are two protocols, the inter-device per-link layer 3
discovery and the API to the upper level BGP-like routing prototol:
<t>There are two protocols, the inter-device (left-right in the
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">
<t>Inter-device PDUs are used to exchange device and logical link
identities and layer 2.5 (MPLS) and 3 identifiers (not payloads),
e.g. device IDs, port identities, VLAN IDs, Encapsulations, and
IP addresses.</t>
e.g. device IDs, port identities, VLAN IDs, Encapsulations, and IP
addresses.</t>
<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,
@ -276,20 +278,21 @@
<t>Two devices discover each other and their respective identities
by sending multicast HELLO PDUs (<xref target="hello"/>). To assure
discovery of new devices coming up on a multi-link topology, devices
on such a topology send periodic HELLOs forever, see <xref
target="dhello"/>.</t>
on such a topology, and only on a multi-link topology, send periodic
HELLOs forever, see <xref target="dhello"/>.</t>
<t>Once a new device is recognized, both devices attempt to
negotiate and establish a session by sending unicast OPEN PDUs
(<xref target="open"/>) to the source MAC addresses (plus VIDs if
VLANs)of the received HELLOs. In an established session, the
Encapsulations (<xref target="afisafi"/>) configured on an end point
may be announced and modified. Note that these are only the
encapsuation 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>
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 encapsuation 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>
<section anchor="ladder" title="L3DL Ladder Diagram">
@ -383,9 +386,9 @@
<section anchor="transport" title="Transport Layer">
<t>L3DL PDUs are carried by a simple transport layer which allows
PDUs to occupy many Ethernet frames. The L3DL content of an
Ethernet frame, exclusive of Ethernet framing data, is referred to
as a Datagram.</t>
long PDUs to occupy many Ethernet frames. The L3DL content of a
single Ethernet frame, exclusive of Ethernet framing data, is
referred to as a Datagram.</t>
<t>The L3DL Transport Layer encapsulates each Datagram using a
common transport header.</t>
@ -396,7 +399,7 @@
<t>Should a PDU need to be retransmitted, it MUST BE sent as 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>
<!--
@ -446,7 +449,8 @@
<t hangText="Datagram Length:">Total number of octets in the
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
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
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
Type.</t>
already in flight and not yet acknowledged; assuming it is an ACKed
PDU Type.</t>
</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
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,
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>
<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,
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
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
configuration SHOULD create and assign a unique one by
configuration SHOULD create and assign a unique one, likely by
configuration.</t>
<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>
<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>
@ -742,7 +747,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<section anchor="open" title="OPEN">
<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
frame.</t>
@ -806,7 +811,7 @@ q-->
<t>The Key is specific to the operational environment. A failure to
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.
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
that the sending LLEI or entire device has been reset. All
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>
</section>
@ -903,10 +908,10 @@ q-->
<?rfc subcompact="no"?>
</list></t>
<t>The Error Codes, noting protocol failures listed in thi document,
are listed in <xref target="iana-error"/>. Someone stuck in the
1990s might think the catenation of EType and Error Code as an echo
of 0x1zzz, 0x2zzz, etc. They might be right; or not.</t>
<t>The Error Codes, noting protocol failures, are listed in <xref
target="iana-error"/>. Someone stuck in the 1990s might think the
catenation of EType and Error Code as an echo of 0x1zzz, 0x2zzz,
etc. They might be right; or not.</t>
<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
@ -935,9 +940,10 @@ q-->
<section anchor="afisafi" title="The Encapsulations">
<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
session is considered established, and the devices SHOULD exchange
L3 interface encapsulations, L3 addresses, and L2.5 labels.</t>
layer (L2.5 and L3) identities, have means to ensure link state,
etc., the L3DL session is considered established, and the devices
SHOULD exchange L3 interface encapsulations, L3 addresses, and L2.5
labels.</t>
<t>The Encapsulation types the peers exchange may be 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
conflict, such as both ends of the link trying to use the same
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
layer topology builder deal with what works.</t>
@ -1027,8 +1033,10 @@ q-->
if data have not changed in the interim.</t>
</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>
<artwork>
@ -1053,9 +1061,8 @@ q-->
target="ack"/> so all encapsulations will be resent.</t>
<t>If an LLEI has multiple addresses for an encapsulation type,
one and only one address SHOULD be configured to be marked as
primary (Primary Flag == 1). Only one address on an interface MAY
be marked as primary for a particular encapsulation type.</t>
one and only one address MAY be marked as primary (Primary Flag ==
1) for that Encapsulation Type.</t>
<t>An Encapsulation interface address in an Encapsulation PDU MAY
be marked as a loopback, in which case the Loopback bit is set.
@ -1103,8 +1110,8 @@ q-->
</artwork>
</figure>
<t>The 24-bit Count is the number of IPv4 Encapsulations being
announced and/or withdrawn.</t>
<t>The 24-bit Count is the sum of the number of IPv4
Encapsulations being announced and/or withdrawn.</t>
</section>
@ -1145,8 +1152,8 @@ q-->
</artwork>
</figure>
<t>The 24-bit Count is the number of IPv6 Encapsulations being
announced and/or withdrawn.</t>
<t>The 24-bit Count is the sum of the number of IPv6
Encapsulations being announced and/or withdrawn.</t>
</section>
@ -1212,15 +1219,15 @@ q-->
</artwork>
</figure>
<t>The 24-bit Count is the number of MPLSv4 Encapsulation being
announced and/or withdrawns.</t>
<t>The 24-bit Count is the sum of the number of MPLSv4
Encapsulation being announced and/or withdrawns.</t>
</section>
<section anchor="mpls6" title="MPLS IPv6 Encapsulation">
<t>The MPLS IPv4 Encapsulation describes a logical link's ability
to exchange labeled IPv4 packets on one or more subnets. It does
<t>The MPLS IPv6 Encapsulation describes a logical link's ability
to exchange labeled IPv6 packets on one or more subnets. It does
so by stating the interface's addresses, the corresponding prefix
lengths, and the corresponding labels which will be accepted for
each address.</t>
@ -1256,8 +1263,8 @@ q-->
</artwork>
</figure>
<t>The 24-bit Count is the number of MPLSv6 Encapsulations being
announced and/or withdrawn.</t>
<t>The 24-bit Count is the sum of the number of MPLSv6
Encapsulations being announced and/or withdrawn.</t>
</section>
</section>
@ -1326,9 +1333,9 @@ q-->
to ignore KEEPALIVE PDUs.</t>
<t>An operational deployment MUST BE configured whether to use
KEEPALIVEs or not, either globally, or down to per-link granularity.
Disagreement MAY result in repeated session break and
reestablishment.</t>
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
@ -1467,7 +1474,7 @@ q-->
<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>
<t>An implementation SHOULD provide the ability to configure whether
@ -1498,15 +1505,15 @@ q-->
<section anchor="security" title="Security Considerations">
<t>The protocol as is MUST NOT be used outside a datacenter or
similarly closed environment due to lack of formal definition of the
authentication and authorization mechanism. Sufficient mechanisms
may be described in separate documents.</t>
similarly closed environment without authentication ans
authorisation mechanisms such as <xref
target="I-D.ymbk-lsvr-l3dl-signing"/>.</t>
<t>Many MDC operators have a strange belief that physical walls and
firewalls provide sufficient security. This is not credible. All
MDC protocols need to be examined for exposure and attack
surface. In the case of L3DL, Authentication and Integrity as
provided in [draft-ymbk-l3dl-signing] is strongly recommended.</t>
MDC protocols need to be examined for exposure and attack surface.
In the case of L3DL, Authentication and Integrity as provided in
<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
secure. Strange/unauthorized devices may plug into a port.
@ -1613,9 +1620,8 @@ q-->
0 No Error
1 Checksum Error
2 Logical Link Addressing Conflict
3 Authorization Failure in OPEN
4 Signature Failure in PDU
5 Announce/Withdraw Error
3 Authorization Failure
4 Announce/Withdraw Error
</artwork>
</figure>
@ -1639,9 +1645,9 @@ q-->
comments, Joe Clarke for a useful review, John Scudder for deeply
serious review and comments, Larry Kreeger for a lot of layer 2
clue, Martijn Schmidt for his contribution, Nalinaksh Pai for
transport discussions, Neeraj Malhotra for review, Russ Housley for
checksum discussion and sBox, and Steve Bellovin for checksum
advice.</t>
transport discussions, Neeraj Malhotra for review, Paul Congdon for
Ethernet hints, Russ Housley for checksum discussion and sBox, and
Steve Bellovin for checksum advice.</t>
</section>
@ -1663,6 +1669,7 @@ q-->
<?rfc include="reference.RFC.8174"?>
<?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.ymbk-lsvr-l3dl-signing"?>
<reference anchor="IANA-PEN" target="https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers">
<front>
<title>IANA Private Enterprise Numbers</title>