[bess] Signaling Control Word in EVPN

[Muthu Arul Mozhi Perumal]

RFC 8214 (EVPN VPWS) introduces a new EVPN Layer 2 Attributes extended
community for signaling the L2 MTU and other control flags, including the
one to signal that the control word needs to be included when sending
packets to this PE. It further describes how MTU checking is to be
performed when signaled using this extended community.

RFC 7432 however is completely silent about it. Is the extended community
described in RFC 8214 expected to used in EVPN (VPLS) as well to signal
things like the usage of control word?

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

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

[Muthu Arul Mozhi Perumal]

Thanks, Jorge.

In EVPN single-active dual-homing or EVPN VPWS single-active multi-homing,
when other PEs realize that the DF is dead, they all need to re-run the DF
election for sure. However, traffic recovery need not wait until the DF
election gets over electing a new DF..it only requires the other PEs and
the backup to realize the primary/DF is dead and start forward. That's my
point..

Regards,
Muthu

On Fri, Oct 5, 2018 at 1:30 AM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Muthu,
>
>
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Thursday, October 4, 2018 at 5:37 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *"jaikumar.somasunda...@ericsson.com" <
> jaikumar.somasunda...@ericsson.com>, "bess@ietf.org" , "
> jiang...@ericsson.com" , "
> p.muthu.arul.mo...@ericsson.com" 
> *Subject: *Re: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Thanks, Jorge. This is inline with my thinking. So, in single-active
> multihoming, once the primary is dead we don't need to wait for the DF
> election to happen for the backup (or some other PE in the ES) to become
> active and start forwarding traffic over the ES, instead it only requires
> the remote PEs and backup to realize that the primary is dead (thru' NH
> tracking / BFD) and start forwarding over the ES, right?
>
> [JORGE] When the other PEs in the ES realize the DF is dead, they need to
> remove the dead PE from the candidate list and run DF Election. You may
> optimize things if you only have two PEs in the ES (such as skip the timer)
> but if you have more than 2 PEs in the ES, there is really no concept of
> backup PE in RFC7432, but simply the other PEs are non-DF. However, the
> concept of backup PE in an ES with more than two PEs is specified in
> RFC8214, where all the PEs in the ES not only elect a DF but also a backup
> DF, and signal this backup condition in the AD per-EVI routes. Note this is
> not there in RFC7432.
>
>
>
> Regards,
>
> Muthu
>
>
>
> On Thu, Oct 4, 2018 at 8:10 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> Muthu,
>
>
>
> About this:
>
>
>
> Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
> withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
> session would timeout causing the primary PE's neighbors to flush out the
> A-D routes received from the primary PE, right? This can take several
> seconds, isn't it?
>
>
>
> No, not in the implementations I know of. Next Hop tracking will
> immediately detect that the PE is not in the network anymore and the routes
> will be invalidated. You can also bootstrap the BGP sessions to BFD.
>
> But that has nothing to do with EVPN!.. it’s regular BGP.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Thursday, October 4, 2018 at 1:14 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *"jaikumar.somasunda...@ericsson.com" <
> jaikumar.somasunda...@ericsson.com>, "bess@ietf.org" , "
> jiang...@ericsson.com" , "
> p.muthu.arul.mo...@ericsson.com" 
> *Subject: *Re: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Please see inline..
>
>
>
> On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> In-line.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Jaikumar Somasundaram 
> *Date: *Thursday, October 4, 2018 at 11:28 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" ,
> "bess@ietf.org" 
> *Cc: *Jiang He , P Muthu Arul Mozhi <
> 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) 
>
> *Sent:* Thursday, October 4, 2018 1:52 PM
> *To:* Jaikumar Somasundaram ;
> bess@ietf.org
> *Cc:* Jiang He ; P Muthu Arul Mozhi <
> 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. *
>
> Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
> withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
> session would timeout causing the primary PE's neighbors to flush out the
> A-D routes received 

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

Anush,

