Gyan- most of these interop questions for MSDP-MVPN are covered in RFC6514. This doc makes no changes to those procedures. This doc simply addresses a fundamental gap that was missed in RFC6514- specifically that MSDP SAs contain 3 pieces of info (source, group, originating RP) and MVPN SAs contain 2 pieces of info (source, group). So everything is fine in the MSDP SA -> MVPN SA direction, but the opposite direction (MVPN SA -> MSDP SA) will be missing this important chunk of info, which MSDP requires to perform peer-RPF. This doc basically sticks the RP address into a BGP EC so RP address can be propagated across the MVPN P domain and transmitted back out when sending MSDP SAs on the other side. Otherwise, RFC6514 rules apply: MSDP accepts/rejects SAs based on it's peer-RPF rules and MVPN uses BGP selection rules to determine the best route. Hope this answers your questions, -Lenny On Tue, 11 May 2021, Gyan Mishra wrote: | | 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 <zzhang@xxxxxxxxxxx> 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 <hayabusagsm@xxxxxxxxx> | Sent: Friday, May 7, 2021 12:55 PM | To: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@xxxxxxxxxxxxxx> | Cc: Lenny Giuliano <lenny@xxxxxxxxxxx>; Qin Wu <bill.wu@xxxxxxxxxx>; bess <bess@xxxxxxxx>; draft-ietf-bess-mvpn-msdp-sa-interoperation.all | <draft-ietf-bess-mvpn-msdp-sa-interoperation.all@xxxxxxxx>; last-call <last-call@xxxxxxxx>; ops-dir <ops-dir@xxxxxxxx> | 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.net@xxxxxxxxxxxxxx> wrote: | | > Hi Qin, | > | > | > | > Thank you so much for the review and comments. I have posted -06 revision | | Juniper Business Use Only | | -- | | [vz-logo-email] | | Gyan Mishra | | Network Solutions Architect | | Email gyan.s.mishra@xxxxxxxxxxx | | M 301 502-1347 | | | | -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
