Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 6 May 2021 19:25:58 +0000

Hi Qin,

Thank you so much for the review and comments. I have posted -06 revision.

Jeffrey

From: Qin Wu <[email-masked]>
Sent: Friday, April 30, 2021 11:59 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Lenny Giuliano <[email-masked]>; ops-dir <[email-masked]>
Cc: bess <[email-masked]>; draft-ietf-bess-mvpn-msdp-sa-interoperation.all <[email-masked]>; last-call <[email-masked]>
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<[email-masked]<mailto:[email-masked]>>
收件人： Qin Wu<[email-masked]<mailto:[email-masked]>>;Lenny Giuliano<[email-masked]<mailto:[email-masked]>>;ops-dir<[email-masked]<mailto:[email-masked]>>
抄送： bess<[email-masked]<mailto:[email-masked]>>;draft-ietf-bess-mvpn-msdp-sa-interoperation.all<[email-masked]<mailto:[email-masked]>>;last-call<[email-masked]<mailto:[email-masked]>>
主题： 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 <[email-masked]<mailto:[email-masked]>>
Sent: Friday, April 30, 2021 10:21 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Lenny Giuliano <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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:[email-masked]]
发送时间: 2021年4月30日 22:05
收件人: Qin Wu <[email-masked]<mailto:[email-masked]>>; Lenny Giuliano <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: 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 <[email-masked]<mailto:[email-masked]>>
Sent: Friday, April 30, 2021 9:43 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Lenny Giuliano <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 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?

Juniper Business Use Only

Juniper Business Use Only

Juniper Business Use Only

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 7 May 2021 12:55:08 -0400

Hi Jeffrey

I read the draft and saw your comments that RFC 6514 mentions MSDP on the
PE.

In what use case would SP have to run Anycast RP / MSDP on the PE when that
ASM control plane function can all be done on the CE.

I guess there maybe customers looking for value added service to have the
SP provide that function and in that case is where this draft would come
into play for SPT feature to make it work.

My understanding of the shared tree over MVPN using MVPN RFC 6513, 6514
procedures is as follows:

ASM

1. Egress receiver PE sends Type 6 shared tree (c-*,c-g)  is sent towards
the RP PE.

2. The join received by RP behind PE triggers a type 7 source tree join
(c-s,c-g) towards the source ingress PE.

3.  Ingress PE sends Type-5 source active to trigger SPT switchover back to
the RP PE and all PEs on the S-PMSI selective tree.

4.  Egress receiver PEs now sends Type-7 (c-s,c-g) to the source PE

5.  Multicast stream now flows over the selective tree S-PMSI from Ingress
Source PE to all egress receiver PEs.

SSM

1. Egress receiver PEs now sends Type-7 (c-s,c-g) to the source PE

2.  Multicast stream now flows over the selective tree S-PMSI from Ingress
Source PE to all egress receiver PEs.

Kind Regards

Gyan

On Thu, May 6, 2021 at 3:27 PM Jeffrey (Zhaohui) Zhang <zzhang=
[email-masked]> wrote:

> *From:* Qin Wu <[email-masked]>
> *Sent:* Friday, April 30, 2021 11:59 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>; Lenny Giuliano <
> [email-masked]>; ops-dir <[email-masked]>
> *Cc:* bess <[email-masked]>;
> draft-ietf-bess-mvpn-msdp-sa-interoperation.all <
> [email-masked]>; last-call <
> [email-masked]>
> *Subject:* RE: Opsdir last call review of
> draft-ietf-bess-mvpn-msdp-sa-interoperation-05
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
> *发件人：* Jeffrey (Zhaohui) Zhang<[email-masked]>
>
> *收件人：* Qin Wu<[email-masked]>;Lenny Giuliano<[email-masked]
> >;ops-dir<[email-masked]>
>
> *抄送：* bess<[email-masked]>;draft-ietf-bess-mvpn-msdp-sa-interoperation.all<
> [email-masked]>;last-call<
> [email-masked]>
>
> *主题：* RE: Opsdir last call review of
> draft-ietf-bess-mvpn-msdp-sa-interoperation-05
>
> *时间：* 2021-04-30 23:04:49
>
>
>
> Hi Qin,
>
>
>
> 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 <[email-masked]>
> *Sent:* Friday, April 30, 2021 10:21 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>; Lenny Giuliano <
> [email-masked]>; [email-masked]
> *Cc:* [email-masked];
> [email-masked];
> [email-masked]
> *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:[email-masked]
> <[email-masked]>]
> *发送时间:* 2021年4月30日 22:05
> *收件人:* Qin Wu <[email-masked]>; Lenny Giuliano <[email-masked]>;
> [email-masked]
> *抄送:* [email-masked];
> [email-masked];
> [email-masked]
> *主题:* RE: Opsdir last call review of
> draft-ietf-bess-mvpn-msdp-sa-interoperation-05
>
>
>
> Hi Qin,
>
>
>
> 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.
>
>
>
> Are you saying VPN-specific MSDP session between PEs are not needed? Or
> sometimes need while sometimes not needed?
>
>
>
> Thanks.
>
> Jeffrey
>
>
>
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Lenny Giuliano <
> [email-masked]>; [email-masked]
> Cc: [email-masked];
> [email-masked];
> [email-masked]
> Subject: RE: Opsdir last call review of
> draft-ietf-bess-mvpn-msdp-sa-interoperation-05
>
>
>
> 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?
>
>
>
> [Qin2]: without your clarification or familiar with the context of
> RFC6514, I will believe MSDP can be either PE2 or non PE elements.
>
>
>
> 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:
>
> "
>
> 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> 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
>
>
>
> 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".
>
> "
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 10 May 2021 13:52:59 +0000

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 <[email-masked]>
Sent: Friday, May 7, 2021 12:55 PM
To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
Cc: Lenny Giuliano <[email-masked]>; Qin Wu <[email-masked]>; bess <[email-masked]>; draft-ietf-bess-mvpn-msdp-sa-interoperation.all <[email-masked]>; last-call <[email-masked]>; ops-dir <[email-masked]>
Subject: Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05

