Re: [bess] DF election rule in EVPN MH, for untagged interface - reg

[Jaikumar Somasundaram]

Thanks a lot Jorge.

Thanks & Regards
Jaikumar S

From: Rabadan, Jorge (Nokia - US/Mountain View) 
Sent: Friday, April 5, 2019 11:11 AM
To: Jaikumar Somasundaram ; bess@ietf.org
Cc: P Muthu Arul Mozhi 
Subject: Re: [bess] DF election rule in EVPN MH, for untagged interface - reg

Hi,

I think you should check out 
https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-framework-09

This draft updates RFC7432 in certain aspects of the DF Election, and it is 
already at the RFC editor.

Check out the use of Ethernet Tag in the document.

   o Ethernet Tag - used to represent a Broadcast Domain that is
 configured on a given ES for the purpose of DF election. Note that
 any of the following may be used to represent a Broadcast Domain:
 VIDs (including Q-in-Q tags), configured IDs, VNI (VXLAN Network
 Identifiers), normalized VID, I-SIDs (Service Instance
 Identifiers), etc., as long as the representation of the broadcast
 domains is configured consistently across the multi-homed PEs
 attached to that ES. The Ethernet Tag value MUST be different from
 zero.

Thanks.
Jorge

From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Friday, April 5, 2019 at 6:15 AM
To: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: P Muthu Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: [bess] DF election rule in EVPN MH, for untagged interface - reg

Hi All,

RFC7432, section 8.5, talks about DF election algorithm (service carving 
algorithm)

only for  for VLAN-based service or  for VLAN-(aware)
bundle service.

But there wont be any vlan id for untagged interface and so I wonder
how the service carving algorithm can be applied to elect the DF.
Also, should I use the lower VLAN ID even in the case of VLAN-bundle
service, for electing the DF?

Could some one help me to understand this please?

=
8.5<https://tools.ietf.org/html/rfc7432#section-8.5>.  Designated Forwarder 
Election

…

   The default procedure for DF election at the granularity of  for VLAN-based service or  for VLAN-(aware)

   bundle service is referred to as "service carving".
…

  Assuming a redundancy group of N PE nodes, for VLAN-based service,

  the PE with ordinal i is the DF for an  when (V mod N)

  = i.  In the case of VLAN-(aware) bundle service, then the

  numerically lowest VLAN value in that bundle on that ES MUST be

  used in the modulo function.
…
===

Thanks & Regards
Jaikumar S

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

[bess] DF election rule in EVPN MH, for untagged interface - reg

[Jaikumar Somasundaram]

Hi All,

RFC7432, section 8.5, talks about DF election algorithm (service carving 
algorithm)

only for  for VLAN-based service or  for VLAN-(aware)
bundle service.

But there wont be any vlan id for untagged interface and so I wonder
how the service carving algorithm can be applied to elect the DF.
Also, should I use the lower VLAN ID even in the case of VLAN-bundle
service, for electing the DF?

Could some one help me to understand this please?

=
8.5.  Designated Forwarder 
Election



   The default procedure for DF election at the granularity of  for VLAN-based service or  for VLAN-(aware)

   bundle service is referred to as "service carving".


  Assuming a redundancy group of N PE nodes, for VLAN-based service,

  the PE with ordinal i is the DF for an  when (V mod N)

  = i.  In the case of VLAN-(aware) bundle service, then the

  numerically lowest VLAN value in that bundle on that ES MUST be

  used in the modulo function.

===

Thanks & Regards
Jaikumar S

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

Re: [bess] A question on using EVPN label and Alias label in load balancing

[Jaikumar Somasundaram]

Thanks a lot Jide, for the reply.
Please find my response below [Jai]

Thanks & Regards
Jaikumar S

From: Jide Akintola 
Sent: Monday, February 18, 2019 5:00 PM
To: bess@ietf.org; Jaikumar Somasundaram 
Subject: Re: [bess] A question on using EVPN label and Alias label in load 
balancing

Hi Jaikumar,

As per the rfc, aliasing is define as the ability of a PE to signal that it has 
reachability to an EVPN instance on a given ES even when it has learned no MAC 
addresses from that EVI/ES. It is advertised with Ethernet A-D per EVI type 1 
routes.

Aliasing improves load-balancing by allowing remote VNEs to continue to 
load-balance traffic evenly though they have only received a single MAC/IP from 
a single ingress VNE. Meaning a remote PE that receives a MAC/IP Advertisement 
route (type 2 route) with a non-reserved ESI would consider the advertised MAC 
address to be reachable via all PEs that have advertised reachability to that 
MAC address EVI/ES via the Ethernet A-D per EVI route.

