Last Modified: 2004-09-07
|Done||Submit I-D on inter-provider coordination of the deployment of pruning mrouteds.|
|Done||Establish initial charter, goals, and long-term group agenda.|
|Done||Submit I-D outlining requirements for the existing MBONE infrastructure.|
|Done||Submit I-D specifying the use of administratively scoped multicast addresses (RFC 2365)|
|Done||Submit I-D specifying the use of native multicast where appropriate (e.g. exchange points).|
|Done||Submit I-D on IP Multicast and Firewalls (RFC 2588)|
|Done||Submit I-D specifying static allocations in 233/87 (RFC 3180)|
|Done||Submit I-D on debugging multicast problems.|
|Done||Submit final version of scope zone announcement protocol (MZAP RFC 2776)|
|Done||Submit final version of scoped address discovery protocol (SADP)|
|Done||Submit I-D describing ISP multicast deployment practices|
|Done||Submit I-D, with RPS WG, on extensions to RPSL to describe multicast routing policy|
|Done||Submit I-D describing extended allocations in 233/8 (RFC 3138)|
|Done||Submit I-D describing IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171)|
|Done||Submit I-D describing IP Multicast Applications issues (RFC 3170)|
|Done||Submit I-D describing Anycast (RP) mechanism (RFC 3446)|
|Done||Submit I-D describing Source-Specific Protocol Independent Multicast in 232/8|
|Done||Submit I-D describing MSDP Deployment Scenarios|
|Done||Submit I-D describing IPv4 Multicast Unusable Group And Source Addresses|
|Done||Submit I-D describing Embedded RP for IPv6 Multicast Address|
|Apr 04||Submit I-D on PIM-SM Multicast Routing Security Issues|
|May 04||Submit I-D on IPv4/IPv6 multicast co-existence issues and strategies for IPv4 multicast and IPv6 multicast|
|Jun 04||Update IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171/BCP 51)|
|Jun 04||Submit PIM-SM Multicast Routing Security Issues to IESG for Informational|
|Jun 04||Submit MSDP MIB to IESG for Experimental|
|Aug 04||Submit IPv4 multicast address allocation procedures IESG for BCP|
|Aug 04||Submit IPv4/v6 co-existence strategies to IESG for Informational|
|Aug 04||Submit multicast roadmap/reference architecture document to IESG for Informational|
|RFC2365||BCP||Administratively Scoped IP Multicast|
|RFC2588||I||IP Multicast and Firewalls|
|RFC2770||E||GLOP Addressing in 233/8|
|RFC2776||PS||Multicast-Scope Zone Announcement Protocol (MZAP)|
|RFC3138||I||Extended Allocations in 233/8|
|RFC3170||I||IP Multicast Applications: Challenges and Solutions|
|RFC3171||BCP||IANA Guidelines for IPv4 Multicast Address Assignments|
|RFC3180||BCP||GLOP Addressing in 233/8|
|RFC3446||I||Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)|
MboneD IETF 61 8 November 2004
Chair: David Meyer
David Meyer - time is tight, so let's move fast
A new topic is Multi Point LSP's - MPLS Multicast
Brief discussion on drafts in progress :
Ideas for keeping SSM and ASM traffic separate on real networks. Waiting on normative reference for the PIM spec
Embedded RP has gone through the IESG and is on track at the editor queue
Mroutesec - Also in the editor queue
This needed a waiver for MSDP (an experimental spec is not generally allowed as a reference in a standards track document ) and is waiting on the PIM spec.
IPv6 multicast issue draft - waiting on the AE to approve for the IESG or bounce.
It is now out of the WG.
Note that several specs are now being held up by references to the still unfinished PIM spec.
Tom Pusateri - the PIM spec is waiting on a few details and needs some volunteers to finish
Bill Fenner - this is making as much progress as usual (i.e., none).
Some changes were promised but now I have forgotten what they were.
Action Item - remember what is needed and ask the group to approve them.
Tom Pusateri - AMT draft
AMT is a way to have an AMT gateway discover a path from a non-multicast site to a native multicast domain
3 way membership handshake has been added, plus a 32 bit nonce based on discussions in Seoul.
Why do this ?
Content providers should drive this
- first at server farms
- also providers who have multicast enabled upstream provider
3 way handshake
AMT Request with a gateway NONCE (GNONCE) from the gateway
Relay creates a RNONCE from the hash of a secret with the gateway nonce and the group address. It sends the GNONCE and the RNONCE to the gateway
the gateway sends back the GNONCE and the RNONCE and the ????
Need - a /16 prefix to deploy and try to do public relay for BGP and anycast
Pusateri has FreeBSD gateway / relay code ready for testing.
He wants providers who can provide test relays
Toerless Eckert :
Why do we need yet another tunnel mechanism ? Why not IPSec ?
Or another existing tunnel protocol ?
Pusateri - this is based on the IPv6 6to4
This uses the existing tunnel mechanism of 6to4
Dave Thaler - this has been asked in the past. The difference is primarily at the server end. The primary benefit is on the server side
Toerless - I would not worry about the scalability Hopefully this will lead to adoption, so it is not clear why scalability is an issue, and deployment will be self limited.
I do not think that the difference from this and existing tunnels is that essential.
Pekka Savola - it is
Toerless - if you cannot provide at least 200 to 300 kbps per tunnel, what is the point.
Pekka Savola - for DSL aggregation, there can be a lot of L2TP
Isadore -- This does require state per client per stream. This cannot be escaped
Dave Thaler - but there is not state for idle clients
David Meyer - If you want to see other encapsulations (i.e., existing tunnel mechanisms) used for this purpose, you need to make an objection and write a draft.
Unicast prefix based multicast addresses.
People ask - "Is there interest in this ?", so I sent out a message to group. No responses as yet.
This is not intended to replace the IPv4 GLOP space system, but to extend it.
Is there interest - so I asked the group, is there still interest. There is very little work to do.
Toerless - We should use SSM for interdomain multicast. This draft leads in the wrong way. This also needs a lot of address space - a complete /8
Pekka Savola - It is important to note that you get one address per/24, which is not a lot.
David Meyer - Let's take this to the list.
Pekka Savola. I notice that there is not yet a current and up to date documentation for multicast addressing. There are some confusing or even wrong earlier documents.
IANA also needs something to point to when people request multicast address from then.
I have separated assignment from allocation
Multicast address discovery is an open question but in practice is not being done.
Is making RFC2908 historic appropriate.
My question to you is - would this be a useful document ?
Toerless - this would be a nice BCP
It may be that "architecture" should be removed from the document.
Pekka Savola. I think that your interpretation of "architecture" is a little more formal than mine.
Toerless - It is
Mark Handley - As an author, I think the RFC2908 should be replaced. The word architecture should be kept in the title so that people looking for the old one will find this one.
Multicast source discovery for SSM
For the one to many model, sources can be discovered out of band
For many-to many or many to one, need source discovery
Why in the host ?
This can be deployed rapidly and co-exists with existing SD protocols
No RP's are needed, and there is no traffic
New source sends MSDP to a group controller.
This can be implemented in the network or in the edge hosts
Toerless - do all of the channels have to use the same G ? You should not
try to restrict all of the channels to use the same G.
Colin Perkins - what problems does this solve ? If I am using ASM for service discovery, then
Colin - I cannot see any applications that can use this.
Steve ? - The idea here is that you can announce the (S.G) for SSM. Is there a standardized way to do this ?
Colin : SIP
Toerless : It would be useful if Colin could give a presentation to describe how do this. Or write a draft.
Colin : There are 3000 pages of RFC that describe this
Toerless : That's too many pages for this purpose. Write us a draft.
Steve - I have applications that I know how to do this with ASM. I would like an easy way on how to do this for SSM.
Colin - Go and talk the SIPPING working group. That is what they do.
"Well managed IP multicasting"
Network operators want to
- build efficient networks
- create value added services
- build manageable networks
IGMP / MLD does not provide accounting
Network cannot identify or authenticate or authorize users or keep track of usage
This is not sufficient for carrier class services (high quality premium or fee based).
Content providers also want this
Dave Thaler : Are the existing mechanisms sufficient ?
Pekka Savola : I think that existing ISPs can do all of this using existing mechanisms
Haixiang He : Layer 2 authentication is not good enough as the link account provider and the content provider may not be the same party.
Dave Thaler : Layer 3 solutions involving only
IGMP and MLD are not at the right layer. For the last hop L2 mechanisms are a much better fit. If you are talking about end to end then I can agree that this is necessary. You might want to remove the IGMP and MLD from this discussion.
We need to make it possible for network operators and content providers cooperate and both make money. They need to share revenue, and this means that they need to measure usage. Content providers are not good for networks and network providers are not good for network, They both need to cooperate.
I want to find out if the MBONED network
Dan Alveraz: MBONED needs to support different business models for multicast. I want the MBONED group to be a repository for all multicast work. I want to evolve this into a framework and requirements document.
Pekka Savola : I think that in general this work is useful, and that the current approach is not really useful. We need to take this one level to a frameworks and requirements draft.
Dan of Cisco - That is what this draft is trying to do.
David Meyer - How many in the WG think that we should take this on ? (Show of hands - a majority yes, but definitely some no.)
David Meyer - Let's shift gears to P2MP
This is in cooperation with the L3VPN group.
Generic issue - how do we set up multipoint forwarding paths.
This is just getting attention in the MPLS world.
- forwarding state vs tree construction cost
- efficiency of forwarding path
The last IETF there was the YCAI presentation for L4VPNs and MP-LSP's
Claim : This is still a multipoint tree building problem, and previous work should be leveraged. Same issues, some different
Several good attempts to describe a framework, but they also include a solution, which muddies the waters.
Can the group come up with a framework via IMDOC ?
I propose that we produce a framework draft and requirements draft and cleanly separate those two.
IMDOC and MBONED are focused on functional proposals into a logical architecture
Yakov Richter - You mentioned a need to work on a requirements document.
There is ongoing work in L3VPN for multicast requirements.
There is also a L2VPN requirements document in existence. What will this third requirements document service. Requirements document makes sense in the
John Meylor - One thing that would be useful is some requirements between them. I think that the best thing for MBONED is to extract the common points out of this.
Nudula - I think that the applications group should have a requirements document. If they feel a need for multicast help, they can come to the appropriate multicast working group.
Ne Ching from Cisco - The multicast requirements document should include MORE than just the particular and specific requirements for each particular area (such as L3VPN
Toerless - what we have is a service model. RFC2547 and other architechtures are coming up that have no common frameworks
Yakov. Talking about a service model in the abstract is pointless unless you talk about the particular service.
David Meyer - Last one
George Swallow - firstname.lastname@example.org
Within MPLS, some people are interested in point to multipoint distribution of large (video) flows with QOS and high availability
The MPLS mentions multicast but "I am not sure that that sentence is parsable."
Dino F started this work, but it has gone fallow and needs to be restarted.
MPLS is NOT chartered to redefine or replace IP multicast
P2MP TE - exists below the IP layer
How the set of destination s is determined is outside of the scope
Iit may be useful to extend PIM and or MBGP to handle P2MP TWE tunnels.
This is not the job of the MPLS WG
We are chartered to think about requirements but not to resolve them.
Eric - I think that your charter is defective
Swallow - When the charter was broader, we got a lot of bozons involved who wanted to re-define everything
Mike McBride - The PIM charter says that PIMWG will act as consultants for proposals for "PIM over foo". The area directors did not want us to expand our Charter until we finished our basic documents, which we have nearly done and now the area directors are willing to allow us to expand our charter.
Tom Pusateri - We are not _looking_ for new work in the PIM WG, but we will consider new requirements if they are brought to us.
Mike McBride - We are open to this, but we need some guidance from MBONED as to what we should do.
Seisho Yasukawa - P2MP TE
TE is used to provide QOS "guarantees"
MPLS is a suitable solution for this.
What is P2MP TE ?
A TE tunnel with one source and multiple destinations
This should be application agnostic.
P2MP TE tunnels should have unique P2MP ID's
Need mechanisms for tunnel establishment, teardown, failure reporting, call admission control, QOS, etc.
GMPLS should be applicable
LSP (Label Switched Path) variation on different LSP branches ?
Can short term data duplication be tolerated when there is tree modification ?
What are the limits and design targets?
P2MP solutions and properties based on RSVP
Features include ;
explicit source routing
tree is expected to show homogeneous QOS parameters
need means to delete parts of the tree without affecting other parts of the tree
Specific issues are still under discussion and we invite advice from the multicast community.
John Meylor - we need a complete survey of the different multipoint solutions that are available.
Yakov - That is an excellent suggestion, for the L2VPN or L3VPN working groups.
David Meyer - We wanted to have MPLS in this group as the multicast people were not providing input into those working groups.
Adrian Farrel - Detecting P2MP Data Plane Failures.
There is a need to create analogues of the traditional internet tools such as ping and trace for P2MP solutions.
For PING, the ping hits all of the egresses, and if it them all, it can flood the ingress.
Two solutions - rate limiting, or specifying a specific receiver.
Traceroute has a similar problem.
Dave Thaler - For multicast, the mtrace goes from the receiver to sender
Haixiang He - using mtrace the response is unicast
Bill Fenner - the group is specified in the request. It can be either unicast or multicast.
Documentation on multicast threats has been lacking. We just finished one document, but we need another for first hop multicast threats.
This falls between PIM and MAGMA working groups.
Dave Thaler - I think that this should be done in MAGMA and PIM as appropriate. These threats are not really protocol independent
David Meyer - We are talking about threat analysis, not the solution
Tom Pusateri - As we advance the PIM spec, we could and should include this in the PIM WG