Subject: Re: [magma] IGMP Router State information

From: Anupam S <[email-masked]>
Date: Thu, 6 Oct 2005 01:46:29 -0700 (PDT)

--- Manikantan Srinivasan <[email-masked]> wrote:

> Hello
> 
> I have the following question and thanks in advance
> for your reply.
> 
> The question is related to the IGMP State maintained
> by multicast routers
> and the availability of the state information to the
> end users (Example CLI
> output)
> 
> When a router state becomes Exclude (A*B,B-A), (i.e
> when the router receives
> an IS_EX (B) and its current state is INCLUDE (A)),
> How should the multicast
> group table information get displayed in the user
> output (Ex CLI)?
> 
> Let me use a specific example, Suppose the router
> initially receives from a
> Host H1 an IS_IN (for group 224.1.1.1 , for source
> 192.168.6.1) on an
> interface, and subsequently receives from a Host H2
> an IS_EX (for group
> 224.1.1.1, for sources 192.168.6.1, 192.168.6.2),
> the expected changed state
> is EXCLUDE (192.168.6.1, 192.168.6.2). How should
> the router state
> information be made available in the user output
> (example CLI)?
> 
> I have come across two types of implementation
> 
> The first type is shown below.
>
==========================================================
> Router#show ip igmp group 224.1.1 detail
>  
> Interface: Ethernet0/0
> Group: 224.1.1.1
> Uptime: 00:00:01
> Group mode: EXCLUDE (Expires: 00:02:59)
> Last reporter: 192.168.2.2
> 
> Source Address   Uptime    v3 Exp   CSR Exp   Fwd
> 192.168.6.1      00:00:01  00:02:58  stopped   No
> 192.168.6.2      00:00:00  stopped   stopped   No
> Router#
>
==========================================================
> 
> In this case the timer for 192.168.6.1 is active.
> There is no active timer
> for 192.168.6.2.
> 

The above output is evidently from a Cisco Router and
the output, IMO, is perfectly correct. Infact as shown
correctly above, there should be only ONE Grp-Rec (not
TWO as shown in the contorted display of "second type"
below). And that Grp-Rec (224.1.1.1) has, in Set-A,
ONE  Src-Rec viz., 192.168.6.1 (evident from the fact
that v3 Exp Timer is NOT "stopped") and ONE MORE
Src-Rec viz., 192.168.6.2 in Set-B (evident from the
fact that its Src-Timer is "stopped"). This is inline
with what the RFC states, All Set-A Src-Rec SHOULD
have Src-Timers ticking (may even be stopped in
certain cases, refer RFC for those cases) and is
called as INCL-Set and the other is infact the Set of
all Src-Recs with *NO* src-timers ticking and
constitutes the explicitly EXCLUDE Srcs list.

> The second type is shown below
>
==========================================================
> #show ip multicast group
> Total 2 Groups
> Group Address   Source Address  Interface  Mode   
> Life
>
---------------+---------------+---------+-------+-------
> 224.1.1.1       192.168.6.2        3      exclude  
> 257
> 224.1.1.1       192.168.6.1        3      include  
> 255
> 
> #

IMO, the above display is incorrect in displaying "TWO
Groups" in the first place, and *SEPARATE* Modes for
the *SAME* Grp-rec. The "Mode" is for the entire
Grp-Rec, NOT for each individual Src-Rec. Infact its
only Src-Lists one with Src-Timers Ticking and the
other with Src-Timers not even started. Infact, its
very *wrong* for Src-Rec 192.168.6.2 to have a
Src-Timer running, if in case, "Life=257" above
depicts its Src-Timer value. Its also very *wrong* to
say that Src 192.168.6.1 is in "INCLUDE" mode. The
mode is only for the Grp-Rec.

