2.4.8 MBONE Deployment (mboned)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional MBONED Page

Last Modified: 2005-09-20


Dave 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

- 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 2004  Submit I-D on PIM-SM Multicast Routing Security Issues
May 2004  Submit I-D on IPv4/IPv6 multicast co-existence issues and strategies for IPv4 multicast and IPv6 multicast
Jun 2004  Update IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171/BCP 51)
Jun 2004  Submit PIM-SM Multicast Routing Security Issues to IESG for Informational
Jun 2004  Submit MSDP MIB to IESG for Experimental
Aug 2004  Submit IPv4 multicast address allocation procedures IESG for BCP
Aug 2004  Submit IPv4/v6 co-existence strategies to IESG for Informational
Aug 2004  Submit multicast roadmap/reference architecture document to IESG for Informational


  • draft-ietf-mboned-ssm232-08.txt
  • draft-ietf-mboned-auto-multicast-05.txt
  • draft-ietf-mboned-msdp-deploy-06.txt
  • draft-ietf-mboned-mroutesec-04.txt
  • draft-ietf-mboned-msdp-mib-01.txt
  • draft-ietf-mboned-addrarch-03.txt
  • draft-ietf-mboned-addrdisc-problems-00.txt
  • draft-ietf-mboned-maccnt-req-01.txt
  • draft-ietf-mboned-routingarch-02.txt
  • draft-ietf-mboned-rac-issues-01.txt

    Request For Comments:

    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
    RFC3170 I IP Multicast Applications: Challenges and Solutions
    RFC3171 BCP IANA Guidelines for IPv4 Multicast Address Assignments
    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)
    RFC3956 Standard Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address

    Current Meeting Report

    MBONE Deployment WG (mboned)
    WEDNESDAY, November 9, 2005 0900-1130 (Morning Session I)
    CHAIR: David Meyer 
     o Administriva
       - Mailing list: majordomo@lists.uoregon.edu
         subscribe mboned
       - Scribe(s)?
       - Blue Sheets
     o Agenda Bashing                                                
     o Review and status of work items                      
       Passed WGLC
       draft-ietf-mboned-addrarch-02.txt                             2 minutes 
    This document has been revised. John Kristoff requested editorial
    changes and meta-context. This draft is on hold pending for the
    additional content.
       Active Drafts
       draft-ietf-mboned-addrdisc-problems-00.txt                    5 minutes 
    The author requested additional WG review of this document.
       draft-ietf-mboned-routingarch-01.txt                          5 minutes
    The author wondered if outside comments should be solicited.
       draft-ietf-mboned-maccnt-req-01.txt                           7 minutes
         Hayashi, et al.
    The authors have revised the document with comments and hope to
    go to WGLC with a revised draft.
       draft-ietf-mboned-rac-issues-01.txt                           7 minutes 
    The author plans to update including multicast AAA frameworks
    with multi-provider networks.
       draft-ietf-mboned-msdp-mib-00.txt                             5 minutes
    The author feels that this is ready for WGLC.
       Expired Drafts
       draft-ietf-mboned-rfc3171bis-02.txt                           5 minutes 
    The WG Chair proposed to leave this one expired.
       draft-ietf-mboned-auto-multicast-04.txt                       5 minutes
         Pusateri, et al.
    This draft is not expired, and the author's seek further
       draft-ietf-mboned-ipv6-multicast-issues-02.txt                5 minutes
    This draft is currently dead, and will not be revived without
    interest from the WG.
       draft-savola-mboned-address-discovery-problems-00.txt        10 minutes
    This draft is currently dead, and will not be revived without
    interest from the WG.
       AAA Framework for Multicasting                               7 minutes
    The authors request that this be considered as a WG item.
       Multicast Address Discovery                                  10 minutes
    This was not a draft but a proposal for a solution to the
    lightweight discovery problem. After extended discussion the
    sense of the room seemed supportive of moving towards a solution.
       Label Switched Multicast Solutions                           10 minutes
       Experience With Multicast VPN                                 5 minutes
    These two presentations described work in the L3VPN WG and
    elsewhere on Multicast VPN's. There was considerable discussion
    about the relative role of PIM and BGP in MVPN's.
       IP Multicast MIB                                              5 minutes
    McWalter briefly described extensions to the PIM MIB. The PIM WG
    suggested that this work be done in MBoneD. There was concerns
    that the WG may not have the required expertise. This issue will
    be taken to the mailing list.
       Organizational Issues 
    David Kessens (the AD for this WG) announced that Dave Meyer
    would be stepping down as WG chair. He questioned whether the WG
    should be shut down; the consensus in the room was that it should
    not be.
    The room expressed strong appreciation to Dave Meyer for his
    efforts as Chair. The question of whether the WG should
    re-charter or change direction will be taken to the list.
    Narrative Minutes :
    Dave : Welcome. Here is where the list is.
    Do we have a jabber scribe ?
    Blue sheets are circulating.
    We will look at active, expired, and new drafts, and there will be a few 
    minutes at the end for our AD. 
    Pekka: draft-ietf-mboned-addrarch-02.txt ? This document passed WGLC
    Pekka Savola : OK. This has been revised twice since March. There
    were some good comments about eGlop and other things that hadn't
    been mentioned. Then after WGLC John Kristoff made some editorial
    comments. He also said that he wanted some meta context. I didn't
    respond as I didn't have that context. We have similar issues for
    the Architecture draft.
    Dave : Active drafts - draft-ietf-mboned-addrdisc-problems-00.txt
    - Pekka ?
    Pekka : 
    Lightwieght MADPS: There isn't much to say about this
    document. The WG hasn't been very active. The last discussion was
    in March, and was around whether the enterprises can use the
    whole of the 239 scoped block if they want to. It is not clear to
    me whether or not we should proceed with this document.
    [the scribe agreed to review this document]
    [the AD asked for a show of hands re review]
    John Meylor : There are going to be a couple of address spots
    related to addressing.  We should hold the discussion until then.
    [draft-ietf-mboned-routingarch-01.txt] Pekka : There has been
    some discussion since the last meeting. I added text to explain
    by biDir doesn't work in Interdomain. The document has been very
    I am not sure whether or not we should solicit comments from
    outside the WG. It might be useful to add historical context. I
    don't have all of that information myself.
    Dave : I am trying to figure out if we WGLC this whether people
    will read it.
    Next is Hayashi [draft-ietf-mboned-maccnt-req-01.txt] - Hiroshi
    Ohta is presenting.
    Ohta : Concerning IP multicast, there are 3 players, content
    providers, network operators, and end users. The network
    operators want to have the same management capabilities as for
    Concerning content providers : they want an affordable
    infrastructure, QOS, content protection. They also want detailed
    usage info.
    End users want reliable service.
    The draft was updated since two meetings ago. Duplications with
    the related draft were removed. The drafts were reorganized to
    clarify the role of each draft. There were editorial changes
    reflecting the feedback from the meeting.
    Recently, we received some comments that were helpful. We propose
    to address the comments and publish the revised draft in a few
    weeks and then go to last call.
    Next steps will include find solutions which meet the requirements.
    Dave : If this is stable with the comments from the next round we
    will go to WGLC.
    Satou : Many of the issues are not well covered by existing
    standards. The first figure shows the multiple entity model,
    where a user may subscribe to more than one content provider.
    Changes include 
    - removed unnecessary overlap with requirement draft.
    - changed title of section 5.2 to clarify this
    - added detailed description of IGMP/MLD with unicast control
    - added detailed description of Layer 2 and 3 authentication in section 6.4
    [presented a figure showing that current architectures do not
    cover their requirements]
    Next steps are to update with comments and start discussion on
    multicast AAA frameworks with multi-provider networks.
    Dave : Next is the MSDP MIB. I think that this piece of history
    is ready for WGLC. It's the last piece of the MSDP universe, and
    we will WGLC it.
    Bill Fenner : There were holes that we were going to clean up
    when MSDP went to standards track, but MSDP is not going to
    standards track.
    Dave : And it's IPv4 only
    Dave : Now we will deal with some expired drafts.
    draft-ietf-mboned-rfc3171bis-02.txt. I don't know what we can do
    with this.
    I am proposing to leave this one expired.
    AMT [draft-ietf-mboned-auto-multicast-04.txt] : Tom ?
    Tom Pusateri : The draft has been updated and it's active. There
    was a period when I was learning XML when it went to expired
    state, but now it's active. I have to do one more version, and
    hopefully we will get that done.
    We have got a second implementation going, and if you know of any
    others, please let me know.
    After this meeting, anyone with any interest, we are going to get
    together and discuss deployment
    Dave Thaler : We have an implementation in progress. 
    Dave Thaler : Me and my co-authors.
    Dave : Next is IPv6 Multicast Issues 
    [draft-ietf-mboned-ipv6-multicast-issues-02.txt]. Pekka ? 
    Pekka : I didn't make a presentation as this document is
    basically dead. There was a feeling that this wasn't useful
    enough. There was discussion that this should be combined with
    other expired drafts. If people are interested, I would encourage
    them to pick up the ball and write something.
    Marshall : I think that this should be dealt with in the context
    of a general review of expired drafts.
    Dave : Any of these things requires someone who is going to step
    up and work on it. Otherwise, they become academic, if nobody is
    going to work on it.
    Dave Kessens : Quite frankly, I feel that we should let the
    expired rest in peace. If new people want to bring up the topic,
    they can work on it.
    Dave : As part of the process, we want to make sure we air all of
    this stuff.
    Next is draft-savola-mboned-address-discovery-problems-00.txt
    Pekka : There was stuff in this one that wasn't in other drafts,
    but currently it is dead.
    Dave : So 3171bis is dead, AMT is not expired, multicast-issues,
    and address discovery is RIP.
    Next is AAA Framework for Multicasting [draft-satou-multiaaa-framework-00.txt].
    Hiroaki Satou : We want to start discussion. We have a
    requirements draft and an issues draft.
    We present a new framework, where content providers functions
    include user ID assignment, network providers are responsible for
    forwarding requests to the appropriate content providers. We
    define user access requests, UNI (user -> network) and NNI
    (network -> content providers) requests.
    We want feedback from the WG, and wish for acceptance as a WG
    Dave : This is something that will have to go to the list.
    Dave Thaler : I don't think this should be a working group
    document in this WG.  It should be in the AAA WG. This is an OPS
    Also, can I ask a clarifying question or two ? (Please.)
    There was a earlier presentation. Does this architecture mirror
    the way that things are done for unicast ? Is the proposal
    Hiroaki : We want the capability. We don't have the same
    framework. We want the capability but don't need the same
    John Meylor : I think that the objective is very good. Whether or
    not you can achieve it here is another question.
    Within unicast AAA there are a number of different models. The
    objective is a good general objective.
    I think that this is an opportunity for the operational WG to
    take on these documents and try and achieve parity. Ultimately,
    it might be better to move to AAA, but at this point in time this
    WG is where the required expertise is.
    Dave Thaler : My comment was about this draft specifically, not
    the requirements and issues one.
    Ohta : I agree that this is not the place to discuss protocol,
    but I think it is a goods place to discuss framework. I believe
    framework can be discussed here.
    John Meylor : I agree with that. We need to work out the parts
    that are unique to multicast before we go forward. Once that's
    done, I am not sure that AAA WG will even understand what to do
    with that.
    Dave Thaler : I agree with what John said.
    Is the assumption that every network provider of interest knows
    who the content provider is ? Are there no intermediaries ?
    In other words, every network provider must have a direct
    relationship with the CP for AAA ?
    Hiroshi Ohta : That is our assumption.
    Dave T : Is that the same assumption as in unicast ?
    Dave M : No. It is not the case in unicast.
    John M : And that is why it would be good for us to do a little
    homework. There are some parallels with unicast, but there are
    some things where there are differences.
    Dave M : This is a question of who actually owns the subscriber,
    Dave T : This has been discussed in many previous MBones. Given
    that the its not clear to me that the network actually cares
    about Content AAA, this
    That was the case where you had the single and multiple CP model,
    where it is true on the single CP side.
    Hiroshi Ohta : This is a frame work and an initial
    proposal. There can be several frameworks.
    Dave M : The question is what the disposition is. I think that we
    need to focus more on requirements, and I feel that is the sense
    of the room. [did a hum - it was]
    Next is Beau Williamson with Ideas on multicast address discovery
    [there was no draft].
    Beau : Ok, the basic problem is that enterprise networks want to
    run scoped zones, admin scoping, with enterprise wide multicast.
    Things like Norton Ghost and Altiris are then suddenly enterprise
    wide, and many of these use non-IANA hardwired addresses. Many
    people do this because there is no good mechanism to get suitable
    This makes scope range maintenance into a bit of a nightmare. We
    need some way to give application developers some very light
    weight zero config multicast address discovery.
    In RFC 2365, the 239 space is given scopes, but most enterprises
    view this as private address space.
    We have the 2365 scoped relative addresses. Within each scoped
    zone the top 255 addresses are available, as was used by Madcap.
    Currently 239 has only two well known scopes, the local scope and
    the org-local scope.
    We have well known scoped relative addresses for these two well
    known scopes.  Typically, enterprises go further and define more
    scopes, say campus scopes, regional scopes, what ever makes
    They allocate these out of org local in 239. Often they'll keep
    the local scope separate.
    What we are proposing is a light weight MADP that assumes nothing
    except multicast, and runs entirely in application clients and
    servers, and is completely under the control of the application
    So, I am proposing a single scope-relative address from IANA.
    Client issues a request on local scope first, making a query, the
    server responds saying, "here is the address, this is what we
    Maybe we don't even need to do an RFC to do it, but I think it
    would be useful to define the process.
    Dino Farinacci : Why not use DNS ?
    Beau : They don't want to assume any infrastructure in the local
    They put this in their code.
    Dino : I still think that DNS is better
    Beau : They can't count on it, so it won't happen.
    Pekka : This is re-inventing a small part of DNS for this
    purpose. This looks a bit like multicast DNS.
    Dave M : The problem space is not the same, it's embedded
    applications that are very tightly constrained.
    Beau : The reality is that if you make them rely on anything
    being present in the network they will not use it.
    Toerless : Can you explain how it compares to SLP ?
    Dave M : SLP was a pretty heavy piece that was intended for
    workstations and the like.
    Toerless : If SLP is too heavy, then we should rewrite it.
    Dave T : I think this is a good idea. This is multicast address
    discovery.  There is zero overlap with MADCAP.
    This is not defined as being link local. The other mechanisms are
    defined as being link local. You didn't propose exactly what the
    protocol is.
    Beau : Except that there is a single multicast packet you send
    out and you wait for a response.
    The next step is to define the protocol. This doesn't preclude
    the use of other mechanism for address discovery.
    Dave T : There is no enterprise wide multicast DNS, and
    applications cannot count on being able to insert an A record.
    Dave M : I am sympathetic about updating the A records but
    anything that has DNSsec in the path of deployment is a hurdle.
    Dave T : I do not disagree.
    Pekka : This will require that the admin will configure a group
    Dave T: This does not mention how the application would get this
    Beau : It reduces the problem set to configuring one or a few
    Pekka : If the server has to get the address anyhow, what's the
    difference with manually configuring in the DNS ?
    Beau : It goes back to controlling your own destiny. A lot of
    times the application gets deployed by other groups.
    Dino F : This is not simple enough. It can't be any simpler than
    DNS. We've done this on many unicast applications.  Use one level
    of indirection with a name.
    Beau : We are not precluding that. This has been there all the
    time - if they wanted to use DNS, they could have.
    Lenny Giuliano : Could this problem be solved using SAP ?
    Wouldn't that solve this problem ?
    Beau : Who controls that particular mechanism ? If the app
    developer has to rely on someone else then it won't work.
    Dave T : SAP may be a valid solution.
    Dino : What group ?
    Dave T : Beau answered that - it's scope relative.
    Dino : Nothing needs to be hard coded at all. 
    Stig : I think that this solution is promising. I am still
    worried that people might hard code addresses in solutions.
    Beau : It is guaranteed that if we don't do anything then they
    will continue to hard code addresses.
    Dave M : Right now, if you had a lightweight solution, you could
    tell IANA.  Right now we can't.
    Pekka : Would it be sufficient if we had a document describing
    how to use DNS so we could tell IANA to point to that ?
    Pekka : I am curious that there are devices with no site local DNS
    Dave M : The way they're discovering their addresses is that they
    are asking IANA (or not) and hard coding.
    Dave M : OK, we have two talks on MPLS Multicast. We seem to be
    on the verge of reinventing a lot of multicast, hopefully we can
    learn from history.
    Nidhi Bhaskar : I am here to talk about PE-PE signally options
    being discussed in L3VPN.
    Today, PE-PE signally is deployed using PIM-LAN solutions. There
    is a push to replace this with BGP.
    The enhancements required are fairly extensive.
    There is a new SAFI, with a specific NLRI with enough information
    for detecting a RP and which PE is associated with a given
    {S,G}. Both the upstream and the downstream PE is in the NLRI.
    In the draft there is a description with new functions in BGP
    like aggregating downstream PE information, there is a concept of
    RPF lookup, like PIM but sitting in PIM.
    There is no extension for unicast reachability.
    The slide shows how we might redistribute join information from a
    receiver PE to the source PE. If another PE was to join, there
    would be a second unique NLRI.
    BGP is already deployed as part of the L3VPN infrastructure for
    unicast. BGP seems to be the rule, rather than the exception.
    The RR stores one multicast as N NLRI's, where N is the number of
    downstream PEs interested in a given stream.
    It isn't clear that the existing unicast uses of the RR [Router
    Reflector] will carry over to multicast.
    The RR is now the one thing through which all joins and prunes
    and bindings have to pass, so there will be latency implications.
    There is nothing that talks about HELLO operations for
    There is no Join suppression or Prune override.
    There is currently no support for BiDir, DF Election or for PIM
    Assert  resolution. 
    It isn't clear if PIM Assert resolution is even possible using
    The other problem that we see is that in PIM there is the concept
    of a full state update.  With BGP there is no way to associate
    NLRI's, at least with the existing mechanisms. They same is
    applicable to BSR mappings.
    Other things that need to be addressed are restricting the
    multicast binding to the multicast tree, and the SAFI can be so
    large it can't be encoded for IPv6.
    The LAN-based solutions address most of the issues, but we want
    to have BGP do so as well.
    [Note from the scribe : In the L3VPN WG, PIM Multicast is
    frequently described as the "LAN-based solution" or "LAN
    procedures" or variants thereof.]
    Dave M : I have a couple of questions.
    Well, we have tried to do multicast deployment, without great
    success in the inter-domain space. Part of the problem is it was
    way too complicated. Is this simpler ?
    At some point we have to look at the rate in which we are putting
    stuff into the control place.
    Second, can you use non-route reflector topology ?
    Third, we have already done this one. We have solutions.
    This looks more like DVMRP, rather than PIM. There were a lot of
    optimizations available in DVMRP. Are they available
    N. The purpose [to my talk] is not to propose a solution.
    The purpose is describing how we plan to replace LAN procedures
    Toerless : This doesn't include the functionality of MSDP. We
    would have to expand this to include MSDP.
    If I remember history correctly, the whole reason for using MSDP
    was to not risk the stability of BGP.
    I think that there is a lot of things learned in doing multicast
    that weren't written down and so it is hard to point to them.
    This started out in one very restricted view of multicast
    requirements. Is it appropriate to design something that way ?
    John Meylor : Knowing the presenter, I am sure that the intent is
    to describe from a tree building multicast perspective what the
    issues are getting a tree building multicast service into a
    multipoint LSP. What does the signaling look like, and how does
    that relate to the BGP solution ?
    Eric Rosen : If you want to deflect the BGP proposal, you are
    going to have to have a killer issue. It's more attractive to
    have a BGP everywhere.
    Nidhi put out a whole bunch of issues, but there seem to be
    solutions to all of these issues. People won't care that it is
    not exactly optimal.
    The fact that a Route Reflector is required is not a killer
    The big issue is the rate of change issue. This is to support
    enterprise multicast, and it is hard to figure out what the
    design standard should be.
    Other proposals tend to run into L3VPN issues like properly
    respecting control boundaries.
    Lorenzo : One point is, "let's just use BGP because we are using
    BGP." Are we sure that it will be BGP when it is finished. Are we
    inventing a protocol inside a protocol ?
    Dave Thaler : It would be great if we could have a little more
    [Audience Member] : BGP lately has had extensions. Putting the
    whole PIM complexity into BGP
    Nidhi : I think that we are not there yet on how we can carry all
    of this in BGP.
    Hiroaki Satou : Can PIM-DM be supported using BGP ?
    Although BGP is a reliable session on TCP, refresh reduction can
    be achieved in PIM.
    Nidhi : I do not see how we could support PIM-DM by BGP.
    Dave Meyer : Next is MVPN Experience by Yiqun Cai
    Yiqun : I am going to talk about some of the things we have
    learned about MVPN.
    Vendors started looking at MVPN 5 years ago, way before the IETF
    started dealing with it. It is on of those examples where a pre
    standard implementation has been put into place by a number of
    After the IETF adopted it, we had a lot of debate, but vendors
    and SP's continue to roll out deployments.
    We thought it was valuable to document this experience. Also, if
    we go for a new routing protocol, what are the concerns that we
    have to deal with ?
    This draft covers the model described in the Rosen draft, which
    has been merged into a new draft. AFAIK this is the most dominant
    deployment so far.
    It basically builds a VLAN between the PE routers.
    I am not aware of any v6 deployments.
    PIM is in the core, GRE encapsulation only is supported.
    There is default MDT, which puts all customer multicast onto one
    overlay broadcast network, and data MDTs, which puts certain
    multicasts onto their own overlay network.
    MDT SAFI was introduced 2 years ago to provide inter-AS support.
    The draft describes the problems that we encountered :
    RPF and Load Balancing. If there are multiple routers, what is
    the best practice to avoid routing loops.
    Addressing - what is the best practice for service providers ?
    Summary : This is well deployed, supports existing multicast
    applications and has been tested in the world and is running
    operationally for production traffic. It provides real end to end
    multicast protocol support.
    It leverages the existing multicast protocols in the core. It
    allows migration for new features like p2mp/mp2mp LSP's.
    John Meylor : There is a basic concept that within a PE to PE
    service model, you need to convey
    - how to construct a tree
    - [cross-talk]
    This is handled perfectly in PIM. This model uses PIM.
    Many of us feel that until we can show that BGP can carry the
    models supported in PIM, that we leave the functionalities in PIM
    in the L3VPN Model.
    Dave M : The last talk is the IP Multicast MIB
    David Walter : I am working on a PIM MIB, and we thought that
    certain pieces of RFC 2932 should be updated to support IPv6, and
    that we need generic SSM IPv4 address range configurations.  This
    work picks up a few threads from the expired
    Dave M : Did you say that the PIM WG said that this should be
    done in MBONED ?
    David W : Yes, they did.
    Is this WG interested in this work ?
    Dave M : I would say that with some notable exceptions that I
    don't feel strongly that we have the expertise here to do it.
    There are accidents of history, and we are in operations and
    management but we are more ops than management.
    What alternate WG would take this on ?
    I propose that you take this on the list and we will see what the issues are.
    David Kessens : This WG has been in existence for a while. Dave
    has indicated to me that he would like to step down.
    One proposal is to close the WG. Another is to get a new chair,
    and re-charter the WG
    Dave Meylor : I think that the MBONE WG has been extremely useful
    and continues to be.
    Dino : I think that if it is shut down it's work will have to be
    done elsewhere.
    Pekka : I think that this WG has been very useful and continues
    to be useful.  Instead of expanding I might consider trimming it
    Toerless : Can you be more specific.
    Pekka : For example, the more extensive AAA work could be done
    somewhere else.
    Dave M : Let me see if I can use a little history. Over time,
    there have been certain protocol things that couldn't find a WG.
    MBoneD has been the stop of final resort for Multicast.
    Pekka : Yes, for some of them, maybe not all of them.
    Joel : I think that a lot of what MBoneD was created to do was to
    address problems that we thought we were going to have in
    John Meylor : I think that the notes should reflect the
    appreciation that the WG feels for the efforts of
    Multicast. [applause]
    Eric Rosen : I thought that the first 45 minutes of the meeting
    was about expired drafts and nobody wanted to work on this and
    nobody wanted to work on that.
    Dave Kessens : We have had 10 years of history here; how are we
    going to get multicast deployed.
    Lenny : History has not been very kind in the last couple of
    years. The number of deployments is not growing, or at least in
    the ways that we expected.
    We need to be working towards identifying why deployments aren't
    Chris [?, of France Telecom] : This WG is very useful for us. We
    do need requirements, directives, and the sort of things that
    should be addressed in this WG.
    John Meylor : We have actually never seen multicast being
    deployed more actively than it is today. There is a lot of
    activity going on in multicast today, more than a few years ago.
    The bulk of the Multicast deployments today are in walled
    gardens. I think that there is no correlation in multicast
    deployment and what you see announced in MBGP.
    Nidhi : I think that this WG is very useful, especially as
    multicast tends to be very complex.
    Beau : I think that Tony Soprano has a term for the concept of
    getting rid of MBONED, which is "forget about it." [laughter]
    The deployment tends to be in private network space, in the last
    10 months to a year I have seen an explosion in multicast
    John Meylor : If we look at possible ways to re-charter, a lot of
    the focus was on the bread and butter of the Multicast
    protocols. I think what's still wide open is some of the more
    integrated components of the problem space, address allocation,
    access control. Maybe the direction that the WG takes on is to
    review proposals and to set directions.
    David K : I think that the general consensus is that we keep the
    MBONED WG in one form or way.
    We could do a rechartering on the list.
    Beau : Let's start on the list, and see what is brought up. Maybe
    it's a re-charter, maybe not. If it appears that there is a need,
    we could have a BOF at the next IETF.
    Nidhi : Do you have something in mind ?
    David K : I believe that this has to be set by the WG itself.
    I am going to insist on at least one chair who is a operations
    Beau : I think that you should not narrow your scope that
    much. There are a lot of us who could speak to operations but who
    aren't operators.
    Pekka : I might want to narrow it down even further. We should
    have an operator who has deployed
    Toerless : That is just one access. To me the topics of AAA are
    much more interesting.
    Beau : If you require someone who is a deployer of MVPN, you have
    effectively narrowed the scope and re-chartered it.
    Tom P : How many people here would consider themselves to be operators.
    David K : Recently we did this on the NSO WG. We wrote a
    description of what attributes the WG thought that the Chair
    should have. We wrote the description of the people that would
    fit this. I thought this worked rather well.


    Multicast Routing Architectures
    Address Discover
    AAA Framework for Multicasting
    Issues Related to Receiver Access Control in the Current Multicast Protocols
    L3VPN Multicast Issues
    Experience With Multicast VPN
    Multicast Address Location Protocol
    IP Multicast MIB
    Accounting, Authentication and Authorization Issues in Well Managed IP Multicasting Services