Re: [bess] RFC or Draft that lists all standards track rfc’s of all mvpn profiles

[Gyan Mishra <[e-mail]>]

In-line 

Sent from my iPhone

> On Oct 1, 2019, at 4:22 PM, Jeffrey (Zhaohui) Zhang <[e-mail]> wrote:
> 
> Hi Gyan,
>  
> No such RFC exists, because different customers have different preferences in both aspects; one flavor may be optimal for customer 1 but not desired for customer 2 😊
>  
[Gyan] Understood. Thanks Jeff 


> Jeffrey
>  
> From: Gyan Mishra <[e-mail]> 
> Sent: Tuesday, October 1, 2019 4:02 PM
> To: Jeffrey (Zhaohui) Zhang <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [bess] RFC or Draft that lists all standards track rfc’s of all mvpn profiles
>  
> Thanks Jeff for details response
>  
> In-line my response 
>  
> Sent from my iPhone
> 
> On Sep 30, 2019, at 11:01 PM, Jeffrey (Zhaohui) Zhang <[e-mail]> wrote:
> 
> Another way to look at different flavors/profiles of MVPN is to consider the following two aspects:
>  
> How are C-multicast state (customer (s,g)/(*,g) or mLDP FEC signaled on PC-CE interfaces) are signaled over provider core
> How are C-multicast traffic transported through the provider core
>  
> For #1, you have the choice of PIM (Rosen/PIM-MVPN and its later variants), BGP (BGP-MVPN), and mLDP (mLDP inband signaling).
> For #2, your provider tunnel choice can be PIM ASM/SSM, RSVP-TE/mLDP P2MP, Ingress Replication, BIER, … and more could be defined (e.g. SR P2MP).
>  
> The two aspects together will give you many combinations and they’re referred to as different “profiles” of MVPN by a certain vendor (😊) but I personally find it easier to look at those two aspects (e.g. “BGP-MVPN with mLDP tunnel”) 😊
>  
> BTW the same applies to EVPN BUM as well.
>  
> [Gyan] That is a good way to break it down from PE-CE c-tree c-signaling variations #1 and #2 Provider core p-tree transports PIM/Rosen or mLDP/P2MP TE providing either a-d shared default tree all PEs join Inclusive PMSI /aggregated or selective PMSI data tree constrained to specific ingress and egress source and receiver PEs.  
>  
> I wonder if an RFC exist that goes into detail of all the permutations that can exist for MVPN and even PBB EVPN multicast and maybe that may a gap that would be worthwhile effort to fill if one does not exist.  I think from a design perspective it would also help picking the optimal profile MVPN characteristics that meet the customer needs and also help with vendor interoperability.
>  
> 
> 
> Jeffrey
>  
> From: BESS <[e-mail]> On Behalf Of Gyan Mishra
> Sent: Saturday, September 28, 2019 2:06 PM
> To: Gyan Mishra <[e-mail]>; [e-mail]
> Subject: Re: [bess] RFC or Draft that lists all standards track rfc’s of all mvpn profiles
>  
>  
> I did some research and theseare the main RFCs for MVPN and how based they map to CISCO profiles and you do the same for Juniper and Huawei.
>  
> The 1st two are for mLDP w/ BGP-AD pim (in band) or bgp (out of band)c-signaling 
>  
> UI-PMSI (uni directional inclusive provider multicast service instance) Cisco Default MDT for PIM SM or SSM 
>  
> MI-PMSI (multi directional provider multicast service instance)  CISCO Default MDT for PIM SM or SSM
>  
> S-PMSI (Selective Provider multicast service instance) CISCO Data MDT for PIM SM or SSM
>  
> PIM dense mode MVPN  not supported - I don’t think anyone uses dense these days 
>  
> https://tools.ietf.org/html/rfc6513 MVPN
>  
> https://tools.ietf.org/html/rfc6514 MVPN
>  
>  
> https://tools.ietf.org/html/rfc6037. Rosen PIM GRE
>  
> https://tools.ietf.org/html/rfc4875 P2MP TE
> 
> Sent from my iPhone
> 
> On Sep 28, 2019, at 11:58 AM, Gyan Mishra <[e-mail]> wrote:
> 
> BESS WG / All
>  
> I am trying to find a list of all MVPN profiles that are supported by Cisco and Juniper and Huawei SP router vendors.
>  
> Below link shows what CISCO supports most of which I believe are a CISCO proprietary and non standard so won’t work between vendors.
>  
>  
> https://www.cisco.com/c/en/us/support/docs/ip/multicast/200512-Configure-mVPN-Profiles-within-Cisco-IOS.html
>  
> Thank you
>  
> Gyan Mishra 
> Verizon Communications 
> Cell 301 502-1347
> 
> Sent from my iPhone