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

[Gyan Mishra <[e-mail]>]

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=
[e-mail]> wrote:

> Hi Qin,
>
>
>
> Thank you so much for the review and comments. I have posted -06 revision.
>
>
>
> Jeffrey
>
>
>
> *From:* Qin Wu <[e-mail]>
> *Sent:* Friday, April 30, 2021 11:59 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Lenny Giuliano <
> [e-mail]>; ops-dir <[e-mail]>
> *Cc:* bess <[e-mail]>;
> draft-ietf-bess-mvpn-msdp-sa-interoperation.all <
> [e-mail]>; last-call <
> [e-mail]>
> *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<[e-mail]>
>
> *收件人：* Qin Wu<[e-mail]>;Lenny Giuliano<[e-mail]
> >;ops-dir<[e-mail]>
>
> *抄送：* bess<[e-mail]>;draft-ietf-bess-mvpn-msdp-sa-interoperation.all<
> [e-mail]>;last-call<
> [e-mail]>
>
> *主题：* 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 <[e-mail]>
> *Sent:* Friday, April 30, 2021 10:21 AM
> *To:* Jeffrey (Zhaohui) Zhang <[e-mail]>; Lenny Giuliano <
> [e-mail]>; [e-mail]
> *Cc:* [e-mail];
> [e-mail];
> [e-mail]
> *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:[e-mail]
> <[e-mail]>]
> *发送时间:* 2021年4月30日 22:05
> *收件人:* Qin Wu <[e-mail]>; Lenny Giuliano <[e-mail]>;
> [e-mail]
> *抄送:* [e-mail];
> [e-mail];
> [e-mail]
> *主题:* 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 <[e-mail]>
> Sent: Friday, April 30, 2021 9:43 AM
> To: Jeffrey (Zhaohui) Zhang <[e-mail]>; Lenny Giuliano <
> [e-mail]>; [e-mail]
> Cc: [e-mail];
> [e-mail];
> [e-mail]
> 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
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*