Thanks Leonard that answers my questions. Kind Regards
Gyan On Tue, May 11, 2021 at 2:40 PM Leonard Giuliano <le...@juniper.net> wrote: > > 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 < > 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 > | > | -- > | > | [vz-logo-email] > | > | Gyan Mishra > | > | Network Solutions Architect > | > | Email gyan.s.mis...@verizon.com > | > | M 301 502-1347 > | > | > | > | > -- <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
