RE: FW: WGLC: draft-ietf-behave-multicast-06.txt

 

> -----Original Message-----
> From: Bharat Joshi [mailto:bharat_joshiinfosys.com] 
> Sent: Monday, June 04, 2007 9:48 PM
> To: behaveietf.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 behaveietf.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:dwingcisco.com] 
> > > Sent: Thursday, May 17, 2007 2:47 PM
> > > To: 'behaveietf.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-beh
ave-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 mbonedlists.uoregon.edu prior to 
> > > submitting to IESG.
> > > 
> > > -d
> > > 
> > 
> > _______________________________________________
> > MBONED mailing list
> > MBONEDietf.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
> Behaveietf.org
> https:/
/www1.ietf.org/mailman/listinfo/behave


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

Hi Dan,

    Please see my replies in line.

Thanks,
Bharat

> > * 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).
> 

Things should work even if we do not aggregate IGMPv3
message also. Why
we do aggregation is that we do not want to send multiple
messages
upstream? Because upstream would forward multicast data
traffic if he
knows that there is atleast one host interested in a group.

Aggregating IGMPv3 is a little more complex than V1 and V2.

I just wanted to point out that if an NAPT is implementing
RFC 4605 than
it should be aggregating all versions of IGMP. So why do you
want to
specifically mention the case for IGMPv3?

> > * 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>.
>     >

Thats exactly why I raised this question. How does this
creates an
issue? This can happen in a host as well. Lets say
application just
started and send a join and immediately after this because
of some
failure, it goes down and send a leave. I am not sure what
the problem
is.

> > * 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).
> 

I think this may not be completely correct. This is because
239/8 is
available to administrator and they can use this for SSM
within a given
domain.

> > * 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.
> 

Ok. So now how do you remove that mapping? I guess only once
that times
out. Right?


**************** 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
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave