[MBONED] Continued Review of multicast-yang-model
"Holland, Jake" <jholland@akamai.com> Sat, 20 March 2021 03:01 UTC
Return-Path: <jholland@akamai.com>
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 A34383A1858 for <mboned@ietfa.amsl.com>; Fri, 19 Mar 2021 20:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.347
X-Spam-Level:
X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 cxszuZnp7-jd for <mboned@ietfa.amsl.com>; Fri, 19 Mar 2021 20:01:19 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 10FCB3A1857 for <mboned@ietf.org>; Fri, 19 Mar 2021 20:01:18 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12K2j2O3009987; Sat, 20 Mar 2021 03:01:18 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=4h2GOWNryL2Rt+T2Y1VJsfu8HlLkoffN1RgRpzpYtF0=; b=ojZGCRqHAyzSDMf1/+8Lgw/X+J0IQbMeHukqNMa9DXilrtWLp9G8/wDAQB/38gA4Zjot 8ajzgrQ5+YD0VV6G+rUYZq3vkAQ5OHVGRX8l/ilxlxWSKaxAjgRh7R3EU1VhFEEcU6pX MDgblnF6H8B6A0LoZ8Je9CmhCEXQ2KX2ZDKjXDU3YdfiCFUaGeLnTrGMgeroBNRvIP/q Qq4+PQT1tSXIyFd1mxUvXAd09vQZCR6Gpsyn6XZaU14yqvHSPb4kykAEhLCeqwl5ueQR rIpw/BbuaFbR4ImwGJKgJdBqzYHXYbCO+mq6CsFhdWRN6pCQWQm9+ke+iATh75ctfMT9 Mw==
Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 379s4dbetw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 20 Mar 2021 03:01:18 +0000
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 12K2nYD1026607; Fri, 19 Mar 2021 23:01:17 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint8.akamai.com with ESMTP id 37c4we92rb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 19 Mar 2021 23:01:17 -0400
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.165.122) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Mar 2021 22:01:16 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.165.122]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.165.122]) with mapi id 15.00.1497.012; Fri, 19 Mar 2021 22:01:16 -0500
From: "Holland, Jake" <jholland@akamai.com>
To: MBONED WG <mboned@ietf.org>, "zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>
Thread-Topic: Continued Review of multicast-yang-model
Thread-Index: AQHXHTVLr2PcnFq8yUq0bcRhF8kOVQ==
Date: Sat, 20 Mar 2021 03:01:16 +0000
Message-ID: <D2BD5442-7FED-42E9-9831-9CD8D69D4ED7@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.46.21021202
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.118.139]
Content-Type: text/plain; charset="utf-8"
Content-ID: <37CEB48286D6674EAC19939984EC62E7@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-19_12:2021-03-19, 2021-03-19 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 phishscore=0 mlxscore=0 suspectscore=0 adultscore=0 spamscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103200020
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-19_12:2021-03-19, 2021-03-19 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 phishscore=0 adultscore=0 clxscore=1011 suspectscore=0 mlxlogscore=957 malwarescore=0 bulkscore=0 impostorscore=0 mlxscore=0 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103200020
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=jholland@akamai.com smtp.helo=prod-mail-ppoint8
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/6A9Tcu9Cl7DC_I_PKPlR7XEXg-8>
Subject: [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, 20 Mar 2021 03:01:21 -0000
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/ 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 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? 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?) 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. 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? 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? 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? 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?) 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? I hope that's helpful, and please let me know if you're expecting anything else from me on this revision. 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