headers
Dan Wing | 5 Jun 2007 01:38
Picon
Favicon

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

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 <at> ietf.org.  Thanks!

-Dan Wing
 chair, BEHAVE working group

> -----Original Message-----
> From: Dan Wing [mailto:dwing <at> cisco.com] 
> Sent: Thursday, May 17, 2007 2:47 PM
> To: 'behave <at> 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).
(Continue reading)

Permalink | Reply | 7 comments |
headers
Manfredi, Albert E | 5 Jun 2007 16:02
Picon
Favicon

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

> -----Original Message-----
> From: Dan Wing [mailto:dwing <at> cisco.com] 
> Sent: Monday, June 04, 2007 7:38 PM
> To: mboned <at> ietf.org; magma <at> ietf.org
> Cc: 'Behave WG'
> Subject: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt
> 
> 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 <at> ietf.org.  Thanks!

http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-06.txt: 

What if the NAPT or NAT device just passed IGMP queries and reports
through, changing only the source address of the reports, and let the
multicast router outside do all the hard work? I'm wondering whether the
IGMP aggregation function is mandatory in NAT/NATP.

Bert

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 6 Jun 2007 02:46
Picon
Favicon

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

> http://www.ietf.org/internet-drafts/draft-ietf-behave-multicas
> t-06.txt: 
> 
> What if the NAPT or NAT device just passed IGMP queries and reports
> through, changing only the source address of the reports, and let the
> multicast router outside do all the hard work? I'm wondering 
> whether the IGMP aggregation function is mandatory in NAT/NATP.

For IGMPv3, you would have the problem described in the document, namely:

   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 lesaving 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 [RFC3376].

Based on Prashant Jhingran's comment,
<http://www1.ietf.org/mail-archive/web/behave/current/msg02373.html>, I'm
trying to determine if this 
same problem exists for IGMPv1 and IGMPv2.  If so, we will need to require
aggregating all flavors of IGMP to avoid that problem.

-d

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Haberman | 6 Jun 2007 14:16

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


Dan Wing wrote:
>> http://www.ietf.org/internet-drafts/draft-ietf-behave-multicas
>> t-06.txt: 
>>
>> What if the NAPT or NAT device just passed IGMP queries and reports
>> through, changing only the source address of the reports, and let the
>> multicast router outside do all the hard work? I'm wondering 
>> whether the IGMP aggregation function is mandatory in NAT/NATP.
> 
> For IGMPv3, you would have the problem described in the document, namely:
> 
>    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 lesaving 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 [RFC3376].

The main issue being that on the upstream interface of the NAPT, the
same source address will be used for the Report and Done message.  So
depending on the order of those messages, traffic may stop temporarily
(until the router sends another Query).

> 
> Based on Prashant Jhingran's comment,
> <http://www1.ietf.org/mail-archive/web/behave/current/msg02373.html>, I'm
> trying to determine if this 
> same problem exists for IGMPv1 and IGMPv2.  If so, we will need to require
> aggregating all flavors of IGMP to avoid that problem.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pekka Savola | 6 Jun 2007 15:06
Picon

Re: issues in draft-ietf-mboned-routingarch-07

Hi,

I've waited for further input on this, but none so far.  Any more 
thoughts?

Some comments inline:

On Wed, 18 Apr 2007, Peter Koch wrote:
> your questions seem far more process oriented or RFC Editor related than
> subject to WG consensus, but here are my two cents:
>
>>  1) BCP vs Informational.  This was discussed mostly between myself
>>     and David and wider input would be useful.  BCPs express wide IETF
>>     community consensus and reviews are conducted in more depth.
>>     Given that the document makes statements about the usefulness and
>>     applicability of a lot of protocols (also outside this WG), having
>>     broad consensus seems very important.  When the document is
>>     updated in the future (likely in this case), BCP number does not
>>     need to change.  On the other hand, informational is easier to
>>     achieve and can also go through IETF Last Call (though people will
>>     likely not review the document at the same detail).
>
> I do not think that the level of review you'd like to see should determine
> the document status, but it is the other way round. A reason for BCP
> would be, e.g., adding or changing IANA instructions, but if I read the
> draft correctly it does not have IANA considerations (read: instructions)
> on its own. Informational seems fine to me and asking the ADs to issue
> an IETF LC is the way to get broader review.

The document status implies how high a bar the document must pass
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pekka Savola | 6 Jun 2007 15:22
Picon

draft-ietf-mboned-addrarch next steps?

Hi all,

(I'm reposting this on the ML and expanding it a bit as I didn't get 
response from the chairs.)

My take of the room at IETF68 wrt draft-ietf-mboned-addrarch was 
follows.  I'd like to get help in figuring out how to move forward 
with the draft.

Requires action (by someone else than the document editor):

