Re: [pim] Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-snooping-yang-17: (with DISCUSS and COMMENT)

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 14 July 2020 11:50 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6321B3A0AFA; Tue, 14 Jul 2020 04:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.62
X-Spam-Level:
X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cMLAjgzk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RE72HQnI
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 AZV_6OlnGvpa; Tue, 14 Jul 2020 04:50:32 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5403A0AF7; Tue, 14 Jul 2020 04:50:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21940; q=dns/txt; s=iport; t=1594727431; x=1595937031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3ioTSV/owQQWEq2j55hL+vS1Dirom3ZkKtd8yx39HUM=; b=cMLAjgzk3k5EXRuk4gu0E2WlWXlOLtjxkc4yWrNg+sklCbwWYVBAWnM8 +TMnLsjdCY5a8oWJ/pHD+Bixz7OSZfHMR10f0ImhqTvE2et/Gm5/6qOfj gMQuQj08KF2F2UtaU8kZZNA5UKWjr/r/+2HCbGhgBYTWKJzWR3ZmESuc6 M=;
IronPort-PHdr: =?us-ascii?q?9a23=3AID+ISBSXDvZWf/FV4OjEZPQSqNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9mJ5/dNkeGQsq38VyoH+5nS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh4TsbAB?= =?us-ascii?q?65NAdpKKLyAIGBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR?= =?us-ascii?q?6cqXpTcOMQzmRtdl8=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwBQCYmg1f/4UNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUlEHb1gvLAqEKYNGA41RigKOXIFCgREDVQsBAQEMAQE?= =?us-ascii?q?jCgIEAQGETAIXggUCJDgTAgMBAQsBAQUBAQECAQYEbYVbDIVvAQEBAQIBEhE?= =?us-ascii?q?RDAEBKQ4BCwQCAQgRAwEBAQMCHwcCAgIfERUICAIEAQ0FCBqDBYJLAw4gAQ6?= =?us-ascii?q?dZAKBOYhhdoEygwEBAQWBRkGDJQ0Lgg4DBoEOKoJqg1WCL4QEGoFBP4ERQ4J?= =?us-ascii?q?NPoIaQgICAQGBJgESAQcCGoMUM4ItjxEjgxSiFE0Kgl2IU4wXBIUNgnWJOYU?= =?us-ascii?q?ljWCRcYokgluNUYQmAgQCBAUCDgEBBYFqI2dYEQdwFYMkUBcCDY4eN4M6hRS?= =?us-ascii?q?FQnQCNQIGAQcBAQMJfI5LAYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.75,350,1589241600"; d="scan'208";a="801285170"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2020 11:50:30 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 06EBoUQJ020325 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Jul 2020 11:50:30 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Jul 2020 06:50:29 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Jul 2020 06:50:29 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 14 Jul 2020 06:50:29 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZO9ZOpPR4+TxN6Jwv6I6cXocqMw0JBqggjiZloEefbUq7N3FJDiXCjMtAO0Q3ViS8MAX3z8RTrMZ7ymytf1Ny/8A20GJCtLxGX3c/2nctXOmXledv1ZKIpuqoPOSzpUHmY2ruHUfGrdEMWoNiyylC9kiPA+B+hPPaQkpPzVyEfWo1e5mXpTfTjEi78e373EVnRGVd+T0kLN4ZIP+BPl23pM4pqjuVNxoapSwwRXHGAAA8UWS36XxhlYJvcSdV3HFfeiP6fSZPD3Qhj8KQnqBrC7kMLL5mowYZh9Bn3tfeItBkqM589kI42md3xJoYcTuhAmln7sc3dSsdkCwZg8L2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3ioTSV/owQQWEq2j55hL+vS1Dirom3ZkKtd8yx39HUM=; b=LWwZJ2qRhcyUpoQ8D03wGvypI14l4GKeoqDfWRttCM0TT/5+ghMMYxvqUQVpNotnzE+7EzOB7EBbeJGzax+544Y3nv3vCP4wI4UcKAf282zMsHOC7R5eDb9J30V5WPoQi/KraLBCiK2ISp6KVQLgirVIyMFLZ6NNfFuf9jBKZZm8E4qzatV59ZrOPNnlKyrLyakWJ74mrneof4rzWiU2g9Dq6Q6JarPMOZ2Ajlyl9uVhTrjtxl7lIVJW7j7zG51h/C5Rp0UcNatmkM/Ie29SgF1566tFHKFU+QqkPKrkqrDaOSmbDVeVF076CWi5sH815/qWVOj3CFhwkRM8e+7WpA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3ioTSV/owQQWEq2j55hL+vS1Dirom3ZkKtd8yx39HUM=; b=RE72HQnIlYreR3OnD1ON25IeWMyHJdJ0HO2ngRKZf5WflAv2HB4uKeqKPt/9Hmn+fXa0uqhpJaxvTb5LCquW3SFy7bSafnxAjjn4x7nzanOToLi9uhqiKn1C8OAxizCdFoLmhUGKcqofw7q4+Qdzx5u1O5foQDk4w0V37GKIDwI=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3252.namprd11.prod.outlook.com (2603:10b6:208:6e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Tue, 14 Jul 2020 11:50:27 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18%5]) with mapi id 15.20.3174.026; Tue, 14 Jul 2020 11:50:27 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, Hongji Zhao <hongji.zhao@ericsson.com>, The IESG <iesg@ietf.org>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
CC: Stig Venaas <stig@venaas.com>, "pim-chairs@ietf.org" <pim-chairs@ietf.org>, "pim@ietf.org" <pim@ietf.org>, "draft-ietf-pim-igmp-mld-snooping-yang@ietf.org" <draft-ietf-pim-igmp-mld-snooping-yang@ietf.org>
Thread-Topic: Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-snooping-yang-17: (with DISCUSS and COMMENT)
Thread-Index: AQHWVdcaKt9UCD5UUEutTLuXABV+vKkGcTkAgABSZOCAADRTAIAABWJg
Date: Tue, 14 Jul 2020 11:50:27 +0000
Message-ID: <MN2PR11MB43666D4D3FBB12BD1F618254B5610@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <159428852777.7283.9711125025293117565@ietfa.amsl.com> <HE1PR0701MB249249C361CB7EAE14C9E8BF96610@HE1PR0701MB2492.eurprd07.prod.outlook.com> <BY5PR11MB435511BEE3DAF693888E91E2B5610@BY5PR11MB4355.namprd11.prod.outlook.com> <FCA2400B-CC22-47DB-9E0C-9BD100107A0F@cisco.com>
In-Reply-To: <FCA2400B-CC22-47DB-9E0C-9BD100107A0F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [64.103.40.19]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3a91e016-3bf5-4f05-6d7d-08d827ec1a3c
x-ms-traffictypediagnostic: BL0PR11MB3252:
x-microsoft-antispam-prvs: <BL0PR11MB3252A71D5134543861C7EC3EB5610@BL0PR11MB3252.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: tQsFjABdcwdxdJb/JEjRr5CcoKNTTaF0sNAwIgZ5mp3h93VhPX7zKpbZ2QHO/IfhLMbexcjgHn8SIP62x6dvlDwvU1Qu73WesN8ybx+17KSFB9Z0nKSPCcJh0udPsK27K0a+0OoFfOMkZpV7ZIO0efg8lgu+4r7vscV1J+Q7Rp24MhClOZjSh+sQVmFeiwTg6NmCg5NeFZD9Po4q4jF7LW0tDuHSbzOcBf0NF1IJGAdMP77jTXbWlV73IQhRAVhVwHYJN4IpwGJQ9yqPZ2k0zD5zTfo+reCzMziQV3oGrdIsFwNC5wsDlUc8hI4pIbcWdz2/dcQHmv5+hXzS8hYKRHu3PbMw/u1sWHPNXP2qrMfoJLqUKF9/WyrJDFAYFFI+TPSvI76RpLXZmKoZHbwfjWMFmqsISpbOhBzm5rRWWlr/T9XekroEbWJt0lJMyeT1+sLIGiV2cQ32F0GWWi9NyQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(396003)(366004)(39860400002)(136003)(66556008)(64756008)(66574015)(8676002)(8936002)(66476007)(66446008)(66946007)(966005)(76116006)(54906003)(83380400001)(86362001)(478600001)(110136005)(71200400001)(33656002)(55016002)(316002)(9686003)(6506007)(186003)(53546011)(26005)(7696005)(4326008)(30864003)(2906002)(5660300002)(52536014)(21314003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: yGDvXAT6hgk9t5DT6BEQc7SCthT07U9rvkQj60q+yP3apBDCcw8WkwRO1OiGuzN6flSNf9tANq/CLm5Td42MnS3Ntq/FK7N3Ff+Gc9Bv4V2k7tgTN2Cp6X0smWARUrgsWA2ZwdiPfCC8CY+fIdb+H+uQjx5n8vy9U1UcxRWTo7m03oFA3zGcGq5ZarVcqEnxrpQXRyig1/ZGIBkqeVu5gC40Z3DQIz/UEQUpONQ3MQ3H+0DMRR+tehQ1HubtdIh0dr4YzNTNNfdVJ9xCaTTRQzsZK+dbGv30+ayVHxzPHsjWXmK7I4uyKxfw5kaAGj0mU1gEDsJLwobJWQeamq4vQIug0dABmwg1jmnO22FhJfdXUmPXs1JaU1FF0VIL3Ie2MpKnYRaBzWSibhqOBcCvXu1iuDcqAX8I9XXWKTJvFJuYGXmEM5G+1AXN+mgoksn/MbOItwq/witK7bmTrbzPyStxpqAMuzGxQ+Z/R0hE/Cs=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a91e016-3bf5-4f05-6d7d-08d827ec1a3c
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 11:50:27.7049 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vFos2Egb07c5daCI20pjCkfnHmrWluSUYsbrWzj8r9mhMqPrmuV/jvOO7gn3ozP5TepdjYg5szh8Vz4UlwKCSw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3252
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/g7OsP5Qa59_UGQR6zCJwiVRx6sU>
Subject: Re: [pim] Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-snooping-yang-17: (with DISCUSS and COMMENT)
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2020 11:50:44 -0000

Hi Hongji,

Having discussed this with Eric, I would also be happy with the suggestion that he proposes (i.e. of having a single combined tree that covers both IGMP snooping and MLD snooping), so it is another option for you to please consider.

Regards,
Rob


> -----Original Message-----
> From: Eric Vyncke (evyncke) <evyncke=40cisco.com@dmarc.ietf.org>
> Sent: 14 July 2020 12:28
> To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; Hongji Zhao
> <hongji.zhao@ericsson.com>om>; The IESG <iesg@ietf.org>rg>;
> aretana.ietf@gmail.com
> Cc: Stig Venaas <stig@venaas.com>om>; pim-chairs@ietf.org; pim@ietf.org;
> draft-ietf-pim-igmp-mld-snooping-yang@ietf.org
> Subject: Re: Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-snooping-
> yang-17: (with DISCUSS and COMMENT)
> 
> It seems that similar issues keep repeating for IPv4 and IPv6 (e.g. RFC
> 8652)... Either two trees in one module or two modules (one per address
> family).
> 
> While I am not a YANG expert, I would assume that network operators would
> prefer a unified models (of course with specific leaves & containers) when
> operating a dual-stack network rather than duplicating their automation
> effort.
> 
> As long as IPv6 is covered, I am OK (per my COMMENT on this I-D) but
> unsure whether 2 modules/2 trees should be the 'way to go'... For SNMP,
> RFC 4292/4293 was made protocol version independent which is a big plus
> IMHO for operations.
> 
> -éric
> 
> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> on behalf of "Rob Wilton (rwilton)"
> <rwilton=40cisco.com@dmarc.ietf.org>
> Date: Tuesday, 14 July 2020 at 10:58
> To: Hongji Zhao <hongji.zhao@ericsson.com>om>, The IESG <iesg@ietf.org>rg>,
> "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
> Cc: Stig Venaas <stig@venaas.com>om>, "pim-chairs@ietf.org" <pim-
> chairs@ietf.org>gt;, "pim@ietf.org" <pim@ietf.org>rg>, "draft-ietf-pim-igmp-mld-
> snooping-yang@ietf.org" <draft-ietf-pim-igmp-mld-snooping-yang@ietf.org>
> Subject: RE: Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-snooping-
> yang-17: (with DISCUSS and COMMENT)
> 
>     Hi Hongji,
> 
>     There are 3 choices here:
> 
>     (1) Put both models in the same YANG module, use common groupings, and
> then use top level features to enable/disable the functionality.  I.e.,
> this is what the draft currently does.
> 
>     Benefits:
>      - One module
>      - Use of groupings ensure the contents are aligned.
> 
>     Downsides:
>      - Undesirable top level IGMP/MLD features
>      - Somewhat unclear description statements (since the descriptions
> reference both IGMP and MLD even when they only apply to one protocol).
> 
> 
>     (2) Split the work into 3 YANG models:
>       (i) Common IGMP/MLD groupings/features, i.e. the same shared
> groupings that you have now.
>       (ii) IGMP snooping module (importing shared groupings)
>       (iii) MLD snooping module (importing shared groupings)
> 
>     Benefits:
>      - Avoids top level IGMP/MLD features
>      - Use of groupings ensures the contents are aligned
> 
>     Downsides:
>       - Somewhat unclear description statements (since the descriptions
> reference both IGMP and MLD even when they only apply to one protocol).
>       - Note, the 'refine' statement could be used where the groupings are
> used (RFC 7950 sec 7.13.2) to potentially improve the descriptions.
> Otherwise possibly some of the description statements could be slightly
> reworded to avoid referencing back to IGMP or MLD.
>       - Some features would need to belong the common module unless the
> data nodes using those features were taken out of the common groupings
> 
>     (3) Split the work into 2 separate modules
>       (i) IGMP snooping module
>       (ii) MLD snooping module
> 
>     Benefits:
>      - Avoids top level IGMP/MLD features
>      - Description statements are clear (since they always only refer to
> the protocol they act on)
>      - Features are controllable for each protocol separately (not sure if
> this is a benefit or a downside)
> 
>     Downsides:
>      - Duplicate definitions, more potential to get out of sync in future,
> although given that they are both defined in the same document, that
> doesn't seem too likely.
> 
> 
>     My preference is for (3).  I believe that makes it much easier/clearer
> to an operator to see whether one/both IGMP and MLD snooping is supported.
> 
>     However, this is just a preference, and I also want to see IETF YANG
> models completed and standardized.  I.e., I will not block progression of
> this document if the authors & Alvaro thinks that the existing module
> structure is sufficient, or choose to do (2) instead.
> 
>     Regards,
>     Rob
> 
> 
> 
>     > -----Original Message-----
>     > From: Hongji Zhao <hongji.zhao@ericsson.com>
>     > Sent: 14 July 2020 04:26
>     > To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; The IESG
> <iesg@ietf.org>
>     > Cc: draft-ietf-pim-igmp-mld-snooping-yang@ietf.org; pim-
> chairs@ietf.org;
>     > pim@ietf.org; Stig Venaas <stig@venaas.com>om>; aretana.ietf@gmail.com
>     > Subject: RE: Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-
> snooping-
>     > yang-17: (with DISCUSS and COMMENT)
>     >
>     > Hi Robert,
>     >
>     > Thanks a lot for your comments.
>     >
>     > In this YANG model, four of six groupings are common for both igmp
>     > snooping and mld snooping.
>     > If it is splitted into two separate YANG models, there will be a lot
> of
>     > duplicated contents.  Is it ok?   Thank you very much.
>     >
>     >
>     >
>     > BR/Hongji
>     >
>     > -----Original Message-----
>     > From: Robert Wilton via Datatracker <noreply@ietf.org>
>     > Sent: Thursday, July 9, 2020 5:55 PM
>     > To: The IESG <iesg@ietf.org>
>     > Cc: draft-ietf-pim-igmp-mld-snooping-yang@ietf.org; pim-
> chairs@ietf.org;
>     > pim@ietf.org; Stig Venaas <stig@venaas.com>om>; aretana.ietf@gmail.com;
>     > stig@venaas.com
>     > Subject: Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-
> snooping-yang-
>     > 17: (with DISCUSS and COMMENT)
>     >
>     > Robert Wilton has entered the following ballot position for
>     > draft-ietf-pim-igmp-mld-snooping-yang-17: Discuss
>     >
>     > When responding, please keep the subject line intact and reply to
> all
>     > email addresses included in the To and CC lines. (Feel free to cut
> this
>     > introductory paragraph, however.)
>     >
>     >
>     > Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
>     > for more information about IESG DISCUSS and COMMENT positions.
>     >
>     >
>     > The document, along with other ballot positions, can be found here:
>     > https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-snooping-
> yang/
>     >
>     >
>     >
>     > --------------------------------------------------------------------
> --
>     > DISCUSS:
>     > --------------------------------------------------------------------
> --
>     >
>     > Hi,
>     >
>     > I appreciate that this YANG model has already passed a YANG doctor
> review,
>     > but this discuss is to understand the reasoning as to why both IGMP
>     > snooping and MLD snooping are in the same YANG module, yet have top
> level
>     > features to separate their functionality.
>     >
>     >     4. IGMP and MLD Snooping YANG Module
>     >
>     >       feature igmp-snooping {
>     >         description
>     >           "Support IGMP snooping.";
>     >         reference
>     >           "RFC 4541";
>     >       }
>     >
>     >       feature mld-snooping {
>     >         description
>     >           "Support MLD snooping.";
>     >         reference
>     >           "RFC 4541";
>     >       }
>     >
>     > It seems strange to me to have the entire YANG Model split under two
>     > separate feature statements. I believe that it would have been
> better to
>     > split this into two separate YANG models, both following the same
>     > structure.  Possibly, a common YANG module could have been used to
> share
>     > groupings and definitions, but even then duplicating the contents of
> the
>     > model so that the description statements could be correct/accurate
> would
>     > be more helpful.
>     >
>     >
>     > --------------------------------------------------------------------
> --
>     > COMMENT:
>     > --------------------------------------------------------------------
> --
>     >
>     > Thank you for your work on this document and YANG model.  I also
> have a
>     > few minor comments/suggestions that may improve the document and
> YANG
>     > module:
>     >
>     >     2. Design of Data Model
>     >
>     >     An IGMP/MLD snooping switch [RFC4541] analyzes IGMP/MLD packets
> and
>     > sets
>     >     up forwarding tables for multicast traffic. If a switch does not
> run
>     >     IGMP/MLD snooping, multicast traffic will be flooded in the
> broadcast
>     >     domain. If a switch runs IGMP/MLD snooping, multicast traffic
> will be
>     >     forwarded based on the forwarding tables to avoid wasting
> bandwidth.
>     > The
>     >     IGMP/MLD snooping switch does not need to run any of the
> IGMP/MLD
>     >     protocols. Because the IGMP/MLD snooping is independent of the
>     > IGMP/MLD
>     >     protocols, the data model defined in this document does not
> augment,
>     > or
>     >     even require, the IGMP/MLD data model defined in [RFC8652].
>     >     The model covers considerations for Internet Group Management
> Protocol
>     >     (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches
>     >     [RFC4541].
>     >
>     > It wasn't clear to me what the final sentence was trying to say.
> Perhaps
>     > it should be merged with the penultimate sentence in the paragraph?
>     >
>     >     The YANG module includes IGMP and MLD Snooping instance
> definition,
>     >     using instance in the scenario of BRIDGE [dot1Qcp] and L2VPN
> [draft-
>     >     ietf-bess-l2vpn-yang]. The module also includes actions for
> clearing
>     >     IGMP and MLD Snooping group tables.
>     >
>     > I find the use of the terminology of "scenario of " to be somewhat
>     > strange.  I would probably have referred to these a "L2 forwarding
>     > pradigms" or "L2 forwarding instances".  If this terminology is
> changed
>     > then it would need to be fixed elsewhere in this document and the
> YANG
>     > model.
>     >
>     >     On the other hand, operational state parameters are not so
> widely
>     >     designated as features, as there are many cases where the
> defaulting
>     >     of an operational state parameter would not cause any harm to
> the
>     >     system, and it is much more likely that an implementation
> without
>     >     native support for a piece of operational state would be able to
>     > derive
>     >     a suitable value for a state variable that is not natively
> supported.
>     >
>     > With NMDA, the server also has the option of not returning a value
> for a
>     > given item of operational data (RFC 8342, section 5,3, paragraph 4).
>     > Although this doesn't conform to the data model, the semantics are
> well
>     > defined - i.e. the client cannot infer anything about the value that
> has
>     > not been returned.
>     >
>     >     2.3. Position of Address Family in Hierarchy
>     >
>     >     IGMP Snooping only supports IPv4, while MLD Snooping only
> supports
>     > IPv6.
>     >     The data model defined in this document can be used for both
> IPv4 and
>     >     IPv6 address families.
>     >
>     >     This document defines IGMP Snooping and MLD Snooping as separate
>     > schema
>     >     branches in the structure. The benefits are:
>     >
>     >     *  The model can support IGMP Snooping (IPv4), MLD Snooping
> (IPv6), or
>     >     both optionally and independently. Such flexibility cannot be
> achieved
>     >     cleanly with a combined branch.
>     >
>     >     *  The separate branches for IGMP Snooping and MLD Snooping can
>     >     accommodate their differences better and cleaner. The two
> branches can
>     >     better support different features and node types.
>     >
>     > I would suggest rewording this first sentence to something like:
>     >
>     > "Having separate branches for IGMP Snooping and MLD Snooping allows
> minor
>     > differences in their  behavior to be modelled more simply and
> cleanly".
>     >
>     >     3. Module Structure
>     >
>     >     A configuration data node is marked as mandatory only when its
> value
>     >     must be provided by the user. Where nodes are not essential to
>     > protocol
>     >     operation, they are marked as optional.  Some other nodes are
>     > essential
>     >     but have a default specified, so that they are also optional and
> need
>     >     not be configured explicitly.
>     >
>     > This paragraph seems to just describe standard YANG modelling and
> can be
>     > removed.
>     >
>     >     3.1. IGMP Snooping Instances
>     >
>     >     The value of scenario in igmp-snooping-instance is bridge or
> l2vpn.
>     > When it
>     >     is bridge, igmp-snooping-instance will be used in the BRIDGE
>     >
>     > As per previous comments, this first sentence does not read well for
> me.
>     >
>     >     The values of bridge-mrouter-interface, l2vpn-mrouter-interface-
> ac,
>     >     l2vpn-mrouter-interface-pw are filled by the snooping device
>     > dynamically.
>     >     They are different from static-bridge-mrouter-interface,
>     >     static-l2vpn-mrouter-interface-ac, and static-l2vpn-mrouter-
> interface-
>     > pw
>     >     which are configured
>     >
>     > Ideally, these static nodes would not have been necessary, instead
> relying
>     > on the NMDA split between configuration and state, but that would
> probably
>     > require the default model to always allow them to be statically
>     > configured.  In NMDA, features can be implemented per-datastore but
> it is
>     > not clear how well that would work here.
>     >
>     >       units one-tenth-second;
>     >
>     > Perhaps "units deciseconds" would be better?
>     >
>     >   grouping igmp-snooping-statistics {
>     >     description
>     >       "The statistics attributes for IGMP snooping.";
>     >
>     >       leaf num-query {
>     >         type yang:counter64;
>     >         description
>     >           "The number of Membership Query messages.";
>     >         reference
>     >           "RFC 2236";
>     >       }
>     >
>     > For these counters, rather than "num-XXX", I think that they would
> be
>     > better as "XXX-count", or if these relate to the number of packets
> "XXX-
>     > pkts" (as per RFC 8343).
>     >
>     >            container statistics {
>     >              description
>     >                "The interface statistics for IGMP snooping";
>     >
>     >              container received {
>     >                description
>     >                  "Statistics of received IGMP snooping packets.";
>     >
>     >                uses igmp-snooping-statistics;
>     >              }
>     >              container sent {
>     >                description
>     >                  "Statistics of sent IGMP snooping packets.";
>     >
>     >                uses igmp-snooping-statistics;
>     >              }
>     >            }
>     >
>     > Should the descriptions for received and sent be for "snooped IGMP
>     > packets"?
>     > The equivalent MLD structure probably also needs a similar fix.
>     >
>     >
>