Last Modified: 2005-01-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 |
| RFC | Status | Title |
|---|---|---|
| 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) |
| RFC3956 | Standard | Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address |
|
MBONE Deployment WG (mboned) MONDAY, March 7, 2005 (0900-1130) ================================= CHAIR: David Meyer <dmm@1-4-5.net> MINUTES: Marshall Eubanks <tme@multicasttech.com> AGENDA o Administriva - Mailing list: majordomo@lists.uoregon.edu subscribe mboned - Scribe(s)? - Blue Sheets o Agenda Bashing 5 minutes Meyer o Review and status of work items Active Drafts ------------- draft-ietf-mboned-addrarch-01.txt 5 minutes Savola draft-ietf-mboned-auto-multicast-04.txt 5 minutes Thaler, et al. draft-ietf-mboned-ipv6-multicast-issues-02.txt 10 minutes Savola Expired Drafts ------------- draft-ietf-mboned-rfc3171bis-03.txt 5 minutes Meyer Potential WG Drafts ------------------ draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01.txt 7 minutes Durand draft-jdurand-ipv6-multicast-ra-00.txt 8 minutes Durand draft-lehtonen-mboned-dynssm-req-00.txt 10 minutes Venaas draft-savola-mboned-address-discovery-problems-00.txt 10 minutes Savola draft-savola-mboned-routingarch-01.txt 5 minutes Savola Status/Update ------------- Multicast VPN 20 minutes TBD TUESDAY, March 8, 2005 (1530-1630) ================================== CHAIR: David Meyer <dmm@1-4-5.net> MINUTES: Marshall Eubanks <tme@multicasttech.com> AGENDA o Administriva - Mailing list: majordomo@lists.uoregon.edu subscribe mboned - Scribe(s)? - Blue Sheets Status/Update ------------- Issues Related to Receiver Access Control in the Current 10 minutes Multicast Protocols draft-hayashi-rac-issues-00.txt Hiroaki Sato Accounting, Authentication and Authorization Issues in 8 minutes Well Managed IP Multicasting Services draft-hayashi-maccnt-02.txt Tsunemasa Hayashi Using SIP for Multicast Source discovery 14 minutes Eubanks Minutes ======= Greg Shepard is not here ssm232-07 is hung on the PIM - SM spec, as is msdp-deploy-5 Pekka Savola - Multicast Address Architecture Idea is a BCP for multicast addressing Document is close to convergence and it would be a good time for the group to read it, before it goes to WG Last call. Tom Pusateri - Dave Thaler's automatic multicast AMT -03 to -04 just came out with minor updates. Media Access Code is generated and verified by the same host, so the algorithm does not have to be standardized. An example technique was put in the spec, but it is not required. Added a UDP source port to MAC IANA has assigned 2268 as the port number for AMT Need a /16 prefix for an anycast address, to find relays. Some firewalls require that the host send traffic out to keep state in the firewall. IGMP refresh may not be frequent enough. They recommend making this a tunable parameter. Dave Meyer : I am going to get together with IANA today to discuss this. How many people are away of the TC BOF that is at 3:30 today ? There are a bunch of application specific automatic tunnel protocols floating around. People should go to this BOF to see if there is a way to use the multicast ideas to create a single tunnel standard. Toerless E : Isn't there also a problem with a multicast-like API ? Dave : That is one possible solution. Pekka Savola : IPv6 Multicast Deployment Critique in December was harsh but to the point. This was not reviewed adequately in the working group. Issues : Structure and purpose of the document is not clear enough. Comment by Allison Mankin that she was doubtful about further work on ASM, but embedded RP is already there, so ASM is not going away. Comment that SSM deployment issues are not IPv6 specific, but these do not appear elsewhere, and this document seems a good place for them. Directions : Abandon the work, or get more readers and reviewers. Dave Meyer : My Internet Draft, Some Issues for Multicast Deployment, has timed out a long time ago, but it could be revived. Many of these concerns are still there and are coming back, what with multicast L3 VPN's, etc. Toerless : Why does this have to be limited to IPv6 ? That would solve the SSM scope issues. Dave Meyer rfc3171bis-03 timed out inadvertently. This isn't really helping right now. The intent was to find the way to solve the problem of people asking for multicast addresses to solve the embedded application problem. I need to know from the group whether it is worth reviving. IANA gets two or three of these group address requests per week from application writers Marshall Eubanks - Does that mean that there really a lot more, 10 or 20 or more per week, as many people won't apply ? That seems like a lot. Dave Meyer : Some history. After Jon Postel passed away, IANA made some applications of multicast addresses, particularly to the NASDAQ. Now, every financial house comes to them and says, we need a class 16, and NASDAQ has space, so why can't we get one ? I say no, and I get overruled. Lenny Giuliano : Why can't IANA say, that was then, this is now ? Dave : That is a legal issue. IANA has exposure. Dave : With respect to GLOP and every other address application, I have built an address state web site that you should follow. I tell them to do that, and they just say no. We have not build a lightweight service discovery protocol that can be used in a embedded application devices. Lenny : What about SAP ? Dave : It's not reliable enough. Toerless : It's not as if we haven't gone through the motions before. Why not just charge for them ? Dave : That's the e-glop idea. We tried that, and we could never get it instantiate. Operations AD - I have talked to RIPE and they should be coming back to this. Steve Minas - I really can't understand why these people want global deployment. Can't we explain why this is not a good idea. Pekka : We can discuss this later. Even if we gave addresses to RIR to allocate, they would still go to to IANA. Dave : But then IANA could just tell them to go to the RIR, and that would be sufficient. [Audience Member] If people think that this is an important issue, I would like to take this back to the RIR's. J. Durand : Jerome.Durand@renater.fr IPV6 Multicast Deployment. ASM + SSM is working now. Only existing solution for ASM is RFC 3956 for embedded RP. The problem is not about address uniqueness, the problem is making sure that addresses are picked which map to a proper RP. The RP is "chosen" by the application. It could be topologically far from the application or the user. Solutions : MADCAP - can do what we want, but is not deployed and is rather complex. Want to use protocols already used for multicast. Ideas DHCPv6 Multicast address assignment was easy to add. We can even assign prefixes to the host for the host to pick from. Another ideda was NDP draft-jdurand-ipv6-multicast-ra-00 Collisions are very unlikely to happen in IPv6 but could be dealt with if people thought it was necessary. The problem is different than for IPv4. Only addresses derived from a working RP will lead to a working multicast group. With NDP + DHCPv6, multicast and unicast addressing architecture becomes the same. Another idea : What if every DR is a RP ? The RP address is now the subnet anycast router address. Then embedded RP multicast address can be figured out by the application. It seems strange but it should work. Dave Meyer : Do you run into state synchronization problem with this ? Durand - with a mechanism like this I do not think that you have any redundancy in the RP's/ Pekka - I think that the redundancy comes at the DR level. Durand : Do we need anything more than MADCAP + manual assignment ? If yes, which of the 3 proposed solutions (or others) should be pursued. Bill Fenner : MADCAP started as a DHCP v4 subset, and was turned into a different protocol, as it was not a good fit to DHCP. Pekka : I think it is important to analyze what sort of features MADCAP have and what IPv6 needs, to make sure we don't make the same mistakes. Steve Vignus : I think DHCP v6 is a much better fit than the v4 case. If you do this, do you need to solve other problems than just embedded RP, or is that enough ? Pekke : We are trying to address the 90% case. Bill Fenner : I would have said that that was the 20% case. Something to remember is that PIM gives the RP a lot of work, while the DR does not have a lot to do. If every DR becomes an RP, then small boxes may become overloaded. Durand : Don't you think that the work will be more distributed ? Bill : For a small edge router, being the RP for even one group may be too much work. Isadore : I do not understand something. If you create the address at the time the first sender starts sending, how do the other members learn about it. Toerless : I think that the original ASM model was focused on peer to peer applications, but now the focus is on client server applications. If there are P2P applications, then embedded RP in this fashion has problems - if it's really just the first member in the group, then what if his RP goes away ? So you have reliability problems. Marshall Eubanks - I would personally like to see a solution that solves the lightweight discovery problem in v4 and v6 using the same tools. Dave Meyer : Is this a topic that the working group should take on ? (Inconclusive show of hands). I think we need to take this to the list. --- Stig Venaas Rami Lehtonen / Mickael Hoerdt SSM applications need to know source addresses. In a videoconferencing type environment, this may be difficult, as people may come and go. We could use embedded RP, but we are trying to do this in the application with SSM. Different applications, say in the same video conference, need to work together. It might be useful to have an "application RP". Requirements : Want performance comparable to ASM No network requirements except to SSM Multiple applications on the same host should work Need to know when sources leaves to tear down the state. The signally might follow different traffic paths from the data. Questions : Is this a problem worth looking at ? Should it be solved here ? Pekka : I am a bit concerned what we are trying to accomplish. Why do we want to do this in SSM ? Stig : We are trying to have ASM applications work with SSM. John Meylor : I think that there is value in investigating the requirements here. It was dawning on me that this applies to the multi-point scenarios. A lot of the discussions there overlook the dynamics of the applications. I think that a little work on a requirements document would be useful. [Japanese member] : Are you interested in doing this in this WG ? I think doing requirements and solutions in one place is useful. Dave : We can do requirements for operations, but officially we do not do protocols. Stig Venaas : Maybe the biggest problem is actually getting in touch with application developers. The end goal is to have a lightweight solution that has no requirements on the network except for SSM. Lenny : The last two presentations were basically on how to discover stuff. If those two are in the charter, why shouldn't this be ? Stig : We are interested in very dynamic situations, where applications come and go very fast. --- Pekka Lightweight Address Discovery Debated many times, but nothing ever happens. The discussion does not seem to be converging. So, it seems to me that the only way to do this is to write drafts. 4 Problems : - Static Assignments - mess up local scoping plans - depletes resources - doesn't work with embedded RP, as addresses are not correct - it's difficult to filter in MSDP Dave Meyer's insight is that application writers expect that the app might have to be used between sites, so they want global addresses. Problem Scopes - locally scoped addresses from IANA - Address discovery within one domain, with a configured domain - zero-config single admin address discovery - global multiple administration address discovery We need people to work on this and create I-D's if this is to go forward. Dave Meyer : I think that there needs to be some consensus about what the problem space really is. John Meylor : There was a comment about the expectations of application writers. Wasn't there an attempt to write a document about this. Dave Meyer : MADCAP was part of a unified field theory that is no longer unified. Bill Fenner : It is part of an infrastructure and architecture that never got deployed. In the context of embedded RP in IPv6, I think that MADCAP could be a reasonable solution. Dave Thaler was more involved. Maybe he remembers more about what the problems were. Dave Meyer : I think that it would be worthwhile to document this. Stig : I think that the most complex parts of MADCAP was the problem of sharing state between servers (different parts of the organization might be running different DHCP servers). --- Pekka - Multicast Addressing Architecture We need a short overview for new-comers and operators. This also obsoletes MOSPF, BGMP and CBT. About five people have reviewed this so far. Any document with a lot of references to other protocols has trouble with new protocols, so we suggest that we don't discuss protocols that haven't gone to the IESG yet. Tom Pusateri : Why do you consider MOSPF to be historic ? Pekka : If I understand it correctly, neither Juniper nor Cisco implements it. Tom : It has its place Dave Meyer : I think that NASA Science Internet has a large MOSPF deployment. Pekka : Historic doesn't mean that its obsolete or not used, just that it's not the current state of the art. This reflects my understanding of what historic meant. Tom P. I think that MOSPF could be placed in the same category as DVMRP. Dave M. Personally I think that we haven't done enough I also think that the term historic is loaded and should be avoided. Dave Meylor : I think that we are beginning to see other working groups make assumptions about what multicast protocols are supported. Pekka : As an ISP, I was trying to give some signal about what is legacy and what the real status of the protocols is. Dave Meyer : Bill [Fenner], can you give me an indication of the status of the MSDP MIB ? Bill Fenner : I have to add some words to the MIB saying why the MSDP MIB is IPv4 only. So I need to add two sentences to the draft and resubmit. ----- Multicast VPN Yiqun Cai ycai@cisco.com Development really started in the 1990's, but first draft is draft-rosen-vpn-mcast-00.txt Multicast was added to the charter in Seoul, 2004 Last year in San Diego, draft-rosen-vpn-mcast-07.txt was accepted as a L3 VPN document. Also, start of scaling discussion, including SSM. A number of drafts were submitted for the IETF in DC in Fall 2004. Since there are multiple solutions, there was a need to merge them. New draft will be l3vpn-2547bis-mcast-00.txt This missed the meeting curfew. Cisco has implemented the 07 version of the rosen draft. Juniper has shipped a solution based on rosen draft 06. Other vendors are developing multicast VPN as well. Some interop testing. Significant and growing deployment world-wide since 2003. A note on the Rosen draft It's a complete solution - a balance between optimal traffic distribution and state maintenance - Inter-AS - Features have several years of deployment. The most heated recent discussion topics have been about scaling. - Control plane scaling - balance between traffic delivery versus cost. Ideas : Use SSM in the core to establish forwarding trees. - Use of PIM-SM / BiDir is never considered. PIM Adjacency between PE routers. Overhead includes PIM Hello's and PIM Join/Prunes. Is there any Order(MVPN) states in the core ? In the unicast case, the core does not keep any VPN state. The trade=off - No state in the core means that the ingress PE has to maintain all of the dynamic membership information - Aggregation reduces the state in the core, but may result in sub-optimal forwarding. - Optimal traffic distribution requires extra states on the ingress PE and/or in the core. So, the optimal solution is likely to be some combination of native multicast, unicast replication, and P2MP LSP. Existing deployments are providing empirical data. - the base proposal seems to work well for existing multicast. I do not think that there is a simple one size fits all solution. Service provider and enterprise networks can have very different characteristics. I believe different solutions will be needed. Questions for the group : What do we need to do to scale the P routers ? The PE routers ? Do we want to do both ? ----------------------------------------------------- 2005/3/08 MBONED WG (second session) ========================================= Tsune Hayashi presents draft-hayashi-maccnt-02.txt Pekka Savola : minor editorial issue, recommends changing title "well-managed multicasting" Quick response, channel changes, not a AAA item consensus to take as working group item, take to mailing list for any. ========================================= Hiroaki Satou presents draft-hayashi-rac-issues-00.txt Pekka: Resource protection between SP and user can't it be done be existing protocols? not clear what draft's relation is to other document want to signal admission control? Hiaxang He: need SLA, intelligent decision based on existing resourcing, Pekka: unclear where you want to do between SP and CP, from the last link Steven Wright, Bellsouth: many service providers are interested in these issues and it is valuable to document the question.. it is in scope. since unicasting has many of the features we are looking for maybe it would be possible to import multicast into unicast.. make unicast protocols support multicasting. Dave Meyer: need to be careful about pulling protocol not out of scope, but haven't done Toerless: less friction if we talk about adding to multicasting protocols, not step on other groups toes. consensus is to accept this draft as working group item but with condition that overlap between drafts is removed. ========================================= Marshall Eubanks Using SIP how do you find out about sources out there? A little history - original "package" of multicast media included SAP (2974) well though out was well known and simple - This described announcements that were multicast to a well known group and port 224.2.127.254 - bandwidth was limited announce included MIME type followed by SPP file (or equiv) question is how do I join? SAP troubles - SAP in conjunction with sdr was pretty cool - TV Guide like capability - used for address allocation ASM oriented doesn't scale SIP was orrignally build for th Mbone Multicast has faded SIP- user agent use edge box, allows user services is a "push" model send invite, invite contains SDP file three-way handshare to set up session URIs are used to identify agents SIP is ASCII, so the packets are easy to prepare Applications could send a SIP register packet - a proxy server on the LAN could listen for this - no way to force usage of this mechanism to announce info - but application writers aren't doing things like that SIP Session Discovery -SIP could be used to Multicast INVITEs -TTL is RECOMMENDED but not a MUST - would work over LAN, but so what? - what is gain over SAP -not much - still scaling issues - however can send to list of names SIP subscribe -RFC sets up a soft-state SUBSCRIPTION list - can keep track of users by this mechanism - would at least know who joined the group. Source Discover: Forward & Inverse Problems - SIP SUBSCRIVE could solve the "forward" source discovery problem Inverse problem lehtonen-mboned-dynssm-req-00.txt - not likely to be purely "in band" (multicast) - cannot be a single central server -some purity is likely to be list Probably would be more like DNS Does not directly solve the TV Guide problem Collin Perkins: for TV Guide problems, work in MMUSIC group SIP not good for discovery but good for negotiation Toreless: whether using multicast is used or not is not most important, worried about negotiations in dynamic application Stig: interested in multiparty SSM. |
None received.