2.4.10 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 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-20

David Meyer <dmm@1-4-5.net>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Randy Bush <randy@psg.com>
Technical Advisor(s):
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion: mboned@ns.uoregon.edu
To Subscribe: majordomo@ns.uoregon.edu
Archive: ftp://ftp.uoregon.edu/mailing-lists/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 to aid in the transition to native multicast, where appropriate.

- Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects.

This is not meant to be a protocol development Working Group.

Goals and Milestones:
Done  Submit Internet-Draft on inter-provider coordination of the deployment of pruning mrouteds.
Done  Establish initial charter, goals, and long-term group agenda.
Done  Submit Internet-Draft outlining requirements for the existing MBONE infrastructure.
Done  Submit Internet-Draft specifying the use of administratively scoped multicast addresses.
Done  Begin work, with RPS WG, on extensions to RPSL to describe multicast routing policy.
Dec 99  Submit Internet-Draft specifying the use of native multicast where appropriate (e.g. exchange points).
Dec 99  Begin work on document of co-existence strategies for IPv4 multicast and IPv6 multicast.
Dec 99  Submit final version of RP document
Dec 99  Submit Internet-Draft specifying static allocations in 233/8
Mar 00  Submit Internet-Draft on debugging multicast problems.
Mar 00  Submit final version of scope zone announcement protocol (MZAP)
Mar 00  Submit final version of scoped address discovery protocol (SADP)
Mar 00  Submit I-D describing ISP multicast deployment practices
  • - draft-ietf-mboned-ssm232-06.txt
  • - draft-ietf-mboned-msdp-deploy-04.txt
  • - draft-ietf-mboned-ipv4-mcast-unusable-00.txt
  • - draft-ietf-mboned-embeddedrp-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

    MBONED Nov 11, 2003
    MSDP is finally through
    Cannot close the working group because there is not a MIB yet.
    Dave Thaler :
    I do not know what the current status of the MIB is. Bill Fenner is the  
    primary owner.
    Bill Fenner:
    So, the update is that I have polled for MIB implementations. I know  that 
    Cisco has one. Looking at the evolution of the MSDP MIB and  protocol, I 
    backed the MIB down to more or less what Cisco has  implemented. A couple 
    tweaks and it should be ready for last call.
    Dave Meyer:
    Do you think we can working group last call it after the IETF.
    Bill Fenner:
    Drafts on MSDP deployment and SSM 232 are both at the IESG waiting on  last 
    Bill Nickless :
    I ran into problems with IGMP snooping switches, because of MAC  
    collisions. I thought these should be brought out in a document. 
    However, I had feedback from the group suggesting
    The two approaches are
    - accept everything except those that are globally "unusable" (because  of 
    MAC collisions, because of  their site local only use, etc.)
    - deny everything except what IANA has reserved specifically for  
    Which should we do ?
    Beau Williamson :
    I think that there should be a big address space that is allowed, and  then 
    everything else
    Dave Meyer I think that this should become like unicast addresses. Never 
    allocate  anything unless it is absolutely necessary. Most people who ask 
    for  multicast addresses do not really know what they are asking for.
    I do not want this or any other working group to become the multicast  
    address space routing registry.
    Also, there is the extended GLOP space which the IANA and a Routing  
    Registry - we  need to push this through and we need volunteers to help  
    with this.
    Audience Member:
    I think we are heading for trouble if we block out lots of address  
    Marshall Eubanks:
    I agree. If we do this I fear that the space blocked out will never be  
    useable due to the inertia of the system.
    Also, I see need for extended GLOP address space and want to work to help 
    get that set up.
    Beau Williamson:
    We need to make sure that we can limit what is unusable to a 
    reasonable  amount.
    Hugh Holbrook:
    For SSM snooping, these are more operational practice issue than Many 
    companies, including my own, are going to Layer 3 snooping, where  we look at 
    IP addresses instead of MAC addresses, so we don't have the  problems with 
    MAC address. Maybe this should be a BCP or informational.
    Beau Williamson:
    I am starting to see address allocation problems inside enterprises -  
    where they do not understand the relationship between their address  usage 
    which causes problems.
    I want to work on a multicast address allocation document.
    My goal is to put together an informational draft that explains the  
    issues for everyone, both inside the enterprise and globally.
    Dave Meyer:
    The problem that we are facing is that people want unique addresses,  and 
    they use one they got a long time ago or just make one up.
    So we get requests from financial organizations for /18 in the  
    multicast address range, which they don't need, and this is a problem.
    Kevin Almeroth:
    Does this relate to the updated 3171 ?
    Dave Meyer:
    I updated rfc3171 because there were /8's that were not being used.
    <Consensus was obtained to update and finish the draft as is (i.e.,  with 
    narrow scoping).>
    ---------------------------------------------------------- Pekka Savola / 
    Toerless Eckert
    Embedded RP for IPv6 - Issues
    Focused on PIM-SM not BiDir - it is more complex and not clear how to  make 
    it work.
    Hugh Holbrook :
    Why doesn't BiDir work ?
    Toerless Eckert:
    The problem is that the Designated Forwarder (DF) election would have  to be 
    done before you send the first packet - it needs to be  
    pre-calculated and embedded in the group address. It is too much work  to do 
    this globally.
    Open issues.
    SPT threshold is not addressed in current implementations.
    - There are security issues
    Sender side DOS attacks Old ASM - MSDP floods SSM - Only first hop router is 
    flooded Embedded RP - the embedded RP is flooded No multicast state, 
    Receiver Side is very similar to SSM
    Is this critical ?
    Marshall Eubanks:
    The vulnerabilities seem similar in danger to SSM, which I think renders 
    them acceptable.
    Also, if I embed your IP address (not a router, just a random address)  in a 
    embedded RP address, can't I DOS your (or any arbitrary) IP address. This is a 
    little different from SSM, where I can only DOS your RP.
    Tom Pusateri:
    This will require changes to RPs and elsewhere. Does a protocol change  
    belong in an operational group ?
    Dave Meyer:
    Yes, this is an operational group, but if we see something that's  
    needed, and its not getting done, we need to do it.
    ----- Toerless Eckert :
    We need to create an IP Multicast Address-Plan This is enforced today by 
    manual allocation & scoping within a PIM  domain. In a PIM domain, this is 
    fine, as it sits inside an AS.
    With embedded RP, the PIM domain becomes bigger than an AS, so the  
    binary discussion between inter and intra domain becomes no longer 
    This is too simple - the inter vs intra domain decision should become a  
    sliding scale.
    Dave Meyer:
    I have never seen a document which says how to allocate RFC1918  
    addresses. Why do we need one now ?
    Toerless Eckert:
    Proposal :
    Leave the lower 7 bits of the Group ID bit open for different service  
    models, to be defined later.
    For example, a bit saying "only accept multicast data from sources in  the 
    same address block as the source" would help avoid traffic  
    interference in few to many ASM multicasts.
    Lenny Guilani :
    If you want to do interdomain multi source does that mean that the  
    sources DF is going to register with the RP?
    This is basic to any embedded RP. I just think that we need to decide  how to 
    handle the multi-domain case.
    Lenny Guiliani:
    How is anycast RP done in embedded RP ?
    I took this slide out, but I do not think that this is a problem.
    Dave Meyer:
    Is it possible to merge this up into one document ?
    Toerless Eckert:
    I don't think that we should do this. What's the need to allocate all  of 
    the bits right from the start.
    Hugh Holbrook:
    It seems that this a point with minor operational issues which should  be 
    moved forward.
    <consensus was obtained to continue moving forward with the embedded RP  
    ------- Lenny Guiliani:
    Framework for deploying IPv6 Multicast
    Competing idea :
    Just do SSM interdomain for IPv6 Intradomain - do what you want.
    Dave Meyer:
    The authors felt that since the embedded RP draft is moving  forward, this 
    draft was dead. I wanted to explore to see if this could  be continued as a 
    BCP or something similar.
    Lenny Guilani:
    We could do anything from simply deprecating ASM to saying that SSM is  the 
    long term solution.
    The authors favor the deprecating ASM option.
    Kevin Almeroth:
    I would say that it should say that SSM must be done.
    Dave Thaler:
    I do not want for application developers to say that "we need ASM, so  we 
    can't use IPv6." I do not want disincentives to not to use IPv6.
    I suggest Option 3.b, just telling people that SSM is the way to go.
    John Meylor:
    It is a moot point to a degree, as there are embedded RP solutions out  
    there already. Maybe the market will deprecate ASM in the long run.
    Pekka S.:
    One thing that might be useful is a framework document describing when  to 
    use SSM and when to use embedded RP.
    Tim C:
    In the Op6 group there are documents on how to move applications to  IPv6. Is 
    there such a document on how you move to SSM ?
    Lenny Guilani:
    John Meylor:
    Is there a detailed description on how to do multisource with SSM ?
    Hugh Holbrook :
    This is missing.
    Dave Meyer:
    What we really need is a deployment document that describes  
    functionalities we have and how to achieve them.
    Lenny Guiliani:
    Wouldn't this be a "yeah we already know that"
    Dave Meyer:
    I do not think that anyone has a done a detailed gap analysis on either  
    Kevin Almeroth:
    Isn't SSM the lowest common denominator ? If they support any PIM,  
    shouldn't we say that they have to support SSM ?
    Dave Meyer:
    The analysis needs to be done before we say that.
    Dave Meyer:
    I do not think that there is any consensus here, so I will take this to  the 
    ------- Dave Meyer:
    The 3171 guidelines to IANA has expired.
    There are 4 other drafts that have expired. I want to try and revive  all of 
    Dave Thaler:
    My draft was at the IESG waiting for approval. I can revive it easily  if 
    there is interest.
    ------- Hugh Holbrook - Update on the Apple IPR issue for SSM
    Apple claims that a patent that they own is infringed on by SSM.  It  says 
    that they want reasonable and non-discriminatory licenses
    SSM is a core technology, so this issue cannot be fudged. This will be 
    discussed at the SSM WG
    We do use a lot of IPR-impacted technology in the IETF. We need to make  a 
    risk-benefit decision before we move forward.
    Mike Luby:
    Have you talked to Apple recently ?
    Hugh Holbrook:
    I talked to Apple through the back door recently, but they were not  very 
    open to changing the wording. They point to all of the similar  wording on 
    the IETF IPR.
    Audience Member:
    When was this patent granted?
    Hugh Holbrook:
    Granted 1996 - the creator was Mark Green, who is still around.
    Dino F. I was working with Mark Green on this, and they would not likely 
    view  this applying to the ASM parts of PIM-SM.
    Kevin Almeroth:
    This same risk applies to pretty much everything
    Bill Fenner:
    You are only required to disclose IPR if you are working on a spec. The  
    simple fact that Apple has come forward with this when they could have 
    waited should not be viewed as requiring us to do anything about it.
    Dino F.:
    Apple didn't wait. We were worried that PIM was infringing, so it was  
    brought to their attention.
    ------ Kevin Almeroth:
    We need better feedback tools. If we are not receiving traffic, we need  
    tools to decide what is going wrong.
    Ideas :
    SSM ping - establish SSM reachability. Is there a new ICMP message  
    needed ? What are the security issues ?
    The mechanism for trying multicast now - join and wait - is just not  
    robust enough.
    Kamil Sarac wrote a preliminary draft. Is there interest ?
    Pekka S. There is a similar problem with embedded RP. There is a 
    potential for DOS attacks
    Louis Lamenkis:
    In my previous life as an operator, there was a definite need for this.
    Beau Williamson:
    What we really need is a replacement for mtrace, which seems to be  
    broken now.
    Kevin Almeroth:
    We also need to get feedback from first hop routers - do they support  
    IGMPv3 ? Am I sending (S,G)  in an ASM range or a (*,G) in an SSM range  ? We 
    need better feedback.
    There have been a lot of us who have worked on this. The tools are  still 
    really primitive.
    Louis Lamenkis:
    There are overlapping problems here. One problem I had was, "is the  first 
    hop router multicast capable" ? One size does not fit all.
    Dave Thaler:
    What are the problems with the current mtrace ? (Besides MSDP.)
    Bill Fenner:
    Are these implementation problems or protocol problems ?
    Dave Thaler:
    Before MSDP, mtrace seemed to work fine
    Bill Nickless:
    mtrace is not useful for when you have a RP with any sort of tree  
    Dave Meyer:
    Our charter (when revised) will definitely include
    Marshall Eubanks:
    What about the various multicast beacon groups and their software tools    ?
    Kevin Almeroth:
    That doesn't help application writers
    Marshall Eubanks:
    So you would put mping in an application ?
    Kevin Almeroth:
    John Meylor:
    Is mping the most important thing ? I would say that mtrace is.
    Kevin Almeroth:
    That's an implementation issue, not a WG issue.
    John Meylor:
    A posted draft for mtrace would be really useful.
    -------------------- FLUTE:
    Rod Walsh
    FLUTE == File delivery over Unidirectional Transport
    Based on ALC & LCT but fully specified
    3 genetically different implementations now
    FLUTES from INRIA TUT (Tampere Finland) Nokia U. Bremen
    Interop testing 2 and 3 way testing - multicast and unicast working 
    towards a 4 way test.
    Need a new Interoperability Testing Guideline document.
    RMT is likely to go dormant soon, so we need to know if we can do this  in 
    Toerless Eckert:
    This is router based, right ? Are there any implementations that do the  
    router based congestion control ?
      Lorenzo Vicisano There are no implementations with built in (non end to 
    end) congestion  control.
    Dave Meyer:
    I think that this is outside the scope of this working group.
    Tom Pusateri:
    I don't think that being in or out of scope of the  charter is relevant to 
    this working group!
    Dave Meyer:
    Point taken. I would be concerned about our competency to do this.
    Lorenzo Vicisano We will continue this in RMT. The only question was the  
    interoperability testing.
    Rod Walsh:
    There will be a document for interoperability guidelines
    Mike Luby:
    Where will it be published ?
    Rod Walsh:
    This is open, but it sounds like it should be RMT.
    ------- John Meylor IMDOC Internet Multicast Documentation
    Problem :
    There tends to be holes in deployment. Some Issues -
    Multisource use for SSM ? or Tunnel use for initial deployment .
    Topics fall through the cracks, as so much is spread over various  
    working groups.
    Also, build it and they will come has not worked in practice.
    Need :
    Process to track these issues across working groups
    Handle in MBONED with no extra WG needed.
    Dave Meyer:
    People have asked - is this a directorate ? This comes from the AD's.  
    Unless and until the ADs ask for a Directorate we will do this here.
    If IMDOC did recognize a real gap or hole in the current work, then  they 
    could propose to the AD's that a given working group be pushed to  handle 
    Toerless Eckert:
    Couldn't this lead to protocol changes or enhancements ?
    Dave Meyer:
    IMDOC is a process. It is not our intention to write protocols - that  
    should be left to others.
    John Meylor:
    Our goals are to 1.) write down a framework 2.) discuss input 3.) set 
    priorities !


    None received.