pim WG minutes Hiroshima Tue Nov 10 1710-1810 Chairs: Stig and Mike Meeting opened at 1715 draft-ietf-pim-group-rp-mapping-02 Dave 10 ================================== draft-ietf-pim-port-02 Stig 10 ====================== Stig presented changes since -01 Scudder commented that the draft still has plenty of text that mentions VPN Stig It's only instance ID text Scudder It shouldn't be a big deal to take the rest of it out Stig Any thoughts on whether we should keep the instance ID for future use? Scudder Can leave it in as 'only zero is the defined'. Stig That's what we'll do. Will update the draft for the next IETF. Stig: How many people have read the draft. 4-6 hands of 40-50 people present Thomas Morin: Also commented that many instances of VPN are left over. Thomas Morin: PIM specification defines a bit that controls join suppression, is there an interaction between these procedures and the explicit tracking described in this draft? Stig: It is possible to have both port and non-port neighbors, it is possible to have a mix. Thomas: Need to be consistent with the T bit in the PIM spec. Stig: I'll add something to address that. Thomas: The draft mentions ... and SCTP. If it is possible to do both, which do you use? Stig: I had this comment on the draft like a year ago before I started working on it. Perhaps the administrator should configure it, or perhaps one should have preference over the other? Thomas: You need to do something. Stig: Yes, thanks. That's it. draft-ietf-pim-mtid-02 Yiqun 10 ====================== Yiqun: Between -01 and -02, the PIM MT-ID space has been carved up, introducing reserved ranges. Updates also addressed Dimitri's concerns about what is exchanged between MT and non-MT routers. The -02 routers include Hello option to address this concern. This must be present in Hello packets from PIM routers that support MT-ID. MT-ID routers must then include MT-ID in all join attributes sent. Yiqun: Authors consider we are pretty much done in the base draft, hopefully ready for WGLC in 2010, comments are welcome. Yiqun: I'm really hoping Dimitri is here. . Thomas: Dimitri in Stockholm described an issue related to loops. Is it addressed? Yiqun: Dimitri agreed to contribute text, but didn't. I think this may be a configuration error, it is not clear whether a protocol fix is required. I'm open to suggestions. Thomas: If the same (S,G) comes from two neighbors, ... it is possible for loops to exist on the SPF path. The question is whether a configuration error or something transient. Perhaps it would be best not to propagate joins Yiqun: If inconsistent joins/MT-IDs are received, they should be dropped. Other cases we want to handle, as they are important for incremental deployment. Thomas: You still have the possibility of loops, right? Yiqun: Yes, misconfiguration, migration, or IGP loops. Thomas: I don't get it, if you receive messages from two neighbors, one with an without the MT-ID, which do you accept? Yiqun: There is inconsistency. The possible causes are configuration, the other is migration path. You can change [configuration] of the MT-IDs [such that it works]. I don't see the case other than migration such that you have inconsistent routes. Thomas: How do you change a mapping on all the PEs at the same time? Yiqun: You cannot. Thomas: So some routers will have (S,G) in topology X and others will have it in Y. ... An upstream router might see (S,G) in topologies X and Y. Yiqun: You have a control plane loop, but not a dataplane loop. Thomas: If it goes multiple hops, it might be a loop. Yiwun: It's a control plane loop, where can you inject data into it? Thomas: It's still a loop. It seems as though it would be better if in an inconsistent case, nothing is propagated. Mike: It seems like you guys should go and discuss this. draft-lwei-pim-tmfrr-00 Yiqun 10 ======================= Yiqun: This is a new submission that allows protection tunnels to be built that protect native IP multicast and GRE mVPN traffic against both link and node failures. PIM options are introduced to support this. Multiple tunneling technologies are supported. MoFRR is also supported, in the sense that traffic can be sent both natively and into the protection tunnel whilst it is set up. Both link and node protection are supported. Yiqun: The point of adding protection tunnels is to get around the RPF check in the downstream router. The target is <100ms, so we can't wait for the downstream router's RPF interface to converge. The merge point assigns a label X from its own label space. The tunneling technology can be anything, it can be a GRE tunnel. As long as the inner label is X, the packet is accepted by the MP router. Yiqun: Changes to the PIM protocol are a Hello option and a join attribute. There's a short (L=0) TMFRR option from the upstream router, and a long (L=1) option including the router ID of the protected router and the inner label assigned by the downstream router. Yiqun: We'd like comments from the WG on whether all the minimum function is included. draft-xu-pim-drpriority-auto-adjustment-01 Xiaohu 10 ========================================== Xiaohu: This is about how to achieve RP priority adjustment. A use case is where two DRs are deployed for redundancy. one DR's upstream link fails, DR failover does not occur automatically and the current PIM-SM spec does not mention this case. Xiaohu presented several solutions and their drawbacks. Xiaohu: This proposal is to allow a router to cease its DR role by reducing its DR priority in cases where its upstream link has failed. When the upstream link recovers, the DR priority can return to its configured value. Xiaohu: There has been discussion on the mailing list, more discussion is encouraged. Yiqun: A comment about changing back and forth on the RP priority. You have to go back, otherwise if failures keep happening, everyone ends up at priority zero. So we need to accept the disruption to the traffic when the link comes back up. This should be addressed. Yiqun: Isn't this draft an implementation issue, is it a BCP? Xiaohu: It's already an informational draft. It doesn't require changes to the protocol. Thomas: In IGMP, the role of propagating a join to the source is defined by who is the IGMP querier, not who is the DR? The DR is about who encapsulates registers? Stig: Who is the IGMP querier is irrelevant to who sends the join upstream. Yiqun: Both routers need to keep IGMP states. Stig: The IGMP querier can be separate from the router sends the join upstream. Mike: Should the working group adopt this? Mike's count: 4 hands. Mike: Who thinks we should not adopt this? Mike's count: 1 hand. Mike: We'll take it to the list. Xiaohu: Thank-you. draft-wijnands-pim-neighbor-reduction-00 Ice 10 ======================================== Ice: PIM creates a neighbor relationship by default. So on a LAN you'll see as many PIM neighbots as there are PIM routers. A transit LAN has no directly connected sources or receivers (this is typical for a MI-PMSI). There's little reason to have neighbor relationship with all PIM routers on the LAN. Ice: It is proposed to limit the number of PIM neighbors. Hellos are not sent by default, but are only set up as a special relationship with a target upstream router. Typically in L3VPN, all the sources are behind a few sites, so we tend to get the benefit. Ice: Are Hellos necessary at all? Yes, it is useful for per-neighbor options such as GenIDs. Other neighbor options are not learned, for example Join suppression and prune override can't be done if the J/P message cannot be parsed. So there is a fallback option to send a Hello on failure to parse a Join/Prune that it is interested in. Ice: This requires RFC 4601 rules to be relaxed; we must accept PIM joins from neighbors with which there is no Hello adjacnecy. This is the behaviour of some PIM implementations that are out there today. Ice: This improves scalability, and addresses some concerns from the L3VPN context. Albert (Ericsson): It seems a key part of this draft is to combine the PIM join with the Hello message. Would it be sufficient to send a Hello whenever you send a join? Ice: Yes, you can do that too. Albert (Ericsson): That would be less change to the protocol? Ice: That's true. Thomas: In PIM there is an option which is the 'LAN delay' that interacts with this and needs to be addressed in some way. Ice: Yes. Thomas: My underlying concern is that there are options that in future we might like to put in Hellos, that might work with this I-D or not. We should highlight that it might prevent future extensions of PIM or Hellos? I am not comfortable with this. Ice: There are ways to deal with this, if we receive an option we do not support, we can always fall back to Hellos to make sure an option is not used. Yiqun: The new option would need to be configured, so we can also configure to send Hellos. Ice: Same for LAN prune delay, it's not on by default. Ice: We can refine it. Thomas: You certainly need to talk about it in the draft. Mike: Should the WG take on this work? Mike's count: 3 Mike: Those who think differntly? Mike's count: 0 Mike: We'll take it to the list. Let's get to the social. Meeting closed 18:14.