Re: [bess] [**EXTERNAL**] WG Last Call, IPR and Implementation Poll for draft-ietf-bess-evpn-vpws-fxc

[Shah, Himanshu]

I support publishing of this draft.

Ciena has implemented this draft.

Thanks,
Himanshu

From: BESS  on behalf of "slitkows.i...@gmail.com" 

Date: Tuesday, September 28, 2021 at 2:03 AM
To: "bess@ietf.org" 
Cc: "bess-cha...@ietf.org" 
Subject: [**EXTERNAL**] [bess] WG Last Call, IPR and Implementation Poll for 
draft-ietf-bess-evpn-vpws-fxc


Hi,



This email starts a two-week working group last call for 
draft-ietf-bess-evpn-vpws-fxc [1]



Please review the draft and send any comments to the BESS list. Also, please 
indicate if you support publishing the draft as a Standards Track RFC.



This poll runs until the 12th October 2021.



We are also polling for knowledge of any undisclosed IPR that applies to this 
document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as an author or a contributor of this document please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The document won't progress without answers from all the 
authors and contributors.

There are currently two IPR disclosures.



In addition, we are polling for knowledge of implementations of this draft, per 
the BESS policy in [2].



Thank you,

Matthew & Stephane





[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws-fxc/ 
[datatracker.ietf.org]

[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw 
[mailarchive.ietf.org]

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

Re: [bess] [**EXTERNAL**] Re: comments on draft-boutros-bess-elan-services-over-sr

[Shah, Himanshu]

Several (my) points –

  *   There is no intent to “knock off” EVPN and replace with this technology. 
Instead, it is a lightweight solution that offers a lot of benefits.
 *   We have several L2VPN solutions; LDP based, BGP based, EVPN – each 
solution with benefits of its own. And so is the Sami’s proposal.
  *   Discussions below is steering towards – “data plane learning is evil and 
control plane learning is god sent”.
 *   This is not true, one has to use the tools available in the chest to 
produce the best solution
  *   “oh if anycast is missing, let us put that in EVPN and punt this 
solution” is completely wrong approach
  *   The offered solution, uniquely leverages the SR technology to greatly 
simplify the ELAN services

Thanks,
Himanshu

From: BESS  on behalf of "Ali Sajassi (sajassi)" 

Date: Friday, November 20, 2020 at 4:21 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
"Jeffrey (Zhaohui) Zhang" , "Sami com>" 

Cc: "bess@ietf.org" 
Subject: [**EXTERNAL**] Re: [bess] comments on 
draft-boutros-bess-elan-services-over-sr

Hi Jorge,

Yes, EVPN has evolved over many years and that’s why it has such a big traction 
in industry (thanks to your contributions and many others) and we have always 
been open to improvements (mostly driven by our customers) and evaluated them 
objectively. So, if there is any suggestion wrt to Anycast ID, we can 
definitely evaluate it based on what use cases it covers, All-active mode (both 
equal and unequal LB), failure scenarios, convergence, impact to underlay and 
overlay protocols, as well as applicability to different encapsulations to name 
a few.

Cheers,
Ali

From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Friday, November 20, 2020 at 12:26 PM
To: Cisco Employee , "Jeffrey (Zhaohui) Zhang" 
, Sami Boutros 
Cc: "bess@ietf.org" 
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

Hi Ali,

Yes, I understand it has pros and cons. What I meant is that, if using anycast 
SID in EVPN satisfies Sami’s requirements (or most), there is no need to add a 
completely new technology that needs to reinvent how to do all services (elan, 
eline, etree, L3, mcast, etc) and relies on data-plane mac-learning - we can 
apply anycast SIDs to existing EVPN.

Thanks.
Jorge

From: Ali Sajassi (sajassi) 
Date: Friday, November 20, 2020 at 7:21 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) , 
Jeffrey (Zhaohui) Zhang , Sami Boutros 

Cc: bess@ietf.org 
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi Jorge,


Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an 
alternative to aliasing, since it may have its merits, I’ll be glad to 
investigate it with you and help. However data plane-learning sounds a step 
back to me.


I looked at this long time ago and it had some issues. For example, if you pass 
the anycast ID in underlay, then the load balancing is dictated by your 
underlay topology instead of the actual link BW of MCLAG. If you try to get 
fancier and distribute link bw info in the underlay (IGP), then you are 
burdening the underly protocol with overlay info.  And finally if you 
distribute it in the overlay (e.g., BGP), it becomes very similar to what we do 
currently.

BTW, Aliasing feature in EVPN is not mandatory but rather optional as you know.

Cheers,
Ali



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

Re: [bess] [**EXTERNAL**] Re: comments on draft-boutros-bess-elan-services-over-sr

[Shah, Himanshu]

As for control  plane learning vs. data plane learning, I don’t know about the 
history, but my impression is that control plane learning is considered as a 
feature but not as a fallback solution for not having the PW contexts for do 
data plane learning. I could be wrong though.
[jorge] I agree with you Jeffrey, to me is an improvement too. More below.



Just so that everyone is aware of the history, I introduced the control plane 
signaling concept for L2VPN,
as well as PW status signaling, capability exchange and PW QoS signaling for 
throttling the traffic.

EVPN utilized that idea and applied in EVPN signaling to offer related benefits.

https://tools.ietf.org/html/draft-shah-pwe3-control-protocol-extension-00

Control plane learning was used in arp-mediation (RFC 6575) and IPLS (RFC 7436).

(Just a note on the history).

Thanks,
Himanshu

From: BESS  on behalf of "Rabadan, Jorge (Nokia - 
US/Mountain View)" 
Date: Friday, November 20, 2020 at 2:15 AM
To: "Jeffrey (Zhaohui) Zhang" , "Sami com>" 

Cc: "bess@ietf.org" 
Subject: [**EXTERNAL**] Re: [bess] comments on 
draft-boutros-bess-elan-services-over-sr

Hi Sami and Jeffrey,

Please see some comments/replies in-line.

Thank you!
Jorge

From: Jeffrey (Zhaohui) Zhang 
Date: Thursday, November 19, 2020 at 7:20 PM
To: Sami Boutros , Rabadan, Jorge (Nokia - US/Mountain 
View) 
Cc: bess@ietf.org 
Subject: RE: [bess] comments on draft-boutros-bess-elan-services-over-sr
To clarify, when I said “evpn-like solution” I was referring to the fact that 
it uses service-SID/label instead of per-PW labels, and it supports split 
horizon for multi-homing.



Jeffrey

From: Sami Boutros 
Sent: Thursday, November 19, 2020 12:11 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
Cc: Jeffrey (Zhaohui) Zhang ; bess@ietf.org
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

[External Email. Be cautious of content]

Hi Jorge,





On Nov 19, 2020, at 5:09 AM, Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:

Hi everyone,

Jeffrey, not sure how much of EVPN this solution is, since there are no 
‘overlay’ routes advertised. In fact the draft says that no routes type 1..4 
are needed at all.
But I see your point Jeffrey, and I agree the concept of the source 
identification is not SR specific.

Agreed, source identification is not SR specific.





@Sami,

I couldn’t speak during the meeting so I’ll throw a couple of general 
comments/questions:


1.   While I see the anycast-SID as an interesting point, I disagree with 
the document’s motivation that EVPN needed to introduce control-plane learning 
due to the MP2P tunnels.

What I said is with MP2P tunnels EVPN was forced to only control plane Mac 
learning. Are you saying this is incorrect? If so, Why?
[jorge] No, I didn’t make myself clear enough – control plane is needed with 
MP2P tunnels, yes, but what I meant is that in your motivation it *sounds* like 
control-plane learning was a necessary evil due to the need for MP2P tunnels to 
fix the scale issue. I see control-plane learning as an additional 
improvement/feature, as Jeffrey was saying.





1.   Control plane learning has a lot of advantages and data-plane 
learning/aging has tons of issues. So this should be debated in the WG.

Sure, will be good to get Service providers input on that too. One thing to 
note here, our proposal is by no mean don’t use EVPN, it is simply another 
option that greatly simplify the control plane and remove tons of control plane 
overhead, as well simplify the data plane and remove need for any overlay 
convergence.






2.   Irrespective, the anycast-SID idea could work in regular EVPN as an 
optional alternative to aliasing. You don’t need to do data-plane learning for 
that, right?

Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an 
alternative to aliasing, since it may have its merits, I’ll be glad to 
investigate it with you and help. However data plane-learning sounds a step 
back to me.







3.   The document seems to claim fast mac move. How can that be guaranteed 
if the mac learning is data plane based?

In data plane when a MAC move from one port to another, or one PW to another, 
routers simply adjust no need for any EVPN procedure for MAC move.
[jorge] you are assuming that when that MAC moves to another port, it sends BUM 
traffic that is flooded and all the nodes can update. That is not always the 
case. The host that moves can simply generate known unicast traffic, and hence 
most nodes in the network will have stale information for the aging time. EVPN 
takes care of the mobility immediately as soon as the MAC that moves generates 
*any* type of frame.






4.   ARP suppression is not a merit of this solution. It could work even in 
RFC4761/74762 VPLS networks.


Agreed, we don’t claim any of that, the proposal doesn’t claim that it invented 
ARP suppression, or invented 

Re: [bess] [**EXTERNAL**] L2VPN YANG model

[Shah, Himanshu]

Thanks for bringing attention to this.
Will fix..

Thanks,
Himanshu

From: BESS  on behalf of Mahesh Jethanandani 

Date: Thursday, August 8, 2019 at 3:56 PM
To: "bess@ietf.org" 
Subject: [**EXTERNAL**] [bess] L2VPN YANG model

Hi,

-10 version of draft-ietf-bess-l2vpn-yang contains two YANG models:
  - ietf-pseudowi...@2018-10-17.yang
  - ietf-l2...@2019-05-28.yang

-09 version of the same draft contains the same two YANG models, but with these 
dates:
  - ietf-pseudowi...@2018-10-22.yang
  - ietf-l2...@2018-02-06.yang


In essence, the newer draft has an older version of ietf-pseudowires module, 
while the older draft has a newer version. Is this intentional?


The effect of this is that even if there are changes made to ietf-pseudowires 
module in the -10 draft, because of its date, and in a repository with both 
modules, the older one (in -09) will be picked up, unless there is an explicit 
reference by date.


Please clarify what was the intention of backdating the model.


Thanks

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [bess] [**EXTERNAL**] Re: EVPN VPWS BDF forwarding behavior at MH site

[Shah, Himanshu]

Just so that we all are on same page –

You have PE1 & PE2 as MH peers with PE1 as primary while PE2 as backup for 
certain EVI with PE3 as remote PE.
The problem you describe is, what if PE3 quickly changes over the path to PE2, 
and PE2 has not yet changed to primary role.
The solution you propose is – Let PE2 be unidirectionally active 
(remote->local) even when in standby role.
This will prevent one way traffic loss. However, local to remote is delayed 
until PE2 becomes primary via EVPN means (DF election, etc)

You mentioned MH-IPBFD between PE1<->PE3 and BGP-PIC to activate path between 
PE3<->PE2.

So followings need to be considered –

  *   PE1 and PE3 path is broken : meaning PE1 is alive but MH-IPBFD triggers
 *   If path between PE1 and PE2 is not broken, withdraw of ES route by PE1 
would cause DF reelection trigger,

may/may not be within BGP-PIC based resumption

  *   PE1 has died – MH-IPBFD triggers
 *   If PE1 & PE2 also had MH-IPBFD for liveliness check then PE2 can react 
faster
 *   The danger with this scheme is that if path between PE1 and PE2 is 
broken but from both to PE3 is fine,

PE2 will elect itself as primary which results in both being active, EAD/EVI 
will conflict with EAD/ES which is still single-active.

 *   There may be other complication on CE side with LACP becoming active 
and CE doing load-balancing.

All in all – Optimizing packet loss for one way communication may not 
necessarily be beneficial (if TCP, missing ACK will cause re-send anyway).
What would be important is to avoid sustained service blackouts.

Thanks,
Himanshu

From: BESS  on behalf of gangadhara reddy chavva 

Date: Monday, August 12, 2019 at 5:53 PM
To: "UTTARO, JAMES" 
Cc: "Thirumavalavan Periyannan (thiperiy)" , 
"bess@ietf.org" 
Subject: [**EXTERNAL**] Re: [bess] EVPN VPWS BDF forwarding behavior at MH site

Yes, Jim Uttaro, it is related to FXC, please let me know your comments on the 
below proposal.

Regards,
Gangadhar

On Mon, Aug 12, 2019 at 6:45 PM UTTARO, JAMES 
mailto:ju1...@att.com>> wrote:
I assume this discussion applies to FXC ( Flexible Cross Connect )..

Thanks,
  Jim Uttaro

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
gangadhara reddy chavva
Sent: Saturday, August 10, 2019 7:29 AM
To: Thirumavalavan Periyannan (thiperiy) 
mailto:thipe...@cisco.com>>
Cc: bess@ietf.org
Subject: Re: [bess] EVPN VPWS BDF forwarding behavior at MH site

