Re: [OPSAWG] Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06

"Wubo (lana)" <lana.wubo@huawei.com> Mon, 25 April 2022 08:44 UTC

Return-Path: <lana.wubo@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47B63A12CA; Mon, 25 Apr 2022 01:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EQoOZBPH_bZ; Mon, 25 Apr 2022 01:44:26 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9803A12BA; Mon, 25 Apr 2022 01:44:26 -0700 (PDT)
Received: from fraeml706-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Kmz5X6szFz67xBy; Mon, 25 Apr 2022 16:41:52 +0800 (CST)
Received: from kwepemi500011.china.huawei.com (7.221.188.124) by fraeml706-chm.china.huawei.com (10.206.15.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.24; Mon, 25 Apr 2022 10:44:21 +0200
Received: from kwepemi500014.china.huawei.com (7.221.188.232) by kwepemi500011.china.huawei.com (7.221.188.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 25 Apr 2022 16:44:20 +0800
Received: from kwepemi500014.china.huawei.com ([7.221.188.232]) by kwepemi500014.china.huawei.com ([7.221.188.232]) with mapi id 15.01.2375.024; Mon, 25 Apr 2022 16:44:20 +0800
From: "Wubo (lana)" <lana.wubo@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "draft-ietf-opsawg-yang-vpn-service-pm@ietf.org" <draft-ietf-opsawg-yang-vpn-service-pm@ietf.org>
CC: 'opsawg' <opsawg@ietf.org>
Thread-Topic: Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06
Thread-Index: AdhWZsmF1/vkxsf0R4egBFtGMbrwpwB8k5lA
Date: Mon, 25 Apr 2022 08:44:20 +0000
Message-ID: <4c387dd328b445ca9d2201572f31d06b@huawei.com>
References: <010201d85666$ee4a76a0$cadf63e0$@olddog.co.uk>
In-Reply-To: <010201d85666$ee4a76a0$cadf63e0$@olddog.co.uk>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.98.73]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/bi4sTtkocSLl8JKxCQAsFktYOqo>
Subject: Re: [OPSAWG] Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Apr 2022 08:44:30 -0000

Hi Adrian,

Many thanks for your detailed review. We have released Rev-07 to address these issues, see if they are fully addressed.
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-07

Please also find some replies inline.

Thanks,
Bo

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
Sent: Saturday, April 23, 2022 12:35 AM
To: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org
Cc: 'opsawg' <opsawg@ietf.org>
Subject: Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06

Hi,

I'm the document shepherd for this document as it moves beyond the WG for requested publication as an RFC.

I reviewed the draft at -03 during WG last call, so my comments here are basically editorial with only a few small questions.

If the authors could produce a new revision, I will start work on the shepherd write-up.

One other point: can someone say whether this draft has been shared with the IPPM working group?

Thanks,
Adrian

===

Introduction.

First sentence could use a reference to RFC 6020.
[Bo Wu] Fixed.

---

Introduction

OLD
   It defines that the performance
   measurement telemetry model to be tied with the service, such as
   Layer 3 VPN and Layer 2 VPN, or network models to monitor the overall
   network performance or Service Level Agreement (SLA).
NEW
   It defines that the performance
   measurement telemetry model should be tied to the services (such as
   a Layer 3 VPN or Layer 2 VPN) or to the network models to monitor the
   overall network performance and the Service Level Agreements (SLAs).
END

 [Bo Wu] Fixed.
---

2.1

OLD
   SLA     Service Level Agreements
NEW
   SLA     Service Level Agreement
END

[Bo Wu] Fixed.
---

3.

   For example, the
   controller can use information from [RFC8345], [I-D.ietf-opsawg-sap]
   or VPN instances.

I think this is where there should be a reference to RFC 9182 and draft-ietf-opsawg-l2nm.

[Bo Wu] Fixed.
---

3.1

s/dynamic-changing/dynamic/
[Bo Wu] Fixed.

---

4.

OLD
   This document defines the YANG module, "ietf-network-vpn-pm", which
   is an augmentation to the "ietf-network" and "ietf-network-topology".
NEW
   This document defines the YANG module, "ietf-network-vpn-pm", which
   is an augmentation to the "ietf-network" and "ietf-network-topology"
   modules.
END

[Bo Wu] Fixed.
---

4.

Would it be more consistent if the box on the right of Figure 2 showed "ietf-network-vpn-pm"?
[Bo Wu] Fixed.

---

I think that Figure 3 could use a little tidying.
- Some gaps in lines
- A couple of lines slightly out of place
- S2A and S2B are confusinly places
- The cross-over of VN3-N2 and VN1-N1 is unclear
- Wording of the Legend a little unclear

How about...


                     VPN 1                       VPN 2
          +------------------------+   +------------------------+
         /                        /   /                        /
        / S1C_[VN3]:::           /   /                        /
       /         \   :::::      /   / S2A_[VN1]____[VN3]_S2B /
      /           \       :::  /   /      :          :      / Overlay
     /             \         :::::::::::: :          :     /
    / S1B_[VN2]____[VN1]_S1A /   /       :           :    /
   +---------:-------:------+   +-------:-:----------:---+
             :        :     ::::::::::::   :         :
             :         :   :                :        :
   Site-1A   :  +-------:-:------------------:-------:-----+ Site-1C
     [CE1]___:_/_______[N1]___________________[N2]___:____/__[CE3]
             :/       / / \             _____//     :    /
   [CE5]_____:_______/ /    \     _____/     /    ::    /
 Site-2A    /:        /       \  /          /   ::     /
           / :                [N5]         /  ::      / Underlay Network
          /   :     /       __/ \__       / ::       /
         /     :   /    ___/       \__   /::        /
Site-1B /       : / ___/              \ /:         /  Site-2B
[CE2]__/________[N4]__________________[N3]________/____[CE4]
      /                                          /
     +------------------------------------------+

    Legend:
    N:Node   VN:VPN-Node  S:Site  CE:Customer Edge
    __  Link within a network layer
    :   Mapping between network layers

[Bo Wu] Fixed. Thanks for helping to correct the figure.
---

4.1

s/topologies are both built/topologies are built/
[Bo Wu] Fixed.

---

The legend for Figure 4 should include "TP" (if TPs are actually relevant to the figure and aren't something you should remove - the text doesn't mention them, and they don't really seem to be important in Section 4.1).

Probably, TP should be added to the list in Section 2.1 with a reference to where TP is properly explained. 4.4 would then be able to lean on that definition.

[Bo Wu] Fixed. Thanks for catching this. The reference of TP has been added in Section 2.1.
---

4.1

s/VPN PM can provides/VPN PM can provide/

[Bo Wu] Fixed.
---

4.2

s/[RFC9181])./[RFC9181]./

[Bo Wu] Fixed.
---

4.2 etc.

Not sure why 'mac-num' has that name when you use 'ipv4' and 'ipv6'
not 'ipv4-num' and 'ipv6-num'.  This is highly unimportant, but might be something to fix purely for consistency of appearance.

[Bo Wu] Fixed.
---

4.4

   The 'links' are classified into two types: topology link defined in
   [RFC8345] and abstract link of a VPN between PEs.

Would be nice to give a reference for the abstract link as well.
[Bo Wu] Fixed. The abstract one is defined in this module.

---

4.4

   The performance data of a link is a collection of counters that
   report the performance status.

Perhaps "counters and gauges"?
[Bo Wu] Fixed.

---

5. and  10.

I think that all documents referenced from 'reference' clauses should be Normative References. I found 3 (4026, 4364, 8571) that are not.
There might be a good reason (if so tell me) or this could be an oversight.
[Bo Wu] Fixed. Sorry for the oversight, not fully corrected. Tom also pointed this out .

---

5.

It's not really your fault, but I hate to see types redefined, especially with the same name.

     typedef percentage {
       type decimal64 {
         fraction-digits 5;
         range "0..100";
       }
       description
         "Percentage.";
     }

...appears exactly like this in RFC 8532. This makes me think that it should possibly be in a common types module somewhere. Possibly nothing you can do about this at this stage.

Do we have a way of flagging desirable common types to Netmod?

Is there value in you using a different name for this type just to set it in the context of your work?
[Bo Wu] Thanks for pointing this out. And I need more guidance on this issue. The definition of percentage in this draft is the same as that in RFC 8532, which is also for "loss-ratio". Actually, this value may derive from the mechanism of RFC 8532. We have imported "ietf-lime-time-types" from RFC 8532. But "percentage" is defined in "ietf-connectionless-oam". As "ietf-connectionless-oam" is a device model, I'm not sure if a network configuration model could import "ietf-connectionless-oam".

---

5.

vpn-pm-type has a case for inter-vpn-access-interface that is empty and described as a placeholder. And that is all good.

But I expected some text (not a lot) explaining:
- why this is empty
- how/why it might be used in future (presumably through augmentation)

I suspect this belongs in the "VPN PM type" hanging text in Section 4.4
[Bo Wu] Our consideration is inter-vpn-access-interface PM is VPN-specific measurement, compared with the tunnel PM that may be shared by multiple VPNs. And based on this, the measurement could be CE-PE-PE-CE or PE-PE or other combination. The empty leaf is defined to specify the basic VPN specific measurement, and allow extension for other measurement combinations.
Please see whether the new text helps. Here is the text proposed:
"This is a placeholder for inter-vpn-access-interface PM, which is not bound to a specific VPN access interface. The source or destination VPN access interface of the measurement can be augmented as needed."

---

OLD
   Appendix A.  Illustrating Examples
NEW
   Appendix A.  Illustrative Examples
OR
   Appendix A.  Examples
END
[Bo Wu] Fixed.