headers
Marshall Eubanks | 2 Jun 2006 14:54

mboned: Fwd: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada

Hello;

It's that time again !

Note the deadlines for document submissions.

If you have items you want to discuss in Montreal, please send them  
to the chairs.

Regards
Marshall Eubanks

Begin forwarded message:

> From: ietf-secretariat <at> ietf.org
> Date: June 2, 2006 12:00:01 AM EDT
> To: ietf-announce <at> ietf.org
> Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF  
> Meeting in Montreal, Quebec, Canada
>
>
> There are two (2) Internet-Draft cutoff dates for the 66th
> IETF Meeting in Montreal, Quebec, Canada:
>
> June 19th: Cutoff Date for Initial (i.e., version -00)
> Internet-Draft Submissions
>
> All initial Internet-Drafts (version -00) must be submitted by Monday,
> June 19th at 9:00 AM ET. As always, all initial submissions with a
> filename beginning with "draft-ietf" must be approved by the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marshall Eubanks | 2 Jun 2006 17:39

mboned: Fwd: IETF 2008 - 2010 Meeting Calendar Adopted

Just FYI.

Begin forwarded message:

> From: Ray Pelletier <rpelletier <at> isoc.org>
> Date: June 2, 2006 9:52:02 AM EDT
> To: IETF Discussion <ietf <at> ietf.org>
> Subject: IETF 2008 - 2010 Meeting Calendar Adopted
> Reply-To: iad <at> ietf.org
>
> The IAOC has formally adopted an IETF Meeting Calendar for 2008 -  
> 2010.  Thanks for your feedback during its development.
>
> The calendar also includes targeted regions for each meeting for  
> planning purposes.  These regions are provisional and dependent  
> upon many variables, including qualified venue availability,  
> financial risk and an appropriate Host arrangement, and thus are  
> subject to change.
>
> A process for sending expressions of interest to host a meeting is  
> under development and will be separately announced.
>
> The calendar can be found at: http://www.ietf.org/meetings/0mtg- 
> sites.txt
>
> BTW - only 38 days before IETF 66 in the City of Festivals,  
> Montreal.  Register and book your hotels at:  http://www.ietf.org/ 
> meetings/IETF-66.html
>
> Thanks again,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marshall Eubanks | 2 Jun 2006 20:57

mboned: Fwd: New IRTF RG chartered--Scalable Adaptive Multicast (SAM) RG

I know that this will be of interest to some group members.

Regards
Marshall

Begin forwarded message:

> From: "John Buford" <buford <at> research.panasonic.com>
> Date: June 2, 2006 2:26:36 PM EDT
> To: <ietf <at> ietf.org>
> Subject: New IRTF RG chartered--Scalable Adaptive Multicast (SAM) RG
>
>
> A new IRTF research group, Scalable Adaptive Multicast (SAM)
> Research Group, has begun, with the appended charter.
> Use sam-request at irtf.org to subscribe
> to the mailing list.  See http://www.samrg.org for
> further information.
>
> John Buford & Jeremy Mineweaser
>
> ====================================================================== 
> ==
>
>   The Scalable Adaptive Multicast (SAM) Research Group is chartered
>   to explore and research techniques which improve multicast
>   performance with respect to dimensions such as number of groups,
>   dynamics of group membership, dynamics of the network topology, and
>   network resource constraints.  The RG will investigate approaches
>   based on application layer multicast (ALM), overlay multicast (OM),
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 6 Jun 2006 21:50
Picon
Favicon

mboned: I-D ACTION:draft-ietf-mboned-ip-mcast-mib-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the MBONE Deployment Working Group of the IETF.

	Title		: IP Multicast MIB
	Author(s)	: D. McWalter, et al.
	Filename	: draft-ietf-mboned-ip-mcast-mib-01.txt
	Pages		: 48
	Date		: 2006-6-6
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes objects used for managing multicast
   function, independent of the specific multicast protocol(s) in use.
   This document obsoletes RFC 2932.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mboned-ip-mcast-mib-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mboned-ip-mcast-mib-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
David McWalter | 7 Jun 2006 09:53
Favicon

FW: mboned: draft-ietf-mboned-ip-mcast-mib-00 review

The revised draft contains these changes.
DMcW.

http://www.ietf.org/internet-drafts/draft-ietf-mboned-ip-mcast-mib-01.txt

-----Original Message-----
From: owner-mboned <at> lists.uoregon.edu
[mailto:owner-mboned <at> lists.uoregon.edu]On Behalf Of David McWalter
Sent: 03 May 2006 14:04
To: Pekka Savola
Cc: mboned <at> lists.uoregon.edu
Subject: RE: mboned: draft-ietf-mboned-ip-mcast-mib-00 review

Hi Pekka.

It's great that you've reviewed the MIB.  Thanks.

I plan to make the following changes.  Let me know if you'd like anything different.

Dave McW.

1)  It would be good to count dropped packets at zone boundaries.
-  In table ipMcastBoundaryEntry, I'll add a packet count and an octet count with text like:
"The number of [octets of] multicast packets that have been dropped as a result of this zone boundary configuration."
-  I'll add these two new counts to conformance group ipMcastMIBBoundaryIfGroup.

2)  ipMcastRouteDifferentInIfPackets is really useful, and should be included in basic support for this MIB.
-  Okay.  Unless anyone objects, I'll move the contents of ipMcastMIBPktsGroup into the more basic group
ipMcastMIBRouteGroup, which is mandatory for routers.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hiroaki Satou | 8 Jun 2006 08:24
Picon

Re: mboned: Comments to draft-ietf-mboned-rac-issues-03.txt (long message)

