RE: [pim] IETF68 pimwg mtg minutes

[Su Haiyang <suhaiyang at huawei.com>]

Dear All,
 Where can I find any progress about periodic state refresh reduction on SM
draft?
Thanks
Su haiyang 

-----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



_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim