Subject: [pim] Apply for WGLC about draft-ietf-pim-igmp-mld-snooping-yang

From: Hongji Zhao <[email-masked]>
Date: Tue, 18 Dec 2018 02:09:47 +0000

Hi Stig & Mike,

I have addressed all the YANG DOCTOR’s comments about draft-ietf-pim-igmp-mld-snooping-yang-05.  I also referred to the comments for draft-ietf-pim-igmp-mld-yang.

Now the latest version is  draft-ietf-pim-igmp-mld-snooping-yang-06.  Apply for WGLC here. Thanks a lot!

Message: 1

Date: Mon, 10 Dec 2018 19:00:52 -0800

From: [email-masked]<mailto:[email-masked]>

To: <[email-masked]<mailto:[email-masked]>>

Cc: [email-masked]<mailto:[email-masked]>

Subject: [pim] I-D Action:

                draft-ietf-pim-igmp-mld-snooping-yang-06.txt

Message-ID: <[email-masked]<mailto:[email-masked]>>

Content-Type: text/plain; charset="utf-8"

A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Protocols for IP Multicast WG of the IETF.

        Title           : A Yang Data Model for IGMP and MLD Snooping

        Authors         : Hongji Zhao

                          Xufeng Liu

                          Yisong Liu

                          Mahesh Sivakumar

                          Anish Peter

                Filename        : draft-ietf-pim-igmp-mld-snooping-yang-06.txt

                Pages           : 43

                Date            : 2018-12-10

Abstract:

   This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping devices. The YANG module in this document conforms to Network Management Datastore Architecture (NMDA).

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-snooping-yang/

BR/Hongji
赵宏吉

---

From: Mike McBride <[email-masked]>
Date: Wed, 19 Dec 2018 08:53:57 -0800

Excellent, thank you Hongji and team. We will hold off on this, and others,
wglc until after the new year. Lots of people on holiday.

mike

On Mon, Dec 17, 2018 at 6:10 PM Hongji Zhao <[email-masked]>
wrote:

> Hi Stig & Mike,
>
>
>
> I have addressed all the YANG DOCTOR’s comments about
> draft-ietf-pim-igmp-mld-snooping-yang-05.  I also referred to the comments
> for draft-ietf-pim-igmp-mld-yang.
>
> From: [email-masked]
>
> To: <[email-masked]>
>
> Cc: [email-masked]
>
> Message-ID: <[email-masked]>
>
>                 Filename        :
>    This document defines a YANG data model that can be used to configure
> and manage Internet Group Management Protocol (IGMP) and Multicast Listener
> Discovery (MLD) Snooping devices. The YANG module in this document conforms
> to Network Management Datastore Architecture (NMDA).
>
>
>
>
>
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 20 Dec 2018 11:57:23 +0100 (CET)

Hi,

Thanks for doing this work. I haven't looked at this model before, but I 
took a look now:

    leaf expire {
       type uint32;
       units seconds;
       mandatory true;
       description
         "The time left before multicast group timeout.";
     }

This means there is no "infinity" when it comes to this timeout. So for 
static configuration where no timeout exists, what should be reported 
here? I don't know if this is a practical problem, just something that 
came to mind.

Apart from that I spent 15 minutes to quick-read the document and nothing 
else jumped out to me... Thanks for including the appendix examples, makes 
it easier to understand.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Hongji Zhao <[email-masked]>
Date: Fri, 21 Dec 2018 02:15:50 +0000

Hi Mikael,

 The expire here is only for dynamic multicast group. As you say, the static configuration group won't be timeout.

 Thanks for your comments!

BR/Hongji
赵宏吉

-----Original Message-----
From: Mikael Abrahamsson <[email-masked]> 
Sent: Thursday, December 20, 2018 6:57 PM
To: Hongji Zhao <[email-masked]>
Cc: Stig Venaas <[email-masked]>; Michael McBride <[email-masked]>; [email-masked]
Subject: Re: [pim] Apply for WGLC about draft-ietf-pim-igmp-mld-snooping-yang

