draft-ietf-lsvr-l3dl-03.txt   draft-ietf-lsvr-l3dl-04.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: May 5, 2020 K. Patel Expires: November 8, 2020 K. Patel
Arrcus Arrcus
November 2, 2019 May 7, 2020
Layer 3 Discovery and Liveness Layer 3 Discovery and Liveness
draft-ietf-lsvr-l3dl-03 draft-ietf-lsvr-l3dl-04
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 neighbor IP
IP encapsulation abilities, IP neighbor address discovery, and link addressing, logical link IP encapsulation abilities, 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 BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
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 May 5, 2020. This Internet-Draft will expire on November 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . 6
5. Inter-Link Protocol Overview . . . . . . . . . . . . . . . . 7 5. Inter-Link Protocol Overview . . . . . . . . . . . . . . . . 7
5.1. L3DL Ladder Diagram . . . . . . . . . . . . . . . . . . . 7 5.1. L3DL Ladder Diagram . . . . . . . . . . . . . . . . . . . 7
6. Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 9 6. Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 9
7. The Checksum . . . . . . . . . . . . . . . . . . . . . . . . 10 7. The Checksum . . . . . . . . . . . . . . . . . . . . . . . . 11
8. TLV PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. TLV PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Logical Link Endpoint Identifier . . . . . . . . . . . . . . 13 9. Logical Link Endpoint Identifier . . . . . . . . . . . . . . 14
10. HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 19 12.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 20
13. The Encapsulations . . . . . . . . . . . . . . . . . . . . . 19 13. The Encapsulations . . . . . . . . . . . . . . . . . . . . . 20
13.1. The Encapsulation PDU Skeleton . . . . . . . . . . . . . 20 13.1. The Encapsulation PDU Skeleton . . . . . . . . . . . . . 21
13.2. Encapsulaion Flags . . . . . . . . . . . . . . . . . . . 21 13.2. Encapsulaion Flags . . . . . . . . . . . . . . . . . . . 22
13.3. IPv4 Encapsulation . . . . . . . . . . . . . . . . . . . 21 13.3. IPv4 Encapsulation . . . . . . . . . . . . . . . . . . . 22
13.4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 22 13.4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 23
13.5. MPLS Label List . . . . . . . . . . . . . . . . . . . . 23 13.5. MPLS Label List . . . . . . . . . . . . . . . . . . . . 24
13.6. MPLS IPv4 Encapsulation . . . . . . . . . . . . . . . . 23 13.6. MPLS IPv4 Encapsulation . . . . . . . . . . . . . . . . 24
13.7. MPLS IPv6 Encapsulation . . . . . . . . . . . . . . . . 24 13.7. MPLS IPv6 Encapsulation . . . . . . . . . . . . . . . . 25
14. VENDOR - Vendor Extensions . . . . . . . . . . . . . . . . . 24 14. VENDOR - Vendor Extensions . . . . . . . . . . . . . . . . . 25
15. KEEPALIVE - Layer 2 Liveness . . . . . . . . . . . . . . . . 25 15. KEEPALIVE - Layer 2 Liveness . . . . . . . . . . . . . . . . 26
16. Layers 2.5 and 3 Liveness . . . . . . . . . . . . . . . . . . 26 16. Layers 2.5 and 3 Liveness . . . . . . . . . . . . . . . . . . 27
17. The North/South Protocol . . . . . . . . . . . . . . . . . . 26 17. The North/South Protocol . . . . . . . . . . . . . . . . . . 27
17.1. Use BGP-LS as Much as Possible . . . . . . . . . . . . . 27 17.1. Use BGP-LS as Much as Possible . . . . . . . . . . . . . 28
17.2. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . 27 17.2. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . 28
18. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 27 18. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 28
18.1. HELLO Discussion . . . . . . . . . . . . . . . . . . . . 27 18.1. HELLO Discussion . . . . . . . . . . . . . . . . . . . . 28
18.2. HELLO versus KEEPALIVE . . . . . . . . . . . . . . . . . 28 18.2. HELLO versus KEEPALIVE . . . . . . . . . . . . . . . . . 29
19. VLANs/SVIs/Sub-interfaces . . . . . . . . . . . . . . . . . . 28 19. VLANs/SVIs/Sub-interfaces . . . . . . . . . . . . . . . . . . 29
20. Implementation Considerations . . . . . . . . . . . . . . . . 28 20. Implementation Considerations . . . . . . . . . . . . . . . . 29
21. Security Considerations . . . . . . . . . . . . . . . . . . . 29 21. Security Considerations . . . . . . . . . . . . . . . . . . . 30
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
22.1. PDU Types . . . . . . . . . . . . . . . . . . . . . . . 29 22.1. PDU Types . . . . . . . . . . . . . . . . . . . . . . . 30
22.2. Signature Type . . . . . . . . . . . . . . . . . . . . . 30 22.2. Signature Type . . . . . . . . . . . . . . . . . . . . . 31
22.3. Flag Bits . . . . . . . . . . . . . . . . . . . . . . . 30 22.3. Flag Bits . . . . . . . . . . . . . . . . . . . . . . . 31
22.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . 30 22.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . 31
23. IEEE Considerations . . . . . . . . . . . . . . . . . . . . . 31 23. IEEE Considerations . . . . . . . . . . . . . . . . . . . . . 32
24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
25. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 25. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
25.1. Normative References . . . . . . . . . . . . . . . . . . 31 25.1. Normative References . . . . . . . . . . . . . . . . . . 32
25.2. Informative References . . . . . . . . . . . . . . . . . 33 25.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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 4, line 7 skipping to change at page 4, line 7
[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, o Enable Layer 3 link liveness such as BFD,
o Provide Layer 2 keep-alive messages for session continuity, and o Provide Layer 2 keep-alive messages for session continuity, and
finally finally
o Provide for authenticity verification of protocol messages. o Provide for authenticity verification of protocol messages.
This protocol may be more widely applicable to a range of routing and In this document, the use case for L3DL is for point to point links
similar protocols which need layer 3 discovery and characterisation. in a datacenter Clos in order to exchange the data needed for BGP-SPF
[I-D.ietf-lsvr-bgp-spf] bootstrap and continuity. Once layer two
connectivity has been leveraged to get layer three addressability and
forwarding capabilities, normal layer three forwarding and routing
can take over.
L3DL might be found to be more widely applicable to a range of
routing and similar protocols which need layer three 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.
skipping to change at page 9, line 24 skipping to change at page 9, line 34
Ethernet frame, exclusive of Ethernet framing data, is referred to as Ethernet frame, exclusive of Ethernet framing data, is referred to as
a Datagram. 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.
This is not classic 'fragmentation', but rather decomposition at the
origin to allow PDU payloads larger than the frame allows. There are
no intermediate devices capable of further fragmentation or
reassembly.
L3DL is carrying relatively small amounts of data on relatively high
bandwidth links, and at a time when the link is not active with other
data as it does not yet have layer three connectivity. So congestion
is not considered a sufficiently significant risk to warrent
additional complexity.
Should a PDU need to be retransmitted, it MUST BE sent as the Should a PDU need to be retransmitted, it MUST BE sent as the
identical Datagram set as the original transmission. The identical Datagram set as the original transmission. The
Transmission Sequence Number informs the receiver that it is the same Transmission Sequence Number informs the receiver that it is the same
PDU. 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 | Transmission Sequence Number |L| ~ | Version | Transmission Sequence Number |L| ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 9 skipping to change at page 10, line 33
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 Transmission Sequence Number: A 16-bit strictly increasing unsigned
integer identifying this PDU, possibly across retransmissions, integer identifying this PDU, possibly across retransmissions,
that wraps from 2^16-1 to 0. The initial value is arbitrary. See 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 [RFC1982] on DNS Serial Number Arithmetic for too much detail on
comparison and incrementing a wrapping sequence number. comparing 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; though Ethernet framing is likely to impose a smaller octets; though Ethernet framing is likely to impose a smaller
limit. limit.
skipping to change at page 10, line 43 skipping to change at page 11, line 18
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 a suggested algorithm. This
specification avoids mandatory to implement, algorithm agility, etc.
What matters is that the same algorithm is used consistently in any
deployment.
Sum up 32-bit unsigned ints in a 64-bit long, then take the high- Sum up 32-bit unsigned ints in a 64-bit long, then take the high-
order section, shift it right, rotate, add it in, repeat until zero. order section, shift it right, rotate, add it in, repeat until zero.
<CODE BEGINS> <CODE BEGINS>
#include <stddef.h> #include <stddef.h>
#include <stdint.h> #include <stdint.h>
/* The F table from Skipjack, and it would work for the S-Box. */ /* The F table from Skipjack, and it would work for the S-Box. */
static const uint8_t sbox[256] = { static const uint8_t sbox[256] = {
skipping to change at page 11, line 45 skipping to change at page 12, line 45
/* non-normative example C code, constant time even */ /* non-normative example C code, constant time even */
uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
{ {
uint32_t sum[4] = {0, 0, 0, 0}; uint32_t sum[4] = {0, 0, 0, 0};
uint64_t result = 0; uint64_t result = 0;
for (size_t i = 0; i < n; i++) for (size_t i = 0; i < n; i++)
sum[i & 3] += sbox[*b++]; sum[i & 3] += sbox[*b++];
for (int i = 0; i < sizeof(sum)/sizeof(*sum); i++) for (int i = 0; i < sizeof(sum)/sizeof(*sum); i++)
result = (result << 8) + sum[i]; result = (result << 8) + sum[i];
result = (result >> 32) + (result & 0xFFFFFFFF); result = (result >> 32) + (result & 0xFFFFFFFFU);
result = (result >> 32) + (result & 0xFFFFFFFF); result = (result >> 32) + (result & 0xFFFFFFFFU);
return (uint32_t) result; return (uint32_t) result;
} }
<CODE ENDS> <CODE ENDS>
8. TLV PDUs 8. TLV PDUs
The basic L3DL application layer PDU is a typical TLV (Type Length The basic L3DL application layer PDU is a typical TLV (Type Length
Value) PDU. It includes a signature to provide optional integrity Value) PDU. It includes a signature to provide optional integrity
and authentication. It may be broken into multiple Datagrams, see and authentication. It may be broken into multiple Datagrams, see
Section 6. Section 6.
skipping to change at page 14, line 47 skipping to change at page 15, line 47
if it is to participate in L3DL sessions. if it is to participate in L3DL sessions.
If a constrained Nearest Bridge destination address has been If a constrained Nearest Bridge destination address has been
configured for a point-to-point interface, see above, then the HELLO configured for a point-to-point interface, see above, then the HELLO
SHOULD NOT be repeated once a session has been created by an exchange SHOULD NOT be repeated once a session has been created by an exchange
of OPENs. 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. In this multi-link scenario, the
operator should be aware of the trade-off between timer tuning and
network noise and adjust the inter-HELLO timer accordingly.
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 (plus VID if VLAN) When a HELLO is received from a source MAC address (plus VID if VLAN)
with which there is no established L3DL session, the receiver SHOULD with which there is no established L3DL session, the receiver SHOULD
respond by sending an OPEN PDU to the source MAC address (plus VID). respond by sending an OPEN PDU to the source MAC address (plus VID).
The two devices establish an L3DL session by exchanging OPEN PDUs. The two devices establish an L3DL session by exchanging OPEN PDUs.
To ameliorate possible load spikes during bootstrap or event
recovery, there SHOULD be a jittered delay between receipt of a HELLO
and issue of the OPEN. The default delay range SHOULD BE zero to
five seconds, and MUST be configurable.
If a HELLO is received from a MAC address with which there is an If a HELLO is received from a MAC address with which there is an
established session, the HELLO should be dropped. 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
skipping to change at page 17, line 30 skipping to change at page 18, line 30
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, then If a sender of OPEN does not receive an ACK of the OPEN PDU, then
they MUST resend the same OPEN PDU, with the same Nonce. Resending they MUST resend the same OPEN PDU, with the same Nonce. Resending
an unacknowledged OPEN PDU, like other ACKed PDUs, SHOULD use an unacknowledged OPEN PDU, like other ACKed PDUs, SHOULD 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 at L3DL speaker A with a new
LLEI with which the receiving logical link endpoint believes it Nonce from an LLEI, speaker B, with which A believes it already has
already has an L3DL session (OPENs have already been exchanged), and an L3DL session (OPENs have already been exchanged), and the Serial
the Serial Number in the OPEN is non-zero, the receiver SHOULD Number in the OPEN PDU is non-zero, speaker A SHOULD establish a new
establish a new session by sending an OPEN with the Serial Number of session by sending an OPEN with the Serial Number being the same as
the last data it received. Each party MUST resume sending that of A's last sent and ACKed PDU. 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
skipping to change at page 19, line 15 skipping to change at page 20, line 15
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 this 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 (L2.5 and L3) identities, have means to ensure link state, layer (L2.5 and L3) identities, have means to ensure link state,
etc., the L3DL session is considered established, and the devices etc., the L3DL session is considered established, and the devices
SHOULD exchange L3 interface encapsulations, L3 addresses, and L2.5 SHOULD exchange L3 interface encapsulations, L3 addresses, and L2.5
skipping to change at page 31, line 27 skipping to change at page 32, line 27
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, Joerg Ott for an early but deep transport review, Joe
serious review and comments, Larry Kreeger for a lot of layer 2 clue, Clarke for a useful review, John Scudder for deeply serious review
Martijn Schmidt for his contribution, Nalinaksh Pai for transport and comments, Larry Kreeger for a lot of layer 2 clue, Martijn
Schmidt for his contribution, Nalinaksh Pai for transport
discussions, Neeraj Malhotra for review, Paul Congdon for Ethernet discussions, Neeraj Malhotra for review, Paul Congdon for Ethernet
hints, Russ Housley for checksum discussion and sBox, and Steve hints, Russ Housley for checksum discussion and sBox, and Steve
Bellovin for checksum advice. 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.,
skipping to change at page 32, line 8 skipping to change at page 33, line 8
[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-06 (work in progress), September draft-ietf-lsvr-bgp-spf-08 (work in progress), March 2020.
2019.
[I-D.ymbk-lsvr-l3dl-signing] [I-D.ymbk-lsvr-l3dl-signing]
Bush, R. and R. Austein, "Layer 3 Discovery and Liveness Bush, R. and R. Austein, "Layer 3 Discovery and Liveness
Signing", draft-ymbk-lsvr-l3dl-signing-00 (work in Signing", draft-ymbk-lsvr-l3dl-signing-01 (work in
progress), October 2019. progress), May 2020.
[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,
<http://ieeexplore.ieee.org/servlet/opac?punumber=7732>. <http://ieeexplore.ieee.org/servlet/opac?punumber=7732>.
[IEEE802-2014] [IEEE802-2014]
Institute of Electrical and Electronics Engineers, "Local Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Overview and and Metropolitan Area Networks: Overview and
Architecture", IEEE Std 802-2014, 2014. Architecture", IEEE Std 802-2014, 2014.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991,
<http://www.rfc-editor.org/info/rfc1213>. <https://www.rfc-editor.org/info/rfc1213>.
[RFC1629] Colella, R., Callon, R., Gardner, E., and Y. Rekhter, [RFC1629] Colella, R., Callon, R., Gardner, E., and Y. Rekhter,
"Guidelines for OSI NSAP Allocation in the Internet", "Guidelines for OSI NSAP Allocation in the Internet",
RFC 1629, DOI 10.17487/RFC1629, May 1994, RFC 1629, DOI 10.17487/RFC1629, May 1994,
<http://www.rfc-editor.org/info/rfc1629>. <https://www.rfc-editor.org/info/rfc1629>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<http://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
June 2011, <http://www.rfc-editor.org/info/rfc6286>. June 2011, <https://www.rfc-editor.org/info/rfc6286>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
25.2. Informative References 25.2. Informative References
[Clos0] Clos, C., "A study of non-blocking switching networks [Clos0] Clos, C., "A study of non-blocking switching networks
[PAYWALLED]", Bell System Technical Journal 32 (2), pp [PAYWALLED]", Bell System Technical Journal 32 (2), pp
406-424, March 1953. 406-424, March 1953.
[Clos1] "Clos Network", [Clos1] "Clos Network",
<https://en.wikipedia.org/wiki/Clos_network/>. <https://en.wikipedia.org/wiki/Clos_network/>.
[I-D.malhotra-bess-evpn-lsoe] [I-D.malhotra-bess-evpn-lsoe]
Malhotra, N., Patel, K., and J. Rabadan, "LSoE-based PE-CE Malhotra, N., Patel, K., and J. Rabadan, "LSoE-based PE-CE
Control Plane for EVPN", draft-malhotra-bess-evpn-lsoe-00 Control Plane for EVPN", draft-malhotra-bess-evpn-lsoe-00
(work in progress), March 2019. (work in progress), March 2019.
[JUPITER] Singh, A., Germano, P., Kanagala, A., Liu, H., Provost, [JUPITER] Singh, A., Ong, J., Agarwal, A., Anderson, G., Armistead,
J., Simmons, J., Tanda, E., Wanderer, J., HAP.lzle, U., A., Bannon, R., Boving, S., Desai, G., Felderman, B.,
Stuart, S., Vahdat, A., Ong, J., Agarwal, A., Anderson, Germano, P., Kanagala, A., Liu, H., Provost, J., Simmons,
G., Armistead, A., Bannon, R., Boving, S., Desai, G., and J., Tanda, E., Wanderer, J., HAP.lzle, U., Stuart, S., and
B. Felderman, "Jupiter rising", Communications of the A. Vahdat, "Jupiter rising", Communications of the
ACM Vol. 59, pp. 88-97, DOI 10.1145/2975159, August 2016. ACM Vol. 59, pp. 88-97, DOI 10.1145/2975159, August 2016.
[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>. <https://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>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996, DOI 10.17487/RFC1982, August 1996,
<http://www.rfc-editor.org/info/rfc1982>. <https://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. 35 change blocks. 
85 lines changed or deleted 114 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/