From: Anush Mohan 
Date: Thursday, October 4, 2018 at 5:47 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Cc: "muthu.a...@gmail.com" , "jiang...@ericsson.com" 
, "p.muthu.arul.mo...@ericsson.com" 
, "bess@ietf.org" , 
"jaikumar.somasunda...@ericsson.com" 
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi Jorge,

  Related to this topic, I had couple of queries as well. Could you please 
clarify.

1.  I hope the section of RFC pasted by Jai is superceded by the particular DF 
algorithm used. If all PEs can decide one particular backup PE for 
Ethernet-segment based on HRW (for e.g),
 only that particular backup-PE can be used for unicasting traffic. We can 
avoid flushing mac-entry in this case.
[JORGE] see my other email. In RFC7432 you can avoid mac flushing at the remote 
PEs only if there are two PEs in the ES, with more than two, the remote PEs 
need to flush the macs and flood:

   If there is only one backup PE for a given ES, the remote PE MAY use
   the primary PE's withdrawal of its set of Ethernet A-D per ES routes
   as a trigger to update its forwarding entries, for the associated MAC
   addresses, to point towards the backup PE.  As the backup PE starts
   learning the MAC addresses over its attached ES, it will start
   sending MAC/IP Advertisement routes while the failed PE withdraws its
   routes.  This mechanism minimizes the flooding of traffic during
   fail-over events.

   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.

[JORGE] In RFC8214 there is a single backup PE, even with more than 2 PEs in 
the ES, and that condition is signaled. We’ve had some discussions to re-use 
this backup signaling in RFC7432 based EVIs, but it is not there in existing 
RFC7432 networks.


2.  If 'all-active' multihoming is used and a particular MAC is learnt from 
multiple PEs on an Ethernet-segment, should we use 'mac-ip' route label for 
load-balancing traffic or alias-label from
 'EAD/ESI' route. Or it doesn't matter.
[JORGE] IMO it doesn’t matter much if you use a label per MAC-VRF (or per-BD) 
on the ES PEs, since the labels will be the same anyway and at the egress you 
do a mac-lookup anyway…

Regards
Anush

On Thu, Oct 4, 2018 at 8:10 PM Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:
Muthu,

About this:

Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would 
withdraw the routes if the primary PE / DF itself fails? Instead, the BGP 
session would timeout causing the primary PE's neighbors to flush out the A-D 
routes received from the primary PE, right? This can take several seconds, 
isn't it?

No, not in the implementations I know of. Next Hop tracking will immediately 
detect that the PE is not in the network anymore and the routes will be 
invalidated. You can also bootstrap the BGP sessions to BFD.
But that has nothing to do with EVPN!.. it’s regular BGP.

Thx
Jorge

From: Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>>
Date: Thursday, October 4, 2018 at 1:14 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>
Cc: 
"jaikumar.somasunda...@ericsson.com" 
mailto:jaikumar.somasunda...@ericsson.com>>,
 "bess@ietf.org" mailto:bess@ietf.org>>, 
"jiang...@ericsson.com" 
mailto:jiang...@ericsson.com>>, 
"p.muthu.arul.mo...@ericsson.com" 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Please see inline..

On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:
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>>
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
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

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

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 
Date: Thursday, October 4, 2018 at 5:39 PM
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

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) 
Sent: Thursday, October 4, 2018 8:06 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

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

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

Muthu,


From: Muthu Arul Mozhi Perumal 
Date: Thursday, October 4, 2018 at 5:37 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Cc: "jaikumar.somasunda...@ericsson.com" , 
"bess@ietf.org" , "jiang...@ericsson.com" 
, "p.muthu.arul.mo...@ericsson.com" 

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

Thanks, Jorge. This is inline with my thinking. So, in single-active 
multihoming, once the primary is dead we don't need to wait for the DF election 
to happen for the backup (or some other PE in the ES) to become active and 
start forwarding traffic over the ES, instead it only requires the remote PEs 
and backup to realize that the primary is dead (thru' NH tracking / BFD) and 
start forwarding over the ES, right?
[JORGE] When the other PEs in the ES realize the DF is dead, they need to 
remove the dead PE from the candidate list and run DF Election. You may 
optimize things if you only have two PEs in the ES (such as skip the timer) but 
if you have more than 2 PEs in the ES, there is really no concept of backup PE 
in RFC7432, but simply the other PEs are non-DF. However, the concept of backup 
PE in an ES with more than two PEs is specified in RFC8214, where all the PEs 
in the ES not only elect a DF but also a backup DF, and signal this backup 
condition in the AD per-EVI routes. Note this is not there in RFC7432.

Regards,
Muthu

On Thu, Oct 4, 2018 at 8:10 PM Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:
Muthu,

About this:

Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would 
withdraw the routes if the primary PE / DF itself fails? Instead, the BGP 
session would timeout causing the primary PE's neighbors to flush out the A-D 
routes received from the primary PE, right? This can take several seconds, 
isn't it?

No, not in the implementations I know of. Next Hop tracking will immediately 
detect that the PE is not in the network anymore and the routes will be 
invalidated. You can also bootstrap the BGP sessions to BFD.
But that has nothing to do with EVPN!.. it’s regular BGP.

Thx
Jorge

From: Muthu Arul Mozhi Perumal 
mailto:muthu.a...@gmail.com>>
Date: Thursday, October 4, 2018 at 1:14 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
mailto:jorge.raba...@nokia.com>>
Cc: 
"jaikumar.somasunda...@ericsson.com" 
mailto:jaikumar.somasunda...@ericsson.com>>,
 "bess@ietf.org" mailto:bess@ietf.org>>, 
"jiang...@ericsson.com" 
mailto:jiang...@ericsson.com>>, 
"p.muthu.arul.mo...@ericsson.com" 
mailto:p.muthu.arul.mo...@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Please see inline..

On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:
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>>
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
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.
Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would 
withdraw the routes if the primary PE / DF itself fails? Instead, the BGP 
session would timeout causing the primary PE's neighbors to flush out the A-D 
routes received from the primary PE, right? This can take several seconds, 
isn't it?

Regards,
Muthu

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 

Re: [bess] Genart last call review of draft-ietf-bess-mvpn-expl-track-10

[Brian E Carpenter]

Hi Eric,

On 2018-10-05 04:15, Eric Rosen wrote:
>> Minor issues:
>> -
>>
>> As I understand it, if a network only partially supports the new
>> (LIR-pF) flag, it doesn't work properly. So we find at the end of
>> section 2:
>>
>> ...the ingress node can conclude
>> that the egress node originating that Leaf A-D route does not support
>> the LIR-pF flag.
>>
>> The software at the ingress node SHOULD detect this, and should have
>> a way of alerting the operator that the deployment is not properly
>> configured.
>>
>> I don't see why this is only a SHOULD, and I don't see why the operator
>> alert is not a MUST too. Surely the operator always needs to be alerted?
> 
> Good point, I have changed this to:
> 
>     The software at the ingress node MUST detect this, and MUST have a 
> way of alerting the operator that the deployment is not properly configured.

Thanks.
 
>> I agree with the point raised in the Routing Area review
>> (be explicit about the updated sections of RFC 6514, 6625,
>> and 7524).
> 
> The clarifications and extensions may affect the procedures for 
> originating and receiving/processing S-PMSI A-D routes and Leaf A-D 
> routes.  These procedures are discussed in many different places in the 
> updated drafts.  

Fair enough. I suggest adding a version of those two sentences in the
Introduction. Otherwise you can bet on this point being raised by the
IESG anyway.

Regards
Brian

> I don't believe there is any value in having the 
> authors of mvpn-expl-track go through those drafts to try to make a list 
> of all the places where S-PMSI A-D routes and/or Leaf A-D routes are 
> discussed.  If we attempted to do so, we'd surely miss a few places and 
> thereby introduce bugs into the spec.  The information currently in the 
> document is sufficient to enable anyone who understands the updated 
> references to figure out what needs to be done.




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

[bess] Last call comment to draft-ietf-bess-evpn-inter-subnet-forwarding-05

[Linda Dunbar]

Ali, et al:

Sorry for the late comments. I remember reviewing/contributing to this draft 
many years ago. Happy to see it is finally moving to IESG Last Call.

The draft describes the mechanism to allow TSs belonging to different subnets 
attached to same PE to be communicated by the PE (instead hair pinned to the 
L3GW). Very good optimization.

However, not every PE has the needed policies for any two subnet communication 
(that is why the traffic was to be sent to L3GW). Therefore, the draft needs a 
section to describe how the PEs determine if it has the needed policies for 
specific inter subnets communication.
In addition, when subnets are scatted among many different PEs, it requires the 
L3GW to maintain all the mappings. In Data center when there are many VMs or 
Containers, the number of mappings for L3GW to maintain is huge (it practically 
becomes host routing for tens of thousands of VMs or Containers). It doesn't 
scale well. Therefore, the mechanism should allow some PEs to maintain some of 
the mappings, i.e. becoming a designated L3GW for some subnets.

If you are willing to accept this comment, I can provide the text on 
"Inter-subnet communication Policy on PE".

Thank you.

Linda Dunbar



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

[bess] I-D Action: draft-ietf-bess-mvpn-expl-track-11.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Explicit Tracking with Wild Card Routes in Multicast 
VPN
Authors : Andrew Dolganow
  Jayant Kotalwar
  Eric C. Rosen
  Zhaohui Zhang
Filename: draft-ietf-bess-mvpn-expl-track-11.txt
Pages   : 18
Date: 2018-10-04

Abstract:
   The MVPN specifications provide procedures to allow a multicast
   ingress node to invoke "explicit tracking" for a multicast flow or
   set of flows, thus learning the egress nodes for that flow or set of
   flows.  However, the specifications are not completely clear about
   how the explicit tracking procedures work in certain scenarios.  This
   document provides the necessary clarifications.  It also specifies a
   new, optimized explicit tracking procedure.  This new procedure
   allows an ingress node, by sending a single message, to request
   explicit tracking of each of a set of flows, where the set of flows
   is specified using a wildcard mechanism.  This document updates RFCs
   6514, 6625, and 7524.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-expl-track-11
https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-expl-track-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-expl-track-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

[Anush Mohan]

Hi Jorge,

  Related to this topic, I had couple of queries as well. Could you
please clarify.

1.  I hope the section of RFC pasted by Jai is superceded by the particular
DF algorithm used. If all PEs can decide one particular backup PE for
Ethernet-segment based on HRW (for e.g),
 only that particular backup-PE can be used for unicasting traffic. We
can avoid flushing mac-entry in this case.

2.  If 'all-active' multihoming is used and a particular MAC is learnt from
multiple PEs on an Ethernet-segment, should we use 'mac-ip' route label for
load-balancing traffic or alias-label from
 'EAD/ESI' route. Or it doesn't matter.

Regards
Anush


On Thu, Oct 4, 2018 at 8:10 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Muthu,
>
>
>
> About this:
>
>
>
> Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
> withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
> session would timeout causing the primary PE's neighbors to flush out the
> A-D routes received from the primary PE, right? This can take several
> seconds, isn't it?
>
>
>
> No, not in the implementations I know of. Next Hop tracking will
> immediately detect that the PE is not in the network anymore and the routes
> will be invalidated. You can also bootstrap the BGP sessions to BFD.
>
> But that has nothing to do with EVPN!.. it’s regular BGP.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Thursday, October 4, 2018 at 1:14 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *"jaikumar.somasunda...@ericsson.com" <
> jaikumar.somasunda...@ericsson.com>, "bess@ietf.org" , "
> jiang...@ericsson.com" , "
> p.muthu.arul.mo...@ericsson.com" 
> *Subject: *Re: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Please see inline..
>
>
>
> On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> In-line.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Jaikumar Somasundaram 
> *Date: *Thursday, October 4, 2018 at 11:28 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" ,
> "bess@ietf.org" 
> *Cc: *Jiang He , P Muthu Arul Mozhi <
> 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) 
>
> *Sent:* Thursday, October 4, 2018 1:52 PM
> *To:* Jaikumar Somasundaram ;
> bess@ietf.org
> *Cc:* Jiang He ; P Muthu Arul Mozhi <
> 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. *
>
> Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
> withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
> session would timeout causing the primary PE's neighbors to flush out the
> A-D routes received from the primary PE, right? This can take several
> seconds, isn't it?
>
>
>
> Regards,
>
> Muthu
>
> *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. 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  on behalf of Jaikumar Somasundaram <
> jaikumar.somasunda...@ericsson.com>
> *Date: *Thursday, October 4, 2018 at 10:03 AM
> *To: *"bess@ietf.org" 
> *Cc: *Jiang He , P Muthu Arul Mozhi <
> 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 

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

