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
-------------------------------
o Introductions/Agenda Bashing 10 minutes
-- Meyer
The working group opened at approximately 19:30 and a volunteer
was requested to take minutes.
o 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.
o 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
--------------------------------
o 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.
o 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"