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 protected]> on behalf of Gyan Mishra 
<[email protected]>
Date: Saturday, 28 September 2019 at 7:11 AM
To: Vinod N Kumar <[email protected]>
Cc: "Bocci, Matthew (Nokia - GB)" <[email protected]>, 
"[email protected]" 
<[email protected]>, Lenny Giuliano 
<[email protected]>, "[email protected]" <[email protected]>, "Jeffrey (Zhaohui) Zhang" 
<[email protected]>
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
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 protected]<mailto:[email protected]>
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 
<[email protected]<mailto:[email protected]>>
 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 protected]<mailto:[email protected]> on behalf of 
[email protected]<mailto:[email protected]>>
 wrote:

   Not aware of any relevant IPR.

   Juniper has an implementation.

   Jeffrey

   -----Original Message-----
   From: Lenny Giuliano <[email protected]<mailto:[email protected]>>
   Sent: Friday, September 13, 2019 3:07 PM
   To: Bocci, Matthew (Nokia - GB) 
<[email protected]<mailto:[email protected]>>
   Cc: [email protected]<mailto:[email protected]>; 
[email protected]<mailto:[email protected]>
   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


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

Reply via email to