MBONED Mtg Minutes IETF 81 Quebec City Thurs, July 28, 2011 0900-1130 208 AB Audio Archive: http://www.ietf.org/audio/ietf81/ietf81-208ab-20110728-0855-am.mp3 Agenda review status of work items draft ietf-mboned-addrarch is now RFC6308 draft-ietf-mboned-mtrace-v2-08 to be revised after IESG eval draft-ietg-mboned-ssmping-08 in IESG evaluation draft-ietf-ip-multicast-pm-requirement-01 Author commented on status. draft-ietf-mboned-mcaddrdoc-01 stig is going to talk about it. draft-mboned-mcaddrdoc-01 Peter Koch posted 8 weeks before deadline. GOt feedback from Stig, can not go forward because there are known issues. Subject to further WG feedback edit out problematic element. charter issues. Ron Bonica, AD. Have taken beating by IESG for protocols because it is out of charter. Proposes to update charter to indicate that we do not do protocols in this WG unless we do. Lenny: Interpretation of charter is to not do protocols that are routing and membership signaling. Greg - AMT got into mboned because of request by the IESG after BOF in Vienna and because multiple competing proposal where made. Ron aggrees that we can do operational protocols, but not routing protocols. Greg asking Ron what the charter text suggestion is. Ron recommends squishy text. draft-ietf-mboned-mcaddrdoc Stig presenting. Simple draft to define what addresses shuold be used in documentation. Includes example addresses IPv4/IPv6, ASM/SSM, well-known/GLOB/unicast-prefix based ones. Few changes since last IETF. - removed allocation for SSM - added GLOB, unicast-prefix IPv4/IPv6, embedded-RP Greg complains about insuficient readership/review. Please read. Tim Chown asks about mails from yesterday mails about redirecting traffic for AS and wanted to know if this applies to multicast. Stig says it is more difficult for multicast. Bill A reads from email about AS112 and reverse lookup. From William Sotomeyer Peter Koch. Proposes to cover in context of mcast.arpa. Stig: There is some /24 allocation for documentation prefixes. Peter Koch not concerned because he does not expect a lot of traffic to DNS to be caused by this. draft-chown-mboned-multicast-filtering Tim Chown (author): Initial rationale of draft: 234.0.0.0/8 (RFC6034) still seems to be filtered in many networks. Asking for operational feedback to summarize in draft. Also targets to survey discovery mechanisms Greg: HTTP ? No, not considered, only SAF. Responses from academic oriented lists, janet(UK), Internet2(USA) Dozen of responses about border and MSDP peer filters Scopes learned from feedback - Organization border - MSDP peer filters (same as org, but also excluding SSM) - intra-organization ... Topics raised - no direct responses mentions 234.0.0.0/8 - TTL filtering seems obsolete - some commonalities in filtreing of specific IANA assigned addresses under 224.0.0.0/8. How arbitrary is the filter list here ? Greg: Where are those filters applied ? For PIM joins ? Not sure. - varying use of RFC2365 scoping within sites. Aggregate filter list slide lists summary of prefixes filtered in responses. Filtering inconsistent across all feedback. Greg: General problem in IETF. Applied inconsistent applied policy. Question to AD. What eg: does IANA do about unicast filtering. Ron: Short answer IANA does do nothing. Long answer: There is not much what IETF can do, there is no policy application police. Can chase wrong policy implementation in opeational groups like NANOG/RIPE, but nothing else. In unicast world you can complain to upstream network. Suggests to also try this in unicast, eg: contact the folks who misapply filtering policy. Lenny: So this is a survey, but less so a recommendation ? Tim Chown: First state, showing what is being done. Would be good to come up with recommendations. Lenny: Unicast never routes unicast blocks that do not belong to anybody, so he is wondering why there is permission for equally unassigned blocks are mostly allowed in global internet (eg: 225/8). Agree/Disagree ? Ron: When there was a large block of unassigned unicast those would be published for filtering - bogons. Now that all addresses are assigned this list is gone. Greg agrees with Lenny. Problem is that there is no guidance given to applications that want addresses. Used schemes such as expanding ring-search via multicast addresses. No address use recommendation never panned out. Stig: several applications want hard-coded applications to ship box from service with burned in addresses. Problem is this is often for site-local discovery but applies for global addresses. Stig is IANA expert for site address allocation (eg: doing review of requests). Finance market requests (stock market) and IPTV uses are asking for real-inter-domain used addresses. Greg: Even if we where to create a solution for address assignment there is no way these would be applied appropriately. Toerless: would be interested to know what rate of global address assignment is - eg: With prediction of current assignments, how long would it last ? Liming: General idea from day 1: Multicast addresses are not same as unicast. Not to be assigned statically. Lenny: There was an ad-hoc block. Greg: handed out via SDR. Liming: do not see documented guidance. Greg: Original intent of multicast by Deering is different from what application vendors today want to do. If there is no better solution, app vendors will continue to ask for such addresses. Stig: public registry exists, but no explanation how it should be assigned. Maybe we can create statistics about type of allocations. Lenny: DOcumentation for use of each block exists in draft/RFC. Peter Koch: registry at IANA web page. Still lot of addresses available. Wrt. bogon list, maintaining living list of changing objects is best not done in IETF. Toerless: SSM is better. Just exhaust global IPv4 addresses. Question: What global IPv6 ASM assignments exist ? Stig: Yes there are global ASM assignments, listed on IANA page. Mostly for local use though (service discovery type). Optimistic about us running out of ASM IPv4 addresses not sooner than IPv4 multicast is replaced by IPv6. Liming: Question on filtering in draft. Does rthe list implies that other ranges are permitted ? Tim Lenny: List is game of wackamole. Thinks we should recommend blocking larger unused/bogon prefixes. Next slide: Topics raised(2) Next steps ? Extract recommendations out of this ? Need more IPv6 information into this ? Greg: Would like to move interdomain solution to SSM (Lenny, Greg, others). If there is going to be a filtering recommendation, then it should include a section to very simply state how simple filtering would be if a site only uses SSM interdomain (only permit 232/8). Question for adoption as WG draft ? 10-15 yes. 0 No. question will also go to list. MBONED feedback on work in Softwires Slides: Multicast Extensions to DS-Lite Technique in Broadband Deployments draft-qin-softwire-dslite-multicast-04 Xiaohong Deng Greg: Last minute request giving update of work in other WG. Mechanism relies on stateless IGMP-MLD interworking function at receiver (v4 join -> v6 join and decap). And stateless IPv6-IPv4 PIM interworking function on first-hop network doing encap. Uses mB4 and mPREFIX64 and uPREFIX64 addresses. Greg: other mechanisms proposed only PIM. Why IGMP/MLD? Co-Author: receiver side in home on actual receiver LAN. Address-building: boudacair-behave-64-multicast-address-format .. Toerless wondering aobut use-case of v6-only network and ONLY good support for v4only sources/receivers. Translation of header v4->v6 instead of tunneling would better support v4-only and v6-only receivers simultanesously. ??: Other solutions targeting translation, this one is only encap based. Argument against translation: Content provider claim that their packet must not be touched. Yiqun Cai wondering why to restrict to the case that CPE only does IPv6 towards network. Answer (co-author): Assumption of DSlite deployment cases is that CPE only gets IPv6 addresses. Yiqun: Could also let IGMP join go all the way to QR. Toerless: CPE could generate IGMP memberships even if it does not have an outside IPv4 address because IGMPv3 explicitly supports source-IP address 0.0.0.0. Will this solution support ASM and SSM ? Yes. RP-placement. Toerless: Should use same RP-placement recommendations as if this was a native end-to-end IPv6 solution. Request for joining discussion in softwires, WG/Mailing List. Discovery of optimal AMT relay Presentation by Bob Sayko. Draft name not mentioned. Toerless: issue of overload of A entries in in-addr. Stig: should maybe use amt.z.y.x.a.in-addr.arpa to look up the AMT relay for a.x.y.z. Peter Koch: proof point exists with old RFCs overloading reverse mapping. Peter concerned about whether or not we can expect for the reverse mapping to exist for sources. Address returned could be unicast or anycast address. Bill A. ... (did not understand the question) Is there is enough control to tell users which AMT relay to use ? Toerless: No. AMT model is SSM receiver. and gateway may not need to be directly integrated into Toerless suggesting a solution with additional DNS prefixes using same type of entries. Show of hands for adoption of draft as WG item. 10-15 yes, 0 no. Will also take to the list. AMT update draft-ietf-mboned-auto-multicast-11 Greg Bumgardner - another revision will be required. GregS: Need normative reference (security section). Issue about mixed IPv4 in IPv6 or vice versa. The gateway does not indicate what version of protocol is used inside the tunnel, so relay does not know initially what type of queries to send, IGMP or MLD. Needs a solution. GregB: couple of possible solutions. indication in initial signaling packet Greg: Need to have AMT support v6 over v4 and vice versa, but do not take on any address or other translation - just tunneling v4/v6 over v4/v6. Lenny: Lets try to find the most easy solution. Discusssion about issues listed on larger protocol design issues. Lenny: Is it in spec to stop advertising anycast address when running out of resources ? It is now. Suggest to add headroom to avoid race-condition. No solution understood for issue 1 on slide (account for update message loss, reordering or rejection). Yiqun: Wants to put MTU limit on update message. Greg: Would require additional work in gateway to split up IGMPv3/MLDv2 packets. Yiqun explaining how such large packets are a possible issue for routers to handle. Recommends for protocol messages to fit into IPv6 default MTU of 1280. Toerless: if we adopted the DNS draft and we would select different relays for different sources simultaneously, would this be supported by the current AMT-spec ? Greg: yes. Greg giving public chastizing for an open, transparent process improving this document. Send diffs to the list with explanations to allow creating agreement/disagreement. Discussion about possible larger changes in future versions of AMT. Toerless/Kurt: Let not change requirements against the forwarding plane. second point ? Mike McBride. Get it out as an RFC even if there are gaps otherwise it gets on forever. Toerless: Try to resolve security issues that would cause IESG refusal. Greg: If necessary change target status to experimental, but hopefully not needed. Bill: security section has to acknowledge existing security gaps. But they may not necessarily need to be fixed. GregB/Toerless: Existing vendor mechanisms to enforce state limits to minimize resource exhaustion due to attacks is something that should maybe added to security considerations section. Yiqun Cai: how about mtrace over AMT ? Need two things: - AMT-relay needs to accept mtrace packets coming in from gateway currently not included in spec (not possible right now because sourcing from gateway not supported). - add code-points for AMT tunnel into mtrace to indicate it in mtrace results. But does not have full solution together to propose text.