BGMP met in one session at the Oslo IETF: Tuesday 5:00-6:00.

BGMP is a proposed new IETF working group.
Mailing list: bgmp@catarina.usc.edu
To subscribe: bgmp-request@catarina.usc.edu
Archive: ftp://catarina.usc.edu/pub/bgmp/mail-archive/

The meeting started with a summary of BGMP.  BGMP is an inter-domain multicast tree building protocol.  It builds bidirectional trees of domains, with a root domain per group determined by a table (likely to be a RIB propogated by MBGP, but that's a detail to be worked out).  Bidirectional trees reduce the dependence on the root for data distribution, and trees of domains reduce the dependence on any one node in a domain, allowing more flexibility in handling failures.  BGMP supports bidirectional or unidirectional shared trees as well as source-specific trees.

Dave Thaler gave a status update.  He covered two main items; the use of BGP path attributes and a brief implementation status.  As discussed in IDMR in Minneapolis, using BGP Path Attributes to perform designated forwarder election can eliminate a race condition that arises between the time a BGP route is learned and the BGMP designated forwarder election exchange occurs.  However, there was a strong feeling from the BGP community that it's not appropriate to have BGP perform per-link actions, particularly for a specific tree construction protocol.  Dave said that Rusty Eddy had some comments on handling the race condition which should get added to the spec.

The other proposed BGP path attribute, the directional annotation, seems more feasible, since it's more end-to-end and is likely to be usable for other tree construction protocols (e.g. bidirectional PIM).  Tree directionality needs to get added to the spec.

Bill Fenner gave an overview of BGMP and the attributes that make it appropriate for an inter-domain routing protocol; that presentation is available in the proceedings.

A discussion then followed.  The highlights of the discussion follow.

It was suggested that the transition architecture be a join work item for MSDP, BGMP and MBONED.  MSDP and BGMP should be involved because they are the protocols being transitioned from and to, respectively, and MBONED because transition is an operational issue so the operational multicast WG needs to be involved.  The MBONED mailing list will be used for this transition discussion.

An additional work item was suggested: constructing the rules for BGMP to interoperate in a shared forwarding cache on a single router using the architecture described in draft-thaler-interop.  This should probably be a seperate informational document. 

Rusty Eddy at ISI has a BGMP implementation and might be able to help with interoperability and protocol testing.

Two service providers raised issues:
Interoperability and coexistence with MSDP, since we know that MSDP will remain deployed for some time.
Since MSDP is our "now" solution, we don't want the BGMP "future" solution to interfere with resources (e.g. developer time) that should be committed to MSDP.

Deborah on "simulation" item on charter - "test" is a better word which could include simulation if appropriate.  ns has bidirectional tree stuff but it doesn't simulate any particular routing protocol.

Don't implement without a story on debugging (at least mtrace, i.e. at least as much as we have now).
"network management implications" in spec?
story on debugging infrastructure before real deployment

Action Items:
Could other tree construction protocols use designated forwarder elections from MBGP?
Rusty Eddy's comments on how to handle the forwarder election race condition should get added to the spec.
Tree directionality needs to get added to the spec.
Spec security section needs to get updated; many can be the same the BGP4 spec.
Slides
None received.
1.1.1	Multicast Address Extension & Simple Transmitter Opti (maestro) bof
Current Meeting Report

MAESTRO BOF, Dave Oran

AGENDA

History - modify multicast model, do we need a working group on this?

A number of people think if we simplify the multicast model there are significant benefits in reducing complexity. changes: addressing model, assume single sender.

We want to look at the problems today and see how proposed simplications might help.

Ground rules: talk about problems and how they map to the proposed simplifications.  from two perspectives, isp's and architectural view.


Bryan Lyles, Sprint Deployment Strategy

Today, multicast enabled, working with vendors and customers to make it work.  built on PIM-SM, MSDP, MBGP, IGMPV2, GLOP.

Short Term - push current protocols, work in ietf to enhance base.

Certain kinds of applications want single server (radio station, politician giving speech, dont want opposition heckling him)


Hugh Holbrook, Stanford/Cisco

Some multicast applications work well with unicast others its impossible, high data rates, many receivers questions to isp's - how do you bill for it.  make billing reflect cost.  so charge by size of group.

dmm - if i am a source, receivers on same isp are onnet, other receivers are offnet. want to billed for offnet folks.

brad cain - bill by bandwidth, can isp's break even on multicast.

Queries flow down tree, counts flow back up, somehow gather data to bill src.  access control for large groups, restrict senders in advance (pirates on tv station), important for commercial applications too.

kevin almeroth - why does it work with radio, lawyers are the answers, no one owns a multicast address, if they did you could sue someone for using yours without permission.

security - source provides passwd to receivers

www.dsg.stanford.edu/hollbrook/express


Jeremy Hall, uunet

Problems - scalability, single source model ok, hard to implement. you are trying to restrict something that is not restrictable. lots of protocols running as ships in the night, ok when it works, never know which one is not working correctly.  way too much ad hoc stuff going on. which protocol is broken.  nice to be able to trace a problem from the sender, to the receiver.  receiver says i'm not receiving this content.  have to figure out from that info, where the source is and what the problem is.

Some applications hide the group, so you cant figure out where to troubleshoot.  people dont understand how it works, so they cant help you debug.  need education.

Billing problems, counting receivers might be nice but is hard as groups get big.  onnet vs offnet.  tried to employ things that are parallel to unicast.  unicast routing tries to dump traffic asap, mulitcast wants to keep as long as possible.  current model doesnt scale.  anyone can source to any group and thats a security problem.  there are a lot of security issues with multicast.


Mark Handley, ACIRI

Internet Standard Multicast, where it came from and why it had nice properties.  direct extension of the unicast model, host sends packets to destination address, it gets there.  Nice architecure, senders dont need to know about receivers. recievers dont need to know who senders are.  distributed binding is useful resource.  senders and receivers dont need to know about topology, robust, route around failures etc.  hosts dont need to knows about routing protocool.  need distinction between service model and its implementation in the network.  separates what the application wants and how the network achieves it.  Clean separation of routing and transport/application layer.

What can we do with it:

Regular one to many applications - video distribution, data distribution many to many applications - conferening, games, dont know members in advance, distributed binding is very robust, changes the way you design applications (eg wb)

Many to few applications - server discovery

Scoping, used to have ttl scoping, poor for traffic engineering, great for self organizing applications, expanding ring search, we lost the ttl in pim, admin scoping getting it back, mzap

Security - can only restrict traffic safely with encryption. content providers want authentication, have the mechanisms already.

problems:

forwarding table size, aggregation helps some;
how can isp's make money;
lack of scalable routing protocol, bgmp, hierarchical pim,
bi-direction pim with grib, bgmp will probably work,
hierarchical pim too;
lack or good network management and diagnostic tools.

serious growing pains, transition from dvmrp painful

distributed binding a key - wb, sdr, mimaze applications

important to avoid constraining network mechanisms to support only one to many applications

Bryan - lots of differences of opionion in the community.
Hugh  - avoid overly commplicating things for futures applications when we have existing applications that need support now.


jon crowcroft, ucl, www.cs.ucl.ac.uk/research/rama

Enhancing deering multicast, enhancing the addressing scheme. class D address is a channel, not really an ip address. Anonymously names a group of receivers, allows anyone to send to it. alternatives, allow end systems to be explicit DCM/connectionless multicast - add list of addresses, transparency and fault tolerance


David Oran - Final Questions

we have 5 minutes, where should we go with this?

Brian Whetten - wishes had heard more from isps about problems.

TODO - decide which problems are of deployment and which are based on what we are deploying.

Scott Petrak - 3 things: think about low bandwidth hosts at the end,   like wireless; thing 2 i missed; small number of senders a worthy optimization.

Dorian Kim - deployment problems have been maturity of implementation issues and how to make all the hacks play together.  havent tried running native multicast at scales we want.  will find more answers as we deploy and ramp up, at this point probably not worth limiting model.

Hum votes
create a mailing list  2/3 hum
no mailing list          1/3 hum