mboned WG THURSDAY, November 9, 2006, Morning Session I Chair(s): Hiroshi Ohta Marshall Eubanks Note-taker: Gorry Fairhurst 1. The agenda was presented. 2. WG Chairs reviewed the document status. RFCs published since last IETF are: draft-ietf-mboned-ssm232-09.txt --> RFC4608 draft-ietf-mboned-msdp-deploy-06.txt --> RFC4611 draft-ietf-mboned-mroutesec-04.txt --> RFC4609 draft-ietf-mboned-msdp-mib-01.txt --> RFC4624 Documents that are in/completed WGLC are: draft-ietf-mboned-routingarch-06.txt Marshall noted that the address architecture I-D had re-entered a WGLC for rev -05, after changes from rev -04, which had already been WGLC'ed. The call was now complete. Publication requests by the WG Chairs to IESG were being prepared for: draft-ietf-mboned-addrarch-05.txt (proto shepherd Hiroshi Ohta) -> mini last call, no comments draft-ietf-mboned-maccnt-req-04.txt (proto shepherd: Marshall Eubanks) 3. Active Drafts and related issues --- Report on AMT prototype implementation, Dino Farinacci Dino presented a CISCO implementation report for AMT - IPv4 (information may be available on IPv6, perhaps by the next IETF) Cisco Implementation Status - Coding and Syte Test completed (see slides). UDP-replication on road-map for next generation ASICs (zero UDP checksum), agreed in 06 draft. There could be a 2 byte compressed header instead of 4-byte (this would not be backwards compatible). This could appear in rev -07. Next IETF, there may be interoperable implementations, and some experience with pilot deployment. AMT implementations microsoft cisco -Dino freebsd/linux- Tom Pusateri, Greg Shepherd Milestone March 2007 hope to get interoperability between those 3 implementations Tom Pusateri (TP): We have a temp. prefix and AS number, need approval of doc for IANA to get prefix Marshall Ewbanks (ME): We need to get IESG approval to get a permanent IANA assignment. ME: Was the BSD implementation ever ported to MacOSX? TP: The relay works, but not the gateway. There is some work to port the TUNtap driver to this OS. ME: This port could be a useful thing to do. DF: There is a call for interest in performing a trial. ME: What is involved to do a trial? What does a content provider need to do to take part? Greg Shepherd (GS): Content providers, etc ME: Does VLC support this? Tim Chown (TC) : Can you say what is a CISCO PC? DF: CISCO OS running on a PC platform. Currently not a product. --- AAA Framework, draft-ietf-mboned-multiaaa-framework-02.txt, H. Sato A significant update was presented (see slides). ME: How many people had read this 6-7? ME: How many people think it should advance? (2) ME: Who has reasons why this should not advance? - No response. David Kessens (Ops AD): Does anyone need this? - No response. ME: Are there implementation plans for the framework? Thomas: Operators are interested in this. ME: Operators may be interested, but we do need to see their inputs here in this WG. HOhta: The aim is to bring operator needs to the group. Another author from an operator has been introduced as a coauthor. ?: is Christian's support institutional or individual? Marshall thinks it should advance, but no reaction ME: I don't see a strong interest here. We will take this to the list. --- Multicast MIB draft-ietf-mboned-ip-mcast-mib-03.txt - David McWalter Now completed WGLC (-02), there is a need now for Routing AD inputs, and MIB review). Trying to get expert review. Fixed language tag Interface table has statistics Current changes editorial (see slides). Martin : Speaking as an operator. When using mrtg, having the ifindex in last position is preferred (the ordering as before) - please leave the interface index as the last index - either have inetversion somewhere else or leave inetversion out (as is). DM: Either way, his table should be consistent with the ifstats, consistency with other table would be good I will talk to you. Counter32s can now be discounted, and just use counter64s. RFC2932 fields that say which protocol works over an interface will be removed (recommended by Bill Fenner, Bill Fenner talked to some people-- they think deprecation would be good). He proposes to make the required changes, take to ML and then to request a further WGLC (and at the same time request MIB doctor review). ME: Please post this to the list. Is anyone unhappy with a WGLC? - We can issue the WGLC next week. question about process for MIB DK: MIB doctors can be requested by the WG Chair, or we can request this. It should not be someone who was involved in making the MIB. ---- 4. Individual Drafts draft-ycai-mvpn-deploy-00.txt, Michael McBride (MMB) - comprehensive draft about deployment experience hopes mboned group will adopt Yakov: Do you have one case, where you deploy a MVPN over the general Internet? MMB: No. Yakov: This was recommended to bring it here. this draft is useful but that not public internet so interlap is zero Yakov: This should be done in L3VPN. ME: Has it been presented at L3VPN? MMB: Yes, as far as I know, it was not requested to be adopted. Yakov: This is about VPNs, not use in the general Internet, these are different. GS: We need to remember these issues, when we re-charter mboned. Yakov: The core expertise is in the L3VPN document. GF: The technology seems that this talks about seems like the sort of things that we know about - operations aspects of mtrace, PIM, addressing, etc. Yakov: The technology is really a L3VPN issue, that is a different set of issues, to those in mboned. Leonard Giullard: agree with Yakov, has nothing to do with mboned although a good draft. This is the mboned, the document is about VPN issues. DK: Are you sure that OPS groups know less than non-ops groups about multicast deployment? Yakov:I was surprised the authors did not send comments to the L3VPN group. MMB: They had not yet. ME: It would be good to see pointers sent to documents on both lists (this does not seem to be happening). --- Benchmarking MVPN, draft-sdry-bmwg-mvpnscale-00.txt, Silvija Dry MVPN many service providers deploying - no standard way to measure MVPN scalability - wants to define methodology to size networks - scaling for stability and failure recovery capabilities of the network are assured Goals to define the MVPN metric set - can be used by "MVPN Deployment Recommendation" mboned-mvpn-deploy" The work will be done in the BenchMarking (BM) WG, the question concerns would these metrics be useful to people here (operators)? doc overview, in addition to single variables, used requirement survey to define scenarios - a few service providers want to contribute - want more people from mboned to contribute ?: How about adding the number of neighbours? SD: We have not seen networks with large numbers of PE neighbours (just a few), so not currently included, but could be added for completeness. SD: Are you asking PE<->PE routers? ?: Yes. SD: We do this. ?: The right direction is not to include issues that are already covered in other BenchMarking WG RFCs. SD: Yes, but there are things that need to be included to offer customers ability to understand the impact of PIM choices in the core. ME: Was this document brought before the BM WG? Were there many comments? SD: Yes, at this IETF. There was some comments. ME: Is this within the BM WG Charter? SD: Yes - but, but that group is too general, the specific technical expertise on multicast is not within the BM WG, so we need to work with mboned. We will also talk about this in L3VPN in the future. We expect to see it adopted in the BM WG. ME: Will you take responsibility for forwarding comments back from the mboned list? SD: Yes. ME: Can the mboned WG please read and comment to the list? --- Lightweight IGMP/MLD, draft-liu-magma-igmpv3-mldv2-lite-02.txt, Hitoshi Asaeda [see slides] Updated since rev -01 and has added SSM related requirements, and compliance to MSF API filter specs. * joke to rename original to IGMPv3 Heavyclarify record types * explanation of tables * merging an unsolicted report option is optional ME: Cisco have already use the term "IGMPv3-Light", does the name of the current ID need to be changed? MMB: We could ask within Cisco. Cisco's use was an interim solution. ME: Two different names can always lead to confusion. ?: We would be wise to change (others also agreed). Joke to rename original to IGMPv3 Heavy GF: Can we confirm that the goal is to be fully interoperable with standard IGMPv3? will this be backward compatable? ME: Yes, that is my understanding. SS: We do have a lightweight implementation and we have confirmed implementability for SSM deployment. CW: We plan to implement Lite version router/switch. ME: Are there any open source versions? HA: Yes, and we shall confirm the goal of interoperability. ME: Who thinks this should be adopted by the mboned WG? (Many hands) ME: Those against adopting this? (No hands) ME: We'll now take the question of adoption to the list. --- Mcast.arpa draft-koch-mboned-mcast-arpa-00.txt, Peter Koch Please can the WG review the draft? LG: Why remove 224.1 and 224.2? PK: Is this SDP? LG: That's one use. PK: I didn't see the use. IANA needs clear guidelines. LG: I think whatever value for 224.0, it's also valid for 224.1 and 224.2. If one sees a weird group this can be looked up, and that is useful. PK: This is not the reverse-mapping part, we can see the value in that. LG: My statement was on the reverse DNS case. ?: If reverse was just used for addressing, then you may wish to do both ways. Stig Vernaas, SV: I think this is a good idea. Can you be sure this will be maintained bette than current use? PK: The aim is to setup a policy (amend BCP51). SV: OK. ME: If I define a new protocol, will IANA make an automatic appropriate entry? PK: The group allocation for these ranges are made by IANA, and they would then allocate the name when the address registration was made. SV: There are IPv6 prefix-based addresses - a unicast address delegation could also get a multicast delegation for the corresponding addresses. PK: This involves regional registries for addresses. SV: Yes. PK: This is beyond the scope for this particular document. TC: You'd also need to consider scopes. You could also do things with Embedded RP addresses. ME: GLOP addresses are still used. were you proposing to include glob? PK: There are management and maintenance issues. These are not done by IANA, RIRs give AS numbers. SV: Looks similar to IPv6 unicast prefix addresses. ME: Can we adopt this as a WG item? (many hands) ME: Those against adopting this? (No hands) ME: We'll now take the question of adoption to the list. --- SSM Ping, Stig Vernaas. Presentation of the slide, and a request for IANA for assignments? Bill Atwood: Please ensure the slides get on the web page. PK: Specification is required for a port assignment. A document is required to get an allocation. TC: There was a previous SSMPING draft discussed some time ago? I'd like to make sure there is no chance of confusion. ME: Marshall:thinks to get port number, need to go through RFC can anyone lend for purposes of testing ME: Does anyone know of the use of that? (No one did.) GF: You can always publish this as a I-D, at least it gives visibility and a known name. ME: Yes please do that, and submit an I-D, we can then talk about this on the list. --- 5. Charter Discussion/Multicast survey status/AOB Multicast Survey Results, Eubanks/Leymann Large scale IP-multicast deployment rarely at ISPs during the last few years but last year IPTV is driver to make it pick up, now considered a best common practice Goal: we did survey kind of focused on 3P issues showed section of the questionaire (see slides) received 9 responses General IPTV/ Multicast requirements - how many content resource - 2 to 30,000 median was 1000 ME: Any comments on the survey? Yakov: Caution is needed for surveys, a sample of 9 is very small. ME: Greg Shepherd suggested a name change to Multicast OPs. ME: is MBONED needed? most deploying are not IETF participants some options: either wind it down or expand its reach Yakov: IGMPv3 is a change to the protocol. This group is not in the routing area and this is a protocol spec, it's not in the right area. If this is a routing issue, it should be in the routing area. ME: MAGMA was closed down. Yakov: A discussion needs to be made with routing ADs. TC: What about debugging - guidance is a good thing. Taking this forward would be a good thing. ME: The people who need this are not here - is this an active IETF activity? TC: There are separate views as a consumer (not provider). LG: 2 biggest questions: Scope of networks, needs to be understood; Protocol development has been talked about and done in mboned. ME: On the protocols, it is the same group of people who do the work, so thats a complication. On the first point, there is expertise here in multicast deployment and protocols, L2VPN and L3VPN have other groups working on this. Yakov: There's also MPLS. There's also a question of OAM. Hiroshi Ohta presented a summary presented of the discussion on charter from the mailing list following the Montreal IETF. MMB: PIM is also expanding the charter, expect this to be done by the next IETF. ME: I think we should talk about where the boundaries should be drawn between the new Charters of the two WGs. MMB: Yes - both groups are seeking new Charters. Tom Morn (TM): Deployment is currently walled-garden. This has not been the focus within mboned. Other groups focus on the walled garden, and these groups have less experience, we need to continue work that is appropriate and profitable for a range of business models (AAA and management for as an example). This work should be done in the IETF. New protocol extensions may be needed. ME: enterprises have no place to go. idea of setting up a forum SV: Some people are trying to develop inter-domain services. Important tools are beacons, mtrace, etc. These are important to the IETF. ME: Should we encourage the dbeacon people to come? HAsadea: Mbone is a good place to work on multicast protocols. Why is MAGMA closed down? ME: The WG was wound up when the work was done. JE: How many enterprises are in this room? There are many more of these enterprises who do not seem to be represented in the room.