Subject: [bess] WG Last Call, IPR and Implementation poll for draft-ietf-bess-mvpn-msdp-sa-interoperation-03

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Tue, 10 Sep 2019 14:26:16 +0000

Hello Working Group,

This email starts a two week Working Group Last Call on draft-ietf-bess-mvpn-msdp-sa-interoperation-03 [1].

This poll runs until 25 September 2019.

We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an Author or a Contributor of this document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors.

There are currently no IPR disclosures against the document.

If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

We are also polling for any existing implementation as per [2].

    Thank you,

    Matthew and Stephane

    [1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interoperation/

    [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 13 Sep 2019 12:07:15 -0700

Not aware of any IPR related to draft-ietf-bess-mvpn-msdp-sa-interoperation

On Tue, 10 Sep 2019, Bocci, Matthew (Nokia - GB) wrote:

| 
| Hello Working Group,
| 
|     
| 
| This email starts a two week Working Group Last Call on draft-ietf-bess-mvpn-msdp-sa-interoperation-03 [1]. 
| 
|  
| 
| This poll runs until 25 September 2019.
| 
|  
| 
| We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and
| 5378 for more details).
| 
|  
| 
| If you are listed as an Author or a Contributor of this document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't
| progress without answers from all the Authors and Contributors.
| 
|  
| 
| There are currently no IPR disclosures against the document.
| 
|  
| 
| If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.
| 
|  
| 
| We are also polling for any existing implementation as per [2].
| 
|     
| 
|     Thank you,
| 
|     Matthew and Stephane
| 
|  
| 
|     [1] https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interoperation/
| 
|     [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
| 
|  
| 
|  
| 
| 
|

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 23 Sep 2019 18:37:12 +0000

Not aware of any relevant IPR.

Juniper has an implementation.

Jeffrey

-----Original Message-----
From: Lenny Giuliano <[email-masked]> 
Sent: Friday, September 13, 2019 3:07 PM
To: Bocci, Matthew (Nokia - GB) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [bess] WG Last Call, IPR and Implementation poll for draft-ietf-bess-mvpn-msdp-sa-interoperation-03

| 
| Hello Working Group,
| 
|     
| 
| This email starts a two week Working Group Last Call on 
| draft-ietf-bess-mvpn-msdp-sa-interoperation-03 [1].
| 
|  
| 
| This poll runs until 25 September 2019.
| 
|  
| 
| We are also polling for knowledge of any undisclosed IPR that applies 
| to this Document, to ensure that IPR has been disclosed in compliance 
| with IETF IPR rules (see RFCs 3979, 4879, 3669 and
| 5378 for more details).
| 
|  
| 
| If you are listed as an Author or a Contributor of this document 
| please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors.
| 
|  
| 
| There are currently no IPR disclosures against the document.
| 
|  
| 
| If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.
| 
|  
| 
| We are also polling for any existing implementation as per [2].
| 
|     
| 
|     Thank you,
| 
|     Matthew and Stephane
| 
|  
| 
|     [1] 
| https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interope
| ration/
| 
|     [2] 
| https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
| 
|  
| 
|  
| 
| 
|

---

From: Stig Venaas <[email-masked]>
Date: Mon, 23 Sep 2019 13:50:30 -0700

Hi

I support publication of this document, but there are a few minor
editorial issues that needs to be addressed.

Section 2.1 has minor issues:

   For comparison, another method of supporting customer ASM is
   generally referred to "rpt-spt" mode.  Section "13.  Switching from a
                      ^^^^
referred to as

   Shared C-Tree to a Source C-Tree" of [RFC6514] specifies the MVPN SA
   procedures for that mode, but those SA routes are replacement for
                                                   ^^^
are a replacement
   PIM-ASM assert and (s,g,rpt) prune mechanisms, not for source
   discovery purpose.  MVPN/MSDP SA interoperation for the "rpt-spt"
             ^^^^^^^^^
purposes?

   mode is outside of the scope of this document.  In the rest of the
   document, the "spt-only" mode is assumed.

In section 3:
of the document, it is referred to as the PE mesh group.  It MUST not
                                                           ^^^^^^^^^^
This is not allowed, should be "MUST NOT".

In section 3:
   In addition to procedures in [RFC6514], an MVPN PE may be provisioned
   to generate MSDP SA messages from received MVPN SA routes, with or
   without fine policy control.  If a received MVPN SA route is to

I'm not sure what is meant by "fine policy control" here. Is that one
may have policy for specific SAs? Should it be "fine grained"?

Section 5:
"IANA Assignment" should be "IANA Considerations".

Regards,
Stig

On Tue, Sep 10, 2019 at 7:26 AM Bocci, Matthew (Nokia - GB)
<[email-masked]> wrote:
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

---

From: Vinod N Kumar <[email-masked]>
Date: Tue, 24 Sep 2019 04:07:06 +0000

Not aware of any IPR related to mvpn-msdp-sa-interoperation.
Juniper has an implementation of this draft.

Regards,
Vinod Kumar.

On 24/09/19, 12:07 AM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" <[email-masked] on behalf of zzhang=[email-masked]> wrote:

    
    Jeffrey
    
    -----Original Message-----
    From: Lenny Giuliano <[email-masked]> 
    Sent: Friday, September 13, 2019 3:07 PM
    To: Bocci, Matthew (Nokia - GB) <[email-masked]>
    Cc: [email-masked]; [email-masked]
    Subject: Re: [bess] WG Last Call, IPR and Implementation poll for draft-ietf-bess-mvpn-msdp-sa-interoperation-03

    
    | 
    | Hello Working Group,
    | 
    |     
    | 
    | https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interope__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZR3Kw5Qb$ 
    | ration/
    | 
    |     [2] 
    | https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZekFkSyU$ 
    | 
    |  
    | 
    |  
    | 
    | 
    | 
    
    _______________________________________________
    BESS mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZR5oAE0v$

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 27 Sep 2019 21:41:22 -0400

As a technical representative of Verizon from an operator and network designer perspective I support the draft as it stands and don’t know of any non disclosed IPRs.

I have a few questions.

So I agree this draft is very useful and fills a gap or problem where customers using ASM do not have a local RP and their shared tree needs to traverse the core.

I think for most customers it’s easy to change their location of their ASM anycast RP so it’s local at every edge and then build your msdp mesh group between all your CE edges and boom “no shared trees” over the mpls core MVPN.

From reading the draft it sounds like the Msdp SA is detected and mapped to the mvpn for the shared tree to get built.

So if your shared tree terminates locally at the edge CE and the edge see is running msdp then you would never have a shared tree. ^*,G that would traverse the core.

If their is an msdp session tcp/639 am not sure I understand how that would be detected also that is RP control plane and not the data plane forwarding.  Also how are you going to do SPT switchover and from shared to SPT tree.  Also then I guess you would need to provide option for RP  infinity to stay permanently on the shared tree.

Regards,

Gyan S. Mishra
IT Network Engineering & Technology 
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

Sent from my iPhone

> On Sep 24, 2019, at 12:07 AM, Vinod N Kumar <vinkumar=[email-masked]> wrote:
>

---

From: Vinod N Kumar <[email-masked]>
Date: Sat, 28 Sep 2019 07:31:50 +0000

Procedures described in this Draft are applicable to Section "14. Supporting PIM-SM without Inter-Site Shared C-Trees" of RFC6514 i.e MVPN operating in SPT-only Mode.

In MVPN SPT-only mode , MVPN Source Active route (MVPN Type-5 route) is functionally similar to MSDP Source Active message.

The Draft defines procedures to translate MVPN Source Active route (MVPN Type-5 route) to MSDP Source Active message.

Procedures defined are to facilitate building SPT (Source Tree) not shared tree.

Snippet from Section 2.1 of Draft.

Section "13. Switching from a Shared C-Tree to a Source C-Tree" of [RFC6514] specifies the MVPN Source Active route procedures for that mode, but those MVPN SA routes (Type-5 routes) are replacement for PIM-ASM assert and (s,g,rpt) prune mechanisms, not for source discovery purpose.

MVPN/MSDP SA interoperation for the "rpt-spt" mode is outside of the scope of this document. In the rest of the document, the "spt-only" mode is assumed.

Regards,
Vinod Kumar.

From: BESS <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Saturday, 28 September 2019 at 7:11 AM
To: Vinod N Kumar <vinkumar=[email-masked]>
Cc: "Bocci, Matthew (Nokia - GB)" <[email-masked]>, "[email-masked]" <[email-masked]>, Lenny Giuliano <[email-masked]>, "[email-masked]" <[email-masked]>, "Jeffrey (Zhaohui) Zhang" <zzhang=[email-masked]>
Subject: Re: [bess] WG Last Call, IPR and Implementation poll for draft-ietf-bess-mvpn-msdp-sa-interoperation-03

I have a few questions.

Regards,

Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904<x-apple-data-detectors://3/0>
United States<x-apple-data-detectors://3/0>
Phone: 301 502-1347<tel:301%20502-1347>
Email: [email-masked]<mailto:[email-masked]>
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT<https://urldefense.com/v3/__http:/www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT__;!8WoA6RjC81c!R-Artm4_BH690XpxiqYhdAAbHY4bIPD9i8S_C6ZDn4hHE6LlPAewrMVT12UjUHXi$>

Sent from my iPhone

On Sep 24, 2019, at 12:07 AM, Vinod N Kumar <vinkumar=[email-masked]<mailto:vinkumar=[email-masked]>> wrote:
Not aware of any IPR related to mvpn-msdp-sa-interoperation.
Juniper has an implementation of this draft.

Regards,
Vinod Kumar.

On 24/09/19, 12:07 AM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" <[email-masked]<mailto:[email-masked]> on behalf of zzhang=[email-masked]<mailto:zzhang=[email-masked]>> wrote:

   Jeffrey

   -----Original Message-----
   From: Lenny Giuliano <[email-masked]<mailto:[email-masked]>>
   Sent: Friday, September 13, 2019 3:07 PM
   To: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
   Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
   Subject: Re: [bess] WG Last Call, IPR and Implementation poll for draft-ietf-bess-mvpn-msdp-sa-interoperation-03

   |
   | Hello Working Group,
   |
   |
   |
   | https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interope__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZR3Kw5Qb$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interope__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZR3Kw5Qb$>
   | ration/
   |
   |     [2]
   | https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZekFkSyU$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZekFkSyU$>
   |
   |
   |
   |
   |
   |
   |

   _______________________________________________
   BESS mailing list
   [email-masked]<mailto:[email-masked]>
   https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZR5oAE0v$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZR5oAE0v$>

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!8WoA6RjC81c!R-Artm4_BH690XpxiqYhdAAbHY4bIPD9i8S_C6ZDn4hHE6LlPAewrMVT10UBDSje$>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 28 Sep 2019 10:23:21 -0400

Hi Vinod

Thank you for your response and that makes sense that this is for SPT mode
only meaning the L3 VPN associated MVPN profile mLDP in band signalling
using BGP AD with pim c-signalling default MDT or default and data mdt
profiles with Type 1 and Type 3 route types and out of band mLDP w/ BGP AD
bgp c-signalling profiles with Type 1,3,6,7 route types the IGMP join
source register that triggers either the inband or out of band signalling
mvpn type 5 route translates the type 5 to msdp AS.

So since the shared tree in the SPT only scenario described in the draft
terminates on the edge CE the msdp mesh group between all the CEs that
propagate the SA to all msdp peersfor the RP control plane multicast inter
domain routing this new mvpn type 5 msdp sa is translated and intercepts
the msdp TCP session and inserts the SA into the SA message propagated to
the msdp peers in the mesh group.

Since the source register happens at the edge to the FHR and when a
receiver builds its shared tree at the CE edge domain once the ASM anycast
RP/msdp peering router receives the join the SA is triggered to be
propagated following the msdp peer rpf check rules for mesh group peers
which bypass the peer rpf check rules sbd non mesh group peers which follow
the peer rpf check rules and propagates the SA from the CE edge to all msdp
mesh and non mesh group peers within the L3 vpn.  So since msdp SA is by
design sits in the control plane separate from the LMDT (Labeled mulricast
distribution tree) data plane and so is propagated per MSDP peer RPF check
rules i am wondering what use case is this draft addressing whrere the msdp
SA is not propagated and requires assistance of this new mvpn type 5 route
translation to msdp sa.

Regards

Gyan

On Sat, Sep 28, 2019, 3:31 AM Vinod N Kumar <[email-masked]> wrote:

> Procedures described in this Draft are applicable to Section "14.
> Supporting PIM-SM without Inter-Site Shared C-Trees" of RFC6514 i.e MVPN
> operating in SPT-only Mode.
>
>
>
> In MVPN SPT-only mode , MVPN Source Active route (MVPN Type-5 route) is
> functionally similar to MSDP Source Active message.
>
> The Draft defines procedures to translate MVPN Source Active route (MVPN
> Type-5 route) to MSDP Source Active message.
>
> Section "13. Switching from a Shared C-Tree to a Source C-Tree" of
> [RFC6514] specifies the MVPN Source Active route procedures for that mode,
> but those MVPN SA routes (Type-5 routes) are replacement for PIM-ASM assert
> and (s,g,rpt) prune mechanisms, not for source discovery purpose.
>
> MVPN/MSDP SA interoperation for the "rpt-spt" mode is outside of the scope
> of this document. In the rest of the document, the "spt-only" mode is
> assumed.
>
>
>
>
>
> Regards,
>
> Vinod Kumar.
>
>
>
> *From: *BESS <[email-masked]> on behalf of Gyan Mishra <
> [email-masked]>
> *Date: *Saturday, 28 September 2019 at 7:11 AM
> *To: *Vinod N Kumar <vinkumar=[email-masked]>
> *Cc: *"Bocci, Matthew (Nokia - GB)" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, Lenny Giuliano <
> [email-masked]>, "[email-masked]" <[email-masked]>, "Jeffrey (Zhaohui)
> Zhang" <zzhang=[email-masked]>
> *Subject: *Re: [bess] WG Last Call, IPR and Implementation poll for
> draft-ietf-bess-mvpn-msdp-sa-interoperation-03
>
>
>
>
>
>
>
> As a technical representative of Verizon from an operator and network
> designer perspective I support the draft as it stands and don’t know of any
> non disclosed IPRs.
>
>
>
> I have a few questions.
>
>
>
> So I agree this draft is very useful and fills a gap or problem where
> customers using ASM do not have a local RP and their shared tree needs to
> traverse the core.
>
>
>
> I think for most customers it’s easy to change their location of their ASM
> anycast RP so it’s local at every edge and then build your msdp mesh group
> between all your CE edges and boom “no shared trees” over the mpls core
> MVPN.
>
>
>
> From reading the draft it sounds like the Msdp SA is detected and mapped
> to the mvpn for the shared tree to get built.
>
>
>
> So if your shared tree terminates locally at the edge CE and the edge see
> is running msdp then you would never have a shared tree. ^*,G that would
> traverse the core.
>
>
>
> If their is an msdp session tcp/639 am not sure I understand how that
> would be detected also that is RP control plane and not the data plane
> forwarding.  Also how are you going to do SPT switchover and from shared to
> SPT tree.  Also then I guess you would need to provide option for RP
>  infinity to stay permanently on the shared tree.
>
>
>
>
>
> Regards,
>
>
>
> Gyan S. Mishra
>
> <https://urldefense.com/v3/__http:/www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT__;!8WoA6RjC81c!R-Artm4_BH690XpxiqYhdAAbHY4bIPD9i8S_C6ZDn4hHE6LlPAewrMVT12UjUHXi$>
>
>
>
> Sent from my iPhone
>
>
> On Sep 24, 2019, at 12:07 AM, Vinod N Kumar <
> vinkumar=[email-masked]> wrote:
>
> On 24/09/19, 12:07 AM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" <
> [email-masked] on behalf of zzhang=[email-masked]>
> wrote:
>
>    Subject: Re: [bess] WG Last Call, IPR and Implementation poll for
> draft-ietf-bess-mvpn-msdp-sa-interoperation-03
>
>
>    Not aware of any IPR related to
> draft-ietf-bess-mvpn-msdp-sa-interoperation
>
>
>    | please respond to this email and indicate whether or not you are
> aware of any relevant undisclosed IPR. The Document won't progress without
> answers from all the Authors and Contributors.
>    |
>    |
>    |
>    | If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>    |
>    |
>    |
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interope__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZR3Kw5Qb$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-mvpn-msdp-sa-interope__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZR3Kw5Qb$>
>    | ration/
>    |
>    |     [2]
>    |
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZekFkSyU$
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZekFkSyU$>
>    |
>    |
>    |
>    |
>    |
>    |
>    |
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!8WoA6RjC81c!U8aCsuRpFMIP3TlcIw1_NuPboayld-LeUp2fk-4GbqPAhszKQS6xcSbHZR5oAE0v$>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!8WoA6RjC81c!R-Artm4_BH690XpxiqYhdAAbHY4bIPD9i8S_C6ZDn4hHE6LlPAewrMVT10UBDSje$>
>
>

---

From: Vinod N Kumar <[email-masked]>
Date: Mon, 30 Sep 2019 07:43:24 +0000

Hi Gyan,

Please find response inline,

Thank you for your response and that makes sense that this is for SPT mode only meaning the L3 VPN associated MVPN profile mLDP in band signalling using BGP AD with pim c-signalling default MDT or default and data mdt profiles with Type 1 and Type 3 route types and out of band mLDP w/ BGP AD bgp c-signalling profiles with Type 1,3,6,7 route types the IGMP join source register that triggers either the inband or out of band signalling mvpn type 5 route translates the type 5 to msdp AS.

<Vinod> Solution described in Draft is Control Plane Only. It is about relaying (advertising) information of Active Multicast Source to C-sites (Customer sites) via MVPN TYPE-5 to MSDP SA translation. Draft is applicable to NG-MVPN operating in SPT-only , this mode of MVPN would not build Shared Tree (RPT) across VPN Core. NG-MVPN operating in SPT-only mode could make use

Of any P-Tunnel across VPN Core like RSVP-TE P2MP , Ingress Replication , mLDP (LDP-P2MP) , PIM-ASM (MDT) , PIM-SSM (MDT) for transporting multicast traffic across VPN Core. Solution described

In draft is agnostic to Provider Tunnel used in VPN Core & would work with any Provider Tunnel.

So since the shared tree in the SPT only scenario described in the draft terminates on the edge CE the msdp mesh group between all the CEs that propagate the SA to all msdp peersfor the RP control plane multicast inter domain routing this new mvpn type 5 msdp sa is translated and intercepts the msdp TCP session and inserts the SA into the SA message propagated to the msdp peers in the mesh group.

Since the source register happens at the edge to the FHR and when a receiver builds its shared tree at the CE edge domain once the ASM anycast RP/msdp peering router receives the join the SA is triggered to be propagated following the msdp peer rpf check rules for mesh group peers which bypass the peer rpf check rules sbd non mesh group peers which follow the peer rpf check rules and propagates the SA from the CE edge to all msdp mesh and non mesh group peers within the L3 vpn.  So since msdp SA is by design sits in the control plane separate from the LMDT (Labeled mulricast distribution tree) data plane and so is propagated per MSDP peer RPF check rules i am wondering what use case is this draft addressing whrere the msdp SA is not propagated and requires assistance of this new mvpn type 5 route translation to msdp sa.

<Vinod> Let me explain w.r.t below topology,

CE1,CE2,CE3 are C-sites. (Customer sites)

PE1,PE2,PE3 are Provider Edge devices for CE1,CE2,CE3 respectively.

Deployment you are talking about is Anycast C-RP deployed in each of C-sites (Customer site) i.e CE1,CE2,CE3 & MSDP mesh between these Anycast C-RPs.

MSDP mesh between CE1,CE2,CE3.

NG-MVPN SPT_only mode requires C-RP to be deployed in one of PE devices, if not then a MSDP Peering connecting CE device hosting C-RP to one of PE devices.

In above topology we have Anycast C-RP deployed on CE1,CE2,CE3 & MSDP Mesh between CE1,CE2,CE3.

With Solution described in Draft, we can avoid MSDP Peering (Overlay MSDP Peering) traversing VPN Core as below,

Enable MSDP Peering between CE1 to PE1.

Enable MSDP Peering between CE2 to PE2.

Enable MSDP Peering between CE3 to PE3.

Disable MSDP Peering between CE1,CE2,CE3. [ No MSDP Peering traversing VPN Core ].

MVPN TYPE-5 to MSDP SA translation feature described in Draft ensures that information about Active Multicast Sources is exchanged between all C-sites (Customer sites).

Let’s say S1 (Multicast Source) registers to Anycast C-RP on CE1.

MSDP between CE1-PE1, carries information of S1 to PE1. PE1 would flood information about S1 to all PEs (part of VPN) via MVPN Type-5 route.

Translation feature on PE2/PE3 would ensure MSDP SA is generated for S1 and would advertise to CE2/CE3.

Regards,

Vinod Kumar.

From: Gyan Mishra <[email-masked]>
Date: Saturday, 28 September 2019 at 7:53 PM
To: Vinod N Kumar <[email-masked]>
Cc: Vinod N Kumar <vinkumar=[email-masked]>, "Bocci, Matthew (Nokia - GB)" <[email-masked]>, "[email-masked]" <[email-masked]>, Lenny Giuliano <[email-masked]>, "[email-masked]" <[email-masked]>, "Jeffrey (Zhaohui) Zhang" <zzhang=[email-masked]>
Subject: Re: [bess] WG Last Call, IPR and Implementation poll for draft-ietf-bess-mvpn-msdp-sa-interoperation-03

Hi Vinod

Thank you for your response and that makes sense that this is for SPT mode only meaning the L3 VPN associated MVPN profile mLDP in band signalling using BGP AD with pim c-signalling default MDT or default and data mdt profiles with Type 1 and Type 3 route types and out of band mLDP w/ BGP AD bgp c-signalling profiles with Type 1,3,6,7 route types the IGMP join source register that triggers either the inband or out of band signalling mvpn type 5 route translates the type 5 to msdp AS.

So since the shared tree in the SPT only scenario described in the draft terminates on the edge CE the msdp mesh group between all the CEs that propagate the SA to all msdp peersfor the RP control plane multicast inter domain routing this new mvpn type 5 msdp sa is translated and intercepts the msdp TCP session and inserts the SA into the SA message propagated to the msdp peers in the mesh group.

Since the source register happens at the edge to the FHR and when a receiver builds its shared tree at the CE edge domain once the ASM anycast RP/msdp peering router receives the join the SA is triggered to be propagated following the msdp peer rpf check rules for mesh group peers which bypass the peer rpf check rules sbd non mesh group peers which follow the peer rpf check rules and propagates the SA from the CE edge to all msdp mesh and non mesh group peers within the L3 vpn.  So since msdp SA is by design sits in the control plane separate from the LMDT (Labeled mulricast distribution tree) data plane and so is propagated per MSDP peer RPF check rules i am wondering what use case is this draft addressing whrere the msdp SA is not propagated and requires assistance of this new mvpn type 5 route translation to msdp sa.

Regards

Gyan

On Sat, Sep 28, 2019, 3:31 AM Vinod N Kumar <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Vinod Kumar.

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Saturday, 28 September 2019 at 7:11 AM
To: Vinod N Kumar <vinkumar=[email-masked]<mailto:[email-masked]>>
Cc: "Bocci, Matthew (Nokia - GB)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Lenny Giuliano <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Jeffrey (Zhaohui) Zhang" <zzhang=[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] WG Last Call, IPR and Implementation poll for draft-ietf-bess-mvpn-msdp-sa-interoperation-03

I have a few questions.

Regards,

Gyan S. Mishra

Sent from my iPhone

Regards,
Vinod Kumar.

   Jeffrey

   -----Original Message-----
   From: Lenny Giuliano <[email-masked]<mailto:[email-masked]>>
   Sent: Friday, September 13, 2019 3:07 PM
   To: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
   Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
   Subject: Re: [bess] WG Last Call, IPR and Implementation poll for draft-ietf-bess-mvpn-msdp-sa-interoperation-03

   |
   | Hello Working Group,
   |
   |
   |

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 30 Sep 2019 21:09:24 -0400

Response in-line

Thank you for your detailed response 

Sent from my iPhone

> On Sep 30, 2019, at 3:43 AM, Vinod N Kumar <[email-masked]> wrote:
> 
> Hi Gyan,
>  
 [Gyan] In the draft I think having this example helps tremendously to visually understand the use case as the SP is providing a value added service so the customer does not have to perform  MSDP peering between its CEs and maybe in some cases where the customer had multiple administrative scopes this I can see would be very useful value added service which is the gap filled by this feature.  Without this feature if the administrative domain is contained by the same customer performing full mesh msdp peering between in a customer VPN is a non technical issue so other then having different administrative scope for the CEs within the same VPN what other problem is this feature solving from a management as well ad technical standpoint.

Gyan