Hi Thiru,

here is the clarifications for your questions.

this is basically primary PE reach ability /  availability can be determined 
through BFD/Multihop BFD, in this case FRR switch can happen very quickly at 
the remote PE, control plane convergence later.

please see in line answers for the below questions:
for faster convergence if we can install the route such that BDF can allow the 
traffic from remote PE towards to multi homed segment, we can forward the 
traffic received from the remote PE.

Gangadhar >> this explains the route programming at multi homed site, if 
elected PE is BDF, program the label path, so that traffic received from remote 
PE will be send to multi homed CE.

at the same time we shouldn't allow the traffic from multi homed site this 
leads to duplicate traffic on the remote PE. to achieve this we should not 
program the path from multi home site towards remote PE until this PE elected 
as DF for that VPWS instance.

Gangadhar >> again this is at BDF, we shouldn't allow the traffic from multi 
homed site CE to remote PE, for this BDF should not program the path towards 
remote PE, so at BDF if there is any traffic from CE will be get  dropped at 
BDF.


I hope this will clarify your question.

Regards,
Gangadhar



On Sat, Aug 10, 2019 at 2:50 AM Thirumavalavan Periyannan (thiperiy) 
mailto:thipe...@cisco.com>> wrote:
Hello Gangadhara,

How remote PE detect the DF failure? It’s based on EVI/AD Withdraw message from 
DF PE if so then NDF PE also received this route and changed its DF status at 
the same time Remote PE changed its nexthop to NEW DF PE.

The below info is not clear, could you please help me to understand.

for faster convergence if we can install the route such that BDF can allow the 
traffic from remote PE towards to multi homed segment, we can forward the 
traffic received from the remote PE.

at the same time we shouldn't allow the traffic from multi homed site this 
leads to duplicate traffic on the remote PE. to achieve this we should not 
program the path from multi home site towards remote PE until this PE elected 
as DF for that VPWS instance.

Thanks,
Thiru

On 09-Aug-2019, at 19:02, gangadhara reddy chavva 
mailto:meetgangadh...@gmail.com>> wrote:
HI All,

i have one question on EVPN VPWS BDF forwarding behavior at MH site.
when PE is selected as BDF, it will communicate the EAD EVI route with B bit 
set to remote PE. so remote PE will install the FRR route with primary path 
towards DF PE and secondary path towards BDF.
when ever 

[bess] FXC draft refresh

[Shah, Himanshu]

Hello authors –

The FXC draft expired last October and needs refreshing.


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

Re: [bess] Call for adoption: draft-rabadan-bess-evpn-pref-df

[Shah, Himanshu]

Support.

Thanks,
Himanshu

From: BESS  on behalf of "Thomas com>" 

Organization: Orange
Date: Tuesday, June 6, 2017 at 9:44 AM
To: "bess@ietf.org" 
Cc: "draft-rabadan-bess-evpn-pref...@ietf.org" 

Subject: [bess] Call for adoption: draft-rabadan-bess-evpn-pref-df

Hello working group,

This email starts a two-week call for adoption on
draft-rabadan-bess-evpn-pref-df-02 [1] as a Working Group Document.

Please state on the list if you support the adoption or not (in both
cases, please also state the reasons).

This poll runs until *the 20th of June*.

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 Contributor of this Document please
respond to this email and indicate whether or not you are aware of any
relevant undisclosed IPR. The Document won't progress without answers
from all the Authors and Contributors.

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-rabadan-bess-evpn-pref-df/

_

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

___
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]

In red..

Thanks,
Himanshu

From: BESS <bess-boun...@ietf.org> on behalf of Sami Boutros 
<sbout...@vmware.com>
Date: Friday, February 24, 2017 at 2:29 PM
To: "Shah, Himanshu" <hs...@ciena.com>, Alvaro Retana <aret...@cisco.com>, 
"draft-ietf-bess-evpn-v...@ietf.org" <draft-ietf-bess-evpn-v...@ietf.org>
Cc: Jeffrey Zhang <zzh...@juniper.net>, "bess-cha...@ietf.org" 
<bess-cha...@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Himanshu,

Please see comments inline.



Hi Sami –

Some more comments for your consideration (based on -09- version) –
Many of the followings are either clarifications related or editorial.

1-

Overall comment : the draft uses long sentences, short sentences are more
favored (at least that is the feedback I used to get for my drafts).

