Skip to main content

Last Call Review of draft-ietf-teas-actn-vn-yang-26

Request Review of draft-ietf-teas-actn-vn-yang
Requested revision No specific revision (document currently at 29)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2024-06-06
Requested 2024-05-16
Requested by Jim Guichard
Authors Young Lee , Dhruv Dhody , Daniele Ceccarelli , Igor Bryskin , Bin Yeong Yoon
I-D last updated 2024-06-04
Completed reviews Genart Last Call review of -25 by Behcet Sarikaya (diff)
Yangdoctors Last Call review of -24 by Andy Bierman (diff)
Rtgdir Last Call review of -28 by Susan Hares (diff)
Secdir Last Call review of -26 by Shivan Kaul Sahib (diff)
Opsdir Last Call review of -26 by Bo Wu (diff)
Rtgdir Early review of -22 by Darren Dukes (diff)
Yangdoctors Early review of -10 by Andy Bierman (diff)
Assignment Reviewer Bo Wu
State Completed
Request Last Call review on draft-ietf-teas-actn-vn-yang by Ops Directorate Assigned
Posted at
Reviewed revision 26 (document currently at 29)
Result Has nits
Completed 2024-06-04
As an Ops reviewer, I have the following comments:

The document describes a YANG model for Virtual Network (VN) Operations. It is
almost ready for publication. I previously reviewed an earlier version of this
document during the WGLC.

There are several mentions of LTP and definitions related to YANG in this
document, with some comments as follows:

- The term "ltp" appears to be inconsistent:

  The introduction states:
  Characteristics of Virtual Network Access Points (VNAP) that describe how an
  AP is partitioned for multiple VNs sharing the AP and its reference to a Link
      Termination Point (LTP) of the Provider Edge (PE) Node.

From this sentence, it seems that LTP refers to the LTP in the native TE
topology, because in YANG, PE is defined as the PE node in the native TE
Topology. While in the YANG model and the Examples in B.1. VN JSON, it looks
like "ltp" is the LTP within the abstract node, correct? If so, could the YANG
path be modified to a relative path of the abstract node?

Also in Figures 2 and 3, the diagrams appear to show that L1-L8 are all LTPs of
same kind. While in the examples of B.2. TE-topology JSON, these two typess of
LTPs use different identifiers, therefore it is suggested to be clarified.

- For "vn-member" YANG model,  "src-vn-ap-id" and "dest-vn-ap-id" are better to
contextually restricted to "ap"?

## Minor
- In Section 4.3.1. VN Compute, it mentions "achieving this via path
computation or 'compute only' tunnel setup does not provide the same
functionality", it is suggested to add a reference to the definition of the TE
tunnel. - In Section 4.3.3. Others, the "underlay" node mentions SR. It would
be clearer if a reference to the SR YANG model could be added. - The content of
Section 4.3.3. Others does not seem to belong to Section 4.3 Innovative
Services. It is suggested to make it an independent section or combine it with
Section 3.2.1. VN and AP Usage into a separate independent section. - The
summary in Section 4.3.4 includes some content that is not discussed in 4.3, it
is suggested to remove it, for example, Maintenance of AP and VNAP along with
VN, VN construct to group of edge-to-edge links, Ability to support various VN
and VNS Types.

## Nits
- s/inter- domain/inter-domain
- s/VN-Member/VN-member
- s/L1, L2, L3, L4, L7 and L8/L1, L2, L3, L4, L7, and L8
- s/Provider Edge (PE) ./Provider Edge (PE).
- s/To achieve this/To achieve this,
- s/creation of VN/creation of a VN
- s/(S2 and S7)/(S4 and S7)