pim wg meeting Monday November 5, 2012 13-15 Title Presenter Minutes ========================================================================== WG Status Stig/Mike 10 draft-asghar-pim-explicit-rpf-vector-00 Javed Asghar 10 4601 update Stig 10 draft-ietf-pim-explicit-tracking-02 Hitoshi Asaeda 10 draft-liu-multimob-igmp-mld-wireless-mobile-02 Mike McBride 10 draft-zhou-pim-vrrp-00 Stig Venaas 20 draft-asaeda-pim-mldproxy-multif-00 Hitoshi Asaeda 10 draft-contreras-multimob-multiple-upstreams-00 Carlos J. Bernardos 10 draft-asghar-pim-explicit-rpf-vector Javed Asghar - Build multicast trees via an explicitly configured path sent in the PIM join. Lenny: You're reinventing MPLS, why not use MPLS? Javed: Operators using PIM want to stick with PIM. Toerless: (did not understand the question) Toerless: You have to ensure that all the configuration of the receiving routers are correct. Stig: You need to have global addresses. Think about address list HELLO option. Mike McBride: At the beginning of the draft, explain the motivation for this. Lenny: What you want is multi-topology routing. (S,G,blue), (S,G,red) Lenny: What would unicast do? With unicast when you want something more than what IGPs give you, you use MPLS. Toerless: They're just preferences of some operator communities. Javed: If you tell them to use MPLS instead, it's not going to happen. ? Lee: What if one of the specified nodes is down? Javed: The JOIN will not route. (did not understand answer) Stig: Do you want this adopted in the WG? (4 people in favour of adoption, 2 people against) RFC4601-bis Survey Preliminary Report Stig - Survey of PIM-SM implementation and deployment (vendors and operators) - 9 operator responses, 8 vendor responses Toerless: What are the actionable items for this WG? Stig: Yes. Toerless: I'm a fan of having a base PIM-SSM document, then others as add-ons. Stig: We can remove stuff, add explanations. Explicit tracking, (*,*,RP), etc. Stig: Discuss on the list. Mike: Are we at the point of writing a draft? Stig: Before christmas. draft-ietf-pim-explicit-tracking-02 Hitoshi Asaeda - IGMP/MLD-based explicit membership tracking function for multicast routers Stig: We should decide on the intended status before WGLC. Mike: WG adopted the draft because it was informational. We do not want to do bait-and-switch. Stig: Status change can happen but needs good support. (3 people have read this draft) (3 people say it should be standard) (0 people say it should be informational) Sue Hares: Why do you want to go to standard? Explicit tracking has some very valuable debugging stuff. Hitoshi: When other protocols want to refer to explicit tracking, they cannot do it as normative reference if it is informational. Sue: Why does that matter? Dino: The subject matter is IGMP/MLD explicit tracking. If it's compelling enough, why go halfway? Make it full standard. Adrian Farrell: Decide the track based on contents, not based on who wants to refer to it. If this is an implementable protocol, make it standard track. Dino: Explicit tracking is an importnat feature that we need to have. We should go full steam ahead (full standard). Sue: Yes, it should go for standard. Toerless: Default preference should be IGMPv3 + explicit tracking. Dino: Maybe we should do IGMPv4. Toerless: There once was IGMPv3 lite. (6 people want it to be standard) (0 people want it to be informational) (Will be asked on the list. If the people that wanted it adopted as informational don't speak up, then it will change to standard.) draft-liu-multimob-igmp-mld-wireless-mobile-02 Mike McBride - IGMP and MLD optimizations in wireless and mobile networks - Was presented in multimob. Brian Haberman suggested to move it here. Dino: Packets to class D addresses may be unicasted at the link layer. Toerless: Many vendors are already doing that. Sue: (did not understand question) Stig: Some of these optimizations may apply to one environment, another set of optmizations to another environment, etc. - Triggering Reports and Queries during handover Dino: That depends on the L2 network. Stig: If you have a switch that detects no link on a port, it makes sense. Stig: I think it's useful. Mike: We'll make a new revision of the draft with Hitoshi. Toerless: Draft should talk about energy efficiency. (5 people think this should be done here (as opposed to multimob)) draft-zhou-pim-vrrp-00 Stig Venaas - PIM VRRP interoperability - Adjust PIM DR priority depending on who is master - The intent is to document the behaviour. Dino: You're making an active/backup protocol, but it could be active/active. Dino: The best way to do this is: (did not understand, but it sounded nice) Stig: I agree. Dino: You may want to coordinate with the work that Mike and Hitoshi are doing. Dino: IGMP should be part of ICMP. (semi-joking) draft-asaeda-pim-mldproxy-multif-00 Hitoshi Asaeda - Multiple Upstream Interfaces Support for IGMP/MLD Proxy - Proxy as defined in RFC4605 is always in a tree topology, which implies a single upstream interface. - Proposal: pick upstream interface according to three types of configurations Toerless: Present this in homenet. But manual configuration would not be accepted. - 1. Choose upstream based on (S,G) tuple, named "supported address prefix" - 2. Configure interface priority value. Stig: How do you use this priority value? Hitoshi: Use it if no supported address prefix configured on all configured upstream interfaces. - 3. ECMP. Choose upstream based on hash of (*,G) or (S,G) so as to load-splitting - Open issue: What to do about downstream sources? Forward packets to all configured upstream interfaces? Toerless: Too early for adoption. Problem is important to be solved. Homenet should do something like this. (take it to the list) draft-contreras-multimob-multiple-upstreams-00 Carlos J. Bernardos - Extension of the MLD proxy functionality to support multiple upstream interfaces - CPE has multiple multicast content providers - Also want to provide redundancy - Focused on scenarios and requirements Stig: It's useful to have solutions like this. It would be good to do it in this WG. ?: What functionality do you propose extending? Carlos: We're not there yet. Will do in a future revision of the draft. ? (co-author): Agree with Stig. (end of meeting)