PIM-WG Notes # Chairs - Please note Note Well - IPR Policy, let WG know if there is any IPR on drafts presented today * Updates to 4061 it's RFC editor's queue, editor has some comments for consistent wordings etc and ready for publication * explicit tracking Mike: moved to experimental from proposed standard * RPF-vector, AD requested to add more robustness to security section, also question on status informational, experimental ? Stig: previous AD suggested it to be experimental, and had a last call. Also there will be minor changes to make commentors happy w/ the darft. Last version will be posted on the list. * DR Load balancing: AD had some comments, draft will be modified and updated soon * IGMP-MLD wireless mobile commit to update in the next month, Mike and Hitoshi will update the draft, incl comments given in the past * Source Discovery BSR added some text, would need people to review has not changes since last IETF. Stig plan to do some more changes and present it in the next IETF * PIM Join Attr for LISP IESG is not wanting to take on new LISP work until LISP wg make some progress * PIM-NG please provide comments on the list, author has been pining the list # draft-ietf-pim-hierarchicaljoinattr - Stig presenting... - question to wg chairs, can we do wglc ? Mike: ready for last call, polling the room room: no hands for LC, no hands for not ready for LC exec decision by chair - wglc on the list and see what happens on the list, Plea from Stig for people to read the draft and respond to LC... # draft-ietf-pim-multiple-upstreams-reqs - Carlos presenting... Seil: shape of draft is good, want to see more general considerations also link status of upstream interfaces need to be detected,one of objective is to redistribute traffic carlos: load balancing and resiliency are already in the draft, but not consideration for lin status, if more input please send it on the list Mike: righ now it's focused on fixed scenarios, what about mobile ? Carlos: draft started with mobility, but now more focused on fixed scenarios, Mike: enough mobility scenario requiring another draft ? Carlos: no Stig: For now one document would be fine Stig: wg if you have more use cases, or requirements please provide some input, let the authors know # draft-ietf-pim-explicit-tracking - Satoshi presenting.... Satoshi: no need to qualify further 'robust link state' apart from what presented, it's up to the operator to define the robustness of link state. Alvaro: for experimental is fine, see sec 1.1, but for this to be a standard, need to provide more guidance on how this is to be done, as experiments are done then we can provide more chracterisation on it Stig: do not think need formal wglc it's already passed LC, only small changes, people can just speak up if they have issue. # draft-wijnands-bier-mld-lan-election - Ijs presenting.... Hitoshi: clarification, querier is DR ? Ijs: not necessarily, can be the same but doesn't have to be Hitoshi: this DR can take the role of querier Ijs: maybe yes, maybe no. Initial thinking is to have separate DR election from querier election. Not specified currently Toerless: Is there a benefit of keeping PIM message format and strip it down to meet the functionality needed ? Ijs: we can, but we're trying to achieve DR election in IGMP Toerless: DF election has more specific to do with PIM-BIDIR, how is it going to be used outside PIM-BIDIR ? also need to consider PIM snooping switches at L2, they know PIM messages no IGMP Stig: comment on sending PIM hellos, don't want devices to think PIM is there while it is actually not there. Also wrt to DR load balancing and backup works, would be nice to have a solution for PIM which also works for those scenarios. PIM is better place for this than BIER. Ijs: I'm fine for it to be here Mike: the work can be done in BIER, but any alterations to IGMP/PIM to be done here. Alvaro: fine whaever you wanna do, PIM chairs and BIER's to coordinate NN: Is this technology to be used on edge BIER routers or all ? Ijs: at the edge, outside the overlay domain Greg: need to be clear a bout that, in BIER talked about interior ingress-egress and exterior ingress-egress, problem maybe different and solution maybe different, in this instance where two interfaces see each other, who's going to pickup packets into the overlay and who's going to put packets off the overlay. From BIER-wg perspective, this is more generic problem, rooted in assumptions made 20 years ago, it's great to see separation of functions, make more sense for this to take place here however, immediate use case now is BIER and so, need tight coolaboration w/ BIER. Jeffrey: it belongs here, and maybe should remove BIER from name, even if BIER didn't exist, this technology still makes sense. LAN could be virtual LAN. Greg: make sense here, but wherever the drive to do it, take it there Stig: does room think this is interesting and something the wg should take on ? not adoption call, but raise your hands if you think this could be interesting or you want to work on it ? room: 6 hands raised Mike: did you ask BIER ? Ijs: Friday, going to shop around # draft-asaeda-pim-multiif-igmpmldproxy - Hitoshi presenting.... Seil:asking for clarification on the decision order, subscribers are attached to different prefix ranges on different interfaces, in that case could the same channel be received on both ? Hitoshi: yes, if intentionally configured Seil: not intentional, you don't know which one subscribers want, the situation could be complicated. Hitoshi: configuration options allow subscribers to go to correct upstream interface eventough subscribing to the same channel - this is static configuration. No automatic configuration specified yet, what kind of automatic conf. should be specified in this draft ? Stig: Needs some discussion whether there is requirements for automatic configurations, might make sense for different scenarios Stig: in general deployment you may not want to have multiple upstream interfaces, even if routers support it operator might not want to do this by default, maybe multimob ? but in general I'm not sure Hitoshi: multimod also depends on configurations, Stig: must be worth discussing requirements and use cases, what conditions this can be useful and so on Hitoshi: so maybe do not need to specifiy automatic configuration in the draft ?then it's close to the goal Stig: can't really complete solution document until we know more about requirements, so discuss more on requirements and update the draft so it's alligned with the requirements, if there is no requirement for autoconfigurations, then maybe should not discuss it in document Seil: is it the chair's recommendation to remove automatic ocnfig ? Stig: might make sense in some scenario, but it's hard to say...need to discuss use cases in more details, also discussion in room. Could be other cases like homenet or other ? Seil: This kind of solution is popular used in operators network Stig: if you use SSM, might be safe to have multiple upstreams, in general, if you're not sure about topology, it's dangerous to determine this group joins that upstream etc... Seil: WG should come up with tools and compile the tools to make this kind of autoconfig possible Stig: autoconfig is additional, one choice is doing it separately, or add more usecase in the requirements. # draft-anggawijaya-pim-resilient-gmp - Angga presenting... Mike: there is potential practical use of this, one scenario is multicast in WiFi environment which is challenging- discussed in mboned, no acknowledgement, congestion, etc. This could potentially help with lack of acknowledgement on multicast packets unlike unicast. Whatever happens on the progression of this draft, probably will include this draft as one potential solution on wifi multicast problem statement draft, it can be potential usecase of what it's been proposed here. Stig: I agree that new message is required for acknowledgement, also adds consideration to snooping devices and explicit tracking wrt to robustness Angga: yes, will add section on considerations on those Stig: also better to use new type rather than reflected report, take it also to mboned to see if they think it might be useful, also interested to see if people in room think Hitoshi: question on title, is this the same as reliable IGMP ? increasing robustness is a tradeoff, congestion may increase. The reason for packet loss is bad link condition, akcnowledgement might make it worse....it's a trade-off, you don't guide just increae robustness ? Angga: no Hitoshi: This requires acknowledgement Angga: yes Hitoshi: Someone published RFC on reliable IGMP ? Stig: Rememberred someone proposed unicast reply to queries, but not ack for report Hitoshi: If this is reliable IGMP/MLD maybe interesting for some environment, this is positive opinion. Angga: main point is to shortent dead period between report being sent until the next general query. Mike: one draft out there Hitoshi and I have about ways to help promote a more beneficial IGMP activity in a mobile environment including sending unicast and doing different things, may just want ot review that, but that doesn't go as far as creating extension to IGMP, just review and find out what existing drafts may have been proposed in the past, but a couple of people at least interested in this work, and let's take it to the list. Angga: IPR might exist, but checked it's not there yet. Stig: next IETF, take it to MBONED to see if this help with problems with multicast deployment. # draft-zhang-pim-dr-improvement - Sandy presenting.... Jason: lan w/ multiple vlans with 2 different DRs, DR-A and DR-B, after failure of DR-B, how do you normalise back to having the two DRs on the different vlans ? Stig: if DR goes away, and BDR becomes DR, and if the old DR comes back, would you use the old DR later ? Sandy: old DR will follow the rule and becomes DR again Stig: what you could do is when the old DR comes back it could start with priority 0, and after rebuilding forwarding state, could start sending hello with configured priority so that the old DR could become new DR again, but need some delay so not to loose packets Jason: it's like having a pre-empt options w/ timer Stig: there are a couple vendors that do something like that Mike: who feels this draft is something we should take on as a wg ? Stig: this is useful, a couple of vendors implementing something like this, something along the samee lines, room: 7 hands for wg adoption, and no hand for not adopting Mike: pretty good indication # draft-mcallister-pim-yang - Liu presenting... Mike: YANG design team, did a great job and making big impact Mike: WG adoption ? Room: 6 hands, no hands for 'not ready for adoption Stig: anyone is welcome to join the design team, PIM work is almost done, but IGMP MSDP etc are still to be done.