< draft-ietf-lsvr-l3dl-ulpc-01.txt		draft-ietf-lsvr-l3dl-ulpc-02.txt >
	Network Working Group R. Bush		Network Working Group R. Bush
	Internet-Draft Arrcus & IIJ		Internet-Draft Arrcus & IIJ
	Intended status: Standards Track K. Patel		Intended status: Standards Track K. Patel
	Expires: July 30, 2021 Arrcus		Expires: 17 April 2022 Arrcus
	January 26, 2021		14 October 2021
	L3DL Upper Layer Protocol Configuration		L3DL Upper-Layer Protocol Configuration
	draft-ietf-lsvr-l3dl-ulpc-01		draft-ietf-lsvr-l3dl-ulpc-02
	Abstract		Abstract
	This document users the Layer 3 Liveness and Discovery protocol to		This document uses the Layer-3 Liveness and Discovery protocol to
	communicate the parameters needed to exchange inter-device Upper		communicate the parameters needed to exchange inter-device Upper
	Layer Protocol Configuration for upper layer protocols such as the		Layer Protocol Configuration for upper-layer protocols such as the
	BGP family.		BGP family.
	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.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 July 30, 2021.		This Internet-Draft will expire on 17 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Reading and Terminology . . . . . . . . . . . . . . . . . . . 2		2. Reading and Terminology . . . . . . . . . . . . . . . . . . . 2
	3. Upper Layer Protocol Configuration PDU . . . . . . . . . . . 3		3. Upper-Layer Protocol Configuration PDU . . . . . . . . . . . 3
	3.1. BGP ULPC Attribute sub-TLVs . . . . . . . . . . . . . . . 3		3.1. BGP ULPC Attribute sub-TLVs . . . . . . . . . . . . . . . 3
	3.1.1. BGP ASN . . . . . . . . . . . . . . . . . . . . . . . 4		3.1.1. BGP ASN . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1.2. BGP IPv4 Address . . . . . . . . . . . . . . . . . . 5		3.1.2. BGP IPv4 Address . . . . . . . . . . . . . . . . . . 5
	3.1.3. BGP IPv6 Address . . . . . . . . . . . . . . . . . . 5		3.1.3. BGP IPv6 Address . . . . . . . . . . . . . . . . . . 5
	3.1.4. BGP Authentication sub-TLV . . . . . . . . . . . . . 6		3.1.4. BGP Authentication sub-TLV . . . . . . . . . . . . . 6
	3.1.5. BGP Miscellaneous Flags . . . . . . . . . . . . . . . 6		3.1.5. BGP Miscellaneous Flags . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. Normative References . . . . . . . . . . . . . . . . . . 7		6.1. Normative References . . . . . . . . . . . . . . . . . . 7
	6.2. Informative References . . . . . . . . . . . . . . . . . 8		6.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	Massive Data Centers (MDCs) which use upper layer protocols such as		Massive Data Centers (MDCs) which use upper-layer protocols such as
	BGP4, BGP-LS, BGP-SPF, etc. may use the Layer 3 Liveness and		BGP4, BGP-LS, BGP-SPF, etc. may use the Layer-3 Liveness and
	Discovery Protocol, L3DP, [I-D.ietf-lsvr-l3dl] to reveal the inter-		Discovery Protocol, L3DP, [I-D.ietf-lsvr-l3dl] to reveal the inter-
	device links of the topology. It is desirable for devices to		device links of the topology. It is desirable for devices to
	facilitate the configuration parameters of those upper layer		facilitate the configuration parameters of those upper layer
	protocols to enable more hands-free configuration. This document		protocols to enable more hands-free configuration. This document
	defines a new L3DP PDU to communicate these Upper Layer Protocol		defines a new L3DP PDU to communicate these Upper-Layer Protocol
	Configuration parameters.		Configuration parameters.
	2. Reading and Terminology		2. Reading and Terminology
	The reader is assumed to have read Layer 3 Discovery and Liveness		The reader is assumed to have read Layer-3 Discovery and Liveness
	[I-D.ietf-lsvr-l3dl]. The terminology and PDUs there are assumed		[I-D.ietf-lsvr-l3dl]. The terminology and PDUs there are assumed
	here.		here.
	Familiarity with the BGP4 Protocol [RFC4271] is assumed. Familiarity		Familiarity with the BGP4 Protocol [RFC4271] is assumed. Familiarity
	with BGP-SPF, [I-D.ietf-lsvr-bgp-spf], might be useful.		with BGP-SPF, [I-D.ietf-lsvr-bgp-spf], might be useful.
	3. Upper Layer Protocol Configuration PDU		3. Upper-Layer Protocol Configuration PDU
	To communicate parameters required to configure peering and operation		To communicate parameters required to configure peering and operation
	of Upper Layer Protocols at IP layer 3 and above, e.g., BGP sessions		of Upper-Layer Protocols at IP layer-3 and above, e.g., BGP sessions
	on a link, a neutral sub-TLV based Upper Layer Protocol PDU is		on a link, a neutral sub-TLV based Upper-Layer Protocol PDU is
	defined as follows:		defined as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 9 | Payload Length ~		| Type = 9 | Payload Length ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ | ULPC Type | AttrCount | ~		~ | ULPC Type | AttrCount | ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Attribute List ... | Sig Type | Signature Len ~		~ Attribute List ... | Sig Type | Signature Len ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ | Signature ... |		~ | Signature ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Type and Payload Length are defined in [I-D.ietf-lsvr-l3dl].		The Type and Payload Length are defined in [I-D.ietf-lsvr-l3dl].
	ULPC Type: An integer denoting the type of the uper layer protocol		ULPC Type: An integer denoting the type of the upper-layer protocol
	0 : Reserved		0 : Reserved
	1 : BGP		1 : BGP
	2-255 : Reserved		2-255 : Reserved
	The AttrCount is the number of attribute sub-TLVs in the Attribute		The AttrCount is the number of attribute sub-TLVs in the Attribute
	List.		List.
	The Attribute List is a, possibly null, set of sub-TLVs describing		The Attribute List is a, possibly null, set of sub-TLVs describing
	the configuration attributes of the specific upper layer protocol.		the configuration attributes of the specific upper-layer protocol.
	An Attribute consists of a one octet Attribute Type, a one octet		An Attribute consists of a one octet Attribute Type, a one octet
	Attribute Length of the number of octets in the Attribute, and a		Attribute Length of the number of octets in the Attribute, and a
	Payload of arbitrary length up to 253 octets.		Payload of arbitrary length up to 253 octets.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Attr Type = 1 | Attr Len | Payload |		| Attr Type = 1 | Attr Len | Payload |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.1. BGP ULPC Attribute sub-TLVs		3.1. BGP ULPC Attribute sub-TLVs
	The parameters needed for BGP peering on a link are exchanged in sub-		The parameters needed for BGP peering on a link are exchanged in sub-
	TLVs within an Upper Layer Protocol PDU. The following describe the		TLVs within an Upper-Layer Protocol PDU. The following describe the
	various sub-TLVs for BGP.		various sub-TLVs for BGP.
	The goal is to provide the minimal set of configuration parameters		The goal is to provide the minimal set of configuration parameters
	needed by BGP OPEN to successfully start a BGP peering. The goal is		needed by BGP OPEN to successfully start a BGP peering. The goal is
	specifically not to replace or conflict with data exchanged during		specifically not to replace or conflict with data exchanged during
	BGP OPEN. Multiple sources of truth are a recipe for complexity and		BGP OPEN. Multiple sources of truth are a recipe for complexity and
	hence pain.		hence pain.
	If there are multiple BGP sessions on a link, e.g., IPv4 and IPv6,		If there are multiple BGP sessions on a link, e.g., IPv4 and IPv6,
	then multiple sets of BGP sub-TLVs MAY BE exchanged within the BGP		then multiple sets of BGP sub-TLVs MAY BE exchanged within the BGP
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	As a link may have multiple encapsulations and multiple addresses for		As a link may have multiple encapsulations and multiple addresses for
	an IP encapsulation, which address of which encapsulation is to be		an IP encapsulation, which address of which encapsulation is to be
	used for the BGP session MUST be specified.		used for the BGP session MUST be specified.
	For each BGP peering on a link here MUST be one agreed encapsulation,		For each BGP peering on a link here MUST be one agreed encapsulation,
	and the addresses used MUST be in the corresponding L3DP IPv4/IPv6		and the addresses used MUST be in the corresponding L3DP IPv4/IPv6
	Announcement PDUs. If the choice is ambiguous, an Attribute may be		Announcement PDUs. If the choice is ambiguous, an Attribute may be
	used to signal preferences.		used to signal preferences.
	If a peering address has been announced as a loopback, i.e. MUST BE		If a peering address has been announced as a loopback, i.e. MUST BE
	flagged as such in the L3DL Encapsulation PDU, a two or three hop BGP		flagged as such in the L3DL Encapsulation PDU (see
	session will be established. Otherwise a direct one hop session is		[I-D.ietf-lsvr-l3dl] Sec. 13.2), a two or three hop BGP session will
	used. the BGP session to a loopback will forward to the peer's		be established. Otherwise a direct one hop session is used. The BGP
	address which was marked as Primary in the L3DL Encapsulation Flags,		session to a loopback will forward to the peer's address which was
	iff it is in a subnet which is shared with both BGP speakers. If the		marked as Primary in the L3DL Encapsulation Flags, iff it is in a
	primary is not in a common subnet, then the BGP speaker MAY pick a		subnet which is shared with both BGP speakers. If the primary is not
	forwarding next hop that is in a subnet they share. If there are		in a common subnet, then the BGP speaker MAY pick a forwarding next
	multiple choices, the BGP speaker SHOULD have signaled which subnet		hop that is in a subnet they share. If there are multiple choices,
	to choose in an Upper Layer Protocol Configuration PDU Attribute.		the BGP speaker SHOULD have signaled which subnet to choose in an
			Upper-Layer Protocol Configuration PDU Attribute.
	3.1.1. BGP ASN		3.1.1. BGP ASN
	The Autonomous System number MUST be specified. If the AS Number is		The Autonomous System number MUST be specified. If the AS Number is
	less than 32 bits, it is padded with high order zeros.		less than 32 bits, it is padded with high order zeros.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Attr Type = 1 | Attr Len = 6 | My ASN ~		| Attr Type = 1 | Attr Len = 6 | My ASN ~
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	| |		| |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Prefix Len |		| | Prefix Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	3.1.4. BGP Authentication sub-TLV		3.1.4. BGP Authentication sub-TLV
	The BGP Authentication sub-TLV provides any authentication data		The BGP Authentication sub-TLV provides any authentication data
	needed to OPEN the BGP session. Depending on operator configuration		needed to OPEN the BGP session. Depending on operator configuration
	of the environment, it might be a simple MD5 key (see [RFC2385]), the		of the environment, it might be a simple MD5 key (see [RFC2385]), the
	name of a key chain a KARP database (see [RFC7210]), or one of		name of a key chain in a KARP database (see [RFC7210]), or one of
	multiple Authentication sub-TLVs to support hop[RFC4808].		multiple Authentication sub-TLVs to support hop[RFC4808].
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Attr Type = 4 | Attr Len | ~		| Attr Type = 4 | Attr Len | ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
	~ BGP Authentication Data ... ~		~ BGP Authentication Data ... ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 36 ¶
	are currently defined.		are currently defined.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Attr Type = 5 | Attr Len = 4 | Misc Flags |		| Attr Type = 5 | Attr Len = 4 | Misc Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Misc Attrs:		Misc Attrs:
	Bit 0: Ghu knows what		Bit 0: GTSM
	Bit 1-15: Must be zero		Bit 1-15: Must be zero
			The GTSM flag indicates that the sender wishes to enable the
			[RFC5682] Generalized TTL Security Mechanism for the session.
	4. Security Considerations		4. Security Considerations
	All the Security considerations of [I-D.ietf-lsvr-l3dl] apply to this		All the Security considerations of [I-D.ietf-lsvr-l3dl] apply to this
	PDU.		PDU.
	As the ULPC PDU may contain keying material, see Section 3.1.4, it		As the ULPC PDU may contain keying material, see Section 3.1.4, it
	SHOULD BE signed.		SHOULD BE signed.
	Any keying material in the PDU SHOULD BE salted and hashed.		Any keying material in the PDU SHOULD BE salted and hashed.
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 39 ¶
	0 Reserved		0 Reserved
	1 BGP		1 BGP
	2-255 Reserved		2-255 Reserved
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[I-D.ietf-lsvr-l3dl]		[I-D.ietf-lsvr-l3dl]
	Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery		Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery
	and Liveness", draft-ietf-lsvr-l3dl-06 (work in progress),		and Liveness", Work in Progress, Internet-Draft, draft-
	July 2020.		ietf-lsvr-l3dl-07, 26 January 2021,
			<https://www.ietf.org/archive/id/draft-ietf-lsvr-l3dl-
			07.txt>.
	[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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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,
	<https://www.rfc-editor.org/info/rfc4271>.		<https://www.rfc-editor.org/info/rfc4271>.
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 15 ¶
	[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,		[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
	"Multiprotocol Extensions for BGP-4", RFC 4760,		"Multiprotocol Extensions for BGP-4", RFC 4760,
	DOI 10.17487/RFC4760, January 2007,		DOI 10.17487/RFC4760, January 2007,
	<https://www.rfc-editor.org/info/rfc4760>.		<https://www.rfc-editor.org/info/rfc4760>.
	[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,
	<https://www.rfc-editor.org/info/rfc5226>.		<https://www.rfc-editor.org/info/rfc5226>.
			[RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata,
			"Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
			Spurious Retransmission Timeouts with TCP", RFC 5682,
			DOI 10.17487/RFC5682, September 2009,
			<https://www.rfc-editor.org/info/rfc5682>.
	[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, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	6.2. Informative References		6.2. Informative References
	[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, "BGP
	"Shortest Path Routing Extensions for BGP Protocol",		Link-State Shortest Path First (SPF) Routing", Work in
	draft-ietf-lsvr-bgp-spf-11 (work in progress), August		Progress, Internet-Draft, draft-ietf-lsvr-bgp-spf-15, 1
	2020.		July 2021, <https://www.ietf.org/archive/id/draft-ietf-
			lsvr-bgp-spf-15.txt>.
	[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5		[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
	Signature Option", RFC 2385, DOI 10.17487/RFC2385, August		Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
	1998, <https://www.rfc-editor.org/info/rfc2385>.		1998, <https://www.rfc-editor.org/info/rfc2385>.
	[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",		[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",
	RFC 4808, DOI 10.17487/RFC4808, March 2007,		RFC 4808, DOI 10.17487/RFC4808, March 2007,
	<https://www.rfc-editor.org/info/rfc4808>.		<https://www.rfc-editor.org/info/rfc4808>.
	[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,		[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,
	skipping to change at page 8, line 36 ¶		skipping to change at page 9, line 4 ¶
	[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",		[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",
	RFC 4808, DOI 10.17487/RFC4808, March 2007,		RFC 4808, DOI 10.17487/RFC4808, March 2007,
	<https://www.rfc-editor.org/info/rfc4808>.		<https://www.rfc-editor.org/info/rfc4808>.
	[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,		[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,
	"Database of Long-Lived Symmetric Cryptographic Keys",		"Database of Long-Lived Symmetric Cryptographic Keys",
	RFC 7210, DOI 10.17487/RFC7210, April 2014,		RFC 7210, DOI 10.17487/RFC7210, April 2014,
	<https://www.rfc-editor.org/info/rfc7210>.		<https://www.rfc-editor.org/info/rfc7210>.
	Authors' Addresses		Authors' Addresses
	Randy Bush		Randy Bush
	Arrcus & IIJ		Arrcus & IIJ
	5147 Crystal Springs		5147 Crystal Springs
	Bainbridge Island, WA 98110		Bainbridge Island, WA 98110
	US		United States of America
	Email: randy@psg.com		Email: randy@psg.com
	Keyur Patel		Keyur Patel
	Arrcus		Arrcus
	2077 Gateway Place, Suite #400		2077 Gateway Place, Suite #400
	San Jose, CA 95119		San Jose, CA 95119
	United States of America		United States of America
	Email: keyur@arrcus.com		Email: keyur@arrcus.com
End of changes. 26 change blocks.
	49 lines changed or deleted		61 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/