pim wg meeting Thursday 1510-1610 PIM chairs: Mike McBride Stig Venaas Approx 30 people present. Mike couldn't make it this time, so Stig chaired. agenda bashing, status of wg drafts etc Stig 1518 ------------------------------------------------ Stig asked for issues with the agenda - no reply. Stig presented status of WG drafts. draft-ietf-pim-sm-linklocal Stig 1520 ------------------------------------------------ Stig presented this for Bill, who is not present. Some AD comments have been received, authors are preparing a new version. The authors have a XORP implementation which is done purely by IPsec configuration, and plan to do the same with Cisco and do interworking tests. Farrel asked whether there have been comments on whether this draft should move to standards track, or to stay experimental. Stig asked for comments from the room, there were none. Stig will ask again on the list. draft-ietf-pim-group-rp-mapping-01 David 1530 ------------------------------------------------ David presented this. There was a recent decision on BSR hashing. It was proposed to remove this, but it turns out some people have implemented it and do like it, so this will be changed. Stig asked how many had read the drafts, about 5 raised their hands. Stig asked how many think the document is about ready for wglc, no one raised their hands. Stig asked how many thought it was not ready, no one raised their hands. draft-ietf-pim-pop-count-01 Stig 1535 ------------------------------------------------ Stig presented this for the authors. The slides showed the changes in the -01 version, the formats and assigned option value. Dimitri asked that we check that this draft doesn't change the message processing or triggering of messages that flow. Stig replied that this just amends content of messages that would flow anyway, so this should maybe be clarified. Stig then asked how this interacts with reliable PIM joins, where we don't send periodic joins. Dino replied that this may impact the statistics and make them unreliable, as messages must not be triggered. With implementation experience we may get a better idea of the overhead involved with pushing statistics. Dino noted that are two designs maturing at the same time, and they interact, so the interactions will need to be worked out as they mature. Stig also noted that there may be a problem with PIM messages getting too large. draft-ietf-pim-port-01 Stig 1550 ------------------------------------------------ Stig presented. This is about using reliable transport (TCP) so updates are only required when there is a change. The main change in -01 is that there is no switching between PORT J/P and datagrams, this is now configured. There are some other changes as well, Stig went through the detailed slides describing them. Yakov Rechter says he has quite a few comments on this draft. First, all VPN-related text is out of scope for this working group, and it should be put in another draft for discussion in L3VPN WG. Dino Farinacci definitely agrees, but can't speak for the other authors, he expects they might disagree. Stig agrees as well. Yakov's point number 2 is confusion about segmented MDT and PMSI, which is introduced without any definition or explanation of why it is useful, and Yakov assures us that these terms are not defined in any L3VPN draft. Dino says this is from the other authors, was surprised that there is no reference to the terminology from the VPN spec. Yakov requests that such references be added. Yakov is also confused by outgoing interface tracking, and quoted from previous minutes and section 6 of the draft. Is OIF equal to neighbor, yes or no? Dino says yes for a point-to-point link, but not for multi-access LANs. Yakov asked what about NBMA? Dino replied that the intent was to make it look like a collection of point to point links, and this is a way an implementation could do it. Yakov asked for this to be documented, especially that tracking is required per neighbor, not merely per outgoiong interface. Why not just specify explicit tracking per neighbor? Dino doesn't want to require per neighbor tracking on a large multi-access network. Yakov says then it must be explained how it is decided how to forward. Dino stated that there is a simple explanation, even in the MDT case in which Yakov is interested. Yakov wants this spelled out explicitly. Stig said that text update would be made. Dino asked that Yakov help form the text. Yakov assented. thoughts on draft-ietf-pim-mtid Dimitri 1600 ------------------------------------------------ Dimitri said that it was difficult to know whether the concerns that have been expressed should be incorporated into the document. As this is a considerable amount of work, the authors want discussion before undertaking this work. The point of concern is to conditions for transient looping. Dimitri explained this from the slides. The next steps are to document loop conditions and mitigation means without additional protocol procedures. The second step might be a new ID. Thomas Morin asked is this specific to MT ID in PIM joins, or might this arise from something else in PIM joins that affect how RPT is made? Dimitri agreed that the problem is generic, and that the draft does not specify how it is used, the MT ID is not included as part of the multicast packet. Dimitri illustrated using primary/backup trees. Thomas said that is a different question. If we don't have the corresponding information in the packet on which the RPF check is made, then an issue arises when things can affect the RPT. Dimitri agreed. Thomas said that text should be added to say when it was possible to use this sort of mechanism, either this draft or RPF vector. Dimitri says other authors are okay to incorporate these next steps. Stig directed Dimitri to talk to the other authors, and consider whether it is worth a separate document because of the wider concernts. Dimitri says this depends on the applicability of the MT ID, the urgency to do this depends on the application that is forseen. Dimitri's personal opinion is that the document as it stands is about how to encode but not how to parse. The draft should also document the procedures for a receiver. Stig agreed this is worth documenting, please talk to the authors. draft-wijnands-mpls-mldp-in-band-signaling-00 Uwe 1610 ------------------------------------------------ Uwe Joorde from Deutsche Telecom, presented on behalf of Ice. This is a way to do multicast traffic over an MPLS core. Uwe explained the mechanism from slides. Stig interrupted to make it clear that this is being presented here just for review, and would not be adopted by this WG. Marshall Eubanks asked which WG it would be in. Discussion from the floor agreed that it was an individual submission intended for the MPLS WG. Uwe continued and described the formats used, scalability and application. Uwe noted that for him this is an IPTV application. Uwe asked for comments on the draft, there were none. Stig declared the meeting closed at 1559.