Re: [pim] Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-snooping-yang-17: (with DISCUSS and COMMENT)
Hongji Zhao <hongji.zhao@ericsson.com> Wed, 15 July 2020 03:47 UTC
Return-Path: <hongji.zhao@ericsson.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 4FC9A3A0E31; Tue, 14 Jul 2020 20:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 OgCbq45FQkFM; Tue, 14 Jul 2020 20:47:32 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2069.outbound.protection.outlook.com [40.107.22.69]) (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 0DCBC3A0E36; Tue, 14 Jul 2020 20:47:31 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YNU3IqJALf3F33sYmDU55V73kUbct7bj6J1xkyH3N51FGBfoXqOeOG2DLwYvLLByXB/qeHpTLyhGHgns6hkYRTNkajnPRzk3FXF4xWeGzDWbqyzzLCy/kfkvrp2p9aojcOTlOwg/VRqLWdRlCTeZPacS6DJjMjMV0nDbKcJWOWmmsGsaaaV9yKAbWXrZkauYJD4zGpnMGBWUiZNXmicZzU2pyj5vauQQB8kf1Q1F7Wm+SWN1AV1axkvw9EqPTPAG3uub/evWF1cbWLG62vE6IPjtPPB3Sqj2Hmc0i3usVrbPr/f0faBABZmxZC6Xy12jPB9Xjqx4kopRlFnjCCmeSQ==
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=WEhGKkMw2xja3nH6spo8rPZ4MTsaPU7grkO6Krc+szg=; b=AJA0OWVaqrGrDtnUQXF46ikBHow6I9U82RFuNHucllNLVDudqLrL6d9sDyfii0nKlmV85d6itIn1hBPgy3E69DE+xXU2dsmUyQFuJUwHONYDtcYCd0L09qupxGTTGSXVF32iA7a43Gr5ikB9+cO8OHrZlfK6uM1VPr8hDF4tCFn91cJ96OsdhKWDBUifLFjfNRodg3c8gVba8wwhZRZjqRQyBIsKklKvJEjBz6zhwZMTVkIfD02iHVExVlATw2wNrn9LHmOZ+xlQFf0BTa9kCA/ZPfBG4UKRCcicVYV5jyyNvEM7TAA5e5TBrTmn90zN3XyDwHGW+AyxNL7jB3BSNw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WEhGKkMw2xja3nH6spo8rPZ4MTsaPU7grkO6Krc+szg=; b=EF7dqDXHsKJK9fVxXT4AkrdWHB7QoiNpSb8js1n6PO0D847AtJm0Yb9z6NcNITqAagu2WeEI6mYg4a01R3uAPPMCPdl1G2PFxdBkxafiQ3TJKxKRTp2fHsYmPJSgBxPK0t7cIhJa0SuZUGtrFDRhlCT1Ri/Xo6iXagzBw9icXEE=
Received: from HE1PR0701MB2492.eurprd07.prod.outlook.com (2603:10a6:3:71::22) by HE1PR0702MB3803.eurprd07.prod.outlook.com (2603:10a6:7:84::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.11; Wed, 15 Jul 2020 03:47:29 +0000
Received: from HE1PR0701MB2492.eurprd07.prod.outlook.com ([fe80::ec82:bf39:2810:fbb0]) by HE1PR0701MB2492.eurprd07.prod.outlook.com ([fe80::ec82:bf39:2810:fbb0%7]) with mapi id 15.20.3195.018; Wed, 15 Jul 2020 03:47:29 +0000
From: Hongji Zhao <hongji.zhao@ericsson.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, The IESG <iesg@ietf.org>
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>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-snooping-yang-17: (with DISCUSS and COMMENT)
Thread-Index: AQHWVdcXmlpukUvGqE2bmmz/z85+SqkGcErggABdioCAAEuigP//5MqAgAEK7jA=
Date: Wed, 15 Jul 2020 03:47:29 +0000
Message-ID: <HE1PR0701MB249250BD7D8FCBE0DD101BE0967E0@HE1PR0701MB2492.eurprd07.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> <MN2PR11MB43666D4D3FBB12BD1F618254B5610@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB43666D4D3FBB12BD1F618254B5610@MN2PR11MB4366.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [119.28.22.196]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2276804d-e850-4d5d-4ef0-08d82871cc3e
x-ms-traffictypediagnostic: HE1PR0702MB3803:
x-microsoft-antispam-prvs: <HE1PR0702MB3803A8B0704F1EE1CA04672D967E0@HE1PR0702MB3803.eurprd07.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: GUEp1DNdlCYlvKeE6PuTaSPDStnit/k0qKRVknG3n427v1Z/fX7f/hMbHJGxvuFisYKsCZxE7XzymW6Ie3NrJ8kmpyWN7Alkrlotiu0xuLEBXAV8sylS1mHTOVQgjkbQyTXvkfum22XDRqWPfPmxONJWCkQAoWZquYWSum6xKOpm5bOB/z3zlelOZY1TB3CCbM/bUiiwZBR4yW8JtdU7Ar30+rPLmubAaMYxO2X3a7E5nx2Nequv/KQ4VxEpax6t89T8DX2SMoeU6UIkUUMeEnX7DjlXOPW5oO5wSMzpxYgztjraj14R0bslTyKmEhqzzVX9/u74yB6F2+wvmdydIFxXNaop+4VA+kbUiuCl7avP25DVeJlBHe5PseSXNqO1qp+2mDVWheIj+f7guye8yQlkc8mvBiwPPnqHBHI2AkRrLAPe0bwPLin0+Tn8A27+KVDuTpU1NB2s9muM2sxHLw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2492.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(346002)(39860400002)(136003)(366004)(26005)(6506007)(53546011)(33656002)(316002)(9686003)(7696005)(110136005)(55016002)(54906003)(186003)(30864003)(52536014)(66946007)(66476007)(5660300002)(66556008)(66446008)(64756008)(76116006)(86362001)(71200400001)(44832011)(478600001)(966005)(83380400001)(66574015)(4326008)(2906002)(8676002)(8936002)(21314003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: BacFBldzK9Xf0RrhEZ3OLJMVajrkF5RqiZLuE3vSMlE7vJajsoqf+fax7QRUHE+old+UNHEpiyodefhP5XssZpOyO1AkoYpLfYyaYUTJkgbx1QsIfBraZftLFtvWz+7OVWSKTv1cV2D+mQMlQyKGvD1Np/RFW0sEEElP66pIwYEvKt7twE5fX7N1wi/y4BshfkU6a2PZu4etmcDC1bRTAHeNLswYPOKzd+Y0pIieCF39wGFCJqJMyvwaO/Altkw4KF4EfJQ5L1x1xpBpoyFhv0DxB7/ztsaUmlYUnKUxAqTTRMO3JfI+mm+B2NujoOsWkZ2u51z4FY65i7s5rkSML1p7E1WM/nAHOqszNTQ3GLdErMKHT6as3pr75Luof9yK3pQUsKBLg8pmll3YgKeaNEQaLmRSQ4O+uqq9EDhrtzRk8gaxPs2JlXt41rsoVngIdMZ+bLdhp5C7vcRB1WIWBjXV9J1uUaTyqHJGqQM0VmI=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2492.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2276804d-e850-4d5d-4ef0-08d82871cc3e
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2020 03:47:29.1588 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OSkY66oPC6T6W72TgPmiG4wvdEsArLpr2pR/DPi4brgPWMJhzNJABc43nfqjPny3YYkaaygKF7FFI/3IFA8EM0y4I59RMw8Zm7AI5ApGDOs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3803
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/PiqxsFL3N2BJ2B1DbiG6xGYAUrI>
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: Wed, 15 Jul 2020 03:47:35 -0000
Hi Rob & Eric, Authors will hold a meeting to discuss your suggestions. Thanks a lot for your comments. BR/Hongji -----Original Message----- From: Rob Wilton (rwilton) <rwilton@cisco.com> Sent: Tuesday, July 14, 2020 7:50 PM 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 Cc: Stig Venaas <stig@venaas.com>; 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) 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>; Hongji Zhao > <hongji.zhao@ericsson.com>; The IESG <iesg@ietf.org>; > aretana.ietf@gmail.com > Cc: Stig Venaas <stig@venaas.com>; 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>, 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> > 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>; 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>; 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>; 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. > > > > >
- [pim] Robert Wilton's Discuss on draft-ietf-pim-i… Robert Wilton via Datatracker
- Re: [pim] Robert Wilton's Discuss on draft-ietf-p… Hongji Zhao
- Re: [pim] Robert Wilton's Discuss on draft-ietf-p… Rob Wilton (rwilton)
- Re: [pim] Robert Wilton's Discuss on draft-ietf-p… Eric Vyncke (evyncke)
- Re: [pim] Robert Wilton's Discuss on draft-ietf-p… Rob Wilton (rwilton)
- Re: [pim] Robert Wilton's Discuss on draft-ietf-p… Alvaro Retana
- Re: [pim] Robert Wilton's Discuss on draft-ietf-p… Hongji Zhao
- Re: [pim] Robert Wilton's Discuss on draft-ietf-p… Hongji Zhao
- Re: [pim] Robert Wilton's Discuss on draft-ietf-p… Rob Wilton (rwilton)
- Re: [pim] Robert Wilton's Discuss on draft-ietf-p… Hongji Zhao
- Re: [pim] Robert Wilton's Discuss on draft-ietf-p… Hongji Zhao