headers
Hiroshi Ohta | 4 Sep 2007 07:40
Picon

Adopting <draft-sarikaya-mboned-mldauth-ps-00.txt> as a WG doc

Working group,

In the last session of mboned during IETF-69 in Chicago, the 
meeting agreed to adopt 
<draft-sarikaya-mboned-mldauth-ps-00.txt> as a WG document.  
We would like to confirm this on the ML as well.

If you have any comments or objections, please post 
them on the ML by the end of the next week (i.e., by Sept. 14).

Thank you.
Hiroshi and Marshall

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned
Permalink | Reply | 1 comment |
headers
Hiroshi Ohta | 4 Sep 2007 07:42
Picon

Adopting <draft-asaeda-mboned-mtrace-v2-00.txt> as a WG doc

Working group,

In the last session of mboned during IETF-69 in Chicago, the 
meeting agreed to adopt 
<draft-asaeda-mboned-mtrace-v2-00.txt> as a WG document.  
We would like to confirm this on the ML as well.

If you have any comments or objections, please post 
them on the ML by the end of the next week (i.e., by Sept. 14).

Thank you.
Hiroshi and Marshall

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned
Permalink | Reply | 0 comments |
headers
The IESG | 5 Sep 2007 22:22
Picon
Favicon

Last Call: draft-ietf-mboned-routingarch (Overview of the Internet Multicast Routing Architecture) to BCP

The IESG has received a request from the MBONE Deployment WG (mboned) to 
consider the following document:

- 'Overview of the Internet Multicast Routing Architecture '
   <draft-ietf-mboned-routingarch-09.txt> as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2007-09-19. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mboned-routingarch-09.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13102&rfc_flag=0

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned
Permalink | Reply | 9 comments |
headers
Marshall Eubanks | 6 Sep 2007 15:21

Fwd: Call for Corrections to 69th IETF Meeting Proceedings

We have minutes and slides posted - please send any corrections to  
the chairs in time for this
deadline.

Regards
Marshall

Begin forwarded message:

