Re: [pim] Some explanations for you questions. Thanks! RE: [yang-doctors] Yangdoctors early review of draft-ietf-pim-igmp-mld-snooping-yang-03

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Fri, 06 July 2018 18:59 UTC

Return-Path: <rrahman@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 B59E3130E5E; Fri, 6 Jul 2018 11:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Ekks2lTMw37W; Fri, 6 Jul 2018 11:59:42 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89C312F1AB; Fri, 6 Jul 2018 11:59:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48950; q=dns/txt; s=iport; t=1530903581; x=1532113181; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ysAE8tHRay7w23dmJHoVjDDIfyqZgPBft93rXY5tMsQ=; b=KdJJYD2rxFzIJfcQfXGD5FvQKErSc6JVIk+mFGP/t6PKWM6ve/IJfVjM ba10yCzIvfrg6YOzhd7Mx7EA8T+eeWlUlUWjqn1yP4NWZ4gXw3wMx6EB8 hKz0Qhaa5X/8vyYZZXJQex5Ox1ptTin+xcm6OFgpAoHv5eh2Kq89zIx+r g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DFAADM+T5b/40NJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYJTdmJ/KAqDcIgEjDWBZSJ1h0GMehSBZgsYAQ4FhEACF4IWITQYAQIBAQIBAQJtHAyFNgEBAQEDAQEhSwsMBAIBBgIRAwEBASEBAgQDAgICHwYLFAkIAQEEDgWDIAGBG0wDFQ+NTZtIghyHFA2BLoE1BYhtgVY/gQ8nDIInBy6CVkIBAQIBAYEpARIBNgkWgksxggQgAodibIQEhRiHOisJAoYEhhGDC4FAhneFIYo1T4ZgAhETAYEkHThhcXAVOyoBgj4JgkOISIU+bwEBgROLdw0XB4EBAYEZAQE
X-IronPort-AV: E=Sophos;i="5.51,317,1526342400"; d="scan'208,217";a="138995690"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2018 18:59:40 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w66IxelH010134 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Jul 2018 18:59:40 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 6 Jul 2018 13:59:39 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Fri, 6 Jul 2018 13:59:39 -0500
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Hongji Zhao <hongji.zhao@ericsson.com>
CC: "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "draft-ietf-pim-igmp-mld-snooping-yang.all@ietf.org" <draft-ietf-pim-igmp-mld-snooping-yang.all@ietf.org>, "pim@ietf.org" <pim@ietf.org>, Xufeng Liu <xufeng.liu.ietf@gmail.com>, Liuyisong <liuyisong@huawei.com>, "draft-ietf-bess-l2vpn-yang@ietf.org" <draft-ietf-bess-l2vpn-yang@ietf.org>
Thread-Topic: Some explanations for you questions. Thanks! RE: [yang-doctors] Yangdoctors early review of draft-ietf-pim-igmp-mld-snooping-yang-03
Thread-Index: AdQSmgiw7+sLKQpBToWrB7kbECQiGQCydXYA
Date: Fri, 06 Jul 2018 18:59:39 +0000
Message-ID: <6D963C60-1999-4243-A49A-0F9F7D0A0DBE@cisco.com>
References: <VI1PR07MB4192036A5992A003E1A56C8596420@VI1PR07MB4192.eurprd07.prod.outlook.com>
In-Reply-To: <VI1PR07MB4192036A5992A003E1A56C8596420@VI1PR07MB4192.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.82]
Content-Type: multipart/alternative; boundary="_000_6D963C6019994243A49A0F9F7D0A0DBEciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/xwQnO2FnXblPput9qcz11DiG23E>
X-Mailman-Approved-At: Fri, 20 Jul 2018 08:19:14 -0700
Subject: Re: [pim] Some explanations for you questions. Thanks! RE: [yang-doctors] Yangdoctors early review of draft-ietf-pim-igmp-mld-snooping-yang-03
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 06 Jul 2018 18:59:46 -0000

Hi Hongji,

I agree that if you augment l2vpn-instance and BRIDGE, you’d need a grouping for igmp-snooping-instance. But I’m not sure what you mean by having the IGMP snooping model independent: IGMP snooping is used in BRIDGE or L2VPN context so there is an implicit dependency. If you do augment l2vpn-instance with a grouping, you’d still be able to augment that augmentation further in the future just by providing the correct path. And BTW there already ~15 groupings in the current IGMP/MLD snooping model….