[Muthu Arul Mozhi Perumal]

Thanks, Jorge. This is inline with my thinking. So, in single-active
multihoming, once the primary is dead we don't need to wait for the DF
election to happen for the backup (or some other PE in the ES) to become
active and start forwarding traffic over the ES, instead it only requires
the remote PEs and backup to realize that the primary is dead (thru' NH
tracking / BFD) and start forwarding over the ES, right?

Regards,
Muthu

On Thu, Oct 4, 2018 at 8:10 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> Muthu,
>
>
>
> About this:
>
>
>
> Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
> withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
> session would timeout causing the primary PE's neighbors to flush out the
> A-D routes received from the primary PE, right? This can take several
> seconds, isn't it?
>
>
>
> No, not in the implementations I know of. Next Hop tracking will
> immediately detect that the PE is not in the network anymore and the routes
> will be invalidated. You can also bootstrap the BGP sessions to BFD.
>
> But that has nothing to do with EVPN!.. it’s regular BGP.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Muthu Arul Mozhi Perumal 
> *Date: *Thursday, October 4, 2018 at 1:14 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)"  >
> *Cc: *"jaikumar.somasunda...@ericsson.com" <
> jaikumar.somasunda...@ericsson.com>, "bess@ietf.org" , "
> jiang...@ericsson.com" , "
> p.muthu.arul.mo...@ericsson.com" 
> *Subject: *Re: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Please see inline..
>
>
>
> On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.raba...@nokia.com> wrote:
>
> In-line.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Jaikumar Somasundaram 
> *Date: *Thursday, October 4, 2018 at 11:28 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" ,
> "bess@ietf.org" 
> *Cc: *Jiang He , P Muthu Arul Mozhi <
> 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) 
>
> *Sent:* Thursday, October 4, 2018 1:52 PM
> *To:* Jaikumar Somasundaram ;
> bess@ietf.org
> *Cc:* Jiang He ; P Muthu Arul Mozhi <
> 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. *
>
> Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
> withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
> session would timeout causing the primary PE's neighbors to flush out the
> A-D routes received from the primary PE, right? This can take several
> seconds, isn't it?
>
>
>
> Regards,
>
> Muthu
>
> *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. 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  on behalf of Jaikumar Somasundaram <
> jaikumar.somasunda...@ericsson.com>
> *Date: *Thursday, October 4, 2018 at 10:03 AM
> *To: *"bess@ietf.org" 
> *Cc: *Jiang He , P Muthu Arul Mozhi <
> 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 