For example:
--- original text --
Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for
   Port-based, vlan-based, and vlan-bundle interface mode and it is set
   to non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS,
   for all the four interface modes, Ethernet tag ID in the Ethernet A-D
   route MUST be set to a non-zero value in all the service interface
   types.

This could be written as –

Ethernet tag ID in Ethernet A-D route MUST be set to a non-zero value
irrespective of the service interface types. This is a deviation from
what is expected for EVPN. In EVPN, Ethernet Tag ID in EVPN routes are
set to zero for Port-based, vlan-based and vlan-bundle interface mode
while non-zero Ethernet tag ID only for vlan-aware bundle mode.


[Sami] We are defining new interface types in other drafts, so we can’t say in 
the above text
For all a service interface types for example, honestly I am not in favor to 
change the text.

[Himanshu] OK. I understand the intent. You note the issue on using 
“irrespective
of service interface types”. You can append that as “irrespective of service
interface types defined in this document”.

But this was a suggestion for better reading. Leave it or take it.. ☺
2-

In section 2.1

Original text ---

If the VLAN is represented by different VIDs on different PEs.
(note there should not be a period here)
[Himanshu] do note the comment on this ‘period’
(e.g., a different VID per Ethernet segment per PE), then each PE needs to
perform VID translation for frames destined to its Ethernet segment.

Comment ---

This particular paragraph is somewhat confusing. The confusing part is
That text seems to indicate that multiple PEs connected to an ES may
see same VLAN as different VID (which I believe is not true).

[Sami] This is not what the text is indicating.

For
example, PE members PE1 and PE2 of same ESx, may see VID 100 for PE1
but 101 for PE2.

[Sami] This is simply not possible, since the source of traffic on the ES is 
one for both PE1 and PE2.

[Himanshu] but of course. That is the point. It needs clarifying and the text
you offer below would work as well.
I believe what you are trying to convey is PEs on
local ES and PEs on remote ES may have different VIDs.

[Sami] I will add to the above text, on different PE (s) and different ES (es) 
instead of different PE (s)

It can be clarified as –

If the VLAN is represented by different VIDs on local PEs (connected
to local ES) and remote PEs (connected to remote ES), then each PE
needs to perform VID translation for frames destined to its Ethernet segment.

---
3- editorial

Original text for page 8 –

A remote PE SHOULD receive P=1 from only one Primary PE and a B-1 from only one 
Backup PE.

Comment –
B=1


[Sami] Sure will fix.

4- clarification

original text –

This allows an ingress PE to perform flow-based load-balancing
of traffic flows to all of the PEs attached to that ES.



Comment --

In multi-homed All-active configuration, this allows an ingress PE to perform
Flow-based load-balancing of traffic flows to all the PEs attached to that ES.

(I am assuming that in VPWS, single active multi-homing, there is load-balancing
from remote to local multi-homed PEs – Right??)

[Sami] Ok I will add that this is for all-active.


Thanks,

Sami

 Thanks,
himanshu
___
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 –

Some more comments for your consideration (based on -09- version) –
Many of the followings are either clarifications related or editorial.

1-

Overall comment : the draft uses long sentences, short sentences are more
favored (at least that is the feedback I used to get for my drafts).

For example:
--- original text --
Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for
   Port-based, vlan-based, and vlan-bundle interface mode and it is set
   to non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS,
   for all the four interface modes, Ethernet tag ID in the Ethernet A-D
   route MUST be set to a non-zero value in all the service interface
   types.

This could be written as –

Ethernet tag ID in Ethernet A-D route MUST be set to a non-zero value
irrespective of the service interface types. This is a deviation from
what is expected for EVPN. In EVPN, Ethernet Tag ID in EVPN routes are
set to zero for Port-based, vlan-based and vlan-bundle interface mode
while non-zero Ethernet tag ID only for vlan-aware bundle mode.


2-

In section 2.1

Original text ---

If the VLAN is represented by different VIDs on different PEs.
(note there should not be a period here)
(e.g., a different VID per Ethernet segment per PE), then each PE needs to
perform VID translation for frames destined to its Ethernet segment.

Comment ---

This particular paragraph is somewhat confusing. The confusing part is
That text seems to indicate that multiple PEs connected to an ES may
see same VLAN as different VID (which I believe is not true). For
example, PE members PE1 and PE2 of same ESx, may see VID 100 for PE1
but 101 for PE2. I believe what you are trying to convey is PEs on
local ES and PEs on remote ES may have different VIDs.

