Re: [bess] The significance of bypassing DF Election Behavior in the EVPN Fast Reroute draft

[Luc Andre Burdet (lburdet)]

Hi Sasha,

BUM is not in-scope of the draft, it is not redirected;

The Fast-Reroute draft describes 2 behaviours, terminal disposition and 
NDF-bypass. The mechanism is agnostic to the load-balancing mode: one, the 
other, or both behaviours may be applicable. You are right, in A/A the 
“NDF-bypass” is not applicable for ERL

Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com<mailto:lbur...@cisco.com>  |  Tel: +1 
613 254 4814


From: Alexander Vainshtein 
Date: Thursday, November 9, 2023 at 10:41
To: Luc Andre Burdet (lburdet) 
Cc: bess@ietf.org 
Subject: The significance of bypassing DF Election Behavior in the EVPN Fast 
Reroute draft
Luc and 
all,https://datatracker.ietf.org/doc/html/draft-burdet-bess-evpn-fast-reroute-06#section-5.1
I have a question regarding significance of bypassing DF Election behavior in 
Section 5.1 of the EVPN Fast Reroute draft, at least in the case of All-Active 
multi-homing and EVPN-MPLS.

To the best of my understanding, in this case DF Election based filtering is 
applied only to BUM traffic. Per Section 11.2 of RFC 
7432<https://datatracker.ietf.org/doc/html/rfc7432#section-11.2> this traffic 
is carried using the label advertised in the PMSI attribute in the EVPN IMET 
route so that DF Election-based filtering can be applied only to the traffic 
received with this label:

  *   In the case of ingress replication, this label is down-stream allocated 
by the egress PE and therefore would be different from the ERL label
  *   In the case of P-multicast trees, this label would be upstream-allocated 
by the ingress PE and, in the case of non-aggregated tunnels, preceded by the 
label that identifies the P-multicast tree. (I am leaving aside the case of 
aggregated P-multicast trees).
I.e., in both cases, the egress PE can identify the received BUM traffic based 
on the label stack in its EVPN encapsulation and apply DF-Election-based 
filtering just to this traffic – but not to traffic received with the ESL or 
ERL labels.

What, if anything, do I miss?

Regards, and lots of thanks in advance,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon 
Communications Inc. and its Affiliates that is confidential and/or proprietary 
for the sole use of the intended recipient. Any review, disclosure, reliance or 
distribution by others or forwarding without express permission is strictly 
prohibited. If you are not the intended recipient, please notify the sender 
immediately and then delete all copies, including any attachments.
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Chair review of draft-ietf-bess-evpn-mh-pa-08

[Luc Andre Burdet (lburdet)]

Thanks Stéphane, I am uploading v09 shortly.

The missing references to i.e. LACP are actually in the MCLAG section and some 
of the “first expansions” you mention also : I think the best solution is to 
simply move Fig1 down into there.

Let me know what you think

Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com  |  Tel: +1 
613 254 4814


From: Stephane Litkowski (slitkows) 
Date: Wednesday, October 18, 2023 at 05:54
To: draft-ietf-bess-evpn-mh...@ietf.org 
Cc: bess-cha...@ietf.org , bess@ietf.org 
Subject: Chair review of draft-ietf-bess-evpn-mh-pa-08
Hi,

Here is my last review (as WG chair) of the draft, I have also requested a 
GEN-ART review.


Abstract:
Use “RFC7432” as a plain text reference and not as a link (xml xtarget) in the 
abstract.


Introduction:

s/QOS/QoS/

I think this sentence is useless in the text as previous one already mentions 
the same:

“A new type of load-balancing mode,
   Port-Active redundancy, is defined. “

Need to expand MC-LAG on first use

Don’t you need to provide an informative reference for LACP ? you may need to 
expand it on first use.
Also don’t need to say “LACP protocol” , but just say “LACP”, P=protocol.

s/aca tive/active


Section 2:
Refer to LACP and expansion should be intro, not here.

s/must synchronize… data among them/ must synchronize… data between them/


Not able to parse this properly:

“as are LAG misconfiguration and miswiring detection across

   peering PEs.”




Section 3.1:

s/QOS/QoS

Expand DF abbrev (first use)

Section 3.2:

I think the term “Peering PEs” is unclear and may need a better wording.

On Bullet d., it would be worth using some normative language regarding the 
usage of DF election.

Bullet f. first sentence should use normative language IMO. “SHOULD by default 
implement” ? or MUST ?

Should bullet g. use normative language ? Would it be a MAY (optional) or 
SHOULD (if highly recommended) ?


Section 4:

s/ new Port Mode Load-Balancing capability/ new Port Mode Load-Balancing 
capability bit





Section 4.4:

Add reference to pref-df-draft




Section 4.5:

Add reference to RFC8584



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

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

[Luc Andre Burdet (lburdet)]

Hi Adrian,

Thank you for your valuable comments, and apologies for the late reply/update. 
I have incorporated all changes into -v08 which I hope address your feedback: 
some comments are replied to below:


I note that the topic of "updates" was raised by matthew in his review,
and that 2.2 is clear about the changes. I note, however, that the
decision to make this an Update happened after WG last call, and I
wonder whether the owrking group is fully on board with the implication
that any future implementation claiming conformance to 8584 will be
required to implement this specification. There is a difference between
an Update and an additional procedure.

[LAB] It is worth noting that the delay introduced (change to 8584) is by 
default 0 i.e. no change to RFC8584 when the extcomm is not present.
An implementation which does not support this adding a delay of 0 and one 
supporting it but with a delay of 0 would display similar behaviours ?  I can 
defer to Matthew and the WG on this.


Why bit 3? I know the answer is "because that's the bit our
implementation uses" and I'm fine with that and I'm not asking for any
change, but it makes me suspicious about what happened to bits 0 and 2.
Why aren't they used? Is someone squatting on them?

[LAB] yes bits 0 and 2 are in-use already for Preference-Based DF indication;  
Bit 2 is iirc from an old version of this document which was also requesting a 
H=handshake bit, no longer is.  We felt it best to just leave this one at 3 
instead of shifting down. (Bit 5 is also in-use for Port-Mode in another 
document)



I see some challenges here.
The first is when a PE joins the segment while DF election is ongoing
among the other PEs.
The second is what happens if the SCT BGP extended community is present
when the T-bit is not set.
The third is what happens if the T-bit is set but no SCT BGP extended
community is provided.
All of these are easy to describe.

Does the backwards compatibility not describe these already i.e. “SHALL revert 
back to 7432” ?

Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com  |  Tel: +1 
613 254 4814


From: Adrian Farrel via Datatracker 
Date: Saturday, May 27, 2023 at 15:42
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org 

Subject: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07
Reviewer: Adrian Farrel
Review result: Has Issues

Hello

I have been selected to do a Routing Directorate early review of this draft..
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery. I
reviewed revision -07.

The Routing Directorate will, on request from the working group chair, perform
an early review of a draft before it is submitted for publication to the IESG.
The early review can be performed at any time during the draft's lifetime as a
working group document. The purpose of the early review depends on the stage
that the document has reached.

I reviewed revision -07 of this draft after the completion of WG last call and
shepherd review, but before the WG makes a publication request. The purpose of
a review at this stage is to improve the quality before AD review and so reduce
the AD workload as wellas improve the output of the working group and the final
quality of any published RFCs.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-bess-evpn-fast-df-recovery-07.txt
Reviewer: Adrian Farrel
Review Date: 2023-05-27
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved
before it is submitted to the AD.

