Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
Hi Jeffrey I am all set with the draft technical Q 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 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 >> 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 < >> draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org>; last-call < >> last-c...@ietf.org>; 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 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
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
> | 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 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 | 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 * *M 301 502-1347* ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
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. | |
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
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 < > draft-ietf-bess-mvpn-msdp-sa-interoperation....@ietf.org>; last-call < > last-c...@ietf.org>; 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 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 selecti
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
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 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 wrote: > Hi Qin, > > > > Thank you so much for the review and comments. I have posted -06 revision Juniper Business Use Only ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
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 wrote: > Hi Qin, > > > > Thank you so much for the review and comments. I have posted -06 revision. > > > > Jeffrey > > > > *From:* Qin Wu > *Sent:* Friday, April 30, 2021 11:59 AM > *To:* Jeffrey (Zhaohui) Zhang ; Lenny Giuliano < > le...@juniper.net>; ops-dir > *Cc:* bess ; > draft-ietf-bess-mvpn-msdp-sa-interoperation.all < > draft-ietf-bess-mvpn-msdp-sa-interoperation....@ietf.org>; last-call < > last-c...@ietf.org> > *Subject:* RE: Opsdir last call review of > draft-ietf-bess-mvpn-msdp-sa-interoperation-05 > > > > *[External Email. Be cautious of content]* > > > > > Jeffrey, thanks for your clarification. I am clear now. Would it be great to > add some clarifications text as an overview somewhere which will add a lot of > clarity. Thanks! > > -Qin > > *发件人：* Jeffrey (Zhaohui) Zhang > > *收件人：* Qin Wu;Lenny Giuliano >;ops-dir > > *抄送：* bess;draft-ietf-bess-mvpn-msdp-sa-interoperation.all< > draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org>;last-call< > last-c...@ietf.org> > > *主题：* RE: Opsdir last call review of > draft-ietf-bess-mvpn-msdp-sa-interoperation-05 > > *时间：* 2021-04-30 23:04:49 > > > > Hi Qin, > > > > Before the mechanism in this document is introduced, a PE may need to have > MSDP sessions of both of the following: > > > >1. With non-PE MSDP speakers (e.g. a C-RP) >2. With other PEs > > > > #1 is clearly stated in RFC6514. #2 is mentioned in this document: > > > >… PE2 would need to > >have an MSDP session with PE1 (that advertised the MVPN SA messages) > >to learn the sources via MSDP SA messages, for it to advertise the > >MSDP SA to its local peers. > > > > With the mechanism (i.e., a PE advertises MSDP SA messages based on > received MVPN SA routes) in this document, #2 is no longer needed. > > > > Jeffrey > > > > *From:* Qin Wu > *Sent:* Friday, April 30, 2021 10:21 AM > *To:* Jeffrey (Zhaohui) Zhang ; Lenny Giuliano < > le...@juniper.net>; ops-...@ietf.org > *Cc:* bess@ietf.org; > draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; > last-c...@ietf.org > *Subject:* RE: Opsdir last call review of > draft-ietf-bess-mvpn-msdp-sa-interoperation-05 > > > > *[External Email. Be cautious of content]* > > > > *发件人**:* Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net > ] > *发送时间:* 2021年4月30日 22:05 > *收件人:* Qin Wu ; Lenny Giuliano ; > ops-...@ietf.org > *抄送:* bess@ietf.org; > draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; > last-c...@ietf.org > *主题:* RE: Opsdir last call review of > draft-ietf-bess-mvpn-msdp-sa-interoperation-05 > > > > Hi Qin, > > > > I assume there is one question in your latest email, marked with [Qin3], > about the following paragraph: > > > >The MVPN PEs that act as customer RPs or have one or more MSDP > >sessions in a VPN (or the global table in case of GTM) are treated as > >an MSDP mesh group for that VPN (or the global table). In the rest > >of the document, it is referred to as the PE mesh group. It MUST NOT > >include other MSDP speakers … > > > > Let's restart from a clean slate. It reads the following: > > > > The MVPN PEs … are treated as an MSDP mesh group … It MUST NOT > > Include other MSDP speakers … > > > > Basically the
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
Hi Qin, Thank you so much for the review and comments. I have posted -06 revision. Jeffrey From: Qin Wu Sent: Friday, April 30, 2021 11:59 AM To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano ; ops-dir Cc: bess ; draft-ietf-bess-mvpn-msdp-sa-interoperation.all ; last-call Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Jeffrey, thanks for your clarification. I am clear now. Would it be great to add some clarifications text as an overview somewhere which will add a lot of clarity. Thanks! -Qin 发件人： Jeffrey (Zhaohui) Zhangmailto:zzh...@juniper.net>> 收件人： Qin Wumailto:bill...@huawei.com>>;Lenny Giulianomailto:le...@juniper.net>>;ops-dirmailto:ops-...@ietf.org>> 抄送： bessmailto:bess@ietf.org>>;draft-ietf-bess-mvpn-msdp-sa-interoperation.allmailto:draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org>>;last-callmailto:last-c...@ietf.org>> 主题： RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 时间： 2021-04-30 23:04:49 Hi Qin, Before the mechanism in this document is introduced, a PE may need to have MSDP sessions of both of the following: 1. With non-PE MSDP speakers (e.g. a C-RP) 2. With other PEs #1 is clearly stated in RFC6514. #2 is mentioned in this document: … PE2 would need to have an MSDP session with PE1 (that advertised the MVPN SA messages) to learn the sources via MSDP SA messages, for it to advertise the MSDP SA to its local peers. With the mechanism (i.e., a PE advertises MSDP SA messages based on received MVPN SA routes) in this document, #2 is no longer needed. Jeffrey From: Qin Wu mailto:bill...@huawei.com>> Sent: Friday, April 30, 2021 10:21 AM To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; Lenny Giuliano mailto:le...@juniper.net>>; ops-...@ietf.org<mailto:ops-...@ietf.org> Cc: bess@ietf.org<mailto:bess@ietf.org>; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperation....@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org> Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] 发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2021年4月30日 22:05 收件人: Qin Wu mailto:bill...@huawei.com>>; Lenny Giuliano mailto:le...@juniper.net>>; ops-...@ietf.org<mailto:ops-...@ietf.org> 抄送: bess@ietf.org<mailto:bess@ietf.org>; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperation....@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org> 主题: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 Hi Qin, I assume there is one question in your latest email, marked with [Qin3], about the following paragraph: The MVPN PEs that act as customer RPs or have one or more MSDP sessions in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It MUST NOT include other MSDP speakers … Let's restart from a clean slate. It reads the following: The MVPN PEs … are treated as an MSDP mesh group … It MUST NOT Include other MSDP speakers … Basically the mesh group only includes certain MVPN PEs and not other MSDP speakers. The PEs that are included in the mesh group are those that "act as customer RPs or have one ore more MSDP sessions". I thought the text is clear? [Qin]: Sorry to go into loop discussion, When you say MVPN PEs have one or more MSDP sessions in a VPN, I am wondering, with whom MVPN PE have one or more MSDP session? non-PE MSDP speakers ? This is not clear to me. Do we really need to have such MSDP session? [Qin]: it seems PEs can have one or more MSDP session with other PEs, but based on your previous clarification, you said: “ 1. Highlight the assumption difference between mechanism proposed in RFC6514 and one proposed in this draft, e.g., in this draft, it doesn't require MSDP session to be established between PEs while RFC6514 allows this, that is why we applied different policy on different network elements. Zzh3> The introduction section does clearly state the following: If a PE does advertise MSDP SA messages based on received MVPN SA routes, the VPN-specific MSDP sessions are no longer needed. ” Are you saying VPN-specific MSDP session between PEs are not needed? Or sometimes need while sometimes not needed? Thanks. Jeffrey -Original Message- From: Qin Wu mailto:bill...@huawei.com>> Sent: Friday, April 30, 2021 9:43 AM To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; Lenny Giuliano mailto:le...@juniper.net>>; ops-...@ietf.org<mailto:ops-...@ietf.org> Cc: bess@ietf.o
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
Jeffrey, thanks for your clarification. I am clear now. Would it be great to add some clarifications text as an overview somewhere which will add a lot of clarity. Thanks! -Qin 发件人： Jeffrey (Zhaohui) Zhangmailto:zzh...@juniper.net>> 收件人： Qin Wumailto:bill...@huawei.com>>;Lenny Giulianomailto:le...@juniper.net>>;ops-dirmailto:ops-...@ietf.org>> 抄送： bessmailto:bess@ietf.org>>;draft-ietf-bess-mvpn-msdp-sa-interoperation.allmailto:draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org>>;last-callmailto:last-c...@ietf.org>> 主题： RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 时间： 2021-04-30 23:04:49 Hi Qin, Before the mechanism in this document is introduced, a PE may need to have MSDP sessions of both of the following: 1. With non-PE MSDP speakers (e.g. a C-RP) 2. With other PEs #1 is clearly stated in RFC6514. #2 is mentioned in this document: … PE2 would need to have an MSDP session with PE1 (that advertised the MVPN SA messages) to learn the sources via MSDP SA messages, for it to advertise the MSDP SA to its local peers. With the mechanism (i.e., a PE advertises MSDP SA messages based on received MVPN SA routes) in this document, #2 is no longer needed. Jeffrey From: Qin Wu Sent: Friday, April 30, 2021 10:21 AM To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano ; ops-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation....@ietf.org; last-c...@ietf.org Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] 发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2021年4月30日 22:05 收件人: Qin Wu mailto:bill...@huawei.com>>; Lenny Giuliano mailto:le...@juniper.net>>; ops-...@ietf.org<mailto:ops-...@ietf.org> 抄送: bess@ietf.org<mailto:bess@ietf.org>; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperation....@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org> 主题: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 Hi Qin, I assume there is one question in your latest email, marked with [Qin3], about the following paragraph: The MVPN PEs that act as customer RPs or have one or more MSDP sessions in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It MUST NOT include other MSDP speakers … Let's restart from a clean slate. It reads the following: The MVPN PEs … are treated as an MSDP mesh group … It MUST NOT Include other MSDP speakers … Basically the mesh group only includes certain MVPN PEs and not other MSDP speakers. The PEs that are included in the mesh group are those that "act as customer RPs or have one ore more MSDP sessions". I thought the text is clear? [Qin]: Sorry to go into loop discussion, When you say MVPN PEs have one or more MSDP sessions in a VPN, I am wondering, with whom MVPN PE have one or more MSDP session? non-PE MSDP speakers ? This is not clear to me. Do we really need to have such MSDP session? [Qin]: it seems PEs can have one or more MSDP session with other PEs, but based on your previous clarification, you said: “ 1. Highlight the assumption difference between mechanism proposed in RFC6514 and one proposed in this draft, e.g., in this draft, it doesn't require MSDP session to be established between PEs while RFC6514 allows this, that is why we applied different policy on different network elements. Zzh3> The introduction section does clearly state the following: If a PE does advertise MSDP SA messages based on received MVPN SA routes, the VPN-specific MSDP sessions are no longer needed. ” Are you saying VPN-specific MSDP session between PEs are not needed? Or sometimes need while sometimes not needed? Thanks. Jeffrey -Original Message- From: Qin Wu mailto:bill...@huawei.com>> Sent: Friday, April 30, 2021 9:43 AM To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; Lenny Giuliano mailto:le...@juniper.net>>; ops-...@ietf.org<mailto:ops-...@ietf.org> Cc: bess@ietf.org<mailto:bess@ietf.org>; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperation....@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org> Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Section 3 When we say MVPN Pes that have one or more MSDP session in a VPN, does this statement contradict with “VPN-specific MSDP sessions are not required among the PEs”? zzh> The MSDP session that the PEs have are with other non-PE MSDP speakers but not among themselves, so it does not contradict with that quote
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
Hi Qin, Before the mechanism in this document is introduced, a PE may need to have MSDP sessions of both of the following: 1. With non-PE MSDP speakers (e.g. a C-RP) 2. With other PEs #1 is clearly stated in RFC6514. #2 is mentioned in this document: … PE2 would need to have an MSDP session with PE1 (that advertised the MVPN SA messages) to learn the sources via MSDP SA messages, for it to advertise the MSDP SA to its local peers. With the mechanism (i.e., a PE advertises MSDP SA messages based on received MVPN SA routes) in this document, #2 is no longer needed. Jeffrey From: Qin Wu Sent: Friday, April 30, 2021 10:21 AM To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano ; ops-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] 发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2021年4月30日 22:05 收件人: Qin Wu mailto:bill...@huawei.com>>; Lenny Giuliano mailto:le...@juniper.net>>; ops-...@ietf.org<mailto:ops-...@ietf.org> 抄送: bess@ietf.org<mailto:bess@ietf.org>; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org> 主题: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 Hi Qin, I assume there is one question in your latest email, marked with [Qin3], about the following paragraph: The MVPN PEs that act as customer RPs or have one or more MSDP sessions in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It MUST NOT include other MSDP speakers … Let's restart from a clean slate. It reads the following: The MVPN PEs … are treated as an MSDP mesh group … It MUST NOT Include other MSDP speakers … Basically the mesh group only includes certain MVPN PEs and not other MSDP speakers. The PEs that are included in the mesh group are those that "act as customer RPs or have one ore more MSDP sessions". I thought the text is clear? [Qin]: Sorry to go into loop discussion, When you say MVPN PEs have one or more MSDP sessions in a VPN, I am wondering, with whom MVPN PE have one or more MSDP session? non-PE MSDP speakers ? This is not clear to me. Do we really need to have such MSDP session? [Qin]: it seems PEs can have one or more MSDP session with other PEs, but based on your previous clarification, you said: “ 1. Highlight the assumption difference between mechanism proposed in RFC6514 and one proposed in this draft, e.g., in this draft, it doesn't require MSDP session to be established between PEs while RFC6514 allows this, that is why we applied different policy on different network elements. Zzh3> The introduction section does clearly state the following: If a PE does advertise MSDP SA messages based on received MVPN SA routes, the VPN-specific MSDP sessions are no longer needed. ” Are you saying VPN-specific MSDP session between PEs are not needed? Or sometimes need while sometimes not needed? Thanks. Jeffrey -Original Message- From: Qin Wu mailto:bill...@huawei.com>> Sent: Friday, April 30, 2021 9:43 AM To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; Lenny Giuliano mailto:le...@juniper.net>>; ops-...@ietf.org<mailto:ops-...@ietf.org> Cc: bess@ietf.org<mailto:bess@ietf.org>; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperation....@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org> Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Section 3 When we say MVPN Pes that have one or more MSDP session in a VPN, does this statement contradict with “VPN-specific MSDP sessions are not required among the PEs”? zzh> The MSDP session that the PEs have are with other non-PE MSDP speakers but not among themselves, so it does not contradict with that quoted text. [Qin]:Without your clarification, I feel MVPN PEs will only establish MSDP session with other PEs in a VPN, rather than non-PE MSDP speakers? Can you add text to make this clear? Zzh2> Section 1 does say the following: ... One or more of the PEs, say PE1, either act as a C-RP and learn of (C-S,C-G) via PIM Register messages, or have MSDP sessions with some MSDP peers and < learn (C-S,C-G) via MSDP SA messages... [Qin2]: without your clarification or familiar with the context of RFC6514, I will believe MSDP can be either PE2 or non PE elements. [RFC6514] only specifies that a PE receiving the MVPN SA routes, say PE2, will advertise
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2021年4月30日 22:05 收件人: Qin Wu ; Lenny Giuliano ; ops-...@ietf.org 抄送: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org 主题: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 Hi Qin, I assume there is one question in your latest email, marked with [Qin3], about the following paragraph: The MVPN PEs that act as customer RPs or have one or more MSDP sessions in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It MUST NOT include other MSDP speakers … Let's restart from a clean slate. It reads the following: The MVPN PEs … are treated as an MSDP mesh group … It MUST NOT Include other MSDP speakers … Basically the mesh group only includes certain MVPN PEs and not other MSDP speakers. The PEs that are included in the mesh group are those that "act as customer RPs or have one ore more MSDP sessions". I thought the text is clear? [Qin]: Sorry to go into loop discussion, When you say MVPN PEs have one or more MSDP sessions in a VPN, I am wondering, with whom MVPN PE have one or more MSDP session? non-PE MSDP speakers ? This is not clear to me. Do we really need to have such MSDP session? [Qin]: it seems PEs can have one or more MSDP session with other PEs, but based on your previous clarification, you said: “ 1. Highlight the assumption difference between mechanism proposed in RFC6514 and one proposed in this draft, e.g., in this draft, it doesn't require MSDP session to be established between PEs while RFC6514 allows this, that is why we applied different policy on different network elements. Zzh3> The introduction section does clearly state the following: If a PE does advertise MSDP SA messages based on received MVPN SA routes, the VPN-specific MSDP sessions are no longer needed. ” Are you saying VPN-specific MSDP session between PEs are not needed? Or sometimes need while sometimes not needed? Thanks. Jeffrey -Original Message- From: Qin Wu mailto:bill...@huawei.com>> Sent: Friday, April 30, 2021 9:43 AM To: Jeffrey (Zhaohui) Zhang mailto:zzh...@juniper.net>>; Lenny Giuliano mailto:le...@juniper.net>>; ops-...@ietf.org<mailto:ops-...@ietf.org> Cc: bess@ietf.org<mailto:bess@ietf.org>; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org<mailto:draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org> Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Section 3 When we say MVPN Pes that have one or more MSDP session in a VPN, does this statement contradict with “VPN-specific MSDP sessions are not required among the PEs”? zzh> The MSDP session that the PEs have are with other non-PE MSDP speakers but not among themselves, so it does not contradict with that quoted text. [Qin]:Without your clarification, I feel MVPN PEs will only establish MSDP session with other PEs in a VPN, rather than non-PE MSDP speakers? Can you add text to make this clear? Zzh2> Section 1 does say the following: ... One or more of the PEs, say PE1, either act as a C-RP and learn of (C-S,C-G) via PIM Register messages, or have MSDP sessions with some MSDP peers and < learn (C-S,C-G) via MSDP SA messages... [Qin2]: without your clarification or familiar with the context of RFC6514, I will believe MSDP can be either PE2 or non PE elements. [RFC6514] only specifies that a PE receiving the MVPN SA routes, say PE2, will advertise (C-S,C-G) C-multicast routes if it has corresponding (C-*,C-G) state learnt from its CE. PE2 may also have MSDP sessions with other C-RPs at its site, < [Qin2]: In the VPN membership context, I will assume C-RPs can be PE1, but of course I am wrong. Zzh2> MVPN PEs establishing MSDP sessions with other non-PE devices is a common practice in RFC6514, so we should not need to call it again. [Qin2]: I think having some text to clarify MSDP peers or C-RPS as MSDP speakers is non-PE elements will have no harm, e.g., OLD TEXT: " The MVPN PEs that act as customer RPs or have one or more MSDP sessions in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It MUST NOT include other MSDP speakers, and is integrated into the rest of MSDP infrastructure for the VPN (or the global table) following normal MSDP rules and practices. " NEW TEXT: " The MVPN PEs that act as customer RPs or have one or more MSDP sessions with non-PE element
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
Hi Qin, I assume there is one question in your latest email, marked with [Qin3], about the following paragraph: The MVPN PEs that act as customer RPs or have one or more MSDP sessions in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It MUST NOT include other MSDP speakers … Let's restart from a clean slate. It reads the following: The MVPN PEs … are treated as an MSDP mesh group … It MUST NOT Include other MSDP speakers … Basically the mesh group only includes certain MVPN PEs and not other MSDP speakers. The PEs that are included in the mesh group are those that "act as customer RPs or have one ore more MSDP sessions". I thought the text is clear? Thanks. Jeffrey -Original Message- From: Qin Wu Sent: Friday, April 30, 2021 9:43 AM To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano ; ops-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Section 3 When we say MVPN Pes that have one or more MSDP session in a VPN, does this statement contradict with “VPN-specific MSDP sessions are not required among the PEs”? zzh> The MSDP session that the PEs have are with other non-PE MSDP speakers but not among themselves, so it does not contradict with that quoted text. [Qin]:Without your clarification, I feel MVPN PEs will only establish MSDP session with other PEs in a VPN, rather than non-PE MSDP speakers? Can you add text to make this clear? Zzh2> Section 1 does say the following: ... One or more of the PEs, say PE1, either act as a C-RP and learn of (C-S,C-G) via PIM Register messages, or have MSDP sessions with some MSDP peers and < learn (C-S,C-G) via MSDP SA messages... [Qin2]: without your clarification or familiar with the context of RFC6514, I will believe MSDP can be either PE2 or non PE elements. [RFC6514] only specifies that a PE receiving the MVPN SA routes, say PE2, will advertise (C-S,C-G) C-multicast routes if it has corresponding (C-*,C-G) state learnt from its CE. PE2 may also have MSDP sessions with other C-RPs at its site, < [Qin2]: In the VPN membership context, I will assume C-RPs can be PE1, but of course I am wrong. Zzh2> MVPN PEs establishing MSDP sessions with other non-PE devices is a common practice in RFC6514, so we should not need to call it again. [Qin2]: I think having some text to clarify MSDP peers or C-RPS as MSDP speakers is non-PE elements will have no harm, e.g., OLD TEXT: " The MVPN PEs that act as customer RPs or have one or more MSDP sessions in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It MUST NOT include other MSDP speakers, and is integrated into the rest of MSDP infrastructure for the VPN (or the global table) following normal MSDP rules and practices. " NEW TEXT: " The MVPN PEs that act as customer RPs or have one or more MSDP sessions with non-PE elements in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It only have one PE and MUST NOT include other PEs as MSDP speakers, and is integrated into the rest of MSDP infrastructure for the VPN (or the global table) following normal MSDP rules and practices. " Zzh3> Unfortunately the new text is not correct Zzh3> This document is about a PE treating incoming MVPN SA routes as MSDP SA messages (which triggers outgoing MSDP SA messages to MSDP peers). Therefore, the PEs originating the MVPN SA routes and PEs originating outgoing MSDP SA messages as a result are considered in the same MSDP mesh group (as if they were running MSDP among themselves). That mesh group, referred to as PE mesh group, includes all PEs that "act as customer RPs or have one or more MSDP sessions in a VPN". Zzh3> A PE may have multiple MSDP sessions and mesh groups. Zzh3> This document does assume "familiarity with MVPN and MSDP protocols and procedures", and adding more clarifications will pull in more and more concepts/procedures like a chain reaction, so I'd rather avoid that. Zzh3> Thanks. Zzh3> Jeffrey [Qin3]: I think the confusing issue comes from " It MUST NOT include other MSDP speakers " and " have one or more MSDP sessions in a VPN ", my question are what are other MSDP speaker?, with whom PE have one or more session in a VPN? based on your previous clar
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
Section 3 When we say MVPN Pes that have one or more MSDP session in a VPN, does this statement contradict with “VPN-specific MSDP sessions are not required among the PEs”? zzh> The MSDP session that the PEs have are with other non-PE MSDP speakers but not among themselves, so it does not contradict with that quoted text. [Qin]:Without your clarification, I feel MVPN PEs will only establish MSDP session with other PEs in a VPN, rather than non-PE MSDP speakers? Can you add text to make this clear? Zzh2> Section 1 does say the following: ... One or more of the PEs, say PE1, either act as a C-RP and learn of (C-S,C-G) via PIM Register messages, or have MSDP sessions with some MSDP peers and < learn (C-S,C-G) via MSDP SA messages... [Qin2]: without your clarification or familiar with the context of RFC6514, I will believe MSDP can be either PE2 or non PE elements. [RFC6514] only specifies that a PE receiving the MVPN SA routes, say PE2, will advertise (C-S,C-G) C-multicast routes if it has corresponding (C-*,C-G) state learnt from its CE. PE2 may also have MSDP sessions with other C-RPs at its site, < [Qin2]: In the VPN membership context, I will assume C-RPs can be PE1, but of course I am wrong. Zzh2> MVPN PEs establishing MSDP sessions with other non-PE devices is a common practice in RFC6514, so we should not need to call it again. [Qin2]: I think having some text to clarify MSDP peers or C-RPS as MSDP speakers is non-PE elements will have no harm, e.g., OLD TEXT: " The MVPN PEs that act as customer RPs or have one or more MSDP sessions in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It MUST NOT include other MSDP speakers, and is integrated into the rest of MSDP infrastructure for the VPN (or the global table) following normal MSDP rules and practices. " NEW TEXT: " The MVPN PEs that act as customer RPs or have one or more MSDP sessions with non-PE elements in a VPN (or the global table in case of GTM) are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, it is referred to as the PE mesh group. It only have one PE and MUST NOT include other PEs as MSDP speakers, and is integrated into the rest of MSDP infrastructure for the VPN (or the global table) following normal MSDP rules and practices. " Zzh3> Unfortunately the new text is not correct Zzh3> This document is about a PE treating incoming MVPN SA routes as MSDP SA messages (which triggers outgoing MSDP SA messages to MSDP peers). Therefore, the PEs originating the MVPN SA routes and PEs originating outgoing MSDP SA messages as a result are considered in the same MSDP mesh group (as if they were running MSDP among themselves). That mesh group, referred to as PE mesh group, includes all PEs that "act as customer RPs or have one or more MSDP sessions in a VPN". Zzh3> A PE may have multiple MSDP sessions and mesh groups. Zzh3> This document does assume "familiarity with MVPN and MSDP protocols and procedures", and adding more clarifications will pull in more and more concepts/procedures like a chain reaction, so I'd rather avoid that. Zzh3> Thanks. Zzh3> Jeffrey [Qin3]: I think the confusing issue comes from " It MUST NOT include other MSDP speakers " and " have one or more MSDP sessions in a VPN ", my question are what are other MSDP speaker?, with whom PE have one or more session in a VPN? based on your previous clarification above, i.e., " Zzh said: " zzh> The MSDP session that the PEs have are with other non-PE MSDP speakers but not among themselves " Now you said: " Zzh3> A PE may have multiple MSDP sessions and mesh groups with other PEs Zzh3>That mesh group, referred to as PE mesh group, includes all PEs that "act as customer RPs or have one or more MSDP sessions in a VPN". " So Which one statement is correct? Are you sure MSDP session between PEs are needed or required in this document? ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
Hi Qin, Please see zzh3> below, and attached diff. -Original Message- From: Qin Wu Sent: Tuesday, April 27, 2021 9:53 PM To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano ; ops-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Thanks Jeffrey for clarification, I have better understanding on your document. I suggest to add clarity to the text from two perspectives: 1. Highlight the assumption difference between mechanism proposed in RFC6514 and one proposed in this draft, e.g., in this draft, it doesn't require MSDP session to be established between PEs while RFC6514 allows this, that is why we applied different policy on different network elements. Zzh3> The introduction section does clearly state the following: If a PE does advertise MSDP SA messages based on received MVPN SA routes, the VPN-specific MSDP sessions are no longer needed. Zzh3> I added "with other PEs": If a PE does advertise MSDP SA messages based on received MVPN SA routes, the VPN-specific MSDP sessions with other PEs are no longer needed. Zzh3> The policy difference is actually irrelevant here. 2. Clarify only one PE exist in the MSDP mesh group Zzh3> The "PE MSDP mesh group" actually includes all PEs that are either a C-RP or an MSDP peer. Please see below for further information. See comments marked with [Qin2] Zzh3> more responses below. -邮件原件- 发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2021年4月28日 3:18 收件人: Qin Wu ; Lenny Giuliano ; ops-...@ietf.org 抄送: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation....@ietf.org; last-c...@ietf.org 主题: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 Hi Qin, Please see zzh2> below for clarifications. -Original Message- From: Qin Wu Sent: Tuesday, April 27, 2021 2:38 AM To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano ; ops-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation....@ietf.org; last-c...@ietf.org Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Hi, Jeffrey: -邮件原件- 发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2021年4月27日 4:35 收件人: Qin Wu ; Lenny Giuliano ; ops-...@ietf.org 抄送: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation....@ietf.org; last-c...@ietf.org 主题: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 Hi Qin, Thank you for your review and comments. Let me share a diff to see if it addresses the issues, before I post a revision. Please see zzh> below. -Original Message- From: Qin Wu via Datatracker Sent: Friday, April 23, 2021 11:20 AM To: ops-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org Subject: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Reviewer: Qin Wu Review result: Ready Reviewer: Qin Wu Review result: Ready with nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how to convey the RP address information into the MVPN Source Active route using an Extended Community so this information can be shared with an existing MSDP infrastructure. It provides an update to RFC6514. Major issues: None Minor issues: I am wondering how MVPN and MSDP SA Interoperation is back compatible with existing source discovery information dissemination methods? Is there any downside to make MVPN SA and MSDP SA work together. Zzh> There is no downside. The RFC6514 specified MSDP SA -> MVPN SA but is missing the other direction (MVPN SA -> MSDP SA), which causes lots of headache. This document is to add the missing part, as explained in introduction section. Zzh> The only backwards compatibility issue is with a scenario further explained at the end of this message - where PE2 is a legacy PE that does not attach the EC. [Qin]: Thank for clarification, I am little bit worried about this, with the magic policy control, we can solve all the backward compatibility issues,:-) Zzh2> Well at this time we don't foresee other issues [Qin2]:How about "rpt-spt" mode which is beyond scope of this document. I don't investigate this. Zzh3> Because it is out of scope, it is irrelevant
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
Thanks Jeffrey for clarification, I have better understanding on your document. I suggest to add clarity to the text from two perspectives: 1. Highlight the assumption difference between mechanism proposed in RFC6514 and one proposed in this draft, e.g., in this draft, it doesn't require MSDP session to be established between PEs while RFC6514 allows this, that is why we applied different policy on different network elements. 2. Clarify only one PE exist in the MSDP mesh group See comments marked with [Qin2] -邮件原件- 发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2021年4月28日 3:18 收件人: Qin Wu ; Lenny Giuliano ; ops-...@ietf.org 抄送: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org 主题: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 Hi Qin, Please see zzh2> below for clarifications. -Original Message- From: Qin Wu Sent: Tuesday, April 27, 2021 2:38 AM To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano ; ops-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Hi, Jeffrey: -邮件原件- 发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2021年4月27日 4:35 收件人: Qin Wu ; Lenny Giuliano ; ops-...@ietf.org 抄送: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org 主题: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 Hi Qin, Thank you for your review and comments. Let me share a diff to see if it addresses the issues, before I post a revision. Please see zzh> below. -Original Message- From: Qin Wu via Datatracker Sent: Friday, April 23, 2021 11:20 AM To: ops-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org Subject: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Reviewer: Qin Wu Review result: Ready Reviewer: Qin Wu Review result: Ready with nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how to convey the RP address information into the MVPN Source Active route using an Extended Community so this information can be shared with an existing MSDP infrastructure. It provides an update to RFC6514. Major issues: None Minor issues: I am wondering how MVPN and MSDP SA Interoperation is back compatible with existing source discovery information dissemination methods? Is there any downside to make MVPN SA and MSDP SA work together. Zzh> There is no downside. The RFC6514 specified MSDP SA -> MVPN SA but is missing the other direction (MVPN SA -> MSDP SA), which causes lots of headache. This document is to add the missing part, as explained in introduction section. Zzh> The only backwards compatibility issue is with a scenario further explained at the end of this message - where PE2 is a legacy PE that does not attach the EC. [Qin]: Thank for clarification, I am little bit worried about this, with the magic policy control, we can solve all the backward compatibility issues,:-) Zzh2> Well at this time we don't foresee other issues [Qin2]:How about "rpt-spt" mode which is beyond scope of this document. I don't investigate this. Section 1: Suggest to add term for GTM, RPT, C-Multicast Zzh> Added. Section 3 When we say MVPN Pes that have one or more MSDP session in a VPN, does this statement contradict with “VPN-specific MSDP sessions are not required among the PEs”? zzh> The MSDP session that the PEs have are with other non-PE MSDP speakers but not among themselves, so it does not contradict with that quoted text. [Qin]:Without your clarification, I feel MVPN PEs will only establish MSDP session with other PEs in a VPN, rather than non-PE MSDP speakers? Can you add text to make this clear? Zzh2> Section 1 does say the following: ... One or more of the PEs, say PE1, either act as a C-RP and learn of (C-S,C-G) via PIM Register messages, or have MSDP sessions with some MSDP peers and < learn (C-S,C-G) via MSDP SA messages... [Qin2]: without your clarification or familiar with the context of RFC6514, I will believe MSDP can be either PE2 or non PE elements. [RFC6514] only specifies that a PE receiving the MVPN SA routes, say PE2, will advertise (C-S,C-G) C-multicast routes if it has correspondi
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
Hi Qin, Please see zzh2> below for clarifications. -Original Message- From: Qin Wu Sent: Tuesday, April 27, 2021 2:38 AM To: Jeffrey (Zhaohui) Zhang ; Lenny Giuliano ; ops-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org Subject: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Hi, Jeffrey: -邮件原件- 发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2021年4月27日 4:35 收件人: Qin Wu ; Lenny Giuliano ; ops-...@ietf.org 抄送: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org 主题: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 Hi Qin, Thank you for your review and comments. Let me share a diff to see if it addresses the issues, before I post a revision. Please see zzh> below. -Original Message- From: Qin Wu via Datatracker Sent: Friday, April 23, 2021 11:20 AM To: ops-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org Subject: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Reviewer: Qin Wu Review result: Ready Reviewer: Qin Wu Review result: Ready with nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how to convey the RP address information into the MVPN Source Active route using an Extended Community so this information can be shared with an existing MSDP infrastructure. It provides an update to RFC6514. Major issues: None Minor issues: I am wondering how MVPN and MSDP SA Interoperation is back compatible with existing source discovery information dissemination methods? Is there any downside to make MVPN SA and MSDP SA work together. Zzh> There is no downside. The RFC6514 specified MSDP SA -> MVPN SA but is missing the other direction (MVPN SA -> MSDP SA), which causes lots of headache. This document is to add the missing part, as explained in introduction section. Zzh> The only backwards compatibility issue is with a scenario further explained at the end of this message - where PE2 is a legacy PE that does not attach the EC. [Qin]: Thank for clarification, I am little bit worried about this, with the magic policy control, we can solve all the backward compatibility issues,:-) Zzh2> Well at this time we don't foresee other issues Section 1: Suggest to add term for GTM, RPT, C-Multicast Zzh> Added. Section 3 When we say MVPN Pes that have one or more MSDP session in a VPN, does this statement contradict with “VPN-specific MSDP sessions are not required among the PEs”? zzh> The MSDP session that the PEs have are with other non-PE MSDP speakers but not among themselves, so it does not contradict with that quoted text. [Qin]:Without your clarification, I feel MVPN PEs will only establish MSDP session with other PEs in a VPN, rather than non-PE MSDP speakers? Can you add text to make this clear? Zzh2> Section 1 does say the following: ... One or more of the PEs, say PE1, either act as a C-RP and learn of (C-S,C-G) via PIM Register messages, or have MSDP sessions with some MSDP peers and < learn (C-S,C-G) via MSDP SA messages... [RFC6514] only specifies that a PE receiving the MVPN SA routes, say PE2, will advertise (C-S,C-G) C-multicast routes if it has corresponding (C-*,C-G) state learnt from its CE. PE2 may also have MSDP sessions with other C-RPs at its site, < Zzh2> MVPN PEs establishing MSDP sessions with other non-PE devices is a common practice in RFC6514, so we should not need to call it again. Section 3 What do you mean other MSDP speaker? Do we assume there is one or only one MSDP speaker in the MSDP mesh group? How MSDP speaker is different from MSDP peer? Do you mean there is no session to be established between MSDP peer? Zzh> MSDP sessions are established among MSDP speakers/peers. The text here means that the MVPN PEs that are running MSDP (with sessions to other non-PEs) form a mesh group and that group does not include other MSDP peers that are not PEs. [Qin]:Confused, the first half sentence said the MSDP session is established between PE and non-PEs, the second half sentence said the group does not include non-PE as MSDP peers? Are you saying in the second half sentence that the group only include other MSDP peers that are not PEs?
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
Hi, Jeffrey: -邮件原件- 发件人: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] 发送时间: 2021年4月27日 4:35 收件人: Qin Wu ; Lenny Giuliano ; ops-...@ietf.org 抄送: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org 主题: RE: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 Hi Qin, Thank you for your review and comments. Let me share a diff to see if it addresses the issues, before I post a revision. Please see zzh> below. -Original Message- From: Qin Wu via Datatracker Sent: Friday, April 23, 2021 11:20 AM To: ops-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org Subject: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Reviewer: Qin Wu Review result: Ready Reviewer: Qin Wu Review result: Ready with nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how to convey the RP address information into the MVPN Source Active route using an Extended Community so this information can be shared with an existing MSDP infrastructure. It provides an update to RFC6514. Major issues: None Minor issues: I am wondering how MVPN and MSDP SA Interoperation is back compatible with existing source discovery information dissemination methods? Is there any downside to make MVPN SA and MSDP SA work together. Zzh> There is no downside. The RFC6514 specified MSDP SA -> MVPN SA but is missing the other direction (MVPN SA -> MSDP SA), which causes lots of headache. This document is to add the missing part, as explained in introduction section. Zzh> The only backwards compatibility issue is with a scenario further explained at the end of this message - where PE2 is a legacy PE that does not attach the EC. [Qin]: Thank for clarification, I am little bit worried about this, with the magic policy control, we can solve all the backward compatibility issues,:-) Section 1: Suggest to add term for GTM, RPT, C-Multicast Zzh> Added. Section 3 When we say MVPN Pes that have one or more MSDP session in a VPN, does this statement contradict with “VPN-specific MSDP sessions are not required among the PEs”? zzh> The MSDP session that the PEs have are with other non-PE MSDP speakers but not among themselves, so it does not contradict with that quoted text. [Qin]:Without your clarification, I feel MVPN PEs will only establish MSDP session with other PEs in a VPN, rather than non-PE MSDP speakers? Can you add text to make this clear? Section 3 What do you mean other MSDP speaker? Do we assume there is one or only one MSDP speaker in the MSDP mesh group? How MSDP speaker is different from MSDP peer? Do you mean there is no session to be established between MSDP peer? Zzh> MSDP sessions are established among MSDP speakers/peers. The text here means that the MVPN PEs that are running MSDP (with sessions to other non-PEs) form a mesh group and that group does not include other MSDP peers that are not PEs. [Qin]:Confused, the first half sentence said the MSDP session is established between PE and non-PEs, the second half sentence said the group does not include non-PE as MSDP peers? Are you saying in the second half sentence that the group only include other MSDP peers that are not PEs? Section 3, last paragraph: When we say ” In that case, if the selected best MVPN SA route does not have the "MVPN SA RP-address EC" but another route for the same (C-S, C-G) does, then the best route with the EC SHOULD be chosen.”, which best route is selected? Selected best MVPN SA route without EC or normal route with the EC? It looks you assume the normal route with the EC is the best selected route as well in this context? Zzh> The BGP selected best route may not have the EC. In that case, for MSDP interop purpose, the next best route with the EC should be used. [Qin]: Understood, thanks for clarification. Section 3 Can you provide an example of fine grained policy control? Is this related to local policy? “accepted MSDP SA message when receiving PE’s RP for the C-G is MSDP peer to which the generated MSDP message is advertised” Zzh> Yes I changed it to local policy. We probably don't need examples here - just whatever MSDP policies that can be used in an MSDP deployment. Zzh> The quoted text is part of the following description: a receiving PE1 receives an SA route from another PE2 who does not attach the EC, so PE1 uses its own local RP address
Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
Hi Qin, Thank you for your review and comments. Let me share a diff to see if it addresses the issues, before I post a revision. Please see zzh> below. -Original Message- From: Qin Wu via Datatracker Sent: Friday, April 23, 2021 11:20 AM To: ops-...@ietf.org Cc: bess@ietf.org; draft-ietf-bess-mvpn-msdp-sa-interoperation@ietf.org; last-c...@ietf.org Subject: Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05 [External Email. Be cautious of content] Reviewer: Qin Wu Review result: Ready Reviewer: Qin Wu Review result: Ready with nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how to convey the RP address information into the MVPN Source Active route using an Extended Community so this information can be shared with an existing MSDP infrastructure. It provides an update to RFC6514. Major issues: None Minor issues: I am wondering how MVPN and MSDP SA Interoperation is back compatible with existing source discovery information dissemination methods? Is there any downside to make MVPN SA and MSDP SA work together. Zzh> There is no downside. The RFC6514 specified MSDP SA -> MVPN SA but is missing the other direction (MVPN SA -> MSDP SA), which causes lots of headache. This document is to add the missing part, as explained in introduction section. Zzh> The only backwards compatibility issue is with a scenario further explained at the end of this message - where PE2 is a legacy PE that does not attach the EC. Section 1: Suggest to add term for GTM, RPT, C-Multicast Zzh> Added. Section 3 When we say MVPN Pes that have one or more MSDP session in a VPN, does this statement contradict with “VPN-specific MSDP sessions are not required among the PEs”? zzh> The MSDP session that the PEs have are with other non-PE MSDP speakers but not among themselves, so it does not contradict with that quoted text. Section 3 What do you mean other MSDP speaker? Do we assume there is one or only one MSDP speaker in the MSDP mesh group? How MSDP speaker is different from MSDP peer? Do you mean there is no session to be established between MSDP peer? Zzh> MSDP sessions are established among MSDP speakers/peers. The text here means that the MVPN PEs that are running MSDP (with sessions to other non-PEs) form a mesh group and that group does not include other MSDP peers that are not PEs. Section 3, last paragraph: When we say ” In that case, if the selected best MVPN SA route does not have the "MVPN SA RP-address EC" but another route for the same (C-S, C-G) does, then the best route with the EC SHOULD be chosen.”, which best route is selected? Selected best MVPN SA route without EC or normal route with the EC? It looks you assume the normal route with the EC is the best selected route as well in this context? Zzh> The BGP selected best route may not have the EC. In that case, for MSDP interop purpose, the next best route with the EC should be used. Section 3 Can you provide an example of fine grained policy control? Is this related to local policy? “accepted MSDP SA message when receiving PE’s RP for the C-G is MSDP peer to which the generated MSDP message is advertised” Zzh> Yes I changed it to local policy. We probably don't need examples here - just whatever MSDP policies that can be used in an MSDP deployment. Zzh> The quoted text is part of the following description: a receiving PE1 receives an SA route from another PE2 who does not attach the EC, so PE1 uses its own local RP address (say R1) to construct that MSDP SA message and advertise to its peer. If that peer happens to be R1, the peer will reject it because PE1 used R1 in constructing the message. To prevent this rejection, R1 should configure MSDP policy to accept the message. Zzh> Thanks! Zzh> Jeffrey Juniper Business Use Only <<< text/html; name="Diff_ draft-ietf-bess-mvpn-sa-to-msdp.txt - draft-ietf-bess-mvpn-msdp-sa-interoperation-05.txt.html": Unrecognized >>> ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
