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

[Hongji Zhao <[e-mail]>]

Hi Robert

Regarding your comments, please check inline. Thanks a lot!


----------------------------------------------------------------------
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?
[Authors] The penultimate sentence is to explain the relationship between igmp and igmp snooping. The last sentence is to explain where igmp snooping is from.

    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 paradigms" or "L2 forwarding instances".
If this terminology is changed then it would need to be fixed elsewhere in this document and the YANG model.
[Authors] What about use l2-service-type instead of scenario?

    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.
[Authors] yes you are right, do we need to do any changes?


    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.
[Authors] The scenario is a leaf in yang module, we would like to add quotation marks and reword as below, is it ok?
The value of the leaf "scenario" in igmp-snooping-instance ...


    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.
[Authors] Static interfaces are different from dynamical interfaces.  An interface can be either static or dynamical, but not both. Static interfaces need configured, so they have configuration and operational states.
Dynamic interfaces are learnt by the system. They are not configured, but they have the operational state.



BR/Hongji


From: Rob Wilton (rwilton) <[e-mail]>
Sent: Tuesday, July 21, 2020 4:38 PM
To: Hongji Zhao <hongji.zhao=[e-mail]>
Cc: Stig Venaas <[e-mail]>; [e-mail]; Alvaro Retana <[e-mail]>; The IESG <[e-mail]>; Eric Vyncke (evyncke) <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: Robert Wilton's Discuss on draft-ietf-pim-igmp-mld-snooping-yang-17: (with DISCUSS and COMMENT)

Hi Hongji,

That is fine.  Thank you for considering/discussing the options.  I have cleared my discuss.

Regards,
Rob