1)  disposition wrt. IPv4 unicast-prefix-based and eGLOP was left
     unclear.  There was no time for eGLOP status report. (Though on
     05 April telechat, the IESG seemed to discuss EGLOP with IANA,
     with Ron Bonica left with an action point on this.)

     It would be useful to be able to point to an eGLOP policy that has
     at least been approved, preferably implemented.  How far are we
     from this event?  Do we know more about the schedule?

     Likewise for IPv4 unicast-prefix-based approach, though it's still
     in the IETF's (and this WG's) hands.  The main thing I took away
     from the meeting seemed to be that the editor needs to tune the
     language of who gets the multicast addresses ('subnet' versus the
     'prefix aggregate').  Is this going to move forward soon?

     Or should we just leave these empty and go forward right now
     as-is?

Seem to be clear enough unless there are objections:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Haberman | 6 Jun 2007 16:06

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

Alvaro,
     I am not sure what problem this solves.  Alfred's comments had to
do with receivers behind the NAPT sending Report and Done messages that
had to be aggregated at the NAPT in order to avoid having the external
router stop the multicast stream.  What you describe *appears* to put
the senders behind the NAPT.  Could you elaborate on what your concern is?

Regards,
Brian

Alvaro Fernandez wrote:
> Hi all.
> 
>  
> 
> If you have two sources from two different inside interfaces sending
> multicast data to the outside interface and both sources use the same
> multicast address (G1) then outside routers, using for example PIM-SM,
> will consider that there is only one multicast channel and will send all
> the traffic. Also hosts receiving all the traffic need to separate it.
> 
>  
> 
> One solution is to reserve an IP address range inside SSM range ( for
> example 232.0.0.0 to 232.0.255.255) and let the NAPT change, not only
> the source address of the sender, but also the multicast address of the
> sender to be unique in this range. In this way outside routers ( and
> receivers ) will consider traffic as coming from different channels (IP
> public ,G2) and ( IP public, G3) with G2 and G3 inside the said range.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Manfredi, Albert E | 6 Jun 2007 17:12
Picon
Favicon

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

> -----Original Message-----
> From: Brian Haberman [mailto:brian <at> innovationslab.net] 

> The main issue being that on the upstream interface of the NAPT, the
> same source address will be used for the Report and Done message.  So
> depending on the order of those messages, traffic may stop temporarily
> (until the router sends another Query).

Except that, I thought, the multicast router has to send group-specific
or group-and-source-specific queries before it stops forwarding
multicast packets, in IGMPv2 (the former only) and v3. This is supposed
to ensure that there are no members left in the group, before the
multicast router stops forwarding the packets.

So I'm not sure why there would be this gap in multicasts if everything
is working as it should.

Not that I have anything against aggregation. Just that it seems
unnecessary. It would be nice if the NAT or NAPT device could be as
transparent as possible, I think.

Bert

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned
Permalink | Reply | 0 comments |
headers
Brian Haberman | 6 Jun 2007 18:22

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


Alvaro Fernandez wrote:
> Brian:
> 
>  
> 
> My e-mail was not an answer to Albert, sorry for that,
> 
>  
> 
> It is an idea regarding the BEHAVE Internet Draft and how the multicast
> NAPT can allow outside multicast routers to uniquely identify different
> multicast SSM channels (S,G) coming from inside interfaces in the case
> two inside interfaces use the same multicast group.
> 

How prevalent do people expect the scenario of a SSM sender being
located behind a NAPT?

>  
> 
> In the BEHAVE draft, REQ-4, if there is a host on the inside interface
> sending UDP packets to a multicast group, the NAPT can change the source
> address and the port but not the multicast group address. In this way, I
> think the outside routers can not differentiate the two channels because
> they have the same source (the public interface) and the same multicast
> group address.
> 

Is it possible for the NAPT to have multiple external addresses to use
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brian Haberman | 6 Jun 2007 18:49

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


Marshall Eubanks wrote:
> Hello;
> 
> On 6/6/07, Brian Haberman <brian <at> innovationslab.net> wrote:
>>
>>
>> Alvaro Fernandez wrote:
>> > Brian:
>> >
>> >
>> >
>> > My e-mail was not an answer to Albert, sorry for that,
>> >
>> >
>> >
>> > It is an idea regarding the BEHAVE Internet Draft and how the multicast
>> > NAPT can allow outside multicast routers to uniquely identify different
>> > multicast SSM channels (S,G) coming from inside interfaces in the case
>> > two inside interfaces use the same multicast group.
>> >
>>
>> How prevalent do people expect the scenario of a SSM sender being
>> located behind a NAPT?
>>
> 
> I would expect that this has the potential of being fairly common.
> 
> - Enterprises use NATs a lot. (I am not going to get into the question
> as to whether they should...)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane