Subject: [pim] Need clarification on treatment of IGMPv3 reports in ASM (non-SSM) range

From: Sunil Shah <[email-masked]>
Date: Wed, 28 Apr 2010 20:02:43 -0400

Hi,

I have been wondering about the behavior of a router when it receives a IGMPv3 Report in ASM range (i.e. non-SSM range).

Shouldn't the router skip any SSM semantic for membership reports in the ASM range (whether it is an IGMPv2 report or an IGMPv3 report)?
If the Group is not in SSM range, then that would mean, either:
a) The host is misconfigured, and is sending IGMPv3 reports in ASM range.
b) The router is not configured with the correct SSM range. The network admin needs to fix this.

RFC5186
But, from referring to the Informational RFC: http://tools.ietf.org/html/rfc5186, it says something else.

"6.1 PIM-SM join messages are initiated when a PIM-SM router determines that there are entities interested in a specific group or a specific source sending to the group. If this is due to an IGMPv3 or MLDv2 report with a zero-length EXCLUDE list, then the join is sent as a (*,G) join towards the RP.
If the join is triggered by an IGMPv3 or MLDv2 state change that affects source information, the PIM-SM join is sent as a (S,G) join towards the specific source.
This behavior optimizes the join process, as well as facilitates the adoption of the SSM model."

>From this passage, it looks like they are suggesting a Last-Hop-Router should initiate a (S, G) JOIN toward Source regardless of whether the Group address in IGMPv3 reports is in ASM or SSM range.

Cisco's documentation
Found this link on the web: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtmcxacl.html#wp1052303<http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtmcxacl.html>
Refer to "Source Addresses in IGMPv3 Reports for ASM Groups"
>From this, looks like Cisco simply ignores any of the Sources in the IGMPv3 message, and treats it like a regular (*, G) from a IP Routing point of view.

Juniper's documentation
Found this link on the web: https://www.juniper.net/techpubs/en_US/junos/topics/reference/command-summary/show-igmp-statistics.html
They have a counter under Rx errors for IGMP v3 mode not applicable for SSM.
Number of IGMP version 3 messages received that did not contain a mode applicable for source-specific multicast (SSM).

I have looked at RFCs 4601 (PIM-SM Spec), 4604 (IGMPv3 and SSM) and 4607 (PIM-SSM), but could not find the behavior defined explicitly.
It is quite possible, I may have missed something. Could someone point me to the appropriate documentation in the "Standards Track" or elsewhere that describes this behavior?

Thanks,
-Sunil

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 28 Apr 2010 23:10:52 -0400

On Apr 28, 2010, at 8:02 PM, Sunil Shah wrote:

> Found this link on the web: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtmcxacl.html#wp1052303

There is nothing SSM specific about IGMPv3. It was invented prior to the definition of SSM for the purpose of pruning back mis-behaving ASM sources. Please see RFC 3376.

Tom

---

From: Sunil Shah <[email-masked]>
Date: Thu, 29 Apr 2010 02:51:08 -0400

Thanks Tom for the historical perspective. It is very helpful.

So, since IGMPv3 has nothing to do with PIM SSM, its role seems to be that of providing a "filtering" capability.

Coming back to my original query - 
- So, if a PIM router receives a IGMPv3 Report in ASM range (non-SSM), that would imply, the PIM router needs to send a (*, G) JOIN toward the RP. 
- And then allow only that traffic to flow towards its IGMP Receivers if the Source is one that was in the v3 Reports INCLUDE mode (or EXCLUDE none). Right?

Thanks,
-Sunil

