headers
Christian Kaas-Petersen | 3 Mar 2003 12:11
Picon

State changes

draft-vida-mld-v2-06.txt states in appendix 2 in point 1, that
"routers may want to track per-host multicast listener status on
an interface".  In that case, the actions described in sections
6.4.1 and 6.4.2 need not be done, as the receiving router already
has a full knowledge of listening status of hosts, and thus can use
the same algorithm as described for hosts calculating their
interface state (section 3.2).  Further, such a router will never
send Multicast Address Specific Queries and
Multicast Address and Source Specific Queries.  Having followed the
recent discussion on the set manipulations in sections
6.4.1 and 6.4.2, I think I'm entitled to conclude, that implementors
may choose for themselves what the new router state shall be
and the actions to be taken, provided they end with the same result.

Christian
Permalink | Reply | 1 comment |
headers
Rolland Vida | 5 Mar 2003 11:01
Picon

RE: State changes

Christian,

> draft-vida-mld-v2-06.txt states in appendix 2 in point 1, that
> "routers may want to track per-host multicast listener status on
> an interface".  In that case, the actions described in sections
> 6.4.1 and 6.4.2 need not be done, as the receiving router already
> has a full knowledge of listening status of hosts, and thus can use
> the same algorithm as described for hosts calculating their
> interface state (section 3.2).  Further, such a router will never
> send Multicast Address Specific Queries and
> Multicast Address and Source Specific Queries.

As I pointed out in the discussion with Erik, the MLDv2 spec does not
include host tracking. Therefore, if an MLDv2 router implementation wants to
be conform to the future MLDv2 standard, it should follow the behaviour
described in this document. Nevertheless, there might be some proprietary
implementations that do provide host tracking.
As Erik mentioned also, the sentence you talk about might be confusing. We
will try thus to rephrase it.

> Having followed the
> recent discussion on the set manipulations in sections
> 6.4.1 and 6.4.2, I think I'm entitled to conclude, that implementors
> may choose for themselves what the new router state shall be
> and the actions to be taken, provided they end with the same result.

We will write a new version of the draft, taking into account all the
modifications and including all the explanations required by Erik.
Hopefully, the new document will be clearer and easier to understand both
for implementors and simple readers.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Haberman | 5 Mar 2003 17:26
Picon

Request Advancement: draft-ietf-magma-igmp-proxy-02.txt

Erik,
      On behalf of the MAGMA working group, we would like to
request the advancement of

	Title		: IGMP/MLD-based Multicast Forwarding ('IGMP/MLD
                           Proxying')
	Author(s)	: B. Fenner et al.
	Filename	: draft-ietf-magma-igmp-proxy-02.txt
	Pages		: 9
	Date		: 2003-3-4

as Proposed Standard.  The working group last call completed on
02/24/2003.

Regards
Brian & Bill
Permalink | Reply | 0 comments |
headers
Brian Haberman | 6 Mar 2003 17:21
Picon

Request Advancement:draft-ietf-magma-mrdssm-02.txt

Erik,
      On behalf of the MAGMA working group, we would like to
request advancement of:

	Title		: Multicast Router Discovery SSM Range Option
	Author(s)	: I. Kouvelas
	Filename	: draft-ietf-magma-mrdssm-02.txt,.ps
	Pages		: 5
	Date		: 2003-3-3
	
as a Proposed Standard.  The working group last call completed on
02/24/2003.

Regards,
Brian & Bill
Permalink | Reply | 0 comments |
headers
Brian Haberman | 7 Mar 2003 02:03
Picon

WG Last Call: draft-ietf-magma-msnip-02.txt

All,
      This is the start of a working group last call on
draft-ietf-magma-msnip-02.txt as a Proposed Standard.  This
last call will be three (3) weeks long and end on 03/28/2003.
Substantive comments should be directed to the mailing list.
Editorial issues should be directed to the authors.

Regards,
Brian
Permalink | Reply | 1 comment |
headers
Seehofer, Markus | 7 Mar 2003 17:04
Picon

Question about IGMP and MLD Snooping Switches

> Hello,
> 
>            Considerations for IGMP and MLD Snooping Switches
>                     <draft-ietf-magma-snoop-06.txt>
> 
> reads as follows:
> --------------------------------------------------------------------------
> -----------------------------
>     4)  An IGMP snooping switch should be aware of link layer topology
>          changes.  Following a topology change the switch should
>          initiate the transmission of a General Query over the receiving
>          ports in order to reduce network convergence time.
> 
>          a) ....
> 
>          b)  ....
> 
>          c)   When a new port comes up, a General Query message should
>               be sent out the new port to determine which groups, if
>               any, have receipients that have become reachable.  The new
>               port is designated as a router port in MRD messages are
>               processed.
> 
>          If the switch is not the Querier, it should use the 'all-zeros'
>          IP Source Address in these proxy queries.  When such proxy
>          queries are received, they must not be included in the Querier
>          election process.
> --------------------------------------------------------------------------
> --------------------------------
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Karen Kimball | 9 Mar 2003 18:57
Picon