Re: [bess] Genart last call review of draft-ietf-bess-mvpn-expl-track-10

[Eric Rosen]

> Minor issues:
> -
>
> As I understand it, if a network only partially supports the new
> (LIR-pF) flag, it doesn't work properly. So we find at the end of
> section 2:
>
> ...the ingress node can conclude
> that the egress node originating that Leaf A-D route does not support
> the LIR-pF flag.
>
> The software at the ingress node SHOULD detect this, and should have
> a way of alerting the operator that the deployment is not properly
> configured.
>
> I don't see why this is only a SHOULD, and I don't see why the operator
> alert is not a MUST too. Surely the operator always needs to be alerted?

Good point, I have changed this to:

    The software at the ingress node MUST detect this, and MUST have a 
way of alerting the operator that the deployment is not properly configured.

> I agree with the point raised in the Routing Area review
> (be explicit about the updated sections of RFC 6514, 6625,
> and 7524).

The clarifications and extensions may affect the procedures for 
originating and receiving/processing S-PMSI A-D routes and Leaf A-D 
routes.  These procedures are discussed in many different places in the 
updated drafts.  I don't believe there is any value in having the 
authors of mvpn-expl-track go through those drafts to try to make a list 
of all the places where S-PMSI A-D routes and/or Leaf A-D routes are 
discussed.  If we attempted to do so, we'd surely miss a few places and 
thereby introduce bugs into the spec.  The information currently in the 
document is sufficient to enable anyone who understands the updated 
references to figure out what needs to be done.

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

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