This document is short and readable. While most of what I found is nits, they
somewhat detract from the clarity of the document. The minor points could do
with small additions to the text to help the reader and smooth the document's
passage through the IESG.

===

Abstract should note that this document updates RFC 8584 and say
(briefly) how. (Note that idnits warned you about this.)

I would put similar text in the Introduction, but that text can have a
pointer to Section 2.2).

I note that the topic of "updates" was raised by matthew in his review,
and that 2.2 is clear about the changes. I note, however, that the
decision to make this an Update happened after WG last call, and I
wonder whether the owrking group is fully on board with the implication
that any future implementation claiming conformance to 8584 will be
required to implement this specification. There is a difference between
an Update and an additional procedure.

---

Abstract

Move "(DF)" to the first use of "Designated Forwarder"

Please expand "EVI" and "PE"

s/via a simple signaling/via simple signaling/

---

Move the requirements language into a new Section 1.1

Please use the correct version of the boilerplate text...

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", 

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-l2gw-proto-03

[Luc Andre Burdet (lburdet)]

Hi Daniele,

Thank you for your valuable comments.  I have incorporated them into -v04, 
which I hope addresses your feedback

> add a reference to G.8032, (M)STP, REP
I did this in the Terminology section, rather than inline in text – I have 
removed references to REP(proprietary, no references) and MPLS-TP mainly 
because including them in the list doesn’t add or remove from the document.

> nice to have a small description of what a VLAN flow is
This is also in the terminology section, I have cross-referenced it a little 
better. I hope this satisfies this comment ?


Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com  |  Tel: +1 
613 254 4814


From: Daniele Ceccarelli via Datatracker 
Date: Thursday, June 29, 2023 at 11:38
To: rtg-...@ietf.org 
Cc: bess@ietf.org , draft-ietf-bess-evpn-l2gw-proto@ietf.org 

Subject: Rtgdir early review of draft-ietf-bess-evpn-l2gw-proto-03
Reviewer: Daniele Ceccarelli
Review result: Has Nits

Hello, this is the first time i do a RTG-DIR review using the new interface. I
hope all the fields are properly filled automatically and mails sent
accordingly.

Please note that the draft in in WG last call and an early review was
requested. I'll assume this is a WG last call review.

All in all the document is almost ready for being progressed. I just suggested
few improvements for better readability and understanding.

Here are my findings:

- Abstract:
1) I would suggest rephrasing into:
"The existing EVPN multi-homing load-balancing modes do not adequately
represent ethernet-segments facing access networks with Layer-2 Gateway
protocols such as G.8032, (M)STP, REP, MPLS-TP, etc. This document defines a
new multi-homing mechanism to support these loop-preventing Layer-2 protocols"

2) My MPLS-TP is a bit rusty, but can it be considered a layer 2 protocol? and
is it loop-preventing?

- Introduction:
1)" Existing EVPN Single-Active and All-Active redundancy modes" add a
reference to where they are defined. 2) you should also add a reference to
G.8032, (M)STP, REP etc 3) same comment to MPLS-TP 4) the rest of the section
is well written and understandable. It would be nice to have a small
description of what a VLAN flow is to better explain why the need to have a
flow active on a PE only but not all on the same.

- 2. Requirements
1) Again references to EVPN L2GW would help. Where do the "following rules"
come from? 2) missing ESI expansions

- Section 3
1)i'd suggest finding a better way to show that the loop is open between CE4
and CE2. On first look i thought the simbol meant that the can be there many
other nodes between CE4 and CE2. 2) it would be nice if the part of section 3
that comes before 3.1 introduced not only the example network but also the
components of the solution. i.e the single-flow-active redundancy mode, fast
convergenge etc

- Section 3.1
1)"Additionally, the reachability between CE1/CE4 and CE2 is achieved with the
forwarding path through the EVPN MPLS/IP core side" does it mean via PE1-PE2?
2)"Therefore, aliasing of [RFC7432] Section 8.4 cannot be performed by PE3."
suggest to rephrase in: Therefore the Aliasing procedure, described in Section
8.4 of [RFC7432] cannot be performed by PE3.

- Section 3.3
I dont' understand why an alternative solution (3.3.1) is described in the
backwards compatibility section. Why not pulling it out from 3.3 and describing
it as an alternative solution with limitations?

- Section 4
This section needs to be alaborated a bit more. As is, it is saying the same
things as the IANA considerations. in addition to that if the document defines
RED 10, why in the IANA considerations you have 00, 01 and 10?


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

Re: [bess] Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

[Luc Andre Burdet (lburdet)]

Hi Matthew,

I had started going through changes but not completed; I will post this week an 
updated version
Thanks for the reminder

Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com  |  Tel: +1 
613 254 4814


From: Matthew Bocci (Nokia) 
Date: Friday, June 30, 2023 at 12:07
To: Adrian Farrel , 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org 

Cc: bess@ietf.org , rtg-...@ietf.org 
Subject: Re: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07
Adrian

Thanks for the RTGDir review.

Authors: Please can you look at the review and address Adrian’s comments.

Regards

Matthew

From: Adrian Farrel via Datatracker 
Date: Saturday, 27 May 2023 at 20:42
To: rtg-...@ietf.org 
Cc: bess@ietf.org , 
draft-ietf-bess-evpn-fast-df-recovery@ietf.org 

Subject: Rtgdir early review of draft-ietf-bess-evpn-fast-df-recovery-07

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Reviewer: Adrian Farrel
Review result: Has Issues

Hello

I have been selected to do a Routing Directorate early review of this draft..
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery. I
reviewed revision -07.

The Routing Directorate will, on request from the working group chair, perform
an early review of a draft before it is submitted for publication to the IESG.
The early review can be performed at any time during the draft's lifetime as a
working group document. The purpose of the early review depends on the stage
that the document has reached.

I reviewed revision -07 of this draft after the completion of WG last call and
shepherd review, but before the WG makes a publication request. The purpose of
a review at this stage is to improve the quality before AD review and so reduce
the AD workload as wellas improve the output of the working group and the final
quality of any published RFCs.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-bess-evpn-fast-df-recovery-07.txt
Reviewer: Adrian Farrel
Review Date: 2023-05-27
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved
before it is submitted to the AD.

This document is short and readable. While most of what I found is nits, they
somewhat detract from the clarity of the document. The minor points could do
with small additions to the text to help the reader and smooth the document's
passage through the IESG.

===

Abstract should note that this document updates RFC 8584 and say
(briefly) how. (Note that idnits warned you about this.)

I would put similar text in the Introduction, but that text can have a
pointer to Section 2.2).

I note that the topic of "updates" was raised by matthew in his review,
and that 2.2 is clear about the changes. I note, however, that the
decision to make this an Update happened after WG last call, and I
wonder whether the owrking group is fully on board with the implication
that any future implementation claiming conformance to 8584 will be
required to implement this specification. There is a difference between
an Update and an additional procedure.

---

Abstract

Move "(DF)" to the first use of "Designated Forwarder"

Please expand "EVI" and "PE"

s/via a simple signaling/via simple signaling/

---

Move the requirements language into a new Section 1.1

Please use the correct version of the boilerplate text...

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

---

1.

Please expand "DF", "EVI", and "PE" on first use.

s/applying Highest/applying the Highest/
s/independent of number/independent of the number/
s/via a simple signaling/via simple signaling/
s/on simple one-way signaling/on a simple one-way signaling/

---

1.2

s/in redundancy group/in a redundancy group/

---

1.2

The RFC Editor will ask you to consider another term in place of
"blackholing". You might choose to retain the term, or you might
think that it is OK to say "packets being dropped if the timer is
too long"

