Re: [pim] draft-wijnands-pim-source-discovery-bsr call for adoption

[Mike McBride <[e-mail]>]

This draft has received sufficient support to declare rough consensus
for adoption. We are now the proud (for most) owners of this draft.
Authors, please submit a new draft-pim version of this draft. Thank
you all for your opinions on this draft, both for and against.

It was good seeing many of you in Vancouver. After a couple of back to
back Friday slots, PIM will NOT be meeting on a Friday again for
awhile.

mike

On Fri, Oct 25, 2013 at 3:07 PM, Mike McBride <[e-mail]> wrote:
>
> The authors of draft-wijnands-pim-source-discovery-bsr-03 have requested that we initiate a call for adoption of their draft which they presented in our last meeting in Berlin. Notes from that presentation are below. Please comment over the next week (before ietf week) on your interest/non-interest with adoption of this draft.
>
> http://www.ietf.org/id/draft-wijnands-pim-source-discovery-bsr-03.txt
>
> thanks,
> mike
>
> 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.
>
>