Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Shah, Himanshu]

Works!!

Himanshu using iPad (so excuse the auto-corrects...)

From: Sami Boutros 
Sent: Wednesday, February 8, 2017 8:42:10 PM
To: Shah, Himanshu; Rabadan, Jorge (Nokia - US); Sami Boutros; Iftekhar Hussain
Cc: Jeffrey Zhang; Alvaro Retana (aretana); bess-cha...@ietf.org; 
bess@ietf.org; draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

How about this?


In multihoming single-active scenario, for a given VPWS service instance, in 
steady state, as result of DF election, the Primary elected PE for the VPWS 
service instance should signal P=1,B=0, the Backup elected PE should signal 
P=0,B=1, and the rest of the PEs in the same ES should signal P=0,B=0. When the 
primary PE/ES fails, the primary PE will withdraw the associated Ethernet A-D 
routes for the VPWS service instance from the remote PE, the remote PEs should 
then send traffic associated with the VPWS instance to the backup PE.

DF re-election will happen between the PE(s) in the same ES, and there will be 
a new elected primary PE and new elected backup PE that will signal the P and B 
bits as described. A remote PE SHOULD receive P=1 from only one Primary PE and 
a B-1 from only one Backup PE. However during transient situations, a remote PE 
receiving P=1 from more than one PE will select the last advertising PE as the 
primary PE when forwarding traffic. A remote PE receiving B=1 from more than 
one PE will select only one backup PE. A remote PE MUST receive P=1 from at 
least one PE before forwarding traffic.

Thanks,

Sami

From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 4:53 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, "Rabadan, 
Jorge (Nokia - US)" mailto:jorge.raba...@nokia.com>>, 
Sami Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

I recommend using Jorge’s text. That says, what originating multi-homed PEs 
should behave in single-active case.
That along with the text below (on how remote should behave) will help.

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Wednesday, February 08, 2017 7:46 PM
To: Shah, Himanshu mailto:hs...@ciena.com>>; Rabadan, Jorge 
(Nokia - US) mailto:jorge.raba...@nokia.com>>; Sami 
Boutros mailto:boutros.s...@gmail.com>>; Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org; 
bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Himanshu,

Will changing the text as below make it clear ?

In multihoming single-active scenario, for a given VPWS service instance, in 
steady state, a remote PE SHOULD receive P=1 from only one PE and a B-1 from 
only one PE. However during transient situations, a remote PE receiving P=1 
from more than one PE will select the last advertising PE as the primary PE 
when forwarding traffic. A remote PE receiving B=1 from more than one PE will 
select only one backup PE. A remote PE MUST receive P=1 from at least one PE 
before forwarding traffic.

Thanks,

Sami

From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 4:31 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, "Rabadan, 
Jorge (Nokia - US)" mailto:jorge.raba...@nokia.com>>, 
Sami Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

I strongly suggest that more clarifying text is added.
VPWS draft is introducing the Primary/backup extensions
and it is confusing what the exact behavior should be for
single-active multi-homing.

Even in case of transition, how multi-homed PEs behavior wrt
P/B when it would change from P to B and B to P and what remote
has accepted is not clear (what ‘last’ received at remote is
not assured at originating multi-homed PE members).

More I think about it, pref-def draft is increasingly playing

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

How about this?


In multihoming single-active scenario, for a given VPWS service instance, in 
steady state, as result of DF election, the Primary elected PE for the VPWS 
service instance should signal P=1,B=0, the Backup elected PE should signal 
P=0,B=1, and the rest of the PEs in the same ES should signal P=0,B=0. When the 
primary PE/ES fails, the primary PE will withdraw the associated Ethernet A-D 
routes for the VPWS service instance from the remote PE, the remote PEs should 
then send traffic associated with the VPWS instance to the backup PE.

DF re-election will happen between the PE(s) in the same ES, and there will be 
a new elected primary PE and new elected backup PE that will signal the P and B 
bits as described. A remote PE SHOULD receive P=1 from only one Primary PE and 
a B-1 from only one Backup PE. However during transient situations, a remote PE 
receiving P=1 from more than one PE will select the last advertising PE as the 
primary PE when forwarding traffic. A remote PE receiving B=1 from more than 
one PE will select only one backup PE. A remote PE MUST receive P=1 from at 
least one PE before forwarding traffic.

Thanks,

Sami

From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 4:53 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, "Rabadan, 
Jorge (Nokia - US)" mailto:jorge.raba...@nokia.com>>, 
Sami Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

I recommend using Jorge’s text. That says, what originating multi-homed PEs 
should behave in single-active case.
That along with the text below (on how remote should behave) will help.

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Wednesday, February 08, 2017 7:46 PM
To: Shah, Himanshu mailto:hs...@ciena.com>>; Rabadan, Jorge 
(Nokia - US) mailto:jorge.raba...@nokia.com>>; Sami 
Boutros mailto:boutros.s...@gmail.com>>; Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org; 
bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Himanshu,

Will changing the text as below make it clear ?

In multihoming single-active scenario, for a given VPWS service instance, in 
steady state, a remote PE SHOULD receive P=1 from only one PE and a B-1 from 
only one PE. However during transient situations, a remote PE receiving P=1 
from more than one PE will select the last advertising PE as the primary PE 
when forwarding traffic. A remote PE receiving B=1 from more than one PE will 
select only one backup PE. A remote PE MUST receive P=1 from at least one PE 
before forwarding traffic.

Thanks,

Sami

From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 4:31 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, "Rabadan, 
Jorge (Nokia - US)" mailto:jorge.raba...@nokia.com>>, 
Sami Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

I strongly suggest that more clarifying text is added.
VPWS draft is introducing the Primary/backup extensions
and it is confusing what the exact behavior should be for
single-active multi-homing.

Even in case of transition, how multi-homed PEs behavior wrt
P/B when it would change from P to B and B to P and what remote
has accepted is not clear (what ‘last’ received at remote is
not assured at originating multi-homed PE members).