There are quite a few similar uses throughout the document.

---

1.2

   upon re-entry of the packet

I think you mean, "upon the packet re-entering the Ethernet Segment"

---

1.3.

This section is a bit messy because it talks about the "proposed
solution" in text that will eventually become an RFC, and because it
makes cryptic references to mechanisms that have not yet been described.

I am not convinced that you actually need this text (why are you trying
to sell the benefits having already told us there is a problem to be
solved?) but if you want to keep the text, I would suggest that you

Re: [bess] Document shepherd review of draft-ietf-bess-evpn-fast-df-recovery-05

[Luc Andre Burdet (lburdet)]

Thank you Matthew, will update shortly

Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com  |  Tel: +1 
613 254 4814


From: Bocci, Matthew (Nokia - GB) 
Date: Monday, August 8, 2022 at 10:46
To: draft-ietf-bess-evpn-fast-df-recov...@ietf.org 
, bess@ietf.org 
Subject: Document shepherd review of draft-ietf-bess-evpn-fast-df-recovery-05
Authors

As is customary, please find below my document shepherd review of this draft.

The comments are mainly of an editorial nature or suggest improvements to aid 
readability.

Please treat these comments (prepended with MB>) as you would any other working 
group last call comments.

Best regards

Matthew

===

  Fast Recovery for EVPN Designated Forwarder Election
draft-ietf-bess-evpn-fast-df-recovery-05

Abstract

   Ethernet Virtual Private Network (EVPN) solution provides Designated

MB> /Ethernet/The Ethernet

   Forwarder election procedures for multihomed Ethernet Segments.
   These procedures have been enhanced further by applying Highest
   Random Weight (HRW) Algorithm for Designated Forwarded election in
   order to avoid unnecessary DF status changes upon a failure.  This
   draft improves these procedures by providing a fast Designated

MB> /draft/document

   Forwarder (DF) election upon recovery of the failed link or node
   associated with the multihomed Ethernet Segment.  The solution is
   independent of number of EVIs associated with that Ethernet Segment

MB> /of number/of the number

   and it is performed via a simple signaling between the recovered PE
   and each of the other PEs in the multihoming group.

[...]

1.  Introduction

   Ethernet Virtual Private Network (EVPN) solution [RFC7432] is

MB> /Ethernet/The Ethernet

   becoming pervasive in data center (DC) applications for Network
   Virtualization Overlay (NVO) and DC interconnect (DCI) services, and
   in service provider (SP) applications for next generation virtual
   private LAN services.



[...]

   The EVPN specification [RFC7432] describes DF election procedures for

MB> I think you just need to say [RFC7432] describes...



   multihomed Ethernet Segments.  These procedures are enhanced further
   in [RFC8584] by applying Highest Random Weight Algorithm for DF
   election in order to avoid DF status change unnecessarily upon a link
   or node failure associated with the multihomed Ethernet Segment.

MB> I found the above hard to parse. Maybe replace it with:
"These procedures are enhanced further
   in [RFC8584] by applying Highest Random Weight Algorithm for DF
   election in order to avoid unnecessary DF status changes upon a link
   or node failure associated with the multihomed Ethernet Segment."

   [...]

1.1.  Terminology

   Provider Edge (PE):  A device that sits in the boundary of Provider
  and Customer networks and performs encap/decap of data from L2 to
  L3 and vice-versa.

MB> Not sure you need to define PE as it is a well known term, but in any case 
I think
Your definition differs from ones I could find I previous RFCs. Maybe you can 
just delete it.

   Designated Forwarder (DF):  A PE that is currently forwarding
  (encapsulating/decapsulating) traffic for a given VLAN in and out
  of a site.

2.  Challenges with Existing Solution

   In EVPN technology, multiple PE devices have the ability to encap and
   decap data belonging to the same VLAN.  In certain situations, this
   may cause L2 duplicates and even loops if there is a momentary
   overlap of forwarding roles between two or more PE devices, leading
   to broadcast storms.

   EVPN [RFC7432] currently uses timer based synchronization among PE
   devices in redundancy group that can result in duplications (and even
   loops) because of multiple DFs if the timer is too short or
   blackholing if the timer is too long.

   Using split-horizon filtering (Section 8.3 of [RFC7432]) can prevent
   loops (but not duplicates), however if there are overlapping DFs in

MB> I suggest you split the sentence to make it more readable:
"...(but not duplicates). However, if there are..."


   two different sites at the same time for the same VLAN, the site
   identifier will be different upon re-entry of the packet and hence
   the split-horizon check will fail, leading to L2 loops.

[...]


   However, upon PE insertion or port bring-up (recovery event), HRW

MB> Do you mean "...or port bring-up following a recovery event,"?

   also cannot help as a transfer of DF role to the newly inserted
   device/port must occur while the old DF is still active.

 +-+
  +-+| |
  | || |
/ |PE1  || |   +-+
   /  | ||  MPLS/  |   | |---CE3
  /   +-+|  VxLAN/ |   | PE3 |
 CE1 -   |  Cloud  

Re: [bess] A query regarding applicability of EVPN fast failover mechanisms to Port-Active multi-homing draft

[Luc Andre Burdet (lburdet)]

Hi Sasha,

The DF-Election timer is only run on an interface recovery, not on failure, 
e.g. on PE1 PE-CE link recovery.  In step 4.b.ii, there is no timer involved.

Port-active is no different than other DF-election mechanisms: RT4 ES 
withdrawal by PE1 will trigger DF takeover at PE2. I am aware of some 
implementations which have chosen to take PE1’s ES-EAD withdrawal into 
consideration for a pre-emptive DF-takeover by previous-BDF but I am not aware 
of any draft that specifies this.  ES RT-4 and ES-EAD RT-1 are usually fairly 
close in terms of BGP propagation delays anyways.

Hope this helps clarify

Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com  |  Tel: +1 
613 254 4814


From: Alexander Vainshtein 
Date: Thursday, December 9, 2021 at 09:28
To: "draft-ietf-bess-evpn-mh-pa@ietf.org" 

Cc: "bess@ietf.org" 
Subject: A query regarding applicability of EVPN fast failover mechanisms to 
Port-Active multi-homing draft
Resent-From: 
Resent-To: , , 
, , , 
, , 
, , , 
, , 
Resent-Date: Thursday, December 9, 2021 at 09:28

Hi,
A have a question regarding usage of EVPN fast failover mechanisms in 
combination with the port-active multi-homing mode as defined in the 
corresponding 
draft.

Please configure the following scenario:

  1.  There are 3 PEs in the setup: PE-1, PE-2 and PE-3, and an EVI that is 
present in all of them.
  2.  The EVI in PE-1 and PE-2 is attached to a Port-Active MH ES (i.e. 
configuration is consistent) that uses Highest Preference-based Df election 
method
 *   PE-1 is elected as the DF and activates the corresponding local port
 *   PE-2 is elected as the Backup DF (BDF) in accordance with and blocks 
the corresponding port for customer traffic
 *   Both PE-1 and PE-2 advertise per-EVI EVPN Type 1 route for the EVI in 
question (please note that this requires PE-2 to differentiate between failed 
ports and ports that it has decided to deactivate)
  3.  PE-1 learns multiple IP→MAC pairs from the MH ES in question and 
