Mike McBride: draft-ietf-pim-rpf-vector-05. Minimal edits made to it. Two previous wglc's. We'll issue one more. We need to add IPR disclosure info. Yakov/Dino submitted a patent for this back in 2000. Bill Fenner: IPR stuff doesn't go into the draft anymore. RFC 3668 got rid of that requirement. Make a general statement and make sure ipr statement is filed on the IPR website. Mike: IPR statement has been filed, so its ready for wglc. Stig Venaas: We need people to respond to the wglc for this. Its hard to move the doc forward otherwise. Bill Atwood: draft-ietf-pim-sm-linklocal-02 draft is really a keepalive. Minor changes in title and housekeeping. Enlarged section on what the communications patterns are. Most of the activity has occurred in the background. Discussions on common features of pim-sm work and ospf work. And possibility that some of the needs for secure communications of rsvp can make use of these ideas. He came up with idea to extend GDOI for our use. Also came up with an idea, with a student, on controlling the adjacency. Communication is effectively in little groups. They share one address. To manage this you can have single key for entire admin region or one key per speaking router. That decision will be element of policy for routers in domain. The group controller and key server need to distribute the shared key to every router in the admin domain. In second case each speaking router needs to distribute its key to all of its adjacent routers but we want central control over this. The whole idea is to automate this. Separate the group controller from the key servers. GDOI doesn't disallow this but also doesn't have provision in it for the protocol that would exist between group controller and key server. To get reliability, only the group controller needs to be replicated. GDOI is formulated as a centralized entity so an extension needs to be specified to specify the protocol between the centralized group controller and the 100s or 1000s of individual key servers, one per router. If we feel that this is the right approach, we need to talk to the msec guys. OSPF has the same link local problem but it can't assume unicast connectivity with the central key server. So they really need the key server to maintain info across restarts. RSVP does next hop which is almost link local. Some of the ideas here may map to their requirements. There are probably other protocols that could make use of this nearest neighbor communication. One suggestion is to extract this common problem and describe in a new draft. Not sure where that work would live. Brian thought it was a reasonable approach. The first issue is talking securely to the neighbor router. The second issue is being permitted to talk to the neighbor router. Is he in fact adjacent to me? Which routers are entitled to receiving keys? To ensure rogue routers don't suddenly appear as neighbors, the group controller can be mandated to maintain an adjacency matrix and only authorize true neighbors. In v6 you could use neighbor discovery. In general the multicast map will be the same as the unicast map but not always. For v4 we'll have to use central group controller or create something. Plan: complete the exploration of adjacency control issues with others to define extensions to GDOI and create a draft. Create a draft for sub problem of key managenment. Then rewrite the linklocal draft to include the proposed GDOI extensions. Toerless Eckert: There is nothing in draft about these proposed extensions. Why can't mcast simply inherent the security associations from ospf or other igp? Where are the requirements coming from? Can see the need to provide a signature for what I'm sending to identify each other. But not seeing the justification to encrypt everything. Is there info that needs to be protected in the pim messages? Atwood: The ospf linkage has been going on off line, probably doesn't belong in the draft. The common parts of the work will end up in the new draft. Both drafts will reference the common work. Its only ospfv3 where the work is going on. This has to work in both v4 and v6 communities. If we feel we need a requirement draft first he's prepared to do that. Stig: Don't you need all of the routers on the link to understand each others messages? If you encrypt messages you might have a problem. One router, when speaking onto a link, needs to be understood by all of its neighbors. Why do you want to encrypt this? Atwood: Do we need the confidentiality? He didn't hear anything from the group either way. To protect himself he put it in. The doc says IF you do confidentiality you should do it this way. It doesn't say you must do confidentiality. We need communication with msec to communicate interest in shared work in linklocal security and need extensions to achive that. Stig: draft-ietf-pim-bsr-mib-04 Draft submitted to IESG. Fenner reviewed. Minor changes made, just updating. Look at the diff and review the changes. Moving forward to get this published. if you have a problem with any of the changes let us know. Archana: draft-kulkarni-pim-gr-enhancement-00.txt draft-archana-pimwg-pim-ping-00 pim-gr (graceful restart): To support pim gr, pim uses hello message genid field. When hello message, received with new genid, peer router sends the bsm message with no forward bit set. Rebooted router doesn't do any rfc check for this message and stores group/rp mappping from bsm message. sm/bidir require *g, s,g joins to refresh states on rebooted router. Some issues with existing pim gr support. This draft tries to address those issues. BSR: elected bsr reelection takes 5-23 seconds. bs_override interval. Starts sending empty bsm message once elected as elected bsr. Now candidate rp router doesn't know ebsr has rebooted and it started advertisement message only after crp adv timer expired. so group to rp mapping on a rebooted ebsr will be refreshed only during 0-60 sec interval. During that interval you see a lot of state changes. To solve this: when rebooted router receives the bsm message with peer with routers own address as bsr address, it can directly transition to ebsr state. After bsr election, it first sends bsm message. This bsm message can help the restart bit set. Once the crp router receives bsm message with restart bit set it knows the ebsr router has rebooted and it starts sending crp adv message. The second bsm message will only be generated after 10 seconds. Allows ebsr to learn all the group to rp mapping from the crp routers. This is the new bsm message format. Same but using one r bit from the reserve field to indicate that the bsr router has rebooted. The c bit in the group to rp mapping is used for the crp routers. Also new candidate rp adv message format, added one bit from the reserve field to indicate the crp has rebooted. Issue with existing pim bidir gr support: when receive hello message with new genid from upstream router. Downstream immediately triggers join message. On upstream rp info may not be present or df election may not have happeneed yet. So the join message sent by the downstream will be ignored by the rebooted router. solution: do not trigger join when receive hello message with new genid. approach two: have genid field in df winner message same as hello. When the genid field has changed message changes in df winner message, it knows the df winner has lost state and triggered join can be sent. Solution for pim sm gr: assert loser shouldn't move to no info state when recieves hello with new genid from assert winner. pim ping draft: This feature is extension to existing PIM protocol to check the convexity in PIM-Domain and to verify the RP consistency in PIM domain. This feature can be extended to find the number of receivers for source and to find minimun PMTU for receiver. It has two message types, Request and Response and used PIM Type 14. Dino Farinacci: About 3 years ago I proposed a pim hop count draft and it was rejected by the pimwg. It adds a new source in the pim join message that could periodically convey minimum bandwidth, max bandwith, mtu, etc. But comments were said that statistics and acounting shouldn't be in the protocol. Mike: Your draft was likely rejected at the time because we were being careful not to do anything to derail the pim-sm drafts completion and it wasn't part of our charter to add extensions to pim. We've since rechartered. ?: The new mtrace draft supports ipv6 and we changed packet format to udp and not icmp or igmp. Archana: its not only tracing the mcast path, it also does an rp consistency check. Fenner: the pim version of it can have more pim specific features. One of the things we talked about for mtrace is to add a tlv extension mechanism so hops can insert relevant info without having to say where everything is that needs to be inserted. Its seems like we can combined these efforts. Its probably true that pim is the only mcast routing protocol that people run. If instead we used traceroute as the basis with these tlv's we could probably get the same functionality. I like the functionality you are talking about. Stig: have also had discussions about using mtrace using new tlv's. Fenner: you can find the number of lans that have joined, not the number of receivers. Dinos draft comes in to track this. The receiver tracking may be something you want to do all of the time to allow incrementally updating instead of asking the the network to tally the number of receivers. Dinos draft is proably a good way to do it if that?s what we want to do. Which pieces of this makes since to do? I've heard from the SPs that the content providers want to be able to count receivers. Dino: what about in a swiched network? Fenner: You count the number of dsl routers that have subscribed, you don't care about the actual number of receivers at a home. Its an approximation. Mike: useful draft to address in pimwg? Fenner: it should happen in mboned with mtrace. Stig: Is there an interest in this type of statistic info/debugging within this wg? (6 or so hands) Mike: draft-mmcbride-pim-refresh-problem-statement-01 problem statement refresh draft completed. Please review. Welcome any and all comments. The problem listed is in reference to mvpn, pim from pe to pe. A few possible solution listed also. Mike: draft-wen-pim-improved-register-00 Alcatel gentlemen in China submitted this draft but not able to attend this ietf and requested we present it for them. It discusses a way to improve the register process in sm. The review the expensiveness of encapsulation from dr to rp. And how to not rely on the data plane to set up the control plane. They propose not sending data from source until state is created. Extensions to igmp or new protocol so source can advertise that its interested in sending data. Having sender send a sender request to dr, no data. The dr sends a register request to rp. rp has the option to send joins towards source. The dr would then send a dr ack or nack and the dr would also send an spt ok towards the rp. The data would then flow. Trying to simplify the process, take burden off the routers. Fenner: Trying to get rid of the requirement to look in the data plane to set the spt bit? Mike: right Fenner: This is one of the things that has been one of the biggest complaints of pim. This is a change to the existing model that the senders don't have to do anything except send. Perhaps that needs to change. To allow senders to send without doing anything, this is the original model. Atwood: This would help secure multicast where you need to authenticate the receivers and senders. It would be a useful trigger. Mike: yes, the draft specifies the dr sending a dr nack if they were not permitted. Toerless: this is a dependency of a rewrite of rfc 1112 as the service model that would be required. We did ssm in 2000 and that was a new model. This is a good idea, same problems we've had for years. Stig: Worried about changing the service model. But would be cool to do bidir with embedded rp if you had this. Beau Williamson: This is something that has been missing. But not holding breath, we could start considering. While we are doing this, we should introduce a request to send and clear to send. Mike: the authors do have a sender alive and sender leave proposal. Dino: Microsoft, in the day when they were intested in mcast, wanted a request to send. They wanted router vendors to take the rsvp path message and make that look like a request to send message. They backed off from that but that could be a solution. Periodic, not end to end acks. When path messages received from DR it could do all the back end stuff being done here. Stig: Also have had the msnip stuff which could be merged with this. Beau: The title is misleading, should be sender signalling. Could also have the sender advertise how fast he intends to go. Andy Kessler: This is a piece of the bigger picture of controlling sources completely. Have to authenticate as part of aaa. Authenticated at a particular rate. Its part of the bigger scheme, we should authenticate sources, profile what they can send to and rate limit. Dino: The disadvantage of changing the service model is what would a brokerage firm say about its send latency when there is a short rtt and long rtt and queuing delays from dr to rp. Send latency would be affected by this. Mike: we will take these comments to the authors and let them take it to the list.