Dear Christian,

Thank you for your feedback on draft-ietf-mboned-rac-issues-03.
Sorry for the late response.
Authors were discussing how to rearrange the ducument to this day.
We will update the draft by the cutoff date.

As you indicated the goal and scope of the current version, as well as
the draft's relation to draft-ietf-mboned-maccnt-req-04 need
clarification.  We plan to do the following:

1) Clarify the goal of the draft:
	to survey how current standards satisfy the requirements
defined in draft-ietf-mboned-maccnt-req-04, and to identify any lackings
in current standards which should be addressed by future solutions work.
mboned-maccnt-req defines requirements including those for (standardized)
user-based accounting capabilities in
multicasting similar to what are possible with unicasting.

2) Refine scope of the draft:
	No new requirements should be presented in this draft.
         Scope should be limited to the requirements for a "fully AAA
enabled" IP multicasting network, as defined in mboned-maccnt-req.

Related to the clarified goal and scope, and considering the comments
from you and other people we realize the organization of the draft needs
to be overhauled.
1) we will reorganize the draft to more clearly adhere to the order and
terminology of the requirements presented in mboned-maccnt-req.
2) we will include consideration of relevant standards that are not
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hui Liu | 8 Jun 2006 11:59
Favicon

mboned: suggestion for simplifying IGMPV3/MLDV2 to discard EXCLUDE mode

Hello, all

I'd like to suggest here the simplification of IGMPv3/MLDv2;

In IGMPV3/MLDv2, protocol filter-mode is defined to support SSM. In
practice, it seems EXCLUDE mode is not so useful, for there is little
requirement for excluding specific sources. Further, EXCLUDE can not
guarantee host not receiving unexpected traffic.

The realization of the EXCLUDE mode and corresponding mode-switch operation
are relatively complicated, especially when implementing L2/L3 LAN switch
with snooping. So it is suggested here to simplify IGMPV3/MLD2 to eliminate
the EXCLUDE mode. Then the process of router and host will be greatly
simplified. And the important thing is: For SSM, INCLUDE mode is enough to
express join for specific sources.

Glad to hear your opinions

Regards,

Hui   Liu

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
Permalink | Reply | 0 comments |
headers
David McWalter | 8 Jun 2006 14:29
Favicon

mboned: RE: [magma] suggestion for simplifying IGMPV3/MLDV2 to discard EXCLUDEmode

Hi Hui.

Yes, I think that's already been agreed.

(See section 2.2.2 in 
http://www.ietf.org/internet-drafts/draft-holbrook-idmr-igmpv3-ssm-08.txt
currently in RFC Ed queue).

'An SSM-aware host SHOULD NOT send any of the following record types for
an SSM address.

    - MODE_IS_EXCLUDE as part of a Current-State Record

    - CHANGE_TO_EXCLUDE_MODE as part of a Filter-Mode-Change Record

This is a MODIFICATION to [IGMPv3,MLDv2], imposing a restriction on its
use for SSM destination addresses.  The rationale is that EXCLUDE mode
does not apply to SSM addresses ... '

I don't think you're proposing anything in addition to this?
DMcW.

-----Original Message-----
From: Hui Liu [mailto:liuhui47967 <at> huawei.com]
Sent: 08 June 2006 10:59
To: magma <at> ietf.org
Cc: mboned <at> lists.uoregon.edu
Subject: [magma] suggestion for simplifying IGMPV3/MLDV2 to discard
EXCLUDEmode
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bryan McLaughlin (brmclaug | 8 Jun 2006 17:07
Picon
Favicon

RE: suggestion for simplifying IGMPV3/MLDV2 to discard EXCLUDEmode


-----Original Message-----
From: Hui Liu [mailto:liuhui47967 <at> huawei.com] 
Sent: 08 June 2006 10:59

I'd like to suggest here the simplification of IGMPv3/MLDv2;

In IGMPV3/MLDv2, protocol filter-mode is defined to support SSM. 

BMC>

It's my understanding exclude mode was designed to allow a host to
reject a ASM source. It's for this purpose I think it is still a valid
requirement.

Cheers

Bryan
Permalink | Reply | 0 comments |
headers
Manfredi, Albert E | 8 Jun 2006 17:20
Picon
Favicon

RE: mboned: RE: [magma] suggestion for simplifying IGMPV3/MLDV2 to discard EXCLUDEmode

When operating with IGMPv3/MLDv2, is there no value in allowing for any
source multicast filtering behavior? Are we saying that whenever ASM is
needed, the host must revert to IGMPv1/IGMPv2/MLDv1?

I figured the EXCLUDE mode was useful if IGMPv3/MLDv2 was to be used in
an ASM situation, although I suppose that this isn't a big deal. Because
the version can be different for any given multicast group supported by
a multicast router.

Bert

> -----Original Message-----
> From: David McWalter [mailto:DMcW <at> dataconnection.com] 
> Sent: Thursday, June 08, 2006 7:29 AM
> To: Hui Liu; magma <at> ietf.org
> Cc: mboned <at> lists.uoregon.edu
> Subject: mboned: RE: [magma] suggestion for simplifying 
> IGMPV3/MLDV2 to discard EXCLUDEmode
> 
> Hi Hui.
> 
> Yes, I think that's already been agreed.
> 
> (See section 2.2.2 in 
> http://www.ietf.org/internet-drafts/draft-holbrook-idmr-igmpv3
-ssm-08.txt
> currently in RFC Ed queue).
> 
> 'An SSM-aware host SHOULD NOT send any of the following 
> record types for
(Continue reading)

Permalink | Reply | 0 comments |

Gmane