Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
2) <!--[rfced] Is the final sentence of the Abstract pointing to another
document (RFC 8453)? Or is this a general mention of the concept?
Original:
This includes VN operations as per the Abstraction and Control of TE
Networks (ACTN) framework.
Perhaps:
This includes VN operations as per the Abstraction and Control of TE
Networks (ACTN) framework described in RFC 8453.
-->
3) <!-- [rfced] FYI, the authors' comments in the XML file have been
marked with [auth]. Please let us know if any updates are needed
based on those comments; if not, they will be removed.
-->
4) <!--[rfced] Might the following update to the Terminology section be
helpful to the reader? It reduces redundancy, groups the
abbreviations in one list, and makes the treatment of the terms
more similar. Otherwise, we have "Connectivity Matrix" without
any descriptor in the original...
Original:
1.1. Terminology
This document borrows the following terms from [RFC8453]:
VN: Virtual Network
AP: Access Point
VNAP: VN Access Point
ACTN: Abstraction and Control of TE Networks
CNC: Customer Network Controller
MDSC: Multi-Domain Service Coordinator
CMI: CNC-MDSC Interface
This document borrows the following terms from [RFC8795]:
LTP: Link Termination Point
Connectivity Matrix
This document borrows the terminology in Section 1.1 of [RFC7926].
This document uses the term 'Service Model' as described in
[RFC8309].
Perhaps:
1.1. Terminology
This document borrows the following abbreviations from [RFC8453]
and/or [RFC8795]:
VN: Virtual Network
AP: Access Point
VNAP: VN Access Point
ACTN: Abstraction and Control of TE Networks
CNC: Customer Network Controller
MDSC: Multi-Domain Service Coordinator
CMI: CNC-MDSC Interface
LTP: Link Termination Point
This document borrows the terminology in Section 1.1 of
[RFC7926], the term "Service Model" from [RFC8309], and the term
"Connectivity Matrix" from [RFC8795].
-->
5) <!--[rfced] The use of the blockquote element with this text may be
confusing to readers. If this is simply a paraphrase instead of
a direct quote from RFC 8543 (which it appears to be), we suggest
removing the blockquote element.
Original:
As defined in [RFC8453], a Virtual Network is a customer view of the
TE network. To recapitulate VN types from [RFC8453], Type 1 VN is
defined as follows:
| The VN can be seen as a set of edge-to-edge abstract links (a Type
| 1 VN). Each abstract link is referred to as a VN member and is
| formed as an end-to-end tunnel across the underlying networks.
| Such tunnels may be constructed by recursive slicing or
| abstraction of paths in the underlying networks and can encompass
| edge points of the customer's network, access links, intra-domain
| paths, and inter-domain links.
Perhaps:
As defined in [RFC8453], a Virtual Network is a customer view of the
TE network. To recapitulate VN types from [RFC8453], Type 1 VN is
defined as follows:
The VN can be seen as a set of edge-to-edge abstract links (a Type
1 VN). Each abstract link is referred to as a VN member and is
formed as an end-to-end tunnel across the underlying networks.
Such tunnels may be constructed by recursive slicing or
abstraction of paths in the underlying networks and can encompass
edge points of the customer's network, access links, intra-domain
paths, and inter-domain links.
-->
6) <!--[rfced] We are unsure of how to parse the list below beginning
with "which". Please rephrase.
Original:
Type 1 VN can be seen as a higher abstraction of a Type 2 VN (which
along with a single node abstract topology, an underlay topology and
the intended path is specified).
-->
7) <!--[rfced] In the "Type 1 VN Illustration" figure (Figure 5), should
"multi-s-d" instead read as "multi-s/d" to more closely mirror
the text to the right of the figure? -->
8) <!--[rfced] This sentence may trip up some readers; particularly, how
does "only" apply to the sentence (especially considering the use
of "as well")? Please consider a rephrase.
Original:
The VN operation allows the creation of a VN with only a PE identifier
as well.
-->
9) <!--[rfced] Please review the use of lowercase "vn" in this sentence.
Is this the abbreviation for Virtual Network? Or is this the
Prefix defined in Section 1.3?
Original:
To achieve this, the 'ap' container has a leaf for 'pe' node that
allows AP to be created with PE information. The vn-member (and vn)
could use APs that only have PE information initially.
-->
10) <!--[rfced] We had a few questions about the bulleted list following
Figure 10:
a) May we replace "This" with its antecedent for clarity? Note that
this text occurs twice (in the first two bullets of the list):
Original:
This also overrides any constraints in the referenced abstract node in
the TE topology.
Pephaps:
The VN-member level also overrides any constraints in the referenced
abstract node in the TE topology.
b) In the following, is the meaning "at the VN level and/or VN-member
level"? Note that this text also occurs twice in the first two bullet
points of this list.
Original:
This is used optionally in the RPC input at the VN and/or VN-member
level.
Perhaps:
This is used optionally in the RPC input at the VN level and/or the
VN-member level.
-->
11) <!--[rfced] We would suggest making the following updates for clarity
as two YANG models are being discussed in close proximity.
Original:
Note that the YANG model is tightly coupled with the TE Topology
model [RFC8795]. Any underlay technology not supported by [RFC8795]
is also not supported by this model. The model does include an empty
container called "underlay" that can be augmented. For example the
Segment Routing (SR) Policy [RFC9256] information can be augmented
for the SR underlay by a future model.
Perhaps:
Note that the VN YANG model is tightly coupled with the TE Topology
model [RFC8795]. Any underlay technology not supported by the TE
Topology model in [RFC8795] is also not supported by the VN YANG
model. However, the VN YANG model does include an empty container
called "underlay" that can be augmented. For example, the Segment
Routing (SR) Policy [RFC9256] information can be augmented for the
SR underlay by a future model.
-->
12) <!--[rfced] RFC 4124 does not use the term "cos" or "class of
service". Is this citation in the right place in the sentence?
Original:
Apart from the te-types:generic-path-constraints and te-
types:generic-path-optimization, an additional leaf cos for the class
of service [RFC4124] is added to represent the Class-Type of traffic
to be used as one of the path constraints.
Perhaps:
Apart from the te-types:generic-path-constraints and te-
types:generic-path-optimization, an additional leaf cos for the class
of service is added to represent the Class-Type of traffic [RFC4124]
to be used as one of the path constraints.
-->
13) <!--[rfced] We had the following questions about the YANG module in
Section 6:
a) Is "This module contains a YANG module" correct?
Original:
This module contains a YANG module for the Virtual Network (VN).
Perhaps:
This YANG module is for the Virtual Network (VN).
b) The beginning of the module lists abbreviations, but they are
expanded on first use in the module anyway. May we cut these first
expansions?
c) Same for src and dest: they are introduced, but not used in
descriptions consistently. Please let us know if updates should be
made.
d) FYI - We will update the expansion of CMI to match the version used
in the Terminology section (i.e., CNC-MDSC Interface) as follows (if
you decide to keep the abbreviations list we mentioned above - if not,
we will simply update in the running text):
Original:
It describes a VN operation module that can take place
in the context of the Customer Network Controller (CNC)-
Multi-Domain Service Coordinator (MDSC) interface (CMI) of
the Abstraction and Control of Traffic Engineered (TE)
Networks (ACTN) architecture where the CNC is the actor of
a VN Instantiation/modification/deletion as per RFC 8453.
This module uses following abbreviations:
- VN: Virtual Network
- AP: Access Point
- VNAP: Virtual Network Access Point
- LTP: Link Termination Point
- PE: Provider Edge
- COS: Class of Service
Perhaps:
It describes a VN operation module that can take place
in the context of the Customer Network Controller (CNC)
Multi-Domain Service Coordinator (MDSC) interface of
the Abstraction and Control of Traffic Engineered (TE)
Networks (ACTN) architecture where the CNC is the actor of
a VN instantiation/modification/deletion as per RFC 8453.
This module uses following abbreviations:
- VN: Virtual Network
- AP: Access Point
- VNAP: Virtual Network Access Point
- LTP: Link Termination Point
- PE: Provider Edge
- COS: Class of Service
- CMI: CNC-MDSC Interface
e) Because this description clause mentions RFC 8795, should a
reference to it be added as well?
container underlay {
description
"An empty container that can be augmented with underlay
technology information not supported by RFC 8795 (for
example - Segment Routing (SR).";
}
reference
"RFC 8454: Information Model for Abstraction and Control of TE
Networks (ACTN)";
f) Note that the YANG module has been updated per the formatting
option of pyang. Please let us know any concerns.
-->
14) <!--[rfced] We note that IANA lists both RFCs 6020 and 8407 as
references for the "YANG Module Names" registry. Should this
text be updated to add RFC 8407 (and an entry added to the
Informative References section)?
Original:
IANA is requested to make the following allocation for the YANG
module in the "YANG Module Names" registry [RFC6020]:
Perhaps:
IANA has made the following allocation for the YANG module in the
"YANG Module Names" registry ([RFC6020] and [RFC8407]):
-->
15) <!--[rfced] Replacing "this" with its antecedent may help the reader
with clarity.
Original:
It should be noted that this YANG module relies on the TE-Topology
Model [RFC8795] by using a reference to an abstract node to achieve
this.
Perhaps:
It should be noted that the VN YANG module described in this document
relies on the TE-Topology Model in [RFC8795] by using a reference to
an abstract node to provide VN-level constraints and optimization
criteria.
-->
16) <!--[rfced] We have received guidance from Benoit Claise and the YANG
Doctors that "YANG module" and "YANG data model" are preferred.
a) We will update to use the above forms unless we hear objection.
b) Note that we have already updated the short/running title of the
document from "VN YANG Model" to "VN YANG Data Model". Please let us
know any objections.
c) Please let us know if any uses of "VN model" (particularly in the
Introduction) should also be updated with the above guidance in mind.
We see the following inconsistent use of that term. Please also let
us know any updates to the capitalization scheme of this term.
VN model vs. VN Model
VN module
VN-YANG model vs. VN YANG model vs. VN Yang model
d) Please review the way that the module from RFC 8795 is referred to
and let us know if/how this may be made uniform:
TE-Topology Model vs. TE-topology Model vs. TE-Topology model
vs. TE-topology model vs. TE Topology model
and
TE-Topo Model vs. TE-topo model
and
TE-topology YANG
TE-topo
e) We also see "TE-tunnel Model" (with Model capped). Please review
and advise on if Model should be used for these names of YANG modules.
-->
17) <!-- [rfced] We had a few comments/questions regarding sourcecode and
artwork elements:
a) FYI - We updated <artwork> to <sourcecode> in Sections 4.3.1,
4.3.2, 5, and 6 and in Appendix B.1 and B.2. Please confirm that this
is correct.
b) Please consider whether the "type" attribute of any sourcecode
element should be set and/or has been set correctly.
The current list of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to
suggest additions for consideration. Note that it is also acceptable
to leave the "type" attribute not set.
c) FYI - We updated the list in Section 3.2 to <artwork> to match the
artwork in Section 2.1 and Appendix B.1. Please confirm that this is
correct.
d) We note that the tree structures represented in Sections 4.3.1,
4.3.2, and 5 all have line lengths over the 72-character limit. RFC
8792 defines the use of the backslash character for breaking these
lines. We will update to use backslashes where necessary and add an
informative reference to RFC 8792 unless we hear objection.
-->
18) <!--[rfced] We had the following questions related to figure titles in
this document:
a) We note that Figures 2, 6, and 11 do not have titles while the
other figures in the document do. Please let us know what, if any,
titles you would like to add.
b) We note that Figures 9 and 10 have the same titles. Please let us
know if these figures can be differentiated in some way. We also feel
doing so might lead to an updated of this text, in which "In either
case" might be able to become more easily understandable to the
reader:
Original:
In either case the output includes a reference to the single node
abstract topology with each VN-member including a reference to the
connectivity-matrix-id where the path properties could be found.
c) We see the title of Figure 3 includes "One Node Topology" while the
title of Figure 4 is "Type 2 Topology". Should these be made more
similar? That is, is Figure 3 actually "Type 1 Topology"?
-->
19) <!--[rfced] We had the following questions/comments regarding
abbreviation use in this document:
a) To match the guidance at
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev, we will
remove the expansions from abbreviations that have already been
expanded (excluding repeats in the YANG). Examples as follows:
VN
PE
b) We have expanded these abbreviations on first use as follows.
Please let us know any objections:
LSP - Label Switched Path
RPC - Remote Procedure Call
c) To reduce redundancy, we cut repeated words from following an
abbreviation. Please let us know any objections.
RPC call
d) We note that the document uses both "cos" and "COS" as relates to
Class of Service. Please review if this capitalization variance
should be made uniform and if so, which form is preferred.
-->
20) <!--[rfced] The following terminology appears to have been used
inconsistently throughout the document. Please review each use
carefully and let us know if/how they may be updated. Note: it
may be easier for authors to directly update our edited XML,
which they are welcome to do.
a) Please review the mixed use of capitalization, hyphenation, and
word order in the instances of the following. Please let us know
if/how to update.
VN Members vs. VN members vs. VN-members vs. vn-member
VN Type vs. VN type
abstract node vs. Abstract Node vs. Abstract node vs. node abstract
single-node-abstract topology vs. single node abstract topology
vs. single node topology abstract1
TE topology vs. TE Topology vs. TE-topology vs. TE network topology
vs. TE-topo
Connectivity Matrices vs. connectivity matrix and Conn. Matrix
vs. conn. matrix
vn-compute vs. VN compute vs. Computed VNs vs. computed VN vs.
VN computation
explicit path vs. explicit abstract path vs. Explicit path
b) Please review the use of multi-source vs. multi-src and
multi-destination vs. multi-dest and let us know if updates are
desired.
c) May we update to use hyphenation with VN-level when in attributive
position throughout?
d) We note that this document uses "compute only" while
draft-ietf-teas-yang-te-36 uses "compute-only". Please let us know
how you would like to update for consistency.
-->
21) <!--[rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this
nature typically result in more precise language, which is
helpful for readers.
For example, our script pointed out:
native TE topology / native TE Topology
Native/White topology
With the use of "Gray topology", we assume "Native/White topology" is
related. Please advise.
-->
Thank you.
RFC Editor/mf
*****IMPORTANT*****
Updated 2025/01/27
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9731.xml
https://www.rfc-editor.org/authors/rfc9731.html
https://www.rfc-editor.org/authors/rfc9731.pdf
https://www.rfc-editor.org/authors/rfc9731.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9731-diff.html
https://www.rfc-editor.org/authors/rfc9731-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9731-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9731
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9731 (draft-ietf-teas-actn-vn-yang-29)
Title : A YANG Data Model for Virtual Network (VN) Operations
Author(s) : Y. Lee, D. Dhody, D. Ceccarelli, I. Bryskin, B. Y. Yoon
WG Chair(s) : Oscar Gonzalez de Dios, Vishnu Pavan Beeram, Lou Berger
Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
