date:20190313

Re: [bess] A short question on draft-ietf-bess-evpn-yang-07

2019-03-13 Thread Alexander Vainshtein

Patrice,
Unfortunately I will not be attending the IETF meeting in Prague.
But I can be reached via Skype (sasha.vainshtein) if you want to discuss things.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Patrice Brissette (pbrisset) 
Sent: Wednesday, March 13, 2019 11:27 PM
To: Alexander Vainshtein ; Yu Tianpeng 

Cc: draft-ietf-bess-evpn-y...@ietf.org; bess@ietf.org; Michael Gorokhovsky 
; Yechiel Rosengarten 
; Ron Sdayoor 
Subject: Re: A short question on draft-ietf-bess-evpn-yang-07

Guys,

Thanks a lot for your comments. We will have a sit down in Prague to discuss 
them.
Ping me if you will be around.

Regards,
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these 
forms: Segment 
Routing / 
EVPN

http://e-vpn.io, http://go2.cisco.com/evpn




From: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>
Date: Wednesday, March 13, 2019 at 04:05
To: Yu Tianpeng mailto:yutianpeng.i...@gmail.com>>
Cc: 
"draft-ietf-bess-evpn-y...@ietf.org" 
mailto:draft-ietf-bess-evpn-y...@ietf.org>>,
 "bess@ietf.org" mailto:bess@ietf.org>>, 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>, 
Yechiel Rosengarten 
mailto:yechiel.rosengar...@ecitele.com>>, Ron 
Sdayoor mailto:ron.sday...@ecitele.com>>
Subject: RE: A short question on draft-ietf-bess-evpn-yang-07
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Patrice Brissette mailto:pbris...@cisco.com>>, 
mailto:hs...@ciena.com>>, 
mailto:ihuss...@infinera.com>>, 
mailto:kisho...@juniper.net>>, 
mailto:jorge.raba...@nokia.com>>
Resent-Date: Wednesday, March 13, 2019 at 04:05

Tim,
Lots of thanks for a prompt response.
I have indeed missed the ingress-replication  and p2mp-replication leaves at 
the top of the EVPN YANG tree. But I do not see how it helps to answer my 
original questions (in addition to being misplaced as you have noticed).

Seems we are in sync with regard to this issue.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com

From: Yu Tianpeng mailto:yutianpeng.i...@gmail.com>>
Sent: Wednesday, March 13, 2019 9:52 AM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>
Cc: 
draft-ietf-bess-evpn-y...@ietf.org; 
bess@ietf.org; Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Yechiel Rosengarten 
mailto:yechiel.rosengar...@ecitele.com>>; Ron 
Sdayoor mailto:ron.sday...@ecitele.com>>
Subject: Re: A short question on draft-ietf-bess-evpn-yang-07

Hi Sasha,
If you read the beginning of even yang, it has a common leaf which indicating 
it is IR or P2MP. But it is globally not per EVI.
So actually I also have a comment here I may forgot to mention in previous 
email is that this common leaf should be per EVI basis not globally.
If this info should be included in route leaf, the common leaf actually can be 
deleted I believe.
So basically I support what you said.

Hi author,
Thanks for the new version which fixes  a lot.
But I still have some concerns on the current version.
I will try put major ones down later.

Here just quick query on the usage of counter32 in statistics, isn't it very 
likely to get full in short time?  If you check interface-yang it always use 
counter64. If I calculate correctly, with 1mbps traffic counter32 will rotate 
in about 1 hour. Or I miss sth?

Thanks in advance.
Regards
Tim


On Wed, 13 Mar 2019, 06:47 Alexander Vainshtein, 
mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Hi all,
I am now reading the draft, and I see that it is a substantial improvement over 
the earlier versions.

At the same time I have a question regarding the definition of Type 3 
(Inclusive Multicast Ethernet Tag) EVPN route in this (and previous) versions.

