rfc9730v1.txt		rfc9730.txt
	Internet Engineering Task Force (IETF) H. Zheng		Internet Engineering Task Force (IETF) H. Zheng
	Request for Comments: 9730 Y. Lin		Request for Comments: 9730 Y. Lin
	Category: Informational Huawei Technologies		Category: Informational Huawei Technologies
	ISSN: 2070-1721 Y. Zhao		ISSN: 2070-1721 Y. Zhao
	China Mobile		China Mobile
	Y. Xu		Y. Xu
	CAICT		CAICT
	D. Beller		D. Beller
	Nokia		Nokia
	January 2025		March 2025
	Interworking of GMPLS Control and Centralized Controller Systems		Interworking of GMPLS Control and Centralized Controller Systems
	Abstract		Abstract
	Generalized Multiprotocol Label Switching (GMPLS) control allows each		Generalized Multiprotocol Label Switching (GMPLS) control allows each
	network element (NE) to perform local resource discovery, routing,		network element (NE) to perform local resource discovery, routing,
	and signaling in a distributed manner.		and signaling in a distributed manner.
	The advancement of software-defined transport networking technology		The advancement of software-defined transport networking technology
	skipping to change at line 180 ¶		skipping to change at line 180 ¶
	H-PCE: Hierarchical PCE [RFC8685]		H-PCE: Hierarchical PCE [RFC8685]
	IDS: Intrusion Detection System		IDS: Intrusion Detection System
	IGP: Interior Gateway Protocol		IGP: Interior Gateway Protocol
	IoCs: Indicators of Compromise [RFC9424]		IoCs: Indicators of Compromise [RFC9424]
	IPS: Intrusion Prevention System		IPS: Intrusion Prevention System
	IS-IS: Intermediate System to Intermediate System protocol		IS-IS: Intermediate System to Intermediate System
	LMP: Link Management Protocol [RFC4204]		LMP: Link Management Protocol [RFC4204]
	LSP: Label Switched Path		LSP: Label Switched Path
	LSP-DB: LSP Database		LSP-DB: LSP Database
	MD: multi-domain		MD: multi-domain
	MDSC: Multi-Domain Service Coordinator [RFC8453]		MDSC: Multi-Domain Service Coordinator [RFC8453]
	skipping to change at line 204 ¶		skipping to change at line 204 ¶
	ML: multi-layer		ML: multi-layer
	MPI: MDSC to PNC Interface [RFC8453]		MPI: MDSC to PNC Interface [RFC8453]
	NE: network element		NE: network element
	NETCONF: Network Configuration Protocol [RFC6241]		NETCONF: Network Configuration Protocol [RFC6241]
	NMS: Network Management System		NMS: Network Management System
	OSPF: Open Shortest Path First protocol		OSPF: Open Shortest Path First
	PCC: Path Computation Client [RFC4655]		PCC: Path Computation Client [RFC4655]
	PCE: Path Computation Element [RFC4655]		PCE: Path Computation Element [RFC4655]
	PCEP: PCE Communication Protocol [RFC5440]		PCEP: PCE Communication Protocol [RFC5440]
	PCEP-LS: Link State PCEP [PCEP-LS]		PCEP-LS: Link State PCEP [PCEP-LS]
	PLR: Point of Local Repair		PLR: Point of Local Repair
	skipping to change at line 330 ¶		skipping to change at line 330 ¶
	Controller(N): A domain controller controlling a non-GMPLS domain		Controller(N): A domain controller controlling a non-GMPLS domain
	Controller(G): A domain controller controlling a GMPLS domain		Controller(G): A domain controller controlling a GMPLS domain
	Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS		Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS
	domain. This system supports the interworking among non-GMPLS		domain. This system supports the interworking among non-GMPLS
	domains, GMPLS domains, and the controller hierarchies.		domains, GMPLS domains, and the controller hierarchies.
	For domain 1, the network elements were not enabled with GMPLS, so		For domain 1, the network elements were not enabled with GMPLS, so
	the control is purely from the controller, via Network Configuration		the control is purely from the controller, via Network Configuration
	Protocol (NETCONF) [RFC6241] / YANG and/or PCE Communication Protocol		Protocol (NETCONF) [RFC6241] with a YANG data model [RFC7950] and/or
	(PCEP) [RFC5440].		PCE Communication Protocol (PCEP) [RFC5440].
	For domains 2 and 3:		For domains 2 and 3:
	* Each domain has the GMPLS control plane enabled at the physical		* Each domain has the GMPLS control plane enabled at the physical
	network level. The Provisioning Network Controller (PNC) can		network level. The Provisioning Network Controller (PNC) can
	exploit GMPLS capabilities implemented in the domain to listen to		exploit GMPLS capabilities implemented in the domain to listen to
	the IGP routing protocol messages (for example, OSPF Link State		the IGP routing protocol messages (for example, OSPF Link State
	Advertisements (LSAs)) that the GMPLS control plane instances are		Advertisements (LSAs)) that the GMPLS control plane instances are
	disseminating into the network and thus learn the network		disseminating into the network and thus learn the network
	topology. For path computation in the domain with the PNC		topology. For path computation in the domain with the PNC
	skipping to change at line 712 ¶		skipping to change at line 712 ¶
	downstream domain and its upstream neighbor domain; and		downstream domain and its upstream neighbor domain; and
	this stitching label will be passed to the upstream		this stitching label will be passed to the upstream
	neighbor domain by PCE protocol, which will be used for the		neighbor domain by PCE protocol, which will be used for the
	path segment creation in the upstream neighbor domain.		path segment creation in the upstream neighbor domain.
	2.2) Inter-domain labels assigned by the controller:		2.2) Inter-domain labels assigned by the controller:
	If the resources of inter-domain links are managed by the		If the resources of inter-domain links are managed by the
	Orchestrator(MD), each domain controller can provide to the		Orchestrator(MD), each domain controller can provide to the
	Orchestrator(MD) the list of available labels (e.g., time		Orchestrator(MD) the list of available labels (e.g., time
	slots, if the OTN is the scenario) using the IETF Topology		slots if the OTN is the scenario) using topology-related
	YANG module and a related technology-specific extension.		YANG modules and specific technology-related extensions.
	Once the Orchestrator(MD) has computed the E2E path, RSVP-		Once the orchestrator(MD) has computed the E2E path, RSVP-
	TE or PCEP can be used in the different domains to set up		TE or PCEP can be used in the different domains to set up
	the related segment tunnel consisting of label inter-domain		the related segment tunnel consisting of information about
	information; for example, for PCEP, the label Explicit		inter-domain labels; for example, for PCEP, the label
	Route Object (ERO) can be included in the PCInitiate		Explicit Route Object (ERO) can be included in the
	message to indicate the inter-domain labels so that each		PCInitiate message to indicate the inter-domain labels so
	border node of each domain can configure the correct cross-		that each border node of each domain can configure the
	connect within itself.		correct cross-connect within itself.
	8.3. Multi-Layer Service Provisioning		8.3. Multi-Layer Service Provisioning
	GMPLS can interwork with centralized controller systems in multi-		GMPLS can interwork with centralized controller systems in multi-
	layer networks.		layer networks.
	+----------------+		+----------------+
	|Orchestrator(ML)|		|Orchestrator(ML)|
	+------+--+------+		+------+--+------+
	| | Higher-layer Network		| | Higher-layer Network
	skipping to change at line 799 ¶		skipping to change at line 799 ¶
	To apply [RFC5623] in a multi-layer network with GMPLS-controller		To apply [RFC5623] in a multi-layer network with GMPLS-controller
	interworking, the H-Controller and the L-Controller can act as the		interworking, the H-Controller and the L-Controller can act as the
	PCE Hi and PCE Lo, respectively; and typically, the Orchestrator(ML)		PCE Hi and PCE Lo, respectively; and typically, the Orchestrator(ML)
	can act as a VNTM because it has the abstracted view of both the		can act as a VNTM because it has the abstracted view of both the
	higher-layer and lower-layer networks.		higher-layer and lower-layer networks.
	Table 1 shows all possible combinations of path computation and path		Table 1 shows all possible combinations of path computation and path
	control models in multi-layer network with GMPLS-controller		control models in multi-layer network with GMPLS-controller
	interworking:		interworking:
	+=====================+=================+===========+===========+		+======================+========+================+===============+
	| Path computation / | Single PCE (Not | Multiple | Multiple |		| Path computation / | Single | Multiple PCE | Multiple PCE |
	| Path control | applicable) | PCE with | PCE w/o |		| Path control | PCE | with inter-PCE | w/o inter-PCE |
	| | | inter-PCE | inter-PCE |		+======================+========+================+===============+
	+=====================+=================+===========+===========+		| PCE-VNTM cooperation | N/A | Yes | Yes |
	| PCE-VNTM | N/A | Yes | Yes |		+----------------------+--------+----------------+---------------+
	| cooperation | | | |		| Higher-layer | N/A | Yes | Yes |
	+---------------------+-----------------+-----------+-----------+		| signaling trigger | | | |
	| Higher-layer | N/A | Yes | Yes |		+----------------------+--------+----------------+---------------+
	| signaling trigger | | | |		| NMS-VNTM cooperation | N/A | Yes (1) | No (1) |
	+---------------------+-----------------+-----------+-----------+		| (integrated flavor) | | | |
	| NMS-VNTM | N/A | Yes (1) | No (1) |		+----------------------+--------+----------------+---------------+
	| cooperation | | | |		| NMS-VNTM cooperation | N/A | No (1) | Yes (1) |
	| (integrated flavor) | | | |		| (separate flavor) | | | |
	+---------------------+-----------------+-----------+-----------+		+----------------------+--------+----------------+---------------+
	| NMS-VNTM | N/A | No (1) | Yes (1) |
	| cooperation | | | |
	| (separate flavor) | | | |
	+---------------------+-----------------+-----------+-----------+
	Table 1: Combinations of Path Computation and Path Control Models		Table 1: Combinations of Path Computation and Path Control Models
	Note that:		Note that:
	* Since there is one PCE in each layer network, the path computation		* Since there is one PCE in each layer network, the path computation
	model "Single PCE path computation" is not applicable (N/A).		model "Single PCE path computation" is not applicable (N/A).
	* For the other two path computation models "Multiple PCE with		* For the other two path computation models "Multiple PCE with
	inter-PCE" and "Multiple PCE w/o inter-PCE", the possible		inter-PCE" and "Multiple PCE w/o inter-PCE", the possible
	combinations are the same as defined in [RFC5623]. More		combinations are the same as defined in [RFC5623]. More
	specifically:		specifically:
	skipping to change at line 842 ¶		skipping to change at line 838 ¶
	flavor)" and "NMS-VNTM cooperation (separate flavor)" are the		flavor)" and "NMS-VNTM cooperation (separate flavor)" are the
	typical models to be used in a multi-layer network with GMPLS-		typical models to be used in a multi-layer network with GMPLS-
	controller interworking. This is because, in these two models,		controller interworking. This is because, in these two models,
	the path computation is triggered by the NMS or VNTM. And in		the path computation is triggered by the NMS or VNTM. And in
	the centralized controller system, the path computation		the centralized controller system, the path computation
	requests are typically from the Orchestrator(ML) (acts as		requests are typically from the Orchestrator(ML) (acts as
	VNTM).		VNTM).
	- For the other two path control models "PCE-VNTM cooperation"		- For the other two path control models "PCE-VNTM cooperation"
	and "Higher-layer signaling trigger", the path computation is		and "Higher-layer signaling trigger", the path computation is
	triggered by the NEs, i.e., the NE performs PCC functions.		triggered by the NEs, i.e., the NE performs PCC functions. It
	These two models are still possible to be used, although they		is still possible to use these two models, although they are
	are not the main methods.		not the main methods.
	8.3.2. Cross-Layer Path Creation		8.3.2. Cross-Layer Path Creation
	In a multi-layer network, a lower-layer LSP in the lower-layer		In a multi-layer network, a lower-layer LSP in the lower-layer
	network can be created, which will construct a new link in the		network can be created, which will construct a new link in the
	higher-layer network. Such a lower-layer LSP is called Hierarchical		higher-layer network. Such a lower-layer LSP is called Hierarchical
	LSP, or H-LSP for short; see [RFC6107].		LSP, or H-LSP for short; see [RFC6107].
	The new link constructed by the H-LSP can then be used by the higher-		The new link constructed by the H-LSP can then be used by the higher-
	layer network to create new LSPs.		layer network to create new LSPs.
	skipping to change at line 869 ¶		skipping to change at line 865 ¶
	1) Static (pre-provisioned) method:		1) Static (pre-provisioned) method:
	In this method, the H-LSP in the lower-layer network is created		In this method, the H-LSP in the lower-layer network is created
	in advance. After that, the higher-layer network can create LSPs		in advance. After that, the higher-layer network can create LSPs
	using the resource of the link constructed by the H-LSP.		using the resource of the link constructed by the H-LSP.
	The Orchestrator(ML) is responsible to decide the creation of		The Orchestrator(ML) is responsible to decide the creation of
	H-LSP in the lower-layer network if it acts as a VNTM. Then it		H-LSP in the lower-layer network if it acts as a VNTM. Then it
	requests the L-Controller to create the H-LSP via, for example,		requests the L-Controller to create the H-LSP via, for example,
	an MPI interface under the ACTN architecture. See Section 3.3.2		an MPI under the ACTN architecture.
	of [YANG-TE].
	If the lower-layer network is a GMPLS domain, the L-Controller(G)		If the lower-layer network is a GMPLS domain, the L-Controller(G)
	can trigger the GMPLS control plane to create the H-LSP. As a		can trigger the GMPLS control plane to create the H-LSP. As a
	typical example, the PCInitiate message can be used for the		typical example, the PCInitiate message can be used for the
	communication between the L-Controller and the source node of the		communication between the L-Controller and the source node of the
	H-LSP. And the source node of the H-LSP can trigger the RSVP-TE		H-LSP. And the source node of the H-LSP can trigger the RSVP-TE
	signaling procedure to create the H-LSP, as described in		signaling procedure to create the H-LSP, as described in
	[RFC6107].		[RFC6107].
	If the lower-layer network is a non-GMPLS domain, other methods		If the lower-layer network is a non-GMPLS domain, other methods
	skipping to change at line 894 ¶		skipping to change at line 889 ¶
	2) Dynamic (triggered) method:		2) Dynamic (triggered) method:
	In this method, the signaling of LSP creation in the higher-layer		In this method, the signaling of LSP creation in the higher-layer
	network will trigger the creation of H-LSP in the lower-layer		network will trigger the creation of H-LSP in the lower-layer
	network dynamically, if it is necessary. Therefore, both the		network dynamically, if it is necessary. Therefore, both the
	higher-layer and lower-layer networks need to support the RSVP-TE		higher-layer and lower-layer networks need to support the RSVP-TE
	protocol and thus need to be GMPLS domains.		protocol and thus need to be GMPLS domains.
	In this case, after the cross-layer path is computed, the		In this case, after the cross-layer path is computed, the
	Orchestrator(ML) requests the H-Controller(G) for the cross-layer		Orchestrator(ML) requests the H-Controller(G) for the cross-layer
	LSP creation. As a typical example, the MPI interface under the		LSP creation. As a typical example, the MPI under the ACTN
	ACTN architecture could be used.		architecture could be used.
	The H-Controller(G) can trigger the GMPLS control plane to create		The H-Controller(G) can trigger the GMPLS control plane to create
	the LSP in the higher-layer network. As a typical example, the		the LSP in the higher-layer network. As a typical example, the
	PCInitiate message can be used for the communication between the		PCInitiate message can be used for the communication between the
	H-Controller(G) and the source node of the higher-layer LSP, as		H-Controller(G) and the source node of the higher-layer LSP, as
	described in Section 4.3 of [RFC8282]. At least two sets of ERO		described in Section 4.3 of [RFC8282]. At least two sets of ERO
	information should be included to indicate the routes of higher-		information should be included to indicate the routes of higher-
	layer LSP and lower-layer H-LSP.		layer LSP and lower-layer H-LSP.
	The source node of the higher-layer LSP follows the procedure		The source node of the higher-layer LSP follows the procedure
	skipping to change at line 929 ¶		skipping to change at line 924 ¶
	by this FA-LSP can be advertised in the routing instance, so that the		by this FA-LSP can be advertised in the routing instance, so that the
	H-Controller can be aware of this new FA. [RFC4206] and the		H-Controller can be aware of this new FA. [RFC4206] and the
	following updates to it (including [RFC6001] and [RFC6107]) describe		following updates to it (including [RFC6001] and [RFC6107]) describe
	the detailed extensions to support advertisement of an FA.		the detailed extensions to support advertisement of an FA.
	If the higher-layer network and the lower-layer network are under		If the higher-layer network and the lower-layer network are under
	separate GMPLS control plane instances or if one of the layer		separate GMPLS control plane instances or if one of the layer
	networks is a non-GMPLS domain, after an H-LSP is created in the		networks is a non-GMPLS domain, after an H-LSP is created in the
	lower-layer network, the link discovery procedure will be triggered		lower-layer network, the link discovery procedure will be triggered
	in the higher-layer network to discover the information of the link		in the higher-layer network to discover the information of the link
	constructed by the H-LSP. The LMP protocol defined in [RFC4204] can		constructed by the H-LSP. The LMP defined in [RFC4204] can be used
	be used if the higher-layer network supports GMPLS. The information		if the higher-layer network supports GMPLS. The information of this
	of this new link will be advertised to the H-Controller.		new link will be advertised to the H-Controller.
	8.4. Recovery		8.4. Recovery
	The GMPLS recovery functions are described in [RFC4426]. Span		The GMPLS recovery functions are described in [RFC4426]. Span
	protection and end-to-end protection and restoration are discussed		protection and end-to-end protection and restoration are discussed
	with different protection schemes and message exchange requirements.		with different protection schemes and message exchange requirements.
	Related RSVP-TE extensions to support end-to-end recovery are		Related RSVP-TE extensions to support end-to-end recovery are
	described in [RFC4872]. The extensions in [RFC4872] include		described in [RFC4872]. The extensions in [RFC4872] include
	protection, restoration, preemption, and rerouting mechanisms for an		protection, restoration, preemption, and rerouting mechanisms for an
	end-to-end LSP. Besides end-to-end recovery, a GMPLS segment		end-to-end LSP. Besides end-to-end recovery, a GMPLS segment
	skipping to change at line 1142 ¶		skipping to change at line 1137 ¶
	procedure need to be GMPLS domains, which support the RSVP-		procedure need to be GMPLS domains, which support the RSVP-
	TE signaling for the creation of a rerouting LSP segment.		TE signaling for the creation of a rerouting LSP segment.
	For inter-domain rerouting, the interaction between GMPLS		For inter-domain rerouting, the interaction between GMPLS
	and a centralized controller system is needed:		and a centralized controller system is needed:
	* A report of the result of intra-domain segment rerouting		* A report of the result of intra-domain segment rerouting
	to its Controller(G) and then to the Orchestrator(MD).		to its Controller(G) and then to the Orchestrator(MD).
	The former could be supported by the PCRpt message in		The former could be supported by the PCRpt message in
	[RFC8231], while the latter could be supported by the		[RFC8231], while the latter could be supported by the
	MPI interface of ACTN.		MPI of ACTN.
	* A report of inter-domain link failure to the two		* A report of inter-domain link failure to the two
	Controllers (e.g., Controller(G) 1 and Controller(G) 2		Controllers (e.g., Controller(G) 1 and Controller(G) 2
	in Figure 7) by which the two ends of the inter-domain		in Figure 7) by which the two ends of the inter-domain
	link are controlled, respectively, and then to the		link are controlled, respectively, and then to the
	Orchestrator(MD). The former could be done as described		Orchestrator(MD). The former could be done as described
	in Section 8.1, while the latter could be supported by		in Section 8.1, while the latter could be supported by
	the MPI interface of ACTN.		the MPI of ACTN.
	* The computation of a rerouting path or path segment		* The computation of a rerouting path or path segment
	crossing multi-domains by the centralized controller		crossing multi-domains by the centralized controller
	system (see [PATH-COMP]);		system (see [PATH-COMP]);
	* The creation of a rerouting LSP segment in each related		* The creation of a rerouting LSP segment in each related
	domain. The Orchestrator(MD) can send the LSP segment		domain. The Orchestrator(MD) can send the LSP segment
	rerouting request to the source Controller(G) (e.g.,		rerouting request to the source Controller(G) (e.g.,
	Controller(G) 1 in Figure 7) via MPI interface, and then		Controller(G) 1 in Figure 7) via MPI interface, and then
	the Controller(G) can trigger the creation of a		the Controller(G) can trigger the creation of a
	skipping to change at line 1485 ¶		skipping to change at line 1480 ¶
	12.2. Informative References		12.2. Informative References
	[G.808.1] ITU-T, "Generic protection switching - Linear trail and		[G.808.1] ITU-T, "Generic protection switching - Linear trail and
	subnetwork protection", ITU-T Recommendation G.808.1, May		subnetwork protection", ITU-T Recommendation G.808.1, May
	2014, <https://www.itu.int/rec/T-REC-G.808.1-201405-I/en>.		2014, <https://www.itu.int/rec/T-REC-G.808.1-201405-I/en>.
	[PATH-COMP]		[PATH-COMP]
	Busi, I., Belotti, S., de Dios, O. G., Sharma, A., and Y.		Busi, I., Belotti, S., de Dios, O. G., Sharma, A., and Y.
	Shi, "A YANG Data Model for requesting path computation",		Shi, "A YANG Data Model for requesting path computation",
	Work in Progress, Internet-Draft, draft-ietf-teas-yang-		Work in Progress, Internet-Draft, draft-ietf-teas-yang-
	path-computation-23, 19 August 2024,		path-computation-24, 13 February 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-teas-		<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
	yang-path-computation-23>.		yang-path-computation-24>.
	[PCEP-LS] Dhody, D., Peng, S., Lee, Y., Ceccarelli, D., Wang, A.,		[PCEP-LS] Dhody, D., Peng, S., Lee, Y., Ceccarelli, D., Wang, A.,
	and G. S. Mishra, "PCEP extensions for Distribution of		and G. S. Mishra, "PCEP extensions for Distribution of
	Link-State and TE Information", Work in Progress,		Link-State and TE Information", Work in Progress,
	Internet-Draft, draft-ietf-pce-pcep-ls-02, 20 October		Internet-Draft, draft-ietf-pce-pcep-ls-02, 20 October
	2024, <https://datatracker.ietf.org/doc/html/draft-ietf-		2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
	pce-pcep-ls-02>.		pce-pcep-ls-02>.
	[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label		[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
	Switching (GMPLS) Signaling Functional Description",		Switching (GMPLS) Signaling Functional Description",
	skipping to change at line 1616 ¶		skipping to change at line 1611 ¶
	[RFC8363] Zhang, X., Zheng, H., Casellas, R., Gonzalez de Dios, O.,		[RFC8363] Zhang, X., Zheng, H., Casellas, R., Gonzalez de Dios, O.,
	and D. Ceccarelli, "GMPLS OSPF-TE Extensions in Support of		and D. Ceccarelli, "GMPLS OSPF-TE Extensions in Support of
	Flexi-Grid Dense Wavelength Division Multiplexing (DWDM)		Flexi-Grid Dense Wavelength Division Multiplexing (DWDM)
	Networks", RFC 8363, DOI 10.17487/RFC8363, May 2018,		Networks", RFC 8363, DOI 10.17487/RFC8363, May 2018,
	<https://www.rfc-editor.org/info/rfc8363>.		<https://www.rfc-editor.org/info/rfc8363>.
	[SPCE-ID] Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP		[SPCE-ID] Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
	Extension for Stateful Inter-Domain Tunnels", Work in		Extension for Stateful Inter-Domain Tunnels", Work in
	Progress, Internet-Draft, draft-ietf-pce-stateful-		Progress, Internet-Draft, draft-ietf-pce-stateful-
	interdomain-06, 6 January 2025,		interdomain-07, 3 March 2025,
	<https://datatracker.ietf.org/doc/html/draft-ietf-pce-		<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
	stateful-interdomain-06>.		stateful-interdomain-07>.
	[YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.		[YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
	Bryskin, "A YANG Data Model for Traffic Engineering		Bryskin, "A YANG Data Model for Traffic Engineering
	Tunnels, Label Switched Paths and Interfaces", Work in		Tunnels, Label Switched Paths and Interfaces", Work in
	Progress, Internet-Draft, draft-ietf-teas-yang-te-37, 9		Progress, Internet-Draft, draft-ietf-teas-yang-te-37, 9
	October 2024, <https://datatracker.ietf.org/doc/html/		October 2024, <https://datatracker.ietf.org/doc/html/
	draft-ietf-teas-yang-te-37>.		draft-ietf-teas-yang-te-37>.
	Acknowledgements		Acknowledgements
End of changes. 18 change blocks.
	50 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.48.