More I think about it, pref-def draft is increasingly playing
important role for this to be clean.

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Wednesday, February 08, 2017 7:12 PM
To: Shah, Himanshu mailto:hs...@ciena.com>>; Rabadan, Jorge 
(Nokia - US) mailto:jorge.raba...@nokia.com>>; Sami 
Boutros mailto:boutros.s...@gmail.com>>; Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>; Alvaro 
Retana (areta

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Shah, Himanshu]

Hi Sami –

I recommend using Jorge’s text. That says, what originating multi-homed PEs 
should behave in single-active case.
That along with the text below (on how remote should behave) will help.

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Wednesday, February 08, 2017 7:46 PM
To: Shah, Himanshu ; Rabadan, Jorge (Nokia - US) 
; Sami Boutros ; Iftekhar 
Hussain 
Cc: Jeffrey Zhang ; Alvaro Retana (aretana) 
; bess-cha...@ietf.org; bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Himanshu,

Will changing the text as below make it clear ?

In multihoming single-active scenario, for a given VPWS service instance, in 
steady state, a remote PE SHOULD receive P=1 from only one PE and a B-1 from 
only one PE. However during transient situations, a remote PE receiving P=1 
from more than one PE will select the last advertising PE as the primary PE 
when forwarding traffic. A remote PE receiving B=1 from more than one PE will 
select only one backup PE. A remote PE MUST receive P=1 from at least one PE 
before forwarding traffic.

Thanks,

Sami

From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 4:31 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, "Rabadan, 
Jorge (Nokia - US)" mailto:jorge.raba...@nokia.com>>, 
Sami Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

I strongly suggest that more clarifying text is added.
VPWS draft is introducing the Primary/backup extensions
and it is confusing what the exact behavior should be for
single-active multi-homing.

Even in case of transition, how multi-homed PEs behavior wrt
P/B when it would change from P to B and B to P and what remote
has accepted is not clear (what ‘last’ received at remote is
not assured at originating multi-homed PE members).

More I think about it, pref-def draft is increasingly playing
important role for this to be clean.

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Wednesday, February 08, 2017 7:12 PM
To: Shah, Himanshu mailto:hs...@ciena.com>>; Rabadan, Jorge 
(Nokia - US) mailto:jorge.raba...@nokia.com>>; Sami 
Boutros mailto:boutros.s...@gmail.com>>; Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org; 
bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07



From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:54 PM
To: "Rabadan, Jorge (Nokia - US)" 
mailto:jorge.raba...@nokia.com>>, Sami Boutros 
mailto:sbout...@vmware.com>>, Sami Boutros 
mailto:boutros.s...@gmail.com>>, Iftekhar Hussain 
mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Ahh...This makes sense.

And NO it is not in the draft. Contrary, draft says that remote will accept 
only one as B=1 (may be to his liking..:-))

[Sami] This is correct,  we can receive more than one P=1 and on B=1 and the 
draft say this happen only in transit scenarios as in  the following text.. for 
a given EVPN-VPWS instance.

In multihoming single-active scenario, during transient situations, a remote PE 
receiving P=1 from more than one PE will select the last advertising PE as the 
primary PE when forwarding traffic. A remote PE receiving B=1 from more than 
one PE will select only one backup PE. A remote PE MUST receive P=1 from at 
least one PE before forwarding traffic.

Thanks,

Sami

What you say below needs to be explicitly included in the draft. Please..

Thanks,
Himanshu

From: Rabadan, Jorge (Nokia - US) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, February 08, 2017 6:47 PM
To: Sami Boutros mailto:sbout...@vmware.com>>; Shah, 
Himanshu mailto:hs...@ciena.com>>; Sami Boutros 
mailto:boutros.s...@gmail.com>>; Iftekhar Hussain 
mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) mailto:

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Himanshu,

Will changing the text as below make it clear ?

In multihoming single-active scenario, for a given VPWS service instance, in 
steady state, a remote PE SHOULD receive P=1 from only one PE and a B-1 from 
only one PE. However during transient situations, a remote PE receiving P=1 
from more than one PE will select the last advertising PE as the primary PE 
when forwarding traffic. A remote PE receiving B=1 from more than one PE will 
select only one backup PE. A remote PE MUST receive P=1 from at least one PE 
before forwarding traffic.

Thanks,

Sami

From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 4:31 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, "Rabadan, 
Jorge (Nokia - US)" mailto:jorge.raba...@nokia.com>>, 
Sami Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

I strongly suggest that more clarifying text is added.
VPWS draft is introducing the Primary/backup extensions
and it is confusing what the exact behavior should be for
single-active multi-homing.

Even in case of transition, how multi-homed PEs behavior wrt
P/B when it would change from P to B and B to P and what remote
has accepted is not clear (what ‘last’ received at remote is
not assured at originating multi-homed PE members).

More I think about it, pref-def draft is increasingly playing
important role for this to be clean.

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Wednesday, February 08, 2017 7:12 PM
To: Shah, Himanshu mailto:hs...@ciena.com>>; Rabadan, Jorge 
(Nokia - US) mailto:jorge.raba...@nokia.com>>; Sami 
Boutros mailto:boutros.s...@gmail.com>>; Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org; 
bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07



From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:54 PM
To: "Rabadan, Jorge (Nokia - US)" 
mailto:jorge.raba...@nokia.com>>, Sami Boutros 
mailto:sbout...@vmware.com>>, Sami Boutros 
mailto:boutros.s...@gmail.com>>, Iftekhar Hussain 
mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Ahh...This makes sense.

And NO it is not in the draft. Contrary, draft says that remote will accept 
only one as B=1 (may be to his liking..:-))

[Sami] This is correct,  we can receive more than one P=1 and on B=1 and the 
draft say this happen only in transit scenarios as in  the following text.. for 
a given EVPN-VPWS instance.

In multihoming single-active scenario, during transient situations, a remote PE 
receiving P=1 from more than one PE will select the last advertising PE as the 
primary PE when forwarding traffic. A remote PE receiving B=1 from more than 
one PE will select only one backup PE. A remote PE MUST receive P=1 from at 
least one PE before forwarding traffic.