The YANG definition of this route  runs as following:

 list inclusive-multicast-ethernet-tag-route {
   uses route-rd-rt-grp;
   leaf originator-ip-prefix {
 type inet:ip-prefix;
 description "originator-ip-prefix";
   }
   list path {
 uses next-hop-label-grp;
 uses path-detail-grp;
 description "path";
   }
   description "inclusive-multicast-ethernet-tag-route";


This definition matches the definition of the NRLI of this route in Section 7.3 
of RFC 7432. But it seems to miss the requirement (stated in Section 11.2 of 
RFC 7432) that this route MUST carry an PMSI Tunnel Type Attribute (a.k.a. PTA) 
as defined in RFC 6514.

The draft also defines a Boolean attribute underlay-multicast of an EVPN 
ins

Re: [bess] A short question on draft-ietf-bess-evpn-yang-07

2019-03-13 Thread Patrice Brissette (pbrisset)

Guys,

Thanks a lot for your comments. We will have a sit down in Prague to discuss 
them.
Ping me if you will be around.

Regards,
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these 
forms: Segment 
Routing / 
EVPN

http://e-vpn.io, http://go2.cisco.com/evpn




From: Alexander Vainshtein 
Date: Wednesday, March 13, 2019 at 04:05
To: Yu Tianpeng 
Cc: "draft-ietf-bess-evpn-y...@ietf.org" , 
"bess@ietf.org" , Michael Gorokhovsky 
, Yechiel Rosengarten 
, Ron Sdayoor 
Subject: RE: A short question on draft-ietf-bess-evpn-yang-07
Resent-From: 
Resent-To: Patrice Brissette , , 
, , 
Resent-Date: Wednesday, March 13, 2019 at 04:05

Tim,
Lots of thanks for a prompt response.
I have indeed missed the ingress-replication  and p2mp-replication leaves at 
the top of the EVPN YANG tree. But I do not see how it helps to answer my 
original questions (in addition to being misplaced as you have noticed).

Seems we are in sync with regard to this issue.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Yu Tianpeng 
Sent: Wednesday, March 13, 2019 9:52 AM
To: Alexander Vainshtein 
Cc: draft-ietf-bess-evpn-y...@ietf.org; bess@ietf.org; Michael Gorokhovsky 
; Yechiel Rosengarten 
; Ron Sdayoor 
Subject: Re: A short question on draft-ietf-bess-evpn-yang-07

Hi Sasha,
If you read the beginning of even yang, it has a common leaf which indicating 
it is IR or P2MP. But it is globally not per EVI.
So actually I also have a comment here I may forgot to mention in previous 
email is that this common leaf should be per EVI basis not globally.
If this info should be included in route leaf, the common leaf actually can be 
deleted I believe.
So basically I support what you said.

Hi author,
Thanks for the new version which fixes  a lot.
But I still have some concerns on the current version.
I will try put major ones down later.

Here just quick query on the usage of counter32 in statistics, isn't it very 
likely to get full in short time?  If you check interface-yang it always use 
counter64. If I calculate correctly, with 1mbps traffic counter32 will rotate 
in about 1 hour. Or I miss sth?

Thanks in advance.
Regards
Tim


On Wed, 13 Mar 2019, 06:47 Alexander Vainshtein, 
mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Hi all,
I am now reading the draft, and I see that it is a substantial improvement over 
the earlier versions.

At the same time I have a question regarding the definition of Type 3 
(Inclusive Multicast Ethernet Tag) EVPN route in this (and previous) versions.

The YANG definition of this route  runs as following:

 list inclusive-multicast-ethernet-tag-route {
   uses route-rd-rt-grp;
   leaf originator-ip-prefix {
 type inet:ip-prefix;
 description "originator-ip-prefix";
   }
   list path {
 uses next-hop-label-grp;
 uses path-detail-grp;
 description "path";
   }
   description "inclusive-multicast-ethernet-tag-route";


This definition matches the definition of the NRLI of this route in Section 7.3 
of RFC 7432. But it seems to miss the requirement (stated in Section 11.2 of 
RFC 7432) that this route MUST carry an PMSI Tunnel Type Attribute (a.k.a. PTA) 
as defined in RFC 6514.

The draft also defines a Boolean attribute underlay-multicast of an EVPN 
instance, but it does not explain what this means and how it is used. My guess 
)FWIW) is that this attribute differentiates between EVPN instances that use 
ingress replication and EVPN instances that use P2MP LSPs to deliver BUM 
traffic. But it does not help to identify specific  technology used for setting 
up P2MP LSPs, and does not allow the user to see the labels advertised in the 
PTA.

Did I miss something substantial here?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com

-Original Message-
From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
internet-dra...@ietf.org
Sent: Monday, March 11, 2019 9:21 PM
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-evpn-yang-07.txt


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   : Yang Data Model for EVPN
Authors : Patrice Brissette
  Himanshu Shah
  Iftekar Hussain
  Kishore Tiruveedhula
  Jorg

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

2019-03-13 Thread Jeffrey (Zhaohui) Zhang

Sorry for the delay. Will take care of it this week.

