Last Modified: 2004-05-18
- Documenting deployment of multicast routing in the global Internet.
- Receive regular reports on the current state of the deployment of multicast technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies.
- Based on reports and other information, provide feedback to other relevant working groups.
- Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects.
- Update RFC 3171/BCP 51 based on experience.
- Develop a roadmap informational RFC that describes the current IPv4 and IPv6 IETF multicast architectures, including references to the relevant IETF documents and guidance for implementers and network operators.
- Complete the MSDP MIB
This is not meant to be a protocol development Working Group.
|Done||Submit I-D on inter-provider coordination of the deployment of pruning mrouteds.|
|Done||Establish initial charter, goals, and long-term group agenda.|
|Done||Submit I-D outlining requirements for the existing MBONE infrastructure.|
|Done||Submit I-D specifying the use of administratively scoped multicast addresses (RFC 2365)|
|Done||Submit I-D specifying the use of native multicast where appropriate (e.g. exchange points).|
|Done||Submit I-D on IP Multicast and Firewalls (RFC 2588)|
|Done||Submit I-D specifying static allocations in 233/87 (RFC 3180)|
|Done||Submit I-D on debugging multicast problems.|
|Done||Submit final version of scope zone announcement protocol (MZAP RFC 2776)|
|Done||Submit final version of scoped address discovery protocol (SADP)|
|Done||Submit I-D describing ISP multicast deployment practices|
|Done||Submit I-D, with RPS WG, on extensions to RPSL to describe multicast routing policy|
|Done||Submit I-D describing extended allocations in 233/8 (RFC 3138)|
|Done||Submit I-D describing IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171)|
|Done||Submit I-D describing IP Multicast Applications issues (RFC 3170)|
|Done||Submit I-D describing Anycast (RP) mechanism (RFC 3446)|
|Done||Submit I-D describing Source-Specific Protocol Independent Multicast in 232/8|
|Done||Submit I-D describing MSDP Deployment Scenarios|
|Done||Submit I-D describing IPv4 Multicast Unusable Group And Source Addresses|
|Done||Submit I-D describing Embedded RP for IPv6 Multicast Address|
|Apr 04||Submit I-D on PIM-SM Multicast Routing Security Issues|
|May 04||Submit I-D on IPv4/IPv6 multicast co-existence issues and strategies for IPv4 multicast and IPv6 multicast|
|Jun 04||Update IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171/BCP 51)|
|Jun 04||Submit PIM-SM Multicast Routing Security Issues to IESG for Informational|
|Jun 04||Submit MSDP MIB to IESG for Experimental|
|Aug 04||Submit IPv4 multicast address allocation procedures IESG for BCP|
|Aug 04||Submit IPv4/v6 co-existence strategies to IESG for Informational|
|Aug 04||Submit multicast roadmap/reference architecture document to IESG for Informational|
|RFC2365||BCP||Administratively Scoped IP Multicast|
|RFC2588||I||IP Multicast and Firewalls|
|RFC2770||E||GLOP Addressing in 233/8|
|RFC2776||PS||Multicast-Scope Zone Announcement Protocol (MZAP)|
|RFC3138||I||Extended Allocations in 233/8|
|RFC3171||BCP||IANA Guidelines for IPv4 Multicast Address Assignments|
|RFC3170||I||IP Multicast Applications: Challenges and Solutions|
|RFC3180||BCP||GLOP Addressing in 233/8|
|RFC3446||I||Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)|
MBONE Deployment WG (mboned)
Wednesday, August 4 at 0900-1130
CHAIR: David Meyer <email@example.com>
MINUTES: John Meylor <firstname.lastname@example.org>
o Agenda Bashing 5 minutes
o Review and status of work items 35 minutes
draft-ietf-mboned-auto-multicast-02.txt 5 minutes
Thaler, et al
Dave Thaler: Input from last IETF not incorporated yet. Will do. Is there interest from deployment community?
John Meylor: Still seems to be general interest in auto-tunneling
Tom Pusateri: Also think there is interest, and also applicability to the VPN space.
draft-ietf-mboned-ssm232-08.txt 5 minutes
Shepherd, et al
David Meyer: Change of ADs and norm reference to PIM caused some delay. Now reference to new PIM space, which we need status on...
Hugh Holbrook: As for SSM spec: in IESG, and for SM: ready for IESG
David Meyer: So we're just waiting for RFC editors queue
draft-ietf-mboned-embeddedrp-06.txt 5 minutes
Pekka Savola: Waiting for AD to pass it on to RFC editors. In one revision it specifies both FF7 and FFF but now limited to FF7, if needed can extend to FFF later.
draft-ietf-mboned-ipv4-uni-based-mcast-01.txt 5 minutes
draft-ietf-mboned-mroutesec-02.txt 5 minutes
Savola et al
Pekka Savola: Past the IESG evalution. There may be one little thing we would like to add here about "passive-mode" PIM, but that can be left out as well.
David Kessens: Probably don't want to change this.
draft-ietf-mboned-msdp-deploy-06.txt 5 minutes
McBride, et al
David Meyer: Normative reference dependency problem, waiting for variance.
David Kessens: Variance should have cleared last call now.
draft-ietf-mboned-rfc3171bis-02.txt 5 minutes
Albanna, et al
David Meyer: Maintenance mode, consider last call and closing it.
o MSDP MIB Update 5 minutes
Bill Fenner: changes made to keep up with changes in MSDP spec. Need to check and see if anyone has implemented the msdp notification objects
- Just want to point out its only IPv4 specific, but that's because the spec it supports (msdp) is only applicable at this point to IPv4.
- implementation of 03 near compliant, implementation of 07 has several changes to make
David Meyer: need to request variance since its only v4, but since MSDP is only spec'd for v4, then it should be considered fair and justifiable.
Bill Fenner: will add section on why its v4 specific.
o Assignment of IPv6 Multicast Addresses with DHCPv6 20 minutes
Hugh Holbrook: why does RFC 3306 address allocation scheme not work?
Jerome Durand: you can choose via this method, but you can't determine where the RP mapping exists for that address.
Toerless Ekert: but Embedded RP is subset of 3306
Jerome Durand: but embedded RP uses a group ID
Pekka Savola: Host could calculate address with RIID, but thats more complicated, it would simplify to have DHCP server determine this address.
Dave Thaler: All this functionality is covered in MADCAP draft What do we expect for primary deployments, v6 only: then, consider DHCP v4/v6: then, consider extending MADCAP to handle this Question for WG then is do we go for MADCAP or DHCP ?
o Embedded-RP and control mechanisms 20 minutes
Some discussion of MSDP history
- ISPs now willing to use 3rd party RP today allowing models leveraging embedded RP
- Address assignment mechanisms necessary for those RPs
- no way to control which hosts use particular RP
- group_address/register filtering not sufficient
- control for which hosts use RP
- functionality needed: to allow external users only if internal users already instantiated the session
Pekka Savola: Does the RP have to keep some kind of state?
Jerome Durand: Should already be covered
Toerless Eckrt: Suggest restating the problem specifically as one which occurs with ASM services only, since SSM doesn't have this problem.
David Meyer: Warrants further discussion, please take to list.
o IPv6 Multicast Deployment Issues 10 minutes
Pekka Savola: Is this draft useful, should we document?
David Meyer: Poll conclusion: about the amount who read it (majority?) also think it should be wg document
o Update on the IMDOC Initiative 10 minutes
1) address allocation (Pekka Savola presented from the mic):
Pekka Savola: Consider changing status of existing RFCs on address allocation, so they don't confuse folks who assume the are best current documents. Examples given by Pekka on the alias:
RFC3559 Multicast Address Allocation MIB (PS)
RFC2909 The Multicast Address-Set Claim (MASC) Protocol (Exp)
RFC2908 The Internet Multicast Address Allocation Architecture (Info)
RFC2907 MADCAP Multicast Scope Nesting State Option (PS)
RFC2776 Multicast-Scope Zone Announcement Protocol (MZAP) (PS)
RFC2771 An Abstract API for Multicast Address Allocation (Info)
RFC2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP) (PS)
Dave Thaler: Believe 2908 is still valid, but perhaps fact that its not fully implemented is issue. Maybe just need to update?
David Meyer: Many uncoordinated docs, perhaps need unifying doc.?
Dave Thaler: Maybe need BCP which describes how various mechanisms are currently used - and update those referenced docs as needed.
Pekka Savola: Architecture may not now be valid, may need redo
John Meylor: Many docs, some valid, some outdated, some part of problem not resolved yet, in total its confusing, so could use BCP to help guide folks through this space
David Meyer: Perhaps we can get authors for a unifying doc?
Toerless Eckert: Will this be for ASM or also SSM, and will this be academic exercise, since unless it describes an address management scheme which is commercially viable, it likely doesn't have much better chance of success than current situation.
David Meyer: We did include address allocation in charter, so we can cover this additionally on the list.
2) MP-LSPs (Yiqun presentation)
David Meyer: This is good example of the type of issue we intended to cover within IMDOC.
Yakov Rekhter: This is already covered in Req doc in MPLS and its been on last-call.
Yiqun: But it has not passed last call and the purpose of this presentation is to educate mcast folks in MBONED on this open issue since tree-building is a critical component being discussed.
Pekka Savola: Customers don't necessarily need mcast to justify mp solution, could be used for broadcast
Yakov Rekhter: Need to include bullet for pim-free core. Also, presentation assumes packet based service, but should include reference to other services (ex cell based).
Rahul Aggarwal: Education is good, offered to present on this at next MBONED meeting
Yiqun: This is good, but we should then hold up req and spec until this mcast community gets valid input.
John Meylor: 2 key points here:
a) Requirements are being discussed in the MPLS WG and the multicast people need to provide input
b) The problem is multi-faceted and any spec proposal should provide an applicability statement on the extent and limits of the proposed solution.