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

[Vinod N Kumar]

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.



 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.





 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 
Date: Saturday, 28 September 2019 at 7:53 PM
To: Vinod N Kumar 
Cc: Vinod N Kumar , "Bocci, Matthew 
(Nokia - GB)" , 
"draft-ietf-bess-mvpn-msdp-sa-interoperat...@ietf.org" 
, Lenny Giuliano 
, "bess@ietf.org" , "Jeffrey (Zhaohui) Zhang" 

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 contr

Re: [bess] Comments on draft-ietf-bess-evpn-pref-df

[Satya Mohanty (satyamoh)]

Hi Stephane,

An alternative way to guarantee precedence per vlan (i.e. the most granular) 
rather than the vlan-range in the vlan-based service models, could be by using 
the DF extcom in the per EVI AD route instead of the procedures in Section 4.2 
relevant to the vlan range.

But this may not be required in a real deployment and specification of 
precedence per a vlan-range is probably sufficient.

So, I agree with Jorge regarding his observation of vES.

Best,
--Satya

From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Sunday, September 29, 2019 at 4:10 AM
To: "slitkows.i...@gmail.com" , 
"draft-ietf-bess-evpn-pref...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: Comments on draft-ietf-bess-evpn-pref-df
Resent-From: 
Resent-To: , , 
, , "jdr...@juniper.net" 
, , 
Resent-Date: Sunday, September 29, 2019 at 4:09 AM

Hi Stephane,

Please see in-line.

If you think we should add some text making my comments below more explicit, 
I’d be happy to do it.
Thank you.
Jorge

From: "slitkows.i...@gmail.com" 
Date: Saturday, September 28, 2019 at 4:57 AM
To: "draft-ietf-bess-evpn-pref...@ietf.org" 
, "bess@ietf.org" 
Subject: Comments on draft-ietf-bess-evpn-pref-df
Resent-From: 
Resent-To: , , 
, , , 
, 
Resent-Date: Saturday, September 28, 2019 at 4:57 AM

Hi Authors,

I had a look on your draft and I have some concerns/questions that I would like 
to discuss.
I like the fact of being able to tune the pref DF election per VLAN range, 
however:

-  Don’t you think that using a local configuration may open to 
inconsistent configurations resulting in issues ?
[JORGE] We discussed quite a few times whether we should signal the vlan ranges 
for which you desire high_pref or low_pref. We ended up coming to the 
conclusion that it is better/simpler (and already supported) to define virtual 
ethernet segments for ranges of vlans and then have the default high_pref that 
is defined in the spec. That is less prone to errors. E.g. on a given port, 
define two ranges: vlan (1-2k) --> vES-1 and [(2k+1)-4k] -->vES-2. On a given 
PE, vES-1 and vES-2 have different pref values.


-  How does the high_or_low works if I have more than 2 links in the ES 
? (multihoming with 4 links with 4 levels of preference ?)
[JORGE] if you want 4 levels of preference so that each of the 4 PEs is DF for 
a range of vlans, the easiest way as discussed above is to define 4 vESes. The 
high_or_low is an easy way of having load balancing if you have only 2 PEs in 
the ES and you really want to define only one ES.

Thanks,

Stephane

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] WGLC / Adoption queue in Wiki

[Mankamana Mishra (mankamis)]

All,
Please check WGLC / Adoption call queue in Wiki. If some of the document 
missing, please Unicast me.  List have been updated based on email exchange & 
pervious meetings.

https://trac.ietf.org/trac/bess/wiki/WikiStart


Thanks
Mankamana

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] I-D Action: draft-ietf-bess-evpn-igmp-mld-proxy-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : IGMP and MLD Proxy for EVPN
Authors : Ali Sajassi
  Samir Thoria
  Keyur Patel
  John Drake
  Wen Lin
Filename: draft-ietf-bess-evpn-igmp-mld-proxy-04.txt
Pages   : 32
Date: 2019-09-30

Abstract:
   Ethernet Virtual Private Network (EVPN) solution is becoming
   pervasive in data center (DC) applications for Network Virtualization
   Overlay (NVO) and DC interconnect (DCI) services, and in service
   provider (SP) applications for next generation virtual private LAN
   services.

   This draft describes how to support efficiently endpoints running
   IGMP for the above services over an EVPN network by incorporating
   IGMP proxy procedures on EVPN PEs.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-04
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-igmp-mld-proxy-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-igmp-mld-proxy-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Mankamana Mishra (mankamis)]

