[pim] Berlin meeting notes

[Mike McBride <[e-mail]>]

Please review the following draft meeting notes from our meeting in
Berlin. If you have corrections or additions please let Stig and I
know. Thank you to Hitoshi for taking the minutes.

thanks,
mike

PIM WG minutes
Thursday 8/1, 1-3pm
Stig Venaas, Mike McBride
Notes: Hitoshi Asaeda

No comments on agenda

Status (Stig/Mike)
==================
rfc4601-update passed WGLC

explicit-tracking draft passed WGLC. One more update.

explicit-rpf-vector passed WGLC, needs updating based on ML comments.

igmp-mld wireless will go to WG draft. 4 yes in the meeting.

joinattributes draft: 4 in the room in favor. 3 in the room last time.
Bharat offered comments. Will poll the list.

draft-zhou-pim-vrrp-01 adoption discussion (Mike)
=================================================
Adoption currently on hold. Authors of
draft-xu-pim-drpriority-auto-adjustment-04 would like wg to consider a
merge because there is an overlap particularly with aligning vrrp with
pim. We will have a brief overview of both and discuss how to proceed.

draft-xu-pim-drpriority-auto-adjustment wasn't accepted as a wg item a
couple of years ago. No strong interest in the group.

The WG needs to decide if its interested in this work, the earlier
draft. If not we proceed with draft-zhou-pim-vrrp adoption call if
there is interest. If intereste we either:

-Adopt and progress both drafts. One as a problem statement, the other
as protocol work.
-Reference earlier draft in draft-zhou-pim-vrrp
-Merge drafts into new draft

Any interest in VRRP in general? No hands. Will take it to the list
and see if there is any interest. If no one but the authors care we
won't work it. 4 in favor last time in addition to authors.

Note: the usual suspects were not in the room primarily due to
conflicting WG meetings.

draft-ietf-6man-multicast-addr-arch-update-01 (Stig)
====================================================
stig: should not ff2x::/32 also be SSM?
???: a little bit scared about cleaning up for something in the
future. Maybe put this in information draft. Multiple implementations
in the field so wouldn't be easy but there are definite
inconsistancies.
Stig: implementations would treat those addresses differently.
Brian Haberman:Stig and i have talked about this off/on for a year.
There are some issues in the document. Looking for values for the flag
rather then looking at bits. One way would be to write errata
statements saying to not do that. Need to look at existing
implementations, someone will need to change code. Do we really need
this changed? See if you can get a couple implementatons to say if
that are doing the bit wise comparisons like they are suppose to. Or
check entire thing as a single value.
???: Errata probably is the best way.
stig: lots of people don't read errata.
Action: pim to review the draft, maybe a joint wglc.

draft-joshi-pim-ecmp-neighbor-select-00 (Stig)
==============================================
Stig presenting in his behalf.
Is it worth standardizing this hash to select the upstream neighbor
because currently its undefined.
Stig: could be complications with implementations supporting old and new.
2 people have read it.
Bob kebler: not sure if its solving the problem they hope. You can
still have an assert with a hash. R2 can still have a different path
to the source then R1. Depends upon topology.
Jeffrey Zhang: Not taking on the work would be fine.
???: it works, its a transient problem.

draft-wignands-pim-source-discovery-bsr-03 (Ice)
==============================================
highly redudant mcast network without single point of failure.
Jeffrey: Of the 10k flows how many groups?
Ice: the sources are what's relevant. 10k s,gs. Not introducing a new
routing protocol.
Jeffrey: Could use mospf. pim bidir is another viable approach. With
bidir, while the RPA canbe an address that is not tried to any router
(the address would be associated with a LAN), the LAN that the RPA is
on could become partitioned. When that happens, traffic cannot be
exchanged on the LAN between the partitions, affecting lots of
receivers. That's the problem using PIM-BIDIR instead of BSR flooing.
However, that can be easily resolved by a protocol extension. I should
be able to publish it for the next IETF meeting. With that resolved,
PIM bidir will be a better solution for the targeted deployment
scenario.
stig: one issue with bidir is you don't have the optimal path.
operator DT: I like the use case and support.
Hitoshi: flooding is not typically optimal.
Ice: its only using mechanisms that exist today with bsr.
jeffrey: the amount of information is more with today.
Hitoshi: Why not use SAP (I'm not a fan of SAP though)? Whats the
meaning of flooding. Use MSDP if interdomain?
lighthouse networks: you mentioned dns, why can't you use that?
Ice; this is a case where you don't know the source. bsr based
flooding. not inter domain discussion. Enterprise network.
Mike: applaud any efforts to make multicast more simple. But flooding
may be a problem.

1 room interested. 2 operators on draft interested. Mike will poll on list.

draft-kebler-pim-mrt-protection-01 (Rob Kebler)
===========================================
Rob: pim extensions to support maximally redundant trees.
MRT being done in rtgwg.
Ice: how do you do rpf check?
Rob: If the link is down
Stig: GRE or MPLS is simpler?
Mike: any operators needing this beyond what's there today? Which
routers need to support (LHR or other)?
Rob: All routers, but incremental deployment scenario is also considered.
Stig: How much MRT is interested in?
Rob: MRT is discussed in rtgrg
Ice: local protection?
Rob: we can discuss
Stig: 4 people interested
Rob: ask for adoption after the next revision.
Ice: link and local protection hard to do. what should be done in pim
versus mldp, etc

draft-contreras-pim-multiple-upstreams-00:
Brian: In magma, no strong interest of multiple upstream for IGMP
proxy. Second, reducing complexity is the way to go. not sure if we
wanted to go down the road because the whole point of proxy is to
simply multicast.
Behcet: Why not multimob?
Brian: pim has the responsibility in specifying group mgmt protocols.
Adrian: This WG has mld/igmp. multimob does not have work on igmp/mld protocols.
Stig: igmp/mld solutions belong here. Good to have people with
protocol knowledge.
Ice: would be good to see a better use case explanation and motivation.
Hitoshi: well written draft. good to publish as a requirements draft.
Bechet: already an industry practice having multiple interfaces.
Hitoshi's explicit tracking is also widely implemented so why are we.
Carlos: these extensions may be useful and bring to a more wide area.
Brian: Area Director: don't want to see core protocol development over
multiple groups. igmp work should be done here so we don't have people
step on each other.
Brian: would highly encourage discussion in mboned because that is
where operators live.
Hitoshi: document is useful. could be useful in mboned.
Stig: typically initial work done in mboned and solutions done here.
Carlos: have non multimob scenarios.
Brian: just talked about multiple upstreams, don't confuse about
mobility. Take to the list. please get input from mboned.
Carlos: comfortable with this being an Informational requirements/use
case document.
Stig: present to mboned and then come to pim and report.

zhang: initial idea.

Hitoshi: similar draft. submitted last year.
What is the next step?
Stig: Good to discuss, but early to make decision, whether selecting a
single doc or merging into one doc.