draft-ietf-lsvr-l3dl-05.txt   draft-ietf-lsvr-l3dl-06.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: November 26, 2020 K. Patel Expires: January 30, 2021 K. Patel
Arrcus Arrcus
May 25, 2020 July 29, 2020
Layer 3 Discovery and Liveness Layer 3 Discovery and Liveness
draft-ietf-lsvr-l3dl-05 draft-ietf-lsvr-l3dl-06
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 neighbor IP need to discover IP Layer 3 attributes of links, such as neighbor IP
addressing, logical link IP encapsulation abilities, 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.
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 November 26, 2020. This Internet-Draft will expire on January 30, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 6, line 16 skipping to change at page 6, line 16
o Devices discover each other on logical links o Devices discover each other on logical links
o Logical Link Endpoint Identifiers (LLEIs) are exchanged o Logical Link Endpoint Identifiers (LLEIs) are exchanged
o Layer 2 Liveness checks may be started o Layer 2 Liveness checks may be started
o Encapsulation data are exchanged and IP-Level Liveness checks o Encapsulation data are exchanged and IP-Level Liveness checks
enabled enabled
o A BGP-like upper layer protocol is assumed to use the identiiers o A BGP-like upper layer protocol is assumed to use the identifiers
and encapsulation data to discover and build a topology database and encapsulation data to discover and build a topology database
+-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+
| Device | | Device | | Device | | Device | | Device | | Device |
| | | | | | | | | | | |
|+-----------------+| |+-----------------+| |+-----------------+| |+-----------------+| |+-----------------+| |+-----------------+|
|| || || || || || || || || || || ||
|| BGP-SPF <+---+> BGP-SPF <+---+> BGP-SPF || || BGP-SPF <+---+> BGP-SPF <+---+> BGP-SPF ||
|| || || || || || || || || || || ||
|+--------^--------+| |+--------^--------+| |+--------^--------+| |+--------^--------+| |+--------^--------+| |+--------^--------+|
skipping to change at page 6, line 45 skipping to change at page 6, line 45
| | | | | | | | | | | | | | | | | |
|+--------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 (left-right in the diagram) There are two protocols, the inter-device (left-right in the diagram)
per-link layer 3 discovery and the API to the upper level BGP-like per-link layer 3 discovery and the API to the upper level BGP-like
routing prototol (up-down in the above diagram): routing protocol (up-down in the above diagram):
o Inter-device PDUs are used to exchange device and logical link o Inter-device PDUs are used to exchange device and logical link
identities and layer 2.5 (MPLS) and 3 identifiers (not payloads), identities and layer 2.5 (MPLS) and 3 identifiers (not payloads),
e.g. device IDs, port identities, VLAN IDs, Encapsulations, and IP e.g. device IDs, port identities, VLAN IDs, Encapsulations, and IP
addresses. addresses.
o A Link Layer to BGP API presents these data up the stack to a BGP o A Link Layer to BGP API presents these data up the stack to a BGP
protocol or an other device-spanning upper layer protocol, protocol or an other device-spanning upper layer protocol,
presenting them using the BGP-LS BGP-like data format. presenting them using the BGP-LS BGP-like data format.
skipping to change at page 7, line 28 skipping to change at page 7, line 28
sending multicast HELLO PDUs (Section 10). To assure discovery of sending multicast HELLO PDUs (Section 10). To assure discovery of
new devices coming up on a multi-link topology, devices on such a new devices coming up on a multi-link topology, devices on such a
topology, and only on a multi-link topology, send periodic HELLOs topology, and only on a multi-link topology, send periodic HELLOs
forever, see Section 18.1. forever, see Section 18.1.
Once a new device is recognized, both devices attempt to negotiate Once a new device is recognized, both devices attempt to negotiate
and establish a session by sending unicast OPEN PDUs (Section 11) to and establish a session by sending unicast OPEN PDUs (Section 11) to
the source MAC addresses (plus VIDs if VLANs) of the received HELLOs. the source MAC addresses (plus VIDs if VLANs) of the received HELLOs.
Once a session is established through the OPEN exchange, the Once a session is established through the OPEN exchange, the
Encapsulations (Section 13) configured on an end point may be Encapsulations (Section 13) configured on an end point may be
announced and modified. Note that these are only the encapsuation announced and modified. Note that these are only the encapsulation
and addresses configured on the announcing interface; though a and addresses configured on the announcing interface; though a
device's loopback and overlay interface(s) may also be announced. device's loopback and overlay interface(s) may also be announced.
When two devices on a link have compatible Encapsulations and When two devices on a link have compatible Encapsulations and
addresses, i.e. the same AFI/SAFI and the same subnet, the link is addresses, i.e. the same AFI/SAFI and the same subnet, the link is
announced via the BGP-LS API. announced via the BGP-LS API.
5.1. L3DL Ladder Diagram 5.1. L3DL Ladder Diagram
The HELLO, Section 10, is a priming message sent on all configured The HELLO, Section 10, is a priming message sent on all configured
logical links. It is a small L3DL PDU encapsulated in an Ethernet logical links. It is a small L3DL PDU encapsulated in an Ethernet
skipping to change at page 9, line 39 skipping to change at page 9, line 39
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 This is not classic 'fragmentation', but rather decomposition at the
origin to allow PDU payloads larger than the frame allows. There are origin to allow PDU payloads larger than the frame allows. There are
no intermediate devices capable of further fragmentation or no intermediate devices capable of further fragmentation or
reassembly. reassembly.
A PDU might need a large number of frames to be sent. As fragments
are not ACK paced (as PDUs are), to avoid overwhelming bursts, the
sender should pace fragments of a large PDU.
L3DL is carrying relatively small amounts of data on relatively high 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 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 data as it does not yet have layer three connectivity. So congestion
is not considered a sufficiently significant risk to warrent is not considered a sufficiently significant risk to warrant
additional complexity. 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| Dtgm Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Datagram Number | Datagram Length | ~ Datagram Number (contd) | Datagram Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | | 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: Eight-bit Version number of the protocol, currently 0.
Values other than 0 MUST BE treated as an error. The protocol Values other than 0 MUST BE treated as an error. The protocol
version needs to be in one and only one place, so it is in the version needs to be in one and only one place, so it is in the
datagram as opposed to, for example, the PDU header. datagram as opposed to, for example, the PDU header.
L: A bit that set to one if this Datagram is the last Datagram of the
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
[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
comparing and incrementing a wrapping sequence number. comparing and incrementing a wrapping sequence number.
Datagram Number: A monotonically increasing 24-bit value which 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.
Note that this is the inverse of the marking technique used by
[RFC0791].
Datagram Number: A monotonically increasing 23-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.
Checksum: A 32 bit hash over the Datagram to detect bit flips, see Checksum: A 32 bit hash over the Datagram to detect bit flips, see
Section 7. Section 7.
If a Datagram fails checksum verification, the datagram is invalid If a Datagram fails checksum verification, the datagram is invalid
and should be silently discarded. The sender will retransmit the and should be silently discarded. The sender will retransmit the
PDU, and the receiver can assmble it. PDU, and the receiver can assemble it.
Payload: The PDU being transported or a fragment thereof. Payload: The PDU being transported or a fragment thereof.
To avoid the need for a receiver to reassemble two PDUs at the same To avoid the need for a receiver to reassemble two PDUs at the same
time, a sender MUST NOT send a subsequent PDU when a PDU is already time, a sender MUST NOT send a subsequent PDU when a PDU is already
in flight and not yet acknowledged; assuming it is an ACKed PDU Type. in flight and not yet acknowledged; assuming it is an ACKed PDU Type.
7. The Checksum 7. The Checksum
There is a reason conservative folk use a checksum in UDP. And as There is a reason conservative folk use a checksum in UDP. And as
skipping to change at page 18, line 11 skipping to change at page 18, line 11
itself, not including the Auth Type or the Key Length. If the Auth itself, not including the Auth Type or the Key Length. If the Auth
Type is zero, then the Key Length MUST also be zero, and there MUST Type is zero, then the Key Length MUST also be zero, and there MUST
BE no Key data. BE no Key data.
The Key is specific to the operational environment. A failure to The Key is specific to the operational environment. A failure to
authenticate is a failure to start the L3DL session, an ERROR PDU authenticate is a failure to start the L3DL session, an ERROR PDU
MUST BE sent (Error Code 3), and HELLOs MUST be restarted. MUST BE sent (Error Code 3), and HELLOs MUST be restarted.
Although delay and jitter in responding with an OPEN were specified Although delay and jitter in responding with an OPEN were specified
above, beware of load created by long strings of authentication above, beware of load created by long strings of authentication
failures and retries. failures and retries. A configurable failure count limit (default 8)
SHOULD result in giving up on the connection attempt.
The Serial Number is that of the last received and processed PDU. The Serial Number is that of the last received and processed PDU.
This allows a receiver sending an OPEN to tell the sender that the This allows a receiver sending an OPEN to tell the sender that the
receiver wants to resume a session and the sender only needs to send receiver wants to resume a session and the sender only needs to send
data more recent than the Serial Number. If this OPEN is not trying data more recent than the Serial Number. If this OPEN is not trying
to restart a lost session, the Serial Number MUST BE set to zero. to restart a lost session, the Serial Number MUST BE set to zero.
The Signature fields are described in Section 8 and in an asymmetric The Signature fields are described in Section 8 and in an asymmetric
key environment serve as a proof of possession of the signing auth key environment serve as a proof of possession of the signing auth
data by the sender. data by the sender.
skipping to change at page 24, line 29 skipping to change at page 24, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 which will be accepted fpr each address. and the corresponding labels which will be accepted for each address.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Type = 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 sum of the number of MPLSv4 Encapsulation The 24-bit Count is the sum of the number of MPLSv4 Encapsulation
being announced and/or withdrawns. being announced and/or withdrawn.
13.7. MPLS IPv6 Encapsulation 13.7. MPLS IPv6 Encapsulation
The MPLS IPv6 Encapsulation describes a logical link's ability to The MPLS IPv6 Encapsulation describes a logical link's ability to
exchange labeled IPv6 packets on one or more subnets. It does so by exchange labeled IPv6 packets on one or more subnets. It does so by
stating the interface's addresses, the corresponding prefix lengths, stating the interface's addresses, the corresponding prefix lengths,
and the corresponding labels which will be accepted for each address. and the corresponding labels which will be accepted for each address.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 30, line 8 skipping to change at page 30, line 8
interface. If there is only one address for a particular interface. If there is only one address for a particular
encapsulation, the implementation MAY mark it as primary by default. encapsulation, the implementation MAY mark it as primary by default.
An implementation MAY allow optional configuration which updates the An implementation MAY allow optional configuration which updates the
local forwarding table with overlay and underlay data both learned local forwarding table with overlay and underlay data both learned
from L3DL peers and configured locally. from L3DL peers and configured locally.
21. Security Considerations 21. Security Considerations
The protocol as is MUST NOT be used outside a datacenter or similarly The protocol as is MUST NOT be used outside a datacenter or similarly
closed environment without authentication ans authorisation closed environment without authentication and authorization
mechanisms such as [I-D.ymbk-lsvr-l3dl-signing]. mechanisms such as [I-D.ymbk-lsvr-l3dl-signing].
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
[I-D.ymbk-lsvr-l3dl-signing] is strongly recommended. [I-D.ymbk-lsvr-l3dl-signing] is strongly recommended.
It is generally unwise to assume that on the wire Layer 2 is secure. It is generally unwise to assume that on the wire Layer 2 is secure.
Strange/unauthorized devices may plug into a port. Mis-wiring is Strange/unauthorized devices may plug into a port. Mis-wiring is
skipping to change at page 33, 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-09 (work in progress), May 2020. draft-ietf-lsvr-bgp-spf-10 (work in progress), July 2020.
[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-01 (work in Signing", draft-ymbk-lsvr-l3dl-signing-01 (work in
progress), May 2020. 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>.
 End of changes. 20 change blocks. 
23 lines changed or deleted 28 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/