Hi Gyan,
Is there any specific OS mVPN profile implementation you are looking for ?

Thanks
Mankamana


From: BESS  on behalf of Gyan Mishra 

Date: Saturday, September 28, 2019 at 8:59 AM
To: "bess@ietf.org" 
Subject: [bess] RFC or Draft that lists all standards track rfc’s of all mvpn 
profiles

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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Gyan Mishra]

Hi Mankamana

Let’s take this discussion off line from Bess.

Thank you 

Gyan

Sent from my iPhone

> On Sep 30, 2019, at 3:04 PM, Mankamana Mishra (mankamis)  
> wrote:
> 
> Hi Gyan,
> Is there any specific OS mVPN profile implementation you are looking for ?
>  
> Thanks
> Mankamana
>  
>  
> From: BESS  on behalf of Gyan Mishra 
> 
> Date: Saturday, September 28, 2019 at 8:59 AM
> To: "bess@ietf.org" 
> Subject: [bess] RFC or Draft that lists all standards track rfc’s of all mvpn 
> profiles
>  
> 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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] REG: https://datatracker.ietf.org/doc/draft-kishjac-bmwg-evpnvpwstest/

[Gyan Mishra]

Sent from my iPhone

> On Sep 29, 2019, at 11:44 PM, Sudhin Jacob  wrote:
> 
> Hi Gyan,
>  
> Thank you very much for the comments. I will get back in a day or two.
>  
> Regards,
> Sudhin

Thank you 

Gyan
>  
>  
> Juniper Business Use Only
> From: Gyan Mishra  
> Sent: Saturday, September 28, 2019 9:02 PM
> To: Sudhin Jacob 
> Cc: b...@ietf.org; bess@ietf.org
> Subject: Re: [bess] REG: 
> https://datatracker.ietf.org/doc/draft-kishjac-bmwg-evpnvpwstest/
>  
>  
>  
> 
> Which Juniper platform was the testing done on?
>  
> 
> Also in the drawing you have the RR / Core router.
>  
> Can you modify the drawing so it depicts a typical SP environment with 
> separate PE and P in the data plane LSP path and RR sitting separately 
> serving control plane function out of the data plane.
>  
> In the core mpls and this is pbb-evpn over mpls analogous to vxlan evpn in DC 
> space.
>  
> Is evpn-vpws Junipers version of Cisco pbb-evpn?
>  
> 
>  
>  
> 
> 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: gyan.s.mis...@verizon.com
> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
>  
> Sent from my iPhone
> 
> On Sep 21, 2019, at 9:04 AM, Sudhin Jacob 
>  wrote:
> 
> Dear All,
>  
> We have floated a draft for benchmarking EVPN-VPWS services. Kindly request 
> you to have a look on it. Please let us know your feedback.
>  
> https://datatracker.ietf.org/doc/draft-kishjac-bmwg-evpnvpwstest/
>  
> Regards,
> Sudhin
>  
>  
> 
> Juniper Business Use Only
>  
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf..org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Gyan Mishra]

Response in-line

Thank you for your detailed response 

Sent from my iPhone

> On Sep 30, 2019, at 3:43 AM, Vinod N Kumar  wrote:
> 
> 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.
>  
>  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.
>  
>  
>  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. 
>  
 [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
>  
>  
> Regards,
> Vinod Kumar.
>  
>  
> From: Gyan Mishra 
> Da

Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

[Khatri, Paresh (Nokia - AU/Brisbane)]

I support this draft.

Regards,
Paresh


From: BESS  on behalf of "stephane.litkow...@orange.com" 

Date: Tuesday, 3 September 2019 at 12:29 am
To: "bess@ietf.org" , 
"draft-snr-bess-evpn-loop-prot...@ietf.org" 

Cc: "bess-cha...@ietf.org" 
Subject: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Hi,

This email begins a two-weeks WG adoption poll for 
draft-snr-bess-evpn-loop-protect-04 [1]
Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this 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.

This poll for adoption closes on 16th September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-snr-bess-evpn-loop-protect/




[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Yes, Support adoption.

G/

From: BESS  On Behalf Of Stephane Litkowski
Sent: Thursday, September 19, 2019 16:06
To: stephane.litkow...@orange.com
Cc: draft-snr-bess-evpn-loop-prot...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Hi,

The poll has ended.
I haven't seen a lot of support from the various vendor while Jorge has 
mentioned that there are multiple implementations. Before closing definitely 
this poll, I would like to let the opportunity to other vendors to raise their 
voice and support the draft especially if they have implementations.
I will let an additional week.

Stephane


On Mon, Sep 2, 2019 at 4:29 PM 
mailto:stephane.litkow...@orange.com>> wrote:
Hi,

This email begins a two-weeks WG adoption poll for 
draft-snr-bess-evpn-loop-protect-04 [1]
Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this 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.

This poll for adoption closes on 16th September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-snr-bess-evpn-loop-protect/




[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Jeffrey (Zhaohui) Zhang]

Another way to look at different flavors/profiles of MVPN is to consider the 
following two aspects:


  1.  How are C-multicast state (customer (s,g)/(*,g) or mLDP FEC signaled on 
PC-CE interfaces) are signaled over provider core
  2.  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.

Jeffrey

From: BESS  On Behalf Of Gyan Mishra
Sent: Saturday, September 28, 2019 2:06 PM
To: Gyan Mishra ; bess@ietf.org
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 
mailto:hayabusa...@gmail.com>> 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
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] WG adoption poll and IPR poll for draft-snr-bess-evpn-loop-protect

[Henderickx, Wim (Nokia - BE/Antwerp)]

Support adoption,  as this is useful addition to EPVN

From: BESS  on behalf of Gunter VAN DE VELDE 

Date: Tuesday, 1 October 2019 at 04:59
To: Stephane Litkowski , Stephane Litkowski 

Cc: "draft-snr-bess-evpn-loop-prot...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Yes, Support adoption.

G/

From: BESS  On Behalf Of Stephane Litkowski
Sent: Thursday, September 19, 2019 16:06
To: stephane.litkow...@orange.com
Cc: draft-snr-bess-evpn-loop-prot...@ietf.org; bess-cha...@ietf.org; 
bess@ietf.org
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-snr-bess-evpn-loop-protect

Hi,

The poll has ended.
I haven't seen a lot of support from the various vendor while Jorge has 
mentioned that there are multiple implementations. Before closing definitely 
this poll, I would like to let the opportunity to other vendors to raise their 
voice and support the draft especially if they have implementations.
I will let an additional week.

Stephane


On Mon, Sep 2, 2019 at 4:29 PM 
mailto:stephane.litkow...@orange.com>> wrote:
Hi,

This email begins a two-weeks WG adoption poll for 
draft-snr-bess-evpn-loop-protect-04 [1]
Please review the draft and post any comments to the BESS working group list.

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, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this 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.

This poll for adoption closes on 16th September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-snr-bess-evpn-loop-protect/




[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] REG: https://datatracker.ietf.org/doc/draft-kishjac-bmwg-evpnvpwstest/

[Sudhin Jacob]

Hi Gyan,

Kindly find the answers inline. Appreciate your feedback.

Regards,
Sudhin


Juniper Business Use Only
From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Saturday, September 28, 2019 9:02 PM
To: Sudhin Jacob mailto:sja...@juniper.net>>
Cc: b...@ietf.org; bess@ietf.org
Subject: Re: [bess] REG: 
https://datatracker.ietf.org/doc/draft-kishjac-bmwg-evpnvpwstest/



Which Juniper platform was the testing done on?

Sudhin>>> This draft is for benchmarking EVPN-VPWS service, we are defining 
a set of parameters for the same. This can be done on any platforms which 
supports EVPN.

Also in the drawing you have the RR / Core router.

Can you modify the drawing so it depicts a typical SP environment with separate 
PE and P in the data plane LSP path and RR sitting separately serving control 
plane function out of the data plane.

Sudhin> sure we will work on it.

In the core mpls and this is pbb-evpn over mpls analogous to vxlan evpn in DC 
space.

Sudhin> This service is different, it is a point to point service like 
ELINE.

Is evpn-vpws Junipers version of Cisco pbb-evpn?

Sudhin No, PBB-EVPN is different. EVPN-VPWS is a point to point service as 
I mentioned above. In EVPN-VPWS service there is no mac learning.



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: gyan.s.mis...@verizon.com
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT

Sent from my iPhone

On Sep 21, 2019, at 9:04 AM, Sudhin Jacob 
mailto:sjacob=40juniper@dmarc.ietf.org>>
 wrote:
Dear All,

We have floated a draft for benchmarking EVPN-VPWS services. Kindly request you 
to have a look on it. Please let us know your feedback.

https://datatracker.ietf.org/doc/draft-kishjac-bmwg-evpnvpwstest/

Regards,
Sudhin



Juniper Business Use Only

___
BESS mailing list
BESS@ietf.org
https://www.ietf..org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess