Updates for the -05 version of the draft

Updated Xufeng affiliation Added Chaode as author Updated abstract and introduction to clarify the scope of the draft: fix ietf-ccamp-wg#1 Restructured sections 2, 3 and 4 Clarified that TE bandwidth and label augmentations are based on the guidelines in section 6 of RFC8795: see ietf-ccamp-wg#2 Removed section 5: see ietf-ccamp-wg#2 Aligned with latest YANG model: see PR ietf-ccamp-wg#6 Updated list of authors and contributors
italobusi · Sep 12, 2023 · a782bf8 · a782bf8
1 parent 613a862
commit a782bf8
Show file tree

Hide file tree

Showing 3 changed files with 1,400 additions and 1,022 deletions.
diff --git a/draft-ietf-ccamp-eth-client-te-topo-yang.md b/draft-ietf-ccamp-eth-client-te-topo-yang.md
@@ -14,6 +14,10 @@ stand_alone: yes
 pi: [toc, sortrefs, symrefs, comments]
 
 author:
+  -
+    name: Chaode Yu
+    org: Huawei Technologies
+    email: [email protected]
   -
     name: Haomian Zheng
     org: Huawei Technologies
@@ -41,7 +45,7 @@ author:
     email: [email protected]
   -
     name: Xufeng Liu
-    org: Volta Networks
+    org: Alef Edge
     email: [email protected]
 
 contributor:
@@ -66,94 +70,186 @@ contributor:
     org: Huawei Technologies
     email: [email protected]
 
+normative:
+  ITU_G.8021:
+    title: Generic protection switching - Linear trail and subnetwork protection
+    author:
+      org: ITU-T Recommendation G.808.1
+    date: May 2014
+    seriesinfo: ITU-T G.808.1
+
 --- abstract
 
-   A transport network is a server-layer network to provide connectivity
-   services to its client.  In this draft the topology of Ethernet with
-   TE is described with YANG data model.
+This document describes a YANG data model for Ethernet networks when used either as a client-layer network of an underlay transport network (e.g., an Optical Transport Network (OTN)) or as a transport network technology.
 
 --- middle
 
 # Introduction
 
+To be added
+
    A transport network is a server-layer network designed to provide
    connectivity services for a client-layer network to carry the client
-   traffic transparently across the server-layer network resources.  The
-   topology model in Traffic-Engineered network has been defined in both
-   generic way and technology-specific way.  The generic model, which is
-   the base TE YANG model, can be found at {{!RFC8795}}.  Technology-
-   specific models, such as OTN/WSON topology model, have also been
-   defined in {{!I-D.ietf-ccamp-otn-topo-yang}} and {{?RFC9094}} respectively.
-   Corresponding topology on client-layer is also required, to have a
-   complete topology view from the perspective of network controllers.
+   traffic transparently across the server-layer network resources.
+
+A transport network typically utilizes several different transport technologies such as the Optical Transport Networks (OTN) or packet transport such as provided by the MPLS-Transport Profile (MPLS-TP).
+
+An Ethernet network can be either a client-layer network of an underlay transport network or a transport network technology.
+
+This document describes a YANG data model for Ethernet networks when used either a client-layer network of an underlay transport network (e.g., an Optical Transport Network (OTN)) or a transport network technology.
+
+The YANG model defined in this document augments from the TE topology YANG model defined in {{!RFC8795}}, and imports from the generic Ethernet types defined in {{!I-D.ietf-ccamp-client-signal-yang}}.
+
+The YANG data model in this document conforms to the Network Management Datastore Architecture defined in {{!RFC8342}}.
+
+## Terminology and Notations
+
+The following terms are defined in {{!RFC7950}} and are not redefined
+here:
+
+- client
 
-   This document defines a data model of all client-layer Topology,
-   using YANG language defined in {{!RFC7950}}.  The model is augmenting
-   the generic TE topology model, and can be used by either applications
-   exposing to a network controller or among controllers.  Furthermore,
-   it can be used by an application for topology description in client-
-   layer network.
+- server
 