It can be clarified as –

If the VLAN is represented by different VIDs on local PEs (connected
to local ES) and remote PEs (connected to remote ES), then each PE
needs to perform VID translation for frames destined to its Ethernet segment.

---
3- editorial

Original text for page 8 –

A remote PE SHOULD receive P=1 from only one Primary PE and a B-1 from only one 
Backup PE.

Comment –
B=1


4- clarification

original text –

This allows an ingress PE to perform flow-based load-balancing
of traffic flows to all of the PEs attached to that ES.



Comment --

In multi-homed All-active configuration, this allows an ingress PE to perform
Flow-based load-balancing of traffic flows to all the PEs attached to that ES.

(I am assuming that in VPWS, single active multi-homing, there is load-balancing
from remote to local multi-homed PEs – Right??)

--

Thanks,
Himanshu

From: BESS  on behalf of Alvaro Retana 

Date: Friday, February 24, 2017 at 10:17 AM
To: Sami Boutros , "draft-ietf-bess-evpn-v...@ietf.org" 

Cc: Jeffrey Zhang , "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

One more thing…you’re missing the reference to RFC5226.

Thanks!

Alvaro.

___
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] AD Review of draft-ietf-bess-evpn-vpws-07

[Shah, Himanshu]

Works!!

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

From: Sami Boutros <sbout...@vmware.com>
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" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 4:53 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, "Rabadan, 
Jorge (Nokia - US)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Sami Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@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 <hs...@ciena.com<mailto:hs...@ciena.com>>; Rabadan, Jorge 
(Nokia - US) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; Sami 
Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>; Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) <aret...@cisco.com<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 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" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 4:31 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, "Rabadan, 
Jorge (Nokia - US)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Sami Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 

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 <hs...@ciena.com>; Rabadan, Jorge (Nokia - US) 
<jorge.raba...@nokia.com>; Sami Boutros <boutros.s...@gmail.com>; Iftekhar 
Hussain <ihuss...@infinera.com>
Cc: Jeffrey Zhang <zzh...@juniper.net>; Alvaro Retana (aretana) 
<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" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 4:31 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, "Rabadan, 
Jorge (Nokia - US)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, 
Sami Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@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 <hs...@ciena.com<mailto:hs...@ciena.com>>; Rabadan, Jorge 
(Nokia - US) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; Sami 
Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>; Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) <aret...@cisco.com<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



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

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 <hs...@ciena.com>; Rabadan, Jorge (Nokia - US) 
<jorge.raba...@nokia.com>; Sami Boutros <boutros.s...@gmail.com>; Iftekhar 
Hussain <ihuss...@infinera.com>
Cc: Jeffrey Zhang <zzh...@juniper.net>; Alvaro Retana (aretana) 
<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" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:54 PM
To: "Rabadan, Jorge (Nokia - US)" 
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Sami Boutros 
<sbout...@vmware.com<mailto:sbout...@vmware.com>>, Sami Boutros 
<boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar Hussain 
<ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@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 <sbout...@vmware.com<mailto:sbout...@vmware.com>>; Shah, 
Himanshu <hs...@ciena.com<mailto:hs...@ciena.com>>; Sami Boutros 
<boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>; Iftekhar Hussain 
<ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>; Alvaro 
Retana (aretana) <aret...@cisco.com<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

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" 
<sbout...@vmware.com<m

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 <sbout...@vmware.com>; Shah, Himanshu <hs...@ciena.com>; Sami 
Boutros <boutros.s...@gmail.com>; Iftekhar Hussain <ihuss...@infinera.com>
Cc: Jeffrey Zhang <zzh...@juniper.net>; Alvaro Retana (aretana) 
<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" 
<sbout...@vmware.com<mailto:sbout...@vmware.com>> wrote:

Hi Himanshu,


From: "Shah, Himanshu" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Wednesday, February 8, 2017 at 3:04 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, Sami 
Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@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.

