]> Huawei Technologies

yuchaode@huawei.com

CAICT

zhaoxing@caict.ac.cn

China Unicom

tanyx11@chinaunicom.cn

Ciena

ndavis@ciena.com

Old Dog Consulting

daniel@olddog.co.uk

Routing Common Control and Measurement Plane next generation unicorn sparkling distributed ledger This document defines two extension YANG data models augmenting to TE topology and TE tunnel modules, based on the RDNM (Rich-Detail Network Management) requirements in transport networks. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction defines a YANG data module for technology generic, and it is augmented by some other technology specific data modules, e.g. OTN topology data model in . defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. Similarly, it could be also augmented by some other technology specific data modules to implement a specific layer of TE tunnel. According to , it is good to used the current TE data model system to manage an abstracted network topology. In , it is called Abstracted Control (AC) approach. In , it also raised another management approach, which is called Rich-Detail Network Management (RDNM). RDNM is designed to continue to deliver FCAPS capabilities within the context of ACTN. describes transport network from the viewpoint of the information transfer capability, provides a generic functional architecture which is also implementation independent. This recommendation is the implementation basis of most of the vendors' or operators' systems. To provide traditional FCAPS functionalities, we need to align with the modelling of traditional approach, which is suggested to be . Therefore, some more TMF attributes would be introduced. To avoid introducing non-backward-compatible (NBC) changes, we would like to provide some extension YANG data models, based on the current model architecture. Some extensions, which are generic for all network layers, are defined in the RDNM topology and RDNM tunnel models. Layer-specific RDNM extensions can be found in other YANG data modules.

Terminology and Notations Note: to be added on demand.

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Tree Diagram A simplified graphical representation of the data model is used in this document. The meaning of the symbols in this diagram is defined in .

Prefix in Data Node Names In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as showned in the following table. Prefixes and corresponding YANG modules

Prefix	Yang Module	Reference
nw	ietf-network
nt	ietf-network-topology
tet	ietf-te-topology
yang	ietf-yang-types
inet	ietf-inet-types
te	ietf-te	RFCYYYY
te-types	ietf-te-types
rdnmt	ietf-rdnm-topology	RFC XXXX
rdnm-tnl	ietf-rdnm-tunnel	RFC XXXX
rdnm-types	ietf-rdnm-types	RFC XXXX

RFC Editor Note: Please replace XXXX with the RFC number assigned to this document. Please replace YYYY with the RFC number assigned to the TE tunnel draft. Please remove this note.

Mapping of ACTN modelling objects with TMF objects describes the network as a transport network from the viewpoint of the information transfer capability. More specifically, the functional and structural architecture of transport networks are described independently of networking technology. It also defines various types of reference points, such as the Access Point (AP), Connection Point (CP), and Trail Connection Point (TCP), and the processing between reference points, which is called adaptation. A transport entity that transmits information such as trails and connections between reference points. For the details, we can refer to descriptions in chapter 3 of and Figure 1 to Figure 3. One disadvantage of is it is too complicated. So TMF simplifies the modelling system of . The adaptation is changed to be the capabilities of reference points. The reference points is so that changed to some other terminologies, e.g. PTP and FTP etc. This simplification still can be mapped to . So that a lot of vendors and operators choose TMF modelling in their system. Based on the TMF modelling, CORBA/XML interface was defined to provide FCAPS interfaces. These interfaces were widely used in the operators' network. The transport ACTN is also initially designed to simplify network configurations. To have a unified modelling with IP technology, many new modelling terms of TE were introduced and build up a new modelling system. Theoretically, these new modelling objects should be a part of, or can be mapped to the reference points or adaptation defined by . However, in the existing IETF documents, there is not sufficient details can be found. If the transport ACTN interface wants to support the complete FCAPS capability, there could be two approaches. The first approach is the ACTN interface build up a new alarm/performance monitoring mechanism, based on its abstract control modelling. Just like what have been done in and . The second approach is reusing the traditional alarm/performance monitoring mechanism, so that the ACTN modelling needs to be mapped to the traditional modelling. Currently, there is not sufficient theoretical support for the first approach, and there is not such a attempt is tried in IETF. For the second approach, one of the advantage is it can inherit the functions integrated before. So that there would not be two much efforts need to pay for the new integration. In this document, we would like to follow the second approach. Table 2 provides a mapping between the ACTN objects and TMF objects. Mapping of ACTN objects with TMF objects