IGMP-MLD Proxying Draft Comments No. 2

Comments on    IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")

This next set of comments will deal with smaller issues in the forwarding 
behaviors described by the protocol.

In Section 3. Abstract protocol definition  paragraph 7, there is the 
phrase, "... A can be configured to forward packets even though B is the 
Querier."  

How is this to occur? An explanation is needed. Is this supposed to mean 
that an explicit "IGMP forward" configuration should be allowed for 
interfaces of Proxy devices? "IGMP forward" configuration is something that 
some IGMP switch and/or router vendors support, but it is not a required 
part of any IGMP standard. Thus, I believe it needs to be spelled out here 
if this is what is desired.

Also in Section 3, the figures for LAN 1 and LAN 2 with Proxy Devices A 
and B could be improved in both cases to explicitly label B as the Querier.

In section 4.3. SSM Considerations, I regret that I am not familiar enough
with SSM to know the impact of the following phrase in paragraph 2:

     "... a proxy device that supports this document should ignore those
     IGMPv1 or IGMPv2 subscriptions sent to SSM addresses. And more
     importantly, the packets with source-specific addresses SHOULD not
     be forwarded to interfaces with IGMPv2 or IGMPv1 subscriptions for
     these addresses."

What will happen at a higher level if these IGMPv1 and/or IGMPv2 
subscriptions are ignored? Will the server and client renegotiate for a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Karen Kimball | 9 Mar 2003 18:57
Picon

IGMP-MLD-Proxying Draft Comments No.1

Comments on    IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")

This first set of comments will deal with problems in the forwarding behaviors
described by the protocol.

Section 3. Abstract protocol definition   describes the forwarding behaviors
for the IGMP/MLD Proxy device. However, I can think of network setups-- in
a tree structure as prescribed-- where this will not work. Given the following,
where the Proxy Querier A is the "Root" device,

                      < Larger LAN >         upstream
                            |                  ^
                            |                  |
                      Proxy A (Querier)      [ROOT]
                     /      |          \
                    /       |           \
                   /        |            \
             Proxy B    Proxy C           Proxy E
            /   \      /       \         /    |   \
           /     \    /     Proxy D     /     |    \
      Host1   Host2  Host3   /    \   Host6  Host7  Host8
                            /      \
                        Host4    Host5

if Proxy B receives a packet from Host1, it will forward the packet ONLY 
upstream to Proxy A. Proxy A will forward the packet down to all of its members.

But what if Host2 needed to receive the packet as well? Proxy B can't forward
the packet because Proxy B is not the Querier (and can't forward downstream).
Proxy A cannot forward the packet to HOst2 because the packet was received on
(Continue reading)

Permalink | Reply | 3 comments |
headers
Karen Kimball | 9 Mar 2003 18:58
Picon

IGMP-MLD Proxying Draft Comments No. 3

Comments on    IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")

These final comments are purely editorial. 

Section 2.3 Group Mode, 

   paragraph 1, change  "In IPv4 environment" to  "In IPv4 environments"

   paragraph 2, change  "In IPv6 environment" to  "In IPv6 environments"
                change  "if a MLDv1 report" to  "if an MLDv1 report"

2.4 Subscription

   end of this paragraph needs a closing parenthesis, "on an interface)."

3. Abstract protocol definition

   paragraph 4, I recommend adding text at the end of this paragraph that
                changes "remaining interfaces."   to    "remaining
                interfaces (this may include the upstream interface)."

Section 4.1 Membership database

   paragraphs 5 and 6 (? or 6 and 7), the word "the" should precede
                references to "upstream interface," e.g., all incidences
                should be changed to   "the upstream interface"

Section 4.3 SSM Considerations

   paragraph 1 needs additional insertions of "the". The final portion
(Continue reading)

Permalink | Reply | 1 comment |
headers
Haixiang He | 9 Mar 2003 21:48

Re: IGMP-MLD-Proxying Draft Comments No.1


Karen Kimball wrote:

> Comments on    IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")
>
> This first set of comments will deal with problems in the forwarding behaviors
> described by the protocol.
>
> Section 3. Abstract protocol definition   describes the forwarding behaviors
> for the IGMP/MLD Proxy device. However, I can think of network setups-- in
> a tree structure as prescribed-- where this will not work. Given the following,
> where the Proxy Querier A is the "Root" device,
>
>                       < Larger LAN >         upstream
>                             |                  ^
>                             |                  |
>                       Proxy A (Querier)      [ROOT]
>                      /      |          \
>                     /       |           \
>                    /        |            \
>              Proxy B    Proxy C           Proxy E
>             /   \      /       \         /    |   \
>            /     \    /     Proxy D     /     |    \
>       Host1   Host2  Host3   /    \   Host6  Host7  Host8
>                             /      \
>                         Host4    Host5
>
> if Proxy B receives a packet from Host1, it will forward the packet ONLY
> upstream to Proxy A. Proxy A will forward the packet down to all of its members.
>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane