3/1/12 Virtual MBONED Interim Notes Notetaker: Tom Taylor (with assistance from Sue Hares) Webex Recording: https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=59066907&rKey=89db506666a6b7ca These are my notes from the interim meeting held on March 1. Thanks to Sue Hares for also taking notes and passing them on to me. Introduction ============ An interim meeting of the MBONED Working Group was held on March 1, 2012, from 10:00 to 12:00 am EST . The MBONED Chairs, Leonard Giuliano and Greg Shepherd , presided. The NOTE WELL may have been displayed, but was not read out. A list of attendees and a URL pointing to a recordingt of the meeting have been made available in separate messages to the MBONED list. The agenda suggested by Tina Tsou in an E-mail to the MBONED list on Wednesday, Feb 29, 2012 at 2:38 AM EST was accepted. Lenny Giuliano introduced the first meeting topic, the work item discussion. He noted that feedback from the MULTRANS BOF was that the list of topics had to be narrowed. This imperative was reflected in the brevity of the Eubanks overview draft compared with the Jaclee problem statement. He asked for comments from the floor before turning over the meeting over to Stig Venaas . There were none. Work Item Presentation and Discussion ===================================== Stig spoke to a presentation (attached to this E-mail) on the work items to be accomplished. The four areas of work presented were the overview document, multicast address translation, address acquisition, and specification of the adaptation function (AF). Chart 3: Overview Document -------------------------- No comments. Chart 4: Multicast Address Translation -------------------------------------- Lenny Giuliano provided a brief status report. Draft-ietf-mboned-64-multicast-address-format has passed WGLC and has been forwarded to the V6OPS and 6MAN Working Groups for comments. Assuming all goes well, a request for publication should be issued soon. There was no discussion of whether this draft satisfied all requirements for multicast address translation. Chart 5: Address Acquisition ---------------------------- In response to the question at the bottom of the chart, Stig Venaas expressed his belief that the IETF could indeed contribute to the resolution of the problem. The chart provoked a number of comments from Dave Thaler . He found the (unmentioned) transport protocol for delivery of the electronic program guide (EPG) more interesting that the encoding of the content. How does the provider ensure that the right person gets the right guide content? He wondered if the IETF could work on a standard distribution protocol. Aside from that, he wanted to see an analysis that would answer the question of whether development of an application level gateway (ALG) for EPG translation would be worthwhile. One of the key issues coming out in subsequent discussion was to what extent providers currently use proprietary rather than standardized solutions. Another key question is whether there is a requirement that there be no change to the receiver. [Note: discussion of these issues was resumed at a later point. See below.] Chart 6: Adaptation Function Specification ------------------------------------------ This chart set off a discussion of encapsulation. Ron Bonica asked whether encapsulation was already solved with the work on Automatic Multicast Tunneling (AMT) (draft-ietf-mboned-auto-multicast). Toerless Eckert noted that AMT had limits in scalability and could not handle the necessary fanout. Ron asked whether ASM was a requirement, and was told that feedback indicated that it was needed. Toerless mentioned a 6over4 solution by Carpenter and Zheng, encapsulating IPv6 multicast in IPv4 multicast. Ron questioned whether, given that we are dealing with a transitional situation, it was worthwhile developing a solution for encapsulation of multicast. He proposed that we just do encapsulation of multicast in unicast, then see if the market demands a more sophisticated solution. Further discussion revolved around the need to look at real scenarios, define use cases, and determine the true requirements. Stig Venaas and Yiu Lee described current work in Softwires, of which Ron was unaware. Draft-ietf-softwire-dslite-multicast covers IPv4 to IPv4 over an intervening IPv6 network, while draft-ietf-softwire-mesh-multicast looks at transport of multicast over a full mesh. [Some of this actually occured later, but is reported here.] Charts 7-8: Adaptation Function Specification (cont'd) ------------------------------------------------------ No comments. Chart 9: Adaptation Function Specification (cont'd) --------------------------------------------------- The question on the chart was whether besides the detailed IGMP/MLD and PIM translation specifications we also needed a high-level AF specification to pull everything together. Dave Thaler suggested that the framework document produced by Behave (RFC 6144) be used as a precedent. This document provided guidance for the detailed work that followed. Ron Bonica asked if we were talking about an overview document and a separate AF specification. Yiu Lee noted that a multicast framework (draft-venaas-behave-v4v6mc-framework) had already been posted. Stig Venaas, the author, said it would have to be reworked because our ideas had changed. The general conclusion at this point was that we do need a framework document. However, a further conclusion was that the overview document could ultimately fulfill this role. This would leave us with a two-level hierarchy: the detailed specifications such as the IGMP/MLD and the PIM-to-PIM translators, and the overview document to motivate and tie them together. Dave Thaler asked if people currently deploy reliable multicast protocols, making transport part of the transition problem. Lenny Giuliano (correction: wasn't Lenny, was probably Ron) said that would be out of scope, but Dave argued that it could be required for a deployable solution. Yiu Lee said that there was some use of such protocols for pre-provisioning of Electronic Program Guides. Dave said, besides transport, there could be other gaps, such as RADIUS or security. Someone mentioned that RTCP is sent multicast as well as unicast in some applications, so that has to be investigated. [Section 2.1 of RFC 3550 provides an example.] At this point, Ron Bonica questioned whether we might be facing too large a problem, particularly if translation at higher protocol layers is required. We need a complete picture before we go forward with this work. Yiu Lee pointed out that there were already drafts in Behave giving requirements. As for distribution of the EPG, every operator has their own solution. The only common agreement is to use multicast for distribution of broadcast content. Someone else expressed the opinion that we have some problems that we know about and can work on now. We can work on others later. Ron stated that the key question is whether we have a deployable solution if the problems described in draft-eubanks are solved. The question is whether enough other things are needed that the scope is intractable. Speaking as an individual contributor, he was of the opinion that the only thing we should work on now is the overview document. We shouldn't waste our resources on other work until we determine that the problem is tractable. Tina Tsou asked if we could come to a conclusion on the work items. Respondents suggested that we don't have to solve everything at once. The key need is to identify which pieces need standardization, and which others should be left to the operators to solve individually. At this point Ron looked for an operator to identify gaps in what we had identified already. Yiu Lee volunteered to canvas his own and other operator organizations and bring back the needed information. Ron repeated that we should not do further work until the full scope is clear. Either Yiu reports back a small list of additional pieces to a deployable solution, or the effort is too large and everything should stop. Yiu will be recruiting help from other providers. Ron now asked whether there was anything worth still pursuing while we wait for Yiu to report back. Tina Tsou suggested that we might as well progress the address translation and IGMP/MLD drafts, and Ron agreed. Stig added the PIM-to-PIM translation work to that list, but worried that we do not have the non-IPTV requirements that might affect that work. Yiu Lee asked whether work on the Softwires drafts m,entioned above would be affected by these decisions. They basically duplicate work being contemplated here. Ron said the basic idea was for MBONED to put bounds on the work to be done, then farm it out to other Working Groups as required. There was some discussion of the current status of BEHAVE as a target of some of the work. Ron's impression was that BEHAVE is being closed down, and any outstanding work items will be given either to other existing Working Groups or to a new one. Coming back to the agenda, Ron summarized by saying that the overview document appears to have gaps. Tina Tsou asked if the IGMP/MLD draft would be a Working Group draft. Stig Venaas said that draft and PIM translation should be resubmitted to the PIM Working Group. However, it is too soon to make the IGMP/MLD draft a Working Group document, until the requirements are fully fleshed out. Tina asked if address acquisition would stay in MBONED. Stig said it could stay there for now. Yiu Lee questioned whether the problem could be solved. Again there is the question: can the receiver change, or is it a requirement to leave it unchanged? The key question, given the proprietary solutions in use now, is whether an IETF solution would be adopted. Mohamed Boucadair expressed the view that changing the receiver would be a cleaner solution. There was discussion of whether Set Top Box (STB) updates required a truck roll or could be done remotely. Yiu Lee pointed out that there are different arrrangements for STBs, and no single answer. Baseline Overview Document ========================== Ron turned to the topic of the baseline overview document. Was it acceptable to Yiu to build on draft-eubanks? Yiu agreed. (He will be added to the list of authors.) Ron asked the meeting at large whether this was acceptable. Dave Thaler noted that there is stuff missing from from draft-eubanks. draft-jaclee has more information, but he was not sure which was the better starting point. Yiu Lee said he would look to see if the documents could be merged. Ron said that the action would be to take the IPTV-related material from draft-jaclee and put it into draft-eubanks. Yiu should also add his new material there. We could call it a framework later after the AF high-level design text had been added. The more detailed documents such as the IGMP/MLD draft would be separate. It is too early to incorporate the AF specification now, but individuals can start on it now as a separate document and add it in later. It should use informative language. Dave Thaler suggested we use RFC 6144 as a model. The question was raised, whether we agree that IPTV is the only use case. This was confirmed. There was a brief discussion on ASM. The requirement for ASM is present in draft-eubanks but is unjustified by preceding text. It appears that it is needed because operators use it currently in IPv4 networks. SSM represents a simplification (as a subset of ASM) in the network core, but would require an upgrade at the network edge. Stig Venaas raised the possibility of work on interworking IPv4 ASM with IPv6 SSM. Tina Tsou, as the one co-author common to draft-jaclee and draft-eubanks, was given the task of convening a meeting of authors and other interested parties to work on merging the drafts. Greg Shepherd, Mike McBride , and Stig Venaas will be attending the next NANOG meeting and will work together on a presentation to that meeting about the multicast transition work. Solution-Related Discussion Points ================================== Stateful/Stateless ------------------ Stig Venaas clarified a point he had raised in earlier discussion about the AF. Of course, IGMP, MLD, and PIM have state. What he meant by the stateful/stateless terminology was its application to address translation. He noted that IPv6 to IPv4 address translation might have to be stateful. Best Strategy For Address Acquisition ------------------------------------- We need operator input. It could take a while to settle this question. Reverse Path Forwarding and Loop Avoidance ------------------------------------------ Tom Taylor explained the issue. If multiple address translations during path setup, it is possible that the path gets looped back to a network it has already transited. Stig Venaas had pointed out that networks could avoid this if each network knew the true source address, Tom Taylor noted that an IPv4 source address would always remain available if RFC 6052 was applied for its conversion to IPv6 and back again. Stig Venaas noted that the problem needs further exploration. It should be mentioned as a potential problem in the overview, and documented more thoroughly when we have developed a fuller view. He said there were other issues besides routing loops that are not currently noted in the overview. Translation Between IGMP/MLD and PIM In the Other IP Version ------------------------------------------------------------ Covered by the IGMP/MLD draft. Wrapping Up =========== Tina Tsou pressed the chairs to summarized the action items. 1. Merge the relevant information from draft-jaclee into draft-eubanks. 2. Yiu Lee to chase down requirements. What is out there, what is needed, what is not. 3. The IGMP/MLD draft to be resubmitted to the PIM WG. Any PIM-to-PIM translation draft would also go there. The MBONED Chairs were asked what the MBONED agenda in Paris would cover. Lenny Giuliano said the meeting would cover the standard items and an update on the action items in the interim meeting. They would leave room for a good discussion on the multicast transition topic. A call for agenda items would go out shortly. The meeting was adjourned.