Please see zzh> below. From: Gyan Mishra <[email protected]> Sent: Thursday, January 9, 2020 1:25 PM To: Jeffrey (Zhaohui) Zhang <[email protected]> Cc: Lenny Giuliano <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03
On Thu, Jan 9, 2020 at 12:41 PM Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>> wrote: Gyan, What embedded RP gives you is that you don't need to configure RP addresses. Once the RP is known for a group (however it is done - static config in case of IPv4/IPv6, dynamic learning via BSR/Auto-RP in case of v4, or embedded RP in case of IPv6), the rest is all the same: source sends register towards the RP and LHRs sends (*,g) join towards the RP. In case a set of RPs are used for a single group, the RPs learn the sources from each other either via MSDP (IPv4 only) or via PIM registers sent among themselves. Once the traffic arrives at the LHR routers they learn the sources and can send (s,g) joins. When we say network-based source discovery we refer to the learning of sources by the LHRs (so that they can send (s,g) joins). Gyan> I understand the IPv4 scenario. I was referring to the IPv6 scenario that the embedded RP provides the RP address to build the group RP map which is fine but you still need a LHR mechanism to discover the source which does not exist with SSM. There are reasons for that and I am drafting reply to the other thread I will explain. Zzh> That’s why the draft has relevant text: 1) SSM needs source discovery and will not totally succeed unless the source discovery problem is solved 2) this draft provides a BGP based source discovery mechanism (in addition to BGP based join/prune). > via BGP multicast NLRI AFI 1 and 2 for v4 v6 with SAFI 2 to propagate the > source information That is not for source learning. It is for learning of the non-congruent routes to the sources. In many cases you only need to originate a few routes (in extreme cases a default route is enough), and it has no group information. Gyan> I understand that non congruent routes is one use case for multicast NLRI ; If the LHR was BGP connected and its RPF path to the source was now via BGP multicast NLRI you could use this method to discover all SSM sources via the network. Imagine if you decided you wanted to augment you SSM infrastructure with a multicast NLRI for source propagation you could do this on your source FHR and receiver LHR and with all intermediate hops including the core now providing congruent reach ability to the SSM multicast sources ; you now have solved the SSM gap mentioned related to LHR network based source discovery. I don’t think their is a draft on this but I think it’s a worthwhile I-D. Zzh> Source discovery is about (s,g), and SAFI 2 does not have group information. Zzh> Jeffrey Jeffrey -----Original Message----- From: Lenny Giuliano <[email protected]<mailto:[email protected]>> Sent: Thursday, January 9, 2020 12:06 PM To: Gyan Mishra <[email protected]<mailto:[email protected]>> Cc: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03 On Thu, 9 Jan 2020, Gyan Mishra wrote: <trimmed> | | Actually, Embedded RP provides interdomain ASM for IPv6 and is the reason | there is no need for MSDP in IPv6. | | | Gyan> With embedded RP how is the “source” SA propagated as is done | by MSDP with IPv4 accomplished with IPv6. The only alternative and is a way that SSM for both IPv4 and IPv6 can provide network discovery that I know of and not have to rely on app based discovery ; is via BGP multicast NLRI AFI 1 and 2 for v4 v6 with SAFI 2 to propagate the source information. | This is also used when migration from ASM to SSM and want to maintain inter domain boundaries you can use SAFI 2 for multicast NLRI source propagation. With Embedded RP, the address of the RP is "embedded" in the group address, so just by looking at the group address, routers can derive the RP address and know where to send their (*,g) joins. Hence there is no need for RPs to "talk" to one another as they do in IPv4 with MSDP. See RFC 3956 for more details. | | | 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. | | | Gyan> Agreed ASM must be supported for intra domain Then I suspect we are all in violent agreement. -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: [email protected]<mailto:[email protected]>
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