Muthu,

About this:

Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would 
withdraw the routes if the primary PE / DF itself fails? Instead, the BGP 
session would timeout causing the primary PE's neighbors to flush out the A-D 
routes received from the primary PE, right? This can take several seconds, 
isn't it?

No, not in the implementations I know of. Next Hop tracking will immediately 
detect that the PE is not in the network anymore and the routes will be 
invalidated. You can also bootstrap the BGP sessions to BFD.
But that has nothing to do with EVPN!.. it’s regular BGP.

Thx
Jorge

From: Muthu Arul Mozhi Perumal 
Date: Thursday, October 4, 2018 at 1:14 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" 
Cc: "jaikumar.somasunda...@ericsson.com" , 
"bess@ietf.org" , "jiang...@ericsson.com" 
, "p.muthu.arul.mo...@ericsson.com" 

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

Please see inline..

On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) 
mailto:jorge.raba...@nokia.com>> wrote:
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>>
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
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.
Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would 
withdraw the routes if the primary PE / DF itself fails? Instead, the BGP 
session would timeout causing the primary PE's neighbors to flush out the A-D 
routes received from the primary PE, right? This can take several seconds, 
isn't it?

Regards,
Muthu

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

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

Jai,

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

From: Jaikumar Somasundaram 
Date: Thursday, October 4, 2018 at 12:23 PM
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

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

[Muthu Arul Mozhi Perumal]

Please see inline..

On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.raba...@nokia.com> wrote:

> In-line.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Jaikumar Somasundaram 
> *Date: *Thursday, October 4, 2018 at 11:28 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" ,
> "bess@ietf.org" 
> *Cc: *Jiang He , P Muthu Arul Mozhi <
> 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) 
>
> *Sent:* Thursday, October 4, 2018 1:52 PM
> *To:* Jaikumar Somasundaram ;
> bess@ietf.org
> *Cc:* Jiang He ; P Muthu Arul Mozhi <
> 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. *
>
Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
session would timeout causing the primary PE's neighbors to flush out the
A-D routes received from the primary PE, right? This can take several
seconds, isn't it?

Regards,
Muthu

> *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. 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  on behalf of Jaikumar Somasundaram <
> jaikumar.somasunda...@ericsson.com>
> *Date: *Thursday, October 4, 2018 at 10:03 AM
> *To: *"bess@ietf.org" 
> *Cc: *Jiang He , P Muthu Arul Mozhi <
> 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 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>>
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

[Rabadan, Jorge (Nokia - US/Mountain View)]

In-line.

Thx
Jorge

From: Jaikumar Somasundaram 
Date: Thursday, October 4, 2018 at 11:28 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 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)?

[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. 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>>
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

[Rabadan, Jorge (Nokia - US/Mountain View)]

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.



  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  on behalf of Jaikumar Somasundaram 

Date: Thursday, October 4, 2018 at 10:03 AM
To: "bess@ietf.org" 
Cc: Jiang He , P Muthu Arul Mozhi 

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