2.4.12 MBONE Deployment (mboned)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://antc.uoregon.edu/MBONED/ -- Additional MBONED Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-05-18

David Meyer <dmm@1-4-5.net>
Operations and Management Area Director(s):
Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>
Operations and Management Area Advisor:
David Kessens <david.kessens@nokia.com>
Technical Advisor(s):
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion: mboned@lists.uoregon.edu
To Subscribe: majordomo@lists.uoregon.edu
Archive: http://www.uoregon.edu/~llynch/mboned
Description of Working Group:
The MBONE Deployment Working Group is a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet. This activity will include, but not be limited to:

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

Goals and Milestones:
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
  • - draft-ietf-mboned-ssm232-08.txt
  • - draft-ietf-mboned-auto-multicast-02.txt
  • - draft-ietf-mboned-msdp-deploy-06.txt
  • - draft-ietf-mboned-ipv4-uni-based-mcast-01.txt
  • - draft-ietf-mboned-embeddedrp-07.txt
  • - draft-ietf-mboned-rfc3171bis-02.txt
  • - draft-ietf-mboned-mroutesec-02.txt
  • - draft-ietf-mboned-msdp-mib-00.txt
  • Request For Comments:
    RFC2365BCPAdministratively 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
    RFC3171BCPIANA Guidelines for IPv4 Multicast Address Assignments
    RFC3170 I IP Multicast Applications: Challenges and Solutions
    RFC3180BCPGLOP Addressing in 233/8
    RFC3446 I Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)

    Current Meeting Report

    MBONE Deployment WG (mboned)

    Wednesday, August 4 at 0900-1130

    CHAIR: David Meyer <dmm@1-4-5.net>
    MINUTES: John Meylor <jmeylor@cisco.com>

    o Agenda Bashing 5 minutes

    o Review and status of work items 35 minutes

    Active Drafts
    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
    Jerome Durand

    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
    Jerome Durand

    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.


    None received.