Hi Jeffrey

ASM

SSM

Kind Regards

Gyan

On Thu, May 6, 2021 at 3:27 PM Jeffrey (Zhaohui) Zhang <zzhang=
[email-masked]> wrote:

> Hi Qin,
>
>
>
> Thank you so much for the review and comments. I have posted -06 revision

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 11 May 2021 11:08:11 -0400

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 <[email-masked]>
wrote:

> 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
>
> Cc: Lenny Giuliano <[email-masked]>; Qin Wu <[email-masked]>; bess
> <[email-masked]>; draft-ietf-bess-mvpn-msdp-sa-interoperation.all <
> [email-masked]>; ops-dir <[email-masked]>
> Subject: Re: [bess] Opsdir last call review of
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 11 May 2021 11:46:47 -0700

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 <[email-masked]> 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 <[email-masked]>
|       Sent: Friday, May 7, 2021 12:55 PM
|       To: Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]>
|       Cc: Lenny Giuliano <[email-masked]>; Qin Wu <[email-masked]>; bess <[email-masked]>; draft-ietf-bess-mvpn-msdp-sa-interoperation.all
|       <[email-masked]>; last-call <[email-masked]>; ops-dir <[email-masked]>
|       Subject: Re: [bess] Opsdir last call review of draft-ietf-bess-mvpn-msdp-sa-interoperation-05
| 
|       [External Email. Be cautious of content]
| 
| 
|       Hi Jeffrey
| 
|       I read the draft and saw your comments that RFC 6514 mentions MSDP on the
|       PE.
| 
|       In what use case would SP have to run Anycast RP / MSDP on the PE when that
|       ASM control plane function can all be done on the CE.
| 
|       I guess there maybe customers looking for value added service to have the
|       SP provide that function and in that case is where this draft would come
|       into play for SPT feature to make it work.
| 
|       My understanding of the shared tree over MVPN using MVPN RFC 6513, 6514
|       procedures is as follows:
| 
|       ASM
| 
|       1. Egress receiver PE sends Type 6 shared tree (c-*,c-g)  is sent towards
|       the RP PE.
| 
|       2. The join received by RP behind PE triggers a type 7 source tree join
|       (c-s,c-g) towards the source ingress PE.
| 
|       3.  Ingress PE sends Type-5 source active to trigger SPT switchover back to
|       the RP PE and all PEs on the S-PMSI selective tree.
| 
|       4.  Egress receiver PEs now sends Type-7 (c-s,c-g) to the source PE
| 
|       5.  Multicast stream now flows over the selective tree S-PMSI from Ingress
|       Source PE to all egress receiver PEs.
| 
|       SSM
| 
|       1. Egress receiver PEs now sends Type-7 (c-s,c-g) to the source PE
| 
|       2.  Multicast stream now flows over the selective tree S-PMSI from Ingress
|       Source PE to all egress receiver PEs.
| 
| 
| 
|       Kind Regards
| 
| 
|       Gyan
| 
|       On Thu, May 6, 2021 at 3:27 PM Jeffrey (Zhaohui) Zhang <zzhang=
|       [email-masked]> 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 [email-masked]
| 
| M 301 502-1347
| 
| 
| 
|

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 11 May 2021 19:00:07 -0400

Thanks Leonard that answers my questions.

Kind Regards

Gyan
On Tue, May 11, 2021 at 2:40 PM Leonard Giuliano <[email-masked]> wrote:

> | So Section 14 is a case of C-Multicast PIM ASM and non inter site
> 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
> | 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
> | 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
> |  The MVPN SA cache state is not necessarily per MVPN and that would be
> 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
> |
> |       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
> |       That has one missing feature when the customer also has its own
> MSDP infrastructure to distribute source information among its MSDP
> speakers, and
> |       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
> |
> |       Cc: Lenny Giuliano <[email-masked]>; Qin Wu <[email-masked]>;
> bess <[email-masked]>; draft-ietf-bess-mvpn-msdp-sa-interoperation.all
> |       <[email-masked]>;
> last-call <[email-masked]>; ops-dir <[email-masked]>
> |       Subject: Re: [bess] Opsdir last call review of
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 11 May 2021 22:46:52 -0400

Hi Jeffrey

I am all set with the draft technical Q&A as this draft fills an important
gap for operators, I believe is in excellent shape ready for publication.

Thank you

Gyan

On Tue, May 11, 2021 at 11:08 AM Gyan Mishra <[email-masked]> wrote:

> On Mon, May 10, 2021 at 9:53 AM Jeffrey (Zhaohui) Zhang <
> [email-masked]> wrote:
>
>> Hi Gyan,
>>
>> Cc: Lenny Giuliano <[email-masked]>; Qin Wu <[email-masked]>;
>> bess <[email-masked]>; draft-ietf-bess-mvpn-msdp-sa-interoperation.all <

-- 

*Gyan Mishra*

*M 301 502-1347*