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

congdon comments incorporated

Browse source
This commit is contained in:
Randy Bush 2019-08-01 12:10:07 -07:00
parent 04615d1ab5
commit f8eb59dc13
1 changed files with 38 additions and 33 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -107,8 +107,9 @@
<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>Enable Layer 3 link liveness such as BFD, and finally</t>
<t>Provide Layer 2 keep-alive messages for session continuity.</t>
<t>Provide for authenticity verification of protocol messages.</t>
</list></t>
<t>This protocol may be more widely applicable to a range of routing
@ -214,8 +215,9 @@
<t>Layer 2 Liveness checks may be started</t>
<t>Encapsulation data are exchanged and IP-Level Liveness checks
enabled</t>
<t>A BGP-like upper layer protocol is assumed to use these data to
discover and build a topology database</t>
<t>A BGP-like upper layer protocol is assumed to use the
identiiers and encapsulation data to discover and build a topology
database</t>
</list></t>
<figure>
@ -251,9 +253,9 @@
<list style="symbols">
<t>Inter-device PDUs are used to exchange device and logical link
identities and layer 2.5 and 3 identifiers (not payloads), e.g.
device IDs, port identities, VLAN IDs, Encapsulations, and IP
addresses.</t>
identities and layer 2.5 (MPLS) and 3 identifiers (not payloads),
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,
@ -279,7 +281,8 @@
<t>Once a new device is recognized, both devices attempt to
negotiate and establish a session by sending unicast OPEN PDUs
(<xref target="open"/>). In an established session, the
(<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;
@ -290,11 +293,11 @@
<section anchor="ladder" title="L3DL Ladder Diagram">
<t>The HELLO, <xref target="hello"/>, is a priming message. It is
a small L3DL PDU encapsulated in an Ethernet multicast frame with
the simple goal of discovering the identities of logical link
endpoint(s) reachable from a Logical Link Endpoint, <xref
target="llei"/>.</t>
<t>The HELLO, <xref target="hello"/>, is a priming message sent on
all configured logical links. It is a small L3DL PDU encapsulated
in an Ethernet multicast frame with the simple goal of discovering
the identities of logical link endpoint(s) reachable from a
Logical Link Endpoint, <xref target="llei"/>.</t>
<t>The HELLO and OPEN, <xref target="open"/>, PDUs, which are used
to discover and exchange detailed Logical Link Endpoint
@ -397,16 +400,16 @@
same PDU.</t>
<!--
protocol "Version:8,Transmission Sequence Number:16,L:1,Datagram Number:24,Datagram Length:15,Checksum:32,Payload...:32"
protocol "Version:8,Transmission Sequence Number:16,L:1,Datagram Number:23,Datagram Length:16,Checksum:32,Payload...:32"
-->
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Transmission Sequence Number |L| |
| Version | Transmission Sequence Number |L| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datagram Number | Datagram Length |
~ Datagram Number | Datagram Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@ -420,7 +423,7 @@
<t hangText="Version:">Seven-bit Version number of the protocol,
currently 0. Values other than 0 MUST BE treated as an error.
The protocol version nees to be in one and only one place, so it
The protocol version needs to be in one and only one place, so it
is in the datagram as opposed to, for example, the PDU header.</t>
<t hangText="L:">A bit that set to one if this Datagram is the
@ -690,10 +693,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>When an interface is turned up on a device, it SHOULD issue a
HELLO if it is to participate in L3DL sessions.</t>
<t>If a constrained Nearest Bridge destination address is 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 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,
@ -720,10 +723,11 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
each unique source LLEI response. L3DL treats each adjacency as a
separate logical link.</t>
<t>When a HELLO is received from a source MAC address with which
there is no established L3DL session, the receiver SHOULD respond
with an OPEN PDU. The two devices establish an L3DL session by
exchanging OPEN PDUs.</t>
<t>When a HELLO is received from a source MAC address (plus VID if
VLAN) with which there is no established L3DL session, the receiver
SHOULD respond by sending an OPEN PDU to the source MAC address
(plus VID). The two devices establish an L3DL session by exchanging
OPEN PDUs.</t>
<t>The Payload Length is zero as there is no payload.</t>
@ -793,8 +797,9 @@ q-->
target="tlv"/>.</t>
<t>Key Length is a 16-bit field denoting the length in octets of the
Key itself, not including the Auth Type or the Key Length. If there
is no Key, the Auth Type and key Length MUST both be zero.</t>
Key itself, not including the Auth Type or the Key Length. If the
Auth Type is zero, then the Key Length MUST also be zero, and there
MUST BE no Key data.</t>
<t>The Key is specific to the operational environment. A failure to
authenticate is a failure to start the L3DL session, an ERROR PDU
@ -900,9 +905,9 @@ q-->
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 is any additional data the sender of the error PDU
thinks will help the recipient or the debugger with the particular
error.</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
debugger with the particular error.</t>
<t>The Signature fields are described in <xref target="tlv"/>.</t>
@ -939,8 +944,8 @@ q-->
<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 to assume that they
are compatible for that type.</t>
have sent the same Encapsulation Type is it safe for Layer 3
protocols to assume that they are compatible for that 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
@ -1012,8 +1017,8 @@ q-->
<t>If the Sender does not receive an ACK in a configurable
interval (default one second), and the interface is live at layer
2, they SHOULD retransmit. After a user configurable number of
failures, the L3DL session should be considered dead and the OPEN
process SHOULD be restarted.</t>
failures (default three), the L3DL session should be considered
dead and the OPEN process SHOULD be restarted.</t>
<t>If the link is broken at layer 2, retransmission MAY BE retried
if data have not changed in the interim.</t>