Subject: Re: [pim] agenda requests for Montreal

From: Toerless Eckert <[email-masked]>
Date: Mon, 2 Jul 2018 23:54:32 +0200

WOuld like to ask for a "new new draft currently" to discuss
interest and process to evolve standards status of IGMP/MLD

   a)  downgrade IGMPv1/IGMPv2/MLDv1 to something worse than IGMPv3/MLDv2/IGMP-MLD-lite
      - goal is to do everything we can do to discourage utilization of old protocols
        in new products.

   b) Raising standards track level of IGMPv3/MLDv2/IGMP-MLD-lite

   c) documenting/mitigating ? Risk in deployments upgrading.

I for once have really no clue on what the process for a), b) is and what
our options are, so i hope we'll have a friendly AD or more senior IETF
pprocess aware folks who could help figuring ou the best option quickly.

Wrt to c): After raising a) on the list i talkd to a customer who was
worried about a) happening because of i think a range of issues: 

  a) misunderstanding how IGMPv3/MLDv2 are fully backward compatible
     with IGMPv2 / MLDv1 functionality and also fully support ASM.

  b) In any text we may produce about downgrading older IGMP/MLD<
     it needs to be very clear that this implies NO change to the
     status of ASM (and the separate work we are doing to change the status
     of ASM will only downgrade interdomain ASM).
     
  c) In the specific deplyment, intradomain ASM is used wih Bidir-PIM,
     and to the best of my knowledge, the interaction between Bidir-PIM and
     IGMPv3/MLDv2 is not well specified, but IMHO its also not really well
     specified for PIM-SM. 

Let me know. 10 mins or so ?
     
Cheers
    Toerless

(*): If you prefer me to have slides highlighting 

In-Reply-To: <[email-masked]>

On Fri, Jun 29, 2018 at 11:13:48PM +0000, Michael McBride wrote:
> If you haven't yet requested time to present in Montreal please do so. We are meeting back to back, same room, with mboned but not sharing the same timeslot since we were way to rushed last time. Grab a cookie then come to pim. Here are the time slots:
> 
> TUESDAY, July 17, 2018
> 
> 1330-1530  Afternoon Session I
> Notre Dame      	OPS 	mboned      	MBONE Deployment WG
> 
> 1530-1550  Beverage and Snack Break - Convention Floor Foyer
> 
> 1550-1820  Afternoon Session II
> Notre Dame      	RTG 	pim         	Protocols for IP Multicast WG
> 
> We will send an agenda out in another week.
> 
> Thanks,
> mike
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

-- 
---
[email-masked]

---

From: Stig Venaas <[email-masked]>
Date: Mon, 2 Jul 2018 15:04:09 -0700

Hi

I think this is a good topic and should hopefully be an interesting
discussion. It would be good to see if people agree that deployments
should use IGMPv3/MLDv2, and to what extent and how strongly we should
discourage the older versions. I also would like to see if there is
interest in advancing IGMPv3/MLDv2 on the standards track. This may
require us to find volunteers (Toerless and others) to work on related
drafts.

Perhaps you should consider a slot in mboned as well, as this has a
lot to do with deployment?

Stig

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 3 Jul 2018 00:15:07 +0200

Hah, PIM and MBoned have parted ways in IETF102 i see, so
yes, i will ask for a slot primarily to make MBoned aware of this
(as PIM is after MBoned) and focussing on the aspects
where such official changes would incur operational challenges.

Cheers
    Toerless

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 3 Jul 2018 15:00:53 +0900

Hi Toerless,

Thanks for raising this discussion.

I have a few questions/comments.

>     with IGMPv2 / MLDv1 functionality and also fully support ASM.

IGMPv3/MLDv2 fully support ASM with an EXCLUDE (*,G) mode operation, no?

This may not be the intended discussion, but the EXCLUDE mode operation is the concern.

In IGMPv3/MLDv2, once a member subscribes a multicast channel with EXCLUDE mode, the upstream router's filter-mode for the group will be set to EXCLUDE, which requires switching to the shared tree. This means an EXCLUDE mode operation easily stops the SSM communication.
Of course, EXCLUDE (*,G) join whose multicast addresses are within the SSM address range should be discarded by applications/kernels/routers. However, it is an operational solution. If applications use other multicast address range such as GLOP or something, the problem can appear again.
(I don't remember what happens if a user invokes EXCLUDE (S,G) join whose multicast address is within the SSM address range..)

Moreover, the EXCLUDE mode operation is almost meaningless as practical applications do not use EXCLUDE mode to block sources very often; a user or application usually wants to specify desired source addresses, not undesired source addresses. Nevertheless, kernel implementations to support EXCLUDE filter-mode as well as INCLUDE filter-mode are complex enough.

I don't know what direction this discussion will lead to, but if it aims to revisit IGMP/MLD protocol standardization, I support to get rid of EXCLUDE mode operations for the regular multicast *applications* (except for control messages invoking (*,G) such as ND and other discovery protocols on a LAN).
RFC5790 (Lightweight-IGMPv3/MLDv2) would be a good start.

>   b) Raising standards track level of IGMPv3/MLDv2/IGMP-MLD-lite

