Re: [pim] Suresh Krishnan's No Objection on draft-ietf-pim-igmp-mld-yang-13: (with COMMENT)
Liuyisong <liuyisong@huawei.com> Tue, 11 June 2019 01:20 UTC
Return-Path: <liuyisong@huawei.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 EA29C1201E0 for <pim@ietfa.amsl.com>; Mon, 10 Jun 2019 18:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 IQvM0lbfJ2uU for <pim@ietfa.amsl.com>; Mon, 10 Jun 2019 18:20:42 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 90444120026 for <pim@ietf.org>; Mon, 10 Jun 2019 18:20:42 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6D71752E816B7AB19240; Tue, 11 Jun 2019 02:20:40 +0100 (IST)
Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 11 Jun 2019 02:20:39 +0100
Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 11 Jun 2019 02:20:39 +0100
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 11 Jun 2019 02:20:39 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Tue, 11 Jun 2019 09:20:30 +0800
From: Liuyisong <liuyisong@huawei.com>
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
CC: "pim@ietf.org" <pim@ietf.org>, Guofeng <guofeng@huawei.com>
Thread-Topic: Suresh Krishnan's No Objection on draft-ietf-pim-igmp-mld-yang-13: (with COMMENT)
Thread-Index: AQHVFmpyBUnGlEdgWkCnYmGWoBhWf6aDAB4AgAsClVCAAAc6oIACdGAAgAU4vbA=
Date: Tue, 11 Jun 2019 01:20:30 +0000
Message-ID: <D55792544C0AAD429ADA4746FE3504E08D7C38A2@NKGEML515-MBX.china.huawei.com>
References: <155916744586.5441.2052365244437409953.idtracker@ietfa.amsl.com> <CAEz6PPRNT3=9VD8thKtAjj4T1Psw83OPxQ=c3pD26vdNLmdcug@mail.gmail.com> <26C188D59156FB48A93A72ACF12DE0A5B2482373@DGGEMM527-MBX.china.huawei.com> <D55792544C0AAD429ADA4746FE3504E08D7C2F5C@NKGEML515-MBX.china.huawei.com> <CAEz6PPQC=yNVjNDiAcU51g3dAGk-12+Ecc6WBMRjE9LA3EQCbA@mail.gmail.com>
In-Reply-To: <CAEz6PPQC=yNVjNDiAcU51g3dAGk-12+Ecc6WBMRjE9LA3EQCbA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.172.168]
Content-Type: multipart/alternative; boundary="_000_D55792544C0AAD429ADA4746FE3504E08D7C38A2NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/owcyjJ3uaqRr4Z8q7u2nxMmQl7Y>
Subject: Re: [pim] Suresh Krishnan's No Objection on draft-ietf-pim-igmp-mld-yang-13: (with 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, 11 Jun 2019 01:20:50 -0000
Hi Xufeng I agree your comments except the point 3. I think the ssm-map feature is more commonly used for low-version protocol like IGMPv1,v2 and MLDv1 to be compatible with the multicast users, so we cannot restrict the ssm-map feature to only IGMPv3 and MLDv2. Thanks Yisong From: Xufeng Liu [mailto:xufeng.liu.ietf@gmail.com] Sent: Saturday, June 08, 2019 9:22 AM To: Liuyisong <liuyisong@huawei.com> Cc: pim@ietf.org; Guofeng <guofeng@huawei.com> Subject: Re: Suresh Krishnan's No Objection on draft-ietf-pim-igmp-mld-yang-13: (with COMMENT) Thank Yisong for providing the valuable information. Some of my comments are: 1. For operational states, we do not need to add constraints. As specified in RFC8342, semantic constraints MAY be violated in the <operational> datastore. The server implementations usually do not need to perform such validations. Moreover, these leaves are not mandatory, so the server does not need to return any values when the protocol version does not provide. Such nodes include the “leave” nodes under “statistics”, and the “source” sub-tree. 2. Based on RFC2236, the IGMPv2 spec requires the presence of the IP Router Alert option. Should the default value of “require-router-alert” be “true” for IGMPv2? 3. Should we restrict “ssm-map” sub-tree to IGMPv3/MLDv2 only? 4. We cannot avoid the “source-addr” in the “static-group” sub-tree because it is a key for the list, but we may add a description to indicate that (S,G) is only supported by IGMPv3/MLDv2. Additional proposal: As the discussions on Benjamin’s review comments, it is proposed to replace “exclude-lite” with “lite-exclude-filter". Thanks, - Xufeng On Thu, Jun 6, 2019 at 2:17 AM Liuyisong <liuyisong@huawei.com<mailto:liuyisong@huawei.com>> wrote: Hi I have gone through the parameters in IGMP & MLD yang model, and identified the differences of the parameters based on version. Thanks Yisong From: Xufeng Liu [mailto:xufeng.liu.ietf@gmail.com] Sent: Thursday, May 30, 2019 7:19 PM To: Suresh Krishnan <suresh@kaloom.com<mailto:suresh@kaloom.com>> Cc: The IESG <iesg@ietf.org<mailto:iesg@ietf.org>>; draft-ietf-pim-igmp-mld-yang@ietf.org<mailto:draft-ietf-pim-igmp-mld-yang@ietf.org>; Stig Venaas <stig@venaas.com<mailto:stig@venaas.com>>; Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>>; pim-chairs@ietf.org<mailto:pim-chairs@ietf.org>; pim@ietf.org<mailto:pim@ietf.org> Subject: Re: Suresh Krishnan's No Objection on draft-ietf-pim-igmp-mld-yang-13: (with COMMENT) Hi Suresh, Thanks for the review and comments. Some of the version check could be done in YANG, while the concern was the complexity added to the model, with a cost to the usability. The authors will examine these cases and address them using either approach as suggested. Maybe some of them use YANG and others use explanation descriptions. In the case of the explanation description, the system can do the validation at the backend and provide feedback. Thanks, - Xufeng On Wed, May 29, 2019 at 6:04 PM Suresh Krishnan via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote: Suresh Krishnan has entered the following ballot position for draft-ietf-pim-igmp-mld-yang-13: No Objection 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-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I do have a general concern with the document in relation to its handling of multiple protocol versions. There are features in the yang models that should be conditional but they do not seem to be. Here are some examples. * The source specific features are to be used with IGMPv3 and MLDv2 and will not work with the earlier versions * The router alert check is not optional for MLD or IGMPv3, but is required to be disabled for compatibility with earlier versions of IGMP. I would also make this feature conditional on the IGMP version. If not you need to rethink the defaults for this. I would like to understand the authors' views on how they plan to address the potential consistency issues due to these features being unbound in the model. I would be fine if it is either addressed with yang constructs or with some explanatory text to this point.
- [pim] Suresh Krishnan's No Objection on draft-iet… Suresh Krishnan via Datatracker
- Re: [pim] Suresh Krishnan's No Objection on draft… Xufeng Liu
- Re: [pim] Suresh Krishnan's No Objection on draft… Liuyisong
- Re: [pim] Suresh Krishnan's No Objection on draft… Xufeng Liu
- Re: [pim] Suresh Krishnan's No Objection on draft… Xufeng Liu
- Re: [pim] Suresh Krishnan's No Objection on draft… Liuyisong
- Re: [pim] Suresh Krishnan's No Objection on draft… Xufeng Liu