PIM IETF 73 November 18, 2008 Mike : We have remote participants and also a remote presentation. We have Andy on the line. We will have presentations on 2 existing drafts and two new drafts from Yiqun and Thomas. We have a couple of drafts that have become RFC's since Dublin - the vector [?] draft and the Port draft and we have added the group-rp- mapping draft. Stig : We have the pop count and rp-mapping drafts. Bill Atwood : Link Local Security There have been a few minor changes. GSAKMP is mentioned as a possibility, and the section on rekeying is copied from 4552. What I have been trying to do the last few months is to get help on the "environment" problem. However, I have realized that I can write this draft assuming that someone else will put the right keys into the right place. So, we assume that there is a mechanism to give each router a unique identity, within an administrative region. We assume a group controller and key server exists and will assign the encryption keys and SAIs so that do not conflict. So, that GC can answer the question, is this router legitimate. I considered two "end" cases - one key and SA per router, or one key and SA per administrative region. RFC4601 mandates authentication using AH. This draft draws heavily from RFC 4552. We specify mandatory authentication and optional confidentiality. I am just going to walk through the draft. Two routers are acting as hosts. We need a transport mode. They must support authentication and optional confidentiality. There are requires on IPSEC, which needs multiple SPDs. This is copied straight out of RFC4552. The Key Server model may not really be required for PIM, but if you lose your path to your key server, you can get it locally. There are two models for the number of security associations - one SA for each neighbor plus one for outgoing, or one SA or everyone, and one for outgoing. The multicast lookup needs the sender IP address, which may not be unique. interface ID SPI The security considerations point to RFCs 4593 5294 and 4601 My plan s to tidy up a few issues, listen to feedback and ask for WGLC. Mike : Can this use msec ? Bill : I have started a process of communication, What we are looking at is more likely to be within an AS. Hitoshi Asaeda : I am of the opinion that this key association should be published in Msec. Bill : They said, this is our problem but we are not going to deal whit it right now. Find me the people who can write these specifications and I will write them. They said that this work is important but we don't see a need for it right now. Stig : We can do a last call from here and get feedback, but we need feedback from Some people do WGLC in multiple groups. Gorry : You can also ask for an early Sector review. Mike : Update the draft ad let us know when it is done, Andy Kessler (remotely) : Grouped RP mapping This draft has been presented 3 times and was adopted last time. The purpose is to have a standardized and deterministic method to pick RPs from a set of RP candidates. This method could also be used by a network monitoring standard to see what RPs were selected. What's new : The hash function has been removed based on list discussion. There is a new section for clarification of MIB objects. The draft now deprecates the algorithm presented in RFC 4601 & 5060. We want to have one stop shopping for all multicast group ranges. SSM and DM would have entries with address types of unknown and a PIM mode of DM or SSM. Proposed algorithm preference : embedded RP static with 'override dynamic' flag longest match PIM-Bidir over PIM-SM origin preference highest IP address. I would like to send this to WGLC. Lenny G. : My comments on the list were more about deprecating all BSR, not just the hash. Mike : Aside from the comments about IPv6, is there any opposition to sending this WGLC. [no hands] We will take this to the list. Stig : Unless this interoperates with existing routers there needs to be a knob to select it. Lenny : This seems somewhat analogous to BGP, which is also left up to the implementations. How does BGP handle this. Andy : I have references which talk about embedded RP, and the BiDir and sparse mode are already defined. With BGP a lot of it developed over time. Here there are implementations but they are not standardized and would not interoperate. This needs to be documented somewhere. Maria : I cannot say yet but we will shortly know whether or not we will have problems. Andy : I have seen this in the field. Yiqun Cai : PIM MT-ID Join Attribute The objective is to build non-overlapping multicast forwarding trees. Now, there is an issue if a single network failure multiple trees can be broken. How do we fix this ? We set up multiple topologies for each RPF. We chose a topology and send a MT attribute. Attribute definition - key design decisions - no PIM Hello options - for joins and asserts only This is the minimum required for SSM. MT-ID zero is not encoded and will be ignored. Next is the forward bit. Should it be 1 or not ? If the router cannot recognize this attribute, the router doesn't know how to forward it. Next is how to avoid conflict. An upstream router will receive multiple joins. If it received multiple conflicting MT-iD, it uses the lowest IP address. If a downstream router sees a join, does it follow RFC 4601. If an assert winner uses a different MT-ID, but the MT-ID is not encoded in Joins. The goal is that conflict does not happen. We would like to get some comments ... ? : Questions on the draft - What about IS-IS Yiqun : There is no conflict with any routing protocol. Stig : Can we see how many people are in favor of adopting this document. 7 people in favor, none against. Thomas Morin : PIM Fast HELO exchange. A suggested modification. Current PIM-SM have a high random delay between neighbors that have exchanged Hellos - 5 to 10 seconds. This is required to process joins. It has been shown that Hellos can be ignored, but this can cause multicast block-holes. This was discussed in past meetings. Why is there a delay ? To avoid storms of hellos on a LAN. On point to point links, you can set the triggered hello delay to zero. On multi-access links or LANs, you could send unicast Hellos. The other router could respond instantly, in unicast. When messages need to be sent to a neighbor - Send Hello at once - set a 100 msec timer - messages are queued and sent on the link when - a hello is received or - the timer is expired - if the timer expired, then everything repeats. There are black holing issues with misconfiguration. The other case is where unicast/RPF converges faster. I would like to thank Bill Fenner Mark Handley and Dino Farinacci. Yiqun : I am not sure we need this. There are 3 cases - a link becomes available - a route with a better metric becomes available - a router with the same metric to the source, but a better tie-breaker in an ECMP scenario comes up. The first case is not a problem. 4601 is complicated and has a bunch of knobs. Thomas : The only think new here is configurations. Only on LANs do we need to have knobs. The other solution does not require a knob. Yiqun : What is the most cost-effective way to solve this ? Rajiv : Slide 4, please How do you the neighbor A to send the Hello message. Thomas : I am talking about the address inside the PIM message that specifies which router this is addressed to. Yiqun : If you want to solve the problem in the general case it requires cooperation of all routers. If you combine both solutions (Thomas and Cai) Steve Casner : I see a parallel with this and RTP, where we made a change for that unicast connections so that we could send immediate reports for the unicast connection. Eric Rosen : Don't you want a make before break for point to point. For the multicast case, I don't like parameters to set to avoid storms. This sounds like a dangerous knob. Thomas : I am not so sure how much we should worry about Hello storms. Dino : I am worried that this is over-engineered. If you really care about it, just send a join, don't send the Hello. Tony Li : The control plane for routers today is not all that wonderful. We basically use laptops. I would be very careful about storms. Thomas : If it is not possible, we don't do it and could just to it on point to point links. Tony Li : I don't see an issue with point to point links. Asking the average network admin to figure out what the tunable parameter to set the Triggered_Hello_Delay is asking a lot. The track record here is really really poor. Everything should be as automatic as possible. Thomas : Point taken. That's why Bill Fenner suggested unicasts. Rajiv : I wonder if we are avoiding multicast storms for unicast storms. Thomas : You don't have the implosion effects with unicast. Not everyone hears and responds. Rajiv : You might send 5 unicast hellos where you only needed 1 multicast hello. Sending fast hellos helps. But, sending joins without sending hellos, I don't know what the router is capable of. Eric Rosen : If multicast is not available and you send a join it just dies. Dino : You cannot beat not sending hellos. If PIM is not enabled, then the network admin is not capable. We should have to worry about those. Thomas : The information that you put in hellos is not that important. Eric Rosen : If you send send a join you probably have 99% capability, cover 99% of the cases. Rajiv : I would be cautious to not rely on hellos. Thomas : I think that this solution preserves everything that we have Stig : We are done - thank you all.