< draft-ietf-lsvr-l3dl-01.txt   draft-ietf-lsvr-l3dl-02.txt >
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Arrcus & IIJ Internet-Draft Arrcus & Internet Initiative Japan
Intended status: Standards Track R. Austein Intended status: Standards Track R. Austein
Expires: December 14, 2019 K. Patel Expires: January 8, 2020 K. Patel
Arrcus Arrcus
June 12, 2019 July 7, 2019
Layer 3 Discovery and Liveness Layer 3 Discovery and Liveness
draft-ietf-lsvr-l3dl-01 draft-ietf-lsvr-l3dl-02
Abstract Abstract
In Massive Data Centers (MDCs), BGP-SPF and similar routing protocols In Massive Data Centers, BGP-SPF and similar routing protocols are
are used to build topology and reachability databases. These used to build topology and reachability databases. These protocols
protocols need to discover IP Layer 3 attributes of links, such as need to discover IP Layer 3 attributes of links, such as logical link
logical link IP encapsulation abilities, IP neighbor address IP encapsulation abilities, IP neighbor address discovery, and link
discovery, and link liveness. The Layer 3 Discovery and Liveness liveness. This Layer 3 Discovery and Liveness protocol collects
protocol specified in this document collects these data, which are these data, which may then be disseminated using BGP-SPF and similar
then 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 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 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
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 December 14, 2019. This Internet-Draft will expire on January 8, 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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . 6
5.1. L3DL Ladder Diagram . . . . . . . . . . . . . . . . . . . 7 5.1. L3DL Ladder Diagram . . . . . . . . . . . . . . . . . . . 7
6. Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 8 6. Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 8
7. The Checksum . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 18 12.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 18
13. The Encapsulations . . . . . . . . . . . . . . . . . . . . . 18 13. The Encapsulations . . . . . . . . . . . . . . . . . . . . . 18
13.1. The Encapsulation PDU Skeleton . . . . . . . . . . . . . 19 13.1. The Encapsulation PDU Skeleton . . . . . . . . . . . . . 19
13.2. Encapsulaion Flags . . . . . . . . . . . . . . . . . . . 20 13.2. Encapsulaion Flags . . . . . . . . . . . . . . . . . . . 20
13.3. IPv4 Encapsulation . . . . . . . . . . . . . . . . . . . 21 13.3. IPv4 Encapsulation . . . . . . . . . . . . . . . . . . . 21
13.4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 21 13.4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 21
13.5. MPLS Label List . . . . . . . . . . . . . . . . . . . . 22 13.5. MPLS Label List . . . . . . . . . . . . . . . . . . . . 22
13.6. MPLS IPv4 Encapsulation . . . . . . . . . . . . . . . . 22 13.6. MPLS IPv4 Encapsulation . . . . . . . . . . . . . . . . 22
13.7. MPLS IPv6 Encapsulation . . . . . . . . . . . . . . . . 23 13.7. MPLS IPv6 Encapsulation . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . 26
17.2. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . 26 17.2. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . 26
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 . . . . . . . . . . . . . . . . . 27
19. VLANs/SVIs/Sub-interfaces . . . . . . . . . . . . . . . . . . 27 19. VLANs/SVIs/Sub-interfaces . . . . . . . . . . . . . . . . . . 27
20. Implementation Considerations . . . . . . . . . . . . . . . . 27 20. Implementation Considerations . . . . . . . . . . . . . . . . 28
21. Security Considerations . . . . . . . . . . . . . . . . . . . 28 21. Security Considerations . . . . . . . . . . . . . . . . . . . 28
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 . . . . . . . . . . . . . . . . . . . . . 29
22.3. Flag Bits . . . . . . . . . . . . . . . . . . . . . . . 29 22.3. Flag Bits . . . . . . . . . . . . . . . . . . . . . . . 30
22.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . 30 22.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . 30
23. IEEE Considerations . . . . . . . . . . . . . . . . . . . . . 30 23. IEEE Considerations . . . . . . . . . . . . . . . . . . . . . 30
24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
25. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 25. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
25.1. Normative References . . . . . . . . . . . . . . . . . . 30 25.1. Normative References . . . . . . . . . . . . . . . . . . 31
25.2. Informative References . . . . . . . . . . . . . . . . . 32 25.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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) devices, while its homogeneity presents of scale, e.g. O(10,000) forwarding devices, while its homogeneity
opportunities for simple approaches. Approaches such as Jupiter presents opportunities for simple approaches. Approaches such as
Rising [JUPITER] use a central controller to deal with scaling, while Jupiter Rising [JUPITER] use a central controller to deal with
BGP-SPF [I-D.ietf-lsvr-bgp-spf] provides massive scale-out without scaling, while BGP-SPF [I-D.ietf-lsvr-bgp-spf] provides massive
centralization using a tried and tested scalable distributed control scale-out without centralization using a tried and tested scalable
plane, offering a scalable routing solution in Clos [Clos0][Clos1] distributed control plane, offering a scalable routing solution in
and similar environments. But BGP-SPF and similar higher level Clos [Clos0][Clos1] and similar environments. But BGP-SPF and
device-spanning protocols, e.g. [I-D.malhotra-bess-evpn-lsoe], need similar higher level device-spanning protocols, e.g.
logical link state and addressing data from the network to build the [I-D.malhotra-bess-evpn-lsoe], need logical link state and addressing
routing topology. They also need prompt but prudent reaction to data from the network to build the routing topology. They also need
(logical) link failure. prompt but prudent reaction to (logical) link failure.
Layer 3 Discovery and Liveness (L3DL) provides brutally simple Layer 3 Discovery and Liveness (L3DL) provides brutally simple
mechanisms for devices to mechanisms for devices to
o Discover unique identities of devices/ports/... on a logical link,
o Run Layer 2 keep-alive messages for session continuity,
o Discover each other's unique endpoint identification, o Discover each other's unique endpoint identification,
o Discover mutually supported 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 Enable layer 3 link liveness such as BFD, and finally
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 Provide Layer 2 keep-alive messages for session continuity.
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:
ASN: Autonomous System Number [RFC4271], a BGP identifier for ASN: Autonomous System Number [RFC4271], a BGP identifier for
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 SPF BGP-SPF A hybrid protocol using BGP transport but a Dijkstra
decision process. See [I-D.ietf-lsvr-bgp-spf]. Shortest Path First decision process. See
[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. A full L3DL
PDU may be packaged in multiple Datagrams. 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, ... and 3 addresses such as IPv4, IPv6, MPLS, etc.
Frame: A Layer 2 packet. Frame: A Layer 2 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 thousands of TORs. MDC: Massive Data Center, commonly composed of thousands of Top
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 may need to be broken into multiple Datagrams to make
it through MTU or other restrictions. 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,
skipping to change at page 5, line 36 skipping to change at page 5, line 34
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 hot restart, a la BGP ([RFC4271]). announcement and widrawal 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 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
skipping to change at page 6, line 30 skipping to change at page 6, line 30
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
|+--------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 per-link layer 3 discovery
and the interface to the upper level BGP-like API: and the API to the upper level BGP-like routing prototol:
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 and 3 identifiers (not payloads), e.g.
device IDs, port identities, VLAN IDs, Encapsulations, and IP 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 allow discovery of new sending multicast HELLO PDUs (Section 10). To assure discovery of
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 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 peering by sending unicast OPEN PDUs (Section 11). In and establish a session by sending unicast OPEN PDUs (Section 11).
an established peering, the Encapsulations (Section 13) configured on In an established session, the Encapsulations (Section 13) configured
an end point may be announced and modified. Note that these are only on an end point may be announced and modified. Note that these are
the encapsuation and addresses on the announcing interface; though a only the encapsuation and addresses configured on the announcing
device's loopback interface(s) may also be announced. When two interface; though a device's loopback and overlay interface(s) may
devices on a link have compatible Encapsulations and addresses, i.e. also be announced. When two devices on a link have compatible
the same AFI/SAFI and the same subnet, the link is announced via the Encapsulations and addresses, i.e. the same AFI/SAFI and the same
BGP-LS API. 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. It is a small L3DL PDU
encapsulated in an Ethernet multicast frame with the simple goal of encapsulated in an Ethernet multicast frame with the simple goal of
discovering the identities of logical link endpoint(s) reachable from discovering the identities of logical link endpoint(s) reachable from
a Logical Link Endpoint, Section 9. 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 sketch 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.
|---------------------------->| |---------------------------->|
skipping to change at page 8, line 49 skipping to change at page 8, line 49
|---------------------------->| |---------------------------->|
| | | |
| | | |
| 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 long L3DL PDUs are carried by a simple transport layer which allows PDUs
PDUs to occupy many Ethernet frames. An L3DL frame is referred to as to occupy many Ethernet frames. An L3DL Ethernet frame is referred
a Datagram. 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.
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 |L| Datagram Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datagram Length | Checksum ~ | Datagram Length | Checksum ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Payload... | ~ | 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 are treated as errors. The protocol version Values other than 0 MUST BE treated as an error. The protocol
nees to be in one and only one place, so it is in the datagram as version nees to be in one and only one place, so it is in the
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].
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.
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.
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
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.
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.
The following code describes the suggested algorithm. The following code describes the suggested algorithm.
skipping to change at page 12, line 21 skipping to change at page 12, line 21
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 | Payload Length ~ | PDU Type | Payload Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Payload ... | ~ | Payload ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig Type | Signature Length | ~ | Sig Type | Signature Length | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ Signature | ~ Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the basic L3DL header are as follows: The fields of the basic L3DL header are as follows:
PDU Type: An integer differentiating PDU payload types. See PDU Type: An integer differentiating PDU payload types. See
Section 22.1. Section 22.1.
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.
skipping to change at page 12, line 43 skipping to change at page 12, line 43
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 authentication.
Other Sig Types may be defined in other documents. Other Sig Types may be defined in other documents.
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
L3DL discovers neighbors on logical links and establishes sessions L3DL discovers neighbors on logical links and establishes sessions
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
skipping to change at page 14, line 17 skipping to change at page 14, line 17
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
interface for the VLAN. interface for the VLAN.
LLEIs are big-endian. LLEIs are big-endian.
10. HELLO 10. HELLO
WARNING: The second multicast address below is incorrect. We need to
get a new assignment. , which is what we really wanted with the
second address below.
The HELLO PDU is unique in that it is encapsulated in a multicast The HELLO PDU is unique in that it is encapsulated in a multicast
Ethernet frame. It solicits response(s) from other LLEI(s) on the Ethernet frame. It solicits response(s) from other LLEI(s) on the
link. See Section 18.1 for why multicast is used. The destination link. See Section 18.1 for why multicast is used. The destination
multicast MAC Addressees to be used MUST be one of the following, See multicast MAC Addressees to be used MUST be one of the following, See
Clause 9.2.2 of [IEEE802-2014]: Clause 9.2.2 of [IEEE802-2014]:
01-80-C2-00-00-0E: Nearest Bridge = Propagation constrained to a 01-80-C2-00-00-0E: Nearest Bridge = Propagation constrained to a
single physical link; stopped by all types of bridges (including single physical link; stopped by all types of bridges (including
MPRs (media converters)). MPRs (media converters)). This SHOULD BE used when the link is
known to be a simple point to point link.
To Be Assigned: When a switch receives a frame with a multicast To Be Assigned: When a switch receives a frame with a multicast
destination MAC it does not recognize, it forwards to all ports. destination MAC it does not recognize, it forwards to all ports.
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. be connected to a switch. See Section 23. This SHOULD BE used
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 a constrained destination address configured, see above, then the If a constrained Nearest Bridge destination address is configured for
HELLO need not be repeated once a session has been created by an a point-to-point interface, see above, then the HELLO SHOULD NOT be
exchange of OPENs. 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 with which there
is no established L3DL adjacency, the receiver SHOULD respond with an is no established L3DL session, the receiver SHOULD respond with an
OPEN PDU. The two devices establish an L3DL adjacency by exchanging OPEN PDU. The two devices establish an L3DL session by exchanging
OPEN PDUs. OPEN PDUs.
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 are exchange, see Section 10. Therefore the OPEN and subsequent PDUs
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 16 skipping to change at page 16, line 16
final signature fields. final signature fields.
The Nonce enables detection of a duplicate OPEN PDU. It SHOULD be The Nonce enables detection of a duplicate OPEN PDU. It SHOULD be
either a random number or a high resolution timestamp. It is needed either a random number or a high resolution timestamp. It is needed
to prevent session closure due to a repeated OPEN caused by a race or to prevent session closure due to a repeated OPEN caused by a race or
a dropped or delayed ACK. a dropped or delayed ACK.
My LLEI is the sender's LLEI, see Section 9. My LLEI is the sender's LLEI, see Section 9.
AttrCount is the number of attributes in the Attribute List. AttrCount is the number of attributes in the Attribute List.
Attributes are single octets whose semantics are user-defined. Attributes are single octets the semantics of which are operator-
defined.
A node may have zero or more user-defined attributes, e.g. spine, A node may have zero or more operator-defined attributes, e.g.:
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 Lengths. If there is 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. no Key, the Auth Type and key Length MUST both be zero.
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 is authenticate is a failure to start the L3DL session, an ERROR PDU
sent (Error Code 2), and HELLOs MUST be restarted. MUST BE sent (Error Code 2), and HELLOs MUST be restarted.
The Serial Number is that of the last received and processed The Serial Number is that of the last received and processed PDU.
Encapsulation PDU. This allows a receiver sending an OPEN to tell This allows a receiver sending an OPEN to tell the sender that the
the sender that the receiver wants to resume a session and the sender receiver wants to resume a session and the sender only needs to send
only needs to send data more recent than the Serial Number. If this data more recent than the Serial Number. If this OPEN is not trying
OPEN is not trying to restart a lost session, the Serial Number MUST to restart a lost session, the Serial Number MUST BE set to zero.
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.
Once two logical link endpoints know each other, and have ACKed each Once two logical link endpoints know each other, and have ACKed each
other's OPEN PDUs, Layer 2 KEEPALIVEs (see Section 15) MAY be started other's OPEN PDUs, Layer 2 KEEPALIVEs (see Section 15) MAY be started
to ensure Layer 2 liveness and keep the session semantics alive. The to ensure Layer 2 liveness and keep the session semantics alive. The
timing and acceptable drop of KEEPALIVE PDUs are discussed in timing and acceptable drop of KEEPALIVE PDUs are discussed in
Section 15. Section 15.
If a sender of OPEN does not receive an ACK of the OPEN PDU Type, If a sender of OPEN does not receive an ACK of the OPEN PDU, then
then they MUST resend the same OPEN PDU, with the same Nonce. they MUST resend the same OPEN PDU, with the same Nonce. Resending
Resending an unacknowledged OPEN PDU, like other ACKed PDUs, SHOULD an unacknowledged OPEN PDU, like other ACKed PDUs, SHOULD use
use exponential back-off, see [RFC1122]. exponential back-off, see [RFC1122].
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), the already has an L3DL session (OPENs have already been exchanged), and
receiver MAY assume that the sending LLEI or entire device has been the Serial Number in the OPEN is non-zero, the receiver SHOULD
reset. If the Serial Number in the OPEN is zero, then all discovered establish a new session by sending an OPEN with the Serial Number of
encapsulation data SHOULD be withdrawn via the BGP-LS API and the the last data it received. Each party MUST resume sending
recipient MUST respond with a new OPEN. In this circumstance encapsulations etc. subsequent to the other party's Sequence Number.
encapsulations SHOULD NOT be kept. And each MUST retain all previously discovered encapsulation and
other data.
If a properly authenticated OPEN arrives with a new Nonce from an
LLEI with which the receiving logical link endpoint believes it
already has an L3DL session (OPENs have already been exchanged), and
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 a
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Type = 3 | Payload Length = 5 ~ | PDU Type = 3 | Payload Length = 5 ~
skipping to change at page 17, line 40 skipping to change at page 17, line 50
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Hint | Sig Type |Signature Leng.~ | Error Hint | Sig Type |Signature Leng.~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Signature ... | ~ | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ACK acknowledges receipt of an OPEN, Encapsulation, VENDOR PDU, The ACK acknowledges receipt of an OPEN, Encapsulation, VENDOR PDU,
etc. etc.
The ACKed PDU is the PDU Type of the PDU being acknowledged, e.g., The ACKed PDU is the PDU Type of the PDU being acknowledged, e.g.,
OPEN or one of the Encapsulations. OPEN, one of the Encapsulations, etc.
If there was an error processing the received PDU, then the EType is If there was an error processing the received PDU, then the EType is
non-zero. If the EType is zero, Error Code and Error Hint MUST also non-zero. If the EType is zero, Error Code and Error Hint MUST also
be zero. be zero.
A non-zero EType is the receiver's way of telling the PDU's sender A non-zero EType is the receiver's way of telling the PDU's sender
that the receiver had problems processing the PDU. The Error Code that the receiver had problems processing the PDU. The Error Code
and Error Hint will tell the sender more detail about the error. and Error Hint will tell the sender more detail about the error.
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. The ETypes are sending the ACK believes things should proceed:
listed in Section 22.4. Someone stuck in the 1990s might think of
the error codes as 0x1zzz, 0x2zzz, etc. They might be right. Or
not.
The Error Code indicates the type of error. 0 - No Error, Error Code and Error Hint MUST be zero
1 - Warning, something not too serious happened, continue
2 - Session should not be continued, try to restart
3 - Restart is hopeless, call the operator
4-15 - Reserved
The Error Codes, noting protocol failures listed in thi document, are
listed in Section 22.4. 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 is any additional data the sender of the error PDU The Error Hint is any additional data the sender of the error PDU
thinks will help the recipient or the debugger with the particular thinks will help the recipient or the debugger with the particular
error. 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 comes back up if data have not changed in the interim. 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 identities, have means to ensure link state, etc., the L3DL
session is considered established, and the devices SHOULD exchange L3 session is considered established, and the devices SHOULD exchange L3
interface encapsulations, L3 addresses, and L2.5 labels. interface encapsulations, L3 addresses, and L2.5 labels.
The Encapsulation types the peers exchange may be IPv4 Announcement The Encapsulation types the peers exchange may be IPv4
(Section 13.3), IPv6 Announcement (Section 13.4), MPLS IPv4 (Section 13.3), IPv6 (Section 13.4), MPLS IPv4 (Section 13.6), MPLS
Announcement (Section 13.6), MPLS IPv6 Announcement (Section 13.7), IPv6 (Section 13.7), and/or possibly others not defined here.
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 to assume that they are compatible for
that type. 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
skipping to change at page 19, line 28 skipping to change at page 19, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Count | ~ | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation List... | Sig Type | | Encapsulation List... | Sig Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | Signature ... | | Signature Length | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 24-bit Count is the number of Encapsulations in the Encapsulation
list.
An Encapsulation PDU describes zero or more addresses of the An Encapsulation PDU describes zero or more addresses of the
encapsulation type. encapsulation type.
The 24-bit Count is the number of Encapsulations in the Encapsulation
list.
The Serial Number is a monotonically increasing 32-bit value The Serial Number is a monotonically increasing 32-bit value
representing the sender's state in time. It may be an integer, a representing the sender's state in time. It may be an integer, a
timestamp, etc. On session restart (new OPEN), a receiver MAY send timestamp, etc. On session restart (new OPEN), a receiver MAY send
the last received Session Number to tell the sender to only send the last received Session Number to tell the sender to only send
newer data. newer data.
If a sender has multiple links on the same interface, separate state: If a sender has multiple links on the same interface, separate state:
data, ACKs, etc. must be kept for each peer. data, ACKs, etc. must be kept for each peer session.
Over time, multiple Encapsulation PDUs may be sent for an interface Over time, multiple Encapsulation PDUs may be sent for an interface
as configuration changes. as configuration changes.
If the length of an Encapsulation PDU exceeds the Datagram size limit If the length of an Encapsulation PDU exceeds the Datagram size limit
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,
skipping to change at page 20, line 25 skipping to change at page 20, line 39
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
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 ..|
+------------+------------+------------+------------+------------+ +------------+------------+------------+------------+------------+
An Encapsulation PDU of Type T may announce new and/or withdraw old Each encapsulation in an Encapsulation PDU of Type T may announce new
encapsulations of Type T. It indicates this with the Ann/With and/or withdraw old encapsulations of Type T. It indicates this 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 SHOULD be configured to be marked as primary
skipping to change at page 20, line 43 skipping to change at page 21, line 9
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 SHOULD be configured to be marked as primary
(Primary Flag == 1). Only one address on an interface MAY be marked (Primary Flag == 1). Only one address on an interface MAY be marked
as primary for a particular 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'
address (Under/Over == 0), likely that of a VM or container guest address (Under/Over == 0), likely that of a VM or container guest
bridged on to the interface with an underlay address. bridged or configured on to the interface already having an underlay
address.
13.3. IPv4 Encapsulation 13.3. IPv4 Encapsulation
The IPv4 Encapsulation describes a device's ability to exchange IPv4 The IPv4 Encapsulation describes a device's ability to exchange IPv4
packets on one or more subnets. It does so by stating the 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 21, line 27 skipping to change at page 21, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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. The 24-bit Count is the number of IPv4 Encapsulations 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 27 skipping to change at page 22, line 27
+ + + +
| | | |
+ + + +
| IPv6 Address | | IPv6 Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PrefixLen | more ... | Sig Type | | | PrefixLen | more ... | Sig Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length | Signature ... | | Signature Length | Signature ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 24-bit Count is the number of IPv6 Encapsulations. The 24-bit Count is the number of IPv6 Encapsulations being announced
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. variable length list of labels is needed. These are the labels the
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Count | Label | Exp |S| | Label Count | Label | Exp |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| more ... | | Label | Exp |S| more ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Label Count of zero is an implicit withdraw of all labels for that A Label Count of zero is an implicit withdraw of all labels for that
prefix on that interface. prefix on that interface.
13.6. MPLS IPv4 Encapsulation 13.6. MPLS IPv4 Encapsulation
The MPLS IPv4 Encapsulation describes a logical link's ability to The MPLS IPv4 Encapsulation describes a logical link's ability to
exchange labeled IPv4 packets on one or more subnets. It does so by exchange labeled IPv4 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. and the corresponding labels which will be accepted fpr 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 = 6 | Payload Length ~ | PDU Type = 6 | Payload Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Count | ~ | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Encapsulations. The 24-bit Count is the number of MPLSv4 Encapsulation 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 IPv4 Encapsulation describes a logical link's ability to
exchange labeled IPv4 packets on one or more subnets. It does so by exchange labeled IPv4 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. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 29 skipping to change at page 24, line 29
+ + + +
| 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. The 24-bit Count is the number of MPLSv6 Encapsulations being
announced and/or withdrawn.
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.
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 18 skipping to change at page 25, line 16
Ent Type allows a VENDOR PDU to be sub-typed in the event that the Ent Type allows a VENDOR PDU to be sub-typed in the event that the
vendor/enterprise needs multiple PDU types. vendor/enterprise needs multiple PDU types.
As with Encapsulation PDUs, a receiver of a VENDOR PDU MUST respond As with Encapsulation PDUs, a receiver of a VENDOR PDU MUST respond
with an ACK or an ERROR PDU. Similarly, a VENDOR PDU MUST only be with an ACK or an ERROR PDU. Similarly, a VENDOR PDU MUST only be
sent over an open session. sent over an open session.
15. KEEPALIVE - Layer 2 Liveness 15. KEEPALIVE - Layer 2 Liveness
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Type = 2 | Payload 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. 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 down to per-link granularity.
Disagreement MAY result in repeated session break and Disagreement MAY result in repeated session break 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.
If a KEEPALIVE is not received from a peer with which a receiver has When a sender transmits a PDU which is not a KEEPALIVE, the sender
an open session for a configurable time (default 30 seconds), the SHOULD reset the KEEPALIVE timer. I.e. sending any PDU acts as a
link SHOULD BE presumed down. The devices MAY keep configuration keepalive. Once the last fragment has been sent, the KEEPALIVE timer
state and restore it without retransmission if no data have changed. SHOULD BE restarted. Do not wait for the ACK.
Otherwise, a new session SHOULD BE established and new Encapsulation
PDUs exchanged.
0 1 2 3 If a KEEPALIVE or other PDUs have not been received from a peer with
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 which a receiver has an open session for a configurable time (default
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 30 seconds), the link SHOULD BE presumed down. The devices MAY keep
| PDU Type = 2 | Payload Length = 0 ~ configuration state and restore it without retransmission if no data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ have changed. Otherwise, a new session SHOULD BE established and new
~ | Sig Type = 0 | Signature Length = 0 | Encapsulation PDUs exchanged.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16. Layers 2.5 and 3 Liveness 16. Layers 2.5 and 3 Liveness
Layer 2 liveness may be continuously tested by KEEPALIVE PDUs, see Layer 2 liveness may be continuously tested by KEEPALIVE PDUs, see
Section 15. As layer 2.5 or layer 3 connectivity could still break, Section 15. As layer 2.5 or layer 3 connectivity could still break,
liveness above layer 2 MAY be frequently tested using BFD ([RFC5880]) liveness above layer 2 MAY be frequently tested using BFD ([RFC5880])
or a similar technique. or a similar technique.
This protocol assumes that one or more Encapsulation addresses will This protocol assumes that one or more Encapsulation addresses may be
be used to ping, run BFD, or whatever the operator configures. used to ping, run BFD, or whatever the operator configures.
17. The North/South Protocol 17. The North/South Protocol
Thus far, a one-hop point-to-point logical link discovery protocol Thus far, a one-hop point-to-point logical link discovery protocol
has been defined. has been defined.
The devices know their unique LLEIs and know the unique peer LLEIs The devices know their unique LLEIs and know the unique peer LLEIs
and Encapsulations on each logical link interface. and Encapsulations on each logical link interface.
Full topology discovery is not appropriate at the L3DL layer, so Full topology discovery is not appropriate at the L3DL layer, so
skipping to change at page 27, line 21 skipping to change at page 27, line 28
This section explores some trade-offs taken and some considerations. This section explores some trade-offs taken and some considerations.
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, interfaces MUST peering with K could not be discovered. Therefore, on multi-link
continue to send HELLOs as long as they are turned up. interfaces MUST continue to send HELLOs as long as they are 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 22 skipping to change at page 28, line 27
An implementation SHOULD provide the ability to distribute one or An implementation SHOULD provide the ability to distribute one or
more overlay and/or underlay addresses or interfaces into L3DL on an more overlay and/or underlay addresses or interfaces into L3DL on an
external L3DL speaking interface. external L3DL speaking interface.
An implementation SHOULD provide the ability to configure one of the An implementation SHOULD provide the ability to configure one of the
addresses of an encapsulation as primary on an L3DL speaking addresses of an encapsulation as primary on an L3DL speaking
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 SHOULD allow optional configuration which updates An implementation MAY allow optional configuration which updates the
the local forwarding table with overlay and underlay data both local forwarding table with overlay and underlay data both learned
learned from L3DL peers and configured locally. from L3DL peers and configured locally.
21. Security Considerations 21. Security Considerations
The protocol as it is MUST NOT be used outside a datacenter or The protocol as is MUST NOT be used outside a datacenter or similarly
similarly closed environment due to lack of formal definition of the closed environment due to lack of formal definition of the
authentication and authorization mechanism. Sufficient mechanisms authentication and authorization mechanism. Sufficient mechanisms
may be described in separate documents. 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. [draft-ymbk-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.
skipping to change at page 30, line 39 skipping to change at page 30, line 47
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, Jeff Haas for The authors thank Cristel Pelsser for multiple reviews, Harsha Kovuru
review and comments, Joe Clarke for a useful review, John Scudder for for comments during implementation, Jeff Haas for review and
deeply serious review and comments, Larry Kreeger for a lot of layer comments, Joe Clarke for a useful review, John Scudder for deeply
2 clue, Martijn Schmidt for his contribution, Neeraj Malhotra for serious review and comments, Larry Kreeger for a lot of layer 2 clue,
review, Russ Housley for checksum discussion and sBox, and Steve Martijn Schmidt for his contribution, Neeraj Malhotra for review,
Bellovin for checksum advice. 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-15 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16
(work in progress), May 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",
skipping to change at page 33, line 24 skipping to change at page 33, line 32
<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>.
Authors' Addresses Authors' Addresses
Randy Bush Randy Bush
Arrcus & IIJ 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
Rob Austein Rob Austein
Arrcus, Inc Arrcus, Inc
Email: sra@hactrn.net Email: sra@hactrn.net
 End of changes. 72 change blocks. 
161 lines changed or deleted 187 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/