Thanks,

Sami

What you say below needs to be explicitly included in the draft. Please..

Thanks,
Himanshu

From: Rabadan, Jorge (Nokia - US) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, February 08, 2017 6:47 PM
To: Sami Boutros mailto:sbout...@vmware.com>>; Shah, 
Himanshu mailto:hs...@ciena.com>>; Sami Boutros 
mailto:boutros.s...@gmail.com>>; Iftekhar Hussain 
mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org; 
bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Himanshu,

Just to reinforce what Sami is saying, I think the confusion comes between how 
many backup or redundant nodes can be in an ethernet-segment, and how many of 
them can signal B=1.

There is only one PE signaling B=1. There may be more than 2 PEs in the ES, in 
which case there are more than 1 redundant PEs, but

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Shah, Himanshu]

Hi Sami –

I strongly suggest that more clarifying text is added.
VPWS draft is introducing the Primary/backup extensions
and it is confusing what the exact behavior should be for
single-active multi-homing.

Even in case of transition, how multi-homed PEs behavior wrt
P/B when it would change from P to B and B to P and what remote
has accepted is not clear (what ‘last’ received at remote is
not assured at originating multi-homed PE members).

More I think about it, pref-def draft is increasingly playing
important role for this to be clean.

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Wednesday, February 08, 2017 7:12 PM
To: Shah, Himanshu ; Rabadan, Jorge (Nokia - US) 
; Sami Boutros ; Iftekhar 
Hussain 
Cc: Jeffrey Zhang ; Alvaro Retana (aretana) 
; bess-cha...@ietf.org; bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07



From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:54 PM
To: "Rabadan, Jorge (Nokia - US)" 
mailto:jorge.raba...@nokia.com>>, Sami Boutros 
mailto:sbout...@vmware.com>>, Sami Boutros 
mailto:boutros.s...@gmail.com>>, Iftekhar Hussain 
mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Ahh...This makes sense.

And NO it is not in the draft. Contrary, draft says that remote will accept 
only one as B=1 (may be to his liking..:-))

[Sami] This is correct,  we can receive more than one P=1 and on B=1 and the 
draft say this happen only in transit scenarios as in  the following text.. for 
a given EVPN-VPWS instance.

In multihoming single-active scenario, during transient situations, a remote PE 
receiving P=1 from more than one PE will select the last advertising PE as the 
primary PE when forwarding traffic. A remote PE receiving B=1 from more than 
one PE will select only one backup PE. A remote PE MUST receive P=1 from at 
least one PE before forwarding traffic.

Thanks,

Sami

What you say below needs to be explicitly included in the draft. Please..

Thanks,
Himanshu

From: Rabadan, Jorge (Nokia - US) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, February 08, 2017 6:47 PM
To: Sami Boutros mailto:sbout...@vmware.com>>; Shah, 
Himanshu mailto:hs...@ciena.com>>; Sami Boutros 
mailto:boutros.s...@gmail.com>>; Iftekhar Hussain 
mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org; 
bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Himanshu,

Just to reinforce what Sami is saying, I think the confusion comes between how 
many backup or redundant nodes can be in an ethernet-segment, and how many of 
them can signal B=1.

There is only one PE signaling B=1. There may be more than 2 PEs in the ES, in 
which case there are more than 1 redundant PEs, but only one PE should signal 
B=1 at the time. Since there may be transient windows where the remote PE gets 
2 P=1s or 2 B=1s, we need to define what to do, but it doesn’t mean that is a 
normal steady state.

In a nutshell, Primary will send P=1,B=0. Backup will send P=0,B=1 and the rest 
of the redundant PEs in the ES will send P=0,B=0. If the primary PE/ES fails, 
the remote PEs will immediately send to the backup. In the meantime, there is a 
DF reelection, and there will be a new primary and new backup that will signal 
the bits as per the above. The remote PE will always send to the primary first 
and if not present to the backup.

I think all this is in the draft though…

Thanks.
Jorge


On 2/9/17, 12:39 AM, "Sami Boutros" 
mailto:sbout...@vmware.com>> wrote:

Hi Himanshu,


From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:04 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, Sami 
Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

Thanks for clarifications. The rabadan-evpn-pref-df has the right idea (did not 
know about it...)

Fo

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:54 PM
To: "Rabadan, Jorge (Nokia - US)" 
mailto:jorge.raba...@nokia.com>>, Sami Boutros 
mailto:sbout...@vmware.com>>, Sami Boutros 
mailto:boutros.s...@gmail.com>>, Iftekhar Hussain 
mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Ahh...This makes sense.

And NO it is not in the draft. Contrary, draft says that remote will accept 
only one as B=1 (may be to his liking..:-))

[Sami] This is correct,  we can receive more than one P=1 and on B=1 and the 
draft say this happen only in transit scenarios as in  the following text.. for 
a given EVPN-VPWS instance.

In multihoming single-active scenario, during transient situations, a remote PE 
receiving P=1 from more than one PE will select the last advertising PE as the 
primary PE when forwarding traffic. A remote PE receiving B=1 from more than 
one PE will select only one backup PE. A remote PE MUST receive P=1 from at 
least one PE before forwarding traffic.

Thanks,

Sami

What you say below needs to be explicitly included in the draft. Please..

Thanks,
Himanshu

From: Rabadan, Jorge (Nokia - US) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, February 08, 2017 6:47 PM
To: Sami Boutros mailto:sbout...@vmware.com>>; Shah, 
Himanshu mailto:hs...@ciena.com>>; Sami Boutros 
mailto:boutros.s...@gmail.com>>; Iftekhar Hussain 
mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org; 
bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Himanshu,

Just to reinforce what Sami is saying, I think the confusion comes between how 
many backup or redundant nodes can be in an ethernet-segment, and how many of 
them can signal B=1.

There is only one PE signaling B=1. There may be more than 2 PEs in the ES, in 
which case there are more than 1 redundant PEs, but only one PE should signal 
B=1 at the time. Since there may be transient windows where the remote PE gets 
2 P=1s or 2 B=1s, we need to define what to do, but it doesn’t mean that is a 
normal steady state.