==========================================================
> 
> As per standards (RFC 3376) Section 6.3 Page 29, for
> a 
> Group filter mode EXCLUDE, TIMER > 0, we have a
> suggestion to forward
> The traffic to the source (whose timer is > 0)
> 
> As per standards (RFC 3376) Section 6.4.` Page 30,
> for a notation
> EXCLUDE (A, B) A is a set of source records, whose
> timer is > 0
> (sources that at least one host has requested to be
> forwarded).
> 
> Hence as per standards, (for my example) the router
> can forward 
> Traffic received from source 192.168.6.1. Does it
> mean the mode
> Is "INCLUDE"?
> 

No, the "Mode" is for the Grp-Rec.

> Assume both implementations are as per the
> requirements of the standard
> IS the CLI output "implementation specific"? i.e in
> the second
> Type shown above, the mode "include" provides
> clarity to the end user
> That the data from that source will be forwarded.
> 

I doubt the internal d-structs in the second CLI
example to have a correct interpretation of the RFC. I
would take the CLI to be a depiction of the internal
d-struct design.

BTW, which Router is the second CLI display from?

> Thanks 
> 
> Best regards
> Mani
> 
> 
>  
> 
> 
> 
> _______________________________________________
> magma mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/magma
> 

__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: mark fine <[email-masked]>
Date: Thu, 6 Oct 2005 12:07:38 -0700 (PDT)

> constitutes the explicitly EXCLUDE Srcs list.

the "contorted" display is a compressed representation of its group,
records showing users the "effective" membership state -- it is not a
strict, rfc-verbatim dump of its group records.

> mode is only for the Grp-Rec.

the display is showing ONE group record with TWO source records -- again,
it's a compressed representation to display the "effective" state of the
membership state: YES, the group record overall has an EXCLUDE mode, but
the source record 192.168.6.1 has a timer on it and is effectively in an
INCLUDE mode, while the source record 192.168.6.2 does not have a timer
(the displayed timer is the group record's timer) and is effectively in an
EXCLUDE mode -- again, this is not meant to be rfc-verbatim dump of the
membership tables, but a compressed representation of the membership state
that illustrates the effective advice to the forwarding mechanism, i..e,
the INCLUDE, EXCLUDE could have just as easily been replaced by ALLOW,
BLOCK.

> No, the "Mode" is for the Grp-Rec.

if you're so insistent on this restricted interpretation, you should look
at getting the following DESCRIPTION text excised from the "Multicast
Group Membership Discovery MIB" draft:

mgmdRouterSrcListExpire OBJECT-TYPE
    SYNTAX     TimeTicks
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
            "This value indicates the relevance of the SrcList entry,
            whereby a non-zero value indicates this is an INCLUDE state
            value, and a zero value indicates this to be an EXCLUDE
            state value."
    ::= { mgmdRouterSrcListEntry 5 }

which is where the idea for the above "contorted" display originated from.

> would take the CLI to be a depiction of the internal

solid reasoning, but wrong... and the "internal d-structs" are
not patricia tries either, as i can think of only a handful of data
structures worse-suited for set operations.

p.s. try using IMHO in place of IMO next time.

---

From: "Manikantan Srinivasan" <[email-masked]>
Date: Fri, 7 Oct 2005 12:01:52 +0530

Hello Anupam, Mark

Good day to you. Thank you for your time and your comments.

My intention was to check if standard mandates any specific format for CLI
output to reflect a protocol implementation. I understand there is no such
mandate, and it is sufficient that the provider of the CLI (output) provide
the needful description/information to the end user to understand the
needful details/implementation.

I am interested to know if there are any other CLI implementation for
reflecting the IGMP group information, other than the two which I had
earlier indicated.

Thanks again,

Best regards
Mani

> -----Original Message-----
> From: mark fine [mailto:[email-masked]] 
> Sent: Friday, October 07, 2005 12:38 AM
> To: Anupam S
> Cc: [email-masked]; magma wg
> Subject: Re: [magma] IGMP Router State information
> 
> > The above output is evidently from a Cisco Router and the 
> output, IMO, 
> > is perfectly correct. Infact as shown correctly above, 
> there should be 
> > only ONE Grp-Rec (not TWO as shown in the contorted display 
> of "second 
> > type"
> > below). And that Grp-Rec (224.1.1.1) has, in Set-A, ONE  
> Src-Rec viz., 
> > 192.168.6.1 (evident from the fact that v3 Exp Timer is NOT 
> "stopped") 
> > and ONE MORE Src-Rec viz., 192.168.6.2 in Set-B (evident 
> from the fact 
> > that its Src-Timer is "stopped"). This is inline with what the RFC 
> > states, All Set-A Src-Rec SHOULD have Src-Timers ticking 
> (may even be 
> > stopped in certain cases, refer RFC for those cases) and is 
> called as 
> > INCL-Set and the other is infact the Set of all Src-Recs with *NO* 
> > src-timers ticking and constitutes the explicitly EXCLUDE Srcs list.
> 
> the "contorted" display is a compressed representation of its 
> group, records showing users the "effective" membership state 
> -- it is not a strict, rfc-verbatim dump of its group records.
> 
> Groups" in the 
> > first place, and *SEPARATE* Modes for the *SAME* Grp-rec. 
> The "Mode" 
> > is for the entire Grp-Rec, NOT for each individual Src-Rec. 
> Infact its 
> > only Src-Lists one with Src-Timers Ticking and the other with 
> > Src-Timers not even started. Infact, its very *wrong* for Src-Rec 
> > 192.168.6.2 to have a Src-Timer running, if in case, 
> "Life=257" above 
> > depicts its Src-Timer value. Its also very *wrong* to say that Src 
> > 192.168.6.1 is in "INCLUDE" mode. The mode is only for the Grp-Rec.
> 
> the display is showing ONE group record with TWO source 
> records -- again, it's a compressed representation to display 
> the "effective" state of the membership state: YES, the group 
> record overall has an EXCLUDE mode, but the source record 
> 192.168.6.1 has a timer on it and is effectively in an 
> INCLUDE mode, while the source record 192.168.6.2 does not 
> have a timer (the displayed timer is the group record's 
> timer) and is effectively in an EXCLUDE mode -- again, this 
> is not meant to be rfc-verbatim dump of the membership 
> tables, but a compressed representation of the membership 
> state that illustrates the effective advice to the forwarding 
> mechanism, i..e, the INCLUDE, EXCLUDE could have just as 
> easily been replaced by ALLOW, BLOCK.
> 
> if you're so insistent on this restricted interpretation, you 
> should look at getting the following DESCRIPTION text excised 
> from the "Multicast Group Membership Discovery MIB" draft:
> 
> > I doubt the internal d-structs in the second CLI example to have a 
> > correct interpretation of the RFC. I would take the CLI to be a 
> > depiction of the internal d-struct design.
> 
> solid reasoning, but wrong... and the "internal d-structs" 
> are not patricia tries either, as i can think of only a 
> handful of data structures worse-suited for set operations.
>