Thanks Jeffrey for the explaining section 14 and your drafts use case that is being addressed.
So Section 14 is a case of C-Multicast PIM ASM and non inter site local-only shared C-Tree where the PE can function as MVPN C-RP, Anycast RP or MSDP peer for the MVPN and the procedure describes the source discovery to generate the Type 5 SA AD route. Section 14 only applies to case where RP/MSDP function is done by the PE for the customer MVPN. So your draft provides an additional option to section 14 use case update of ASM SPT mode C-Multicast PIM ASM non inter site no local-only shared tree use case where the customer has existing MSDP infrastructure to not use section 14 existing solution which would require VPN Specific MSDP peering overhead on the PEs mesh group for SA propagation inter site. This is an important common use case for operators. For the MSDP SA / MVPN SA interoperability translation how would you apply the MSDP peer RPF check rules for MSDP peer RPF check failures where SA messages are filtered and dropped as mesh group peers RPF check does not apply, where non mesh group peers RPF check applies. With mesh group peers the concept is similar to iBGP full mesh where SA re-advertisement into the mesh cannot occur. How do you prevent or deal with looping SAs which is common. Also as SAs are looped and SA cache has continuous churn and as per the interop the SA churn in MSDP is propagated now into MVPN SA that would seem to have same soft state as MSDP soft state. Also how would you maintain the SA cache state table in MVPN SA. The SA state table can be pretty massive. How would this scale for inter-as L3 VPN MVPN SAFI 129 inter-as. How does the soft state maintenance of SA cache state table even in intra-as scale for MVPN SA interop? The MVPN SA cache state is not necessarily per MVPN and that would be difficult to create an aggregate label. You could have multiple discrete overlays of sets of MSDP meshed for a single customer that don’t talk to each other thus different grouping of sources and receivers within a single customer VPN. So then you could have multiple discrete SA state tables that would have to translate into multiple discrete MVPN SA state maintenance per discrete state table. Kind Regards Gyan On Mon, May 10, 2021 at 9:53 AM Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> wrote: > Hi Gyan, > > Now your question and this discussion is really about RFC 6514. > > As specified in RFC 6514 (section 14 & 13) and mentioned in this draft, > there are two ways to support ASM over MVPN. > > One way is to have a PE (its VRF to be exact) as a C-RP or with an MSDP > session to an off-site C-RP is one way (section 14). Its purpose is to > avoid establishing (*,g) tree (and subsequent rpt/spt switch) over the > provider network, not to provide value-added service. That's why RFC has > section title as "14. Supporting PIM-SM without Inter-Site Shared C-Trees". > > That has one missing feature when the customer also has its own MSDP > infrastructure to distribute source information among its MSDP speakers, > and that's what this draft is about. > > What you describe below about how ASM is done is the other way (Section > "13. Switching from a Shared C-Tree to a Source C-Tree" in RFC 6514). > > Thanks. > > Jeffrey > > -----Original Message----- > From: Gyan Mishra <hayabusa...@gmail.com> > Sent: Friday, May 7, 2021 12:55 PM > To: Jeffrey (Zhaohui) Zhang <zzhang=40juniper....@dmarc.ietf.org> > Cc: Lenny Giuliano <le...@juniper.net>; Qin Wu <bill...@huawei.com>; bess > <bess@ietf.org>; draft-ietf-bess-mvpn-msdp-sa-interoperation.all < > draft-ietf-bess-mvpn-msdp-sa-interoperation....@ietf.org>; last-call < > last-c...@ietf.org>; ops-dir <ops-...@ietf.org> > Subject: Re: [bess] Opsdir last call review of > draft-ietf-bess-mvpn-msdp-sa-interoperation-05 > > [External Email. Be cautious of content] > > > Hi Jeffrey > > I read the draft and saw your comments that RFC 6514 mentions MSDP on the > PE. > > In what use case would SP have to run Anycast RP / MSDP on the PE when that > ASM control plane function can all be done on the CE. > > I guess there maybe customers looking for value added service to have the > SP provide that function and in that case is where this draft would come > into play for SPT feature to make it work. > > My understanding of the shared tree over MVPN using MVPN RFC 6513, 6514 > procedures is as follows: > > ASM > > 1. Egress receiver PE sends Type 6 shared tree (c-*,c-g) is sent towards > the RP PE. > > 2. The join received by RP behind PE triggers a type 7 source tree join > (c-s,c-g) towards the source ingress PE. > > 3. Ingress PE sends Type-5 source active to trigger SPT switchover back to > the RP PE and all PEs on the S-PMSI selective tree. > > 4. Egress receiver PEs now sends Type-7 (c-s,c-g) to the source PE > > 5. Multicast stream now flows over the selective tree S-PMSI from Ingress > Source PE to all egress receiver PEs. > > SSM > > 1. Egress receiver PEs now sends Type-7 (c-s,c-g) to the source PE > > 2. Multicast stream now flows over the selective tree S-PMSI from Ingress > Source PE to all egress receiver PEs. > > > > Kind Regards > > > Gyan > > On Thu, May 6, 2021 at 3:27 PM Jeffrey (Zhaohui) Zhang <zzhang= > 40juniper....@dmarc.ietf.org> wrote: > > > Hi Qin, > > > > > > > > Thank you so much for the review and comments. I have posted -06 revision > > Juniper Business Use Only > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
