< draft-ietf-detnet-mpls-over-tsn-02.txt		draft-ietf-detnet-mpls-over-tsn-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
	March 6, 2020		June 8, 2020
	DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN)		DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN)
	draft-ietf-detnet-mpls-over-tsn-02		draft-ietf-detnet-mpls-over-tsn-03
	Abstract		Abstract
	This document specifies the Deterministic Networking MPLS data plane		This document specifies the Deterministic Networking MPLS data plane
	when operating over a TSN sub-network.		when operating over a TSN sub-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 35 ¶		skipping to change at page 1, line 35 ¶
	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.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 . . . . . . . . . . . . . . . . . . 3		2.3. Requirements Language . . . . . . . . . . . . . . . . . . 3
	3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 4		3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 4
	4. DetNet MPLS Operation Over IEEE 802.1 TSN Sub-Networks . . . 5		4. DetNet MPLS Operation Over IEEE 802.1 TSN Sub-Networks . . . 5
	4.1. Functions for DetNet Flow to TSN Stream Mapping . . . . . 7		4.1. Functions for DetNet Flow to TSN Stream Mapping . . . . . 7
	4.2. TSN requirements of MPLS DetNet nodes . . . . . . . . . . 7		4.2. TSN requirements of MPLS DetNet nodes . . . . . . . . . . 7
	4.3. Service protection within the TSN sub-network . . . . . . 9		4.3. Service protection within the TSN sub-network . . . . . . 9
	4.4. Aggregation during DetNet flow to TSN Stream mapping . . 9		4.4. Aggregation during DetNet flow to TSN Stream mapping . . 9
	5. Management and Control Implications . . . . . . . . . . . . . 9		5. Management and Control Implications . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . 11		9.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Deterministic Networking (DetNet) is a service that can be offered by		Deterministic Networking (DetNet) is a service that can be offered by
	a network to DetNet flows. DetNet provides these flows with a low		a network to DetNet flows. DetNet provides these flows with a low
	packet loss rates and assured maximum end-to-end delivery latency.		packet loss rates and assured maximum end-to-end delivery latency.
	General background and concepts of DetNet can be found in [RFC8655].		General background and concepts of DetNet can be found in [RFC8655].
	The DetNet Architecture decomposes the DetNet related data plane		The DetNet Architecture decomposes the DetNet related data plane
	functions into two sub-layers: a service sub-layer and a forwarding		functions into two sub-layers: a service sub-layer and a forwarding
	skipping to change at page 6, line 37 ¶		skipping to change at page 6, line 37 ¶
	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. Furthermore IEEE 802.1CB		bounded latency in bridged networks. Furthermore IEEE 802.1CB
	[IEEE8021CB] defines frame replication and elimination functions for		[IEEE8021CB] defines frame replication and elimination functions for
	reliability that should prove both compatible with and useful to,		reliability that should prove both compatible with and useful to,
	DetNet networks. All these functions have to identify flows those		DetNet networks. All these functions have to identify flows those
	require TSN treatment.		require TSN treatment.
	TSN capabilities of the TSN sub-network are made available for MPLS		TSN capabilities of the TSN sub-network are made available for MPLS
	(DetNet) flows via the protocol interworking function defined in IEEE		(DetNet) flows via the protocol interworking function defined in
	802.1CB [IEEE8021CB]. For example, applied on the TSN edge port it		Annex C.5 of IEEE 802.1CB [IEEE8021CB]. For example, applied on the
	can convert an ingress unicast MPLS (DetNet) flow to use a specific		TSN edge port it can convert an ingress unicast MPLS (DetNet) flow to
	Layer-2 multicast destination MAC address and a VLAN, in order to		use a specific Layer-2 multicast destination MAC address and a VLAN,
	direct the packet through a specific path inside the bridged network.		in order to direct the packet through a specific path inside the
	A similar interworking function pair at the other end of the TSN sub-		bridged network. A similar interworking function pair at the other
	network would restore the packet to its original Layer-2 destination		end of the TSN sub-network would restore the packet to its original
	MAC address and VLAN.		Layer-2 destination MAC address and VLAN.
	Placement of TSN functions depends on the TSN capabilities of nodes.		Placement of TSN functions depends on the TSN capabilities of nodes.
	MPLS (DetNet) Nodes may or may not support TSN functions. For a		MPLS (DetNet) Nodes may or may not support TSN functions. For a
	given TSN Stream (i.e., DetNet flow) an MPLS (DetNet) node is treated		given TSN Stream (i.e., DetNet flow) an MPLS (DetNet) node is treated
	as a Talker or a Listener inside the TSN sub-network.		as a Talker or a Listener inside the TSN sub-network.
	4.1. Functions for DetNet Flow to TSN Stream Mapping		4.1. Functions for DetNet Flow to TSN Stream Mapping
	Mapping of a DetNet MPLS flow to a TSN Stream is provided via the		Mapping of a DetNet MPLS flow to a TSN Stream is provided via the
	combination of a passive and an active stream identification function		combination of a passive and an active stream identification function
	that operate at the frame level. The passive stream identification		that operate at the frame level. The passive stream identification
	function is used to catch the MPLS label(s) of a DetNet MPLS flow and		function is used to catch the MPLS label(s) of a DetNet MPLS flow and
	the active stream identification function is used to modify the		the active stream identification function is used to modify the
	Ethernet header according to the ID of the mapped TSN Stream.		Ethernet header according to the ID of the mapped TSN Stream.
	IEEE P802.1CBdb [IEEEP8021CBdb] defines a Mask-and-Match Stream		Clause 6.8 of IEEE P802.1CBdb [IEEEP8021CBdb] defines a Mask-and-
	identification function that can be used as a passive function for		Match Stream identification function that can be used as a passive
	MPLS DetNet flows.		function for MPLS DetNet flows.
	IEEE 802.1CB [IEEE8021CB] defines an Active Destination MAC and VLAN		Clause 6.6 of IEEE 802.1CB [IEEE8021CB] defines an Active Destination
	Stream identification function, what can replace some Ethernet header		MAC and VLAN Stream identification function, what can replace some
	fields namely (1) the destination MAC-address, (2) the VLAN-ID and		Ethernet header fields namely (1) the destination MAC-address, (2)
	(3) priority parameters with alternate values. Replacement is		the VLAN-ID and (3) priority parameters with alternate values.
	provided for the frame passed down the stack from the upper layers or		Replacement is provided for the frame passed down the stack from the
	up the stack from the lower layers.		upper layers or up the stack from the lower layers.
	Active Destination MAC and VLAN Stream identification can be used		Active Destination MAC and VLAN Stream identification can be used
	within a Talker to set flow identity or a Listener to recover the		within a Talker to set flow identity or a Listener to recover the
	original addressing information. It can be used also in a TSN bridge		original addressing information. It can be used also in a TSN bridge
	that is providing translation as a proxy service for an End System.		that is providing translation as a proxy service for an End System.
	4.2. TSN requirements of MPLS DetNet nodes		4.2. TSN requirements of MPLS DetNet nodes
	This section covers required behavior of a TSN-aware MPLS (DetNet)		This section covers required behavior of a TSN-aware MPLS (DetNet)
	node using a TSN sub-network.		node using a TSN sub-network. The implementation of TSN packet
			processing functions MUST be compliant with the relevant IEEE 802.1
			standards.
	From the TSN sub-network perspective MPLS (DetNet) nodes are treated		From the TSN sub-network perspective MPLS (DetNet) nodes are treated
	as Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware.		as Talker or Listener, that may be (1) TSN-unaware or (2) TSN-aware.
	In cases of TSN-unaware MPLS DetNet nodes the TSN relay nodes within		In cases of TSN-unaware MPLS DetNet nodes the TSN relay nodes within
	the TSN sub-network must modify the Ethernet encapsulation of the		the TSN sub-network must modify the Ethernet encapsulation of the
	DetNet MPLS flow (e.g., MAC translation, VLAN-ID setting, Sequence		DetNet MPLS flow (e.g., MAC translation, VLAN-ID setting, Sequence
	number addition, etc.) to allow proper TSN specific handling inside		number addition, etc.) to allow proper TSN specific handling inside
	the sub-network. There are no requirements defined for TSN-unaware		the sub-network. There are no requirements defined for TSN-unaware
	MPLS DetNet nodes in this document.		MPLS DetNet nodes in this document.
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	Identification TSN component for recognizing flows.		Identification TSN component for recognizing flows.
	A Stream identification component MUST be able to instantiate the		A Stream identification component MUST be able to instantiate the
	following functions (1) Active Destination MAC and VLAN Stream		following functions (1) Active Destination MAC and VLAN Stream
	identification function, (2) Mask-and-Match Stream identification		identification function, (2) Mask-and-Match Stream identification
	function and (3) the related managed objects in Clause 9 of IEEE		function and (3) the related managed objects in Clause 9 of IEEE
	802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb].		802.1CB [IEEE8021CB] and IEEE P802.1CBdb [IEEEP8021CBdb].
	A TSN-aware MPLS (DetNet) node implementations MUST support the		A TSN-aware MPLS (DetNet) node implementations MUST support the
	Sequencing function and the Sequence encode/decode function as		Sequencing function and the Sequence encode/decode function as
	defined in IEEE 802.1CB [IEEE8021CB] if FRER is used inside the TSN		defined in Clause 7.4 and 7.6 of IEEE 802.1CB [IEEE8021CB] if FRER is
	sub-network.		used inside the TSN sub-network.
	The Sequence encode/decode function MUST support the Redundancy tag		The Sequence encode/decode function MUST support the Redundancy tag
	(R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB].		(R-TAG) format as per Clause 7.8 of IEEE 802.1CB [IEEE8021CB].
	A TSN-aware MPLS (DetNet) node implementations MUST support the		A TSN-aware MPLS (DetNet) node implementations MUST support the
	Stream splitting function and the Individual recovery function as		Stream splitting function and the Individual recovery function as
	defined in IEEE 802.1CB [IEEE8021CB] when the node is a replication		defined in Clause 7.7 and 7.5 of IEEE 802.1CB [IEEE8021CB] when the
	or elimination point for FRER.		node is a replication or elimination point for FRER.
	4.3. Service protection within the TSN sub-network		4.3. Service protection within the TSN sub-network
	TSN Streams supporting DetNet flows may use Frame Replication and		TSN Streams supporting DetNet flows may use Frame Replication and
	Elimination for Redundancy (FRER) as defined in IEEE 802.1CB		Elimination for Redundancy (FRER) as defined in Clause 8. of IEEE
	[IEEE8021CB] based on the loss service requirements of the TSN		802.1CB [IEEE8021CB] based on the loss service requirements of the
	Stream, which is derived from the DetNet service requirements of the		TSN Stream, which is derived from the DetNet service requirements of
	DetNet mapped flow. The specific operation of FRER is not modified		the DetNet mapped flow. The specific operation of FRER is not
	by the use of DetNet and follows IEEE 802.1CB [IEEE8021CB].		modified by the use of DetNet and follows IEEE 802.1CB [IEEE8021CB].
	FRER function and the provided service recovery is available only		FRER function and the provided service recovery is available only
	within the TSN sub-network as the TSN Stream-ID and the TSN sequence		within the TSN sub-network as the TSN Stream-ID and the TSN sequence
	number are not valid outside the sub-network. An MPLS (DetNet) node		number are not valid outside the sub-network. An MPLS (DetNet) node
	represents a L3 border and as such it terminates all related		represents a L3 border and as such it terminates all related
	information elements encoded in the L2 frames.		information elements encoded in the L2 frames.
	As the Stream-ID and the TSN sequence number are paired with the		As the Stream-ID and the TSN sequence number are paired with the
	similar MPLS flow parameters, FRER can be combined with PREOF		similar MPLS flow parameters, FRER can be combined with PREOF
	functions. Such service protection interworking scenarios may		functions. Such service protection interworking scenarios may
	skipping to change at page 9, line 42 ¶		skipping to change at page 9, line 42 ¶
	ensure that adequate resources are allocated and configured to		ensure that adequate resources are allocated and configured to
	provide proper service requirements of the mapped flows.		provide proper service requirements of the mapped flows.
	5. Management and Control Implications		5. Management and Control Implications
	DetNet flow and TSN Stream mapping related information are required		DetNet flow and TSN Stream mapping related information are required
	only for TSN-aware MPLS (DetNet) nodes. From the Data Plane		only for TSN-aware MPLS (DetNet) nodes. From the Data Plane
	perspective there is no practical difference based on the origin of		perspective there is no practical difference based on the origin of
	flow mapping related information (management plane or control plane).		flow mapping related information (management plane or control plane).
			The following summarizes the set of information that is needed to
			configure DetNet MPLS over TSN:
			o DetNet MPLS related configuration information according to the
			DetNet role of the DetNet MPLS node, as per
			[I-D.ietf-detnet-mpls].
			o TSN related configuration information according to the TSN role of
			the DetNet MPLS node, as per [IEEE8021Q], [IEEE8021CB] and
			[IEEEP8021CBdb].
			o Mapping between DetNet MPLS flow(s) (label information: A-labels,
			S-labels and F-labels as defined in [I-D.ietf-detnet-mpls]) and
			TSN Stream(s) (as stream identification information defined in
			[IEEEP8021CBdb]). Note, that managed objects for TSN Stream
			identification can be found in [IEEEP8021CBcv].
			This information MUST be provisioned per DetNet flow.
	TSN-aware MPLS DetNet nodes are member of both the DetNet domain and		TSN-aware MPLS DetNet nodes are member of both the DetNet domain and
	the TSN sub-network. Within the TSN sub-network the TSN-aware MPLS		the TSN sub-network. Within the TSN sub-network the TSN-aware MPLS
	(DetNet) node has a TSN-aware Talker/Listener role, so TSN specific		(DetNet) node has a TSN-aware Talker/Listener 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 10, line 44 ¶		skipping to change at page 11, line 14 ¶
	complicated as they are fully unaware of the sub-network and run		complicated as they are fully unaware of the sub-network and run
	independently.		independently.
	Configuration of TSN specific functions (e.g., FRER) inside the TSN		Configuration of TSN specific functions (e.g., FRER) inside the TSN
	sub-network is a TSN domain specific decision and may not be visible		sub-network is a TSN domain specific decision and may not be visible
	in the DetNet domain. Service protection interworking scenarios are		in the DetNet domain. Service protection interworking scenarios are
	left for further study.		left for further study.
	6. Security Considerations		6. Security Considerations
	The security considerations of DetNet in general are discussed in		Security considerations for DetNet are described in detail in
	[RFC8655] and [I-D.ietf-detnet-security]. DetNet IP data plane		[I-D.ietf-detnet-security]. General security considerations are
	specific considerations are summarized in [I-D.ietf-detnet-ip].		described in [RFC8655]. DetNet MPLS data plane specific
	Encryption may provided by an underlying sub-net using MACSec		considerations are summarized in [I-D.ietf-detnet-mpls]. This
	[IEEE802.1AE-2018] for DetNet IP over TSN flows.		section considers exclusively security considerations which are
			specific to the DetNet MPLS over TSN sub-network scenario.
			The sub-network between DetNet nodes needs to be subject to
			appropriate confidentiality. Additionally, knowledge of what DetNet/
			TSN services are provided by a sub-network may supply information
			that can be used in a variety of security attacks. The ability to
			modify information exchanges between connected DetNet nodes may
			result in bogus operations. Therefore, it is important that the
			interface between DetNet nodes and TSN sub-network are subject to
			authorization, authentication, and encryption.
			The TSN sub-network operates at Layer-2 so various security
			mechanisms defined by IEEE can be used to secure the connection
			between the DetNet nodes (e.g., encryption may be provided using
			MACSec [IEEE802.1AE-2018]).
	7. IANA Considerations		7. IANA Considerations
	This document makes no IANA requests.		This document makes no IANA requests.
	8. Acknowledgements		8. 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.
	9. References		9. References
	9.1. Normative References		9.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>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-detnet-ip]		[I-D.ietf-detnet-ip]
	Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,		Varga, B., Farkas, J., Berger, L., Fedyk, D., and S.
	and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-		Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-06
	ip-05 (work in progress), February 2020.		(work in progress), April 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,
	<http://www.ieee802.org/1/files/private/cb-drafts/d2/802-		<http://www.ieee802.org/1/files/private/cb-drafts/d2/802-
	1CB-d2-1.pdf>.		1CB-d2-1.pdf>.
	[IEEE8021Q]		[IEEE8021Q]
	IEEE 802.1, "Standard for Local and metropolitan area		IEEE 802.1, "Standard for Local and metropolitan area
	networks--Bridges and Bridged Networks (IEEE Std 802.1Q-		networks--Bridges and Bridged Networks (IEEE Std 802.1Q-
	2014)", 2014, <http://standards.ieee.org/about/get/>.		2014)", 2014, <http://standards.ieee.org/about/get/>.
			[IEEEP8021CBcv]
			Kehrer, S., "FRER YANG Data Model and Management
			Information Base Module", IEEE P802.1CBcv
			/D0.3 P802.1CBcv, May 2020,
			<http://www.ieee802.org/1/files/private/cv-drafts/d0/802-
			1CBcv-d0-3.pdf>.
	[IEEEP8021CBdb]		[IEEEP8021CBdb]
	Mangin, C., "Extended Stream identification functions",		Mangin, C., "Extended Stream identification functions",
	IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019,		IEEE P802.1CBdb /D0.2 P802.1CBdb, August 2019,
	<http://www.ieee802.org/1/files/private/cb-drafts/d2/802-		<http://www.ieee802.org/1/files/private/cb-drafts/d2/802-
	1CB-d2-1.pdf>.		1CB-d2-1.pdf>.
	[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,		[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", RFC 8655,		"Deterministic Networking Architecture", RFC 8655,
	DOI 10.17487/RFC8655, October 2019,		DOI 10.17487/RFC8655, October 2019,
	<https://www.rfc-editor.org/info/rfc8655>.		<https://www.rfc-editor.org/info/rfc8655>.
	skipping to change at page 13, line 4 ¶		skipping to change at page 13, line 40 ¶
	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
End of changes. 22 change blocks.
	51 lines changed or deleted		93 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/