ACTN Object	TMF Object
Network	NA
Node	Management Element
Link	Topology Link
TP	PTP
TTP	CTP/FTP
Tunnel	SNC/XC
NE	Management Element
component	equipment holder/equipment
Client signal	NA
Ethernet Client signal	NA
NA	Protection Group
NA	Equipment Protection Group

The ONF TAPI also defines a new set of terms, which are different from the definitions of the . But it provides the mapping of TAPI objects to ITU-T objects in Figure 3-2 of . In the appendix of this document, we also compare the ACTN object modelling and TAPI object modelling, which can be used as a reference for a possible integration of these two interfaces in a same MDSC.

Model relationship The current ACTN topology models for transport technology follows the relationship as bellow:

Relationship of ACTN topology

TE topology model was aimed to define common attributes for all the technologies. OTN topology and WDM topology, etc., they are all augmenting TE topology model to provide layer-specific extensions. Although most of the objects in ACTN and TMF can be mapped to each other, the parameters of the objects cannot be completely matched. In other words, the current ACTN object needs to be extended with some properties to support the full functionality of a traditional object. But in the traditional transport standards there is not such a saying of TE-related modelling. If we want to extend the current IETF data models to have full modelling of traditional approach, which is called RDNM extension by us, we suggest to define the common attributes for all the technologies in a RDNM extension model. For layer-specific RDNM extensions could reference existing way and define in a separated layer-specific RDNM extension document. So in the RDNM approach, the ACTN topology architecture will be extended to be:

Relationship of RDNM ACTN topology

It is also same for the TE tunnel architecture. The whole architecture after RDNM tunnel extensions will be:

Relationship of RDNM ACTN tunnel

RDNM Extension for Topology For the some objects, although it is defined in IETF, but the way of abstraction is not so implementation friendly, especially for TTP.

RDNM extension for TE topology (To be added)

The modelling and usage of TTP According to the description of , TTP is an element of a TE topology representing one or several potential transport service termination points, (i.e., service client adaptation points, such as a WDM/OCh transponder). In the ITU-T standard, such an adaptation point can be the termination point of an end-to-end connection, or the source or sink point of the intermediate cross-connection. A physical port can generate a lot of logical objects. For example, a 100G line port can function as 80 lower-order ODU0 adaptation points, 40 ODU1 adaptation points, or even the adaptation point of an OCh tunnel. Considering the data volume in large-scale network, it is not wise to expose all these points. Because that most of them are potentially existing, they are probably not used at the end. In the document of TE topology, it is not indicated whether the TTPs should be provided at day 0 or not. And it is also hard to find the correlation with the physical port. In this document, we suggest not to provide the potential TTPs but the existing TTPs who have been used by connections at any time. If the client want to retrieve these potential TTPs, a single RPC can help to do so. This RPC should return the existing and potential TTPs at the same time. The key of TTP is tunnel-tp-id which is a binary type. For the potential TTPs, it is no need to allocate a tunnel-tp-id for them. But the server can provide a name for these TTPs, this name should follow the pattern defined by TMF. When the client want to reference a potential TTP, it can reference the name of this TTP, and then the server will allocated a tunnel-tp-id for it after the connection created. And this TTP is no more than a potential TTP but an existing TTP, it should appear in the TTP list of topology.

RDNM Extensions for TE Tunnel

Modelling of Point to Multi-Points and Multi-Points to Multi-Points TE Tunnel The current TE tunnel model only supports point-to-point scenario. Therefore, only one source and sink structure is defined on the tunnel node. In the transport technology, there are point-to-multipoint scenarios and multipoint-to-multipoint connection scenarios. For example, multicast service. We suggest to extend the current TE tunnel model to support the multi-point scenario. Considering the TTPs was not generate before the tunnel created, the client can reference by the TTP by name.

Restoration

Lock of restoration In some maintenance scenarios, people may need to freeze the restoration capability of a TE tunnel. For example, after obtaining the customers' consent, the carrier can choose not to restore services during the TE tunnel cutover. This prevents unstable services flapping caused by repeated fiber cuts during the cutover. The unstable services flapping would also affects existing services. Section 3.2.8.11 in mentions the freezing operation of protection and rerouting switching. Therefore, compared with traditional path management, the current TE tunnel model also needs to add freezing capability to the protection and restoration structure.

Lock of restoration reversion For some cutover scenario, services may be rerouted to a new trail before the cutover operation. During the cutover, the fiber may be frequently plug in and plug out due to commissioning. To make sure that the new route will not go back to the original route and if the tunnel is restoration reversion, there would be a requirement the freeze the restoration reversion function. This is also a functionality defined by ITU-T and it's missing in the current TE tunnel.

