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

From: Jeff Tantsura <[email-masked]>
Date: Tue, 5 Nov 2013 19:24:45 +0000

Hi,

I support adoption of this draft, I believe it is useful for a multicast
enabled enterprise environment.

Cheers,
Jeff

-----Original Message-----

>>>> 
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>> Mike McBride
>>>> Sent: Friday, October 25, 2013 6:08 PM
>>>> To: [email-masked]
>>>> Subject: [pim] draft-wijnands-pim-source-discovery-bsr call for
>>> adoption
>>>> 
>>>> 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.
>>>> 
>>>> _______________________________________________
>>>> pim mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/pim
>>> 
>>> 
>> 
>> 
>
>_______________________________________________
>pim mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pim

---

From: Hermin Anggawijaya <[email-masked]>
Date: Tue, 5 Nov 2013 22:02:00 -0800

I support the WG adoption of this draft.

Regards

Angga