Hi Jeffrey I am all set with the draft technical Q&A as this draft fills an important gap for operators, I believe is in excellent shape ready for publication.
Thank you Gyan On Tue, May 11, 2021 at 11:08 AM Gyan Mishra <hayabusa...@gmail.com> 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 >> > -- > > <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* > > -- <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
