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
David Meyer <firstname.lastname@example.org>
Operations and Management Area Director(s):
Randy Bush <email@example.com>
Bert Wijnen <firstname.lastname@example.org>
Operations and Management Area Advisor:
Randy Bush <email@example.com>
Scott Bradner <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 interconnects.
This is not meant to be a protocol development Working Group.
Goals and Milestones:
Submit Internet-Draft on inter-provider coordination of the deployment of pruning mrouteds.
Establish initial charter, goals, and long-term group agenda.
Submit Internet-Draft outlining requirements for the existing MBONE infrastructure.
Submit Internet-Draft specifying the use of administratively scoped multicast addresses.
Begin work, with RPS WG, on extensions to RPSL to describe multicast routing policy.
Submit Internet-Draft specifying the use of native multicast where appropriate (e.g. exchange points).
Begin work on document of co-existence strategies for IPv4 multicast and IPv6 multicast.
Submit final version of RP document
Submit Internet-Draft specifying static allocations in 233/8
Submit Internet-Draft on debugging multicast problems.
Submit final version of scope zone announcement protocol (MZAP)
Submit final version of scoped address discovery protocol (SADP)
Submit I-D describing ISP multicast deployment practices
Request For Comments:
Administratively Scoped IP Multicast
IP Multicast and Firewalls
Deferred by Meyer
GLOP Draft Status
- 233/8 with AS in middle 2 octets
- 233/8 assigned by IANA - runs out in June, can be renewed
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)
Pusatari - Terminolgy a problem
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)
- 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
key is holdtome
- tells sender how long to send
- tells R how long to listen
- TRs start test when hearing 1st packet or after timeout value specified in the TRR
- holdtime of 0 stops test
intra-domain management tool (NOC)
- reachablity combined w/other tools
inter-domain in the style of sdr-monitor
- new draft
- growing vendor support
o cisco version in S code train
o Nortel & Junier in the works
- End host implamentation
- manager support in development (mmon)
- 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
- 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
- Keep thinking about SNMP (answers 1st 3 bullets)
- read RTP MIB (common goals)
- recommend: framework independent of control protocol
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?
- 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):
- Border Routers
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
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
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 - >>
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)
SDP containd a mc address
- announce session w/ SAP
- include a scope indentfier
How to choose the scope identifier
MZAP has a scope name would require
- name allocation
MZAP zone ID
- unique (may change w/time)
- may be static enough best option now
- problem that needs solving?
- use zone ID
- any alternatives
Le MUR - Multicast relays in firewalls
- don't let bad packets in
- don't let confidential packets out
- 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
- can't unicast back to source
- rewrite source address (NAT)
- use HTTP for feedback (protocol change)
- terminate in firewall
- run internal instance of mc
- translate between domains
- need way for proxy to represent multiple internal members
- RTP translator idea
- relaying destroys sender addresses
- congestion control info
- NAT/PAT translate between service models