advertises it as an EVPN Type 2 route. As a consequence, PE-3 creates a pair of 
FDB entries for the MAC addresses  in these pairs:
 *   The active FDB entry in each pair entry points to PE-1 (because it has 
advertised an EVPN Type 2 route for the IP→MAC pair) and uses the label 
received in the Label1 field of the corresponding EVPN Type 2 route
 *   The backup  FDB entry in each points to PE-2 (because it has only 
advertised a per EVI EVPN Type 1 route for the EVI in question) and uses the 
label received in the Label field of the per-EVI EVPN Type 1 route
  4.  When the PE-CE link that is part of the MH ES in question fails in PE-1, 
it immediately withdraws the per ES EVPN Type 1 route for this MH ES
 *   As a consequence, PE-3 activates the backup FDB entries for all MAC 
addresses it has learned from PE-1 and starts sending traffic to PE-2
 *   However, withdrawal of the per-ES EVPN-Type 1 route by and of itself 
will not trigger re-election of the DF. As a consequence, the port in PE-2 
shall remain blocked until:

   i.  The EVPN 
Type 4 route advertised by PE-1 for the MH ES in question is withdrawn

 ii.  The DF 
Election timer (started when the EVPN Type 4 route is withdrawn, by default 3 
seconds) expires.

From my POV the above means that known unicast traffic sent by PE-3 toward the 
CEs on the MH ES shall be lost at least for the duration of the DF Election 
timer (could be more if withdrawal of the EVPN Type 4 route by PE-1 is not 
prioritized).  Do I miss something substantial here?

IMHO and FWIW the situation could be improved if the BDF on the Port-Active MH 
ES, upon detection of the per-ES EVPN Type 1 route for the MH ES in question by 
the PE that has been elected as the DF, would immediately assume the DF role 
and activates the corresponding port. But the Port-Active Multi-Homing draft 
does not define such behavior.

Your timely feedback would be highly appreciated.


Regards, and lots of thanks in advance,
Sasha

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


Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

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

Re: [bess] A question regarding DF election for Virtual Ethernet Segments

[Luc Andre Burdet (lburdet)]

I agree.
Shepherd write-up dates to 2019-02-20 and is prior to my -v06/07 rewrite.
There will probably be a RTG-DIR review soon, I will make sure to bring this up 
at that stage when I assign. Are you volunteering Sasha? 

Regards,
Luc André

Luc André Burdet  |  lbur...@cisco.com  |  Tel: +1 
613 254 4814


From: John E Drake 
Date: Tuesday, October 19, 2021 at 09:55
To: Alexander Vainshtein 
Cc: "bess@ietf.org" , Luc André Burdet 
, 
"draft-ietf-bess-evpn-virtual-eth-segment@ietf.org" 

Subject: RE: A question regarding DF election for Virtual Ethernet Segments
Resent-From: 
Resent-To: , , 
, , , 
, , , 
, , , 

Resent-Date: Tuesday, October 19, 2021 at 09:55

Sasha,

You’re most welcome.  RFC 8584 is the key reference as it explicitly updates 
RFC 7432, and I agree that the Virtual ES draft should both reference RFC 8584 
and be compliant with it.

Yours Irrespectively,

John



Juniper Business Use Only
From: Alexander Vainshtein 
Sent: Tuesday, October 19, 2021 9:36 AM
To: John E Drake 
Cc: bess@ietf.org; Luc André Burdet ; 
draft-ietf-bess-evpn-virtual-eth-segment@ietf.org
Subject: RE: A question regarding DF election for Virtual Ethernet Segments
Importance: High

[External Email. Be cautious of content]

John,
Lots of thanks for a prompt and clarifying response!

According to the shepherd’s 
write-up
 the Virtual Ethernet Segment draft is long past its WG LC, while 7432bis draft 
is still in its early stages.
Therefore I think the former should be updated to avoid any further 
misunderstanding.


My 2c,
Sasha

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

From: John E Drake mailto:jdr...@juniper.net>>
Sent: Tuesday, October 19, 2021 3:29 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
draft-ietf-bess-evpn-virtual-eth-segment@ietf.org
Cc: bess@ietf.org; Luc André Burdet 
mailto:laburdet.i...@gmail.com>>
Subject: [EXTERNAL] RE: A question regarding DF election for Virtual Ethernet 
Segments

Sasha,

Thanks for catching this, as it is a remnant.  Please see 
https://datatracker.ietf.org/doc/html/rfc8584#section-1.1,
 
https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-01#section-3,
 and 
https://clicktime.symantec.com/3LpRvM7ZQnWHJnT2jPntZH56H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-rfc7432bis-01%23section-8.5.

Yours Irrespectively,

John



Juniper Business Use Only
From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Sent: Tuesday, October 19, 2021 7:57 AM
To: 
draft-ietf-bess-evpn-virtual-eth-segment@ietf.org
Cc: bess@ietf.org; Luc André Burdet 
mailto:laburdet.i...@gmail.com>>
Subject: A question regarding DF election for Virtual Ethernet Segments
Importance: High

[External Email. Be cautious of content]

Hi,
I have a question regarding Section 4.1 of the Virtual Ethernet Segment 
draft.
This section describes the default DF election procedure defined in RFC 7432 
for virtual Ethernet Segments and says in item 3 (the problematic text is 
highlighted):

Assuming a redundancy group of N PE nodes, the PE with ordinal i is the DF for 
an EVPN instance with an associated Ethernet Tag value of V when (V mod N) = i

My question is, what does the associated Ethernet Tag mean in this context?
Specifically, if the EVI that is attached to the 

Re: [bess] Shepherd's Review of draft-ietf-bess-evpn-pref-df

[Luc Andre Burdet (lburdet)]

Hi Jorge,

Sorry for the imprecise language, this was indeed about Highest-Preference vs. 
Lowest-Preference algo.

Seems we can agree on Option 2.
I think my wording below betrayed what my preference was  and option 2 is 
definitely the best approach in my book (easiest backward-compatibility and 
fallback to 7432).

It’s obviously best to have values 2 & 3 side by side but I acknowledge that 
may not be possible... TBD for the Algo value is fine for now.
I *think* 3 is free, the only place I see it mentioned is in the Multicast-DF 
draft and that’s claiming 4 & 5. It refers to 3 which is actually just the 
NTP-capability flag not a DF-Algo.

Regards,
Luc André

From: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Date: Monday, March 8, 2021 at 11:02
To: Luc André Burdet , "slitkows.i...@gmail.com" 

Cc: "draft-ietf-bess-evpn-pref...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] Shepherd's Review of draft-ietf-bess-evpn-pref-df

Hi Luc,

Thanks for your email.
A few comments:


  1.  You mention the lowest-ip vs highest-ip debate, but I don’t think there 
is any debate about the PE’s IP. In the document the PE’s IP is used as a last 
resort tie-breaker, and it is always the lowest IP the one chosen assuming 
Preference and DP are equal. There was never ambiguity about that. If you want 
to use the lowest vs highest IP as the input for DF election I would suggest 
you use another Alg value and define it. However I don’t see much value on it, 
since the PE’s IP is not very useful for DF election (it is not easy to change 
and it is common to all the ESes).



  1.  Then you are talking about highest vs lowest weight. I *guess* you mean 
the “DF Preference” value? Note there is no “weight" defined in 
draft-ietf-bess-evpn-pref-df



  1.  Assuming (2) is a yes, about your three options:
 *   I’m personally ok to signal highest vs lowest preference (option 2). I 
can make the change and run it by the other authors.
 *   I think Option 3 has issues since, remember there have been 