In a nutshell, Primary will send P=1,B=0. Backup will send P=0,B=1 and the rest 
of the redundant PEs in the ES will send P=0,B=0. If the primary PE/ES fails, 
the remote PEs will immediately send to the backup. In the meantime, there is a 
DF reelection, and there will be a new primary and new backup that will signal 
the bits as per the above. The remote PE will always send to the primary first 
and if not present to the backup.

I think all this is in the draft though…

Thanks.
Jorge


On 2/9/17, 12:39 AM, "Sami Boutros" 
mailto:sbout...@vmware.com>> wrote:

Hi Himanshu,


From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:04 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, Sami 
Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

Thanks for clarifications. The rabadan-evpn-pref-df has the right idea (did not 
know about it...)

Following text from the draft –

   In multihoming single-active scenario, the DF election will determine
   who the primary and the backup PEs are, and only those PEs will set
   the P bit and B bit respectively. A remote PE will forward the
   traffic to the primary PE and switch over to the backup PE as soon as
   it receives an Ethernet A-D route withdrawal from the primary PE in
   the Ethernet Segment.

[Himanshu] the highlighted text is somewhat confusing in the context of
multiple backups (in single-active redundancy). How would remote PE know
which backup to switch over to.

   In multihoming single-active scenario, during transient situations, a
   remote PE receiving P=1 from more than one PE will select the last
   advertising PE as the primary PE when forwarding traffic. A remote PE
  receiving B=1 from more than one PE will select only one backup PE. A
   remote PE MUST receive P=1 from at lea

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Shah, Himanshu]

Ahh...This makes sense.

And NO it is not in the draft. Contrary, draft says that remote will accept 
only one as B=1 (may be to his liking..:-))

What you say below needs to be explicitly included in the draft. Please..

Thanks,
Himanshu

From: Rabadan, Jorge (Nokia - US) [mailto:jorge.raba...@nokia.com]
Sent: Wednesday, February 08, 2017 6:47 PM
To: Sami Boutros ; Shah, Himanshu ; Sami 
Boutros ; Iftekhar Hussain 
Cc: Jeffrey Zhang ; Alvaro Retana (aretana) 
; bess-cha...@ietf.org; bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Himanshu,

Just to reinforce what Sami is saying, I think the confusion comes between how 
many backup or redundant nodes can be in an ethernet-segment, and how many of 
them can signal B=1.

There is only one PE signaling B=1. There may be more than 2 PEs in the ES, in 
which case there are more than 1 redundant PEs, but only one PE should signal 
B=1 at the time. Since there may be transient windows where the remote PE gets 
2 P=1s or 2 B=1s, we need to define what to do, but it doesn’t mean that is a 
normal steady state.

In a nutshell, Primary will send P=1,B=0. Backup will send P=0,B=1 and the rest 
of the redundant PEs in the ES will send P=0,B=0. If the primary PE/ES fails, 
the remote PEs will immediately send to the backup. In the meantime, there is a 
DF reelection, and there will be a new primary and new backup that will signal 
the bits as per the above. The remote PE will always send to the primary first 
and if not present to the backup.

I think all this is in the draft though…

Thanks.
Jorge


On 2/9/17, 12:39 AM, "Sami Boutros" 
mailto:sbout...@vmware.com>> wrote:

Hi Himanshu,


From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:04 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, Sami 
Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

Thanks for clarifications. The rabadan-evpn-pref-df has the right idea (did not 
know about it...)

Following text from the draft –

   In multihoming single-active scenario, the DF election will determine
   who the primary and the backup PEs are, and only those PEs will set
   the P bit and B bit respectively. A remote PE will forward the
   traffic to the primary PE and switch over to the backup PE as soon as
   it receives an Ethernet A-D route withdrawal from the primary PE in
   the Ethernet Segment.

[Himanshu] the highlighted text is somewhat confusing in the context of
multiple backups (in single-active redundancy). How would remote PE know
which backup to switch over to.

   In multihoming single-active scenario, during transient situations, a
   remote PE receiving P=1 from more than one PE will select the last
   advertising PE as the primary PE when forwarding traffic. A remote PE
  receiving B=1 from more than one PE will select only one backup PE. A
   remote PE MUST receive P=1 from at least one PE before forwarding

[Himanshu] the above highlighted text seems to suggest that only one backup
is supported, contrary to what you suggest below that one primary
and one or more backups are supported.
---

[Sami] But wouldn’t the text highlighted here clarify the text above, that only 
one Backup should be selected.

It would be better if the draft clearly states that it will only support
One primary and one backup in single-active redundancy and one primary
and multiple backups are NOT supported (unlike EVPN..)

[Sami] Why the limitation? Any reason? For PW redundancy we do support too 
multiple backups, however for
a given PW only one backup will be selected, exactly the same as here.

Also, for single-active redundancy, DF election is relegated to selection of
the role of multi-homed PEs to be primary or backup. Is this role determined
in the context of VLANs (bundled VLAN case), I am guessing NOT.
Clarifying text in this area would also be helpful.

[Sami] DF election is intentionally not in scope, not to redefine any 
mechanisms in Base 7432 or other drafts like
draft-ietf-bess-evpn-df-election.

Thanks,

Sami

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Tuesday, February 07, 2017 6:06 PM
To: Shah, Himanshu mailto:hs...@ciena.com>>; Sami Boutros 
mailto:boutros.s...@gmail.com>>; Iftekhar Hussain 
mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org; 
bess@ietf.org

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Rabadan, Jorge (Nokia - US)]

Himanshu,

Just to reinforce what Sami is saying, I think the confusion comes between how 
many backup or redundant nodes can be in an ethernet-segment, and how many of 
them can signal B=1.

There is only one PE signaling B=1. There may be more than 2 PEs in the ES, in 
which case there are more than 1 redundant PEs, but only one PE should signal 
B=1 at the time. Since there may be transient windows where the remote PE gets 
2 P=1s or 2 B=1s, we need to define what to do, but it doesn’t mean that is a 
normal steady state.

