diff --git a/draft-ietf-lsvr-l3dl.xml b/draft-ietf-lsvr-l3dl.xml index 6cf42d5..11db013 100644 --- a/draft-ietf-lsvr-l3dl.xml +++ b/draft-ietf-lsvr-l3dl.xml @@ -100,15 +100,16 @@ Layer 3 Discovery and Liveness (L3DL) provides brutally simple mechanisms for devices to Discover each other's unique endpoint identification, - Discover mutually supported layer 3 encapsulations, - e.g. IP/MPLS, + Discover mutually supported layer 3 encapsulations, e.g. + IP/MPLS, Discover Layer 3 IP and/or MPLS addressing of interfaces of the encapsulations, 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 - Provide Layer 2 keep-alive messages for session continuity. + Enable Layer 3 link liveness such as BFD, + Provide Layer 2 keep-alive messages for session continuity, and + finally Provide for authenticity verification of protocol messages. @@ -211,7 +212,7 @@ Devices discover each other on logical links - Logical Link Endpoint Identifiers are exchanged + Logical Link Endpoint Identifiers (LLEIs) are exchanged Layer 2 Liveness checks may be started Encapsulation data are exchanged and IP-Level Liveness checks enabled @@ -248,14 +249,15 @@ - There are two protocols, the inter-device per-link layer 3 - discovery and the API to the upper level BGP-like routing prototol: + 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): 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. + 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, @@ -276,20 +278,21 @@ Two devices discover each other and their respective identities by sending multicast HELLO PDUs (). To assure discovery of new devices coming up on a multi-link topology, devices - on such a topology send periodic HELLOs forever, see . + on such a topology, and only on a multi-link topology, send periodic + HELLOs forever, see . Once a new device is recognized, both devices attempt to negotiate and establish a session by sending unicast OPEN PDUs () 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; - 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. + VLANs) of the received HELLOs. Once a session is established + through the OPEN exchange, 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; 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.
@@ -383,9 +386,9 @@
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. + 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. The L3DL Transport Layer encapsulates each Datagram using a common transport header. @@ -396,7 +399,7 @@ 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. 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. + MUST BE sent (Error Code 3), and HELLOs MUST be restarted. 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.
@@ -903,10 +908,10 @@ q--> - The Error Codes, noting protocol failures listed in thi document, - are listed in . 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. + The Error Codes, noting protocol failures, are listed in . 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. 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-->
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. + 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. The Encapsulation types the peers exchange may be IPv4 (), IPv6 (), MPLS IPv4 ( 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. @@ -1027,8 +1033,10 @@ q--> if data have not changed in the interim.
+
-
+ The Encapsulation Flags are a sequence of bit fields as + follows:
@@ -1053,9 +1061,8 @@ q--> target="ack"/> so all encapsulations will be resent. 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. + one and only one address MAY be marked as primary (Primary Flag == + 1) for that Encapsulation Type. 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-->
- The 24-bit Count is the number of IPv4 Encapsulations being - announced and/or withdrawn. + The 24-bit Count is the sum of the number of IPv4 + Encapsulations being announced and/or withdrawn.
@@ -1145,8 +1152,8 @@ q--> - The 24-bit Count is the number of IPv6 Encapsulations being - announced and/or withdrawn. + The 24-bit Count is the sum of the number of IPv6 + Encapsulations being announced and/or withdrawn.
@@ -1212,15 +1219,15 @@ q--> - The 24-bit Count is the number of MPLSv4 Encapsulation being - announced and/or withdrawns. + The 24-bit Count is the sum of the number of MPLSv4 + Encapsulation being announced and/or withdrawns.
- The MPLS IPv4 Encapsulation describes a logical link's ability - to exchange labeled IPv4 packets on one or more subnets. It does + 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. @@ -1256,8 +1263,8 @@ q--> - The 24-bit Count is the number of MPLSv6 Encapsulations being - announced and/or withdrawn. + The 24-bit Count is the sum of the number of MPLSv6 + Encapsulations being announced and/or withdrawn.
@@ -1326,9 +1333,9 @@ q--> to ignore KEEPALIVE PDUs. 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. + KEEPALIVEs or not, either globally, or as finely as to per-link + granularity. Disagreement MAY result in repeated session failure + and reestablishment. 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-->
- An implementation SHOULD provide the ability to configure a + An implementation SHOULD provide the ability to configure each logical interface as L3DL speaking or not. An implementation SHOULD provide the ability to configure whether @@ -1498,15 +1505,15 @@ q-->
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. + similarly closed environment without authentication ans + authorisation mechanisms such as . 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. + MDC protocols need to be examined for exposure and attack surface. + In the case of L3DL, Authentication and Integrity as provided in + is strongly recommended. 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 @@ -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. + transport discussions, Neeraj Malhotra for review, Paul Congdon for + Ethernet hints, Russ Housley for checksum discussion and sBox, and + Steve Bellovin for checksum advice.
@@ -1663,6 +1669,7 @@ q--> + IANA Private Enterprise Numbers