-----Original Message-----
From: Tom Pusateri [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2010 8:11 PM
To: Sunil Shah
Cc: [email-masked]
Subject: Re: [pim] Need clarification on treatment of IGMPv3 reports in ASM (non-SSM) range

On Apr 28, 2010, at 8:02 PM, Sunil Shah wrote:

> Found this link on the web: 
> http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtmcxac
> l.html#wp1052303 Refer to "Source Addresses in IGMPv3 Reports for ASM 
> Groups"
> Found this link on the web: 
> https://www.juniper.net/techpubs/en_US/junos/topics/reference/command-
> summary/show-igmp-statistics.html They have a counter under Rx errors 
> for IGMP v3 mode not applicable for SSM.

Tom

---

From: Everton Marques <[email-masked]>
Date: Thu, 29 Apr 2010 10:04:40 -0300

RFC 3376 tells how the IGMP router state should
change upon reception of every type of IGMPv3 record
(from an IGMPv3 report), and what actions it should take.
See: RFC 3376 6.4. Action on Reception of Reports

That router IGMP state can be used to define the
"local membership" state needed by PIM mechanisms.

RFC 4601 tells how changes in "local membership"
state should affect the PIM states, and which
actions should result.
See: RFC 4601 local_receiver_ macros

Everton

On Thu, Apr 29, 2010 at 3:51 AM, Sunil Shah <[email-masked]> wrote:

> - So, if a PIM router receives a IGMPv3 Report in ASM range (non-SSM), that
> would imply, the PIM router needs to send a (*, G) JOIN toward the RP.
> - And then allow only that traffic to flow towards its IGMP Receivers if
> the Source is one that was in the v3 Reports INCLUDE mode (or EXCLUDE none).
> Right?
>
> Thanks,
> -Sunil
>
> > I have been wondering about the behavior of a router when it receives a
> IGMPv3 Report in ASM range (i.e. non-SSM range).
> >
> > Shouldn't the router skip any SSM semantic for membership reports in the
> ASM range (whether it is an IGMPv2 report or an IGMPv3 report)?
> > But, from referring to the Informational RFC:
> http://tools.ietf.org/html/rfc5186, it says something else.
> >
> > "6.1 PIM-SM join messages are initiated when a PIM-SM router determines
> that there are entities interested in a specific group or a specific source
> sending to the group. If this is due to an IGMPv3 or MLDv2 report with a
> zero-length EXCLUDE list, then the join is sent as a (*,G) join towards the
> RP.
> > If the join is triggered by an IGMPv3 or MLDv2 state change that affects
> source information, the PIM-SM join is sent as a (S,G) join towards the
> specific source.
> > From this passage, it looks like they are suggesting a Last-Hop-Router
> should initiate a (S, G) JOIN toward Source regardless of whether the Group
> address in IGMPv3 reports is in ASM or SSM range.
> >
> > Cisco's documentation
> > From this, looks like Cisco simply ignores any of the Sources in the
> IGMPv3 message, and treats it like a regular (*, G) from a IP Routing point
> of view.
> > Juniper's documentation
> > Number of IGMP version 3 messages received that did not contain a mode
> applicable for source-specific multicast (SSM).
> >
> >
> > I have looked at RFCs 4601 (PIM-SM Spec), 4604 (IGMPv3 and SSM) and 4607
> (PIM-SSM), but could not find the behavior defined explicitly.
> > It is quite possible, I may have missed something. Could someone point me
> to the appropriate documentation in the "Standards Track" or elsewhere that
> describes this behavior?
> >
> >
> > Thanks,
> > -Sunil
>
> There is nothing SSM specific about IGMPv3. It was invented prior to the
> definition of SSM for the purpose of pruning back mis-behaving ASM sources.
> Please see RFC 3376.
>
> Tom
>
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 29 Apr 2010 08:32:15 -0700

As explained by other posters, 4601 does allow for implementation policies
here. The two most relevant ones for PIM-SM are IMHO

a) expand INCLUDE({S},G) for PIM to be interpreted like a group join
b) tread INCLUDE({S},G) as a PIM (S,G) join.

I was mostly promoting b) for SSM groups and a) for PIM-SM groups
because i always felt that

  I)  Having to worry about PIM-SM groups where clients can either
      join groups via RPT or (S,G) directly via include membership
      reprts makes it become a more complex model than PIM-SM already
      is (with IGMPv2) and would lead to more inconsistent tree building
      betwen those type of clients. (ANd i don't even want to think about
      EXCLUDE({S},G) to create PIM (S,G, RPbit) prunes ;-))

  II) Customers have liked the lightweight/best-effort centralized
      version of source-access-control possible in PIM-SM where the RP sends
      back a register stop for sources who should not send to the group.
      Choosing option b) would inhibit that type of access control
      and/or break it if already deployed.

Aka: If you can and want to send (S,G) memberships from an application,
please use SSM - that's my recommendation.

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
"The strategy is what you do, not what you write" - Wesley Clark
"Vision without ressources is hallucination" - James L. Jones

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 29 Apr 2010 12:56:31 -0700

