[pim] Orlando meeting minutes

[Mike McBride <[e-mail]>]

Thanks to Tom Taylor for taking the minutes. Please review and reply
to Stig and I with any proposed changes/additions we may have missed.

thanks,
mike

PIM WG minutes
Friday 3/15, 9-11am
Mike McBride, Stig Venaas

No comments on agenda

Status (Stig)
=============
draft-ietf-pim-explicit-tracking
Really need people to comment
Looked for willingness to forward to IESG. 3 in favour, no one
against. Taking to list
again to confirm, PLEASE respond.

Implementation report
draft-zzp-pim-rfc4601-update-survey-report-00
Reviewed history.
8 for adoption, none against. Will check on list.
Will do last call after small change and resubmission as draft-ietf-pim...

Lenny repeated his opinion that it should be Informational

PIM DR LOad Balancing (Toerless Eckert presenting)
==================================================
draft-ietf-pim-drlb-02

Overview
Update from -01
- changed hash algorithm
- simplified some of the Hello options
Next steps:
- continued experiments with hash algorithm
- implementation
Perhaps WGLC after this next round

Multiple Upstream Interface Support for IGMP/MLD Proxy
=======================================================
draft-asaeda-pim-mldproxy-multif-01
Stig presenting

Slides:
  Overview
  Terminology, Configuration
  Supported Address Prefix
  Supported Address Prefix -- Possible Scenarios
  Interface Priority
  Interface Priority -- Possible Scenarios
  Upstream Interface Take-Over
  Default Values
  Open Issue
  Next Steps
  - presented to Homenet ML as well
  - adopt here?

  Comment: some simplification possible -- have additional information.
  Comment (Thomas Schmidt): mobility inspires this work -- additional
information not available.
  Comment (Toerless Eckert): Cisco has similar implementation, relies
on routing info as suggested, could consider this stuff too.
Compromise. Another comment: some routes could be provisioned by DHCP.
Stig: on Linux, can create routes for multicast. Toerless agrees.
  Comment: need to decide whether to work on requiremnts or solution.
  Stig as Chair: yes, would have to decide which to work on. Need to
figure which use  cases are worth working on. Mike: are they shopping
for WG? Stig: this is the logical place -- Multimob doesn't have the
full scope.

Extension of MLD proxy functionality to support multiple upstream interfaces
============================================================================

Slides:
  Problem statement - general application: common network access
infrastructure to get

info from multiple multicast providers
  Motivation
    - notes changes from previous version
  Fixed network communication scenarios
  Needed functionality per fixed scenario
  Mobile network communication scenarios
  Proxy mobile IPv6 (RFC5213)
  A minimal deployment option for multicast listeners in PMIPv6
domains (RFC6224)
  - Toerless: why not just use routes built up by MLD? Answer: Multimob charter
  - Thomas: routing actually done by policy rather than routing
tables. Alternative more complex than one might expect. PMIP's
function is to hide actual routing from mobile terminal.
  - take offline.
  Toerless: would like to substitute "IGMP/MLD" in place of "MLD". Agreed.

  Proposed next steps
    - collect more scenarios
    - get comments
    - start defining needed proxy extensions
    - move to PIM

Stig asks: worth working on motivations, use cases? Yes. Bill Atkins:
need requirements
draft, this may be it. Do keep working on it. Possible outcome is that
PIM needs change.

Multi-Upstream Interfaces IGMP/MLD Proxy
========================================
draft-zhang-pim-muiimp-00
Presented by Thomas.

Slides:
  Why multi-upstream interfaces?
  History
  - initial ideas in MAGMA
  Objectives and requirements
  - unique coverage of receivers
  - prevent routing loops
  Multi-Upstream Interfaces IGMP/MLD Proxy
  - proposed approach - route according to a filtering table
  Filter table for MUIIMP
  (More details)
  Is this work of interest?
  Stig: need to work up requirements. Premature to adopt at this time,
but potentially of interest.
  Mike: need presentation on why PMIP  chosen rather than LISP or
other approaches.
  - response: Multimob focus was PMIP. Has certain advantages in
compatibility with operator policy, implementation simplicity.

draft-liu-multimob-igmp-mld-wireless-mobile-03
==============================================================
Mike McBride presenting.

Slides:
  Aims
  New
  Option List
  Suspend/Resume
    Thomas: suspend/resume has more general use case. e.g. channel
switching. Probably
should be in separate document.
    Toerless: performance optimization needs to be supported by a performance
requirement.
    Stig: Agreed - remove suspend/resume from draft.
  Will WG take this work if suspend/resume removed? 3 support, none
against. Post
revised document, then adoption request will be called.

draft-asghar-pim-explicit-rpf-vector
====================================
Toerless Eckert presented.

Slides:
  Editorial changes 00 -> 01
  Problem statement
  - building tree explicitly analogously to operation of RSVP
  Solution requirement: path diversity in live-live resiliency
  Motivation (detail)
    - author of "Maximally Redundant Tree" draft to discuss with
Toerless. Stig says:
concepts of this draft and MRT draft are orthogonal.
  Solution example (this draft): Explicit Path Vector TLV Stack
  Encoding
  - new PIM Join attribute
  Explicit RPF Vector Attribute TLV Format
  Moving forward - looking for feedback

10 in favour, none against. Pretty conclusive, check on mailing list.

PIM VRRP Interoperability
=========================
draft-zhou-pim-vrrp-01
Presented by Toerless.

Slides:
  Rationale
   - Comment: VRRP is for host to router, PIM is router to router.
Routers are smart
enough to switch? Response: next slide.
  Use case
  - routers A and B do not run IGP dynamically for security reasons
  Proposed solution
  Tracking and Failover
  ditto, proposed change in -01
         ditto, advantages
  PIM Assert
  BiDir Group
  Further Considerations
  Adopt?
   - Comment: seems like reasonable approach for solving when VRRP is
used. Should fix
the IGP problem. Use case seems to be a misuse of VRRP. Toerless: lot
of deployment.

Alternative use case presented orally does seem valid.

4 for adoption. None against. Will check on mailing list.

PIM Join Attributes For LISP
============================
draft-arango-pim-join-attributes-for-lisp-00
Being presented in LISP too.
Presented by Stig.

Slides:
  Problem being solved
  Unicast transport
  Encoding Rcvr-Source ITR
  Outer IP Source Unsuitable
  Inner IP Source Unsuitable
  PIM J/P Attribute Solution (more for LISP WG)
  Encoding LISP Unicast Transport Information
  Transport Attribute Format
  Receiver RLOC Format
  Wrap up
   - hoping for LISP WG to decide on requirement, but if they do, work
has to be done
here.
   - question to Chair: could call for adoption happen before next
IETF if LISP gives
the word?. Mike: yes, could be done.

Hierarchical Join/Prune Attributes
==================================
draft-venaas-pim-hierarchicaljoinattr-00
Stig presenting.

Trying to provide more efficient coding for particular situations.

Slides:
  Introduction
  J/P message format
  J/P attribute hierarchy:
  - specify at upstream neighbour, group, or source address level
  - can override at lower level for more specific cases
  Encoding types

Useful?
 - 3 for, none against. To the list.