implementations for quite a long time now, and those implementations didn’t use 
any flag to indicate lowest-pref.
*   If you do this with option (3), suppose you have an existing 
implementation using type 2 with flag=0 (PE1), and a new one using type 2 with 
flag=1 (PE2).
*   When PE1 and PE2 exchange ES routes, you want them to fall back to 
default Alg as in RFC8584. However PE1 will never do that.
*   If we do (2), PE1 and PE2 can fall back to the default Alg.



  1.  Suppose we agree on defining a new Alg for lowest-preference. Note that 
value 3 *may not* be available. For the moment we should use a TBD value.

About the ‘D’ capability, this document should state that it does not change 
anything for Alg 0 or 1, which are the ones in RFC8584. Other documents will 
have to define whether ‘D’ applies to other DF types other than 2 (and the new 
TBD for lowest-preference).

Let me know your thoughts please.

Thanks.
Jorge


From: Luc André Burdet 
Date: Wednesday, March 3, 2021 at 2:42 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) , 
slitkows.i...@gmail.com 
Cc: draft-ietf-bess-evpn-pref...@ietf.org 
, bess-cha...@ietf.org 
, bess@ietf.org 
Subject: Re: [bess] Shepherd's Review of draft-ietf-bess-evpn-pref-df
Hi Jorge,

Stéphane, Satya and I have gone over this draft again and propose the following 
regarding the Lowest-IP vs. Highest-IP debate.

Option 1
Pick one, e.g. draft explicitly states highest-weight wins. Removes all 
ambiguity.

Option 2:
Support Lowest-weight and Highest-weight both, and it must be signaled.
Signaling is done using DF-Algorithm types:

-  DF-Type=2 : Preference-DF, Highest-weight

-  DF-Type=3 : Preference DF, Lowest-weight
. Example/precedent for this approach:  
draft-ietf-bess-evpn-per-mcast-flow-df-election
  claims 2 DF-Types for each S,G and *,G DF election (ignoring that the draft 
is in serious need of revision)
. 7432-fallback if non-agreement (type2<>type3)
. forward-compatible with existing implementations: DF-Type 2 with default 
Highest-wt.

Option 3:
Support Lowest-weight and Highest-weight both, and it must be signaled.
Signaling is done using a Flag in the DF-Elect extcomm

-  DF-Type=2 : Preference-DF

-  DF-Elect ExtComm:  specify a Flag: 0=Highest, 1=Lowest.
. 7432-fallback if non-agreement (flag) is more complicated on an EC
. doesn’ match other WG documents’ approach
. forward-compatible with existing implementations: DF-Type 2 with Fl=0.
. minimal support would be alarming based on flag mismatch
. must use ‘Reserved’ and NOT capability bitmap because that would require 
analysis against all other DF Algo modes.


Speaking for myself, I would add that  ‘D’ bit capability is a generic flag 
across DF Type Algos.  Evaluation against all existing DF-types must be done 
but... I would remove the ‘all other DF-types SHOULD ignore’.
Many other DF types may want to leverage and I think it is 

Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming

[Luc Andre Burdet (lburdet)]

Hi Chalu,

Please read 7432 s.8.4: in single-active it is not an aliasing label/procedure 
but a backup-path procedure.
It will answer your questions (both, actually).

There is no flooding once the MAC is learnt & distributed: cf. that’s the point.


[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]




Luc André Burdet
lbur...@cisco.com
Tel: +1 613 254 4814






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







From: BESS  on behalf of chalapathi andhe 

Date: Wednesday, March 6, 2019 at 04:15
To: "bess@ietf.org" 
Cc: Sean Wu , Jaikumar Somasundaram 
, "chalapathi.an...@ericsson.com" 

Subject: Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming



Hi All,

Can you please help us on the following issue.
In the following diagram, PE1, PE2, PE3 are connected to the same ES [ES1] in 
Single active mode, and PE4 is a remote PE.
Let’s say PE1 is advertising the MAC1 route, PE4 will install the MAC1 with the 
PE1 as primary path with MAC Label,
and PE2, PE3 as backup with the Alias Label. Now if the PE1 to CE1 link goes 
down, then PE1 withdraw the EAD/ES route
which will be processed by PE4.
Now what should the forwarding state at PE4 ?, PE4 should update the forwarding 
state of MAC1 with the PE2, PE3 Alias label
and any traffic destined to MAC1 should be flooded to PE2, PE3 with the Alias 
labels ?
Or packet should be flooded to PE2, PE3 with the Flood labels ? Or should it be 
some other method ?

In similar if the ES is operating in all active mode, what should be the 
forwarding state at PE4 ?
PE4 should update the forwarding state of MAC1 with the PE2, PE3 Alias label
and any traffic destined to MAC1 should be sent to either PE2 or PE3 with the 
Alias labels [ not flood to both] ?
Or packet should be flooded to PE2, PE3 with the Flood labels  or Alias Label ?
Or should it be some other method ?


[cid:1695247dcc04ce8e91]


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

Re: [bess] Review on draft-ietf-bess-evpn-yang-06

[Luc Andre Burdet (lburdet)]

Hi Sasha, Tim,

Apologies for not sending a response to your prior email; Your comments were 
noted and intend to update the draft this week.

Thanks,
Luc André


[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]




Luc André Burdet
lbur...@cisco.com
Tel: +1 613 254 4814






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







From: BESS  on behalf of Alexander Vainshtein 

Date: Sunday, March 3, 2019 at 05:46
To: Yu Tianpeng , 
"draft-ietf-bess-evpn-yang.auth...@ietf.org" 

Cc: "bess@ietf.org" 
Subject: Re: [bess] Review on draft-ietf-bess-evpn-yang-06

Dear all,
I concur with Tim’s comment regarding representation of ESI in  
draft-ietf-bess-evpn-yang-06.

I have raised similar concerns in an 
email 
to the authors of the draft and to the WG  last August (when the draft was 
still at its -05 version).
Unfortunately, I did not receive any response, nor were my concerns addresses 
in the -06 version of the draft.

My 2c,
Sasha

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

From: BESS  On Behalf Of Yu Tianpeng
Sent: Saturday, March 2, 2019 9:31 PM
To: draft-ietf-bess-evpn-yang.auth...@ietf.org
Cc: bess@ietf.org
Subject: [bess] Review on draft-ietf-bess-evpn-yang-06

Dear authors and WG,
I had a review on draft-ietf-bess-evpn-yang-06.
This draft covers most of the evpn/vpws scenarios, but there are some points I 
would like to discuss.

For small points that do not impact the architecture of the yang data model, I 
have made changes in a new yang file directly (attached), which will be easier 
to understand.
Also, some comments related to the structure of the data model in the final.
Appreciate authors and WG can have a review on comments and proposed changes 
below.
Thanks in advance.
Regards,
Tim
=
Changes:
ietf-ethernet-segment.yang
1. esid-type defined. current uint32 cannot cover 10 octs ESI. We can either 
use a string with a regex or uint64 with a range. in the attachment is the 
regex.
2. change key to esi instead of "name", the name looks like a string or a 
description to me, cannot be used as the key.
3. add new leaf "interface" to indicate which ESI applied to which interface.
4. BGP parameters are deleted, I don't think RD RT are concepts related with 
ES. I have put a new leaf es-list in the EVPN yang data model providing links 
between ES and EVPN yang
5. change of VLAN type to unit16 with range limit

ietf-evpn.yang
1. evpn label mode function added
2. re-write RD RT part as rt-types:vpn-route-targets is a list type already, an 
extra level of list definition in EVPN is not needed anymore.
3. ES list leaf added. This leaf provides a list indicating ESs bound to the 
EVPN instance.
4. control word and MTU added
5. statistics part re-structure.
6. change the counter type from uint32 to counter64 to avoid overflow.
7. interface type leaf added, the previous vpws-vlan-aware deleted. reason: all 
interface type should be covered across EVPN and VPWS