Sunil,

I think 6.1 in RFC5186 covers this correctly.  Send a (*,G) if 
include/exclude is null (otherwise ASM would be broken for IGMPv3), and 
send an (S,G) if the IGMPv3 message includes a source.  

This can actually be somewhat useful for someone who desires SSM-like 
behavior, but is willing to live with ASM for receivers that don't support 
IGMPv3.  EG, imagine a source that wanted IGMPv3-capable receivers to get 
the traffic via SSM, and IGMPv2-capable receivers to get something (which 
is better than getting nothing).  Of course, you would not be "guaranteed" 
the SSM service model (for that you'd need to use an SSM group), but you 
get the benefit of SSM for those who are able and ASM for those who 
aren't.  Put another way, you can only get SSM behavior in the SSM group 
range, but you can get both ASM and SSM-like behavior in the ASM range 
(but be prepared for frowns and finger-wagging from the Service Model 
Police).

I think sect 6.1 in RFC 3569 says it well:

   Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8
   range.  However, SSM service, as defined in [5], is available only in
   this address range for IPv4.

-Lenny

On Thu, 29 Apr 2010, Sunil Shah wrote:

-) Thanks Tom for the historical perspective. It is very helpful.
-) 
-) So, since IGMPv3 has nothing to do with PIM SSM, its role seems to be that of providing a "filtering" capability.
-) 
-) Coming back to my original query - 
-) - So, if a PIM router receives a IGMPv3 Report in ASM range (non-SSM), 
-) that would imply, the PIM router needs to send a (*, G) JOIN toward the 
-) RP.
-) - And then allow only that traffic to flow towards its IGMP Receivers 
-) if the Source is one that was in the v3 Reports INCLUDE mode (or 
-) EXCLUDE none). Right?
-) 
-) Thanks,
-) -Sunil
-) 
-) -----Original Message-----
-) From: Tom Pusateri [mailto:[email-masked]] 
-) Sent: Wednesday, April 28, 2010 8:11 PM
-) To: Sunil Shah
-) Cc: [email-masked]
-) Subject: Re: [pim] Need clarification on treatment of IGMPv3 reports in ASM (non-SSM) range
-) 
-) 
-) On Apr 28, 2010, at 8:02 PM, Sunil Shah wrote:
-) 
-) > Hi,
-) >  
-) > I have been wondering about the behavior of a router when it receives a IGMPv3 Report in ASM range (i.e. non-SSM range).
-) >  
-) > Shouldn't the router skip any SSM semantic for membership reports in the ASM range (whether it is an IGMPv2 report or an IGMPv3 report)?
-) > If the Group is not in SSM range, then that would mean, either:
-) > a) The host is misconfigured, and is sending IGMPv3 reports in ASM range. 
-) > b) The router is not configured with the correct SSM range. The network admin needs to fix this.
-) >  
-) > RFC5186
-) > But, from referring to the Informational RFC: http://tools.ietf.org/html/rfc5186, it says something else.
-) > 
-) > "6.1 PIM-SM join messages are initiated when a PIM-SM router determines that there are entities interested in a specific group or a specific source sending to the group. If this is due to an IGMPv3 or MLDv2 report with a zero-length EXCLUDE list, then the join is sent as a (*,G) join towards the RP.
-) > If the join is triggered by an IGMPv3 or MLDv2 state change that affects source information, the PIM-SM join is sent as a (S,G) join towards the specific source.
-) > This behavior optimizes the join process, as well as facilitates the adoption of the SSM model."
-) >  
-) > From this passage, it looks like they are suggesting a Last-Hop-Router should initiate a (S, G) JOIN toward Source regardless of whether the Group address in IGMPv3 reports is in ASM or SSM range.
-) >  
-) > Cisco's documentation
-) > Found this link on the web: 
-) > http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtmcxac
-) > l.html#wp1052303 Refer to "Source Addresses in IGMPv3 Reports for ASM 
-) > Groups"
-) > From this, looks like Cisco simply ignores any of the Sources in the IGMPv3 message, and treats it like a regular (*, G) from a IP Routing point of view.
-) > Juniper's documentation
-) > Found this link on the web: 
-) > https://www.juniper.net/techpubs/en_US/junos/topics/reference/command-
-) > summary/show-igmp-statistics.html They have a counter under Rx errors 
-) > for IGMP v3 mode not applicable for SSM.
-) > Number of IGMP version 3 messages received that did not contain a mode applicable for source-specific multicast (SSM).
-) >  
-) >  
-) > I have looked at RFCs 4601 (PIM-SM Spec), 4604 (IGMPv3 and SSM) and 4607 (PIM-SSM), but could not find the behavior defined explicitly.
-) > It is quite possible, I may have missed something. Could someone point me to the appropriate documentation in the "Standards Track" or elsewhere that describes this behavior?
-) >  
-) >  
-) > Thanks,
-) > -Sunil
-) 
-) There is nothing SSM specific about IGMPv3. It was invented prior to the definition of SSM for the purpose of pruning back mis-behaving ASM sources. Please see RFC 3376.
-) 
-) Tom
-) 
-) _______________________________________________
-) pim mailing list
-) [email-masked]
-) https://www.ietf.org/mailman/listinfo/pim
-)