I’ve added the authors of the L2VPN YANG model to get their thoughts.

Regards,
Reshad.

From: Hongji Zhao <hongji.zhao@ericsson.com>
Date: Tuesday, July 3, 2018 at 2:54 AM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "draft-ietf-pim-igmp-mld-snooping-yang.all@ietf.org" <draft-ietf-pim-igmp-mld-snooping-yang.all@ietf.org>, "pim@ietf.org" <pim@ietf.org>, Xufeng Liu <xufeng.liu.ietf@gmail.com>, Liuyisong <liuyisong@huawei.com>
Subject: Some explanations for you questions. Thanks! RE: [yang-doctors] Yangdoctors early review of draft-ietf-pim-igmp-mld-snooping-yang-03


Hi Reshad,



Below are the explanations for major issues.  Thank you very much!



1)            The YANG model has a new container+list for bridges and “l2vpn-instances”.  Why not augment l2vpn-instance (from draft-ietf-bess-l2vpn-yang)?

If all L2 features end up adding their own lists for “l2vpn-instances” this will be messy and there’ll be no easy way to look at all the configuration relevant to

an l2vpn-instance, it’ll have to be done feature by feature.

--------  There are 2 reasons for not augment l2vpn-instance

   a) If augment l2vpn-instance, the igmp-snooping-instances need to defined as grouping. This igmp snooping model will not be an independent model, and couldn't be augmented furtherly;

   b) If augment l2vpn-instance and BRIDGE, this draft will rely on l2vpn-instance and BRIDGE.





2)            If:interface is augmented and has the name of the l2vpn-instance. This config seems redundant since under l2vpn-instance (draft-ietf-bess-l2vpn-yang)

there is already an interface-ref for AC (Access Circuit). Why not augment the L2VPN endpoint or AC?

--------Augmenting if:interface in this model is used to configure static multicast router interface (static-mrouter-interface) and static l2 multicast forward table.

                    They are the concepts in IGMP/MLD Snooping. Augmenting if:interface could cover BRIDGE and L2VPN scenario at the same time.





3)            There doesn’t seem to be the capability to enable IGMP/MLD snooping on a subset of ACs or PW (i.e. not on the full l2vpn-instance)?

--------Generally IGMP/MLD Snooping is corresponding to l2vpn-instance. They are in the same level. AC or pw is lower than l2vpn-instance.





4)            I thought Bridge related YANG models belong to IEEE. But if we have to do the model for bridges in this draft, why not augment IEEE YANG models

e.g.  ieee802-dot1q-bridge.yang (same comment as for l2vpn-instance)?

--------It is similar as Question 1.

- Section 2.2, 2nd paragraph needs rewording. Explanation of how reference also not super clear (add reference to 2.4?) , e.g. what does an igmp-snooping-instance correspond to
(to me it seems to be more a profile than the instances we have with routing protocols)? And is 1 instance usable in multiple l2vpn or BRIDGE instances? I believe it’s for 1 instance?
 Anyway clarify that.
  ----------------There are config data and stata data in igmp-snooping-instance. So I think it is an instance. Generally there is no state data in profile.
                                                                  1 instance is usable in multiple l2vpn or BRIDGE instances, but we don't recommend.



BR/Hongji
赵宏吉


-----Original Message-----
From: Reshad Rahman (rrahman) <rrahman@cisco.com>
Sent: Friday, June 29, 2018 5:57 AM
To: draft-ietf-pim-igmp-mld-snooping-yang.all@ietf.org; pim@ietf.org
Cc: yang-doctors@ietf.org
Subject: Re: [yang-doctors] Yangdoctors early review of draft-ietf-pim-igmp-mld-snooping-yang-03



FYI, easier to read https://datatracker.ietf.org/doc/review-ietf-pim-igmp-mld-snooping-yang-03-yangdoctors-early-rahman-2018-06-28/ than the email below.