> From: "Bunch, Rebecca" <Rebecca.Bunch <at> neustar.biz>
> Date: September 5, 2007 4:11:13 PM EDT
> To: "Working Group Chairs" <wgchairs <at> ietf.org>, "BOF Chairs"  
> <bofchairs <at> ietf.org>, "Arron Falk" <irtf-chair <at> irtf.org>
> Cc:
> Subject: Call for Corrections to 69th IETF Meeting Proceedings
>
> Dear Working Group and BOF Chairs:
>
>
>
> The deadline for CORRECTIONS to the minutes and presentation slides  
> submitted for inclusion in the proceedings of the 69th IETF meeting  
> is Wednesday, September 12, 2007 at 17:00 ET (21:00 GMT).
>
>
>
> Status of Submissions:
>
> One Hundred Eleven (111) Working Groups, BoFs and AG’s met at IETF  
> 69 (This number includes the training sessions, Plenary sessions,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 7 Sep 2007 14:04
Picon
Favicon

Re: [BEHAVE] WGLC for draft-ietf-behave-multicast-09

Hi,

As AD and shepherd of this document I am concluding this WG last call.
Some comments was received, but it appears nothing controversial. Editor
please update the draft. When a new draft version is available I will
request publication of this document as BCP.

Best Regards

Magnus

Dan Wing skrev:
> I am starting the 3rd WGLC on draft-ietf-behave-multicast-09, "IP Multicast
> Requirements for a Network Address (and port) Translator NAT".  The WGLC ends
> on September 3.  The previous WGLCs were for -06 and -03 (which also went to
> IESG).
> 
> 
> Draft-ietf-behave-multicast-09 integrates all of the comments received to
> date.  Significant changes from -08 include:
> 
> * Consideration of Gorry Fairhurst's comments in Chicago about a multicast
> source inside of a multi-homed network; unfortunately the best I could
> describe to deal with that problem was the new requirement 5-a:
> 
>            "a:  If a network is multihomed, the NATs or the network
>                 configuration MUST ensure that duplicate instances of
>                 the multicast data traffic does not appear on the public
>                 network.  This can be accomplished by network design (an
>                 access control list) or a protocol between the NATs
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 10 Sep 2007 23:48
Picon
Favicon

Last Call: draft-ietf-mboned-routingarch (Overview of the Internet Multicast Routing Architecture) to BCP

The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document:

- 'Overview of the Internet Multicast Routing Architecture '
   <draft-ietf-mboned-routingarch-09.txt> as a BCP

If approved, this memo obsoletes the following RFCs:
3913,2189,2201,1584,1585

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2007-09-24. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mboned-routingarch-09.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13102&rfc_flag=0

_______________________________________________
MBONED mailing list
MBONED <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mboned
Permalink | Reply | 0 comments |
headers
Stig Venaas | 11 Sep 2007 14:07
Picon
Picon

Re: IPv4/IPv6 Multicast interoperability

Vincent Gay wrote:
> Hi all,

Hi Vincent. I've been planning to follow up on this for a while,
apologies for the late response.
> 
>  
> 
> I and my company are strongly interested in doing efficient Multicast
> over IPv4 between IPv6 islands.
> 
> Ideally, any host, in v4 or v6 domain, should be able to receive
> Multicast stream content sourced by any other host. Note that Multicast
> stream must be sent in Multicast over both IPv4 and IPv6.
> 
>  
> 
> I saw that a set of solutions  - based on reflection or translation -
> had been implemented some years ago (respectively by K.Kabassanov and
> S.Venaas).

For this particular problem I think encapsulation is better than
translation. Sounds like more or less need to map IPv6 multicast
groups to IPv4 groups and encapsulate the IPv6 multicast into the
respective IPv4 multicast groups. There are some interesting questions
whether this should be 1-1 etc.

There has been some work somewhat related to this. See for instance
draft-ietf-l3vpn-2547bis-mcast-05.txt which has some interesting
discussion on different types of mappings depending on what you want
(Continue reading)

Permalink | Reply | 5 comments |
headers
Manfredi, Albert E | 11 Sep 2007 17:24
Picon
Favicon

RE: IPv4/IPv6 Multicast interoperability

> -----Original Message-----
> From: Stig Venaas [mailto:stig.venaas <at> uninett.no] 

> Vincent Gay wrote:
> > 
> > I and my company are strongly interested in doing efficient 
> Multicast
> > over IPv4 between IPv6 islands.
> > 
> > Ideally, any host, in v4 or v6 domain, should be able to receive
> > Multicast stream content sourced by any other host. Note 
> that Multicast
> > stream must be sent in Multicast over both IPv4 and IPv6.
> > 
> > I saw that a set of solutions  - based on reflection or 
> translation -
> > had been implemented some years ago (respectively by 
> K.Kabassanov and
> > S.Venaas).
> 
> For this particular problem I think encapsulation is better than
> translation. Sounds like more or less need to map IPv6 multicast
> groups to IPv4 groups and encapsulate the IPv6 multicast into the
> respective IPv4 multicast groups. There are some interesting questions
> whether this should be 1-1 etc.
> 
> There has been some work somewhat related to this. See for instance
> draft-ietf-l3vpn-2547bis-mcast-05.txt which has some interesting
> discussion on different types of mappings depending on what you want
> to optimise etc. I think the l3vpn stuff could apply to what you are
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stig Venaas | 12 Sep 2007 11:26
Picon
Picon

Multicast and IPv4-IPv6 co-existence

With the transition/migration to IPv6 we will probably for decades have
nodes and networks that either can be IPv4-only, both IPv4 and IPv6, or
IPv6-only. And of course, combinations of those. Below are some thoughts
regarding multicast and IPv4-IPv6 co-existence.

Looking at end nodes (multicast sources and receivers) the principal
problem is that the source and all the receivers must use the same IP
protocol. If you source multicast and some receivers are IPv4-only and
some IPv6-only, you will need to either send the stream twice, both IPv4
and IPv6, or you need some kind of translation.

Having the source send the content twice might be fine for many single
source applications. It becomes more problematic if receivers send
multicast RTCP reports that you want all the other receivers to receive,
or if you have multi-party applications like conferencing. One thing is
bandwidth, the other is that this is not possible if some of the
participants are IPv4-only and some IPv6-only.

We can hope that in the short run all end-points can do IPv4 multicast
(IPv4-only or dual-stack), and that by the time we get many IPv6-only
there will be few IPv4-only. I am far from sure this will be the case,
but this would simplify things.

Assuming that all nodes participating in a multicast session (all
sources and receivers) can speak the same IP protocol, one can avoid
translation. However, while all the end-points might speak the same,
there will probably be a need for encapsulation/tunneling techniques to
make things work through networks that might only support multicast for
one of the IP protocols. It might make sense to encapsulate multicast
from one IP protocol into multicast in the other, however one could
(Continue reading)

Permalink | Reply | 4 comments |
headers
Prashant Jhingran | 12 Sep 2007 14:40
Favicon

RE: Multicast and IPv4-IPv6 co-existence


As per the mail, solution for following scenarios may be
required:

- Multicast between IPv6 isolated domains connected via IPv4
backbone 
- Multicast between IPv6 only domains & IPv4 only domains
[draft-venaas-mboned-v4v6mcastgw-00.txt]
- Multicast between IPv4 isolated domains connected via IPv6
backbone  [draft-xu-softwire-4over6multicast-00]

Provided border routers are dual-stack in all the above
scenarios.

Various protocol standards exists for IPv6 multicast but
there exists none which facilitates a smooth integration of
IPv6 with the existing IPv4 networks!  

I also feel that the WG should address these scenarios
particularly the first two listed above.

-----Original Message-----
From: Stig Venaas [mailto:stig.venaas <at> uninett.no] 
Sent: Wednesday, September 12, 2007 2:57 PM
To: mboned <at> ietf.org
Subject: [MBONED] Multicast and IPv4-IPv6 co-existence

With the transition/migration to IPv6 we will probably for
decades have
nodes and networks that either can be IPv4-only, both IPv4
(Continue reading)

Permalink | Reply | 0 comments |

Gmane