[S

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 <hs...@ciena.com>; Sami Boutros <boutros.s...@gmail.com>; 
Iftekhar Hussain <ihuss...@infinera.com>
Cc: Jeffrey Zhang <zzh...@juniper.net>; Alvaro Retana (aretana) 
<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" <hs...@ciena.com<mailto:hs...@ciena.com>>
Date: Tuesday, February 7, 2017 at 12:45 PM
To: Sami Boutros <sbout...@vmware.com<mailto:sbout...@vmware.com>>, Sami 
Boutros <boutros.s...@gmail.com<mailto:boutros.s...@gmail.com>>, Iftekhar 
Hussain <ihuss...@infinera.com<mailto:ihuss...@infinera.com>>
Cc: Jeffrey Zhang <zzh...@juniper.net<mailto:zzh...@juniper.net>>, "Alvaro 
Retana (aretana)" <aret...@cisco.com<mailto:aret...@cisco.com>>, 
"bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" 
<bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, 
"bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, 
"draft-ietf-bess-evpn-v...@ietf.org<mailto:draft-ietf-bess-evpn-v...@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

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

[Shah, Himanshu]

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.

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

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?).

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

So what is the intent?

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

Also, there has to be corresponding understanding/configuration in CE as well.
So if the CE+multi-hommed-PEs configuration is consistent and if all the 
parties,
(CE, multi-homed PEs and remote PE) are aware of this, selection algorithm 
would work better?

Thanks,
Himanshu

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Sami Boutros
Sent: Tuesday, February 07, 2017 2:06 PM
To: 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 Iftekhar,

Are you ok with what I added to the doc? For presenting the entity for 
Management.

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

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

Re: [bess] Poll for adoption: draft-shah-bess-l2vpn-yang

[Shah, Himanshu]

Hi Adrian -

Appreciate your detail review and the comments.
Please see below inline responses to your comments..

Thanks,
Himanshu


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Tuesday, May 24, 2016 8:52 AM
To: 'Thomas Morin'; bess@ietf.org
Cc: draft-shah-bess-l2vpn-y...@tools.ietf.org
Subject: Re: [bess] Poll for adoption: draft-shah-bess-l2vpn-yang

Hi Thomas,

I'm not opposed to this work at all. But I think that the extensive use of the 
word "service" in the document may cause a load of confusion.

As far as I can see, this YANG model is about operating and monitoring the 
network components and protocols that are used to realize (deliver) the service.
This is all information that the network operator (service provider) cares 
about deeply, and that the equipment vendor must understand. But a lot of it is 
beyond the concern (or understanding) of the service consumer who has requested 
the service.

If I might compare with the work of L3SM, we need to distinguish between the 
"service model" on the interface between the customer and the operator, and the 
"service delivery model" on the northbound interface of an orchestrator". It 
may be helpful to consider two separate conceptual components: a "service 
orchestrator" that consumes a service model, and a "network orchestrator" that 
consumes the model in this document and uses it to work out what to tell 
protocols, network controller, etc. 

Perhaps the document could be enhanced by a little extra text explaining how 
the model will be used. This need not be pages and pages, just a simple 
statement that, for example, it is expected that this model will be used by the 
management tools run by network operators in order to manage and monitor the 
network resources that they use to deliver L2VPN services.

[Himanshu>] Agreed. Will clarify the purpose of the draft as you suggest above.


Might I ask also that one sentence is removed from the Abstract *before* 
adoption?
   This is a
   living document and contains aspects of object models that have been
   discussed extensively in the working group with consensus.
It is not the place of the authors to claim consensus for the content of the
document: that call belongs to the WG chairs in response to targeted questions 
to the WG. WG adoption is not a measure by which to determine consensus for the 
content of the document, either.

Additionally, the Introduction has:
   The definition work is undertaken initially by a smaller
   working group with members representing various vendors and service
   providers.
I'm sure you don't mean to imply any subversion of the IETF process, and I am 
equally sure that this is just a matter of English usage.
I think you need...
   The definition work was initially undertaken initially by a small
   group of co-authors with members representing various vendors and service
   providers.

[Himanshu>] Agreed on this as well. Did not mean to shortcut the due process at 
IETF
[Himanshu>] 

Again, this change needs to be made before adoption.

[Himanshu>] 
[Himanshu>] Will update the draft to address your comments in the -00- version 
of the WG draft.
Does that work for you?


Thanks,
Adrian

> -Original Message-
> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas Morin
> Sent: 04 May 2016 15:18
> To: bess@ietf.org
> Cc: draft-shah-bess-l2vpn-y...@tools.ietf.org
> Subject: [bess] Poll for adoption: draft-shah-bess-l2vpn-yang
> 
> Hello working group,
> 
> This email starts a two-week poll on adopting 
> draft-shah-bess-l2vpn-yang [1] as a working group document.
> 
> Please state on the list if you support adoption or not (in both 
> cases, please also state the reasons).
> 
> This poll runs until *May 25th*.
> 
> This call runs in parallel with the adoption call on 
> draft-brissette-bess-evpn-yang hence the extended period.
> 
> 
> We are *coincidentally* also polling for knowledge of any other 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-shah-bess-l2vpn-yang
> 
> ___
> 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] Poll for adoption: draft-shah-bess-l2vpn-yang