General comments:
1. In EVPN yang, I would suggest to re-structure current content as below 
instead of one evpn container :
- EVPN general: RD, RT, name, etc.
- EVPN ELAN/VPWS/E-TREE specifics: BUM, leaf indication, proxy.. and use the 
generals to get yang data model for each scenario.

2. EVPN parameters are not registered under /ni:network-instances and /pw: 
pseudowires. Now only very few info registered






___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___

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

Re: [bess] Mirja Kühlewind's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)

[Luc Andre Burdet (lburdet)]

That's an interesting point Mirja.

A rogue PE/agent could foreseeably inject via BGP an ES Route Type 4 with no DF 
Alg extended community and "bring down" a peering group to the default DF 
election (common denominator). Repetitive inject-delete could cause 
considerable churn and disruption as the target peers repetitively accept, and 
remove this rogue PE/nexthop from the forwarding determination and flip-flop DF 
Alg.

The only way to prevent this, would be for the "federation of peers" to 
(independently) come to a unanimous conclusion to accept, or reject, this new 
peer into their peering group (based on.. peer's reputation? Or?) In the end, 
however, ...this also applies to 7432 as-is with default algorithm.
The net effect of such an attack would be no different than RFC7432 where a 
rogue PE injecting/deleting itself (its nexthop) from the DF election is 
causing churn and disruption.

The other attack vector is not new to this draft, but from 7432. A rogue PE 
with knowledge of the {VLAN/VPN, ESI and peers-list} can conceivably advertise 
in BGP the correct IP/nexthop value, leveraging the default DF Alg to 
steer/attract VPN traffic towards himself. But this is a 7432 attack vector, 
not new/introduced by this draft.

I think if the draft reflects similar to 7432 (peers must be consistently 
configured), then parallels to the security aspect of 7432 are sufficient?

Thanks,

Luc André Burdet
lbur...@cisco.com
Tel: +1 613 254 4814
Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com 
 

On 2019-01-15, 10:57, "BESS on behalf of Mirja Kuehlewind (IETF)" 
 wrote:

Hi Jorge,

thanks! I guess the security consideration could say even more, e.g. that 
this behavior could be exploited by an attack that relies on the default 
mechanism. And is there anyway to hinder this attack? That should be discussed 
as well.

Mirja

 

> Am 15.01.2019 um 16:49 schrieb Rabadan, Jorge (Nokia - US/Mountain View) 
:
> 
> Mirja,
> 
> Thank you very much for reviewing.
> Please see in-line with [JORGE].
> Thx
> Jorge
> 
> -Original Message-
> From: Mirja Kühlewind 
> Date: Thursday, January 10, 2019 at 12:16 PM
> To: The IESG 
> Cc: "draft-ietf-bess-evpn-df-election-framew...@ietf.org" 
, Stephane Litkowski 
, "bess-cha...@ietf.org" , 
"stephane.litkow...@orange.com" , 
"bess@ietf.org" 
> Subject: Mirja Kühlewind's No Objection on 
draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)
> Resent-From: 
> Resent-To: , , 
, , , 

> Resent-Date: Thursday, January 10, 2019 at 12:16 PM
> 
>Mirja Kühlewind has entered the following ballot position for
>draft-ietf-bess-evpn-df-election-framework-07: No Objection
> 
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
> 
> 
>Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
> 
> 
>The document, along with other ballot positions, can be found here:
>
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/
> 
> 
> 
>--
>COMMENT:
>--
> 
>First one minor editorial comment:
>Sec 3.2 "Otherwise if even a single advertisement for the type-4 route 
is
>   not received with the locally configured DF Alg and capability,
>   the Default DF Election algorithm (modulus) algorithm MUST be
>   used as in [RFC7432]."
>I believe you meant a single advertisement is received without the 
configured
>DF Alg and capability (or a different one I guess), and not that the
>advertisement is not received at all (because that might be hard to 
check),
>right? Maybe you can rephrase this sentence a bit to make the 
intention more
>clear!
> [JORGE] we changed it to the following:
> " - Otherwise if even a single advertisement for the type-4 route is 
received without the locally configured DF Alg and capability, the Default DF 
Election..."
> 
>However, think about this further, I wondering if there is something 
here that
>such be discussed in the security considerations, e.g. how easy would 
it be for
>an attacker to disturb the algo selection and cause a fallback to the 
default
>scheme...?
> [JORGE] yep, good point. We added this in the security section, also 
based on the comments from another reviewer:
> "Note that the network will not benefit of the new procedures if the DF 
Election Alg is not 

Re: [bess] A question about RFC 8317

[Luc Andre Burdet (lburdet)]

Sasha,
I would add only to Jorge’s response that in your topology below:
“PE3 would flood anything for which MAC DA is unknown to both local ESes.”
For traffic in the reverse direction (Leaf@PE3 -> Root@PE1) you’d want to add 
an administratively configured split-horizon between green and blue ACs at PE2 
& PE3 because otherwise you may locally switch(or flood) leaf-leaf at PE2/PE3 
which should be disallowed.

Regards,
Luc André

[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]




Luc André Burdet
lbur...@cisco.com
Tel: +1 613 254 4814






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







From: BESS  on behalf of "Rabadan, Jorge (Nokia - 
US/Mountain View)" 
Date: Thursday, December 20, 2018 at 12:32
To: Alexander Vainshtein , "Ali Sajassi 
(sajassi)" 
Cc: "John E Drake (jdr...@juniper.net)" , "Samer Salam 
(ssalam)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "bess@ietf.org" 
Subject: Re: [bess] A question about RFC 8317

Hi Sasha,

What you are explaining is correct.

PE3 would flood anything for which MAC DA is unknown to both local ESes. That 
is normal behavior, only that in this case CE-1’s MAC will not be learned on 
PE3 until CE-1 hashes the traffic to PE3 and not only PE2 (which will happen if 
you have a decent number of flows). *Technically speaking*, the E-Tree solution 
works since you don’t have leaf-to-leaf communication. However, I would not use 
the two RT solution in this scenario since it could create unnecessary flooding 
to local ESes as you describe.

For this scenario I would always use a single RT per EVI, ingress filtering for 
unicast (based on the leaf indication on MAC/IP routes), and egress filtering 
for BUM based on leaf label, as explained in RFC8317.

My two cents.

Thank you.
Jorge


From: Alexander Vainshtein 
Date: Thursday, December 20, 2018 at 12:30 PM
To: "Ali Sajassi  (saja...@cisco.com)" 
Cc: "Samer Salam (ssalam)" , "John E Drake 
(jdr...@juniper.net)" , "ju1...@att.com" , 
"sbout...@vmware.com" , "Rabadan, Jorge (Nokia - 
US/Mountain View)" , "bess@ietf.org" 
Subject: A question about RFC 8317

Ali and all,
I have read RFC 8317, and I would like to 
clarify a question dealing with Leaf ACs of an EVPN-based E-Tree service on 
All-Active Multi-Homed Ethernet Segments (MH ES).

The reference model for my question is shown in the Embedded diagram below.


[cid:image002.png@01D49865.895588B0]

It shows an EVPN E-tree service with one Root customer site and two leaf 
customer sites, where each Leaf CE is dual-homed to the same pair of PEs using 
two different All-Active multi-homed Ethernet Segments.

Suppose that the scheme with two RTs (one identifying the Root site and the 
other identifying the Leaf sites) is used as described in 4.3.1.

