Subject: [BEHAVE] RE: multicast-08

From: Bharat Joshi <[email-masked]>
Date: Mon, 9 Jul 2007 21:08:08 +0530

Hi Dan,

     I still have some questions and suggestions:

* In introduction, I think you can add a paragraph for the hosts "inside" the NAT can source multicast traffic.

* Can you please simplify the following statement under section #3:

In general, receipt of IGMP messages by the device updated IGMP state maintained by the device and either those changes or timers trigger the sending of IGMP messages.

* The section header "NATting IP Multicast Packets" is misnomer. IGMP messages are also IP Multicast packets as their destination IP is a multicast address. I guess you would want to differentiate the handling of IGMP messages with IP Multicast data traffic.

* I think I mentioned this last time also. I did not understand the differentiation you have mentioned for IGMPv1,v2 and IGMPv3

Thanks,
Bharat

________________________________________
From: Dan Wing [[email-masked]]
Sent: Monday, July 09, 2007 4:03 AM
To: 'Manfredi, Albert E'; Bharat Joshi; [email-masked]; 'Brian Haberman'; [email-masked]; 'Jean-Jacques Pansiot'; 'Marshall Eubanks'; 'Leymann, Nicolai'
Cc: Toerless Eckert
Subject: multicast-08

FYI.

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Sent: Sunday, July 08, 2007 3:33 PM
> To: [email-masked]'
> Cc: Toerless Eckert
> Subject: multicast-08
>
> draft-ietf-behave-multicast-08.txt was just posted at
> http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-08.txt
>
> This version is a significant re-organization from previous
> versions and includes several additions that were necessary
> to incorporate feedback from -06.  If you are at all
> interested in NATting of multicast traffic, please review
> this document.  I expect to issue a WGLC on it shortly.
>
> Please send comments to [email-masked].
>
> -d
>

**************** 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Jul 2007 13:58:50 -0700

> From: Bharat Joshi [mailto:[email-masked]] 
> Sent: Monday, July 09, 2007 8:38 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: RE: multicast-08
> 
> 
> Hi Dan,
> 

Thanks for your comments.

> * In introduction, I think you can add a paragraph for the 
> hosts "inside" the NAT can source multicast traffic.

I added:

  This allows a host 'inside' the NAT to both receive 
  multicast traffic and to send multicast traffic.

to the fourth paragraph.  (Full context is at the URL below.)

> In general, receipt of IGMP messages by the device updated 
> IGMP state maintained by the device and either those changes 
> or timers trigger the sending of IGMP messages.

Let me know if this revision is clearer:

  In general, receipt of IGMP messages by the device 
  updates the device's IGMP state.  The updated state changes
  the device's forwarding of multicast messages or triggers
  the sending of IGMP messages.

This text is reflected in the updated document below.

> * The section header "NATting IP Multicast Packets" is 
> misnomer. IGMP messages are also IP Multicast packets as 
> their destination IP is a multicast address. I guess you 
> would want to differentiate the handling of IGMP messages 
> with IP Multicast data traffic.

I changed that section title to "NATing IP Multicast Data Packets", which is
reflected in the updated document below.

> * I think I mentioned this last time also. I did not 
> understand the differentiation you have mentioned for 
> IGMPv1,v2 and IGMPv3

Are you referring to these requirements?

   REQ-7:   A NAT MAY support IGMPv1 (although IGMPv1 is considered
            obsolete).

   REQ-8:   A NAT MUST support IGMPv2.

   REQ-9:   A NAT SHOULD support IGMPv3.

We're trying to require IGMPv2 and steer support towards v3.  Should we add
some text describing that motivation?  Mostly it's that IGMPv3 and SSM go
hand-in-hand, and we want to encourage IGMPv3 implementations.

new version:
http://svn.resiprocate.org/rep/ietf-drafts/behave/draft-ietf-behave-multicas
t-09.txt

diffs from -08:
http://tools.ietf.org/rfcdiff?url2=http://svn.resiprocate.org/rep/ietf-draft
s/behave/draft-ietf-behave-multicast-09.txt

-d

> To: 'Manfredi, Albert E'; Bharat Joshi; [email-masked]; 
> 'Brian Haberman'; [email-masked]; 'Jean-Jacques 
> Pansiot'; 'Marshall Eubanks'; 'Leymann, Nicolai'
> Cc: Toerless Eckert
> Subject: multicast-08
> 
> FYI.
> 
> 
> 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.

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 10 Jul 2007 09:21:14 +0530

Hi Dan,

    I looked at the diffs and it looks good to me. Thanks for making
these changes. Please see one reply in line.

Thanks,
Bharat

> hand-in-hand, and we want to encourage IGMPv3 implementations.

No. I was not pointing to this. I was trying to understand the
requirement of saying "For IGMPv3, NAT must support IGMP proxying while
for IGMPv1 and v2, its recommended and not mandatory"

My understanding is that, NAT would be changing source address of these
messages [IGMPv1 and IGMPv2] before sending them to upstream router. In
case of IGMPv3, we do IGMP proxying i.e. aggregating reports in NAT
device before generating the aggregated report. This would also have
source IP as the outside interface IP.

Now to me, generating a leave by an IGMPv3 host and immediately after
this leave a join, looks to be a normal IGMPv3 host behavior. So why is
it that we can not pass these messages the way we pass IGMPv1 and v2
messages?