headers
Internet-Drafts | 5 Jun 2003 13:41
Picon
Favicon

I-D ACTION:draft-vida-mld-v2-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multicast & Anycast Group Membership Working Group of the IETF.

	Title		: Multicast Listener Discovery Version 2 (MLDv2) for 
                          IPv6
	Author(s)	: R. Vida, L. Costa
	Filename	: draft-vida-mld-v2-07.txt
	Pages		: 57
	Date		: 2003-6-4
	
This document specifies Version 2 of the Multicast Listener Discovery
Protocol, MLDv2.  MLD is the protocol used by an IPv6 router to
discover the presence of multicast listeners (that is, nodes wishing
to receive multicast packets) on its directly attached links, and to
discover specifically which multicast addresses are of interest to
those neighboring nodes. 
MLDv2 is derived from version 3 of IPv4's Internet Group Management
Protocol, IGMPv3.  Compared to the previous version, MLDv2 adds 
support for 'source filtering', that is, the ability for a node to 
report interest in listening to packets *only* from specific source 
addresses, or from *all but* specific source addresses, sent to a 
particular multicast address.  
This document obsoletes RFC 2710.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vida-mld-v2-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Isidor Kouvelas | 5 Jun 2003 20:59
Picon
Favicon

Re: AD comments on magma-mrdssm-02


Erik,

Sorry for the long delay in resopnding to your comments. More inline.

Erik Nordmark writes:
>
>Draft-ietf-ssm-arch-00.txt is listed as a normative reference.
>When is that document likely to become a proposed standard?
>The RFC editor would not publish this as an RFC until all normative
>references have been published.
>
>So perhaps ssm-arch was intended to be a non-normative reference?

I will move the reference to an informative section.

>In section 1 it would be quite useful to include the motivation for
>needing local ssm range for IPv4 (and not for IPv6).
>As I understand it, but I could be off base, a single /8 is not
>believed to be sufficient for IPv4 SSM (and in IPv6 there is a whole
>/32).

I think the reason for extending the v4 range is the ability to define
admin-scoped SSM ranges outside 232/8. There has been discussion on
the list for using admin scoped SSM ranges within 232/8 but I think
that in practice most people define additional ranges. 
V6 has well defined admin-scoped SSM ranges.
I will add text to the spec to reflect these points.

>Section 1 could benefit from a reference where it says "the SSM range for
(Continue reading)

Permalink | Reply | 501 comments |
headers
Nidhi Bhaskar | 5 Jun 2003 21:13
Picon
Favicon

Re: WG Last Call: draft-holbrook-idmr-igmpv3-ssm-04.txt

> Now, on the question whether the admin-scoped range for SSM should
> be within the SSM range of 232/8 or within the existing admin-scoped
> range of 239/8.
> RFC 2365 already defines 224.0.1.0-238.255.255.255 as
> "global scope", but this was before SSM (i.e., when 232/8 was
> allocated for VMTP transient groups :)
> Hence, it seems to me that you can go either way, by shifting the
> configuration compexity between extra SSM-range configuration and
> extra admin-scope configuration.
>
> My preference would be that the SSM admin-scope range is within the
> original SSM range (232/8), because of the substantial difference
> between ASM and SSM (compared to the difference between "scoped" and
> "non-scoped" multicast), and because it keeps things cleaner. In
> that case, you may need to add additional scope zone configuration
> only for your border routers; otherwise you may have to reconfigure
> all your routers AND hosts to support SSM within some subrange of
> 239/8.

I agree that a scoped multicast SSM range should be allocated.  This
reduces configuration required to enable SSM defaults. However,
carving one from 232/8 (say 232.239/16) may not be the better option.

I don't think Admin scoping is different between ASM/SSM. It is used
to restrict traffic to a certain topology by relying on the group
to which it is sent. For SSM we could reword that to -- restrict
traffic for all channels where the group falls under 239/8.

I think it is early enough to define a admin scoped SSM range within
239/8. Right now, most vendors likely require SSM to be explicitly
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Nordmark | 6 Jun 2003 15:39
Picon

Re: AD comments on magma-mrdssm-02


> I think the reason for extending the v4 range is the ability to define
> admin-scoped SSM ranges outside 232/8. There has been discussion on
> the list for using admin scoped SSM ranges within 232/8 but I think
> that in practice most people define additional ranges. 
> V6 has well defined admin-scoped SSM ranges.
> I will add text to the spec to reflect these points.

Good - that discussion must have occured when I was not around.

> >Mask-Len-n
> >     The mask length for the nth address range.
> >In what unit? (bits I assume)
> >What is the relationship between this and the number of octets used for 
> >the prefix-N field?
> >(pretty basic to have missed that as well.)
> 
> Yes bits, sorry for the omission. The relationship to the prefix
> length is given in the prefix field description. Do you feel I should
> also say something here?

As long as the relationship is clear you can keep thigs in the prefix-n
description.

> >This section could benefit from examples e.g with a /16 prefix and a /17
> >prefix.
> 
> I can add a sentence about /16 needing two bytes for the prefix and
> /17 3 bytes. Do you think this is sufficient or were you thinking
> about including a diagram of the actual packet format?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anouk Rocher | 11 Jun 2003 22:56
Picon
Favicon

question on igmp snooping

Section 2.1.1 of draft-ietf-magma-snoop-07.txt lays down the
rules for forwarding IGMP packets. However, it does not
explicitly indicate if an IGMP Membership Reports should be
forwarded on interfaces connected to other IGMP snooping
switches.