[Shah, Himanshu]

Including kamran raza..

Thanks,
Himanshu


-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas Morin
Sent: Wednesday, May 04, 2016 10:18 AM
To: bess@ietf.org
Cc: draft-shah-bess-l2vpn-y...@tools.ietf.org
Subject: [bess] Poll for adoption: draft-shah-bess-l2vpn-yang

Hello working group,

This email starts a two-week poll on adopting draft-shah-bess-l2vpn-yang [1] as 
a working group document.

Please state on the list if you support adoption or not (in both cases, please 
also state the reasons).

This poll runs until *May 25th*.

This call runs in parallel with the adoption call on 
draft-brissette-bess-evpn-yang hence the extended period.


We are *coincidentally* also polling for knowledge of any other
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-shah-bess-l2vpn-yang

___
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] Poll for adoption: draft-shah-bess-l2vpn-yang

[Shah, Himanshu]

Hi Giles -

Thanks for your support.
We will work through your comments as highest priority through the next 
iteration of the draft.

Thanks,
Himanshu

-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Giles Heron
Sent: Friday, May 06, 2016 4:13 PM
To: Thomas Morin; Carl Moberg (camoberg)
Cc: bess@ietf.org; draft-shah-bess-l2vpn-y...@tools.ietf.org
Subject: Re: [bess] Poll for adoption: draft-shah-bess-l2vpn-yang

Hi Thomas,

I support this document being adopted.

However I would like to see the comments that Carl Moberg and I brought to the 
authors in Prague get addressed (they still seem to be outstanding).   Sorry - 
I should have followed up on those before now.

There’s also some degree of overlap with draft-brissette-bess-evpn-yang, and 
with draft-dhjain-bess-bgp-l3vpn-yang-01, and I’d like to see common components 
(e.g. BGP RTs/RDs) being abstracted into common models.

Giles

> On 4 May 2016, at 15:17, Thomas Morin  wrote:
> 
> Hello working group,
> 
> This email starts a two-week poll on adopting 
> draft-shah-bess-l2vpn-yang [1] as a working group document.
> 
> Please state on the list if you support adoption or not (in both cases, 
> please also state the reasons).
> 
> This poll runs until *May 25th*.
> 
> This call runs in parallel with the adoption call on 
> draft-brissette-bess-evpn-yang hence the extended period.
> 
> 
> We are *coincidentally* also polling for knowledge of any other 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-shah-bess-l2vpn-yang
> 
> ___
> 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

Re: [bess] Poll for adoption: draft-brissette-bess-evpn-yang

[Shah, Himanshu]

I support this draft for WG adoption and am not aware
Of any IPR that applies to this draft.

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

From: BESS [bess-boun...@ietf.org] On Behalf Of Patrice Brissette (pbrisset) 
[pbris...@cisco.com]
Sent: Wednesday, May 04, 2016 3:55 PM
To: Thomas Morin; bess@ietf.org
Cc: draft-brissette-bess-evpn-y...@tools.ietf.org
Subject: Re: [bess] Poll for adoption: draft-brissette-bess-evpn-yang

Thomas,

As a co-author, I support this draft.


Regards,

Patrice

   Patrice Brissette
TECHNICAL LEADER.ENGINEERING

pbris...@cisco.com
Phone: +1 613 254 3336

Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Canada
Cisco.com 

 Think before you print.This
 email may contain confidential and privileged material for the sole use
 of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient
(or authorized to receive for the recipient), please contact the sender
by reply email and delete all copies of this message.
Please click here
 for
Company Registration Information.






On 2016-05-04, 10:18 AM, "BESS on behalf of Thomas Morin"
 wrote:

>Hello working group,
>
>This email starts a two-week poll on adopting
>draft-brissette-bess-evpn-yang [1] as a working group document.
>
>Please state on the list if you support adoption or not (in both cases,
>please also state the reasons).
>
>This poll runs until *May 25th*.
>
>This call runs in parallel with the adoption call on
>draft-shah-bess-l2vpn-yang hence the extended period.
>
>
>We are *coincidentally* also polling for knowledge of any other
>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-brissette-bess-evpn-yang
>
>___
>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