PIM WG ====== 4601bis ====== Stig - trying to move this to Internet standard - Recommendations for IPSec - not much experience with implementation/deployment Brian Haberman - find it disconcerting to see IPSec text - point to RFC 5796 Alia - take the text out regarding IPSec - lack of maturity regarding implementation PIM recharter =========== - help make the WG work on things relevant to operators and have momentum - suggested name is PIM - include Yang - include igmp/mld Lucy Yong - change name to expand scope Alia - Changing means closing/re-opening WG - lose archives - scope not substantial enough to worry about changing - charter to keep WG to tasks committed to being done - don't want to give the impression that anything multicast related will be looked at Catilin Bestler - group should be default for new modeling work - clarity on where new work should go Lenny Giuliano - if changed name should be multicast protocols Mike - Plan to finish rechartering soon - Should we include - IGP based multicast - IP Multicast over 802.11 - Got an enquiry about this work - need for conversation about any issues Alia - Did talk to help with IEEE liaison stuff - Will wait for draft to come forward Lenny Guiliano - If there is energy and interest, work would be welcome Yang Models ========== Stig - Lot of interest from both vendors/operators - like MIBs, several WGs have proposed drafts - ways to do this quickly - discuss scope - interest in forming a design team Vote on whether we need Yang - 10 to none - 6 people interested in being on the design team - start discussion on mailing list with PIM Spec IGP based multicast ================ Bessler - physical networks with disjoint address spaces - looks to be limiting multicast work Eric Rosen - detailed comparison with M-OSPF - didn't understand about RP and (*,G) trees - draft seems to be mentioning a lot of things multicast to be dealt with after claim that there is no multicast work - multicast going past the IGP boundary Beau Williamson - just a variation of M-OSPF - major drawback of OSPF was the need to do Djikstra's repeatedly limiting its scalability - Response: CPU power much better now. Calculation done only initially or when topology changes Lucy Yong - primary use case is for data center - solutions for inter AS will be developed if the current work is considered valuable Ice - not really explained how multicast traffic is constrained - need multiple trees for each flow - tradeoff between state and flooding is not acceptable - if you want to announce group membership in IGP it goes to the whole network. With PIM it goes only to concerned routers - Afraid we will end up something like PIM Lenny Giuliano - If we are flooding the information using IGP why would you not flood the source information. Why do we need RPs - why is this different from M-OSPF other than using increased computational power Uma Chanduri - We have data on M-OSPF. There were no requirements 20 years back for using multicast - should address drawbacks of M-OSPF - need shared trees and not waste computational power - eases operation in data center networks Anoop Ghannani - misunderstanding on what is proposed - forwarding state is same whether we use PIM or OSPF - cross boundary problem important and needs to be addressed Ice - just need a few trees but 1000 sources but packets go everywhere - there is a lot of state on the trees that need to be pruned Jeffrey Zhang - source vs shared tree is not the key - still has the same problems as M-OSPF (flooding group membership) - area boundary issue is also important - if data center operator really cares about multicast, PIM SSM and Bidir are very mature and not very difficult - if PIM is not needed, we don't need to flood membership. We can just use OSPF like link-local flooding - no need to standardize since there is only one vendor requesting it Caitlin Bessler - scalability not addressing the right concerns - need to recognize there could be a very simple topology decision to restrict multicasting to specific set of unicast addresses Lucy Yong - document is very primary to allow IGP to do multicast Lenny Guiliano - argument that it is one protocol as opposed to two does not hold - should improve protocol not stuff everything in PIM and call it IGP or OSPF Greg Shepherd - Should take on work that improves something - there clearly are changes, need a solution so that we can honestly evaluate Beau Williamson - smaller details not really small - all that is done is extend signaling mechanism by extending IGMP into IGP - the end solution will have all restrictions in M-OSPF and have same level of complexity Vote to consider in WG 9 in favor 10 against Vote to consider other multicast protocol work majority in favor draft-contreras-pim-multiple-upstreams-reqs-00 ==================================== Luis M. Contreras Ice Toerless - is there any RPF selection for SSM Response: this is only a requirement draft. We are not doing any solution - SSM with IGMP would be a possible solution Stig - main thing is if the WG wants to explore - there are quite a few things that need to be added to the document Mike - with the proposed text, this type of work would be in scope Vote to adopt 4 in favor, none against Alvaro - what we want is not requirements but solutions draft-itef-pim-explicit-tracking draft-ietf-pim-explicit-rpf-vector Alia - Mailing list discussion between Ice and Jeffrey - text agreed upon in discussion missing in the latest draft - Jeffrey to re-check latest draft draft-ietm-pim-drlb Drafts with no updates since last IETF - draft-ietf-pim-hierarchicaljoinattr - draft-item-pim-igmp-mld-wireless-mobile - draft-item-pim-source-discovery-bsr