RE: [BEHAVE] Re: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt

> -----Original Message-----
> From: Bharat Joshi [mailto:bharat_joshi@infosys.com] 
> Sent: Monday, June 04, 2007 9:48 PM
> To: behave@ietf.org
> Subject: [BEHAVE] Re: [MBONED] FW: WGLC: 
> draft-ietf-behave-multicast-06.txt
> 
> 
> Hi Dan,
> 
>     I have couple of questions and suggestions:

Thanks for your comments!

> > The BEHAVE working group concluded its WGLC of
> > draft-ietf-behave-multicast-06 with no comments received.  
> > I would like
> > MBONED and MAGMA to please take a look at this draft prior 
> . to its submission
> > to IESG.
> > 
> > Please send replies to behave@ietf.org.  Thanks!
> 
> * In section 4.2, why is it that a NAPT device implementing this draft
> needs to aggregate IGMP message only for IGMPv3? I think if it is
> implementing 'RFC4605', it will anyway do the aggregation.

It's my understanding that things will work -- somewhat sub-optimally --
with IGMPv1 or IGMPv2 without the NAT doing aggregation of IGMPv1/v2
messages and blindly just forwarding them upstream.

If my understanding is incorrect, please let me know (it may well be;
multicast is not my expertise).

> * In case of IGMPv3, why is it that aggregation is a MUST? 
> Also I think
> when one of the hosts behind the NAPT generates LEAVE and another
> generates JOIN simultaneously, the session will be UP till the
> group-timer timesout and as JOIN is also received, it will be updated
> and so session will always be UP. Am I mixing the session created in
> NAPT with the state in upstream router?

Slightly after that requirement in the document is this explanation:

    >
    >  Failure to do this aggregation will cause undesired
    >  temporary blackholing of multicast traffic.  For example,
    >  consider two hosts behind the same NAPT. If one host is
    >  joining a session at the same time another is leaving the
    >  session, and the NAPT merely relays the join and leave
    >  upstream, the session will be terminated and the join and
    >  leave announcements do not comply with section 5 of <xref
    >  target="RFC3376"></xref>.
    >

> * Typo "lesaving the session" -> "leaving the session"

Thanks, fixed.

> * In section 4.4, though complete Multicast Range is 224/4 but out of
> this range 232/8 is used for Source Specific Multicast or 
> Single-Source
> Multicast. So is the following statement syntactically correct
> 
> "Any-sosurce multicast (ASM) uses the IP addresses in the 224.0.0.0 -
> 239.255.255.255 range [IANA-ALLOC]."
> 
> What I meant is that it looks to be incorrect to call this 
> range as ASM range.

You're right.  I pulled this from the Terminology section of RFC3569 
("An Overview of Source-Specific Multicast (SSM)").  I have adjusted
my document so that it describes the ASM space as 224/8 through
231/8 and 233/8 through 239/8 (with a hole for 224/8).

> * In section 4.4,
> 
>      a.  This UDP mapping SHOULD be destroyed when the host leaves
>          that host group.
> 
>   How do we find out that host has left the group? Please 
> correct me if I am wrong.
> We are talking about a host behind the NAPT device
> generating Multicast data traffic [UDP traffic]. A multicast host does
> not need to join the multicast group [By sending an IGMP join message]
> to send multicast traffic to that group. So how does NAPT 
> finds out when
> it can destroy this mapping and so this mapping will have to timeout
> before it can be removed.

Ah, good point which I hadn't considered.  I have removed that 
requirement.

> Thanks & Regards,
> Bharat
> 
> PS: I am not subscribed to 'behave' mailing list so please 
> reply-all or include my id in your reply.

-d

> > -Dan Wing
> >  chair, BEHAVE working group
> > 
> > > -----Original Message-----
> > > From: Dan Wing [mailto:dwing@cisco.com] 
> > > Sent: Thursday, May 17, 2007 2:47 PM
> > > To: 'behave@ietf.org'
> > > Subject: WGLC: draft-ietf-behave-multicast-06.txt
> > > 
> > > The working group last call is starting now for "Multicast 
> > > Requirements for a Network Address Port Translator (NAPT)", 
> > > http://www.ietf.org/internet-drafts/draft-ietf-behave-multicas
> > > t-06.txt: 
> > > 
> > >    This document specifies requirements for a Network Address
> > >    Translator (NAT) and Network Address and Port Translator (NAPT)
> > >    that supports any-source multicast or single-source 
> multicast.  A
> > >    multicast-capable NAPT device that adheres to the 
> requirements of
> > >    this document can optimize the operation of multicast
> > >    applications that are generally unaware of multicast NAPT
> > >    devices.
> > > 
> > > This WGLC will finish on Thursday, May 31 (two weeks from today).
> > > 
> > > If this WGLC is successful, I will ask for review by the 
> > > MAGMA working group and mboned@lists.uoregon.edu prior to 
> > > submitting to IESG.
> > > 
> > > -d
> > > 
> > 
> > _______________________________________________
> > MBONED mailing list
> > MBONED@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mboned
> 
> 
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION 
> intended solely for the use of the addressee(s). If you are 
> not the intended recipient, please notify the sender by 
> e-mail and delete the original message. Further, you are not 
> to copy, disclose, or distribute this e-mail or its contents 
> to any other person and any such actions are unlawful. This 
> e-mail may contain viruses. Infosys has taken every 
> reasonable precaution to minimize this risk, but is not 
> liable for any damage you may sustain as a result of any 
> virus in this e-mail. You should carry out your own virus 
> checks before opening the e-mail or attachment. Infosys 
> reserves the right to monitor and review the content of all 
> messages sent to or from this e-mail address. Messages sent 
> to or from this e-mail address may be stored on the Infosys 
> e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> 
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www1.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www1.ietf.org/mailman/listinfo/behave