In your example, it would mean that if MAC1 is only learned by PE3 from PE1, 
but because PE3 has received Ethernet A-D per EVI type 1 route with aliasing 
label from PE2, it would consider that MAC1 is also reacheable via PE2 and 
would load balance traffic destined for MAC1 to both PE1 and PE2.

For cases where the MAC1 is learnt from PE1 and PE2 by PE3, then aliasing 
should not come into play.
[Jai] Any reason why we should not use Alias label to reach any of PE1 or PE2. 
I see the only difference between EPN label and Alias label is that Mac look up 
will happen but Alias label does not expect the MAC entry to be present and so 
no MAC lookup is required
and simply forward it on the ESI port/link. Please correct me if something is 
not right.


There are some optimization done by some vendor using proxy advertisement via 
PE2 to mitigate traffic loss for cases where say PE3 only learns MAC1 from say 
PE1 and say you lost PE1.

Many thanks.

Cheers,

Jide


On Monday, 18 February 2019, 10:08:02 GMT, Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>> 
wrote:



Hi All,

 --

 ||

  PORT1 |  DEVICE1   |PORT3

   --| PE1|-

   |  1/5|  2.2.2.2   | 1/4 |

   | || |

   | -- |

   |PORT1  |PORT2   |PORT2

--| ++--

 ||| |||
|

 | DEVICE4|| ||PORT1   | DEVICE4
|

 | (CE1)  || |   DEVICE3  || (CE2)  
|

 | Multi-home || | PE3 |   PORT3| Single 
home|

 ||| |   4.4.4.4  ||
|

--| ++--

   |PORT2  |1/1|PORT3

   |   |PORT2  | 1/6

   | --|

   | |||

   |   PORT1 |  DEVICE2   ||

   --|PE2 |-

1/4  |  3.3.3.3   |PORT3

 ||1/4

 --



Let’s say CE1 is connected to PE1 and PE2 (all-active case)

and PE1 and PE2 learn same MAC1 entry (say different destination)

PE3 will learn MAC1 from both PE1 and PE2 with their respective

EVPN label (Assume BGP ECMP is enabled). As part of load balancing,

should PE3 always use EVPN label to send the frame destined to MAC1

or can Alias label also be used? what is the need of using EVPN label?



Thanks & Regards

Jaikumar S


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

[bess] A question on using EVPN label and Alias label in load balancing

[Jaikumar Somasundaram]

Hi All,
 --
 ||
  PORT1 |  DEVICE1   |PORT3
   --| PE1|-
   |  1/5|  2.2.2.2   | 1/4 |
   | || |
   | -- |
   |PORT1  |PORT2   |PORT2
--| ++--
 ||| |||
|
 | DEVICE4|| ||PORT1   | DEVICE4
|
 | (CE1)  || |   DEVICE3  || (CE2)  
|
 | Multi-home || | PE3 |   PORT3| Single 
home|
 ||| |   4.4.4.4  ||
|
--| ++--
   |PORT2  |1/1|PORT3
   |   |PORT2  | 1/6
   | --|
   | |||
   |   PORT1 |  DEVICE2   ||
   --|PE2 |-
1/4  |  3.3.3.3   |PORT3
 ||1/4
 --

Let's say CE1 is connected to PE1 and PE2 (all-active case)
and PE1 and PE2 learn same MAC1 entry (say different destination)
PE3 will learn MAC1 from both PE1 and PE2 with their respective
EVPN label (Assume BGP ECMP is enabled). As part of load balancing,
should PE3 always use EVPN label to send the frame destined to MAC1
or can Alias label also be used? what is the need of using EVPN label?

Thanks & Regards
Jaikumar S

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

Re: [bess] A question on CE behavior on traffic forwarding to EVPN multihomed PEs in single-active mode

[Jaikumar Somasundaram]

Thanks Mrinmoy for the quick answer.

Thanks & Regards
Jaikumar S

From: Mrinmoy Ghosh (mrghosh) 
Sent: Wednesday, February 13, 2019 1:21 PM
To: Jaikumar Somasundaram ; bess@ietf.org
Cc: Pradeep Ramakrishnan ; Chalapathi Andhe 

Subject: RE: A question on CE behavior on traffic forwarding to EVPN multihomed 
PEs in single-active mode

