Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
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 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 | Sent: Friday, May 7, 2021 12:55 PM | To: Jeffrey (Zhaohui) Zhang | Cc: Lenny Giuliano ; Qin Wu ; bess ; draft-ietf-bess-mvpn-msdp-sa-interoperation.all | ; last-call ; ops-dir | 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
Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03
On Thu, 9 Jan 2020, Gyan Mishra wrote: | | 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. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03
On Wed, 8 Jan 2020, Gyan Mishra wrote: | Gyan> Source discovery is only necessary with ASM not SSM. With SSM the receiver is "source" aware so does not require any discovery mechanism. | So with SSM which requires IGMPv3 enabled on the receiver last hop router subnets and on the source first hop router subnet for the both to be "source aware" ; for the receiver now to | send the (S,G) join for the channel since it is now source aware. How the receiver gets that source awareness is from the server URI that the user connects to which has the S,G | information ; server has to be also source aware and has S,G channel available that can be joined. With IGMPv3 the packet accommodate the Source information in the S,G join sent | along the RPF path to the source. You mention that SSM deployment has been limited but in fact the opposite and reason why ASM is being officially deprecated by the IETF for inter | domain multicast routing. IPv6 does not even have MSDP support since with ASM MSDP source discovery and propagation is not necessary since no RPs exist all disparate ASM multicast | domains can now be collapsed into a single SSM domain. ASM MSDP/Anycast has its complexities which is why IPv6 nixed the idea of integrating MSDP into the architecture. Thus IPv6 only | supports SSM for inter-domain multicast routing. I would keep the comment about ASM complexity which is true but remove mention of SSM. I would not mention any gains with less state Actually, Embedded RP provides interdomain ASM for IPv6 and is the reason there is no need for MSDP in IPv6. 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. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG adoption and IPR poll for draft-zzhang-bess-bgp-multicast-03
I am not aware of any IPR related to this draft. -Lenny On Mon, 6 Jan 2020, slitkows.i...@gmail.com wrote: | | Hello, | | | | This email begins a two-weeks WG adoption poll for and draft-zzhang-bess-bgp-multicast-03 [1] . | | For information, it’s companion document (draft-zzhang-bess-bgp-multicast-controller-02) is also polled for WG adoption in a separate email. | | | | Please review the draft and post any comments to the BESS working group list. | | | | We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, | 3669 and 5378 for more details). | | | | If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the | BESS mailing list. The document won't progress without answers from all the authors and contributors. | | Currently, there are no IPR disclosures against this document. | | | | If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. | | | | This poll for adoption closes on *** 20th January 2020 *** | | | | Regards, | | Matthew and Stephane | | | | [1] https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast | | | | | ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] WG adoption poll and IPR poll for draft-zzhang-bess-bgp-multicast-controller
I support adoption of this draft. On Mon, 6 Jan 2020, slitkows.i...@gmail.com wrote: | | Hello, | | | | This email begins a two-weeks WG adoption poll for and draft-zzhang-bess-bgp-multicast-controller-02 [1] .. | | For information, it’s companion document (draft-zzhang-bess-bgp-multicast-03) is also polled for WG adoption in a separate email. | | | | Please review the draft and post any comments to the BESS working group list. | | | | We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, | 3669 and 5378 for more details). | | | | If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the | BESS mailing list. The document won't progress without answers from all the authors and contributors. | | Currently, there are no IPR disclosures against this document. | | | | If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. | | | | This poll for adoption closes on *** 20th January 2020 *** | | | | Regards, | | Matthew and Stephane | | | | [1] https://datatracker.ietf.org/doc/draft-zzhang-bess-bgp-multicast-controller/ | | | | | ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Call for adoption: draft-zzhang-bess-mvpn-msdp-sa-interoperation-01
Support as coauthor bc it addresses a practical deployment problem that is currently seen with MSDP interacting with MVPN. I am not aware of any relevant undisclosed IPR. On Mon, 26 Feb 2018, stephane.litkow...@orange.com wrote: | | Hello working group, | | | | This email starts a two-week call for adoption on | | draft-zzhang-bess-mvpn-msdp-sa-interoperation-01 [1] as a BESS Working Group Document. | | | | Please state on the list if you support the adoption or not (in both cases, please also state the reasons). | | | | This poll runs until *the 19th of March*. | | | | We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). | | If you are listed as an Author or a Contributor of this Document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and | Contributors. | | | | Currently no IPR has been disclosed against this Document. | | | | If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. | | | | Thank you | | | | (Martin), Matthew, Stéphane | | bess chairs | | | | [1] https://datatracker.ietf.org/doc/draft-zzhang-bess-mvpn-msdp-sa-interoperation/ | | | | _ | | Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc | pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler | a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, | Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. | | This message and its attachments may contain confidential or privileged information that may be protected by law; | they should not be distributed, used or copied without authorisation. | If you have received this email in error, please notify the sender and delete this message and its attachments. | As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. | Thank you. | | ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] bess: draft-zzhang-bess-mvpn-msdp-sa-interoperation
Toerless, Thanks for the comments. After thinking about your feedback on RFC4610 a bit, I'm not sure that case is applicable here. Consider the 2 directions of interworking: 1) MSDP SA/AnycastRP_PIM_Register -> MVPN SA 2) MVPN SA -> MSDP SA/AnycastRP_PIM_Register As I understand, #1 is already covered by RFC6513/6514. #2 is the missing piece that this draft attempts to address. I don't believe #2 will be applicable for RFC4610, as these registers only go to members of the RP set. And the RP set should be configured on all the C-RPs. It wouldn't make much sense to have these registers transit the MVPN domain to go to an AnycastRP not in the configured RP set. Hope this is clear, and let me know if I'm missing anything. -Lenny | -Original Message- | From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Toerless Eckert | Sent: Monday, November 13, 2017 9:43 PM | To: bess@ietf.org | Cc: mbo...@ietf.org | Subject: [bess] bess: draft-zzhang-bess-mvpn-msdp-sa-interoperation | | Jeffrey presented subject draft in mboned. Given how i am | not usually tracking BESS WG mailing list and may not be around: | | I would like to see subject draft to be adopted as a WG document in BESS | and become an update to RFC6514 (not to say bugfix ;-). | | Feeedback detail: The draft should be amended to fix the same problem not only for | MSDP SA but also RFC4610 and probably accordingly change the draft name. | | Cross-posted to mboned (sorry) because there where a couple of MBoned | participants expressing support for the draft in BESS and may like me not | be BESS regulars. | | Cheers | Toerless ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
