Subject: [pim] Working group last call for draft-ietf-pim-igmp-mld-yang-05

From: Stig Venaas <[email-masked]>
Date: Tue, 3 Oct 2017 14:50:59 -0700

Hi

This is a working group last call for draft-ietf-pim-igmp-mld-yang-05.
In Prague we had 6 people in favor of going to working group last call
for this draft, and none against.

We have however been waiting for a new version that follows the new
NMDA routing models. This latest version now follows that model.

Please let us know whether you believe the draft is ready for
publication, or if you have any issues with this last revision. The
draft can be found at
https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-yang-05

This working group last call ends October 17th.

Stig

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 6 Oct 2017 14:46:23 +0900

Hi,

I have a couple of comments.

> https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-yang-05

There is one PS document, rfc5790, which is known as Lightweight-IGMPv3/MLDv2. LW-IGMPv3/MLDv2 duplicate the EXCLUDE mode operations and translate the EXCLUDE operations to INCLUDE operations. The authors may need to check rfc5790.

And also, routers may enable the explicit tracking function for IGMP/MLD. I don’t know whether some entries are needed for this function or should be defined for the yang model or not, but the authors may want to check.
(Note that we will revise the explicit tracking draft in the very near future, but please refer to the current (expired) I-D for the explicit tracking function to recognize its functionalities.)

Regards,

Hitoshi

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 12 Oct 2017 19:40:42 +0000

Hi Hitoshi,

Thanks for the comments. We have discussed them during our weekly design team meeting.

For rfc5790, do you know if there are existing implementations? Cisco seems to be the only company that has the implementation. If so, we usually would leave it for vendor augmentation. If there were several implementations, we would add it as a feature.

For the explicit tracking, it seems that at lease Cisco and Juniper have implemented. Huawei and Ericsson have not. We plan to add this as an optional feature to the model.

The modeling of these two modes should be simple, with one boolean leaf for each. Do you think that any more configuration knobs are needed?

Thanks,
- Xufeng

> -----Original Message-----
> From: Hitoshi Asaeda [mailto:[email-masked]]
> Sent: Friday, October 6, 2017 1:46 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [pim] Working group last call for draft-ietf-pim-igmp-mld-yang-05
> 
> Hi,
> 
> There is one PS document, rfc5790, which is known as Lightweight-
> IGMPv3/MLDv2. LW-IGMPv3/MLDv2 duplicate the EXCLUDE mode operations
> and translate the EXCLUDE operations to INCLUDE operations. The authors may
> need to check rfc5790.
> 
> And also, routers may enable the explicit tracking function for IGMP/MLD. I
> don’t know whether some entries are needed for this function or should be
> defined for the yang model or not, but the authors may want to check.
> (Note that we will revise the explicit tracking draft in the very near future, but
> please refer to the current (expired) I-D for the explicit tracking function to
> recognize its functionalities.)
> 
> Regards,
> 
> Hitoshi

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 13 Oct 2017 12:09:51 +0900

Hi,

> 2017/10/13 4:40, Xufeng Liu <[email-masked]> wrote:
> 
> Hi Hitoshi,
> 

It's an old implementation and not a vendor implementation, but there is one.
http://web.sfc.wide.ad.jp/~asaeda/LW-IGMPv3/index.html

And I vaguely remember that Huawei had the implementation, while I don’t know it is (or was) included in their commercial version.

My opinion is that since RFC5790 is the PS document and referred by several RFCs (*), it’s better to consider it as the supported protocol.
(*) http://www.arkko.com/tools/allstats/citations-rfc5790.html

> For the explicit tracking, it seems that at lease Cisco and Juniper have implemented. Huawei and Ericsson have not. We plan to add this as an optional feature to the model.

I don’t know the detail but I heard several operators such as Deutsche Telekom already support this function in their networks.

> The modeling of these two modes should be simple, with one boolean leaf for each. Do you think that any more configuration knobs are needed?

RFC5790 and the explicit tracking function do not declare any new values and uses the standard values defined by rfc3376 and rfc3810; therefore they could be with one boolean leaf I guess.

Regards,

Hitoshi

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 17 Oct 2017 14:04:28 +0000

Hi Hitoshi,

Thanks for the further information.
Personally I am fine to add RFC5790 to the model as a feature. I'd like to hear from others.
Thanks,
- Xufeng

> Sent: Thursday, October 12, 2017 11:10 PM
> To: Xufeng Liu <[email-masked]>
> Cc: [email-masked]; [email-masked]
> > For rfc5790, do you know if there are existing implementations? Cisco seems
> to be the only company that has the implementation. If so, we usually would
> leave it for vendor augmentation. If there were several implementations, we
> would add it as a feature.
> 
> And I vaguely remember that Huawei had the implementation, while I don’t
> know it is (or was) included in their commercial version.
> 
> My opinion is that since RFC5790 is the PS document and referred by several
> RFCs (*), it’s better to consider it as the supported protocol.
> > For the explicit tracking, it seems that at lease Cisco and Juniper have
> implemented. Huawei and Ericsson have not. We plan to add this as an optional
> feature to the model.
> 
> I don’t know the detail but I heard several operators such as Deutsche Telekom
> already support this function in their networks.
> 
> > The modeling of these two modes should be simple, with one boolean leaf for
> each. Do you think that any more configuration knobs are needed?
> 
> RFC5790 and the explicit tracking function do not declare any new values and
> uses the standard values defined by rfc3376 and rfc3810; therefore they could
> be with one boolean leaf I guess.
> 
> Regards,
> 
> Hitoshi
> 
> > Thanks,
> > - Xufeng
> >
> >>> In Prague we had 6 people in favor of going to working group last
> >>> call for this draft, and none against.
> >>>
> >> and translate the EXCLUDE operations to INCLUDE operations. The
> >> authors may need to check rfc5790.
> >>
> >> And also, routers may enable the explicit tracking function for
> >> IGMP/MLD. I don’t know whether some entries are needed for this
> >> function or should be defined for the yang model or not, but the authors may
> want to check.
> >> (Note that we will revise the explicit tracking draft in the very
> >> near future, but please refer to the current (expired) I-D for the
> >> explicit tracking function to recognize its functionalities.)
> >>
> >> Regards,
> >>
> >> Hitoshi
> >

---

From: Stig Venaas <[email-masked]>
Date: Sun, 22 Oct 2017 10:01:17 -0700

Hi

It would be great if could get some more responses to this WGLC. If
anyone thinks the draft is ready to be published, or have issues,
please let us know. I will also review the draft once more myself.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 26 Oct 2017 13:51:13 -0700

Hi

I had another look at the draft myself, and I only found a few nits.

I see you have listed earlier revisions in the module definition. I
wonder whether draft versions should be here, or if the published RFC
should be the initial version, no revisions. Thoughts?

Otherwise I just found a few typos.

There are 3 places where this description is missing a space.:

               membership.A device can restrict the length

Typo "or":
            "The maximum number of groups that IGMP ro MLD can join.";

Typo "entires":
          "Clears the specified MLD cache entires.";

Stig

---

From: Stig Venaas <[email-masked]>
Date: Fri, 27 Oct 2017 14:20:54 -0700

Hi

While we wish there were more responses to the WGLC, Mike and I
believe we have sufficient support to publish it. The design team has
done a lot of work on this and we have support at least from a handful
of authors and vendors, and there is no doubt that we need a YANG
model. The draft has also been through YANG doctor review. I will
request publication.

However, please review the draft if you haven't. if anyone has any
concerns or would like changes to the draft, there is still time. It
will also go to IETF last call. But please review and let us know ASAP
if anything.

Stig