Scheduling of reversion time Maintenance job usually is taken place in a fixed time window, for example at night when people are not using the network frequently as daytime. So that there will not be impact as large as operating at daytime if the maintenance job is failed. Operator can choose to revert the services to the original path at night, so that the restoration reversion would not have big impact on the network.

Priority of restoration In some operator, they configure different restoration priority to different tunnels or services. When multiple services need to be restored at a same time, high-priority services preferentially occupy resources, and low-priority services can be rerouted only after the rerouting of high-priority services is complete.

YANG for restoration extension

TTP hop The current TE tunnel data model can support to specify explicit node/LTP included/excluded. However, for finer grain object, such as TTP, it is not supported to specify. For example, in the scenario where lower-order and higher-order ODUk tunnel are both existing, sometimes multiple lower-order ODUk tunnels need to multiplex a higher-order ODUk tunnel. The client can specify the higher-order ODUk tunnel's TTP to be included in the lower-order ODUk tunnel's creation request. If the lower-order ODUk doesn't need to multiplex a higher-order ODUk tunnel, the client can specify the higher-order ODUk tunnel's TTP to be excluded in the lower-order ODUk tunnel's creation request. There can be two ways to specify this TTP. This higher-order ODUk TTP can be existing in the topology if it has been occupied by a higher-order ODUk tunnel. Then in the TTP hop, the client can specify the ttp-id of this TTP. This TTP can also be nonexisting in the topology or idle for tunnel creation. And then then client can specify the name of TTP in the creation request.

Tree Diagram

RDNM Topology below shows the tree diagram of the YANG data model defined in module "ietf-rdnm-topology".

Tree of RDNM Topology

RDNM Tunnel below shows the tree diagram of the YANG data model defined in module "ietf-rdnm-tunnel".

Tree of RDNM Tunnel /nw:networks/network/node/node-id | +--rw (endpoint-tp)? | | +--:(ltp) | | | +--rw tp-id? leafref | | +--:(ttp) | | +--rw (id-or-name)? | | +--:(id) | | | +--rw ttp-id? leafref | | +--:(name) | | +--rw ttp-name? leafref | +--rw protection-role? enumeration +--rw destination-endpoints +--rw destination-endpoint* [] +--rw node-id? | -> /nw:networks/network/node/node-id +--rw (endpoint-tp)? | +--:(ltp) | | +--rw tp-id? leafref | +--:(ttp) | +--rw (id-or-name)? | +--:(id) | | +--rw ttp-id? leafref | +--:(name) | +--rw ttp-name? leafref +--rw protection-role? enumeration augment /te:te/te:tunnels/te:tunnel/te:restoration: +--rw restoration-lock? boolean +--rw restoration-reversion-lock? boolean +--rw scheduled-reversion-time? yang:date-and-time +--rw restoration-priority? enumeration +--rw restoration-layer? enumeration ]]>

YANG Data Model

RDNM Topology

RDNM Topology YANG module WG List: Editor: Chaode Yu Xing Zhao Yanxia Tan Nigel Davis Daniel King "; description "This module provide some extensions to TE topology model, based on transport Rich-Detail Network Management requirement"; revision 2025-02-22 { description "Revision 1.0"; reference "draft-yu-ccamp-rdnm-yang-00"; } augment "/nw:networks/nw:network/nw:node/tet:te" { description "Generic Rich-Detail Network Management extensions for te node"; uses node-rdnm-ext-grouping; } augment "/nw:networks/nw:network/nw:node/nt:termination-point/" + "tet:te" { description "Generic Rich-Detail Network Management extensions for termination point"; uses tp-rdnm-ext-grouping; } augment "/nw:networks/nw:network/nw:node/tet:te" + "/tet:tunnel-termination-point" { description "Generic Rich-Detail Network Management extensions for te node"; uses ttp-rdnm-ext-grouping; } augment "/nw:networks/nw:network/nt:link/tet:te" { description "Generic Rich-Detail Network Management extensions for link"; uses link-rdnm-ext-grouping; } grouping node-rdnm-ext-grouping { description "Generic extension of node."; choice layer-specific-extension { description "The layer rate information."; case generic { } } } grouping tp-rdnm-ext-grouping { description "Generic extension of TP."; choice layer-specific-extension { description "The layer rate information."; case generic { } } } grouping ttp-rdnm-ext-grouping { description "Generic extension of TTP."; choice layer-specific-extension { description "The layer rate information."; case generic { } } } grouping link-rdnm-ext-grouping { description "Generic extension of link."; choice layer-specific-extension { description "The layer rate information."; case generic { } } } rpc query-ttp-by-tps { description "Query all the TTPs on the LTPs"; input { list tp-list { description "the LTPs to retrieve."; key tp-id; leaf tp-id { type leafref { path "/nw:networks/nw:network/nw:node" + "/nt:termination-point/nt:tp-id"; } description "the identifier of TP to querey"; } } } output { leaf result { type enumeration { enum failed; enum partially-successful; enum successful; } description "the result of retrieval"; } list result-list { description "The result list."; key tp-id; leaf tp-id { type leafref { path "/nw:networks/nw:network/nw:node" + "/nt:termination-point/nt:tp-id"; } description "the identifier of TP queried and returns TTPs"; } list ttp-list { description "the TTPs list for this LTP."; leaf tunnel-tp-id { type leafref { path "/nw:networks/nw:network/nw:node/tet:te" + "/tet:tunnel-termination-point/tet:tunnel-tp-id"; } description "Identifier of TTP which is existing in the topology. It is not required to return if it is not existing in the topology."; } leaf ttp-name { type string; description "Name of TTP. If the ttp is idle, the default name should be provided by the server and follow the naming pattern of TMF814."; } leaf using-status { type enumeration { enum idle; enum bidirectional-used; } } } } } } } ]]>

