On Thu, Jan 9, 2020 at 12:41 PM Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>
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.
>
> > 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.
>
> Jeffrey
>
> -----Original Message-----
> From: Lenny Giuliano <le...@juniper.net>
> Sent: Thursday, January 9, 2020 12:06 PM
> To: Gyan Mishra <hayabusa...@gmail.com>
> Cc: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; bess-cha...@ietf.org;
> bess@ietf.org; draft-zzhang-bess-bgp-multic...@ietf.org;
> slitkows.i...@gmail.com
> 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: gyan.s.mis...@verizon.com
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