In a nutshell, Primary will send P=1,B=0. Backup will send P=0,B=1 and the rest 
of the redundant PEs in the ES will send P=0,B=0. If the primary PE/ES fails, 
the remote PEs will immediately send to the backup. In the meantime, there is a 
DF reelection, and there will be a new primary and new backup that will signal 
the bits as per the above. The remote PE will always send to the primary first 
and if not present to the backup.

I think all this is in the draft though…

Thanks.
Jorge


On 2/9/17, 12:39 AM, "Sami Boutros" 
mailto:sbout...@vmware.com>> wrote:

Hi Himanshu,


From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:04 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, Sami 
Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

Thanks for clarifications. The rabadan-evpn-pref-df has the right idea (did not 
know about it...)

Following text from the draft –

   In multihoming single-active scenario, the DF election will determine
   who the primary and the backup PEs are, and only those PEs will set
   the P bit and B bit respectively. A remote PE will forward the
   traffic to the primary PE and switch over to the backup PE as soon as
   it receives an Ethernet A-D route withdrawal from the primary PE in
   the Ethernet Segment.

[Himanshu] the highlighted text is somewhat confusing in the context of
multiple backups (in single-active redundancy). How would remote PE know
which backup to switch over to.

   In multihoming single-active scenario, during transient situations, a
   remote PE receiving P=1 from more than one PE will select the last
   advertising PE as the primary PE when forwarding traffic. A remote PE
  receiving B=1 from more than one PE will select only one backup PE. A
   remote PE MUST receive P=1 from at least one PE before forwarding

[Himanshu] the above highlighted text seems to suggest that only one backup
is supported, contrary to what you suggest below that one primary
and one or more backups are supported.
---

[Sami] But wouldn’t the text highlighted here clarify the text above, that only 
one Backup should be selected.

It would be better if the draft clearly states that it will only support
One primary and one backup in single-active redundancy and one primary
and multiple backups are NOT supported (unlike EVPN..)

[Sami] Why the limitation? Any reason? For PW redundancy we do support too 
multiple backups, however for
a given PW only one backup will be selected, exactly the same as here.

Also, for single-active redundancy, DF election is relegated to selection of
the role of multi-homed PEs to be primary or backup. Is this role determined
in the context of VLANs (bundled VLAN case), I am guessing NOT.
Clarifying text in this area would also be helpful.

[Sami] DF election is intentionally not in scope, not to redefine any 
mechanisms in Base 7432 or other drafts like
draft-ietf-bess-evpn-df-election.

Thanks,

Sami

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Tuesday, February 07, 2017 6:06 PM
To: Shah, Himanshu mailto:hs...@ciena.com>>; Sami Boutros 
mailto:boutros.s...@gmail.com>>; Iftekhar Hussain 
mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org; 
bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Himanshu,

Please see comments inline.

From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Tuesday, February 7, 2017 at 12:45 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, Sami 
Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:be

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Himanshu,


From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:04 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, Sami 
Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

Thanks for clarifications. The rabadan-evpn-pref-df has the right idea (did not 
know about it...)

Following text from the draft –

   In multihoming single-active scenario, the DF election will determine
   who the primary and the backup PEs are, and only those PEs will set
   the P bit and B bit respectively. A remote PE will forward the
   traffic to the primary PE and switch over to the backup PE as soon as
   it receives an Ethernet A-D route withdrawal from the primary PE in
   the Ethernet Segment.

[Himanshu] the highlighted text is somewhat confusing in the context of
multiple backups (in single-active redundancy). How would remote PE know
which backup to switch over to.

   In multihoming single-active scenario, during transient situations, a
   remote PE receiving P=1 from more than one PE will select the last
   advertising PE as the primary PE when forwarding traffic. A remote PE
  receiving B=1 from more than one PE will select only one backup PE. A
   remote PE MUST receive P=1 from at least one PE before forwarding

[Himanshu] the above highlighted text seems to suggest that only one backup
is supported, contrary to what you suggest below that one primary
and one or more backups are supported.
---

[Sami] But wouldn’t the text highlighted here clarify the text above, that only 
one Backup should be selected.

It would be better if the draft clearly states that it will only support
One primary and one backup in single-active redundancy and one primary
and multiple backups are NOT supported (unlike EVPN..)

[Sami] Why the limitation? Any reason? For PW redundancy we do support too 
multiple backups, however for
a given PW only one backup will be selected, exactly the same as here.

Also, for single-active redundancy, DF election is relegated to selection of
the role of multi-homed PEs to be primary or backup. Is this role determined
in the context of VLANs (bundled VLAN case), I am guessing NOT.
Clarifying text in this area would also be helpful.

[Sami] DF election is intentionally not in scope, not to redefine any 
mechanisms in Base 7432 or other drafts like
draft-ietf-bess-evpn-df-election.

Thanks,

Sami

Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Tuesday, February 07, 2017 6:06 PM
To: Shah, Himanshu mailto:hs...@ciena.com>>; Sami Boutros 
mailto:boutros.s...@gmail.com>>; Iftekhar Hussain 
mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) mailto:aret...@cisco.com>>; 
bess-cha...@ietf.org; 
bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Himanshu,

Please see comments inline.

From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Tuesday, February 7, 2017 at 12:45 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, Sami 
Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

It seems to me that single-active multihoming case could use some more 
clarification text.

I think there should be an additional field in L2 extended community
as (for example) “election priority” so that each multi-homed member can 
definitely tell
to each other as well as to remote PE who/what primary election order would be.

[Sami] In single active, there would be only one primary as per definition 
below in this e-mail.

Thus, when ESI link to primary fails, remote PE can quickly change the next hop
to next priority PE multi-home member.

[Sami] Extending the DF election is not in scope for the draft and I doubt we 
will include it, however there are other drafts extending DF election like 
rabadan-evpn-pref-df.

The text in VPWS draft is not very clear.

It seems to suggest there could be multipl