Suppose also that each MAC-VRF uses per MAC-VRF label assignment as defined in 
section 9.2.1 of RFC 7432, i.e., advertises exactly one EVPN application label 
that identifies it as the Egress MAC-VRF, while the disposition of the received 
Ethernet frame within this MAC-VRF is based on the destination MAC address. In 
this case the per MAC-VRF label can be also used as the “aliasing” label in the 
per EVI EAD route.

PE-1 will receive and accept per EVI EAD routes for both MH ES for PE-2 and 
PE-3 with the corresponding “aliasing” labels.

Suppose that MAC-VRF in PE-2 learns some {MAC, IP} pair  {X, Y}  locally from 
the Leaf CE-1 and advertises this pair in the EVPN MAC/IP Advertisement route. 
With the “two RTs” scheme this route will be accepted by the MAC-VRF in PE-1 
but it will not be accepted by the MAC-VRF in PE3. As a consequence:

-  MAC-VRF in PE-1 will know that this pair has been learned from the 
“blue” all-active MH ES, and therefore can decide to send locally received 
unicast frames with destination MAC address X to PE-3 using the corresponding 
“aliasing label”. No other labels will be included in the EVN encapsulation of 
such  frames because they are received from the Root AC.

-  MAC-VRF in PE-3 will not know anything about MAC address X, 
therefore, when it receives an EVPN-encapsulated frame with this destination, 
it will treat it as an “unknown unicast” and flood it to both Leaf CE-1 (where 
it should be sent) and to Leaf CE-2 (where it should not be sent).

Is this what is really supposed to happen in this scenario? If not, what did I 
miss in the E-tree EVPN solution?

Regards, and lots of thanks in advance,
Sasha

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


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, 

Re: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

[Luc Andre Burdet (lburdet)]

Hi Sasha,

I agree the vES draft does not go in great detail about A/A PWs.

For A/A PWs terminating at peering PEs, the concept is similar to LAG, using 
static label at peering PEs:

  *   The CE sets up a single PW to remote endpoint to anycast IP1, Label1.
  *   PE1, PE2 set up a PW each to CE, using local static label Label1.
  *   PE1,PE2 adv IP1 as anycast IP towards CE-side
There will not be excessive MAC-moves since the CE sees only one pseudowire to 
a single remote—very similar to what is done for LAG on “real” links.

We can update the draft to be more descriptive—that draft needs a re-read 
anyways, the header on each page still reads “PBB-EVPN” ☺

HTH,
Luc André

[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]




Luc André Burdet
lbur...@cisco.com
Tel: +1 613 254 4814






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







From: BESS  on behalf of Alexander Vainshtein 

Date: Tuesday, September 25, 2018 at 06:25
To: "draft-sajassi-bess-evpn-virtual-eth-segment.auth...@ietf.org" 

Cc: Michael Gorokhovsky , Alexander Ferdman 
, Shell Nakash , 
"bess@ietf.org" 
Subject: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A 
Question

Dear authors of the EVPN Virtual Ethernet 
Segment
 draft,
My colleagues and I have a question pertaining to support of All-Active 
redundancy mode in EVPN that uses virtual Ethernet Segments.

Section 8.5 of RFC 7432 says:

   If a bridged network is multihomed to more than one PE in an EVPN
   network via switches, then the support of All-Active redundancy mode
   requires the bridged network to be connected to two or more PEs using
   a LAG.

   If a bridged network does not connect to the PEs using a LAG, then
   only one of the links between the bridged network and the PEs must be
   the active link for a given  or .  In this
   case, the set of Ethernet A-D per ES routes advertised by each PE
   MUST have the "Single-Active" bit in the flags of the ESI Label
   extended community set to 1.

This restriction is easy to understand, since, with the All-Active multi-homing 
mode of an Ethernet Segment, a CE attached to such a segment potentially would 
receive traffic from all the PEs attached to this  segment. Since A CE that is 
part of a bridged network must learn MAC addresses of the received traffic, it 
would potentially experience continuous MAC Move events – with undesirable 
consequences.

The EVPN Virtual Ethernet Segment draft replaces Ethernet links (forming a 
“real” ES) with Ethernet PWs, and claims support of both Single-homed and 
multi-homed multi-homing modes. When I compare these claims with the quoted 
above statement from RFC 7432, I see two possibilities:

  *   Either a CE that is connected to an All-Active vES cannot be part of a 
bridged network (and thus would not do any MAC learning)
  *   Or  an extension of LAG that deals with Ethernet PWs instead of Ethernet 
links is required.

Could you please clarify which of these two options is correct?

Note: The draft includes Informative references to the two drafts that have 
been published as RFC 7432 and RFC 7623.

Regards,
Sasha

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


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___

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

Re: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05

[Luc Andre Burdet (lburdet)]

Support.

This is an important draft and is implemented;

?

?(1) I echo Acee's comment re: "Router MAC" for readability


(2) The document often refers to two Route-targets (MAC-VRF & IP-VRF) which is 
overly restrictive.

I would propose language more to the effect of MAC/IP must be advertised with 
two sets of RTs


RFC7432:  EVPN route MAY carry one or more Route Target (RT) attributes..?

vs. for example:

   This route MUST be advertised with two route targets - one
   corresponding to the MAC-VRF of the tenant's subnet and another
   corresponding to the tenant's IP-VRF.


Thanks,

Luc André? Burdet



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

Sent: August 8, 2018 10:03 AM
To: bess@ietf.org
Subject: [bess] new WGLC for draft-ietf-bess-evpn-inter-subnet-forwarding-05


Hello working group,



This email starts a two-week Working Group Last Call on 
draft-ietf-bess-evpn-inter-subnet-forwarding-05 [1].



A significant amount of update has been introduced since the previous WGLC. 
Please review the updates and provide your feedback.



This poll runs until *the 22th of August*.





Thank you



Stéphane, Matthew

bess chairs



[1] 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [bess] WG adoption poll and IPR poll for draft-sajassi-bess-evpn-per-mcast-flow-df-election

[Luc Andre Burdet (lburdet)]

Support adoption by WG
Regards,
Luc André Burdet


From: BESS  on behalf of "Samir Thoria (sthoria)" 

Date: Thursday, August 9, 2018 at 5:45 PM
To: "stephane.litkow...@orange.com" , 
"bess@ietf.org" 
Subject: Re: [bess] WG adoption poll and IPR poll for 
draft-sajassi-bess-evpn-per-mcast-flow-df-election

Support the adoption as co-author. I am not aware of any other undisclosed IPR.

Thanks
Samir.


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

Date: Wednesday, August 8, 2018 at 6:38 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption poll and IPR poll for 
draft-sajassi-bess-evpn-per-mcast-flow-df-election

Hi WG,

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-per-mcast-flow-df-election-01 [1]

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

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

The poll for working group adoption closes on Wed 22th Aug.

Regards,
Stéphane and Matthew

[1] 
https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-per-mcast-flow-df-election/




_



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

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

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

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



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

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

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

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

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

Re: [bess] Reg: RFC7432 EVPN - ES-import RT

[Luc Andre Burdet (lburdet)]

Hi Prasanna,

FYI the ES-Import auto-extraction is expanded to ES Type 0,4,5 in 
https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-03#section-3.3.

Thanks
Luc André

[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]




Luc André Burdet
lbur...@cisco.com
Tel: +1 613 254 4814






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







From: BESS  on behalf of "Mankamana Mishra (mankamis)" 

