On Wed, 8 Jan 2020, Gyan Mishra wrote:
<trimmed> | Gyan> Source discovery is only necessary with ASM not SSM. With SSM the receiver is "source" aware so does not require any discovery mechanism. | So with SSM which requires IGMPv3 enabled on the receiver last hop router subnets and on the source first hop router subnet for the both to be "source aware" ; for the receiver now to | send the (S,G) join for the channel since it is now source aware. How the receiver gets that source awareness is from the server URI that the user connects to which has the S,G | information ; server has to be also source aware and has S,G channel available that can be joined. With IGMPv3 the packet accommodate the Source information in the S,G join sent | along the RPF path to the source. You mention that SSM deployment has been limited but in fact the opposite and reason why ASM is being officially deprecated by the IETF for inter | domain multicast routing. IPv6 does not even have MSDP support since with ASM MSDP source discovery and propagation is not necessary since no RPs exist all disparate ASM multicast | domains can now be collapsed into a single SSM domain. ASM MSDP/Anycast has its complexities which is why IPv6 nixed the idea of integrating MSDP into the architecture. Thus IPv6 only | supports SSM for inter-domain multicast routing. I would keep the comment about ASM complexity which is true but remove mention of SSM. I would not mention any gains with less state Actually, Embedded RP provides interdomain ASM for IPv6 and is the reason there is no need for MSDP in IPv6. No one would disagree that SSM is simpler and the ideal way to go, hence draft-ietf-mboned-deprecate-interdomain-asm recommends SSM-only for interdomain deployments. Unfortunately, for various (and sometimes somewhat valid) reasons, ASM lives on, at least in intradomain deployments. Hence, BGP would still need to cover ASM scenarios, at least for these intradomain deployments that still rely on ASM to work. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
