Subject: [pim] Prague wg meeting minutes

From: "Mike McBride (mmcbride)" <[email-masked]>
Date: Mon, 4 Apr 2011 12:53:44 -0700

Please review and offer corrections/additions where necessary before we
post. Thanks to Greg Shepherd for the notes:

PIM WG Minutes
Prague, March 28th, 2011

Mike McBride
Recharter Proposals
 -errata: "There is a significant number of errata that need to be
addressed in order to advance RFC4601 to Draft Standard. The PIM WG will
correct the errata, as necessary, and then update RFC4601."
 -igmp: "The working group primarily works on extensions to PIM, but may
take on work related to IGMP/MLD."
 -No opposition in the room. Alias is next.

Jeffrey Zhang
4601 Revision
Address about 100 open errata
 -Three volunteers from cisco/huawei/juniper
 -00 draft in 2-3 weeks with all verified errata corrected
 -identify optional features that do not meet 2026 req's.
  -*,*,RP
  -explicit tracking
  -group to rp mappings (refer to pim-group-rp-mapping)
 -01 draft with optional features removed before July ietf
 -feedback please

Stig Venaas
pim-port-06 update
Good feedback on the list after wglc#2
Many minor editorial issues fixed
Changed format of port j/p message
Added keepalive message
Made interface ID a standalone pim hello option
Is the draft ready for another last call? - yes

Gorry Fairhurst
getting back on keep alive. Do we need so many options? What's the
motivation for so many options vs a few simple ones.

Stig
Hold time is needed... if there, why not other places. Flexibility is
beneficial.

Stig
pim-hello-intid-00
if we take this out of PORT then PORT relies on this - both need same
standards track
..covered other draft bits (see press)
vote to room for adoption - 5 for, 0 against

Gorry
type field exchanging... can't have different levels of uniqueness

Stig
The way the draft is written now, can be zero if you don't care.

Stig
magma-msnip-06
History of draft.. started in MAGMA which closed down. Picked up last
version and resubmitted to see if there is interest here.
ASM support added to the draft
Other draft bits presented (see preso/draft)

Lenny Giuliano
Lack of interest 10 years ago.. What's new?

Stig
There was interest in limiting traffic on first hop L2. Other
proposals have come to address some of this

Lenny
If it didn't progress 10 years ago, just as little interest now.

Mike
Stig resurrected this in response to another proposal at the last WG
meeting

Thomas Schmidt
Interest in the mobility area - pre-work to multimob
Work in the IRTF to address overlay multicast - a common host API

Hitoshi Asaeda
We must take care when we proposed to changed the host stack.

Stig	
Is it worth working on or should we let it die?

Shep
I'd prefer to see this work focus on addressing real needs ie - mobility

Thomas
Could we let it progress then add use cases?

Mike
Who thinks msnip is work the group should take on? - 0 hands.

Stig
Who feels it still is interesting work? - 11 hands

Gorry
Two questions? Are we interested in source discovery, and are we
interested in MSNIP?

Hitoshi
Explicit-tracking-02
Covering draft bits.. (see presentation)

Mike
What's the history of this draft? Why was it not adopted in the past?

Lenny
It didn't get far enough..

Mike
Isn't explicit tracking covered in the IGMPv3/MLDv2 drafts?

Hitoshi
Yes, but it doesn't explain how.

Shep
would this be informational?

Lenny
Lots of interest in the WG a few meetings back

Stig
Protocol drafts don't detail how-to, so this work could clarify
Pending charter changes, should we adopt this work?
Gorry
How will this document affect existing ET implementations?
Mike
Let's sort out the charter then we'll come back to evaluate this
work. We should get some vendor involvement.

Ice Wijnands
hou-pim-ecmp - Presenting on the authors' behalf
Covered draft bits (see press)

Lenny
How is this different than current PIM assert?

Ice
This is not data driven, and more deterministic.

Lenny
Assert has been a problem on peering LANs. It's always been a
challenge. Many would consider assert to be broken - is this
introducing the same mechanisms over multiple ifcs and making the
problem worse?

Ice
No, this is addressing many of those issues as well. Perhaps we
shouldn't call it "asserts".

Sven
Two comments - agreement that this is an uncommon topology
the behavior you're trying to correct we are actually intentionally
implementing.

Ice
This was proposed to address a customers need

Sven
I'm happy to work with you on this offline

Mike
Adoption 0 for, 0 against.. 0 participation in the room I guess. 
taking it to the list
Are the use cases in the draft?

Ice
Not explicitly at the moment.

Wrap