Hi Jaikumar,

EVPN Single active heavily depends upon MAC Flush mechanism like MVRP or TCN 
Flush.

In your topology, initially CE1 would flood unknown ucast to both PE1 and PE2; 
PE1 being DF will send and receive traffic for that (ES, EVI), hence once the 
traffic  will be learned eventually from PE1.
However on switchover, Mac flush is sent to CE so that the forwarding table is 
flushed and the traffic is flooded to both PE until learned from the new DF.

Thanks,
Mrinmoy

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Jaikumar Somasundaram
Sent: Tuesday, February 12, 2019 10:11 PM
To: bess@ietf.org<mailto:bess@ietf.org>
Cc: Pradeep Ramakrishnan 
mailto:pradeep.ramakrish...@ericsson.com>>; 
Chalapathi Andhe 
mailto:chalapathi.an...@ericsson.com>>
Subject: [bess] A question on CE behavior on traffic forwarding to EVPN 
multihomed PEs in single-active mode

Hello All,

In EVPN MH with Single-Active scenario, could you help us to clarify the below 
query?

 --
 ||
   PORT1 |  DEVICE1   |PORT3
   --| PE1|-
   |  1/5|  2.2.2.2   | 1/4 |
   | || |
   | -- |
   |PORT1  |PORT2   |PORT2
--| ++--
 ||| |||
|
 | DEVICE4|| ||PORT1   | DEVICE4
|
 | (CE1)  || |   DEVICE3  || (CE2)  
|
 | Multi-home || | PE |   PORT3| Single 
home|
 ||| |   4.4.4.4  ||
|
--| ++--
   |PORT2  |1/1|PORT3
   |   |PORT2  | 1/6
   | --|
   | |||
   |   PORT1 |  DEVICE2   ||
   --|PE2 |-
1/4  |  3.3.3.3   |PORT3
 ||1/4
 --

Let's say CE1 is connected to PE1 and PE2 (single-active case)
and PE1 is the DF for VLAN 10 and has the active link,
but CE1 sends unknown unicast traffic on the link to PE2 (standby link),
wouldn't the traffic be dropped because its non-DF ?

or

How does CE ensure traffic is always forwarded on the active link
(as standby link will drop the traffic) ?

Thanks & Regards
Jaikumar S

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

[bess] A question on CE behavior on traffic forwarding to EVPN multihomed PEs in single-active mode

[Jaikumar Somasundaram]

Hello All,

In EVPN MH with Single-Active scenario, could you help us to clarify the below 
query?

 --
 ||
   PORT1 |  DEVICE1   |PORT3
   --| PE1|-
   |  1/5|  2.2.2.2   | 1/4 |
   | || |
   | -- |
   |PORT1  |PORT2   |PORT2
--| ++--
 ||| |||
|
 | DEVICE4|| ||PORT1   | DEVICE4
|
 | (CE1)  || |   DEVICE3  || (CE2)  
|
 | Multi-home || | PE |   PORT3| Single 
home|
 ||| |   4.4.4.4  ||
|
--| ++--
   |PORT2  |1/1|PORT3
   |   |PORT2  | 1/6
   | --|
   | |||
   |   PORT1 |  DEVICE2   ||
   --|PE2 |-
1/4  |  3.3.3.3   |PORT3
 ||1/4
 --

Let's say CE1 is connected to PE1 and PE2 (single-active case)
and PE1 is the DF for VLAN 10 and has the active link,
but CE1 sends unknown unicast traffic on the link to PE2 (standby link),
wouldn't the traffic be dropped because its non-DF ?

or

How does CE ensure traffic is always forwarded on the active link
(as standby link will drop the traffic) ?

Thanks & Regards
Jaikumar S

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

Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

[Jaikumar Somasundaram]

Thanks Jorge.

I think that this optimization is not mentioned in the RFC 7432.

Section 8.5 of RFC 7432:

  In the case of link or port failure, the affected PE withdraws its
  Ethernet Segment route.  This will re-trigger the service carving
  procedures on all the PEs in the redundancy group.  For PE node
  failure, or upon PE commissioning or decommissioning, the PEs
  re-trigger the service carving.

Section 13.2.1 of RFC 7432:


  - If the PE is not the designated forwarder on any of the ESIs for

 the Ethernet tag, the default behavior is for it to drop the

 packet.