On 2018-06-28, 5:42 PM, "yang-doctors on behalf of Reshad Rahman" <yang-doctors-bounces@ietf.org on behalf of rrahman=40cisco.com@dmarc.ietf.org<mailto:yang-doctors-bounces@ietf.org%20on%20behalf%20of%20rrahman=40cisco.com@dmarc.ietf.org>> wrote:



    Reviewer: Reshad Rahman

    Review result: On the Right Track



    YANG Doctor review of draft-ietf-pim-igmp-mld-snooping-yang-03 (by Reshad

    Rahman)



    1 module defined in this draft:

    - ietf-igmp-mld-snooping@2018-05-03.yang<mailto:ietf-igmp-mld-snooping@2018-05-03.yang>



    No YANG validation errors or warnings (from yang and yanglint).



    1 example are provided in this draft.



    Major issues perceived:

        1)      The YANG model has a new container+list for bridges and

    “l2vpn-instances”.  Why not augment l2vpn-instance (from

    draft-ietf-bess-l2vpn-yang)? If all L2 features end up adding their own lists

    for “l2vpn-instances” this will be messy and there’ll be no easy way to look at

    all the configuration relevant to an l2vpn-instance, it’ll have to be done

    feature by feature. 2)      If:interface is augmented and has the name of the

    l2vpn-instance. This config seems redundant since under l2vpn-instance

    (draft-ietf-bess-l2vpn-yang) there is already an interface-ref for AC (Access

    Circuit). Why not augment the L2VPN endpoint or AC? 3)      There doesn’t seem

    to be the capability to enable IGMP/MLD snooping on a subset of ACs or PW (i.e.

    not on the full l2vpn-instance)? 4)      I thought Bridge related YANG models

    belong to IEEE. But if we have to do the model for bridges in this draft, why

    not augment IEEE YANG models e.g.  ieee802-dot1q-bridge.yang (same comment as

    for l2vpn-instance)?



    There might be good reasons to justify the way the YANG model has been done,

    but if that's the case IMO there needs to be text which justifies the design of

    the YANG model.



    If the authors haven’t done so already I would suggest discussing with authors

    of draft-ietf-bess-l2vpn-yang, IETF102 would be a good opportunity and I can

    attend a meeting if needed.



    I will have to re-review once the issues are addressed.



    Other comments/questions/nits:

    - General: needs spelling verification

    - General: indentation of YANG model has to be fixed, also some descriptions

    are too long and wrap. - Add NMDA in abstract (that's what most drafts now do)

    - Section 1.1, add space after in "in[RFC6020]" - There are references for

    L2VPN/EVPN YANG but none for bridges - Section 2, add reference for IGMP -

    Section 2.2, 2nd paragraph needs rewording. Explanation of how reference also

    not super clear (add reference to 2.4?) , e.g. what does an

    igmp-snooping-instance correspond to (to me it seems to be more a profile than

    the instances we have with routing protocols)? And is 1 instance usable in

    multiple l2vpn or BRIDGE instances? I believe it’s for 1 instance? Anyway

    clarify that. - Section 2.2, 4th paragraph, instead of “routing system” should

    this be “snooping device”? - Section 2.5 "This model augment", should be

    "augments". - YANG model: s/to configure the igmp snooping/to configure IGMP

    snooping/ - YANG model, having a feature for supporting admin-enable seems like

    overkill. My first impression was that that's a lot of features for this model,

    but I guess that's debatable. - YANG model s/fowarding/forwarding/ - YANG

    model, for the lookup modes (IP-based and MAC-based, add reference). I don’t

    think adding a vendor-specific CLI-example in the YANG description is a good

    idea. - YANG model, use yang-version 1.1 and add reference to import statements

    (as per 6087bis) - YANG model, if per-instance-config feature is not supported,

    how are the IGMP/MLD instances configured? - YANG model, vlan-index-type, use

    of range 4096… not very clear. And vlan-id shouldn’t be uint32, uint16 is

    enough. There’s also ieee:vlanid - YANG model, as opposed to using regular

    address type for group/multicast addresses, is there a type already defined for

    group addresses? If not there should be (V4 and V6) - YANG model,

    host-filter-mode, add reference - Appendix A, fix diagram





    _______________________________________________

    yang-doctors mailing list

    yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>

    https://www.ietf.org/mailman/listinfo/yang-doctors