Current Meeting Report
2.4.8 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 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 05/06/2002
David Meyer <email@example.com>
Operations and Management Area Director(s):
Randy Bush <firstname.lastname@example.org>
Bert Wijnen <email@example.com>
Operations and Management Area Advisor:
Randy Bush <firstname.lastname@example.org>
Scott Bradner <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
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
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
|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
|MAR 00|| ||Submit Internet-Draft on debugging multicast problems. |
|MAR 00|| ||Submit final version of scope zone announcement protocol
|MAR 00|| ||Submit final version of scoped address discovery protocol
|MAR 00|| ||Submit I-D describing ISP multicast deployment practices |
Request For Comments:
|RFC2365||BCP||Administratively Scoped IP Multicast|
|RFC2588|| I ||IP Multicast and Firewalls|
|RFC2776|| PS ||Multicast-Scope Zone Announcement Protocol (MZAP)|
|RFC2770|| E ||GLOP Addressing in 233/8|
|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|
Current Meeting Report
9:00 Dave Meyer did agenda bashing. No further points requirested.
9:10 Mike McBride presented MSDP BCP, draft-ietf-mboned-msdp-deploy-01.txt added
security section since -00 of the draft, Bill Bickless did work on filtering.
Dave raised the question wether the BCP would at one point be updated to include
scenarios for the current (-13/-14) version of the MSDP spec. Mike explained
that the current version of the BCP only addresses recommendations for currently
deployed -0x versions. Dave asked wether the normative reerences in the BCP
would need to be resolved. Randy said that as long as the references are not
refernced for implementation, this would not be an issue.
9:17 Bill Bickless presents draft-nickless-ipv4-mcast-unusable-01.txt. The draft
addresses which multicast group and active source information needs to be
filtered intra- and inter domain. Additions from mailing list proposed for -02
of the draft: Add Sun NIS+, nbc-pro, HP Device Discovery, BSD rwho. Refereces to
Bill Manning's DSUA Document. Randy Bush pointed to another draft
Dave asked about deprecated ip multicast addresses. He wants to take that
section and stick it into the address assignment draft/next version RFC. Yiquin
raised the question of flooding based on layer3 addresses by newer hardware.
Collin warned that there is a difference between tactical filtering because of
broken applications and the longer term structural filtering needed, and that
this should be explicitly pointed out to avoid longer term filtering of tactic
filters. Dave proposed that the non-allocation of global addresses to private
applications should be described on a way in the document that would allow the
IANA to refer to it whenever such requests are brought up by application
developrs. Toerless suggested that BCP information for default admin scope
ranges beyond those defined in the current address asignment RFC should be
Dave agreed that this document should become a working group document.
9:38 Dave reported from the MSDP Design Team -- SOW. Nothin happened. MSDP
draft-13 is not bacward compatible, which violates a fundamental design
principle. Caching was brought in. Dave Thaler wanted to have a section written
on notification which Dino wanted to be simplified. Peer RPF rules and their
wording is discussed over and over again. Generalization of mesh-group
forwarding rules especially the cross-mesh-group forwarding rules are discussed.
Default route (default peer) was brought in. SA request language is contentious
(brought into the spec early by Jeremy - wanted to build a cache box to request
SAs)). Language on MRIB and RPF route was discussed but nobody felt comfortable
to provide more expicit detail. MP/MPP notation in the peer RPF riles. Maximum
MTU was changed. Other problems ??? Encapsulation, sending of initial packets,
Discussion: Toerless suggested that the above list and details should be written
down in a "History of MSDP" text/rfc. Toerless asked why there is no
experimental RFC for the implementations that are out there working and
interoperate with each other. Dave responded that nobody has written that draft,
and that he is not going to write it because of the amount of work involved.
Randy said that the MSDP RFC process is not going anywhere, and that this was
the opinion in the IESG. Bill Nickless reminded that one of the issues with MSDP
is that it tried to realize the RFC1112 service model with too much effort and
for this reason failed to deliver. Dave reminded that if a
current-implementation RFC is to be published the question about the above
raised points is still open and needed to be answered in some way or the other.
Peter Lothberg suggested to open a working group to define the components for
content distribution with IP multicast being one of them.
Lorenzo said that MSDP paths can today not be used for reliable multicast paths.
Interdomain exchanges are also a problem independent of MSDP.
Dave summarized on proposed actions:
1. Need to publish -06+ draft (MSDP wg agenda). Bill and Mike volunteered to put
2. MBoned should put together recommendations for the IESG in the form of the
gap analysis (MBoned agenda).
This was agreed upon by the WG.