Protocol Independent Multicast (PIM) WG IETF-74 Tuesday 13:00 Chair(s): Mike McBride Stig Venaas Note-taker: Stig reviewed status and agenda. * Link-local security draft-ietf-pim-sm-linklocal-07 (Bill Atwood) Two revisions had been made since the last meeting. Brian Weis had provided a secdir review prior to WGLC. This had proved very helpful, and significantly improved the content of rev -07. Vishwas Manral: The draft is nice. Why is the transport mode a requirement in this document? Whereas, IPsec specifies the tunnel mode. Bill: We use transport, because although it is a router, this is acting as a host between adjacent routers. In contrast, OSPF uses tunnel mode. Vishwas: My comment was that IPsec is seeking to remove the transport mode, although tunnel mode is more complex, it also covers all cases (and it would be nice to reduce the number of modes offered by IPsec). Bill: I do not know enough about IPsec to answer this question. Can you email me the comment? Vishwas: I will do. Mike (as Chair): The WGLC has been completed, but there were no comments received during the WGLC. Who had read the latest version of the draft? - 4 people have read the latest version. Who would like to forward this to the IESG for submission: - For, 4 people - Against, 0 people Mike (as Chair): Can you make sure you check whether transport mode is the correct approach? We then plan to take this forward to the IESG once this is settled. * Presentation on RFC 5378 Issues (Bill Atwood) Bill reviewed the recent changes in IPR rules and how these impacted submissions for drafts to be published. Gorry: Of the 3 case in the slides, is the simplest way to get through the problem at this moment, to use the case 3 (i.e. leave the onus on others to chase permissions), at least until the IETF defines what to do next? Mike: Yes, if you cant get author permissions. * PIM MT-ID Join Attribute (Yiqun Cai) draft-ietf-pim-mtid-00 This was accepted as a WG draft after IETF 73, replacing draft-ietf-pim-mtid-00. The draft is generally stable, and -01 will address some issues. Dimitri: How do you consistently set the MT_IDs in different routers? Yiqun Cai: There is a local rule. Yiqun Cai: The PIM MT_ID space is independent of the MT IGP. You can have local preferences - PIM MT_ID 100, OSPF 200 could contribute to PIM MT_ID 100. Dimitri: Independent spaces are desirable, but we need consistency with the understanding of the PIM neighbours. Yiqun Cai: Should this be part of this specification? Do you want to offer text? Dimitri: I will contribute text. * Multicast only Fast Re-Route (Dino Farinacci) draft-karan-mofrr-00 There is CISCO IPR associated with this I-D. Multicast trees need resilience to network outages. This draft seeks to provide resilience of the order of 50-100ms, most current router implementations can do 100-500ms reroute. This fast switchover needs to not rely on message exchanges and use equal-cost multicast (multiple equal paths). Dimitri: What if the alternate path fails? Dino: There could be more than one resilient path. Lenny: How does downstream router know which router to use as the alternate path? Dino: We could configure it, or we could find the alternate paths from the RIB. Hitoshi: So it receives data from both interfaces? Dino: Yes. Hitoshi: So, we could join twice, but doe we suppress the data for the alternate path? Dino: Yes, but this would be slower. Greg: Are you worried about the cost of duplicate data? Hitoshi: We could keep the state without receiving the data. Dino: We could find this out from the link-state database. Greg: The duplicate data is only to the router, the RPF is pruned, it does not flow downstream. If we provision resilient paths, we need to have redundant capacity. Stig: This is a three-way trade-off. Leo Roberts: Hopefully this is not processed using the slow path? Dino: We hear you, and we think the packets should be dropped in hardware. Lenny: Are you concerned we are returning to the ideas of data-driven states, which is going out of fashion? Dino: The control plane can watch the counters, and then tell the forwarding engine to change. What you do depends on the hardware. This is not watching data packets, the machinery is polling the counters. This is control plane. Dimitri: There is a problem of detecting failure - there is no mean even by using unicast multi-hop BFD from the downstream selecting router towards the source to detect the liveness of the multicast path towards that router. ?: What happens if there are no source packets for a group for a while? Dino: You need to look at activity on both interfaces, so they know if the data arrives at either interface. Liming: We are dealing with this on our platform already (cisco). There is a case when the stream is irregular (varying rate). Constant streams work well. Dino: Could you comment on the cost of polling hardware? ?: this is easy and efficient to detect this. Gorry: If one path has much more delay than the other path, then you also have an intermittent source, is this not going to cause some flapping? Dino: Yes, you need to configure some slop to avoid duplication/loss, it's actually not just as simple as it may appear. Lenny: Does this have a narrow deployment scenario? Can you expand this approach and reach more common scenarios? Dino: So, you want us to solve all four cases (in the slides)? IPTV service networks are important, and usually using a ring topology. Greg: There are tons of other applications for which this can be used. Dino: FECFRAME may help make this switchover more robust. Greg: Or multi-dimensional coding? Stig: What would you like to do with the draft next? Dino: I would like to take this question to the list. Stig: There are various approaches: this could be informational, etc. Dino: I would like to see comments first, before we decide. Dimitri: The main question is what we need to document? Lenny: Does this imply a change to PIM? Dino: There is no packet format change. It is just the addition of a new action to generate a secondary join. Someone suggested that this could set a bit in the state to say this was a secondary join, and let you have more options when the capacity is constrained. Dimitri: It would be nice to know when this was needed because it gives a lower bound on time performance that could be reached. This would be useful to document. Dino: Yes. We also do not have the much experience of non constant bit rate sources. Mike (as Chair): We will take this draft to the list for comments. Adrian Farrel: I am your new AD. Meeting closed.