[bess] IPR Disclosure Juniper's Statement about IPR related to draft-ietf-bess-dci-evpn-overlay

[IETF Secretariat]

Dear Ali Sajassi, Dennis Cai, Jorge Rabadan, Senthil Sathappan, Wim Henderickx, 
Senad Palislamovic:


An IPR disclosure that pertains to your Internet-Draft entitled
"Interconnect Solution for EVPN Overlay networks"
(draft-ietf-bess-dci-evpn-overlay) was submitted to the IETF Secretariat on  and
has been posted on the "IETF Page of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/2951/). The title of the IPR disclosure is
"Juniper's Statement about IPR related to draft-ietf-bess-dci-evpn-overlay"


Thank you

IETF Secretariat

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

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Shah, Himanshu]

Hi Sami –

Thanks for clarifications. The rabadan-evpn-pref-df has the right idea (did not 
know about it...)

Following text from the draft –

   In multihoming single-active scenario, the DF election will determine
   who the primary and the backup PEs are, and only those PEs will set
   the P bit and B bit respectively. A remote PE will forward the
   traffic to the primary PE and switch over to the backup PE as soon as
   it receives an Ethernet A-D route withdrawal from the primary PE in
   the Ethernet Segment.

[Himanshu] the highlighted text is somewhat confusing in the context of
multiple backups (in single-active redundancy). How would remote PE know
which backup to switch over to.

   In multihoming single-active scenario, during transient situations, a
   remote PE receiving P=1 from more than one PE will select the last
   advertising PE as the primary PE when forwarding traffic. A remote PE
  receiving B=1 from more than one PE will select only one backup PE. A
   remote PE MUST receive P=1 from at least one PE before forwarding

[Himanshu] the above highlighted text seems to suggest that only one backup
is supported, contrary to what you suggest below that one primary
and one or more backups are supported.
---

It would be better if the draft clearly states that it will only support
One primary and one backup in single-active redundancy and one primary
and multiple backups are NOT supported (unlike EVPN..)

Also, for single-active redundancy, DF election is relegated to selection of
the role of multi-homed PEs to be primary or backup. Is this role determined
in the context of VLANs (bundled VLAN case), I am guessing NOT.
Clarifying text in this area would also be helpful.


Thanks,
Himanshu

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Tuesday, February 07, 2017 6:06 PM
To: Shah, Himanshu ; Sami Boutros ; 
Iftekhar Hussain 
Cc: Jeffrey Zhang ; Alvaro Retana (aretana) 
; bess-cha...@ietf.org; bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Himanshu,

Please see comments inline.

From: "Shah, Himanshu" mailto:hs...@ciena.com>>
Date: Tuesday, February 7, 2017 at 12:45 PM
To: Sami Boutros mailto:sbout...@vmware.com>>, Sami 
Boutros mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

It seems to me that single-active multihoming case could use some more 
clarification text.

I think there should be an additional field in L2 extended community
as (for example) “election priority” so that each multi-homed member can 
definitely tell
to each other as well as to remote PE who/what primary election order would be.

[Sami] In single active, there would be only one primary as per definition 
below in this e-mail.

Thus, when ESI link to primary fails, remote PE can quickly change the next hop
to next priority PE multi-home member.

[Sami] Extending the DF election is not in scope for the draft and I doubt we 
will include it, however there are other drafts extending DF election like 
rabadan-evpn-pref-df.

The text in VPWS draft is not very clear.

It seems to suggest there could be multiple primaries and backups.
But if that is true how would remote PE can independently switchover to backup 
PE
(i.e. which backup PE?).

[Sami] As per draft, "A remote PE receiving B=1 from more than one PE will 
select only one backup PE."

If there are multiple primary PEs, and if one of them fail, why not switchover 
to other
primary PE, so on and so forth..

[Sami] In single active there should be only one primary, having more than one 
primary will be transit in this case.

So what is the intent?

[Sami] As per EVPN, the intent is to support A/A in which all will be primary, 
or A/S in which only one primary and one backup.

One primary, one backup
Multiple primary, one backup
Or (one or) multiple primaries, multiple backups?

[Sami] We are not redefining what single active or all active mean, this is as 
per EVPN RFC7432

Single-Active Redundancy Mode: When only a single PE, among all the

  PEs attached to an Ethernet segment, is allowed to forward traffic

  to/from that Ethernet segment for a given VLAN, then the Ethernet

  segment is defined to be operating in Single-Active redundancy

  mode.



I.e. One primary and one/multiple backup.



   All-Active Redundancy Mode: When all PEs attached to an Ethernet

  segment are allowed to forward known unicast traffic to/from that

  Ethernet segment for a given VLAN, then the Ethern

[bess] IPR Disclosure Cisco's Statement about IPR related to draft-sajassi-bess-evpn-igmp-mld-proxy

[IETF Secretariat]

Dear Ali Sajassi, Samir Thoria, John Drake, Wen Lin, Keyur Patel, Derek M. 
Yeung:


An IPR disclosure that pertains to your Internet-Draft entitled "IGMP and
MLD Proxy for EVPN" (draft-sajassi-bess-evpn-igmp-mld-proxy) was submitted
to the IETF Secretariat on  and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/2949/). The title of the IPR disclosure is
"Cisco's Statement about IPR related to
draft-sajassi-bess-evpn-igmp-mld-proxy"


Thank you

IETF Secretariat

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

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Iftekhar Hussain]

Hi Sami,

Certainly, if it helps, certainly we could chat  via phone sometime. PWE3 model 
is different than what your doc is proposing. No, I am not looking for Yang 
model – I am co-authoring one. I am looking for clarity and thoroughness.

Thanks,
Iftekhar

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Wednesday, February 08, 2017 11:25 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; bess-cha...@ietf.org; 
bess@ietf.org; draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,

We can have a phone call to go over this, if you like, I will send you my 
availability in contact in a private e-mail.
From: Iftekhar Hussain mailto:ihuss...@infinera.com>>
Date: Wednesday, February 8, 2017 at 10:45 AM
To: Sami Boutros mailto:sbout...@vmware.com>>
Cc: "Alvaro Retana (aretana)" mailto:aret...@cisco.com>>, 
Jeffrey Zhang mailto:zzh...@juniper.net>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami,

