RE: [pim] IETF68 pimwg mtg minutes

[Mike McBride <[e-mail]>]

> Where can I find any progress about periodic state refresh reduction on SM
> draft?

We had a pim refresh reduction mailing list which is now discontinued. I 
do have the email archive which I'll post somewhere soon. Basically, we 
came up with three solutions:

1) J/P Ack extension to PIM
   - New JP-Ack with identical JP format
   - New JP-Ack hello option
   - Minimal change to pim
   - Complicated?

2) Hard state (TCP)
   - No need to reinvent message flow control
   - Reliability during congestion
   - No refresh necessary
   - Mesh of TCP connections
   - Significant(?) change to pim

3) Do nothing
   - Perhaps use long holdtimes
   - Monitor to see if this effort is necessary

At the time, we had rough consensus with #1. But we've basically been 
following #3. But enough operators have voiced concern about future 
scalability, particularly in PE-PE context, that we've added it to our new 
charter.

mike

> -----Original Message-----
> From: Mike McBride [mailto:[e-mail]]
> Sent: Friday, April 20, 2007 6:05 AM
> To: [e-mail]
> Subject: [pim] IETF68 pimwg mtg minutes
>
> pimwg meeting minutes
> Prague, Czech Republic
> Tuesday, March 20th, 2007
>
> Created the summarized notes from the pimwg audio archive which can be
> listened to in its entirety at:
> http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/ietf68-ch6-tue-pm
> .mp3
>
> Mike: Welcome, agenda bashing
>
> Bill: AD for few more hours. Both bidir and pim mib approved by iesg in last
>
> few weeks. Getting stuff off books that have been languishing. BSR is almost
>
> complete as well.
>
> Mike: Thanks to Bill for all his hard work as AD
>
> BSR Draft:
>
> Alex: Received few comments from last rev of bsr draft from Eric Gray and
> Sandy
> Murphy. Will talk to Sandy this week, few issues she came up with, will take
>
> to list. Lars Eggert: are you allowed to say document updates 2362? It has
> been obsoleted by new pimsm spec which doesn't contain the bsr. Alex thinks
> its
> correct that we say we obsolete 2362.
>
> Bill: Those relationships don't have the meanings we'd like them to. Since
> its
> obsolete it may be that it just doesn't matter, you should take out obsolete
>
> comments, just pretend this is new.
>
> Alex: Eric Gray had valid issues with bsr state machine and I will update
> draft
> to clarify things a bit. Describe the no info state better.
>
> Alex: Eric has issue that scopes could expire before bootstrap timer expires
>
> unless timers were constrained in certain way. Have a constraint that its
> not
> allowed to happen. State machine is correct. Scopes on timer always has to
> be
> higher than bootstrap timer. Scopes will expire a little bit later than if
> implemented then with default timers specified in current spec.
>
> Alex: There is a timer assoc with group to rp mapping and when that timer
> expires that mapping is deleted. its not explicitely mentioned anywhere. It
> could be added to a section that describes how the rp set is received and
> used
> by a router.
>
> Alex: Would like to published one more revision then get draft approved.
>
> RPF vector and join attribute drafts:
>
> Arjen: join attributes passed last call, one last Stig comment about adding
> IANA registry then off to iesg. rpf vector has a few more improvements and
> corrections then we'll go to last call.
>
> last hop threats draft:
>
> Pekka:recap in hopes to generate feedback. It identifies last hop
> vulnerabilities and attacks that can be done with vulnerabilities. Last hop
> between router and host is the concern. Could send unauthorized register
> message to RPs that may contain spoofed messages and create nasty state.
> Host
> may also become unauthorized neighbor. Routers may accept unauthorized
> messages from neighbors. Unauthorized node could be elected as DR.
> Mitigation
> methods: pim passive mode (able to receive and send multicast but router
> doesn't send hellos on that interface or process pim messages). Possible
> when
> you have a single router on a link. Also could use IPsec on a link. If just
> one router also possible to filter out all pim messages. When multiple valid
>
> pim routers on a link, you'll have to use IPsec.
>
> Not much changed since last rev except minor editorial updates. pim spec has
>
> been published so this can now proceed. pim passive has been implemented in
> Junos. Should we go for wglc or have people review doc.
>
> Derek: could you also have pim filter which filters on sources.
>
> Pekka: yes, but you could also spoof the source. The host could send source
> messages with router. So that might not be good enough.
>
> Derek: we have the capability to filter on source but should also combine
> that
> with lockdown of addresses.
>
> Dino: How about having a switch between host and routers. If a switch is
> connected to a particular host port don't accept pim messages on that port,
> so
> router never sees the pim message.
>
> Pekka: yes, that could also be mentioned in the doc.
>
> Pekka: How to procede with the doc?
>
> Mike: revise the doc based upon these comments then we'll issue wglc.
>
> Mike: authors for linklocal draft not able to attend but they are activity
> working on it and have been seeking and receiving advice from msec.
>
> Mike: rechartering/milestones discussion. sent a proposed new charter, all
> comments have been incorporated in text of new charter and milestones. Will
> email ADS and secretariat in a week if I don't hear anything.
>
> Mike: One milestone worth discussion is reducing the messaging of pim. We
> did
> have a design team to look into ways to reduce pim messaging. at that time
> it
> appeared that a j/p ack proposal was most agreed upon but since then the
> urgency of it has dissipated and it was thought that it was a bit too
> complex.
> There have been other thoughts on how to handle this. We have had plenty of
> requests to come up with some sort of solution from operators and l3vpn.
>
> Maria: Nothing has been completed on this in pimwg?
>
> Mike:  correct
>
> Maria: Something has to be done in this area, particularly in context of
> 2547
> multicast. refresh reduction is critical for scalability purposes. Dont see
> the problem yet for scalability of mvpns but it may show up and need some
> sort
> of solution. Receiver explicit tracking needs to be a part of the solution
> for
> aggregation purposes of trees in the core. It has to scale.
>
> Mike: how does wg want to proceed to solve this?
>
> Dino: Do people think this is important for non mvpn environments
>
> Maria: yes. definitely need in core for vpn context, but also needed towards
>
> the CE. native ip multicast needs it. biggest impact is in the core.
>
> Dino: let me restate: do you think solution is necessary for a non pe box.
>
> Greg: Marias explanation is still mvpn context. PE to CE is still mvpn
> environment. The solution would have to be on both ends of the PE.
>
> Dino: If there is too much traffic on the PE-CE link, there is probably too
> much state on one hop downstream as well. Do your customers have a concern?
>
> Maria: not yey. They do have the choice of bidir to reduce state.
>
> Maria: Only PE, which has many interfaces, is of most importance.
>
> Mike: We have a milestone to get something submitted by end of year. If that
>
> doesn't happen, we'll probably need to create a design team.
>
> Mike: drafts have been submitted (not in time to discuss for ietf) to offer
> other enhancements to pim which fit into our new charter.
>
> Pekka: One clarification needed in the charter which says provide a "more
> reliable" solution. Propose to whom and by whom.
>
> Mike: I'll change "propose" to "submit".
>
> _______________________________________________
> pim mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pim
>

_______________________________________________
pim mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pim