PIM WG IETF 84 Agenda Bashing drlb: better hash function? Will update for the next meeting. pop-count: with the IESG, had several changes they wanted, Stig ran out of time to make the changes ECMP: some changes from the IESG, but they're minor. Adrian: agreement has been reached on text to clear the last DISCUSS, but we're waiting for revision with that text. 4601bis: Jeffrey Zhang Implementation survey went out Closed, waiting for compiled results Adrian: Are you getting enough response from Marshall? Jeffrey: No. Adrian: Let's try to put some pressure on him to either do it or hand it over to another anonymizer. Next step on 4601bis: get the results, write it in a draft, pass it through the WG to the IESG. -- pim-explicit-tracking Open issue: explicit tracking querier, non-explicit tracking non-querier. Bill: Explicitly disable explicit tracking Toerless: I want the explicit tracker to keep doing the G-specific or SG-specific queries, but we can ignore the result Bill: Toerless is right, remember you need to send queries for snooping switches too, and you can have an explicitly configured mode where you don't send the queries Stig: External behavior is to be externally-compatible -- sending IGMP messages like you weren't doing explicit tracking -- so it's not visibly different. You would have an explicit configuration to do the "don't send IGMP messages" thing. Q: Informational Toerless: Why not move towards a standard? Isn't this a good thing for everyone? Mike: We accepted this with the idea that it would be informational. It's not impossible to revisit that idea. --- pim-hello-mtu Problem: MTU mismatch on subnet. Downstream router packs to its MTU, so upstream router drops the packet. Bill: OSPF and IS-IS fail to create the neighbor relationship when there's an MTU mismatch Stig: since we don't have this problem just with PIM, maybe we should solve it in a more general way, like with BFD? Toerless: We are missing the use case, since you can't get RPF information since you can't run OSPF or IS-IS. Do we want to be able to diagnose this problem to fix it? Robert: When the protocol supports segmentation, it's important to know the MTU. Lin: This is a HELLO option, just to exchange the MTU - the more useful thing is to tell the source the MTU of the whole path Toerless: If we're doing this for PIM, why don't we do it for IGMP? If we're worried about the PIM messages, what happens to the multicast data packets that are forwarded between the two routers that have the wrong MTUs? Tom: This is solved in OSPF, because it allows exchange of MTU Lin: We should have Path-MTU discovery for multicast. Toerless: could do path MTU discovery with Dino's pop-count kind of signalling Simon: Let's talk here just about the problem of signalling Stig: Why don't we discuss in mboned if operators feel like this is something that happens or don't need it? The motivation for this should come from the operational community Lenny: A survey of what the unicast routing protocols do would help, this isn't just a PIM problem -- if you have an MTU mismatch, your other protocols won't come up, so PIM will be the least of your problems. The easiest fix is: don't configure different MTUs on the same network! -- v4v6-translation The translation of addresses between v4 and v6 is a "don't care": it happens somehow, it could be a static mapping, it could be stateless, it happens somehow. I don't want to focus on that part. Toerless: What was the intended status of this? Tom: If I can't come up with any MUSTs, I guess it has to be info Mike: He's just asking for advice; we're not going to adopt this until mboned thinks that it's useful Toerless: It all sounds very simple, just translate internally based on what you're doing downstream and what you're doing upstream. There's no interoperability aspect of this, so is it even necessary to standardize what's going on here? It's all inside a router. Keep it informational. -- mpls-pim-interworking Possible working area between PIM and MPLS Want a single PIM domain connected by an MPLS backbone; use a P2MP LSP in the MPLS domain. "mPMBRs" join the MPLS and PIM domains. My approach: look at PIM and MPLS as interworking, instead of running PIM over the backbone. mPMBR has both PIM and MPLS interfaces. It has an internal "Quasi-PIM Interface" (QPI), which doesn't use PIM messages; e.g., when an upstream join is received, the mPMBR dynamically creates a tunnel and binds that tunnel to the multicast state. Map forwarding state (upstream state -> mflow specification); some messages (register, CRP-Adv) get unicasted; special bootstrap tunnel over MPLS to exchange bootstrap messages. Toerless: What's the point of this one? Is this the type of state machinery that you're describing hasn't been described in MPLS WG, and you've identified the need for them? Robert: We need a framework Toerless: For the other methods like draft-rosen or BGP signalling, that the whole PE behavior is underspecified? Who has raised the need for that? You're trying to cover that as well? Robert: This is an alternative approach that does not use a 3rd protocol. [[ Ran out of time. ]] -- Secure IGMP/MLD Bill Atwood: Is this something that we want to do? Tom: Vague memory of work of this pattern in AVT or MMUSIC Bill F: Tried before and abandoned always for various reason: trust domains (owner of DR can steal the key), multicast on LAN means all LAN users can see it, etc. Adrian: try karp; also see TSV and key groups Toerless: In the end, isn't this a multicast-independent question of how to distribute a key to both a host and a network access device?