Subject: [pim] RFC 4541 - 224.0.0.*

From: <[email-masked]>
Date: Tue, 30 Oct 2018 07:15:25 +0000

Hi,

Looking at RFC4541 and specifically the discussion 2.1.2 (2) on data forwarding rules. It says

"Packets with a destination IP (DIP) address in the 224.0.0.X range
      which are not IGMP must be forwarded on all ports."

As I see, there may not be explicit joins in this range and looking at IANA registry most protocols look chatty.

Are there any groups with silent listeners that use this range ?

regs
Ganesh

---

From: Stig Venaas <[email-masked]>
Date: Thu, 8 Nov 2018 00:27:42 -0800

Hi

The problem is that many stacks don't send IGMP reports for link-local
groups, making the assumption that only routers need to know about
membership, and link-local groups are not routed. Hence, you cannot
rely on IGMP to determine which ports have interested receivers.

Stig

On Sun, Nov 4, 2018 at 4:55 PM <[email-masked]> wrote:
>
> Hi,
>
>
>
> Looking at RFC4541 and specifically the discussion 2..1.2 (2) on data forwarding rules. It says
>
>
>
> “Packets with a destination IP (DIP) address in the 224.0.0.X range
>
>       which are not IGMP must be forwarded on all ports.”
>
>
>
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: <[email-masked]>
Date: Thu, 8 Nov 2018 08:40:39 +0000

Hi Stig,

I understand the point. My question is: when all protocols are chatty we theoretically can use an alternate mechanism to learn their existence and forward only to group members. For instance OSPF is chatty and OSPF PDUs can be forwarded only within OSPF routers by leveraging its chatty nature. But when we have passive listeners in a link-local group, there is no opportunity for the network to know about the existence of such receivers. 

Do we have passive receivers (or protocols) in this 224.0.0.* range ?

regs
Ganesh

-----Original Message-----
From: pim <[email-masked]> On Behalf Of Stig Venaas
Sent: Thursday, November 8, 2018 1:58 PM
To: ChennimalaiSankaran, Ganesh
Cc: [email-masked]
Subject: Re: [pim] RFC 4541 - 224.0.0.*

[EXTERNAL EMAIL] 
Please report any suspicious attachments, links, or requests for sensitive information.

Hi

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 8 Nov 2018 01:10:29 -0800

Hi

OK, I think I understand. Isn't it a problem if a protocol expects to
be able to receive before sending though? If you look at
https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml#multicast-addresses-1
you will see that there are quite a few different protocols, it is
difficult to say how all of them behave. Also, we don't know how
future protocols might behave.

Also, I hope you aren't assuming that a router/host that wants to
receive for a specific group, would be sending messages to the same
group address. There could be client-server link-local protocols that
don't work that way.

Stig

---

From: <[email-masked]>
Date: Thu, 8 Nov 2018 16:51:44 +0000

Hi Stig,

Going through the IANA registry, I see the below class of protocols 
1. bidirectional protocols such as OSPF, RIPv2 etc
2. protocols used to locate a service such as mDNS etc
3. reserved but usage not known

First two are chatty but as you said the response can be a unicast/multicast. Unfortunately, protocols under the third class does not have public documentation.

regs
Ganesh

-----Original Message-----
From: Stig Venaas <[email-masked]> 
Sent: Thursday, November 8, 2018 2:40 PM
To: ChennimalaiSankaran, Ganesh
Cc: [email-masked]
Subject: Re: [pim] RFC 4541 - 224.0.0.*

[EXTERNAL EMAIL] 

Hi

Stig

---

From: William Atwood <[email-masked]>
Date: Thu, 8 Nov 2018 15:32:41 -0500

Hi,

Three things:

1) The "reserved" numbers in the range 224.0.0.x are as yet unassigned.
No protocol should be using them.  In the future, IANA may be requested
to make a new assignment in this range; this will normally happen as the
result of the issuing of an RFC (describing, for example, a new
protocol).  So one has to assume the same properties in this range as
for all presently know (i.e., assigned) protocols.

2) NO protocol operating in the range 224.0.0.x need ever issue an
explicit join.  As you quote in your first message, other than IGMP, all
 switches MUST forward every packet received to every port on the
switch.  This is _precisely_ because there may be silent listeners on
that port.

3) Concerning IGMP and MLD, I suspect that if you look elsewhere, you
will find that IGMP v2 packets and MLD v1 packets must be forwarded in
the same way, but IGMP v3 and MLD v2 packets need not be.  (This is
because the latest versions of IGMP and MLD have different semantics
from the previous versions.)

  Bill

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: <[email-masked]>
Date: Fri, 9 Nov 2018 03:09:55 +0000

