All things related to multicast

["Curtis, Bruce" <>]

Looks like I was wrong.  Further testing now that ASM connectivity to the Janet dbeacon is gone shows that the dbeacon using the -B bootstrap option learns the list of other dbeacons and sends joins towards them correctly.  However the dbeacon that receives the bootstrap request via unicast does not appear to send joins towards the dbeacon that sent the -B bootstrap request.  I glanced at the source code but couldn’t verify that quickly.  But testing so far indicates that two dbeacons that don’t have ASM connectivity would both have to use the -B bootstrap option towards each other.

On Oct 30, 2018, at 3:28 PM, Curtis, Bruce <> wrote:

I found that the dbeacon already has a “bootstrap” option.

-B ADDR
              This  allows  you  to  bootstrap  from  an ADDR that is already in the matrix. This
              option is useful when you ASM connectivity is broken but SSM connectivity works.

http://manpages.ubuntu.com/manpages/xenial/man1/dbeacon.1.html

I tested with the NORDUnet beacon and was successful but also saw indications that this may have been a special case and therefore not a complete test.

While I did not have ASM connectivity with the NORDUnet beacon after I ran the dbeacon with the bootstrap option that triggered ASM connectivity NORDUnet beacon to work.

http://noctv.funet.fi/nordunet?full=1&what=ssmorasm&att=loss&at=

I did find that it is important to include the /port-number option with the IP number used for the -B option and that the ASM group must match in the -b option.

Here is the command I used for testing.

dbeacon -n NDSU2 -a -b 233.10.43.42/10000 -B 193.166.4.38/10000 -S 232.10.43.42/10000 -C US

If further testing shows that the  “bootstrap” option will work then we should be able to use the “bootstrap” options with the Janet IPv4 multicast dbeacon.

http://www.beacon.ja.net/cgi-bin/m4

On Sep 26, 2018, at 1:49 PM, David Farmer <> wrote:

Chris,

Is the Multicast WG () still the preferred place to discuss Multicast related issues? In not where?

I ask because I believe most of the Multicast Beacons were configured for ASM.  Are there suggestions or community BCP for SSM configuration of the Multicast Beacons?  

Will Internet2 provide SSM Multicast Beacons?  Anyone else planning to provide SSM Multicast Beacons? How do we coordinate this?

Further, if we are going to continue to support SSM Multicasts are there any other suggestions for monitoring it and ensuring that it is actually functioning? 

Thanks

On Wed, Sep 26, 2018 at 1:40 PM, Chris Wilkinson <> wrote:

Good afternoon NTAC,

Below you will find Internet2's newly minted announcement for the sunset of interdomain ASM currently targeted for 12/15. We're hoping the large lead time will allow us to develop collaborative solutions with anyone who may be impacted by this change. Considering our extensive discussions last year on this topic, it will helpfully not come as a surprise to anyone on this list.

If you have any comments, questions, or concerns please reply on list, to the I2 NTAC channel, or reach out to Mark Brochu and myself. We welcome any and all input.

Best,
Chris

--
Chris Wilkinson
Director of Network Architecture and Planning, Internet2
734.352.4962
--

Internet2, in response to community and Internet Engineering Task Force (IETF) recommendations, as well as interoperability concerns with future growth, will begin the sunset of Interdomain Any Source Multicast (ASM).

As part of this transition, Internet2 will coordinate with members to begin the decommission of Multicast Source Discovery Protocol (MSDP) peerings. This is already occurring with various members and we are seeing an accelerated trend since the release of the Deprecating ASM for Interdomain Multicast Abstract. Internet2 is recommending that the few members that still have active ASM sources transition these to SSM. 

If this is technically impractical, our technical staff can work with your organization and your multicast subscribers to transition to private multicast peerings, such as layer 2 circuits between receivers, and/or the provisioning of private multicast VPNs (mvpns) between participants. Internet2 will be available for feedback and questions during the 2018 Technology Exchange on Oct 15-18. Starting on October 28, Internet2 will begin formally sending notification to any existing MSDP peers that a disconnect will be scheduled. We hope to have all MSDP sessions removed by Dec 15, 2018.

Background:

There are two well-known flavors of IP multicast: Any Source Multicast (ASM), and Source Specific Multicast (SSM). Initially, many applications were written to leverage ASM addressing. This was mostly due to the fact that several operating systems lacked support for IGMPv3, a necessary component of SSM. As such, autonomous networks would exchange information using the Multicast Source Discovery Protocol, or MSDP.

MSDP was implemented in 2003 and has remained in “experimental” status. The low demand across operators for this feature has led to deficiencies which have not been addressed, leading to liabilities on the Internet2 network. These deficiencies include flooding of network state information, lack of state attack protection, and undesired source filtering.

As time progressed, it became clear that the use case for ASM was not as relevant in the interdomain setting. That is, between domains, usually only one source would send data to multiple receivers, something better suited to SSM. Major operating systems have also been supporting SSM for some time (Windows, MacOS, Linux/Android).

As Internet2 continues to evolve its network, it has become clear that our continued support of MSDP would hinder future growth, in part by the lack of attention the protocol has received from vendors, resulting in the deficiencies listed above. In response, the IETF felt it necessary to issue a draft BCP recommending the deprecation of Inter-domain ASM. Internet2 supports the IETF draft and believes this is the best path forward for the community.

Please note that this does NOT mean that Internet2 will stop supporting Interdomain Multicast. PIM SSM and IPv6 will both be supported mechanisms for interdomain multicast applications across the Internet2 footprint.

--

===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---
Bruce Curtis                        
Certified NetAnalyst II                701-231-8527
North Dakota State University        

---
Bruce Curtis                        
Certified NetAnalyst II                701-231-8527
North Dakota State University