RDNM Tunnel

RDNM Tunnel YANG module WG List: Editor: Chaode Yu Xing Zhao Yanxia Tan Nigel Davis Daniel King "; description "This module provide some extensions to TE topology model, based on transport Rich-Detail Network Management requirement"; revision 2025-02-22 { description "Revision 1.0"; reference "draft-yu-ccamp-rdnm-yang-00"; } augment "/te:te/te:tunnels/te:tunnel" { description "Extensions for TE tunnel structure, includes alias, time management and another option of specifying source and destination."; leaf alias { type string; description "alias of TE tunnel"; } uses time-state-grouping; container source-endpoints { description "Source endpoints."; list source-endpoint { uses endpoint-grouping; description "List of source endpoints."; } } container destination-endpoints { description "Destination endpoints."; list destination-endpoint { uses endpoint-grouping; description "List of destination endpoints."; } } } augment "/te:te/te:tunnels/te:tunnel/te:restoration" { description "Extensions of TE tunnel restoration."; leaf restoration-lock { type boolean; description "a lock to control whether the restoration can take effect or not, it is useful in the maintenance scenrios, such as in cutover"; } leaf restoration-reversion-lock { type boolean; description "a lock to control whether the reversion of restoration can take effect or not."; } leaf scheduled-reversion-time { type yang:date-and-time; description "a time when the reversion of restoration can take effect."; } leaf restoration-priority { type enumeration { enum high; enum medium; enum low; } description "when there are multiple services need to be restored, the higher estoration priority services can occupied the idle resource in priority, it is used to control the restoration sequence."; } leaf restoration-layer { type enumeration { enum odu; enum wdm; } description "the layer of topolgy prefered to be operated when restoration is needed."; } } augment "/te:te/te:tunnels/te:tunnel/te:primary-paths" + "/te:primary-path/te:explicit-route-objects" + "/te:route-object-include-exclude/te:type" { description "a TTP hop"; case ttp-hop { uses rdnm-types:explicit-ttp-hop; } } augment "/te:te/te:tunnels/te:tunnel/te:secondary-paths" + "/te:secondary-path/te:explicit-route-objects" + "/te:route-object-include-exclude/te:type" { description "a TTP hop"; case ttp-hop { uses rdnm-types:explicit-ttp-hop; } } augment "/te:te/te:tunnels/te:tunnel/te:primary-paths" + "/te:primary-path/te:primary-reverse-path" + "/te:explicit-route-objects" + "/te:route-object-include-exclude/te:type" { description "a TTP hop"; case ttp-hop { uses rdnm-types:explicit-ttp-hop; } } augment "/te:te/te:tunnels/te:tunnel/te:secondary-reverse-paths" + "/te:secondary-reverse-path" + "/te:explicit-route-objects" + "/te:route-object-include-exclude/te:type" { description "a TTP hop"; case ttp-hop { uses rdnm-types:explicit-ttp-hop; } } grouping time-state-grouping { description "time management of TE tunnel."; leaf create-time { type yang:date-and-time; config false; description "the time when the tunnel was created"; } leaf active-time { type yang:date-and-time; config false; description "the lastest time when the tunnel was activated"; } } grouping endpoint-grouping { description "Source/destination endpoint information of TE tunnel."; leaf node-id { type leafref { path "/nw:networks/nw:network/nw:node/nw:node-id"; } description "Identifier of node for this endpoint."; } choice endpoint-tp { description "The client can choose to specify LTP or TTP to create TE tunnel."; case ltp { leaf tp-id { type leafref { path "/nw:networks/nw:network/nw:node/nt:termination-point" + "/nt:tp-id"; } description "identifier of LTP for this endpoint."; } } case ttp { choice id-or-name { description "The client can choose to specify the identifier or the name of TTP to create TE tunnel."; case id { leaf ttp-id { type leafref { path "/nw:networks/nw:network/nw:node/tet:te" + "/tet:tunnel-termination-point/tet:tunnel-tp-id"; } description "the identifier of TTP for this endpoint."; } } case name { leaf ttp-name { type leafref { path "/nw:networks/nw:network/nw:node/tet:te" + "/tet:tunnel-termination-point/tet:name"; } description "the name of TTP for this endpoint."; } } } } } leaf protection-role { type enumeration { enum work; enum protect; } description "role of this endpoint in multipoints scenario"; } } } ]]>