I don't think this IGMP-MLD-lite means RFC5790, but is it almost same or very similar to LW-IGMPv3/LW-MLDv2?

Regards,

Hitoshi

> On 2018/07/03, at 6:54, Toerless Eckert <[email-masked]> wrote:
>

---

From: Stig Venaas <[email-masked]>
Date: Tue, 3 Jul 2018 09:47:23 -0700

Hi

> (I don't remember what happens if a user invokes EXCLUDE (S,G) join whose multicast address is within the SSM address range..)

It would be sufficient to configure the correct SSM range on the
routers I believe (and potentially switches).
It seems reasonable to ignore exclude (S,G) in the SSM range, but I
haven't thought much about it and
4607 is not very clear. IGMPv3/MLDv2 specifications do not have text
related to this. I guess we could
discuss if they should.

> I don't think this IGMP-MLD-lite means RFC5790, but is it almost same or very similar to LW-IGMPv3/LW-MLDv2?

There are at least a few people using exclude filter mode, but it is
certainly uncommon. I'm wondering what the
WG thinks of supporting it when progressing them. We would at least
require multiple interoperable
implementations, which I think we have. As part of progressing them we
would probably do a survey.

I'm hoping for a good discussion here on the list. This is also a
great topic for our WG meeting. It would probably
be good in mboned to discuss operational aspects like configuring the
appropriate SSM range and the need for
exclude filter mode support.

Stig

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 4 Jul 2018 17:58:40 +0900

Hi Stig,

> routers I believe (and potentially switches).

You cannot configure overlapped address range, e.g., SSM range within administrative boundary. Conceptually (E)GLOP does not need to coexist with SSM, but it can't.

> related to this. I guess we could

I agree.

> WG thinks of supporting it when progressing them.

Oh, I didn't know that exclude filter-mode is used in some situations.
According to the current specifications, if exclude filter-mode must be supported in inter-domain multicast services, ASM must be also supported in inter-domains.

> We would at least

The current backward compatibility is also a problem. 
For example, whenever an IGMPv2 General Query is received on an interface, the Host Compatibility Mode of that interface is set to IGMPv2 and its IGMPv2 Querier Present timer is set to Older Version Querier Present Timeout seconds. The router acts as IGMPv2 router for that interface until its timer expires. It's easy to stop SSM.

> exclude filter mode support.

Agreed.

Regards,

Hitoshi

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Wed, 4 Jul 2018 12:56:20 +0000

Hi Hitoshi ,

On Jul 4, 2018, at 1:58 AM, Hitoshi Asaeda <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stig,

I agree.

We would at least

But Do we not need to account the fact that network might really have IGMPv2 Querier present, and we need to act on it. So would it not be network admin to make sure Querier are configured with correct version if there is need to operate in SSM mode ?

Agreed.

Regards,

Hitoshi

Stig

Regards,

Hitoshi

On 2018/07/03, at 6:54, Toerless Eckert <[email-masked]<mailto:[email-masked]>> wrote:

Cheers
 Toerless

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

TUESDAY, July 17, 2018

Thanks,
mike

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pim

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

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pim

_______________________________________________
pim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pim

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 5 Jul 2018 14:37:57 +0900

Mankamana,

> On 2018/07/04, at 21:56, Mankamana Mishra (mankamis) <[email-masked]> wrote:
> 
> Hi Hitoshi ,
> 
> 
>> On Jul 4, 2018, at 1:58 AM, Hitoshi Asaeda <[email-masked]> wrote:
>> 
>> Hi Stig,
>> 

According to the current specifications, even if (or precisely because) you configure the querier to speak IGMPv3, the querier works as v2 querier when it receives a v2 report. And it stops SSM for the requested multicast address.
Of course, we need to legitimately support IGMPv2 members in various situations. That's why this backward compatibility was specified. The problem is that RFC3376 and 3810 do not explicitly consider the way to ease the unexpected situation, which is a type of DoS. 
RFC5790 says that routers should be able to configure to disable the backward compatibility. I don't know what is the best solution for this problem at this moment, but defining such configuration option is one of the choice.

Regards,

Hitoshi