Hi,

Thanks for doing this work. I haven't looked at this model before, but I took a look now:

    leaf expire {
       type uint32;
       units seconds;
       mandatory true;
       description

This means there is no "infinity" when it comes to this timeout. So for static configuration where no timeout exists, what should be reported here? I don't know if this is a practical problem, just something that came to mind.

Apart from that I spent 15 minutes to quick-read the document and nothing else jumped out to me... Thanks for including the appendix examples, makes it easier to understand.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 21 Dec 2018 07:48:50 +0100 (CET)

> The expire here is only for dynamic multicast group. As you say, the static configuration group won't be timeout.

Since this is a "mandatory true;" leaf, what should go in here when it's a 
statically configured grop?

---

From: Hongji Zhao <[email-masked]>
Date: Fri, 21 Dec 2018 08:09:23 +0000

Hi Mikael,

 This is a "mandatory true", it means all the dynamic groups need expire. The group(who is read-only)  list only includes dynamic groups.
 I suppose it won't be a statically configured group.

 Do you think it should not be "mandatory true"?  OR the group (who is read-only) should include the statically configured group?

module: ietf-igmp-mld-snooping
  augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:
    +--rw igmp-snooping-instance {feature-igmp-snooping}?
    |  +--rw scenario?                            snooping-scenario-type
    |  +--rw enable?                              Boolean
   ...
   |  +--ro group* [address]
    |  |  +--ro address          rt-types:ipv4-multicast-group-address
    |  |  +--ro mac-address?     yang:phys-address
    |  |  +--ro expire           uint32
    |  |  +--ro up-time          uint32

BR/Hongji

-----Original Message-----
From: Mikael Abrahamsson <[email-masked]> 
Sent: Friday, December 21, 2018 2:49 PM
To: Hongji Zhao <[email-masked]>
Cc: Stig Venaas <[email-masked]>; Michael McBride <[email-masked]>; [email-masked]
Subject: RE: [pim] Apply for WGLC about draft-ietf-pim-igmp-mld-snooping-yang

> The expire here is only for dynamic multicast group. As you say, the static configuration group won't be timeout.

Since this is a "mandatory true;" leaf, what should go in here when it's a statically configured grop?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 21 Dec 2018 10:37:00 +0100 (CET)

> Do you think it should not be "mandatory true"?  OR the group (who is read-only) should include the statically configured group?

I believe operational data should show all groups currently being handled, 
regardless if they're statically configured or not. I want to be able to 
see other aspects of them, so it would be a bad idea if they were omitted 
from the list just because they're statically configured.

Minimum change could be to either remove the "mandatory true;" and say 
that groups without known expiry time doesn't report this value, or one 
could say that uint32 max value means "infinity". There could be other 
ways.

I have no strong opinion how to handle this, but I'd like to see it 
defined in the model how to handle statically configured groups with 
no defined expiry time.

---

From: Hongji Zhao <[email-masked]>
Date: Fri, 21 Dec 2018 09:46:09 +0000

Thanks for your comments. I will discuss with the team.

BR/Hongji
赵宏吉

-----Original Message-----
From: Mikael Abrahamsson <[email-masked]> 
Sent: Friday, December 21, 2018 5:37 PM
To: Hongji Zhao <[email-masked]>
Cc: Stig Venaas <[email-masked]>; Michael McBride <[email-masked]>; [email-masked]
Subject: RE: [pim] Apply for WGLC about draft-ietf-pim-igmp-mld-snooping-yang

> Do you think it should not be "mandatory true"?  OR the group (who is read-only) should include the statically configured group?

I believe operational data should show all groups currently being handled, regardless if they're statically configured or not. I want to be able to see other aspects of them, so it would be a bad idea if they were omitted from the list just because they're statically configured.

Minimum change could be to either remove the "mandatory true;" and say that groups without known expiry time doesn't report this value, or one could say that uint32 max value means "infinity". There could be other ways.

I have no strong opinion how to handle this, but I'd like to see it defined in the model how to handle statically configured groups with no defined expiry time.