< draft-ietf-detnet-tsn-vpn-over-mpls-02.txt		draft-ietf-detnet-tsn-vpn-over-mpls-03.txt >
	DetNet B. Varga, Ed.		DetNet B. Varga, Ed.
	Internet-Draft J. Farkas		Internet-Draft J. Farkas
	Intended status: Standards Track Ericsson		Intended status: Standards Track Ericsson
	Expires: September 7, 2020 A. Malis		Expires: December 10, 2020 A. Malis
	Independent		Malis Consulting
	S. Bryant		S. Bryant
	Futurewei Technologies		Futurewei Technologies
	D. Fedyk		D. Fedyk
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	March 6, 2020		June 8, 2020
	DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS		DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS
	draft-ietf-detnet-tsn-vpn-over-mpls-02		draft-ietf-detnet-tsn-vpn-over-mpls-03
	Abstract		Abstract
	This document specifies the Deterministic Networking data plane when		This document specifies the Deterministic Networking data plane when
	TSN networks are interconnected over a DetNet MPLS Network.		TSN networks are interconnected over a DetNet MPLS Network.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 September 7, 2020.		This Internet-Draft will expire on December 10, 2020.
	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 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3		2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3
	2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
	2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
	3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . . 4		3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario . . . . . 4
	4. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . . . 6		4. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . . . 6
	4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2. TSN over DetNet MPLS Encapsulation . . . . . . . . . . . 7		4.2. TSN over DetNet MPLS Encapsulation . . . . . . . . . . . 7
	5. TSN over MPLS Data Plane Procedures . . . . . . . . . . . . . 8		5. TSN over MPLS Data Plane Procedures . . . . . . . . . . . . . 8
	5.1. Edge Node TSN Procedures . . . . . . . . . . . . . . . . 8		5.1. Edge Node TSN Procedures . . . . . . . . . . . . . . . . 8
	5.2. Edge Node DetNet Service Proxy Procedures . . . . . . . . 9		5.2. Edge Node DetNet Service Proxy Procedures . . . . . . . . 10
	5.3. Edge Node DetNet Service and Forwarding Sub-Layer		5.3. Edge Node DetNet Service and Forwarding Sub-Layer
	Procedures . . . . . . . . . . . . . . . . . . . . . . . 10		Procedures . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Controller Plane (Management and Control) Considerations . . 11		6. Controller Plane (Management and Control) Considerations . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	10.1. Normative References . . . . . . . . . . . . . . . . . . 13		10.1. Normative References . . . . . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . 13		10.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1		The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1
	Working Group deals with deterministic services through IEEE 802		Working Group deals with deterministic services through IEEE 802
	networks. Deterministic Networking (DetNet) defined by IETF is a		networks. Deterministic Networking (DetNet) defined by IETF is a
	service that can be offered by a L3 network to DetNet flows. General		service that can be offered by a L3 network to DetNet flows. General
	background and concepts of DetNet can be found in [RFC8655].		background and concepts of DetNet can be found in [RFC8655].
	This document specifies the use of a DetNet MPLS network to		This document specifies the use of a DetNet MPLS network to
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 30 ¶
	3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario		3. IEEE 802.1 TSN Over DetNet MPLS Data Plane Scenario
	Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN aware		Figure 1 shows IEEE 802.1 TSN end stations operating over a TSN aware
	DetNet service running over an MPLS network. DetNet Edge Nodes sit		DetNet service running over an MPLS network. DetNet Edge Nodes sit
	at the boundary of a DetNet domain. They are responsible for mapping		at the boundary of a DetNet domain. They are responsible for mapping
	non-DetNet aware L2 traffic to DetNet services. They also support		non-DetNet aware L2 traffic to DetNet services. They also support
	the imposition and disposition of the required DetNet encapsulation.		the imposition and disposition of the required DetNet encapsulation.
	These are functionally similar to pseudowire (PW) Terminating		These are functionally similar to pseudowire (PW) Terminating
	Provider Edge (T-PE) nodes which use MPLS-TE LSPs. In this example		Provider Edge (T-PE) nodes which use MPLS-TE LSPs. In this example
	TSN Streams are simple applicaions over DetNet flows. The specific		TSN Streams are simple applications over DetNet flows. The specific
	of this operation are discussed later in this document.		of this operation are discussed later in this document.
	TSN Edge Transit Edge TSN		TSN Edge Transit Edge TSN
	End System Node Node Node End System		End System Node Node Node End System
	(T-PE) (LSR) (T-PE)		(T-PE) (LSR) (T-PE)
	+----------+ +----------+		+----------+ +----------+
	| TSN | <---------End to End TSN Service----------> | TSN |		| TSN | <---------End to End TSN Service----------> | TSN |
	| Applic. | | Applic. |		| Applic. | | Applic. |
	+----------+ +.........+ +.........+ +----------+		+----------+ +.........+ +.........+ +----------+
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 28 ¶
	allocation to eliminate (or reduce) congestion loss and jitter.		allocation to eliminate (or reduce) congestion loss and jitter.
	DetNet transit nodes reside wholly within a DetNet domain, and also		DetNet transit nodes reside wholly within a DetNet domain, and also
	provide DetNet forwarding sub-layer functions in accordance with the		provide DetNet forwarding sub-layer functions in accordance with the
	performance required by a DetNet flow carried over an LSP. Unlike		performance required by a DetNet flow carried over an LSP. Unlike
	other DetNet node types, transit nodes provide no service sub-layer		other DetNet node types, transit nodes provide no service sub-layer
	processing.		processing.
	4.2. TSN over DetNet MPLS Encapsulation		4.2. TSN over DetNet MPLS Encapsulation
	The basic encapsulation approach is to treat a TSN Stream as an app-		The basic encapsulation approach is to treat a TSN Stream as an App-
	flow from the DetNet MPLS perspective. The corresponding example		flow from the DetNet MPLS perspective. The corresponding example
	shown in Figure 3.		shown in Figure 3.
	/-> +------+ +------+ +------+ TSN ^ ^		/-> +------+ +------+ +------+ TSN ^ ^
	| | X | | X | | X |<- Appli : :		| | X | | X | | X |<- Appli : :
	App-Flow <-+ +------+ +------+ +------+ cation : :(1)		App-Flow <-+ +------+ +------+ +------+ cation : :(1)
	for MPLS | |TSN-L2| |TSN-L2| |TSN-L2| : v		for MPLS | |TSN-L2| |TSN-L2| |TSN-L2| : v
	\-> +---+======+--+======+--+======+-----+ :		\-> +---+======+--+======+--+======+-----+ :
	| d-CW | | d-CW | | d-CW | :		| d-CW | | d-CW | | d-CW | :
	DetNet-MPLS +------+ +------+ +------+ :(2)		DetNet-MPLS +------+ +------+ +------+ :(2)
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 37 ¶
	5.1. Edge Node TSN Procedures		5.1. Edge Node TSN Procedures
	The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1		The Time-Sensitive Networking (TSN) Task Group of the IEEE 802.1
	Working Group have defined (and are defining) a number of amendments		Working Group have defined (and are defining) a number of amendments
	to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and		to IEEE 802.1Q [IEEE8021Q] that provide zero congestion loss and
	bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB]		bounded latency in bridged networks. IEEE 802.1CB [IEEE8021CB]
	defines packet replication and elimination functions for a TSN		defines packet replication and elimination functions for a TSN
	network.		network.
			The implementation of TSN entity (i.e., TSN packet processing
			functions) MUST be compliant with the relevant IEEE 802.1 standards.
	TSN specific functions are executed on the data received by the		TSN specific functions are executed on the data received by the
	DetNet Edge Node from the connected CE before forwarded to connected		DetNet Edge Node from the connected CE before forwarded to connected
	CE(s) or presentation to the DetNet Service Proxy function for		CE(s) or presentation to the DetNet Service Proxy function for
	transmission across the DetNet domain, or on the data received from a		transmission across the DetNet domain, or on the data received from a
	DetNet PW by a PE before it is output on the Attachment Circuit(s)		DetNet PW by a PE before it is output on the Attachment Circuit(s)
	(AC).		(AC).
	TSN specific function(s) of Edge Nodes (T-PE) are belonging to the		TSN packet processing function(s) of Edge Nodes (T-PE) are belonging
	native service processing (NSP) [RFC3985] block. This is similar to		to the native service processing (NSP) [RFC3985] block. This is
	other functionalities being defined by standard bodies other than the		similar to other functionalities being defined by standard bodies
	IETF (for example in case of Ethernet: stripping, overwriting or		other than the IETF (for example in case of Ethernet: stripping,
	adding VLAN tags, etc.). Depending on the TSN role of the Edge Node		overwriting or adding VLAN tags, etc.). Depending on the TSN role of
	in the end-to-end TSN service selected TSN functions must be		the Edge Node in the end-to-end TSN service selected TSN functions
	supported.		are supported.
	When a PE receives a packet from a CE, on a given AC with DetNet		When a PE receives a packet from a CE, on a given AC with DetNet
	service, it MUST first check via Stream Identification whether the		service, it MUST first check via Stream Identification (see Clause 6.
	packet belongs to a configured TSN Stream (i.e., App-flow from DetNet		of IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])
	perspective). If no Stream ID is matched and no other (VPN) service		whether the packet belongs to a configured TSN Stream (i.e., App-flow
	is configured for the AC then packet MUST be dropped. If there is a		from DetNet perspective). If no Stream ID is matched and no other
	matching TSN Stream then the Stream-ID specific TSN functions MUST be		(VPN) service is configured for the AC then packet MUST be dropped.
	executed (e.g., ingress policing, header field manipulation in case		If there is a matching TSN Stream then the Stream-ID specific TSN
	of active Stream Identification, FRER, etc.). Source MAC lookup MAY		functions MUST be executed (e.g., ingress policing, header field
	also be used for local MAC address learning.		manipulation in case of active Stream Identification, FRER, etc.).
			Source MAC lookup MAY also be used for local MAC address learning.
	If the PE decides to forward the packet, the packet MUST be forwarded		If the PE decides to forward the packet, the packet MUST be forwarded
	according to the TSN Stream specific configuration to connected CE(s)		according to the TSN Stream specific configuration to connected CE(s)
	(in case of local bridging) and/or to the DetNet Service Proxy (in		(in case of local bridging) and/or to the DetNet Service Proxy (in
	case of forwarding to remote CE(s) required). If there are no TSN		case of forwarding to remote CE(s) required). If there are no TSN
	Stream specific forwarding configurations the PE MUST flood the		Stream specific forwarding configurations the PE MUST flood the
	packet to other locally attached CE(s) and to the DetNet Service		packet to other locally attached CE(s) and to the DetNet Service
	Proxy. If the administrative policy on the PE does not allow		Proxy. If the administrative policy on the PE does not allow
	flooding the PE MUST drop the packet.		flooding the PE MUST drop the packet.
	When a TSN entity of the PE receives a packet from the DetNet Service		When a TSN entity of the PE receives a packet from the DetNet Service
	Proxy, it MUST first check via Stream Identification whether the		Proxy, it MUST first check via Stream Identification (see Clause 6.
	packet belongs to a configured TSN Stream. If no Stream ID is		of IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb])
	matched then packet MUST be dropped. If there is a matching TSN		whether the packet belongs to a configured TSN Stream. If no Stream
	Stream then the Stream ID specific TSN functions MUST be executed		ID is matched then packet MUST be dropped. If there is a matching
			TSN Stream then the Stream ID specific TSN functions MUST be executed
	(e.g., header field manipulation in case of active Stream		(e.g., header field manipulation in case of active Stream
	Identification, FRER, etc.). Source MAC lookup MAY also be used for		Identification, FRER, etc.). Source MAC lookup MAY also be used for
	local MAC address learning.		local MAC address learning.
	If the PE decides to forward the packet, the packet MUST be forwarded		If the PE decides to forward the packet, the packet MUST be forwarded
	according to the TSN Stream specific configuration to connected		according to the TSN Stream specific configuration to connected
	CE(s). If there are no TSN Stream specific forwarding configurations		CE(s). If there are no TSN Stream specific forwarding configurations
	the PE MUST flood the packet to locally attached CE(s). If the		the PE MUST flood the packet to locally attached CE(s). If the
	administrative policy on the PE does not allow flooding the PE MUST		administrative policy on the PE does not allow flooding the PE MUST
	drop the packet.		drop the packet.
	Implementations of this document SHALL use management and control		Implementations of this document SHALL use management and control
	information to ensure TSN specific functions of the Edge Node		information to ensure TSN specific functions of the Edge Node
	according to the expectations of the connected TSN network.		according to the expectations of the connected TSN network.
	5.2. Edge Node DetNet Service Proxy Procedures		5.2. Edge Node DetNet Service Proxy Procedures
	The Service Proxy function maps between App-flows and DetNet flows.		The Service Proxy function maps between App-flows and DetNet flows.
	The DetNet Edge Node TSN entity MUST support the TSN Stream		The DetNet Edge Node TSN entity MUST support the TSN Stream
	identification functions and the related managed objects as defined		identification functions and the related managed objects as defined
	in IEEE 802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb] to		in Clause 6. and Clause 9. of IEEE 802.1CB [IEEE8021CB] and IEEE
	recognize the App-flow related packets. The Service Proxy presents		P802.1CBdb [IEEEP8021CBdb] to recognize the App-flow related packets.
	TSN Streams as an App-flow to a DetNet Flow.		The Service Proxy presents TSN Streams as an App-flow to a DetNet
			Flow.
	When a DetNet Service Proxy receives a packet from the TSN Entity it		When a DetNet Service Proxy receives a packet from the TSN Entity it
	MUST check whether such an App-flow is present in its mapping table.		MUST check whether such an App-flow is present in its mapping table.
	If present it associates the internal DetNet flow-ID to the packet		If present it associates the internal DetNet flow-ID to the packet
	and MUST forward it to the DetNet Service and Forwarding sub-layers.		and MUST forward it to the DetNet Service and Forwarding sub-layers.
	If no matching statement is present it MUST drop the packet.		If no matching statement is present it MUST drop the packet.
	When a DetNet Service Proxy receives a packet from the DetNet Service		When a DetNet Service Proxy receives a packet from the DetNet Service
	and Forwarding sub-layers it MUST be forwarded to the Edge Node TSN		and Forwarding sub-layers it MUST be forwarded to the Edge Node TSN
	Entity.		Entity.
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 39 ¶
	[I-D.ietf-detnet-mpls].		[I-D.ietf-detnet-mpls].
	6. Controller Plane (Management and Control) Considerations		6. Controller Plane (Management and Control) Considerations
	TSN Stream(s) to DetNet flow mapping related information are required		TSN Stream(s) to DetNet flow mapping related information are required
	only for the service proxy function of MPLS (DetNet) Edge nodes.		only for the service proxy function of MPLS (DetNet) Edge nodes.
	From the Data Plane perspective there is no practical difference		From the Data Plane perspective there is no practical difference
	based on the origin of flow mapping related information (management		based on the origin of flow mapping related information (management
	plane or control plane).		plane or control plane).
			The following summarizes the set of information that is needed to
			configure TSN over DetNet MPLS:
			o TSN related configuration information according to the TSN role of
			the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and
			[IEEEP8021CBdb].
			o DetNet MPLS related configuration information according to the
			DetNet role of the DetNet MPLS node, as per
			[I-D.ietf-detnet-mpls].
			o App-Flow identification information to map received TSN Stream(s)
			to the DetNet flow. Parameters fo TSN stream identification are
			defined in [IEEE8021CB] and [IEEEP8021CBdb].
			This information MUST be provisioned per DetNet flow.
	MPLS DetNet Edge nodes are member of both the DetNet domain and the		MPLS DetNet Edge nodes are member of both the DetNet domain and the
	connected TSN network. From the TSN network perspective the MPLS		connected TSN network. From the TSN network perspective the MPLS
	(DetNet) Edge node has a "TSN relay node" role, so TSN specific		(DetNet) Edge node has a "TSN relay node" role, so TSN specific
	management and control plane functionalities must be implemented.		management and control plane functionalities must be implemented.
	There are many similarities in the management plane techniques used		There are many similarities in the management plane techniques used
	in DetNet and TSN, but that is not the case for the control plane		in DetNet and TSN, but that is not the case for the control plane
	protocols. For example, RSVP-TE and MSRP behaves differently.		protocols. For example, RSVP-TE and MSRP behaves differently.
	Therefore management and control plane design is an important aspect		Therefore management and control plane design is an important aspect
	of scenarios, where mapping between DetNet and TSN is required.		of scenarios, where mapping between DetNet and TSN is required.
	skipping to change at page 12, line 33 ¶		skipping to change at page 13, line 9 ¶
	Configuration of TSN specific functions (e.g., FRER) inside the TSN		Configuration of TSN specific functions (e.g., FRER) inside the TSN
	network is a TSN domain specific decision and may not be visible in		network is a TSN domain specific decision and may not be visible in
	the DetNet domain. Service protection interworking scenarios are		the DetNet domain. Service protection interworking scenarios are
	left for further study.		left for further study.
	7. Security Considerations		7. Security Considerations
	Security considerations for DetNet are described in detail in		Security considerations for DetNet are described in detail in
	[I-D.ietf-detnet-security]. General security considerations are		[I-D.ietf-detnet-security]. General security considerations are
	described in [RFC8655]. DetNet MPLS data plane specific		described in [RFC8655].
	considerations are summarized in [I-D.ietf-detnet-mpls]. The primary
	considerations for the data plane is to maintain integrity of data		DetNet MPLS data plane specific considerations are summarized and
	and delivery of the associated DetNet service traversing the DetNet		described in [I-D.ietf-detnet-mpls] including any application flow
	network. Application flows can be protected through whatever means		types. This document focuses on the scenario where TSN Streams are
	is provided by the underlying technology. For example, encryption		the application flows for DetNet and it is already covered by those
	may be used, such as that provided by IPSec [RFC4301] for IP flows		DetNet MPLS data plane security considerations.
	and/or by an underlying sub-net using MACSec [IEEE802.1AE-2018] for
	IP over Ethernet (Layer-2) flows.
	8. IANA Considerations		8. IANA Considerations
	This document makes no IANA requests.		This document makes no IANA requests.
	9. Acknowledgements		9. Acknowledgements
	The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,		The authors wish to thank Norman Finn, Lou Berger, Craig Gunther,
	Christophe Mangin and Jouni Korhonen for their various contributions		Christophe Mangin and Jouni Korhonen for their various contributions
	to this work.		to this work.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-detnet-mpls]		[I-D.ietf-detnet-mpls]
	Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,		Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S.,
	Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",		and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-
	draft-ietf-detnet-mpls-05 (work in progress), February		detnet-mpls-06 (work in progress), April 2020.
	2020.
	[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>.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031,		Label Switching Architecture", RFC 3031,
	DOI 10.17487/RFC3031, January 2001,		DOI 10.17487/RFC3031, January 2001,
	<https://www.rfc-editor.org/info/rfc3031>.		<https://www.rfc-editor.org/info/rfc3031>.
	[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>.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-detnet-data-plane-framework]		[I-D.ietf-detnet-data-plane-framework]
	Varga, B., Farkas, J., Berger, L., Malis, A., and S.		Varga, B., Farkas, J., Berger, L., Malis, A., and S.
	Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-		Bryant, "DetNet Data Plane Framework", draft-ietf-detnet-
	data-plane-framework-04 (work in progress), February 2020.		data-plane-framework-06 (work in progress), May 2020.
	[I-D.ietf-detnet-security]		[I-D.ietf-detnet-security]
	Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,		Mizrahi, T. and E. Grossman, "Deterministic Networking
	J., Austad, H., and N. Finn, "Deterministic Networking
	(DetNet) Security Considerations", draft-ietf-detnet-		(DetNet) Security Considerations", draft-ietf-detnet-
	security-08 (work in progress), February 2020.		security-10 (work in progress), May 2020.
	[IEEE802.1AE-2018]		[IEEE802.1AE-2018]
	IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC		IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC
	Security (MACsec)", 2018,		Security (MACsec)", 2018,
	<https://ieeexplore.ieee.org/document/8585421>.		<https://ieeexplore.ieee.org/document/8585421>.
	[IEEE8021CB]		[IEEE8021CB]
	Finn, N., "Draft Standard for Local and metropolitan area		Finn, N., "Draft Standard for Local and metropolitan area
	networks - Seamless Redundancy", IEEE P802.1CB		networks - Seamless Redundancy", IEEE P802.1CB
	/D2.1 P802.1CB, December 2015,		/D2.1 P802.1CB, December 2015,
	skipping to change at page 15, line 4 ¶		skipping to change at page 15, line 25 ¶
	Authors' Addresses		Authors' Addresses
	Balazs Varga (editor)		Balazs Varga (editor)
	Ericsson		Ericsson
	Magyar Tudosok krt. 11.		Magyar Tudosok krt. 11.
	Budapest 1117		Budapest 1117
	Hungary		Hungary
	Email: balazs.a.varga@ericsson.com		Email: balazs.a.varga@ericsson.com
	Janos Farkas		Janos Farkas
	Ericsson		Ericsson
	Magyar Tudosok krt. 11.		Magyar Tudosok krt. 11.
	Budapest 1117		Budapest 1117
	Hungary		Hungary
	Email: janos.farkas@ericsson.com		Email: janos.farkas@ericsson.com
	Andrew G. Malis		Andrew G. Malis
	Independent		Malis Consulting
	Email: agmalis@gmail.com		Email: agmalis@gmail.com
	Stewart Bryant		Stewart Bryant
	Futurewei Technologies		Futurewei Technologies
	Email: stewart.bryant@gmail.com		Email: stewart.bryant@gmail.com
	Don Fedyk		Don Fedyk
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
End of changes. 22 change blocks.
	53 lines changed or deleted		73 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/