Date: Friday, June 29, 2018 at 11:24 AM
To: Prasannakumara S 
Cc: "bess@ietf.org" 
Subject: Re: [bess] Reg: RFC7432 EVPN - ES-import RT

Hi Prasanna,



On Jun 29, 2018, at 6:30 AM, Prasannakumara S 
mailto:prasannakumar...@ipinfusion.com>> wrote:

Hi All,

Related sections are:
https://tools.ietf.org/html/rfc7432#section-5
https://tools.ietf.org/html/rfc7432#section-7.6

Would like to understand how ES-import RT should behave in case of

1. ESI type 1 - statically configured
In this case on what basis one should import the ESI route as ES-import RT 
does not talk about ESI type 1. Why this should not follow the same semantics 
of creating ES-import RT as done for ESI Type 2; with the 6 high-order octates? 
If same ESI is configured in different VTEPS then it would still work.
This question comes because manually configuring the manual RT is tough to meet 
multiple combinations of multihomed sites.

 - Type 1 (T=0x01) - When IEEE 802.1AX LACP is used between the PEs

 and CEs, this ESI type indicates an auto-generated ESI value

 determined from LACP by concatenating the following parameters:



 + CE LACP System MAC address (6 octets).  The CE LACP System MAC

   address MUST be encoded in the high-order 6 octets of the ESI

   Value field.



 + CE LACP Port Key (2 octets).  The CE LACP port key MUST be

   encoded in the 2 octets next to the System MAC address.



 + The remaining octet will be set to 0x00.



 As far as the CE is concerned, it would treat the multiple PEs that

 it is connected to as the same switch.  This allows the CE to

 aggregate links that are attached to different PEs in the same

 bundle.



 This mechanism could be used only if it produces ESIs that satisfy

 the uniqueness requirement specified above.

I do not think, Type 1 is statically configured.


And if question was about


   - Type 0 (T=0x00) - This type indicates an arbitrary 9-octet ESI

 value, which is managed and configured by the operator.
Should it not be up to implementation to decide if they want to derive 
ES-import RT with 6 high-order octates  ?




2. ESI type 3 - MAC based ESI of the PE
If MAC of the PE is considered then how different PE's can produce the same 
unique ESI? instead it should have used CE's MAC address?
Since last/hig-order 6 octets are used for import how RT-import works?

There is already Type 1 defined (Pasted above) which uses CE’s MAC address.

As mentioned in https://tools.ietf.org/html/rfc7432#section-7.6 Auto derivation 
is only for Type 1, 2 , and 3. For other types, Admin would be responsible to 
configure correct ES-import RT.



Let me know if I am missing something.

Please refer me to any other drafts which are trying to address this; I can 
discuss over there and be part of that.

Thanks in advance.

Regards,
Prasanna


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

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

Re: [bess] WG adoption and IPR poll for draft-sajassi-bess-evpn-fast-df-recovery-02

[Luc Andre Burdet (lburdet)]

Support. I am not aware of any relevant undisclosed IPR.

Thanks,

Luc André Burdet
lbur...@cisco.com
Tel: +1 613 254 4814






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







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

Date: Monday, May 14, 2018 at 5:48 AM
To: "bess@ietf.org" 
Subject: [bess] WG adoption and IPR poll for 
draft-sajassi-bess-evpn-fast-df-recovery-02

Hi WG,

This email begins a two-week poll for BESS working group adoption of 
draft-sajassi-bess-evpn-fast-df-recovery-02 [1].

Please review the draft and post any comments to the BESS working group list, 
stating whether or not you support adoption.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.

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

The poll for working group adoption closes on Monday 28th May.

Regards,
Stéphane and Matthew

[1] https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-fast-df-recovery/



[Orange logo]

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

  NEW !
mobile: +33 6 71 63 27 50 

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


_



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

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

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

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



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

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

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

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

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

Re: [bess] WG Last Call and IPR Poll for draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

[Luc Andre Burdet (lburdet)]

Support.

Thanks Ali for comment responses and taking into consideration. Cisco has been 
shipping an implementation of this since -00 timeframe.

Regards,

Luc André Burdet


From: BESS  on behalf of "Bocci, Matthew (Nokia - GB)" 

Date: Thursday, March 29, 2018 at 4:47 AM
To: Alexander Vainshtein , "Ali Sajassi 
(sajassi)" 
Cc: "draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org" 
, "bess-cha...@ietf.org" 
, "bess@ietf.org" 
Subject: Re: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Thanks for the quick turnaround.

Folks, please focus any further review and comments on the new v02 of the draft:

https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/

Regards

Matthew

From: Alexander Vainshtein 
Date: Thursday, 29 March 2018 at 06:55
To: "Bocci, Matthew (Nokia - GB)" , "Ali Sajassi 
(sajassi)" 
Cc: "bess-cha...@ietf.org" , 
"draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org" 
, "bess@ietf.org" 

Subject: Re: WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Ali and all,
I have looked up the -02 revision of the draft, and the texr looks much more 
mature now.
I will read it again and send technical comments (if any) next week as well as 
my position regarding its support.
Thumb typed by Sasha Vainshtein


From: Ali Sajassi (sajassi) 
Sent: Thursday, March 29, 2018 7:20:16 AM
To: Alexander Vainshtein; Bocci, Matthew (Nokia - GB)
Cc: bess-cha...@ietf.org; draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org; 
bess@ietf.org
Subject: Re: WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Hi Sasha,

Thanks for your comments. I took care of them all in rev02 of the document that 
I just posted.

Cheers,
Ali

From: Alexander Vainshtein 
Date: Wednesday, March 28, 2018 at 7:32 AM
To: "Bocci, Matthew (Nokia - GB)" 
Cc: "bess-cha...@ietf.org" , 
"draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org" 
, "bess@ietf.org" 

Subject: RE: WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt
Resent-From: 
Resent-To: Cisco Employee , , 
, 
Resent-Date: Wednesday, March 28, 2018 at 7:32 AM

Matthew, and all,
I’ve looked up the -01 version of the draft and I have found 5 references to a 
future revision of the document (all dealing with either LSM or MAC Mobility 
handling).
These references are in the following sections:

  *   3.3.2  (LSM)
  *   4.2  (MAC mobility)
  *   4.3.2 (LSM)
  *   5.2  (MAC mobility)
  *   5.3.2 (LSM)

BTW, the abbreviation “LSM” is not expanded in the document, and I admit that 
do not know what it means in the context of this draft.

I wonder whether the document in this state is ready for the WG LC because, to 
me, these references indicate that the authors do not consider their work as 
complete.

What, if anything, did I miss?

Regards, and lots of thanks in advance,
Sasha

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

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Bocci, Matthew (Nokia - 
GB)
Sent: Wednesday, March 28, 2018 3:50 PM
To: draft-ietf-bess-evpn-vpls-seamless-in...@ietf.org; bess@ietf.org
Cc: bess-cha...@ietf.org
Subject: [bess] WG Last Call and IPR Poll for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

This email begins a two-week working group last call for 
draft-ietf-bess-evpn-vpls-seamless-integ-01.txt

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this 
Document, to ensure that IPR has been disclosed in compliance with IETF IPR 
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
If you are listed as an author or a contributor of this document, please 
respond to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR, copying the BESS mailing list. The document won't progress 
without answers from all the authors and contributors.
Currently there is one IPR declaration against this document.
If you are not listed as an author or a contributor, then please explicitly 
respond only if you are aware of any IPR that has not yet been disclosed in 
conformance with IETF rules.
We are also polling for any existing implementations.
The working group last call closes on Wednesday 11th April.

Regards,
Matthew and Stéphane