Section 14.1.1 of RFC 7432:


   If there is more than one backup PE for a given ES, the remote PE

   MUST use the primary PE's withdrawal of its set of Ethernet A-D per

   ES routes as a trigger to start flooding traffic for the associated

   MAC addresses (as long as flooding of unknown unicast packets is

   administratively allowed), as it is not possible to select a single

   backup PE.

Thanks & Regards
Jaikumar S
From: Rabadan, Jorge (Nokia - US/Mountain View) 
Sent: Thursday, October 4, 2018 10:11 PM
To: Jaikumar Somasundaram ; bess@ietf.org
Cc: Jiang He ; P Muthu Arul Mozhi 

Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jai,

Yes, but see my other email.. if you only have two PEs in the ES, you may 
optimize things.
Thanks.
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 5:39 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jorge,

Yes, new DF will be identified after the new election.
Election process will need to wait for DF election timer period, say 3s or the 
configured timer period.
Until this DF election timer expiry and new DF is identified, the traffic 
towards CE coming to the node this PE
will get dropped. Please let me know if my understanding is right?

Thanks & Regards
Jaikumar S
From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 8:06 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org<mailto:bess@ietf.org>
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Jai,

The new DF becomes DF because it re-runs DF election.
Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 12:23 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 3:33 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org<mailto:bess@ietf.org>
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 11:28 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Thanks Jorge for the quick reply.
Please find further question below.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 1:52 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org<mailto:bess@ietf.org>
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi,


Questions:
1.  Will the node in backup mode forward the packet to CE?

[JORGE] as soon as it becomes DF it can forward packets to the CE. The backup 
node will have to run DF election upon the ES rout

Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

[Jaikumar Somasundaram]

Thanks Mrinmoy.
Response in-lined.

From: Mrinmoy Ghosh (mrghosh) 
Sent: Thursday, October 4, 2018 11:40 PM
To: Jaikumar Somasundaram ; Rabadan, Jorge 
(Nokia - US/Mountain View) ; bess@ietf.org
Cc: Jiang He ; P Muthu Arul Mozhi 

Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jaikumar,

Backup failure can happen in multiple forms, Node down, Interface down etc.
There is no DF election timer on ES withdrawal, it should be carved immediately 
in Peering PEs.
[Jai] RFC 7432 does not mention anything about this.

…
  In the case of link or port failure, the affected PE withdraws its
  Ethernet Segment route.  This will re-trigger the service carving
  procedures on all the PEs in the redundancy group.  For PE node
  failure, or upon PE commissioning or decommissioning, the PEs
  re-trigger the service carving.

DF election timer is manly when the ES is coming up (Node up, Interface up etc) 
to specify some.

Thanks,
Mrinmoy

From: BESS mailto:bess-boun...@ietf.org>> On Behalf Of 
Jaikumar Somasundaram
Sent: Thursday, October 4, 2018 8:39 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jorge,

Yes, new DF will be identified after the new election.
Election process will need to wait for DF election timer period, say 3s or the 
configured timer period.
Until this DF election timer expiry and new DF is identified, the traffic 
towards CE coming to the node this PE
will get dropped. Please let me know if my understanding is right?

Thanks & Regards
Jaikumar S
From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 8:06 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org<mailto:bess@ietf.org>
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Jai,

The new DF becomes DF because it re-runs DF election.
Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 12:23 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 3:33 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org<mailto:bess@ietf.org>
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 11:28 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Thanks Jorge for the quick reply.
Please find further question below.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 1:52 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org<mailto:bess@ietf.org>
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi,


Questions:
1.  Will the node in backup mode forward the packet to CE?

[JORGE] as soon as it becomes DF it can forward packets to the CE. The backup 
node will have to run DF election upon the ES route withdrawal from the 
primary. If AC-DF is enabled, it can also react to the withdrawal of AD routes 
from the primary PE.

[Jai] Does that mean if any packet comes to a node that is still in the backup 
mode will get dropped, before the new DF election is complete? Why cant this be 
used as FRR? Or what is the use case of having backup node(s)?

[JORGE2] when the primary node fails, ES and AD routes are withdrawn. The AD 
route withdrawal is an indication for 

Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

[Jaikumar Somasundaram]

Thanks a lot Jorge, for your help to clarify that the traffic towards CE will 
get dropped
when the Primary Path failed, until the a new DF is elected and becomes in 
forwarding state,
as per RFC7432.

Thanks & Regards
Jaikumar S

From: Jaikumar Somasundaram
Sent: Friday, October 5, 2018 10:37 AM
To: 'Rabadan, Jorge (Nokia - US/Mountain View)' ; 
bess@ietf.org
Cc: Jiang He ; P Muthu Arul Mozhi 

Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Thanks Jorge.

