-----Original Message-----
From: Mike McBride [mailto:mmcbride at cisco.com]
Sent: Friday, April 20, 2007 6:05 AM
To: pim at ietf.org
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
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim
