Last Modified: 2005-02-26
| Done | Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items. | |
| Done | Update the PIM-DM version 2 Internet-draft. Go to WG last call. Submision to IESG for considerations as proposed standard. | |
| Done | Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC | |
| Done | Submit PIM-SM Applicability Statements | |
| Aug 04 | Submit PIMv2 MIB to IESG for consideration as proposed standard. | |
| Done | Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts. | |
| Done | Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG for consideration as Draft Standards. | |
| Mar 05 | Submit PIMv2 MIB to IESG for consideration as draft standard. |
| RFC | Status | Title |
|---|---|---|
| RFC3973 | E | Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) |
|
Protocol Independent Multicast WG (pim)
Wednesday, March 9 at 1530-1730 =============================== CHAIRS: Mike McBride <mmcbride@cisco.com> Tom Pusateri <pusateri@juniper.net> AGENDA: update on drafts/charter Tom/Mike draft-ietf-pim-sm-bsr-05 James draft-ietf-pim-proxy-00 Arjen draft-ietf-pim-rpf-vector-00 Ice draft-ietf-pim-mib-v2-02 draft-savola-pim-lasthop-threats-01 Pekka pim refresh reduction design team progress Albert/Venu PIM BSR ======== draft-ietf-pim-sm-bsr-05 James Lingard History BSR specified in RFC 2117/RFC 2362 Work for draft since 2001 New author team produced revision 04 last year Major changs support for admin scoped zones generalization to bidir-poim as well as pim-sm other goals backwards compat with rfc2362 remove genuine errors improve clarity and precision of specs non-goals compat with previous revisions of the draft adding extra enhancements and optimizations Major changes in 05 rev Admin Scoping change to handling of ipv6 scopes clarification to descrioption of admin scoping Minor technical fixes fixes to unicast bsm sending/receivpt fix to checking of ip router alert ptioon fix to rand_override algorithm clarification to use of hash mask length lots of editorial changes Remaing work we have made progress were approx 70 items on issues list now about 30 remaining still much to be done finalize iw/ew issues issues with the bootstrap fsm issues with semantic fragmentation various other minor problems further editorial work plan for completion resolve all remaining known isues produce one more draft with all known issues resolved need wg input on certain tech points recommend to wait for this draft before detailed review should be ready by may incorporate wg feedback one or two further drafts wg last call shortly after ietf63 Discussion: Venu: what are the compatibility issues James: None that would break Stig: Scoping is different esp for IPv6 Venu: could these compat issues be sent to the mailing list PIM Proxy ========= draft-ietf-pim-proxy-00 initial draft submited june 2004 presented at San Diego and dc ietf draft spplit into two parts generic encoding fromat use of single rpf vector removed rd+vector and vector stack Tom: 5 bits for tlv does not give enough room. Other usage.. should not use all 5 You have the hello option routers understand source encoding format. In case of vector proxy..upsteam might not understand.. it does not guarantee compatibilty.. Move things that do not belong here to the other draft. Generic encoding .. so proxy does not belong here. Fenner: Is it enought to change proxy to.. Venu: Is it only for proxy source and is it for any type of source encoding.. can this be of any encoding type.. There other thing is .. if you make this generic field.. fenner: one bit indicating Vector proxy... edge routers have bgp router to source bgp next-hop is present in the igp in the core routers edge router add bgp next-hop in the pim jp message core routers rpf using the vector receiving edge router removes vector Discussion pts name proxy will be changed f-bit good or bad thing to have use of reserved field to indicate the number of tlvs in other words there is no reserved field anymore in the new source encoing iana consideration.. who assigns tlv numbers Tom: new source encoding type.. will it affect pim snooping switches.... Venu: is this used only for rpf attribute..given that it might break pim snooping.. PIM MIB ======= draft-ietf-pim-mib-v2-02 Tom: Past year work has been done. NMS ppl have been using this mib. They have been asked to do IPV6 changes. People doing ipv6 have been asked to do IPv6 mib. overview Define addr family independent tables using inetaddress data-type similar objects for v4 and v6 defined in common tables common updates to both ipv4 and ipv6 mibs conversion of ipmroute-mib fulfills need for a mcast routing table mib for v6 currently dependency against ipmroute-mib not removed represent new protocol features - bidir-pim, new grp-rp mapping, hello options et all fenner: Coupling of mibs was a mistake. Removing dependency makes sense Dave thaler did a draft for ipmroute v6 mib. long expired. no wg. no pursuing for it. can ask dave to resurrect that work. pimnbr entry to have type and address for v4 and v6 represent neadd additional info to the source encoding no room in current source encoding for additional info add new source encoing type add info us put in tlv this is descrived generic protocol features grp to rp mapping extended for static, embedded, autorp new pim hello options addr family independent ip-mroute-mib need to enhance iana ipmrouteproto textual convention split pim sparsemode into pimssm, pim asm and pim bidir add mld add in/out pkt stats plan of action sync up with discussion in the pi-mib list address any other suggestions ordering of mib obj mib compilation issues send mib for review Tom: Coming straight to the wg is disappointing before even going to the list James: No messages on the mailing list? Fenner:There was one in feb.. where is the mib? stig: Draft is available? Fenner: Captured in archives around sept.. Tom: I am happy not if you want to get into the main mailing list. Bharath has not sent his changes. So they might get lost. Tom is going to do the driving. PIM Last Hop Threats ==================== draft-savola-pim-lasthop-threats-01 Background draft-mboned-mroutesec does not talk about last hop threats. There has not been an analysis on last-hop mcast threats. These issues deserved to be spelled out. Vulnerabilitues Nodes may send unauthorized register messages Nodes may become unauthorixed pim nbrs Router may accept pim messages from unknown-nbrs The spec should probably be tightened here. An unauthorized node may be elected as the pim dr. A node may become an unauhorized asserted forwarder Threats attacks Dos on the link Dos on the outside Confidentiality, integrity and authorization violations Mitigation methods Pim passive mode Using ipsec among the valid routers on a link IP filtering of pim messages Main issues are with multiple valid pim routers on a link you will have to use ipsec betwen them to be secure with just one router, filtering pim messages is a good method Now what: What is the contribution of this draft? Explicit threat vulnerablity analysis and speclling out more elabore description compared to the pim spec section 6.1 more extensive discussion of non-ipsec countermeasures Options Make this an info rfc of its own Merge it with pim-sm spec security consideration section. Wait until IESG evaluates the pim spec, ask/see how they react. Make this dormant until the pim-sm spec is revised. Drop the project completly. Bill Fenner: Should not be merged. Spec has been given to iesg. wait and see. Tom/Mike: agreed with point 3. Bill Fenner: Can be made as an informational rfc PIM Refresh Reduction ===================== pim refresh reduction design team progress In the last ietf l3vpn requested PIM WG to come up with pim messaging in the context of scalability. The PIM WG created a design team to address it. Several solutions were discussed. Tom/Mike working with l3vpn wg to get a requirement. Discussed with l3vpn. Such a doc maybe in the works. Regardless of that request it is probably not a bad idea to work on this in this WG. As multicast vpn grows there is a possiblity of scaling issues.. years down the line.. more specific number might be required.. Reduce PIM JP messages. There are no problems currently. But definitely beneficial to reduce the PIM JP messages. Thomas Morin: About requirement docs. There will be in the mcast requirement in l3vpn. The draft on mcast vpn described two options: pim and bgp. One or both not decided. We are not clear if this is needed or not. Tom: independent of the vpn case.. in case of large nbrs.. large numer of sources/joins.. this is required in those cases.. Y Cai: How far do we want to go with existing pim. New version of pim(pimv3) or just this draft?? ??: what is the improvement needed elsewhere? What are the priorities? Venu Hemige: scaling for l3vpn and l2vpn Tom: We should get a picture if other wg's have this issue. ?: We are not making any assertion to fix pim. we are pursuing both options. pim and bgp.. regardless of the outcome.. There is a case scenario.. without improvements.. wrong impression should not be given to l3vpn that this is some kind of a fix. Albert Presentation =================== JP ack scheme Problem and motivation Too much processing overhead related to the periodic refresh several bgp impl can suport over one million routes, but pim impl cannot support even half mvpns and many apps are capable of generating lage stats History: Liming and Albert took this work in 2004 summer. Joined force with Dino and Yiqun Cai in Nov 2004 and focused on ack based approach. Yiqun/Liming mentioned checksum based solution. Suresh's scheme. Highlights of JP ack Introduce JP ack message to achieve reliable JP message delivery. Adding sequence number to PIM JP to achieve in-order delivery. Handle other failures such as losing pim nbr and one way failure. Disable join suppression and enable explicit member tracking. Reliable JP delivery Intrduce reliable JP message that is same as regular JP but added sequence numbers. Intruduce ack message which is same as reliable JP except message type. Use Join-Timer as retranmission timer. Stop the join timer when acked. Holdtime in reliable join set to oxffff Possible to still have low frequence refesh In-order message delivery A tranmit seq number is maintained seperately for each upstream nbr. The transmit seq number is incremented each time a JP message is sent to that nbr. Each upstream keeps track of the max sequence number received from a downstream, only accept higher sequence number than the max. Encode sequence number as options at the beginning of the reliable JP message. Using sequence numbers Each PIM entry on the downstream nbr must keep track of the seq no of the lst outbound pim JP message that contained the pim entry. And entry is considered acked only when the seq number in the ack mathches the seq number in the pim entry. Retransmit method 2 Use separate retransmission q and receive q for each nbr(sliding window or the like). Essentially builds a reliable transmission layer inside pim. Pros: no need to maintain seq# in each pim entry, easier in handling rpf change Cons: more work and more memory in retransmission q and receive q. Prune override no longer works: One solution is to use explicit tracking. Explicit tracking Pros: JP and ack can be sent unicast Don't have to process JP not intended for you Less backward compatible concerns and we have more flxibity and how to encode sequence numbers. Cons: More code changes and more memory consumption:requires one extra bit per group per nbr Recovery from nbr failure?: All pim entries learned from the failed nbr must be removed. The upstream can either immdeiatedly remove the pim entries or start the expiry timer for those entries and let the timeout handle the removal. Recovery from one way failure Two nbrs x and y and if x to y direction is failing, y could timeout and remove all pim entries, learned from x, without x knowing about it. Need a way for y to inform x that it has lost the nbr and request a refresh. one solution from Dino is to let y to send a unicast hello with genid 0 to x. Another: three way hellos Issues with TCP based solution? In mvpn appl, each pim peering between c instance would require a seperate TCP connection. Vpn address family can be introduced to mcast to allow tcp cnnections betwen P-instances to be shared among C-instances but that requires more change in the protocol. Venu's Presentation ==================== Albert has presented beyond what was agreed on the PIM state mailing list. He had given 4 slides but has presented things that I was supposed to present. Any questions? ?? : Message based ACK seems more complex and not sure what it achieves. Bob Kebler: It is more optimal to do ACKs per message - lesser processing. It may not be very intuitive to explain that it is not that complex, but it is. Albert: There are reordering issues with the current approaches. And there is complexity and a lot of memory requirements to keep retransmission state. So why not use TCP? Venu: We cannot use TCP because snooping will not work. And there are no reordering issues with the current approaches. If it is designed right, the complexity and memory requirements for retransmission state is almost the same as what we need with the current PIM. Cisco guy#2: Who said snooping is a requirement? This is news to me. Venu: There are two drafts in the l2vpn WG on vpls-multicast. Both rely on snooping. Cisco guy#2: But that does not mean snooping is a requirement for pim refresh reduction. Venu: Ok, so I guess what is missing is a formal requirement doc from the l2vpn wg, just like one from the l3vpn WG is also missing. Mike McBride: Yes, we have not received any requirements from them. Yiqun Cai: Maybe we need to take a step back and see how far we want to take PIM. If the goal is to take a big step than just refresh reduction, then we really should be thinking of TCP. A few other guys came up and spoke on how we should not be thinking about snooping without any requirements. Tom Pusateri: Even for refresh reduction, it seems to me that the joins will have to be unicast. Then why not simply use TCP. Mike McBride: Running out of time, so ended the meeting. |