I think that this optimization is not mentioned in the RFC 7432.

Section 8.5 of RFC 7432:

  In the case of link or port failure, the affected PE withdraws its
  Ethernet Segment route.  This will re-trigger the service carving
  procedures on all the PEs in the redundancy group.  For PE node
  failure, or upon PE commissioning or decommissioning, the PEs
  re-trigger the service carving.

Section 13.2.1 of RFC 7432:


  - If the PE is not the designated forwarder on any of the ESIs for

 the Ethernet tag, the default behavior is for it to drop the

 packet.

Section 14.1.1 of RFC 7432:


   If there is more than one backup PE for a given ES, the remote PE

   MUST use the primary PE's withdrawal of its set of Ethernet A-D per

   ES routes as a trigger to start flooding traffic for the associated

   MAC addresses (as long as flooding of unknown unicast packets is

   administratively allowed), as it is not possible to select a single

   backup PE.

Thanks & Regards
Jaikumar S
From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 10:11 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org<mailto:bess@ietf.org>
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jai,

Yes, but see my other email.. if you only have two PEs in the ES, you may 
optimize things.
Thanks.
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 5:39 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jorge,

Yes, new DF will be identified after the new election.
Election process will need to wait for DF election timer period, say 3s or the 
configured timer period.
Until this DF election timer expiry and new DF is identified, the traffic 
towards CE coming to the node this PE
will get dropped. Please let me know if my understanding is right?

Thanks & Regards
Jaikumar S
From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 8:06 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org<mailto:bess@ietf.org>
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Jai,

The new DF becomes DF because it re-runs DF election.
Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 12:23 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 3:33 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org<mailto:bess@ietf.org>
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 11:28 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Thanks Jorge for the quick reply.
Please fin

Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

[Jaikumar Somasundaram]

In-line.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
Sent: Thursday, October 4, 2018 3:33 PM
To: Jaikumar Somasundaram ; bess@ietf.org
Cc: Jiang He ; P Muthu Arul Mozhi 

Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

In-line.

Thx
Jorge

From: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 11:28 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>, 
"bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Thanks Jorge for the quick reply.
Please find further question below.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>>
Sent: Thursday, October 4, 2018 1:52 PM
To: Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>;
 bess@ietf.org<mailto:bess@ietf.org>
Cc: Jiang He mailto:jiang...@ericsson.com>>; P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi,


Questions:
1.  Will the node in backup mode forward the packet to CE?

[JORGE] as soon as it becomes DF it can forward packets to the CE. The backup 
node will have to run DF election upon the ES route withdrawal from the 
primary. If AC-DF is enabled, it can also react to the withdrawal of AD routes 
from the primary PE.

[Jai] Does that mean if any packet comes to a node that is still in the backup 
mode will get dropped, before the new DF election is complete? Why cant this be 
used as FRR? Or what is the use case of having backup node(s)?

[JORGE2] when the primary node fails, ES and AD routes are withdrawn. The AD 
route withdrawal is an indication for remote nodes that they have to send 
traffic to the backup (for a given MAC) or to flush the MACs if there are more 
than 2 PEs in the ES. Around the same time or maybe earlier, the ES route 
withdrawal will make the backup PE take over as DF

[Jai] will it become DF without DF election? What if there is more than one PE 
in backup mode?

. So the overall convergence time will depend on how/when those two things 
happen in time. Only the DF PE can forward traffic. A non-DF can never forward 
traffic or there will be risk of duplicate packets.




2.  Will all the nodes in backup mode forward the packet before DF election?

[JORGE] Only the new DF can forward.



3. If they forward, how is duplicate packets handled, in this case?
[JORGE] see above.

My two cents..

Thanks.
Jorge



From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 10:03 AM
To: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: [bess] EVPN MH: Backup node behavior in Primary Path Failure


Hello Everyone,

Sorry if it is a duplicate. I repost this query as I did not receive any 
response yet.
(I was wondering if this mail already reached the group or not)


I have a question on Primary PE encountering a failure in EVPN multihoming

in single active mode.



RFC7432, section 14.1.1:



   If there is more than one backup PE for a given ES, the remote PE

   MUST use the primary PE's withdrawal of its set of Ethernet A-D per

   ES routes as a trigger to start flooding traffic for the associated

   MAC addresses (as long as flooding of unknown unicast packets is

   administratively allowed), as it is not possible to select a single

   backup PE.





