PIMWG July 29, 2008 Mike: agenda / draft status See Slides Dino: pim port See Slides Fenner: What about keepalives/hellos on the port connection Yakov: 1. l3vpn should do the segmented lan definition 2. on segmented lan, part of the document says to track neighbors, another part says just track oiflist. Dino: implementation detail, in this case oif = neighbor Yakov: please clear it up. 3. Section 7, *,G and S,G: rtr forwards when it gets join on interface - should be more like "on the tcp connection from a neighbor on that interface". Marshall: How are we going to move segmented lan part to l3vpn? Yakov: Move it to Eric's document. Toerless: Maybe use TCP keepalive instead of protocol message? Yakov: TCP just tells you TCP is OK Toerless: Is that enough? Do we want another mechanism? Yakov: Ask yourself what info you want to get, that will tell you what mechanisms you can use Dmitri: multicast fast reroute framework See Slides Toerless: a lot of this solution space applies equally to mldp and PIM so can you generalize? bmwg would be a good place to talk about this as well. Dmitri: on mboned: is there an interest from the ops community? Toerless: Reliability of multicast is the biggest that I've seen as a vendor Dmitri: on bmwg: it's metrics, you have something based on performance we can use. Toerless: we can at least talk about what things to measure, like number of trees, etc. Ice: I would keep this seperate from MLDP, it may be very different because you have very different underlying state. Dmitri: That's why I wanted to keep them seperate, at some level they'll need to be different Rajiv Asati: bmwg does have an rfc on multicast convergence bkhabs: What about IGMP and MLD? THese signalling mechanisms are also all soft state. Dmitri: What's the boundary? Toerless: So many times the problem is in the edge network so it is worth considering Toerless: What problem are you trying to solve? "I'm a user with multicast working and it stopped"? Dmitri: wanted to just scope it to PIM to solve one problem at a time Rajiv: By scoping it to the PIM domain - are you just looking at control plane or also data plane? Dmitri: Control plane, since we can't detect the data flow at the leaves, there's been some work on data detection in bfd? Mike: Did rtgwg accept the document? Dmitri: There was lots of support Mike: So no action for us Dmitri: Want to make sure to coordinate with PIM WG Rajiv: draft-asati-pim-multicast-routing-blackhole-avoid See slides Dino: Z found this in testing: neighbor comes up, sends hello, unicast hello reply results in arp request/reply which is further delay Thomas Morin: You have a local solution to a problem of global consistency, and doesn't work in the general case. Our problem when you have multiple hops between a router who has the link failure and the rib change, .. Rajiv: Right, remote link failure isn't handled. Thomas: but all local failures are remote for someone else Rajiv: We're trying to characterize it Thomas: don't see the point Rajiv: Maybe not for failure but for restoral Fenner: this is good for where two paths work Fenner: another way to think about it is that the new thing doesn't show up in the MRIB until the hello negotiation is complete. Dino: Just send the join. Forget about the hello negotiation. Dmitri: not sure it paves the way for make-before-break criteria are very complex Rajiv: Chain the sequence Dmitri: If I follow the full sequence then you may still not have the traffic if you're in the middle depending on what event -- difficult decision process Rajiv: not sure I follow Dmitri: objective is to avoid disrupting traffic. Dmitri: point solution to a problem that exists Maria: advantage is the security, especially in vpn context - messages when pim session not established are problematic Toerless: my preference is the most complex thing, which is to have a topology in the IGP that reflects PIM neighbor relationships in its link state Thomas: just improving adjacency setup time will probably solve most of the issues. If adjacency can setup in 10ms then you'll probably cover most cases. Rajiv: paraphrase: aggressive hello times can solve this problem, but that goes against what T was saying Thomas: If you are in a situation where you need multi-topology then you can do it but this low-hanging fruit can ... Dmitri: BIDIR: offer/exchange takes 1.3 seconds - can and should optimize this outon P2P links ?: Can we leverage any mechanism used from switchover from RPT to SPT until Fenner: that's make-before-break Rajiv: The main point is the sending the join Dino: another problem in ring topologies where you're recieving joins on your RPF interface because the ring turned around Ice: This solves a limited set of problems - wouldn't it be better to spend more time with make-before-break and solve all the problems? Rajiv: make-before-break is an optional extension to this Mike: It's early to ask for wg adoption of this draft. Mike: Is this an important area? general sense of yes. Zero "no's". Mike: draft-joshi-pim-group-rp-mapping See slides Also considering removing the hash mechanism altogether Z said on the list he isn't seeing determinism from hash. Dino: Static with 'override-dynamic' should instead be done with /32 or /128 Dino: If we're going to change it all around, we should change it right. Stig: if you want to use a combination of static and dynamic, you probably really want input filters on the dynamic protocol. Toerless: embedded RP being at the top is the same as static-override being at the top Stig: are people using the hash? should we make it better? Toerless: as long as the alternative RPs are still from the same protocol picking one makes sense fenner: We didn't know what we were doing when we wrote it, we thought the hash was good though so I'm surprised to hear Mike: Z said it didn't distribute very well MM: WG draft? handful of yes, no no. Dino: lisp multicast See slides Starts with a lisp tutorial Toerless: on slide 10: there is no IETF standards-track inter-domain solution. MSDP is dead Dino: Support SSM only and ASM-with-embedded-RP only? Yakov: on slide 14: you are delivering to more sites than have recievers. In the PIM J/P that are green (n the EID domain) you have no PIM join suppression, and the edge of the source EID domain has to do explicit tracking. Unless you have port you have periodic message hell. Toerless: 1:1 mapping of trees from edge to core means that you're not saving. Dino: We're saving state. Dino: Slide 15: Now we can solve the problem that Yakov brought up: you can have R21/R22 hash to join S1 instead of S2 and create another tree.