---

From: Sunil Shah <[email-masked]>
Date: Thu, 29 Apr 2010 20:20:13 -0400

Thanks to everyone for their thoughtful and detailed replies. 

But, it seems like there isn't a consensus on how this situation needs to be handled...

My personal view would be to go with the creation of (*, G) approach. By doing it this way -
1. Existing implementations that filter sources at the RP can still be honored.
2. If a network admin had configured a Switchover_Threshold at the Last-Hop-Router, that can be honored. (By creating a RPTree, the traffic from slow/infrequent sources can remain on the RP Tree, and we can prevent adding (S, G) state throughout the network.)
3. Since IGMPv3 pre-dated SSM, it seems like this was the behavior intended by the multicast gurus in those days.
4. Of course, by following this approach, I can see a network admin getting upset if there is no RP. Their point will be, the Last-Hop-Router has the Source and the Group, why isn't the receiver getting any traffic ... :(
(Note: Any network admin wishing to get SSM behavior beyond the default 232.0.0.0/8 range can still get that by easily configuring the range of SSM addresses in almost all router implementations.)

On the flip side, by creating a (S, G) entry and sending a (S, G) JOIN directly toward the Source -
1. This appears as the preferred behavior from the majority of responses received so far.
2. By looking at RFC 4601 spec's "letter of the law", in section 4.5.7 "Sending (S,G) Join/Prune Messages", the JoinDesired (S, G) macro is TRUE if immediate_olist(S,G) != NULL.
For immediate_olist(S,G), it refers to pim_include(S,G)
pim_include(S,G) refers to local_receiver_include(S,G,I)
"The clause 'local_receiver_include(S,G,I)' is true if the IGMP/MLD module or other local membership mechanism has determined that local members on interface I desire to receive traffic sent specifically by S to G."
There is no reference of SSM-range in any of these macros, which would imply the Last-Hop-Router should go ahead and send a (S, G)JOIN as soon as it has a Source and a Group regardless of whether it was in SSM-range or not.
Difficult to say if this was the intention of the 4601 authors, or an omission. Would be nice to hear from one of them on this.

Any further thoughts/comments always welcome.

Regards,
-Sunil

-----Original Message-----
From: Leonard Giuliano [mailto:[email-masked]] 
Sent: Thursday, April 29, 2010 12:57 PM
To: Sunil Shah
Cc: Tom Pusateri; [email-masked]
Subject: Re: [pim] Need clarification on treatment of IGMPv3 reports in ASM (non-SSM) range

Sunil,

I think 6.1 in RFC5186 covers this correctly.  Send a (*,G) if include/exclude is null (otherwise ASM would be broken for IGMPv3), and send an (S,G) if the IGMPv3 message includes a source.  

This can actually be somewhat useful for someone who desires SSM-like behavior, but is willing to live with ASM for receivers that don't support IGMPv3.  EG, imagine a source that wanted IGMPv3-capable receivers to get the traffic via SSM, and IGMPv2-capable receivers to get something (which is better than getting nothing).  Of course, you would not be "guaranteed" 
the SSM service model (for that you'd need to use an SSM group), but you get the benefit of SSM for those who are able and ASM for those who aren't.  Put another way, you can only get SSM behavior in the SSM group range, but you can get both ASM and SSM-like behavior in the ASM range (but be prepared for frowns and finger-wagging from the Service Model Police).

-Lenny