NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99
Chair(s):
David Meyer <dmm@cisco.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <wijnen@vnet.ibm.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:
· Multicast Debugging Handbook
· Multicast-Scope Zone Announcement Protocol (MZAP)
· Scoped Address Discovery Protocol (SADP)
· Multicast-Friendly Internet Exchange (MIX)
· IP Multicast Applications: Challenges and Solutions
· Justification for and use of the Multicast Routing Monitor (MRM) Protocol
· Using MSDP to create Logical RPs
Request For Comments:
RFC |
Status |
Title |
RFC2365 |
Administratively Scoped IP Multicast | |
RFC2588 |
IP Multicast and Firewalls | |
Agenda Bashing
MadDogs Update
Deferred by Meyer
GLOP Draft Status
- draft-ietf-mboned-glop-addressing-00.txt
- 233/8 with AS in middle 2 octets
- 233/8 assigned by IANA - runs out in June, can be renewed
Update:
transition from GLOP
GLOP addressing in 233/8
WG last call
Thaler: Why look at this for 232/8 - Is 64 bit addressing an issue?
Meyer - possible that there may be single source models that don't use extended addresses. (not ESL model)
Meyer - We should *not* move GLOP to BCP for now.
Ron Roberts - can we determine which addresses are generating high bandwidth?
Meyer - not addressed yet - submit a draft.
Randy - conflict between last call and the experimental nature of address space
Meyer - leave it experimental.
Anycast RP draft status (DMM slides)
- name change - foo-anycast-rp-00.txt within a domain, deploy more than one RP for the same group range give each RP the same IP address assignment
- anycast address sources and receivers use closest RP
sources known RP-RP via MSDP (convergence slide)
.
Lots of deployment (i.e. Sprint)
.
PIM-SM slide (Sprint)
generic anycast approuch (level3 DNS servers)
(unknown) ? about MSDP events of last week
DMM - SA storms caused by SA looping - caused by ability to set defaults routes - instance of mis-configuration causing storm ... (blah)
need tools (peer-RPF for upwards trace)
Comments:
Pusatari - Terminolgy a problem
Pusatari:
Section 6.2 interactions
single-homed MSDP speaker always accept ...seems like a bad thing
doesn't say which address to use - some practices active but not documented
6.2.4 default peers - what are default peers? seems like a bad idea
6.2.4 - bad because it shuts off split horizon
Dino - can't do default route since you might not be directly connected to MSDP peer -
Pusatari: could tunnel
resolution - take to MSDP working group will import MSDP desicions back into this group
MRM status: (Kevin Almeroth)
- mrm manager
- mrm agent
o Test Sender (TS)
o Test Receiver (TR)
heartbeat
- message types (TSR) (TRR)
- TSs generate packets (DT - packet ? contol or data? - KA - data)
- TRs are polled or generate alerts (loss thresh)
- beacon messages refreach state
o can also updaye (unreliably) state
Operation:
key is holdtome
- tells sender how long to send
- tells R how long to listen
mechanism
- TRs start test when hearing 1st packet or after timeout value specified in the TRR
- holdtime of 0 stops test
Goals:
intra-domain management tool (NOC)
- reachablity combined w/other tools
inter-domain in the style of sdr-monitor
Status:
- new draft
- growing vendor support
o cisco version in S code train
o Nortel & Junier in the works
- End host implamentation
o imj.ucsb.edu/mrm/
- manager support in development (mmon)
Changes:
- name change "reachablity"
- admin changes + clarification
- add a length field (16 bytes - 2048 kbytes)
- monitoring existing groups is put on hold
- support for beacon messages is optional in the manager
Open Issues:
- best way to do security (?)
- how to monitor existing groups
- NACKs for TSRs/TRRs
o needed for inter-domain or dynamic conditions
- better support for alternate packet types
- good justification in the face of SNMP
Questions:
Thaler:
- Keep thinking about SNMP (answers 1st 3 bullets)
- read RTP MIB (common goals)
- recommend: framework independent of control protocol
Fenner:
RTP MIB has support for TR could evolve to supporting all MRM requirements (TS etc.)
Fenner: Not sure what linkages - but will be backwards compatable
Almeroth: DT what piece of draft do you want moved to an archetecture?
Thaler:
- Abstract out transport, security model, test data format and
- TR/TS model. Examine the transport protocol in seperate doc (RTP MIB integration)
Fenner: Agree with Thaler
Connecting Multicast Domains (Brad Cain):
draft-cain-mcast-connect-00.txt
Intro:
providers PIM-SM/MSDP?MBGP
enterprises
- PIM-DM/DVMRP
- MOSPF
- PIM-SM
describes options
- Border Routers
cache architecture
protocols submit (s,g) forwarding entries to shared table
.
several ways to bring transit sources into stub domains
- domain wide reports
- recievers are senders heuristic
(*.*.RP)
MSDP on boarder
Flood-and Prune protocols
Stub transit examples (see slides)
PIM-SM to PIM-SM
enterprises use as intra-domain routing protocol
connection options are
- standard MSDP MSDP to provider
- stub domain may use providers RPs
- stub domain becomes extension of provider PIM domain
- may have its own RP for admin scoped addresses
Comments
Thaler: Unfortunately, admin scoped domain not allowed in PIM2.
Cain: Filter RP data sets at the border
Thaler: Need a draft in PIM WG - I'll help.
MPSPF in stub
easy to connect because
- group LSAs provide global group membership info - >>
MOSPF
Summary:
need comments on draft
- dvmrp<-> MBGP
- default route use in stub
section on BiDir tress
- BGMP and PIM-SM bidir
publish as informational doc
SDP and Multicat scoping (Colin Perkins)
Problem
SDP containd a mc address
Solutions
- announce session w/ SAP
- include a scope indentfier
How to choose the scope identifier
MZAP has a scope name would require
- manditory
- name allocation
MZAP zone ID
- unique (may change w/time)
- may be static enough best option now
Concluding
- problem that needs solving?
- use zone ID
- any alternatives
Le MUR - Multicast relays in firewalls
(Carsten Bormann)
RFC2588
- don't let bad packets in
- don't let confidential packets out
Unicast considerations
- need to be able to talk back to source
a. multicast everything
b. allow unicast path back
- external sources - need dynamic hole punching address translation
o little need to translate multicast addresses
o translate unicast address
Running firewall:
Packet filters
- can't unicast back to source
- rewrite source address (NAT)
- use HTTP for feedback (protocol change)
Proxy firewalls
- terminate in firewall
- run internal instance of mc
- translate between domains
- need way for proxy to represent multiple internal members
Multicast relays
- RTP translator idea
- relaying destroys sender addresses
- congestion control info
Unicast relay
- NAT/PAT translate between service models
None received.