Hiroshi: review status of work items. Two rfcs published after last ietf. RFC5110 (used to be draft-ietf-mboned-routingarch-12) RFC5132 (used to be draft-ietf-mboned-ip-mcast-mib-07). drafts which had wg last call: maccnt-req-05. This was the 2nd last call. Received alot of iesg comments after the 1st wglc. No comments after 2nd last call. Will resubmit to iesg. Ron Bonica: make sure all the DISCUSS's have been resolved, maybe check with the people with the comments and resubmit. Then send me an email and i will take it to IESG for reconsideration. ipv4-uni-based-mcast-04. alot of comments on draft. revised 05 version and on the agenda today. addrarch-05. it is waiting for other draft (uni-based-mcast-04) becoming rfc. Pekka:as author, another thing waiting for is resolution to eglop space and iana allocation which is later in agenda items. presentations of active drafts: Sato: multiaaa-framework-06. updated: especially 1) accounting and control mechanism developed further. 2) Reflected ANCP framework draft. this is companion draft to maccnt-req-05, just presented. Changes include 1) NSP records accounting stop if user requests leave OR multicast state timeout OR reauthentication failure. 2) 2 levels of accounting level 1 with channel and user IDs and start and stop info, level 2 adds traffic volume info. 3) QoS class info is optional for each level. level config of accounting messaging between NSP and CP (either preconfig or dynamically requested.) ultimate admission decision made by NSP based on NSP AAA or NSP performance. QoS class downgrade. Detailed downgrade mechanism descibed in framework. NSP can downgrade to besteffort if cant provide guaranteed QoS. User can indicate whether will accept besteffort traffic in request. CP may also indicate besteffort preference configured statically or dynamically. NSP doesnt stream besteffort if either user or CP doesn not want. This is optional functionality. Changed terminology that was too specificic to NGN. Removed mention of caching, changed to caching. Added reference to ANCP framework draft. awaiting comments from ANCP working group. Requests any comments from group. After next revision wish to go wglc. Hiroshi: received some comments from outside wg. raise hand if read draft: 7 read. thats increasing plus external review. Interest increasing. Also encourages members to look at activity within ANCP. Stig: ssmping-04. been 2 revisions since the last ietf. Changes: basically new name to protocol and protocol simplified a bit. ssm-ping before. new:multicast ping protocol. This protocol fairly generic, multicast tools could be created from it. simplications: padding option. multicast ping protocol spec should be more readable. Text on rate limiting and security security considerations. Stig feels draft is done. Need more people to read it. ready for wglc? Marshall: do you want a particular area reviewed, we can get the right people? Stig: Not really. Marshall: how many people think this should go to last call? anyone think it should not go to last call? good consensus, move forward. Dave Thaler: ipv4-uni-based-mcast-04: rfc3306 is the v6 version. This is the v4 version of that rfc. last draft wglc was issued dec. 12th. Strong consensus for but not unanimous. Lots of comments. posted issues/resolutions on the list. Go to list for full discussion. Rough consensus for permanent addr assignment. Toerless argued against permanent. all mention of the 1 year experiment has been removed. use mcast.net? use something shorter than /8? prefix length- /8 is more easliy human understandable He thinks all issues dealt with and ready for iesg but wants to check with group. Peter: should someone use this /16 for their 256 mcast groups, find it fine to use dns reverse mapping for that. reverse mapping could point to anything not just mcast.net. no infrustrature in place at point of IRR/LIRs to actually support this. Would have to identify the holder of the /16 in between. Thats an operational reason that there will not be a reverse mapping for that. Explicitly mention this in the document and the IRR/LIRs dont need to support it. Saying nothing is not the best way to go forward. Dave: I have no problem to that. Do you think there are similar issues that are part of glop, etc. Does the wg need to do anything for that? Peter: I'm working on mcast.arpa draft. I did spot this gap in there as well. Might be able to address glop, etc in mcast.arpa draft. Marshall: would be better to use example.com. There is an rfc on that. This should be in 3171bis, would be more natural there. Toerless: as far as dns is concerned, should try to resolve this in separate place than this draft. excellent work, very thorough. if it were ever to the point of writing an bcp of what internet mcast is or should be, could never say ASM could be recommended for v4 mcast, dont have a standard track doc for it (msdp is experimental) and dont have resolution for security concerns. What would be the bcp for internet mcast: must support ssm must not support asm? This is one of these drafts that unnecesarily try to solve a non working model of the internet. Dave: you are making the same argument for anything in internet scope pekka: This needs to be said somewhere, maybe iana guidelines, but not this doc. Dave: Is this any consideration that is unique to this space or same recommendation that you would have to other drafts? Peter: both. This is spotted while still in doc preparation. dont defer dealing with issue. operationally: the uniqueness here is this kind of addr space and assignment follows, exploits, and leverages on assignment heirarchy present for unicast space. makes it special but not unique. Dave: the question is whether that specialness should be addr in this draft or another. Toerless: would we have a problem statement or a solution. Dave: no solution in this document. Toerless: agree. Peter: one solution is to declare we dont expect reverse mapping in this space. Dont delay publication of this document. Dave: Add a sentence that it is not expected that dns reverse mappings to be present. Or do nothing, addr in a future doc. Marshall: do nothing or dont expect it to happen? who wants to do nothing? 2. who wants to add a sentence? 4. will confirm on list. Gorry: what does the sentence mean that we are not doing it now but will in the future. Dave: does not preclude someone from doing it. Toerless: just informational. Dave: Peter, send me a sentence. Peter will send a sentence proposal to list. Peter: If I as a customer grab this doc, and have mcast addr from LIR (I'm used to dealing with reverse mapping from them), and ask to please organize this reverse mapping for me. But the LIR says ietf failed to specify this. LIR Doesn't want to look incompetent. Marshall: IRR/LIR not responsible until a future doc if there is a future doc. Pekka: could user of addr space approach iana for allocation? Dave: no, iana only permanent assignments. Marshall: a sentence would be good. Dave: peter will you send me a sentence? Peter: yes. Dave: should I rev draft before sending to iesg? Marshall: yes. Marshall: anyone opposed? rough consensus, most think should go to IESG Liu: lightweight-igmpv3-mldv2-02:draft hasn't changed since last ietf meeting. simplied version of igmpv3 and mldv2. Discard rarely used exclude operation. Open source code after this meeting. wglc? Marshall: when will the source code be published? another person from Hauwei: between this meeting and next. Wei, Hauwei: router side completed. Marshall: how many people have read? 10 Hiroshi: need to wait for the next revision. then we'll see about wglc. Toerless: object to this draft. every vendor is welcome to simplify v3 as long as it is fully interoperable. then there is no need for a draft. If its just simplier implementation, that is a vendor decision, should not be an rfc. Wei: problem with interoperability? Toerless: if you are creating a new protocol, the only reason to doc it is because it creates change to interoperablility. if its just a simplified implementation, dont see a need to have an rfc. Wei: Customers like to see an RFC. Pekka: its not obvious if this is targetting standards track or informational rfc. I'd be ok if this described a profile and informational. Thomas: useful as a spec, but this would be enough as info rfc. Dave Thaler: I dont have any real opinion on info/proposed standard. Do feel value to this doc. had an implementor say this v3 thing is real complicated and we have a resource constrained device, what do we do? wants to be completely compatible with routers. Dave pointed them to this draft and they went away happy. as long as this draft can interoperate with existing fully v3 compliant routers it is fine. I am in favor of this document as an rfc. somebody already implementing this. Marshall: speaking with chair hat off: its not obvious what vendors should do. therefore there is value to this draft. Marshall: how many people see value in this draft as a wg item? opposed? There needs to be another rev. think about the track of this doc, standards track or not. hopefully the draft will be ready for final call by dublin. I will take that to the list. Marshall: charter discussion. we proposed a new charter at the last meeting. there were 32 emails from 11 indiduals. 6 in favor, 2 opposed. revised. 9 individuals commented, all on this point here: which was added at request of ADs. why would we say we wouldn't entertain protocol development? Ron Bonica: two points. 1) do we develop protocols. occasionally we do. normally ops area doesn't. this wg an exception, we do mtrace and ping. we should say something like the wg doesn't develop protocols but may do something for mcast debugging or diagnostics. 2)we wont interfere with ongoing work in other wg's. Marshall: noboby objected to that. its implicit. Ron: we've just reinforced the rule that was already there. its implicit but people are violating it in other wgs. Rahul: I agree with Ron. a little detail which is interesting. With oam and debugging, mpls working group is working on these things so we need to be even more precise. Ron: He's got a point, dont want to be stepping on mpls wg toes. Tom: The amt work is clearly not diagnostic work but it is transitional. it would be nice for that to fit here. Marshall: igmpv3 is also not diagnostic. Ron: v3 is a good example. if we were writing something that did have interoperable issues with v3, we would be out of charter. but because there are no interoperability issues we are not out of charter. Marshall: improvements? Ron: not just improvements. if the igmp work is informational, and just an implementation and not changing the protocol, but if we were changing protocol in a substational way we would be out of charter. Marshall: The trouble with that, what if there was a hold in v3, are they really going to start a wg to address it? Toerless: I whole-heartedly disagree with Ron. it should be taken to the list for a full discussion. The more I listen to this its micromanagement of the drafts he likes to have here and he just wants to take the other work to a more friendly wg. We don't need a micromanaged charter. Dave: for protocols like amt, they are somewhat grandfathered because the wgs they would have fit in have shut down. perhaps say here are explicit things in our milestones. Only such and such discussions are in charter. for things like igmpv3 work, that wg would have magma. if changes to v3, it wouldn't be in ops group. extensions ok. perhaps have as an AD sponsored draft with mboned reviewing the work. Dont have a problem saying transition things are here as long as they are explicit charter items. Marshall: if someone said they want igmpv4 you would say they either need to create a new wg or go AD sponsored and reviewed by mboned. Ron: I'm agreeing with Dave. But a step further. igmp is the property of the internet area. if we wanted a v4, just because they've shut down the wg, it doesn't give us the right to take the work. best way is to go to internet area and ask them to either do it in the open group or spin a new wg. Marshall: would like to propose, to wordsmith it a little bit and send it back out to the list. Dave: no objections, when doing that make it be noted that its allowed that the ops area can do protocols but they must be diagnostics or transition. its too strong to say we won't do protocols period. Ron: he nailed it. diagnostics and transition. yakov: i support that too. Stig: we do have people in pim wg proposing extensions to pim for diagnostics/mgmt/ etc which belong in pim wg. would like to see this wg looking at generally mgmt problems we have, but specific extensions to pim belong in pim. Marshall: send text Dave: Of the diagnostics you mention are they are diagnosing pim or mcast. Stig: pim Lenny: before moving on, has the charter discussion ended? In the proposed charter, the one concern I have is the addition of mvpns to the charter. kind of capricious and arbitrary to extend our scope beyond internet multicast for the first time, this has only been about internet deployment as opposed to other non internet mcast scope multicast, vpls, l2, mobility and various other non internet. adding mvpn here seems arbitrary, why aren't we leaving that in other wgs. Ron: This applies to the sentence I said earlier about spillover from other wgs. l3vpn is exactly the thing I was thinking about. Lenny: that's my concern. you have the potential for competing and shopping for drafts. if it doesn't get into this wg we'll go over here and see if we can get it done. Ron: on the one hand I dont want to restrict this group to just multicast on the global internet because most of the multicast is on the enterprise and on vpns so in the long term I dont want to restrict the wgs charter, but short term want to make sure that debates about vpns are in l3vpn where they belong. Toerless: this is the operational group so anything operational about mvpns would fit perfectly here. Lenny: if that's the case this is not mboned, its mcastops. why not do the same thing for mobility, vpls, etc why just mvpns? Mike: this was debated at great length on the list and as Marshall stated we had reached rough consensus so not sure why we are revisiting this. Marshall: I can declare rough consensus for spirit of the text but not the letter, so I agree with you there. Toerless: If there is operational experience with multicast in other areas it shouldn't be excluded either. Multicast operational experience in a mobile environment should be here as well. not particular fond of mboned name either. Marshall: I'm not worried about it operationally since we have the l3vpn wg chair who is also our AD and is at every one of our meetings. Mike: mvpn-pim-deploy-02. updated pim based mvpn deployment draft. changes based upon comments are: removed even historical mentioning of draft-rosen. any mentioning of draft-rosen in the description has been removed. At this point the only place rosen's name is listed is in the contributions section of the draft. alcatel-lucent approached us and informed us they have an mvpn implemention in their Tim0S and also offered numbers for scalability for deployment with their scalability numbers. Dmitry:reviewed the scale chart. next revisions will provide more text what numbers are representing. still using terminology of draft-rosen will change to wg draft terminology. Mike:should also add resiliency info to it as well. Dmitry:yes, so we can determine switchover time and performance. would be helpful to have resiliency in the document along with existing implementation info. Mike: appropriate time to ask for it to be a wg draft? Marshall: who has read this draft? pretty good should it taken on by the group? 6 Rahul: should we wait for charter to be complete? Marshall: no, AD asked for consenus of group. should not be taken on by group? 6 Yakov: two questions: 1)is it useful for this wg to have a deployment doc to doc draft-rosen? 2)is this doc an appropriate instance of that experience? Mike: this draft docs the standards based pim mvpn deployments Yakov: I didn't ask for answers to these questions Mike: oh, ok, they are hypothetical questions. Yakov: It still has alot of problems, not ready for primetime. may give impression that life is good. but there are issues with draft rosen. for example, switching to s-pmsi, issues with join latency. another issue, to Maria, she made known that its important to doc anycast rp, this should be in this doc as well. Also, security section is a joke. This draft is not ready for prime time. Ron: need to correct something. there is no standards track doc of mvpn, its a wg doc, but in its current state there is no way its ready to be sent to the iesg. Mike: good point. Rahul: first question, not just doc operational experience with draft rosen but also doc interoperable experience with draft rosen. even now this doc talks about lots of things. a bunch of stuff not implemented by juniper. what is interoperable? Mike: We should add more info on interoperability. Rahul: I'm not suggesting, just pointing out a fundamental flaw of the draft. Mike: whats the flaw? Rahul: last time it was pointing to rosen08. Mike: now its completely referring to the wg draft Rahul: you are missing the point, the wg draft doesn't have the machinery that rosen08 did. mdt safi, etc Mike: those are just minor protocol encodings that are not that critical. Rahul: then don't talk about minor protocol encodings just talk about the major ones. Dmitry: we are going to addr the resiliency aspects and switchover. this will be in next release. security section, what is something we can base on experience? anycastrp will be expanded. will continue to enhance the draft based upon comments in the group in a positive way. Marshall: Make the comments on the list please. Thomas: what was the subject for rough consensus, for including experience doc on mvpn? Mike: right Thomas: I would expect more info from a best current practice. Mike: its not a BCP Thomas: how does it fit in charter change. Mike: Charter changed from being global internet only. Thomas: is this suppose to fit the bcp item of the charter. Mike: No, informational experience draft Thomas: experience on pim in the core backbone between PEs? Mike: yes. and someday I envision a doc based upon deployment experience with bgp based, etc, mvpns. Thomas: some of these are common across technologies, if you use pim in the core, its also relevant if you use something different for the control plane. this info shouldn't just be in one draft. Eric Rosen: 2547bis-mcast-06. waiting to hear that I've been ruled out of the charter all together, even as a speaker. I'm not asking the group to adopt any documents or protocols so feel free to say whatever I want. useful to go to multicast ops group and familiarize you with recent mvpn work. trying to get feedback on options that have been generating controversy more than others. will these new features really support enterprise apps? many of the new options have been created by unicast routing experts. We are talking about enterprise apps. See presentation for presentation details. Yakov: I'm glad you mentioned TCP because pim-wg just put pim over tcp and you should tell them how bad that will affect latency. you should repeat all your arguments. Eric: with pim you wont need RRs. Yakov: you don't need them with BGP either. Eric: we are going to have RRs in any actual deployment. Also, their tcp connection is not shared with unicast routing. Yakov: you can do the same thing for multicast Toerless: theres also no best path calculation and its not only join latency also reconvergence events going to another upstream PE. Yakov: some points are correct. some misstatement. some outright wrong. questions for mboned group: are bottlenexks properly addressed? Ice: mvpn-profiles-00. partitioned mdt. Its a solution which is documented in section 3 of the profiles draft. its a dynamic version of the rosen draft. combination of an emulated lan and a p2mp network. tree is a mp2mp lsp. set up partitioned mdt per ingress PE and only when you want to send data. today you need the tree to be static to run pim over it. root is ingress PE. don't need to statically define roots. for customers who have sources at every site, this model isn't that good, better off with static mdts of rosen. pim procedures only occuring between interested PEs. See presentation for details. Yakov: what is the presentation doing in this wg? how is it related to operational experience. Marshall: Ice is looking for feedback from our wg. Ron: the only thing we saw was profiles draft on the agenda. Ice: section 3 of the draft. Ron: question of whether this is appropriate for this group. No great loss if its not. Eric: its really tiresome to hear people making arguments of what people shouldn't be allowed to hear. Anything can be presented before a working group thats of any interest as long as the wg is not being asked to take action on it. I hope we don't have to get lawyers involved every time anyone wants to present a draft they think might be of interest to a wg. Thomas:mvpn-considerations-02. presentation not directly in charter of wg. Its a draft written from operators involved in l3vpn. The current mvpn draft includes several options of building blocks and in its current state its more a framework doc than a doc ready for iesg. not enough to provide a solution that would provide interoperability. identifying a set of mandatory procedures. goals are to discuss the different options and identify the ones that are good candidates for a set of mandatory procedures. non goals are not excluding an option. anything not mandatory still described as an optional procedure. mboned to review comparisons between different approaches. see presentation for more details. Marshall: we should be thinking about how to proceed with a bcp in mboned. Pekka: l3vpn should provide a doc which is interoperable. otherwise there should be a bcp and it should be written from those not involved with protocol design. Marshall: drafts help drive effort. Ron: A good thing to get a high level overview whats going on in l3vpn particularly Erics showing us to know the issues. encourage everyone to participate in l3vpn. encourage important decisions and debates to happen in l3vpn so debate happens in one place. the experience we saw today is the same debate we have in l3vpn, lets have it in one place. Toerless: so l3vpn is now an operational group? how does it work? Thomas: the 3 last presentations were not operational. Toerless: at least Mikes was. Ron: 3 weren't operational, but informative. interesting observation is the one operational one ended up the same way it did in l3vpn with the same players saying the same things. Marshall: 3171bis draft. all issues seem to be textual. I will take to the list. Pekka: comments I raised on list are substantial. propose significantly change iana allocation procedures so enterprise, for instance, can request /24. Dmitry: one comment, going back to presentation I did with Mike. We receive each ietf to improve a section. Please provide feedback now on list so we can make fast changes and not delay document on meeting to meeting basis. Marshall: meeting is closed.