RDNM Types

RDNM Types YANG module WG List: Editor: Chaode Yu Xing Zhao Yanxia Tan Nigel Davis Daniel King "; description "This module defines Rich-Detail Network Management (RDNM) YANG types."; revision 2025-02-22 { description "Revision 1.0"; reference "draft-yu-ccamp-rdnm-yang-00"; } grouping explicit-ttp-hop { container ttp-hop { description "TTP Hop"; leaf node-id { type nw:node-id; description "identifier of node for this TTP hop."; } choice id-or-name { description "The server can choose to display the identifier or the name of TTP."; case id { leaf ttp-id { type binary; } description "the identifier of TTP for this TTP hop."; } case name { leaf ttp-name { type string; } description "the name of TTP for this TTP hop."; } } } } } ]]>

Manageability Considerations <Add any manageability considerations>

Security Considerations <Add any security considerations>

IANA Considerations <Add any IANA considerations>

References Normative References This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. This document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities. Informative References TM Forum (TMF) Open Networking Foundation (ONF) International Telecommunication Union International Telecommunication Union International Telecommunication Union International Telecommunication Union Huawei Technologies Huawei Technologies Alef Edge Nokia Telefonica This document defines a YANG data model for representing, retrieving, and manipulating Optical Transport Network (OTN) topologies. It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. Cisco Systems Inc Cisco Systems Inc Alef Edge Juniper Networks Individual This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data that is independent of any technology or dataplane encapsulation and is divided into two YANG modules that cover device-specific, and device independent data. This model covers data for configuration, operational state, remote procedural calls, and event notifications. Huawei Old Dog Consulting Huawei CAICT This document provides an analysis of the applicability of the YANG models defined by the IETF (in particular in the Traffic Engineering Architecture and Signaling (TEAS) and Common Control and Measurement Plane (CCAMP) working groups) to support ODU transit services, transparent client services, and Ethernet Private Line/Ethernet Virtual Private Line (EPL/EVPL) services over Optical Transport Network (OTN) in single and multi-domain network scenarios. This document also describes how existing YANG models can be used through several worked examples and JSON fragments. China Unicom CAICT Huawei Technologies Old Dog Consulting Old Dog Consulting Many network technologies are operated as Traffic Engineered (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds fine-grained network management to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF- based YANG and RESTful API capabilities.

Appendix

Mapping Between ACTN & TMF & TAPI Modelling Mapping of ACTN & TMF & TAPI Modelling

ACTN Object	TMF Object	TAPI Object
Network	NA	topology
Node	Management Element	node
Link	Topology Link	link
TP	PTP	SIP/NEP
TTP	CTP/FTP	CEP
Tunnel	SNC/XC	connection
NE	Management Element	device
component	equipment holder/equipment	equipment/holder
Client signal	NA	connectivity service
Ethernet Client signal	NA	connectivity service
NA	Protection Group	NA
NA	Equipment Protection Group	NA

Acknowledgments The authors would like to thank Adrian Farrrel and Scott Mansfield for their inputs and suggestions. This document was prepared using kramdown.

Contributors Orange Innovation

julien.meuric@orange.com

Nokia

sergio.belotti@nokia.com

Huawei Technologies

liuzhoulong@huawei.com

Huawei Technologies

Italo.Busi@huawei.com

Futurewei Technologies

aihuaguo.ietf@gmail.com