Hi Bill,

Trying to understand passive listeners from a protocol interaction point of view. Is there an example of (2) passive listener case from IANA assigned multicast groups in this range ?

PS: Thanks for correcting. Sorry, I actually meant "assigned" by "reserved" in my email. 

regs
Ganesh

-----Original Message-----
From: William Atwood <[email-masked]> 
Sent: Friday, November 9, 2018 2:03 AM
To: ChennimalaiSankaran, Ganesh
Cc: [email-masked]
Subject: Re: [pim] RFC 4541 - 224.0.0.*

[EXTERNAL EMAIL] 

Hi,

Three things:

  Bill

--

---

From: William Atwood <[email-masked]>
Date: Thu, 8 Nov 2018 22:52:33 -0500

Ganesh,

I am personally not aware of a specific example; my knowledge is
primarily based on work with IGMP/MLD.  However, I believe that worrying
about this is fruitless.  RFC 4541 _requires_ that all packets in this
range be flooded to all ports (except IGMP/MLD, for the reasons
explained below), so whether or not there is anyone listening is not
relevant.

That said, I can certainly see a newly-booted router (or host) wanting
(or needing) to "listen in" for a while (as part of a boot-up sequence);
the rule in RFC 4541 is there to make switched subnets look as much like
an original Ethernet as possible.

I could also see that a host might receive (and act on) an "All Systems
on this Subnet" packet without ever sending one itself.

Concerning "Assigned, but no documentation":  This means that you cannot
find out what the "system" (host/router) will do with the packet, or
whether it will ever send one prior to listening.  The rule in RFC 4541
is designed to make sure that this lack of knowledge does not matter.

I hope that this helps.

  Bill

--

---

From: Anish Peter <[email-masked]>
Date: Fri, 9 Nov 2018 11:57:46 +0530

Hi Ganesh,
 The one of the primary reason for using 224.0.0.x range is to do discovery
on the link-local scope. This discovery is many cases are required even
before multicast learning can happen.
 Hence the switch the ideal switch behavior is for flood them.
Thanks,
Anish

On Mon, Nov 5, 2018 at 6:25 AM <[email-masked]> wrote:

> As I see, there may not be explicit joins in this range and looking at
> IANA registry most protocols look chatty.
>
>
>

---

From: <[email-masked]>
Date: Fri, 9 Nov 2018 06:34:28 +0000

Hi Anish,

Thanks for explaining the rationale, I understand that.

For instance, there is MAC learning it is flooded the first time but after MAC is learnt, it is not flooded. Flooding every time is different from flooding the first time.

regs
Ganesh

From: Anish Peter <[email-masked]>
Sent: Friday, November 9, 2018 11:58 AM
To: ChennimalaiSankaran, Ganesh
Cc: [email-masked]
Subject: Re: [pim] RFC 4541 - 224.0.0.*

Hi Ganesh,
 The one of the primary reason for using 224.0.0.x range is to do discovery on the link-local scope. This discovery is many cases are required even before multicast learning can happen.
 Hence the switch the ideal switch behavior is for flood them.
Thanks,
Anish

On Mon, Nov 5, 2018 at 6:25 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

regs
Ganesh

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

---

From: Anish Peter <[email-masked]>
Date: Fri, 9 Nov 2018 14:16:02 +0530

Hi Ganesh,
 There would be many cases where this optimization could become
sub-optimal.
 For instance if a routers states are cleared (fully or partially), it may
need a mechanism to relearn. For which the switch/application now may be
forced to do additional logic.
 Another case if for two devices commented to different (TOR)switches. In
which case a link flap or device restart may not get propagated to the
second switch.
 In cases that we can imaging like this, this optimization would be
sub-optimal. An application that can handle such dynamics may use an
address range than 224.0.0.x.
 IGMP/MLD behavior is well known to switch so this group is an exception.
 Hope this helps.
Thanks,
Anish

On Fri, Nov 9, 2018 at 12:04 PM <[email-masked]> wrote:

> For instance, there is MAC learning it is flooded the first time but after
> MAC is learnt, it is not flooded. Flooding every time is different from
> flooding the first time.
>
>
>
> regs
>
> Ganesh
>
>
>
>
>
> *From:* Anish Peter <[email-masked]>
> *Sent:* Friday, November 9, 2018 11:58 AM
> *To:* ChennimalaiSankaran, Ganesh
> *Cc:* [email-masked]
> *Subject:* Re: [pim] RFC 4541 - 224.0.0.*
>
>
>
> Hi Ganesh,
>
>  The one of the primary reason for using 224.0.0.x range is to do
> discovery on the link-local scope. This discovery is many cases are
> required even before multicast learning can happen.
>