draft-ietf-lsvr-l3dl-02.txt   draft-ietf-lsvr-l3dl-03.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Arrcus & Internet Initiative Japan Internet-Draft Arrcus & Internet Initiative Japan
Intended status: Standards Track R. Austein Intended status: Standards Track R. Austein
Expires: January 8, 2020 K. Patel Expires: May 5, 2020 K. Patel
Arrcus Arrcus
July 7, 2019 November 2, 2019
Layer 3 Discovery and Liveness Layer 3 Discovery and Liveness
draft-ietf-lsvr-l3dl-02 draft-ietf-lsvr-l3dl-03
Abstract Abstract
In Massive Data Centers, BGP-SPF and similar routing protocols are In Massive Data Centers, BGP-SPF and similar routing protocols are
used to build topology and reachability databases. These protocols used to build topology and reachability databases. These protocols
need to discover IP Layer 3 attributes of links, such as logical link need to discover IP Layer 3 attributes of links, such as logical link
IP encapsulation abilities, IP neighbor address discovery, and link IP encapsulation abilities, IP neighbor address discovery, and link
liveness. This Layer 3 Discovery and Liveness protocol collects liveness. This Layer 3 Discovery and Liveness protocol collects
these data, which may then be disseminated using BGP-SPF and similar these data, which may then be disseminated using BGP-SPF and similar
protocols. protocols.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 8, 2020. This Internet-Draft will expire on May 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Top Level Overview . . . . . . . . . . . . . . . . . . . . . 5 4. Top Level Overview . . . . . . . . . . . . . . . . . . . . . 5
5. Inter-Link Protocol Overview . . . . . . . . . . . . . . . . 6 5. Inter-Link Protocol Overview . . . . . . . . . . . . . . . . 7
5.1. L3DL Ladder Diagram . . . . . . . . . . . . . . . . . . . 7 5.1. L3DL Ladder Diagram . . . . . . . . . . . . . . . . . . . 7
6. Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 8 6. Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 9
7. The Checksum . . . . . . . . . . . . . . . . . . . . . . . . 10 7. The Checksum . . . . . . . . . . . . . . . . . . . . . . . . 10
8. TLV PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. TLV PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Logical Link Endpoint Identifier . . . . . . . . . . . . . . 13 9. Logical Link Endpoint Identifier . . . . . . . . . . . . . . 13
10. HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 18 12.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 19
13. The Encapsulations . . . . . . . . . . . . . . . . . . . . . 18 13. The Encapsulations . . . . . . . . . . . . . . . . . . . . . 19
13.1. The Encapsulation PDU Skeleton . . . . . . . . . . . . . 19 13.1. The Encapsulation PDU Skeleton . . . . . . . . . . . . . 20
13.2. Encapsulaion Flags . . . . . . . . . . . . . . . . . . . 20 13.2. Encapsulaion Flags . . . . . . . . . . . . . . . . . . . 21
13.3. IPv4 Encapsulation . . . . . . . . . . . . . . . . . . . 21 13.3. IPv4 Encapsulation . . . . . . . . . . . . . . . . . . . 21
13.4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 21 13.4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 22
13.5. MPLS Label List . . . . . . . . . . . . . . . . . . . . 22 13.5. MPLS Label List . . . . . . . . . . . . . . . . . . . . 23
13.6. MPLS IPv4 Encapsulation . . . . . . . . . . . . . . . . 22 13.6. MPLS IPv4 Encapsulation . . . . . . . . . . . . . . . . 23
13.7. MPLS IPv6 Encapsulation . . . . . . . . . . . . . . . . 23 13.7. MPLS IPv6 Encapsulation . . . . . . . . . . . . . . . . 24
14. VENDOR - Vendor Extensions . . . . . . . . . . . . . . . . . 24 14. VENDOR - Vendor Extensions . . . . . . . . . . . . . . . . . 24
15. KEEPALIVE - Layer 2 Liveness . . . . . . . . . . . . . . . . 25 15. KEEPALIVE - Layer 2 Liveness . . . . . . . . . . . . . . . . 25
16. Layers 2.5 and 3 Liveness . . . . . . . . . . . . . . . . . . 26 16. Layers 2.5 and 3 Liveness . . . . . . . . . . . . . . . . . . 26
17. The North/South Protocol . . . . . . . . . . . . . . . . . . 26 17. The North/South Protocol . . . . . . . . . . . . . . . . . . 26
17.1. Use BGP-LS as Much as Possible . . . . . . . . . . . . . 26 17.1. Use BGP-LS as Much as Possible . . . . . . . . . . . . . 27
17.2. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . 26 17.2. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . 27
18. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 27 18. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 27
18.1. HELLO Discussion . . . . . . . . . . . . . . . . . . . . 27 18.1. HELLO Discussion . . . . . . . . . . . . . . . . . . . . 27
18.2. HELLO versus KEEPALIVE . . . . . . . . . . . . . . . . . 27 18.2. HELLO versus KEEPALIVE . . . . . . . . . . . . . . . . . 28
19. VLANs/SVIs/Sub-interfaces . . . . . . . . . . . . . . . . . . 27 19. VLANs/SVIs/Sub-interfaces . . . . . . . . . . . . . . . . . . 28
20. Implementation Considerations . . . . . . . . . . . . . . . . 28 20. Implementation Considerations . . . . . . . . . . . . . . . . 28
21. Security Considerations . . . . . . . . . . . . . . . . . . . 28 21. Security Considerations . . . . . . . . . . . . . . . . . . . 29
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
22.1. PDU Types . . . . . . . . . . . . . . . . . . . . . . . 29 22.1. PDU Types . . . . . . . . . . . . . . . . . . . . . . . 29
22.2. Signature Type . . . . . . . . . . . . . . . . . . . . . 29 22.2. Signature Type . . . . . . . . . . . . . . . . . . . . . 30
22.3. Flag Bits . . . . . . . . . . . . . . . . . . . . . . . 30 22.3. Flag Bits . . . . . . . . . . . . . . . . . . . . . . . 30
22.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . 30 22.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . 30
23. IEEE Considerations . . . . . . . . . . . . . . . . . . . . . 30 23. IEEE Considerations . . . . . . . . . . . . . . . . . . . . . 31
24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
25. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 25. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
25.1. Normative References . . . . . . . . . . . . . . . . . . 31 25.1. Normative References . . . . . . . . . . . . . . . . . . 31
25.2. Informative References . . . . . . . . . . . . . . . . . 32 25.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
The Massive Data Center (MDC) environment presents unusual problems The Massive Data Center (MDC) environment presents unusual problems
of scale, e.g. O(10,000) forwarding devices, while its homogeneity of scale, e.g. O(10,000) forwarding devices, while its homogeneity
presents opportunities for simple approaches. Approaches such as presents opportunities for simple approaches. Approaches such as
Jupiter Rising [JUPITER] use a central controller to deal with Jupiter Rising [JUPITER] use a central controller to deal with
scaling, while BGP-SPF [I-D.ietf-lsvr-bgp-spf] provides massive scaling, while BGP-SPF [I-D.ietf-lsvr-bgp-spf] provides massive
scale-out without centralization using a tried and tested scalable scale-out without centralization using a tried and tested scalable
distributed control plane, offering a scalable routing solution in distributed control plane, offering a scalable routing solution in
skipping to change at page 3, line 49 skipping to change at page 3, line 49
o Discover mutually supported layer 3 encapsulations, e.g. IP/MPLS, o Discover mutually supported layer 3 encapsulations, e.g. IP/MPLS,
o Discover Layer 3 IP and/or MPLS addressing of interfaces of the o Discover Layer 3 IP and/or MPLS addressing of interfaces of the
encapsulations, encapsulations,
o Present these data, using a very restricted profile of a BGP-LS o Present these data, using a very restricted profile of a BGP-LS
[RFC7752] API, to BGP-SPF which computes the topology and builds [RFC7752] API, to BGP-SPF which computes the topology and builds
routing and forwarding tables, routing and forwarding tables,
o Enable layer 3 link liveness such as BFD, and finally o Enable Layer 3 link liveness such as BFD,
o Provide Layer 2 keep-alive messages for session continuity. o Provide Layer 2 keep-alive messages for session continuity, and
finally
o Provide for authenticity verification of protocol messages.
This protocol may be more widely applicable to a range of routing and This protocol may be more widely applicable to a range of routing and
similar protocols which need layer 3 discovery and characterisation. similar protocols which need layer 3 discovery and characterisation.
2. Terminology 2. Terminology
Even though it concentrates on the inter-device layer, this document Even though it concentrates on the inter-device layer, this document
relies heavily on routing terminology. The following attempts to relies heavily on routing terminology. The following attempts to
clarify the use of some possibly confusing terms: clarify the use of some possibly confusing terms:
skipping to change at page 4, line 25 skipping to change at page 4, line 27
an originator of Layer 3 routes, particularly BGP an originator of Layer 3 routes, particularly BGP
announcements. announcements.
BGP-LS: A mechanism by which link-state and TE information can be BGP-LS: A mechanism by which link-state and TE information can be
collected from networks and shared with external collected from networks and shared with external
components using the BGP routing protocol. See [RFC7752]. components using the BGP routing protocol. See [RFC7752].
BGP-SPF A hybrid protocol using BGP transport but a Dijkstra BGP-SPF A hybrid protocol using BGP transport but a Dijkstra
Shortest Path First decision process. See Shortest Path First decision process. See
[I-D.ietf-lsvr-bgp-spf]. [I-D.ietf-lsvr-bgp-spf].
Clos: A hierarchic subset of a crossbar switch topology commonly Clos: A hierarchic subset of a crossbar switch topology commonly
used in data centers. used in data centers.
Datagram: The L3DL content of a single Layer 2 frame. A full L3DL Datagram: The L3DL content of a single Layer 2 frame, sans Ethernet
PDU may be packaged in multiple Datagrams. framing. A full L3DL PDU may be packaged in multiple
Datagrams.
Encapsulation: Address Family Indicator and Subsequent Address Encapsulation: Address Family Indicator and Subsequent Address
Family Indicator (AFI/SAFI). I.e. classes of layer 2.5 Family Indicator (AFI/SAFI). I.e. classes of layer 2.5
and 3 addresses such as IPv4, IPv6, MPLS, etc. and 3 addresses such as IPv4, IPv6, MPLS, etc.
Frame: A Layer 2 packet. Frame: A Layer 2 Ethernet packet.
Link or Logical Link: A logical connection between two logical ports Link or Logical Link: A logical connection between two logical ports
on two devices. E.g. two VLANs between the same two ports on two devices. E.g. two VLANs between the same two ports
are two links. are two links.
LLEI: Logical Link Endpoint Identifier, the unique identifier of LLEI: Logical Link Endpoint Identifier, the unique identifier of
one end of a logical link, see Section 9. one end of a logical link, see Section 9.
MAC Address: 48-bit Layer 2 addresses are assumed since they are MAC Address: 48-bit Layer 2 addresses are assumed since they are
used by all widely deployed Layer 2 network technologies used by all widely deployed Layer 2 network technologies
of interest, especially Ethernet. See [IEEE.802_2001]. of interest, especially Ethernet. See [IEEE.802_2001].
MDC: Massive Data Center, commonly composed of thousands of Top MDC: Massive Data Center, commonly composed of thousands of Top
of Rack Switches (TORs). of Rack Switches (TORs).
MTU: Maximum Transmission Unit, the size in octets of the MTU: Maximum Transmission Unit, the size in octets of the
largest packet that can be sent on a medium, see [RFC1122] largest packet that can be sent on a medium, see [RFC1122]
1.3.3. 1.3.3.
PDU: Protocol Data Unit, an L3DL application layer message. A PDU: Protocol Data Unit, an L3DL application layer message. A
PDU may need to be broken into multiple Datagrams to make PDU's content may need to be broken into multiple
it through MTU or other restrictions. Datagrams to make it through MTU or other restrictions.
RouterID: An 32-bit identifier unique in the current routing domain, RouterID: An 32-bit identifier unique in the current routing domain,
see [RFC6286]. see [RFC6286].
Session: An established, via OPEN PDUs, session between two L3DL Session: An established, via OPEN PDUs, session between two L3DL
capable link end-points, capable link end-points,
SPF: Shortest Path First, an algorithm for finding the shortest SPF: Shortest Path First, an algorithm for finding the shortest
paths between nodes in a graph; AKA Dijkstra's algorithm. paths between nodes in a graph; AKA Dijkstra's algorithm.
System Identifier: An eight octet ISO System Identifier a la System Identifier: An eight octet ISO System Identifier a la
[RFC1629] System ID [RFC1629] System ID
TOR: Top Of Rack switch, aggregates the servers in a rack and TOR: Top Of Rack switch, aggregates the servers in a rack and
connects to aggregation layers of the Clos tree, AKA the connects to aggregation layers of the Clos tree, AKA the
Clos spine. Clos spine.
ZTP: Zero Touch Provisioning gives devices initial addresses, ZTP: Zero Touch Provisioning gives devices initial addresses,
credentials, etc. on boot/restart. credentials, etc. on boot/restart.
3. Background 3. Background
skipping to change at page 5, line 34 skipping to change at page 5, line 38
L3DL assumes a new IEEE assigned EtherType (TBD). L3DL assumes a new IEEE assigned EtherType (TBD).
The number of addresses of one Encapsulation type on an interface The number of addresses of one Encapsulation type on an interface
link may be quite large given a TOR with tens of servers, each server link may be quite large given a TOR with tens of servers, each server
having a few hundred micro-services, resulting in an inordinate having a few hundred micro-services, resulting in an inordinate
number of addresses. And highly automated micro-service migration number of addresses. And highly automated micro-service migration
can cause serious address prefix disaggregation, resulting in can cause serious address prefix disaggregation, resulting in
interfaces with thousands of disaggregated prefixes. interfaces with thousands of disaggregated prefixes.
Therefore the L3DL protocol is session oriented and uses incremental Therefore the L3DL protocol is session oriented and uses incremental
announcement and widrawal with session restart, a la BGP ([RFC4271]). announcement and withdrawal with session restart, a la BGP
([RFC4271]).
4. Top Level Overview 4. Top Level Overview
o Devices discover each other on logical links o Devices discover each other on logical links
o Logical Link Endpoint Identifiers are exchanged o Logical Link Endpoint Identifiers (LLEIs) are exchanged
o Layer 2 Liveness Checks may be started o Layer 2 Liveness checks may be started
o Encapsulation data are exchanged and IP-Level Liveness Checks o Encapsulation data are exchanged and IP-Level Liveness checks
enabled enabled
o A BGP-like upper layer protocol is assumed to use these data to o A BGP-like upper layer protocol is assumed to use the identiiers
discover and build a topology database and encapsulation data to discover and build a topology database
+-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+
| Device | | Device | | Device | | Device | | Device | | Device |
| | | | | | | | | | | |
|+-----------------+| |+-----------------+| |+-----------------+| |+-----------------+| |+-----------------+| |+-----------------+|
|| || || || || || || || || || || ||
|| BGP-SPF <+---+> BGP-SPF <+---+> BGP-SPF || || BGP-SPF <+---+> BGP-SPF <+---+> BGP-SPF ||
|| || || || || || || || || || || ||
|+--------^--------+| |+--------^--------+| |+--------^--------+| |+--------^--------+| |+--------^--------+| |+--------^--------+|
| | | | | | | | | | | | | | | | | |
skipping to change at page 6, line 29 skipping to change at page 6, line 32
|+--------^--------+| |+--------^--------+| |+--------^--------+| |+--------^--------+| |+--------^--------+| |+--------^--------+|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
|+--------v--------+| |+--------v--------+| |+--------v--------+| |+--------v--------+| |+--------v--------+| |+--------v--------+|
|| || || || || || || || || || || ||
||Inter-Device PDUs<+---+>Inter-Device PDUs<+---+>Inter-Device PDUs|| ||Inter-Device PDUs<+---+>Inter-Device PDUs<+---+>Inter-Device PDUs||
|| || || || || || || || || || || ||
|+-----------------+| |+-----------------+| |+-----------------+| |+-----------------+| |+-----------------+| |+-----------------+|
+-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+
There are two protocols, the inter-device per-link layer 3 discovery There are two protocols, the inter-device (left-right in the diagram)
and the API to the upper level BGP-like routing prototol: per-link layer 3 discovery and the API to the upper level BGP-like
routing prototol (up-down in the above diagram):
o Inter-device PDUs are used to exchange device and logical link o Inter-device PDUs are used to exchange device and logical link
identities and layer 2.5 and 3 identifiers (not payloads), e.g. identities and layer 2.5 (MPLS) and 3 identifiers (not payloads),
device IDs, port identities, VLAN IDs, Encapsulations, and IP e.g. device IDs, port identities, VLAN IDs, Encapsulations, and IP
addresses. addresses.
o A Link Layer to BGP API presents these data up the stack to a BGP o A Link Layer to BGP API presents these data up the stack to a BGP
protocol or an other device-spanning upper layer protocol, protocol or an other device-spanning upper layer protocol,
presenting them using the BGP-LS BGP-like data format. presenting them using the BGP-LS BGP-like data format.
The upper layer BGP family routing protocols cross all the devices, The upper layer BGP family routing protocols cross all the devices,
though they are not part of these L3DL protocols. though they are not part of these L3DL protocols.
To simplify this document, Layer 2 framing is not shown. L3DL is To simplify this document, Layer 2 framing is not shown. L3DL is
about layer 3. about layer 3.
5. Inter-Link Protocol Overview 5. Inter-Link Protocol Overview
Two devices discover each other and their respective identities by Two devices discover each other and their respective identities by
sending multicast HELLO PDUs (Section 10). To assure discovery of sending multicast HELLO PDUs (Section 10). To assure discovery of
new devices coming up on a multi-link topology, devices on such a new devices coming up on a multi-link topology, devices on such a
topology send periodic HELLOs forever, see Section 18.1. topology, and only on a multi-link topology, send periodic HELLOs
forever, see Section 18.1.
Once a new device is recognized, both devices attempt to negotiate Once a new device is recognized, both devices attempt to negotiate
and establish a session by sending unicast OPEN PDUs (Section 11). and establish a session by sending unicast OPEN PDUs (Section 11) to
In an established session, the Encapsulations (Section 13) configured the source MAC addresses (plus VIDs if VLANs) of the received HELLOs.
on an end point may be announced and modified. Note that these are Once a session is established through the OPEN exchange, the
only the encapsuation and addresses configured on the announcing Encapsulations (Section 13) configured on an end point may be
interface; though a device's loopback and overlay interface(s) may announced and modified. Note that these are only the encapsuation
also be announced. When two devices on a link have compatible and addresses configured on the announcing interface; though a
Encapsulations and addresses, i.e. the same AFI/SAFI and the same device's loopback and overlay interface(s) may also be announced.
subnet, the link is announced via the BGP-LS API. 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.
5.1. L3DL Ladder Diagram 5.1. L3DL Ladder Diagram
The HELLO, Section 10, is a priming message. It is a small L3DL PDU The HELLO, Section 10, is a priming message sent on all configured
encapsulated in an Ethernet multicast frame with the simple goal of logical links. It is a small L3DL PDU encapsulated in an Ethernet
discovering the identities of logical link endpoint(s) reachable from multicast frame with the simple goal of discovering the identities of
a Logical Link Endpoint, Section 9. logical link endpoint(s) reachable from a Logical Link Endpoint,
Section 9.
The HELLO and OPEN, Section 11, PDUs, which are used to discover and The HELLO and OPEN, Section 11, PDUs, which are used to discover and
exchange detailed Logical Link Endpoint Identifiers, LLEIs, and the exchange detailed Logical Link Endpoint Identifiers, LLEIs, and the
ACK/ERROR PDU, are mandatory; other PDUs are optional; though at ACK/ERROR PDU, are mandatory; other PDUs are optional; though at
least one encapsulation SHOULD be agreed at some point. least one encapsulation SHOULD be agreed at some point.
The following is a ladder-style diagram of the L3DL protocol The following is a ladder-style diagram of the L3DL protocol
exchanges: exchanges:
| HELLO | Logical Link Peer discovery | HELLO | Logical Link Peer discovery
|---------------------------->| |---------------------------->|
| HELLO | Mandatory | HELLO | Mandatory
|<----------------------------| |<----------------------------|
| | | |
| | | |
| OPEN | MACs, IDs, etc. | OPEN | MACs, IDs, etc.
|---------------------------->| |---------------------------->|
| ACK | | ACK |
|<----------------------------| |<----------------------------|
| | | |
| OPEN | Mandatory | OPEN | Mandatory
|<----------------------------| |<----------------------------|
| ACK | | ACK |
|---------------------------->| |---------------------------->|
| | | |
| | | |
| Interface IPv4 Addresses | Interface IPv4 Addresses | Interface IPv4 Addresses | Interface IPv4 Addresses
|---------------------------->| Optional |---------------------------->| Optional
| ACK | | ACK |
|<----------------------------| |<----------------------------|
| | | |
skipping to change at page 8, line 49 skipping to change at page 9, line 12
|---------------------------->| |---------------------------->|
| | | |
| | | |
| L3DL KEEPALIVE | Layer 2 Liveness | L3DL KEEPALIVE | Layer 2 Liveness
|---------------------------->| Optional |---------------------------->| Optional
| L3DL KEEPALIVE | | L3DL KEEPALIVE |
|<----------------------------| |<----------------------------|
6. Transport Layer 6. Transport Layer
L3DL PDUs are carried by a simple transport layer which allows PDUs L3DL PDUs are carried by a simple transport layer which allows long
to occupy many Ethernet frames. An L3DL Ethernet frame is referred PDUs to occupy many Ethernet frames. The L3DL content of a single
to as a Datagram. Ethernet frame, exclusive of Ethernet framing data, is referred to as
a Datagram.
The L3DL Transport Layer encapsulates each Datagram using a common The L3DL Transport Layer encapsulates each Datagram using a common
transport header. transport header.
If a PDU does not fit in a single datagram, it is broken into If a PDU does not fit in a single datagram, it is broken into
multiple datagrams and reassembled by the receiver a la [RFC0791] multiple Datagrams and reassembled by the receiver a la [RFC0791]
Section 2.3 Fragmentation. Section 2.3 Fragmentation.
Should a PDU need to be retransmitted, it MUST BE sent as the
identical Datagram set as the original transmission. The
Transmission Sequence Number informs the receiver that it is the same
PDU.
0 1 2 3 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 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 |L| Datagram Number | | Version | Transmission Sequence Number |L| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datagram Length | Checksum ~ ~ Datagram Number | Datagram Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Payload... ~ | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the L3DL Transport Header are as follows: The fields of the L3DL Transport Header are as follows:
Version: Seven-bit Version number of the protocol, currently 0. Version: Seven-bit Version number of the protocol, currently 0.
Values other than 0 MUST BE treated as an error. The protocol Values other than 0 MUST BE treated as an error. The protocol
version nees to be in one and only one place, so it is in the version needs to be in one and only one place, so it is in the
datagram as opposed to, for example, the PDU header. datagram as opposed to, for example, the PDU header.
L: A bit that set to one if this Datagram is the last Datagram of the L: A bit that set to one if this Datagram is the last Datagram of the
PDU. For a PDU which fits in only one Datagram, it is set to one. PDU. For a PDU which fits in only one Datagram, it is set to one.
Note that this is the inverse of the marking technique used by Note that this is the inverse of the marking technique used by
[RFC0791]. [RFC0791].
Transmission Sequence Number: A 16-bit strictly increasing unsigned
integer identifying this PDU, possibly across retransmissions,
that wraps from 2^16-1 to 0. The initial value is arbitrary. See
[RFC1982] on DNS Serial Number Arithmetic for too much detail on
comparison and incrementing a wrapping sequence number.
Datagram Number: A monotonically increasing 24-bit value which Datagram Number: A monotonically increasing 24-bit value which
starts at zero for each PDU. This is used to reassemble frames starts at zero for each PDU. This is used to reassemble frames
into PDUs a la [RFC0791] Section 2.3. Note that this limits an into PDUs a la [RFC0791] Section 2.3. Note that this limits an
L3DL PDU to 2^24 frames. L3DL PDU to 2^24 frames.
Datagram Length: Total number of octets in the Datagram including Datagram Length: Total number of octets in the Datagram including
all payloads and fields. Note that this limits a datagram to 2^16 all payloads and fields. Note that this limits a datagram to 2^16
octets. octets; though Ethernet framing is likely to impose a smaller
limit.
Checksum: A 32 bit hash over the Datagram to detect bit flips, see Checksum: A 32 bit hash over the Datagram to detect bit flips, see
Section 7. Section 7.
If a Datagram fails checksum verification, the datagram is invalid
and should be silently discarded. The sender will retransmit the
PDU, and the receiver can assmble it.
Payload: The PDU being transported or a fragment thereof. Payload: The PDU being transported or a fragment thereof.
To avoid the need for a receiver to reassemble two PDUs at the same 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 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. in flight and not yet acknowledged; assuming it is an ACKed PDU Type.
7. The Checksum 7. The Checksum
There is a reason conservative folk use a checksum in UDP. And as There is a reason conservative folk use a checksum in UDP. And as
many operators stretch to jumbo frames (over 1,500 octets) longer many operators stretch to jumbo frames (over 1,500 octets) longer
checksums are the prudent approach. checksums are the prudent approach.
For the purpose of computing a checksum, the checksum field itself is For the purpose of computing a checksum, the checksum field itself is
assumed to be zero. assumed to be zero.
skipping to change at page 12, line 38 skipping to change at page 12, line 38
Payload Length: Total number of octets in the Payload field. Payload Length: Total number of octets in the Payload field.
Payload: The application layer content of the L3DL PDU. Payload: The application layer content of the L3DL PDU.
Sig Type: The type of the Signature, see Section 22.2. Type 0, a Sig Type: The type of the Signature, see Section 22.2. Type 0, a
null signature, is defined in this document. null signature, is defined in this document.
Sig Type 0 indicates a null Signature. For a trivial PDU such as Sig Type 0 indicates a null Signature. For a trivial PDU such as
KEEPALIVE, the underlying Datagram checksum may be sufficient for KEEPALIVE, the underlying Datagram checksum may be sufficient for
integrity, though it lacks authentication. integrity, though it lacks authenticity.
Other Sig Types may be defined in other documents. Other Sig Types may be defined in other documents, cf.
[I-D.ymbk-lsvr-l3dl-signing].
Signature Length: The length of the Signature, possibly including Signature Length: The length of the Signature, possibly including
padding, in octets. If Sig Type is 0, Signature Length MUST BE 0. padding, in octets. If Sig Type is 0, Signature Length MUST BE 0.
Signature: The result of running the signature algorithm specified Signature: The result of running the signature algorithm specified
in Sig Type over all octets of the PDU except for the Signature in Sig Type over all octets of the PDU except for the Signature
itself. itself.
9. Logical Link Endpoint Identifier 9. Logical Link Endpoint Identifier
skipping to change at page 13, line 18 skipping to change at page 13, line 18
between the two ends of all consenting discovered logical links. A between the two ends of all consenting discovered logical links. A
logical link is described by a pair of Logical Link Endpoint logical link is described by a pair of Logical Link Endpoint
Identifiers, LLEIs. Identifiers, LLEIs.
An LLEI is a variable length descriptor which could be an ASN, a An LLEI is a variable length descriptor which could be an ASN, a
classic RouterID, a catenation of the two, an eight octet ISO System classic RouterID, a catenation of the two, an eight octet ISO System
Identifier [RFC1629], or any other identifier unique to a single Identifier [RFC1629], or any other identifier unique to a single
logical link endpoint in the topology. logical link endpoint in the topology.
An L3DL deployment will choose and define an LLEI which suits its An L3DL deployment will choose and define an LLEI which suits its
needs, simple or complex. Two extremes are as follows: needs, simple or complex. Examples of two extremes follow:
A simplistic view of a link between two devices is two ports, 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
conversation. In this case, the MAC addresses might suffice for the conversation. In this case, the MAC addresses might suffice for the
LLEIs. LLEIs.
Unfortunately, things can get more complex. Multiple VLANs can run Unfortunately, things can get more complex. Multiple VLANs can run
between those two MAC addresses. In practice, many real devices use between those two MAC addresses. In practice, many real devices use
the same MAC address on multiple ports and/or sub-interfaces. the same MAC address on multiple ports and/or sub-interfaces.
skipping to change at page 13, line 47 skipping to change at page 13, line 47
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifIndex | | ifIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
System Identifier, a la [RFC1629], is an eight octet identifier System Identifier, a la [RFC1629], is an eight octet identifier
unique in the entire operational space. Routers and switches usually unique in the entire operational space. Routers and switches usually
have internal MAC Addresses which can be padded with high order zeros 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 and used if no System ID exists on the device. If no unique
identifier is burned into a device, the local L3DL configuration 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.
ifIndex is the SNMP identifier of the (sub-)interface, see [RFC1213]. ifIndex is the SNMP identifier of the (sub-)interface, see [RFC1213].
This uniquely identifies the port. This uniquely identifies the port.
For a layer 3 tagged sub-interface or a VLAN/SVI interface, Ifindex For a layer 3 tagged sub-interface or a VLAN/SVI interface, Ifindex
is that of the logical sub-interface, so no further disambiguation is is that of the logical sub-interface, so no further disambiguation is
needed. needed.
L3DL PDUs learned over VLAN-ports may be interpreted by upper layer-3 L3DL PDUs learned over VLAN-ports may be interpreted by upper layer-3
routing protocols as being learned on the corresponding layer-3 SVI routing protocols as being learned on the corresponding layer-3 SVI
skipping to change at page 14, line 39 skipping to change at page 14, line 39
This destination MAC is to be sent when the interface is known to This destination MAC is to be sent when the interface is known to
be connected to a switch. See Section 23. This SHOULD BE used be connected to a switch. See Section 23. This SHOULD BE used
when the link may be a multi-point link. when the link may be a multi-point link.
All other L3DL PDUs are encapsulated in unicast frames, as the peer's All other L3DL PDUs are encapsulated in unicast frames, as the peer's
destination MAC address is known after the HELLO exchange. destination MAC address is known after the HELLO exchange.
When an interface is turned up on a device, it SHOULD issue a HELLO When an interface is turned up on a device, it SHOULD issue a HELLO
if it is to participate in L3DL sessions. if it is to participate in L3DL sessions.
If a constrained Nearest Bridge destination address is configured for If a constrained Nearest Bridge destination address has been
a point-to-point interface, see above, then the HELLO SHOULD NOT be configured for a point-to-point interface, see above, then the HELLO
repeated once a session has been created by an exchange of OPENs. 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 If the configured destination address is one that is propagated by
switches, the HELLO SHOULD be repeated at a configured interval, with switches, the HELLO SHOULD be repeated at a configured interval, with
a default of 60 seconds. This allows discovery by new devices which a default of 60 seconds. This allows discovery by new devices which
come up on the layer-2 mesh. come up on the layer-2 mesh.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Type = 0 | Payload Length = 0 ~ | PDU Type = 0 | Payload Length = 0 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Sig Type = 0 | Signature Length = 0 | ~ | Sig Type = 0 | Signature Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If more than one device responds, one adjacency is formed for each If more than one device responds, one adjacency is formed for each
unique source LLEI response. L3DL treats each adjacency as a unique source LLEI response. L3DL treats each adjacency as a
separate logical link. separate logical link.
When a HELLO is received from a source MAC address with which there When a HELLO is received from a source MAC address (plus VID if VLAN)
is no established L3DL session, the receiver SHOULD respond with an with which there is no established L3DL session, the receiver SHOULD
OPEN PDU. The two devices establish an L3DL session by exchanging respond by sending an OPEN PDU to the source MAC address (plus VID).
OPEN PDUs. The two devices establish an L3DL session by exchanging OPEN PDUs.
If a HELLO is received from a MAC address with which there is an
established session, the HELLO should be dropped.
The Payload Length is zero as there is no payload. The Payload Length is zero as there is no payload.
HELLO PDUs can not be signed as keying material has yet to be HELLO PDUs can not be signed as keying material has yet to be
exchanged. Hence the signature MUST always be the null type. exchanged. Hence the signature MUST always be the null type.
11. OPEN 11. OPEN
Each device has learned the other's MAC Address from the HELLO Each device has learned the other's MAC Address from the HELLO
exchange, see Section 10. Therefore the OPEN and subsequent PDUs exchange, see Section 10. Therefore the OPEN and all subsequent PDUs
MUST BE unicast, as opposed to the HELLO's multicast frame. MUST BE unicast, as opposed to the HELLO's multicast frame.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Type = 1 | Payload Length ~ | PDU Type = 1 | Payload Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Nonce ~ ~ | Nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | LLEI Length | My LLEI | ~ | LLEI Length | My LLEI |
skipping to change at page 16, line 29 skipping to change at page 16, line 50
A node may have zero or more operator-defined attributes, e.g.: A node may have zero or more operator-defined attributes, e.g.:
spine, leaf, backbone, route reflector, arabica, ... spine, leaf, backbone, route reflector, arabica, ...
Attribute syntax and semantics are local to an operator or Attribute syntax and semantics are local to an operator or
datacenter; hence there is no global registry. Nodes exchange their datacenter; hence there is no global registry. Nodes exchange their
attributes only in the OPEN PDU. attributes only in the OPEN PDU.
Auth Type is the Signature algorithm suite, see Section 8. Auth Type is the Signature algorithm suite, see Section 8.
Key Length is a 16-bit field denoting the length in octets of the Key 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 itself, not including the Auth Type or the Key Length. If the Auth
no Key, the Auth Type and key Length MUST both be zero. 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 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. MUST BE sent (Error Code 3), and HELLOs MUST be restarted.
The Serial Number is that of the last received and processed PDU. 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
receiver wants to resume a session and the sender only needs to send receiver wants to resume a session and the sender only needs to send
data more recent than the Serial Number. If this OPEN is not trying data more recent than the Serial Number. If this OPEN is not trying
to restart a lost session, the Serial Number MUST BE set to zero. to restart a lost session, the Serial Number MUST BE set to zero.
The Signature fields are described in Section 8 and in an asymmetric The Signature fields are described in Section 8 and in an asymmetric
key environment serve as a proof of possession of the signing auth key environment serve as a proof of possession of the signing auth
data by the sender. data by the sender.
skipping to change at page 17, line 25 skipping to change at page 17, line 45
the last data it received. Each party MUST resume sending the last data it received. Each party MUST resume sending
encapsulations etc. subsequent to the other party's Sequence Number. encapsulations etc. subsequent to the other party's Sequence Number.
And each MUST retain all previously discovered encapsulation and And each MUST retain all previously discovered encapsulation and
other data. other data.
If a properly authenticated OPEN arrives with a new Nonce from an If a properly authenticated OPEN arrives with a new Nonce from an
LLEI with which the receiving logical link endpoint believes it LLEI with which the receiving logical link endpoint believes it
already has an L3DL session (OPENs have already been exchanged), and already has an L3DL session (OPENs have already been exchanged), and
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 be previously discovered encapsulation data MUST NOT be kept and MUST BE
withdrawn via the BGP-LS API and the recipient MUST respond with a withdrawn via the BGP-LS API and the recipient MUST respond with a
new OPEN. new OPEN.
12. ACK 12. ACK
The ACK PDU acknowledges receipt of a PDU and reports any error The ACK PDU acknowledges receipt of a PDU and reports any error
condition which might have been raised. condition which might have been raised.
0 1 2 3 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 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
skipping to change at page 18, line 22 skipping to change at page 18, line 45
The decimal value of EType gives a strong hint how the receiver The decimal value of EType gives a strong hint how the receiver
sending the ACK believes things should proceed: sending the ACK believes things should proceed:
0 - No Error, Error Code and Error Hint MUST be zero 0 - No Error, Error Code and Error Hint MUST be zero
1 - Warning, something not too serious happened, continue 1 - Warning, something not too serious happened, continue
2 - Session should not be continued, try to restart 2 - Session should not be continued, try to restart
3 - Restart is hopeless, call the operator 3 - Restart is hopeless, call the operator
4-15 - Reserved 4-15 - Reserved
The Error Codes, noting protocol failures listed in thi document, are The Error Codes, noting protocol failures, are listed in
listed in Section 22.4. Someone stuck in the 1990s might think the Section 22.4. Someone stuck in the 1990s might think the catenation
catenation of EType and Error Code as an echo of 0x1zzz, 0x2zzz, etc. of EType and Error Code as an echo of 0x1zzz, 0x2zzz, etc. They
They might be right; or not. might be right; or not.
The Error Hint is any additional data the sender of the error PDU The Error Hint, an arbitrary 16 bits, is any additional data the
thinks will help the recipient or the debugger with the particular sender of the error PDU thinks will help the recipient or the
error. debugger with the particular error.
The Signature fields are described in Section 8. The Signature fields are described in Section 8.
12.1. Retransmission 12.1. Retransmission
If a PDU sender expects an ACK, e.g. for an OPEN, an Encapsulation, a If a PDU sender expects an ACK, e.g. for an OPEN, an Encapsulation, a
VENDOR PDU, etc., and does not receive the ACK for a configurable VENDOR PDU, etc., and does not receive the ACK for a configurable
time (default one second), and the interface is live at layer 2, the time (default one second), and the interface is live at layer 2, the
sender resends the PDU using exponential back-off, see [RFC1122]. sender resends the PDU using exponential back-off, see [RFC1122].
This cycle MAY be repeated a configurable number of times (default This cycle MAY be repeated a configurable number of times (default
three) before it is considered a failure. The session MAY BE three) before it is considered a failure. The session MAY BE
considered closed in case of this ACK failure. considered closed in case of this ACK failure.
If the link is broken at layer 2, retransmission MAY BE retried when If the link is broken at layer 2, retransmission MAY BE retried when
the link is restored. the link is restored.
13. The Encapsulations 13. The Encapsulations
Once the devices know each other's LLEIs, know each other's upper 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 L3 etc., the L3DL session is considered established, and the devices
interface encapsulations, L3 addresses, and L2.5 labels. SHOULD exchange L3 interface encapsulations, L3 addresses, and L2.5
labels.
The Encapsulation types the peers exchange may be IPv4 The Encapsulation types the peers exchange may be IPv4
(Section 13.3), IPv6 (Section 13.4), MPLS IPv4 (Section 13.6), MPLS (Section 13.3), IPv6 (Section 13.4), MPLS IPv4 (Section 13.6), MPLS
IPv6 (Section 13.7), and/or possibly others not defined here. IPv6 (Section 13.7), and/or possibly others not defined here.
The sender of an Encapsulation PDU MUST NOT assume that the peer is The sender of an Encapsulation PDU MUST NOT assume that the peer is
capable of the same Encapsulation Type. An ACK (Section 12) merely capable of the same Encapsulation Type. An ACK (Section 12) merely
acknowledges receipt. Only if both peers have sent the same acknowledges receipt. Only if both peers have sent the same
Encapsulation Type is it safe to assume that they are compatible for Encapsulation Type is it safe for Layer 3 protocols to assume that
that type. they are compatible for that type.
A receiver of an encapsulation might recognize an addressing 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. layer topology builder deal with what works.
Further, to consider a logical link of a type to formally be Further, to consider a logical link of a type to formally be
established so that it may be pushed up to upper layer protocols, the established so that it may be pushed up to upper layer protocols, the
addressing for the type must be compatible, e.g. on the same IP addressing for the type must be compatible, e.g. on the same IP
subnet. subnet.
13.1. The Encapsulation PDU Skeleton 13.1. The Encapsulation PDU Skeleton
skipping to change at page 20, line 25 skipping to change at page 20, line 52
on media, the PDU is broken into multiple Datagrams. See Section 8. on media, the PDU is broken into multiple Datagrams. See Section 8.
The Signature fields are described in Section 8. The Signature fields are described in Section 8.
The Receiver MUST acknowledge the Encapsulation PDU with a Type=3, The Receiver MUST acknowledge the Encapsulation PDU with a Type=3,
ACK PDU (Section 12) with the Encapsulation Type being that of the ACK PDU (Section 12) with the Encapsulation Type being that of the
encapsulation being announced, see Section 12. encapsulation being announced, see Section 12.
If the Sender does not receive an ACK in a configurable interval If the Sender does not receive an ACK in a configurable interval
(default one second), and the interface is live at layer 2, they (default one second), and the interface is live at layer 2, they
SHOULD retransmit. After a user configurable number of failures, the SHOULD retransmit. After a user configurable number of failures
L3DL session should be considered dead and the OPEN process SHOULD be (default three), the L3DL session should be considered dead and the
restarted. OPEN process SHOULD be restarted.
If the link is broken at layer 2, retransmission MAY BE retried if If the link is broken at layer 2, retransmission MAY BE retried if
data have not changed in the interim. data have not changed in the interim.
13.2. Encapsulaion Flags 13.2. Encapsulaion Flags
The Encapsulation Flags are a sequence of bit fields as follows:
0 1 2 3 4 ... 7 0 1 2 3 4 ... 7
+------------+------------+------------+------------+------------+ +------------+------------+------------+------------+------------+
| Ann/With | Primary | Under/Over | Loopback | Reserved ..| | Ann/With | Primary | Under/Over | Loopback | Reserved ..|
+------------+------------+------------+------------+------------+ +------------+------------+------------+------------+------------+
Each encapsulation in an Encapsulation PDU of Type T may announce new Each encapsulation in an Encapsulation PDU of Type T may announce new
and/or withdraw old encapsulations of Type T. It indicates this with and/or withdraw old encapsulations of Type T. It indicates this with
the Ann/With Encapsulation Flag, Announce == 1, Withdraw == 0. the Ann/With Encapsulation Flag, Announce == 1, Withdraw == 0.
Each Encapsulation interface address in an Encapsulation PDU is Each Encapsulation interface address in an Encapsulation PDU is
either a new encapsulation be announced (Ann/With == 1) (yes, a la either a new encapsulation be announced (Ann/With == 1) (yes, a la
BGP) or requests one be withdrawn (Ann/With == 0). Adding an BGP) or requests one be withdrawn (Ann/With == 0). Adding an
encapsulation which already exists SHOULD raise an Announce/Withdraw encapsulation which already exists SHOULD raise an Announce/Withdraw
Error (see Section 22.4); the EType SHOULD be 2, suggesting a session Error (see Section 22.4); the EType SHOULD be 2, suggesting a session
restart (see Section 12 so all encapsulations will be resent. restart (see Section 12 so all encapsulations will be resent.
If an LLEI has multiple addresses for an encapsulation type, one and If an LLEI has multiple addresses for an encapsulation type, one and
only one address SHOULD be configured to be marked as primary only one address MAY be marked as primary (Primary Flag == 1) for
(Primary Flag == 1). Only one address on an interface MAY be marked that Encapsulation Type.
as primary for a particular encapsulation type.
An Encapsulation interface address in an Encapsulation PDU MAY be An Encapsulation interface address in an Encapsulation PDU MAY be
marked as a loopback, in which case the Loopback bit is set. marked as a loopback, in which case the Loopback bit is set.
Loopback addresses are generally not seen directly on an external Loopback addresses are generally not seen directly on an external
interface. One or more loopback addresses MAY be exposed by interface. One or more loopback addresses MAY be exposed by
configuration on one or more L3DL speaking external interfaces, e.g. configuration on one or more L3DL speaking external interfaces, e.g.
for iBGP peering. They SHOULD be marked as such, Loopback Flag == 1. for iBGP peering. They SHOULD be marked as such, Loopback Flag == 1.
Each Encapsulation interface address in an Encapsulation PDU is that Each Encapsulation interface address in an Encapsulation PDU is that
of the direct 'underlay interface (Under/Over == 1), or an 'overlay' of the direct 'underlay interface (Under/Over == 1), or an 'overlay'
skipping to change at page 21, line 42 skipping to change at page 22, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encaps Flags | IPv4 Address ~ | Encaps Flags | IPv4 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | PrefixLen | more ... | Sig Type | ~ | PrefixLen | more ... | Sig Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | Signature ... | | Signature Length | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 24-bit Count is the number of IPv4 Encapsulations being announced The 24-bit Count is the sum of the number of IPv4 Encapsulations
and/or withdrawn. being announced and/or withdrawn.
13.4. IPv6 Encapsulation 13.4. IPv6 Encapsulation
The IPv6 Encapsulation describes a logical link's ability to exchange The IPv6 Encapsulation describes a logical link's ability to exchange
IPv6 packets on one or more subnets. It does so by stating the IPv6 packets on one or more subnets. It does so by stating the
interface's addresses and the corresponding prefix lengths. interface's addresses and the corresponding prefix lengths.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 26 skipping to change at page 23, line 4
| | | |
+ + + +
| | | |
+ + + +
| IPv6 Address | | IPv6 Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PrefixLen | more ... | Sig Type | | | PrefixLen | more ... | Sig Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | Signature ... | | Signature Length | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 24-bit Count is the sum of the number of IPv6 Encapsulations
The 24-bit Count is the number of IPv6 Encapsulations being announced being announced and/or withdrawn.
and/or withdrawn.
13.5. MPLS Label List 13.5. MPLS Label List
As an MPLS enabled interface may have a label stack, see [RFC3032], a As an MPLS enabled interface may have a label stack, see [RFC3032], a
variable length list of labels is needed. These are the labels the variable length list of labels is needed. These are the labels the
sender will accept for the prefix to which the list is attached. sender will accept for the prefix to which the list is attached.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 23 skipping to change at page 23, line 49
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encaps Flags | MPLS Label List ... | ~ | Encaps Flags | MPLS Label List ... | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv4 Address | PrefixLen | ~ IPv4 Address | PrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more ... | Sig Type | Signature Length | | more ... | Sig Type | Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature | | Signature |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 24-bit Count is the number of MPLSv4 Encapsulation being The 24-bit Count is the sum of the number of MPLSv4 Encapsulation
announced and/or withdrawns. being announced and/or withdrawns.
13.7. MPLS IPv6 Encapsulation 13.7. MPLS IPv6 Encapsulation
The MPLS IPv4 Encapsulation describes a logical link's ability to The MPLS IPv6 Encapsulation describes a logical link's ability to
exchange labeled IPv4 packets on one or more subnets. It does so by exchange labeled IPv6 packets on one or more subnets. It does so by
stating the interface's addresses, the corresponding prefix lengths, stating the interface's addresses, the corresponding prefix lengths,
and the corresponding labels which will be accepted for each address. and the corresponding labels which will be accepted for each address.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Type = 7 | Payload Length ~ | PDU Type = 7 | Payload Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Count | ~ | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 29 skipping to change at page 24, line 36
+ + + +
| IPv6 Address | | IPv6 Address |
+ +-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+
| | Prefix Len | | | Prefix Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more ... | Sig Type | Signature Length | | more ... | Sig Type | Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature ... | | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 24-bit Count is the number of MPLSv6 Encapsulations being The 24-bit Count is the sum of the number of MPLSv6 Encapsulations
announced and/or withdrawn. being announced and/or withdrawn.
14. VENDOR - Vendor Extensions 14. VENDOR - Vendor Extensions
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Type = 255| Payload Length ~ | PDU Type = 255| Payload Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Serial Number ~ ~ | Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Enterprise Number | ~ | Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent Type | Enterprise Data ... ~ | Ent Type | Enterprise Data ... ~
skipping to change at page 25, line 25 skipping to change at page 25, line 43
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Type = 2 | Payload Length = 0 ~ | PDU Type = 2 | Payload Length = 0 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Sig Type = 0 | Signature Length = 0 | ~ | Sig Type = 0 | Signature Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L3DL devices SHOULD beacon frequent Layer 2 KEEPALIVE PDUs to ensure L3DL devices SHOULD beacon frequent Layer 2 KEEPALIVE PDUs to ensure
session continuity. A receiver may choose to ignore KEEPALIVE PDUs. session continuity. The inter-KEEPALIVE interval is configurable,
with a default of ten seconds. A receiver may choose to ignore
KEEPALIVE PDUs.
An operational deployment MUST BE configured whether to use 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 and
reestablishment. reestablishment.
KEEPALIVEs SHOULD be beaconed at a configured frequency. One per 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
(or less) aggressive. (or less) aggressive.
When a sender transmits a PDU which is not a KEEPALIVE, the sender When a sender transmits a PDU which is not a KEEPALIVE, the sender
SHOULD reset the KEEPALIVE timer. I.e. sending any PDU acts as a SHOULD reset the KEEPALIVE timer. I.e. sending any PDU acts as a
keepalive. Once the last fragment has been sent, the KEEPALIVE timer keepalive. Once the last fragment has been sent, the KEEPALIVE timer
SHOULD BE restarted. Do not wait for the ACK. SHOULD BE restarted. Do not wait for the ACK.
skipping to change at page 27, line 29 skipping to change at page 27, line 46
18.1. HELLO Discussion 18.1. HELLO Discussion
A device with multiple Layer 2 interfaces, traditionally called a A device with multiple Layer 2 interfaces, traditionally called a
switch, may be used to forward frames and therefore packets from switch, may be used to forward frames and therefore packets from
multiple devices to one logical interface (LLEI), I, on an L3DL multiple devices to one logical interface (LLEI), I, on an L3DL
speaking device. Interface I could discover a peer J across the speaking device. Interface I could discover a peer J across the
switch. Later, a prospective peer K could come up across the switch. switch. Later, a prospective peer K could come up across the switch.
If I was not still sending and listening for HELLOs, the potential If I was not still sending and listening for HELLOs, the potential
peering with K could not be discovered. Therefore, on multi-link peering with K could not be discovered. Therefore, on multi-link
interfaces MUST continue to send HELLOs as long as they are turned interfaces, L3DL MUST continue to send HELLOs as long as they are
up. turned up.
18.2. HELLO versus KEEPALIVE 18.2. HELLO versus KEEPALIVE
Both HELLO and KEEPALIVE are periodic. KEEPALIVE might be eliminated Both HELLO and KEEPALIVE are periodic. KEEPALIVE might be eliminated
in favor of keeping only HELLOs. But KEEPALIVEs are unicast, and in favor of keeping only HELLOs. But KEEPALIVEs are unicast, and
thus less noisy on the network, especially if HELLO is configured to thus less noisy on the network, especially if HELLO is configured to
transit layer-2-only switches, see Section 18.1. transit layer-2-only switches, see Section 18.1.
19. VLANs/SVIs/Sub-interfaces 19. VLANs/SVIs/Sub-interfaces
skipping to change at page 28, line 7 skipping to change at page 28, line 29
L3DL PDUs learned over VLAN-ports may be interpreted by upper layer-3 L3DL PDUs learned over VLAN-ports may be interpreted by upper layer-3
routing protocols as being learned on the corresponding layer-3 SVI routing protocols as being learned on the corresponding layer-3 SVI
interface for the VLAN. interface for the VLAN.
As Sub-Interfaces each have their own LLIEs, they act as separate As Sub-Interfaces each have their own LLIEs, they act as separate
interfaces, forming their own links. interfaces, forming their own links.
20. Implementation Considerations 20. Implementation Considerations
An implementation SHOULD provide the ability to configure a logical An implementation SHOULD provide the ability to configure each
interface as L3DL speaking or not. logical interface as L3DL speaking or not.
An implementation SHOULD provide the ability to configure whether An implementation SHOULD provide the ability to configure whether
HELLOs on an L3DL enabled interface send Nearest Bridge or the MAC HELLOs on an L3DL enabled interface send Nearest Bridge or the MAC
which is propagated by switches from that interface; see Section 10. which is propagated by switches from that interface; see Section 10.
An implementation SHOULD provide the ability to distribute one or An implementation SHOULD provide the ability to distribute one or
more loopback addresses or interfaces into L3DL on an external L3DL more loopback addresses or interfaces into L3DL on an external L3DL
speaking interface. speaking interface.
An implementation SHOULD provide the ability to distribute one or An implementation SHOULD provide the ability to distribute one or
skipping to change at page 28, line 34 skipping to change at page 29, line 8
interface. If there is only one address for a particular interface. If there is only one address for a particular
encapsulation, the implementation MAY mark it as primary by default. encapsulation, the implementation MAY mark it as primary by default.
An implementation MAY allow optional configuration which updates the An implementation MAY allow optional configuration which updates the
local forwarding table with overlay and underlay data both learned local forwarding table with overlay and underlay data both learned
from L3DL peers and configured locally. from L3DL peers and configured locally.
21. Security Considerations 21. Security Considerations
The protocol as is MUST NOT be used outside a datacenter or similarly The protocol as is MUST NOT be used outside a datacenter or similarly
closed environment due to lack of formal definition of the closed environment without authentication ans authorisation
authentication and authorization mechanism. Sufficient mechanisms mechanisms such as [I-D.ymbk-lsvr-l3dl-signing].
may be described in separate documents.
Many MDC operators have a strange belief that physical walls and 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 surface. MDC protocols need to be examined for exposure and attack surface.
In the case of L3DL, Authentication and Integrity as provided in In the case of L3DL, Authentication and Integrity as provided in
[draft-ymbk-l3dl-signing] is strongly recommended. [I-D.ymbk-lsvr-l3dl-signing] is strongly recommended.
It is generally unwise to assume that on the wire Layer 2 is secure. It is generally unwise to assume that on the wire Layer 2 is secure.
Strange/unauthorized devices may plug into a port. Mis-wiring is Strange/unauthorized devices may plug into a port. Mis-wiring is
very common in datacenter installations. A poisoned laptop might be very common in datacenter installations. A poisoned laptop might be
plugged into a device's port, form malicious sessions, etc. to plugged into a device's port, form malicious sessions, etc. to
divert, intercept, or drop traffic. divert, intercept, or drop traffic.
Similarly, malicious nodes/devices could mis-announce addressing. Similarly, malicious nodes/devices could mis-announce addressing.
If OPENs are not being authenticated, an attacker could forge an OPEN If OPENs are not being authenticated, an attacker could forge an OPEN
skipping to change at page 30, line 33 skipping to change at page 31, line 11
This document requests the IANA create a registry for L3DL Error This document requests the IANA create a registry for L3DL Error
Codes, a 16 bit integer. The name of the registry should be L3DL- Codes, a 16 bit integer. The name of the registry should be L3DL-
Error-Codes. The policy for adding to the registry is RFC Required Error-Codes. The policy for adding to the registry is RFC Required
per [RFC5226], either standards track or experimental. The initial per [RFC5226], either standards track or experimental. The initial
entries should be the following: entries should be the following:
Error Error
Code Error Name Code Error Name
---- ------------------- ---- -------------------
0 No Error 0 No Error
1 Logical Link Addressing Conflict 1 Checksum Error
2 Authorization Failure in OPEN 2 Logical Link Addressing Conflict
3 Signature Failure in PDU 3 Authorization Failure
4 Announce/Withdraw Error 4 Announce/Withdraw Error
23. IEEE Considerations 23. IEEE Considerations
This document requires a new EtherType. This document requires a new EtherType.
This document requires a new multicast MAC address that will be This document requires a new multicast MAC address that will be
broadcast through a switch. broadcast through a switch.
24. Acknowledgments 24. Acknowledgments
The authors thank Cristel Pelsser for multiple reviews, Harsha Kovuru The authors thank Cristel Pelsser for multiple reviews, Harsha Kovuru
for comments during implementation, Jeff Haas for review and for comments during implementation, Jeff Haas for review and
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 clue, serious review and comments, Larry Kreeger for a lot of layer 2 clue,
Martijn Schmidt for his contribution, Neeraj Malhotra for review, Martijn Schmidt for his contribution, Nalinaksh Pai for transport
Russ Housley for checksum discussion and sBox, and Steve Bellovin for discussions, Neeraj Malhotra for review, Paul Congdon for Ethernet
checksum advice. hints, Russ Housley for checksum discussion and sBox, and Steve
Bellovin for checksum advice.
25. References 25. References
25.1. Normative References 25.1. Normative References
[I-D.ietf-idr-bgp-ls-segment-routing-ext] [I-D.ietf-idr-bgp-ls-segment-routing-ext]
Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H.,
and M. Chen, "BGP Link-State extensions for Segment and M. Chen, "BGP Link-State extensions for Segment
Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16
(work in progress), June 2019. (work in progress), June 2019.
[I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,
S., and J. Dong, "BGP-LS extensions for Segment Routing S., and J. Dong, "BGP-LS extensions for Segment Routing
BGP Egress Peer Engineering", draft-ietf-idr-bgpls- BGP Egress Peer Engineering", draft-ietf-idr-bgpls-
segment-routing-epe-19 (work in progress), May 2019. segment-routing-epe-19 (work in progress), May 2019.
[I-D.ietf-lsvr-bgp-spf] [I-D.ietf-lsvr-bgp-spf]
Patel, K., Lindem, A., Zandi, S., and W. Henderickx, Patel, K., Lindem, A., Zandi, S., and W. Henderickx,
"Shortest Path Routing Extensions for BGP Protocol", "Shortest Path Routing Extensions for BGP Protocol",
draft-ietf-lsvr-bgp-spf-04 (work in progress), December draft-ietf-lsvr-bgp-spf-06 (work in progress), September
2018. 2019.
[I-D.ymbk-lsvr-l3dl-signing]
Bush, R. and R. Austein, "Layer 3 Discovery and Liveness
Signing", draft-ymbk-lsvr-l3dl-signing-00 (work in
progress), October 2019.
[IANA-PEN] [IANA-PEN]
"IANA Private Enterprise Numbers", "IANA Private Enterprise Numbers",
<https://www.iana.org/assignments/enterprise-numbers/ <https://www.iana.org/assignments/enterprise-numbers/
enterprise-numbers>. enterprise-numbers>.
[IEEE.802_2001] [IEEE.802_2001]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE 802-2001, Networks: Overview and Architecture", IEEE 802-2001,
DOI 10.1109/ieeestd.2002.93395, July 2002, DOI 10.1109/ieeestd.2002.93395, July 2002,
skipping to change at page 33, line 29 skipping to change at page 34, line 14
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996,
<http://www.rfc-editor.org/info/rfc1982>.
Authors' Addresses Authors' Addresses
Randy Bush Randy Bush
Arrcus & Internet Initiative Japan Arrcus & Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, WA 98110 Bainbridge Island, WA 98110
US US
Email: randy@psg.com Email: randy@psg.com
 End of changes. 82 change blocks. 
138 lines changed or deleted 184 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/