PIM WG TUESDAY, March 11, 2008 IETF-71, Philadelphia, USA Agenda Bashing No additional items were suggested for the Agenda. The WG reviewed the document status. draft-farinacci-pim-port-00 Dino Slides sketched the history and why the solution was being designed for PIMv2. This would eliminate the Join-Overide, since even in a multi-access LAN the control plane would be pt-to-pt. Greg: This looks like the same format for JP messages as we used today. We could pack more efficiently. Gorry: What happens if the TCP session resets? When do you set the delete timer? Dino: Sender generates a datagram join, this starts the timer. Dino: Should we make this a WG draft? Stig: This falls within the remit of the Charter, and is the only current proposal. Bill Atwood: Have you looked at NSIS, this is what the new RSVP mode is doing. It looks very similar. Have you looked at security? Dino: Secure-TCP? Toerless: Do we use a static TCP port or a dynamic port? Dino: Could be interesting to see security implications of dynamic ports. It could make it harder to make a snooping switch. Stig: Is there any advantage in sending Hellos over the connection to verify the path? Dino: Not sure, it would probably get through. Bill: What are the real trade offs with hard-state v soft-state. Toerless: I'd like to see this go-ahead. I'd like to add to the problem status that we should consider Congestion Control as a goal. Bill: How do we know if the connection breaks? Do we use BFD? Stig: Fast hellos are not so costly. Should we consider adopting this as a WG draft (14 hands). There were no people wanting to not progress this ? (none). Should we also look for other solutions? (few) Bill: We should not delay this to wait for new solutions to arrive. Dino: Should we do this over some multicast reliable transport? Bill: Doesn't seem to fit the VPN scenario. Gorry: It seems complicated - like a research project - I do not think this will happen soon. draft-farinacci-pim-pop-count-00 Greg Talked about packet counts. Pekka: How do you know if an interface is transit or stub? Dino: Count the reports Lenny: Who do at the network layer? Greg: There is a distribution tree already. I can detailed information on a tree without access to all the routers on the path. Dino: You would have to traverse the tree to find out what is happening otherwise. Lenny: This is troubleshooting, not accounting. Toerless: Looking at what is the top traffic can be interesting in say a multicast TV, but there is also advantage in more dynamic MANET networks. Dino: The spec says don't trigger the information on time. Thomas: Which state would be useful? Have we thought about upper and lower bounds? Dino: It becomes hard when there are many downstream neighbours? Dimitri: Could we separate accounting and messages? To decouple the dynamics of the two types of messages. Thomas: Should we send some statistics less frequently? Pekka: This is interesting from a troubleshooting information. Far away from your home domain, operators may not wish to disclose this. Stig: Did you consider using PIM Join Attributes syntax instead? Dino: It doesn't work through PIM routers today. It would let us introduce things in the future. Can we make this a WG draft? (15 people) How many against? (4 people) We'll take the question of adoption to the list. If this is adopted the draft can evolve. draft-joshi-pim-group-rp-mapping-00 Bharat Joshi Toerless: I sent some comments earlier. I see two questions? Should we allow the MIB to specify what RP is used across different vendors? We should look at the group mode and RP selection - i.e. SSM ranges and any other protocol ranges. We should describe the approaches. How much needs to be standardised? Bharat: If we consider all vendors how does this work? Toerless: Let's look at typical deployment recommendations. The MIB should be able to express more than is mandatory. Stig (no hat): I like the idea of some precedence specification. Pekka: I'm not sure the RP mapping preferences is a widely required feature. The longest prefix match is the most important. I think we could just create a MIB module to publish this information. Toerless: Will the MIB express the variations of each vendor? I think we can figure out the rest once we have done this. There is some interest, but these need more discussion. The authors would like to receive inputs from people via the list. draft-joshi-pim-protocol-state-diag-00 Bharat Joshi Rajiv (?) asked about reliability of Join test messages, Bharat replied that there is no fallback mechanism, so a tool could send it periodically. It's up to the tool. Rajiv asked whether information about the last hop router would be idnetified, Bharat replied that the Join Test is actually a new message type with a slightly different format, needs a new message type. Greg suggested that this is useless if Join Tests are not more reliable than the Joins, otherwise we need a Join Test Test as well. Maria Napierala objected that that this tools should not be available to administrators in customer domains to test connectivity in the provider's network. tracert and ping cause enough trouble already. Pekka thought it would be better if the actual Join codepath could be excercised, rather than using something different. Pekka again suggested that MIB modules are the right way to Dino noted that Cisco PIMv1 had a 'PIM Joiners' message that did a similar sort of thing as a network management tool, telling you how many joiners were present. This allowed routers to see who (downstream) thought they were joined to. Just an undocumented bit of code - might want to incorporate these ideas. Stig thought this was interesting, but perhaps more a topic for mboned? Perhaps should start by considering what diagnostics are required. draft-ietf-pim-sm-linklocal-03 Bill Atwood Bill said this draft hasn't changed very much. New section 10 on IPSec protection barriers, though. There's recent work going on that isn't yet reflected in the draft. Bill will be in the kmart working group talking about the common problem for all routing protocols, and will also be asking the msec WG for GDOI modifications required for the changed protocol. Bill asked for comments or objections, there were none. Router identification problem statement Bill Atwood draft-tsvwg-rsvp-security-groupkeyring was referenced by the foils. Detailed problem statement for keying models for identification of PIM routers. Includes both manual and automatic keying cases. Sue Hares asked a question about whether multiple PIM routers on a LAN are supported, and if so what happens. Bill answered that each group contains a PIM router and all of its single-hop neighbors. Toerless clarified that this is related to msec and kmart, Bill agreed, and will be going to those groups. Note that IPv6 neighbor discovery might give an alternate mechanism. Sue Hares asked whether a 'lighter' protocol like 802.1x with local Radius service was not used. Bill replied that IPsec is mandated by the PIM spec, and in that context he needs to go to IKE. Though Bill thinks 1x is perhaps a good idea. Sue Hares then asked the chairs why iPsec is mandated. Bill repeated that the PIMv2 spec requires AH. Mike took this offline and moved things on. draft-morin-mboned-mcast-blackhole-mitigation-01 Thomas Thomas explained the draft - possible blackhole following a topology change that brings up a new unicast adjacency. The PIM adjacency may take up to 5 seconds to form (wait before sending Hello to new neighbor). Possible options are to ignore Hellos (remove requirement to send/receive a Hello before sending/receiving Joins). Not satisfactory because negotiated options are not known. Pekka noted that this is touched on by the PIM spec. Could reduce triggered_hello_delay, the point of which is to avoid 'hello storms'. This seems not to be required on p2p links, and we could set a lower time (50ms?) on LANs that would reduce the problem. Thomas/Bill discussed the idea of a unicast Hello which could be used to solicit a triggered Hellos with no delay (no chance of a storm). Toerless said the root of the problem is that the RPF path we're using may include hops on which joins cannot be sent. Toerless suggested that the ultimate solution is the use of a non-congruent IGP topology consisting only of links on which joins can be sent. Perhaps anything less is an unsatisfactory workaround. Thomas replied that updating the specs to cover the p2p case might be desirable. Thomas then presented the multi-topology, where links are only considered active by the IGP while a PIM adjacency exists (send and received Hellos). Toerless noted the additional complexity with LANs, where Hellos must be exchanged with all neighbors before advertising the LAN. Thomas agreed that determining 'all' is pretty complex. Thomas proposes that the PIM specs should be updated to reduce adjacency setup time, and in the mean time propose a BCP document recommending criteria to use when an MT IGP is used for PIM routing. Mike: Who would be interested in a draft addressing PIM setup time. (Mike counted 4) will take it to the list. Pekka asked whether Bill had said this was already in the spec? Bill answered that only part of it is, and the piece of the proposal related to Hellos is clearly useful. Pekka thought the BCP is best placed in OPS (mboned) as this is a much more general problem that affects other protocols. Dimitri agreed (not sure). Sue agreed as well, and asked for information related to eBGP, stating that there are dragons hidden under this approach.