Thanks.
Jeffrey

> -Original Message-
> From: Mankamana Mishra (mankamis) 
> Sent: Tuesday, March 12, 2019 12:15 PM
> To: Jeffrey (Zhaohui) Zhang 
> Cc: Greg Mirsky ; bess-cha...@ietf.org; EXT -
> thomas.mo...@orange.com ; Robert Kebler
> ; bess@ietf.org; ext-zhang.zh...@zte.com.cn
> 
> Subject: Re: [bess] WGLC,IPR and implementation poll for draft-ietf-bess-
> mvpn-fast-failover
> 
> Hi Jeffery,
> wondering if you got chance to updated text & if you are fine with it.
> 
> Mankamana
> 
> > On Feb 13, 2019, at 7:09 PM, zhang.zh...@zte.com.cn wrote:
> >
> > Hi Greg,
> >
> > Thank you very much for your clarification!
> > I made a mistake that I thought the BFD session is the base solution for UMH
> failover.
> > Now I get it. Thank you!
> > BTW: In section 3.1.2, "draft-ietf-rtgwg-bgp-pic-08" may be mentioned as
> another example like MPLS FRR.
> >
> > Thanks,
> > Sandy
> > --原始邮件--
> > 发件人：GregMirsky 
> > 收件人：张征7940;
> > 抄送人：zzh...@juniper.net ;bess-cha...@ietf.org
> ;Thomas Morin ;Robert
> Kebler ;BESS ;
> > 日 期 ：2019年02月14日 10:38
> > 主 题 ：Re: [bess] WGLC,IPR and implementation poll for draft-ietf-bess-
> mvpn-fast-failover
> > Hi Sandy,
> > thank you for your kind consideration of the proposed updates. I've logged
> my answers under GIM3>> tag.
> >
> > Regards,
> > Greg
> >
> > On Mon, Feb 11, 2019 at 11:44 PM  wrote:
> > Hi Greg,
> > Thank you for your good modification and clarification!
> > About two sections I still have some comments, I copy the contents here
> because the mail is too long:
> > 1,
> > 3. I am confused with section 3.1.1/3.1.2/3.1.3. IMO only the X-PMSI 
> > tunnel's
> state influence the BFD session, there is no need for other decision.
> > GIM2>> The Upstream PE as MultipointHead of the p2mp BFD session may
> use a combination of conditions (the combination being determined by policy)
> to control the state of the BFD session, e.g., set it to AdminDown. I think 
> that
> the use of policy to control the conditions that affect the P-tunnel reception
> state is the advantage of the proposed solution. What do you think?
> > 4. For section 3.1.5, IMO the counter method has no relationship with the
> BFD function defined in this document. If the counter method will be used as a
> supplement for BFD session?
> > GIM2>> As above, this is one of the conditions, controlled by the policy, 
> > that
> may be considered to influence the state of the BFD session.
> > Sandy2> Since BFD packet is forwarding through by x-PMSI tunnel, egress PE
> can get the tunnel states by BFD detection timer expiration. So administrator
> may choose different policies to control the session state, but the bfd 
> packets
> detection should be the base. IMO section 3.1.1~4 are optional.
> > GIM3>> I re-read the 3.1 and I think now better understand the original 
> > idea.
> All methods listed in sub-sections, including the one that describes use of
> p2mp BFD, are alternatives, options to detect a failure in the tunnel. Would
> the following update be helpful:
> > OLD TEXT:
> > The procedure proposed here also allows that all downstream PEs don't
> > apply the same rules to define what the status of a P-tunnel is
> > (please see Section 6), and some of them will produce a result that
> > may be different for different downstream PEs.
> > NEW TEXT:
> > The optional procedures proposed in this section also allow that all
> downstream PEs don't
> > apply the same rules to define what the status of a P-tunnel is
> > (please see Section 6), and some of them will produce a result that
> > may be different for different downstream PEs.
> >
> > For section 3.1.5 counter information, how do the configurable timer work
> with the bfd detection timer? What should egress PE do with the expiration of
> the two timers when they are both used?
> > GIM3>> MPLS FRR is mentioned in the draft as an example of the "fast
> restoration mechanism". Likely, FRR will be enabled by single-hop p2p BFD per
> protected link. If that's the case, for the scenario described in this 
> sub-section,
> p2mp BFD is unnecessary.
> >
> > 2.
> > For section 3.1.7.1, the last sentence.
> > GIM2>> I think that Jeffrey asked why the new BFD Discriminator must be
> sent and the new p2mp BFD session must be initiated. Your question, as I
> interpret it, is to how operationally an implementation can minimize the
> disruption when the new BFD session advertised to replace one that already
> exists. Firstly, would we agree that sending the new BGP-BFD Discriminator
> and starting the new p2mp BFD session when the RPF interface changes is the
> right action? If we agree, then I can add a sentence or two to describe 
> optional
> procedure for the upstream PE to minimize the disruption when the egress PE
> switches to the new p2mp BFD session.
> > Sandy2>If the "old" BFD discriminator can be reused in the new
> advertisement when the switchover is happened on a same

