IETF 82 MBONED Mtg Minutes Taipei, Taiwan THURSDAY, November 17, 2011 0900, room 101B Audio Archive: http://www.ietf.org/audio/ietf82/ietf82-101b-20111117-0855-am.mp3 Jabber Notes: http://www.ietf.org/jabber/logs/mboned/2011-11-17.html Hitoshi Asaeda, mboned-mtrace-v2 status update wglc done -06. AD evaluation. revised ID needed (-07). last call requested. IESG evaluation. revised ID needed (-08). Peter: had issues with sound quality in room. This was a very important issue to Greg. This sound quality issue MUST be in the notes. Big discussion and lots of hand waving. Many editorial/technical changes. Decide way to move forward. Ron Bonica: Need an implementer to know if this is thorough enough. -Find someone not familiar with this draft. Greg will find someone. Technical changes: Name of header is confusing. mtrace header (old: query header). No change in format of header. No changes in block. No clear explanation of length of mtrace message. An mtrace2 message is carried as a UDP packet which MUST NOT be fragmented. Changed type to "NO_SPACE". If the mtrace2 request packet size, after appending a standard response block, would exceed the mtu of the outgoing interface, modify the forwarding code in the last standard response block of the received mtrace2 request packet into "NO_SPACE". modify the mtrace header type to 0x03 in order to change it to an mtrace2 reply and send the mtrace2 reply packet back to the mtrace2 client. Ron Bonica: doc should make a bigger deal that an mtrace message is directed to node attached to it, its a hop by hop protocol. Should be on page one and not something to figure out after the 4th draft read. mtrace2 request. received by non supported router. clarification in sect. 9.7. New text. reply timeout. New specification in sect.9.8.4. sect.8.5:proxying mtrace2 query. sect.9.2:determining the path. Sect.9.7:non-supported router. NO_SPACE error. clarification in sect.9.9. AMT is now out of scope. Toerless: we do have use case that we have an AMT tunnel between two clouds. If we don't have PIM and if mtrace assumes interface with PIM, don't have an answer but there is a use case. Jabber comment: You can have mcast cloud at the gateway. Next step: find outside reviewer as discussed before. Greg: Will take this to the list, we need a solid review. Toerless: There is sufficiently many implementations of AMT. Ron Bonica: The ietf isn't here so we can just speak to each other. The ietf is here to document protocols (etc) so people who aren't here know what we have to say. sometimes a doc needs restructuring so important info is said first so outsiders understand. We are talking to outsiders. Stig: I will read AMT carefully again but no promises. Ron: when a doc takes to many trips between wg and AD the AD gets grumpy. draft-ietf-mboned-mcaddrdoc. Stig Venaas. IANA provided statistics: stock exchanges: 11,040 v4 allocations. IPTV: 1280 v4 allocations. Other: 5 v4 and 23 v6 allocations. New protocol: 2 v4 allocations. Jan-2010 thru Oct 2011. Greg: there was a land grab early on. But they really don't need their own addresses, 239 addresses would be just fine. Most addr are sitting in the enterprise and not inderdomain. Toerless: are we really having this rant here? This (allocation of addresses) is a lost cause. Stig: We ran out of unicast addresses but still have mcast addresses. Shhhh... Toerless: any percentages? 10% left? Need a safety buffer. Peter: Time span of data is rather large. Would be good to see allocations over time. Growing demand? constant demand? burst? Tina: Today I'm applying v6 for my campus. Should I apply for addresses from IANA or ARIN or ? Stig: depends on use. Internal? then easily use site local addresses. only if you are interacting with other orgs, mcast going outside, then you should coordinate with IANA. Tina: any guidelines how many v6 mcast addresses needed. Stig: if you just want to run addresses that don't clash use unicast based addresses. Peter: mcast addresses aren't addresses in this space. Don't go through the RIRs. mcast addresses are protocol parameters. Toerless: mcast addresses should be admin'd the same way as unicast. Tim: what are the 23 v6 prefixes being requested for? Stig will answer later. Stig: Glop doesn't provide enough addresses. Tim: If one of the 23 v6 is for something like mdns it is quite important. now getting to draft-ietf-mboned-mcaddrdoc There are unicast addresses for doc purposes People have been asking what addresses to use for mcast This draft aims to tell people what mcast address to use: IPv4/IPv6, ASM/SSM, well known, GLOP, unicast prefixe based, embedded rp. status: Merged examples from appendix into the main body, makes it easier to read. There was a question on the list in July about reverse dns mappings and a project called AS112. It was discussed in DNSOP. I responded that whether to have reverse mappings for IANA assignments is a more general discussion and does not need to be considered here. Ready for WGLC? Peter: both AS 112 and reverse mapping are two different issues. I would suggest to keep this out of this doc. If need arises we can address at later stage. 5 read the draft 4 support going to wglc. AMT status, Greg: issues on the list seem resolved token currently with greg bumgardner diffs schedule to the list for next week. loads of editorial changes. clarification, consolidation. non technical changes. IPv6 UDP checksum discussion addendum draft. open technical question. current text is no different then what other drafts are using to address the same problem. once we get into editors queue, we will make some clarifications at that point. v6 required an outer checksum. they weren't considering what a router generated packet would be. trying to simplify load on router. it is harder for a router to generate a checksum. why put on outer when there is an inner. there hasn't been a lot of consensus what the impact is. draft is moving forward to have to signal whether a host can tolerate a checksum on a udp packet. vague handwaving if you ask him. Stig: don't have any opinions. seems unclear what impact would be. would be nice to look into that. Greg: rather than trying to solve in this draft, let it be addressed in IESG. Hitoshi: other encapsulation protocol? Greg: LISP, they are also punting. Plan is to minimize the revs. ship the bloody thing. bulk of changes are not technical: clarifications. Stig: should be able to work through a NAT. Idea is to do the same for v6 as through v4. Greg: please stay engage, please read, really like to see this doc move, we have implementations and deployment moving forward. Hopefully by end of week we will have something to read. Tim: have filtering draft. will put out a new version with some comments from Lenny. Greg: beat the list up to make people move and comment on list. Tina: this afternoon is multrans - people encouraged/welcome to come.