To make my comments clear (in case it didn’t come through earlier emails), I am 
summarizing my comments again.

1.  Clearly identify the role of AC and ES for point-to-point services

Sami: We clearly say the following: "Ethernet Virtual Private Line (EVPL) 
service as p2p service between a pair of ACs (designated by VLANs) and Ethernet 
Private Line (EPL) service, in which all traffic flows are between a single 
pair of ports, that in EVPN terminology would mean a single pair of Ethernet 
Segments ES(es).”
But I think you don’t find that clear, so can you propose some text that will 
make it clear?


2.  Clearly identify and document the reference model for the 
point-to-point services. For example, here is what I believe the model should 
look like.


[cid:image001.png@01D28202.3DC08BA0]

Sami: We have a already a reference model similar to PWE3 in the doc, in 
section 4. Not sure what the above will do, and does PWE3 have the above? If 
you need the above to define some YANG data model, I would recommend adding it 
to the YANG data model draft!



3.  Define an entity to toward PSN – see the picture above. Like I said 
earlier, if we don’t fix it now, it is only get worse/confusing as other 
extensions are added.

Sami: Can you propose some text for that? That will make it clear for you 
different than what we already added.
"VPWS Service Instance: It is represented by a pair of EVPN service labels 
associated with a pair of endpoints. Each label is downstream assigned and 
advertised by the disposition PE through an Ethernet A-D per-EVI route. The 
downstream label identifies the endpoint on the disposition PE. A VPWS service 
instance can be associated with only one VPWS service identifier.”



4.  I would reiterate again – please summarize the functionality of RFC7432 
that applies to point-to-point services and which does not.  Users who are only 
interested in point-to-point services, could use this document to implement it 
without getting drowned information which is not relevant in such scenarios. 
Point-to-point services should be treated as services in their own wright – 
rather than after thought or extension of multipoint services.


Sami: And, I will repeat again, through out the document we are only talking 
about only E-AD routes, which is used by EVPN-VPWS service, and when we talk 
about redundancy we refer to the EVPN base for single-active and active-active, 
not sure what else do you want us to say? As I said we don’t agree to list what 
we don’t support from EVPN, since the list can’t predict what future extensions 
will be added to EVPN.

Thanks,

Sami

Hope this makes it clear the type of updates I am looking for.

Thanks,
Iftekhar

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Tuesday, February 07, 2017 11:55 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; 
bess-cha...@ietf.org; 
bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,


The management entity you are looking for is the evpn VPWS service instance, 
fxc can map more than one AC to this. I will add a definition in the doc to 
this evpn VPWS instance and mention that only one AC can be xconnected to it. 
Will that be ok?

[Iftekhar2] An issue pointed earlier that I see with the current solution is 
that there is no per service level entity for statistic counters on the PSN 
side. The LSP provides aggregate counters for all the services carried on that 
LSP.

[Sami] The EVPN-VPWS LSP here carries only one service not multiple servcies. 
Here is what I add

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros]

Hi Iftekhar,

We can have a phone call to go over this, if you like, I will send you my 
availability in contact in a private e-mail.
From: Iftekhar Hussain mailto:ihuss...@infinera.com>>
Date: Wednesday, February 8, 2017 at 10:45 AM
To: Sami Boutros mailto:sbout...@vmware.com>>
Cc: "Alvaro Retana (aretana)" mailto:aret...@cisco.com>>, 
Jeffrey Zhang mailto:zzh...@juniper.net>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org" mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org" 
mailto:draft-ietf-bess-evpn-v...@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami,

To make my comments clear (in case it didn’t come through earlier emails), I am 
summarizing my comments again.

1.   Clearly identify the role of AC and ES for point-to-point services

Sami: We clearly say the following: "Ethernet Virtual Private Line (EVPL) 
service as p2p service between a pair of ACs (designated by VLANs) and Ethernet 
Private Line (EPL) service, in which all traffic flows are between a single 
pair of ports, that in EVPN terminology would mean a single pair of Ethernet 
Segments ES(es).”
But I think you don’t find that clear, so can you propose some text that will 
make it clear?


2.   Clearly identify and document the reference model for the 
point-to-point services. For example, here is what I believe the model should 
look like.


[cid:image002.png@01D281F8.6434A550]

Sami: We have a already a reference model similar to PWE3 in the doc, in 
section 4. Not sure what the above will do, and does PWE3 have the above? If 
you need the above to define some YANG data model, I would recommend adding it 
to the YANG data model draft!



3.   Define an entity to toward PSN – see the picture above. Like I said 
earlier, if we don’t fix it now, it is only get worse/confusing as other 
extensions are added.

Sami: Can you propose some text for that? That will make it clear for you 
different than what we already added.
"VPWS Service Instance: It is represented by a pair of EVPN service labels 
associated with a pair of endpoints. Each label is downstream assigned and 
advertised by the disposition PE through an Ethernet A-D per-EVI route. The 
downstream label identifies the endpoint on the disposition PE. A VPWS service 
instance can be associated with only one VPWS service identifier.”



4.   I would reiterate again – please summarize the functionality of 
RFC7432 that applies to point-to-point services and which does not.  Users who 
are only interested in point-to-point services, could use this document to 
implement it without getting drowned information which is not relevant in such 
scenarios. Point-to-point services should be treated as services in their own 
wright – rather than after thought or extension of multipoint services.


Sami: And, I will repeat again, through out the document we are only talking 
about only E-AD routes, which is used by EVPN-VPWS service, and when we talk 
about redundancy we refer to the EVPN base for single-active and active-active, 
not sure what else do you want us to say? As I said we don’t agree to list what 
we don’t support from EVPN, since the list can’t predict what future extensions 
will be added to EVPN.

Thanks,

Sami

Hope this makes it clear the type of updates I am looking for.