Re: [bess] A short question on draft-ietf-bess-evpn-yang-07

2019-03-13 Thread Alexander Vainshtein

Tim,
Lots of thanks for a prompt response.
I have indeed missed the ingress-replication  and p2mp-replication leaves at 
the top of the EVPN YANG tree. But I do not see how it helps to answer my 
original questions (in addition to being misplaced as you have noticed).

Seems we are in sync with regard to this issue.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Yu Tianpeng 
Sent: Wednesday, March 13, 2019 9:52 AM
To: Alexander Vainshtein 
Cc: draft-ietf-bess-evpn-y...@ietf.org; bess@ietf.org; Michael Gorokhovsky 
; Yechiel Rosengarten 
; Ron Sdayoor 
Subject: Re: A short question on draft-ietf-bess-evpn-yang-07

Hi Sasha,
If you read the beginning of even yang, it has a common leaf which indicating 
it is IR or P2MP. But it is globally not per EVI.
So actually I also have a comment here I may forgot to mention in previous 
email is that this common leaf should be per EVI basis not globally.
If this info should be included in route leaf, the common leaf actually can be 
deleted I believe.
So basically I support what you said.

Hi author,
Thanks for the new version which fixes  a lot.
But I still have some concerns on the current version.
I will try put major ones down later.

Here just quick query on the usage of counter32 in statistics, isn't it very 
likely to get full in short time?  If you check interface-yang it always use 
counter64. If I calculate correctly, with 1mbps traffic counter32 will rotate 
in about 1 hour. Or I miss sth?

Thanks in advance.
Regards
Tim


On Wed, 13 Mar 2019, 06:47 Alexander Vainshtein, 
mailto:alexander.vainsht...@ecitele.com>> 
wrote:
Hi all,
I am now reading the draft, and I see that it is a substantial improvement over 
the earlier versions.

At the same time I have a question regarding the definition of Type 3 
(Inclusive Multicast Ethernet Tag) EVPN route in this (and previous) versions.

The YANG definition of this route  runs as following:

 list inclusive-multicast-ethernet-tag-route {
   uses route-rd-rt-grp;
   leaf originator-ip-prefix {
 type inet:ip-prefix;
 description "originator-ip-prefix";
   }
   list path {
 uses next-hop-label-grp;
 uses path-detail-grp;
 description "path";
   }
   description "inclusive-multicast-ethernet-tag-route";


This definition matches the definition of the NRLI of this route in Section 7.3 
of RFC 7432. But it seems to miss the requirement (stated in Section 11.2 of 
RFC 7432) that this route MUST carry an PMSI Tunnel Type Attribute (a.k.a. PTA) 
as defined in RFC 6514.

The draft also defines a Boolean attribute underlay-multicast of an EVPN 
instance, but it does not explain what this means and how it is used. My guess 
)FWIW) is that this attribute differentiates between EVPN instances that use 
ingress replication and EVPN instances that use P2MP LSPs to deliver BUM 
traffic. But it does not help to identify specific  technology used for setting 
up P2MP LSPs, and does not allow the user to see the labels advertised in the 
PTA.

Did I miss something substantial here?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com

-Original Message-
From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
internet-dra...@ietf.org
Sent: Monday, March 11, 2019 9:21 PM
To: i-d-annou...@ietf.org
Cc: bess@ietf.org
Subject: [bess] I-D Action: draft-ietf-bess-evpn-yang-07.txt


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   : Yang Data Model for EVPN
Authors : Patrice Brissette
  Himanshu Shah
  Iftekar Hussain
  Kishore Tiruveedhula
  Jorge Rabadan
Filename: draft-ietf-bess-evpn-yang-07.txt
Pages   : 28
Date: 2019-03-11

