Hi Bo,
Thanks for your review.
On Wed, Jun 5, 2024 at 7:58 AM Bo Wu via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Bo Wu
Review result: Has Nits
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.
Dhruv: I will remove "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?
Dhruv: Since the 'te-node-id' is not a key, it is not possible to change to relative path like "path "/nw:networks/nw:network/nw:node[tet:te-node-id=current()/../abstract-node]/nt:termination-point/tet:te-tp-id";"
Instead I will update the description.
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.
Dhruv: Those are APs and not LTPs. I will clarify.
- For "vn-member" YANG model, "src-vn-ap-id" and "dest-vn-ap-id" are better to
contextually restricted to "ap"?
Dhruv: This makes sense and has been updated.
## 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.
Dhruv: Done
- 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.
Dhruv: I added a reference to RFC9256. I am not sure adding a reference to the SR YANG model is correct.
- 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.
Dhruv: I moved it out into a new section 4.4
- 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.
Dhruv: I moved it out into a new section 4.5 and updated the text
## 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)
Dhruv: Ack, updated.
Thanks!
Dhruv
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