Thanks,
Iftekhar

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Tuesday, February 07, 2017 11:55 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; 
bess-cha...@ietf.org; 
bess@ietf.org; 
draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,


The management entity you are looking for is the evpn VPWS service instance, 
fxc can map more than one AC to this. I will add a definition in the doc to 
this evpn VPWS instance and mention that only one AC can be xconnected to it. 
Will that be ok?

[Iftekhar2] An issue pointed earlier that I see with the current solution is 
that there is no per service level entity for statistic counters on the PSN 
side. The LSP provides aggregate counters for all the services carried on that 
LSP.

[Sami] The EVPN-VPWS LSP here carries only one service not multiple servcies. 
Here is what I added. I hope this will be good enough.

VPWS Service Instance: It is represented by a pair of EVPN service labels 
associated with a pair of endpoints. Each label is downstream assigned and 
advertised by the disposition PE through an Ethernet A-D per-EVI route. The 
downstream label identifies the endpoint on the disposition PE. A VPWS service 
instance can be associated with only one VPWS service identifier.

Thanks,

Sami


A LSP could be carrying multiple VPWS-EVPN services. My suggestion is that it 
would be better to sort this out. Again, i

Re: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01

[Samir Thoria (sthoria)]

Support as a co-author.  There is an IPR related to this draft and IETF should 
get Cisco “standard notification" on it shortly.

Thanks,
Samir.

On 1/31/17, 6:58 AM, "Thomas Morin"  wrote:

Hello working group,

This email starts a two-week poll on adopting 
draft-sajassi-bess-evpn-igmp-mld-proxy-01 [1] as a working group item.

Please send comments to the list and state if you support adoption or 
not (in the later case, please also state the reasons).

This poll runs until **February 14th**.

*Coincidentally*, we are also polling for knowledge of any IPR that 
applies to this draft, 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 a document author or contributor please 
respond to this email and indicate whether or not you are aware of any 
relevant IPR.

The draft will not be adopted until a response has been received from 
each author and contributor.

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

Thank you,

Martin & Thomas
bess chairs

[1] 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-igmp-mld-proxy-01


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

Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Iftekhar Hussain]

Hi Sami,

To make my comments clear (in case it didn’t come through earlier emails), I am 
summarizing my comments again.

1.   Clearly identify the role of AC and ES for point-to-point services

2.   Clearly identify and document the reference model for the 
point-to-point services. For example, here is what I believe the model should 
look like.


[cid:image002.png@01D281F8.6434A550]


3.   Define an entity to toward PSN – see the picture above. Like I said 
earlier, if we don’t fix it now, it is only get worse/confusing as other 
extensions are added.

4.   I would reiterate again – please summarize the functionality of 
RFC7432 that applies to point-to-point services and which does not.  Users who 
are only interested in point-to-point services, could use this document to 
implement it without getting drowned information which is not relevant in such 
scenarios. Point-to-point services should be treated as services in their own 
wright – rather than after thought or extension of multipoint services.

Hope this makes it clear the type of updates I am looking for.

Thanks,
Iftekhar

From: Sami Boutros [mailto:sbout...@vmware.com]
Sent: Tuesday, February 07, 2017 11:55 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; bess-cha...@ietf.org; 
bess@ietf.org; draft-ietf-bess-evpn-v...@ietf.org
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,


The management entity you are looking for is the evpn VPWS service instance, 
fxc can map more than one AC to this. I will add a definition in the doc to 
this evpn VPWS instance and mention that only one AC can be xconnected to it. 
Will that be ok?

[Iftekhar2] An issue pointed earlier that I see with the current solution is 
that there is no per service level entity for statistic counters on the PSN 
side. The LSP provides aggregate counters for all the services carried on that 
LSP.

[Sami] The EVPN-VPWS LSP here carries only one service not multiple servcies. 
Here is what I added. I hope this will be good enough.

VPWS Service Instance: It is represented by a pair of EVPN service labels 
associated with a pair of endpoints. Each label is downstream assigned and 
advertised by the disposition PE through an Ethernet A-D per-EVI route. The 
downstream label identifies the endpoint on the disposition PE. A VPWS service 
instance can be associated with only one VPWS service identifier.

Thanks,

Sami


A LSP could be carrying multiple VPWS-EVPN services. My suggestion is that it 
would be better to sort this out. Again, if other folks are happy with the 
current state of the doc, I don’t want to hold your doc.

Thanks,
Iftekhar

Thanks,

Sami



image001.emz
Description: image001.emz


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

Re: [bess] WG Last Call for draft-ietf-bess-dci-evpn-overlay-04

[Wen Lin]

Support and not aware of IPR related to this draft either.

Thanks,
Wen

On 2/7/17, 6:06 PM, "BESS on behalf of Henderickx, Wim (Nokia - BE)" 
 wrote:

Support, not aware of IPR related to this draft

On 07/02/2017, 07:42, "BESS on behalf of Dolganow, Andrew (Nokia - SG)" 
 wrote:

Support

Andrew

Sent from my iPhone

> On Feb 6, 2017, at 10:07 PM, Martin Vigoureux 
 wrote:
> 
> Hello Working Group,
> 
> This email starts a Working Group Last Call on 
draft-ietf-bess-dci-evpn-overlay-04 [1] which is considered mature and ready 
for a final working group review.
> 
> Please read the document if you haven't read the most recent
> version yet, and send your comments to the list, no later than
> *19th of February*.
> Note that this is *not only* a call for comments on the document; it 
is also a call for support (or not) to publish this document as a Proposed 
Standard RFC.
> 
> *Coincidentally*, we are also polling for knowledge of any IPR that 
applies to draft-ietf-bess-dci-evpn-overlay, 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 a document author or contributor of
> draft-ietf-bess-dci-evpn-overlay-04 please respond to this email and 
indicate whether or not you are aware of any relevant IPR.
> 
> Note that IPR exists and has been disclosed against this document [2].
> 
> Thank you,
> M&T
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/
> [2] 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-dci-evpn-overlay
> 
> ___
> 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


___
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