Abstract:
   This document describes a YANG data model for Ethernet VPN services.
   The model is agnostic of the underlay. It apply to MPLS as well as to
   VxLAN encapsulation. The model is also agnostic of the services
   including E-LAN, E-LINE and E-TREE services. This document mainly
   focuses on EVPN and Ethernet-Segment instance framework.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-yang-07
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-yang-07

A diff from the previous version is available at:
https://www.ietf.org/rf

Re: [bess] A short question on draft-ietf-bess-evpn-yang-07

2019-03-13 Thread Yu Tianpeng

Hi Sasha,
If you read the beginning of even yang, it has a common leaf which
indicating it is IR or P2MP. But it is globally not per EVI.
So actually I also have a comment here I may forgot to mention in previous
email is that this common leaf should be per EVI basis not globally.
If this info should be included in route leaf, the common leaf actually can
be deleted I believe.
So basically I support what you said.

Hi author,
Thanks for the new version which fixes  a lot.
But I still have some concerns on the current version.
I will try put major ones down later.

Here just quick query on the usage of counter32 in statistics, isn't it
very likely to get full in short time?  If you check interface-yang it
always use counter64. If I calculate correctly, with 1mbps traffic
counter32 will rotate in about 1 hour. Or I miss sth?

Thanks in advance.
Regards
Tim



On Wed, 13 Mar 2019, 06:47 Alexander Vainshtein, <
alexander.vainsht...@ecitele.com> wrote:

> Hi all,
> I am now reading the draft, and I see that it is a substantial improvement
> over the earlier versions.
>
> At the same time I have a question regarding the definition of Type 3
> (Inclusive Multicast Ethernet Tag) EVPN route in this (and previous)
> versions.
>
> The YANG definition of this route  runs as following:
> 
>  list inclusive-multicast-ethernet-tag-route {
>uses route-rd-rt-grp;
>leaf originator-ip-prefix {
>  type inet:ip-prefix;
>  description "originator-ip-prefix";
>}
>list path {
>  uses next-hop-label-grp;
>  uses path-detail-grp;
>  description "path";
>}
>description "inclusive-multicast-ethernet-tag-route";
> 
>
> This definition matches the definition of the NRLI of this route in
> Section 7.3 of RFC 7432. But it seems to miss the requirement (stated in
> Section 11.2 of RFC 7432) that this route MUST carry an PMSI Tunnel Type
> Attribute (a.k.a. PTA) as defined in RFC 6514.
>
> The draft also defines a Boolean attribute underlay-multicast of an EVPN
> instance, but it does not explain what this means and how it is used. My
> guess )FWIW) is that this attribute differentiates between EVPN instances
> that use ingress replication and EVPN instances that use P2MP LSPs to
> deliver BUM traffic. But it does not help to identify specific  technology
> used for setting up P2MP LSPs, and does not allow the user to see the
> labels advertised in the PTA.
>
> Did I miss something substantial here?
>
> Regards, and lots of thanks in advance,
> Sasha
>
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
>
> -Original Message-
> From: BESS  On Behalf Of internet-dra...@ietf.org
> Sent: Monday, March 11, 2019 9:21 PM
> To: i-d-annou...@ietf.org
> Cc: bess@ietf.org
> Subject: [bess] I-D Action: draft-ietf-bess-evpn-yang-07.txt
>
>
> 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   : Yang Data Model for EVPN
> Authors : Patrice Brissette
>   Himanshu Shah
>   Iftekar Hussain
>   Kishore Tiruveedhula
>   Jorge Rabadan
> Filename: draft-ietf-bess-evpn-yang-07.txt
> Pages   : 28
> Date: 2019-03-11
>
> Abstract:
>This document describes a YANG data model for Ethernet VPN services.
>The model is agnostic of the underlay. It apply to MPLS as well as to
>VxLAN encapsulation. The model is also agnostic of the services
>including E-LAN, E-LINE and E-TREE services. This document mainly
>focuses on EVPN and Ethernet-Segment instance framework.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-yang/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-bess-evpn-yang-07
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-yang-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-yang-07
>
>
> 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
>
> ___
>
> This e-mail message is intended for the recipient only and contains
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
> received this
> transmission in error,

Re: [bess] A short question on draft-ietf-bess-evpn-yang-07

Re: [bess] A short question on draft-ietf-bess-evpn-yang-07

Re: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-mvpn-fast-failover

Re: [bess] A short question on draft-ietf-bess-evpn-yang-07

Re: [bess] A short question on draft-ietf-bess-evpn-yang-07

5 matches

Site Navigation

Mail list logo

Footer information