It seems like one would need to forward IGMP packets to other
IGMP snooping switches to make a network of Snooping switches
connected to a multicast router at one end, work. Or else
how will IGMP Snooping work in the network below :

               [multicast router]
                  /         \
              [switch2]    [host3]
               /     \
           [switch1] [host2]
             |
          [host1]

Comments?
Anouk

________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
Permalink | Reply | 0 comments |
headers
Brian Haberman | 12 Jun 2003 15:14

WG Last Call: draft-vida-mld-v2-07.txt

All,
      This is the start of a one week WG Last Call on
draft-vida-mld-v2-07.txt.  This document has had substantive
changes made to it as a result of IESG comments, so we will
have another WG Last Call to ensure that those changes do not
conflict with the group consensus on the protocol's functionality.
This Last Call will end on June 20th.

Regards,
Brian & Isidor
Permalink | Reply | 0 comments |
headers
Anouk Rocher | 12 Jun 2003 16:12
Picon
Favicon

Re: question on igmp snooping

Hello Saravana,

This definitely helps. I had missed that somehow. A follow
up question : Are the rules currently specified, sufficient
for operation when the multiocast router in the diagram
below is not present. Ie there are on IGMP snooping switches
in the network  and hosts send IGMP join/leave messages.

My take is it would, but the switch-2 to switch-1 and 
switch-1 to switch-2 ports would have to be manually
configured to forward IGMP reports.

Thank you,
Anouk

________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

---- On Thu, 12 Jun 2003, SARAVANAP (SARAVANAP <at> infosys.com)
wrote:

> Hello Anouk,
> 
>    IGMP reports should be forwarded upstream. Though this
configuration is not explicitly mentioned,
> it is taken care in the draft in section 2.1.1, points a,b,c
in page 4. If you follow these rules,
> It'll automatically take care of the configuration you are
(Continue reading)

Permalink | Reply | 1 comment |
headers
Anouk Rocher | 12 Jun 2003 22:07
Picon
Favicon

Re: question on igmp snooping

Hello Karen,

Thank you for the summary. It leads one to a model
where if an IGMP snooping network does not have a multicast
router, one or more of the IGMP snooping switches behave
like one and send out IGMP queries. This certainly gets
rid of configuring switch-to-switch ports manually for
IGMP report forwarding. However, the IGMP queriers will 
need to be configured with the list of multicast groups 
they are supposed to query for. So there is still some
manual intervention required.

Regardless, I think even without an IGMP querier the
IGMP snooping will work if switch-to-switch ports are
configured to forward IGMP reports - just not as robustly 
as witha querier. This is kinda cool as for small networks
one can get by without the complexities of PIM.

Sorry if my questions sound dumb - I used to work with DVMRP
a long time ago and am pickung up on IGMP or anything
multicast after a long hiatus.

Anouk.

---- On Thu, 12 Jun 2003, Karen Kimball
(karenk <at> autumn.rose.hp.com) wrote:
> All of this is outside of the IGMP snooping-switch document.
> It is instead part of the IGMP standard(s) itself.
> 	
> To summarize, for proper IGMP operation,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Karen Kimball | 12 Jun 2003 18:03
Picon

Re: question on igmp snooping

Saravana,
	
Thanks for posting the reply.
	
> Hello Saravana,
> 
> This definitely helps. I had missed that somehow. A follow
> up question : Are the rules currently specified, sufficient
> for operation when the multiocast router in the diagram
> below is not present. Ie there are on IGMP snooping switches
> in the network  and hosts send IGMP join/leave messages.
> 
> My take is it would, but the switch-2 to switch-1 and 
> switch-1 to switch-2 ports would have to be manually
> configured to forward IGMP reports.
	
All of this is outside of the IGMP snooping-switch document.
It is instead part of the IGMP standard(s) itself.
	
To summarize, for proper IGMP operation,
	* Reports and multicast traffic must be forwarded
		in the direction of the Querier and out all
		multicast router ports
	* There must always be an IGMP Querier present. That
		means that there must always be one, 
		preferrably more, IGMP-Querier-capable 
		device.
	
Some IGMP snooping-switches can perform limited Querier
capabilities, enough to make IGMP work properly. BUT, in the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Karen Kimball | 12 Jun 2003 23:07
Picon

Re: question on igmp snooping

Hi, Anouk,
	
> Thank you for the summary. It leads one to a model
> where if an IGMP snooping network does not have a multicast
> router, one or more of the IGMP snooping switches behave
> like one and send out IGMP queries. This certainly gets
> rid of configuring switch-to-switch ports manually for
> IGMP report forwarding. However, the IGMP queriers will 
> need to be configured with the list of multicast groups 
> they are supposed to query for. So there is still some
> manual intervention required.
	
This actually isn't true. The IGMP Querier sends out a 
General Query on a fixed interval, which prompts hosts to
Join any groups they are interested in.
	
You may be thinking instead of the Group-Specific Query.
This is sent out in response to an IGMP Leave message from
a host-- it is used to see if any other interested hosts
remain off of that downstream connection. So, the group to
Query for in this case was indicated by the Leaving host.
	
		
> Regardless, I think even without an IGMP querier the
> IGMP snooping will work if switch-to-switch ports are
> configured to forward IGMP reports - just not as robustly 
> as witha querier. This is kinda cool as for small networks
> one can get by without the complexities of PIM.
	
You really don't want to configure the switch-to-switch ports
(Continue reading)

Permalink | Reply | 0 comments |

Gmane