IETF80 (Prague) MBONED Minutes Jabber Archive: http://www.ietf.org/jabber/logs/mboned/2011-03-30.txt Audio Archive: http://ietf80streaming.dnsalias.net/ietf80/ietf80-ch6-wed-pm.mp3 Working Group Status Pub requested drafts: mtrace, Ron had some issues, Hitoshi waiting for response. Ron says owes review for mtrace, ssmping and maccant. ssmping should go to ietf last call soon. AMT has new editors, should be almost done. PIM WG is in process of adding IGMP/MLD to charter. Explicit tracking draft probably going to pim wg after that happens. Stig presented mcaddrdoc Hitoshi: How is this different from Pekka's draft Stig: This is for documentation purposes only Tim: What's the recommendation for ipv4 unicast based addresses Stig: If you have a /24 uni, you get just one Tim: We found group address filters, 234 needs to get removed Is there a filter bcp draft? Lenny: Good point. Perhaps we need a doc here. Tim: Writing some docs.. It would be nice to point to an "official" doc, perhaps including the "why" certain addresses are filtered William F. Maton Sotomayor: Second Tim's request Bechet: Isn't it time to focus on ipv6 and begin ignoring ipv4? Stig: This doc covers both Lenny: Who would like to see this as a WG doc? half the room - no dissent. Will also take to the mailing list. Lenny: Who would like to take on the filter recommendation doc? Thanks Tim Limitations of SAP Greg notes that SDP can be done with e.g. a web page. Stig also noted that SDP can be done without SAP, and using different group addresses etc. Lenny notes that limitations of SAP are well known and understood- like describing the limitations of a sundial to the NTP WG. Says there are more effective scalable solutions now. Also, SAPv2 requirements draft was proposed last year and was not interest in adopting as a doc. Presenter: asking if limitations are well known. Hitoshi: Changed from requirements to limitation draft because requirements may indicate looking for new protocol? Greg: points out that SAP does many to many announcments. There are many ways to do one to many. Tim: Said something about issues? Greg: Says he sees some need to document SAP vs sdr etc. Tim: Volunteering for a new document Brian Adamson: Mentiones mDNS can be used, and possibly extended to site scope Lenny: Notes various issues with SAP, suggested a more thorough doc on of mcast content discovery, including discussions of SAP and SAP storms and mitigation techniques. ATT AMT trial Lenny: Noted that unicast and multicast both uses UDP so any firewall issues would apply to both unicast and AMT. Tim: What was the cause for a small percentage of users having trouble. Presenter: The previous mentioned firewall issues Thomas: Asked why the end to end latency was as high as 20-30s Presenter: It was due to the specific protocol used by Octoshape, but that they did not had more details. AMT draft recommendations Presenter: why anycast address restricted Greg: Says the anycast address has to be a prefix due to BGP filtering. Then just picked an address in that prefix. Thomas: Will talk about this later. Greg: SDP could be extended to include a relay address AMT draft update Stig: Fine with removing sourcing from doc Lenny: Agree Show of hands: lots of people in favor, non against Stig: Observing that more and more users behind the same IP address so may be more gateways behind the same IP address Teemu: Suggests to let Relay kill some established sessions among the ones to a same gateway IP when getting close to their resource limit Thomas: Says it may break things and not clear if good practice. Greg: Suggests could relax requirements Robert Sayko: Says a bit simplistic to restrict to one address and should perhaps be more dynamic. Lenny: MSDP per source limits limit number of MSDP SAs per source address works well, and says it may indicate per resource limit may work here. Greg: It's not that easy, may or may not be parallels, could be different deployment profiles. Lenny: Yes, need enough flexibility Greg Bumgardner: Points out spec doesn't talk about relay resource exhaustion. Hitoshi: Has some issues with the anycast IANA prefix? Thomas: Prefix does not have to be address from IANA. Hitoshi: Asking if anycast mandatory for discovery Greg: Says yes Thomas: It could be done anyway Robert: You could just use some other address Thomas: Spec does not prevent non-anycast for discovery Greg Bumgardner: Limiting amount of tunnels may require more often to do discovery to establish new tunnels. Robert: It is when you get an update you need to state that relay is overloaded, that is when resources are allocated. Robert: ATTs solution to gateway address change is to create a new tunnel instance, no easy way to correlate old and new tunnel instances. Thomas: So it is an incomplete solution? Robert: Unless you are on the wire and can snoop Greg: Asking if time to check all 2^48 is for checking all. Thomas: Yes, 2 years is worst case Greg B: A possible race condition related to tear down message. Says a session ID could be good. Lenny: Why not same checksum issue for IPv4 and IPv6 Stig: Problem is old IPv6 implementations and that they cannot always accept 0. Teemu: May be issue with intermediate devices Thomas: What do you suggest? Teemu: Some kind of test would be good. Lenny: Should not try to solve everything now Greg B: Yes, better allow some extensibility, e.g. a version field. Greg B: Could put proposed changes in a separate document. Thomas: Main thing is to keep it extensible Robert Kebler: Agrees better put it in a separate document. Greg: We found some holes thanks to trial. Now we have data, need a focused effort to fix big issues found, and at the same time keep it extensible. Lenny: Points out more implementations and tests. AAA: Greg: Extending AAA to AMT is one example of a future extension Greg B: this seems more an IGMP issue than an AMT issue. Jeffrey Zhang: wondering about AMT relay logging for billing etc. same problem without AMT. Lenny: Have you read existing mboned AAA drafts? Should look at multiaaa-framework draft