Re: [MBONED] Continued Review of multicast-yang-model
zhang.zheng@zte.com.cn Sat, 08 May 2021 08:49 UTC
Return-Path: <zhang.zheng@zte.com.cn>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6313A444C for <mboned@ietfa.amsl.com>; Sat, 8 May 2021 01:49:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 NvBS68g-M5wr for <mboned@ietfa.amsl.com>; Sat, 8 May 2021 01:49:06 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFA03A4448 for <mboned@ietf.org>; Sat, 8 May 2021 01:49:04 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id A2CDB852CAFBAA80A956; Sat, 8 May 2021 16:49:02 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl2.zte.com.cn with SMTP id 1488mbc2006700; Sat, 8 May 2021 16:48:37 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Sat, 8 May 2021 16:48:37 +0800 (CST)
Date: Sat, 08 May 2021 16:48:37 +0800
X-Zmail-TransId: 2afb60965065cb3e3063
X-Mailer: Zmail v1.0
Message-ID: <202105081648374200718@zte.com.cn>
In-Reply-To: <D2BD5442-7FED-42E9-9831-9CD8D69D4ED7@akamai.com>
References: D2BD5442-7FED-42E9-9831-9CD8D69D4ED7@akamai.com
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: jholland@akamai.com
Cc: mboned@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 1488mbc2006700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/CcBA0QFCH9JMifwSMoAFpNFUvsE>
Subject: Re: [MBONED] Continued Review of multicast-yang-model
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 May 2021 08:49:11 -0000
Hi Jake, Thank you very much for your review! And sorry for the late response. Please find my answer with Sandy> inline. 原始邮件 发件人:Holland,Jake 收件人:MBONED WG;张征00007940; 日 期 :2021年03月20日 11:01 主 题 :Continued Review of multicast-yang-model Hi Sandy, During the mboned meeting I think you said you were waiting on a review from me, but I thought I had sent one here the day after IETF 109, so I didn't realize you were waiting: https://mailarchive.ietf.org/arch/msg/mboned/cjVQ_qM2yeboxY0i3vvjSe9g3Xo/ Sandy> Appreciate for your review again! :-) Also, after a quick review of what I said during 109, I think I was expecting you to send something to the list detailing which parts of the model were well-proven with its use in production, and which parts of the model needed a closer look since nobody has used it yet: https://www.youtube.com/watch?v=K1FS3XqqWTw&t=3371s Sandy> Because we verified this model in ODL BIER project, so some other parts included in this model, such as mldp or p2mp-te, has not been verified yet. So experience with these protocols may do good help for the model review. Anyway, I see from my last review that there's parts of the document I didn't cover, so I guess I'll try to do that now: 0. I'm struggling with the high-level expectations of what happens in a network if I configure something with this model. In Appendix A, a helpful example is given, but what happens when you set that data instance in a netconf instance? Does it make the forwarding get configured, so this is mostly a transport path signaling mechanism? Sandy> The model can be used by netconf, but it won't affect the netconf running. When this model configured, some other model may be also configured. For example, when BIER is configured as transport, BIER model may also be configured if you have any parameter needs to be set in BIER model. What happens if the underlay does not match? (For example, what if the underlay in the setting says ospf, but it's in fact the network between ingress and egress was running isis?) Sandy> Yes. The underlay may not match. So the nofitication can be used to report this situation to controller. But what the controller needs to do is out of scope of this draft. 1. There are errors in the yang rules validation, as reported on the datatracker page: https://datatracker.ietf.org/doc/draft-ietf-mboned-multicast-yang-model/ ietf-multicast-model@2020-09-30.yang:252: error: RFC 8407: 4.14: statement "grouping" must have a "description" substatement ietf-multicast-model@2020-09-30.yang:363: error: RFC 8407: 4.14: statement "grouping" must have a "description" substatement ietf-multicast-model@2020-09-30.yang:364: error: RFC 8407: 4.14: statement "choice" must have a "description" substatement These seem to need a fix. Sandy> Thank you very much for your reminder, I'll fix it. 2. In 3.2/3.3, the multicast-keys list seems to be a problem, especially with respect to vni-type and vni-value, because there's only 3 possibilities for virtual-type (vxlan, nvgre, and geneve), but a value is required in order to have it as a key. Likewise, I'm not sure the vpn-rd and vni-value make sense for all (S,G)s, do these have a value? (What about in a traditional PIM network?) Would it make sense to use a type that permits these to be blank where appropriate? Sandy> Yes. If these keys are not used, it can be set to blank or zero. 3. I'm confused about the multicast-underlay/ospf/ospf/toplogy location. What is that, and why don't the other underlays have anythin analogous? Sandy> Thank you for your pointing out it. OSPF and ISIS support multi-topoloty feature, so the underlay can map to a specific topology. I'll also add it in ISIS underlay. 4. In section 3.3, there are a lot of grammar problems. I'll list some of them here, do you need text suggestions for these? Sandy> Much appreciate if you make some suggestion for these. :-) 4.a. ... Multicast keys include the features of multicast flow, such as(vpnid, multicast source and multicast group) information. In data center network, for fine-grained to gather the nodes belonging to the same virtual network, there may need VNI-related information to assist. 4.b. ... there may define BIER information including (Subdomain, ingress-node BFR-id, egress-nodes BFR-id). If no (ingress-node, egress-nodes) information are defined directly, there may need overlay multicast signaling technology, such as MLD or MVPN, to collect these nodes information. 5. In section 3.3, I was confused by this bit: ... One or several transport technologies could be defined at the same time. What does it mean if several transport technologies are defined at the same time, are those for redundant paths or something? Likewise this about the underlay: ... One or several underlay technologies could be defined at the same time if there is protective requirement. By "protective environment" do you mean a redundant setup that can forward the traffic through multiple paths? (And if so, what if the redundant paths use the same type of underlay? Or if not, what does it mean?) Sandy> Yes. But I am not sure if these usage is existed actually. Do you think it's better to only keep one for it? 6. As an overview comment: I still feel like I'm missing something when I read through this spec--am I understanding correctly that the whole purpose is to set up the forwarding for each of the given (S,G)s through the network? If so, I'm confused about what the underlay and overlay properties are for, exactly. How does the controller use the information that there's an OSPF underlay, when it has that info? Sandy> For example, if the OSPF topology is configured, the associated OSPF YANG should also be configured in the controller. And the controller will push the multicast model and OSPF model to the device. But as you said, the description needs to be updated. It's great if you have any suggestion for it. I hope that's helpful, and please let me know if you're expecting anything else from me on this revision. Sandy> Thank you very much again for your help! Best regards, Sandy Best regards, Jake
- [MBONED] Continued Review of multicast-yang-model Holland, Jake
- Re: [MBONED] Continued Review of multicast-yang-m… zhang.zheng
- Re: [MBONED] Continued Review of multicast-yang-m… zhang.zheng
- Re: [MBONED] Continued Review of multicast-yang-m… Gyan Mishra
- Re: [MBONED] Continued Review of multicast-yang-m… Holland, Jake
- Re: [MBONED] Continued Review of multicast-yang-m… zhang.zheng
- Re: [MBONED] Continued Review of multicast-yang-m… Gyan Mishra
- Re: [MBONED] Continued Review of multicast-yang-m… zhang.zheng
- Re: [MBONED] Continued Review of multicast-yang-m… zhang.zheng