Questions:

1. Will the node in backup mode forward the packet to CE?

2. Will all the nodes in backup mode forward the packet before DF election?

3. If they forward, how is duplicate packets handled, in this case?



Please help me anwere these questions.



Thanks & Regards

Jaikumar S


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

Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

[Jaikumar Somasundaram]

Thanks Jorge for the quick reply.
Please find further question below.

From: Rabadan, Jorge (Nokia - US/Mountain View) 
Sent: Thursday, October 4, 2018 1:52 PM
To: Jaikumar Somasundaram ; bess@ietf.org
Cc: Jiang He ; P Muthu Arul Mozhi 

Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi,


Questions:

  1.  Will the node in backup mode forward the packet to CE?

[JORGE] as soon as it becomes DF it can forward packets to the CE. The backup 
node will have to run DF election upon the ES route withdrawal from the 
primary. If AC-DF is enabled, it can also react to the withdrawal of AD routes 
from the primary PE.

[Jai] Does that mean if any packet comes to a node that is still in the backup 
mode will get dropped, before the new DF election is complete? Why cant this be 
used as FRR? Or what is the use case of having backup node(s)?



  1.  Will all the nodes in backup mode forward the packet before DF election?

[JORGE] Only the new DF can forward.



3. If they forward, how is duplicate packets handled, in this case?
[JORGE] see above.

My two cents..

Thanks.
Jorge



From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Jaikumar Somasundaram 
mailto:jaikumar.somasunda...@ericsson.com>>
Date: Thursday, October 4, 2018 at 10:03 AM
To: "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>
Cc: Jiang He mailto:jiang...@ericsson.com>>, P Muthu 
Arul Mozhi 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: [bess] EVPN MH: Backup node behavior in Primary Path Failure


Hello Everyone,

Sorry if it is a duplicate. I repost this query as I did not receive any 
response yet.
(I was wondering if this mail already reached the group or not)


I have a question on Primary PE encountering a failure in EVPN multihoming

in single active mode.



RFC7432, section 14.1.1:



   If there is more than one backup PE for a given ES, the remote PE

   MUST use the primary PE's withdrawal of its set of Ethernet A-D per

   ES routes as a trigger to start flooding traffic for the associated

   MAC addresses (as long as flooding of unknown unicast packets is

   administratively allowed), as it is not possible to select a single

   backup PE.





Questions:

1. Will the node in backup mode forward the packet to CE?

2. Will all the nodes in backup mode forward the packet before DF election?

3. If they forward, how is duplicate packets handled, in this case?



Please help me anwere these questions.



Thanks & Regards

Jaikumar S


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

[bess] EVPN MH: Backup node behavior in Primary Path Failure

[Jaikumar Somasundaram]

Hello Everyone,

Sorry if it is a duplicate. I repost this query as I did not receive any 
response yet.
(I was wondering if this mail already reached the group or not)


I have a question on Primary PE encountering a failure in EVPN multihoming

in single active mode.



RFC7432, section 14.1.1:



   If there is more than one backup PE for a given ES, the remote PE

   MUST use the primary PE's withdrawal of its set of Ethernet A-D per

   ES routes as a trigger to start flooding traffic for the associated

   MAC addresses (as long as flooding of unknown unicast packets is

   administratively allowed), as it is not possible to select a single

   backup PE.





Questions:

1. Will the node in backup mode forward the packet to CE?

2. Will all the nodes in backup mode forward the packet before DF election?

3. If they forward, how is duplicate packets handled, in this case?



Please help me anwere these questions.



Thanks & Regards

Jaikumar S


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

[bess] EVPN MH: Backup node behavior in Primary Path Failure

[Jaikumar Somasundaram]

Hello Everyone,



I have a question on Primary PE encountering a failure in EVPN multihoming

in single active mode.



RFC7432, section 14.1.1:



   If there is more than one backup PE for a given ES, the remote PE

   MUST use the primary PE's withdrawal of its set of Ethernet A-D per

   ES routes as a trigger to start flooding traffic for the associated

   MAC addresses (as long as flooding of unknown unicast packets is

   administratively allowed), as it is not possible to select a single

   backup PE.





Questions:

1. Will the node in backup mode forward the packet to CE?

2. Will all the nodes in backup mode forward the packet before DF election?

3. If they forward, how is duplicate packets handled, in this case?



Please help me anwere these questions.



Thanks & Regards

Jaikumar S


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