-#  Terminology and Notations
+- augment
 
-   A simplified graphical representation of the data model is used in
-   this document.  The meaning of the symbols in the YANG data tree
-   presented later in this document is defined in {{?RFC8340}}.  They are
-   provided below for reference.
+- data model
 
--  Brackets "\[" and "]" enclose list keys.
+- data node
 
--  Abbreviations before data node names: "rw" means configuration
-  (read-write) and "ro" state data (read-only).
+The following terms are defined in {{!RFC6241}} and are not redefined
+here:
 
--  Symbols after data node names: "?" means an optional node, "!"
-  means a presence container, and "*" denotes a list and leaf-list.
+- configuration data
 
--  Parentheses enclose choice and case nodes, and case nodes are also
-  marked with a colon (":").
+- state data
 
--  Ellipsis ("...") stands for contents of subtrees that are not
-  shown.
+The terminology for describing YANG data models is found in
+{{!RFC7950}}.
 
-#  YANG Model for Topology of Client Layer
+## Tree Diagram
 
-## YANG Tree for Ethernet Topology
+A simplified graphical representation of the data model is used in
+{{eth-topology-tree}} of this document.  The meaning of the symbols in these
+diagrams is defined in {{?RFC8340}}.
+
+## Prefix in Data Node Names
+
+In this document, the names of data nodes and other data model
+objects are prefixed using the standard prefix associated with the
+corresponding YANG imported modules, as shown in {{tab-prefixes}}.
+
+  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 shown in {{tab-prefixes}}.
+
+| Prefix     | YANG module           | Reference
+| yang       | ietf-yang-types       | {{!RFC6991}}
+| etht-types | ietf-eth-tran-types   | \[RFCYYYY]
+| nw         | ietf-network          | {{!RFC8345}}
+| nt         | ietf-network-topology | {{!RFC8345}}
+| tet        | ietf-te-topology      | {{!RFC8795}}
+| eth-tet    | ietf-eth-te-topology  | RFCXXXX
+{: #tab-prefixes title="Prefixes and corresponding YANG modules"}
+
+RFC Editor Note: Please replace YYYY and XXXX with the number
+assigned to the RFC once this draft becomes an RFC.
+
+{: #eth-topo-overview}
+
+# Ethernet Topology Model Overview
+
+This document aims to describe the data model for Ethernet topology.
+
+As a classic Traffic-engineering (TE) technology, Ethernet can provide packet
+switching in transport network {{ITU_G.8021}}.
+
+Therefore, the YANG
+module presented in this document augments from a more generic
+Traffic Engineered (TE) network topology data model, i.e., the ietf-
+te-topology, as specified in {{!RFC8795}}.  In section 6 of {{!RFC8795}},
+the guideline for augmenting TE topology model was provided, and in
+this draft, we augment the TE topology model to describe the topology
+in Ethernet network.  Common types, identities and groupings defined in
+{{!I-D.ietf-ccamp-client-signal-yang}} is reused in this document.  {{!RFC8345}}
+describes a network topology model and provides the fundamental model
+for {{!RFC8795}}.  However, this work is not directly augmenting
+{{!RFC8345}}.  {{fig-eth-topo}} shows the augmentation relationship.
 
 ~~~~ ascii-art
-{::include ietf-eth-te-topology.tree}
+                      +-------------------------+
+         TE generic   |    ietf-te-topology     |
+                      +------------+------------+
+                                   ^
+                                   |
+                                   | Augments
+                                   |
+                      +------------+------------+
+         Ethernet     |  ietf-eth-te-topology   |
+                      +-------------------------+
 ~~~~
-{: #fig-eth-topology-tree title="Ethernet topology YANG tree" artwork-name="ietf-eth-te-topology.tree"}
+{: #fig-eth-topo title="Relationship between Ethernet and TE topology models"}
 
-# YANG Code for Topology Client Layer
+   The entities and TE attributes, such as node, termination points and
+   links, are still applicable for describing an Ethernet topology and the
+   model presented in this document only specifies technology-specific
+   attributes/information.
 
-## The ETH Topology YANG Code
+## Attributes Augmentation
+
+  Given the guidance for augmentation in {{!RFC8795}}, the following
+  technology-specific augmentations need to be provided:
+
+  - A network-type to indicate that the TE topology is an Ethernet
+    Topology, as follow:
 
-~~~~ yang
-{::include ietf-eth-te-topology.yang}
 ~~~~
-{: #fig-te-yang title="Ethernet topology YANG module"
-sourcecode-markers="true" sourcecode-name="[email protected]"}
+       augment /nw:networks/nw:network/nw:network-types/tet:te-topology:
+         +--rw eth-tran-topology!
+~~~~
+
+  - TE Bandwidth Augmentations as described in {{eth-bandwidth}}.
+
+  - TE Label Augmentations as described in {{eth-label}}.
+
+{: #eth-bandwidth}
+
+## TE Bandwidth Augmentations
+
+Following the guidelines in {{!RFC8795}}, the model augments
+all the occurrences of the te-bandwidth container with the Ethernet technology
+specific attributes using the eth-bandwidth grouping defined in {{!I-D.ietf-ccamp-client-signal-yang}}.
+
+{: #eth-label}
 
-# Considerations and Open Issue
+## TE Label Augmentations
 
-   Editor Notes: This section is used to note temporary discussion/
-   conclusion that to be fixed in the future version, and will be
-   removed before publication.
+The model augments all the occurrences of the label-restriction list
+with Ethernet technology specific attributes using the eth-label-restriction grouping defined in {{!I-D.ietf-ccamp-client-signal-yang}}.
 
-   Update in draft-zheng-ccamp-client-topo-yang-10: there is no open
-   issue in this version.
+Moreover, following the guidelines in {{!RFC8795}}, the model augments
+all the occurrences of the te-label container with the Ethernet technology
+specific attributes using the eth-label and
+eth-label-step groupings defined in {{!I-D.ietf-ccamp-client-signal-yang}}.
 
-   201902: we have noticed that Ethernet is the only client signal (on
-   the perspective of OTN) which need a topology.  So it is possible
-   that the title of this document will be changed to "A YANG Data Model
-   for Ethernet Topology".  The proposal of this work is that the
-   document will follow up the progress of draft-zheng-ccamp-client-
-   signal-yang, with draft-zheng-ccamp-client-tunnel-yang together.
-   (solved in -06)
+{: #eth-topology-tree}
 
-   201902: will have to align with TE topology model, currently is a
-   totally different format with necessary parameters, a big change is
-   expected.  (solved in -06.)
+# YANG Tree for Ethernet Topology
+
+~~~~ ascii-art
+{::include ietf-eth-te-topology.tree}
+~~~~
+{: #fig-eth-topology-tree title="Ethernet topology YANG tree" artwork-name="ietf-eth-te-topology.tree"}
+
+{: #eth-topology-yang}
+
+# Ethernet Topology YANG Code
+
+~~~~ yang
+{::include ietf-eth-te-topology.yang}
+~~~~
+{: #fig-te-yang title="Ethernet topology YANG module"
+sourcecode-markers="true" sourcecode-name="[email protected]"}
 
 # IANA Considerations
 
@@ -172,7 +268,7 @@ sourcecode-markers="true" sourcecode-name="[email protected]"
 ~~~~
       name:      ietf-eth-te-topology
       namespace: urn:ietf:params:xml:ns:yang:ietf-eth-te-topology
-      prefix:    ethtetopo
+      prefix:    eth-tet
       reference: RFC XXXX
 ~~~~