PIM minutes:
- Showed agenda slides
- MRIB Flap: slides-93-pim-0-damping  (Fangwei Hu)
  = problem if there are a lot of oifs.  Only first and last updates matter,
    but intermediates should be suppressed.
  = RFC 2439 damping is too complex for multicast route flap
  = parameter definition (e.g., max-suppress)
  = Principle of SMRDA (simple multicast route damping algorithm??)
  = Ask for WG adoption... (ZTE has implemented in product)
  = Stig look at Kebler's draft
    == Robert Kebler (ours focus is on upstream neighbors,
			this on on damping)
    == Ravendra Torvi (Is this informational)
    == Fangewi: This draft can be useful for the router.
  = Stig: Is damping something we should work on within this group?
	(no response)
  = Stig: Does it make sense to collaborate with Kebler's draft?
	(only one person read the draft?)
- Reliable PIM registers: slides-93-pim-1-registers (Peter Anish)
  = detailed slide presentation!
  = Toerless: What is the motivation for the solution?
    Peter: Dealing with the register from the first hop to the RP
    Toerless: Only proposing to use for R to RP?
    Peter: Suppose RP is handling 20k source groups.  It would get 20k
	message per minute and have to respond.
    Toerless: So you want to avoid subsequent refresh.  What about behavior
	in the beginning.
    Peter: Packet loss has to be avoided.  Need reliable port to get status.
    Peter: We are only sending the Register State on reliable connection,
	not the Register message
    Toerless: Need more work on the problem statement.
  = Anycast RP (reliable full mesh connectivity between RPs in anycast group)
  = Q: Will the Register State last forever?  A: Yes.
    Q: This uses a lot of TCPs.  A: Is it too many TCPs?  How is it better in
	the current solution?
    Stig:  If TCP connection goes down, do you remove connections from FHR?
    Peter: Would come up and reestablish
    Stig: So have to remember the Register State if TCP connection?
  = As Toerless said, we need to discuss it more, scaling, etc.  Need to
	discuss on the mailing list.
- PIM Source discovery: slides-93-pim-2-stream (Peter Anish)
  = Could help if LHR knows about active sources for multicast group
  = Connection Setup (targeted adjacency, PORT keepalive)
  = IGMP MLD Stream Receiver Interest message
  = Monitoring liveness only needed on FHR
  = This feature is independent from Reliable Register proposal
  = Incremental deploy,ent is possible
  = Pete: What about the source discovery draft
    Peter: That draft is a draft open for discussion.
    Pete: RP already has information about active sources.  RP has
	tight coupling with data plane.
    Tebler: A different draft may be approprite.
    Peter: How does FHR inform the controller?  We want to make it into
	a pure control plane device, not tightly coupled with data plane
  = Tim: If it's suggested as a improvement, when does the improvement
	justify the additional complexity
    Peter: This does not add complexity
- Expicit Tracking: slides-93-pim-4-tracking (Hitoshi Asaeda)
  = Last Call passed.
  = IESG recommended reconsider the intended status of the draft.
	(consider Experimental)
  = Alvaro: Many features specified as optional.
  = Hitoshi: Keeping track of membership state is the only mandatory part
	== and this is just a data structure, can't test for interoperability
  = Option 1: keep as proposed standard (need to rewrite for style of PS)
	== request for help
  = Option 2: Change to Informational (rewrite the document to address
	Alvaro's comments), WGLC again
  = Stig: not clear enough about the benefits of the optional features.
  = Toerless: Reason to implement is to reduce latency and monitoring
  = Alvaro: No guidance for turning on Query Suppression.
  = Toerless: The things that are optional are those for which we have
	not reached consensus.  The thing that is not optional is the
	thing that is mandatory.  What can we do?
  = Alvaro: What about a YANG model?  Plus, if you don't have consensus,
	then the document does still need work!  Don't think we can move
	to a standards document?
  = Stig: How many people think Experimental?  How many proposed?  How
	many have read the draft?
    == O.K. Will proposed Experimental to mailing list
    == Alvaro: Please explain what experiment would be recommended.
- Multiple Upstream Interfaces: slides-93-pim-6-multiif (Hitoshi Aseada)
  = Load Balancing, Robust Data Reception, Upstream I/F Takeover
  = Parameters, configuration syntax, decision order
    == Subscrber Address, Channel/Session ID, Priority->Credit, Backup I/F
    == Default configuration: NULL
  = Default Interface is zero (e.g., 0 credit, 0 backup, ...)
  = Could use explicit tracking to speed up detection of inactive interfaces.
  = Priority -> Credit
  = ... skipped three slides ...
  = Stig: Needs to work on requirements
  = Seil Jeon: What does it mean "inactive"
    == Hitoshi: no fixed definition.  No message at all, too many errors...
    == Seol Jeon: How to decide where interfaces are, for configuration
    == Hitoshi: configuration can be manual
    == Seol Jeon: Could be thousands of interfaces.
    == Hitoshi: Automatic configuration would come later.  Please bring
       any ideas.
- Yang: slides-93-pim-7-yang (Pete McCallister)
  = Please look at wiki
  = Will cover all core PIM and PIM protocol extensions
  = Other multicast protocols done in different drafts
  = So far has a skeleton and design doctrine
  = Still lots to do...  Please fill in the wiki
  = Unresolved issues: Scope of Address family, RP config tree naming, indexing
    = Also, how to configure BFD
    = General concept underlying ACL/policy
  = AF Hierarchy (three options)
    == Toerless : steal from unicast?
    == Acee: Use BGP, or can look at ISIS
    == Xupeng Li?: Structure is similar to BGP, but there is a problem.
	Cisco has AF under Interface, Juniper under "ALL"??
    == Pete Mc: Please send pointer to discussion
    == Peter A: something about AF interfaces
  = RP draft better idea: just non-mode-specific config in RP module
  = Pete Mc: Important to keep it conceptual
- Ran out of time for draft-zhang-pim-dr-improvement (Sandy Zhang)
  = When DR changes (RFC 4601), needs seconds to elect a new DR
  = When newcomer arrives with higher priority, the new router becomes DR
    == packet loss
  = How to reduce recovery time?  How to reduce packet loss?
  = DR/BDR: when DR becomes unreachable, BDR becomes DR immediately
	= BDR imports multicast flows in advance.