On Thu, Jan 9, 2020 at 1:30 PM Jeffrey (Zhaohui) Zhang <[email protected]>
wrote:

> 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]> 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
>
> Gyan> Understood.
>

> Jeffrey
>
> -----Original Message-----
> From: Lenny Giuliano <[email protected]>
> Sent: Thursday, January 9, 2020 12:06 PM
> To: Gyan Mishra <[email protected]>
> Cc: Jeffrey (Zhaohui) Zhang <[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, 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]
>
>
>
>
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email protected]
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess

Reply via email to