2.4.9 MBONE Deployment (mboned)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

Chair(s):

David Meyer <dmm@cisco.com>

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

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC2365

 

Administratively Scoped IP Multicast

RFC2588

 

IP Multicast and Firewalls

RFC2770

E

GLOP Addressing in 233/8

RFC2776

PS

Multicast-Scope Zone Announcement Protocol (MZAP)

Current Meeting Report

MBONED minutes
address allocation
will publish as *mboned*00 and last call

extended GLOP
will publish as *mboned*00 and last call

service naming
no objections to ASM

Marshall
dmm/roll noted dampening at edges could be applied
roll: isolate RP/MSDP speaker to help alleviate this kind of problem
by default, dampen on DR, e.g. joins and registers
we should recommend a default
suggest don't run RP's and MSDP on core boxes
dmm: some work in MSDP, some in MBONED
hugh: ssm arch draft has some text like this
dmm: more in MSDP? all protocols with state?

Prash - Mantra
dmm: dampening registering from DR's
dampening SA advertisements

Bill Nickless - NLANR IP multicast beacon
ross: wants a daemon - bill says it is
marshall: if you use multicast you need a beacon
bill: n*n might get large if it was *everyone*

Automatic Tunneling
Dave Thaler
marshall: how much 6to4 deployment?
thaler: works for me! 3 open relays
marshall: it's deployed and working?
thaler: working today, is shipping this year
dino: please don't underestimate the evilness of dynamic tunnels. people build routers based on link speeds, this can make the dynamic fanout too large for these kinds of systems
thaler: agree -
ross: seperate out 3 different mechanisms:
the basic tunneling protocol itself (i.e., packet formats, etc.)
tunnel endpoint discovery (anycast)
addressing (especially SSM range munging)
jeremy: what do sources do?
... bill says this answer is in the slides ... SSM only
jeremy: the relay is advertising a route for a fake prefix and the source sends from an addr in that prefix masquerading its true identity
thaler: true identity is in pieces of (S,G) -- x.y.a.b, 232.c.d.z
jeremy: this nukes RPF's protection against forged packets
thaler: inner IP has (S,G); outer IP has true a.b.c.d
billF/dmm: depends on source-address-spoofing protection

billN: worried about this preventing real deployment or being harder
roll: there's 0 barrier to doing real deployment, so why not do real deployment
lorenzo: ??
thaler: how can we put the right incentive in place?
dino: hear what peter says: just get multicast over dialup and the NAS boxes to have static tunnels to multicast cloud

Radia:

Radia Perlman presented a proposal that allows quick deployment of any variant of Explicit Root multicast (such as SSM). It allows deployment without depending on new versions of OSs at the endnodes, or support in the routers. It can be deployed as an application-layer process on the endnode. In the "explicit root" model a group is identified by (R,G), where R is an IP address of the root of the tree.

The joining member sends a join message towards R. The join message must look like an ordinary unicast message to non participating routers, and therefore gets routed towards R. But it has to be trappable by participating nodes, who will create a tunnel back to whoever launched the packet. Endnodes or routers can be tunnel endpoints. The UMTP encoding was recommended, because, unlike previous proposals which were implementable at the endnode by a user process that required privileges, UMTP runs over UDP and therefore can be implemented by an unprivileged user process. Further advantages of this approach of joins were given including that it can be deployed without waiting for OS support of IGMPv3 at the endnode, it can be deployed without for IGMPv3 support by the local router, and by having the endnode participate in the tree-building, the source is aware if there are no listeners, and does not clutter the first hop with traffic in that case.

Following Radia's presentation, Ross Finlayson presented the details of UMTP, but time did not allow him to show his demo of UMTP in operation.

Ross:
dmm: what should happen to the document?
ross: dunno, maybe nothing, this talk is to get interest from vendors
tom: there shouldn't have to be any cooperation, should be deployed using existing code in existing routers.
jhall: ross, what have you done to make multicast better?

Pieter:
???: seems to add lots of complexity
not useful for ISP to restrict things (make multicast hard) because people will do it anyway
pieter: not complex, database servers are web servers that do longest-prefix matching or country-level matching
dmm: questions to mailing list

Slides

None received.