From f8eb59dc137ff76550fafbde232e3d0c820b3d30 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Thu, 1 Aug 2019 12:10:07 -0700 Subject: [PATCH] congdon comments incorporated --- draft-ietf-lsvr-l3dl.xml | 71 +++++++++++++++++++++------------------- 1 file changed, 38 insertions(+), 33 deletions(-) diff --git a/draft-ietf-lsvr-l3dl.xml b/draft-ietf-lsvr-l3dl.xml index 27fa2a6..f284cfa 100644 --- a/draft-ietf-lsvr-l3dl.xml +++ b/draft-ietf-lsvr-l3dl.xml @@ -107,8 +107,9 @@ Present these data, using a very restricted profile of a BGP-LS API, to BGP-SPF which computes the topology and builds routing and forwarding tables, - Enable layer 3 link liveness such as BFD, and finally + Enable Layer 3 link liveness such as BFD, and finally Provide Layer 2 keep-alive messages for session continuity. + Provide for authenticity verification of protocol messages. This protocol may be more widely applicable to a range of routing @@ -214,8 +215,9 @@ Layer 2 Liveness checks may be started Encapsulation data are exchanged and IP-Level Liveness checks enabled - A BGP-like upper layer protocol is assumed to use these data to - discover and build a topology database + A BGP-like upper layer protocol is assumed to use the + identiiers and encapsulation data to discover and build a topology + database
@@ -251,9 +253,9 @@ 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. + identities and layer 2.5 (MPLS) and 3 identifiers (not payloads), + e.g. device IDs, port identities, VLAN IDs, Encapsulations, and + IP addresses. 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 @@ Once a new device is recognized, both devices attempt to negotiate and establish a session by sending unicast OPEN PDUs - (). In an established session, the + () to the source MAC addresses (plus VIDs if + VLANs) of the received HELLOs. In an established session, the Encapsulations () 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 @@
- The 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, . + The 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, . The HELLO and OPEN, , PDUs, which are used to discover and exchange detailed Logical Link Endpoint @@ -397,16 +400,16 @@ same PDU.
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 @@ 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. 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) When an interface is turned up on a device, it SHOULD issue a HELLO if it is to participate in L3DL sessions. - 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. + 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. 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. - 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. + 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. The Payload Length is zero as there is no payload. @@ -793,8 +797,9 @@ q--> target="tlv"/>. 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. + 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. 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. - 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. + 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. The Signature fields are described in . @@ -939,8 +944,8 @@ q--> The sender of an Encapsulation PDU MUST NOT assume that the peer is capable of the same Encapsulation Type. An 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. + have sent the same Encapsulation Type is it safe for Layer 3 + protocols to assume that they are compatible for that type. 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--> 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. + failures (default three), the L3DL session should be considered + dead and the OPEN process SHOULD be restarted. If the link is broken at layer 2, retransmission MAY BE retried if data have not changed in the interim.