NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Chair(s):
David Meyer <dmm@cisco.com>
Operations and Management Area Director(s):
Harald Alvestrand <Harald.Alvestrand@maxware.no>
Bert Wijnen <wijnen@vnet.ibm.com>
Operations and Management Area Advisor:
Harald Alvestrand <Harald.Alvestrand@maxware.no>
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 will be 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:
- Deployment of multicast routing in the global Internet.
- Receive regular reports on the current state of the deployment of mbone technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various MBONE technologies (e.g. PIM, DVMRP, CBT).
- Based on reports and other information, provide feedback to IDMR.
- 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 global MBONE.
- Development of guidelines to improve the use of administratively scoped multicast addresses.
- Develop mechanisms and procedures for creating and maintaining a MBONE topology database.
This working group will initially interact closely with IDMR. It is believed that, once hierarchical multicast routing systems are specified and deployed, the working groups will diverge somewhat. Finally, note that in the below 'Goals & Milestones', the type of RFC will be subject to discussions within the working group.
Goals and Milestones:
Sep 96 |
|
Submit Internet-Draft on inter-provider coordination of the deployment of pruning mrouteds. |
Sep 96 |
|
Establish initial charter, goals, and long-term group agenda. |
Jan 97 |
|
Submit Internet-Draft outlining requirements for the existing MBONE infrastructure. |
Apr 97 |
|
Submit Internet-Draft specifying the use of administratively scoped multicast addresses. |
Jun 97 |
|
Begin work, with RPS WG, on extensions to RPSL to describe multicast routing policy. |
Jun 97 |
|
Subnmit Internet-Draft specifying the use of aggregation for DVMRP (and, in general where applicable). In addition, address the use of DVMRP default. |
Sep 97 |
|
Submit Internet-Draft specifying the use of native multicast where appropriate (e.g. exchange points). |
Sep 97 |
|
Begin work on document of co-existence strategies for IPv4 multicast and IPv6 multicast. |
Dec 97 |
|
Begin work on a document describing the deployment of inter-provider hirearchical multicast routing coordination (or, when available). |
Internet-Drafts:
Request For Comments:
RFC |
Status |
Title |
RFC2365 |
Administratively Scoped IP Multicast | |
MBONE Deployment WG (MboneD)
Monday, December 7 at 1930-2200
Tuesday, December 8 at 1545-1800
Chair: David Meyer <dmm@cisco.com>
AGENDA:
Monday, December 7 at 1930-2200
· Introductions/Agenda Bashing 10 minutes
- Meyer
The working group opened at approximately 19:30 and a volunteer was requested to take minutes.
· Resolve Status 10 minutes
The chair proposed a last call for the following informational draft. However, a poll of the audience indicated that only one person had read the draft. The chair decided to provide the group with an opportunity to read the draft and comment on the mailing list. The last call was postponed until next week.
R. Finlayson, "IP Multicast and Firewalls", draft-ietf-mboned-mcast-firewall-01.txt, August 1998.
· New Documents
- B. Quinn 30 minutes
Bob Quinn began the following presentation at 19:34:
"IP Multicast Applications: Challenges and Solutions", draft-quinn-multicast-apps-00.txt, November, 1998.
Slide 1: ID Motivation & Purpose
Slide 2: Motivation for the Internet Draft
Slide 3: Purpose: Informational Draft draft-quinn-multicast-apps-00.txt
Slide 4: Ultimate Goal
Slide 5: Scope
Slide 6: Multicast Application Taxonomy
Slide 7: One-to-Many Applications
Slide 8: Many-to-Many Applications (not comprehensive)
Slide 9: Many-to-One Applications
Slide 10: Multicast Application Requirements
Slide 11: Heterogeneous Receivers
Slide 12: Reliable Data Delivery
Slide 13: Multicast Security
Slide 14: Observations
Slide 15: Evaluation
The excellent presentation was completed at 19:52 and there were no questions.
The chair requested that the working group members read the draft and make comments to the mailing list.
- Roger Kermode 30 minutes
Roger Kermode began the following presentation at 19:55:
"Scoped Address Discovery Protocol (SADP)", draft-kermode-sadp-00.txt, November, 1998
Before the presentation began, the author acknowledged that the MboneD working group may not be the correct venue.
Slide 1: The Problem
Slide 2: Interesting problem, why do we need this?
Slide 3: SADP is a strawman protocol
Slide 4: Complicating Factors
Slide 5: Solution
Slide 6: Packet Formats: SADP Header
Slide 7: SADP Request & Response
The author polled the audience to find out if anyone thought that the work was a bad idea. No one responded. The author then asked if the work should be continued. Two or three audience members indicated that the work is worth further investigation.
Several questions were asked (paraphrased):
1) Address offset for requests and responses?
Answer: "<???? author's response not captured>"
2) How many different kinds of things (applications) will you support? How many different addresses?
Answer: "Currently used in 2 or 3 applications (SRVLOC and Resource discovery)"
3) In order to use this, you must trigger the address allocation. How do you prevent two different scopes (areas) from allocating the same address?
Answer: "Agreed that this problem needs to be addressed"
The presentation concluded at 20:09 when no more questions were raised.
The chair noted that the working group was ahead of schedule. An ad-hoc presentation by <???? need name of presenter> on using SNMP tools for debugging and monitoring multicast drivers.
Topic: SNMP monitoring of multicast drivers. Wanted to share the experiences to see if the problems are consistent amongst developers. Mostly interested Multicast broadcast.
The presenter pointed out that the Multicast MIBs are protocol specific For example, the PIM MIB.
The presenter wants to extend the MIB to include:
MIB table
For PIM
add SPT Bit
add RP Bit
Assert
nexthop PruneReason
Questions from the audience: Do you think that the extensions that you have in mind can be generic or Protocol specific?
Answer: "Protocol Specific"
Comment: To release a document in the IETF, you have to enumerate all permutations.
Question: are these in the current MIB?
MIB authors comment: These enhancements will increase the size of the MIB and that is the reason that they are not there now. If there is interest, then there will be no problem adding the entries.
Comment: In hindsight, it is obvious that this stuff is useful. Should there be a Requirements Document for MIBs?
Comment: One possibility, add the protocol field to the router MIB?
Answer: "Opaque values may be problematic"
Comment: OID can be used to refer to another MIB?
Chair: OID may be deprecated
MIB authors comment: Interfaces MIB was deprecated due to ambiguity of <???? Missed phrase>
Chair: How do you want to proceed? Draft MIB requirements for protocol specific extensions?
Chair: Can we make any of this generic?
Comment: It is hard to change MIBs. It is agreed that for debugging, if it is printable from the router, we want it in the MIB. How do you solve this problem when the scale is so large.
Response: "Should I act as advocate?"
Chair: It depends on the utility we are trying not to re-invent principles.
Response: "If you use it in the router, put it in the MIB. But, this is a lot of information!"
The presentation and questions concluded at 20:26.
The chair proposed that we amend the agenda and continue. He polled the audience to see if anyone from the next session was ready to proceed. Steve Shultz responded with his presentation.
Tuesday, 8 December at 1545-1800
· New Documents (Cont)
- Steve Shultz 30 minutes
Steve Shultz began his presentation on the following at 20:28.
"Multicast-Friendly Internet Exchange (MIX)", draft-lamaster-mix-00.txt (not yet posted).
Slide 1: NASA Ames Multicast Exchange (ARC MIX)
Slide 2: Objectives
Slide 3: Elements of MIX Architecture
Slide 4: ARC MIX Architecture
Slide 5: network diagram of AMES Internet Exchange
Slide 6: Routing - BGP4+
Slide 7: Multicast Forwarding
Slide 8: Active Sources
Slide 9: Medium - FDDI
Slide 10: Miscellaneous
There were several questions and comments which concluded at 20:39.
· Deployment Update 30 minutes
- Various
The chair requested a poll of people doing deployment and requested ad-hoc presentations of experiences.
The chair gave the floor to Peter Lothberg of Sprint.
Peter discussed Sprints currently deployed networks. There are two networks, one in Palo Alto, California and one in Pensauken. The networks currently use PIM Dense Mode and have been working well for approximately one year. Peter described Sprints experience setting up an ISP with multicast and there was some discussion of PIM Sparse Mode. Peter noted that Sprint is considering making this a product and it could be a useful service next year. Peters discussion concluded at 20:45.
The chair gave the floor to Danny McPherson of Qwest at 20:46.
Danny started by stating that there are code issues in the core. MSPP for RP and that they are looking at multiple RPs for load balancing. The main application is video conferencing. Dannys discussion concluded at 20:48.
We discovered that operational and support education is a problem because no tools are available. We used tunnels to pretend to be a user.
A request for tools for operational support and trouble shooting was proposed. The MboneD handbook was updated recently to address this issue.
Puneet Sharma with HP labs noted that they are working on OpenView support for Multicast. Contact Puneet Sharma at puneet@hpl.hp.com for access.
It was noted that a headless VAT will send RTCP back. Another audience member requested a tool to send an arbitrary RTCP stream. Another audience member said that we need an "rtpping". Another noted that a number of these applications are real and already have RTP traffic.
Tool will send RTP streams to any arbitrary device.
The chair polled the audience for any additional agenda items. After no response from the audience, the session was closed at 20:53.
MBONE Deployment WG (MboneD)
Tuesday, December 8 at 1545-1800
Brad Cain: Source Access Control for Bi-Directional Trees
Receiver initiated:
Adv. (S,G) entries in SAP use IGMPv3
Encryption Policy in networking devices
Access lists best for small #srcs per group don't trust rxrs or potential senders
Restricting sources is easy with PIM-SM just have RP filter
mjh: just filtering @ the RP isn't enough - rxrs of group can join to another source with igmpv3 so depends on what kind of policy you're trying to implement
Bidir: no central place to filter
Create central point to keep list
distribute list down tree
Also what kind of policy do you want to be able to create? e.g. one src, list of srcs, any src in domain foo
"Push" Method - distribute policy to all routers on tree - not very scalable (might be OK for 1->many)
Other Methods
3 questions:
Where does policy live?
How to find the edge?
- edge router to a source should enforce policy for that source
- note that the edge is a trust boundary - customer border or exchange point
How to avoid constant lookups?
Source Access List State
Can keep access list at root domain - use some kind of query when you hear a new source
How far do you push the policy? Joining the tree? Non-member senders?
Mark group in G-RIB as "1->many" - causes tree to become unidirectional pointing downwards.
- but senders in a transit domain can still send to their subtree
sd: stepping back: what's the concern?
Unauthorized traffic: some jerk sending to a group I'm a member of is parallel to some jerk sending traffic to my unicast address and so maybe this is a more general problem that is not multicast-specific
bc: but people are scared of multicast
Finding the Edge
Don't want other routers to repeat a check that's already been performed
How do you decide to enforce?
- directly connected
- only one AS in AS-path
Policy requires (S,G) state at enforcing routers
- only at enforcer, which is the first "good guy"
Avoiding Lookups
Strawman: install (S-prefix, G) "cache resolve" entries for sources that I might have to filter; install (S,G) entries for good guys and maybe negative (S,G) entries for bad guys; (*,G) entry will handle all others.
Arbitrary Sources
- Encapsulate using PIM-SM like register mechanism to check sources at core
- If source is allowed, then forward down the tree; if not, send "reg-stop"
dt: some domain is setting the policy - but the prefix in the G-RIB may be aggregated - the root of the tree may fall back to the shorter prefix if the longer prefix goes away and the policy might end up getting enforced by someone else
Future Work
How much policy is enough?
What additions are necessary to implement policy?
Additions to BGP to carry all this info around
Beau W.-arbitrary sources: less interesting for ISP - but must address this case for the enterprise anyway
Dino: use source trees in BGMP for source access control group-range gets attribute - don't forward anything on bidir tree
Brad: want to use attributes in G-RIB to specify policy
Dave T.: if you have a g-prefix allocated but not advertised, you can't join on the shared tree - no need to mark it.
H. Alverstrand: access control -> RTCP doesn't work
Dino/Dave: BGMP can work if nobody ever joins the shared tree and people only join source trees
Brad: (S,G) could be optional in BGMP
Dave: we can do whatever
Dave Thaler - Discovering Scope Nestings - follow up to Roger Kermode's talk yesterday
Results of thaler, handley, kermode discussion
Some nestings are static - don't need to be dynamically discovered
XXX Reminder to wg: RFC2365 needs an AS scope - bigger than local scope and smaller than global
Start with Link < local < AS < Global
MZAP has "Big" vs. "Small" bit; link-local <= local <= "small" <= AS < "big" < Global
Q: Does "small" <= AS < "big" always hold true?
A: If "Allocation scope" != "AS" then it's "small" <= "Allocation scope" < "big"
HA: what's an AS? some isps use lots, some use confederations think about how they're used -- issue for the group XXX
Casner: "routing domain" is the boundary we want This boundary is the MASC boundary
dmm: HA's point is well taken
3 possibilities of overlap: "inside", "common border", "overlap"
No single router can tell which is which
Comparing information you can deduce answers
Border router for scope Y can say "X is not in Y" if border router is in X but not border router for X
If nobody says it doesn't nest then it does nest.
-> Need an "X is not in Y" message - in MZAP?
deering: how do you know when you've got all of the right info?
"X not in Y" irrelevant outside of overlap, and might even be wrong outside of X relay across local scopes inside overlap, like ZAMs are ZAM msgs need to relay across boundaries anyway, but this relaying needs to modify the message, not just append to the end - more complex processing
Else add new message which you can just drop.sent periodically, with suppression
dino: want to put info in packet about stuff that's been dropped worried about tracking down who took the info out e.g. if they're doing it wrong
roger k: other ways to get the info across - modifying ZAM msg might not be a good idea for other reasons
New packet format: NIM - Not Inside Msg
MZAP hdr, identifies Y, and then an address which identifies the scope X to complete the statement "X is not inside Y"
Open issues:
- When can you decide that X does nest inside Y (deering's Q earlier) especially since this info can change - network partitions, configuration changes, ... reasonable time? ("days"?)
How does app learn these nestings? MDHCP?
What if config changes? (Related to 1st one?)
brad cain: partition or reconfiguration change - triggered updates
deering: you can't trigger "X is now inside Y"
liming: What are goals for knowing the nesting of groups?
kermode: to enable expanding zone searches
liming: Why can't you just use all scopes?
kermode: if you know nesting you can derive ordering - large to small
mjh: what apps really want to know is # of rxrs in a zone; ordering approximates that
liming: still don't know what info could be used for
mjh: useful for various
deering: if you had lots of overlapping scopes, it'd be nice to skip overlapping scopes when searching
mjh: robustness - routers give 3rd-party reports to cope with partial connectivity - but that was pretty complex this is simple and "good enough"
Discovering Scope Nesting
Scoped Address Discovery Protocol (SADP)